CBPR+ Exceptions and Investigations: camt.110, camt.111, camt.056, and Case Management

Under CBPR+, payment investigations move from MT 199 free text to two structured ISO 20022 messages, camt.110 (Investigation Request) and camt.111 (Investigation Response), which travel only through SWIFT’s Case Management. Cancellations keep camt.056 and camt.029, and from November 2027 must go through Stop and Recall. The message change is the easy part. The operations model behind it is the analyst’s job.

Ask anyone in payments operations what the MT 199 is for and they will laugh. It is for everything: “please confirm status”, “please return funds”, “beneficiary claims non-receipt”, “please advise charges”, and “kindly treat as urgent”, all in free text, all typed by hand, all read by a person who then decides which team should look at it. Investigations are the last large manual island in correspondent banking, and the free-text message is the reason.

This article is in the exceptions and operations section of The ISO 20022 Reference. It builds on returns, reversals, and recalls, which covers what a recall is. Here the focus is the CBPR+ E&I (exceptions and investigations) migration: which messages, which dates, and what you specify and test.

Which messages replace which?

From SWIFT’s E&I FAQ, current as of October 2026:

Purpose	ISO 20022 message	MT messages it replaces
Payment cancellation request	camt.056 FI to FI Payment Cancellation Request	MT 192 / MT 292
Payment cancellation response	camt.029 Resolution of Investigation	MT 196 / MT 296
Investigation request	camt.110 Investigation Request	MT 195 / 198 / 295 / 298 and MT 199 / 299
Investigation response	camt.111 Investigation Response	MT 196 / 198 / 296 / 298 and MT 199 / 299
Tracker alert	trck.003 Tracker Alert Notification	MT 199
Tracker investigation status	trck.005 Tracker Investigation Status Notification	MT 199

Two rows deserve attention. The camt.110 replaces a whole family: the formatted query messages that few banks used well, and the MT 199 that everyone used for everything. And the camt.029 now answers cancellations, while investigation answers move to camt.111, so a single “answers” queue fed by MT 196 has to split.

What is Case Management, and why does it matter?

Case Management is SWIFT’s service for exceptions, built on ISO 20022 and the UETR. It has two parts:

• Case Orchestrator for exceptions and investigations. It centrally routes camt.110 requests and camt.111 responses.
• Stop and Recall for payment cancellations. It routes camt.056 and camt.029 through the Tracker, and can block a UETR so the payment stops being processed. The gpi Tracker article covers how that looks from the Tracker side.

The architectural point that catches teams out: camt.110 and camt.111 cannot be exchanged bilaterally. SWIFT states that migration to camt.110/111 is only possible through Case Orchestrator. Cancellations are different: camt.056 and camt.029 can be exchanged bilaterally today, and only become Stop and Recall only in November 2027.

So a bank that treats E&I as “add two message types to the gateway” has the wrong scope. It needs a Case Management subscription (or mass enablement, below), a case model in its own systems, and routing from Case Orchestrator into its operations queues.

What are the dates?

SWIFT has moved these dates more than once, so here is the state as of October 2026, with the source for each line.

Milestone	What it means	Status
Today	Early adopters exchange camt.110/111 through Case Orchestrator and cancellations through Stop and Recall. Cancellations also run bilaterally in MT or ISO 20022	Live
Receive camt.110	Every bank must accept a camt.110 from Case Management. In-flow translation embeds an MT 199 so a non-adopter can relay or answer it over FIN	Planned for November 2026 in SWIFT’s May 2026 news. SWIFT’s translation services FAQ now says June 2027, in line with the deferred Standards Release 2026 going live on 12 June 2027
November 2027	All investigations are camt.110/111 through Case Management. All cancellations, for every underlying transaction type, go through Stop and Recall in ISO 20022 only. In-flow translation for these ends. SWIFT mass-enables eligible banks as Case Management participants	Unchanged in SWIFT’s public pages
November 2027	MT n92, n95, and n96 removed. MT n99 remains, but must not be used for E&I	Unchanged

Two details from SWIFT’s FAQ are worth quoting in your impact assessment. In-flow translation for the camt.110 is free, unlike in-flow translation for payment instructions, which has been chargeable since 1 January 2026. And a bank can disable (and re-enable) in-flow translation for the camt.110, which only makes sense once its case system processes the native message, because the embedded MT 199 is what lets a non-adopter keep answering over FIN.

What does an investigation look like as data?

The value of camt.110 is that the question is a code, not a sentence. The investigation type comes from an external ISO 20022 code set. The 2Q2026 release defines these:

Code	Investigation type	Typical MT 199 it replaces
CCNR	Creditor claims non-receipt of payment	”Beneficiary has not received funds, please confirm”
CONR	Creditor agent claims non-receipt of cover or settlement	”We have your MT 103 but no cover”
UTAP	A booked entry cannot be applied by the creditor	”Unable to apply, please advise correct account”
RQFI	Further information required on a payment, entry, or instruction	”Please provide full beneficiary address”
PINC	Payment initiation not settled or confirmed	”Please confirm execution of our MT 101”
RQCH	Investigation relating to charges taken or requested	”Please refund USD 25 deducted, charges were OUR”
RQVA	Revaluation of an entry requested	”Please correct value date”
RQUF	Use of funds on an entry requested	”Please advise how to apply these funds”
RQDA	Debit authorisation on an entry requested	”Please authorise debit of your account”
ACCT	Investigation relating to an account	Account-level queries
OTHR	Other request type	Everything that does not fit

Investigation status uses its own small set: PDNG (opened or pending), CLSD (closed), RJCT (rejected). Outcomes use execution confirmation codes from another external set, for example CNCL (cancellation successful), CONF (payment checked and correctly executed), ICOV (cover payment initiated to resolve the case), IDUP (duplicate confirmed), and CHRG (further charges details provided).

For cancellations, the camt.056 carries the reason (DUPL, TECH, FRAD, and the rest of the cancellation reason set) and identifies the original by its UETR, end-to-end identification, and original message. A refused cancellation comes back in a camt.029 with a reason from the payment cancellation rejection set: AC04 (account closed), ARDT (already returned), CUST (customer decision), LEGL (regulatory reasons), NOAS (no response from beneficiary), NOOR (original never received), and others.

Two things follow. Routing can be automatic: a CCNR goes to the inbound payments team, an RQCH to charges, a CONR to nostro reconciliation. And reporting becomes possible: “how many CCNR cases did we receive last month, by correspondent, and how long did we take to close them?” is a query, not a mailbox archaeology project.

What requirements does the analyst write?

E&I requirements fail when they are written as message requirements (“the system shall send camt.111”). Write them as case requirements. A starter set, in the shape I use in a functional specification:

ID	Requirement
EI-01	Every inbound camt.110 creates or updates a case keyed on the requester’s case identifier and the UETR of the underlying payment
EI-02	The case is routed to an operations queue by investigation type, using a configurable type-to-queue table with an owner
EI-03	The system links the case to the underlying payment by UETR. If no payment matches, the case is flagged for manual linking and an alert is raised
EI-04	Each investigation type has a response deadline. Cases approaching the deadline are escalated
EI-05	A response is sent as a camt.111 with a structured outcome. Free text may supplement a code, never replace it
EI-06	An inbound camt.110 with an embedded MT 199 (in-flow translation) is accepted and processed until November 2027
EI-07	A camt.056 for a payment in progress blocks onward processing until the cancellation is resolved
EI-08	An accepted cancellation produces a camt.029 and the return of funds (pacs.004) carrying the original UETR
EI-09	A refused cancellation produces a camt.029 with a rejection reason code from the payment cancellation rejection set
EI-10	After November 2027, no investigation or cancellation is sent as an MT. Attempts are blocked and logged
EI-11	Every case keeps an audit trail of messages, status changes, and the user who acted

Model the case lifecycle as an explicit state machine: received, routed, pending (with the counterparty or the customer), answered, closed, rejected. Then list the illegal transitions, such as answering a closed case or closing a case with no outcome code, because those are the negative tests that find real defects.

If your team is still turning “migrate E&I to ISO 20022” into requirements like these, From Vague BR to Functional Requirements walks through the method, and Break Into Banking covers the payments domain behind it.

Where do E&I migrations go wrong?

From the projects I have seen, five places.

1. The UETR is missing or wrong on the underlying payment. Case Management links everything by UETR. If your bank regenerated it on an onward leg, the identifier on the case does not match anything, and the case lands in manual linking. Fix this in the payment flow, not in E&I.
2. The type-to-queue table is an afterthought. Without it, every camt.110 lands in one queue and someone reads it like an MT 199. You migrated the format and kept the manual process.
3. The embedded MT 199 is treated as the real message. During transition, a non-adopter can answer the embedded MT 199. If your case system only stores that text, you lose the structured type the requester sent. Store the camt.110 and display the MT 199 as a convenience.
4. Cancellations and investigations share one answer flow. camt.029 answers cancellations, camt.111 answers investigations. A single “MT 196 replacement” handler sends the wrong one.
5. Charges cases are forgotten. RQCH is one of the most common investigation types in correspondent banking, because charges deducted on an OUR payment generate client complaints. If the charges team is not in the routing table, those cases age quietly.

There is also the cover case. A CONR, “we have the customer payment but not the funds”, sends you straight into cover payment reconciliation, and the answer (ICOV, cover initiated) has a matching pacs.009 COV that must reference the same underlying payment.

What should you test?

#	Scenario	Expected result
1	Inbound camt.110 CCNR for a payment you credited	Case created, linked by UETR, routed to inbound queue, camt.111 answer with confirmation of credit
2	Inbound camt.110 RQCH	Routed to charges queue, answer within deadline
3	Inbound camt.110 with embedded MT 199 (non-adopter mode)	Accepted, case created, structured type retained
4	camt.110 for an unknown UETR	Case flagged for manual linking, alert raised, no silent drop
5	Duplicate camt.110 for an open case	Linked to the existing case, no second case
6	camt.110 for a payment already returned	Answer references the return, status consistent with the pacs.004
7	Case passes its response deadline	Escalation fires, audit trail records it
8	Inbound camt.056 FRAD for a payment in progress	Payment blocked, case opened, camt.029 sent with outcome
9	Inbound camt.056 for a payment already credited, customer refuses	camt.029 with rejection reason CUST
10	Accepted cancellation	camt.029 CNCL and pacs.004 with the original UETR
11	Attempt to send MT 192 or MT 195 after the November 2027 cut-off	Blocked and logged
12	Report of cases by type, correspondent, and time to close	Matches the case data exactly

Cases 4 and 5 find most of the defects. Case 12 is the one the operations head will actually look at, so build its expected result from the case data with an independent SQL query, not from the report itself.

The investigation skill itself, following one payment across systems until the trail breaks, is what the Investigate a Duplicate Refund lab practises.

The takeaway

CBPR+ moves investigations from MT 199 free text to camt.110 and camt.111 through SWIFT’s Case Orchestrator, and cancellations to camt.056 and camt.029 through Stop and Recall. Receiving a camt.110 is the first milestone (now June 2027 per SWIFT’s translation FAQ), and November 2027 is when E&I becomes ISO 20022 only. Specify a case model, not a message mapping: a case keyed on UETR, a type-to-queue table, deadlines, structured outcomes, and an explicit lifecycle. Then test the unknown UETR and the duplicate request first, because that is where the defects are.

For where an investigation usually starts, read the gpi Tracker and UETR statuses. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, CBPR+, Payments, Investigations, Requirements