# MT101 vs MT103 vs MT202: Which SWIFT Message Does What

Source: https://gravam.com/blog/mt101-vs-mt103-vs-mt202
Author: Tan Gravam
Published: 2026-08-02
Updated: 2026-10-15
Reviewed: 2026-10-15
Summary: MT101 is a corporate's payment instruction, MT103 a bank-to-bank customer transfer, MT202 an interbank transfer. How they differ and what replaced them.

**MT101 is a corporate's payment instruction to its bank, MT103 is a bank carrying a customer's payment to another bank, and MT202 is a bank moving its own funds — three SWIFT messages at three different points in the payment chain, which is exactly why people mix them up.** Since the SWIFT cross-border space [completed its ISO 20022 migration](https://gravam.com/blog/iso-20022-migration-mt-to-mx) in November 2025, two of the three survive mostly as names — pacs.008 and pacs.009 do the work now — while MT101 lives on in the corporate-to-bank space with a retirement clock of its own. The query is durable; the answer in 2026 is partly historical. Both halves are below.

## The one-line version

Ask two questions of any SWIFT payment message: **who is talking to whom**, and **whose money is it**. MT101: corporate to bank, the corporate's money. MT103: bank to bank, a customer's money. MT202: bank to bank, the banks' own money. Everything else in this post is detail on top of that.

> **Figure — MT101, MT103 and MT202 on the payment chain**
>
> A corporate sends an MT101 to a bank. That bank sends an MT103 to another bank and, separately, an MT202. The MT101 and the MT103 are marked as carrying a customer's money; the MT202 is marked as the banks' own.
>
> Who is talking to whom, and whose money is it — the two questions that separate the three.

## MT101 — the corporate's instruction

MT101 is the **Request for Transfer**. It's the odd one out: not an interbank settlement message but an _instruction_ — the ordering customer asking an account-servicing bank to debit the customer's own account there and pay someone. In the classic setup it travels by **relay**: you submit the MT101 to your main bank, which validates it and forwards it over the SWIFT network to the foreign bank that actually holds the account. Nordea's service description is a clean example of the pattern — customer file in, bank check, onward delivery via SWIFT, acknowledgement back.

That relay is what made MT101 the workhorse of remote-account control for a generation of treasuries: repatriating balances, sweeping funds to your own accounts at other banks, making local payments from an account you hold abroad — all through one [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) instead of one e-banking portal per bank. Functionally it's the ancestor of what [pain.001 does today](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): same intent, flat tagged format instead of [structured XML](https://gravam.com/blog/pain-001-structure-and-fields). Its fields, sequence by sequence, and the rules banks reject on are in the [MT101 format reference](https://gravam.com/blog/mt101-format-fields-explained).

## MT103 — the customer payment, bank to bank

MT103 is the **Single Customer Credit Transfer**: the interbank message that carries a customer payment — a named ordering customer paying a named beneficiary customer — between banks. This is the message people usually mean when they say "a SWIFT payment". In the **serial** method, one MT103 hops through the correspondent chain from the ordering bank to the beneficiary bank, information and funds travelling the same route.

Two things practitioners should hold onto. First, **corporates don't send MT103s**. Your file to the bank is a pain.001 (historically an MT101 or a proprietary format); the MT103 — today the pacs.008 — is what your bank creates from it for the interbank leg. Second, the MT103 is the artifact everyone asks for after the fact: when a beneficiary swears the money never arrived, the first request on the call is "send us the MT103 copy". That habit outlived the message — tracing is what [SWIFT gpi and the UETR](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments) were built for, and the reference travels on regardless of format.

### MT103, MT103 STP and MT103 REMIT

There is one MT103 and two variants of it, and SWIFT's message reference guide separates them in a paragraph.

- **MT103** is the core message. It is general use — no registration needed to send or receive it — and uses all the MT103 fields. It _can_ go straight through, SWIFT says, "if the message is properly formatted according to pre-agreed bilateral/multilateral rules".
- **MT103 STP** is the same payment in "a network-validated, restricted set of fields and format options" that makes it straight-through processable by construction. Also general use. The sender marks it with the code STP in validation flag field 119 of the user header — `{3:{119:STP}}` — and the network then refuses a message that breaks the restricted format. It was introduced as the **MT 103+**, a name bank documentation still uses.
- **MT103 REMIT** is an MT103 with one more field, **77T Envelope Contents**, for "an extended amount of remittance information", optionally in a non-SWIFT format such as EDIFACT or ANSI-X12. It is not general use: both sides have to be registered in the Extended Remittance Information message user group.

What "restricted" meant when SWIFT documented the MT 103+ is a short list, and it reads like every payment repair you have ever been charged for:

- the bank party fields — 52, 54, 55, 56 and 57 — only with letter option A, which is a BIC and never a name and address (53 with A or B);
- the account in field 59, the beneficiary, always mandatory;
- field 23E limited to four instruction codes (CORT, INTC, SDVA, REPA);
- field 72 without the reject and return codes, and any INS code followed by a valid BIC.

That list is from the standards release that introduced the variant, so check the current guide for the letter of it. The principle has not moved: every bank identified by a code a machine can route on, and an account always given.

A corporate does not choose between these — the bank does, when it builds the interbank message from your file. But the variant explains why banks insist on a BIC and an account number for the beneficiary's bank and push back on a name and a city: the first can be an MT103 STP, and the second is a message someone has to read. As for REMIT, field 70 in every variant is four lines of 35 characters; the need for more is what the structured remittance block in [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) and its interbank counterpart now answers.

## MT202 — banks moving their own money

MT202 is the **General Financial Institution Transfer**: both sender and receiver are banks, and the funds being moved are the institutions' own — interbank settlement, and the funding legs that sit behind customer payments. No ordering customer, no beneficiary customer; that's the point.

Its best-known variant exists because of that point. In the **cover** method, the MT103 goes straight to the beneficiary's bank as an announcement — funds are coming, for this beneficiary, via this correspondent — while a separate cover message actually moves the funds through the correspondent accounts. For years that cover leg was a plain MT202 carrying no detail about whose payment it funded, which meant intermediaries were screening a message that named no customers. **MT202 COV**, introduced in the November 2009 standards release, closed that gap: a cover message for an underlying customer credit transfer must carry the ordering and beneficiary customer details, matching the MT103 it covers, so sanctions and AML screening can see the parties at every hop.

## Side by side

|  | MT101 | MT103 | MT202 |
| --- | --- | --- | --- |
| **Full name** | Request for Transfer | Single Customer Credit Transfer | General Financial Institution Transfer |
| **Who talks** | Corporate → bank (relayed via a bank) | Bank → bank | Bank → bank |
| **Whose money** | The corporate's account at another bank | A customer's payment | The banks' own funds (incl. cover legs) |
| **Role** | Instruction | Customer payment, interbank leg | Settlement / funding |
| **ISO 20022 heir** | pain.001 | pacs.008 | pacs.009 (COV for cover) |
| **Cross-border now** | SCORE continues; relay end was set for Nov 2026, now being re-phased | Retired in CBPR+ (22 Nov 2025) | Retired in CBPR+ (22 Nov 2025) |

## What ISO 20022 did to each of them

The [CBPR+ coexistence period ended on 22 November 2025](https://gravam.com/blog/iso-20022-migration-mt-to-mx), and with it the MT 1xx, 2xx and 9xx categories stopped meeting CBPR+ requirements for cross-border payments and reporting over SWIFT. For the two interbank messages the succession is clean: **MT103 → pacs.008** (FIToFICustomerCreditTransfer), **MT202 → pacs.009** (FinancialInstitutionCreditTransfer), and **MT202 COV → pacs.009 COV** — same three-way distinction, richer structured data underneath. An MT103 or MT202 that a bank still sends interbank is converted by SWIFT's contingency processing, charged to the sender since January 2026, rather than carried as normal traffic.

MT101 is the interesting case, because it straddles the boundary. The corporate-to-bank leg is **not** part of the CBPR+ interbank cutover: SCORE users — corporates and their banks — can continue exchanging MTs like MT101, MT940 and MT942 after November 2025, and SWIFT says migration is not yet mandatory for corporates, just strongly encouraged. But the **interbank relay** — the bank-to-bank hop that made MT101 useful — had its own deadline: **November 2026**, in favour of the **pain.001 relay**, with contingency processing, automatic conversion and extra fees for what's left. On 27 August 2026 Swift deferred all payments changes planned for that November and said they would be phased separately, so check Swift's current date before you plan against it — the [ISO 20022 and Swift dates](https://gravam.com/blog/iso-20022-swift-dates-2025-2027) page keeps them in one place. And individual banks are setting their own end dates for accepting MT101 at all. So "is MT101 dead?" has a precise answer: not yet, not everywhere, and the direction is pain.001 either way.

> One date does not fit all. 22 November 2025 was the CBPR+ cross-border cutover; the MT101 relay end, set for November 2026, is being re-phased after Swift's August 2026 deferral; market infrastructures and domestic schemes move on their own calendars; and your banks each have their own MT101 sunset letters. When someone tells you "MT is switched off", ask which space they mean.

## Why the confusion persists

Textbook version: three cleanly separated messages, one page each in the standard. Reality: they all get called "the payment message", and the confusion shows up in real projects. I've sat in connectivity workshops where the bank's form asked which payment message we'd use and three people gave three answers — pain.001, MT101, MT103 — each describing the same flow from a different seat. All three were sort of right: the corporate sends the instruction, the bank builds the interbank leg, and the settlement may ride a message the corporate never sees.

The trap is treating them as interchangeable. Asking your bank for "the MT103" on an intercompany sweep that never generated one; expecting customer names inside a plain MT202; assuming the retirement of MT103 means your MT101 channel is dead too. The two questions from the top of the post — who is talking to whom, whose money is it — resolve almost every one of these in seconds.

## Where SWIFT message types get confused

- **Calling every SWIFT payment "an MT103."** If both parties are banks moving their own funds, it was never an MT103 — and after November 2025 the cross-border leg is a pacs message anyway.
- **Expecting customer detail in an MT202.** Only the COV variant carries the underlying parties; that was the entire reason it was created in 2009.
- **Reading "MT is retired" as one event.** The interbank cutover (2025), the MT101 relay (2026) and corporate-to-bank SCORE traffic are three different clocks. Planning on the wrong one either strands you early or strands you late.
- **Building new connectivity on MT101 in 2026.** It still works in SCORE, but the relay is closing and banks are sunsetting it individually. New pipes should be [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) from day one.

Know which seat you're in — instructing, carrying, or settling — and the three messages stop being interchangeable jargon and become a map of the payment chain. That map survives the format change: the names on it just became pain.001, pacs.008 and pacs.009.

***

_See also the [ISO 20022 migration from MT to MX](https://gravam.com/blog/iso-20022-migration-mt-to-mx), [pain.001 and pain.002 explained](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and [bank statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2)._

## Primary sources

MT retirement is space-specific: CBPR+ interbank coexistence ended 22 November 2025, the interbank MT101 relay was scheduled to retire in November 2026 — on 27 August 2026 Swift deferred all payments changes planned for November, to be phased separately — and corporate-to-bank SCORE usage moves on bank-specific timelines. Verify current status against SWIFT's programme documentation.

- SWIFT — ISO 20022: Corporates (FAQ) — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/corporates
- SWIFT — ISO 20022 FAQs: MT to ISO 20022 conversion (contingency processing) — accessed 2026-09-25 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/mt-iso-20022-conversion
- SWIFT — ISO 20022 in bytes: Call to action for November 2026 — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-bytes/call-action-november-2026
- Swift — Swift accepts community request to extend structured address migration for ISO 20022 payment messages (27 August 2026, updated 21 September 2026) — accessed 2026-10-15 — https://www.swift.com/insights/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages
- Nordea — Request for Transfer (MT101) service description — accessed 2026-08-02 — https://www.nordea.fi/Images/147-81975/Request%20for%20Transfer%20Service%20description%2003.2019.pdf
- ING — ISO 20022 SWIFT CBPR+ update — accessed 2026-08-02 — https://www.ingwb.com/en/service/payments-and-collections/iso20022-swift-cbpr-update
- ISO 20022 — Message definitions catalogue — accessed 2026-08-02 — https://www.iso20022.org/iso-20022-message-definitions
- SWIFT — Standards MT November 2021, Message Reference Guide: MT 103 Single Customer Credit Transfer (copy published by BNZ) — accessed 2026-10-10 — https://www.bnz.co.nz/assets/bnz/business-banking/help-and-support/SWIFT-MT103.pdf
- SWIFT — SWIFTStandards FIN Category 1: MT 103+ Single Customer Credit Transfer, Standards Release Guide 2006 (copy published by Millennium bcp) — accessed 2026-10-10 — https://ind.millenniumbcp.pt/pt/negocios/tesouraria/Documents/Manual_mt103.pdf
- Paiementor — SWIFT serial and cover payments — accessed 2026-08-02 — https://www.paiementor.com/swift-serial-and-cover-payments/
- The Global Treasurer — SWIFT message MT202 COV: background and impact — accessed 2026-08-02 — https://www.theglobaltreasurer.com/2009/05/26/swift-message-mt202-cov-what-are-the-background-and-impact-points-for-banks/

## Questions this article answers

**Q: What is the difference between MT101 and MT103?**

MT101 is the Request for Transfer — an instruction from a corporate to a bank, usually relayed through a forwarding bank, asking the account-servicing bank to debit the corporate's own account there. MT103 is the Single Customer Credit Transfer — a bank-to-bank message that carries a customer payment through the correspondent chain. Corporates sent MT101s; only banks send MT103s. Their ISO 20022 successors are pain.001 and pacs.008 respectively.

**Q: What is the difference between MT103 and MT202?**

MT103 and MT202 are both bank-to-bank messages; the difference is whose money moves. MT103 carries a customer's credit transfer — a named ordering customer paying a named beneficiary. MT202 is the General Financial Institution Transfer: banks moving their own funds, including the settlement legs behind customer payments. MT202 COV is the cover variant that must also carry the underlying ordering and beneficiary customer details. In ISO 20022 they map to pacs.008 and pacs.009 (with a COV usage).

**Q: What is the difference between MT103, MT103 STP and MT103 REMIT?**

They are one message and its two variants. The core MT103 is general use and may use every MT103 field. MT103 STP — introduced as the MT 103+ — is the same payment in a network-validated, restricted set of fields and format options so that it can be processed straight through; the sender flags it with the code STP in field 119 of the user header. MT103 REMIT adds field 77T, Envelope Contents, for extended remittance information, optionally in a format such as EDIFACT or ANSI-X12, and both parties must be registered in SWIFT's Extended Remittance Information message user group.

**Q: Are MT103 and MT202 still used after the ISO 20022 migration?**

Not as the standard for cross-border payments over SWIFT. The CBPR+ coexistence period ended on 22 November 2025, and the MT 1xx, 2xx and 9xx categories no longer meet CBPR+ requirements there — pacs.008 and pacs.009 do that work now; an MT a straggler bank still sends is handled through SWIFT's contingency conversion, for a fee, not as normal traffic. The names survive in older documentation, bank contracts and everyday speech (people still ask for 'the MT103 copy'), and other market infrastructures run their own migration timelines, but for the SWIFT cross-border space they are legacy.

**Q: Is MT101 still supported?**

In the corporate-to-bank space, yes for now: SWIFT's SCORE users — corporates and their banks — can continue to exchange MTs such as MT101, MT940 and MT942 after November 2025, and migration is not yet mandatory for corporates, though SWIFT strongly encourages moving. The interbank MT101 relay is different: it retires in November 2026 in favour of the pain.001 relay, with contingency conversion and fees for stragglers. Either way the direction of travel is pain.001.