SWIFT MTs / Learning brief
SWIFT Cancellations and Investigation Messages
Your notes
In simple terms / 01
What this means in plain language
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.
Most payments settle without any fuss, but sometimes a bank sends a wrong amount, a duplicate, or a payment that a customer wants stopped. To handle these cases the Society for Worldwide Interbank Financial Telecommunication (SWIFT) MT world provides a set of exception messages. The n in MTn92, MTn95, MTn96, and MTn99 stands for the category of the original payment being discussed — so a request to cancel a category 1 customer transfer is an MT192. Together these messages form the operational toolkit for cancellations and investigations: asking a counterparty to reverse or return money, chasing missing details, replying to those chases, and sending a plain explanation when nothing else fits.
Complete lesson / 02
Understand the full idea, step by step
There is a moment in every recall that decides everything: had the receiving bank already paid the beneficiary when the request arrived? Answer no, and the payment can be stopped where it stands. Answer yes, and no message can undo the credit — the money can only come back if someone agrees to send it. That single fork is what separates a reject from a return.
Reject versus return — stop before it completes, or send back after
Timing decides which word applies. A reject happens before a payment is processed or settled: the payment is refused, and because the money never moved, nothing has to travel back. A return happens after the beneficiary has been credited: the funds have moved, so putting things right means actually sending money the other way. Choosing the right one keeps the audit trail honest and, crucially, avoids paying twice.
| When | What moves | |
|---|---|---|
| Reject | Before processing / settlement | No money — the payment is refused up front |
| Return | After the beneficiary is credited | Funds travel back, as a pacs.004 |
| Cancellation declined | In answer to a camt.056 recall | Nothing — the recall itself is refused (camt.029 RJCR) |
The cancellation workflow
- MESSAGE
Bank Alfa sends a camt.056 (or a legacy MTn92) quoting the original references and a coded reason — here, a duplicate.
- VALIDATION
Nordbank locates the exact payment and checks its state: still in transit, or already credited to the beneficiary?
- NOTIFICATION
If it has already paid the beneficiary, Nordbank cannot unilaterally reverse it; returning the money would need the beneficiary's agreement.
- MESSAGE
Nordbank answers with a camt.029 resolution of investigation, reporting the outcome with a coded reason — accepted, or rejected.
- SETTLEMENT
Only if the cancellation is accepted for a settled payment does a pacs.004 payment return actually move the money back to Bank Alfa.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
Nordbank's answer. The status RJCR means the cancellation was rejected — the funds were already applied — and the reason code LEGL points to a legal or beneficiary-consent barrier to giving the money back. Notice it still carries no money: it references the original payment (OrgnlEndToEndId, OrgnlUETR) and closes the case. Any actual return would be a separate pacs.004.
camt.029 and pacs.004 — the resolution, and the return that may follow
A camt.029 — resolution of investigation — is the answer to a cancellation request: it reports whether the recall was accepted or rejected and quotes the original references so both sides file it against the same payment. It does not move value. When a recall is accepted for money that already settled, the funds come back on their own message: a pacs.004 payment return, a fresh interbank payment travelling the other way. The answer and the money are deliberately kept apart.
COMMON CONFUSION
“Sending a cancellation request means the money will automatically come back.”
A cancellation request only asks. If the payment has settled and been credited, the beneficiary's bank cannot reverse it on its own, and the beneficiary may decline to give it back — exactly what Nordbank's RJCR answer records. A rejected cancellation is a legitimate outcome, not a system fault, and it closes the case honestly rather than leaving a false hope open.
WHAT IF — The recall is rejected because the beneficiary was already paid
What happens: No pacs.004 is sent; the money stays with the beneficiary. Bank Alfa is now out the duplicate amount unless it can recover it another way — commercially, with the beneficiary, or through its customer.
How it is handled: Maya files the camt.029 against the case, records that recovery failed on the payments rail, and escalates the duplicate to the relationship or dispute path. The audit trail shows a proper request made and a proper answer received — which is what the message set exists to guarantee.
STRICTLY SPEAKING
Strictly speaking, learning the MT toolkit first makes these successors easier to read: MTn92 maps to camt.056, the narrative MTn96 answer to the coded camt.029, and a return that once meant sending a fresh MT payment is now the purpose-built pacs.004. The ideas are identical; ISO 20022 simply moves the meaning out of free text and into labelled, coded fields. Which set a given corridor uses, and by when, follows scheme migration timelines rather than a single global switch.
FOR NOW, REMEMBER
- A reject stops a payment before it completes, so no money moves; a return sends settled funds back and needs an actual money movement.
- A camt.056 recall is only a request — the holder may accept or reject it, and a rejection (camt.029 RJCR) is a valid outcome, not a failure.
- The answer and the money are separate messages: camt.029 reports the resolution; pacs.004 carries any return.
- The MT and ISO 20022 sets express the same intent — MTn92/n96 and a return payment become camt.056, camt.029, and pacs.004.
TRY IT YOURSELF
Nordbank had already credited the supplier when Bank Alfa's recall arrived, and it returns a camt.029 with status RJCR. What does that tell Maya?
You have followed one recall from request to rejected resolution. The topic behind it gathers the whole exceptions-and-investigations discipline: reason codes, deadlines, and how banks keep these exchanges auditable across every rail.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
MTn92 is a request for cancellation, MTn95 is a query, MTn96 is the answer to a query, and MTn99 is a free-format message; the n matches the category of the underlying payment.
- 02
A reject stops a payment before it is processed, while a return sends money back after it has already been credited — the distinction decides which message and which timing apply.
- 03
ISO 20022 replaces this toolkit with structured equivalents: camt.056 for a cancellation request, camt.029 for the resolution of an investigation, and pacs.004 for a payment return.
Practical use cases / 04
Where you would use this
An operations team spots a duplicate outbound transfer and sends an MTn92 asking the beneficiary bank to cancel or return the funds.
A beneficiary bank cannot apply an incoming payment because a reference is missing, so it sends an MTn95 query and waits for the MTn96 answer.
During a migration a bank maps its old MTn92 cancellation requests onto camt.056 so the same investigation can run over an ISO 20022 channel.
Worked example / 05
Put the idea into a real situation
Illustrative example: Northwind Bank sends a EUR 48,200.00 customer transfer, then notices it was released twice. It sends an MT192 request for cancellation to the beneficiary bank, Rivergate Trust. Because Rivergate has already credited its customer, it cannot simply reject the second payment; it must arrange a return. Rivergate replies with an MT196 answer confirming it will send the funds back, and the actual reversal travels as a return payment. On an ISO 20022 channel the same sequence would be a camt.056 cancellation request, a camt.029 resolution, and a pacs.004 return.
Evidence & review / 07
Evidence & review
Cross-border cancellation, rejection and return handling on SWIFT MT and ISO 20022; status and reason codes follow the message standards and rulebooks in force, and corridor migration timelines vary.
What this brief simplifies: Follows a single rejected-recall case; production flows also cover accepted recalls, unable-to-apply and non-receipt investigations, and scheme-specific deadlines not quoted here.
Sources for this brief4
- Scheme-specific rule
Swift Standards MT (annual standards releases) ↗ — Swift · MTn92/n95/n96/n99 cancellation and investigation messages
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 · Resolution status and reason codes (e.g. RJCR, LEGL)
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Scheme-specific rule
ISO 20022 Standards (Swift ISO 20022 adoption programme) ↗ — Swift · Cross-border MT-to-MX migration
Programme milestones change over time; the coexistence period for in-scope cross-border payment instructions ended in November 2025. Check swift.com for the current timeline.