ISO 20022 cutover: what changes for operations teams

SWIFT's coexistence period for MT and ISO 20022 (MX) cross-border payment messages under CBPR+ ends in November. The migration usually belongs to the technology team, while most of the day-to-day consequences arrive in operations.

Picture an investigations analyst working a case on an inbound payment. The beneficiary's name has been cut short and the street address is missing, so the payment is sitting in a repair queue. The sending bank says it sent a complete, structured address, and it probably did. Somewhere along the chain the message passed through a system that still worked in MT, and the fields were shortened to fit. The analyst now has to establish that, chase the missing details and explain the delay to a customer who only wants to know where the money is.

Coexistence made conversions like that routine. Once it ends, a good share of the format conversion between institutions should fall away. What happens inside your own operation depends on what your own systems can read, and that part is still in your hands before November.

Richer data only helps if you keep it

An MX message can carry far more than its MT equivalent: names and addresses split into structured fields, and remittance information with enough room to say something useful. None of that helps an operations team if the data is lost somewhere between the payment gateway and the screen the analyst actually looks at.

The exercise we recommend is plain and a little tedious. Take one inbound payment in your test environment and follow it through every system it touches: the gateway, the payment hub, screening, the ledger, case management, the customer notification and the statement. At each step, write down which fields arrive whole, which are shortened and which disappear. The shortest field is often somewhere unglamorous, such as a beneficiary name column in a core ledger designed long before anyone said CBPR+ out loud, or a free-text box in the CRM that front-line staff paste details into.

Then ask what happens when a field does get truncated. A well-built conversion step raises a flag, so the follow-up question is where that flag goes. If it lands in an application log that nobody reads, your first warning will be a complaint, or a screening result that nobody can explain.

If your ledger or your screening tool still reads MT after November, the truncation happens inside your own walls.

Screening will behave differently

Sanctions screening has been tuned for years against MT messages, where a name and address often arrive as a few lines of free text. Structured fields change what the tool compares. A town field and a country code get matched differently from a line of text that happens to contain a city name, and the tuning that kept false positives manageable was built for the old shape of the data. Expect alert volumes to move in the first weeks after cutover, and plan for the possibility that they go up.

Take an illustrative case. Say your screening team clears 300 alerts a day. A 25 percent rise for a month means 75 extra alerts a day, and at about six minutes each that is seven or eight hours of additional work every day, roughly one more analyst for the month. You would want to know that in October. The way to find out is to replay a sample of recent traffic, in MX form, through the screening configuration in test and compare the alerts with what the same payments produced as MT.

Investigations and returns

Investigators need to see the message as it was received. If your case management tool shows a rendered MT view of an MX payment, the analyst is working from the damaged copy. Put the original message in the case, with the UETR as the reference everyone searches by, so that an inquiry from a correspondent can be matched to the right payment on the first attempt.

Returns deserve separate attention. ISO 20022 returns carry coded reasons, and a code only helps once someone has decided what it means for the customer. List the reason codes you actually receive and map each one to a next step and a customer message. A return for a closed account (AC04) means going back to the customer for new details. A generic code such as MS03 tells you very little, so keep a count of which counterparties send it and raise the pattern with them. Returns are also the moments customers judge you on, as we argued in our post on exception handling.

Decisions for the first weeks after cutover

Most of the preparation above is testing. The rest is a handful of decisions that are easy to leave until the cutover weekend, when nobody has the time to make them well.

1. Who watches the new exception types

   Rejections for invalid structured data and truncation flags need their own queue category and a named owner. Mixed into a general payment exceptions bucket, they disappear, and you cannot tell whether the problem is shrinking.

2. Who can approve a screening change quickly

   Agree with compliance, in writing, who can approve a tuning change during the first weeks and how fast. A change that has to wait for the monthly committee will arrive after the backlog has built.

3. What the front line tells customers

   Prepare wording for payments delayed by data problems, including what the customer can do (often, supply a complete address) and when they will hear back.

4. What you count every day

   Pick a few numbers for the first month: alerts per day, new exceptions by type, returns by reason code and investigation cases opened. Review them daily until they settle, then weekly.

There is a second date behind this one. SWIFT has said that fully unstructured postal addresses will no longer be accepted from November 2026, a planned change that turns address quality into an operations job. If your customer and payee records hold the address as one free-text line, someone has to split it into town, country and the rest, through onboarding forms, KYC refresh and payee updates. That work is slow because it depends on customers replying.

A useful query to run this month: how many active customer and payee records hold the whole address in a single field. That number is the size of the 2026 job, and it is far easier to reduce over fourteen months than over four.

Discuss your operations