Exceptions and investigations

IN ONE LINE

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.

WHAT IT ACTUALLY IS

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.

HOW IT WORKS

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.

THE WORDS

Investigation case

The tracked record opened when a payment needs human attention, holding the question asked, the evidence gathered and the outcome reached.

READ FIRST

• A day in payment operations
• R-transactions: reject, return, recall

CONNECTED TO

• FLOW CBPR+ corporate payment — full MX lifecycle
• FLOW Corporate payment — legacy MT lifecycle
• camt.026 camt.026 — Unable to Apply
• camt.027 camt.027 — Claim Non-Receipt
• camt.028 camt.028 — Additional Payment Information
• camt.056 camt.056 — FI to FI Payment Cancellation Request
• camt.029 camt.029 — Resolution of Investigation
• camt.055 camt.055 — Customer Payment Cancellation Request
• camt.110 camt.110 — Investigation Request
• camt.111 camt.111 — Investigation Response
• pacs.002 pacs.002 — FI to FI Payment Status Report
• pacs.004 pacs.004 — Payment Return
• pacs.028 pacs.028 — FI-to-FI Payment Status Request
• MT192 MT192 — Request for Cancellation
• MT195 MT195 — Queries
• MT196 MT196 — Answers
• MT199 MT199 — Free Format Message
• MT292 MT292 — Request for Cancellation
• MT295 MT295 — Queries
• MT296 MT296 — Answers
• MT299 MT299 — Free Format Message
• CHECKPOINT Payment operations checkpoint
• COMPARE MX vs MT corporate payment lifecycle
• EXCEPTION LAB Too late for today: an MT103 that missed the cut-off
• EXCEPTION LAB Whose money is this? A request for information before crediting

SOURCES

• ISO 20022 Catalogue of messages — ISO 20022 Registration Authority
• Payments Signal editorial teaching models — Payments Signal