Lets an initiating party ask its bank or forwarding agent to cancel a previously sent customer payment initiation such as pain.001. It is the customer-side request; if the payment has gone interbank, the bank may need to raise a separate camt.056 downstream.
DIRECTION: Sent by the initiating party or debtor to the party handling the original customer payment instruction, directly or through a forwarding agent.
Version + profile: camt.055 is a message-family identifier, not a complete version. The numeric .001.xx definition and field rules depend on the scheme, service, usage guideline, and implementation version named in each context; sample namespaces show only the illustrated version.
EVIDENCE AT ARM'S REACH
Start with the exact message version, then apply the scheme or network profile that governs your implementation.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
Choose the exact message definition in the official catalogue. The base XSD checks XML structure; it does not prove compliance with a scheme profile.
The network profile that restricts how ISO 20022 payment and reporting messages are used for cross-border traffic.
Adds the November 2026 validation and structured-address changes; implement against the final SR2026 usage guidelines.
Final usage guidelines are published through MyStandards; the public release page gives the implementation timeline.
Open version sourceA fictional corporate request asking its bank to cancel the original pain.001 payment. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:9bdb7244Customer and FI cancellation, resolution, return, reversal, and structured investigation messages.
crc32:f4772381Curated field requirements, contexts, operational meaning, and implementation cautions.
crc32:e4b86f86Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:9d2559edCurated teaching subset. camt.055 can target original groups, payment-information blocks, or transactions and carries richer case and reason information; the current message definition and service rulebook control usage.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
Assgnmt/Id | Assignment identification | MANDATORY | Reference for this cancellation assignment between the parties. |
Assgnmt/Assgnr | Assigner | MANDATORY | Party sending the cancellation request. |
Assgnmt/Assgne | Assignee | MANDATORY | Party expected to handle the request. |
Case/Id | Case identification | OPTIONAL | Case reference used to track the cancellation dialogue. |
Undrlyg/OrgnlGrpInfAndCxl/OrgnlMsgId | Original message identification | CONDITIONAL | Identifies the original pain.001 or other customer initiation being cancelled. |
Undrlyg/OrgnlPmtInfAndCxl/OrgnlPmtInfId | Original payment information identification | CONDITIONAL | Narrows the request to the original payment block. |
Undrlyg/OrgnlPmtInfAndCxl/TxInf/OrgnlEndToEndId | Original end-to-end identification | CONDITIONAL | Identifies the individual business payment. |
Undrlyg/OrgnlPmtInfAndCxl/CxlRsnInf/Rsn/Cd | Cancellation reason | MANDATORY | Coded reason for asking to cancel, such as duplicate or suspected fraud. |
The whole camt.055 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.CstmrPmtCxlReq—Assgnmt—Assignment — the envelope of a camt case: who assigns the case to whom, and when.IdchoiceDEMO-CAMT055-001MandatoryReference for this cancellation assignment between the parties.Assgnr—MandatoryParty sending the cancellation request.Pty—NmDemo Trading LtdName — the free-text name of a party.<Nm>Demo Trading Ltd</Nm>Assgne—MandatoryParty expected to handle the request.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.DEMODEFFXXXCreDtTm2026-07-18T09:08:00ZMandatoryCreation date and time — when this message was created (a UTC timestamp), separate from when the payment is executed.2026-07-12T09:01:00ZCase—IdchoiceDEMO-CUSTOMER-CXL-001OptionalCase reference used to track the cancellation dialogue.Cretr—Pty—NmDemo Trading LtdName — the free-text name of a party.<Nm>Demo Trading Ltd</Nm>Undrlyg—Underlying — the original transaction the case is about.OrgnlGrpInfAndCxl—OrgnlMsgIdDEMO-PAIN001-001ConditionalIdentifies the original pain.001 or other customer initiation being cancelled.OrgnlMsgNmIdpain.001.001.09Original Message Name Identification — the message type being referred to (e.g. pacs.008.001.08).OrgnlPmtInfAndCxl—OrgnlPmtInfIdDEMO-PMT-001ConditionalNarrows the request to the original payment block.TxInf—Transaction Information — details of one original transaction being returned, cancelled, or reported on.OrgnlEndToEndIdDEMO-E2E-001ConditionalIdentifies the individual business payment.CxlRsnInf—Cancellation Reason Information — why a cancellation is requested: the originator and a reason code.Rsn—Reason — the reason, given as a code or proprietary value.CdDUPLMandatoryCoded reason for asking to cancel, such as duplicate or suspected fraud.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.
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. Public guidance states that after 14 November 2026 fully unstructured addresses are removed for in-scope CBPR+ traffic, with explicit message exceptions including admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060.
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. Coexistence for in-scope FI-to-FI payment instructions ended on 22 November 2025, but treatment differs by MT: some instructions are NAKed and selected messages can enter temporary, chargeable contingency conversion. Reporting, initiation, investigations and correspondence follow separate roadmaps.
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.
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt.055 CustomerPaymentCancellationRequest message definition
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
ISO 20022 Standards (Swift ISO 20022 adoption programme) ↗ — Swift · Payment Initiation Relay rulebook
Do not generalise the payment-instruction deadline to every FIN message. Swift publishes differentiated NAK, contingency-conversion, reporting, initiation and exceptions-and-investigations treatment.
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The reference shows one transaction cancellation and omits forwarding-agent variations.
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.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…