camt.029ISO 20022

camt.029 — Resolution of Investigation

Answers an investigation case — most commonly a cancellation request sent as camt.056. It tells the requester what happened: the cancellation was accepted, it was rejected with a coded reason, or it is still pending. It closes (or updates) the case; if funds actually come back, they travel separately in a pacs.004. Like all camt investigation messages, it carries information, never money.

DIRECTION: Sent by the case assignee — the agent that was asked to cancel or investigate — back to the case creator or assigner that sent the request.

Contributor Shubham Mathure12 July 2026

WHO IS INVOLVED

Case assigneeInvestigates the request — checking the payment's status, and where needed the beneficiary's consent — and issues the resolution.
Case creator / assignerReceives the answer, matches it to the open case, and acts on it: awaiting the return, informing the customer, or escalating a refusal.
Intermediary agentsWhere the request travelled hop by hop, relay the resolution back along the same path.

KEY FIELDS

This is a curated teaching subset — the full camt.029 message definition covers more than cancellation answers, including modification and claim-related resolutions, compensation, and corrective transaction references. Requirement flags summarise the single context named on each field; response obligations and deadlines are scheme-specific, so check the official ISO 20022 message definition and the rulebook governing your rail.

Key fields of camt.029
FIELD	NAME	PRESENCE	WHAT IT MEANS
`Assgnmt/Id`	Assignment identification	MANDATORYBase ISO 20022 message definition	A unique reference for this assignment of the answer from the assignee back toward the case creator.
`Assgnmt/Assgnr`	Assigner	MANDATORYBase ISO 20022 message definition	Who is sending this resolution — on the answering leg, the party that investigated.
`Assgnmt/Assgne`	Assignee	MANDATORYBase ISO 20022 message definition	Who the resolution is addressed to — the party waiting for the answer.
`Assgnmt/CreDtTm`	Assignment creation date and time	MANDATORYBase ISO 20022 message definition	When the resolution was created — evidence for whether the answer met the response window the applicable rulebook defines.
`RslvdCase/Id`	Resolved case identification	CONDITIONALBase ISO 20022 message definition — used when the resolution closes an identified case	The identification of the case being resolved, echoing the case opened by the request.⚠ If the case identification does not match what the requester opened, the answer strands in a queue while the original case looks unanswered.
`Sts/Conf`	Confirmation status	CONDITIONALBase ISO 20022 message definition — the summary answer when responding to a cancellation request	The headline answer, coded from the ISO external confirmation set — for example CNCL (cancelled as requested), RJCR (cancellation request rejected), or PDCR (cancellation request pending).This one code decides the workflow: CNCL means expect funds (or confirm the stop), RJCR means the recall failed and the customer conversation changes, PDCR means keep the case open.⚠ Automations that only handle CNCL and RJCT-style finals and ignore pending statuses leave cases in limbo when the real world needs more time — for example while the beneficiary is asked for consent.
`CxlDtls/TxInfAndSts/OrgnlEndToEndId`	Original end-to-end identification	CONDITIONALBase ISO 20022 message definition — used when transaction-level detail is reported	The EndToEndId of the payment the investigated cancellation was about, echoed so the answer matches the right transaction.
`CxlDtls/TxInfAndSts/OrgnlUETR`	Original UETR	CONDITIONALBase ISO 20022 message definition — echoed when the original payment carried a UETR	The unique tracking identifier of the underlying payment, repeated in the answer.With the UETR present, tracking infrastructure can show request and resolution as one story across the chain.
`CxlDtls/TxInfAndSts/TxCxlSts`	Transaction cancellation status	OPTIONALBase ISO 20022 message definition	The per-transaction verdict on the cancellation — accepted or rejected for this specific payment — alongside the message-level confirmation.Matters when one case covers several transactions with different outcomes; the transaction level is where the truth lives.
`CxlDtls/TxInfAndSts/CxlStsRsnInf/Rsn/Cd`	Cancellation status reason code	CONDITIONALBase ISO 20022 message definition — expected when the cancellation is rejected or pending	Why the request was refused or is still open, coded from the ISO external set — for example CUST (customer decision), LEGL (legal decision), NOAS (no answer from the customer), NOOR (no original transaction received), or ARDT (the payment has already been returned).Each code points somewhere different: ARDT says go match the pacs.004 you already received; NOOR says your request went to the wrong agent or the references were wrong; LEGL says stop pushing and involve legal or compliance.⚠ Reading every refusal as final. NOAS after a consent request is a different situation from LEGL — some codes leave room for a follow-up, others close the door.

FIELD BY FIELD — FULL STRUCTURE

The whole camt.029 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.

Document—The root of an ISO 20022 message — the business payload, which a Business Application Header (head.001) accompanies as a separate document.
- RsltnOfInvstgtn—Resolution of Investigation — the body of a camt.029: the answer to a cancellation request or case.
  - Assgnmt—Assignment — the envelope of a camt case: who assigns the case to whom, and when.
    IdchoiceDEMO-CAMT029-001MandatoryA unique reference for this assignment of the answer from the assignee back toward the case creator.
    Assgnr—MandatoryWho is sending this resolution — on the answering leg, the party that investigated.
    Agt—
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOGB2LXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    Assgne—MandatoryWho the resolution is addressed to — the party waiting for the answer.
    Agt—
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    CreDtTm2026-07-14T11:05:00ZMandatoryWhen the resolution was created — evidence for whether the answer met the response window the applicable rulebook defines.
    Use case
    A processing timestamp for the message — distinct from the requested execution or settlement date.
    Example
    2026-07-12T09:01:00Z
  - RslvdCase—Resolved Case — the case this camt.029 responds to.
    IdchoiceDEMO-RECALL-001ConditionalThe identification of the case being resolved, echoing the case opened by the request.
    Watch out
    If the case identification does not match what the requester opened, the answer strands in a queue while the original case looks unanswered.
    Cretr—
    Agt—
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
  - Sts—Status — the resolution status of the case.
    ConfRJCRConditionalThe headline answer, coded from the ISO external confirmation set — for example CNCL (cancelled as requested), RJCR (cancellation request rejected), or PDCR (cancellation request pending).
    Use case
    This one code decides the workflow: CNCL means expect funds (or confirm the stop), RJCR means the recall failed and the customer conversation changes, PDCR means keep the case open.
    Watch out
    Automations that only handle CNCL and RJCT-style finals and ignore pending statuses leave cases in limbo when the real world needs more time — for example while the beneficiary is asked for consent.
  - CxlDtls—Cancellation Details — the details of the transaction whose cancellation is being answered.
    TxInfAndSts—Transaction Information and Status — the status of one original transaction, keyed by its original references.
    CxlStsIdDEMO-CXLSTS-001Cancellation Status Identification — the reference for this cancellation-status answer.
    OrgnlGrpInf—Original Group Information — identifies the original message a return or report refers to.
    OrgnlMsgIdDEMO-PACS008-001Original Message Identification — the MsgId of the message being reported on, returned, or cancelled.
    OrgnlMsgNmIdpacs.008.001.08Original Message Name Identification — the message type being referred to (e.g. pacs.008.001.08).
    OrgnlEndToEndIdDEMO-E2E-001ConditionalThe EndToEndId of the payment the investigated cancellation was about, echoed so the answer matches the right transaction.
    OrgnlUETR6f9619ff-8b86-4e9f-a6dd-2cce35e4b321ConditionalThe unique tracking identifier of the underlying payment, repeated in the answer.
    Use case
    With the UETR present, tracking infrastructure can show request and resolution as one story across the chain.
    TxCxlStsRJCROptionalThe per-transaction verdict on the cancellation — accepted or rejected for this specific payment — alongside the message-level confirmation.
    Use case
    Matters when one case covers several transactions with different outcomes; the transaction level is where the truth lives.
    CxlStsRsnInf—Cancellation Status Reason Information — why a cancellation request was accepted or rejected.
    Orgtr—Originator — the party that originated this return, cancellation, or status.
    NmExample Supplies LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
    Rsn—Reason — the reason, given as a code or proprietary value.
    CdLEGLConditionalWhy the request was refused or is still open, coded from the ISO external set — for example CUST (customer decision), LEGL (legal decision), NOAS (no answer from the customer), NOOR (no original transaction received), or ARDT (the payment has already been returned).
    Use case
    Each code points somewhere different: ARDT says go match the pacs.004 you already received; NOOR says your request went to the wrong agent or the references were wrong; LEGL says stop pushing and involve legal or compliance.
    Watch out
    Reading every refusal as final. NOAS after a consent request is a different situation from LEGL — some codes leave room for a follow-up, others close the door.

Sources for the field structure4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

COMMON ERRORS

Treating an accepting camt.029 as the money itself.Consequence: The case is closed and the customer told the refund arrived, while the actual pacs.004 is still outstanding — if it never comes, nobody is watching.Avoid it: Close recall cases only on receipt and reconciliation of the returned funds; a positive resolution moves the case to 'awaiting return', not to 'done'.
Failing to match the resolution to the open case — mismatched case identifiers or missing original references.Consequence: The answer sits unlinked while the requester's case ages toward its deadline, and the same question gets asked again through manual channels.Avoid it: Echo the requester's case and cancellation identifiers exactly as received, and match inbound resolutions on those identifiers plus the UETR.
Handling only the final statuses and dropping pending answers on the floor.Consequence: Cases that legitimately need time — beneficiary consent, legal review — look abandoned; follow-ups and escalations fire wrongly or not at all.Avoid it: Model pending as a first-class case state with its own re-review timer, distinct from both acceptance and rejection.
Ignoring the refusal reason code when telling the customer the recall failed.Consequence: The customer gets a generic 'not possible' when the code actually said 'already returned' (the money is back, look again) or 'legal decision' (a materially different situation) — wrong advice from right data.Avoid it: Translate each refusal reason into a distinct customer-facing explanation and internal next step, and audit that mapping against the external code list when it changes.

USAGE CONTEXTS

SEPA recall answersIn the SEPA schemes, camt.029 is the negative or interim side of the recall dialogue: the beneficiary PSP uses it to refuse a recall with a coded reason within the response window the rulebook defines. The positive outcome is not a camt.029 with funds — it is a pacs.004 payment return.
Cross-border case resolution (CBPR+)CBPR+ profiles camt.029 as the response to camt.056 in the correspondent-banking space, correlated by case references and UETR, so both banks hold a structured record of how the cancellation ended.
Investigations beyond cancellationsThe message definition also serves as the resolution for other investigation types in the camt family. In practice most payment-operations traffic you will meet is the cancellation dialogue; the broader investigation usages vary by market and are being reshaped by newer exchange models between institutions.

SEE IT IN A PLAYABLE FLOW

Sources for this reference5

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt.029 ResolutionOfInvestigation message definition
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Investigation confirmation and cancellation status reason code sets
Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · Recall response provisions
Governs the SEPA Credit Transfer scheme: participant obligations, datasets, time cycles, and r-transaction rules for euro credit transfers. · Effective 2025-10-05 · Checked 2026-07-12
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · camt.029 usage guideline
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: The key-field list is a curated subset focused on the cancellation dialogue; modification, claim, and compensation elements are omitted. The status and reason codes named are the most commonly met values from longer external code sets, and response deadlines are described only as rulebook-defined windows, not specific durations.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.