Core Banking System

Accounts, ledger and transfers

Design the system of record of a bank: customers and their accounts, an append-only double-entry ledger, transfers and external payments, the end-of-day close, and recovery after losing a region.

Overview

A core banking system is the bank's system of record. It knows every customer, every account and every movement of money, and its ledger is what the bank's books, statements and regulators rely on. Everything else (the mobile app, the card processor, the payment networks) asks the core to approve a change or tells it about one.

The Payment System topic is about a service that moves card payments for merchants, and the Digital Wallet topic about stored balances and peer-to-peer transfers. This problem is one level deeper: the bank itself. The interviewer listens for four things. Does money only ever change through balanced, append-only ledger entries, with mistakes fixed by reversing entries? Is every request safe to retry? How does a payment that leaves the bank, and may come back days later, stay correct without a distributed transaction? And how does the bank close its books each day and survive losing a data center?

The traffic is moderate (a few thousand ledger writes a second at peak), so a well-run relational database at the center is a sound answer. The hard parts are correctness, auditability and recovery.

Questions to ask first

Which products? — Checking and savings deposit accounts; loans and cards are other systems
Who are the users? — Retail customers through apps, and bank staff through internal tools
Volume? — 20 million customers, 30 million accounts, 50 million ledger transactions a day, peak 5 times the average
Which payment rails? — Internal transfers, ACH and wires out and in; card authorizations arrive as holds
Can a balance go negative? — Not through customer actions; overdraft products are out of scope
How much data loss is acceptable? — None for committed transactions within a region; targets for a region loss are set below

What you will be able to do

Model customers and accounts with explicit states, and say what each state allows.
Build a double-entry ledger in SQL that rejects unbalanced entries, refuses edits and fixes mistakes with reversals.
Explain ledger balance, holds and available balance, and post a transfer that is safe to retry.
Run an outgoing ACH or wire payment as a saga with compensations instead of a two-phase commit.
Describe the end-of-day close, reconciliation, the audit trail and the recovery targets for each kind of failure.

Key concepts

System of record
Double-entry ledger
Reversing entries
Ledger vs available balance
Holds
Idempotency keys
Sagas and compensation
Business date and end of day
CQRS read models
RPO and RTO

Functional requirements

Onboard a customer and record their KYC status; only verified customers can open accounts
Open, freeze, unfreeze and close deposit accounts
Show the ledger balance and the available balance of an account
Transfer money between accounts inside the bank
Place, capture and release holds, for example card authorizations
Send and receive ACH and wire payments
Produce monthly statements and daily regulatory and finance reports
Close each business day: interest, fees, general ledger totals and reconciliation

Non-functional requirements

The ledger never loses, creates or edits money; every entry balances and is append-only
A retried request never moves money twice
No committed transaction is lost when a host or an availability zone fails
Internal transfers complete in under 300 ms at p99 (a target we chose)
99.99% availability for posting (a target we chose); statements and reports may lag minutes
Every change by a customer, staff member or batch job is in a tamper-evident audit log

Interview questions

How do you correct a wrong posting?
What is the difference between ledger balance and available balance?
Why not use two-phase commit for a payment that crosses services?
How do you make transfers safe to retry?
Walk me through the end-of-day close.
Where do statements and reports come from?
What are your RPO and RTO targets, and how do you meet them?
How do you stop an insider from moving money?