Cross-border payments between financial institutions via SWIFT are currently transitioning to ISO 20022. This transition is set to conclude in November 2025 when the coexistence period between the legacy MT messages and the new ISO 20022-standard MX messages will end, and all messages must travel in the MX format. The migration from legacy MT messages to the new MX standard promises numerous benefits, including better data quality, improved straight-through processing (STP), end-to-end data transmission, and extended remittance information. Moreover, the ongoing migration of other payment systems to this same standard will (eventually) reduce the barriers and inefficiencies of moving payments between different payment rails. To achieve these benefits, banks will have to navigate around a variety of challenges unique to their jurisdiction, correspondents, and infrastructure. However, one issue common to most banks is the challenge of payment capture and structured data: how to move to structured data capture across multiple platforms and what to do with legacy instructions in the unstructured MT format.
The SWIFT Payments Market Practice Group defines structured data as “data that is logically specified in dedicated data elements whereby it is clearly documented what element includes which data.” ISO 20022 mandates structured data, specifying precise types and formats to ensure consistency and clarity in payment messages. This is a welcome improvement over traditional MT payment capture which asks end users for broad information elements such as “address” without defining, ordering or validating the various pieces of information that together comprise an address.
A comparison of Beneficiary Customer information in legacy MT format with the equivalent Creditor information in MX format illustrates the difference between unstructured and structured payment data. Consider the same payee information, excluding account numbers, in MT format (below, top) and MX format (below, bottom):
The elements of the MX message are discrete and straightforward, making them both human and machine-readable, which enhances accuracy and efficiency in processing. Some fields require predetermined inputs such as country codes and the available length and character types vary according to the data being captured. Every necessary element of payee information has its own tag and only necessary information is collected. The MT format lacks many of these features. The unlettered version shown here incorporates some structuring with the arrangement of the address data and placement of the country code separated by slashes but this modest attempt at structuring requires a diligent and informed user. Even with such users, errors are more common and, errors aside, automated processing of MT instructions, as SWIFT itself points out, often fails because the unstructured data cannot be properly understood out of context.
Despite these limitations, many financial institutions have payment capture interfaces for both staff and clients that were built specifically for the MT format. Even without the imperative of ISO 20022 transition, there are compelling UX and data integrity reasons to prefer the structured format. Staff and clients are now long accustomed to structured data in web forms, contact managers, and mobile apps. Accounting and ERP systems that hold payee data also commonly use structured formats—indeed, structured data is preferred for accounting and CRM applications. Whether users enter payee information manually or link to another platform, structured data reduces time, confusion, transcription steps and errors while increasing interoperability. Even without new standards, evolving technology and user expectations are already pushing banks towards structured data capture and harmonization with external systems.
Structured data is not only more meaningful and useful but also enhances efficiency and user familiarity, making it a necessity for modern banking. With the advent of ISO 20022, it’s also inevitable. Hundreds of millions, likely billions, of unstructured settlement instructions sit on bank systems today and this number is growing. Banks must determine the urgency of meeting ISO 20022 requirements, prioritize specific systems and workflows, and decide on changes to payment capture interfaces while addressing legacy instructions. Translation, AI and other services are available to smooth the transition but the original problem remains: how to move to structured data capture and assist in the wider project of migrating to ISO 20022 compliance across the enterprise?
These two requirements: structured data capture of payment instructions and assisting with the larger project of ISO 20022 compliance imply a number of capabilities be available at the point of capture. These include:
- A complete and growing selection of required fields across all jurisdictions.
- The ability to operate simultaneously in the MX and/or MT formats as required by downstream systems and counterparties.
- Capable of linking or otherwise ensuring fidelity between the MX and MT versions of a single instruction through any updates or amendments.
- The ability to recognize the appropriate message format for different channels or uses.
- Be able to provide users with tools to recognize and update legacy instructions prior to submission.
Collectively, these capabilities allow a bank to address the immediate needs of payment capture for new instructions and the large backlog of existing instructions while assisting with the larger project of compliance throughout the enterprise and the ongoing project of realizing the promised benefits of ISO 20022 for banks and clients alike. smartTrade’s Commercial Banking and Payments platform offers a leading FX and payments experience, with robust ISO-20022 compliant payment capture and instruction management, supporting your ISO journey at every stage.