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. For the full set of MT-to-ISO 20022 message pairs beyond this investigation cluster — payment returns, cheque messages, financial-institution transfers — the MT to ISO 20022 equivalence lookup indexes each one with an honest equivalence tier.

Direct answer

The message purposes below must be read with the applicable scheme's response rules.

• camt.056 — FIToFIPaymentCancellationRequest. A request to cancel or recall a payment that has already been sent. The instructing side raises it.
• camt.029 — ResolutionOfInvestigation. Can answer a cancellation or legacy investigation request. For SCT and SCT Inst Recall/RFRO, it carries the negative response; the positive response uses pacs.004.
• 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 used across SWIFT cross-border and SEPA recall workflows, but their presence does not establish a universal response sequence. In SCT and SCT Inst, a camt.056 Recall or RFRO receives either a negative camt.029 or a positive pacs.004 returning funds. There is no required positive camt.029 before that pacs.004. camt.110 and camt.111 belong to the newer investigations framework, with staged SWIFT adoption; confirm bank support before building around them.

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. Read the response required by the scheme: for SCT and SCT Inst recalls, camt.029 is negative and pacs.004 is the positive response returning funds.

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. Its ISO purpose includes responses to cancellation and legacy investigation requests. The applicable usage rules determine which outcomes it can carry; the ISO message name alone does not establish a scheme's recall sequence.

For SCT and SCT Inst Recall/RFRO, camt.029 is the negative response. The positive response is pacs.004, which returns the funds. The EPC's SCT implementation guidelines and SCT Inst implementation guidelines define these as alternative response branches. This is a recall-specific distinction: SCT inquiry responses can also use camt.029, including positive responses. For SWIFT/CBPR+ cancellation outcomes, follow the bank's applicable usage guidelines and check any funds movement separately; do not infer a returned payment from a resolution label.

Two things to keep straight. First, camt.029 can answer a cancellation or legacy investigation request; camt.111 answers the newer camt.110 investigation message. Second, a negative recall response 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 not part of the SCT or SCT Inst recall procedure. A camt.056 Recall/RFRO receives a negative camt.029 or a positive pacs.004 returning funds.

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

An investigation points to an original payment, commonly a pacs.008 customer credit transfer. A pacs.002 can report an interbank status, but the gpi Tracker also accepts updates through other channels; its history is not simply a stack of pacs.002 messages. Where settled funds return, pacs.004 is a separate message with its own reference and reason. The status-versus-return reference explains the evidence boundary.

The UETR helps banks correlate the original transfer and subsequent records. Keep it alongside the original message reference and any case or return reference; do not assume every message or customer-facing report exposes the same fields. For the original instruction's identifiers, see the MT103 to pacs.008 field mapping reference; for live tracing, 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.
• MT196/MT296 cancellation responses ↔ camt.029; the same MT numbers used for an exceptions-and-investigations response ↔ camt.111 through Case Management. Which ISO message applies depends on the request being answered.
• MT195/MT295 investigation requests ↔ camt.110 through Case Management. Swift also lists purpose-specific MT199/299 investigation uses against camt.110/111; those free-format types have no single replacement for every use.

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–pacs.008 migration 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 ask for the last available Tracker update. Check separately for any interbank pacs.002 rejection and for any linked pacs.004 return.
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. Read the response under the applicable scheme: SCT/SCT Inst Recall/RFRO has a negative camt.029 or a positive pacs.004 returning funds. For SWIFT/CBPR+, confirm the cancellation outcome and any return with the bank. A camt.111 answers a camt.110 investigation.

When you receive a message:

• A camt.029 against an SCT/SCT Inst Recall/RFRO: read the refusal reason; this is the negative response. The positive response is a pacs.004 returning funds.
• A camt.029 in another workflow: identify the original request and applicable usage rules before interpreting its outcome or expecting a funds movement.
• 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 and the first useful lookup key. Retain it with the original instruction and any case or return reference; do not treat the identifier alone as an outcome.
• 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 field mapping guide — 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 can answer a cancellation or legacy investigation; camt.111 answers camt.110. Check the original request and scheme before choosing the 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 a SEPA recall to use camt.110/111 or a positive camt.029 before funds return. SCT/SCT Inst Recall/RFRO uses camt.056, with a negative camt.029 or a positive pacs.004 returning funds.
• 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. Wait for the scheme's response and confirm any return before promising recovery.
• 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

• The 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.
• SCT / SCT Inst usage: camt.056 requests Recall/RFRO; camt.029 is the negative response, while pacs.004 is the positive response returning funds. camt.110/111 are not part of the SEPA scheme recall procedure. 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.

The public ISO 20022 catalogue establishes message identities and roles, not bank-specific field requirements. camt.110/111 support depends on the rollout stage and institution. The legacy MT–camt mappings describe equivalent purposes, not identical fields; confirm the applicable usage guidelines with your bank.