ISO20022 Adoption Strategy – from a Bank’s perspective

ISO20022 Adoption Strategy – from a Bank’s perspective

In our previous article in JDX’s series of Payments-related articles, we explored the ISO 20022 international standard and the criticality of the framework in driving a global open standard for movement of money messaging.

In our second article in the series, we look at ISO 20022 adoption in further detail, from a bank’s perspective preparing for such change and working towards ISO 20022 compliance.

Why is ISO 20022 being adopted?

Different parts of the financial community have different drivers for adoption. But most see the key drivers of adoption of ISO 20022 as the improved compliance, efficiency and customer experience that having a single end-to-end standard for international, domestic, high value, low value, and instant payments delivers.

Why is ISO 20022 better than MT?

ISO 20022 is richer in content, more granular in detail and more structured than MT messages. That combination enables higher efficiency in end-to-end automation by allowing cleaner screening and adverse event detection, and therefore fewer false positives and straight-through processing (STP) breaks. Moreover, the richer data enables better end-to-end transmission of more and more helpful information for the benefit of customers and their business partners alike. 

What to consider during the co-existence period (2022- 2025)?

The ISO 20022 migration will occur in phases over the next few years and by 2025, 80 per cent of global high-value payment volumes will use ISO 20022 and MT connectivity ends. It’s important to note that from Nov 2022, SWIFT is introducing a central Transaction Manager (TM) that will provide end-to-end orchestration of transactions and allow the industry to move away from point-to-point messaging and towards central transaction processing. TM will hold a master ‘transaction copy’ and orchestrate a transaction from sender to receiver, fundamentally changing the processing and communication of messages for participants in a payment. TM will also provide message interoperability in the co-existence phase (2022-25) including:

  • Application programming interfaces (API) (NEW)
  • ISO 20022 messaging and
  • MT connectivity (ends 2025)

In a following article in this series, we’ll look at in further detail what needs to be taken in account during this coexistence period.

From a Bank’s perspective, what should my ISO20022 adoption strategy be?

A primary element of any bank’s ISO 20022 adoption strategy will be getting their systems ready and ensuring their platforms can cope with the new standard’s larger data sets in terms of capacity, storage and performance. Many banks are already leveraging new technology and digitising their platforms, so they may already have the capabilities to accommodate large sets of data and support ISO 20022-based data models.

It is essential to note that banks will need to analyse their data models across the payment lifecycle’s entirety. Any system that touches the flow of payment processing and settlement—including messaging, accounts data, sanctions screening, accounting entries, settlement reports, statements and reporting, billing and inquiries—has the potential to be affected.

Banks will, therefore, need to carefully consider all of the business components that could be impacted by the upcoming ISO 20022 changes (as highlighted in our previous article and plan accordingly). As banks transition to ISO 20022, several vital decisions must be made concerning strategic outlook and technological operations. There are several ways banks can approach the adoption, most of which can be grouped into one of three categories mentioned below:

  1. Full Migration: Each system within a banks’ payment processing chain is upgraded to accept, process, and send ISO 20022 format messages natively.
  2. Simple Translation: Translation tools transform inbound messages into their MT equivalents and outbound messages into their ISO counterparts, while underlying payment and reporting systems remain essentially unchanged.
  3. Bridged Translation: Underlying payment systems remain largely unimpacted, and messages are translated from MT to ISO formats and back. Overflow information from inbound messages is stored to be restored and reintegrated into the corresponding outbound messages.

Which approach is best for my bank?

A bank may choose one of the approaches above or they may choose to create an incremental approach depending on their organisational structure. For instance, they may start with a bridged approach and then work towards the full migration approach.

The below table provides some insight into which approach could be best suited for different types of organisations.

Regardless of whether a full, simple, or bridged approach is taken, the following are some of the key characteristics that if addressed will lay the foundation of a successful migration to ISO 20022:

  • A clearly defined long-term strategy
  • A comprehensive impact analysis
  • Robust and systematic project management
  • Effective internal communications
  • A future-proof technology and testing solution

This summarizes the key criteria that each approach has been assessed against and the following discusses in detail these criteria each approach.

1. Full Migration Approach – Key Considerations

Full migration replaces existing non-ISO20022 (typically MT) based systems built in its new architecture around ISO20022 functionality. Such a migration naturally involves change and consolidation in almost all components of the organisation’s payment systems. It is typically delivered across a complex, multi-phase and multi-year transformation program.

The full migration approach is the most robust and future-proof of all approaches but is most likely the most costly and time-consuming and comes with their own set of risks and technical challenges as illustrated below:


  • This nature of migration requires the application to be deeply intertwined, and often heavily customised solutions proved to be costly to upgrade or replace.
  • Payment engines, reporting systems, screening products, back-office tools, channels – everything needs to be adapted, and interoperability needs to be ensured.
  • The teams involved in managing and operating each of these tools needs to highly skilled with ISO20022 data structures, as do corporate customers looking to leverage the data language for their payment initiation and reporting.


  • Upgrading multiple systems synchronously increases complexity and the risks in understanding existing and underlying functionality, which requires time for analysis and mapping. 
  • Since testing alone might require months or years, time to go-live in the market with a big bang or staged approach might require thorough planning and structure.
  • Corporate customers expect the improved experience ISO provides, and early adopter banks can expect to win market share. When facing short, hard deadlines for migration, banks should take care to analyse the readiness/ confidence in a timely delivery and realise that there is considerable time spent in merely replacing much of the existing functionality. As is the case with most large and lengthy IT projects, there is inherent time and budget risk along with the unknowns and unexpected issues underway.
  • Payment engine upgrades can negatively impact the correct and timely processing of payments
  • During the upgrade there comes a risk to data integrity and the potential to ‘lose’ critical data and functions.


  • Deciding on Full migration will likely be the costliest approach to the ISO migration in terms of implementation. However, it should result in higher STP rate, other operational efficiencies and a compelling customer experience. 


  • Full migration should increase a bank’s STP rate, which in turn should result in increased operational efficiencies


  • It allows the use and reuse of messages and fields in different ways; using appropriate syntax will enable them to be interpreted correctly by all users.
  • Component architectures are modular and support the reuse of parts of the application logic using the same standards.
  • Upgrading payment processing applications to be ISO native, will ensure that all components speak the same language and eliminates data truncation risk.


  • High availability and cost savings, with simplified scheme maintenance and regulatory compliance. This means banks can innovate at speed, responding to global payment trends while modernising effectively.
  • Using a common internal language such as ISO across processes and applications allows banks to leverage rich data across business processes to improve straight-through processing capabilities, operations efficiency, and business insights.


Full migration approach captures all available data at payment initiation and ensures it remains preserved and available throughout the translation process and for onward and subsequent reporting and access. This essentially means that data integrity is maintained regardless of the underlying system or message format.

2. Simple Translation Approach – Key Considerations

This approach involves technical conversion between the old formats (FIN/MT, or other proprietary formats), and the new ISO20022 (MX) formats. This will typically happen at the edge of the borderline or the periphery of the organisation’s system architecture, with slight or marginal changes within the core components.


  • This type of migration is less complex as it doesn’t require applications to be intertwined and customized deeply.
  • Manual interventions may be necessary to achieve the successful translation and hence lowering STP rates.


  • Several non-immediate visible risks can occur as a result of this approach because payment instructions are modified outside of characteristically secured systems and it could be challenging to track modification.
  • This solution approach could potentially impact the correctness and timeliness of processing payments, impacting corporate customers.
  • As ultimate creditor/debtor fields cannot be reliably mapped to and from an MT message, banks are at risk of truncating this information, and as such, could violate legislation corresponding to this recommendation. Banks must include accurate originator and beneficiary information and pass it along the payment chain under FATF recommendation 16.


  • The least costly approach to the ISO migration in terms of implementation. However, it creates its own unique set of challenges, and provides for the least automation opportunities and will likely lead to lower STP rates.


  • Business operations such as payment initiation, repairs, exception management and other workflows may be updated to deal with the additional data and complexity introduced through translations.
  • Simple migration will likely not improve STP rate and could reduce STP rate and increase operational costs and impact customer experience, especially around if increased manual compliance checks will be required due to data loss or truncation.


  • This approach allows the use and reuse of messages and fields in different ways; using appropriate syntax will enable them to be interpreted correctly by all users. The applications are not intertwined deeply, so reusability might be lessened, depending on the system architecture.


  • The translation is performed at the edge of the periphery of the system architecture so there little ability to scale this solution.


  • When structured information is mapped to an MT message upon translation, it becomes unstructured. If later in the payment processing chain an MX message must be generated (e.g. for reporting- camt messages), it becomes very difficult to make use of the data due to loss of structure which cannot be undone. Such challenges lead to lower STP and reconciliation rates.
  • Mapping key bank to bank information (e.g. Intermediary agent details, local instrument code, instructions for next agent) from the structured MX message to the unstructured MTmessage can potentially lead to data loss or data truncation due to field limits and respective fields unavailability, which further leads to sanction issues as well as lower STP.
  • Besides the loss of originator/beneficiary information, valuable remittance information or identifiers can be lost if they cannot be mapped to an MT message. This can lead to reconciliation issues for the beneficiary, resulting in a poor customer experience for Fis and corporate customers alike.

3. Bridged Translation Approach – Key Considerations

The Bridged or Linked translation approach allows data to be stored, indexed, updated and subsequently accessed throughout the lifecycle of a payment. This approach extends the simple translation approach whereby overflow information from inbound messages is stored to be restored and reintegrated into the corresponding outbound messages.

ISO 20022 payment data can be significantly larger than MT payment data, especially when using structured remittance information. So, by sending this comprehensive data in parallel rather than through the payment systems, complementing existing value processing, banks protect their core systems investment from increased data throughput and storage requirements.

Like all approaches detailed above, this approach also presents a number of challenges as outlined below: 


This migration approach is considered medium complex compared to the full and simple approach. This approach differs from other approach where by:

  • Data is managed and treated end to end and works on a separate processing stream.
  • It addresses needs beyond even what vendor products offer, namely the auditing and traceability of data as it progresses along the payments value chain.


  • In addition to the simple translation approach risks detailed above the time to market will heavily depend on the banks existing infrastructure and how this bridged translation approach can be architected and delivered


  • Due to the additional benefits and functionality, the cost of this approach should be expected to be higher than the simple approach but significantly lower than the expenditure related for full migration approach.
  • The benefits arising from the end-to-end integrity and protection of full MX data can lead to lower operational costs, increased STP rates with fewer repairs, inquiries to respond to, and lower transaction screening false positives.


  • A key feature of ISO20022 is the ability to reuse components across all messages – no matter if it’s a credit transfer, credit card payment or FX transaction. Since the components and applications are intertwined in this approach, reusability is possible assuming the system architecture allows.


  • As this approach allows data to be stored, indexed, updated, and subsequently accessed, its likely this approach will be much more scalable than the simple approach.


  • This approach captures all available data at payment initiation and ensures it remains available throughout the translation process and for onward and subsequent reporting. This essentially means that data integrity is maintained regardless of the underlying system or message format.
  • The data integrity issues with the simple approach is mitigated here with this approach.

What other potential ISO 20022 adoption challenges should a bank address?

Apart from agreeing which strategy to go with as per above, it’s also important to consider a number of other challenges in adopting ISO20022:

  1. Understand the complexity of ISO 20022 as a new data model standard: to fully understand this a banks needs to understand the rationale behind the ISO adoption. For instance, legacy systems should be able to map to the new systems, and this also will need to include the proper rules for AML, fraud, and compliance checks.
  2. Upgrade (or replace) aged legacy systems: legacy systems will need to be updated to handle ISO 20022 data through the use of convertors or translators as they can’t often process or support the ISO 20022 format.
  3. Address differences in Market Infrastructure specifications: There are essential differences between the implementation guidelines for different payment schemes (for example, HVPS+ and CBPR+), and it is imperative to understand the differences.
  4. Implement new data management: ISO 20022 messages can contain repetitive sections that multiply the length of messages by up to a hundred times. This dramatic expansion in data demands a redefinition of all infrastructure that will handle ISO 20022 data.
  5. Keep up to date with the correct timeline: There are different ISO 20022 adoption deadlines for different markets so banks need to plan their migration strategy to achieve the timeline carefully.


ISO 20022 should NOT be viewed as just another IT program of work. While ISO 20022 migration is not mandatory from a regulatory perspective, those banks that do not act now risk being excluded from future international payment systems. As absolute minimum requirement banks do need to ensure that they can no longer depend on using MT messages from an inbound and outbound perspective for cross border payments from 2025 as they will be decommissioned. 

Banks should be looking to approach their ISO 20022 adoption driven by their strategic outlook and how to enhance their existing processes and technology for commercial benefit. It is hoped this article provides thoughtful insight that will assist in defining a banks ISO 20022 adoption strategy, whether that be the full migration, simple translation, bridged translation approach or a mixture of them.

How Can We Help You?

For more information on how JDX can help with ISO 20022 adoption, ISO 20022 compliance, and information relating to our payment solutions and competencies, please contact Michael Levens or Michael Robertson.