Your guide to ISO 20022 exceptions and investigations

Updated June 2026

Key takeaways

• The ISO 20022 Exceptions and Investigations (E&I) migration is already underway.

• By November 2027, all financial institutions must send and receive E&I messages (camt.110 / camt.111) exclusively in ISO 20022 format.

• Banks should not wait for the deadline. Get started now (if you haven’t already).

Exceptions and Investigations (E&I) handling is changing.

The old free-format messages — MT199 and MT299 — are being replaced by structured ISO 20022 camt messages: 

• camt.110 / camt.111 for case resolution 

• camt.056 / camt.029 for stop and recall

These new message types are machine-readable and automation-ready. They’ll replace slow, manual, and error-prone free-text communications. 

Now, the migration is already underway. camt messages are live, and banks have until November 2027 to fully transition away from MT-based E&I messaging (according to Swift migration guidelines).  

There’s a lot to plan for, and while the timelines have been phased, early preparations remain critical. 

So, what’s changing, what will be affected, and how can you prepare? 

Why payments get stuck

Let’s start with the problem the new standards are solving.  

Imagine: It’s just after 8 a.m., and Aisha logs into her payment operations dashboard. Overnight, tens of thousands of cross-border payments have flowed through her bank’s systems. Most have cleared automatically, but a small handful — between 2 and 5% — are waiting in a queue.  

Each case is a payment that didn’t complete as expected. Maybe the beneficiary’s account number didn’t match. Maybe it was held up for sanctions review. Sometimes it’s missing reference data from an intermediary bank.  

Aisha starts by checking the exceptions queue — a list generated by her bank’s transaction monitoring system. Each item shows the payment’s journey, where it stopped, and any related messages. She reviews the structured data, then opens the Swift MT199 trail to see what’s been exchanged so far between the other banks.  

If she needs to investigate or determine the cause of the issue, she sends an MT199 or an email through the secure banking network. Often, issues sit between banks, delayed by missing or incomplete information passed along the chain. Resolving them can take hours or even days, adding costs and frustration for clients. 

Back and forth

Aisha’s workload doesn’t end there—she also has to process a constant stream of incoming MT199s from other correspondent banks.  

These ask her institution to track down missing payments, clarify remittance details, and confirm compliance information. Each inbound query must be located in internal systems, matched to the original transaction, and manually routed to the right team or branch—often across time zones.  

With no structured fields to automate triage, Aisha and her team sift through free-text narratives, reconcile data by hand, and chase colleagues for updates. The result is a double ended sword: outgoing MT199s stall while counterparties search for answers, and incoming MT199s that drain resources, inflate investigation backlogs, and expose the bank to SLA breaches and customer dissatisfaction. 

Why the current process is broken 

The system Aisha is using is nearly 40 years old. She’s dependent on legacy payment infrastructure that is not ISO 20022 native. That means:  

• Free-format messages dominate: Over 70% of E&I cross-border messages are unstructured text (MT199/MT299), akin to handwritten notes. They’re flexible but slow to process and prone to errors, especially across languages and borders. 

• Multiple manual steps: The average E&I case requires 5–10 manual interventions. In many instances, messages are passed through one or more intermediaries (“daisy chaining”), which can take anywhere from 1 to 8 days. 

• Poor visibility: A lack of standard rules and central tracking makes it hard to follow payments, slowing problem-solving. 

• Operational costs and customer impact: Limited transparency leads to an estimated $1.6B in annual industry operational costs (including fees, staff costs, and compensation), unhappy customers, 3%+ attrition rates, increased exposure to fraud and regulatory scrutiny. 

• Legacy Systems and Limited Automation: Banks rely on case management tools or custom modules within payment engines. But the lack of structured formats limits automation. That leads to manual work and delays. 

Source: Swift

The debtor sends a payment to the creditor through multiple banks (debtor agent, intermediary agents, and creditor agent). 

1. If an issue occurs (say, the funds are not received), the creditor contacts the debtor’s bank to investigate. 
2. The debtor bank raises an inquiry and sends an unstructured MT message (i.e,. MT199/MT999) to the first intermediary bank 
3. Each bank in the chain passes the request along to the next, acting only as a messenger until it reaches the creditor bank. This takes time. 
4. The creditor bank responds through the same chain in reverse, causing more delays. 
5. This step-by-step passing of information leads to: 
   1. Delays in investigation resolution. 
   2. Lack of visibility between the sender and receiver banks, as they cannot communicate directly. 

ISO 20022 and Case Management

Swift is overhauling the way banks handle payment problems. This transformation is part of the broader CBPR+ migration roadmap, aligning E&I processes with ISO 20022 adoption around cross-border payments. 

The first attempt, called Case Management 1.0, sat on top of the gpi Tracker and combined two tools: 

• Stop & Recall (SRP), launched in 2019, which lets banks halt or pull back a payment that is still moving through the network.  

• Case Resolution (CASE), added in 2020, which helps fix “Unable-to-Apply” cases or answer simple requests for information when a payment can’t be processed. 

It’s useful. But Case Management 1.0 relied on free-text FIN messages, covered only a few investigation types. And it could only be used by gpi members. 

Case management 2.0

Now, Swift is going further. Case Management is a next-generation service that will replace the old Case Resolution module. It offers a wider range of investigation options, and enables fully structured, automated exchanges for all banks in the network.  

So how does it work? 

The Case Management 2.0 product suite consists of two services: 

Stop and Recall (SRP): Used to stop and recall a transaction that is still in progress, where the funds have not yet been credited to the creditor’s account, or, to request the recall of funds already credited. SRP applies to Customer Credit Transfers (CCT) with an active UETR in the tracker. 

From November 2027, the scope will expand to cover Financial Institution Transfers (FIT), Cover Payments, and payments where the UETR is not active in the tracker.

For banks already using SRP via an API, the current API versions (v5/v6) will remain supported beyond the SR2026 standards release. This means existing integrations won’t need to be rebuilt to meet that milestone.  

Source: Swift

Case Orchestrator: This bit is new. The case orchestrator helps banks handle payment investigations more quickly and easily. It acts as a central system where banks can raise and respond to investigation requests. By following clear industry rules, it automates and streamlines the process, reducing manual work and mistakes. The service also offers a user-friendly interface for banks without their own investigation systems. This leads to faster resolutions, lower costs, and better visibility for everyone involved.  

Source: Swift

Case management will support a defined set of investigation types. These cover the most common scenarios encountered by banks in cross-border payments:  

• Unable to Apply/Unable to Locate (UTAP/UTEX): payments that can’t be matched or processed by the receiving bank  

• Request for Information – Sanctions and Compliance (RQFI / SANC / COMP): queries raised for regulatory or compliance reasons  

• Anti-Money Laundering (AMLI): investigations triggered by anti-money laundering concerns  

• Fraud (FRAD, FWTR, FCCI): covering fraud reporting, fraud warnings and fraud cost claims  

• Cancellation of Credit Transfer/Notification of Return (CCNR/CONR): confirming cancellations and returns  

• Other (OTHR): a catch-all category covering additional request types including account queries, document requests and value date changes.  

Not all investigation types will be available at the same time. If any of these sub-types are relevant to your workflows, it will be important to factor that timeline gap into your project.  

As of the end of Q1 2027, the following investigation types will be supported through Case Management: 

• RFI Sanctions (SANC)  

• RFI Compliance (COMP) 

• Investigations related to anti-money laundering (AMLI) 

• Investigations related to financial crimes compliance (FCCI) 

• Investigations related to fraud (FRAD) 

• Investigations related to funds/wire transfer regulations (FWTR) 

• Investigation type ‘Others’ (OTHR) includes investigation sub-types: 

• Request for Use of Funds (RQUF) 

• Request for Debit Authority (RQDA) 

• Request for Value Date Adjustment (RQVA) 

• Request on Charges (RQCH) 

• Others (OTHR)  

Case management messaging types

Case management 2.0 uses ISO 20022 structured messages  (such as camt.110 for investigation requests and camt.111 for investigation responses), along with APIs (Application Programming Interfaces) and a GUI (Graphical User Interface), to replace manual, free-format messages like MT199 and MT299. Every field — purpose, remittance details, regulatory information — is clearly defined, machine-readable, and automatically validated, rather than buried in sometimes confusing MT199 messages. 

That means investigations are resolved far faster than before: Swift cites resolution-time reductions of up to 80%. It reduces costs, prevents fraud, ensures timely payments, and improves client satisfaction. It also provides transparency through the Case Orchestrator dashboard, which allows users to follow their inquiry requests along their journey through the chain and maintain a clear audit trail of all related communications 

For Aisha, this means: 

• Less detective work  

• Fewer manual handoffs 

• Lots of exceptions are automatically resolved before reaching her queue 

• End-to-end traceability, with all links in the payment chain seeing the same information 

• Reduced back-and-forth messaging and lower risk of human error

Source: Swift

What Case Management participants must do from November 2026

Banks in this position will be bound by a specific set of routing obligations. They will impact how you handle investigation messages based on how they arrive, specifically: 

• If you receive a camt.110 via Case Management: you are typically expected to continue the investigation flow within Case Management. 

• If a request arrives via a legacy channel (MT199): You must respond via that same legacy channel. 

• If a camt.111 response arrives via legacy: you have no obligation to route your reply through Case Management, you can respond via FIN instead.  

It’s important to note that not all banks will be part of Case Management during the transition phase. Banks that are not yet participating will still receive camt.110 investigation requests, but will need to continue responding and forwarding these requests using MT199 through existing legacy channels.  

Who can subscribe to use these services:

Non-GPI Customers: 

• Subscribe to Case Management to implement both components/services. 

GPI Customers: 

• Subscribe to Case Orchestrator
• Have already implemented Stop and Recall as part of the Swift GPI onboarding. 

From November 2027 – automatic participation:

• All eligible FINplus users become case management participants – no subscription required 
• This applies regardless of GPI membership status. If you’re already on FINplus, you will be included.  

Channels for Migration: 

• Case Management GUI: allows institutions to seamlessly initiate / respond to ISO compliant investigations. 
• Structured ISO 20022 messages (FINplus messaging) 
• API 

The camt.110 and camt.111 messages on FINplus are never exchanged directly between banks. Instead, they are always routed through the Case Orchestrator, which functions as a smart router. It automatically ensures that investigation messages are delivered to the correct bank, streamlining the process and reducing manual intervention.

Timelines for ISO 20022 Exceptions and Investigations

So, the new system will vastly improve on the old. How much time do you have to get ready for it? 

Payment cancellations (camt.056 & camt.029) – E&I messages roadmap

Let’s start with payment cancellation messages.

Today, you can already use camt.056 and camt.029 as part of the Stop and Recall service.  They also work with service specifications (mandatory for GPI customers, optional for other eligible customers today). These messages can also be exchanged bilaterally on FINplus. In-flow translation capabilities are available for camt.056 and camt.029 messages.

Source: Swift

Following community pushback, Swift’s November 2026 deadline for changes to payment cancellations has been pushed to November 2027. The delay was driven by feedback from the industry and the new Swift Payment Scheme. 

So, 12 months later than initially planned, financial institutions will need to be ready to send and receive payment cancellation requests and responses through Stop and Recall. 

By November 2027, payment cancellation messages (camt.056 / camt.029) will be routed through Swift’s Stop & Recall service rather than being exchanged directly between banks. The service uses centralised processing and intelligent routing to ensure that requests are delivered to the institution best placed to resolve the case.  

This also applies to support for exchanging payment cancellation requests and responses sent over FIN through Stop and Recall/Case Management will end (in-flow translation support will, therefore, also end). It will be mandatory to send and receive camt.056 and camt.029 messages over FINplus through Stop and Recall/Case Management. Legacy E&I formats will be retired.  

Exceptions and Investigations camt.110/111 – E&I messages roadmap

For exceptions and investigations, camt.110 and camt.111 have been available on an opt-in basis since November 2024. They can be accessed with the Case Management dedicated closed user group on the FINplus live service. 

Source: Swift

In November 2025, in-flow translation capabilities became available to Case Management participants. It’s important to understand what’s supported, and what isn’t:

• Translation is supported in one direction only: camt.110 to MT199 

• There is no reverse translation: MT199 messages won’t be automatically converted to camt.110 or camt.111 

• There is no translation to MT299: camt.110/111 messages cannot be translated to MT299 format.  

camt.110 and camt.111 messages are routed via the Case Orchestrator, which provides centralised orchestration instead of messages being addressed directly to the next bank in the chain. The service ensures that investigation requests are delivered to the appropriate institution for resolution. 

November 2026 marks the first key milestone, where all institutions must be able to receive camt.110 investigation requests with embedded MT199 (in-flow translation)  via Case Management.  

And by November 2027, it will be mandatory to send and receive investigation requests and responses in ISO 20022 formats only (camt.110/111) through Case Management. In-flow translation support to MT199 will end, and legacy E&I formats will be retired.

What should you do now? 

Now for the juicy bit. The transition to ISO 20022-based E&I messaging and centralized case management is already in motion. The impact goes well beyond technical. It will affect operations teams, client service teams and client channels. 

Delaying could expose you to operational headaches, increased costs, and unhappy customers. In other words: get started right away. 

1. Assess existing E&I workflows and identify gaps

Begin by conducting a comprehensive end-to-end mapping of your current E&I workflows. This should include all relevant message types such as MT199, MT299, MT192, and MT196, along with manual intervention points, routing logic, reconciliation gaps, SLA adherence, performance metrics, and monitoring mechanisms.  Luckily, Swift has published an E&I Readiness Guide, providing practical tips on MT199 formatting testing and operational preparation.  

Quantify volumes, exception rates, and operational overhead to identify high-priority areas for early transformation, such as high-volume corridors, geographies with elevated costs or investigation-heavy flows. 

2. Establish governance and strategic leadership

Next, set up a cross-functional steering group that includes stakeholders from payments operations, IT, compliance, risk, and client services. This transformation goes beyond messaging. It’s a fundamental shift in business processes. 

Define your target operating model early and include your chosen connectivity channel – either Swift’s GUI, Messaging, or API. 

Then, secure a budget and build in timeline buffers for integration, testing, training, and contingency planning. The transition will not be easy. Working through edge cases and connecting with institutions that have not yet upgraded will be tricky. Factor this complexity into the project. 

3. Enable training, change management, and clear communication

Then, prioritize training across operations, investigations, payments support, and client service teams. Ensure familiarity with new E&I messaging formats, workflows, and exception handling logic.  

Internally, clear communication of roadmaps, timelines, and fallback plans is essential to align expectations (especially for client-facing teams). 

Externally, inform your clients and anyone else who needs to know about upcoming changes to E&I processes. This includes what information will be required and how SLAs or tracking tools may evolve. Be proactive. Providing support resources like documentation or mapping tools can ease the transition. Monitor the readiness of key partners to coordinate bilateral transitions or maintain fallback arrangements where necessary. 

The takeaway?

The good news is that the move to ISO 20022 brings a big opportunity. With structured messages such as camt.110 and camt.111, information will be clearer, more consistent, and easier to process automatically. This will speed up investigations, reduce misunderstandings, and cut costs. But you know that already. 

 What you might not know are the issues you’ll face if you delay.  

You must act now to avoid operational headaches, increased costs, and unhappy customers. 

Assess your workflows, identify gaps, and begin to align your systems and teams with the upcoming standards. Don’t wait. 

Need help?

Speak to RedCompass Labs. We are ISO 20022 experts and have been helping banks for well over a decade. We can support your transition to structured payments data. Contact a member of the team today.