Payments - Introduction / Learning brief
Payment exceptions and investigations
Your notes
In simple terms / 01
What this means in plain language
Describes how operations teams triage failed, rejected, and queried payments, how they establish where the funds and settlement stand, and how an investigation case is opened, chased, and closed on evidence.
Most payments complete without anyone touching them, and operations teams exist for the ones that do not. It helps to separate two kinds of problem. Exceptions are structured deviations the machinery handles largely automatically — a payment rejected for a bad account number, or returned with a reason code — processed as ordinary flow. Investigations are cases that need human judgment: a claim that money never arrived, a suspected duplicate, a request to cancel or recall funds already sent, or a question about an unclear payment. Every investigation turns on references, the payment's exact identifiers, quoted so the receiving bank can find one payment among millions. A disciplined desk first establishes what actually happened from its own records, because a surprising share of “missing” payments are simply sitting in a local repair or screening queue. A case closes only when the money and the explanation are both where they should be.
Complete lesson / 02
Understand the full idea, step by step
Most payments go exactly as intended, which is why the ones that do not need a place to go. That place is the exceptions queue: a work list where anything the machinery could not finish on its own waits for a human to decide what happens next. Learn to read that queue and you understand how a bank keeps its promises when the happy path breaks.
Exception versus investigation — structured deviation versus judgement-led case
The desk's work divides in two. An exception is a structured deviation the machinery mostly handles itself: a payment stopped before settlement for a bad field (a repair item), or returned after settlement with a coded reason. An investigation is a case that needs a person: a claim of non-receipt, a suspected duplicate, a request to cancel or recall money already gone, or a query about a payment whose purpose is unclear. Exceptions flow down defined paths; investigations are opened, chased, and closed on evidence.
What sits in the queue
- Repair
- A payment held because a field is missing or invalid — fix and release, or reject
- Unable to apply
- Money arrived but the beneficiary cannot be identified — more detail needed
- Claim non-receipt
- The payer or beneficiary says funds sent never turned up
- Duplicate
- The same payment appears to have been sent twice
- Case assignment
- Each item gets an owner, a priority by age and value, and any regulatory deadline
The life of Maya's case
- INSTRUCTION
The case opens with the original payment attached, so every later step can quote the same identifiers.
- VALIDATION
Maya looks inward first: is the payment sitting in Bank Alfa's own repair, funds-control, or screening queue? A large share of "missing" payments never left.
- MESSAGE
It did leave. So Maya sends an outbound query or cancellation request to the next bank, quoting the transaction and end-to-end references and the settlement date.
- NOTIFICATION
She chases on a schedule until it resolves, and tells Asha Traders honestly: a recall is a request, not a guaranteed refund — nothing is promised until the money returns.
- LEDGER
The case closes only when the money and the audit trail agree — a completed credit, a booked return, or a documented dead end.
UETR — unique end-to-end transaction reference
A UETR is a single reference carried unchanged across every hop of a cross-border chain. Because it never changes, a bank can ask a payment's status directly — where it is, which bank last held it — instead of chasing the chain link by link. That one identifier has turned many day-long investigations into a lookup: the central question in any incident is *which stage did the payment last complete, and therefore where do the funds sit?*
COMMON CONFUSION
“When a customer reports a missing payment, the desk should recall it and refund the customer straight away.”
A recall is a question to the bank holding the money, not a switch that pulls it back. The funds might be settled and already credited to the beneficiary, who must agree before anything returns. A good desk promises nothing to the customer until the money is actually back — funds honesty is what separates a sound investigation from a false reassurance.
WHAT IF — The same payment was sent twice — a duplicate
What happens: Only one payment is owed, so the second must be stopped before it settles or returned after. If it is still queued, it can be cancelled internally; if it has settled, it can only come back from the receiving side.
How it is handled: Maya quotes the original identifiers on a cancellation request and, in parallel, feeds back the root cause — the channel or correspondent that produced the resend — because an investigations desk that only closes cases without fixing causes will keep handling the same one forever.
STRICTLY SPEAKING
Strictly speaking, where a payment can be stopped depends entirely on how far it has travelled. A payment still in a queue can be halted internally; one already settled can only be returned by the receiving bank; one held in suspense at the beneficiary bank is waiting on a correction. A payment status report — returned in ISO 20022 as a pacs.002 — often answers "where is it?" without a full investigation. Real schemes set their own procedures and deadlines, so the exact steps vary by rail and jurisdiction.
FOR NOW, REMEMBER
- Exceptions are structured deviations the machinery handles down defined paths; investigations are judgement-led cases a person opens, chases, and closes on evidence.
- The first move on a claimed-missing payment is inward: most "lost" payments are sitting in a local repair, funds-control, or screening queue.
- A recall is a request, not a guaranteed refund — nothing is promised to the customer until the money is actually returned.
- The key question in any incident is where the funds sit, and a UETR often answers it as a lookup rather than a chase.
TRY IT YOURSELF
Asha Traders reports that a EUR 12,400.00 payment sent yesterday never reached its supplier. What should Maya do first?
Maya has decided the payment must be questioned or recalled. The next lesson is the toolkit she uses to say so across banks: the MT investigation messages and their structured ISO 20022 successors.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Exceptions are structured, largely automated deviations, while investigations are cases that need human judgment.
- 02
Every case turns on quoting the original payment's exact identifiers, because the receiving bank must find one payment among millions.
- 03
A request to recall or cancel funds is a question, not a refund, so nothing is promised to the customer until the money actually returns.
Practical use cases / 04
Where you would use this
An investigations analyst opens a case for a claim of non-receipt and checks internal queues before querying another bank.
An operations team sends a cancellation request for a payment a customer reports as a duplicate.
A service desk uses a payment's end-to-end tracking reference to tell a corporate exactly where its transfer currently sits.
Worked example / 05
Put the idea into a real situation
Illustrative example: a customer of a fictional bank, Meridian Trust, reports that a EUR 12,500.00 transfer sent on 2026-06-03 never reached the beneficiary at another fictional bank, Cedar Union. The investigations desk first checks its own records and finds the payment left on time, so it sends a cancellation and request-for-information message quoting the original transaction identifier, the end-to-end reference, the amount EUR 12,500.00, and the settlement date. Cedar Union replies that the funds are sitting in a suspense account because the account number failed validation. The case closes when Cedar credits the corrected account and both banks' records agree.
Evidence & review / 07
Evidence & review
Correspondent-banking and cross-border exception handling; team structures, priority rules and deadlines vary by institution, rail and jurisdiction.
What this brief simplifies: Uses one illustrative case and a linear lifecycle; real desks run many parallel cases with rail-specific procedures, reason codes and regulatory time limits.
Sources for this brief4
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.
- Market practice
Swift gpi (global payments innovation) ↗ — Swift · UETR-based payment tracking and status
Only public summaries are used here; the full service definition and rulebook sit behind a swift.com account.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.002 payment status report; camt investigation messages
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · Cross-border exception and investigation handling
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.