Swift Case Management

Swift Case Management is Swift’s central service for handling exceptions, investigations and payment cancellations in cross-border payments – known in the industry as Exceptions & Investigations (E&I). It replaces the previous bilateral exchange of free-format MT messages with the central orchestration of structured ISO 20022 messages.

Definition

Case Management brings together all messages belonging to a case in one place and delivers them straight to the institution concerned, instead of passing them from bank to bank along the payment chain. The service has been generally available since November 2025 and, according to Swift, more than 200 banks already use it. For the remaining ISO 20022 migration it is no longer optional: the investigation messages camt.110 and camt.111 can only be exchanged through Case Management.

The background is a concrete volume problem: roughly one to three per cent of all payments do not run through cleanly. Resolving them is still largely manual, inconsistent and expensive. Swift puts the industry-wide savings potential at around USD 600 million per year.

The two components

Case Orchestrator

The Case Orchestrator is the E&I component and processes the investigation messages camt.110 (InvestigationRequest) and camt.111 (InvestigationResponse). It receives the request, validates it, enriches it and routes it to the institution that can actually answer the case.

Supported investigation types include:

• Creditor Claim Non-Receipt (CCNR) – the beneficiary reports that the payment has not arrived
• Cover Creditor Claim Non-Receipt (CONR) – the same claim in the cover method
• Request for Information – queries on sanctions, compliance or payments that cannot be executed
• Unable to Apply – the payment cannot be allocated at the receiving end
• Missing Funds – investigation into amounts that have not been credited

Stop and Recall

The second component covers payment cancellations and recalls. It works with camt.056 (Cancellation Request) and camt.029 (Resolution of Investigation) and opens the standardised recall process – previously limited to Swift gpi – to all institutions. Its practical relevance is greatest in fraud cases, where minutes decide whether funds can be recovered.

References and routing

Two references hold a case together:

• The UETR (Unique End-to-End Transaction Reference) identifies the underlying payment and links it to its status reports.
• The EIR (End-to-End Investigation Reference) identifies the case and accompanies it from opening to closure.

Messages to the service are routed via the central Tracker BIC TRCKCHZZ. Using the UETR, the orchestrator can automatically enrich the request with the payment data already held in the Payment Tracker, so the requesting institution does not have to key it in again.

How it works

The automation benefit does not come from the message format alone, but from what the orchestrator does with it:

• Business validation – requests that breach business rules are rejected before they create work at the receiving end.
• Data pre-population from the Tracker – fields are filled from the data of the related transaction.
• Smart routing – the request goes directly to the institution concerned, bypassing intermediaries in the payment chain.
• Automated reminders and end-to-end tracking – open cases stay visible and are followed up.

Access is available via messaging (FIN and FINplus), via an API or via a graphical user interface. This allows institutions to participate even where they do not want to build their own interface to the investigation messages.

Timeline

Roll-out follows the CBPR+ roadmap and proceeds in stages:

• November 2025: the service is generally available; use is voluntary. MT and ISO 20022 formats run in parallel.
• November 2026 (SR 2026): all institutions must be able to receive camt.110 through Case Management. Those that have not yet migrated are supported by free in-flow translation, which delivers the request as an MT 199 with the message embedded.
• November 2027 (SR 2027): camt.110 and camt.111 must be sent and received through Case Management, and payment cancellations run exclusively through Stop and Recall. In-flow translation ends, MT messages of categories n95 and n96 are removed from the network, and free-format MT n99 is discontinued for E&I purposes.

One postponement is worth noting: following market feedback, Swift moved the obligation to handle payment cancellations through the Stop and Recall process from November 2026 to November 2027. The obligation to receive camt.110 by November 2026 is not affected.

Relevance for banks and payment service providers

Every institution that handles payment enquiries is affected – not only Swift gpi participants. Three planning points follow from the staged approach:

• Choice of channel. Messaging, API and user interface differ considerably in implementation effort and in the degree of automation they allow. The interface secures the deadlines but realises only part of the benefit.
• Case handling in the back office. EIR and UETR must remain attached to the case permanently so that follow-up requests are matched to the right case automatically.
• Two processes, one service. Investigations and recalls use different messages, follow different deadlines and in many institutions sit with different departments. Both strands should be planned together.

Case Management explicitly does not apply to the SEPA area: camt.110 and camt.111 are not part of the European Payments Council rulebooks. Investigations and exception handling there continue to rely on camt.027, camt.087, camt.029 and the R-transactions with their SEPA reason codes.

Sources for specifications

• Swift – Case Management (product page)
• Swift – Case Management for Exceptions & Investigations (info sheet, PDF)
• Swift – ISO 20022: Exceptions and Investigations (FAQ)
• Swift – Transforming exceptions and investigations
• Swift – CBPR+ roadmap beyond November 2025 (PDF)