ISO 20022 Academy
100 · Library

What Is a Payment? Moving Value Without Moving Cash

A payment is information changing two ledgers, plus everyone agreeing it really happened. Work out why the message and the money are two different things and the whole field settles down.

7 min read · free, no signup
Read in the interactive Academy →

Two thousand miles, and nothing moved. Bob taps "send $400" on his phone in Dubai. A second later Sweety's bank in Bangalore shows the money as hers. No truck, no courier, no cash crossed the 2,000 miles between them. So what actually travelled?

Last article you built money and found out it's really just numbers on a ledger. So let's use that. Instead of being told what a payment is, design one yourself and watch what you're forced to send.

You're the courier who can't carry cash

{{think}} Here's your job. Get $400 from Bob in Dubai to Sweety in Bangalore. One catch: you're not allowed to move a single physical thing. No cash, no gold, no object of any kind can leave Dubai.

You've still got to make Sweety end up with the money. What do you actually send? {{reveal}} All you can send is a message. Something like "take $400 off Bob, put it on Sweety."

That's the whole trick. Because money is numbers on ledgers, you don't need to move value at all. You move an instruction, and the value changes hands when two ledgers get edited to match it: Bob's balance drops, Sweety's rises. Nothing valuable travelled. Information did, and the ledgers did the rest. {{/think}}

So a payment isn't a parcel of cash. It's an instruction to move value from one account to another, that everyone involved agrees to honour. Strip it right down and there are always three things in it: who pays whom, how much (and in what currency), and a record that it happened so nobody can deny it or do it twice. Notice what's missing from that list. The actual cash.

{{aside:model|The mental model}} Same spine as before, one layer up:

A payment is an agreed edit to two ledger lines. The instruction says what to change. The money is just the numbers the instruction tells everyone to change.

Hold that. The rest of this article is about a gap hiding inside it. {{/aside}}

The one distinction that untangles everything

{{think}} Your message flies from Dubai to Bangalore in about a second. The instant it lands on Sweety's bank's desk, does she actually have the money? Is it hers, for good, right then? {{reveal}} No. Not yet. All that arrived was the ask. Sweety's bank now knows it's owed $400 on her behalf, but the two banks still have to actually square up between themselves, and that can happen hours later.

So there are two different things here, and they happen at two different moments:

Almost every muddle people have about payments comes from quietly assuming the message is the money. It isn't. The message only asks. The settlement does. {{/think}}

Sweety often sees the money before any of that settling finishes, because her bank will front it to her on the strength of the promise. That's a choice her bank makes, not proof the money has landed.

Push and pull: who moves first

Payments come in two directions, sorted by who kicks them off.

Same plumbing underneath, opposite first move. Knowing which one you're looking at tells you who's on the hook for getting the details right.

{{aside:chair|From the engineer's chair}} This message-vs-money split isn't a metaphor. It's written into the standard. When you open a pacs.008 later, the parties and amount are the instruction, but you'll also find IntrBkSttlmDt (settlement date) and IntrBkSttlmAmt (settlement amount) sitting in there as separate fields. The message is telling you two things at once: here's what I'm asking, and here's when and how much the actual money event will be. {{/aside}}

{{aside:breaks|Where it breaks}} Treat the message as the money and you get some of the nastiest bugs in payments. A confirmation screen says "sent," so a system assumes the funds are final and ships the goods, before settlement has actually happened. Or a message gets retried after a timeout, and because nobody kept a record that it already ran, the same instruction edits the ledgers twice and moves real value it shouldn't have. This is exactly why every instruction carries a unique reference, and why "did it settle?" is a different question from "did it send?" {{/aside}}

{{aside:map|The map}} A payment is an instruction with a gap inside it — said now, done later. The next articles live in that gap:

{{/aside}}

{{aside:ref|Reference card}}

{{/aside}}

So what can you do now?

You can explain a payment without ever saying the word cash. It's an agreed instruction that edits two ledgers, and the message and the money are on purpose two separate events. Keep hold of that gap between "said" and "done," because the next two articles — the lifecycle and clearing vs. settlement — are entirely about what lives inside it.

What is a payment, stripped to its essence? An agreed change to two ledger balances

Why isn't the message the same as the money? The message only asks; the money moves later, when settlement actually happens

Part of ISO 20022 Academy — lessons, a message playground, quizzes, and a glossary for the language of modern payments. Written by Revanth Sai Rayapati.