ISO 20022 Payments Explained: pain.001, pain.002 and the camt Family

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 market infrastructures and cross-border payments are migrating to it.

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).

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

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.
• pain.002 — CustomerPaymentStatusReport. The bank's reply: the status of the instruction and its payments — accepted, rejected (with reasons), pending. 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.

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 payments and many market infrastructures are migrating from legacy MT messages to ISO 20022 (MX), 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.

Part of the Treasury Systems Architecture guide. See also bank statement formats and bank connectivity channels. The newsletter sends one finance-systems pattern every two weeks.