MT 103 Single Customer Credit Transfer
MT 103 Single Customer Credit Transfer
MT 103 Single Customer Credit Transfer
Table of Contents
Message Types
The following table lists all message types defined in this book.
For each message type, there is a short description, an indicator whether the message type requires
authentication (Y/N), the maximum message length on input (2,000 or 10,000 characters), whether the
use of the message requires registration with SWIFT for use in a message user group (Y) or not (N)
and whether value date ordering (VDO) can be requested for the message (Y/N). Value date ordering
criteria are described in the Standards MT General Information.
3
Standards MT November 2023
• appropriate MT 103 STP format validation is triggered by the code STP in the validation flag field 119
({3:{119: STP}}) of the user header of the message (block 3)
• fields 52, 54, 55, 56 and 57 may only be used with letter option A
• field 51A is not used in MT 103 STP. This message may only be used on the FIN SWIFT network
since it requires special validation
• field 23E may only contain codes CORT, INTC, SDVA and REPA
• field 72, code INS must be followed by a valid financial institution BIC
Important User header block (block 3) must be present and must contain field 119 Validation Flag,
with code STP, and field 121 Unique End-to-end Transaction Reference (UETR). In cas-
es where the sender is acting as intermediary and a UETR was present in the received
message, the UETR must be passed, unchanged, to the next message in the transac-
tion chain. In all other cases, a new UETR must be used. Details of the format of the user
header block and field 121, and also the required order of fields in the user header block,
can be found in the FIN Operations Guide.
---->
----|
---->
----|
4!a2!a2!c[3!c]
4!a2!a2!c[3!c]
4!a2!a2!c[3!c]
4!a2!a2!c[3!c]
4!a2!a2!c[3!c]
---->
----|
5
Standards MT November 2023
M = Mandatory, O = Optional
C2 If the country codes of the Sender's and the Receiver's BICs are within the following list: AD,
AT, BE, BG, BV, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GF, GI, GP, GR, HU, IE, IS, IT, LI,
LT, LU, LV, MC, MQ, MT, NL, NO, PL, PM, PT, RE, RO, SE, SI, SJ, SK, SM, TF and VA, then
field 33B is mandatory, otherwise field 33B is optional (Error code(s): D49).
If country code of Sen- And country code of Re- Then field 33B is ...
der's BIC equals one of ceiver's BIC equals one of
the listed country codes the listed country codes
Yes No Optional
No Yes Optional
No No Optional
C3 If field 23B contains the code SPRI, field 23E may contain only the codes SDVA or INTC (Er-
ror code(s): E01).
If field 23B contains one of the codes SSTD or SPAY, field 23E must not be used (Error
code(s): E02).
C4 If field 55A is present, both fields 53A and 54A must also be present (Error code(s):
E06).
If field 55A is ... Then field 53A is ... And field 54A is ...
C5 If field 56A is present, field 57A must also be present (Error code(s): C81).
Present Mandatory
C6 If field 23B contains the code SPRI, field 56A must not be present (Error code(s): E16).
C7 If field 71A contains OUR, then field 71F is not allowed and field 71G is optional (Error
code(s): E13).
If field 71A is ... Then field 71F is ... And field 71G is ...
If field 71A contains SHA, then field(s) 71F is(are) optional and field 71G is not allowed (Error
code(s): D50).
If field 71A is ... Then field 71F is ... And field 71G is ...
If field 71A contains BEN, then at least one occurrence of field 71F is mandatory and field 71G
is not allowed (Error code(s): E15).
If field 71A is ... Then field 71F is ... And field 71G is ...
C8 If either field 71F (at least one occurrence) or field 71G is present, then field 33B is mandatory,
otherwise field 33B is optional (Error code(s): D51).
Note 1: The presence of both fields 71F and 71G is also regulated by the Network Validated
Rule C7 (Error code(s): E13, D50, E15).
Note 2: The presence of field 33B is also regulated by the Network Validated Rule C2 (Error
code(s): D49).
C9 The currency code in the fields 71G and 32A must be the same (Error code(s): C02).
C10 If the country codes of the Sender's and the Receiver's BICs are within the following list: AD,
AT, BE, BG, BV, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GF, GI, GP, GR, HR, HU, IE, IL, IS,
IT, LI, LT, LU, LV, MC, MQ, MT, NL, NO, PL, PM, PT, RE, RO, SE, SI, SJ, SK, SM, TF and VA,
then the following apply:
7
Standards MT November 2023
– If field 57A is not present, the IBAN (ISO 13616) is mandatory in subfield Account of field
59a (Error code(s): D19).
– If field 57A is present and the country code of the financial institution BIC in 57A is within the
above list of country codes, the IBAN (ISO 13616) is mandatory in subfield Account of field
59a (Error code(s): D19).
In all other cases, the presence of the IBAN (ISO 13616) is optional and its format is not validat-
ed in subfield Account of field 59a.
All ISO 13616-compliant, country-specific IBAN formats can be found in the IBAN Registry doc-
ument on www.swift.com > Standards > Document Centre.
If country code And country And field 57A And country Then an IBAN in
of Sender's code of Receiv- is present code of field subfield Account
BIC equals one er's BIC equals 57A equals one of field 59a is ...
of the listed one of the listed of the listed
country codes country codes country codes
No No Yes No Optional
• copy the content of field 20 of the MT 103 STP unchanged into field 21 of the related MT 202 COV;
• copy the content of field 121, in the user header block, of the MT 103 STP unchanged into field 121,
in the user header block, of the related MT 202 COV.
• When the receiver of an MT 103 STP either credits the account of the beneficiary customer or re-
jects the payment, a confirmation to Tracker (TRCKCHZZ) is mandatory. Business rules and techni-
cal specifications of the confirmation are available on the Knowledge Centre > Products A-Z > FIN
>Universal Confirmations for MT 103 Rulebook.
• The instructed amount in field 33B, adjusted with the exchange rate in field 36, plus the Receiver's
charges in field 71G, minus the Sender's charges in field(s) 71F, equals the interbank settled amount
in field 32A.
Presence of the fields mentioned above is subject to the conditional field rules C1, C2, C7 and C8. If a
field is not present, that field must not be taken into account in the formula. If field 71F is present more
than once, all occurrences of that field must be taken into account in the formula.
Examples: Transaction A
• Pay the equivalent of EUR 1000,00 in GBP to a beneficiary in the United Kingdom
• Transaction charges on the Sender's side are EUR 5,00 (=GBP 3,1)
71A OUR
36 0,61999
C. The subsequent MT 950 shows one debit entry for GBP 623,99, that is, field 32A.
9
Standards MT November 2023
71A SHA
36 0,61999
C. The subsequent MT 950 shows one debit entry for GBP 619,99, that is, field 32A.
71A BEN
36 0,61999
C. The subsequent MT 950 shows one debit entry for GBP 616,89, that is, field 32A.
Note The beneficiary is also advised of the Sender's charges of GBP 3,1.
Examples: Transaction B
• Pay GBP 1000,00 to a beneficiary in the United Kingdom
• Transaction charges on the Sender's side are EUR 5,00 (=GBP 3,1)
• Transaction charges on the Receiver's side are GBP 4,00 (=EUR 6,45)
Debit on EUR-account
71A OUR
Note Field 36 does not have to be used since currency in fields 32A and 33B is the same.
C. The subsequent MT 950 shows one debit entry for GBP 1004, that is, field 32A.
Debit on EUR-account
11
Standards MT November 2023
71A SHA
C. The subsequent MT 950 shows one debit entry for GBP 1000, that is, field 32A.
Note Field 36 does not have to be used since currency in fields 32A and 33B is the same.
Debit on EUR-account
71A BEN
C. The subsequent MT 950 shows one debit entry for GBP 996,9 that is, field 32A.
Note The beneficiary is also advised of the Sender's charges of GBP 3,1.
based on the receipt of an MT 103, without receipt of the related cover payment, is a policy decision.
Institutions have deployed processes that are approved by their internal risk committees; the risk lies
clearly with the beneficiary institution. Guidelines for the processing of an MT 103 STP sent with the
cover method have been published by the Payments Market Practice Group (PMPG).
For more details, see the market practice document Guidelines for use of the MT 202 COV on
www.pmpg.info.
• If the Sender and the Receiver have no direct account relationship in the currency of the transfer or
do not wish to use their account relationship, then third banks will be involved to cover the transac-
tion. The MT 103 STP contains only the payment details and the Sender must cover the customer
transfer by sending an MT 202 COV General Financial Institution Transfer to a third bank. This pay-
ment method is called 'cover'.
• Where more than two financial institutions are involved in the payment chain, and if the MT 103 STP
is sent from one financial institution to the next financial institution in this chain, then the payment
method is called 'serial'.
• In order to allow better reconciliation by the beneficiary customer, the MT 103 STP supports full
charges transparency and structured remittance information.
• In order to allow better reconciliation by the Receiver, the MT 103 STP gives an unambiguous indica-
tion of the interbank amount booked by the Sender/to be booked by the Receiver.
• The MT 103 STP gives the Sender the ability to identify in the message the level of service request-
ed, that is, what service is expected from the Receiver for a particular payment, for example, SWIFT-
Pay, Standard or Priority or any other bilaterally agreed service.
• The message also allows for the inclusion of regulatory information in countries where regulatory re-
porting is requested.
16x
PRESENCE
Mandatory
DEFINITION
This field specifies the reference assigned by the Sender to unambiguously identify the message.
13
Standards MT November 2023
USAGE RULES
• This reference must be quoted in any related confirmation or statement, for example, MT 900, 910
and/or 950.
• When the cover method is used for a customer credit transfer, this reference must be quoted un-
changed in field 21 of the related MT 202 COV.
EXAMPLES
:20:Ref254
PRESENCE
Optional
DEFINITION
This repetitive field specifies one or several time indication(s) related to the processing of the payment
instruction.
CODES
One of the following codes may be used in Code, placed between slashes ('/'):
CLSTIME CLS Time The time by which the funding payment must be credited, with confir-
mation, to the CLS Bank's account at the central bank, expressed in
Central European Time (CET).
RNCTIME Receive Time The time at which a TARGET2 payment was credited at the receiving
central bank, expressed in Central European Time (CET).
SNDTIME Send Time The time at which a TARGET2 payment was debited at the sending
central bank, expressed in Central European Time (CET).
CODES
One of the following codes must be used in Sign (Error code(s): T15):
Time offset is expressed as 'HHMM', where the hour component, that is, 'HH', must be in the range of
00 through 13, and the minute component, that is, 'MM' must be in the range of 00 through 59. Any 'HH'
or 'MM' component outside of these range checks will be disallowed (Error code(s): T16).
USAGE RULES
The time zone in which Time is expressed is to be identified by means of the offset against the UTC
(Coordinated Universal Time - ISO 8601).
EXAMPLES
Assume a financial institution in London is sending a payment instruction on 5 January related to CLS in
which it indicates that money has to be funded to CLS bank by 09.15 CET.
Time indication field will be completed as follows: :13C:/CLSTIME/0915+0100
Explanation:
• 0915 is the time by which the money has to be funded to CLS bank. It has been agreed that
CLSTIME is to be indicated in CET (see codes above).
• +0100 is the offset of CET against UTC in January (that is during winter time).
If the same instruction had been sent on 10 June (that is during summer time), time indication field
would have been completed as follows: :13C:/CLSTIME/0915+0200
Offsets of local time zones against UTC are published in the BIC Directory download file (TZ***.txt file),
which is available on www.swiftrefdata.com.
PRESENCE
Mandatory
DEFINITION
This field identifies the type of operation.
CODES
One of the following codes must be used (Error code(s): T36):
CRED Normal credit transfer This message contains a credit transfer where there is no SWIFT
Service Level involved.
CRTS Test message This message contains a credit transfer for test purposes.
15
Standards MT November 2023
USAGE RULES
The code CRTS should not be used on the FIN network.
EXAMPLES
:23B:SPAY
PRESENCE
Conditional (see rule C3)
DEFINITION
This field specifies an instruction.
CODES
Instruction Code must contain one of the following codes (Error code(s): T48):
CORT Corporate Trade Payment is made in settlement of a trade, for example, foreign ex-
change deal, securities transaction.
INTC Intra-Company Pay- A payment between two companies belonging to the same group.
ment
SDVA Same Day Value Payment must be executed with same day value to the beneficiary.
SDVA
INTC
REPA
CORT
When this field is used more than once, the following combinations are not allowed (Error code(s):
D67).
REPA with CORT
If this field is repeated, the same code must not be present more than once (Error code(s): E46).
USAGE RULES
This field may be repeated to give several coded instructions to one or more parties.
Code REPA indicates that the payment is the result of an initiation performed via an e-payments prod-
uct between the customers. This code is intended for the beneficiary's bank who should act according
to the specifications of the e-payments product.
EXAMPLES
:23E:SDVA
PRESENCE
Optional
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the individual transaction, for example,
salaries, pensions, dividends.
USAGE RULES
The information given is intended both for regulatory and statutory requirements and/or to provide infor-
mation to the beneficiary customer on the nature of the transaction.
Codes from the EUROSTAT list "Code List for Balance of Payments Collection Systems" may be used
in this field.
In case the Receiver of the message is not legally obliged to forward the information to a regulatory
body, he is allowed to ignore the content of this field.
EXAMPLES
:26T:K90
PRESENCE
Mandatory
DEFINITION
This field specifies the value date, the currency and the settlement amount. The settlement amount is
the amount to be booked/reconciled at interbank level.
17
Standards MT November 2023
The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is in-
cluded in the maximum length. The number of digits following the comma must not exceed the maxi-
mum number allowed for the specified currency (Error code(s): C03, T40, T43).
The codes XAU, XAG, XPD and XPT are not allowed, as these are codes for commodities for which the
category 6 commodities messages must be used (Error code(s): C08).
EXAMPLES
:32A:981209USD1000,00
PRESENCE
Conditional (see rules C2, C8)
DEFINITION
This field specifies the currency and amount of the instruction. This amount is provided for information
purposes and has to be transported unchanged through the transaction chain.
USAGE RULES
If field 33B is present in the message received, it has to be forwarded unchanged to the next party.
This field must be present when a currency conversion or an exchange has been performed on the
Sender's side.
If the transaction is within the scope of the EC Directive on cross border credit transfers, this amount is
the original ordered amount as instructed by the ordering customer. Otherwise, it is the amount that the
sending bank was instructed to pay.
As a consequence, if there are no Sender's or Receiver's charges and no currency conversion or ex-
change took place, field 32A equals 33B, if present.
EXAMPLES
:33B:USD1000,00
12d (Rate)
PRESENCE
Conditional (see rule C1)
DEFINITION
This field specifies the exchange rate used to convert the instructed amount specified in field 33B.
USAGE RULES
This field must be present when a currency conversion or an exchange has been performed on the
Sender's side.
EXAMPLES
:36:0,9236
In option F, the following line formats must be used (Error code(s): T54):
1!n/33x (Number)(Details)
Or
1!n/33x (Number)(Details)
PRESENCE
Mandatory
DEFINITION
This field specifies the customer ordering the transaction.
19
Standards MT November 2023
CODES
In option F, when Party Identifier is used with the (Code)(Country Code)(Identifier) format, one of the
following codes must be used in Code (Error code(s): T55):
ARNU Alien Registration The code followed by a slash, '/' must be followed by the ISO country
Number code, a slash, '/' and the Alien Registration Number.
CCPT Passport Number The code followed by a slash, '/' must be followed by the ISO country
code, a slash, '/' and the Passport Number.
CUST Customer Identifica- The code followed by a slash, '/' must be followed by the ISO country
tion Number code of the issuer of the number, a slash, '/', the issuer of the num-
ber, a slash, '/' and the Customer Identification Number.
DRLC Driver's Licence Num- The code followed by a slash, '/' must be followed by the ISO coun-
ber try code of the issuing authority, a slash, '/', the issuing authority, a
slash, '/' and the Driver's Licence Number.
EMPL Employer Number The code followed by a slash, '/' must be followed by the ISO country
code of the registration authority, a slash, '/', the registration authority,
a slash, '/' and the Employer Number.
NIDN National Identity Num- The code followed by a slash, '/' must be followed by the ISO country
ber code, a slash, '/' and the National Identity Number.
SOSE Social Security Num- The code followed by a slash, '/' must be followed by the ISO country
ber code, a slash, '/' and the Social Security Number.
TXID Tax Identification The code followed by a slash, '/' must be followed by the ISO country
Number code, a slash, '/' and the Tax Identification Number.
CODES
In option F, Number must contain one of the following values (Error code(s): T56):
1 Name of Ordering The number followed by a slash, '/' must be followed by the name of
Customer the ordering customer.
2 Address Line The number followed by a slash, '/' must be followed by an address
line (Address Line can be used to provide, for example, street name
and number, or building name).
3 Country and Town The first occurrence of number 3 must be followed by a slash, '/', the
ISO country code and, optionally, additional details that are preceded
by a slash '/'.
4 Date of Birth The number followed by a slash, '/' must be followed by the date of
birth in the YYYYMMDD format.
5 Place of Birth The number followed by a slash, '/' must be followed by the ISO
country code, a slash '/' and the place of birth.
6 Customer Identifica- The number followed by a slash, '/' must be followed by the ISO
tion Number country code of the issuer of the number, a slash, '/', the issuer of the
number, a slash, '/' and the customer identification number.
7 National Identity Num- The number followed by a slash, '/' must be followed by the ISO
ber country code, a slash, '/' and the national identity number.
8 Additional Information The number followed by a slash, '/' is followed by information that
completes one of the following:
• The first line must start with number 1 (Error code(s): T56).
• The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s):
T73).
• Numbers 1, 2, and 3 may be repeated. The same number must not occur more than 2 times (Error
code(s): T56).
• Number 4 must not be used without number 5 and vice versa (Error code(s): T56).
• Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local to the
sender, must not be later than the date on which the message is successfully sent to SWIFT (Error
code(s): T50).
• Numbers 5, 6 and 7 must be followed by a valid ISO country code (Error code(s): T73), a
slash '/' and additional Details (Error code(s): T56).
• The use of number 8 is only allowed in the following instances (Error code(s): T56):
– to continue information on the Identifier of the ordering customer provided in subfield 1 (Party
Identifier) used with the (Code)(Country Code)(Identifier) format.
– to continue information on the Customer Identification Number provided in subfield 2 (Name and
Address) following number 6.
– to continue information on the National Identity Number provided in subfield 2 (Name and Ad-
dress) following number 7.
21
Standards MT November 2023
USAGE RULES
If the account number of the ordering customer is known, it must be stated in Account.
In option F, subfield 2 (Name and Address): Numbers 1, 2 and 3 may be repeated.
In option F, subfield 2 (Name and Address): if number 2 is present, the first occurrence of number 3
must include the town in additional details.
In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if addi-
tional space is required for providing the Identifier of the ordering customer, one of the following options
must be used:
1. First option (preferred): Identify the ordering customer with a different identifier where the length is
not an issue.
2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.
In option F, subfield 2 (Name and Address): if additional space is required for providing the Customer
Identification Number (number 6) or the National Identity Number (number 7) of the ordering customer,
one of the following options must be used:
1. First option (preferred): Identify the ordering customer with a different identifier where the length is
not an issue.
2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.
When Chinese characters are necessary and when use is bilaterally agreed, the Chinese Commercial
Code e-table and guidelines must be followed as published in www.swift.com > Standards > Document
centre > Market Practice > Chinese Commercial Code eTable Information.
EXAMPLES
Option A
:50A:/SE1350000000054910000011
VWVOSES1
Option F - Example 1
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
3/US/NEW YORK, NY 10017
Option F - Example 2
:50F:/BE30001216371411
1/PHILIPS MARK
3/BE/ANTWERPEN
4/19720830
5/BE/BRUSSELS
Option F - Example 3
:50F:DRLC/BE/BRUSSELS/NB0949042
1/DUPONT JACQUES
2/HIGH STREET 6, APT 6C
3/BE/BRUSSELS
Option F - Example 4
:50F:NIDN/DE/121231234342
1/MANN GEORG
3/DE/DUSSELDORF
6/DE/ABC BANK/1234578293
Option F - Example 5
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
This means that the customer identification number of Mann Georg assigned by ABC Bank
is123456789/8-1234567890.
PRESENCE
Optional
DEFINITION
This field specifies the financial institution of the ordering customer, when different from the Sender,
even if field 50a contains an IBAN.
CODES
Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash '//':
23
Standards MT November 2023
Identifier Code must be a financial institution BIC. This error code applies to all types of BICs refer-
enced in a FIN message including connected BICs, non-connected BICs, Masters, Synonyms, Live
destinations and Test & Training destinations (Error code(s): C05).
USAGE RULES
The coded information contained in field 52A must be meaningful to the Receiver of the message.
EXAMPLES
:52A:ABNANL2A
[35x] (Location)
PRESENCE
Conditional (see rule C4)
DEFINITION
Where required, this field specifies the account or branch of the Sender or another financial institution
through which the Sender will reimburse the Receiver.
USAGE RULES
Absence of this field implies that there is a unique account relationship between the Sender and the Re-
ceiver or that the bilaterally agreed account is to be used for settlement.
In those cases where there are multiple direct account relationships, in the currency of the transaction,
between the Sender and the Receiver, and one of these accounts is to be used for reimbursement, the
account to be credited or debited must be indicated in field 53B with the party identifier only.
If there is no direct account relationship, in the currency of the transaction, between the Sender and the
Receiver (or branch of the Receiver when specified in field 54A), then field 53a must be present with
option A.
When field 53A is present and contains a branch of the Sender, the need for a cover message is de-
pendent on the currency of the transaction, the relationship between the Sender and the Receiver and
the contents of field 54A, if present.
A branch of the Receiver may appear in field 53A if the financial institution providing reimbursement is
both the Sender's correspondent and a branch of the Receiver, and the Sender intends to send a cover
message to the branch of the Receiver. In this case, the Receiver will be paid by its branch in field 53A.
In all other cases, when field 53A is present, a cover message, that is, MT 202 COV or equivalent non-
SWIFT must be sent to the financial institution identified in field 53A.
The use and interpretation of fields 53a and 54A is, in all cases, dictated by the currency of the transac-
tion and the correspondent relationship between the Sender and Receiver relative to that currency.
EXAMPLES
:53A:CITIUS33
PRESENCE
Conditional (see rule C4)
DEFINITION
This field specifies the branch of the Receiver or another financial institution at which the funds will be
made available to the Receiver.
USAGE RULES
When the funds are made available to the Receiver's branch through a financial institution other than
that indicated in field 53A, this financial institution, that is, intermediary reimbursement institution shall
be specified in field 54A and field 55A shall contain the Receiver's branch.
In those cases where field 54A contains a branch of the Receiver, and is not preceded by field 53A, or
field 53B contains an account of the Sender serviced by the Receiver's branch, the Receiver will claim
reimbursement from its branch.
If field 54A contains a branch of the Receiver and field 53A contains a branch of the Sender, the Re-
ceiver will claim reimbursement from its branch or will be paid by its branch, depending on the currency
of the transfer and the relationship between the Sender and the Receiver.
In all other cases where field 54A contains a branch of the Receiver, the Receiver will be paid by its
branch in field 54A.
A branch of the Sender must not appear in field 54A.
If the branch of the Sender or other financial institution specified in field 53A is also the account servicer
for the Receiver, field 54A must not be present.
25
Standards MT November 2023
Field 54A containing the name of a financial institution other than the Receiver's branch must be pre-
ceded by field 53A; the Receiver will be paid by the financial institution in field 54A.
The use and interpretation of fields 53a and 54A is in all cases dictated by the currency of the transac-
tion and the correspondent relationship between the Sender and Receiver relative to that currency.
EXAMPLES
:54A:IRVTUS3N
PRESENCE
Optional
DEFINITION
This field specifies the Receiver's branch, when the funds are made available to this branch through a
financial institution other than that indicated in field 53A.
EXAMPLES
:55A:IRVTUS3N
PRESENCE
Conditional (see rule C6)
DEFINITION
This field specifies the financial institution through which the transaction must pass to reach the account
with institution.
CODES
Party Identifier may be used to indicate a national clearing system code.
USAGE RULES
When one of the codes //FW, //AU, //IN or //RT is used, it should appear only once and in the first of the
fields 56A and 57A of the payment instruction.
When it is necessary that an incoming SWIFT payment be made to the party in this field via Fedwire,
US banks require that the code //FW appears in the optional Party Identifier of field 56A or 57A.
When it is necessary that an incoming SWIFT payment be made to the intermediary or the account
with institution via real-time gross settlement (RTGS), the code //RT should appear in the optional Party
Identifier of field 56A or 57A.
The code //RT is binding for the Receiver. It must not be followed by any other information.
EXAMPLES
:56A:IRVTUS3N
27
Standards MT November 2023
PRESENCE
Conditional (see rule C5)
DEFINITION
This field specifies the financial institution which services the account for the beneficiary customer. This
is applicable even if field 59a contains an IBAN.
CODES
Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash '//':
USAGE RULES
When field 57a is not present, it means that the Receiver is also the account with institution.
When one of the codes //FW, //AU, //IN or //RT is used, it should appear only once and in the first of the
fields 56A and 57A of the payment instruction.
When it is necessary that an incoming SWIFT payment be made to the party in this field via Fedwire,
US banks require that the code //FW appears in the optional Party Identifier of field 56A or 57A.
When it is necessary that an incoming SWIFT payment be made to the intermediary or the account
with institution via real-time gross settlement (RTGS), the code //RT should appear in the optional Party
Identifier of field 56A or 57A.
The code //RT is binding for the Receiver. It must not be followed by any other information.
EXAMPLES
:57A:ABNANL2A
[/34x] (Account)
PRESENCE
Mandatory
DEFINITION
This field specifies the customer which will be paid.
CODES
In option F, Number/Name and Address must contain one of the following codes (Error code(s):
T56)
1 Name of Beneficiary The number followed by a slash, '/' must be followed by the name of
Customer the beneficiary customer.
2 Address Line The number followed by a slash, '/' must be followed by an address
line (Address Line can be used to provide for example, street name
and number, building name or post office box number).
29
Standards MT November 2023
3 Country and Town The first occurrence of number 3 must be followed by a slash, '/', the
ISO country code and, optionally, additional details that are preceded
by a slash '/'.
CODES
Account may contain one of the following codes, preceded by a double slash '//':
• The first line must start with number 1 (Error code(s): T56).
• Numbers 1, 2, and 3 may be repeated. The same number must not occur more than 2 times (Error
code(s): T56).
• The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s):
T73).
USAGE RULES
At least the name or the non-financial institution BIC of the beneficiary customer is mandatory.
If a non-financial institution BIC is specified, it must be meaningful for the financial institution that ser-
vices the account for the beneficiary customer.
If the account number of the beneficiary customer is known, it must be stated in Account.
In option F:
• if number 2 is present, the first occurrence of number 3 must include the town in the additional details
When Chinese characters are necessary and when use is bilaterally agreed, the Chinese Commercial
Code e-table and guidelines must be followed as published in www.swift.com > Standards > Document
centre > Market Practice > Chinese Commercial Code eTable Information.
EXAMPLES
No letter option
:59:/BE62510007547061
JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS
Option F - Example 1
:59F:/BE30001216371411
1/MARK PHILIPS
2/HOOGSTRAAT 6, APT 6C
3/BE/BRUSSELS
Option F - Example 2
:59F:/12345678
1/DEPT OF PROMOTION OF SPICY FISH
1/CENTER FOR INTERNATIONALISATION
3/CN
Option F - Example 3
:59F:/BE88310141014141
1/JOHN SIMONS
2/3658 WITMER ROAD
3/US/POUGHKEEPSIE, NEW YORK 12602
3/DUTCHESS
4*35x (Narrative)
PRESENCE
Optional
DEFINITION
This field specifies either the details of the individual transaction or a reference to another message
containing the details which are to be transmitted to the beneficiary customer.
CODES
One of the following codes may be used, placed between slashes ('/'):
INV Invoice Invoice (followed by the date, reference and details of the invoice).
IPI International Payment Unique reference identifying a related International Payment Instruc-
Instruction tion (followed by up to 20 characters).
RFB Reference for Benefi- Reference for the beneficiary customer (followed by up to 16 charac-
ciary ters).
TSU Trade Services Utility The code placed between slashes ('/') must be followed by the TSU
transaction transaction identifier, a slash ('/'), the invoice number, a slash ('/') and
the amount paid.
31
Standards MT November 2023
USAGE RULES
For clearing purposes, the Sender must check with the Receiver regarding length restrictions of field 70.
The information specified in this field is intended only for the beneficiary customer, that is, this informa-
tion only needs to be conveyed by the Receiver.
Multiple references can be used, if separated with a double slash, '//'. Code must not be repeated be-
tween two references of the same kind.
For STP purposes, when an ISO 11649 Creditor Reference is present in this field it must be on the first
line, without any characters preceding it, and it must be the only information on that line.
EXAMPLES
:70:/RFB/BET072
:70:/INV/abc/SDF-96//1234-234///ROC/98I
U87
:70:/TSU/00000089963-0820-01/ABC-15/256
214,
PRESENCE
Mandatory
DEFINITION
This field specifies which party will bear the charges for the transaction.
CODES
One of the following codes must be used (Error code(s): T08):
BEN Beneficiary All transaction charges are to be borne by the beneficiary customer.
OUR Our customer charged All transaction charges are to be borne by the ordering customer.
SHA Shared charges All transaction charges other than the charges of the financial institu-
tion servicing the ordering customer account are borne by the benefi-
ciary customer.
EXAMPLES
:71A:BEN
PRESENCE
Conditional (see rule C7)
DEFINITION
This repetitive field specifies the currency and amount of the transaction charges deducted by the Sen-
der and by previous banks in the transaction chain.
USAGE RULES
These fields are conveyed for transparency reasons.
The net amount after deduction of the Sender's charges will be quoted as the inter-bank settled amount
in field 32A.
This field may be repeated to specify to the Receiver the currency and amount of charges taken by
preceding banks in the transaction chain. Charges should be indicated in the order in which they
have been deducted from the transaction amount, that is, the first occurrence of this field specifies the
charges of the first bank in the transaction chain that deducted charges; the last occurrence always
gives the Sender's charges.
EXAMPLES
:71F:EUR8,00
PRESENCE
Conditional (see rule C7)
DEFINITION
This field specifies the currency and amount of the transaction charges due to the Receiver.
USAGE RULES
This field is conveyed for accounting reasons, that is, to facilitate bookkeeping.
Where field 71A indicates OUR payments, this field identifies the charges due, which have been pre-
paid and included in the interbank settlement amount.
33
Standards MT November 2023
EXAMPLES
:71G:EUR5,50
or or
PRESENCE
Optional
DEFINITION
This field specifies additional information for the Receiver or other party specified.
CODES
Unless bilaterally agreed otherwise between the Sender and the Receiver, the following code may be
used in Code, placed between slashes ('/'):
INS Instructing institution The instructing institution which instructed the Sender to execute the
transaction.
USAGE RULES
Field 72 must never be used for information for which another field is intended.
Each item for which a code exists must start with that code and may be completed with additional infor-
mation.
Each code used must be between slashes and appear at the beginning of a line. It may be followed by
additional narrative text.
Narrative text relating to a preceding code, which is continued on the next line(s), must start with a dou-
ble slash '//', and, if used, must begin on a new line. Narrative text should preferably be the last informa-
tion in this field.
Use of field 72 with uncoded instructions is not allowed.
It is strongly recommended to use the standard code proposed above. In any case, where bilateral
agreements covering the use of codes in this field are in effect, the code must conform to the structured
format of this field.
If code INS is present in field 72 of a received message, then the code and the related details must be
passed, unchanged, in field 72 of the subsequent message in the payment chain. Additional codes and
details may be added to field 72 of the subsequent message but the original INS and related details
must not be altered or removed.
EXAMPLES
:72:/INS/ABNANL2A
PRESENCE
Optional
DEFINITION
This field specifies the codes for the statutory and/or regulatory information required by the authorities
in the country of Receiver or Sender.
CODES
When the residence of either the ordering customer or the beneficiary customer is to be identified, one
of the following codes may be used in Code, placed between slashes ('/'):
USAGE RULES
Country Code consists of the ISO country code of the country of residence of the ordering customer or
beneficiary customer.
The information specified must not have been explicitly conveyed in another field.
In case the Receiver of the message is not legally obliged to forward the information to a regulatory
body, he is allowed to ignore the content of this field.
35
Standards MT November 2023
EXAMPLES
:77B:/ORDERRES/BE//MEILAAN 1, 9000 GENT
Narrative
Biodata G.m.b.H. orders UBS, Zürich, to pay euro 1,958.47 to ABN Amro Bank, Amsterdam, for the ac-
count of H.F. Janssen.
Information Flow
Sender UBS
Zurich
MT
MT 103 STP
59a
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Receiver ABNANL2A
Message text
Note No reimbursement party has been indicated in the above message. The direct account
relationship, in the currency of the transfer, between the Sender and the Receiver will be
used.
Narrative
Biodata G.m.b.H. orders UBS, Zürich, to pay euro 1,958.47 to ABN Amro Bank, Amsterdam, for the ac-
count of H.F. Janssen, in payment of invoice number 18042 dated 15 July 2009.
As there is more than one account relationship in the currency of the transfer between the Sender and
Receiver, UBS, Zürich specifies that account number 21 94 29 055 should be used for reimbursement.
UBS, Zürich, knows that ABN Amro Bank, Amsterdam, will charge euro 2.50 to execute this transaction.
Information Flow
Sender UBS
Zurich
MT
MT 103 STP
59a
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Receiver ABNANL2A
37
Standards MT November 2023
Explanation Format
Message text
(1) Field 53B indicates the account number of the Sender's account, serviced by the Receiver, which is to be used for reim-
bursement in the transfer.
(2) As the Reference for the beneficiary is an invoice number, the code /INV/ is used, followed by the invoice number.
Example 3: Single Customer Credit Transfer with Ordering and Account With Institu-
tions
Narrative
Franz Holzapfel G.m.b.H. orders Bank Austria, Eisenstadt, to pay, value 28 August 2009, US Dollars
850 into C. Won's account number 729615-941 with Oversea-Chinese Banking Cooperation, Singa-
pore. The payment is for July 2009 expenses.
Bank Austria, Eisenstadt, asks its head office in Vienna, to make the payment. Both Bank Austria, Vien-
na, and Oversea-Chinese Banking Cooperation, Singapore, have their US dollars account at Citibank's
New York office.
Both customers agree to share the charges. Citibank charges US Dollars 10.
Information Flow
MT
Receiver Citibank
New York
Explanation Format
Sender BKAUATWW
Receiver CITIUS33
Message text
39
Standards MT November 2023
Explanation Format
Mapping
The following illustrates the mapping of the first MT 103 STP onto the next MT 103 STP:
S S
R R
20 20
23B 23B
32A 32A
50a 33B
52A 50a
57A 52A
59a 59a
70 70
71A 71A
71F
D0010055
72/INS/
Explanation Format
Sender CITIUS33
Receiver OCBCSGSG
Message text
Explanation Format
Example 4: Single Customer Credit Transfer with Reimbursement Through Two Insti-
tutions
Narrative
Value August 28, 2009, Franz Holzapfel G.m.b.H. orders Bank Austria, Vienna, to pay US Dollars
1,121.50 to C. Klein, Bloemengracht 15, Amsterdam, whose account number 72 34 91 524 is with ABN
Amro Bank, Amsterdam.
Bank Austria uses reference 394882.
This transfer may be sent via SWIFT using one of the following methods:
1. Sent to the party closest to the beneficiary, through several reimbursement institutions
Note The alternative selected is dependent on correspondent relationships and financial practice
in the countries involved.
B. A cover message for the US dollar payment, which is provided through Chase Manhattan Bank,
New York, to ABN Amro Bank, New York.
41
Standards MT November 2023
Information Flow
MT 103 STP
Receiver's ABN Amro Bank
Correspondent 54A New York
(Field 57a of MT 202 COV)
(MT 910/950)
Receiver ABN Amro Bank
Amsterdam
(Field 58a of MT 202 COV)
Explanation Format
Sender BKAUATWW
Receiver ABNANL2A
Message text
Explanation Format
(1) Field 53A indicates the institution which is to provide the funds to the Receiver on behalf of the Sender.
(2) Field 54A is the receiver's correspondent - the institution which will receive the funds on behalf of the Receiver.
Mapping
S S
R R
20 20
23B 21
23E 32A
32A 57a
50a 58a
53A 50a
54A 59a
59a 33B
D0010057
71A
43
Standards MT November 2023
Information Flow
Message B
MT
MT 202 COV
D0010058
(Receiver of MT 103)
Explanation Format
Sender BKAUATWW
Receiver CHASUS33
Explanation Format
(1) The Unique End-to-end Transaction Reference of the received Single Customer Credit Transfer must be copied to field 121
of the cover message.
(2) The related reference is the Sender's reference of the Single Customer Credit Transfer.
45
Standards MT November 2023
Information Flow
Message A
MT
MT 103 STP
(Message B
MT 103 STP*)
59a
* Or its equivalent domestic clearing message
Explanation Format
Sender BKAUATWW
Receiver CHASUS33
Explanation Format
Message text
(1) The intermediary institution, ABN Amro Bank, New York, will receive the funds from the Receiver of this message, Chase
Manhattan Bank, New York.
(2) ABN Amro Bank, Amsterdam, will receive the funds from the intermediary institution, its New York office, for credit to the
beneficiary's account.
Mapping
S S S
R R R
20 20 20
23B 23B 23B
32A 32A 32A
50a 33B 33B
56A 50a 50a
57A 52A 52A
59a 57A 59a
71A 59a 71A
71A 71F
71F 71F
72/INS/
D0010068
47
Standards MT November 2023
Message B 2nd SWIFT MT 103 STP (or its equivalent domestic clearing message)
Information Flow
Message B
MT
MT 103 STP
59a
Explanation Format
Sender CHASUS33
Receiver ABNAUS33
Explanation Format
Message text
(1) The Unique End-to-end Transaction Reference (UETR) of the received MT 103 STP must be passed on, unchanged, in the
next message in the transaction chain.
(2) The Sender of the initial MT 103 STP is Bank Austria, Vienna, which is the ordering institution in all subsequent messages.
(3) ABN Amro Bank, Amsterdam, will receive the funds from the Receiver of this message, its New York office, for credit to the
beneficiary's account.
49
Standards MT November 2023
Message C 3rd SWIFT MT 103 STP (or its equivalent domestic clearing message)
Information Flow
Message C
MT
MT 103 STP
59a
Explanation Format
Sender ABNAUS33
Receiver ABNANL2A
Explanation Format
Message text
(1) The Unique End-to-end Transaction Reference (UETR) of the received MT 103 STP must be passed on, unchanged in field
121 of the next message in the transaction chain.
(2) The Sender of the initial MT 103 STP is Bank Austria, Vienna, which is the ordering institution in all subsequent messages.
Narrative
Consortia Pension Scheme, a corporate in Zürich requests its bank (BNKACHZZ) to execute a pension
payment in Swiss Francs. The beneficiary has his account, 429-5470572-63, with the Belgian corre-
spondent of BNKACHZZ.
51
Standards MT November 2023
Information Flow
Sender BNKACHZZ
MT
(MT 950)
MT 103 STP
Receiver BNKBBEBB
D0010063
59a Brussels
Explanation Format
Sender BNKACHZZ
Receiver BNKBBEBB
Message text
Explanation Format
In the statement message sent by BNKBBEBB to its Swiss correspondent, the settlement amount as
specified in field 32A and the Sender's reference specified in field 20 will be quoted in the appropriate
statement line. For the example given this would result in the following MT 950:
Explanation Format
Sender BNKBBEBB
Receiver BNKACHZZ
Message text
MT 103 STP Example for the MT 103 STP, used in a Service Lev-
el Agreement
In the following examples both the Sender and the Receiver agreed to exchange payment messages
under a SWIFT Service Level.
The message available for this group of users has the following layout for both the Standard and
SWIFTPay Service Level:
----->
-----|
53
Standards MT November 2023
----->
-----|
----->
-----|
The message available for this group has the following layout for the Priority Service Level:
----->
-----|
----->
-----|
----->
-----|
Example 1: Single Customer Credit Transfer With Reimbursement Through Several In-
stitutions
Narrative
Value August 28, 2009, Franz Holzapfel G.m.b.H. orders Bank Austria, Vienna, to pay US Dollars
1,121.50 to C. Klein, Bloemengracht 15, Amsterdam, whose account number 72 34 91 524 is with ABN
Amro Bank, Amsterdam.
Bank Austria uses reference 394882.
In this example, the MT 103 STP will be sent to the party closest to the beneficiary, through several
reimbursement institutions. It would also be possible to send the MT 103 STP to the next party in the
transfer.
Note The alternative selected is dependent on correspondent relationships and financial practice
in the countries involved.
55
Standards MT November 2023
B. A cover message for the US dollar payment, which is provided through Chase Manhattan Bank,
New York, to ABN Amro Bank, New York.
BKAUATWW agreed on the Standard Service Level, as did its Dutch correspondent ABNANL2A.
Information Flow
MT 103 STP
Receiver's ABN Amro Bank
Correspondent 54A New York
(Field 57a of MT 202 COV)
(MT 910/950)
Receiver ABN Amro Bank
Amsterdam
(Field 58a of MT 202 COV)
Explanation Format
Sender BKAUATWW
Receiver ABNANL2A
Message text
Explanation Format
(1) Field 53A indicates the institution which is to provide the funds to the Receiver on behalf of the Sender.
(2) Field 54A is the receiver's correspondent - the institution which will receive the funds on behalf of the Receiver.
57
Standards MT November 2023
Legal Notices
Copyright
SWIFT © 2024. All rights reserved.
This material is a component of MyStandards, the SWIFT collaborative Web application used to man-
age standards definitions and industry usage. It can only be used and distributed in accordance with
MyStandards Terms of Use.
Unless otherwise agreed in writing with SWIFT SCRL, you have no right to:
- authorise external end users to use this component for other purposes than their internal use.
- remove, alter, cover, obfuscate or cancel from view any copyright or other proprietary rights notices
appearing in this physical medium.
- re-sell or authorise another party e.g. software and service providers, to re-sell this component.
Confidentiality
This publication may contain SWIFT or third-party confidential information. Only disclose it outside your
organisation in accordance with MyStandards Terms of Use and your related license rights.
This component is provided 'AS IS'. SWIFT does not give and excludes any express or implied war-
ranties with respect to this component such as but not limited to any guarantee as to its quality, supply
or availability.
Any and all rights, including title, ownership rights, copyright, trademark, patents, and any other intellec-
tual property rights of whatever nature in this component will remain the exclusive property of SWIFT or
its licensors.