SWIFT MT103 Explained: Fields, Message Example, and Why It Was Retired
For two decades, the SWIFT MT103 was the message that moved your money across borders. When your salary landed from an overseas employer, when an importer paid a supplier in another country, when a remittance company settled with its banking partner, an MT103 was almost always the instruction running quietly underneath it.
Here is what almost no other page on this topic will tell you. As of 22 November 2025, the MT103 is gone from the SWIFT network for cross-border bank-to-bank payments. SWIFT switched it off and replaced it with an ISO 20022 message called pacs.008. The format that ran global payments for twenty years is now legacy.
So why write a long guide about a retired message? Because you are almost certainly here for one of three reasons. You are reading an old document or contract that references an MT103 and you need to understand it. You work in payments and you need to map the old fields to the new ones. Or, and this is more common than the industry likes to admit, someone has sent you an MT103 as supposed proof of payment and something feels off. This page covers all three. Field by field, with real examples, and with the part nobody puts in writing: how to spot a fake one.
What an MT103 actually is
An MT103 is a SWIFT message type used for a single customer credit transfer. Strip away the jargon and it is an instruction. One bank telling another bank: pay this specific amount, in this currency, to this named beneficiary, on this date, and here is who is sending it and why.
The "MT" stands for Message Type. The "103" is just the catalog number SWIFT assigned to the single customer credit transfer. There are hundreds of MT message types. The MT103 was the workhorse because it carried payments where the originator or the beneficiary (or both) is a person or a company rather than a bank.
That last point matters and gets confused constantly. An MT103 is for a customer credit transfer. Its sibling, the MT202, is for a bank-to-bank transfer where both parties are financial institutions. People mix them up in fraud pitches all the time, which we will get to.
The part most pages skip: MT103 was retired in November 2025
SWIFT spent twenty years trying to move the industry off MT messages and onto ISO 20022, a richer, structured data standard. The transition ran as a coexistence period from March 2023, where both formats worked side by side, to a hard cutover on 22 November 2025.
On that date, the coexistence period ended. Cross-border payment instructions between financial institutions must now be sent in ISO 20022 format. The MT103, along with the MT202 and several others, was formally retired from the FIN network for these flows. The ISO 20022 message that replaced the MT103 is called pacs.008.
A few practical consequences flow from this:
Some MT messages were removed outright. The MT103 REMIT, MT102, MT102 STP, MT201, and MT203 are no longer accepted at all. Send one and the network rejects it.
The plain MT103 and MT103 STP did not vanish into thin air, but they now fall under what SWIFT calls contingency processing. This is a chargeable, flagged, last-resort service for institutions that did not finish their migration. Anything pushed through it is marked as a conversion and carries data and transparency limitations. It is a penalty box, not a long-term option.
Adoption is already heavy. By late November 2025, roughly 80% of daily SWIFT payment traffic was running in ISO 20022 format. The MT103 era is genuinely over for live cross-border payments.
One nuance worth knowing. Domestic and corporate flows moved on their own timelines. The corporate-to-bank space (think MT101 and its replacement, pain.001) has separate, later deadlines, and some domestic real-time systems adopted ISO 20022 at their own pace. Fedwire in the US, for example, went live with ISO 20022 in July 2025. So "MT103 is retired" is precisely true for cross-border bank-to-bank payment instructions, which is what the MT103 was actually for.
If you are building anything new, you build it on pacs.008. If you are reading something old, you read it as an MT103. Both skills are still useful, which is exactly why this guide exists.
The anatomy of an MT103: five blocks
A SWIFT message is built from five blocks. They wrap the actual payment data the way an envelope wraps a letter.
Block 1, the Basic Header. Identifies the application and the sender. It carries the sender's BIC and the terminal and session details. You will see it as {1:F01...}. The F01 means this is a FIN application message.
Block 2, the Application Header. Tells the network the message type (103), whether it is being sent or received, the counterparty BIC, and the priority. You will see it as {2:I103...} for an input message or {2:O103...} for an output (received) message.
Block 3, the User Header. Optional, but important in the modern era. This is where the UETR lives in field 121, the unique tracking reference that made end-to-end payment tracking possible under SWIFT GPI. It can also carry a Message User Reference in field 108.
Block 4, the Text Block. This is the payment itself. Every field you care about, the amount, the parties, the charges, lives here. We decode it below.
Block 5, the Trailer. Checksums and authentication. You will see {5:{CHK:...}}. It exists so the receiving system can confirm the message arrived intact.
The MT103 fields, decoded
Block 4 is where the work happens. Each field has a two-digit tag, sometimes followed by a letter that specifies the format. Here is what each one carries and, more usefully, why it is there.
Two fields are worth dwelling on because they decide who actually gets paid how much.
Field 32A versus 33B. The 32A amount is what settles between the banks. The 33B amount is what the customer originally instructed. When there is currency conversion or charges in the path, these two numbers diverge, and the gap is where FX margins and fees hide. If you only ever look at one figure on an MT103, the customer's reality is the difference between these two.
Field 71A, the charge code. OUR means the sender pays all fees and the beneficiary receives the full amount. BEN means the beneficiary absorbs every fee, including intermediary deductions, and often receives less than expected. SHA, the most common, splits it: sender pays their side, beneficiary covers the rest. If a remittance arrives short, the charge code in field 71A is usually the reason, not a mistake.
A worked example, line by line
Here is a clean MT103. Every value below is fictional and for illustration only.
{1:F01BANKBEBBAXXX1234567890}{2:I103DEUTDEFFXXXXN}{3:{121:eb6305c9-1f7f-49de-aed0-16487c27b42d}}
{4:
:20:REFERENCE12345
:23B:CRED
:32A:230501EUR123456,78
:50K:/12345678901234567890
JOHN DOE
123 FAKE STREET, BRUSSELS
:59:/23456789012345678901
JANE SMITH
:70:INVOICE 987654
:71A:SHA
-}
{5:{CHK:123456789ABC}}Reading it:
The headers tell you this is a FIN MT103, input, from BANKBEBBAXXX to DEUTDEFFXXX, carrying a UETR in block 3 for tracking.
:20:REFERENCE12345 is the sending bank's reference for this payment.
:23B:CRED confirms it is a credit transfer.
:32A:230501EUR123456,78 is the heart of it. The date is YYMMDD, so 230501 is 1 May 2023. Not 2001, and not 23 May. The currency is EUR and the settled amount is 123,456.78. SWIFT uses a comma for the decimal separator, which trips up people expecting a period.
:50K: is the ordering customer, John Doe, with his account and address. The K format allows name and address on separate lines.
:59: is the beneficiary, Jane Smith, with her account.
:70:INVOICE 987654 is the purpose. This payment is settling an invoice.
:71A:SHA means charges are shared.
That is a complete, valid, simple customer credit transfer.
A complex example with correspondents
Real cross-border payments rarely run bank to bank directly. They hop through correspondents. Here is a richer message.
{1:F01DEUTDEFFXXXX1234567890}{2:I103NDEADKKKXXXXN}{3:{121:9f8e7d6c-5b4a-3210-fedc-ba9876543210}}
{4:
:20:TXNREF1234567890
:23B:CRED
:32A:230523EUR100000,50
:33B:EUR100000,50
:50K:/12345678
JOHN DOE
123 FAKE STREET, FRANKFURT
:52A:DEUTDEFFXXX
:53B:/DE12345678901234567890
:56A:CHASUS33XXX
:57A:NDEADKKKXXX
:59:/DK5000400440116243
JANE SMITH
789 REAL ROAD, COPENHAGEN
:70:PAYMENT FOR INVOICE 998877
:71A:OUR
:72:/ACC/RENT MAY
-}
{5:{CHK:123456789ABC}}What the extra fields add:
:52A:DEUTDEFFXXX names the ordering institution, the payer's bank.
:53B: is the sender's correspondent, the account used to fund the payment.
:56A:CHASUS33XXX is an intermediary bank. This payment routes through a US correspondent even though it moves euros between Germany and Denmark, which is common when banks have no direct relationship.
:57A:NDEADKKKXXX is the account with institution, the beneficiary's bank in Denmark.
:71A:OUR means John pays every fee in the chain, so Jane receives the full 100,000.50 EUR.
:72:/ACC/RENT MAY is a structured note to the receiving bank.
The chain of correspondents is exactly why cross-border payments were slow and expensive in the MT era, and exactly the problem ISO 20022 and newer rails are trying to fix.
MT103 versus pacs.008: what actually changed
The pacs.008 is the ISO 20022 message that now does the MT103's job. It is XML rather than the old tag-based format, and it carries more structured data. The practical differences that matter:
Structured parties. The old MT103 let banks stuff names and addresses into free text. The pacs.008 requires structured or hybrid address formats. Unstructured free-text addresses are being phased out, which is a compliance and screening upgrade.
Richer remittance data. The MT103's field 70 was cramped. ISO 20022 allows far more detail, which helps with reconciliation and reduces the manual chasing that field 72 free-text used to cause.
The UETR carries over. The tracking reference introduced under SWIFT GPI lives on in pacs.008, so end-to-end tracking did not break in the migration.
If your job is to map old to new, the headline pairing is MT103 to pacs.008 and MT202 to pacs.009. Almost everything else is detail on top of that.
Why you might be looking at a fake MT103
This is the section that earns this page its keep, and it is the one the industry is squeamish about.
The MT103 is one of the most abused terms in financial fraud. For years, scammers have waved MT103s around as supposed proof that a payment is on its way, because the format looks official and most people cannot read it. If you found this page because someone sent you an MT103 to prove they paid you, slow down.
A real MT103 is an interbank message. It lives on the SWIFT network between banks. You, as a customer, do not normally receive the raw MT103 text. You see a credit in your account or a payment confirmation from your own bank. A PDF or screenshot of MT103 text emailed directly to you, especially by the other party rather than by your bank, proves nothing. It is trivially fabricated.
Common red flags in fraud pitches:
The "MT103 one-way" or "MT103/202 manual download." There is no legitimate transaction where a sender hands you raw MT103 or MT202 text as evidence of funds. The phrase "manual download" is a fraud tell, not a banking term.
"Serial MT103" or "MT103 with cash backing." These are buzzword salads invented to make advance-fee and prime-bank scams sound technical. They do not describe real settlement mechanics.
A field that does not parse. Wrong date format in 32A, a charge code that is not OUR, BEN, or SHA, a BIC that does not resolve to a real bank, missing mandatory fields. Fakes are usually sloppy.
Pressure to act on the MT103 alone. The honest test is simple. Money has either arrived in your account or it has not. An MT103, real or fake, is not a substitute for a balance you can actually withdraw. If someone needs you to believe the MT103 instead of checking your account, that is the scam.
The rule I give clients is blunt. Trust the credit in your account, confirmed by your own bank. Treat any MT103 sent to you directly as decoration until the money clears.
MT103 versus MT202 versus MT199
Three message types get confused constantly:
MT103 is a customer credit transfer. At least one end is a person or company.
MT202 is a general financial institution transfer, bank to bank, often the cover payment that funds an MT103 in the correspondent chain.
MT199 is a free-format message, used for queries and information rather than to move money. If someone calls an MT199 "proof of payment," they are mistaken or hoping you are.
All three were affected by the ISO 20022 cutover. MT103 maps to pacs.008, MT202 to pacs.009, and the free-format world moved to its own ISO equivalents.
Frequently asked questions
Is an MT103 proof of payment? Not on its own, and not when it is sent to you directly. A genuine MT103 is an interbank instruction, not a customer-facing receipt. Real proof is the cleared credit in your account, confirmed by your own bank. Treat any MT103 emailed to you by a counterparty as unverified until the funds are actually available.
Is the MT103 still used in 2026? For cross-border bank-to-bank payments, no. SWIFT retired the MT103 for these flows on 22 November 2025 and replaced it with the ISO 20022 message pacs.008. A chargeable, last-resort contingency service exists for stragglers, but live cross-border payments now run on ISO 20022. You will still encounter MT103s in historical documents and certain non-cross-border contexts.
What replaced the MT103? The ISO 20022 message pacs.008, the FI-to-Customer and Customer credit transfer equivalent. The MT202 was replaced by pacs.009.
Can an MT103 be reversed or recalled? The instruction itself is not casually undone. Once a payment settles, getting it back depends on a recall request and the cooperation of the receiving bank, not on cancelling the message. This is precisely why fraud recovery is so hard and why you confirm before you ship goods or release value.
What is an MT103/202? In legitimate banking, an MT103 and an MT202 can appear together when a cover payment (MT202) funds a customer transfer (MT103). Outside that, "MT103/202" is most often a phrase used in advance-fee and prime-bank fraud. If someone is pitching you an "MT103/202 manual download," walk away.
How long does an MT103 take to arrive? Historically anywhere from a few hours to several business days, depending on the number of correspondents in the chain, currency cut-off times, and compliance checks. SWIFT GPI and the move to ISO 20022 have compressed this considerably for many corridors, with a large share of payments now crediting same day.
What is the UETR on an MT103? The Unique End-to-end Transaction Reference, a 36-character identifier in block 3, field 121. It is the tracking number that lets the payment be followed end to end under SWIFT GPI, and it carries forward into the ISO 20022 world.
The bottom line
Three things to take away. First, an MT103 is an interbank instruction to pay a named beneficiary, and reading its fields, especially 32A, 33B, and 71A, tells you the real money story including who absorbs the fees. Second, the format was formally retired for cross-border bank-to-bank payments on 22 November 2025 and replaced by ISO 20022's pacs.008, so anything new should be built on the new standard. Third, an MT103 sent to you directly is not proof of payment, and the term is heavily used in fraud, so always trust the cleared balance in your account over any message.
If you run a money services business, a payment company, or a fintech and your real problem is not reading MT103s but getting and keeping a bank that supports proper SWIFT functionality, named accounts with IBAN and BIC, multi-currency, and OUR/BEN/SHA handling, that is a different and harder puzzle.