Where you are. Module 3 built a cross-border payment and found the conversion sitting in the middle of it as a separate act, with its own counterparty, its own timing and its own settlement risk. Herstatt was the name for what happens when that middle step goes wrong.
You have spent five lessons building things that convert one asset into another: a pool, an auction. Both live on the same ledger as the money.
So the conversion no longer has to be a separate act. It can be a leg.
The idea in one paragraph
When the payer’s asset, the payee’s asset and the venue that converts between them are all on one ledger, the debit, the conversion and the credit can be a single posting. There is no interval during which one currency has left and the other has not arrived, because there is no interval at all: the posting commits in full or does not happen. Module 3 needed an entire lesson on the danger of paying first; here the danger has nowhere to live, and it is worth being precise that this is a consequence of everything sharing a ledger rather than of the assets being tokens.
Wider than the screen; scroll it sideways.
The failure that changes nothing
The exercise pays five hundred dollars, converts at the quoted rate, and credits the payee. Then it does the same thing again with a failure injected between the legs.
The assertion is not that an error was raised. It is that every account balance is exactly what it was before the attempt: the payer still has their dollars, the payee still has nothing, and the sheet still balances. Nothing partial exists anywhere for anyone to have to unwind.
That is the same test module 3 applied to payment versus payment and module 6 applied to delivery versus payment, and it is the property this whole course keeps returning to.
One sheet, one unit of account
The exercise carries a detail worth pausing on, because it catches people out.
A balance sheet is denominated in a single currency. A euro balance sitting on a dollar ledger is carried at its dollar value, not at its euro figure, or the sheet cannot balance at all. So the exercise posts the dollar value and reports the euro amount alongside it.
That is not a modelling shortcut. It is the accounting rule that makes multi-currency balance sheets work everywhere else, arriving in a place where people often assume tokens have repealed it. They have not: a ledger that mixes units without converting them is a ledger that will fail to balance the moment anybody checks.
What it is worth
The saving is real and it is narrower than the enthusiasm suggests, which is worth stating now because lesson 18 measures it properly.
What goes away is the settlement risk of the conversion and the reconciliation between three parties’ records of it. What does not go away is the spread. The rate in the exercise is a real rate from a real venue, and somebody is earning the difference between the buy and sell side of it exactly as they were before. The conversion got safer and did not get cheaper.
Where the quote comes from
One loose end is worth tying, because it connects this lesson to the two before it.
The rate has to come from somewhere. For a small payment it can come from the pool of lesson 2, and the conversion is literally a swap inside the payment. For a large one the pool’s price is the wrong price, for exactly the reason lesson 2 measured, so the rate comes from a quote of the kind lesson 5 built, and the payment carries the accepted quote as one of its legs instead.
Both compose the same way, which is the useful part. The payment does not care which venue priced it; it cares only that the conversion can be expressed as a leg that commits with the others.
Check yourself
1. What made the conversion a separate act in module 3, and what changed?
The conversion happened at a different institution, on a different system, at a different time from the payment legs, so it had its own counterparty and its own settlement risk. What changed is that the payer’s asset, the payee’s asset and the venue are now on one ledger, so the conversion can be a leg of one posting.
2. The exercise injects a failure between legs. What does it assert, and why that?
That every balance is exactly what it was before the attempt. Asserting merely that an error was raised would pass even if one leg had already been applied, and a partially applied payment is the failure the whole design exists to prevent.
3. Why is a euro balance carried at its dollar value on this ledger?
Because a balance sheet is denominated in one unit of account, and mixing units means the sheet cannot balance. This is the ordinary accounting rule for multi-currency books; tokens have not changed it, and a ledger that ignores it will fail its own check.
4. What does this atomicity depend on, and what does it not survive?
It depends on everything sharing one ledger. It does not survive a leg moving to another ledger: paying for euro tokens from an ordinary bank account restores the gap and the settlement risk in it, which is exactly the problem lesson 13 takes up.
Do this
Compose the payment and break it.
python3 code/midflight_fx.pyThe starter builds the ledger and leaves you pay_and_convert: move the value from payer to payee in one posting, return the euros that buys at the rate, and raise before posting anything at all when a failure is injected. The assertions check that the payment settles, that the injected failure leaves every balance untouched, and that an unfunded payment is refused.
The completed version is in solutions/midflight_fx.py.
What you can now do. You can compose a payment whose conversion is one of its legs, prove that a failure between legs changes nothing, and say precisely what that guarantee depends on. The next lesson returns to markets and asks who takes the other side of a leveraged trade.