What is an MT103?
SWIFT message, fields and example.
An MT103 is the legacy SWIFT FIN format for a single customer credit transfer. It records the sender, beneficiary, amount, currency, charges, and UETR in field 121. Since November 2025, banks exchange pacs.008 instructions for CBPR+ cross-border payments, while an MT103-format confirmation can still be the bank's customer-facing record.
Trace a SWIFT transfer
AI assistedSee bank reports, and get an email when the payment reaches a new stage.
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 · CBPR+ successor to 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-format confirmation records a payment instruction, not a settlement. Once your bank dispatches the payment instruction, 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.
A bank-issued MT103 copy can document the instruction the sending bank released, but it does not establish receipt or settlement. The routing details are there, but the live tracker events are not.
That is what the UETR shown on the MT103-format confirmation is for. Paste the UETR into uetr.ai and we surface the available timeline from SWIFT's tracking network. The free check shows the plain-language status and how many banks have reported. Paid plans open the bank-by-bank reports with bank names and exact status codes.
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 an annotated sample.
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 an annotated sample MT103
{1:F01RCVBUS33AXXX0000000000}
{2:O1031200250527SNDBGB2LAXXX00000000002505271201N}
{3:{121:6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22}}
{4:
:20:CUST-REF-12345
:23B:CRED
:32A:250527USD25000,00
:50K:/12345678
ACME EXPORTS LIMITED
:52A:SNDBGB2LXXX
:57A:RCVBUS33XXX
:59:/87654321
GLOBAL IMPORTS INC
:70:INV-2025-0421
:71A:OUR
-}
{5:{CHK:000000000000}}In plain English, this illustrative MT103 says: on 27 May 2025 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-2025-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, for CBPR+ cross-border payments. SWIFT migrated that bank-to-bank traffic to the ISO 20022 standard under its CBPR+ programme, and the MT/ISO coexistence period ended in November 2025. The MT103's successor for those instructions 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.

SWIFT has extended the structured-address timetable. Its August 2026 announcement deferred the November 2026 payments changes, with an update on revised timing and approach due by December 2026 at the latest. Keep preparing town and country as separate fields and confirm your bank's requirements. The UETR is unchanged. 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 instructions for CBPR+ cross-border payments, 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. Since November 2025, banks have exchanged pacs.008 instructions for CBPR+ cross-border payments, 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
Delivery time and any fee vary by bank. 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. While the transfer is in progress, free tracking re-checks every 24 hours for up to 30 days from submission. Emails follow further payment stages, at most once 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 legacy SWIFT FIN format for a single customer credit transfer. It records the sender, beneficiary, amount, currency, charges, and UETR in field 121. Since November 2025, banks exchange pacs.008 instructions for CBPR+ cross-border payments, while an MT103-format confirmation can still be the bank's customer-facing record.
What does MT103 mean in banking?
In banking, MT103 names the legacy SWIFT FIN format for a single customer credit transfer. It carries the sender, beneficiary, amount, currency, charges, remittance information, and the UETR in field 121. Since the CBPR+ coexistence period ended in November 2025, banks exchange pacs.008 instructions for CBPR+ cross-border payments while some customer confirmations still use the MT103 layout.
What is MT103 in banking?
An MT103 is the legacy SWIFT FIN format for a single customer credit transfer. It records the sender, beneficiary, amount, currency, charges, and UETR in field 121. Since November 2025, banks exchange pacs.008 instructions for CBPR+ cross-border payments, while an MT103-format confirmation can still be the bank's customer-facing record.
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. Since the CBPR+ migration completed in November 2025, banks have exchanged pacs.008 instructions for CBPR+ cross-border payments, 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?
The phrase 'MT103 wire transfer' refers to a cross-border customer payment represented in the legacy SWIFT MT103 format. Since November 2025, banks exchange pacs.008 instructions for CBPR+ cross-border payments, but a bank may still give its customer an MT103-format confirmation of the instruction.
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 an MT103 copy or SWIFT advice from the sending bank through the payment-details area of its portal, a secure message, a branch, or the relationship manager. Ask for the copy that shows the UETR. Delivery time, document layout, and any fee vary by bank.
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 exchange pacs.008 instructions for CBPR+ cross-border payments while still issuing MT103-format confirmations to customers.
Is the MT103 being replaced by ISO 20022?
For CBPR+ cross-border payments, it already has been. SWIFT's CBPR+ coexistence period ended in November 2025, and the MT103's successor for those instructions is the ISO 20022 pacs.008 message. Two things did not change: banks still issue customers a confirmation of the instruction, a bank may issue that confirmation in either layout, and the UETR from field 121 carries over into pacs.008 unchanged, so the same reference tracks the payment.
Do MT103 and pacs.008 messages need structured addresses?
Structured and hybrid addresses are already available for CBPR+ pacs.008 payments. SWIFT has deferred the planned November 2026 removal of unstructured addresses and will provide an update on revised timing and approach by December 2026 at the latest. Confirm your bank's address requirements for the channel you use, including MT-based corporate channels. The UETR is unchanged. See our ISO 20022 address requirements guide for formats and preparation steps.
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. Since the CBPR+ migration completed in November 2025, banks have exchanged pacs.008 instructions for CBPR+ cross-border payments, 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?
A sender cannot unilaterally cancel a payment after release. The sending bank can request cancellation using an MT192 or the ISO 20022 camt.056 message. If funds are returned, the return travels separately, now as a pacs.004 for CBPR+ payments. The outcome depends on the payment's state and the cooperation of the banks involved.
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?
The MT103 format does not set the delivery time. Timing depends on the banks, correspondent route, currency, compliance checks, cut-off times, weekends, and holidays. If the payment is delayed, use the UETR from field 121 to request a gpi trace or read the reported status.
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 the latest reported gpi status: the full walkthrough.
International wire transfer tracking
Every way to follow a cross-border wire while it is still being processed.
SWIFT payment confirmation
What an MT103-format advice proves, what it does not, and the credit confirmation that shows the money arrived.
SWIFT status codes
ACSP, ACSC, ACCC, PDNG, RJCT: what each one means for your MT103.
ISO 20022 address requirements
The extended SWIFT timetable and how to prepare structured or hybrid addresses.
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.