SWIFT Message Types: MT202, MT199, MT940 and Other MT Messages Explained

SWIFT message types are the standard message formats banks use to send payments, confirmations and statements to each other over the Swift network. SWIFT messages come in two types. MT (message type) messages are named by a three-digit number whose first digit shows the category, such as MT202 for a bank-to-bank transfer, while MX messages are built on the ISO 20022 standard, such as pacs.008.

Since November 2025, cross-border payment instructions between banks travel as MX messages, while the MT names still appear on payment copies, bank advices and support emails. When a foreign client pays you, only a handful matter: the customer payment, the cover payment between banks, free-format status messages and statement messages.

If a payment from abroad is late, a copy of the right message, with its tracking reference, is usually the quickest way to find where it stopped.

Every international transfer you receive starts as a message. The payer's bank writes an instruction in an agreed format, sends it over the Swift network, and the next bank reads it and acts. Swift publishes those formats as Swift's financial standards, so a bank in London and a bank in Pune read the same fields the same way.

A simple payment travels like this:

1. The payer's bank writes the payment instruction and sends it over Swift.
2. A correspondent bank in the payment's currency may sit in the middle and move the funds.
3. Your bank reads the message, credits your account and records the payer's details.

Two families of formats do this work. The older MT family uses short text fields with numbered tags. The newer MX family uses XML built on ISO 20022, a global standard for financial messages. Whether you run an IT-enabled services (ITES) business or freelance for overseas clients, you will mostly hear the MT names, even on payments that travelled as MX.

How an MT message number shows category, group and type

In every MT message the first digit denotes the category, the second the group within it, and the third the exact type. MT202 reads as category 2 (financial institution transfers), group 0, type 2, which is the general transfer one bank sends another. MT103 sits in category 1, customer payments and cheques, because a customer is on at least one side.

The same logic lets you place a code you have never seen: MT910 starts with 9, so it belongs to cash management, and MT700 starts with 7, so it is a trade message you can ignore unless you sell against letters of credit.

How MX messages built on ISO 20022 are different

MX messages are named by business area, not number. A pacs message moves payments between banks, a camt message covers cash management and statements, and a pain message is what a company sends its own bank. The payment you receive from a client now travels as a pacs.008, with structured fields for names, addresses and the reference you put on your invoice.

The main effect you might notice is cleaner payer details on the credit, since names and addresses no longer share one free text box.

The differences between MT and MX explain why details sometimes go missing on the way to you, and Swift describes the newer model on its ISO 20022 on Swift page.

Both formats carry the same tracking reference, the UETR (unique end-to-end transaction reference), so it is a shared feature rather than a difference. For you, the practical point is the reference field: if your invoice number is long, put it first in the reference so it is less likely to be cut.

MT and MX example of the same customer payment

Here is one dummy payment written both ways. Northwind Analytics Ltd in London pays Asha Tech Services Pvt Ltd in Pune USD 4,250 against invoice INV-2026-118. All names, accounts and references are dummy values. The MT version shows only the message body, and each field is explained in our guide to SWIFT MT103.

Field 32A packs the value date, currency and amount into one line, and 71A shows who pays the charges, here shared (SHA). The UETR is missing because it travels in the top section of the message, not the body. The simplified pacs.008 below carries the same payment, with bank codes and account numbers left out.

Notice that the MX version gives the street, town and country their own fields, and the UETR sits inside the message. SHAR is the MX code for shared charges, the same idea as SHA.

The SWIFT message format groups every MT into ten categories by its first digit. You will meet only a few MT message types, but the full set helps you place any code a bank quotes to you.

A client payment to you touches three groups of messages: the payment itself, the notes banks send about it, and the confirmations and statements that follow. Most move between banks only, so you see their effects, such as a credit alert, yet a bank or client will quote the names when a payment is late.

Knowing which group a code belongs to tells you whether to ask your client, the payer's bank or your own bank.

Payment messages MT103, MT202 and MT202 COV for cover payments

MT103 is the single customer credit transfer: it names the payer and you, the amount and the charge code, and it is what a payer's bank shares as a payment copy. MT202 is a transfer between banks with no customer names in it, so it is never proof that your client paid you.

MT202 COV is the version used when an MT202 covers a customer payment. Swift introduced it on 21 November 2009 so banks in the middle could see the real payer and payee for money laundering and sanctions checks. It must repeat the payer and payee of the linked MT103, and it is not an alternative to one.

Banks send a customer payment in one of two ways:

• Serial method - one payment message moves from bank to bank until it reaches your bank, and the funds move with it.
• Cover method - the MT103 goes straight to your bank, while the MT202 COV carries the funds through correspondent banks on a separate path. Your bank receives a credit confirmation, not the MT202 COV.

Status and investigation messages such as MT199 and MT192

When a bank needs to ask about a payment, it uses status and investigation messages, which explain the questions your bank or the payer's bank may raise. If you hear that "an MT199 came in", that alone does not mean the payment failed.

Banks also use MT199 to confirm progress to Swift's tracker. The payer's bank can follow any payment end to end with Swift gpi tracking, using its UETR, and you can see what that tracking shows in our explainer on SWIFT gpi.

MT199 example of a typical bank query on a payment

An MT199 query between two banks might look like this for the same dummy payment. The wording is illustrative, not text that Swift mandates.

Field 20 is the asking bank's own reference, field 21 links back to the payment, and field 79 holds the free text. A query like this usually means a bank wants your name or address confirmed before it credits you, which is why matching your legal name on every invoice saves time.

Reporting messages from MT900 and MT910 to MT940 statements

Once money moves, banks confirm it with reporting messages. These go from the bank that holds an account to the account owner, which is often another bank.

• MT900 - confirmation of debit, telling an account owner that money left its account.
• MT910 - confirmation of credit, telling an account owner that money arrived. In a cover payment, this is what your bank gets.
• MT940 - customer statement, an end-of-day list of every entry on an account.
• MT941 and MT942 - a balance report and an interim report of activity during the day.
• MT950 - statement message, mostly between banks for their accounts with each other.

An ITES business that runs accounting software can ask its bank whether it offers MT940 or camt.053 statement files, which import straight into the ledger. A freelancer rarely needs them, since a normal bank statement shows the same credits.

MT910 and MT940 example of a credit reaching your account

Here is the dummy payment as a credit confirmation sent to your bank about its own account abroad. All values are dummy, and the :25: line is your bank's account with its correspondent bank. This message goes to your bank, not to you; you see the result as a credit alert or statement line.

The same credit then appears as a line in an MT940 statement excerpt:

The :61: line shows the value date, a C for credit, the amount, a transaction type code such as NTRF (transfer) and your invoice reference. The :86: line carries the payer's narrative, which is where your reconciliation team looks first.

Some SWIFT MT messages turn up in client emails or bank forms even though they do not carry your service payments.

Each common MT has an MX counterpart. Swift sets out the payment side in Swift's ISO 20022 programme for payments, and these are the messages a receiver is likely to hear about.

Payment status reports now travel as pacs.002, which does the job a free-format MT199 reject often used to do.

What changed for MT messages

Since 22 November 2025, banks send cross-border payment instructions as MX. An MT103 or MT202 sent between banks is converted by Swift's contingency service, a conversion service Swift charges for, not refused.

Statement messages still run on MT. As of November 2026, there will be no Swift Standards Release 2026 on 14 November 2026, and payment changes were deferred on 27 Aug 2026 with no new date, so check Swift standards releases for the current plan.

Under the Cross-Border Payments and Reporting Plus (CBPR+) rules, the payer still needs your account name, number and bank code.

When a client says they have paid and nothing has arrived, a few steps usually locate the payment.

1. Ask the client for the payment copy - their bank can issue the MT103 or pacs.008 advice, and it should show the UETR, the amount and your account details.
2. Check the beneficiary details - compare the name, account number and bank code on the copy with your invoice. Our guide to the SWIFT code explains how to read one.
3. Ask the client to trace the UETR - the payer's bank can see which bank holds the payment now, and whether it is waiting on a query.
4. Ask your bank what inward advice it has - your bank decides what it shares, but it can tell you whether the funds have arrived and anything it is waiting on.
5. Check the charge code - if the payment arrived short, field 71A or ChrgBr shows whether charges were shared, paid by the payer or deducted from you.

Once the money lands, keep the bank advice and your FIRA with your invoice. The FIRA (foreign inward remittance advice) is what proves the export receipt for tax and export rules, not the MT103 alone.

We built Xflow for Indian businesses and freelancers who get paid by clients abroad. Xflow Payments India Pvt. Ltd. holds the final PA-CB (Payment Aggregator - Cross Border) authorisation from the Reserve Bank of India as of February 2026, the final licence rather than the provisional one.

With Xflow receiving accounts, your clients pay in their own currency, across 25+ currencies from 140+ countries (excluding sanctioned and high-risk ones), and withdrawals reach your Indian bank account within one business day. We provide a free FIRA issued by an RBI-authorised AD-1 bank on each withdrawal, and an eFIRA follows within 24 hours.

Of the many SWIFT message types, only a few touch your payments: the MT103 or pacs.008 that carries them, the MT202 COV that may move funds behind it, MT199 notes between banks, and the confirmations and statements that follow. When a payment is late, the payment copy and its UETR do the most work.