An MT103 is a SWIFT message. Specifically, it is the message one bank sent to another to instruct a single cross-border customer payment, and for about forty years it was the closest thing international trade had to a receipt. Your supplier in Taiwan asked for "the MT103" because a copy showed who sent the money, who it was going to, how much, on what date, with what reference and which bank took a cut on the way. Then on 22 November 2025, SWIFT retired it for cross-border payments. Most of the web has not caught up.
The information has not gone anywhere. It arrives in a different format now, and it carries a tracking code that is far more useful than the old document ever was. But if you are still asking your bank for an MT103, or your suppliers are still asking you, it is worth knowing what you will actually get back.
What the MT103 was for
SWIFT is the network banks use to talk to each other about payments. For decades the standard message for a customer payment was Message Type 103, the "single customer credit transfer". When your bank sent USD 50,000 abroad, it sent an MT103 to the next bank in the chain, which passed it on until the beneficiary's bank received the instruction and credited the account.
Businesses rarely saw the message itself. They saw a copy, usually a PDF from the bank, and used it for four things: proving to a supplier that payment had been sent so goods could be released; tracing a payment that had not arrived; working out which bank in the chain had deducted charges when a supplier was paid short; and keeping evidence for audit.
Reading an old MT103
You will still have these on file, and some banks still generate copies in the legacy layout, so the fields are worth knowing. Field 20 is the sending bank's transaction reference, the number to quote when you query anything. Field 23B is the bank operation code, almost always CRED for a normal transfer. Field 32A carries the value date, currency and amount. Field 50K or 50F identifies the ordering customer, which is you: name, address and account. Field 52A is your bank, as a BIC. Field 56A, when present, is an intermediary bank in the chain, and very often the place where charges were deducted. Field 57A is the beneficiary's bank, again as a BIC, and if a payment went to the wrong bank this is the field that shows it. Field 59 is the beneficiary: name and account or IBAN. Field 70 is the remittance information, the invoice reference the recipient sees. Field 71A says who pays the charges: OUR means the sender pays everything and the beneficiary gets the full amount, SHA means shared, BEN means the beneficiary pays. That one field explains the majority of short-payment disputes. Field 72 is free text between banks.
The UETR, the unique end-to-end transaction reference, lived in the message header rather than in a numbered field. It is a 36-character code that stays with the payment from the first bank to the last, and it is what SWIFT's gpi tracker uses to show where a payment is. Of everything on the page, it is the one piece of data that still matters.
Is the MT103 still available?
For cross-border payments over SWIFT, no. SWIFT's ISO 20022 programme for cross-border payments, CBPR+, ran a coexistence period from March 2023 during which banks could send either the old MT format or the new ISO 20022 format. That period ended on 22 November 2025. Core payment instructions must now be sent as ISO 20022 messages. The MT103 was replaced by pacs.008, and the bank-to-bank MT202 by pacs.009. Some reporting messages, including the MT940 account statement, are moving to their ISO 20022 equivalents on a separate timetable, and SWIFT has said that unstructured address formats will not be accepted after November 2026.
So if you ask your bank for an MT103 today, you will get one of three things. A pacs.008 confirmation, which holds the same information in a structured XML layout rather than numbered fields. A bank-generated payment confirmation, usually a PDF, that summarises the payment and quotes the UETR. Or, for a payment sent before November 2025 or over a domestic system still on legacy formats, a copy of the original MT103. All three do the same job. Whatever the format, the thing to insist on is the UETR.
What the switch changes for a finance team
ISO 20022 was a bank project, but three effects land on your desk.
The first is structured data. The new messages carry more information in defined fields: addresses split into street, town, postcode and country rather than typed into one line, purpose codes, and longer remittance information. Banks have been tightening validation to match. A beneficiary record with the address jammed into a single field, or a name that does not quite match the account holder, is more likely to be rejected or held than it was two years ago. Clean your beneficiary records now. Doing it on the day a payment fails is the expensive way.
The second is tracking. The UETR and SWIFT gpi were already in use, but ISO 20022 makes them standard. Your provider should be able to tell you, for any payment, whether it is in progress, completed or held, and at which bank.
The third is reconciliation. Remittance information now travels intact rather than being chopped at 140 characters, so invoice references are more likely to arrive with the money. If you export, expect fewer unidentified receipts over time.
How to track a payment now
Get the UETR at the moment of sending, on the payment confirmation. If your bank or provider cannot give you one, ask why. Pass it to the beneficiary; their bank can look it up on the gpi tracker and see exactly where the payment is. Before you panic about a "missing" payment, check the value date against the cut-off time, because a dollar payment instructed at five in the afternoon moves the next business day, and that single fact explains a large share of the phone calls. If it really is late, ask your provider to trace it: a gpi trace shows whether an intermediary bank is holding it, whether it has been rejected and whether charges have come off.
SWIFT's own gpi figures show most cross-border payments reaching the beneficiary's bank within hours. The final credit to the account depends on that bank's processing and local cut-offs, which is why "sent" and "arrived" are different things. Our article on how long international business payments take, and why they get held goes through the timelines and the reasons for delays.
Confirmations from Millbank FX
Clients sending international payments through Millbank FX can ask their dealer for the payment confirmation and tracking reference on any transaction, and we will trace a payment that has not arrived. Every outgoing payment is dual-checked before release and beneficiary details are validated against bank checkers before anything moves, which removes most of the reasons a payment gets bounced further down the chain.
This article is general information about payment messaging standards, not advice. Payment timings depend on the currency, the route, cut-off times and the processing of the banks involved.
