ISO 20022 Migration Is Done for Banks, Not Treasury

On November 22, 2025, SWIFT closed the coexistence period between the old MT message formats and ISO 20022. Every cross-border payment instruction between banks now moves as ISO 20022 (MX) data, meaning the MT103 and MT202 formats that carried international payments for decades are gone.

For banks, that's the finish line on a five-year, budget-heavy migration. For corporate treasury teams, almost nothing looks different. And that gap is exactly the problem.

What the ISO 20022 Migration Actually Changed

The November 2025 deadline applied specifically to payment instructions moving between banks. It didn't touch the bank statements treasury teams work with every day. MT940 (end-of-day statements) and MT942 (intraday reports) are still running fine on SWIFT's network, which is precisely why most treasury teams felt zero disruption and assumed the ISO 20022 migration was a bank-side issue that didn't concern them.

That's half right, and half wrong in a very important way.

The payment data now arriving at banks is richer and more structured than anything the old format could carry. But if your treasury system is still pulling MT940 statements, as most still are, you're only seeing a stripped-down summary of what's actually there. The richer data exists, but your systems just aren't reading it.

There's also a second deadline coming that raises the stakes. From November 14, 2026, structured postal addresses become mandatory on cross-border payments under the CBPR+ standard and freeform address text gets rejected outright. That's the point where the ISO 20022 migration stops being a back-office data question and starts causing failed payments.

ISO 20022 for Corporates: What's Actually Different

For most corporates, ISO 20022 has quietly meant ‘check your remittance fields’ and move on. That undersells what changed.

MT940 has run corporate bank reconciliation for decades. It's plain text, with roughly 20 usable data fields. Its replacement, camt.053, supports nearly 1,600 possible XML tags. That gap looks bigger on paper than it plays out in practice, as not every tag gets used on every transaction, but it reflects a real structural ceiling. The MT940 field carrying payment narrative is unstructured free text, and every bank fills it in differently. Bank with eight institutions, and you're reading eight dialects of the same field.

camt.053 replaces that free text with dedicated fields, with invoice numbers, references, FX rates, and transaction codes each getting their own slot instead of being crammed into one messy string. The current version of camt.053 supports up to 9,000 characters of structured remittance detail per transaction, against a practical ceiling of around 140 characters in MT940.

That’s important because structured fields let systems match a payment to an invoice automatically. A narrative string can't reliably do that, so someone still has to read it and match it by hand. Corporates that have fully adopted camt.053 report meaningfully higher auto-match rates than those still parsing MT940 text, though the benefit only shows up when both sides of the transaction send structured data properly and your own system can actually read it. That second condition is where most treasury teams currently fall short.

Why Treasury Hasn't Caught Up With the ISO 20022 Migration

This was run and funded as a bank compliance project, and treasury teams were largely bystanders. The guidance most corporates received amounted to, ‘your bank will handle it, your payments will keep flowing, watch for remittance field changes.’ True, as far as it went.

What it missed is that the migration created two tiers of banks. Some invested in native ISO 20022 processing and now generate camt.053 statements carrying the full structured payload. Others hit the November 2025 deadline by converting incoming MX data back into MT-style data behind the scenes. For the latter, what lands in your inbox is technically camt.053, but it's really an MT940 wearing an XML wrapper.

Asking your bank "do you support camt.053?" isn't enough on its own, you can get an honest yes and still receive thin data. The better question is whether the camt.053 you're receiving is generated natively, or converted from MT-equivalent inputs.

The second barrier sits on the treasury side. Not every TMS or ERP can properly parse camt.053 XML, handle the different schema versions in circulation (camt.053.001.02 through .08), and surface the richer fields somewhere useful. Many treasury teams default to MT940 simply because that's what their system was configured to consume when it was implemented, and revisiting your bank statement format isn't the kind of project that gets prioritised until something breaks.

Nothing has broken yet. The upgrade has just been sitting there, unclaimed.

What the Data Gap Actually Costs

This cost rarely shows up as a line item. It shows up as reconciliation overhead such as manual matching, exception queues, payment investigation tickets and as a ceiling on how accurate your cash forecasting can get.

Reconciliation

When a payment arrives with a structured reference matching an invoice number, the match happens automatically. When it arrives as "PAYMT REF 12345/INV/GOODS" in a free-text field, someone has to work it out by hand. Across hundreds of transactions a day, that adds up.

Forecasting

camt.053's structured transaction codes, purpose codes, and counterparty data support far more granular cash flow categorisation than MT940 ever could. MT940 is fine for gross cash position visibility, but it's not enough for the kind of transaction-level detail that drives accurate short-term forecasting or feeds AI-assisted analysis.

That last point is the one most treasury teams miss, that the current push toward AI in treasury depends entirely on clean, structured transaction data as its foundation. MT940 was never built to be that foundation. camt.053, implemented properly, is.

Structured Addresses: The Next ISO 20022 Deadline

The structured address mandate is a different kind of pressure than the 2025 deadline. From November 14, 2026, cross-border CBPR+ messages carrying unstructured addresses get rejected outright. The current grace period, which allows hybrid addresses (town and country in structured fields, the rest freeform), runs out on that date.

For corporates, the practical impact depends on how you initiate cross-border payments. If you're sending payment instructions through SWIFT's FINplus service or bank connectivity that runs through CBPR+ validation, your payment data needs structured address fields in place by November 2026. If your systems are still passing incomplete counterparty address data, you're heading toward rejected payments.

This is the deadline that turns ‘we'll get to it eventually’ into ‘our payments stopped working.’ A treasurer can defer camt.053 adoption while reconciliation is manual but functional. It's much harder to defer structured address compliance when the alternative is a failed payment.

Completing the ISO 20022 Migration on the Treasury Side

Three practical steps close the gap for treasury teams:

1. Confirm what you're actually receiving. For each banking relationship, check whether you're getting MT940, camt.053, or camt.052 (intraday). If it's camt.053, ask whether your bank generates it natively or converts it from MT-equivalent data. Most banks will answer this directly, and many are actively encouraging clients toward camt formats already.

2. Check whether your systems can use it. Your TMS or ERP needs to parse the camt.053 schema in whichever version your banks send, normalise it into your internal transaction model, and surface structured remittance fields where you'll actually use them. For most enterprise platforms this is a configuration and mapping exercise, not a rebuild. It mainly needs treasury, finance, and IT working from the same page.

3. Send structured data on outbound payments too. The reconciliation benefit runs both ways. If your own payment instructions carry structured references matching your AR invoice numbers, your counterparties' reconciliation improves, and so does the usefulness of your own payment confirmations.

This is exactly where Trovata's multibank connectivity fits, pulling in camt.053 files from multiple banks (each potentially on a different schema version, with different levels of underlying richness) and normalising the structured data into something consistent enough to use for cash positioning, reconciliation, and forecasting.

The Window Is Open Now

Banks have done the hard part. The richer data is already flowing as camt.053 can carry invoice-level detail, structured counterparty identification, and transaction metadata that MT940 was never designed to hold. The open question is whether treasury teams are actually collecting it.

The November 2026 structured address mandate gives you a concrete deadline to work backward from. Treat the ISO 20022 migration as an IT compliance checkbox, and you'll end up compliant and no better off. Treat it as the moment to finally connect your bank feeds, your systems, and your outbound payment data properly, and you'll start 2027 with fundamentally better treasury data than you have today.

The pipes are already there. It's just a question of whether anyone picks up what's flowing through them.

Trovata connects to your banks, normalises whatever format they send and surfaces the structured data your team's been missing without a system migration. If you want to see how that works with your own banks, book a demo.