MT199 — Free Format Message (Category 1)
The Swiss Army knife of SWIFT customer payments: free format to send a status, query, return, exception or further instruction — around an MT103 or a known customer chain.
Purpose of the message
MT199 is the "generic" message of SWIFT Category 1. Where other Category 1 messages carry a firm act (MT103 = a transfer, MT110 = a cheque collection), MT199 is used to communicate in free text around a customer payment:
- flag an intermediate status (received, processing, executed);
- request further information from the correspondent bank;
- respond to an investigation request (cases not covered by MT195 / MT196);
- communicate a soft business rejection or return (before a formal MT-format);
- send an amendment instruction, preventive cancellation, or KYC supplement.
With ISO 20022 going live on SWIFTNet in November 2025 (end of MT/MX coexistence for cross-border), MT199 has been broadly replaced by pacs.002 (status report) and camt.029 (resolution of investigation). MT199 remains used domestically per market and for flows not transmitted as pacs (out-of-scope ISO 20022 cases).
Block 4 structure
MT199's Block 4 is minimal, designed to carry few structured tags and a large free-text block:
| Tag | Name | Status | Format |
|---|---|---|---|
:20: | Transaction Reference Number | Mandatory | 16x |
:21: | Related Reference | Optional | 16x |
:79: | Narrative | Optional (but in practice always present) | 35*50x (35 lines of 50 chars) |
Optional spec tags that may be added per context: :11S: (MT and Date Reference), :11R: (MT and Date of Original Message), :75: (Queries), :76: (Answers). | |||
Tags in detail
:20:Transaction Reference Number — unique MT199 reference on the sender side. No/or//at start/end. Must be traceable in the sender's system.:21:Related Reference — reference to the original message. Typically the:20:of the MT103 the MT199 refers to. Lets the recipient bank trace back to the relevant flow.:79:Narrative — free text, containing the business content. Maximum 35 lines of 50 characters each (~1750 chars in practice). Should be written in English (tacit norm), with classic SWIFT acronyms (REGARDS, REFERS TO, AWAITING).:11S:MT and Date Reference — MT + date combination, useful for explicit pointing when:21:is ambiguous.:75:Queries /:76:Answers — structured question/answer pairs, used in investigation workflows.
Real example
BNP Paribas Paris asks Deutsche Bank Frankfurt to confirm credit posting of MT103
ref REF20260514001 to the beneficiary Hans Mueller GmbH account:
{1:F01BNPAFRPPAXXX0000000000}{2:I199DEUTDEFFXXXXN}{3:{121:1a2b3c4d-5e6f-7890-abcd-ef1234567890}}{4:
:20:REQ20260514ABC
:21:REF20260514001
:79:WE REFER TO YOUR MT103 REF20260514001 DATED 14 MAY 2026
FOR EUR 12500,00 IN FAVOUR OF HANS MUELLER GMBH.
PLEASE CONFIRM CREDIT APPLIED TO BENEFICIARY ACCOUNT
ON VALUE DATE. AWAITING YOUR EARLIEST RESPONSE.
REGARDS, BNP PARIBAS PAYMENTS OPERATIONS
-}{5:{CHK:ABC123456789}}{1:F01BNPAFRPPAXXX...}— sender BNP Paribas Paris.{2:I199DEUTDEFFXXXXN}— recipient Deutsche Bank Frankfurt, priority N.{3:{121:1a2b3c4d-...}}— UETR inherited from the source MT103 (carried for gpi tracking).:20:REQ20260514ABC— sender reference of the MT199.:21:REF20260514001— reference of the MT103 being queried.:79:— free-text body: request for credit confirmation.
Common pitfalls
:79:too long — the spec imposes 35 lines max of 50 chars each. Exceeding triggers a silent truncation at the gateway or a rejection per config. Pre-validate.- No
:21:on a response — an MT199 that doesn't reference the original message via:21:is lost on the receiver side: no automatic matching possible. - UETR not propagated — for gpi flows, the UETR of the source MT103 must be propagated in MT199's Block 3, otherwise gpi tracking is broken.
- Special characters in
:79:— SWIFT MT accepts only a subset of ASCII (character set x). Accents, Unicode characters, native line breaks are rejected or substituted. - Confusion with MT195 / MT196 — for structured investigation flows (return request, modification request), prefer the specific MT192 / MT195 / MT196. MT199 stays for generic cases.
- No clear urgency category — the unstructured format makes automated prioritisation difficult on the receiver side. Prefixing
:79:with a clear marker (URGENT, FYI, ACTION REQUIRED) helps human triage.
MX equivalents
Depending on the use case, MT199 maps to several distinct ISO 20022 messages:
| MT199 case | ISO 20022 equivalent | Family |
|---|---|---|
| Payment status report | pacs.002 (FI to FI Payment Status Report) | pacs |
| Investigation request | camt.027 (Claim Non Receipt) or camt.087 (Request to Modify Payment) | camt |
| Investigation response | camt.029 (Resolution of Investigation) | camt |
| Return of funds | pacs.004 (Payment Return) | pacs |
| Post-settlement cancellation request | camt.056 (FI to FI Payment Cancellation Request) | camt |
| Free communication outside workflow | admi.002 (Message Reject) or kept as domestic MT199 | admi |
Related messages
- MT103 — customer transfer referenced in
:21:. - MT192 / MT195 / MT196 — structured cancellation / queries / answers.
- MT299 — Category 2 equivalent (Financial Institution Transfers).
- MT900 / MT910 — debit/credit confirmations from the correspondent bank.
- pacs.008, pacs.002, camt.029 — ISO 20022 equivalents.