The field that says WHY money moved — the closest thing ISO 20022 has to a reason for existing. Get it right and reconciliation is automatic; get it wrong and a human types it in by hand.
Read in the interactive Academy →The problem first. A building-materials supplier in Chennai receives about 4,000 payments a month. Every one arrives as two things: money, and a mystery — which invoice is this for? In accounts-receivable, a person squints at a statement line reading
PAYMENT THX REF 88213/A INVand guesses. Guess wrong, and a customer who already paid gets a late-payment reminder and an angry phone call comes back.
The money arrived fine. The meaning didn't. And the field meant to carry that meaning — Remittance Information (RmtInf) — is the single best place to see what ISO 20022 was actually built to fix. Let's derive the fix before naming it.
{{think}} You're designing the payment format for that supplier's problem. The money always arrives; what fails is knowing which invoice it pays. Today the payer types free text and a human reads it.
What would you put in the message so the supplier's ERP matches the payment to the exact invoice with zero guessing — and, just as important, who along the bank chain should be allowed to change it? {{reveal}} Two moves:
Strd) carrying the creditor's own reference, the document number, its date, the amount applied. Now matching is a lookup, not a judgement call.Get those two and the receipt books itself. Miss them and it creates work. {{/think}}
Open a pacs.008 or pain.001 and RmtInf offers a choice: Ustrd (unstructured — a free-text line, the old MT field 70, everything from INVOICE 4471 to THX FOR LUNCH, which machines can't reliably parse, so humans do), or Strd (structured — the same facts in named elements). Inside Strd, the workhorses are CdtrRefInf (the creditor's reference, often an ISO 11649 code starting RF with a built-in check digit — the supplier prints it on the invoice, the payer sends it back unchanged, matching becomes a lookup) and RfrdDocInf + RfrdDocAmt (the referred document: "this pays invoice INV-2026-4471, dated 3 June, ₹8,40,000 applied, ₹16,800 discount"). One payment can list several documents — which is how a single transfer settles five invoices and short-pays a sixth with the reason attached. Free text collapses all that into PART PAYMENT VARIOUS; structure keeps it.
When people say ISO 20022 brings "rich, structured data," this field is what they mean. Matched automatically, a receipt costs effectively nothing and the invoice closes the moment the camt.054 lands; matched by hand, it costs minutes, arrives a day late, and occasionally lands on the wrong account and becomes a dispute. Multiply by 4,000 a month and the free-text blob isn't a formatting preference — it's headcount.
{{think}} A payment crosses one legacy hop that still thinks in MT and squeezes 9,000 characters of beautiful structure into 140. Or a converter quietly drops the Strd block instead of mapping it. The money settles perfectly either way.
So what was actually lost — and why is "but it settled" cold comfort? {{reveal}} The business meaning — which invoices the money pays. The ERP now receives INVOICE 4471 AND OTH… (the rest vanished), or nothing structured at all, so the credit drops into an unapplied-cash queue for a human to solve.
"It settled" only means the money arrived. Reconciliation is a different success: money that arrives without its paperwork is a mystery with a balance. The whole point of RmtInf is that the payment carries its own paperwork — abuse it and you've made the money arrive without it. {{/think}}
{{aside:model|The mental model}} The payment carries its own paperwork. Structured RmtInf (Strd) is machine-matchable — invoice closes itself; unstructured (Ustrd) is human work. And it's a passenger: no agent in the chain may alter it, so the payer's accounting data reaches the receiver's intact. {{/aside}}
{{aside:chair|From the engineer's chair}} Two elements do the heavy lifting: CdtrRefInf/Ref (an RF… ISO 11649 reference with a check digit — validate it) and RfrdDocInf/RfrdDocAmt (per-invoice detail, repeatable for multi-invoice payments). It's the single biggest lever on a corporate's auto-reconciliation rate (see the camt.053 chapter) — and the rulebooks oblige agents to pass it on unchanged, so never "normalise" it in a gateway. {{/aside}}
{{aside:breaks|Where it breaks}}
{{/aside}}
RF and drops a character; the check digit catches it only if someone validates. Free text validates nothing.Strd away rather than mapping it — settled, but meaning destroyed in transit.INV 4471 THX stuffed into a structured element: the XML validates, the problem survives.{{aside:map|The map}} The passenger and its vehicles:
{{/aside}}
{{aside:ref|Reference card}}
{{/aside}}
RmtInf = why the money moved. Ustrd (free text, human) vs Strd (structured, machine-matchable).Strd: CdtrRefInf (the RF… creditor reference) + RfrdDocInf/RfrdDocAmt (per-invoice, repeatable).Strd loses the meaning, not the money.See where RmtInf sits inside a live pacs.008 →
How the camt family delivers it to the receiver →
What does structured remittance information eliminate? Manual matching of payments to invoices
Who is allowed to alter RmtInf on its way through the chain? No one — agents must pass it on unchanged
A payment settles but its Strd block was dropped at a conversion hop. What was actually lost? The business meaning — which invoices the money pays