Where you are. You have built the rails themselves: RTGS settling one payment at a time in reserves, batch rails collecting all day and settling only the netted differences at cutoffs, instant rails prefunded and always on, and cards - a deferred-net rail wearing a real-time costume, with interchange flowing from the merchant’s bank to the cardholder’s on every sale and chargebacks reversing by added entries, never deletions. Thirteen lessons in, every payment so far has landed on a ledger you can name. This lesson climbs one layer up, to the apps in your pocket that look like rails and mostly are not, and it hands you the one question that sorts all of them: which rail settles this?
The app that feels like a rail
You install a payment app - call it Pouch, this lesson’s stylised provider. A friend at dinner holds up a QR code; you tap; her phone chimes before yours is back in your pocket. Free, instant, weekends included. It feels faster than the instant rail you built in lesson 9 and cheaper than anything on lesson 1’s map, and for a moment it feels like a discovery: a new rail nobody told the banks about. Then ask the question this module has trained into you. Which ledger changed? Not yours at your bank - your account is untouched. Not hers. Not the central bank’s - no reserve line moved anywhere in the system. Every ledger you have met in this course sat perfectly still while money moved between two people. Money moved, so somewhere a ledger changed. Finding it is this lesson.
The idea in one paragraph
A wallet is a balance at one provider. The provider keeps a book of member balances - your 100, your friend’s 60 - and it banks the way any company banks: one pooled deposit account at one bank holds everyone’s money at once. A wallet payment between members is a book transfer inside that pool: the provider’s book debits one row and credits another, and no bank ledger anywhere records a thing. Only crossing the wallet’s boundary touches the rails beneath - cash-in on the way into the pool, cash-out on the way back to a bank account. That is the count this lesson’s exercise pins: five wallet payments, zero interbank settlements. The wallet is not a rail. It is an overlay: a private ledger riding on the rails you built, settling down to them rarely. And one question places every payment product on this map: which rail settles this?
One provider, one pool
Pouch’s whole machine is smaller than it feels. Pouch is a company, so it banks like one: a single deposit account - the pool, stylised here as pouch pool at the bank Maple - holds every member’s money at once. And Pouch keeps a book: one row per member, recording how much of the pool each member may claim. That book is not a bank ledger. The two-tier map does not contain it; it lives on Pouch’s servers, one hop outside the banking system you have been drawing.
Cash-in is where the two worlds touch. You pay 100 from your account at Ivy to pouch pool at Maple - an ordinary interbank payment, lesson 8’s six lines and all - and Pouch credits your row by 100. From that moment your money has two descriptions: the banking system says Maple owes Pouch’s pool 100 more, and Pouch’s book says the pool owes you. Pay another member and only the second description changes: your row down 40, hers up 40, two edits on one company’s book. The pool at Maple does not move. The central bank does not move. Lesson 8 taught you that a same-bank payment touches two lines and an interbank payment six; a wallet payment touches zero - zero bank-ledger lines, that is, because its two entries land on a book no bank keeps.
Wider than the screen; scroll it sideways.
One hop further from tier 1
Module 0’s map of claims returns with a new floor. Tier 1 is reserves, the central bank’s IOU. Tier 2 is deposits, a bank’s IOU backed by its reserves. Your wallet balance sits on a floor the map did not have: it is Pouch’s IOU to you, backed by Pouch’s deposit at Maple, which is Maple’s IOU, backed in turn by Maple’s reserves at the central bank. A deposit puts one balance sheet between you and tier 1; a wallet puts two. Every hop is a balance sheet you are trusting, and the new hop belongs to a company that is not a bank: your balance there is a claim on the provider, not a deposit of yours at any bank, and if the provider fails you stand in a creditors’ queue, not at a teller’s window.
The other overlay: no balance at all
Not every app in the payment aisle keeps a book. A pay-by-bank app - the account-to-account overlay of this lesson’s title - stores nothing: when you pay, it writes an instruction, not an entry. Your authorisation becomes a credit transfer over the instant rail, your bank account pays the merchant’s bank account, and settlement, finality included, is the rail’s own from lesson 9. The app owns the screen and the data and never, at any moment, the money. A third kind looks like a wallet and is neither: an app that stores your card and presents it at the till is a front-end to lesson 11’s four-party flow, and the payment it triggers is a card payment with a new face. Three products, one test, three different answers: the wallet settles on its own book until cash-out; the pay-by-bank app settles over the instant rail every time; the card front-end settles where cards settle, days later and netted.
Where the float sleeps
Back to the pool, because the pool is where the trouble lives. Everyone’s balances gathered into one deposit account have a name: the float - customer money the provider holds between cash-in and cash-out. The rails you built spread risk across many supervised banks and settle in tier 1 money; the wallet gathers its members’ money into one account, at one bank, governed by one company’s book. Convenience concentrated the risk.
Keep that question warm, because it is a promise: module 6 asks it again of stablecoins, where the wallet is planet-sized, the members are anyone with an internet connection, and where the float sleeps becomes the whole design.
Check yourself
1. The exercise runs five wallet payments and the interbank settlement counter does not move. Two entries per payment were written somewhere - on whose ledger, and why does no bank see them?
On the provider’s own book: the payer’s row down, the payee’s row up. The bank holding the pool sees one customer, the provider, and one account, the pool, and that account’s balance never changed - claims on the pool were relabelled inside it. It is lesson 8’s two-line same-bank shape one more time, except the ledger belongs to a company, so even the two lines land outside the banking system.
2. You hold 100 in the wallet. Walk the chain of IOUs from your balance down to tier 1. How many balance sheets are you trusting?
Three. Your 100 is the provider’s IOU to you; it is backed by the provider’s pooled deposit, which is its bank’s IOU to the provider; and that deposit is backed by the bank’s reserves, the central bank’s IOU. A deposit-holder trusts two balance sheets; a wallet-holder trusts three, and the extra one belongs to a company that is not a bank. That extra hop is exactly what e-money safeguarding rules exist to police.
3. A pay-by-bank app and a wallet both show “sent” within a second. What actually happened underneath each?
The pay-by-bank app wrote no entry of its own: it submitted a credit transfer over the instant rail, two banks settled in reserves, and finality is the rail’s, from lesson 9. The wallet performed a book transfer on the provider’s own ledger, and no bank entry exists until someone cashes out; the finality on show is the provider’s promise. Same screen, different plumbing - which is why the sorting question is “which rail settles this”, never “how fast did it feel”.
4. Cash-out is the exercise’s one settlement after the wallet payments. Why does leaving the wallet touch the rails when paying inside it does not?
Inside the wallet, payer and payee both hold claims on the same provider, so the payment relabels claims on one pool and no bank is owed anything new. Leaving the wallet turns a claim on the provider back into a deposit at a different bank: the pool at Maple pays dev’s account at Ivy, the two banks are out of square, and reserves move at the central bank - lesson 8’s six lines return the moment the payment crosses the overlay’s boundary.
5. reconcile() raises “overlay out of square” when member balances no longer sum to the pool. Which module 1 check is this the twin of, and what would a drift mean?
It is assert_world’s tier mismatch, one hop further out: two tellings of one position must agree. There the bank’s own reserves line had to match the central bank’s line; here the members’ rows must sum to the pool. Drift upward means the provider has minted wallet balances no deposit backs - unbacked private money; drift downward means members paid in money they cannot claim. A bank is allowed a gap between deposits and reserves because lending is its business; a wallet provider is not, which is what one-for-one backing means.
Do this
Fifteen minutes, from module-02-domestic-rails; nothing to install, and the script adds the repo root to its own path so the miniledger import resolves on its own. Open code/overlay.py. The Wallet class is complete except for the method this lesson is about: pay, the member-to-member book transfer. Work the TODO(you) in four steps: refuse with LedgerError if the payer’s stored balance cannot cover the amount; move the amount from payer to payee inside self.members, creating the payee’s entry at 0 if absent; assert that self.pool_balance() did not change, because the provider’s bank account must not move for a member-to-member payment; and finish with self.reconcile(), so the stored balances still sum to the pool.
python3 code/overlay.pyThe demo builds three banks - Maple holds the pool, the five members bank at Ivy, their shops at Acorn - and runs the whole argument as asserts. Five cash-ins fund the pool and print cash-in: 5 rails settlements funded the pool. Your pay then runs the day’s five payments with the settlement counter pinned at zero. The same five run again as ordinary interbank payments from the members’ accounts at Ivy to the shops at Acorn - labelled card:, the stylised stand-in for any purchase that settles across banks - and count five settlements. Finally dev cashes out, which must settle interbank exactly once. Green ends with the scorecard and the closing line, exactly:
wallet payments: 5, interbank settlements: 0
card payments: 5, interbank settlements: 5
the wallet is an overlay: its payments settle inside the provider's account, so always ask of any fintech - which rail settles this?If the zero-settlements assert fires instead, you almost certainly reached for world.submit inside pay. Delete it: a wallet payment is two edits to a dict, and the assert in step 3 is the lesson itself. The completed version is solutions/overlay.py; compare after you are green, not before.
What you can now do. You can run five wallet payments with zero interbank settlements and say exactly where the ten row edits went instead: onto the provider’s own book, one hop further from tier 1 than any deposit. You can place any overlay on the rails beneath it - a stored balance settling inside its pool, a pay-by-bank app passing instructions to the instant rail, a card front-end feeding lesson 11’s four-party flow - and for each one name the ledger every entry lands on and the moment, rare or never, that it touches the rails. Above all, you can ask the sorting question of any payment product that crosses your path: which rail settles this? Lesson 15 turns from where entries land to what travels between the machines - the messages themselves, and the one structured language, ISO 20022, now replacing decades of free text on every rail you have built.