A comprehensive core banking database schema for retail and digital banking platforms. Includes customer onboarding with KYC, multi-type account management (checking, savings, business), transaction ledger with double-entry support, inter-account transfers, debit/credit card issuance, and loan lifecycle tracking with interest rates. Suitable for neobanks, fintech startups, or traditional bank modernization projects.
transactions.balance_after is the column that makes this a banking schema rather than a list of amounts. Every row records what the balance became, so a statement can be printed without replaying the account from opening, and any disagreement between the running figure and accounts.balance is detectable at the exact row where it started.
A transfer is one row in transfers and two in transactions. The transfer is the instruction with its own status; the transactions are what actually happened to each account. That separation is what lets a transfer be pending, fail, or reverse without leaving one side debited and the other untouched.
Cards never store a card number. cards keeps a card_number_hash for matching and last_four for display, which is the only arrangement where a leaked database does not hand over usable card credentials — the real number lives with the issuer and this row refers to it.
accounts.balance is what every screen reads, and the transactions ledger is what proves it. Keeping only the ledger makes every balance check a sum over an unbounded table; keeping only the column leaves no way to explain a figure. Both means a transaction must update the account in the same atomic write, and balance_after makes the two reconcilable row by row rather than only in aggregate.
Recording a transfer as two transactions alone loses the fact that they belong together — a failed second leg would look like a withdrawal that simply vanished. The transfers row carries the status of the whole operation, which is what makes a reversal possible and what a customer sees when the money has left but not yet arrived.
The full schedule exists as rows with due dates before any money moves, each splitting principal from interest. That makes the next payment a query rather than a calculation, lets a missed payment be a row with a status instead of an absence, and keeps the amortisation visible to the customer. Early repayment means rewriting the remaining rows, which is the known cost.
Identity verification is a property of the person, not of each account they hold, and regulation requires it before an account can transact. Keeping it on customers means one check gates everything they own, and a customer whose verification lapses is blocked everywhere at once rather than account by account.