Exceptions and investigations
When a payment goes wrong after it has left: cases, queries, cancellation requests, and the discipline that gets money and explanations back.
L0 Explain simply
An everyday analogy: an airline's lost-luggage desk. The vast network works — bags fly, arrive, appear on the belt. The desk exists for the ones that do not, and everything at that desk starts from the tag number. Payments have the same desk. A sender says the money never arrived; a bank suspects it paid twice; a beneficiary bank asks what an odd-looking credit was for. Each becomes a case, each case lives or dies by references — the payment's identifiers quoted exactly — and each closes only when the money and the explanation are both in the right place. The desk's quiet second job is telling the airline which routes keep losing bags, so the network itself gets better over time.
L1 Core concepts
It helps to split exceptions from investigations. Exceptions are structured deviations the machinery handles largely automatically — rejects and returns with reason codes, processed as normal flow. Investigations are cases needing judgment: a claim of non-receipt, a suspected duplicate, a request to cancel or recall funds already gone, a request for more information about a payment. The message toolkit overlaps SEPA's r-transactions: a camt.056 asks for a payment to be cancelled or recalled; a camt.029 carries the answer or the outcome of an investigation. What makes any of it workable is correlation — quoting the original payment's identifiers exactly — because the receiving bank must find one payment among millions. Institutions organise this work differently: dedicated investigations teams, service desks, or hybrids.
L2 Practitioner view
A case lifecycle: open it with the original payment attached; establish what actually happened from your own records before asking anyone else — a surprising share of 'missing' payments are sitting in a local repair or screening queue; send the outbound query or cancellation request; chase on a schedule; resolve; close with the money and the audit trail agreeing. Two disciplines separate good desks from bad ones. First, funds honesty: a recall or cancellation request is a question, not a refund — nothing is promised to the customer until funds actually return. Second, root-cause routing: investigations are the system's error log, and a desk that only closes cases — without feeding back the correspondent that truncates references or the channel producing malformed addresses — will handle the same case forever. Aging and value drive priority; regulatory deadlines trump both.
L3 Technical details
Mechanically, everything rides on identifier discipline. A camt.056 quotes the original transaction id, end-to-end id, amount, and settlement date; a camt.029 answers the specific request it names. In correspondent banking, the UETR — the unique end-to-end reference carried network-wide — lets a bank query a payment's status and location directly, turning many former day-long investigations into lookups. Rail differences matter to the desk: SEPA gives exceptions a tight structure with defined procedures and deadlines, while classic correspondent flows long leaned on free-format messages, with ISO 20022 progressively structuring them. The linked scenarios — a missed cut-off and a cross-border request for information — show both flavours. Whatever the rail, the case is not the customer's problem statement; it is the payment's identifiers plus the evidence, and it closes on evidence.
Sources & standards1
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt — exceptions and investigations messages
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Sources for this topic2
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt message family
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The case lifecycle is a composite; real desks differ in team structure, tooling, service levels, and where the boundary between exceptions and investigations is drawn. The linked scenarios use fictional banks and customers throughout.
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.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.