As the journey to ISO 20022 messaging progresses, the industry remains firmly focused on the testing associated with the forthcoming cross-border payments and reporting (CBPR+) migration in the correspondent banking space. However, the industry should also be aware of what is just around the corner. Starting in May 2023, the Swift Transaction Manager is set to become “business as usual” – and so it is important that the specific Transaction Manager testing does not get missed off the agenda. 

But why is only testing for CBPR+ not good enough? And why is the additional testing for Transaction Manager essential for smooth payments processing in the near future? In this blog, we explore the answers to these important questions.

Why is the Transaction Manager so critical to the ISO 20022 project?

Brice Goemans, ISO 20022 Programme Lead, Swift: One thing that has become obvious to me over the decade that I’ve worked as a financial services consultant – and during my time at Swift – is that data is key to everything that we do.

At Swift, our ambition is to make cross-border payments instant and frictionless. And to do that, I believe, we need to enable the community to adopt and embrace automation to the fullest. To achieve this, there’s tremendous—currently untapped—value in richer data. As innovations in the payments space continue to evolve, the possibilities that rich, structured data offer to enhance the customer experience will only increase too.

The market’s decision to move to the ISO 20022 messaging standard for CBPR+ opens up a whole host of opportunities for institutions to embrace the benefits of rich and structured data and transform the future of payments.

The transaction management capabilities that we’re building into our platform are one example of how this can be done. Our platform will safeguard the integrity of the transaction data at every step in the process, ensuring that the benefits of rich data can be realised immediately, end to end. 

Swift is providing two essential components that will transform correspondent banking: ISO 20022 and transaction management. You can think of ISO 20022 as a vehicle capable of transporting all the cargo (data) your customers need. Transaction management, which will be provided by our platform, is like a highway on which the vehicle can move quickly and smoothly from end to end, with services along the way to ensure that the cargo is protected and arrives at its destination perfectly intact, exactly as it was at the start of the journey.

It’s been interesting for me to observe the test traffic in preparation for the global rollout of ISO 20022 for CBPR+, and the activation of our transaction management capabilities. We want to offer everyone in our community the ability to use and benefit from the data linked to a transaction. As part of this, we’ve distilled our observations and findings into a set of ‘key minimum requirements’. As a next step, we’re planning to make our customers aware of the main points they should consider ahead of traffic activation to avoid those practices from the legacy format getting carried over into the ISO 20022 implementation. So far, we’ve worked with five customers to pilot these minimum requirements in the form of a scorecard. We’re now looking to extend the delivery of scorecards to all institutions taking part in orchestrated community testing around transaction management over the next few months.

Think of the ‘key minimum requirements scorecard’ as the rules of the road. If you want to take advantage of the highway and its faster services (i.e. not get stopped or routed onto a slower lane), your vehicle needs to meet some minimum standards, and observe the rules of the road.

How important is testing to the success of the Transaction Manager?

Christopher Gardner, ISO 20022 Technical Programme Lead, Deutsche Bank: Our team`s experience with Transaction Manager testing has been invaluable. Having analysed the results of our Transaction Manager test and FIN traffic provided by Swift via the scorecard, we were surprised by a number of “creativities” identified. This included interpretations of the Unique End-to-end Transaction Reference (UETR) use or some very challenging message flows across multiple entities. What surprised me the most is that all of these scenarios perfectly fit into the CBPR+ requirements and, therefore, are impossible to be identified within the ISO 20022 project. The issues only become evident once you get the end-to-end view, which is only made available via the Swift Transaction Manager testing. This is carried out using the FINplus future test environment which, in addition to CBPR+ requirements, enables testing for specific validation, data integrity and visibility rules applied by Transaction Manager.

As mentioned, the results provided by Swift via the scorecard not only referred to the first few months of our Transaction Manager test traffic, but also focused on our live FIN traffic during the same timeframe. This allowed us to see whether the current behaviour could potentially cause issues in future payment processing once the transactions are being routed via Transaction Manager with additional validation rules applied.

In particular, Swift validated our traffic against the set of minimum key criteria that have to be met in order for transactions to be processed smoothly:

1. Validity of UETR. Ensuring each transaction is using specific UETR, i.e. no generation of duplicated UETRs or recycling is taking place.
2. Validity of Instruction ID in cover flows. Ensuring the “advice” message of a cover flow (e.g. MT103/pacs.008) contains a valid Sender’s Reference/Instruction Identification, which is not filled with “NONREF” or “NOTPROVIDED”.
3. Validity of End-To-End ID in cover flows. Ensuring the “cover “message of a cover flow (e.g. MT202 cov/pacs.009 cov) contains a valid Related Reference/End-To-End Identification, which is not filled with “NONREF” or “NOTPROVIDED”.
4. Matching of references in cover flows. Ensuring Related Reference/End-To-End Identification of a “cover” message matches Sender’s Reference/Instruction Identification of an “advice” message.
5. Correct message type. Ensuring integrity and accuracy of message types exchanged (e.g. no MT202 sent to cover MT 103).
6. Presence of /UDLC/ code in Financial Institution (FI) cover flows. Ensuring “core” message of an FI cover flow contains Instruction for Creditor Agent element, which is filled with /UDLC/ code and the respective details on the underlying beneficiary.
7. Matching of key data elements in cover flows. Ensuring underlying Debtor/Creditor (+Debtor Agent/Creditor Agent) elements of a “cover” message match the “advice” message.
8. Validity of gpi Service Level. Ensuring a correct gpi service type identifier/service level is used, e.g. G004 for Financial Institution Credit Transfers.

In order to investigate the results for each of these criteria, we involved various internal stakeholders from multiple locations (e.g. business analysts, product management, etc.). They identified several changes we must make in our own infrastructure as well as changes other participants must make where we act as their correspondent. These are set out below.

The need for market and client communication
As testing results show, in many cases, Deutsche Bank acts as the intermediary and forwards whatever has been received from the previous agent/via Clearing. The incoming messages, however, may already contain invalid cover references, incorrect message types or duplicated UETRs, which will only become visible once we forward the message via Swift – leading to our outgoing transaction “legs” being rejected due to the stricter validation rules. Some recurring examples are:

• Where “cover” messages do not contain valid related references of the underlying messages.
• Where an MT202 is being received as a currency funding payment for a MT103 subject to conversion under the same UETR.
• Where an MT103 is being received after an original MT202 is sent from the originator.

All of these are processed without issue today, but once the Transaction Manager is introduced, they may end in rejection (=not delivered to receiver) or bypass (=delivered to receiver via FINplus, but without processing and application of additional rules by the Transaction Manager). Therefore, for payments to be successfully delivered to their beneficiaries, we as an industry need to ensure adherence to the correct business practices and communication of cases of any incorrect behaviors early on.

The need for internal fixes
In several scenarios, processing issues were caused by the behavior of our own infrastructure, which provides further example of why current practices will not work in future. One such scenario is the payment of charges. Currently, the payment of claimed charges via MT191 is instructed using the same UETR as in the underlying payment. While this may facilitate easy reconciliation and speedy settlement, future UETR validation rules will flag these transactions as UETR duplication, which will lead to them being aborted. As a result, we decided to implement an internal fix and use a new UETR for the payment of charges going forward.

So, what are your conclusions from the testing?

Brice and Christopher: The first results from the Transaction Manager testing analysis show the importance of this exercise. The more issues and inconsistencies that can be spotted proactively in advance of the Transaction Manager go-live at the end of May 2023, the smoother future payments processing will be. Keeping in mind how interconnected our ecosystem is and our dependency on the performance of every actor in the payment chain, we encourage the entire community to test, test and test the end-to-end transaction flow for Transaction Manager. We also encourage the community to look closely at the results on an ongoing basis and assess what needs to be done to ensure all the fixes are implemented well ahead of the Transaction Manager go-live, when the stricter validation rules will be enforced. With the central capabilities established by Swift and accurate market practices followed by the industry, we will reach the goal of frictionless cross-border payments, lower costs and happier customers.

  By Brice Goemans,
  ISO 20022 Programme Lead, Swift

  By Christopher Gardner,
  ISO 20022 Technical Programme Lead, Deutsche Bank