ISO 20022 Investigation Messages: A camt Operator Reference

When a cross-border or SEPA payment does not behave — it needs to be recalled, it has stalled, or the beneficiary disputes it — the action moves out of the pacs clearing-and-settlement family and into the camt (cash management) family. Four camt messages do most of the operator-facing work: camt.056, camt.029, camt.110, and camt.111. This reference explains what each one is, which request each response answers, and — the part that trips people up most — how their use changes depending on whether you are in a SWIFT/CBPR+ cross-border flow or a SEPA scheme flow.

The reference deliberately stays at the operator level: message purpose, who sends what, what responds to what, and which scheme actually uses it. It does not reproduce ISO schemas or XSD element trees, and it does not assert field-level mappings that live in gated usage guidelines. Where public documentation is thin or a detail is implementation-specific, that is said plainly rather than smoothed over.

Direct answer

There are two request/response pairs.

• camt.056 — FIToFIPaymentCancellationRequest. A request to cancel or recall a payment that has already been sent. The instructing side raises it.
• camt.029 — ResolutionOfInvestigation. The response to a camt.056 (and to legacy claim and investigation requests). It carries the outcome: cancelled, rejected, or partially actioned, with a reason.
• camt.110 — InvestigationRequest. The newer ISO 20022 message to raise or query an investigation or case.
• camt.111 — InvestigationResponse. The response to a camt.110.

The core caveat is scheme scope. camt.056 and camt.029 are widely used today across both SWIFT cross-border and SEPA recall flows. camt.110 and camt.111 are the newer investigations and case-management framework, and their SWIFT/CBPR+ adoption is phased and implementation-dependent — not universally live in production. SEPA and SCT Inst recalls do not use camt.110/111 at all; they run camt.056 → camt.029 → pacs.004. Get the pairing right (camt.029 resolves a cancellation; camt.111 answers an investigation) and you avoid the most common reading error in this part of the standard.

Where camt messages sit in the ISO 20022 payment flow

ISO 20022 splits payment messaging into families by purpose. The pacs family carries clearing and settlement: pacs.008 moves a customer credit transfer, pacs.009 moves a financial-institution transfer, pacs.002 reports status, pacs.004 returns funds. The camt family covers cash management and, for our purposes, the exceptions-and-investigations layer: cancellations, recalls, and case management.

The sequence matters. A camt message almost always arrives after a pacs.008 has been sent. You cannot cancel or investigate a payment that does not exist yet — the investigation layer references an original payment that has already entered the chain. So the mental model is: pacs.008 goes out, pacs.002 reports how it went, and if something is wrong, a camt message is what you raise against that original payment. For the broader picture of how SWIFT payment processing works end to end — correspondent chains, gpi, and the ISO 20022 migration — start with the pillar reference.

camt.056: cancellation / recall request

camt.056 is FIToFIPaymentCancellationRequest. It is the message a financial institution sends to request that a payment already in flight — or already credited — be cancelled and the funds returned. Operationally you meet it for duplicate payments, suspected fraud, erroneous amounts or beneficiaries, and customer-requested recalls.

Who sends it: the instructing side raises camt.056 toward the agent holding the payment. In a customer-requested recall the originating bank acts on the customer’s instruction; in a bank-initiated recall (for example a duplicate or technical error) the bank raises it directly.

The critical operator point is that a camt.056 is a request, not a guarantee. The receiving agent can refuse — the funds may already have been paid out, or local law may prevent return. The outcome comes back in a camt.029, not in the camt.056 itself.

Scheme difference. In SWIFT/CBPR+ cross-border flows, camt.056 is the cancellation/recall message and is often raised through the gpi Stop and Recall service. In SEPA, camt.056 is also the recall vehicle — both the bank-initiated Recall and the customer-initiated Request for Recall by the Originator (RFRO) use it — but the windows and reason codes are SEPA-scheme-specific. Those reason codes and timing windows live in the SEPA R-transaction reference; this article does not restate them. For the SCT Inst recall mechanics specifically, the SCT Inst rejection and timeout runbook owns that flow.

camt.029: resolution / investigation response

camt.029 is ResolutionOfInvestigation. It is the response message that carries the outcome of a camt.056 cancellation/recall request — and, historically, the outcome of legacy claim and investigation requests as well. When your bank raises a camt.056, the camt.029 that comes back tells you whether the request succeeded.

The outcome semantics are what you read it for. A positive resolution indicates the cancellation was actioned (and a payment return — pacs.004 — typically follows to move the money back). A negative resolution indicates the request was rejected, with a reason: the funds had already been made available, the case was time-barred, or legal/regulatory constraints applied. The exact reason codes carried are defined by the scheme and the ISO definition; in the SEPA context the relevant recall and refusal reason codes are again owned by the SEPA R-transaction reference.

Two things to keep straight. First, camt.029 resolves a cancellation request (camt.056) — it is not the response to the newer camt.110 investigation message. Second, a camt.029 closing a recall as rejected does not mean the money is gone forever; it means that recovery route failed, and a different procedure (a fraud claim, a chargeback-equivalent, or a legal route) may still apply.

camt.110 and camt.111: case-management messages

camt.110 (InvestigationRequest) and camt.111 (InvestigationResponse) are the newer ISO 20022 investigations and case-management framework — the redesign intended to streamline the older, sprawling exceptions-and-investigations message set into a cleaner request/response model. camt.110 raises or queries an investigation or case; camt.111 is the response.

This is where accuracy matters most, because it is easy to overstate where these are. Their SWIFT/CBPR+ adoption is phased and partly forward-looking. Live production usage is limited and depends on the implementation stage of the institutions involved. Many cross-border investigation flows today still combine camt.056/camt.029 with free-format messaging, and the case-management rollout is staged rather than switched on everywhere at once. Treat camt.110/111 support as something you confirm with your bank against their published usage guidelines and the current CBPR+ roadmap — not as a universal capability you can assume.

And to be explicit about scope: camt.110/111 are a SWIFT/CBPR+ cross-border construct. They are not part of the standard SEPA or SCT Inst recall flow. A SEPA recall is camt.056 → camt.029 → pacs.004. If you are working a euro-area scheme payment, camt.110/111 are not the path.

How camt messages connect to pacs.008 and pacs.002

Every investigation references an original payment. That original is the pacs.008 (the customer credit transfer), and its status history is the pacs.002 (the FI-to-FI status report). When you raise a camt.056 or a camt.110, you are pointing at a specific pacs.008 and, usually, at the pacs.002 status that told you something was wrong.

The thread that ties them together is the UETR — the unique end-to-end transaction reference generated by the originating bank and carried unchanged through the chain. The same UETR appears in the original pacs.008, in each pacs.002 status update, and in any camt.056 cancellation or camt.110 investigation raised against that payment. That is why the UETR is the first thing to capture: it is the single key that lets a bank locate the payment and stitch its full history. For the field-level relationship between the original instruction and its identifiers, see the MT103 to pacs.008 field mapping reference; for the live tracing workflow — pulling pacs.002 status and reading gpi codes — see the SWIFT payment tracing runbook.

Legacy MT investigation mapping context

Operators who came up on MT messages will recognise the camt set as the successor to the old exceptions-and-investigations traffic. The equivalences below are useful for orientation, but each is broadly equivalent at the purpose level — not field-identical, and exact element-by-element MT↔camt mappings are not asserted here.

• MT n92 (request for cancellation, e.g. MT192/MT292) ↔ camt.056 — the cancellation/recall request.
• MT n96 (answers, e.g. MT196/MT296) ↔ camt.029 — the resolution/response.
• MT n95/n96 (queries and answers) and the free-format MT 195/199/299 series ↔ the camt investigation set (the camt.110/111 framework and its predecessors) — the structured replacement for free-text enquiries.

The MT–ISO 20022 coexistence for SWIFT cross-border payment instructions ended 22 November 2025, after which pacs.008 under CBPR+ is the live format (see the MT103 to pacs.008 field mapping reference for the migration detail). The practical consequence for investigations is that the structured camt messages are now the forward path, even though free-format correspondence persists in practice while the camt.110/111 framework’s adoption is still phased.

Operator investigation workflow

This section is PaymentBrief operator guidance — a workflow built on the message roles above, not a scheme-published procedure.

When you need to raise a recall or investigation:

1. Identify the original payment by its UETR, and pull its pacs.002 status history so you know its last known state before acting.
2. Decide the action. If you need the money back (duplicate, fraud, error), that is a cancellation — your bank raises a camt.056. If you need information or a case opened (where did it go, why is it stuck), that is an investigation — potentially a camt.110, if your bank supports it.
3. Provide the reason and any supporting reference (original message ID, amount, value date, parties). For SEPA recalls, the reason code set is scheme-defined.
4. Wait for the response and read it correctly: a camt.029 resolves a camt.056; a camt.111 answers a camt.110.

When you receive a message:

• A camt.029 against your recall: read the outcome and reason. Positive usually means a pacs.004 return is coming; negative means that route failed — consider alternatives.
• A camt.111 against your investigation: read the case status and any next action requested of you.

Identifier checklist

Capture these before escalating. Which subset your bank requires is implementation-specific — confirm their expected reference set rather than assuming.

• UETR — the unique end-to-end transaction reference. The single most useful key in SWIFT cross-border investigations; it threads the original pacs.008, its pacs.002 statuses, and any camt message together. Capture this first.
• EndToEndId — the originator’s own end-to-end reference (invoice, PO, contract). May read as NOTPROVIDED on payments that originated as, or were translated from, MT messages — so it is not always a usable search key.
• InstrId — the point-to-point instruction reference. Changes at each bank hop, so it is useful for correlating one bank’s record, not for end-to-end matching.
• TxId — a transaction-level reference where the instructing bank populates it; population is implementation-dependent and not universal.
• Original message identification — the message ID of the original instruction, used to point a cancellation or investigation at the right payment.
• Case ID — the case reference your bank assigns once an investigation is opened; quote it on every follow-up so the thread stays attached to one case.

This identifier framing mirrors the one established in the MT103 to pacs.008 field mapping reference — the same identifiers, applied to the investigation layer rather than the original instruction.

Message-by-message comparison table

Common mistakes

• Confusing camt.029 with camt.111. camt.029 resolves a camt.056 cancellation; camt.111 answers a camt.110 investigation. Reading a camt.029 as if it were an investigation response (or vice versa) leads to the wrong next action.
• Assuming camt.110/111 are live everywhere. They are the newer case-management framework with phased, implementation-dependent adoption. Building a process that requires camt.110 support before confirming your bank actually offers it will stall.
• Expecting SEPA to use camt.110/111. It does not. SEPA and SCT Inst recalls run camt.056 → camt.029 → pacs.004. Raising or expecting a camt.110 against a SEPA payment is a category error.
• Treating a camt.056 as a guaranteed reversal. It is a request. The funds may already be paid out, or return may be legally blocked. The camt.029 carries the real outcome — wait for it.
• Escalating without the UETR. A missing UETR is the most common cause of a slow investigation. Capture it (and the original message references) before you contact your bank.

Bank / PSP escalation checklist

PaymentBrief operator guidance — what to have ready before contacting your bank.

• The UETR of the original payment.
• The action you want: cancellation/recall (camt.056) versus information/case (camt.110, if supported).
• The reason: duplicate, fraud, error, customer recall — and for SEPA, the scheme reason code that applies.
• The original payment details: value date, settlement amount and currency, debtor agent and creditor agent BICs, original message identification.
• The EndToEndId / InstrId / TxId you hold (noting EndToEndId may be NOTPROVIDED).
• Any case ID already assigned, for follow-ups.
• A clear question phrased by message type — for example, “raise a camt.056 recall for UETR [xxx] with reason [code],” or “does your case-management support camt.110 for this corridor?”

Related references

• MT103 to pacs.008 field mapping reference — the original-instruction identifiers (UETR, EndToEndId, InstrId, TxId) that investigations point at, and the MT–MX migration context.
• SWIFT payment tracing runbook — pulling pacs.002 status, reading gpi codes, and triaging a stalled payment before you escalate.
• SWIFT payment processing: MT103, gpi, and ISO 20022 — the pillar reference for how cross-border payments and their messaging fit together.
• SCT Inst rejection and timeout runbook — the SEPA SCT Inst recall mechanics (camt.056 in the instant-payment context).
• SEPA return and reject codes: the R-transaction reference — SEPA recall windows and reason codes (do not look for them here).

Scope note

This reference separates five layers deliberately — keep them distinct when applying anything below:

• ISO 20022 message purpose (what the standard defines): camt.056 = FIToFIPaymentCancellationRequest; camt.029 = ResolutionOfInvestigation; camt.110 = InvestigationRequest; camt.111 = InvestigationResponse. These identities come from the public ISO 20022 message catalogue.
• CBPR+ usage (SWIFT cross-border): camt.056/camt.029 are in live use; camt.110/111 are the newer investigations framework whose adoption is phased and implementation-dependent, not universally live in production.
• SEPA / SCT Inst usage: recalls run camt.056 → camt.029 → pacs.004. camt.110/111 are not part of the SEPA scheme recall flow. Reason codes and timing windows are owned by the SEPA R-transaction reference and the SCT Inst runbook.
• Bank / PSP implementation variation: which identifiers are required, whether camt.110/111 is supported, and how free-format messaging is still used all vary by institution — confirm against your bank’s published usage guidelines.
• PaymentBrief operator guidance: the investigation workflow, identifier checklist, and escalation checklist are PaymentBrief guidance built on the message roles — they are not scheme-published procedures.

No gated SWIFT MyStandards field-level usage guidelines were used. Message identities and request/response pairings are anchored to the public ISO 20022 catalogue; the camt.110/111 adoption position is marked estimated because it is forward-looking; the legacy MT↔camt equivalences are stated at the purpose level only and caveated as broadly equivalent, not field-identical.