What is MT103?
The SWIFT customer credit transfer message.
An MT103 is the message a bank sends over the SWIFT network to make a single international customer credit transfer. It carries the sender, the beneficiary, the amount, the currency, who pays the charges, and the UETR tracking reference in field 121. Banks issue an MT103 copy as their record that a payment instruction was released over the SWIFT network.
Trace a SWIFT transfer
See where your transfer is in the banking network right now, and get alerted when the status changes.
What is an MT103?
An MT103 is the SWIFT message a bank sends to instruct an international payment from one customer to another. It records the sender, the beneficiary, the amount, the currency, the charges, and the 36-character UETR in field 121, which is the reference that tracks the payment from bank to bank.
MT103 at a glance
A quick reference for the MT103 message, what it is, how it is put together, and where the UETR sits.
{121:6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22}
Block-by-block
Interactive MT103 Field Explorer
Click any line to see what that field means. The UETR sits in field 121, Block 3.
UETR, Field 121 (Block 3)
Field 121 of the user header (Block 3) carries the UETR, the 36-character UUID v4 that tracks this payment end-to-end across the correspondent chain. Mandatory on every MT103 since 18 November 2018.
:20:, :32A:, :59:, etc. Click each line above to see what it means.MT103 field specifications: the complete list
Every field that can appear in Block 4 of an MT103, in message order, plus the header field that carries the UETR. "a" after a tag (as in 50a) means the field has lettered variants such as 50A, 50F, and 50K.
| Field | Name | Status | What it carries |
|---|---|---|---|
| 121 | UETR (Block 3 header) | Mandatory | The 36-character Unique End-to-end Transaction Reference that tracks the payment across every bank. Sits in the user header, not in Block 4. |
| 20 | Sender's Reference | Mandatory | The sending bank's own reference for the transaction, up to 16 characters. Often shown as the transaction ID in online banking. Not the UETR. |
| 13C | Time Indication | Optional | Timestamps tied to settlement systems, such as the CLS time or the credit or debit time to the settlement account. |
| 23B | Bank Operation Code | Mandatory | The operation code of the transfer. CRED, a normal credit transfer with no SWIFT service level, is what nearly every customer transfer shows; SPAY, SPRI, and SSTD marked transfers under specific SWIFT service levels. |
| 23E | Instruction Code | Optional | Special handling instructions such as SDVA (same day value), INTC (intra-company payment), or PHOB (advise beneficiary by phone). |
| 26T | Transaction Type Code | Optional | A 3-character code identifying the nature of the payment for regulatory reporting in some corridors. |
| 32A | Value Date / Currency / Interbank Settled Amount | Mandatory | The date the transfer settles between the banks, the currency code, and the settled amount, written with a European decimal comma. |
| 33B | Currency / Instructed Amount | Optional | The original amount the customer instructed, before any charges were deducted or currency conversion applied. Comparing 33B with 32A shows what was taken along the way. |
| 36 | Exchange Rate | Optional | The exchange rate applied when the instructed currency in 33B differs from the settlement currency in 32A. |
| 50a | Ordering Customer | Mandatory | The sender of the payment. Variant 50K carries an account number and free-form name and address; 50A carries a BIC; 50F carries a structured identity. |
| 51A | Sending Institution | Optional | Identifies the sending institution on FileAct or in a few special cases. Rare on customer copies. |
| 52a | Ordering Institution | Optional | The financial institution of the ordering customer when it differs from the sender of the message itself. |
| 53a | Sender's Correspondent | Optional | The bank through which the sending bank reimburses the receiver, usually the sender's nostro account holder in the payment currency. |
| 54a | Receiver's Correspondent | Optional | The bank at which the receiving bank collects the funds, its correspondent in the payment currency. |
| 55a | Third Reimbursement Institution | Optional | A further intermediary in the reimbursement chain when settlement needs three correspondents. Uncommon. |
| 56a | Intermediary Institution | Optional | An intermediary bank between the receiver and the account-with institution. When your transfer stalls at a go-between bank, this is often the bank named here. |
| 57a | Account With Institution | Optional | The institution that services the beneficiary's account, usually the beneficiary's own bank. |
| 59a | Beneficiary Customer | Mandatory | The final recipient: account number or IBAN on the first line, then the name and address. |
| 70 | Remittance Information | Optional | The free-text note to the beneficiary, up to 4 lines of 35 characters, typically an invoice or contract reference. |
| 71A | Details of Charges | Mandatory | Who pays the fees: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays all). |
| 71F | Sender's Charges | Optional | The charges already deducted by the sender or earlier banks in the chain, one line per bank. Explains why the beneficiary received less than was sent. |
| 71G | Receiver's Charges | Optional | The charges the receiving bank will apply for its role in the transfer, present when 71A is OUR. |
| 72 | Sender to Receiver Information | Optional | Bank-to-bank instructions in coded form, such as /INS/ (instructing institution) or /ACC/ (account with institution information). Not shown to the beneficiary. |
| 77B | Regulatory Reporting | Optional | Statutory reporting codes required by the authorities in the sender or beneficiary country, such as the residence of the ordering or beneficiary customer. Structured line 1: /8a/2!a//additional information, for example /ORDERRES/BE//MEILAAN 1, 9000 GENT. |
| 77T | Envelope Contents | Optional | Extended remittance information, carried only by the MT103 REMIT variant between institutions that have agreed to exchange it. |
The lettered variants (A, B, C, D, F, K) change how a party is identified, for example 50K = account plus name and address, 50A = account plus BIC, 57A = BIC, 57D = name and address. A customer copy of an MT103 usually shows only the fields that were actually used, which is why two MT103 documents rarely look identical.
MT103 vs MT202 vs MT202COV vs pacs.008
MT103 sits in a family of SWIFT customer-payment messages. The differences matter when you are reading a SWIFT copy or troubleshooting a delayed transfer.
| Message | Purpose | Format | Carries UETR? |
|---|---|---|---|
| MT103 | Single customer credit transfer | SWIFT FIN MT | Yes · field 121 |
| MT202 | Financial-institution-to-FI transfer | SWIFT FIN MT | Yes · field 121 |
| MT202COV | Cover payment that funds an underlying MT103 (cover model) | SWIFT FIN MT | Yes · mirrors underlying MT103 |
| MT192 | Request for cancellation of an MT103 | SWIFT FIN MT | Yes · references original UETR |
| pacs.008 | Customer credit transfer · ISO 20022 replacement for MT103 | ISO 20022 XML | Yes · UETR element |
| pacs.009 | FI-to-FI credit transfer · ISO 20022 replacement for MT202 | ISO 20022 XML | Yes · UETR element |
| pacs.004 | Payment return · ISO 20022 replacement for return leg | ISO 20022 XML | Yes · references original UETR |
Why is my MT103 transfer delayed?
An MT103 is an instruction, not a settlement. Once your bank dispatches it, the transfer often passes through one or more go-between banks (the industry calls them correspondent banks) before it reaches the beneficiary's bank. Each go-between has its own compliance checks, cut-off times, and operational queue, and any of them can hold the transfer for hours or days.
Your bank's online portal usually only shows you what your bank did with the transfer. The steps in between, where most delays actually happen, live in SWIFT's own tracking system, tied to the UETR.
This is why an MT103 copy proves the transfer was sent, but does not tell you what happened to it after it left your bank. The routing instructions are all there, but the live tracker events are not.
That is what the UETR (the tracking number inside the MT103) is for. Paste the UETR into uetr.ai and we surface the available timeline from SWIFT's tracking network, so you know which bank in the chain is causing the delay.
Watch: track a stuck transfer with the UETR on your MT103
Get the UETR from field 121, then read the gpi status yourself instead of waiting on a phone line.
Where the UETR sits in an MT103
The five blocks of a SWIFT MT103, and the one that carries your UETR: Block 3, field 121.

How does an MT103 work?
The 5 sections of the message, the fields that matter, and a real sample annotated.
01/ The 5 sections of an MT103
An MT103 message is divided into 5 sections that SWIFT calls "blocks". Block 1 carries the logical terminal address at one end of the delivery: the sender on the way into the network, the receiver on the output copy above. Block 2 says what kind of message it is (in this case "103", a customer transfer), which direction the copy is travelling, and, on an output copy, which bank sent it. Block 3 is where the UETR tracking number lives. Block 4 is the payment instruction itself: sender, beneficiary, amount. Block 5 is an ending section with a checksum the SWIFT network adds.
When you look at a SWIFT copy, blocks 1, 2, and 5 are technical details you do not need. Block 3 holds the UETR. Block 4 is the actual payment.
02/ The fields that actually matter
Block 4 has up to 28 numbered fields, but only a few do the real work and appear on every transfer:
- :20: the bank's internal reference for this transaction
- :32A: the value date, currency, and amount
- :50: who is sending the money
- :57: the beneficiary's bank
- :59: the beneficiary (their account + name)
- :70: the note to the beneficiary (e.g. invoice number)
- :71A: who pays the fees:
OUR(sender),SHA(shared), orBEN(beneficiary)
These are the fields the beneficiary cares about. The UETR (in Block 3 above) is what you care about for tracking.
03/ Reading a real sample MT103
{1:F01RCVBUS33AXXX0000000000}
{2:O1031200260527SNDBGB2LAXXX00000000002605271201N}
{3:{121:6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22}}
{4:
:20:CUST-REF-12345
:23B:CRED
:32A:260527USD25000,00
:50K:/12345678
ACME EXPORTS LIMITED
:52A:SNDBGB2LXXX
:57A:RCVBUS33XXX
:59:/87654321
GLOBAL IMPORTS INC
:70:INV-2026-0421
:71A:OUR
-}
{5:{CHK:000000000000}}In plain English, this MT103 says: on 27 May 2026 at 12:00, SNDBGB2L (the sending bank) sent USD 25,000 to RCVBUS33 (the receiving bank). The money is from ACME Exports Limited, account 12345678, going to Global Imports Inc, account 87654321, against invoice INV-2026-0421. The sender is paying all the fees (OUR). The UETR to track it is 6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22.

Is the MT103 being replaced by ISO 20022?
Yes, and on the bank-to-bank network it already has been. SWIFT migrated cross-border payment messaging to the ISO 20022 standard under its CBPR+ programme, and the MT/ISO coexistence period ended in November 2025. The MT103's successor is the pacs.008 message, which we cover element by element in its own guide.
The reason for the change: MT103 is a 1970s-era plain-text format with tight character limits, while pacs.008 is a modern XML structure that carries much richer information, such as full beneficiary addresses, structured purpose codes, and more remittance text.
Two things did not change for customers. First, banks still issue MT103-format confirmations (SWIFT copies) as payment confirmations, so the document you request from your bank looks the same.
Second, the UETR carries over unchanged. Inside an MT103 it sits in field 121 (Block 3); inside pacs.008 it travels in the payment identification block. It is the same 36-character tracking reference either way, so you track a pacs.008-era transfer exactly as before: paste the UETR into uetr.ai and read the gpi timeline.

The next milestone is about the data, not the message. From 14 November 2026, the addresses inside cross-border payment messages must be structured or hybrid: town and country in dedicated fields for every party, with fully free-text addresses rejected by the network. If your bank has asked you to confirm your address details, that deadline is the reason. Read the ISO 20022 address requirements guide →
Is an MT103 proof of payment?
A bank-issued MT103 copy purports to record a payment instruction released by the sending bank over the SWIFT network. What it sets out is that instruction, not its arrival: it does not establish receipt or settlement, so pair it with a UETR status check to see what the tracker sources report.
What separates a bank-issued advice from a document a customer produced is its source. A genuine advice obtained directly from the sending bank sets out the instruction the bank released, produced by the bank from its own records, not by the customer. Since the CBPR+ migration completed in November 2025 banks exchange pacs.008 between themselves, so an MT103-format advice is the sending bank's customer-facing record of that instruction rather than a copy of the message that travelled between the banks. It shows the amount and currency (field 32A), the value date, the ordering customer (field 50), the beneficiary (field 59), the banks in the route, and who pays the charges (field 71A). That is why a counterparty may ask for an MT103 advice when it wants the sending bank's own record of an instruction. What weight it carries in a dispute depends on the parties and the forum involved.
What an MT103 does not prove is that the money was credited to the beneficiary account. Settlement and credit happen after dispatch, at the beneficiary bank, and a payment can still be held for compliance review, returned, or rejected. This confusion is sometimes abused: a stranger may present an MT103 screenshot or PDF as if it were confirmation of received funds. An MT103 you cannot verify, sent by a stranger to prove a payment to you, is a warning sign, not proof.
To cross-check the details an MT103 shows, read field 121 in Block 3. It carries the UETR, the 36-character tracking reference for the payment. Paste that UETR into uetr.ai and read what the tracker sources report: ACSP is the in-transit code, and ACCC is the code a beneficiary bank sends when it credits the account. A lookup shows only what supported tracker sources returned when queried. It cannot authenticate the document, and a real UETR can appear on a document that is not genuine, so confirm anything consequential directly with the bank.
How do I get an MT103 SWIFT copy from my bank?
A SWIFT copy (MT103 advice, MT103 confirmation) is a PDF or printout that purports to reproduce the sending bank's own record of the payment instruction it released; a genuine copy is one obtained directly from the bank. Banks have exchanged pacs.008 between themselves since November 2025, so a copy issued in the MT103 layout is that customer-facing record rather than the message that travelled between the banks. It is the document a beneficiary or counterparty may ask for when they want the sending bank's record of the instruction.
Identify the transfer
Have the date sent, the amount, the currency, and the sending bank's customer reference (field 20) ready. Your online banking transaction ID usually maps to field 20.
Open the request
Business accounts: relationship manager or 'request SWIFT copy / MT103 copy' workflow in the corporate banking portal. Retail accounts: branch visit or secure-message ticket. Phone is the slowest way.
Specify 'MT103' explicitly
Some staff offer a payment receipt or debit advice instead. Those do not show the UETR or field-level SWIFT structure. Ask for 'the SWIFT MT103 copy with field 121 UETR'.
Check it at uetr.ai, then leave the monitor running
Most banks deliver within 1 to 3 business days. When you receive the document, copy the 36-character UETR from field 121. Enter the 36-character UETR in the form at uetr.ai with the amount, currency and payment date. It is free, with no account and no bank login. uetr.ai checks multiple international banks on the SWIFT network for that reference, not only the sending bank. Checking then continues on its own: a free transfer is re-checked every 24 hours for 30 days, and you get at most one update email a day.
Get an MT103 from your bank
Bank-by-bank guides to requesting an MT103 SWIFT copy and finding the UETR in field 121.
FAQ
Frequently asked questions about MT103
What is an MT103?
An MT103 is the SWIFT message a bank sends to instruct an international payment from one customer to another. It records the sender, the beneficiary, the amount, the currency, the charges, and the 36-character UETR in field 121, which is the reference that tracks the payment from bank to bank.
What is MT103?
MT103 is the SWIFT FIN message type used for single customer credit transfers between two financial institutions. It carries the full payment instruction, sender, beneficiary, amount, currency, charges, remittance information, and the UETR (in field 121) that tracks the payment end-to-end across the correspondent banking chain.
What is MT103 in banking?
In banking, MT103 is the standard SWIFT message that one bank sends to another to instruct a customer credit transfer. It is the document your sending bank can give you as its record that a payment instruction was released over SWIFT. In trade finance it serves as a payment-confirmation document, and a beneficiary or counterparty may ask for one when they want the sending bank's record that the payment instruction entered the SWIFT network.
What is an MT103 SWIFT message?
An MT103 SWIFT message is one of the standard FIN message types in the SWIFT MT catalogue. The number 103 identifies it as a single customer credit transfer. The message is composed of header blocks (basic, application, user) and a text block with up to 28 fields including ordering customer (50), beneficiary (59), amount (32A), and the UETR (121).
What is MT103 swift confirmation?
An MT103 SWIFT confirmation is a printout (PDF or paper) that purports to reproduce the sending bank's own record of the payment instruction it released; a genuine copy is one obtained directly from the bank. Banks have exchanged pacs.008 between themselves since the CBPR+ migration completed in November 2025, so a confirmation issued in the MT103 layout is that customer-facing record rather than the message that travelled between the banks. It shows every field, including the UETR. A beneficiary or counterparty may ask for it when they want the sending bank's record of the instruction, and in trade finance it is used as a payment confirmation.
What is MT103 wire transfer?
An MT103 wire transfer is an international transfer that has been sent over the SWIFT network using the MT103 message type. Most cross-border bank transfers (USD, EUR, GBP, JPY and other major currencies) are routed as MT103 messages between sending and beneficiary banks, often passing through one or more intermediary banks acting as USD or EUR correspondents.
What is field 121 in MT103?
Field 121 is a tag in the SWIFT MT user header (Block 3) that carries the UETR, the 36-character Unique End-to-end Transaction Reference. It was introduced for SWIFT gpi tracking in 2017 and made mandatory on every FIN customer credit transfer (MT103, MT202, MT202COV, MT205, MT205COV) from 18 November 2018. On a printed MT103 advice it appears as '{121:6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22}'.
Which fields are mandatory in an MT103?
Six fields of Block 4 are mandatory in every MT103: field 20 (sender's reference), field 23B (bank operation code), field 32A (value date, currency, and settled amount), field 50a (ordering customer), field 59a (beneficiary customer), and field 71A (details of charges). Everything else, including the intermediary fields 53a to 57a, the remittance note in field 70, and the regulatory reporting in field 77B, is optional and appears only when it is needed. The UETR in field 121 is also mandatory but travels in the Block 3 header, not in Block 4.
What is field 77B in an MT103?
Field 77B (Regulatory Reporting) carries the statutory codes some central banks require on cross-border payments, such as the residence status of the parties or a balance-of-payments purpose code. It is optional and corridor-specific: a transfer between two countries with no reporting requirement will not have it, while payments to or from countries with exchange-control regimes often must include it. A missing or wrong 77B code is one of the reasons a payment can be held for repair at an intermediary bank.
How do I get an MT103 SWIFT copy from my bank?
Request a SWIFT MT103 copy from your sending bank's relationship manager, business banking team, or via your corporate banking portal (HSBCnet, J.P. Morgan Access, CitiDirect, Deutsche Bank Autobahn, Bank of America CashPro, Santander Cash Nexus, Standard Chartered Straight2Bank). Retail customers usually need to call the branch or open a secure-message ticket. Most banks deliver the MT103 PDF within 1 to 3 business days; some charge a fee for paper copies.
MT103 vs MT202: what is the difference?
MT103 is a customer credit transfer, the underlying payment instructed by the customer. MT202 is a financial-institution-to-financial-institution transfer, often used to move the cover funds between banks supporting an MT103 (the cover model). MT202COV is the explicit cover variant that references the underlying MT103. In a cover-model payment, the MT103 and the MT202COV share the same UETR.
Is MT103 the same as pacs.008?
Functionally similar, technically different. MT103 is the legacy SWIFT FIN MT format; pacs.008 (FIToFICustomerCreditTransfer) is the ISO 20022 XML replacement. Both carry the same customer credit transfer information and both carry a UETR. SWIFT's cross-border migration to ISO 20022 (CBPR+) completed in November 2025, when the MT/ISO coexistence period ended, so banks now exchange pacs.008 between themselves while still issuing MT103-format confirmations to customers.
Is the MT103 being replaced by ISO 20022?
On the bank-to-bank network it already has been. SWIFT's coexistence period for cross-border payment messages ended in November 2025, and the MT103's successor is the ISO 20022 pacs.008 message. Two things did not change: banks still issue customers a confirmation of the instruction, and a bank may issue that confirmation in either layout, and the UETR from field 121 carries over into pacs.008 unchanged, so tracking works exactly the same.
Do MT103 and pacs.008 messages need structured addresses?
The network rule applies to the pacs.008: from 14 November 2026, SWIFT's Standards Release 2026 requires the town and country of every party to sit in dedicated structured elements of the ISO 20022 message banks exchange, and messages whose addresses are fully free text are rejected. An MT103-format document itself has no such elements; after the 2025 migration it mainly survives as the customer confirmation. The requirement still reaches you indirectly: if you submit instructions in an MT-based corporate channel, your bank needs your beneficiary's town and country to build a compliant pacs.008. The UETR is unaffected. See our ISO 20022 address requirements guide for the full breakdown.
What is MT103 copy?
An MT103 copy (also called a SWIFT copy, MT103 advice, or MT103/202 copy) is a PDF or printout that purports to reproduce the sending bank's own record of the payment instruction it released; a genuine copy is one obtained directly from the bank. Banks have exchanged pacs.008 between themselves since the CBPR+ migration completed in November 2025, so a copy issued in the MT103 layout is that customer-facing record rather than the message that travelled between the banks. It typically shows all fields including the UETR, ordering customer, beneficiary, intermediary bank, amount, charges, and remittance information. Banks issue it on request as supporting documentation.
Can MT103 be cancelled or recalled?
Once an MT103 has been released and accepted by the beneficiary bank, it usually cannot be unilaterally cancelled by the sender. A recall is requested via the SWIFT MT192 (Request for Cancellation of a Customer Transfer), or its ISO 20022 equivalent camt.056; if funds are returned, the return travels as an MT103/202 RETN or a pacs.004 (Payment Return). It requires the beneficiary bank's cooperation. Most recall requests succeed only if funds have not yet been credited to the beneficiary account.
Is an MT103 proof of payment?
A bank-issued MT103 copy purports to record a payment instruction released by the sending bank over the SWIFT network. What it sets out is that instruction, not its arrival: it does not establish receipt or settlement, so pair it with a UETR status check to see what the tracker sources report. Whether any document is sufficient in a given dispute is for the parties and the forum involved.
How long does an MT103 take?
An MT103 routed over SWIFT gpi typically settles within minutes to a few hours when both banks are gpi members and there are no intermediaries or compliance holds. End-to-end including correspondent banks and sanctions screening, most international MT103s arrive within one to five business days, with weekends, holidays, and time-zone cutoffs adding delay.
Related guides
The tracking reference inside the MT103, and what to do with it when a transfer runs late.
What is pacs.008?
The ISO 20022 successor of the MT103: format, elements, and the field mapping.
What is a UETR?
The 36-character reference in field 121, explained with format and examples.
Track a SWIFT payment step by step
From MT103 copy to live gpi status: the full walkthrough.
International wire transfer tracking
Every way to follow a cross-border wire while it is still being processed.
SWIFT status codes
ACSP, ACSC, ACCC, PDNG, RJCT: what each one means for your MT103.
ISO 20022 address requirements
From 14 November 2026 payments need structured addresses, or the network rejects them.
How long does an international wire take?
Realistic timelines for an MT103 by corridor, and when to worry.
ACH vs wire transfer
How the SWIFT wire behind an MT103 differs from a domestic ACH payment.
Regulatory Disclosure
uetr.ai is an independent information service. We are strictly a read-only payment-monitoring tool. We never hold, move, custody, send, or process money. We are not a money transmitter or payment processor. Always consult your sending bank for the official record of any bank transfer.