The coexistence period for MT and ISO 20022 cross-border payment instructions ended on 22 November 2025. Adoption ramped hard into the deadline: RedCompass Labs put ISO-originated payment instructions at 32.9% in December 2024 and 44.2% in June 2025, before the cutover made the question moot for in-scope SWIFT flows. Most corporates experienced this as a format project, run by their banks and their TMS vendor, with success defined as payments still going out the door.
That definition is too low. The migration replaced sparse MT content with structured data: purpose codes, defined party fields, structured addresses, and remittance information broken into machine-readable elements instead of a free-text blob. A payment format that carries the invoice number in a defined field, rather than somewhere in 140 characters of text, changes what you can automate downstream. The teams getting a return on the migration are the ones treating ISO 20022 as a data layer for reconciliation, exception handling, and payment analytics, and the window to build that layer is now, while the message content is fresh and the internal attention still exists.
Calling the migration finished is also inaccurate. The instruction-format cutover happened, but reporting and exception messages continue well beyond it, CBPR+ address requirements tighten in November 2026, and the CPMI has encouraged the industry to operationalise its harmonisation requirements by end-2027. What ended in November 2025 was coexistence, not the work.
Which messages carry the value
Four message types do most of the operational work, and they map to different problems.
- pain.001 is your outbound instruction. This is where your own data discipline lives: if your AP process populates structured remittance and a stable end-to-end ID here, everything downstream gets easier. If it does not, no amount of bank-side ISO 20022 will save the reconciliation.
- pacs.008 is the FI-to-FI leg. You never touch it directly, but the data you supplied in pain.001 travels through it, which is why truncation and mapping behaviour at your banks is worth testing rather than assuming.
- camt.052 is intraday reporting. It turns cash positioning from a morning ritual into a continuous feed, and it is the input that makes same-day exception detection possible.
- camt.053 is the end-of-day statement: the backbone for reconciliation, GL posting, and open-item clearing, now with structured references that a matching engine can actually use.
The asymmetry matters. Instructions had a hard deadline; the camt reporting and exception messages continue as the operational surface where treasury actually lives. Post-cutover, that surface is where the investment should go.
Reconciliation is the first payoff
The most repeated operational benefit in practitioner commentary, and the one we see confirmed in projects, is auto-matching. Structured remittance in pain.001, echoed back in camt.053 and camt.052, lets you match bank credits to open invoices deterministically instead of probabilistically. Every deterministic match is a manual touch removed and an exception that never existed.
The gains depend on one unglamorous thing: reference discipline across the whole chain, pain.001 through pacs.008 to camt.053. An end-to-end ID that your ERP generates, your bank preserves, and your statement returns is the spine of automated matching. Weak reference governance, where different systems mint their own identifiers or banks truncate what you send, breaks auto-match regardless of how structured the format is. Before investing in smarter matching logic, audit reference survival: take a sample of payments and trace whether the identifiers you sent came back intact. The result is often sobering, and fixing it is cheaper than any software.
Where references survive, the residual matching problem gets small enough that machine learning on the leftovers becomes worthwhile rather than a crutch for bad data.
Exceptions get a data upgrade
Payments still fail after the migration. Formatting issues, address validation, missing or malformed party data: the failure modes changed shape rather than disappearing. What changed is the quality of the evidence. A structured reject tells you which element failed and why, which makes two things possible.
First, repair automation. A large share of rejects are formatting problems that a rules engine can fix and resubmit without a human, and structured error context is what makes those rules safe to write. Second, better routing: exceptions that need investigation can be classified and sent to the right queue with the context attached, instead of an analyst re-keying references into a bank portal to find out what happened. The camt-based exception and investigation messages continue past the coexistence end precisely because this workflow is permanent.
The practical build is a small taxonomy of reject reasons mapped to actions: auto-repair, route to team X, or escalate to the bank. Measure the repair rate and the touch time per exception, because those are the numbers that justify the work.
Mining the messages
Once the structured data is landing somewhere queryable, a set of questions becomes cheap to answer that used to require a project each: straight-through processing rates by bank and by payment type, reject and repair rates over time, which banks truncate your remittance data, investigation-related charges, cash concentration timing, and invoice-matching performance by counterparty. None of this is exotic analytics. It is ordinary reporting on data that finally exists in usable form, and it gives treasury an evidence base for bank negotiations that used to be anecdote.
The prerequisite is storage: keep the full message content, not the flattened extract your ERP integration happens to consume. Schemas evolve and questions change; the raw camt and pacs payloads are cheap to retain and expensive to reconstruct.
The operational reality
The costs are real and worth naming. Normalisation is the biggest: banks implement camt and pacs variants differently, and mapping each bank’s dialect into consistent internal fields is ongoing maintenance, not a one-off. Some counterparties and institutions still run conversion layers or contingency processing, which reintroduces truncation and latency exactly where you thought the migration had removed it. Legacy ERP schemas often cannot hold the richer content, which is why the landing layer belongs outside the ERP.
Two dates should be on the plan. Unstructured addresses become non-compliant under CBPR+ in November 2026, which makes counterparty address cleanup a funded project rather than a hygiene aspiration. And CPMI’s end-2027 harmonisation horizon signals that message usage rules will keep tightening, so build the mapping layer expecting change.
Finally, keep the audit trail. Every auto-matched receipt and every auto-repaired payment is a decision your system made; store the message content and the rule version that produced it. When an auditor or a counterparty disputes a posting, the structured data that enabled the automation is also what lets you defend it.
FAQ
Do we need to change our ERP to benefit from richer remittance data?
Usually not the ERP core, but you do need somewhere to land the full structured payload before it gets truncated into legacy fields. The common pattern is a payment data store that keeps the complete camt and pacs content, with a mapping layer that feeds the ERP what it can hold. Truncating at ingestion is the mistake, because you cannot recover fields you never stored, and the reconciliation and analytics value lives in exactly those fields.
Our banks all send camt.053 now. Why is our auto-match rate still flat?
Format adoption and data quality are different things. Banks populate the same schema differently, some still pass remittance as unstructured text inside a structured envelope, and your own pain.001 files may not be carrying invoice references in the structured elements to begin with. Audit what is actually in the messages end to end before blaming the matching engine; in our experience the gap is usually upstream reference discipline, not the parser.
Is there another deadline after the November 2025 cutover?
Yes. Under CBPR+, unstructured address data becomes non-compliant in November 2026, so structured or hybrid addresses are the next forced cleanup. Treating it as a data-quality project on counterparty master data now is far cheaper than repairing rejected payments later, and the same cleanup improves sanctions screening precision as a side effect.