Where you are. You arrive as a working software engineer, fluent in Python, with no finance background; that is the exact profile this course is written for, and nothing on this page assumes anything more. A first lesson owes you a map before it owes you detail, so this one follows a single contactless card tap through every machine it touches, names the five parties involved, and counts how many records of money actually changed. Everything after this lesson is the same map, redrawn at higher resolution.
Two hundred milliseconds, then a day and a half
You tap your card for a coffee. The reader beeps before your arm finishes the gesture; call it two hundred milliseconds. You take the cup and stop thinking about the payment, which is exactly what everyone who built the system wants.
Here is what you did not see. The beep was an answer, and producing it took a round trip of messages through three institutions you never saw. And the beep was only the start: work on your coffee continued that night, after the shop had closed, and finished the next day inside a fourth institution, one you have probably never thought about at all. The fastest part of your payment took a fifth of a second. The slowest part took a day and a half. Nothing about the cup in your hand hints at either number.
The idea in one paragraph
The machinery that moved your coffee money is shared infrastructure, and shared infrastructure is invisible precisely because it works. You think about DNS on the day it fails; you think about payment machinery on the day your card declines for no reason you can see, or a transfer takes three days to “arrive”. This course is a guided tour of that machinery: what the parts are, why each one exists, what happens when one breaks, and what the people now rebuilding it believe they can do better. The tour starts with the tap you just made, because the most ordinary payment in your day already touches almost everything the course will name.
The five parties behind the beep
Start at the tap, with the first party: you, the cardholder. Your card and the reader run a short cryptographic handshake, and the terminal builds a message: card, amount, shop. This is an authorisation request, and it is a question, not a payment: will this card’s bank stand behind this amount?
The terminal speaks to the shop’s bank, which the card world names for what it does.
The acquirer cannot answer the question; it has never heard of you. It forwards the request.
It forwards it to the card network, the brand printed on the card. The network is a router with a memory. It reads the card number, works out which bank issued this card, passes the question along, and writes the exchange into its log. It has no account for you and none for the shop.
The question lands at your own bank, the fourth party and the only one that can answer.
The issuer can answer. It checks your balance, runs its fraud checks, decides yes, and places a hold on your account: the amount is fenced off so it cannot be spent twice. That hold is the first real state change of the whole trip, an edit in the issuer’s ledger.
The yes retraces the path, issuer to network to acquirer to terminal, and the reader beeps. Around two hundred milliseconds, one round trip.
Now notice what has not happened: no money has moved. The shop holds a promise. Your bank holds a hold. The shop’s bank has recorded a pending receivable, an entry meaning money is on its way. Messages, holds and log lines; bookkeeping about a payment that has not yet occurred.
That night, and the next day
That night the network runs what the industry calls clearing: it totals the day. Between your bank and the shop’s bank there were taps in both directions from morning to close; clearing adds them all up and reports who owes whom overall, and how much. Still no money has moved. Clearing produces a bill, not a payment.
The next day the banks square up, and the fifth party enters: the central bank, the institution where the commercial banks themselves hold their accounts - the banks’ bank. Your bank’s own balance at the central bank goes down; the shop’s bank’s balance goes up. This is the moment money finally moves. The shop’s bank then credits the coffee shop’s account, minus its fees, and the hold on your account becomes a real deduction. A day and a half after the beep, the payment has actually happened.
Count what changed. Five parties: cardholder, acquirer, card network, issuer, central bank. Three ledgers of money edited: the issuer’s, the acquirer’s, and the central bank’s. Not yours, because you do not keep a ledger; your account is a row in the issuer’s. And not the network’s, because it keeps a log of messages, and a log of messages is not a ledger of money.
Wider than the screen; scroll it sideways.
One line of housekeeping, needed once in the whole course: nothing in this course is investment advice; it explains how the machinery works, not what to buy.
The card system you just traced is one machine among several that move money, and the course needs a word for them.
This module draws the rest of the map. It walks the history that produced the machine - money as a record, paper promises that became bank money, banks meeting to swap only their differences, the telegraph - until the whole system fits a two-tier picture you can hold in your head, then closes with a project: a toy two-bank system in Python whose passing assertions prove you can trace a payment across both tiers. The whole course is eight modules. The first six describe the machine as it is: this orientation, money at rest, the domestic rails, payments across borders, the markets bolted on top, and the machinery that multiplies positions and contains their failures. The last two follow the rebuild now being attempted, which claims the message and the money can be fused into a single object on one shared list; lesson 7 gives that claim its name, and the course treats it as something to test, not something to take on faith.
Check yourself
1. The beep came back in two hundred milliseconds. What had actually moved by the time you left the shop?
Nothing. The round trip produced a hold on your account at your bank, a pending receivable at the shop’s bank, and a log entry at the network: bookkeeping about a payment that had not yet happened. The money moved the next day, when the two banks’ own balances at the central bank changed against each other.
2. Name the five parties, and say which one never holds the money.
Cardholder, acquirer (the shop’s bank), card network, issuer (your bank), central bank (the banks’ bank). The network never holds it: it routes the authorisation and keeps the log the nightly totals are computed from. The name printed on the card is the one with no money in it.
3. Five parties, but only three ledgers of money changed. Which three, and why not five?
The issuer’s (your hold becomes a real deduction), the acquirer’s (the shop’s account is credited), and the central bank’s (the two banks’ balances there move against each other). Not five, because the cardholder keeps no ledger - your account is a row in the issuer’s - and the network keeps a log of messages, which records the payment without ever holding the money.
Do this
The trace you just read is committed as a script. From module-00-orientation/, run the starter:
python3 code/card_tap_trace.pyIt replays the six hops, then fails on purpose: LEDGERS_TOUCHED is still None. Read the trace and fill in the number of distinct ledgers of money that changed, remembering that a log of messages is not a ledger of money, then run it again. When your count is right the script exits cleanly and its final line is:
ledgers of money touched: 3The completed version is in solutions/card_tap_trace.py; check it only after your own run passes.
What you can now do. You can take the most ordinary payment of your day and read it the way an engineer should: five named parties, a fast message path, a money path a day and a half behind it, and exactly three ledgers edited. You can also state the course’s working method back to it: plumbing stays invisible while it works, so each lesson will make one piece of it visible on purpose. The next lesson goes looking for the oldest piece of all - what money itself is - and finds not a thing but a record.