camt.056 — FI to FI Payment Cancellation Request
Asks the receiving agent to cancel a previously sent interbank payment — or, if it already settled, to send the funds back. It opens a case: the sender identifies the original payment, gives a coded reason, and waits for an answer. It is a request, not an instruction. No money moves, nothing is guaranteed, and the answer can be no.
DIRECTION: Sent by the case assigner — typically the debtor agent that wants its payment back — to the case assignee, the next agent in the original payment's chain, and relayed hop by hop or through a clearing mechanism until it reaches the agent holding the funds.
WHO IS INVOLVED
- Case creator / assignerOpens the cancellation case — usually the debtor agent, acting on its own error or on its customer's request — and assigns it to the next agent.
- Case assigneeReceives the request, checks whether it still holds the payment, and either acts on it, passes it on, or answers negatively.
- Creditor agentWhere funds are already credited, decides — often only with the beneficiary's consent — whether the money goes back.
- Beneficiary (creditor)May be asked to consent to returning funds already in their account; without consent, many recalls end in refusal.
KEY FIELDS
This is a curated teaching subset — the full camt.056 message definition contains more elements, including case blocks, control data, and the full original transaction reference. Requirement flags summarise the single context named on each field; recall windows, consent requirements, and reason-code menus are scheme-specific, so check the official ISO 20022 message definition and the rulebook governing your rail.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
Assgnmt/Id | Assignment identification | MANDATORYBase ISO 20022 message definition | A unique reference for this assignment of the case from one party to the next.Each hop of a relayed cancellation request is a new assignment with its own identification — the case travels, the assignment is per leg. |
Assgnmt/Assgnr | Assigner | MANDATORYBase ISO 20022 message definition | Who is handing the case over — the party asking for the cancellation on this leg. |
Assgnmt/Assgne | Assignee | MANDATORYBase ISO 20022 message definition | Who is being asked to deal with the case on this leg.⚠ Sending the request to an agent that never saw the original payment produces a 'no original transaction received' answer and wastes the most time-critical hours of a recall. |
Assgnmt/CreDtTm | Assignment creation date and time | MANDATORYBase ISO 20022 message definition | When this assignment was created — the timestamp that starts the clock on this leg of the case.Scheme rulebooks define windows for submitting recalls and for answering them; timestamps are the evidence in any dispute about deadlines. |
Undrlyg/TxInf/CxlId | Cancellation identification | OPTIONALBase ISO 20022 message definition | A unique reference for this specific cancellation request, assigned by the requester.The reference the answering camt.029 echoes back — persist it, or matching answers to requests becomes guesswork. |
Undrlyg/TxInf/OrgnlGrpInf/OrgnlMsgId | Original message identification | CONDITIONALBase ISO 20022 message definition — mandatory within the original-group block when present | The MsgId of the message that carried the payment to be cancelled, together with its message type in the same block. |
Undrlyg/TxInf/OrgnlEndToEndId | Original end-to-end identification | CONDITIONALBase ISO 20022 message definition — guidelines require enough original references to identify the payment unambiguously | The EndToEndId of the payment the request is about, echoed exactly as it travelled. |
Undrlyg/TxInf/OrgnlUETR | Original UETR | CONDITIONALBase ISO 20022 message definition — echoed when the original payment carried a UETR | The unique tracking identifier of the payment to be cancelled.The UETR is what lets tracking infrastructure route and correlate a cancellation across the whole chain rather than hop by hop — the single most useful identifier in the message. |
Undrlyg/TxInf/OrgnlIntrBkSttlmAmt | Original interbank settlement amount | CONDITIONALBase ISO 20022 message definition — required by the usage guidelines that profile cancellation requests | The amount and currency of the original payment — part of proving you are talking about the right transaction. |
Undrlyg/TxInf/OrgnlIntrBkSttlmDt | Original interbank settlement date | CONDITIONALBase ISO 20022 message definition — required by the usage guidelines that profile cancellation requests | When the original payment settled — it also tells the receiving agent whether it is being asked to stop a payment or claw one back. |
Undrlyg/TxInf/CxlRsnInf/Orgtr | Cancellation originator | OPTIONALBase ISO 20022 message definition | Who wants the payment cancelled — the customer or the bank itself.Schemes care about this distinction: which reason codes are available can depend on whether the customer or the PSP originated the request. |
Undrlyg/TxInf/CxlRsnInf/Rsn/Cd | Cancellation reason code | CONDITIONALBase ISO 20022 message definition — usage guidelines require a coded reason on every request | Why the cancellation is requested, coded from the ISO external cancellation reason set — for example DUPL (duplicate payment), TECH (technical problem), FRAD (fraudulent origin), CUST (requested by the debtor), or AM09 (wrong amount).The reason changes the handling: a fraud-coded recall triggers a different urgency, and in some schemes a different consent and indemnity path, than a duplicate. The rulebook in force defines which codes are available to whom.⚠ Coding a customer's ordinary mistake as FRAD to speed things up mislabels the case, can freeze the wrong things, and erodes trust with the counterpart bank. |
FIELD BY FIELD — FULL STRUCTURE
The whole camt.056 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.FIToFIPmtCxlReq—FI-to-FI Payment Cancellation Request — the body of a camt.056: a bank asking another to cancel a payment.Assgnmt—Assignment — the envelope of a camt case: who assigns the case to whom, and when.IdchoiceDEMO-CAMT056-001MandatoryA unique reference for this assignment of the case from one party to the next.- Use case
- Each hop of a relayed cancellation request is a new assignment with its own identification — the case travels, the assignment is per leg.
Assgnr—MandatoryWho is handing the case over — the party asking for the cancellation on this leg.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
Assgne—MandatoryWho is being asked to deal with the case on this leg.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
CreDtTm2026-07-12T10:15:00ZMandatoryWhen this assignment was created — the timestamp that starts the clock on this leg of the case.- Use case
- Scheme rulebooks define windows for submitting recalls and for answering them; timestamps are the evidence in any dispute about deadlines.
- Example
2026-07-12T09:01:00Z
CtrlData—NbOfTxs1Number of transactions the message carries — a control total the receiver checks against the transactions it finds.- Use case
- The receiver counts the transactions it parsed and rejects the whole message if the tally disagrees.
- Example
<NbOfTxs>2</NbOfTxs>
Undrlyg—Underlying — the original transaction the case is about.TxInf—Transaction Information — details of one original transaction being returned, cancelled, or reported on.CxlIdDEMO-RECALL-001OptionalA unique reference for this specific cancellation request, assigned by the requester.- Use case
- The reference the answering camt.029 echoes back — persist it, or matching answers to requests becomes guesswork.
OrgnlGrpInf—Original Group Information — identifies the original message a return or report refers to.OrgnlMsgIdDEMO-PACS008-001ConditionalThe MsgId of the message that carried the payment to be cancelled, together with its message type in the same block.OrgnlMsgNmIdpacs.008.001.08Original Message Name Identification — the message type being referred to (e.g. pacs.008.001.08).
OrgnlInstrIdDEMO-INSTR-001Original Instruction Identification — the InstrId of the transaction this status/return refers to.OrgnlEndToEndIdDEMO-E2E-001ConditionalThe EndToEndId of the payment the request is about, echoed exactly as it travelled.OrgnlTxIdDEMO-TX-001Original Transaction Identification — the TxId of the transaction this status/return refers to.OrgnlIntrBkSttlmAmt1250.00Ccy=EURConditionalThe amount and currency of the original payment — part of proving you are talking about the right transaction.OrgnlIntrBkSttlmDt2026-07-12ConditionalWhen the original payment settled — it also tells the receiving agent whether it is being asked to stop a payment or claw one back.CxlRsnInf—Cancellation Reason Information — why a cancellation is requested: the originator and a reason code.Orgtr—OptionalWho wants the payment cancelled — the customer or the bank itself.NmDemo Trading 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.CdDUPLConditionalWhy the cancellation is requested, coded from the ISO external cancellation reason set — for example DUPL (duplicate payment), TECH (technical problem), FRAD (fraudulent origin), CUST (requested by the debtor), or AM09 (wrong amount).- Use case
- The reason changes the handling: a fraud-coded recall triggers a different urgency, and in some schemes a different consent and indemnity path, than a duplicate. The rulebook in force defines which codes are available to whom.
- Watch out
- Coding a customer's ordinary mistake as FRAD to speed things up mislabels the case, can freeze the wrong things, and erodes trust with the counterpart bank.
Sources for the field structure4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
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
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
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
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 a sent recall as a completed refund — telling the customer the money is on its way back.Consequence: Recalls are refused for legitimate reasons (funds spent, beneficiary refuses consent, legal constraints); the customer was promised money that never returns, and the complaint lands harder than the original error.Avoid it: Track every cancellation case to a definitive outcome — a pacs.004 with funds or a camt.029 with a refusal — and communicate to customers in terms of a request with an uncertain result.
- Weak identification of the original payment — missing UETR, wrong references, or amounts that do not match.Consequence: The receiving agent cannot locate the transaction and answers 'no original transaction received', costing a full round-trip during the hours when funds are most likely still recoverable.Avoid it: Build the request programmatically from the stored original message so references, UETR, amount, and date are echoes rather than re-keyed data.
- Choosing the wrong reason code — most damagingly, fraud coding for non-fraud cases or vice versa.Consequence: The case follows the wrong path: real fraud handled as an ordinary duplicate moves too slowly to catch the funds; ordinary errors coded as fraud trigger disproportionate action and disputes between banks.Avoid it: Map internal case types to the external reason codes deliberately, restrict fraud codes to cases meeting the institution's fraud criteria, and train operations on the difference.
- Letting cases go stale — no monitoring of whether an answer ever arrived.Consequence: Unanswered recalls silently expire, customers chase the bank instead of the bank chasing the case, and the paper trail is incomplete if the dispute escalates.Avoid it: Run cancellation requests through case management with response deadlines taken from the applicable rulebook, and chase or escalate automatically when they pass.
USAGE CONTEXTS
- SEPA recall (SCT and SCT Inst)In SEPA, camt.056 carries the recall: the originator PSP asks the beneficiary PSP to give a settled credit transfer back, within the time limits and for the reasons the rulebook defines. A positive outcome arrives as a pacs.004 returning the funds; a negative one as a camt.029 with the refusal reason. Consent and, in some situations, the beneficiary's agreement decide the outcome — a recall is never a guarantee.
- Cross-border cancellations (CBPR+)CBPR+ profiles camt.056 for cancellation requests in the correspondent-banking space, correlated by UETR. Whether funds come back depends on where the payment is in the chain, local law, and the beneficiary bank's position — the message standardises the asking, not the answer.
- Before versus after settlementIf the payment has not yet settled at the receiving agent, a cancellation request can stop it outright. Once settled — and especially once credited to the beneficiary — the same message becomes a request to return funds that may legally belong to someone else, which is why outcomes diverge so much.
SEE IT IN A PLAYABLE FLOW
Sources for this reference5
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt.056 FIToFIPaymentCancellationRequest message definition
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 · Cancellation reason code set
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 provisions
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.056 usage guideline
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
What this simplifies: The key-field list is a curated subset; case and control-data blocks are omitted. Recall time limits, consent requirements, and indemnity arrangements differ by scheme and jurisdiction — this page describes the mechanics in general terms, and the rulebook in force defines the actual deadlines and conditions.
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.