Introduction to ISO 20022

 

Introduction to ISO 20022

ISO 20022 is an international standard for electronic data interchange between financial institutions. Unlike older, character-limited formats, it is based on XML, which allows for much richer, more structured, and higher-quality data to travel with payments. This is revolutionizing payments, cash management, and securities processing globally.

Key Concepts:

• Message Family: Messages are grouped into families identified by a four-letter code (e.g., pain, pacs, camt).

• Message Identifier: Each message has a unique code, such as pain.001.001.09.

  • pain: The business area (Payments Initiation).

  • 001: The message type (Customer Credit Transfer Initiation).

  • 001: The variant (not always used).

  • 09: The version number of the message.

A Note on "All Possible Transactions": The ISO 20022 catalog contains hundreds of messages covering payments, trade finance, securities, cards, and foreign exchange. The following focuses on the most critical and common messages used in the corporate-to-bank and interbank payments and cash management lifecycle.

Key Stakeholders (ISO 20022 Terminology)

Stakeholder	ISO 20022 Role	Description
Initiating Party	Debtor / Customer	The corporate client or individual starting the payment.
Debtor Agent	ODFI / Payer's Bank	The bank of the Initiating Party.
Creditor Agent	RDFI / Payee's Bank	The bank of the final recipient.
Creditor	Beneficiary / Receiver	The corporate client or individual receiving the funds.
Clearing System	ACH Operator / Market Infrastructure	The central system that clears and settles payments (e.g., The Fed, EBA CLEARING, SWIFT).

---

Common End-to-End Scenarios

Here are the flows for the most frequent banking operations using ISO 20022 messages.

Scenario 1: Standard Customer Credit Transfer (e.g., Paying a Supplier)

This is the equivalent of the EDI 820 payment flow.

Flow: pain.001 -> pain.002 -> pacs.008 -> camt.054 -> camt.053

1. Initiation (Corporate to Bank):

   • The Debtor (company) sends a  (Customer Credit Transfer Initiation) to its Debtor Agent (its bank). This single message can contain thousands of payments and rich remittance information (like invoice numbers, structured addresses, and ultimate party details).

2. Status Confirmation (Bank to Corporate):

   • The Debtor Agent receives the pain.001. It sends back a  (Customer Payment Status Report). This message confirms receipt and provides the status of the instruction:

     • ACCP: Accepted for processing.

     • RJCT: Rejected (with detailed reason codes).

     • PDNG: Pending.

3. Interbank Clearing (Bank to Bank):

   • The Debtor Agent sends a  (FI to FI Customer Credit Transfer) to the Creditor Agent (the supplier's bank) through a clearing system. This is the actual instruction to move the money between banks and contains the payment and remittance data.

4. Credit Notification (Bank to Corporate):

   • The Creditor Agent receives the funds and the pacs.008. It credits the Creditor's (supplier's) account and sends them a  (Bank to Customer Debit/Credit Notification). This is a real-time or intraday notification that a specific credit has been received.

5. End-of-Day Reporting (Bank to Corporate):

   • At the end of the day, both banks send their customers a  (Bank to Customer Statement). This is the full electronic bank statement, showing all of the day's transactions, including the payment sent (for the Debtor) and received (for the Creditor).

Scenario 2: Direct Debit Collection

Flow: pain.008 -> pacs.003 -> pacs.002 / pacs.004

1. Initiation (Corporate to Bank): A company (Creditor) with a mandate to collect funds sends a  (Customer Direct Debit Initiation) to its bank (Creditor Agent).

2. Interbank Clearing (Bank to Bank): The Creditor Agent sends a  (FI to FI Direct Debit) to the Debtor's Bank to request the funds.

3. Handling Returns/Rejects: If the direct debit fails (e.g., insufficient funds), the Debtor's Bank sends a  (FI to FI Payment Status Report) back to the Creditor's Bank to report the failure. Alternatively, if the payment is returned after settlement, it sends a  (Payment Return).

Scenario 3: Request for Payment (RfP)

This is a modern flow used in real-time payment systems.

Flow: pain.013 -> pain.014 -> pacs.008

1. Request (Payee to Payer): A Creditor (e.g., an e-commerce merchant) sends a  (Creditor Payment Activation Request) to the Debtor (customer), often via their respective banks or a mobile app. This is a request to be paid.

2. Response (Payer to Payee): The Debtor approves or rejects the request. Their bank sends a  (Creditor Payment Activation Request Status Report) back.

3. Payment: If approved, the Debtor's bank initiates a pacs.008 credit transfer to complete the payment.

Scenario 4: Exceptions and Investigations

ISO 20022 provides a robust framework for handling inquiries and resolving issues.

1. Query: A bank or corporate needs more information about a payment. They send a  (FI to FI Payment Cancellation Request) to request cancellation or a  (Request to Modify Payment).

2. Resolution: The receiving institution investigates and responds with a  (Resolution of Investigation), providing the outcome (e.g., payment was cancelled, modification was successful, or request was rejected).