Banking / Fintech Database Schema Examples

These banking schema examples show how the same customer-account-ledger core adapts to a neobank wallet, a traditional core banking system, a lending platform, and a payments processor.

Edit this banking schema template Back to template

Banking / Fintech Database Schema Examples

Real examples

Neobank wallet (the modern baseline)

Who uses it: Fintech team building a digital-only bank

Customer with kyc_status and document references

Account simplified — usually one wallet per customer

Transaction always produces two LedgerEntry rows

Card issued from a card-network partner (Visa/Mastercard)

No physical Branch — replace with an Issuer reference

Why this works: Neobanks strip the schema to its essentials — one wallet per customer and a clean double-entry ledger. The diagram drops branches in favor of a partner reference, since the customer never visits one.

Traditional core banking

Who uses it: Bank running multiple account types and channels

Branch as a first-class entity for in-person banking

Multiple AccountTypes: checking, savings, money market, CDs

Interest accrual table joined to AccountType rate

Tellers and ATM withdrawals produce transactions

Customer can hold multiple accounts of different types

Why this works: Traditional core banking carries more product variety — the diagram keeps Branch and expands AccountType, because the same customer holds a checking + savings + CD with different rates and behaviors.

Lending platform

Who uses it: Team building a consumer or SMB lending product

Loan (principal, interest_rate, term_months, status)

Repayment table with scheduled vs actual payments

Credit score and KYC fields on Customer

Loan disbursement is a Transaction that credits Account

Each repayment is a Transaction with two LedgerEntry rows

Why this works: Lending puts Loan and Repayment at the center — the diagram still uses the double-entry ledger for money movement, with loan disbursement and repayment each producing standard Transaction rows.

Payments processor

Who uses it: Team building a Stripe-style payments product

Merchant (id, business_info, payout_account_id)

Payment (id, merchant_id, customer_id, amount, status)

Settlement batches roll up payments for daily payouts

Refund and chargeback tables linked to original payments

Fee structure modeled as per-merchant pricing rules

Why this works: A payments processor's schema centers on Merchant and Payment — the diagram restructures customers as endpoints (payer/payee) and adds settlement batching, because the product is moving money between parties, not holding deposits.

Tips for better study mind maps

Always model money movement with Transaction + LedgerEntry (double entry); a single 'transfer' row hides errors and breaks audit.
Store Account balance as a denormalized cache, but reconcile it against the sum of LedgerEntry rows — the ledger is the truth.
Put KYC status and document references on Customer; compliance audits require easy querying.
Use account_no as an external identifier separate from the surrogate id — account numbers are customer-facing and immutable, ids are internal.

Start editing online

Go back to the template, swap in your own topics, and keep the same structure if it fits your class or project.

Use this template: /editor/new?template=banking-fintech-database-schema

Edit this banking schema template