What is an MT103 used for?

It is the instruction one bank sends to another to pay money to a customer, usually across borders. Banks also give a copy to customers as proof that a payment was sent, which is why people ask for "the MT103" when a transfer has not arrived.

Is the MT103 still used after November 2025?

For cross-border payments between banks on Swift, the instruction is now ISO 20022 pacs.008. Banks that still produce MT103 have it converted by Swift’s contingency processing, and many banks keep showing an MT103-style copy to customers. Domestic systems and bank-to-customer channels can still use MT103 formats.

What do OUR, SHA and BEN mean in field 71A?

They say who pays the bank charges. OUR: the sender pays everything and the beneficiary should receive the full amount. SHA: each side pays its own bank. BEN: all charges are deducted from the amount, so the beneficiary receives less.

Where is the UETR in an MT103?

In the user header block (block 3), field 121, for example {3:{121:e0b1c3a2-5d4f-4c8e-9a7b-2f6d1e3c9b40}}. It is a 36-character UUID that stays the same from the first bank to the last. See how to read a UETR.

What is the difference between MT103 and MT202?

An MT103 pays a customer. An MT202 moves money between banks for the banks themselves. The MT202COV is the bank-to-bank cover for an MT103 and carries the underlying customer details.

The same message with {119:STP} in the user header and stricter rules on field options, so the receiving bank can process it without manual repair.

Category 1: Customer payments and cheques

MT103 Single Customer Credit Transfer

Written and maintained by ZagTrader. Last reviewed 21 October 2026. How this page is sourced and checked

The MT103 is the Swift message a bank sends to move money for a customer: it tells the next bank in the chain to credit a beneficiary customer with a stated amount on a stated value date. It travels from the ordering customer’s bank towards the beneficiary’s bank, directly or through intermediaries. On the Swift network, cross-border FI-to-FI payment instructions moved to ISO 20022 pacs.008 on 22 November 2025.

Message type: MT103
Category: 1
Structure: 23 fields listed
ISO 20022: pacs.008

When MT103 is used

An MT103 is used when at least one end of the payment is a customer that is not a financial institution: a company paying a supplier abroad, a person sending money to family, a fund paying out redemption proceeds. The ordering customer’s bank (the Sender) sends it to the Receiver, which either credits the beneficiary itself or passes the payment on.

When the Sender and the beneficiary’s bank do not hold accounts with each other, the payment can go two ways. In the serial method, each bank in the chain sends its own MT103 to the next. In the cover method, the MT103 goes straight to the beneficiary’s bank while the funds travel separately through correspondents in an MT202COV; see the payment flow guide.

Since November 2018 every MT103 carries a UETR (field 121 in the user header block), a unique reference that stays the same across all banks in the chain and lets each of them track the payment.

An MT103 is only for clean payments. It is not used to advise a cheque or a collection, and it is not the cover for a payment advised by another message.

MT103 format: sequences and fields

Message text (block 4)Mandatory

The MT103 has no sequences: block 4 is a single list of fields. 13C, 23E and 71F may repeat.

Tag	Name	Status	Format	Meaning
20	Sender's Reference	M	16x	The Sender’s own reference for this payment. It must not start or end with a slash or contain two slashes in a row. In a cover payment it is copied into field 21 of the MT202COV.
13C	Time IndicationRepeatable	O	/8c/4!n1!x4!n	A time that matters for processing, with its offset from UTC. Codes include CLSTIME (funding deadline for CLS), SNDTIME and RNCTIME.
23B	Bank Operation Code	M	4!c	The type of operation. In practice almost always CRED (normal credit transfer). SPAY, SPRI and SSTD refer to old Swift service levels and switch on stricter rules for other fields; CRTS marks a test message.
23E	Instruction CodeRepeatable	C	4!c[/30x]	Coded instructions for a party in the chain, for example SDVA (same day value), INTC (intra-company payment), CORT (trade settlement), CHQB (pay by cheque), PHOB or TELB (contact the beneficiary). Repeats must follow a set order and some codes cannot be combined.
26T	Transaction Type Code	O	3!c	A code for the nature or purpose of the payment, for example salaries or dividends, usually for statistics or regulatory reporting. Many banks ask you not to use it.
32A	Value Date/Currency/Interbank Settled Amount	M	6!n3!a15d	The value date (YYMMDD), the ISO currency code and the amount the Receiver will be credited between banks, with a comma as the decimal mark. See how to read 32A.
33B	Currency/Instructed Amount	C	3!a15d	The amount the ordering customer asked to send, before charges and currency conversion. Mandatory when 71F or 71G is present, and when both the Sender’s and Receiver’s BICs are in the listed EU/EEA countries.
36	Exchange Rate	C	12d	The rate used to convert the instructed amount in 33B into the settled currency in 32A. Present only when the 33B currency differs from the 32A currency.
50a	Ordering CustomerOptions A, F or K	M	A: [/34x] 4!a2!a2!c[3!c] F: 35x 4(1!n/33x) K: [/34x] 435x	Who is paying. Option A gives an account and a BIC, option K an account with free-text name and address, and option F a party identifier with numbered lines (1/ name, 2/ address, 3/ country and town). Option F is the structured choice most banks prefer.
51A	Sending Institution	O	[/1!a][/34x] 4!a2!a2!c[3!c]	Only used over FileAct, to name the institution that sent the message. Not used in FIN messages.
52a	Ordering InstitutionOptions A or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The ordering customer’s bank, when it is not the Sender. Absent when the Sender itself is that bank.
53a	Sender's CorrespondentOptions A, B or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	Where the Sender will make the funds available to the Receiver: an account it holds with the Receiver, or a correspondent through which reimbursement will happen.
54a	Receiver's CorrespondentOptions A, B or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	The branch or bank at which the Receiver will receive the funds, when reimbursement goes through a correspondent.
55a	Third Reimbursement InstitutionOptions A, B or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	The Receiver’s branch that receives the funds when 53a and 54a name two different correspondents. If 55a is present, 53a and 54a must be present too.
56a	Intermediary InstitutionOptions A, C or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] C: /34x D: [/1!a][/34x] 4*35x	A bank between the Receiver and the account with institution through which the payment must pass. If 56a is present, 57a must be present too.
57a	Account With InstitutionOptions A, B, C or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] C: /34x D: [/1!a][/34x] 4*35x	The beneficiary’s bank, when it is not the Receiver. Option C carries a national clearing code only, for example a UK sort code (//SC) or a US routing number (//FW).
59a	Beneficiary CustomerOptions no letter, A or F	M	No letter: [/34x] 435x A: [/34x] 4!a2!a2!c[3!c] F: [/34x] 4(1!n/33x)	Who is paid. The first line carries the account (an IBAN where the country uses them). Option F uses numbered lines like 50F, and a line starting with 3/ and a valid country code is required.
70	Remittance Information	O	4*35x	Information for the beneficiary, such as the invoice being paid. Codes between slashes structure it: /INV/ invoice, /RFB/ reference for the beneficiary, /ROC/ reference of the customer, /IPI/ international payment instruction.
71A	Details of Charges	M	3!a	Who pays the charges: OUR (ordering customer pays all), SHA (shared: each side pays its own bank) or BEN (beneficiary pays all, deducted from the amount).
71F	Sender's ChargesRepeatable	C	3!a15d	Charges already taken by the Sender and earlier banks in the chain. Mandatory at least once with BEN, optional with SHA, not allowed with OUR.
71G	Receiver's Charges	C	3!a15d	Charges the Sender has prepaid and included in 32A for the Receiver. Allowed only with OUR, in the same currency as 32A.
72	Sender to Receiver Information	O	6*35x	Bank-to-bank information in coded form, for example /ACC/ (instructions for the account with institution), /INS/ (an instructing institution earlier in the chain) or /REC/ (instructions for the Receiver). It must not repeat information that has its own field.
77B	Regulatory Reporting	O	3*35x	Codes required by the regulator of the ordering or beneficiary country, for example /ORDERRES/ and /BENEFRES/ with a country code for balance of payments reporting.

Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).

Rules worth knowing

Charges: with 71A OUR, 71F is not allowed and 71G is optional; with SHA, 71F is optional and 71G is not allowed; with BEN, at least one 71F is required and 71G is not allowed.
If 71F or 71G is present, 33B must be present.
If the currency in 33B differs from the currency in 32A, field 36 must be present; if the currencies are the same, 36 is not allowed.
If 56a is present, 57a must be present. If 55a is present, 53a and 54a must be present.
The amounts are linked: the instructed amount in 33B, converted at the rate in 36, plus 71G, minus every 71F, equals the settled amount in 32A.
The user header block must carry the UETR in field 121. A bank that passes the payment on keeps the same UETR; in the cover method the MT202COV carries the UETR of the MT103.
An MT103 with {119:STP} in the user header is an MT103 STP: a version with tighter rules on which options may be used (for example 52a, 56a and 57a in option A only), meant for fully automated processing.

MT103 example

ZagTrader Test Bank in Dubai (ZAGTAEADXXX) pays GBP 25,000.00 for its customer Gulf Trading LLC to Acme Components Ltd, which holds its account with BANKGB2LXXX in London. The two banks hold accounts with each other, so the MT103 goes straight to the beneficiary’s bank and no 53a or 57a is needed. Charges are shared.

{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKGB2LXXXXN}{3:{121:e0b1c3a2-5d4f-4c8e-9a7b-2f6d1e3c9b40}}{4:
:20:ZT2610200001
:23B:CRED
:32A:261022GBP25000,00
:33B:GBP25000,00
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/OFFICE 1204 BUSINESS BAY TOWER
3/AE/DUBAI
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0457
:71A:SHA
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKGB2LXXXXN}{3:{121:e0b1c3a2-5d4f-4c8e-9a7b-2f6d1e3c9b40}}{4:	Basic header (sender ZAGTAEADXXX), application header (input MT103 to BANKGB2LXXX, normal priority) and user header with the UETR in field 121.
:20:ZT2610200001	Sender’s reference: 16 characters at most, no leading or trailing slash.
:23B:CRED	A normal credit transfer.
:32A:261022GBP25000,00	Value date 22 October 2026, currency GBP, settled amount 25,000.00. The decimal mark is a comma.
:33B:GBP25000,00	Instructed amount. Same currency as 32A, so no field 36.
:50F:/AE070331234567890123456	Ordering customer in option F: the first line is the account (a test IBAN).
1/GULF TRADING LLC	1/ is the name.
2/OFFICE 1204 BUSINESS BAY TOWER	2/ is an address line.
3/AE/DUBAI	3/ is the country code and town.
:59F:/GB42BANK40051587654321	Beneficiary customer in option F, with the account as a test IBAN.
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0457	Remittance information: the invoice being paid.
:71A:SHA	Charges shared. 71G is not allowed with SHA.
-}	End of block 4.

The BICs, names, IBANs and UETR are made up. The IBANs carry valid check digits so a validator accepts them.

Common errors and rejects

Field 36 present or missing against 33B (D75)
Field 36 must be present when 33B and 32A use different currencies, and must be absent when they use the same currency. Remove the rate for same-currency payments, or add it when the customer instructed in another currency.
How to fix it
Charges fields do not match 71A (E13, D50, E15)
OUR with a 71F, SHA with a 71G, or BEN without any 71F is rejected by the network. Check 71A first, then which charges field your system added.
How to fix it
56a without 57a (C81)
An intermediary was given but no account with institution. If the payment really passes through an intermediary, the beneficiary’s bank must be named in 57a.
How to fix it
33B missing between EU/EEA banks (D49)
When both the Sender’s and Receiver’s BICs are in the listed EU/EEA countries, 33B is mandatory even if it equals 32A.
How to fix it
Amount or date format in 32A
The amount needs a comma as the decimal mark, at least one digit before it, and no more decimals than the currency allows. The date is YYMMDD. A dot instead of a comma is one of the most frequent format rejects.
How to fix it
Wrong or missing beneficiary IBAN
Not a network reject, but the most common reason a payment comes back from the beneficiary bank (a return or a request for information). Check the IBAN length and check digits for the country before sending.
How to fix it

MT103 in ISO 20022

The ISO 20022 equivalent is pacs.008 (FI to FI Customer Credit Transfer). Swift ended the coexistence period for cross-border payment instructions on 22 November 2025: since then FI-to-FI payment instructions on Swift are delivered in ISO 20022, and an MT103 that a bank still sends is converted by Swift’s contingency processing, which Swift charges for from 1 January 2026.

The move matters most for data. pacs.008 has room for structured names and addresses, legal entity identifiers, purpose codes and longer remittance information that an MT103 cannot hold, so translating a pacs.008 back to MT103 can cut data off. See truncation when translating MX to MT.

Status and rejection messages also change: the network-level reject of an MT becomes a business status in pacs.002, and returns use pacs.004.

MT103 questions

What is an MT103 used for?: It is the instruction one bank sends to another to pay money to a customer, usually across borders. Banks also give a copy to customers as proof that a payment was sent, which is why people ask for "the MT103" when a transfer has not arrived.
Is the MT103 still used after November 2025?: For cross-border payments between banks on Swift, the instruction is now ISO 20022 pacs.008. Banks that still produce MT103 have it converted by Swift’s contingency processing, and many banks keep showing an MT103-style copy to customers. Domestic systems and bank-to-customer channels can still use MT103 formats.
What do OUR, SHA and BEN mean in field 71A?: They say who pays the bank charges. OUR: the sender pays everything and the beneficiary should receive the full amount. SHA: each side pays its own bank. BEN: all charges are deducted from the amount, so the beneficiary receives less.
Where is the UETR in an MT103?: In the user header block (block 3), field 121, for example {3:{121:e0b1c3a2-5d4f-4c8e-9a7b-2f6d1e3c9b40}}. It is a 36-character UUID that stays the same from the first bank to the last. See how to read a UETR.
What is the difference between MT103 and MT202?: An MT103 pays a customer. An MT202 moves money between banks for the banks themselves. The MT202COV is the bank-to-bank cover for an MT103 and carries the underlying customer details.
What is MT103 STP?: The same message with {119:STP} in the user header and stricter rules on field options, so the receiving bank can process it without manual repair.

All MT messages · Category 1 messages · ISO 20022 messages · Codes · Troubleshooting