Instant rails: settled in seconds, always on

Where you are. Your workbench runs two settlement engines. RTGS settles each payment one by one in reserves, final on arrival, and lessons 4 to 6 priced that immediacy: the intraday liquidity bill, the frontier where parked reserves trade against accepted delay, and the gridlock waiting at the underfunded end. The batch rail nets the day’s everyday payments down to differences settled at cutoffs, and lesson 8 named what the cheapness costs: hours of waiting, plus a gap between arrived and final wide enough for a payment to bounce through days later. This lesson adds the third engine, the one your phone actually talks to. It keeps RTGS’s per-payment finality, abolishes its opening hours, and pays its liquidity bill in a way neither engine has tried: entirely in advance.

Sunday, 23:59

It is one minute to midnight on a Sunday and you owe a friend for dinner. You type the amount, press pay, and before you have set the phone down hers buzzes: the money is in her account, hers, final, spendable. Now count what is closed. The RTGS shut on Friday evening and reopens Monday morning. The batch rail’s last cutoff passed hours ago; anything filed now sleeps until tomorrow’s first. Every piece of settlement machinery this module has built is asleep, and yet a payment between two different banks just settled with finality in seconds. Somewhere, central-bank money moved at a moment when nothing that moves central-bank money was open. The resolution of that paradox is the whole lesson: nothing moved central-bank money at midnight. It had been moved already, days earlier, before your dinner was even booked.

The idea in one paragraph

An instant rail is always on and settles every payment individually, final in seconds, because its member banks pay the liquidity bill before the payments exist: each parks reserves into the rail’s joint pool at the central bank - the prefund - while the heavy rail is open to carry them there. A payment at any hour then settles by sliding value from the payer bank’s share of the pool to the payee bank’s; reserves proper never wake. And every payment is credit-push - started by the payer’s own bank, which checks cover first and pushes settled money out - so nothing can arrive that is not already funded and final, which closes lesson 8’s gap between arrived and final to zero. The rail’s answer to “when is this final?” is “now, whenever now is”, and the price of that answer is liquidity parked around the clock.

The gap the first two engines leave

Look at the two engines through the dinner payment’s eyes. RTGS would grant it finality on arrival, but RTGS is engineered for the interbank tier: it keeps business hours, and lesson 4 showed that each gross payment needs its full value present in reserves at the moment it settles - machinery sized for trillions, not for dinner. The batch rail was built for exactly this class of payment, small and numerous, but its answer to “when is this final?” is “at the next cutoff, and then only once the return window shuts”. Between the two engines lies the payment a decade of messaging apps has trained you to expect: everyday-sized, at any hour, final the moment it lands.

Instant rails fill that gap on purpose. They settle per payment, like RTGS; they carry the everyday sizes the batch rail carries, and most cap each payment to keep the trillions where the trillions belong; and they run every second of every day, weekends and holidays included. The engineering question is the one the hook posed: how can settlement in central-bank money happen while the central bank’s own rail sleeps?

Prefunding: the bill, paid before the day begins

Before the weekend, while the heavy rail is still open, each member bank makes one unglamorous move: the prefund. On its own books, reserves falls and an asset called its pool share rises. On the central bank’s books, the bank’s reserve line falls and its pool line rises. Two postings, the tier mirror from module 1 lesson 8 intact on both, and not a unit of central-bank money created or destroyed. Value has been relabelled, from the line RTGS settles on to a line the instant rail owns. That relabelling is the last thing in this story that needs the heavy rail awake.

Then midnight comes, and your dinner payment lands as three postings you have seen before:

1. the payer’s bank: your deposit down, its pool share down;
2. the payee’s bank: its pool share up, your friend’s deposit up;
3. the central bank: the payer bank’s pool line down, the payee bank’s pool line up.

Set this beside module 1 lesson 8’s interbank payment and it is the same animal - six changed lines, tier mirrors and all - with one substitution: everywhere reserves stood, the pool stands. That substitution is the entire trick. Reserve lines move only while the heavy rail is open; pool lines belong to a system that never closes. And conservation survives the substitution untouched: the pool is a closed loop, so payments slide the prefund between banks without ever changing its total, exactly as lesson 8’s payments relabelled reserves without changing theirs.

Credit-push only

Not every payment is started by its payer. A direct debit is pulled by the payee’s side, and the batch day’s return machinery exists partly because a pull can be wrong - wrong amount, dead mandate, no cover - in ways discovered only after it lands. An instant rail closes off that entire genus: it carries credit-push payments only. The payer instructs their own bank; the bank checks that the deposit covers it and that the pool covers it; only then does anything move. Nothing on the rail can arrive unfunded, because the only party allowed to start a payment is the party whose bank can see the money leaving.

That is what makes finality-in-seconds safe to promise. The batch rail can admit payments cheaply and sort out the wrong ones later, because later exists. Here there is no later: what arrives is final, so everything a return would have caught must be caught before the push. One consequence is clean - arrived and final collapse into the same second, and the batch day’s reconciliation limbo simply does not exist. The other is sharp: a payment a fraudster talks you into making settles exactly as finally as one you meant, and the rail cannot unwind it, because unwinding is the thing it was built not to do. Instant rails move the fraud fight from after the ledger to before the push; the card lessons later in this module show a rail that made the opposite choice and kept unwinding as a feature.

What always-on pre-pays for

The pool is not a fee, and it is not new money. It is lesson 4’s intraday liquidity bill, relocated in time.

And the prefund is a hard ceiling. On this rail a bank’s payments are refused the moment its pool share cannot cover them, however rich the bank is, because the one cure - relabelling more reserves into pool - waits for the heavy rail to reopen. That is why prefunds are sized against the worst stretch the heavy rail is closed, not against the average hour.

Live, at scale

Everything above is deliberately stylised - six banks, a round 500 apiece - but the design it teaches is the one running at the largest scales in payments today, and lesson 10 builds the full scoreboard, country by country. Here is enough of it, with sources, to see that the pattern is no pilot.

The spread inside that paragraph is the story lesson 10 tells: the same prefunded, credit-push, always-on machinery, adopted at rates that run from a gradual institutional build-out to rails carrying entire economies’ everyday payments.

Review

Check yourself

Do this

Twenty minutes, from module-02-domestic-rails. Open code/instant_rail.py. The scaffolding builds a six-bank world, wraps it in an InstantRail - which opens a pool line per bank at the central bank, a matching instant pool claim on each bank’s own books, and prefunds each with 500 - then regenerates the module’s seeded payment set and keeps only the last 20: the day’s tail, every one submitted after the batch rail’s final cutoff at minute 1020, the last at minute 1439, one minute before midnight.

Your TODO(you) is the pool-settle posting inside settle_instant. Three ledgers move in the same breath, and reserves proper never wake: the payer’s deposit and the payer bank’s instant pool claim fall; the payee bank’s claim and the payee’s deposit rise; and on the central bank’s ledger, value slides from the payer bank’s pool line to the payee bank’s. Finish with self.assert_pools() so both tiers must still agree, then return the arrival minute unchanged - there is no cutoff to round up to, and the first assert in main fires if you pretend otherwise.

python3 code/instant_rail.py

Green prints the day’s tail twice over: each payment’s instant arrival beside the batch arrival it escaped - all 20 would have slept until minute 2040, tomorrow’s first cutoff - then a mean delay of 643.7 minutes on the batch rail against 0.0 instant, then the price line: 3,000 parked in advance to move 795, with Alder’s pool falling lowest, to 341 of 500. It ends with the line

settled in seconds at any hour: the liquidity was positioned before the payment ever arrived

If pool mismatch raises instead, one of your three postings is missing or lopsided: the two tiers no longer tell the same story, which is module 1’s tier mirror doing its job on the new lines. The completed version is solutions/instant_rail.py; compare after you are green, not before.

What you can now do. You can settle a payment at midnight against a prefunded pool and narrate every line it changes: three postings with the same six-line anatomy as module 1’s interbank payment, with the pool standing everywhere reserves stood, sliding value that was positioned before the payment existed. You can say exactly what the always-on rail pre-pays for - lesson 4’s liquidity bill, paid in advance and parked around the clock, a hard ceiling the rail refuses against when a pool runs dry - and you can place instant where it belongs on lesson 5’s frontier: zero delay, bought with liquidity at weekend rates. What this lesson kept stylised, lesson 10 makes real: the scoreboard of the world’s instant rails as they actually run, who is on them and at what scale - and the one limit every one of them shares, which is that they stop at the border.