ISO 20022 Financial Institution Migration Guidelines

1 Introduction

Traditional Financial messaging such as SWIFT MT has served the payments industry well for several decades. However, widespread automation has been held back due to the use of free text fields principally designed to help with manual processing. These limitations have led to longer processing times and increasing costs. In addition, financial crime mitigation and compliance screening has become more complicated and costly than necessary.

ISO 20022 is designed to address these challenges and is becoming the global language for financial messaging. As a result, market infrastructures around the world are migrating to this new standard.

SWIFT responded to this change by announcing a migration of cross-border payment messaging, starting in November 2021 with a coexistence period, and completing by November 2025. Following community feedback, particularly following the Covid-19 pandemic, the migration will now start in November 2022 (the planned completion date of November 2025 being unaffected). In addition SWIFT are introducing a transaction management platform that will assist migration.

This guide has been produced by the Payments Market Practice Group (PMPG) to provide Financial Institutions (FIs) with advice and considerations for managing their migration to ISO 20022 format across the SWIFT infrastructure, both from a technical perspective as well as the associated business processes.

ISO 20022 migration is happening across multiple payment infrastructures around the world and the complexity of managing multiple migrations, many of which are happening in the same timeframe, should not be underestimated. Although this guide is primarily aimed at how FIs should manage their SWIFT cross-border ISO 20022 migration, many of the topics covered are equally relevant to domestic infrastructure migrations that use proprietary interfaces.

The PMPG have also produced a paper on Market Infrastructure migration. (MI Migration Strategy link) This should be read in conjunction with this guide as it includes details about key milestones.

2 Overview of SWIFT’s cross-border ISO 20022 migration plan

The SWIFT ISO 20022 migration is being run as a programme with a number of key deliverables before the completion of the migration in 2025. Further details of the Programme are available here.

SWIFT have published a revised plan for the migration and have adopted a phased approach.

Source: SWIFT Chapter 1_Supporting ISO 20022 and rich data adoption for cross-border payments

2.1 The Cross Border and Payments Reporting Plus Group To define the ISO 20022 message structures and translation rules necessary for a successful migration, SWIFT and the PMPG formed the Cross Border Payments and Reporting Plus Group (CBPR+) in 2019. The key deliverables from the group so far are:

• December 2019: Phase 1 Payments & reporting usage guidelines are published • July 2020: Phase 1 Payments & Reporting translation rules are published and translation

portal is live.

2.2 Introduction to the Transaction Management Platform Over the next 2 years, in the lead-up with the ISO 20022 coexistence period, SWIFT are building a new foundation that will enhance the SWIFT platform to achieve the mission of delivering instant and frictionless international transactions with full transparency, end to end integrity and global reach, supported by smart data and mutualised services. At the heart of this delivery is the introduction of a new transaction management eco-system. This will be a key enabler of the migration and will address several of the challenges that SWIFT members will face during the coexistence period.

SWIFT ISO 20022 Migration Approach

Source: SWIFT Strategy Update_Prioritisation

The introduction of this new system has the following implications:

• Communication channels- A choice of FIN/MT, InterAct/MX and API will be supported, extended for transaction and service consumption;

• Transactional objects with rich structure –rich transactional data will be consistently stored throughout the transaction lifecycle. The TMP will hold the gold copy of the data which is accessible by all parties in the chain ;

• End-to-end service level management –enforced rulebooks on the global and community level across the transaction chain;

• Orchestrated Mutualised Processing Services –orchestrate usage of mutualised services along the transaction lifecycle to improve transaction processing cost.

Banks need to consider these implications, and the timeframes in which these services are offered by SWIFT. As the transaction management eco-system evolves they will need to decide how they will facilitate cross-border payments during the coexistence period, and how their own processes and interactions with the SWIFT network should evolve.

3 Business benefits of migration This section will help banks to prepare their business case for developments related to the migration. The intention is to allow banks to go beyond mere compliance with the technical aspects of the migration and to take advantage of the following significant business benefits:

Faster settlement of payments through increased STP.

Reduction in error and investigations throughout the payment chain because of structured data and increased information contained within a message.

Faster and more accurate compliance checking and financial crime mitigation.

Whilst full benefit of the ISO migration will only be achieved when the whole market adopts ISO 20022 at the end of 2025, there are nevertheless material benefits that can be realised on the journey to full adoption.

3.1 Customer Channel Changes Early consideration should be given to the need to make changes to the systems that clients use to initiate payments and to prepare customers for these changes. E.g it will be necessary to add specific ISO 20022 field elements to your electronic banking platforms.

In addition customers will need to change the information they capture and hold about their payment counterparties to structured formats. This is likely to require them to make both IT and operational changes.

3.2 Structured ISO addresses Having properly populated and structured address information is critical to identify the parties involved in the payment. In particular, names which are translated from non-Latin alphabets or ideograms, the right separation of names and family names helps reduce false positives in sanctions screening. Structured data is also important to understanding geographical money-flows, to detect countries not on AML white list or countries under embargo.

In general, structured addresses provide the opportunity to make the screening processes more efficient and effective.

As the community transitions through the ISO20022 coexistence period, we expect to see increasing prevalence of mandatory requirements for structured customer data, particularly driven by adoption of structured elements in local Market Infrastructure. To avoid the negative impacts of payment delay (associated with E&I processes for additional/clarified information) or payment rejection, it is highly recommended to include your structured customer data journey as part of your ISO migration.

The PMPG has produced market practice guidelines for Structured data. This paper provides vital guidance for preparing for structured customer data implementation aligned with the ISO migration and contains 14 individual market practice guidelines.

3.3 Ultimate debtor and creditor. The knowledge of who the ultimate parties are in a transaction is required in many jurisdictions. With MT messages it is difficult and in some cases unworkable to transport this

information with the payment, however, with ISO 20022, specific fields are provided for this information.

3.4 Structured Remittance information ISO 20022 will allow transmission of structured remittance information, going beyond the present (unstructured) size limitation. Information about the original (XML electronic) invoice, goods which are paid, and other details will help the reconciling parties. Moreover, information which is mandatory to accept a payment in certain jurisdiction can be included in the remittance part of the message, instead of being subject of a separate communication. This will help STP processing and Compliance screening, referring to embargoes and to the analysis of the kinds of good which is bought / sold in the transaction (as dual use goods).

3.5 Purpose codes The purpose code of the payment will improve “safety” and STP, in particular in those countries in which the “purpose code” is a mandatory attribute required by the market infrastructure or regulator. More countries are starting to introduce this as a payment requirement, so being able to capture and transmit this with all payments is a key requirement.

3.6 Customer experience Completing a payment message with the appropriate enhanced and structured information, such as ultimate parties and purpose, will facilitate improved business models, in particular payments and receipt “on behalf of”. Direct impact will be on e-commerce clarifying who are the ultimate subjects in the chain (buyers/sellers).

In addition, the structured information available in an ISO message will increase the likelihood that a payment will not be delayed as it passed through the payment chain.

3.7 Legal Entity Identifier (LEI) The use of LEI to identify parties in the payment chain has significant advantages for automating processing and allowing more accuracy in compliance screening. The PMPG recommends that ISO migration is a catalyst to facilitate the adoption of LEI. The incremental cost of introducing this is minimal as Banks are having to make multiple changes across their infrastructure. More information is available here.

4 Technical considerations

4.1 CBPR+ Standards SWIFT have published a Customer Adoption Guide this is a key resource providing advice to banks on the background to the migration and how to plan their adoption of the new standard. This is an evolving document and will be updated as new information becomes available. The guide provides further links to the CBPR+ Usage Guidelines, User Handbook and training resources.

4.2 SWIFT RMA During the coexistence period, banks are going to continue using both Interact and Fin and will need to ensure that their RMA is maintained for both channels.

RMA is likely to evolve as the Transaction Management Platform is developed. More information will be added to this section as it becomes available.

4.3 Truncation. Banks need to be aware that when ISO messages are converted to MT messages there will be truncation. Although this will be indicated on the MT message, it is important to understand the issue and the impact this can have on processing and screening. The Transaction Management Platform will provide a solution allowing all banks in the payment chain to see the holistic transaction and data, but banks will have to establish how they will use this in their workflow.

4.4 Domestic infrastructure migration timelines. Around the world many domestic payment infrastructures are migrating to ISO 200022. Plans for this continue to evolve and it is important that banks consider this during their own planning. The PMPG guide to MI Migration is a useful resource. (MI Migration Strategy link)

4.5 Exception processing Existing market practise for the management of returns, rejects, errors and investigations is currently inefficient and often manual. ISO 20022 migration will introduce better ways of handling these and banks will need to consider how to introduce or amend applicable processes.

The CBPR+ are currently working on a number of new standards and these will be published during 2021.

4.6 Special Codes and Instructions Because of the manual nature of MT message processing many special codes have been developed between Banks. Migration provides a great opportunity to review these and simplify processes. This should be a key consideration during migration planning with counterparties as it is bad practise to simply try and replicate everything that is currently used within existing MT based processing.

4.7 Testing Strategy Banks should have a testing strategy to ensure the success of their migration.

Mystandards and the Readiness Portal are excellent resources, but banks should also consider how to carry out Industry testing with counterparts (domestically and cross border), and the new test message sets they may need to generate to facilitate this testing.

5 Global payments systems Coexistence

Before and during the coexistence period most high value payment systems will migrate to the HVPS+ standard of ISO 20022 at different points in time. CHAPS in the UK will be one of the first market infrastructures in mid 2022 followed by Target2 and Euro 1 who intend to synchronise their migration with the enablement of MX messages on the SWIFT network in Nov 2022. The US payment system, Fedwire and CHIPS, will follow a year later. Many other systems might only migrate at the end of the migration period or might even elect to stay on MT messages should cross border payments in their local currency play only a marginal role.

Banks who participate in multiple markets will need to actively monitor the migration plans for each market, particularly as it expected that there will be changes during the coexistence period.

The multiple changes to payment systems give participants a number of challenges. They might receive payment orders in MX but need to convert the incoming message and data elements into the local format, which might not have the same data richness. The subsequent truncation and loss of data fidelity is likely to lead to issues for some of the banks in the payment chain.

To address these issues early on, banks need to engage with their community, HVPS operator and SWIFT and explore ways to mitigate any data issues, including options associated with the new Transaction Management Platform. While local transactions can be conducted in legacy format, any excess data can be made available via the TMP and this will allow a bank receiving the payment order in legacy format to access this for screening purposes. However it needs to be recognised that this bifurcated process can cause delays in applying the credit to the beneficiary or create operational risks in the screening process.

Banks should consult the PMPG Paper on Market Infrastructure Migration which details dates and other details about each migration. (MI Migration Strategy link)

6 Compliance with regulations and internal policies ISO 20022 migration is not just a technology issue but also requires a review of how existing regulations influence the migration. From its inception, the business case for ISO 20022 migration had a strong foundation in the Financial Crimes Prevention Community. Supporting the inclusion of all actors in the payment chain in a highly structured format is seen as a big step forward to increase transparency for AML and sanction screening processes. Complementary efforts to promote the use of the LEI in payments and eliminate the use of unstructured address data provide a further boost to support an efficient and compliant payment process.

Banks should carry out a complete review of their Payment Policies and the various regulations that could be impacted by ISO 20022 migration. This should include:

• FATF 16, US Travel Rule, domestic sanctions and regulatory reporting regulations. • Data Truncation and how this can be mitigated need careful consideration during this

exercise.

• KYC Procedures may also need to be amended to ensure that information captured about various parties is accurate, structured and captured from an authentic source.

7 Communication Effective internal and external communication is vital to ensure an effective migration and to minimize customer disruption.

7.1 Customer Communication As explained in section 3, ISO 20022 migration will have a significant impact on customers.

It is vital that the potential changes are communicated as early as possible. Customers may need to change their processes for capturing data about their counterparties and will have to make changes to their systems to store this data in a structured way. It would be prudent for them to complete a review of all their existing data.

Banks should be proactive in telling their customers what data they need to collect. Currently it is often only necessary to quote a beneficiary’s account & name to make a payment. But it is expected that in the future more information such as a business identification code or similar plus an address may be required. As explained in section 4, PMPG is recommending that LEIs are used to identify payment parties. So customers should be advised to capture this where available and to ensure they can validate and store it appropriately.

The customer benefits around improved payment processing times and the reduction in errors should be stressed, to offset any reluctance they may have to make the necessary changes.

7.2 Counterparty Communication During the coexistence period from November 2022 to November 2025, banks will be migrating at different times. It is important to understand what plans your correspondents and counterparties have in this regard, so that a coordinated approach can be agreed. The following some topics you may wish to discuss with them. This list is not exhaustive, but should help banks to plan their communication approach.

• Strategy: big bang or phasing. • Timing (early adopter1 or not), message types(if phased approach is used) for example,

payment messages, cash reporting and investigation messages. • Availability for testing. Finding a partner for testing among your major counterparties will

help to ensure that issues are minimized when the actual migration starts. SWIFT will provide a sparring partner facility for testing in Q1 2021.

• Expectations of new products as a result of ISO20022 migration. • Plans for using optional fields, for example, use of additional intermediary fields, etc. • Plans for using structured data or accepting unstructured data for equivalent fields of

50/59.

Practice in respect of some message types. For example, pacs.002 is mandatory to be used for rejects (code RJTC). It might be of interest to your institution to find out whether your

1 SWIFT assumes that institutions which generate high volumes of payment transactions will be encouraged to be early adopters for payment initiation, to ensure quality data is captured at the very start of the transaction.

correspondent banks are planning to send pacs.002 for each payment, irrespective of its status.

• Approach for existing arrangements on the usage of bilaterally agreed codewords for fields 23 and 72 both for incoming and outgoing messages. Are these arrangements to be kept in place etc.

7.3 Vendor Communication Banks need to ensure that their SWIFT application vendors are prepared for ISO 20022 migration and they should discuss this with them. A list (non exhaustive) of vendors who have confirmed their commitment to support the CBPR+ message collection can be found here. If your application provider is not on the list, let SWIFT know so they can reach out to the vendor directly.

7.4 Internal Communication The migration programme will impact every area of a bank’s organisation, including Legal, Compliance, Relationship Management, Sales, Product, Operations and IT. Effective internal communications are essential to ensuring that these different areas are working together towards a successful migration.

8 Summary Checklist The following are a list of high level recommendations for banks to consider as part of their migration programme.

8.1 Senior Management Sponsorship The complexity and cost of migration should not be underestimated, and many business areas will be impacted. Therefore, it is important to get senior level sponsorship for your migration programme.

8.2 Business Case Migration has many benefits related to improved efficiency and safety and should not be considered solely a regulatory or mandatory project. Without considering these advantages, banks could end up with a solution that costs more in the long term and puts them at a competitive disadvantage.

8.3 Technical & Operational Changes Banks need to fully understand and plan all the change they need to make across their organisation before and during the coexistence period. This should include internal and vendor changes.

8.4 Product and legal documentation changes Product features and terminologies in legal agreements need to be reviewed and adopted to the new ISO 20022 nomenclature. References to specific message types (e.g. MT103) and fields should be made more generic so that MT, MX and API calls are covered. Requirements in regard to new messages such as payment status reports and return messages should be clearly articulated.

8.5 Customer Impact Assessment and Communication Customers will be impacted because of migration. They will need to acquire and store information about their counterparties which will potentially require organisational, as well as IT changes. Early communication to customers is vital.

8.6 Counterparty Communication Migration plans needs to consider how payment counterparties will be affected. Joint planning of migration milestones and testing plans will help to reduce the impact on both parties.

8.7 Community Involvement Being involved with local SWIFT member groups and domestic infrastructure user groups is the best way of understanding particular challenges that will be faced in a community. This also gives banks an opportunity to influence migration timetables and strategy.

8.8 Training Because of the complexity and breadth of change that ISO 20022 migration will have across a bank, it is recommended that a training programme is delivered to all members of staff. This should cover the background to ISO 20022 migration, what is changing across the organisation and how customers will be affected.

Appendix 1 Information about the PMPG

Relevant regulations and any applicable legislation take precedence over the guidance notes issued by this body. These Guidelines represent an industry’s best effort to assist peers in the interpretation and implementation of the relevant topic(s). The PMPG - or any of its Members - cannot be held responsible for any error in these Guidelines or any consequence thereof.

The Payments Market Practice Group (PMPG) is an independent body of payments subject matter experts from Asia Pacific, Europe and North America. The mission of the PMPG is to:

• take stock of payments market practices across regions,

• discuss, explain, and document market practice issues, including possible commercial impact,

• recommend market practices, covering end-to-end transactions,

• propose best practice, business responsibilities and rules, message flows, consistent implementation of ISO messaging standards and exception definitions,

• ensure publication of recommended best practices,

• recommend payments market practices in response to changing compliance requirements

The PMPG provides a truly global forum to drive better market practices which, together with correct use of standards, will help in achieving full STP and improved customer service.