Which ISO 20022 messages does a corporate treasury use?

Mostly two families. From the pain family, which the corporate sends to its bank: pain.001 for credit transfers, pain.008 for direct debits, and pain.002 coming back with the status of both. From the camt family, which the bank sends to the corporate: camt.052 intraday account reports, camt.053 end-of-day statements, camt.054 debit and credit notifications, and camt.086 for bank fee billing. The pacs messages such as pacs.008 and pacs.002 travel between banks and are not something a corporate normally sends or receives.

What is the difference between pain, camt and pacs messages?

The family prefix says who is talking to whom. pain, Payments Initiation, is customer to bank: the payment and direct-debit instructions and their status reports. camt, Cash Management, carries statements, reports, notifications and bank fee billing, plus some investigation messages. pacs, Payments Clearing and Settlement, is bank to bank: the credit transfer between the institutions that settle it and its status. A corporate lives in pain and camt; pacs is what its bank does with the instruction.

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.

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.

ISO 20022 for Corporates: pain, camt and pacs Messages

ISO 20022 is the global XML standard for financial messaging, and for a corporate treasury it comes down to about a dozen messages in three families: pain, the instructions you send your bank; camt, the statements, reports and bills your bank sends you; and pacs, the messages banks exchange with each other. This page is the catalogue: what each message is for, who sends it, and which guide on this site opens it field by field. For the file structures themselves, go straight to pain.001, pain.002, pain.008, camt.052, camt.053 or camt.054. ISO 20022 is replacing the patchwork of legacy and proprietary formats, and its structured data is what makes better straight-through processing and reconciliation possible, provided you handle the bank-specific variations.

pain goes from you to your bank, camt comes back, and pacs travels between banks — a corporate never sends one. More drawings

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:

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
`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
`pain.008` CustomerDirectDebitInitiation	Corporate → bank	Direct-debit collections: mandate details, sequence types, collection dates	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
`camt.053` BankToCustomerStatement	Bank → corporate	The end-of-day statement: typed balances and the entries booked in the period	camt.053 field by field
`camt.054` BankToCustomerDebitCreditNotification	Bank → corporate	Event-driven debit and credit notifications, and the itemised breakdown of a batch booking	camt.054 notification explained
`camt.086` BankServicesBillingStatement	Bank → corporate	The periodic bank fee statement: every chargeable service with volume, price, settlement and tax	bank fee analysis
`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. A corporate asks its bank to attempt a recall; the bank raises the camt.056 and the camt.029 comes back to the bank. ISO 20022 does define a customer-to-bank request for this, camt.055 CustomerPaymentCancellationRequest, but whether your bank accepts it, 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.

How the pieces fit in a payment flow

Read as a flow rather than a list, the corporate side is short:

Your treasury system or payment factory generates a pain.001 (or a pain.008 to collect). What goes where in the file, and where bank guides narrow the schema, is in the pain.001 structure guide.
The bank answers with one or more pain.002 status reports: accepted, rejected with a reason code, or pending. Decoding those codes is its own reference, and every reason code ISO defines is in the full list.
The bank executes through the interbank rails in pacs; you don't see those messages.
The account side comes back in camt: intraday in camt.052, end of day in camt.053, event by event or itemised in camt.054, and once a month the fee bill in camt.086.

Each step has its own guide because each has its own failure modes. This page stays the map.

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.

pain.001 and pain.002 pitfalls across banks

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.