Introduction

Recently we have been working with a growing number of clients who need to use both SWIFT MT and ISO 20022 (MX) messaging. This generally involves the creation of a range of mappings between the two formats.

The requirements vary, but fall mainly into the following categories:

• Connecting to the growing list of new payment services that require ISO 20022 to be used
• Onboarding new clients who use ISO 20022 as their standard
• Protecting legacy systems which only create/consume SWIFT MT which now must be interfaced to an ISO 20022 based system or service

Though the scenarios are diverse, the same questions tend to be raised by our clients:

• Which MT<>MX specification should I use?
• What should we do if no specification exists for our scenario?
• Why can’t every valid SWIFT MT message be mapped to/from ISO 20022?
• Which MX version should I use?
• How do I maintain these mappings each year when the SWIFT MT and/or ISO 20022 change yearly?
• How can I create mappings that support both XML and JSON as input or output?

History of MT and MX (ISO 20022)

Before we describe some features of the solutions we are helping our clients to build, it may be useful to understand how we got here in the first place.  Around 10 years ago, SWIFT wrote a set of formal specifications which describe how to convert a limited number of MT messages into their ISO 20022 (MX) equivalents.  These mapping specifications are mainly constrained by what an MT message can provide (or conversely receive) as ISO 20022 formats tend to be more comprehensive. They were current for when they were written but have not been updated for several years and as the MT standards have moved on then these specifications have quickly become out of date.

For example, in 2015 the Payee field in the MT103 message changed to give a new formatting option (59F) which is essentially a free format field with no formal structure to its data.  Whilst the fields are there in MX to handle it, it is quite a complex free format field with the potential for different interpretations in its use between participants.

Another issue is how the MX messages were created in the first place.  The simple truth is that they were not designed primarily as MT replacements (with the exception of Corporate Actions and Settlement & Reconciliations). This is particularly true in the Funds message set where one MT message covers several MX business uses.

For payments, the MX Payment Clearing and Settlement (‘pacs’) and Payment Instruction (‘pain’) message type were developed with no regard to compatibility with the MT103 Payment message. The aim was rather to include everything that was potentially needed for a future-proof and globally definitive payment message.

With that in mind the definitions in ISO 20022 of one of the actors in a payment – the creditor for example – is defined extensively with lots of explicit fields for name & address information. Conversely, in the MT format the approach is around the 4*35x field with no distinct separation if you want street number, name, town, postcode, country etc.

Whilst conventions exist on how to interpret the address, they are not definitive rules that all adhere to.

Standards Updates

SWIFT update their MT standards yearly, and mandate that you must use the current version if connected to the SWIFT network.

With MX messages, there is no such requirement and most messages exist in several versions as these too are updated annually. External systems are often defined with an explicit version which has become increasingly outdated over time.  This is an important aspect when considering how to create a solution as the maintainability of this will be key.

Why can’t every valid SWIFT MT message be converted to ISO 20022?

This is a common question and a confusing issue. We are often asked the following:

“I have a valid MT103 but when I try and transform this to its pacs equivalent using the SWIFT specification it fails, how can that be?”

The idea that you have a valid MT message does NOT always mean that using the specifications SWIFT define will always produce the relevant ISO 20022 output.  When SWIFT developed their specifications they created rules that restrict which MT messages may be converted.

For example, in the MX Payment Clearing and Settlement (pacs) message the PartyIdentifier field must be present under certain circumstances, but the MT103 Payment message validation allows this field to be empty.  Therefore we can have a valid MT103 which cannot be mapped to a valid ‘pacs’ message.

Our clients often want to be able to choose which of these additional restrictions are enforced or wish to have the ability to turn them all off or turn on specific ones for specific clients. In short, customers want as much flexibility as possible and for these rules to be maintainable.

Maintainability issues

All MT<>MX mappings that our clients construct must be easy to maintain, because both the standards and the specific business needs will of course change over time.

One strategy we recommend is to create two mappings which operate sequentially. Firstly, there is a set of enrichment rules which enhance the original message depending on the source (sender), and then there is a “neutral source” mapping that all messages go through.

We find that this way considerably reduces the complexity of maintenance, as updates that only impact one or a few senders do not require an update of the main “neutral source” mapping.

JSON v XML

With the rise of APIs more and more organisations are struggling to encapsulate the richness of ISO 20022 data elements within a JSON structure.

Frequent challenges that can arise when working with ISO 20022 and JSON include:

Using the ISO 20022 standard to create mappings that consume/produce messages in XML or JSON.
Importing pre-defined JSON Schema or Swagger files to use as message structures in transformations.
Tailoring the ISO 20022 format to fit  project-specific needs and exporting this structure as JSON Schema or Swagger for other applications to consume.

In all these situations JSON interoperability (the ability to handle data in JSON or XML formats with equal ease) and the ability to read and write JSON Schema / Swagger files are critical. Transformer provides all of these capabilities ‘out of the box’.

How does Transformer help me with MT-MX?

Transformer has an MT-MX mapping suite that takes all of these risks into consideration to give you the most configurable and (importantly) maintainable solution for your business.

The mappings are based on the SWIFT standards and we continue to maintain them to keep them in-line with the SWIFT MT yearly upgrades and any ISO 200022 changes.

The additional validation checks that many customers require are also configurable and so can be easily turned on or off. The user can easily select which ones they wish to apply using our powerful GUI.

Bespoke validation/enrichment rules are easily created and maintained through the GUI, and with our documentation functionality you can make these visible to both your team but also the message senders if this is appropriate, to show them how you process their bespoke message formats.

The library which includes the SWIFT MT format, the ISO 20022 format and the mappings that define how messages are transformed are maintained to keep any changes in line with the industry standards meaning that our clients are always kept up to date with any changes that may affect them or their customers.

Transformer allows the user to create outputs in JSON format from any starting point. For example, Transformer’s ISO 20022 library allows the user to create ISO 20022 compliant messages in either XML or JSON. This capability is available for every message standard supported by Transformer, and thus allows global usage of the JSON format.

The testing functionality in the Transformer GUI means that any changes can be rigorously tested using an Expected Results facility. This is particularly useful when you update either the Messages, Rules or Mappings and can see what may have changed/broken in your current configuration and aids the user in either fixing the problem or accepting the changes.

Summary

To successfully build and maintain high quality solutions in the complex area of MT-MX coexistence requires plenty of experience, a deep understanding of the issues, and the right technology. Trace Financial provides all three.

To see which pre-built MT<>MX Mappings are currently supported by Transformer click here