Where you are. Seventeen lessons of machinery, and one question left: what did any of it actually change? The course has been careful to answer that lesson by lesson. This lesson puts the answers in one table.
Take module 3’s cross-border payment, the one that went through four institutions over two days. Send the same amount as tokens instead. Measure both.
The interesting part is not that some numbers improved. It is which ones did not move at all.
The idea in one paragraph
Tokenising a payment reliably changes four things: how long settlement takes, whether the legs are atomic, how many separate records must be reconciled afterwards, and whether the payment can be composed with other operations in one transaction. It reliably changes nothing about what the asset is, what it is worth, who owes it, or what a currency conversion costs. So the value is concentrated exactly where the first list dominates the second, and a use case that is mostly about the second list will not be improved by tokenising it however well the implementation is done.
The four rows
The exercise measures both paths on the same payment.
| row | relay | tokenised | change |
|---|---|---|---|
| settlement time, hours | 48 | 0.02 | -100% |
| ledger entries | 8 | 2 | -75% |
| reconciliations | 3 | 0 | -100% |
| FX spread cost | 450 | 450 | 0% |
n = 4 trials · one hundred thousand, the same corridor, measured both ways
Three rows collapse. The fourth does not move by a penny, and it is the row the payer actually notices, because 450 is money and forty-eight hours is an inconvenience.
That is not an argument against tokenisation. It is a statement about where its value is: in the operational cost of the plumbing, which is largely borne by institutions, rather than in the spread, which is largely borne by the customer.
Where that leaves the case
Run the scorecard over the things this course has built and the pattern is consistent.
The cases that work are the ones where settlement time, atomicity and reconciliation dominate: a repo priced by the hour, a delivery-versus-payment that cannot half-complete, collateral that arrives before the margin call expires. All of those are wins on rows that genuinely moved.
The cases that disappoint are the ones sold on the rows that did not: cheaper remittances where the spread is the cost, tokenised property where the asset’s problems are the problem, a wrapper on an illiquid thing that was illiquid because nobody wanted it. Module 6’s wrapper lesson said this about assets, and the scorecard says it about payments; it is the same sentence twice.
Check yourself
1. Which four rows does tokenising reliably change?
Settlement time, atomicity of the legs, the number of separate records needing reconciliation, and whether the payment composes with other operations in one transaction. All four are properties of the plumbing rather than of the asset.
2. Why is the spread identical?
Because nothing about the currencies changed. Somebody still holds both, still carries the risk of holding them, and still charges for it. The rail got faster; the currency pair did not get cheaper to convert.
3. A tokenised corridor is shown beating a bank transfer on total cost. What should you check?
Whether the saving came from the plumbing or from using a different FX provider with a tighter spread. The second saving was available on the old rail too, so only the first one generalises to tokenisation as such.
4. Which use cases does the scorecard predict will work?
Those where settlement time, atomicity and reconciliation dominate the cost: intraday repo, delivery versus payment that cannot half-complete, collateral arriving before a call expires. Those sold on the unchanged rows, such as remittances where the spread is the cost, will disappoint however well they are built.
Do this
Measure both paths.
python3 code/scorecard.pyThe starter provides the relay’s measurements and leaves you tokenised: one hop, two ledger entries, settlement in about a minute, nothing to reconcile, and the FX spread unchanged. The assertions check that settlement time falls by more than a factor of ten, that reconciliations reach zero, that ledger entries fall, and that the spread cost is identical to the penny.
The completed version is in solutions/scorecard.py.
What you can now do. You can measure a tokenised transfer against the legacy relay row by row, name which rows move and which cannot, and use the scorecard to predict which use cases will disappoint. The last lesson runs the whole module as one system.