The
deadline for ISO 20022 – the new standard for electronic data interchange between financial institutions – is November 2025. Once fully implemented, ISO 20022 will be a game-changer for the
global payments space; instilling enhanced interoperability, streamlined processing times, richer data, increased accuracy, lower maintenance costs, and even reduced levels of fraud.
Yet, for some institutions, the migration process remains complex and opaque. Here is a list of practical considerations, based on Swift's official guidelines,
for ISO 20022 compliance.
1. Adopt official definitions
First and foremost, Swift advises that banks base their implementation processes around the official message definitions published by the ISO 20022 registration. These can be found in the Catalogue
of Messages. Since these definitions allow for a range of implementations, users are encouraged to consider their own unique needs.
Furthermore, implementers and representatives of communities of users are “welcome to participate in the relevant ISO 20022
Standards Evaluation Groups (SEG), which are in charge of evaluating and approving changes requested to existing message definitions and new versions,”
adds Swift. Such groups enable banks to ensure the requested changes are “justified and are worth the required implementation effort.”
2. Employ valid message instances
One of the benefits of ISO 20022’s extensible markup language (XML) is that the XML schema definition (XSD) permits easy validation of message instances. In line with the advice of Swift, “the XML messages must, among others, be valid against the corresponding
XML schema published in the Catalogue of Messages.” This formatting piece is the cornerstone of the ISO transition.
“Some Market Practice Groups, adoption initiatives or communities of users, may generate and publish XML schemas which look like the original ISO 20022 XML schemas, but are in fact restricted versions of the original schema,”
continues Swift. “If they are constructed in a proper way, in compliance with the original ISO 20022 schemas, these subset schemas can be very useful for the community of users to test that their implementation complies with the restrictions they have agreed.”
This is valuable advice for institutions, which are reassured that Swift will always cross-check ISO 20022 compliance “against the original schemas.”
3. Be aware of the constraints
The constraints of ISO 20022 are outlined as rules and guidelines in the
second part of the Message Definition Report (MDR). All messages and data must be valid against this list.
According to
Swift, “sometimes, the use of a message set is further described in the ISO 20022 Message Usage Guide (MUG).” These guidelines, too, comprise ISO’s official documentation and must be heeded for migration journeys.
4. Use registered code values
In its ISO 20022 implementation compliance
document, Swift underlines a distinction between internal code sets and external codes sets, for message definitions.
“When internal, the possible codes of the code set are included in the XML schema, which makes it mandatory to use these codes to comply…When the code set is external to the schema, the possible codes are listed in the
External Code Sets” document.
These lists are reviewed and maintained quarterly.
5. Mind the business application header
When receiving a message, a bank must ascertain: the identity of the sender and receiver, the purpose of the transaction, a reference, the creation date, the priority, et cetera.
In order to expedite this information-gathering process, ISO’s
technical support group (TSG) created the
Business Application Header (BAH). According to Swift, “The BAH is a separate structure which includes part of the message payload. The BAH has not been adopted consistently across all business areas: most of the securities and FX message sets are designed
to be used with a BAH, while most Payments message sets…were not adapted for the BAH, that is, the preliminary business information that is supposed to be conveyed in the BAH is still present in the message itself.”
The upshot here is that the
Catalogue of Messages contains two kinds of message sets: those intended for use with the BAH and those that include the preliminary business information in the message itself – and therefore do not need BAH. Each business domain – namely securities, payments,
trade, foreign exchange and cards – in the catalogue indicates whether a message set is intended for use with the BAH.
It is vital for banks to note that “BAH is not mandatory and is thus not a prerequisite for achieving ISO 20022 compliance.”
6. Be aware of supplementary data extensions
The “supplementary data” field within ISO 20022 messages enables users to insert information that is not encapsulated by any other component. However, use of this element is subject to
strict rules – ignoring these would lessen a financial institution’s chances of securing rapid compliance.
Swift stresses that “only supplementary data extensions authorised by a SEG.” can be deployed.
Maximising preparedness
Notwithstanding these instructions, there are bonus considerations for banks to weigh up, which stand to maximise preparedness and, in turn, boost ISO 20022 compliance levels.
In the interim between today and the November 2025 deadline – when legacy MT formats are discontinued for good – institutions may also wish to:
- Participate in industry testing;
- Ensure all processes and systems are primed to fulfil sanctions and anti-money laundering (AML) controls;
- Design solutions to make enriched data available for customers; and
- Begin training staff in the new language.
If this advice is followed, financial institutions may embark on their migration journeys with confidence, fully achieve compliance, and – most importantly – modernise their cross-border payments offerings for clients of all shapes and sizes.