The ISO 20022 standard defines a family of XML messages for payments. The most common ones — pain.001, pain.002 and pain.008 — each play a specific role in the payment chain. This article explains their differences, use cases and how they work together.
Overview of ISO 20022 messages
ISO 20022 is an international financial messaging standard that is progressively replacing proprietary formats and SWIFT MT messages. It covers the entire payment lifecycle: initiation, clearing, settlement and reporting.
Messages are organised into domains. The "pain" (Payment Initiation) domain handles communication between a business and its bank. The main messages are:
• pain.001: credit transfer initiation (Customer Credit Transfer Initiation)
• pain.002: payment status report (Customer Payment Status Report)
• pain.008: direct debit initiation (Customer Direct Debit Initiation)
Other domains include "pacs" for interbank clearing, "camt" for account statements, and "acmt" for account management.
Messages are organised into domains. The "pain" (Payment Initiation) domain handles communication between a business and its bank. The main messages are:
• pain.001: credit transfer initiation (Customer Credit Transfer Initiation)
• pain.002: payment status report (Customer Payment Status Report)
• pain.008: direct debit initiation (Customer Direct Debit Initiation)
Other domains include "pacs" for interbank clearing, "camt" for account statements, and "acmt" for account management.
pain.001: credit transfer initiation
The pain.001 message (CustomerCreditTransferInitiation) is sent by the business to its bank to order one or more credit transfers. It is the starting point for every SEPA or international wire.
The file contains the originator's details (name, IBAN, BIC), the requested execution date and the details of each transaction: beneficiary, amount, currency and reference. A single file can batch hundreds of transfers.
pain.001 is used for SEPA euro transfers as well as international multi-currency wires since the SWIFT ISO 20022 migration. The SEPA transfer generator produces compliant pain.001 files you can submit directly to your bank.
The file contains the originator's details (name, IBAN, BIC), the requested execution date and the details of each transaction: beneficiary, amount, currency and reference. A single file can batch hundreds of transfers.
pain.001 is used for SEPA euro transfers as well as international multi-currency wires since the SWIFT ISO 20022 migration. The SEPA transfer generator produces compliant pain.001 files you can submit directly to your bank.
pain.002: the status report
The pain.002 message (CustomerPaymentStatusReport) is the bank's response to a pain.001 or pain.008. It tells the business whether its payment batch was accepted, partially accepted or rejected.
For each transaction, pain.002 can indicate:
• ACCP (Accepted): the transaction is accepted and will be executed.
• RJCT (Rejected): the transaction is rejected, with a reason code (e.g. AC01 for incorrect IBAN, AM04 for insufficient funds, FF01 for invalid format).
• PDNG (Pending): the transaction is awaiting processing.
pain.002 is not generated by the business but by the bank. Processing it is essential to identify rejections and correct them promptly. The standardised error codes enable automated monitoring.
For each transaction, pain.002 can indicate:
• ACCP (Accepted): the transaction is accepted and will be executed.
• RJCT (Rejected): the transaction is rejected, with a reason code (e.g. AC01 for incorrect IBAN, AM04 for insufficient funds, FF01 for invalid format).
• PDNG (Pending): the transaction is awaiting processing.
pain.002 is not generated by the business but by the bank. Processing it is essential to identify rejections and correct them promptly. The standardised error codes enable automated monitoring.
pain.008: direct debit initiation
The pain.008 message (CustomerDirectDebitInitiation) is sent by the creditor to its bank to initiate collections from debtor accounts. It is the counterpart of pain.001 for incoming payment flows.
Each direct debit requires:
• A signed mandate identified by a UMR (Unique Mandate Reference) and a signature date.
• The creditor's SCI/ICS (SEPA Creditor Identifier).
• A sequence type: FRST (first collection), RCUR (recurring), OOFF (one-off) or FNAL (final).
pain.008 is used for subscriptions, recurring invoices and any automated collection. The SEPA direct debit generator lets you create these files with full mandate management.
Each direct debit requires:
• A signed mandate identified by a UMR (Unique Mandate Reference) and a signature date.
• The creditor's SCI/ICS (SEPA Creditor Identifier).
• A sequence type: FRST (first collection), RCUR (recurring), OOFF (one-off) or FNAL (final).
pain.008 is used for subscriptions, recurring invoices and any automated collection. The SEPA direct debit generator lets you create these files with full mandate management.
Comparison table
| Feature | pain.001 | pain.002 | pain.008 |
|---|---|---|---|
| Direction | Business → Bank | Bank → Business | Business → Bank |
| Function | Initiate transfers | Report status | Initiate collections |
| Who generates it? | The business | The bank | The business |
| Mandate required | No | No | Yes (UMR + SCI) |
| Currencies | EUR + multi-currency | N/A | EUR |
How these messages work together
The typical flow for a SEPA credit transfer follows this sequence:
1. The business generates a pain.001 file containing its transfer orders and submits it to its bank (via upload or banking channel).
2. The bank processes the file and returns a pain.002 with the status of each transaction: accepted, rejected or pending.
3. For direct debits, the creditor sends a pain.008 to its bank, which forwards it to the clearing system. The debtor's bank may then return a pain.002 in case of rejection.
Understanding this cycle helps automate return handling and reduce reconciliation delays. The ISO 20022 validator helps you verify your pain.001 and pain.008 files before submission, reducing the number of rejections reported in pain.002 responses.
1. The business generates a pain.001 file containing its transfer orders and submits it to its bank (via upload or banking channel).
2. The bank processes the file and returns a pain.002 with the status of each transaction: accepted, rejected or pending.
3. For direct debits, the creditor sends a pain.008 to its bank, which forwards it to the clearing system. The debtor's bank may then return a pain.002 in case of rejection.
Understanding this cycle helps automate return handling and reduce reconciliation delays. The ISO 20022 validator helps you verify your pain.001 and pain.008 files before submission, reducing the number of rejections reported in pain.002 responses.