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

SWIFT MTs / Learning brief

SWIFT investigation and exception messages

Your notes

What this means in plain language

When a payment must be questioned, cancelled, or corrected, banks use dedicated exception messages: free-format MT n99 notes, MT n92 cancellation requests, and the ISO 20022 camt.056 and camt.029 pair, supported by SWIFT gpi stop-and-recall.

Payments do not always go smoothly: a bank may need to ask a question about one, request that another be cancelled, or correct a mistake. A set of exception and investigation messages exists for exactly this. In the legacy MT (Message Type) world, an MT n99 is a free-format message, a plain-text note used to ask or answer a question about a payment, where n is the message category, so MT199 relates to customer payments. An MT n92 is a formal request to cancel a message already sent, such as an MT192 to cancel a customer payment. In the ISO 20022 (International Organization for Standardization standard 20022) world these are replaced by structured messages: a camt.056 (cash management message) is a request to cancel a payment, and a camt.029 is the resolution that accepts or rejects it. SWIFT gpi (global payments innovation) adds a faster route: a stop-and-recall request that uses the payment's UETR (unique end-to-end transaction reference) to find and halt it.

Understand the full idea, step by step

When a payment needs to be questioned, corrected, or pulled back, banks do not telephone one another and hope. They send a defined message — one that quotes the original payment's references, states a reason from a shared list, and leaves a logged record of who asked what and when. Treat these messages not as signs of failure but as the system working: a payment stopped or queried is a control catching something before it becomes a loss.

Why exceptions get their own messages

A structured exception message does three things a phone call cannot. It quotes the original payment's identifiers, so the receiver can find one specific payment among millions. It names a reason from an agreed code list, so the request is unambiguous. And it is logged on both sides, so customers, reconciliation, and regulators can all see the trail. Investigations fall into three broad kinds — queries for more information, cancellations of a payment already sent, and returns of settled funds — each with its own messages and time limits, so the response is orderly rather than improvised.

MT and the category digit nMessage Type; n stands in for the payment's category

In the legacy MT (Message Type) catalogue, exception messages are numbered to match the traffic they concern, and the written form uses n as a placeholder for the category digit. So the same cancellation request is an MT192 for a category 1 customer payment and an MT292 for a category 2 financial-institution transfer. Writing MTn92 just means "the cancellation message, whichever category applies". The digit keeps every investigation attached to the type of payment it is about.

The legacy MT investigation set

MTn92
Request for cancellation — asks the receiver to cancel a message already sent
MTn95
Query — asks for a missing detail or clarification
MTn96
Answers — the structured reply to a query or request
MTn99
Free-format — a plain-text note for anything that does not fit a template
Free text versus structured fields
Legacy MT setISO 20022 set
Cancel a paymentMTn92 request for cancellationcamt.056 payment cancellation request
Report the outcomeMTn96 answers, often as narrativecamt.029 resolution of investigation, coded
Return settled fundsA fresh MT payment sent backpacs.004 payment return
Read by softwareHard — meaning lives in free textEasier — reasons sit in labelled, coded fields

ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION

This is Maya's cancellation request in ISO 20022. Notice it carries no money — only pointers back to the original payment (OrgnlEndToEndId, OrgnlTxId, OrgnlIntrBkSttlmAmt) and a coded reason, DUPL, for a duplicate. It quotes the earlier payment so Nordbank can locate exactly which one to cancel.

camt.056, camt.029, and pacs.004cancel, resolve, and return in ISO 20022

ISO 20022 splits the job across three messages. A camt.056 asks a bank to cancel a payment, quoting the original references and a coded reason. A camt.029 — resolution of investigation — reports the outcome: accepted or rejected, with a reason from a shared external code list. If the cancellation is accepted for a payment that already settled, the money travels back as a pacs.004 payment return. The request, the answer, and the actual money movement are three separate messages — and only the pacs.004 moves value.

If Bank Alfa sends a camt.056, does Nordbank have to cancel the payment?

No — and this is the point that keeps the whole exchange defensive. A camt.056 is a request, not an instruction. Nordbank must check whether the money is still available and, if the beneficiary has already been credited, whether the beneficiary agrees to give it back. It answers with a camt.029 that may accept or reject. A recall never reaches into another bank's books and pulls money out; it asks, and the holder decides.

STRICTLY SPEAKING

Strictly speaking, speed changed with SWIFT gpi (global payments innovation). Because every gpi payment carries a UETR, a stop-and-recall request can be routed straight to the bank currently holding the funds instead of walking the chain link by link. The message set still governs the exchange — coded reasons and time limits keep it auditable — but the funds are found faster. Even so, the guardrail is unchanged: the bank holding the money decides whether it may be returned.

FOR NOW, REMEMBER

  • Exception messages quote the original references, name a coded reason, and are logged on both sides — a phone call does none of these.
  • The legacy MT set uses a category digit n: MTn92 cancels, MTn95 queries, MTn96 answers, MTn99 is free text.
  • ISO 20022 splits the work: camt.056 requests a cancellation, camt.029 reports the resolution, pacs.004 returns settled funds — and only the pacs.004 moves value.
  • A cancellation is a request the holder must assess; gpi and the UETR speed up finding the funds but never override that decision.

TRY IT YOURSELF

Bank Alfa sent the same EUR 1,250.00 payment to Nordbank twice and Maya wants the duplicate stopped. Which action fits the ISO 20022 toolkit?

Send a camt.056 quoting the original references with reason DUPL — a request Nordbank must assess, not a guaranteed reversal.

Correct — Correct. The camt.056 names the exact payment and a coded reason, and Nordbank replies with a camt.029. If accepted after settlement, the money returns as a separate pacs.004. The request and any return are distinct messages.

Send a pacs.004 to pull the EUR 1,250.00 back automatically.

Not this one — A pacs.004 is the return the holding bank sends once it agrees to give the money back — it is not a message Bank Alfa fires to reach into Nordbank and grab funds. The request to cancel comes first, via camt.056.

Telephone Nordbank and ask informally, leaving no coded message on either side.

Not this one — An informal call leaves no auditable record and no coded reason. The whole value of the exception messages is that the request, its reason, and its answer are logged for customers, reconciliation, and regulators.

You have met the messages. Next comes the workflow in detail — what happens when Nordbank has already paid the beneficiary, and why the difference between a reject and a return decides whether money has to travel back at all.

KEEP GOING

Three things to remember

  1. 01

    Exception messages let banks query, cancel, and resolve payments through a defined, auditable process rather than informal contact.

  2. 02

    Legacy MT n99 free-format notes and MT n92 cancellation requests are mirrored by the ISO 20022 camt.056 request and camt.029 resolution.

  3. 03

    SWIFT gpi stop-and-recall uses the UETR (unique end-to-end transaction reference) to locate and halt a payment quickly, which matters most for errors and suspected fraud.

Where you would use this

USE CASE 01

An investigations desk sends an MT n99 free-format note or a camt.026 (unable to apply) message to ask a counterparty for the details needed to process a payment.

USE CASE 02

An operations team issues a camt.056 request to cancel a duplicate payment and waits for the camt.029 resolution before treating funds as recovered.

USE CASE 03

A fraud response team triggers a SWIFT gpi stop-and-recall on a payment reported as fraudulent, quoting its UETR to reach the bank now holding it.

Put the idea into a real situation

Illustrative example: a fictional bank, Meridian Trust, discovers it sent a customer payment of EUR 6,250.00 twice to a beneficiary at a fictional bank, Kestrel Union Bank. To recover the duplicate it sends a camt.056 (cash management message) request to cancel, quoting the original payment's references and a reason code of duplicate payment. Because the original had already been sent through SWIFT gpi (global payments innovation), Meridian Trust also raises a stop-and-recall against the 36-character UETR (unique end-to-end transaction reference) so the request reaches Kestrel Union Bank directly. Kestrel Union Bank checks that the EUR 6,250.00 has not yet been paid out, confirms the beneficiary agrees, and returns it. It then sends a camt.029 resolution marked accepted, closing the case 3 business days after the request. Had the funds already been withdrawn, the resolution could instead have been rejected, and recovery would depend on the beneficiary.

Evidence & review

REVIEWED 2026-07-13

Cross-border correspondent-banking investigation and cancellation traffic on SWIFT MT and ISO 20022; reason codes and time limits follow the message standards and scheme rulebooks in force.

What this brief simplifies: Uses one duplicate-payment case; real investigations also cover unable-to-apply and non-receipt claims, and the migration between MT and MX runs on scheme-specific timelines not stated here.

Sources for this brief4
  1. Scheme-specific rule

    Swift Standards MT (annual standards releases)Swift · MTn92 request for cancellation; MTn95/n96 query and answers; MTn99 free-format

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.

  2. Official requirement

    ISO 20022 Catalogue of messagesISO 20022 Registration Authority · camt.056, camt.029, pacs.004 definitions

    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.

  3. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority · Cancellation reason codes (e.g. DUPL)

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  4. Market practice

    Swift gpi (global payments innovation)Swift · Stop-and-recall via UETR

    Describes Swift gpi, the cross-border payments service layer over the Swift network, including the end-to-end tracking it defines for member banks through the UETR (unique end-to-end transaction reference) and the Tracker. · Checked 2026-07-13

    Only public summaries are used here; the full service definition and rulebook sit behind a swift.com account.

Learn this properly

Related briefs

View SWIFT MTs archive

SWIFT Cancellations and Investigation Messages

When a SWIFT MT payment goes wrong, banks use a small family of exception messages — MTn92, n95, n96, and n99 — to ask for cancellation, query, answer, and explain. ISO 20022 replaces this toolkit with camt.056, camt.029, and pacs.004.

READ BRIEF

SWIFT MT1xx Customer Payment Messages

SWIFT Financial Application (FIN) Category 1 covers customer payments, where a customer is a party to the transfer. This guide walks the MT101, MT102, MT103, and MT104 messages along two axes: single versus multiple, and push versus pull.

READ BRIEF

SWIFT MT2xx Financial Institution Messages

SWIFT Financial Application (FIN) Category 2 covers transfers where banks are the parties. This guide separates own-account from third-party transfers, single from multiple, and explains the notice nature of MT210 and the MT202 COV cover message.

READ BRIEF