MT101 vs MT103 vs MT202: Which SWIFT Message Does What

MT101, MT103 and MT202 all answer to the word "payment", which is exactly why people mix them up — but they sit at three different points in the chain: MT101 is a corporate telling a bank to move its money, MT103 is a bank carrying a customer's payment to another bank, and MT202 is a bank moving its own funds. Since the SWIFT cross-border space completed its ISO 20022 migration 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.

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 instead of one e-banking portal per bank. Functionally it's the ancestor of what pain.001 does today: same intent, flat tagged format instead of structured XML.

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 were built for, and the reference travels on regardless of format.

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

What ISO 20022 did to each of them

The CBPR+ coexistence period ended on 22 November 2025, 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.

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 — has its own deadline: it retires in November 2026 in favour of the pain.001 relay, with contingency processing, automatic conversion and extra fees for what's left. 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.

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.

What usually goes wrong

• 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 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, pain.001 and pain.002 explained, and bank statement formats.