GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

GET IN TOUCH
04 / OPERATIONS & ARCHITECTURE12 MIN

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.

Contributor Shubham Mathure

NOT STARTED

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
  1. Official requirement

    ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt — exceptions and investigations messages

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

SEE THE PAYMENT MOVE

CBPR+ corporate payment — full MX lifecycle — swimlane diagramOne corporate payment from pain.001 initiation through pacs.008 execution, status, settlement, exceptions, and camt account reporting — with every conditional step labelled. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
CBPR+ corporate payment — full MX lifecycle. A teaching composite across customer initiation, CBPR+ execution, Case Management, and bank-to-customer reporting. Not every bank sends every status or report, and mutually exclusive reject, return, and recall outcomes are shown as branches. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    Treasury sends the payment instructionAsha Traders treasury → Bank Alfa (debtor agent) · pain.001

    Asha Traders asks Bank Alfa to pay one supplier. The pain.001 is a customer instruction, not an interbank payment and not proof that funds moved.

  2. 02Processing
    Bank Alfa validates the instructionBank Alfa (debtor agent)

    The bank checks authority, account and address data, duplicate references, available funds, cut-off time, and sanctions-screening results before accepting the instruction.

    Screening checkpoint: Customer-payment screening — Debtor, creditor, agents, addresses, and remittance data are screened before release.

  3. 03Message
    Treasury receives an accepted statusBank Alfa (debtor agent) → Asha Traders treasury · pain.002

    A pain.002 says the instruction passed the reported checks and was accepted for processing. It does not say the supplier has been credited; banks choose which lifecycle statuses their service reports.

  4. 04Posting
    Bank Alfa debits the corporate accountBank Alfa (debtor agent)

    Bank Alfa books the customer debit. The debit and the interbank settlement are separate ledger events and can occur at different times under the account agreement.

    • DR Asha Traders USD operating account — USD 125,000.00
  5. 05Message
    Treasury receives an entry notificationBank Alfa (debtor agent) → Asha Traders treasury · camt.054

    Where the service provides it, a camt.054 reports the booked debit promptly and carries structured references for cash application. It reports an account entry; it does not create the entry.

  6. 06Message
    Bank Alfa sends the interbank paymentBank Alfa (debtor agent) → Meridian Bank (correspondent) · pacs.008

    Bank Alfa turns the accepted customer instruction into a pacs.008. The UETR, end-to-end reference, parties, agents, amounts, and remittance data identify the same business payment on the interbank leg.

  7. 07Processing
    Meridian validates and screens the paymentMeridian Bank (correspondent)

    The correspondent applies CBPR+ validation, sanctions screening, routing checks, and a cover check before it books or forwards the payment.

    Screening checkpoint: Correspondent screening — Every bank in the chain makes its own decision; an upstream pass does not bind a downstream bank.

  8. 08Settlement
    The correspondent settles the interbank legMeridian Bank (correspondent)

    Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. This book transfer is the value movement; the pacs.008 is the instruction describing it.

    This teaching corridor uses correspondent-book settlement in commercial bank money. Other CBPR+ payments may use different correspondents or market infrastructures.

    • DR Bank Alfa USD account at Meridian — USD 125,000.00
    • CR Nordbank USD account at Meridian — USD 125,000.00
  9. 09Message
    The payment reaches NordbankMeridian Bank (correspondent) → Nordbank (creditor agent) · pacs.008

    Meridian forwards the customer credit transfer with the original UETR and structured payment data so Nordbank can identify the supplier and reconcile the incoming cover.

  10. 10Processing
    Nordbank validates the incoming paymentNordbank (creditor agent)

    Nordbank checks the supplier account, screens the payment, and confirms that the incoming value and instruction can be matched before it credits the customer.

  11. 11Posting
    Nordbank credits the supplierNordbank (creditor agent)

    Nordbank books the credit to Northstar Components. The supplier can now use the funds; any later recovery request must respect that settled and credited state.

    • CR Northstar Components USD account — USD 125,000.00
  12. 12Message
    An interbank status closes the processing loopNordbank (creditor agent) → Bank Alfa (debtor agent) · pacs.002

    Where the service and status point provide it, a pacs.002 reports the interbank outcome against the original pacs.008. A transport acknowledgement and a payment status are different signals.

  13. 13Message
    Treasury receives the intraday account reportBank Alfa (debtor agent) → Asha Traders treasury · camt.052

    If contracted, camt.052 gives Asha an intraday view of balances and entries, including the debit and its references. It is an interim report, not the final daily statement.

  14. 14Message
    The end-of-day statement closes reconciliationBank Alfa (debtor agent) → Asha Traders treasury · camt.053

    Bank Alfa sends the booked statement for the account. Treasury matches the camt.053 entry to its pain.001 transaction using the end-to-end and account-servicer references.

Corporate payment — legacy MT lifecycle — swimlane diagramThe legacy MT path from MT101 and MT103 through cancellation, investigations, returns, confirmations, and statements — with explicit no-equivalent and migration notes. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
Corporate payment — legacy MT lifecycle. A legacy teaching composite, not a recommendation to start new MT implementations. It joins corporate initiation, serial correspondent settlement, investigations, returns, and two account-reporting perspectives; bilateral services and migration dates vary. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    Treasury sends a request for transferAsha Traders treasury → Bank Alfa (ordering bank) · MT101

    Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.

  2. 02Processing
    Bank Alfa validates the MT101Bank Alfa (ordering bank)

    The bank checks the mandate, message fields, funds, cut-off, routing, and sanctions-screening results. A FIN ACK only confirms network acceptance; pain.002-style business status has no MT equivalent.

  3. 03Posting
    Bank Alfa debits Asha TradersBank Alfa (ordering bank)

    Once it accepts the request for execution, Bank Alfa books the customer debit under the account agreement before it releases the interbank MT103.

    • DR Asha Traders USD operating account — USD 125,000.00
  4. 04Message
    Treasury receives a debit confirmationBank Alfa (ordering bank) → Asha Traders treasury · MT900

    Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.

  5. 05Message
    Bank Alfa sends the customer paymentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT103

    The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.

  6. 06Processing
    Meridian validates and screens the MT103Meridian Bank (correspondent)

    The correspondent validates FIN fields, checks Bank Alfa's account, screens the parties and narrative data, and decides whether it can book and forward the payment.

  7. 07Settlement
    Meridian settles across its booksMeridian Bank (correspondent)

    Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. The ledger movement is the settlement; the MT103 is the instruction.

    • DR Bank Alfa USD account at Meridian — USD 125,000.00
    • CR Nordbank USD account at Meridian — USD 125,000.00
  8. 08Message
    Nordbank receives a credit confirmationMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT910

    The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.

  9. 09Message
    The MT103 reaches NordbankMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT103

    Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.

  10. 10Processing
    Nordbank validates and matches the paymentNordbank (beneficiary bank)

    Nordbank checks the beneficiary account, screens the payment, and matches the instruction to the credited nostro entry before paying its customer.

  11. 11Posting
    Nordbank credits the supplierNordbank (beneficiary bank)

    Nordbank books the credit to Northstar Components. A later cancellation is now a recovery request; the original credit cannot be erased by sending another message.

    • CR Northstar Components USD account — USD 125,000.00
  12. 12Message
    Treasury receives an intraday balance reportBank Alfa (ordering bank) → Asha Traders treasury · MT941

    Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.

  13. 13Message
    Treasury receives intraday transactionsBank Alfa (ordering bank) → Asha Traders treasury · MT942

    MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.

  14. 14Message
    The customer statement closes the dayBank Alfa (ordering bank) → Asha Traders treasury · MT940

    Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.

  15. 15Message
    Bank Alfa reconciles its nostro statementMeridian Bank (correspondent) → Bank Alfa (ordering bank) · MT950

    Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.

MESSAGES INVOLVED

Sources for this topic2
  1. Official requirement

    ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt message family

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

  2. Simplified educational illustration

    Payments Signal editorial teaching models — Payments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    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.