ISO 20022 Implementation: Some Lessons from the Cross-Border Payments Migration

As the financial industry continues its transformative journey towards ISO 20022 adoption, we find ourselves at a critical juncture. While significant progress has been made, the road ahead remains long and complex. With the coexistence period between MT formats and ISO 20022 extending until November 2025 in correspondent banking, and multiple markets preparing for migration (including the UK, Asia, and the US), it's crucial to reflect on the early lessons learned and how they can guide us in optimizing cross-border payments.

Looking to understand ISO20022 ? check this here: https://topmate.io/learn/1210340

Key Learning #1: MT Practices Are Not Compatible with ISO 20022

The CBPR+ ISO 20022 standard used in correspondent banking isn't simply a new format - it represents a fundamental shift in how payment information is structured and validated. Two critical areas highlight this disparity:

1. BIC Element Differentiation

Unlike the MT standard, CBPR+ ISO 20022 introduces a crucial distinction between two types of Bank Identifier Code (BIC) elements:

• BICFI: Reserved exclusively for financial institution (FI) BICs, used to identify agents such as debtor agents, creditor agents, and previous instructing agents.
• AnyBIC: Accommodates all BIC types, including both FI and non-FI (e.g., CORP for Corporate), primarily used for party identification.

Implementation Challenge

This differentiation creates potential issues for transactions:

• Originated in MT format (which lacks this distinction)
• Processed through Market Infrastructures (MIs) that don't apply the same validation level

For example, if an agent in the payment chain is identified using a BICFI element but includes a non-FI BIC (like CORP), the transaction will be rejected - even if it successfully passed MI validation.

2. Agent Identification Requirements

While BIC remains the preferred method for agent identification, ISO 20022 allows alternatives such as name and address. However, CBPR+ ISO 20022 enforces stricter rules:

• Name and postal address must always be provided together for agents in cross-border payments
• Providing only one element (name without address or address without name) is not permitted

This creates challenges when:

• Translating originating MT messages that only include an agent's name
• Forwarding messages from MIs with less stringent validation requirements

Key Learning #2: Clarifying pacs.002 Status Message Usage

The introduction of CBPR+ pacs.002 status messages has created some confusion in the market. These messages come in two varieties:

1. Negative Confirmations

• Mandatory when rejecting a previously received payment
• Contains RJCT ("rejected") as transaction status
• Includes a reason code explaining the rejection

2. Positive Confirmations

• Optional and should only be sent when bilaterally agreed upon
• Can contain various status codes (e.g., ACSC for AcceptedSettlementCompleted)
• Cannot use RJCT status code

Implementation Challenge

Some market participants have misinterpreted the optionality of positive pacs.002 messages, sending them after every payment without establishing bilateral agreements. This practice can create significant operational overhead, as the industry generally designs processes to handle negative pacs.002 messages (which trigger exceptions and investigations requiring user intervention).

Best Practices Moving Forward

1. Thorough Validation: Implement comprehensive validation checks that account for ISO 20022's stricter requirements, particularly regarding BIC usage and agent identification.
2. Clear Communication: Establish explicit bilateral agreements regarding the use of positive pacs.002 messages to prevent unnecessary operational burden.
3. Robust Testing: Conduct extensive testing scenarios that account for the differences between MT and ISO 20022 formats, especially when payments cross different market infrastructures.

Key Learning #3: Understanding MX Naming Conventions

Another critical aspect of ISO 20022 implementation is adhering to the strict naming conventions for MX messages. These conventions ensure consistency and clarity across the ISO 20022 database:

Generic Naming Rules

1. Upper CamelCase Convention Each word begins with a capital letter No spaces between words Example: PaymentInstruction, CreditTransfer
2. Character Requirements Names must start with an alphabetic character Subsequent characters can be letters or numbers Example: Pacs008Message, Pain001Request
3. Language and Composition British English vocabulary is used consistently Names can comprise multiple words All characters must be alphanumeric

Importance of Naming Conventions

Adhering to these naming conventions is crucial for:

• Ensuring interoperability between systems
• Facilitating clear communication among financial institutions
• Enabling efficient automated processing of messages

Conclusion

The migration to ISO 20022 represents more than just a technical upgrade - it's a fundamental shift in how payment information is structured, validated, and processed. By learning from these early implementation challenges, the financial industry can work together to ensure a smoother transition and ultimately realize the full potential of enhanced cross-border payments.

Thank you for reading.

Santosh Kumar, GFIN

Want to level up your learnings? Many have leveraged the benefits of:

ISO20022 ebook: https://topmate.io/learn/1210340

Cross border payments course: https://www.udemy.com/course/a-beginners-guide-to-cross-border-payments/?couponCode=4B594CFBA2CA62577BA9

Source: DB.com and JP Morgan