What now? ISO 20022 deadlines in 2026 and beyond

Here’s everything you need to know about ISO 20022 for the foreseeable.

Home ◥ Insights ◥ What now? ISO 20022 deadlines in 2026 onwards

20 min read

And here we are. The end of coexistence.

Swift has now ended support for MT payment-instruction messages, marking the end of the transition that began in March 2023.

But if you thought your ISO 20022 migration was over, you’d be mistaken. That milestone was just the beginning. A wave of new deadlines is approaching, and there are major changes afoot for structured addresses and Exceptions and Investigations (E&I) handling.

So, what’s happening?

Swift has published a detailed roadmap that goes beyond payment instructions and E&I. For the first time, it provides retirement dates for nearly all remaining non-instruction message types. This marks a significant step forward in the industry’s transition to ISO 20022.

Here, we break down each step of your ISO 20022 project for 2026 and beyond, and outline exactly what you need to do.

Where are we now? November 2025

From this point on, all outgoing MT payment instructions (MT103, MT200, MT202, etc.) are subject to Swift’s new contingency FIN validation.

If an MT message fails validation, it will be rejected (NAK’d), requiring manual intervention to repair and resend.

If it passes, Swift will auto-convert it to ISO 20022 on FINplus and flag it as “converted.” However, this converted message may lack full rich data, potentially disrupting compliance checks and straight-through processing.

Banks must, by now, have upgraded all relevant systems—screening, routing, reconciliation, and core banking interfaces—to handle incoming ISO 20022 (MX) messages or embedded MT formats. Your end-to-end testing in FINplus pilot/future mode should have been completed well ahead of go-live.

Swift will introduce contingency and in-flow translation fees starting in 2026. If you haven’t met the deadline, you should plan for these costs and actively monitor converted-message flags to manage the impact.

Contingency conversion processing*: Swift Contingency Processing acts as a temporary translator for banks still using legacy MT messages. Outgoing MT payments are automatically converted to ISO20022 (MX) format before leaving the network, while incoming MX messages are returned in MT layout if the receiver’s systems can’t read them—both services incur a conversion fee.

Removed**: Messages are not eligible for Swift’s MT→MX contingency conversion and will be immediately rejected with a negative acknowledgement (NAK).

Note: Banks must stop sending MT102/STP, MT103 REMIT, MT201, and MT203 messages over interbank FIN channels. These flows must be switched to ISO 20022 formats.

What’s next? November 2026

Next up are MT101 messages, which will be nixed by November 2026. After this date:

Multi-instruction MT101s will be rejected (NAKed).

Single-instruction MT101s will be auto-converted to pain.001 under Swift’s contingency process—this will trigger additional FIN validation and translation fees.

To get ready, you’ll need to review and revise business agreements to support ISO 20022 (pain.001) message exchange.

Then, sign up for FINplus and set up RMA (Relationship Management Application) for pain.001 messaging. Make sure your systems can generate, process, and reconcile pain.001 messages effectively.

You’ll need to engage in testing for both MT101 and pain.001 to ensure readiness and smooth transition.

Modify interfaces to support pain.001/pain.002 formats and ensure MT101 relationships are bootstrapped under the Request-for-Transfer Rulebook.

And plan for automatic RMA bootstrapping in 2026 and phase out bilateral MT199/299 flows in favor of admi.024 / camt.025 messages.

Removed**: Messages are not eligible for Swift’s MT→MX contingency conversion and will be immediately rejected with a negative acknowledgement (NAK).

ISO 20022 structured addresses

Now, alongside this, you’ll need to use more structured address formats as unstructured addresses are phased out.

So, starting with Swift Standard Release (SR) 2025 in November 2025, a new Hybrid Postal Address format will be introduced.This format combines structured fields (like Town Name and Country) with up to two unstructured address lines (the structured address format does not contain any unstructured lines)

You’ll have one year to complete the transition. At which point, unstructured addresses will disappear.

Key dates:

SR 2025 (Nov 2025): Hybrid format becomes available.

Grace Period (Nov 2025 – Nov 2026): Structured, hybrid, and unstructured formats are accepted.

SR 2026 (Nov 2026): Unstructured-only addresses will be rejected (NAKed).

So, what do you need to do?

Start by upgrading your core systems. That means modifying customer master data, and onboarding systems to support only structured or hybrid postal addresses from SR 2026. It’s important to ensure that your inbound traffic using hybrid formats is accepted and validated. Because, well, you’re going to start receiving them.

Then, cleanse your customer and counterparty address data. This, again, is important. You also need to convert legacy unstructured address records into structured or hybrid formats. Do not underestimate how big a task this will be. AI can help with reformatting, but you’ll still need to validate the results and enrich address data to meet ISO 20022 field requirements.

Then, it’s time for industry-wide testing and readiness checks. That will mean coordinating with enterprise resource planning (ERP) and treasury management system (TMS) vendors and correspondent banks to check everything is compatible.

But what if your customers don’t upgrade their ERP systems? What then?

You may need to offer a conversion service. One that accepts unstructured addresses during the grace period and maps them internally to hybrid or structured formats before sending to Swift. Middleware or internal translation layers can help integrate structured data with downstream systems that are not yet upgraded.

And, as always, keep an eye on regulatory expectations. Regulators and correspondent banks will increasingly rely on ISO 20022 data richness (for example, unique end-to-end transaction references and structured addresses) to assess Anti-money Laundering (AML) and sanctions risk. Poor data quality may lead to blocked or de-risked payments.

After that? November 2027

What’s next?

Well, alongside this, the handling of Exceptions and Investigations is undergoing big changes. MT messages are making way for camt.110/111 and camt.029/056. Swift has introduced Case Management 2.0 – a product to support it. And the migration is already underway.

So, what do you need to do to get ready?

First, implement a case management workflow. That means setting up FINplus Case Management and making sure you can process camt.110, camt.111, camt.056, and camt.029 messages before November 2027.

Then, make sure you have mandatory cancellation messaging set up. You must be ready to exchange payment cancellation messages via Case Management (SRP) over FIN/FINplus by November 2026.

You’ll want to map internal workflows. That is, identify and convert all internal E&I processes that rely on MT n95/n96/n98/n99 to ISO 20022 equivalents (these will primarily be camt.110 and camt.111).

Then, you can stop using legacy MTs for E&I. Permanently discontinue the use of MT195/295 and MT199/299/999 for enquiry and investigation purposes.

At this stage, you can move your bilateral/free-format MT199/299 traffic to admi.024. This must be done by November 2027. Swift will run an automatic RMA (Relationship Management Application) bootstrap in November 2026 to enforce mandatory receipt status. In other words, they’ll automatically switch on the permissions you need so you can receive the new messages.

You must adopt ancillary messages like pain.002, camt.029, and camt.055 is used in payment initiation and response flows. Align your data models by ensuring message identifiers, case references, and reconciliation logic are aligned with the ISO20022 data model. Update your compliance systems by revising sanctions screening, fraud monitoring, and AML rulesets. And complete bilateral initiation agreements for initiation flows by November 2027.

Removed*: Messages are not eligible for Swift’s MT→MX contingency conversion and will be immediately rejected with a negative acknowledgement (NAK).

Retired**: Not removed, but should no longer be used for its current purpose (e.g. E&I/SRP)

Down the line? November 2028

And in 2028? Swift is phasing out MT messages for statements, direct debits and charges and replacing them with ISO 20022 versions between 2027 and 2028. Many MT9xx statement messages (like MT940, MT942, MT950 and MT900/910) will be removed and replaced by camt.052, camt.053, camt.054 and other ISO 20022 formats.

It is important to note: you must be able to receive these ISO messages by November 2027. Swift will not provide MT-to-ISO conversion.

Direct debit messages such as MT104, MT107 and MT204 are also being retired in favor of ISO messages like pain.008, pacs.003 and pacs.010.

And Charges messages (MT190/191/290/291/990/991) will be replaced by camt.105 and camt.106, which provide clearer, structured fee information and support automated reconciliation.

What do you need to do?

Don’t wait for 2028. Although the end of coexistence for Statement and Reporting messages is planned for SR 2028, you must be ready to receive these messages in ISO20022 format by November 2027. Swift will automatically bootstrap MT9xx relationships based on traffic, but you must coordinate with your counterparties to align formatting and reconciliation.

Swift will not convert MT9xx messages to ISO20022 camt.xxx formats. Full migration depends on community adoption.

In other words, Swift cannot enforce the end of coexistence until banks adopt ISO 20022 for statement and reporting messages. If you do not migrate, you may still send or expect MT9xx messages, so bilateral processing could continue temporarily (2027 to 2028). Full adoption relies on community readiness, not automatic conversion by Swift.

So, build ISO20022 capabilities. You should develop the ability to generate and reconcile camt.052, camt.053, camt.054, camt.057, camt.060, and camt.058 statements. Format agreements with counterparties should be finalized well before November 2027.

And then plan for the direct debit and charges migration. You must track the development of camt.106 (expected in SR 2026) and schedule migration projects for direct-debit, margin-collection, and charges messages to be completed by SR 2028.

Removed*: Messages are not eligible for Swift’s MT→MX contingency conversion and will be immediately rejected with a negative acknowledgement (NAK).

Retired**: Not removed, but should no longer be used for its current purpose (e.g. E&I/SRP).

Supported until further notice

Finally, there are a handful of MT messages that will be supported until we’re told otherwise. For tracker related messages you should replace MT-based tracker updates with trck messages or Swift APIs. This ensures continued support for tracking capabilities and avoids disruption in gpi services.

Deprecated*: Swift discourages the use of tracker-notification MT messages beyond 2026 because they are deprecated and will be phased out in future releases.

A long road ahead

So there you have it. The end of coexistence is by no means the end of your ISO 20022 migration. There is plenty more fun to come.

As the CBPR+ roadmap rolls out, you must treat the coming years as a countdown. Retirement dates are now defined for nearly all MT message types. The margin for delay is shrinking.

Success will depend on early engagement with everyone around you. Many of these transitions rely on bilateral agreements rather than enforced network changes.

To avoid mishaps and headaches, you must incorporate these phased deadlines into internal dashboards, monitor message flags, and prepare systems for ISO 20022 end-to-end.

The clock is ticking. Do not wait for the deadlines. If you haven’t started by now, you’re already behind.