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

Source: https://gravam.com/blog/iso-20022-payments-pain-001-pain-002
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: ISO 20022 is the global XML standard for financial messaging. For payments, pain.001 is the instruction you send and pain.002 the status back. What they are.

**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](https://gravam.com/blog/iso-20022-migration-mt-to-mx) 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](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), field by field in the [camt.053 walkthrough](https://gravam.com/blog/camt-053-structure-and-fields)).

(You'll also hear **pacs**, the bank-to-bank clearing messages — [the successors of MT103 and MT202](https://gravam.com/blog/mt101-vs-mt103-vs-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:

| Message | Direction | What it carries | Guide on this site |
| --- | --- | --- | --- |
| `pain.001` CustomerCreditTransferInitiation | Corporate → bank | Credit-transfer instructions: debtor account, beneficiaries, amounts, requested execution dates | [pain.001 structure and fields](https://gravam.com/blog/pain-001-structure-and-fields) |
| `pain.002` CustomerPaymentStatusReport | Bank → corporate | The status of a pain.001 or pain.008 the bank received — accepted, rejected with reason codes, pending | [pain.002 status and reject codes](https://gravam.com/blog/pain-002-status-and-reject-codes) |
| `pain.008` CustomerDirectDebitInitiation | Corporate → bank | Direct-debit collections: mandate details, sequence types, collection dates | [pain.008 direct debit initiation](https://gravam.com/blog/pain-008-direct-debit-initiation) |
| `camt.052` BankToCustomerAccountReport | Bank → corporate | The intraday account report — movements so far today, ahead of the closing statement | [camt.052 vs MT942, field by field](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) |
| `camt.053` BankToCustomerStatement | Bank → corporate | The end-of-day statement: typed balances and the entries booked in the period | [camt.053 field by field](https://gravam.com/blog/camt-053-structure-and-fields) |
| `camt.054` BankToCustomerDebitCreditNotification | Bank → corporate | Event-driven debit and credit notifications, and the itemised breakdown of a batch booking | [camt.054 notification explained](https://gravam.com/blog/camt-054-notification-explained) |
| `pacs.008` FIToFICustomerCreditTransfer | Interbank | The credit transfer itself, moving between the banks that settle it |  |
| `pacs.002` FIToFIPaymentStatusReport | Interbank | The status of a pacs payment message, back to the institution that sent it |  |
| `camt.056` FIToFIPaymentCancellationRequest | Interbank | A request to revoke a payment order not yet settled, or recall one already settled |  |
| `camt.029` ResolutionOfInvestigation | Interbank | The answer to a camt.056 — whether the revocation or recall succeeded |  |

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](https://gravam.com/blog/pain-001-structure-and-fields).
- **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](https://gravam.com/blog/pain-002-status-and-reject-codes). It's what lets you _track_ a payment rather than fire and forget.
- **[pain.008](https://gravam.com/blog/pain-008-direct-debit-initiation) (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](https://gravam.com/blog/what-is-a-payment-factory).

## Why the migration matters

The formats treasury relies on are moving to ISO 20022. [SWIFT's cross-border payment instructions](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments) left legacy MT for ISO 20022 (MX) when [the coexistence period ended on 22 November 2025](https://gravam.com/blog/iso-20022-migration-mt-to-mx), 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](https://gravam.com/blog/ebics-european-bank-connectivity) 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.

> Treat ISO 20022 adoption like any bank interface: map and test pain.001 (and pain.002) per bank against real scenarios, and make sure you're using the structured fields, not recreating MT-era free-text habits inside XML. The standard gives you the capability; your implementation decides whether you get the benefit.

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](https://gravam.com/blog/the-enterprise-ai-control-layer) is: one choke point every irreversible action has to pass through, whoever — or whatever — initiated it.

***

_See also [bank statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) and [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics)._

## Primary sources

ISO 20022 message definitions and versions evolve; the catalogue table names messages and roles but pins no versions — confirm the versions and profiles your banks require against the ISO 20022 catalogue and each bank's implementation guide.

- ISO 20022 — Message definitions catalogue — accessed 2026-07-28 — https://www.iso20022.org/iso-20022-message-definitions
- SWIFT — ISO 20022 for financial institutions — accessed 2026-07-28 — https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions
- SIX — Swiss Payment Standards, Implementation Guidelines for Credit Transfer (pain.001, with the pain.002 and pain.008 message flow) — accessed 2026-09-02 — https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2026-en.pdf
- SIX — Swiss Payment Standards, Implementation Guidelines for Customer-Bank Messages (Reports): camt.052, camt.053, camt.054 — accessed 2026-09-02 — https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-cash-management-sps-2026-en.pdf
- ECB — TARGET RTGS User Detailed Functional Specifications (scope of pacs.008, pacs.002, camt.056, camt.029) — accessed 2026-09-02 — https://www.ecb.europa.eu/paym/target/t2/prouse/shared/pdf/rtgs-udfs-r2026-JUN-revised.pdf
- ECB — TIPS User Detailed Functional Specifications (FIToFICustomerCreditTransfer and FIToFIPaymentStatusReport message names) — accessed 2026-09-02 — https://www.ecb.europa.eu/paym/target/target-professional-use-documents-links/tips/shared/pdf/TIPS_UDFS_v2.0.0_190614_rev.pdf

## Questions this article answers

**Q: What is pain.001 and pain.002?**

pain.001 and pain.002 are ISO 20022 payment messages. pain.001 is the CustomerCreditTransferInitiation, the structured XML payment instruction a corporate sends to its bank to make credit transfers. pain.002 is the CustomerPaymentStatusReport, the message the bank sends back reporting the status of that instruction (accepted, rejected, pending). Together they cover sending a payment and tracking what happened to it.

**Q: What is ISO 20022 in simple terms?**

ISO 20022 is a global standard for financial messages built on structured XML. Instead of many proprietary and legacy formats, it provides a common, richly structured language for payments (the pain and pacs families), cash management and statements (camt), and more. Its structured data carries more information more cleanly than older formats, which is why the industry is migrating to it.

**Q: Why is the ISO 20022 migration important for treasury?**

Because the formats treasury depends on (payment initiation and bank statements) are moving to ISO 20022, and the richer, structured data improves straight-through processing and reconciliation. SWIFT cross-border payment instructions left legacy MT for ISO 20022 when the coexistence period ended on 22 November 2025, and many market infrastructures are still migrating, so treasuries need their systems and bank interfaces to send pain.001 and consume camt correctly, allowing for bank-specific variations.