MT-MX for Payments
Financial market infrastructures, especially those providing payment processing services, are the principal drivers behind the adoption of ISO 20022 based standards (MX messaging) across financial markets worldwide. However, the older SWIFT MT message set is still deeply entrenched in the core systems and processes of the banking sector. This situation has created a growing demand for MT-MX conversion solutions.
The payments world is migrating to ISO 20022
The pace of change in the payments ecosystem continues to accelerate. As Hannah Nixon, Managing Director of the UK’s Payment Systems Regulator has said: “The payments industry, including the technology, infrastructure, and services offered to users, is going through the type of wholesale change that is only seen once in a generation”.
In numerous jurisdictions worldwide plans are being developed that build up to a complete technology refresh of the core infrastructure systems themselves. The messaging component of the proposed new infrastructures is now invariably based on the ISO 20022 standard. The usage of this standard is therefore also being promoted for a range of short-term developments based on the current legacy infrastructures.
A key benefit of ISO 20022 is that it allows for much more information about the reason for the payment (remittance data), potentially allowing for automated reconciliation between invoices and payments. It is the messaging standard used in most of the Faster Payments systems introduced in the last 10 years. The EU’s Sepa Credit Transfer ‘SCT Instant’ is a current example, going live in November 2017.
The need for MT-MX conversion
So why is this adoption of ISO 20022 (and more specifically MX) a problem? As noted in the introduction, a huge range of banks and other financial institutions still rely on the SWIFT MT format payment messages that have been in use for many years, and which are often deeply embedded in legacy systems and processes.
At Trace Financial we have worked with many customers who need to convert between MT and MX format payment messages, for a range of reasons. Some have a desire to take advantage of a new payment infrastructure service. Some want to communicate with correspondent banks and clients who need either MT or MX. Others wish to insulate their own legacy systems from the switchover to the MX format.
The common issue facing these banks is that building – and then maintaining – an in-house solution would involve considerable effort. The official SWIFT MT-MX mapping specifications are complex, and what’s more, they’ve not been updated since they were originally produced several years ago. Meanwhile the individual MT messages have continued to be updated annually, and new versions/variants of MX message types appear from time to time. On top of all of this there are of course plenty of local usage practices and project-specific mapping issues to deal with.
The biggest drawback of any approach based on in-house coding is the difficulty of maintaining it over time. Coding is inherently opaque and hard to read, especially when the original build team has dispersed.
What banks thus require is a cost-effective solution which can easily be customised to meet the needs of their specific projects, and then maintained in line with both business needs and standards updates.
To meet this demand, at Trace Financial we have combined the powerful facilities of our core Transformer product with a comprehensive set of ready-built, easily customised MT-MX Mapping libraries. The core features and the libraries work together to provide the complete solution.
A key general feature of Transformer is that mappings are created using a model-based ‘building blocks’ approach. Users can select from a huge range of ready-made ‘mapping actions’ – including conditional and other control logic – which are selected and dropped into a mapping project to link source to target fields as needed. This approach ensures that the resulting mappings are clear and easy to read, which promotes maintainability.
The MT-MX Mapping library comprises a complete set of such mapping actions, including several special types which we have developed specifically to address the most complex tasks, such as mapping the set of interrelated fields which identify each party to a transaction. We have kept the mappings current by applying all changes to the MT and MX standards.
To further aid readability, in the Transformer GUI the mappings are presented using business-friendly field names rather than technical field tags (though these can easily be made visible if necessary).
These features mean that a non-technical team can easily take our MT-MX Mappings and adapt them to meet the needs of a specific project.
A range of supporting functions are provided to help the user, including a ‘Where Used’ query that identifies where any chosen field appears in the mapping, and Transformer’s ‘Test-As-You-Build’ function which allows mappings to be tested line by line with a single click.
The mapping created within Transformer is deployed as an API callable from Java, .NET, a web service, an Enterprise Service Bus or almost any messaging infrastructure.
We know through experience with customers that Transformer and its MT-MX Mapping libraries represents the most cost-effective, comprehensive and easily maintained solution available today.