ISO 20022 Payments Explained: pain.001 and pain.002

ISO 20022 is the global standard for financial messaging, built on structured XML — and for corporate payments its key messages are pain.001, the payment instruction you send to the bank, and pain.002, the status report the bank sends back. Statements come in the related camt family. ISO 20022 is replacing the patchwork of legacy and proprietary formats across the industry, and its structured data is what makes better straight-through processing and reconciliation possible, provided you handle the bank-specific variations.

What ISO 20022 is

ISO 20022 is not a single message; it's a standard: a common, structured XML language for financial messages across payments, cash management, securities and more. Its value over older formats is structure: information sits in defined fields rather than free text, so it's richer, cleaner and easier for systems to process automatically. That's why cross-border payments have moved to it and many market infrastructures are still migrating.

The messages are organized into families. The two a corporate treasury deals with most:

• pain: Payments Initiation (customer-to-bank): instructing and tracking payments.
• camt: Cash Management: statements and reports (covered in statement formats, field by field in the camt.053 walkthrough).

(You'll also hear pacs, the bank-to-bank clearing messages — the successors of MT103 and MT202 — but those are between banks, not something a corporate sends.)

The message catalogue

The number tells you which message; the family prefix tells you who is talking to whom. Here are the ones a treasury actually meets, what each carries, and where this site opens it up:

Three things worth reading off it. First, the interbank rows are not yours to send. Once your bank accepts the pain.001, it is the bank that puts a pacs.008 into the clearing, and the pacs.002 that comes back goes to an institution, not to you; what reaches you is the pain.002. That distinction settles a lot of arguments about which message "the payment" is.

Second, the corporate side is two loops, not one. Instruction out and status back (pain.001, pain.002) tells you what the bank did with your file. The camt messages tell you what the account did: camt.052 during the day, camt.053 at the end of it, camt.054 when something specific happened or a batch needs itemising. A treasury that consumes only camt.053 has an end-of-day picture and no intraday one, which is a choice — just make it deliberately.

Third, the cancellation pair is interbank, and that is the whole story of recalls. A corporate asks its bank to attempt one; the bank raises the camt.056 and the camt.029 comes back to the bank. Whether you can trigger that from your treasury system, and how the answer reaches you, is a per-bank arrangement rather than something the standard settles for you.

One thing the table deliberately does not carry is version numbers. Every message here exists in several versions, and the version lives in the XML namespace rather than in the message code — "we're on camt.053" says nothing until someone names the version and the bank's implementation guide alongside it.

The payment messages

• pain.001 (CustomerCreditTransferInitiation). The payment instruction a corporate sends to its bank: pay these beneficiaries, these amounts, from these accounts, on these dates. This is the file your treasury system or payment factory generates to make payments — its structure and fields in detail here.
• pain.002 (CustomerPaymentStatusReport). The bank's reply: the status of the instruction and its payments — accepted, rejected (with reasons), pending — its status and reject codes decoded here. It's what lets you track a payment rather than fire and forget.
• pain.008 (CustomerDirectDebitInitiation). The direct-debit equivalent of pain.001, where you're collecting rather than paying — mandates, sequence types and refund rules included.

Together, pain.001 out and pain.002 back give you a controlled, trackable payment flow: the backbone of a modern payment factory.

Why the migration matters

The formats treasury relies on are moving to ISO 20022. SWIFT's cross-border payment instructions left legacy MT for ISO 20022 (MX) when the coexistence period ended on 22 November 2025, many market infrastructures are still migrating, and instant-payment schemes are ISO 20022 native. For treasury that means two things: your systems and bank interfaces need to send pain.001 and consume camt correctly, and you gain richer data (better structured references and remittance information), which improves straight-through processing and reconciliation. The upside is real; it just has to be implemented per bank.

What usually goes wrong

• Assuming ISO 20022 means identical. Banks implement the standard with variations: different mandatory fields, different handling of optional ones. A pain.001 that one bank accepts may be rejected by another until mapped to its rules. "We support ISO 20022" is a starting point, not a guarantee of interoperability.
• Ignoring pain.002. Sending payments (pain.001) without consuming the status report (pain.002), so you don't actually know what happened to them until something breaks.
• Underestimating mapping and testing. Treating format adoption as a switch rather than a per-bank mapping-and-testing exercise, exactly where connectivity projects run long.
• Losing the richer data. Adopting the XML format but still cramming references into free-text, throwing away the structure that was the whole point.

Get the payment messages right — pain.001 out, pain.002 back, mapped and tested per bank — and you have a controlled, trackable, reconcilable payment flow. Half-adopt it and you get XML with none of the benefit. That single, instrumented path out to the banks is also the easiest place to see what a control layer is: one choke point every irreversible action has to pass through, whoever — or whatever — initiated it.

See also bank statement formats and bank connectivity channels.