Your questions, answered: Exceptions and Investigations under ISO 20022

In June 2026, a panel of industry experts gathered to discuss changes to Exceptions and Investigations under ISO 20022. 

The webinar, which we hosted in partnership with Finextra, generated a number of questions about the changes. So, we’ve decided to answer them all here. 

Some of the questions have been edited for readability or merged with others. 

If you have any more, please do not hesitate to reach out. 

The main challenge for banks in the upcoming ISO 20022 changes is not fixing their own customers’ addresses, but tackling unstructured addresses outside the bank’s control. Any suggestions for how the banks can do this?

This is the most difficult aspect of the upgrades. Fixing your own customers’ address data is mainly about data quality and channels.  

We’ve seen banks take a few different approaches:

1. Tighten the channel at the point of capture by making town and country mandatory in corporate portals, host-to-host templates, and APIs, and reject anything that doesn’t comply before it even enters the payment engine.
2. Publish updated MIGs (message implementation guide) or training videos to your corporates early and walk them through it; don’t assume they’ll read a circular.
3. Decide upfront what your policy is for incomplete inbound addresses: hard reject, manual repair with a charge, or auto-enrich. 

One of the main points of struggle is the readiness of corporates to use the new structured addresses. What is your experience in this field?

It’s true that corporate readiness is uneven. Lots of older enterprise resource planning systems, custom build treasury systems, as well as homegrown payments files don’t have separate town and country fields, which makes things difficult.  

What we usually recommend:  

• Start with an ERP gap assessment 
• Get the vendor roadmap in writing so you know when the patch is coming 
• Run a data profiling exercise on existing beneficiary master data to see how much of it is actually clean today

In parallel, work closely with your colleagues. Every bank is interpreting the hybrid format slightly differently, so you need to know your bank’s specific validation rules. It’s important not to forget operations training too. The people actually processing the exceptions will be affected first. 

A key challenge corporates face in getting ready for the CBPR+ structured address migration is aligning their upstream systems, both for onboarding new customers and for cleaning up existing customer data. 

The first step? Define a single target format (structured or hybrid) that all customer address data will be aligned to. By setting this standard early, your downstream systems have a single agreed-upon format to map against. That reduces the risk of duplicate or inconsistent address records and gives you a controlled baseline for handling incoming data. 

Does the Swift Case Management tool offer enough functionality that you might not need the A2A/API management of your E&I, but actually be able to manage them through the tool? Are there limitations to be considered by smaller or larger banks?

The Swift Case Management solution gives you three ways: GUI (graphic user interface), API, and messaging (camt.110/111).  

Functionally, it covers the full investigation lifecycle: CCNR, UTAP, RFI sanctions, compliance, AML and fraud. So, in principle, a smaller bank could run its entire E&I operation through the GUI without building anything internally. 

But there’s a little more nuance involved. For a smaller bank with low investigation volumes, the GUI is a no-brainer – you can be compliant with minimal investment and no integration project.  

It’s different for larger banks. The GUI doesn’t scale operationally, and you’ll want API integration into your existing case management or workflow tool, so investigators aren’t toggling between systems. 

The middle ground we see most often is a vendor case management platform that consumes the Swift APIs underneath. Our advice is: don’t treat Swift’s tool and your internal tool as an either/or. Look at how they integrate, and base the decision on volume, your ops model, and whether you’ve already invested in a case management platform. 

Swift is moving to the new investigation messages, so is SEPA. As I understand it, Fedwire and FedNow are built on the SEPA/TIPS template. Does this also apply to the E&I message types and rulebooks? When will Fedwire and FedNow mandate this?

FedNow was built natively on ISO 20022 from launch in 2023, and Fedwire migrated to ISO 20022 in July 2025. They share the same underlying ISO standard, and the message structures look familiar. But the Fed has its own usage guidelines and rulebooks. 

On the E&I side, Swift’s camt.110/111 model is for cross-border correspondent banking through Case Orchestrator. The Fed has not announced a mandate to adopt that exact model for domestic investigations.  

What we do expect is convergence in spirit: structured data, ISO-native investigations, retirement of free-format messages because nobody wants to maintain two parallel worlds.

But a formal Fed mandate with dates? Not yet. Realistically, we’d expect the Fed to start consulting on this around 2027–2028, once they’ve digested the Fedwire migration. 

Taking into account that in 2023, 92% of investigation messages in the US were still free forma, what do you see as the likelihood that the 2027 deadline will be met? And what is the backup plan?

The 2027 deadline hasn’t been sprung on banks, they’ve been aware what’s coming since 2023, but there’s no question it’s going to be tight. US banks have leaned heavily on MT199/299 for investigations and moving that volume to structured camt.110/111 through Case Orchestrator inside two years is a huge undertaking. 

Will Swift push the 2027 deadline? No, at least not in full. Swift has been firm publicly, and the working groups are pushing hard. But we may see narrower scope adjustments or specific carve-outs if certain investigation types prove unworkable.  

The backup plan for any bank that’s not ready is to stay on in-flow translation as long as possible and have a contingency to process serially over FIN. But that runway ends in November 2027.

ISO messages with structured data are going to be a significant change, especially in the corporate banking side. Do you see a rising demand for corporates?  

Absolutely, and we’d argue this is one of the most undersold benefits of the whole ISO 20022 migration. Today, a typical corporate accounts receivable team spends a huge chunk of its time matching incoming payments to open invoices because the remittance information arrives as truncated free text. 

Structured remittance data, structured creditor reference (RF reference), and clean party identification change that completely. You can auto-match, you can auto-post, and reconciliation moves from a manual exception process to genuine straight-through processing on the corporate side, too. 

We are seeing demand rise, especially from corporates with high invoice volumes like utilities, insurers, and large B2B suppliers. The corporates pushing their banks hardest are the ones who’ve actually quantified the cost of manual reconciliation. The advice we give corporates: don’t just consume the data, work with your bank to agree on what fields will actually arrive populated and in what format. 

My bank is planning to proceed with inflow translation in November 2026. Could we subscribe to the Case Management GUI option that would allow our operations team to have a view-only access to camt.110, while continuing to work with MT199 embedded within camt.110 in our internal case management tool?

Yes, that approach works for the Nov 2026–Nov 2027 window. From November 2026, every institution will receive the camt.110 with an embedded MT199 through in-flow translation, whether they’re a Case Management participant or not. So, your ops team can absolutely continue working the embedded MT199 inside your existing tool, and if you need to forward to the next agent serially over FIN, that’s also still available. 

Subscribing to the Case Management GUI for view-only visibility on the full camt.110 would be a wise interim move. It will give your team a line of sight on what the structured data actually looks like before you commit to API or messaging integration. This way you can use the 12 month window as a learning period. 

One important caveat; This is a only transitional setup. From November 2027, in-flow translation ends, MT195/295/196/296 are retired, free-format MT199/299 disappears for E&I purposes, and every eligible FINplus user automatically becomes a Case Management participant.  

Your internal tool will need to consume and respond to camt.110/111 natively by then, either through API, messaging, or by moving fully to the GUI. Best to use the interim period to plan for the eventual transition.

How will a payment be handled if directional references are used in the address field (i.e. “behind the building” or “opposite the post office”)?  Does the scanning verify characters are present in the field, or is scannning done on the actual address?

There’s no dedicated structured element for landmarks or directional references like “behind the building,” “next to the temple,” etc, which are present in a lot of Asia-Pacific and Middle East addresses. 

The hybrid format is designed exactly for this. You put town and country in the structured fields, and the landmark or directional info goes into the hybrid address line element. 

On the scanning question, Swift’s network validation operates at the schema level. It checks that the mandatory structured elements are present and well-formed, and that field lengths are respected. It does not parse the semantic content of the address line to check whether it makes sense as an address. 

Where it might get flagged is downstream, sanctions screening, and KYC (know your customer) engines that try to derive geographic context from address lines might raise alerts, so it’s worth checking how your screening platform handles it. 

In a hybrid address, what will happen when the user provides repetitive information? For example, ‘City’ is mentioned in the field ‘Town’ and also mentioned in the address line.

There’s no hard network-level validation in place today to reject duplication. 

But the PMPG (Payments Market Practice Group) and Swift both strongly discourage it. Duplication causes downstream pain in three places. One, sanctions screening: some engines will treat the duplicated string as a separate address component and potentially flag false positives. Also, when you concatenate structured and unstructured fields back into MT940/942 format, you end up with “Paris, Paris” appearing on the customer’s statement.

Swift has a textual rule stating that data held in the structured elements of a postal address must not, under any circumstances, be repeated in the Address Line. A receiving bank may therefore, within its rights and its own compliance interest, reject any payment that breaches this rule, since such duplication degrades the screening it supports.

The fix is on the bank side: build validation logic into your channels and payment engine to strip or flag duplicates before transmission. And on the customer side, get this into your MIGs and corporate communications early. Treat it as a “soft rule” you enforce internally, even though Swift doesn’t enforce it on the network. 

More questions about Exceptions and Investigations?

These questions came out of a webinar we hosted with Finextra, you can watch it here.

If you have your own questions, then maybe it’s worth a conversation with one of our experts?