Category 1: Customer payments and cheques
MT192 Request for Cancellation
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
The MT192 is the message a bank sends to ask the Receiver of an earlier customer payment, usually an MT103, to consider cancelling it. It names the original message by reference, type and date, gives the reason, and always expects an answer in an MT196. In ISO 20022 the same request is a camt.056, answered by a camt.029.
- Message type
- MT192
- Category
- 1
- Structure
- 5 fields listed
When MT192 is used
A bank sends an MT192 when a customer payment it has already sent should not go ahead: it was sent twice, the amount or currency is wrong, it went to the wrong bank, the ordering customer withdrew the order, or the payment turns out to be fraudulent. The MT192 goes to the Receiver of the original message and to no one else.
It is a request, not an order. If the Receiver has not yet acted, it can stop the payment. If it has already passed the payment on or credited the beneficiary, the MT192 becomes a request for the money back, which may need the beneficiary’s consent, and the Receiver may in turn ask the next bank in the chain.
The Receiver must always answer with an MT196, quoting the MT192’s field 20 in its field 21: cancelled, still being worked on, or refused with a reason. Any money returned travels as a separate payment.
In the cover method two messages went out. The MT192 for the customer payment goes to the Receiver of the MT103; if the cover has not yet been executed, the Sender can also ask its correspondent to cancel the MT202COV with an MT292.
Swift gpi added a Stop and Recall service with its own rules: there the MT192 is addressed to the gpi Tracker instead of the next bank, with the UETR of the payment in field 121 of the user header, so that the request can follow the payment along the chain to whichever gpi bank holds it. Answers report a status such as CNCL (cancelled), PDCR (pending) or RJCR (rejected), the same status values that camt.029 uses.
MT192 format: sequences and fields
Message text (block 4)Mandatory
No sequences. Either field 79, a copy of the original fields, or both must follow field 11S.
| Tag | Name | Status | Format | Meaning |
|---|---|---|---|---|
| 20 | Transaction Reference Number | M | 16x | The Sender’s reference for this cancellation request. The answering MT196 quotes it in field 21. |
| 21 | Related Reference | M | 16x | Field 20 of the message to be cancelled, for example the Sender’s reference of the MT103. |
| 11S | MT and Date of the Original Message | M | 3!n 6!n [4!n6!n] | Three lines: the message type of the original (for example 103), the date it was sent (YYMMDD) and, if available, the session number and input sequence number (ISN) of the original, which let the Receiver find it exactly. |
| 79 | Narrative Description of the Original Message | C | 35*50x | Describes the original payment so the Receiver can identify it, and gives the reason. A structured form starts line 1 with a reason code between slashes, /4!c/ followed by optional text, with lines 2 to 35 starting with //. Reason codes: AGNT (incorrect agent), AM09 (wrong amount), COVR (cover cancelled or returned), CURR (incorrect currency), CUST (requested by customer), CUTA (cancel upon unable to apply), DUPL (duplicate payment), FRAD (fraudulent origin), TECH (technical problem), UPAY (undue payment). |
| (no tag) | Copy of at least the Mandatory Fields of the Original Message | C | Copy of fields | The fields of the original message, in their original order, starting with its field 20. Swift checks the field syntax but not whether the copy matches the original. Fields 77F and 77T may not be copied. |
Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).
Rules worth knowing
- Field 79, a copy of at least the mandatory fields of the original message, or both must be present (network rule C1, error C25).
- In field 11S the date must be a valid YYMMDD date (T50) and the message type a number from 100 to 999 (T18). Give the session number and ISN of the original when you have them.
- An MT192 may only be sent to the Receiver of the original message, and only to cancel a Swift message.
- An MT192 always requires an answer, and the answer must be an MT196.
- If the reason code is the only content of field 79 (for example only
/FRAD/), a copy of at least the mandatory fields of the original message must also be present. - To cancel one transaction of a multiple message, follow field 11S with field 79 describing that transaction, or a copy of the fields of both the common part and that transaction. To cancel several but not all, send one MT192 per transaction.
- Use of FRAD is subject to the rules of the jurisdictions involved.
MT192 example
ZagTrader Test Bank, Dubai (ZAGTAEADXXX), discovers that its system sent the same customer payment twice on 20 October 2026. It asks BANKGB2LXXX to cancel the second MT103, reference ZT2610200057, before value date.
{1:F01ZAGTAEADAXXX0000000000}{2:I192BANKGB2LXXXXN}{4:
:20:CXL2610210003
:21:ZT2610200057
:11S:103
261020
:79:/DUPL/DUPLICATE OF OUR ZT2610200051
//USD48500,00 VALUE 261022
//IFO ACME COMPONENTS LTD
//PLEASE CANCEL AND CONFIRM BY MT196
-}Decode this example in the parserLine by line
| Line | What it says |
|---|---|
| {1:F01ZAGTAEADAXXX0000000000}{2:I192BANKGB2LXXXXN}{4: | Sender ZAGTAEADXXX, input MT192 to BANKGB2LXXX: the Receiver of the original MT103. |
| :20:CXL2610210003 | Reference of this request. BANKGB2L will quote it in field 21 of its MT196. |
| :21:ZT2610200057 | Field 20 of the MT103 to be cancelled. |
| :11S:103 | Line 1 of 11S: the original was an MT103. |
| 261020 | Line 2: it was sent on 20 October 2026. The optional third line (session and ISN) is left out. |
| :79:/DUPL/DUPLICATE OF OUR ZT2610200051 | Structured line 1: reason code DUPL between slashes, then free text. |
| //USD48500,00 VALUE 261022 | Following lines start with //. They describe the original payment. |
| //IFO ACME COMPONENTS LTD | |
| //PLEASE CANCEL AND CONFIRM BY MT196 | What the Sender expects in return. |
| -} | End of block 4. |
This example identifies the original by narrative only. A copy of the original fields (:20:, :32A:, :50F: and so on) could follow field 79 or replace it.
BICs and references are made up.
Common errors and rejects
Neither field 79 nor a copy of the original (C25)
After 11S there must be a narrative, a copy of the original fields, or both. A message with only 20, 21 and 11S is rejected.
Wrong date or MT number in 11S (T50, T18)
The date is the date the original was sent, as YYMMDD, on its own line; the message type is three digits. Writing the value date instead of the send date is not rejected but often means the Receiver cannot find the original.
Request sent to the wrong bank
An MT192 goes to the Receiver of the original message. Sending it to the beneficiary’s bank further down the chain, or to the cover correspondent for an MT103, gets a refusal or no action.
Copied fields contain 77F or 77T (T13)
Any valid field can be copied except 77F and 77T. Strip them from the copy.
No answer received
The Receiver must answer with an MT196. If none arrives, chase with an MT199 quoting your field 20 and the UETR of the payment.
How to fix it
MT192 in ISO 20022
The ISO 20022 equivalent is camt.056 (FI to FI Payment Cancellation Request). It carries the original message identification, the original UETR (mandatory) and a structured cancellation reason using the same codes as the structured MT192 field 79, plus NARR for free text. The answer is a camt.029 (Resolution of Investigation) with status CNCL, PDCR or RJCR.
For payments that already travelled as pacs.008 or pacs.009, the cancellation request should follow the ISO 20022 path. Swift’s CBPR+ roadmap moves payment cancellations to case management (the Stop and Recall process), and Swift has postponed that mandate more than once, so check current Swift and correspondent notices for the date that applies.
If the money is returned, the return is a pacs.004 in ISO 20022, not a new credit transfer.
MT192 questions
- What is an MT192?
- A request from one bank to the Receiver of an earlier customer payment, usually an MT103, to consider cancelling it. It is answered by an MT196.
- What is the difference between MT192 and MT292?
- The category. An MT192 cancels a customer payment (category 1, such as an MT103); an MT292 cancels an interbank transfer (category 2, such as an MT202 or MT202COV). The layout is the same.
- Does an MT192 guarantee that the money comes back?
- No. It asks the Receiver to consider cancellation. If the payment has already been credited to the beneficiary, the Receiver may need the beneficiary’s consent before returning the funds, and it can refuse.
- What do DUPL, CUST and FRAD mean in field 79?
- They are cancellation reason codes: DUPL for a duplicate payment, CUST when the ordering customer asked for the cancellation, FRAD when the payment was originated fraudulently. Others are AGNT, AM09, COVR, CURR, CUTA, TECH and UPAY.
All MT messages · Category 1 messages · ISO 20022 messages · Codes · Troubleshooting