Part 16 · 8 chapters · ~50 min

Bonus round: “now design a different one”

Fifteen rounds designed one system. The value of that is not the system; it is the skeleton underneath it, which fits almost every money-moving business. This part strips the skeleton out and then reuses it four times at speed, so that when an interviewer changes the prompt you are adapting a structure rather than starting over.

191

The transferable skeleton

Every design in this part is the same nine decisions, answered differently. If you remember nothing else from the module, remember these.

#	The decision	Our answer, and the one to adapt
1	What is the unit of truth?	A balanced, append-only entry. Almost never a balance column.
2	How is money represented?	Integer minor units, with the exponent read from a currency table.
3	What is the invariant?	Entries sum to zero per journal per currency, checked continuously.
4	How do duplicates become harmless?	A unique key on the intent, at the database level.
5	Where does value sit when the outcome is unknown?	A named suspense account, never nowhere.
6	How do other systems learn what happened?	An event log fed by a transactional outbox.
7	How is permission separated from money?	Holds, limits and facilities. Available balance versus ledger balance.
8	How do you prove it is right?	Internal invariant plus external reconciliation against every counterparty.
9	What degrades, in what order?	Decided in advance, with kill switches on the front door only.

the claim being made

Those nine questions have the same good answers for a bank, a neobank, a payment processor, a POS network and a lending platform. What changes between them is who holds the money, who bears the risk, and which counterparties you must reconcile against. Everything else is a variation, and recognising that is what lets you design an unfamiliar system in fifteen minutes.

the fifteen-minute structure, reusable for any of them

0-2 minClarify. Who holds the money? Who bears the loss? Which rails? One currency or many? Regulated as what?

2-4 minRequirements. Functional as verbs, non-functional with numbers. Name what is out of scope.

4-6 minEstimate. Volume, peak, storage, and the one ratio that decides the shape (usually read to write).

6-10 minCore design. The ledger, the invariant, the write path, the read path. This is where the nine decisions land.

10-13 minThe hard part. Whatever is genuinely distinctive about this business. Spend the time here.

13-15 minBreak it yourself. Name what fails first, what you would monitor, and what you deliberately did not build.

192

Designing a retail bank, in fifteen minutes

interviewer

“Design the core of a licensed retail bank. Deposits, transfers, loans, branches, ATMs.”

The one we just built, so the value here is in what a licensed bank adds that our design did not need.

what a banking licence changes

Customer deposits are liabilities on your own balance sheet, not money held at a partner. You are the counterparty.
Capital and liquidity requirements. You must hold reserves against deposits and report ratios to the central bank.
Direct central bank settlement. An RTGS account rather than a relationship with a sponsor bank.
Deposit insurance obligations and reporting per depositor.
Far heavier regulatory reporting, which makes Part 11's four-way pinning mandatory rather than prudent.

what branches and ATMs add architecturally

Cash is a ledger account. A branch till and an ATM cassette each get accounts, and cash movements are postings like any other.
Cash reconciliation is physical. Someone counts the till and the count is reconciled against the ledger. The Part 10 machinery applies, with a human as the counterparty.
Offline capability. A branch with a broken link must still serve customers, which is Part 8's stand-in problem in a different costume.
Dual control. Large cash movements need two staff members, which is the four-eyes rule from Part 9 applied physically.

customer withdraws ₦50,000 at a branch till · cash is just another account

wallet A	−5000000	customer's balance falls
cash:branch_ikeja:till_03	+5000000	the till now holds less cash, tracked as an account
Σ	0	end of day, the physical count must equal this account's balance

the answer that shows the skeleton transferring

"A branch till is an account, an ATM cassette is an account, and the vault is an account. Cash movements are ordinary double-entry postings, and the end-of-day cash count is an external reconciliation where the counterparty is a person with a cash drawer. Nothing new is needed; Part 10's machinery already covers it."

193

Designing a neobank: Cleva, Grey, and the USD problem

interviewer

“Design a product that gives Nigerian freelancers a US dollar account they can receive international payments into, and convert to naira.”

the defining constraint: you are not a bank

The USD accounts are provided by a partner bank in the US, usually as virtual accounts under one pooled omnibus account.
So you hold a claim on the partner, and your customers hold a claim on you. Two layers, and both must reconcile.
You are regulated as a money transmitter or payment service provider, not a deposit-taking bank, which shapes what you may promise.
Your entire business is the FX spread, so Part 7's position management is not a side feature; it is the product.

worked numbers

the two-layer ledger, and why both are needed


          partner bank omnibus account:     $2,400,000

            ↑ this is ONE account at the partner


          our ledger, customer sub-accounts:

            customer A: $1,200  customer B: $840  … 18,000 more

            Σ must equal                 $2,400,000


the daily reconciliation that matters most: our sum of customer

USD balances must equal the partner's omnibus balance, exactly.

a break here means we owe customers more than we hold.

freelancer receives $1,000 from a US client · journal kind: inbound.usd

partner_receivable:USD	−100000	the partner now holds this for us
customer A (USD)	+100000	our liability to the customer
Σ USD	0	and the USD leg balances independently, per Part 7

the hard parts, where the fifteen minutes should go

The USD-to-NGN conversion is the revenue and the risk. Quote with expiry, hold a position, hedge or cap it. This is Part 7 chapter 84, and it is the business.
Naira liquidity. You must actually have naira to pay out, which is a treasury operation rather than an engineering one, and the engineering must expose the position clearly enough to manage.
Partner concentration risk. One partner bank is a single point of failure for the entire product, so the connector abstraction from Part 6 matters more here than anywhere.
Compliance on inbound. Sanctions screening on every international credit, failing closed, per Part 9 chapter 109.
Regulatory ambiguity. Cross-border FX for individuals is politically sensitive in Nigeria, so the compliance-as-data design from Part 7 is what lets you adapt to a rule change in days.

the sentence that shows you understand the business

"The engineering risk is a reconciliation break between our sum of customer USD balances and the partner's omnibus balance, because that gap is money we owe and do not hold. The business risk is the FX position, because the spread is the revenue and an unhedged position can lose more than the spread earns in a single move. Both are ledger balances I can put on a dashboard, which is the argument for the double-entry model paying for itself in a business this small."

194

Designing a PSP: Paystack, Flutterwave, Monnify

interviewer

“Design a payment processor. Merchants integrate an API, accept cards and bank transfers, and get settled the next day.”

what a PSP is, structurally

A collections engine across many channels: cards, bank transfer, USSD, virtual accounts.
A merchant ledger holding what each merchant is owed.
A settlement engine paying merchants on a schedule, net of fees.
A risk engine deciding which merchants to onboard and which to hold funds from.
An integration surface, which is the actual product: SDKs, a dashboard, and webhooks.

a ₦10,000 card payment to a merchant, 1.5% fee · journal kind: collection.card

acquirer_receivable	−1000000	the acquirer owes us this
merchant_payable:M-88	+985000	what we owe the merchant
fee_income:collection	+15000	our revenue
Σ	0	merchant_payable is the balance the dashboard shows them

the hard parts, in order of how much they define the business

Settlement timing and float. Money collected today is paid out tomorrow, so the PSP holds a large overnight balance. That float is both a funding advantage and a liability you must never spend.
Chargeback risk. A card payment can be reversed months later, after the merchant has been paid. If the merchant has vanished, the PSP eats the loss, which makes merchant underwriting a core function rather than an onboarding formality.
Rolling reserves. Hold a percentage of a risky merchant's volume for 90 days as protection. Implemented exactly as Part 5's holds.
Merchant idempotency. Merchants will retry, double-submit and replay. Their reference is the idempotency key, and the API must be unbreakable by a careless integrator.
Webhook delivery to merchants. Now you are on the sending side of Part 6's webhook problem, so you need signing, retries with backoff, and a replay endpoint for when they were down.

the risk nobody mentions unprompted

Merchant credit risk is the PSP's defining exposure. You pay the merchant tomorrow and the chargeback arrives in three months. A fraudulent merchant who collects heavily for a week and disappears leaves the PSP holding every chargeback. That is why rolling reserves, settlement delays and volume caps are risk controls rather than cashflow tactics, and saying so shows you understand what the business actually sells.

PSP money flow

collect, hold, settle, and where the float sits

swipe the figure sideways, or tap expand for full screen

1/8

card charged

A payer checks out on a merchant site and their card is charged.

195

How a PSP differs from a bank, structurally

	Bank	PSP
Who holds the money	You do, as a licensed deposit taker	A partner bank. You hold a claim
Customer balance means	A deposit, insured, withdrawable on demand	An amount owed, payable on a settlement schedule
Primary risk	Credit risk on lending	Chargeback and merchant fraud
Revenue	Net interest margin, plus fees	Transaction fees, plus float income
Balances change	Continuously, in both directions	Up during the day, to zero at settlement
Regulator cares about	Capital, liquidity, deposit protection	Safeguarding client funds, AML
Worst failure	A run on deposits	Settlement failure. Thousands of merchants unpaid simultaneously

safeguarding, which is the PSP's version of capital requirements

Client funds are held in a segregated account, legally separated from the PSP's own money.
They may not be used for operating expenses, however tempting during a cash crunch.
The segregated balance must always equal or exceed the sum of merchant payables.
That is a daily reconciliation with a hard pass/fail, and failing it is a regulatory incident rather than an engineering bug.

code

-- the single most important query in a PSP, run continuously.
-- it is the Part 10 machinery pointed at the one number that
-- determines whether the business is solvent and compliant.
SELECT
  (SELECT balance FROM segregated_account_balance)      AS held,
  (SELECT SUM(-amount) FROM entries e JOIN accounts a
     ON a.id = e.account_id
    WHERE a.kind = 'merchant_payable')             AS owed;
-- held MUST be >= owed. always. any shortfall is an immediate
-- escalation, not a ticket.

the transferable observation

Every money business has one number that must never go the wrong way, and identifying it early is the fastest route to a good design. For a bank it is capital adequacy. For a PSP it is held versus owed. For the neobank it is the omnibus reconciliation. For our CBA it is the zero-sum invariant. Find that number, put it on a continuous check, and the rest of the design organises itself around protecting it.

196

Designing a POS network and its offline problem

interviewer

“Design a POS network for 200,000 agents in Nigeria. Many operate where connectivity is unreliable.”

The genuinely distinctive problem, and the one worth the whole fifteen minutes. Everything else is a variation on what we have already built.

worked numbers

          200,000 terminals × ~40 transactions/day = 8M/day

          peak concentration: 17:00-20:00              ≈ 1,500/s


          but the defining number is:

            ~8% of terminals have unreliable connectivity at any moment

            = 16,000 terminals that may be offline mid-transaction

the four offline cases, and what each permits

Cash-out from a card, online. Normal authorisation. No problem.
Cash-out, terminal offline. Must decline. The agent is handing over real cash against a card we cannot verify, so an offline approval is an unsecured loan to a stranger.
Transfer, terminal offline. Queue it locally and submit when connectivity returns, with the customer told clearly it is pending.
Balance enquiry, offline. Decline. A stale balance shown at a POS terminal causes disputes.

the asymmetry that decides the design

Part 8's stand-in processing works for card purchases and must not be used for cash-out. A card purchase that turns out to be unfunded leaves you with a claim against a merchant who has goods and a business address. A cash-out that turns out to be unfunded leaves you with nothing, because the cash is gone and the agent already handed it over. Same mechanism, opposite decision, and the reason is recoverability rather than risk appetite.

what the agent float model requires

An agent pre-funds a float account with us, and their cash drawer is the physical counterpart.
A customer cash-out debits the customer and credits the agent's float, so the agent's cash decreases and their electronic balance increases.
The agent's float balance is a hard limit: they cannot dispense more than they have pre-funded, which bounds our exposure to exactly zero.
This is why offline cash-out is unnecessary as well as unsafe: the agent's float is the constraint, and validating it requires being online anyway.

customer withdraws ₦20,000 cash from an agent · journal kind: agent.cashout

wallet A	−2000000	customer's balance falls
agent_float:AG-4471	+1990000	agent's electronic balance rises
agent_commission	+10000	the agent's earning on this transaction
Σ	0	the agent gave out cash and received electronic value plus commission

197

Designing a lending platform on someone else's ledger

interviewer

“Design a lending product where you do not hold the customer's account. You disburse into their bank account and collect from it.”

what changes when you do not own the account

You still need a ledger. It tracks what each borrower owes you, which is your asset, and it is entirely your own.
Disbursement is an outbound payment over a Part 6 rail, with all of its uncertainty. The unknown state now means "we may have lent money and not recorded it".
Collection is a pull, via direct debit or a standing mandate, which can be reversed for a period after it succeeds.
You cannot see the balance before collecting, so you are guessing when to attempt, which makes retry strategy a revenue lever.
Your only leverage is the mandate and the credit bureau, rather than the ability to freeze funds.

worked numbers

          the collection retry problem, which is the whole business:


          attempt on the due date                  → ~62% succeed

          retry the next day                      → +9%

          retry on the likely salary date        → +18%

          retry at a partial amount            → +6%


timing and amount, learned per borrower, are worth more than

any collections messaging. this is a prediction problem.

the hard parts

Inferring income timing. Observed credit patterns predict when money arrives, and attempting collection an hour after a salary credit is dramatically more effective than attempting at midnight.
Partial collection. Taking what is available beats failing entirely, and it requires the allocation ordering from Part 5 chapter 60.
Reversal exposure. A collection that is reversed weeks later means the loan was not really repaid, so the cleared balance concept from Part 5 applies to your own receivable.
Mandate lifecycle. Mandates expire, are cancelled, and fail silently. Monitoring mandate health is monitoring your ability to get paid.
Affordability and regulation. Aggressive collection is increasingly regulated, so the protected-floor idea from Part 14 chapter 164 is both ethical and compliant.

the structural observation

"Without the account, I lose the ability to enforce and keep the obligation to collect. So the engineering centre of gravity moves from the ledger, which is now simple, to the collection engine, which is a prediction and retry problem. The ledger still matters, because I must know precisely what is owed and what is only provisionally repaid, and that is exactly the cleared versus ledger balance distinction from round five applied to my own receivable."

198

What stays the same in all of them

	Holds the money	Bears the loss	The one number
Retail bank	Itself	Credit risk on lending	Capital adequacy
Neobank	A partner bank	FX position, partner failure	Omnibus versus sum of customer balances
PSP	A segregated account	Chargebacks, merchant fraud	Held versus owed
POS network	Agent pre-funded float	Almost none, by design	Agent float never negative
Lending platform	Nobody. It moves through	Default risk	Collected versus cleared

the constants, which is the whole point of the module

Double-entry with a zero-sum invariant. Every one of them.
Integer minor units. Every one of them.
Append-only, corrections as new entries. Every one of them.
Idempotency on the intent. Every one of them.
Suspense accounts for uncertainty. Every one that touches an external rail, which is all but the simplest.
Available versus ledger balance. Every one with holds, limits or provisional funds.
An event log with an outbox. Every one with more than two services.
Continuous internal checks plus external reconciliation. Every one, and the counterparties differ.
Designed degradation with kill switches. Every one that runs at 3am.

the closing thought for the whole module

The system we spent fifteen rounds building is not the deliverable. The deliverable is that you can now be handed an unfamiliar money business and know which nine questions to ask, which answers are almost always right, and which one number must never go the wrong way. The architecture is transferable because the constraints are: money must be conserved, networks are unreliable, duplicates happen, and somebody has to prove it was right afterwards. Those do not change when the prompt does.

the skeleton

five businesses, one structure

swipe the figure sideways, or tap expand for full screen

1/7

five businesses

Five money businesses that look completely different from the outside.