Banking System Design Interview: Double-Entry Ledger, Holds, Transfers and Sharding

One transfer of Rs 500, inside the bank and to another bank

Asha (account 1001) sends Rs 500 to Ravi (account 2002) at the same bank. Then she sends Rs 500 to her landlord at a different bank. Amounts are stored as whole paise, so Rs 500 is 50,000.

1. 1

   Send with a key

   Asha taps Send. The app creates one idempotency key for this transfer and sends POST /transfers with from 1001, to 2002, amount 50,000 paise and the key.

2. 2

   Check limits and fraud

   The transfer service asks the limits and fraud service. Rs 500 is within Asha's daily limit, Ravi is a saved payee, and the fraud score is low. The answer is allow.

3. 3

   Record the key

   The service opens a database transaction and inserts the key. If the key already exists, this is a retry. It rolls back and returns the stored reply, and no money moves twice.

4. 4

   Lock in order

   It locks the balance rows of 1001 and 2002 with SELECT ... FOR UPDATE, a database command that reads rows and locks them. It locks the lowest account id first. Any other transfer touching either account now waits for this one.

5. 5

   Check the money

   Asha's available balance is her ledger balance minus her holds, plus any overdraft limit (money the bank lets her borrow by going below zero). It is at least Rs 500, so the transfer can go ahead. If it were not, the service would roll back and reply "insufficient funds".

6. 6

   Post both legs

   It inserts journal row T-901, an entry of -50,000 on 1001 and an entry of +50,000 on 2002. The entries sum to zero. It updates both balance rows, inserts a transfer.posted event into the outbox, and stores the reply next to the idempotency key. Then it commits, and both locks are released.

7. 7

   Tell everyone

   The relay publishes the event to the event log. The statement service adds a line to both histories, and the notification service sends Asha and Ravi an SMS.

8. 8

   Another bank: debit into suspense

   For the landlord, the same kind of transaction debits Asha 50,000 and credits the bank's NEFT outward suspense account 50,000. The transfer row is marked PENDING. Asha's balance drops at once, so she cannot spend the money twice.

9. 9

   Send through clearing

   The clearing gateway reads the event and sends the payment in the next NEFT batch. NEFT settles in half-hourly batches, and the landlord's bank is expected to credit him within two hours of the batch settling.

10. 10

    Settle or return

    When the batch settles, the bank posts the amount from the suspense account to its NEFT settlement account and marks the transfer COMPLETED. If the landlord's bank cannot credit him, it returns the money. The return comes back through the transfer service as a new credit to Asha. Nothing is ever edited.

These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.

The double-entry ledger: two entries, sum zero

Start with the design to reject: one balance column per account, changed in place. The payment system guide on this site explains in full why that fails. For a bank there is one more reason. To the bank, a customer's deposit is a liability: money the bank owes someone. An auditor checks those liabilities line by line, so every rupee in every balance must be explained by a record. Double-entry bookkeeping gives that. Stripe's engineering team calls it a standard method for making sure all money in a system is accounted for. Every entry is a debit or a credit. For a customer's account, which is money the bank owes, a debit takes money out and a credit puts money in. That is why a salary arriving is a credit to your account. For the bank's own asset and expense accounts it is the other way round: a debit makes them grow. Accountants call these two kinds credit-normal accounts (they grow with a credit, like customer deposits) and debit-normal accounts (they grow with a debit, like cash or interest expense). Every money movement is written as at least two entries, and the entries of one movement always sum to zero. In software, store each entry as a row with a signed amount. Credits are positive and debits negative, for every account. The bank's own asset and expense accounts then carry negative balances, and the screen flips the sign when it shows them. A transfer of Rs 500 is then one journal row and two entries: -50,000 paise on Asha and +50,000 paise on Ravi. The sum is zero. A balance is the sum of an account's entries, so a balance can always be explained line by line. Store amounts as whole paise in a 64-bit integer, never as floating point, because floating point cannot store 0.10 exactly and small errors add up over billions of rows. Check the zero-sum rule in the database itself, not only in the code. A deferred constraint trigger is a check the database runs at commit time, after all the rows of the transaction are in. Use one that sums the entries of each transaction and refuses the commit if the sum is not zero. Then even a bug cannot create money.

Two balances: ledger balance, available balance and holds

Every bank app shows two numbers, and a good answer explains why. Money takes time to finish moving. When Asha pays Rs 2,000 with her debit card, the shop's card machine asks the bank to approve the payment. The bank says yes, but the shop collects the money later, often days later. In between, the Rs 2,000 is promised but not taken. If the bank only looked at the ledger balance of Rs 10,000, Asha could send Rs 9,000 to Ravi, and then the shop's Rs 2,000 would arrive with only Rs 1,000 left. So the bank places a hold: a record that reserves part of the balance for one approved payment. The ledger balance is the sum of posted entries: Rs 10,000. The available balance is the ledger balance minus the holds, plus any overdraft limit: Rs 8,000 here. Every new spending decision is checked against the available balance. Modern Treasury describes the same idea for any ledger: the available balance counts outgoing pending amounts as already gone and incoming pending amounts as not yet arrived, because that is the safe way to approve a new transaction. TigerBeetle, a database built only for ledgers, has this built in: a pending transfer reserves the amount, and a later transfer posts it (makes it final) or voids it (cancels it), or it expires. A hold has three endings. Capture: the shop collects, and the bank posts a real transaction (debit Asha, credit the card settlement account) and closes the hold in the same database transaction, so the available balance does not jump. Release: the shop cancels, the hold closes and the money is free again. Expire: nothing happens before the expiry time, and a job closes the hold. Each ending is a guarded update, WHERE status = 'ACTIVE', so a capture and an expiry that arrive together cannot both win. A capture can be for a different amount than the hold, for example a tip added at a restaurant, and it can arrive after the hold has expired. The bank has already promised the card network to pay, so the capture path posts anyway, against the ledger, without a balance check. If that pushes the account below zero, the shortfall goes to the bank's collections process instead of being refused. Keep held_amount on the balance row and change it in the same transaction as the hold. Then placing a hold and spending the money are protected by the same row lock.

BEGIN;
SELECT ledger_balance, held_amount
FROM   account_balances WHERE account_id = 1001
FOR UPDATE;                          -- 1,000,000 posted, 0 held
-- app checks: ledger_balance - held_amount + overdraft_limit >= 200000
--             (overdraft is 0 here: 1,000,000 - 0 + 0 >= 200,000)
INSERT INTO holds (hold_id, account_id, amount, status, expires_at)
VALUES ('H-77', 1001, 200000, 'ACTIVE', now() + interval '7 days');
UPDATE account_balances
SET    held_amount = held_amount + 200000
WHERE  account_id = 1001;
COMMIT;

SELECT ledger_balance - held_amount + a.overdraft_limit AS available
FROM   account_balances b JOIN accounts a USING (account_id)
WHERE  account_id = 1001;            -- 800,000 paise = Rs 8,000

An internal transfer: one transaction, locks in account order

Asha to Ravi, same bank, is the case to explain most carefully. Atomicity means the transfer happens completely or not at all. It is the A in ACID, the four promises a database transaction makes. So the whole transfer is one database transaction. Inside it, the hard part is two transfers that touch the same accounts at once. Suppose Asha sends Rs 500 to Ravi while Ravi sends Rs 300 to Asha. The first transfer locks Asha's row and then wants Ravi's. The second locks Ravi's row and then wants Asha's. Each waits for the other, forever. This is a deadlock. PostgreSQL finds deadlocks and aborts one of the transactions, but which one it picks is hard to predict, and the aborted transfer must be retried. Its documentation gives this very example, two accounts updated in opposite orders. It also gives the fix: make every transaction take its locks in one consistent order. So always lock the lower account id first. Both transfers now want 1001 first. One gets it, and the other waits. Nobody waits in a circle. Use SELECT ... FOR UPDATE on the balance rows. In PostgreSQL, FOR UPDATE locks the selected rows, so any other transaction that tries to update or lock them waits until this transaction ends. With both rows locked, the service reads the available balance, and nobody can change it between the check and the write. That gap is where a classic bug lives. The balance is Rs 1,000. Two withdrawals of Rs 1,000 each read it at the same time. Each sees enough money, and both succeed. Keep the transaction short: run the fraud check before BEGIN, and send events through the outbox. There is another way to stop the double spend. The isolation level of a database is the rule for what one transaction can see of others running at the same time. The strictest level, Serializable, prevents every anomaly, meaning every wrong result that comes from transactions overlapping. But PostgreSQL then aborts one of two clashing transactions with a serialization error, and every caller must retry. Explicit row locks in a fixed order give the same safety with fewer surprises, because here the rows a transfer touches are known in advance.

BEGIN;
INSERT INTO idempotency_keys (customer_id, idem_key, request_hash)
VALUES (77, 'k-7f3a', 'sha256:91c2...');     -- conflict = retry, stop
SELECT account_id, ledger_balance, held_amount
FROM   account_balances
WHERE  account_id IN (1001, 2002)
ORDER  BY account_id                          -- lowest id first, always
FOR UPDATE;
-- app checks Asha: ledger_balance - held_amount + overdraft_limit >= 50000
--                  (overdraft is 0 here)
INSERT INTO transactions (txn_id, kind, idem_key) VALUES ('T-901', 'INTERNAL', 'k-7f3a');
INSERT INTO ledger_entries (txn_id, account_id, amount)
VALUES ('T-901', 1001, -50000), ('T-901', 2002, 50000);   -- sums to 0
UPDATE account_balances SET ledger_balance = ledger_balance - 50000 WHERE account_id = 1001;
UPDATE account_balances SET ledger_balance = ledger_balance + 50000 WHERE account_id = 2002;
INSERT INTO outbox (txn_id, type) VALUES ('T-901', 'transfer.posted');
UPDATE idempotency_keys SET txn_id = 'T-901', response = '{"status":"POSTED"}'
WHERE  customer_id = 77 AND idem_key = 'k-7f3a';    -- a retry gets this reply
COMMIT;

Never update, never delete: corrections are reversing entries

A bank's history must stay exactly as it happened. An auditor, a regulator or a court may ask what an account looked like on 3 March three years ago. The answer must not depend on whether someone edited a row since. So ledger entries are immutable: once written, never changed and never deleted. Enforce this in the database, not only by habit. The database role the application uses gets INSERT and SELECT on ledger_entries and nothing else. Then even a bug or a careless script cannot run UPDATE or DELETE. TigerBeetle's documentation makes the same rule: accounts and transfers are immutable once created. Mistakes still happen. A transfer was posted twice, a fee was charged by error, an amount was keyed wrong. The fix is a new transaction that reverses the old one: copy each entry of the wrong transaction with the opposite sign. The two transactions together sum to zero for every account, so the balance returns to where it was. The history shows the mistake, the fix, who made the fix and why. Martin Fowler's accounting patterns call this a reversal adjustment: for each wrong entry you post an opposite entry that cancels it. Then post the correct transaction as a new one, if there was a correct amount. Three details matter. First, a transaction may be reversed only once, so put a unique index on reverses_txn_id. Second, a reversal runs through the same path as any transfer, so the statement shows it and an SMS can say so. Third, a reversal may not always be possible. If Ravi has already spent the Rs 500 that reached him by mistake, the reversal would push his account below zero. That is a business decision, not a database one. The bank may freeze the amount, ask the customer, or move the loss to an internal account. It never edits the original entry.

BEGIN;
INSERT INTO transactions (txn_id, kind, reverses_txn_id, reason, created_by)
VALUES ('T-955', 'REVERSAL', 'T-901', 'posted twice', 'ops:priya');
-- unique index on reverses_txn_id: a second reversal of T-901 fails here
INSERT INTO ledger_entries (txn_id, account_id, amount)
SELECT 'T-955', account_id, -amount
FROM   ledger_entries
WHERE  txn_id = 'T-901';             -- +50000 on 1001, -50000 on 2002
-- then lock both balance rows in account-id order and apply the same
-- amounts to ledger_balance, and write a transfer.reversed outbox event
COMMIT;

Transfers to other banks: pending, settlement and returns

When Ravi's account is at another bank, your database cannot write to his account. The money has to leave your books and arrive in theirs, through a clearing network. In India the main ones are NEFT and RTGS, owned and run by the Reserve Bank of India, and IMPS, run by NPCI. They behave differently, and that changes your design. NEFT works in batches. The RBI says it runs in half-hourly batches, around the clock, every day of the year. The receiving bank should credit the customer within two hours of the batch settling. If it cannot, it must return the money to the sending bank within two hours of the batch completing. RTGS settles each payment one by one, in real time. It uses no netting, which means payments are not added up and offset against each other first. Its minimum is Rs 2 lakh, and there is no upper limit. The receiving bank must credit the customer within 30 minutes. A payment that cannot be credited goes back within one hour, or before the end of the RTGS business day if that comes sooner. The RBI describes IMPS as a 24x7 instant domestic funds transfer service, run by NPCI. Design the outward transfer as a small state machine on top of the ledger. A state machine lists every state a transfer can be in and the only moves allowed between them: PENDING, then SENT, then COMPLETED or RETURNED. Step one is local and immediate. In one transaction, debit Asha, credit the NEFT outward suspense account, and mark the transfer PENDING. Asha's balance drops at once, so she cannot spend the money twice. Step two: the clearing gateway sends the payment in the next batch and marks it SENT. Step three comes from the network's settlement report. The bank posts the amount from the suspense account to its settlement account for that network, and marks the transfer COMPLETED. If a return arrives instead, the bank posts a new transaction back to Asha, marks the transfer RETURNED, and sends her an SMS. IMPS adds two twists. First, IMPS answers in seconds with success, failure or no answer. No answer means unknown, not failed. Keep the money in suspense, ask the network for the status, and only then complete or return it. Second, IMPS credits the customer instantly, but the banks settle with each other later, in cycles; the RBI's 2021 statement mentions these IMPS settlement cycles. So an outward IMPS also sits in a suspense account until its settlement cycle. Each step is a short transaction that is safe to repeat. Once everything in transit has settled, the suspense account should be back at zero, so a nightly check that it matches the transfers still in flight finds lost messages fast. Inward transfers are the mirror image: the network's message becomes a credit to the customer and a debit to the network's settlement account, posted by the transfer service.

Interest, fees and the end-of-day batch

Not every money movement starts with a customer. Interest, fees, standing instructions and statements come from scheduled jobs. This is batch processing: work collected and run in large groups on a timetable, instead of one request at a time. This page assumes interest on a savings account is worked out on each day's closing balance and paid every quarter. The real rule comes from the account's terms and the regulator, so say "assume" in the interview. The design has two parts. Every night, for every account, the job computes that day's interest from the closing balance and adds it to an accrual record per account. Accrual means interest that has been earned but not yet paid. The ledger gets one summary transaction for the night: debit interest expense, credit interest payable, an internal account for interest the bank owes but has not paid yet. On payout day, one transaction per account moves the money: credit the customer, debit interest payable. The batch must be safe to rerun. If it crashes at account 31 million, running it again must not pay the first 31 million twice. Give each posting a natural idempotency key, such as interest:account_id:2026-Q3, and insert it with the posting, so a rerun finds the key and skips. Process accounts in order of account id, in chunks of a few thousand, each chunk its own short transaction. Save the last account id done, so a restart picks up there. Short chunks matter because daytime transfers keep running. NEFT, IMPS and RTGS run around the clock, so there is no quiet night in which the bank can pause all transfers. The "closing balance" must therefore be defined by a cut-off time, not by when the job happens to read the row. Use the entries posted before midnight (posted_at earlier than 00:00:00 of the next day), not the live balance row, and a transfer at 00:00:05 belongs to the next day. The same batch closes the day. It checks that every transaction sums to zero, that each balance row equals the sum of its entries, and that suspense accounts match the transfers still in flight.

Sharding accounts and the cross-shard transfer

At the peak in the estimates, about 40,000 row writes a second under strict locks, one database server is a risk. Sharding splits the data across several database servers, and each server is called a shard. A shard key decides where each row lives. For a bank, the shard key is account_id. Each account's balance row, entries, holds and idempotency keys live on one shard. Queries for one account, the most common kind, touch one server. The trouble starts with a transfer: Asha may live on shard 1 and Ravi on shard 4, and one ordinary database transaction cannot span two servers. There are two ways out. The first is two-phase commit. A coordinator, one process in charge of the transfer, asks both shards to prepare. Both promise they can commit. Then the coordinator tells both to commit. This keeps the transfer atomic, but it has two costs. If the coordinator crashes after prepare, both shards keep their locks until it comes back. And every cross-shard transfer holds its locks across two network round trips. The second way, more common in ledger designs, splits the transfer into two local transactions joined by an internal account, the in-flight account. On shard 1, in one transaction: debit Asha, credit shard 1's in-flight account, write an outbox event. On shard 4, triggered by that event: debit shard 4's in-flight account, credit Ravi. Each local transaction sums to zero on its own shard. Between the two steps the money sits visibly in the in-flight accounts, never lost. This is a saga, a chain of local steps where each has an undo step. If Ravi's account turns out to be closed, shard 4 rejects it, and shard 1 posts a reversing transaction back to Asha. Both steps carry the transfer id as an idempotency key, so a repeated event never credits Ravi twice. A nightly check that the in-flight accounts sum to zero catches stuck transfers. Make this case rarer by keeping all accounts of one customer on one shard: shard by customer id, so moving money between your own savings and current accounts stays local.

Hot accounts: the merchant and the bank's own accounts

Sharding spreads accounts apart. It does nothing for one account that every transfer touches. A hot account is one that a large share of transfers write to: a big merchant's collection account during a sale, a government tax account on a due date, or the bank's own fee income account, which receives a credit with every fee charged. Every posting to an account must lock that account's balance row. A row lock is held until commit, and with a synchronous standby the commit waits for the standby too. If one posting holds the lock for about 2 milliseconds, including that wait, one row can take at most 1,000 / 2 = 500 postings a second, however many shards you add. At a peak of 5,800 transactions a second, a fee account touched by one in four of them would need 1,450 a second, nearly three times what one row can do. Three fixes, in order of how often they are used. First, an account that only receives money never needs a balance check. The check exists to stop spending money that is not there, and nobody spends from the fee income account in real time. So postings to it can insert the entry without locking a balance row, and a job folds new entries into the balance every few seconds. The entry is still written in the same transaction as the customer's side, so the transaction still sums to zero. Second, split the hot account into sub-accounts. The merchant's collection account becomes 16 sub-accounts, a posting picks one by hashing the transfer id, and the merchant's balance is the sum of the 16. Each row now takes one sixteenth of the load. Third, for accounts that do need a balance check and are very busy, batch the postings: queue requests for a few milliseconds and post them together in one transaction with one lock. The same trap hides in the batch. If 50 million interest payouts each lock the bank's interest payable row, at 500 a second that is about 100,000 seconds, more than a day. The bank's internal accounts never need a balance check, so post to them without locking their balance row and fold their entries into the balance afterwards, or post one total per chunk. Name the hot account before the interviewer does.

How a Banking System actually does it

Each mechanism on this page is documented by the people who build or run it. Martin Fowler's accounting patterns describe an account as a list of entries whose balance is their sum, and the reversal adjustment. Modern Treasury explains debit-normal and credit-normal accounts and defines posted, pending and available balance. TigerBeetle's documentation covers immutable transfers, a flag that stops a customer account going below zero, and holds as pending transfers. Stripe's Ledger post describes an immutable double-entry log of five billion events a day. PostgreSQL's documentation covers FOR UPDATE, the two-account deadlock, Serializable retries and synchronous replication. The Reserve Bank of India's FAQs give the NEFT and RTGS timings used above, and its 2021 policy statement describes IMPS and its settlement cycles.

Frequently asked questions