The migration to ISO 20022 is one of the biggest changes in international financial messaging. SWIFT ended the MT/MX coexistence period for cross-border payments in November 2025. The deadlines set for November 2026 concern the files businesses send to their banks: older pain versions and, in Germany, the DTAZV format. On 24 September 2026 the Deutsche Kreditwirtschaft suspended that retirement without naming a new date — and as of 25 September 2026 GLS Bank was keeping its own; we have no information on other institutions. This guide, updated on 25 September 2026, covers the timeline, the 2026 deadlines, the real-world impact and the 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. According to SWIFT, more than 98% of payment instructions are now sent in ISO 20022.
November 2026, postponed: SWIFT had planned to require structured postal addresses in ISO 20022 payment messages with its 2026 standards release. On 27 August 2026 it announced that it would defer all payments changes of that release, with an update on the structured address requirement by December 2026 at the latest.
For European businesses, SEPA has already used ISO 20022 (pain.001, pain.008) since 2014. The files businesses send to their own bank follow their own calendar: see the 2026 deadlines below.
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. According to SWIFT, more than 98% of payment instructions are now sent in ISO 20022.
November 2026, postponed: SWIFT had planned to require structured postal addresses in ISO 20022 payment messages with its 2026 standards release. On 27 August 2026 it announced that it would defer all payments changes of that release, with an update on the structured address requirement by December 2026 at the latest.
For European businesses, SEPA has already used ISO 20022 (pain.001, pain.008) since 2014. The files businesses send to their own bank follow their own calendar: see the 2026 deadlines below.
2026 deadlines for payment files
Checked on 25 September 2026. Each bank sets its own cut-off day, so confirm the date with yours.
• Germany, 24.09.2026, suspension: the DK suspended the retirement planned for November 2026 of the legacy formats for SEPA payments, foreign payments and same-day euro payments, and keeps operating those formats temporarily; since 24 September 2026 the lifecycle page carries the notice „Vorübergehend weiter verwendbar“ (temporarily still usable), with no new end date named. The new end dates will follow those of SWIFT and the EPC. The bank dates below still apply unless the bank changes them itself.
• Germany, 14.11.2026 at 00:01: GLS Bank no longer accepts versions older than pain.001.001.09 (credit transfers) and pain.008.001.08 (direct debits), so neither pain.001.001.03 nor pain.008.001.02, and no longer accepts DTAZV files for foreign payments. The format lifecycle of the Deutsche Kreditwirtschaft (DK), the joint committee of the German banking associations, gave only the month, 11/2026, and left the exact day to each bank; since 24 September 2026 the notice „Vorübergehend weiter verwendbar“ applies there and no new end date is named. The GLS page was unchanged on 25 September 2026.
• Germany, 15.11.2026: version 26.11 of the DK's Appendix 3 applies. According to it, DTAZV is phased out as a DK standard in November 2026, and foreign payments are then submitted only as pain.001.001.09 (EBICS order type AXZ). GLS names 01.12.2026 as the end of DTAZV support in the DK; the DK's own documents do not give that date, they say November 2026 or 15.11.2026. Details in our guide to the DTAZV replacement.
• SEPA addresses, 15.11.2026, postponed: the EPC guidance on addresses (EPC153-22 v2.1) set 15.11.2026 as the end of unstructured addresses in the EPC payment schemes, judged on the execution or collection date. An older document, the SDD implementation guidelines 2025 v1.0, gave 22.11.2026. On 10 September 2026, the EPC announced that it is delaying this end date (decision of 9 September) and plans to set a new one in October 2026. In Germany, ebics.de stated on 22 September 2026 that orders in DTAZV or in the 2009 pain versions could no longer be forwarded as a matter of course from 15.11.2026, and that a structured address with at least town and country is a basic requirement; we have not re-confirmed that after the suspension of 24 September 2026.
• Netherlands: the Dutch Payments Association (Betaalvereniging) announced the end of unstructured addresses for 14.11.2026 (non-SEPA payments) and 15.11.2026 (SEPA payments). This concerns addresses, not the pain version. On 22.09.2026 its page did not mention the EPC delay: check with your bank.
• In the files: the 2019 versions pain.001.001.09 and pain.008.001.08 replace pain.001.001.03 and pain.008.001.02. In pain.001, among other changes, the namespace changes, BIC becomes BICFI, and the requested execution date moves into a Dt element.
Sources: GLS Bank, DK, Appendix 3 V26.11, DK notice on ebics.de, EPC153-22 v2.1, EPC, 10.09.2026, SWIFT, 27.08.2026, Betaalvereniging.
• Germany, 24.09.2026, suspension: the DK suspended the retirement planned for November 2026 of the legacy formats for SEPA payments, foreign payments and same-day euro payments, and keeps operating those formats temporarily; since 24 September 2026 the lifecycle page carries the notice „Vorübergehend weiter verwendbar“ (temporarily still usable), with no new end date named. The new end dates will follow those of SWIFT and the EPC. The bank dates below still apply unless the bank changes them itself.
• Germany, 14.11.2026 at 00:01: GLS Bank no longer accepts versions older than pain.001.001.09 (credit transfers) and pain.008.001.08 (direct debits), so neither pain.001.001.03 nor pain.008.001.02, and no longer accepts DTAZV files for foreign payments. The format lifecycle of the Deutsche Kreditwirtschaft (DK), the joint committee of the German banking associations, gave only the month, 11/2026, and left the exact day to each bank; since 24 September 2026 the notice „Vorübergehend weiter verwendbar“ applies there and no new end date is named. The GLS page was unchanged on 25 September 2026.
• Germany, 15.11.2026: version 26.11 of the DK's Appendix 3 applies. According to it, DTAZV is phased out as a DK standard in November 2026, and foreign payments are then submitted only as pain.001.001.09 (EBICS order type AXZ). GLS names 01.12.2026 as the end of DTAZV support in the DK; the DK's own documents do not give that date, they say November 2026 or 15.11.2026. Details in our guide to the DTAZV replacement.
• SEPA addresses, 15.11.2026, postponed: the EPC guidance on addresses (EPC153-22 v2.1) set 15.11.2026 as the end of unstructured addresses in the EPC payment schemes, judged on the execution or collection date. An older document, the SDD implementation guidelines 2025 v1.0, gave 22.11.2026. On 10 September 2026, the EPC announced that it is delaying this end date (decision of 9 September) and plans to set a new one in October 2026. In Germany, ebics.de stated on 22 September 2026 that orders in DTAZV or in the 2009 pain versions could no longer be forwarded as a matter of course from 15.11.2026, and that a structured address with at least town and country is a basic requirement; we have not re-confirmed that after the suspension of 24 September 2026.
• Netherlands: the Dutch Payments Association (Betaalvereniging) announced the end of unstructured addresses for 14.11.2026 (non-SEPA payments) and 15.11.2026 (SEPA payments). This concerns addresses, not the pain version. On 22.09.2026 its page did not mention the EPC delay: check with your bank.
• In the files: the 2019 versions pain.001.001.09 and pain.008.001.08 replace pain.001.001.03 and pain.008.001.02. In pain.001, among other changes, the namespace changes, BIC becomes BICFI, and the requested execution date moves into a Dt element.
Sources: GLS Bank, DK, Appendix 3 V26.11, DK notice on ebics.de, EPC153-22 v2.1, EPC, 10.09.2026, SWIFT, 27.08.2026, Betaalvereniging.
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), but its version changes: see the 2026 deadlines above
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), but its version changes: see the 2026 deadlines above
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 your files against the ISO 20022 schema before going live. It does not check your bank's own rules, such as the German DK profiles, so the test with your bank remains essential.
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 your files against the ISO 20022 schema before going live. It does not check your bank's own rules, such as the German DK profiles, so the test with your bank remains essential.
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.
Your bank decides whether it accepts pain.001 for international wires. In Germany, pain.001.001.09 becomes the only file format for foreign payments: it replaces the DTAZV format — the DK suspended the November deadline on 24 September 2026, and banks may keep their own (see our DTAZV guide). To create these files, use the international transfer generator. 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.
Your bank decides whether it accepts pain.001 for international wires. In Germany, pain.001.001.09 becomes the only file format for foreign payments: it replaces the DTAZV format — the DK suspended the November deadline on 24 September 2026, and banks may keep their own (see our DTAZV guide). To create these files, use the international transfer generator. 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 online, without installation, with built-in XSD validation. Banking data is processed in memory and never stored on our servers.
• pain.008 generator: produce SEPA direct debit files in pain.008.001.08, with pain.008.001.02 still selectable.
• ISO 20022 validator: check your XML files (pain.001, pain.008) against the ISO 20022 schema before sending them to your bank. It does not check bank-specific profiles such as those of the German DK.
• 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 online, without installation, with built-in XSD validation. Banking data is processed in memory and never stored on our servers.
• pain.008 generator: produce SEPA direct debit files in pain.008.001.08, with pain.008.001.02 still selectable.
• ISO 20022 validator: check your XML files (pain.001, pain.008) against the ISO 20022 schema before sending them to your bank. It does not check bank-specific profiles such as those of the German DK.
• 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.