A payment isn't one event, it's a short relay with named legs. Learn them once and every stuck, failed, or missing payment suddenly has an address.
Read in the interactive Academy →Inside the pause. Bob taps "send," there's a pause, and then Sweety gets the money. That pause isn't dead time. A lot happens inside it. And if you can't name the steps in there, every slow or failed payment is going to feel like an unexplained black box.
From the outside a payment looks instant. Inside, it's a relay race with separate legs, each one handed to a different runner. Rather than hand you the list, let's have you build it, because once you've reasoned out the legs yourself, you can find any problem by asking one question.
{{think}} You're building the rail this payment runs on. Bob has just told his bank "pay Sweety $400." Between that tap and Sweety actually having the money, what steps do you have to run, and in what order?
Don't reach for jargon. Just think about what could go wrong if you skipped a step, and let that tell you the order. {{reveal}} Work backwards from the disasters and the order falls out:
Skip validation and you move money you shouldn't. Skip reconciliation and errors pile up silently. The order isn't arbitrary — each leg protects the ones after it. {{/think}}
That's the whole lifecycle. Almost every payment — simple or complex, domestic or cross-border — runs these five in the same order. Everything below is just a closer look at each leg, following Bob's $400.
The tap. Bob tells his bank, in effect, "pay Sweety $400." It might come from a person on a phone, a company's payroll file, a card terminal, or another bank passing along a payment it just received. Either way it's only a request. Nothing has moved, nothing's promised. Bob has just put a well-formed instruction in front of his bank.
Before acting, the bank runs down a checklist. Does Bob actually have the money? Is the instruction complete and well-formed, or is there a missing reference or a mangled account number? Is it allowed — sanctions, fraud, compliance? And is there even a route that reaches Sweety's bank?
This is where the biggest share of failures happen, and it's exactly where you want them. A payment killed here never moved any money, so there's nothing to unwind. That's also why the message standards later are so strict about field formats: most of validation is a machine checking, precisely, that the instruction says what it has to.
Validation passes, so the instruction is relayed toward Sweety's bank and the banks work out the obligation: Bob's bank now owes value to Sweety's bank. Clearing is the matching and agreeing, both sides confirming they see the same thing before any real money is committed. It is not the money moving — that's the next leg. (Clearing vs. settlement is entirely about this split.)
Settlement is when the agreed value actually changes hands between the banks. One account debited, another credited, and it's irreversible. Bob and Sweety never see it — it's the quiet back-office event where their two banks square up. Sweety may well have seen her money already; her bank often credits her on the strength of the agreement and settles behind the scenes afterward.
Finally, each side compares its own records against what actually settled. Did the money we expected arrive? Do our ledgers agree with theirs? It's the least glamorous leg and the one that keeps the whole system honest — it catches anything that drifted, duplicated, or went missing before it becomes tomorrow's mess.
{{aside:model|The mental model}} Here's why this list is worth burning into memory: failures have addresses. A payment doesn't just "fail" — it fails on a leg. Name the leg and you've already narrowed the cause to a handful of things. That single habit is most of what separates someone who debugs payments calmly from someone who guesses. {{/aside}}
{{think}} A payment's been stuck for twenty minutes. The customer's on the phone and annoyed. You've got the reference in front of you. Before you ask why it's stuck, what's the single fastest question to ask? {{reveal}} Which stage was it on when it stopped? Everything flows from the answer:
Ask which stage before why, and you've turned a black box into a map. {{/think}}
{{aside:chair|From the engineer's chair}} These legs are why there are different families of ISO 20022 messages. Initiation is a pain message (customer to bank). The clearing-and-settlement leg between banks is pacs. The status updates that tell the sender "accepted / rejected / pending" are pacs.002. Reconciliation and reporting are camt. When you meet the families later, you're not learning a new taxonomy — you're meeting the lifecycle you already know, one message per leg. {{/aside}}
{{aside:breaks|Where it breaks}} The tempting shortcut is to rush or thin out validation to make payments feel faster. It backfires. A bad payment caught at validation costs almost nothing — no money moved. The same bad payment caught after settlement costs a recall, a reconciliation break, a support case, and sometimes real lost funds. Failures get exponentially more expensive the further down the relay they're caught, which is exactly why the cheap, strict checks come first. {{/aside}}
{{aside:map|The map}} The lifecycle is the backbone the rest of the Library hangs stages off:
{{/aside}}
{{aside:ref|Reference card}}
{{/aside}}
Walk the full Bob → Sweety lifecycle, stage by stage →
You can take any payment — instant or slow, local or cross-border — and drop it onto a five-stage map: initiation, validation, clearing, settlement, reconciliation. And you can do the thing experienced people do without noticing: when something breaks, ask which stage? before why? That instinct is what the rest of this academy sharpens.
Which order matches a payment's life? Initiation, then interbank clearing and settlement, then reconciliation
Why do banks send status updates along the way? So the sender knows whether the instruction was accepted, rejected, or still pending