SWIFT MTs / Learning brief
SWIFT investigation and exception messages
Your notes
In simple terms / 01
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.
Complete lesson / 02
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 n — Message 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
| Legacy MT set | ISO 20022 set | |
|---|---|---|
| Cancel a payment | MTn92 request for cancellation | camt.056 payment cancellation request |
| Report the outcome | MTn96 answers, often as narrative | camt.029 resolution of investigation, coded |
| Return settled funds | A fresh MT payment sent back | pacs.004 payment return |
| Read by software | Hard — meaning lives in free text | Easier — reasons sit in labelled, coded fields |
camt.056, camt.029, and pacs.004 — cancel, 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?
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 GOINGKey takeaways / 03
Three things to remember
- 01
Exception messages let banks query, cancel, and resolve payments through a defined, auditable process rather than informal contact.
- 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.
- 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.
Practical use cases / 04
Where you would use this
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.
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.
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.
Worked example / 05
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 / 07
Evidence & review
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
- Scheme-specific rule
Swift Standards MT (annual standards releases) ↗ — Swift · MTn92 request for cancellation; MTn95/n96 query and answers; MTn99 free-format
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.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt.056, camt.029, pacs.004 definitions
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Cancellation reason codes (e.g. DUPL)
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Market practice
Swift gpi (global payments innovation) ↗ — Swift · Stop-and-recall via UETR
Only public summaries are used here; the full service definition and rulebook sit behind a swift.com account.