The migration to ISO 20022 is one of the biggest changes in international financial messaging. SWIFT completed the MT/MX coexistence period in November 2025, and businesses must adapt their systems. This guide covers the timeline, real-world impacts and steps to make the transition a success.
Why migrate to ISO 20022?
Legacy SWIFT messaging relies on MT (Message Type) formats dating from the 1970s. These text-based messages offer limited, poorly structured fields that make automation, regulatory compliance and fraud prevention difficult.
ISO 20022 brings fundamental improvements:
• Richer data: structured addresses, end-to-end references, detailed remittance information. An MX message can carry 10 times more data than an MT.
• Global interoperability: a single standard for all payment types, currencies and countries.
• Easier automation: the structured XML format enables straight-through processing (STP) without manual intervention.
• Stronger compliance: structured data makes sanctions screening, anti-money laundering (AML) and regulatory reporting more effective.
ISO 20022 brings fundamental improvements:
• Richer data: structured addresses, end-to-end references, detailed remittance information. An MX message can carry 10 times more data than an MT.
• Global interoperability: a single standard for all payment types, currencies and countries.
• Easier automation: the structured XML format enables straight-through processing (STP) without manual intervention.
• Stronger compliance: structured data makes sanctions screening, anti-money laundering (AML) and regulatory reporting more effective.
SWIFT migration timeline
SWIFT planned the migration in several phases:
March 2023: start of coexistence. MX messages (ISO 20022) coexist with MT messages on the SWIFT network. Banks can send in MX and receive in MT (and vice versa) using SWIFT's translation service.
November 2025: end of coexistence for cross-border payments. MT103 (credit transfers) and MT202 (interbank transfers) are replaced by their ISO 20022 equivalents (pacs.008 and pacs.009). Banks must be able to process MX messages natively.
Beyond 2025: progressive extension to other message categories (securities, trade finance, reporting). Remaining MT messages will be phased out gradually.
For European businesses, SEPA has already used ISO 20022 (pain.001, pain.008) since 2014. The SWIFT migration primarily affects international flows outside the euro zone.
March 2023: start of coexistence. MX messages (ISO 20022) coexist with MT messages on the SWIFT network. Banks can send in MX and receive in MT (and vice versa) using SWIFT's translation service.
November 2025: end of coexistence for cross-border payments. MT103 (credit transfers) and MT202 (interbank transfers) are replaced by their ISO 20022 equivalents (pacs.008 and pacs.009). Banks must be able to process MX messages natively.
Beyond 2025: progressive extension to other message categories (securities, trade finance, reporting). Remaining MT messages will be phased out gradually.
For European businesses, SEPA has already used ISO 20022 (pain.001, pain.008) since 2014. The SWIFT migration primarily affects international flows outside the euro zone.
Differences between MT and MX
MT (Message Type) and MX (ISO 20022-based) messages differ fundamentally:
Format: MTs use a proprietary text format with numbered fields (field 20 for reference, field 32A for amount). MX messages use XML with descriptive tags.
Data capacity: an MT103 limits the beneficiary name to 4 lines of 35 characters. A pacs.008 offers structured fields for name, full postal address, country code and LEI identifier.
Addresses: MTs use free-text (unstructured) addresses. ISO 20022 requires structured addresses with separate street, postal code, city and country. This helps sanctions screening but requires updating reference data.
Message mapping:
• MT103 → pacs.008 (customer credit transfer)
• MT202 → pacs.009 (interbank transfer)
• pain.001 stays pain.001 (it was already ISO 20022)
Format: MTs use a proprietary text format with numbered fields (field 20 for reference, field 32A for amount). MX messages use XML with descriptive tags.
Data capacity: an MT103 limits the beneficiary name to 4 lines of 35 characters. A pacs.008 offers structured fields for name, full postal address, country code and LEI identifier.
Addresses: MTs use free-text (unstructured) addresses. ISO 20022 requires structured addresses with separate street, postal code, city and country. This helps sanctions screening but requires updating reference data.
Message mapping:
• MT103 → pacs.008 (customer credit transfer)
• MT202 → pacs.009 (interbank transfer)
• pain.001 stays pain.001 (it was already ISO 20022)
Impact on businesses
The ISO 20022 migration affects several areas:
Payment systems: ERPs, TMS (Treasury Management Systems) and accounting software must be updated to generate and receive ISO 20022 messages. Additional fields (structured addresses, LEI) must be populated.
Databases: beneficiary records must include structured addresses and ideally an LEI identifier. Migrating existing data may require significant cleansing effort.
Reconciliation: end-to-end references (EndToEndId, UETR) enable more precise payment tracking, but matching systems must be adapted to exploit the richer data.
Compliance: enriched data facilitates sanctions screening and reporting, but requires updates to screening engines and filtering rules.
Training: finance, treasury and IT teams need to understand the new formats, required fields and best practices.
Payment systems: ERPs, TMS (Treasury Management Systems) and accounting software must be updated to generate and receive ISO 20022 messages. Additional fields (structured addresses, LEI) must be populated.
Databases: beneficiary records must include structured addresses and ideally an LEI identifier. Migrating existing data may require significant cleansing effort.
Reconciliation: end-to-end references (EndToEndId, UETR) enable more precise payment tracking, but matching systems must be adapted to exploit the richer data.
Compliance: enriched data facilitates sanctions screening and reporting, but requires updates to screening engines and filtering rules.
Training: finance, treasury and IT teams need to understand the new formats, required fields and best practices.
Practical migration steps
Here is a six-step migration plan:
1. Audit current state: inventory all payment flows, formats in use (MT, proprietary, SEPA XML) and systems involved. Identify which flows are affected by the migration.
2. Gap analysis: compare the fields in your current messages with ISO 20022 requirements. Identify missing data (structured addresses, LEI) and necessary adaptations.
3. Update systems: upgrade your ERP, TMS and payment tools to support ISO 20022. Test generation and reception of MX messages.
4. Cleanse data: enrich beneficiary records with structured addresses, up-to-date BICs and required identifiers.
5. Test and validate: run end-to-end tests with your banks. Use an ISO 20022 validator to check file compliance before going live.
6. Go live and monitor: activate new flows in production, monitor rejection rates and fix anomalies. Track pain.002 status reports to catch issues early.
1. Audit current state: inventory all payment flows, formats in use (MT, proprietary, SEPA XML) and systems involved. Identify which flows are affected by the migration.
2. Gap analysis: compare the fields in your current messages with ISO 20022 requirements. Identify missing data (structured addresses, LEI) and necessary adaptations.
3. Update systems: upgrade your ERP, TMS and payment tools to support ISO 20022. Test generation and reception of MX messages.
4. Cleanse data: enrich beneficiary records with structured addresses, up-to-date BICs and required identifiers.
5. Test and validate: run end-to-end tests with your banks. Use an ISO 20022 validator to check file compliance before going live.
6. Go live and monitor: activate new flows in production, monitor rejection rates and fix anomalies. Track pain.002 status reports to catch issues early.
MT103 vs pain.001: what is the difference?
MT103 is the legacy SWIFT message for individual international credit transfers. pain.001 is its ISO 20022 successor for payment initiation on the business side.
In practice:
• pain.001 is the file the business sends to its bank to order transfers. It is already in ISO 20022 format.
• MT103 was the message used between banks on the SWIFT network. It is being replaced by pacs.008.
If your bank accepts pain.001 for international wires (increasingly common), you can use the international transfer generator to create these files. For correspondent banks still using the MT format, the MT103 generator is also available.
In practice:
• pain.001 is the file the business sends to its bank to order transfers. It is already in ISO 20022 format.
• MT103 was the message used between banks on the SWIFT network. It is being replaced by pacs.008.
If your bank accepts pain.001 for international wires (increasingly common), you can use the international transfer generator to create these files. For correspondent banks still using the MT format, the MT103 generator is also available.
Tools to support the migration
Several resources can ease the transition:
• pain.001 generator: create SEPA and international credit transfer files compliant with ISO 20022 directly in your browser, with built-in XSD validation.
• pain.008 generator: produce SEPA direct debit files with full mandate management.
• ISO 20022 validator: check the compliance of your XML files (pain.001, pain.008) before sending them to your bank.
• MT103 generator: for international flows to banks that have not yet migrated, generate MT103 messages in classic text format.
These tools let you test your new ISO 20022 flows, validate your files and manage the coexistence between old and new formats during the transition period.
• pain.001 generator: create SEPA and international credit transfer files compliant with ISO 20022 directly in your browser, with built-in XSD validation.
• pain.008 generator: produce SEPA direct debit files with full mandate management.
• ISO 20022 validator: check the compliance of your XML files (pain.001, pain.008) before sending them to your bank.
• MT103 generator: for international flows to banks that have not yet migrated, generate MT103 messages in classic text format.
These tools let you test your new ISO 20022 flows, validate your files and manage the coexistence between old and new formats during the transition period.