Introduction to ISO 20022

In this article, I’d like to explain what ISO 20022 is and how it is used in our daily processes in the payment ecosystem.

What is ISO 20022?

ISO 20022 is an international standard for electronic data interchange between financial institutions, particularly for messaging in financial transactions. It is designed to improve interoperability and efficiency in financial communications across borders and systems. In other words, ISO20022 is an open standard for financial messaging for payments and other financial transactions. Provides consistent, rich and structured data to be exchanged between financial institutions.

ISO 20022 is poised to become the global standard for financial messaging, driving efficiency, transparency, and interoperability in the financial ecosystem.

Overview

• Established by: The International Organization for Standardization (ISO).
• Purpose: To standardize financial messaging formats to enhance clarity, reduce complexity, and support global business communication in the financial industry.
• Primary Application: It is widely used in payments, securities, trade finance, and foreign exchange.

Why ISO 20022?

Different payment systems were using different formats, message types and standards. Interoperability was difficult and the payment landscape was disjointed. ISO20022 was introduced to bridge this gap.

1. Global Adoption:

• Financial institutions, central banks, and payment systems worldwide are adopting ISO 20022 to streamline international transactions.
• Major systems like SWIFT, SEPA (Single Euro Payments Area), and many real-time gross settlement (RTGS) systems are transitioning to ISO 20022.

2. Support for Modernization:

• The standard is pivotal in enabling faster and more transparent transactions, which aligns with trends like real-time payments and digital banking.

3. Enhanced Compliance:

• Facilitates compliance with regulatory requirements by providing more detailed transaction data, aiding in anti-money laundering (AML) and fraud prevention efforts.

Key Features of ISO 20022

1. Rich Data Structure:

• Allows the inclusion of more detailed and structured information in messages compared to older standards like SWIFT MT.
• Improves automation and reduces errors in processing.

2. XML-Based Standard:

• Messages are defined using XML (Extensible Markup Language), which ensures flexibility and adaptability to various use cases.

3. Interoperability:

• Provides a universal standard that promotes consistency and enables seamless communication between different financial institutions globally.

4. Modular Approach:

• Offers a flexible framework that can be adapted for various financial domains, including payments, securities, cards, trade services, and foreign exchange.

5. Improved processing time

6. Improved accuracy and efficient sanctions checking

7. Reduced costs with multiple formats and legacy

Implementation Timeline

• SWIFT’s Transition: SWIFT started migrating from MT (Message Type) to ISO 20022 in 2022 and aims to complete the transition for cross-border payments by 2025.
• Central Banks: Many central banks globally are also aligning their domestic payment systems with ISO 20022.

Challenges

1. Implementation Costs:

• Upgrading systems and processes to handle ISO 20022 can be costly for smaller institutions.

2. Interim Coexistence:

• During the transition period, systems need to support both ISO 20022 and legacy formats, which can be complex.

Business Domains

ISO20022 has defined messages for the below domains

• Payments
• Securities
• Trade
• Forex
• Cards

Parties

Parties involved in payments clearing and settlement.

Debtor​

Party that owes an amount of money to the (ultimate) creditor. The debtor is also the debit account owner and whose account is debited.

Creditor​

Party to which an amount of money is due. The party whose account is credited.

Ultimate Debtor

This is used when the debtor is different from the party who is the ultimate source of the payment. This is normally used when a subsidiary uses the account of head office to settle the payment.

Ultimate Creditor​

This is used when the creditor is different from the ultimate beneficiary of the payment. This is normally used when a subsidiary uses the account of head office to receive the payment.

Debtor Agent​

The bank/financial institution where debtor holds the account.

Creditor Agent​

The bank/financial institution where creditor holds the account.

Initiating Party​

Party that initiates the payment. This is the party that instantiates the payment data using say an ERP system. Example: The party who initiates the pain.001

Forwarding Party​

Financial institution that receives the instruction from the initiating party and forwards it to the next agent in the payment chain for execution. Forwarding agents are used at times where you have an integration with a bank(coordinator) but the actual debtor agent (or where you hold the account) is another bank.

Instructing Agent​

Agent that instructs the next party in the payment chain to carry out the payment/instruction.

Instructed Agent​

Agent that executes the instruction upon the request of the previous party in the chain (either an agreement party, or a clearing agent).

Intermediary Agents

Agent between the debtor’s agent and the creditor’s agent. There can be several intermediary agents specified for the execution of a payment.

Reimbursing Agents​

Reimbursement agents are used to refer to parties in the cover message. The reimbursement agents in pacs.008 will refer to the parties used in the pacs.009 cover messages.

Previous Instructing Agents​

Previous instructing agents in the payment chain.

Other Roles​

Some parties are referred by other names such as

• Account Owner​: Party that legally owns the account.
• Account Servicer​: Party that manages the account on behalf of the account owner, that manages the registration and booking of entries on the account, calculates balances on the account and provides information about the account.

Settlement Methods

Methods used to settle the credit transfer instruction.

INDA​

Instructed Agent will complete the settlement. The message is sent by the account owner and received by the account servicer. The account owner will instruct the account servicer to debit the nostro/current account in its books once the message is received before sending the payment further. Payment can be returned or rejected.

INGA​

Instructing Agent will complete the settlement. The message is sent by the account servicer and received by the account owner. The account servicer will credit the nostro/current account in its books before sending the payment further. Payment can only be returned.

COVE​

Settlement is don’t through a cover payment. pacs.008 will be settled through a pacs.009 cover payment.

CLRG​

Settlement is don’t through a payment clearing system/market infrastructure

MT and MX Equivalence Tables

The conversion from MT (Message Type) to MX (Message Exchange) under ISO 20022 is a crucial part of the migration to modernized financial messaging. The MT format (used in SWIFT messages) is gradually being replaced by the richer MX format, which adheres to ISO 20022 standards.

This mapping ensures a smoother transition from legacy MT messages to the richer, more structured ISO 20022 MX format.

Category 1: Customer Payments and Cheques

Category 2: Financial Institution Transfers

Category 9: Cash Management and Customer Status

Key Points About the Conversion

1. Richer Data in MX:

• MX messages (ISO 20022) provide more structured and detailed information compared to MT messages, enabling better compliance and automation.

2. Message Granularity:

• The MX format is more modular, often requiring multiple MX messages to achieve the same functionality as a single MT message.

3. XML-Based Structure:

• MX messages use XML for their structure, which makes them more flexible and machine-readable.

4. One-to-Many Relationship:

• In some cases, one MT message type maps to multiple MX messages. For example, MT103 might correspond to PACS.008 and parts of CAMT messages, depending on the details.

Benefits of Migrating to MX

• Better Regulatory Compliance: MX messages include rich, structured data to meet modern regulatory requirements (e.g., AML, KYC). MX messages provide richer information, making it easier to comply with regulations like AML and FATF requirements. Example: Detailed originator and beneficiary information in PACS.008.
• Enhanced Efficiency and Automation: Automates processes by reducing manual intervention. The structured XML format of MX messages facilitates automation, reducing manual intervention and errors.
• Global Standardization/Interoperability: Simplifies international payments by aligning with a universal standard. ISO 20022 is designed as a global standard, making cross-border payments more seamless and efficient.

Migration Strategies

a. Coexistence Period

• SWIFT has implemented a coexistence period (2022–2025) where both MT and MX messages are supported.
• Institutions can gradually adopt MX while maintaining compatibility with MT.

b. Middleware Solutions

• Many banks use middleware or translation tools to convert between MT and MX formats. These tools ensure compatibility without overhauling legacy systems.

c. Data Enrichment

• Enrich MT messages with additional data to comply with ISO 20022 standards when mapping to MX messages.

d. Testing and Certification

• Conduct extensive testing of MX message workflows to ensure compatibility and compliance.

Tools for MT to MX Conversion

• SWIFT Translator: A tool provided by SWIFT to facilitate MT/MX mapping and conversion.
• Data Dictionaries: Detailed ISO 20022 documentation provides data dictionaries and schemas for mapping.
• Third-Party Vendors: Many financial software providers offer solutions for handling MT/MX coexistence and migration.

Practical Example: MT103 to PACS.008

Challenges in Conversion

1. Interim Coexistence:

• During the transition period, institutions may need to support both MT and MX messages, adding complexity.

2. Semantic Mapping:

• Some fields in MT messages do not have a direct equivalent in MX, requiring custom mappings or additional details.

3. Infrastructure Updates:

• Older systems need to be upgraded or replaced to handle the XML-based MX messages.

Detailed MT to MX Conversion Examples

MT103 to PACS.008 (Customer Credit Transfer)

Purpose: MT103 is used for single customer credit transfers, and PACS.008 is its ISO 20022 equivalent.

Field Mapping Example:

MT202 to PACS.009 (Financial Institution Transfer)

Purpose: MT202 is used for bank-to-bank transfers, and PACS.009 is its ISO 20022 equivalent.

Field Mapping Example:

Challenges in Conversion

a. Structural Differences

• MT messages are simpler, using fixed-length fields and tags, while MX messages are XML-based, with hierarchical and structured data.
• Example: MT103 has fixed fields like :20: or :50:, while PACS.008 uses <GrpHdr> and <CdtTrfTxInf> elements to hold similar data.

b. Richer Data in MX

• MX messages support more detailed information, such as:
• Exact remittance details.
• Extended regulatory and compliance data.
• Not all fields in MT messages have direct MX equivalents, requiring enrichment or custom mappings.

c. Coexistence of Standards

• Until the full migration is complete, banks and financial institutions need to handle both formats, requiring parallel systems and increased operational complexity.

d. Compatibility with Legacy Systems

• Many institutions have older infrastructure designed for MT messaging, which may not easily accommodate XML-based MX messages.

Reference Numbers

There are two types of reference numbers used in a payment transaction. There are multiple reference numbers involved in a single transaction.

Point to Point​ — Instruction Identification​

Definition: Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.

Usage: The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.

Point to Point​ — Message Identification​

Definition: Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message.

Usage: The instructing party has to make sure that MessageIdentification is unique per instructed party for a pre-agreed period.

End To End Identification​

Definition: Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.

Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction.

Transaction Identification​

Definition: Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain.

Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level.

UETR​

Definition: Universally unique identifier to provide an end-to-end reference of a payment transaction.

This is mainly used in SWIFT and can uniquely identify a transaction from any Bank within the SWIFT network. This uses UUID v4.

Clearing System Reference​

Definition: Unique reference, as assigned by a clearing system, to unambiguously identify the instruction.

Examples

Reference numbers assigned for some of the message flows are listed below:

Correspondents

Clearing System

Serial Flow

First pacs.008 ->​

Second pacs.008​

Message Details

Identification

The messages are identified using the format [4!a.3!c.3!n.2!n].

• The first set (4 alphabets) represent the business area
• The second set (3 characters) identifies the type of message
• The third set (3 numbers) represent the variant. A ‘variant’ is a restricted version of a message and may exclude portions of the message that are rarely used.
• The fourth set (2 numbers) represent the version of the message and the variant

ISO 20022 Message Identifier

Structure

The important part of the complete payload transferred is highlighted as a dashed line. This contains the application header information and the MX message. The application header follows the business application header format(“head” definition) while the message follows the individual message definitions such as pacs, pain, camt etc. The definitions including the header definition are available in the ISO 20022 message definitions set.

ISO 20022 Message Structure

Character Sets

• Data type text is restricted to — a-z A-Z 0–9 / — ? : ( ) . , ‘ + .
• Special characters are allowed in all party name and addressed, related remittance information, remittance information — ^^!#&%*=^_’{|}~”;@[]
• $ > < are allowed in email address elements

Messages

In the ISO 20022 standard, message structures are organized into distinct categories based on their use cases. Two of the most commonly referenced message structures are PAIN and PACS, which relate to payment transactions.

PAIN (Payment Initiation) Messages

• Used by corporates or customers to initiate payment instructions to their bank.
• Focused on communication between customers and their financial institutions.
• Name Origin: “PAIN” stands for Payments Initiation.

Key PAIN Message Types

1. PAIN.001: Customer Credit Transfer Initiation

• Used to request a bank to transfer funds to a beneficiary.
• Example: Corporate to Bank (C2B) payments.
• Rich in detail, supporting multiple instructions in a single message.
• Replaces paper-based or older electronic formats.

2. PAIN.002: Customer Payment Status Report

• Sent by the bank to provide the customer with the status of a payment instruction.
• Tracks the processing of payments initiated via PAIN.001.

3. PAIN.008: Customer Direct Debit Initiation

• Used to initiate direct debit transactions.
• Often used in recurring billing scenarios, like utilities or subscription services.

4. PAIN.007: Customer Payment Reversal

• Used to reverse a payment previously initiated via PAIN.001 or PAIN.008.

PACS (Payments Clearing and Settlement) Messages

Purpose:

• Used for interbank clearing and settlement of payments.
• Focused on communication between financial institutions.
• Name Origin: “PACS” stands for Payments Clearing and Settlement.

Key PACS Message Types

1. PACS.008: FI to FI Customer Credit Transfer

• Used for customer credit transfers between financial institutions.
• Commonly used in cross-border and domestic payment systems.
• Example: Bank A sends a payment on behalf of a customer to Bank B.

2. PACS.004: Payment Return

• Used to return a payment due to issues like account closure, incorrect details, or insufficient funds.

3. PACS.002: FI to FI Payment Status Report

• Provides status updates about interbank payments.
• Similar to PAIN.002 but focused on institutional rather than customer-facing payments.

4. PACS.009: Financial Institution Credit Transfer

• Handles credit transfers initiated by financial institutions themselves (e.g., treasury operations).

Relationship Between PAIN and PACS

1. PAIN → PACS Conversion:

• A corporate sends a PAIN.001 message to initiate a payment with their bank.
• The bank processes the message and converts it into a PACS.008 message for interbank settlement.

2. Lifecycle Coordination:

• For example, the customer initiates a payment (PAIN.001), and the status (PAIN.002) is relayed as the PACS message flows through the interbank system.

Key Benefits of PAIN and PACS

1. Rich Data Support:

• Both formats support detailed and structured information.
• This helps with compliance, transparency, and automation.

2. Seamless Integration:

• Aligns corporate and interbank systems for end-to-end transaction processing.

3. Interoperability:

• Standardized across multiple financial systems and institutions, facilitating global transactions.

By defining clear structures for customer and interbank messaging, PAIN and PACS streamline the end-to-end payment process under the ISO 20022 framework.

PAIN File

SEPA (Single Euro Payments Area) is a pan-European network that allows you to send and receive payments in euros (€) between two cross-border bank accounts in the eurozone.

Payment Initiation (PAIN) is an xml file format, which is used in the Corporate to Bank payment traffic.

PAIN.001

PAIN.001 is a payments initiation message by ISO 20022. It depicts a Credit Transfer message in an XML format.

PAIN.001 is a generic payment file based on the pain.001.001, both 03 and 09 are supported, format standard and is used by corporates to send SEPA credit transfers in a file to the bank.

It supports the following type of payments:

• Euro payments
• Urgent Domestic Euro payments
• Urgent Euro payments
• Cross border payments

Below you can find an example format of the Pain.001:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <CstmrCdtTrfInitn>
        <GrpHdr>
            <MsgId>MMMM20211231v1</MsgId>
            <CreDtTm>2013-07-18T10:00:00</CreDtTm>
            <NbOfTxs>2</NbOfTxs>
            <CtrlSum>0.03</CtrlSum>
            <InitgPty>
                <Nm>MIB</Nm>
            </InitgPty>
        </GrpHdr>
        <PmtInf>
            <PmtInfId>PmtInfId-MM20211231-1</PmtInfId>
            <PmtMtd>TRF</PmtMtd>
            <BtchBookg>false</BtchBookg>
            <PmtTpInf>
                <InstrPrty>NORM</InstrPrty>
                <SvcLvl>
                    <Cd>SEPA</Cd>
                </SvcLvl>
            </PmtTpInf>
            <ReqdExctnDt>2021-12-31</ReqdExctnDt>
            <Dbtr>
                <Nm>MïB</Nm>
                <PstlAdr>
                    <Ctry>NL</Ctry>
                    <AdrLine>Gräädt van Roggenweg 400</AdrLine>
                    <AdrLine>Utrecht</AdrLine>
                </PstlAdr>
            </Dbtr>
            <DbtrAcct>
                <Id>
                    <IBAN>NL86ING1999999991</IBAN>
                </Id>
                <Ccy>EUR</Ccy>
            </DbtrAcct>
            <DbtrAgt>
                <FinInstnId>
                    <BIC>INGNLBB</BIC>
                </FinInstnId>
            </DbtrAgt>
            <CdtTrfTxInf>
                <PmtId>
                    <InstrId>MIB InstrId305-312MM20211231v1</InstrId>
                    <EndToEndId>MIB E2E305-312MM20211231v1</EndToEndId>
                </PmtId>
                <PmtTpInf/>
                <Amt>
                    <InstdAmt Ccy="EUR">0.01</InstdAmt>
                </Amt>
                <CdtrAgt>
                    <FinInstnId>
                        <BIC>INGNLBB</BIC>
                    </FinInstnId>
                </CdtrAgt>
                <Cdtr>
                    <Nm>MIB 320</Nm>
                    <PstlAdr>
                        <Ctry>NL</Ctry>
                        <AdrLine>Graadt van Roggenweg 400</AdrLine>
                        <AdrLine>Amsterdam</AdrLine>
                    </PstlAdr>
                </Cdtr>
                <CdtrAcct>
                    <Id>
                        <IBAN>NL11INGB3444444443</IBAN>
                    </Id>
                    <Ccy>EUR</Ccy>
                </CdtrAcct>
                <RmtInf>
                    <Ustrd>MIB304-320MM20211231v1</Ustrd>
                </RmtInf>
            </CdtTrfTxInf>
        </PmtInf>
        <PmtInf>
            <PmtInfId>PmtInfId-MM20211231-2</PmtInfId>
            <PmtMtd>TRF</PmtMtd>
            <BtchBookg>false</BtchBookg>
            <PmtTpInf>
                <InstrPrty>NORM</InstrPrty>
                <SvcLvl>
                    <Cd>SEPA</Cd>
                </SvcLvl>
            </PmtTpInf>
            <ReqdExctnDt>2021-12-31</ReqdExctnDt>
            <Dbtr>
                <Nm>MIB</Nm>
                <PstlAdr>
                    <Ctry>NL</Ctry>
                    <AdrLine>Graadt van Roggenweg 400</AdrLine>
                    <AdrLine>Utrecht</AdrLine>
                </PstlAdr>
            </Dbtr>
            <DbtrAcct>
                <Id>
                    <IBAN>NL86RABO1999999991</IBAN>
                </Id>
                <Ccy>EUR</Ccy>
            </DbtrAcct>
            <DbtrAgt>
                <FinInstnId>
                    <BIC>INGNLBB</BIC>
                </FinInstnId>
            </DbtrAgt>
            <CdtTrfTxInf>
                <PmtId>
                    <InstrId>MIB InstrId305-312MM20211231v1</InstrId>
                    <EndToEndId>MIB E2E305-312MM20211231v1</EndToEndId>
                </PmtId>
                <PmtTpInf/>
                <Amt>
                    <InstdAmt Ccy="EUR">0.02</InstdAmt>
                </Amt>
                <CdtrAgt>
                    <FinInstnId>
                        <BIC>INGNLBB</BIC>
                    </FinInstnId>
                </CdtrAgt>
                <Cdtr>
                    <Nm>MIB 320</Nm>
                    <PstlAdr>
                        <Ctry>NL</Ctry>
                        <AdrLine>Graadt van Roggenweg 400</AdrLine>
                        <AdrLine>Utrecht</AdrLine>
                    </PstlAdr>
                </Cdtr>
                <CdtrAcct>
                    <Id>
                        <IBAN>NL11RABO3444444443</IBAN>
                    </Id>
                    <Ccy>EUR</Ccy>
                </CdtrAcct>
                <RmtInf>
                    <Ustrd>MIB305-320MM20211231</Ustrd>
                </RmtInf>
            </CdtTrfTxInf>
        </PmtInf>
    </CstmrCdtTrfInitn>
</Document>

PAIN.002

PAIN.002 or payment status message is a log file based on the pain.002.001.03 format, it contains the actual status of payments (example rejection, acceptance etc.) submitted by SEPA Credit Transfer (pain.001) or SEPA Direct Debit (pain.008).

• Interchange status/group status
• Batch status
• Transaction status on individual payments in the batch

Interchange status/group status

Batch status

Transaction status on individual payment in the batch

Below you can find an example format of the Pain.002:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
    <CstmrPmtStsRpt>
        <GrpHdr>
            <MsgId>INGB-PAIN002-PO-0000000001865281814</MsgId>
            <CreDtTm>2021-08-09T15:39:03.808</CreDtTm>
            <InitgPty>
                <Id>
                    <OrgId>
                        <BICOrBEI>INGBNLBE</BICOrBEI>
                    </OrgId>
                </Id>
            </InitgPty>
        </GrpHdr>
        <OrgnlGrpInfAndSts>
            <OrgnlMsgId>MMMM20211231v1</OrgnlMsgId>
            <OrgnlMsgNmId>PAIN.001.001.03</OrgnlMsgNmId>
            <OrgnlCreDtTm>2021-07-18T10:00:00.000</OrgnlCreDtTm>
            <OrgnlNbOfTxs>2</OrgnlNbOfTxs>
            <OrgnlCtrlSum>0.03</OrgnlCtrlSum>
            <GrpSts>ACTC</GrpSts>
        </OrgnlGrpInfAndSts>
        <OrgnlPmtInfAndSts>
            <OrgnlPmtInfId>PmtInfId-MM20211231-1</OrgnlPmtInfId>
            <OrgnlNbOfTxs>1</OrgnlNbOfTxs>
            <PmtInfSts>ACSC</PmtInfSts>
        </OrgnlPmtInfAndSts>
        <OrgnlPmtInfAndSts>
            <OrgnlPmtInfId>PmtInfId-MM20211231-2</OrgnlPmtInfId>
            <OrgnlNbOfTxs>null</OrgnlNbOfTxs>
            <PmtInfSts>RJCT</PmtInfSts>
        </OrgnlPmtInfAndSts>
    </CstmrPmtStsRpt>
</Document>

PAIN.008

Pain.008 file is a payments initiation message by ISO 20022. It depicts a Direct Debit message in XML format. A PAIN.008 file is used by corporates to send SEPA direct debits in a file to the bank.

Below you can find an example format of the Pain.008:

<?xml version="1.0" encoding="UTF-8" ?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.008.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <CstmrDrctDbtInitn>
        <GrpHdr>
            <MsgId>MMMM20211231v1</MsgId>
            <CreDtTm>2013-07-18T10:00:00</CreDtTm>
            <NbOfTxs>1</NbOfTxs>
            <CtrlSum>0.02</CtrlSum>
            <InitgPty>
                <Nm>MIB</Nm>
            </InitgPty>
        </GrpHdr>
        <PmtInf>
            <PmtInfId>PmtInfId-DD20211231-1</PmtInfId>
            <PmtMtd>DD</PmtMtd>
            <BtchBookg>true</BtchBookg>
            <NbOfTxs>1</NbOfTxs>
            <CtrlSum>0.02</CtrlSum>
            <PmtTpInf>
                <SvcLvl>
                    <Cd>SEPA</Cd>
                </SvcLvl>
                <LclInstrm>
                    <Cd>CORE</Cd>
                </LclInstrm>
                <SeqTp>FRST</SeqTp>
            </PmtTpInf>
            <ReqdColltnDt>2021-12-31</ReqdColltnDt>
            <Cdtr>
                <Nm>MïB</Nm>
                <PstlAdr>
                    <Ctry>NL</Ctry>
                    <AdrLine>Gräädt van Roggenweg 400</AdrLine>
                    <AdrLine>Utrecht</AdrLine>
                </PstlAdr>
            </Cdtr>
            <CdtrAcct>
                <Id>
                    <IBAN>NL86INGB1999999991</IBAN>
                </Id>
                <Ccy>EUR</Ccy>
            </CdtrAcct>
            <CdtrAgt>
                <FinInstnId>
                    <BIC>INGBNLBE</BIC>
                </FinInstnId>
            </CdtrAgt>
            <ChrgBr>SLEV</ChrgBr>
            <CdtrSchmeId>
                <Id>
                    <PrvtId>
                        <Othr>
                            <Id>NL33ZZZ300456820000</Id>
                            <SchmeNm>
                                <Prtry>SEPA</Prtry>
                            </SchmeNm>
                        </Othr>
                    </PrvtId>
                </Id>
            </CdtrSchmeId>
            <DrctDbtTxInf>
                <PmtId>
                    <EndToEndId>MIB E2E305-312DD20211231v1</EndToEndId>
                </PmtId>
                <InstdAmt Ccy="EUR">0.02</InstdAmt>
                <DrctDbtTx>
                    <MndtRltdInf>
                        <MndtId>00001</MndtId>
                        <DtOfSgntr>2021-07-30</DtOfSgntr>
                    </MndtRltdInf>
                </DrctDbtTx>
                <DbtrAgt>
                    <FinInstnId>
                        <BIC>INGBNLBE</BIC>
                    </FinInstnId>
                </DbtrAgt>
                <Dbtr>
                    <Nm>MIB 320</Nm>
                    <PstlAdr>
                        <Ctry>NL</Ctry>
                        <AdrLine>Graadt van Roggenweg 400</AdrLine>
                        <AdrLine>Utrecht</AdrLine>
                    </PstlAdr>
                </Dbtr>
                <DbtrAcct>
                    <Id>
                        <IBAN>NL11INGB3444444443</IBAN>
                    </Id>
                </DbtrAcct>
                <RmtInf>
                    <Ustrd>MIB304-320DD20211231v1</Ustrd>
                </RmtInf>
            </DrctDbtTxInf>
        </PmtInf>
    </CstmrDrctDbtInitn>
</Document>

Information about formats

Payment transactions need to be error-free and efficient. To achieve this, standards for communication between your organization and the bank have been established. Using standardized financial messages (file formats), you can send payment orders and receive account statements.

Payment orders (initiation)

• Pain.001.001.03
• Pain.001.001.09
• MT101

Direct Debit orders (Eurozone)

• Pain.008.001.08

Status information

• Pain.002.001.03 — positive
• Pain.002.001.03 — negative

Account statements (intraday)

• Camt.052.001.02
• MT942

Account statements (end of day)

• Camt.053.001.02
• MT940

PAIN.002 in Detail: PAIN.002 Status Reporting in ISO 20022

The PAIN.002 message, or Customer Payment Status Report, is part of the ISO 20022 standard used to communicate the processing status of payment instructions initiated by customers through a PAIN.001 (Credit Transfer Initiation) or PAIN.008 (Direct Debit Initiation). It allows banks to provide detailed updates about whether the payment was accepted, rejected, or pending.

Purpose of PAIN.002

1. Customer Communication:

• Sent from the bank to the customer to inform them about the current processing status of their initiated payment.

2. Transparency:

• Provides detailed reasons for any payment rejections or issues, enabling customers to take corrective actions.

3. Error Handling:

• Helps identify problems in payment instructions (e.g., missing information, invalid account numbers).

Key Scenarios for PAIN.002 Usage

1. Accepted Payment:

• Confirms that the payment instruction has been received and accepted by the bank.

2. Rejected Payment:

• Communicates reasons for rejecting a payment, such as incorrect beneficiary account details or insufficient funds.

3. Pending or Under Review:

• Informs the customer that the payment is being reviewed or is pending further action (e.g., manual approval or compliance checks).

4. Partial Acceptance:

• For batch payments, some transactions may be accepted, while others are rejected.

PAIN.002 Structure

A PAIN.002 message is composed of several main components. Below is an overview of its hierarchical structure:

1. Group Header (<GrpHdr>):

• Provides general information about the status message.

Example fields:

• <MsgId>: Unique identifier for the status report.
• <CreDtTm>: Creation date and time of the message.

2. Original Group Information and Status (<OrgnlGrpInfAndSts>):

• Relates to the original group of payments from the PAIN.001 or PAIN.008 message.

Example fields:

• <OrgnlMsgId>: Reference to the original message identifier.
• <GrpSts>: Status of the entire group (e.g., “RJCT” for rejected or “ACCP” for accepted).

3. Original Payment Information and Status (<OrgnlPmtInfAndSts>):

• Provides details about the original payment instructions and their status.

Example fields:

• <OrgnlPmtInfId>: ID of the original payment batch or instruction.
• <TxInfAndSts>: Status details for individual transactions within the group.

4. Transaction Information and Status (<TxInfAndSts>):

• Contains details about the status of individual transactions within the batch.

Example fields:

• <TxSts>: Transaction status (e.g., “ACSC” for settled, “RJCT” for rejected).
• <StsRsnInf>: Reason for the status, including reason codes.
• <OrgnlInstrId>: Reference to the original transaction ID.

Common Status Codes in PAIN.002

Example 1: Successful Payment

Here is an example of a PAIN.002 message confirming that a payment was successfully processed:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.09">
   <CstmrPmtStsRpt>
      <GrpHdr>
         <MsgId>20231225-12345</MsgId>
         <CreDtTm>2023-12-25T10:00:00</CreDtTm>
      </GrpHdr>
      <OrgnlGrpInfAndSts>
         <OrgnlMsgId>PAIN001-20231225-1</OrgnlMsgId>
         <GrpSts>ACSC</GrpSts>
      </OrgnlGrpInfAndSts>
      <OrgnlPmtInfAndSts>
         <OrgnlPmtInfId>PaymentBatch1</OrgnlPmtInfId>
         <TxInfAndSts>
            <OrgnlInstrId>Payment123</OrgnlInstrId>
            <TxSts>ACSC</TxSts>
         </TxInfAndSts>
      </OrgnlPmtInfAndSts>
   </CstmrPmtStsRpt>
</Document>

Example 2: Rejected Payment

Here is an example of a PAIN.002 message indicating a rejected payment due to insufficient funds:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.09">
   <CstmrPmtStsRpt>
      <GrpHdr>
         <MsgId>20231225-54321</MsgId>
         <CreDtTm>2023-12-25T12:00:00</CreDtTm>
      </GrpHdr>
      <OrgnlGrpInfAndSts>
         <OrgnlMsgId>PAIN001-20231225-1</OrgnlMsgId>
         <GrpSts>RJCT</GrpSts>
      </OrgnlGrpInfAndSts>
      <OrgnlPmtInfAndSts>
         <OrgnlPmtInfId>PaymentBatch1</OrgnlPmtInfId>
         <TxInfAndSts>
            <OrgnlInstrId>Payment123</OrgnlInstrId>
            <TxSts>RJCT</TxSts>
            <StsRsnInf>
               <Rsn>
                  <Cd>AM05</Cd> <!-- Reason Code -->
               </Rsn>
               <AddtlInf>Insufficient Funds</AddtlInf>
            </StsRsnInf>
         </TxInfAndSts>
      </OrgnlPmtInfAndSts>
   </CstmrPmtStsRpt>
</Document>

Common Reason Codes in PAIN.002

Benefits of PAIN.002

1. Improved Customer Experience:

• Timely updates help customers track their payments in real time.

2. Proactive Error Resolution:

• Detailed rejection reasons enable customers to fix issues quickly.

3. Regulatory Compliance:

• Provides detailed information required for audits and reporting.

Usage in Payment Workflows

1. Customer Initiates Payment:

• A customer sends a PAIN.001 message to their bank.

2. Bank Processes Payment:

• The bank processes the payment and generates a PAIN.002 message to inform the customer about the status.

3. Status Updates:

• Updates are sent for each transaction, ensuring the customer is fully informed.

PAIN.002 plays a vital role in ensuring transparency and efficiency in payment processing within the ISO 20022 framework.