SWIFT ISO 20022 and CBPR+, after the coexistence window closed

The timeline, and where it left banks

• March 2023: coexistence begins on the SWIFT network. Banks may send MT or MX for cross border payments and reporting.
• Through 2023 and 2024: major market infrastructures migrate, and enhanced data becomes normal on domestic rails in several jurisdictions.
• November 2025: the coexistence window for cross border payments and reporting categories closes on FIN.
• After: MX is the network standard for those flows, while MT persists in domestic schemes, internal interfaces, older bilateral arrangements and every archive you own.

What changed in the exception queue

Two things got better and one got worse. Structured parties reduced the repairs caused by address formatting, and a surviving end to end id turned a class of fuzzy matches into exact ones. What got worse, at least temporarily, is the variety: a bank now reconciles MX from most correspondents, MT from some domestic flows, and translated messages from a few legs where an intermediary sat in the middle. Variety is exactly what a rigid reconciliation tool handles badly.

Three failures that still generate breaks

1. 01Truncation at an intermediary. A leg that passes through a system with MT-era field sizes loses structured content, and the receiving bank gets a payment that no longer matches its instruction cleanly.
2. 02Local population habits. A correspondent populates a permitted field in a way your rules did not anticipate. Not invalid, just different, and it produces a steady trickle of unmatched items until someone encodes it.
3. 03Internal flattening. The message arrives correct and a system inside your bank strips it before reconciliation sees it. This is the most common and the most fixable.

What CBPR+ actually constrains

The guideline works by narrowing choices. Where the base standard permits a party to be identified several ways, CBPR+ says which ones are acceptable between banks. Where remittance information could be free text or structured, it says when each is allowed and how long it may be. Where an identifier could be omitted, it makes it mandatory so that the chain has something to carry.

• Structured party data: name and postal address as components, with rules on which components are required for which party role.
• Identifier carriage: the end to end id and the uetr are expected to travel unchanged, which is what makes tracking and exact matching possible.
• Charges: a coded charge bearer plus explicit charge records, rather than a difference the receiver has to infer.
• Return and cancellation handling: coded reasons tied to the original message instead of narrative explanations.
• Character sets and lengths: constrained so that a message accepted by one bank is not rejected by the next.

For an operations team the practical reading is that CBPR+ turned a set of conventions into something you can write a rule against. A field that is mandatory can be a matching key. A field that is optional cannot, and a rule that assumes it will always be there produces a slow trickle of unexplained breaks.

The uetr, and why tracking changed the conversation

The unique end to end transaction reference is a single identifier assigned at the start of a payment and carried by every bank in the chain. It is what makes it possible to ask where a payment is and get an answer rather than a series of emails. For reconciliation it does something quieter but just as useful: it gives an investigation a spine. When an item is unmatched and the counterparty is asked about it, the question is about one identifier rather than about an amount and a date that could describe several payments.

It is worth being clear about what it does not do. A uetr identifies the payment through the chain. It does not guarantee that the originator reference your customer cares about survived, and it is not always present on the statement entry your reconciliation reads. Whether it reaches the statement depends on the reporting bank, which is exactly the kind of thing worth checking per correspondent rather than assuming.

Coexistence left an inventory problem

The end of the coexistence window changed what travels on the network. It did not change what sits inside a bank. Almost every institution now has some mixture of the following, and the mixture is the real migration state.

The mistake worth avoiding is treating format as a property of the bank rather than of the source. A reconciliation configured with one global assumption will be wrong for at least two of the rows above on any given day.

Translation, and the quiet damage it does

During coexistence, network level translation let an MX message reach a bank that could only read MT, and the reverse. Translation is lossy in one direction by definition: a structured address with six components cannot be carried by a field that holds four lines of thirty five characters without something being discarded or truncated.

The damage is quiet because the payment still settles. What arrives is a payment with a shortened name, a truncated reference or a missing structured block, and it settles perfectly well. The cost appears two steps later, when the item does not match cleanly and a person has to work out which of three candidate ledger entries it belongs to. If your break population has a stubborn seam of missing reference items concentrated on a few correspondents, translation somewhere in the chain is the first thing to check.

A migration checklist that is actually about reconciliation

1. 01List your sources and record the actual format each one sends today, verified from a real file rather than from a project document.
2. 02For each source, confirm whether the end to end id and the uetr reach the statement entry, because that decides whether exact matching is available.
3. 03Confirm your ingestion reads to transaction level inside batched entries, not just to entry level.
4. 04Check whether any internal system rewrites references between instruction and reconciliation.
5. 05Keep MT parsing and MT archive reading in support, and make that an explicit decision rather than an oversight.
6. 06Classify breaks by cause and review the distribution monthly, per correspondent, so a population problem is visible while it is still small.

Reject, return and cancellation are three different things

These three words are used loosely in conversation and mean quite different things in a message flow, which matters because each produces a different reconciliation outcome. A reject happens before settlement: the message failed validation or a check, and no money moved. A return happens after settlement: money moved and is being sent back, which means there are two settlements to account for and two entries on the account. A cancellation is a request, not an outcome: one bank asks another to stop or recall a payment, and the answer may be no.

The reconciliation consequences follow directly. A reject should remove an expected item, not create a break. A return should be tied to its original so the account shows a matched pair with a reversal rather than two unexplained entries. A cancellation request should create a pending state on the original item, so that an item under investigation is visibly under investigation rather than simply unmatched. Structured status and reason codes make all three of these automatic; narrative explanations make all three of them manual.

Structured addresses, the deadline that caught people out

The move away from unstructured party address data is the requirement that generated the most late work in this migration, and the reason is that the data does not live in the payments stack. It lives in customer records that were captured years ago, often as free text in a single field, sometimes with the building number and street in an order no parser will reliably separate. A payments team can do nothing about that on its own, and the remediation belongs to whoever owns the customer master.

The reconciliation consequence is worth stating plainly, because it is usually missed. Party data that was previously a display field becomes a field that can carry a matching key and that can also cause a rejection. Both directions matter: a payment that stops for a malformed address is a repair, and a payment that carries a well-structured party is a payment that can be matched on something more reliable than a free-text narrative.

What coexistence taught, and what to keep

The lasting lesson of the coexistence period is that format is an attribute of a source rather than a property of the bank. Institutions that built on that assumption absorbed each cutover as a configuration change. Institutions that treated the migration as a state to be reached found that the date arrived while several internal interfaces, domestic schemes and every archive they held were still on the old format, and the gap was filled with translation layers that nobody planned and few documented.

That is worth keeping, because this is not the last format change. Retaining the ability to parse what a source actually sends, rather than what the roadmap says it should send by now, costs very little when it is designed in and is expensive to retrofit under a deadline.

What to expect, honestly

Structured data improves matching where it survives the whole chain, and it makes very little difference where it does not. That is why two banks running the same migration can report completely different results without either of them being wrong. The variable is not the standard, it is how many hops preserve it, and how much of the structure the receiving bank actually reads. Both of those are within your control in a way that a correspondent behaviour is not, which is where the work is worth putting.

What to do about it

Measure breaks by cause, not by count. If the classification vocabulary distinguishes a missing reference from a fee difference from a timing difference, the pattern in the data tells you which correspondent, which corridor and which internal interface to fix. That is a reconciliation capability before it is a payments project, which is why ISO 20022 payment automation tends to be funded out of the migration budget and paid back out of the operations budget.

Background on the standard itself is in ISO 20022 explained, and the US rails have their own story in Fedwire, FedNow and ISO 20022.