How Money Learned to Travel at the Speed of Light
The Money Stack — Episode 2 of 10
In 1871, Western Union noticed something peculiar about its own network.
It had spent a decade stringing copper wire across an entire continent to carry words. But it also had offices in hundreds of towns, each holding cash, each staffed by an agent, each connected to every other by telegraph. At some point, somebody looked at that infrastructure and realised something quiet and revolutionary: they did not need to move money at all.
You walked into a Western Union office in New York and handed over fifty dollars. The clerk tapped out a message in code. In San Francisco, another clerk read the message, verified a password, and counted fifty dollars out of a drawer that had been sitting there all along.
No money crossed the country. Two ledgers were updated. The value arrived in minutes.
That is still, in every essential respect, how it works today. Everything that followed — SWIFT, Fedwire, your banking app, the transfer you sent last Tuesday — is a refinement of the thing Western Union figured out with a telegraph key in 1871. Money does not travel. Messages travel. Money is what the ledgers say after the message arrives.
The Messy World Before the Standard
For most of the twentieth century, banks that wanted to communicate with each other had to invent their own way of doing it.
Every pair of institutions developed its own message formats, its own codebooks, its own test keys for verifying authenticity. If your bank in Lagos wanted to send a payment instruction to a bank in Frankfurt, you needed a bilateral agreement, a shared cipher, and a telex operator who knew both systems. If you wanted to reach a bank in Tokyo as well, you needed a separate agreement, a separate cipher, and a separate set of procedures.
This was not merely inconvenient. It was a security disaster waiting to happen. Formats were ambiguous. Errors were common. Fraud was difficult to detect because there was no standard against which to check anything. The global banking system was a patchwork of bilateral arrangements that happened to work most of the time, and catastrophically failed when it did not.
By the late 1960s, the volume of cross-border transactions had grown large enough that the industry could no longer ignore the problem.
SWIFT: A Messaging Network, Not a Payment System
In 1973, two hundred and thirty-nine banks from fifteen countries formed a cooperative in Brussels to fix it. They called it the Society for Worldwide Interbank Financial Telecommunication. SWIFT went live in 1977.
Before going any further, it is worth stating clearly what SWIFT is and is not, because this is the most common misconception in any discussion of international payments.
SWIFT is not a payment system. It moves no money. Not a single dollar, pound, naira, or euro passes through SWIFT's network. SWIFT is a secure, standardised messaging network. It carries instructions. When your bank sends a SWIFT message, it is sending a very precisely formatted document that says: "Please transfer this amount, from this party, to this party, on this date." What happens to the actual funds depends entirely on what the receiving bank does with that instruction.
This distinction matters enormously, and understanding it explains most of the frustrations people have with international payments: the delays, the fees, the uncertainty, the occasional disappearance.
Inside an MT103
The workhorse of the SWIFT network is a message type called the MT103: the standard format for a customer credit transfer, the message that moves when you wire money abroad.
Here is what one looks like, stripped to its essential fields:
:20: REF20260805001 → Sender's reference number
:23B: CRED → Bank operation code
:32A: 260805USD5000,00 → Value date, currency, amount
:50K: NEXORATECH CONSULTS → Ordering customer
:57A: DEUTDEFF → Intermediary bank
:59: SHENZHEN PARTS CO → Beneficiary
:70: INVOICE 4471 → Remittance information
:71A: SHA → Who pays the charges
Every field is significant, but two deserve particular attention.
Field :32A: crams three separate pieces of information into a single string with no delimiters between them: a six-digit value date in YYMMDD format, a three-letter currency code, and the amount — where the decimal separator is a comma, not a full stop. The system reads it by character position. Characters one through six are always the date. This format was standardised in 1977, when every transmitted character had a cost, and nobody has got round to redesigning it since.
Field :71A: is the one that determines who absorbs the fees. It takes one of three values. OUR means the sender pays all charges; the beneficiary receives the full amount. SHA means shared: the sender pays their own bank's fee, and every intermediary bank along the route deducts its own cut from the payment in transit. BEN means the beneficiary pays everything.
Most banks default to SHA. Most customers have never been told this. It is why your five thousand dollars sometimes arrives as four thousand nine hundred and fifty-three, and why nobody can tell you in advance exactly how much will disappear.
The Correspondent Banking Chain
Here is the part that explains why international transfers take days rather than seconds.
Almost no two banks on earth have a direct relationship with each other. Your bank in Lagos almost certainly does not have an account at a small regional bank in Germany, and that German bank almost certainly does not have an account at your bank.
Instead, both banks have accounts at larger correspondent banks: institutions that maintain relationships with a wide network of other institutions. When you send a payment abroad, it does not travel directly from your bank to the beneficiary's bank. It hops.
Your bank sends a SWIFT message to its correspondent. The correspondent checks whether it has a direct relationship with the destination bank. If not, it passes the message to its own correspondent. This may happen two or three times before the payment reaches its destination.
Each hop is a separate institution with its own operating hours, its own compliance checks, its own cut-off times, and its own fee. A payment that leaves Lagos on a Friday afternoon may not reach the first correspondent until Monday, because the correspondent operates on New York business hours and does not process on weekends. Each leg of the journey runs on its own clock.
This is why international transfers take three to five business days. Not because the technology is slow: the SWIFT message itself travels in seconds. Because the settlement chain involves multiple human institutions, each operating in sequence, each adding their own delay.
Nostro and Vostro: The Ledgers Underneath
To understand how banks actually hold and move funds across borders, you need two words of Italian.
When your bank maintains an account in foreign currency at another bank abroad, your bank calls it a nostro account — from the Latin for "ours." The other bank, looking at the same account, calls it a vostro account — "yours." Same account, two names, depending on whose perspective you are taking.
These accounts are the pre-positioned liquidity that makes correspondent banking possible. Your bank keeps dollars in a nostro account at a US correspondent. When you send a dollar payment, your bank instructs the correspondent to debit that nostro and credit the next institution in the chain.
No dollars cross the Atlantic. The nostro balances change. Settlement happens in the background, in batches, at the end of the business day or the next. The speed and the settlement are entirely separate concerns, and they run on different schedules.
The Bangladesh Bank Heist
In February 2016, attackers with valid SWIFT credentials attempted to move nine hundred and fifty-one million dollars out of the Bangladesh Bank.
They had been inside the bank's systems for months. They understood the SWIFT interface well enough to issue fraudulent transfer instructions that were, as far as the network was concerned, completely legitimate. The messages were properly formatted, correctly authenticated, and successfully delivered.
Eighty-one million dollars left the account and was transferred to the Philippines before anyone noticed.
The remaining eight hundred and seventy million was stopped not by a security system, not by a fraud detection algorithm, not by any technical control. It was stopped by a spelling error. One of the fraudulent messages directed funds to an organisation called the Shalika Foundation. The routing bank in Germany, suspicious of a large transfer to a private entity in Sri Lanka, looked more carefully and noticed that the message spelled it "Fandation."
A single mistyped vowel stopped the largest attempted bank heist in history.
The lesson is not that attackers are careless. It is that the SWIFT network, by design, has no concept of intent. It authenticated every message perfectly. It delivered every instruction faithfully. It did exactly what it was built to do. The protocol assumed that anyone with valid credentials had legitimate business to conduct, and that assumption cost eighty-one million dollars.
The Format That Refuses to Die
ISO 20022 is the successor standard that the banking industry has been migrating towards for the better part of a decade. Where MT103 is positional and terse, ISO 20022 is structured XML: named fields, explicit schemas, rich remittance data. An invoice reference can travel with the payment instead of being crammed into a free-text line. Errors are detectable at the message level rather than discovered at reconciliation.
The migration has been underway since 2022, with coexistence periods that keep extending. The old format and the new run side by side, and MT messages remain in daily use across a significant share of global payment flows.
This is not laziness. Replacing messaging infrastructure that underpins trillions of dollars in daily transactions requires every institution in the correspondent chain to upgrade simultaneously, or to maintain translation layers at every boundary. The technical migration is straightforward. The coordination problem is not.
A format designed for 1970s telex constraints is still running the global payment system because changing it requires the agreement of thousands of institutions across dozens of jurisdictions, each with their own timeline and their own risk appetite.
What SWIFT Could Not Solve
SWIFT standardised the message. It did not solve the settlement. It did not eliminate the intermediaries. It did not make the process instant, transparent, or predictable in cost.
By the time SWIFT went live in 1977, the world already had a different problem emerging: not how to send messages between banks, but how to let ordinary people make payments to each other, quickly, without needing to know anyone's account details or bank codes.
The answer to that problem was already being prototyped in California. And it would arrive not in a teletype message, but in an envelope. Sixty thousand envelopes, to be precise, sent to the residents of Fresno without their permission.
Episode 3: The Card — how Visa built a real-time distributed network decades before the term existed. Coming 9th September, 2026.
The Money Stack is a ten-part series on the history and technology of how money moves.
