An MT103 is the SWIFT message type a bank uses to send a single customer credit transfer across borders, and the copy a bank hands over as a "wire confirmation" is simply a printout of that message. It names the payer, the payee, the banks in the chain, the amount, the value date, and who pays the fees. The format is also being retired: BNY's client notice on the ISO 20022 migration states that from November 22, 2025, cross-border payments on Swift must be exchanged in ISO 20022 format, with the MT103 replaced by pacs.008.
​

That shift matters for anyone who still asks a bank for "the MT103" to prove a payment left. The information still exists, but it increasingly lives in a pacs.008 message, and some banks now produce the confirmation from that newer format. This guide explains what an MT103 proves, how to read its key fields, how to use one to trace a stuck wire, how it differs from an MT202 COV, and what the pacs.008 transition changes in practice.
​

An MT103 is a standardized SWIFT FIN message that instructs a receiving bank to credit a named beneficiary on behalf of a named ordering customer. It is the core message behind most international wires sent before the ISO 20022 cutover, and banks share a copy of it as documentary evidence that a payment was sent and routed.
​

The "MT" stands for Message Type, and the "1" prefix places it in category 1, customer payments. Each MT103 is built from numbered fields called tags, such as :20: for the sender's reference and :59: for the beneficiary. According to the Paiementor MT103 field walkthrough, field 23B normally carries the code CRED to mark a plain credit transfer, and field 50K holds the ordering customer's account and name in up to four lines of 35 characters.
​

Variants exist. The MT103 STP is a stricter version designed for straight-through processing without manual repair, and the MT103 REMIT carried extended remittance data. The BNY notice lists MT103 and MT103 STP as messages that map to pacs.008, while MT103 REMIT was withdrawn outright with no MT conversion path.
​

For treasury and accounts-payable teams, the MT103 is usually the document a supplier requests when a payment has not arrived. It is more useful than a bank's internal payment receipt because it shows the actual instruction that went out on the network, including the correspondent banks involved. For background on why those intermediary banks exist at all, see how correspondent banking works.
​

An MT103 proves that the sending bank released a payment instruction on the SWIFT network with specific details: amount, currency, value date, beneficiary account, and routing. It does not prove that the beneficiary's account was credited, because later banks in the chain can still hold, reject, or return the funds.
​

This distinction causes most confusion around wire confirmations. HiWiPay's field-by-field guide describes the MT103 as proof of payment showing that the transfer was initiated and routed through named institutions, and notes that banks do not always send it automatically, though it can usually be requested, sometimes for a fee. What it cannot show is what happened after the instruction left the sender.
​

Several things can still go wrong downstream. A correspondent can hold the payment for sanctions or anti-money-laundering review. The beneficiary bank can reject it if the account number in field 59 does not match an open account. An intermediary can deduct fees, so the credited amount differs from field 32A. A payment can also be returned, which under the old format used a separate MT103 or MT202 return message and now maps to pacs.004, per the BNY message table.
​

In practice, an MT103 is strong evidence that the payer did their part on the date shown. It is the starting document for an investigation, not the end of one. Confirmation of credit comes from the beneficiary's bank statement or from a tracking status that shows the payment as completed.
​

The most important MT103 fields identify the transaction, the money, the parties, the banks, and the fees. Reading a handful of them, chiefly the reference, the amount and value date, the beneficiary, the account-with bank, and the charges code, is usually enough to confirm a payment was sent correctly or to spot why it stalled.
​

Field 71A is the field most often behind "short-paid" complaints. Under OUR, the payer covers all fees. Under SHA, each side pays its own bank. Under BEN, the beneficiary absorbs everything, so intermediaries deduct fees from the principal. Paiementor notes that when 71A is OUR, field 71G shows the prepaid receiver's charges included in the settlement amount. A supplier receiving less than the invoice total should check this field before anything else.
​

The mapping is not one to one. X9Ware points out that a single MT field can map to several ISO 20022 elements. Field 50K, for example, crams name and address into free-text lines, while pacs.008 splits the debtor into separate name, street, town, and country elements. That extra structure is the main reason the industry moved.
​

To trace a wire with an MT103, ask the sending bank for a copy of the outgoing message, then check the beneficiary details, the account-with bank, the value date, and the UETR. The UETR lets any bank on the route look up the payment's live status in Swift's tracking system.
​

The payer requests the document, not the payee. Most banks provide it through a relationship manager, a treasury portal, or the wire desk. Some supply it free, others charge, as HiWiPay notes. After the migration, some banks issue a pacs.008 extract or a plain-language confirmation built from it instead, which carries the same core facts.
​

Once the copy is in hand, a practical check runs in this order:

The UETR is the piece that makes tracing possible. The Federal Reserve's Fedwire gpi market practice describes it as a reference of up to 36 characters including dashes, carried in field 121 of an MT message or in the UETR element of an ISO 20022 message. The same document shows the Fed built a way to carry the UETR through Fedwire so a Swift payment keeps its tracking ID when it crosses into the US domestic system, until Fedwire moved to ISO 20022 on July 14, 2025.
​

If a trace shows the payment sitting at an intermediary, the usual cause is a compliance hold or a missing detail. Field 56a identifies which bank that is. At that point, the sending bank opens an investigation with the intermediary. Understanding the accounts those banks keep with each other helps here, and the guide to nostro and vostro accounts covers the mechanics.
​

An MT103 is the customer-level instruction that tells the beneficiary's bank whom to credit. An MT202 COV is a bank-to-bank message that moves the actual funds through correspondents to cover that MT103. It must repeat the ordering customer and beneficiary, so intermediaries can screen who is really behind the payment.
​

Cross-border wires travel in one of two ways. In the serial method, the MT103 itself hops from bank to bank until it reaches the beneficiary's bank. In the cover method, the originating bank sends the MT103 directly to the beneficiary's bank and sends a separate bank-to-bank message through the correspondent chain to settle the money. The cover method is faster, but it created a blind spot.
​

Before 2009, that settlement leg used a plain MT202, which had no fields for the originator or beneficiary. Wikipedia's MT202 COV entry explains that intermediary banks could not perform AML or compliance checks on the origin and destination of funds, and that MT202 COV was implemented in 2009 to create that traceability. The plain MT202 remained for true bank-to-bank transfers, such as settling FX trades.
​

Under ISO 20022 the same split continues with new names. The BNY migration table maps MT202 to pacs.009 and MT202 COV to pacs.009 COV, while MT103 maps to pacs.008. A treasury team tracing a cover payment may therefore need two documents: the pacs.008 that names the beneficiary, and the pacs.009 COV that shows how the funds moved between banks.
​

The MT103 has been replaced by pacs.008, the ISO 20022 FI-to-FI customer credit transfer message. After a multi-year period in which both formats ran side by side, Swift ended coexistence for cross-border payment instructions, so banks must now send pacs.008 or rely on a temporary, paid conversion service.
​

The timeline is short and specific. BNY's notice states that coexistence began in March 2023 and that beginning November 22, 2025, all cross-border payments must be exchanged exclusively in ISO 20022 format using the FINplus service. State Street's client guide likewise describes Swift retiring general usage of in-scope MT payment and cash messages in November 2025.
​

Swift did not simply switch MT103 off. Per the BNY notice, banks that keep sending MT103s are automatically enrolled in a charged conversion service that translates them into pacs.008, but only after stricter validation, and only at payment initiation. The service is aimed at institutions sending fewer than 15,000 MT payment instructions per month, and higher-volume banks must agree alternatives with Swift directly. Receivers can still get an MT-format copy through Swift's in-flow translation, which the same notice says became chargeable for payment instructions from January 2026.
​

Not every MT message disappeared. The BNY notice lists reporting messages, including MT940 and MT950 statements and MT900/MT910 debit and credit confirmations, as remaining on the FIN network until Swift sets an end date. The MT101 request for transfer also continues for now. Treasury teams can therefore still see MT940 statements alongside pacs.008 payment data.
​

The biggest practical change is data quality. pacs.008 separates names, addresses, and remittance details into dedicated elements rather than free text. State Street notes that unstructured addresses will be accepted only until November 2026, after which hybrid or structured addresses become mandatory. For anyone requesting a wire confirmation today, the facts to look for are the same as before, but they appear under ISO 20022 labels: debtor, creditor, creditor agent, charge bearer, and UETR.
​

The MT103, and now pacs.008, belong to the correspondent-banking world of international wires. Domestic rails such as ACH and Fedwire, card networks, and newer instant or blockchain-based rails use different messages and settle differently, so an MT103 only exists when a payment actually travels over Swift.
​

A US domestic wire goes over Fedwire rather than Swift, so it produces a Fedwire confirmation rather than an MT103. Since July 14, 2025, Fedwire itself uses ISO 20022 messages, according to the Federal Reserve's gpi practice note, which brings domestic and cross-border wire data closer together. For a side-by-side view of cost and speed, see ACH vs wire transfers and the broader overview of payment rails.
​

Some finance teams now pair traditional wires with stablecoin settlement for specific corridors or treasury moves between entities. Eco is one company building in that area, offering stablecoin payment infrastructure that settles onchain rather than through a correspondent chain. For most cross-border supplier payments, though, the MT103 successor, pacs.008, remains the document that proves a wire was sent.
​