Requests the receiver to consider cancelling a previously sent Category 1 message, most commonly an MT103 customer payment. It is a request, not a reversal, and should carry structured references and reason codes rather than rely on free text.
DIRECTION: Sent by a financial institution to the institution that received or forwarded the original Category 1 message.
Version + profile: MT192 follows the applicable Standards MT release and service rules. This page is a curated field subset; bilateral practice and annual standards changes can alter permitted content and handling.
EVIDENCE AT ARM'S REACH
Start with the exact message version, then apply the scheme or network profile that governs your implementation.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
The annual MT standard and release information. Full field specifications may require an authenticated Swift account.
A fictional structured request to cancel an earlier MT103. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:b9a5eb01Initiation, serial and cover context, cancellation and correspondence, advices, and statements.
crc32:8b3a20e4Field correspondence, transformation treatment, and data-loss notes for Bank-to-bank request for cancellation of a previously sent payment instruction.
crc32:cac48d1aCurated field requirements, contexts, operational meaning, and implementation cautions.
crc32:c04ea1baCurated teaching subset of MT192. The official Standards MT handbook and current market-practice guidance define the complete format, allowed codes, and cancellation handling.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
:20: | Transaction reference number | MANDATORY | Unique reference for the cancellation request itself. |
:21: | Related reference | MANDATORY | Quotes field 20 of the original payment being cancelled. |
:11S: | Message type and date | MANDATORY | Identifies the original message type and transmission date. |
:79: | Narrative and structured codes | MANDATORY | Carries the cancellation reason and supporting details in the expected coded form. |
Block 3 / field 121 | UETR | CONDITIONAL | Network-wide reference of the original payment or cancellation case. |
:79:/CUST/ | Customer-requested reason | OPTIONAL | Indicates that the ordering customer asked for cancellation. |
Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT192 Request for Cancellation
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login. Coexistence for in-scope FI-to-FI payment instructions ended on 22 November 2025, but treatment differs by MT: some instructions are NAKed and selected messages can enter temporary, chargeable contingency conversion. Reporting, initiation, investigations and correspondence follow separate roadmaps.
ISO 20022 Standards (Swift ISO 20022 adoption programme) ↗ — Swift · Payment cancellation MT/MX equivalents and migration
Do not generalise the payment-instruction deadline to every FIN message. Swift publishes differentiated NAK, contingency-conversion, reporting, initiation and exceptions-and-investigations treatment.
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One MT103 cancellation is shown; cover-leg and multi-agent variations are summarised.
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.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…