ISO 20022 Migration Approaches and Strategies

June 2, 2022

Osama Jasser

Osama Jasser

ISO 20022 Migration Approaches and Strategies

ISO 20022 has been the emerging messaging standard for payment market infrastructures (MIs) around the world, from high-value payments systems (HVPs) and low-value payments systems (LVPs) to the securities and foreign exchange (FX) markets. Moreover, it has recently become the global standard for the world’s cross-border payments to harmonize interoperability between domestic and international payments and deliver a consistent experience for customers.

The Cross-border Payments and Reporting Plus (CBPR+) specification was created to define the ISO 20022 usage guidelines for cross-border payments and cash reporting on the SWIFT network allowing for further enrichment to the party information (payer and payee) within the messages and facilitating for more efficient anti-money laundry and sanction screening. With such inclusivity of data, better quality and capabilities are gained allowing for expanding currently offered services.

With all the advantages of ISO 20022 comes a high level of complexity in the migration of the current legacy MT standards to the new MX standards as financial institutions are expected to cater their systems to the below requirements:

  1. Adopt the new CBPR+ messages format, service and workflow
  2. Extend payments and remittance information to support CBPR+ messages guidelines
  3. Harmonize the ISO 20022 migration process by aligning the product release cycles with the guideline updates for both new and migrated systems
  4. Coexist with the legacy MT standard
  5. Abide by the restricted three-year coexistence period (2022 – 2025)
  6. Revisit and evaluate the required changes in systems affected by CBPR+

The three-year transition period will be a coexistence period between both cross-border MX and MT standards and by completion of this period, SWIFT will decommission the MT format for international payments.

During this period, financial institutions should gradually migrate their affected systems to the CBPR+ in phases, implement both standards and related workflows, and decide how to send the messages based on the migration status at the recipient end.

So, how can financial institutions address these encounters and migrate to ISO 20022 as seamlessly as possible?

Financial institutions can choose one or more migration approaches for their payment systems based on the assessment results and roadmap for each system. These approaches include:

  1. Ad-hoc Translation Approach which converts incoming MX messages into equivalent legacy MT formats, as well as converts outgoing MT messages into equivalent MX formats, and supports required reporting and confirmation messages.

    Pros: Minimal to zero changes on the existing payment system, and considered an intermediary phase towards native support of ISO 20022

    Cons: Does not enhance the current system by introducing any of the new ISO 20022 functionalities since they are matched to the legacy capabilities

    Ad-hoc Translation Approach
  2. Native Implementation which adopts the full richness of ISO 20022.

    Pros: Offers additional and enhanced services for the market and customers

    Cons: Requires a substantial investment and may need considerable time and effort to adapt to the changes in legacy/hard-to-change systems

    Native Implementation
  3. Hybrid Approach which avails smoother adoption of CBPR+ where the financial institution can choose to migrate a subset of CBPR+ messages using an ad-hoc translator, and other messages using native CBPR+/ISO 20022 implementation.

    Using this approach, the financial institution will be able to decide when to rollout any of the CBPR+ messages from the ad-hoc translator to the native implementation according to the institution’s systems’ assessment and priority roadmap.

    Pros: Quick adoption of CBPR+ and flexibility to upgrade to native CBPR+ without strenuous deadlines and the need for full systems’ migration. It is the preferred approach for financial institutions that are gradually migrating towards CBPR+ during the coexistence period

    Cons: Handling the ad-hoc and native approaches simultaneously in a production environment can be challenging for system administrators and operators

    Hybrid Approach
  4. Centralized Payments Hub Orchestrator which acts as an intermediary between the financial institution’s back-end systems and SWIFT network, and supports the above-mentioned approaches along with new additional features

    Pros: Aligns the financial institution with the payment landscape’s best practices and facilitates seamless adoption of CBPR+ guidelines, richness and updates. It may also enable using different types of payment channels and services such as Visa Direct, Ripple and Mastercard Send without impacting other systems

    Cons: This approach is preferred in case of having multiple affected financial systems within the institution or having a hard-to-change system. The cost of this type of solution is usually higher than the other options and should be considered as a part of the cost/value analysis during the assessment phase of each system

    Centralized Payments Hub Orchestrator
  5. Multi-Tenant Enterprise Hub which acts as a central platform for financial institution, subsidiaries, branches and offices across different regions, with the capability of addressing local market infrastructure rules and regulations.

    This approach also avails the ability to serve and manage multiple financial institutions by central banks and/or a centralized service where financial institutions can subscribe to the service and customize their integrations.

    Pros: In addition to the advantages mentioned in the centralized payments hub approach, the multi-tenant enterprise hub avails the ability to share system costs between multiple implementations and provides a central authority with enhanced monitoring/reporting capabilities. It also it boosts the adoption of new payment methods and updates

    Cons: High cost and operational efforts carried by the central service provider

    Multi-Tenant Enterprise Hub

In addition to the above migration approaches, the systems should also support one or more rolling out strategies to accommodate each individual demand and requirement. These implementation strategies include:

  1. Multi-phase Implementation: Ability to roll out a selected subset of features and messages at a time, this strategy can be useful for large systems with many types of supported payment messages
  2. Single Phase Implementation (Big Bang Implementation): This option can be suitable for systems that already support ISO 20022 messages and/or the migration to CBPR+ does not require a lot of effort - it best fits in the ad-hoc translations or centralized payment hub migration approaches. Systems assessment and institution risk appetite play a major role in proceeding with this approach
  3. Canary Release: This strategy avails rolling out the changes to a small subset of users/traffic before rolling it out to all users and infrastructure to reduce the risk of the new CBPR+ related changes
  4. Harmonized Implementation: In this strategy, the CBPR+ system release cycles and roadmap should be aligned with new CBPR+ guidelines releases and updates

ProgressSoft Payments Hub (PS-PayHub):

ProgressSoft’s Payments Hub is an advanced, full-fledged, modular platform that handles all payment types and acts as a single orchestrator for transaction management. It offers a multi-tenant setup through one centralized enterprise platform that supports banks’ complete payment types across different countries and regions, subsidiaries and corresponding financial institutions. Furthermore, due to the modularized and pluggable architecture of PS-PayHub, the system is able to support all introduced migration approaches and rolling out strategies mentioned in this blog.

The advanced PS-PayHub platform is a Cross-Border Payments and Reporting Plus (CBPR)+ ready solution that assists financial institutions in migrating to ISO 20022 with minimal to zero changes on back-end systems.

Subscribe to The ProgressSoft Blog