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

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.

One MT103 = one transfer. Sender, beneficiary, amount, charges, and a note line, plus the UETR tracking number.
Succeeded by pacs.008 between banks since November 2025, when SWIFT's ISO 20022 coexistence period ended. The UETR travels in both, unchanged.
"MT103 copy" or "SWIFT copy" is the printout you ask your bank for as its record that the transfer instruction was sent, and used in trade finance as a payment confirmation.

Trace a SWIFT transfer

See where your transfer is in the banking network right now, and get alerted when the status changes.

AI assisted

The 36-character reference on your bank confirmation.

Where do I find this?

It is on your outbound payment confirmation or transfer advice, on the MT103 (field 121), or in your bank app under the payment's details.

Cannot see it? Ask your bank for "the UETR of my transfer", they can read it out in seconds. More about the UETR

Required by banks to locate the payment.

We check multiple bank data sources to monitor your transfer and send you a free alert, at most once a day, 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.

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.

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 · ISO 20022 replacement for 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 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.

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 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), 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 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.

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

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.
SWIFT migrated cross-border bank-to-bank payments from MT103 to the ISO 20022 pacs.008 message in November 2025, under CBPR+. The format changed, but the 36-character UETR survives unchanged.

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.

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

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.

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