Where you are. Nine lessons ago this module promised to rebuild a country’s rails on your miniledger, and it has kept the promise one engine at a time: an RTGS engine that settles each payment at submission in full reserves, the intraday liquidity bill and the queue frontier that immediacy creates, the offsetting pass that clears a deadlocked queue, a batch engine that nets a day of payments down to positions at two cutoffs, and, in lesson 9, an instant engine that buys always-on finality with prefunded pools. This lesson stops building and starts judging: it puts every rail in one table whose every cell comes from a run you made or are about to make, and then shows how to read the real world’s version of the same table without being fooled.
Four machines, one day, one table
Look at this module’s code/ directory. rtgs_rail.py, dns_batch.py, instant_rail.py - three settlement engines, each built on the same miniledger import, each fed the same kind of synthetic day. A fourth machine is not in the directory because it is in your pocket: the card, whose tap put five parties behind one gesture back in module 0’s opening lesson, and whose engine you build next. Four machines that all do the same job - move a deposit from one person’s bank to another’s - and the obvious question is the one every procurement meeting asks: which one is best?
Every operator of a real rail has a slide answering that question, and the slide always says the same three words: fast, cheap, always on. This lesson answers it differently, with a table where every cell is a number and every number came out of this module’s own simulations. The difference between the slide and the table is the difference between an adjective and a measurement.
The idea in one paragraph
Score the module’s four rails on four columns - speed, cost, size and hours - and fill every cell from the module’s own runs: the delay means from lesson 9’s fixture, the prefund the instant pools parked, the full-cover rule the RTGS replay enforced, two card numbers run ahead from lessons 11 and 12. A scoreboard you computed is one you can defend, because every cell has a source you can re-run, a denominator you can name and a slice you can state; a scoreboard you were handed has adjectives where those should be. The finding is that no rail wins every column - speed, cost, size and hours trade against each other, which is why a country runs all four machines at once rather than crowning one. And when the real world enters the table, it enters under the same discipline: a live rail’s history reads as a sequence of dated steps, never as a compressed jump from launch to today.
Four rows, sixteen cells
Walk the rows in the order the module built them. Every number is stylised - produced by the module’s committed fixtures, sized to be checked at sight - and each one names the run that made it.
RTGS. Speed: 0 minutes while the rail is open, and this is the one cell that is true by construction rather than measured - lesson 3’s engine settles each payment at submission, so there is no wait unless you underfund the rail. Cost is lesson 4’s whole subject in six words: 100 of reserves per 100 moved, gross - every payment posts its full value in central-bank money at the moment it settles. Size: any, because cover is checked in full. Hours: a business day; then the rail closes, and the biggest payments in the country wait for morning.
Batch (DNS). Speed is the first cell that must name its slice: 643.7 minutes mean, measured over the fixture’s last 20 payments - the ones that missed the day’s final cutoff and slept until the next settlement. Cost: net positions only, lesson 7’s compaction at work - a day of gross flow settles as a handful of differences over the heavy rail. Size: everyday sums, in bulk; that is what the rail is for. Hours: two cutoffs, and a payment that misses the last one is not late, it is tomorrow’s.
Instant. Speed: 0.0 minutes mean over the same late 20 - this pair of cells is the module’s sharpest contrast, the same payments scored on two rails - and the always-on half holds right to the edge: a payment submitted at minute 1,439 of the 1,440-minute day settles on arrival. Cost is not a fee but a float: 3,000 parked before the day began, six banks times 500 of prefund, to move 795 of value. Size: pool-capped at 500 per bank, and a payment the pool cannot cover is refused rather than queued. Hours: 24/7, the column instant rails exist to win.
Cards. The fourth machine is built in lesson 11, but two of its numbers are printed here, run ahead of you from the next lessons’ own exercises. Speed is two numbers, and the row is dishonest with only one of them: authorisation 0 minutes - the yes/no at the till - and the money 1,440 minutes later, cleared and then settled the next day. Cost: of a 100.00 sale, the merchant keeps 98.50; where the missing 1.50 goes, and why, is lesson 12’s entire subject. Size: purchase sized. Hours: tap 24/7, settle on batch days - a deferred-net rail wearing a real-time costume.
The cell you cannot defend
One column is missing from the table, and it is the one this section prints: what each cell would need before a stranger should trust it.
The real world, as dated steps
The real scoreboard exists, with country names on the rows. Brazil’s Pix and India’s UPI are instant rails that have become the way their economies pay day to day; the United States’ FedNow, the Federal Reserve’s instant rail, is on a more gradual build-out; and they are not alone - instant rails now run on every major currency’s home turf. Their cells move monthly: volumes, participation, ceilings. So this lesson pins exactly one real sequence, dates it, and uses it to show the shape every real cell should take. The cell chosen is FedNow’s size column - the per-payment ceiling - because it has moved three times since launch.
Read the figure the way the scoreboard taught you to read a cell. The compressed telling - “FedNow’s limit rose from $500,000 to $10 million” - is true and nearly useless: it hides which ceiling was in force when, erases the two-year plateau between launch and the first raise, and leaves nothing to check. The dated steps keep everything: which size cell applied on any given date, the pace the operator chose, and three anchors you can verify against the announcements themselves. A milestone sequence is dated steps; the jump is what a slide makes of it. And notice what the sequence does to the gotcha above: this one cell grew twentyfold in twenty-eight months, which is why a real scoreboard cell without a date is not just vague but wrong by default - the table underneath it keeps moving.
One more thing the real table shows that the module’s does not: an edge. Pix settles reais among Brazilian banks; UPI settles rupees in India; FedNow settles dollars among banks with Federal Reserve accounts. Every rail in this module - and every real rail it models - stops at the boundary of its own central bank’s ledger, because that ledger is where its reserves live. What happens one step past that boundary is module 3’s opening question.
Check yourself
1. The instant row’s cost cell reads “3000 parked to move 795”, not a fee per payment. What is the cell measuring, and why is it the honest price of the hours column?
Liquidity, not fees. The pools were prefunded with 3,000 - six banks times 500 - before the first payment arrived, because a rail that settles at minute 1,439 cannot wait for a treasurer to top up an account. The parked money is the price of always-on finality: it moved only 795 of value all day, and the gap between parked and moved is what 24/7 costs. Lesson 9 measured it; the cell just quotes the run.
2. The batch rail’s speed cell says “643.7 min mean” and then, in brackets, “late 20”. What breaks if the brackets are dropped?
The number loses its slice and stops being checkable. 643.7 is the mean over the fixture’s last 20 payments, the ones that missed the final cutoff and slept over; the same engine scored over the whole day prints a smaller mean, because payments that make a cutoff wait minutes, not overnight. Without the brackets a reader cannot tell which question the cell answers, cannot reproduce it, and cannot catch you if it is wrong - which is exactly the state a marketing slide prefers.
3. The cards row is the only one with two numbers in its speed cell. Which one does the advert quote, and what does the scoreboard force to sit beside it?
The advert quotes authorisation: 0 minutes, the yes/no at the till, and it is a real measurement - the tap genuinely resolves in seconds. The scoreboard forces the second number alongside: the money moves 1,440 minutes later, cleared and then settled the next day, because underneath the real-time costume a card runs on a deferred-net rail. One cell, two truths; showing only the first is how a batch rail gets remembered as an instant one.
4. Why does this course write FedNow’s ceiling as three dated steps rather than “raised to $10 million”?
Because a milestone sequence is only checkable as dated steps. The compressed jump hides which ceiling applied when - a $700,000 payment was over the ceiling in May 2025 and under it in July 2025 - erases the pace, and leaves no anchor to verify or to re-research when the number moves again. Each step carries its own date and its own announcement, so each can be checked, and the asof date on the whole claim says when the sequence was last known to be current.
Do this
Twenty minutes, from module-02-domestic-rails, standard library only. Open code/scoreboard.py. The constants at the top are the table’s raw material, already filled in, and each block is commented with the run that produced it: lesson 9’s fixture for the delay means and the prefund, lessons 3 and 4’s construction for the RTGS cells, and the two card numbers run ahead from lessons 11 and 12. Note what is deliberately absent: not one real-world figure lives in the file, because code cannot carry an expiry date - perishable numbers belong in lesson prose under asof dates, and the file’s header comment says exactly that.
Work the TODO(you) in build_rows: four rows, in the order the module built the rails - RTGS, batch (DNS), instant, cards - each a tuple of five short strings matching COLUMNS. Quote the constants; the starter’s own comment states the exercise’s rule - “fast” is an opinion, “643.7 min mean” is a measurement. For size and hours, state what the simulations enforced: full cover, the pool ceiling, the two cutoffs, 24/7. The asserts are the spec - four rows, no blank cells, the rails in order, plus three sanity checks that the constants still say what the module measured.
python3 code/scoreboard.pyDone right, it prints your aligned table and ends with the line
no rail wins every column: speed, cost, size and hours trade against each other, so a country runs all four at onceIf the “blank cell is a dodge” assert fires, you probably left a column unanswered for a rail where the honest answer felt like “it depends”. It never does: every rail enforces something in every column, and the enforcement is the answer. The completed version is solutions/scoreboard.py; compare after your table prints, not before.
What you can now do. You can score this module’s rails against each other with a table you can defend cell by cell: every number traces to a committed fixture and a run you can repeat, every mean names its slice, and the columns’ trades - speed against cost, size against hours - explain why a country operates four rails rather than electing one. And you can read the real world’s version of the table without being fooled: a live rail’s history as a milestone sequence of dated steps, checked against the operator’s own announcements, never a compressed jump. The next three lessons open the fourth machine - the card rail’s full choreography, the economics of the missing 1.50, and the rules for unwinding a payment after the money has already moved - and turn the two previewed numbers in your scoreboard into runs of your own.