Article 17/01/24

Blog Post: CBPR+ Now

Introduction

A history of Swift’s in-flow translation service

To assist FI’s with their migration from Swift MT to ISO 20022 (MX) for cross-border payments and reporting (CBPR+) Swift provided a free in-flow translation service at the beginning of the co-existence period to allow all members of the Swift network the receipt of both MT and MX messages during the coexistence period which is scheduled to end in November 2025.

This service is a vital aspect to enabling all members connected to the Swift Network to begin their journey to migrate to MX but with the November 2025 deadline approaching this in-flow translation service will become chargeable in 2024[1]

What does this mean for companies who use the Swift in-flow service that:

  1. Plan to migrate to their own in-house MX solution before November 2025
  2. Plan to continue using this Swift in-flow service post-November 2025
  3. Have not planned for the retirement of the MT 1,2 and 9 Series messages for cross-border payments and reporting.

Before we address what FI’s should be planning for let’s describe what this in-flow service does and why it’s being monetised.

What does the Swift in-flow translation produce?

Using the Swift in-flow service allows the recipient to receive both MT and MX flavours of a a payment which has been sent over the Swift Network

[2]

This way the recipient can choose whether to process the MT or MX based on their downstream’s system capbilities of handling the MX and/or MT flavour.

The format of the file consists of these elements in the message.

The Translation result will return one of the following options

TROK – MX translated to MT without any errors

TRAK – Some MX elements not in the MT, translation OK

TRNR – Truncation or charater replacement in non-reference field(s)

TRFR – Truncation of character replacement in reference field(s)*

TRNK – Failure to translate

* (see section “Truncation from MX>MT” section later in this document

What is the cost?

At the moment the start date and cost of this service is unknown.  The last announcement was via the ISO 20022 Community Readiness Deck for December 2023 which stated

“Swift plans to start charging for the service, but no date is decided yet. Swift will communicate about timing and practical details in 2024.”

The questions I would have would be “when” and more importantly “how much?”

The cost of the service and the metric used is unknown.  There are several metrics that Swift could choose to use such as:

  • Annual Flat fee
  • Cost per message
  • Cost based on Company Size (e.g. AUM)

It would make sense to have this cost based on a per message case but there may be other options to Swift such as adding this to their Swift Essentials package (https://www.swift.com/myswift/billing/swift-essentials) rather than a standalone cost.

The challenge for FI’s currently using this service is being able to assign additional unkown budget for this service at a potentially tight deadline to when Swift apply this charge or risk losing this service and therefore the abillity to process MX messages internally.

Why is this now chargeable?

There is a view that the reason behind this charge is to be a revenue generator but I personally disagree.

Swift have provided this service to their entire network for gratis from the start of the co-existance period to enable their users to migrate to the MX standard.

They have provided a wealth of tools and materials for their participants to use and assist them becoming ISO 20022 compliant as they know that completing this migration on time will benefit the entire community.

However the Adoption Rate percentage is still much lower than I would have expected and at November 30th 2023 the percentage of payments over the network which are ISO 20022 is still only at 16%

If the planned cut-off date of November 2025 is to be achieved than something must be done to motivate their users to achieve this goal so I believe they have made this in-flow service chargeable to force people to adopt their own solution to become MX native before the deadline.

Can I continue using this in-flow service after the November 2025 deadline?

No, Swift have stipulated that:

There is currently no plan for Swift to provide the in-flow translation service beyond November 2025. If at that point, your business requires an extension of translation services to accommodate a longer coexistence of legacy systems, an on-premise translation solution should be considered.”[3]

This is another reason why I believe the action of Swift to make the in-flow translation chargeable was not driven by revenue.  Swift could have continued to make this service available after November 2025 and generated revenue from FI’s who were either too late to adopt or for others who saw the cost of upgrading/replacing their legacy systems being much higher than what Swift would charge for their service.

This move tells me that Swift are concentrating solely on retiring these 1, 2 and 9 Series cross-border payment and reporting messages on time rather then generating revenue from this migration.

What limitations does the in-flow service offer?

Even if this in-flow service was available (and it may still be as nothing is carved in stone) why should FI’s be designing their own solution for this deadline?

As I have said previously in this article I believe this in-flow translation service is an excellent and much needed tool for the industry.  But, I do feel it has it’s limitiations and why I believe FI’s should have their own system in place.

Truncation from MX>MT

I believe this to be the greatest risk when using the in-flow translation service.

Even though it is easy to spot when an output MT message (it only affects MX>MT translation) has been truncated (due to the tell-tale “+” at the end of certain fields) the issue is having the knowledge to understand from what part of the original MX this information has started from and what other fields have to be taken into account.

For example if in an MT103 the SenderToRcvrInfo field (:72:) was truncated you would need to go through the logic of understanding from which of the multiple tags of the MX were used to populate the single field in the MT103 and at what point the field was truncated and more importantly what information was lost.

Even when you have captured the data for each potential field that could be truncated you then still need to store this information within your system along with the original MX and transformed MT message.

I believe the design/development/testing needed to achieve the above would mean that designing your own solution in-house rather than patching this to the (soon to be no-longer) free in-flow translation service (which isn’t available post November 2025) would future-proof your internal systems and is the correct path to take for FI’s on their ISO 20022 migration road-map.

Conclusion

This article is not from a “sales” perspective, I am not here to promote vendor solutions (even my own) or in-house development BUT I am here to recommend that any FI who is currently using the (in my opinion, excellent) in-flow translation service from Swift then they should be looking to implement their own in-house solution as soon as possible.

Frankly you don’t have a choice, later this year the in-flow service will no longer be free and more importantly it will no longer exist after November 2025 and so planning for this now is the ONLY logical option.

About the Author

 

During Paul’s 25 years with Trace Financial he has seen all aspects of the challenges organisations large and small face when implementing solutions such as MT and ISO 20022 coexistence and knows the best practices to build future proof, easily maintainable solutions.

Footnotes

[1] https://www.swift.com/standards/iso-20022/iso-20022-faqs/iso-20022-flow-translation#the-cost-of-in-flow-translation

[2] ISO 20022 Community Readiness Deck – https://www.swift.com/swift-resource/251878/download

[3] https://www.swift.com/standards/iso-20022/iso-20022-faqs/iso-20022-flow-translation#the-cost-of-in-flow-translation