Home/What is MT103?
SWIFT FIN Message Type · Customer Credit Transfer

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.

What it contains: sender, beneficiary, amount, currency, charges, remittance information, and the UETR tracking reference.
For CBPR+ cross-border payments, pacs.008 succeeded MT103 in November 2025, when SWIFT's ISO 20022 coexistence period ended. The UETR travels in both, unchanged.
An MT103 copy records the instruction, not its arrival. Get a genuine copy directly from the sending bank, then use its UETR to read the reported payment status.

Trace a SWIFT transfer

AI assisted

See bank reports, and get an email when the payment reaches a new stage.

The reference code on the bank transfer confirmation.

Required by banks to locate the payment.

We check daily and email you when the payment reaches a new stage.

The first result often appears in seconds. If the banks can see your transfer, you will see it too.

MT103 at a glance

A quick reference for the MT103 message, what it is, how it is put together, and where the UETR sits.

Message typeMT103
PurposeCustomer credit transfer
Blocks5 (basic/app/user/text/trailer)
UETR locationBlock 3 · field 121
How field 121 (the UETR) appears in an MT103

{121:6f8d3a2b-1c44-4f8e-9b21-7d2c9f0a1b22}

Block-by-block

Block 1Basic header
Block 2Application header
Block 3User header (field 121 = UETR)
Block 4Text (fields 20, 23B, 32A, 50, 52, 57, 59, 70, 71A …)
Block 5Trailer (CHK)
Read order: 1 → 2 → 3 → 4 → 5. Blocks 1, 2, and 5 are network metadata. Block 3 is where the UETR lives. Block 4 is the payment instruction itself.

Interactive MT103 Field Explorer

Click any line to see what that field means. The UETR sits in field 121, Block 3.

sample-mt103.txt
-}
{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.

This is the field you care about. The UETR in field 121 is what you paste into uetr.ai to track the payment across every correspondent in the chain.
How to read this: blocks 1, 2, 3, 5 wrap the message; block 4 holds the payment instruction with up to 28 fields tagged like :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.

FieldNameStatusWhat it carries
121UETR (Block 3 header)MandatoryThe 36-character Unique End-to-end Transaction Reference that tracks the payment across every bank. Sits in the user header, not in Block 4.
20Sender's ReferenceMandatoryThe sending bank's own reference for the transaction, up to 16 characters. Often shown as the transaction ID in online banking. Not the UETR.
13CTime IndicationOptionalTimestamps tied to settlement systems, such as the CLS time or the credit or debit time to the settlement account.
23BBank Operation CodeMandatoryThe 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.
23EInstruction CodeOptionalSpecial handling instructions such as SDVA (same day value), INTC (intra-company payment), or PHOB (advise beneficiary by phone).
26TTransaction Type CodeOptionalA 3-character code identifying the nature of the payment for regulatory reporting in some corridors.
32AValue Date / Currency / Interbank Settled AmountMandatoryThe date the transfer settles between the banks, the currency code, and the settled amount, written with a European decimal comma.
33BCurrency / Instructed AmountOptionalThe 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.
36Exchange RateOptionalThe exchange rate applied when the instructed currency in 33B differs from the settlement currency in 32A.
50aOrdering CustomerMandatoryThe 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.
51ASending InstitutionOptionalIdentifies the sending institution on FileAct or in a few special cases. Rare on customer copies.
52aOrdering InstitutionOptionalThe financial institution of the ordering customer when it differs from the sender of the message itself.
53aSender's CorrespondentOptionalThe bank through which the sending bank reimburses the receiver, usually the sender's nostro account holder in the payment currency.
54aReceiver's CorrespondentOptionalThe bank at which the receiving bank collects the funds, its correspondent in the payment currency.
55aThird Reimbursement InstitutionOptionalA further intermediary in the reimbursement chain when settlement needs three correspondents. Uncommon.
56aIntermediary InstitutionOptionalAn 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.
57aAccount With InstitutionOptionalThe institution that services the beneficiary's account, usually the beneficiary's own bank.
59aBeneficiary CustomerMandatoryThe final recipient: account number or IBAN on the first line, then the name and address.
70Remittance InformationOptionalThe free-text note to the beneficiary, up to 4 lines of 35 characters, typically an invoice or contract reference.
71ADetails of ChargesMandatoryWho pays the fees: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays all).
71FSender's ChargesOptionalThe 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.
71GReceiver's ChargesOptionalThe charges the receiving bank will apply for its role in the transfer, present when 71A is OUR.
72Sender to Receiver InformationOptionalBank-to-bank instructions in coded form, such as /INS/ (instructing institution) or /ACC/ (account with institution information). Not shown to the beneficiary.
77BRegulatory ReportingOptionalStatutory 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.
77TEnvelope ContentsOptionalExtended 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.

MessagePurposeFormatCarries UETR?
MT103Single customer credit transferSWIFT FIN MTYes · field 121
MT202Financial-institution-to-FI transferSWIFT FIN MTYes · field 121
MT202COVCover payment that funds an underlying MT103 (cover model)SWIFT FIN MTYes · mirrors underlying MT103
MT192Request for cancellation of an MT103SWIFT FIN MTYes · references original UETR
pacs.008Customer credit transfer · CBPR+ successor to MT103ISO 20022 XMLYes · UETR element
pacs.009FI-to-FI credit transfer · ISO 20022 replacement for MT202ISO 20022 XMLYes · UETR element
pacs.004Payment return · ISO 20022 replacement for return legISO 20022 XMLYes · 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.

SWIFT MT103 message structure showing its five blocks, with the UETR highlighted in Block 3 (the User Header) as field 121.
A SWIFT MT103 has five blocks. The UETR sits in Block 3, the User Header, as 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), or BEN (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.

Annotated MT103 message format with every field labelled: the basic, application and user headers, field 121 (the UETR), and the text-block payment fields 20, 23B, 32A, 50K, 52A, 57A, 59, 70 and 71A, plus the trailer.
An MT103 field by field: the headers, the UETR in field 121, the payment fields (20, 32A, 50K, 59, 71A and more), and the trailer.

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.

Side-by-side of the legacy MT103 FIN message and the new pacs.008 ISO 20022 XML message, showing field 121 becomes the UETR element while the value stays the same.
For CBPR+ cross-border customer-payment instructions between financial institutions, the MT and ISO 20022 coexistence period ended in November 2025. pacs.008 succeeded MT103 for those instructions, while the 36-character UETR stayed unchanged.

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.

01

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.

02

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.

03

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'.

04

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.

Got the UETR? Paste it into uetr.ai. We check public SWIFT gpi tracker sources all day, every 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.