Where you are. Lesson 10 priced the danger of paying first: deliver your currency leg before the other side fails to deliver theirs and the loss is total, a risk with a dead bank’s name on it. Lesson 11 named the family of cures and had you build the strongest member: pvp_settle, an atomic commit across two currency ledgers, both legs at one instant or neither at all. You also carry a piece of module 2 that is about to matter enormously: lesson 7’s netting, which collapsed a day of payments into one signed number per bank and shrank reserve traffic 10.6x. This lesson welds those two parts together and shows you the weld running in production: CLS, the specialist hub where the world’s biggest FX-trading banks settle their currency trades with each other. The exercise has you build a toy with exactly its shape.
The biggest machine you have never heard of
Ask a room of engineers to name the machines that move the world’s money. Visa, someone says at once. PayPal. After lesson 2 you would add Swift, and enjoy explaining that it moves no money at all. The room runs dry long before anyone says CLS - a system almost nobody outside wholesale banking can name, and it settles more value before lunch than most payment systems see in a year. It has no app and no retail customers. It sits one layer below every story this module has told, beneath the remittance apps and the correspondent chains, at the depth where the banks themselves square up the currency trades that all of that activity generates. And it exists because the industry eventually decided to manufacture the both-or-neither promise as infrastructure rather than keep hoping the other side pays.
The idea in one paragraph
CLS is lesson 11’s primitive built as an institution. Member banks submit both legs of each FX trade to a specialist hub that holds an account in every currency it settles. Before the daily settlement window, the hub nets each member’s obligations per currency - dollars against dollars, yen against yen, never across - so each member pays in only the currencies where its book nets short. Inside the window, every trade settles both legs at one instant across the hub’s own books; afterwards the hub pays out the net long balances and keeps nothing. PvP supplies the safety: for a covered trade, the gap Herstatt died in never opens. Netting supplies the affordability: the cash a member must find in the morning is its imbalance, not its volume, a sliver of the gross value it settles. The exercise’s toy is this paragraph, runnable.
Net, fund, settle
The hub’s day is three moves, and you have already built two of them.
Move one: net per currency. The toy seeds thirty trades among six members, every one dollars against yen: the seller delivers dollars and receives yen, the buyer the reverse. Run module 2 lesson 7’s arithmetic twice, once per currency: for each member, one signed dollar number and one signed yen number, each book summing to zero because inside a currency every delivery is some other member’s receipt. The new discipline is what you must not do: there is no exchange rate inside a netting engine. Each trade fixed its own price when it was struck; by netting time there are only deliveries owed, each in its own unit, and dollars cancel only dollars.
Move two: fund the net. Where a member’s book nets short it pre-funds exactly that amount to the hub before the window; where its book nets long it simply waits to be paid out. That sentence is where the business case lives, so watch it land on the seeded fixture:
Move three: settle, both legs at one instant. The window opens, and before anything moves a validation prelude checks every member’s pay-in against every net - lesson 11’s rule that all checks run before any writes. In the toy a missing pay-in refuses the whole window, the bluntest possible enforcement of both-or-neither; the real system has gentler machinery for a failed pay-in, but it protects the same invariant: no member’s leg settles unless the matching leg settles with it. Then each currency book posts as one balanced posting, and the hub ends the day holding exactly the pay-outs and nothing else. Pay-ins drain, pay-outs land, the hub keeps nothing.
Notice what the hub never does: it never moves money across a border. Lesson 1 drew this module’s map as closed domestic ledger worlds with no edge between them, and the hub respects the geography - dollars stay in the dollar world, yen in the yen world, which is why it holds one account per currency rather than one account. The toy makes the point structurally: two separate World objects that share nothing, joined only by the atomicity of pvp_settle running across both. What CLS manufactures is not a bridge for money but simultaneity between worlds that have no bridge.
Wider than the screen; scroll it sideways.
The figure is the toy’s seeded day. The gold pair is the fixture’s first trade - Dogwood sells 448 dollars to Elm for 67,200 yen - and both of its legs meet at the hub inside the same window: that meeting is the entire content of the letters PvP. Around the rim, the mono labels show what each member actually funds: gross obligations of 6,938 dollars plus 1,040,700 yen collapse to pay-ins of 2,128 dollars plus 319,200 yen. Every trade settles in full; only the funding shrinks.
The real machine
The toy reproduces a shape. Here is the thing itself, at its real size:
Hold the toy against those last two numbers. Your thirty trades among six members will cut funding by 69.3 percent; the real hub reaches about 96 before its liquidity-saving machinery pushes further. The gap is not a bug in the toy. A netting ratio is a property of how much flow happens to offset, not of the engine: thirty trades leave lumpy books, while a full day of global interbank FX runs the same names against each other so many times that the books nearly cancel. What the toy reproduces exactly is the shape - gross settled in full, funding collapsed to imbalances, both legs atomic. The coefficient belongs to the traffic.
Check yourself
1. Why is there no exchange rate inside net_per_currency, and what would break if you converted the yen book to dollars and netted one combined book?
The rate’s work is already done: each trade priced its own yen leg when it was struck, and what remains are deliveries owed, each in its own unit. Netting may only aggregate deliveries of the same thing. A combined book would let a dollar receipt cancel a yen debt - an exchange nobody agreed to make - and the net it produced would depend on whatever rate you picked at netting time, so the hub would be silently taking currency risk on every member’s behalf. The toy enforces the discipline by shape: two books returned, each zero-summing on its own.
2. Birch settles ten trades and nearly 1,800 dollars of gross dollar obligations, yet funds its whole day with 150 yen. Where did the rest of the funding go?
It cancelled inside Birch’s own books: 896 dollars sold against 897 bought nets to one dollar received, and the yen mirror of that is 150 delivered. Nothing about Birch’s trades settled small - every one settles at face value across the hub’s books - but funding follows the net, and Birch’s day was almost perfectly balanced. Funding scales with imbalance, not volume: module 2’s reserve arithmetic, returned per currency.
3. State exactly how the hub deletes lesson 10’s danger, and what must be true before the window is allowed to move any money.
Herstatt risk lives in the gap between paying away one leg and receiving the other. The hub gives that gap nowhere to open: both legs of every covered trade settle in one atomic step across its books. For the promise to hold, the validation prelude must confirm every pay-in before any posting runs - all checks before any writes - and a member that has not funded causes a refusal, never a partial settlement. Before the window, pay-ins sit at the hub with nothing settled; queued is not settled, and at no instant has any member paid a leg away without the matching leg landing.
4. The real system nets about 96 percent; your toy prints 69.3. Is the toy wrong, and what would move its number?
The toy is right and its number is honest. A netting ratio measures how much flow offsets, and that belongs to the traffic, not the engine: thirty trades among six names leave lumpy imbalances, while a global day of interbank FX crosses the same names densely enough that obligations nearly cancel. More trades among the same members would deepen the toy’s cancellation without changing a line of the engine. The real system then goes further still: its liquidity-saving mechanisms take funding from about 96 to about 99 percent below gross. The shape transfers; the coefficient does not.
Do this
Twenty minutes, from module-03-across-borders. Open code/cls_toy.py. The fixture seeds thirty FX trades among six member banks, dollars against yen at one stylised rate of 150 held fixed all day: the seller delivers dollars and receives yen, the buyer the reverse. build_hub and pvp_settle are already written - one hub bank per currency world, members endowed with exactly their pay-ins, and lesson 11’s primitive scaled up to a validation prelude plus one balanced posting per currency book, with assert_world() run on both. Your work is net_per_currency: start two dicts at zero, make four updates per trade - seller’s dollars down, buyer’s dollars up, buyer’s yen down, seller’s yen up - assert each book sums to zero, and return both.
python3 code/cls_toy.pyGreen is exactly this scoreboard, ending with the final line verbatim:
trades settled 30
gross obligations 6938 dollars + 1040700 yen
pay-ins after netting 2128 dollars + 319200 yen
funding vs gross 4256 vs 13876 (dollar equivalent)
funding reduction 69.3%
a CLS-shaped hub nets per currency and settles only the nets, both legs at one instant - members fund a fraction of the gross they settle, which is the shape of the real system's savingThe funding line counts both books in dollar equivalents, and the toy’s fixed rate makes the yen book an exact mirror of the dollar book, which is why 13,876 is twice 6,938. If the zero-sum assert fires, you dropped one of a trade’s four legs: inside one currency, every delivery is someone’s receipt. If the mirror assert fires, your yen directions are flipped - the buyer delivers yen, the seller receives it. And if you caught yourself reaching for RATE inside net_per_currency, stop: a netting engine has no exchange rate, and the harness touches the rate only to check the mirror, an artefact of pricing every toy trade at one fixed number. When you are green, break it on purpose: shave one unit off any endowment in build_hub and run again. The whole window refuses - REFUSED whole - which is the both-or-neither promise enforcing itself. The completed version is solutions/cls_toy.py; compare after you are green.
What you can now do. You can run a PvP hub end to end: net a day of FX trades per currency, fund only the imbalances, and settle every trade both legs at one instant across the hub’s books, with a validation prelude standing guard in front of the postings. You can read CLS Group’s real figures and recognise the two parts you welded - lesson 11’s atomicity for the safety, module 2’s netting for the affordability - and you can say where the fence runs: 18 currencies and a membership, with everything outside still settling the way lesson 10 drew. The netting did quiet work all lesson and has earned a closer look: lesson 13 strips it down to two banks settling their difference, lesson 14 rebuilds the hub and names what it concentrates, and lesson 15 weighs the trade honestly - cash moved against risk gathered into one central point.