MT100

SWIFTStandards
Category 1 - Customer Payments and Cheques

For SWIFTStandards MT October 2007
Message Reference Guide

This reference guide contains the category 1 message text standards, including a detailed description of the scope, the
format specifications, the rules, the guidelines, and the field specifications of each message type.
31 August 2007
Copyright
Copyright © S.W.I.F.T. SCRL ("SWIFT"), Avenue Adèle 1, B-1310 La Hulpe, Belgium, or its licensors, 2007.
All rights reserved. You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication may contain SWIFT or third-party confidential information. Do not disclose this publication outside your
organisation without the prior written consent of SWIFT.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest available version.
SWIFTStandards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFTStandards are licensed subject to the terms and conditions of the SWIFTStandards IPR Policy - End-User License
Agreement available at www.swift.com > Standards > More information.
Translations
The English version of SWIFT documentation is the only official version.
Trademarks and Patents
SWIFT, S.W.I.F.T., the SWIFT logo, Sibos, SWIFTNet, SWIFTAlliance, SWIFTStandards, SWIFTReady, and Accord are
trademarks of S.W.I.F.T. SCRL. Other SWIFT-derived service and product names, including SWIFTSolutions,
SWIFTWatch, and SWIFTSupport are tradenames of S.W.I.F.T. SCRL.
SWIFT is the trading name of S.W.I.F.T. SCRL.
Other product or company names in this publication are tradenames, trademarks, or registered trademarks of their respective
owners.
31 August 2007
Table of Contents
Table of Contents
Introduction ........................................................................................................................... 1
Category 1 Message Types.................................................................................................... 4
Euro - Impact on Category Message Standards .................................................................... 6
MT 101 Request for Transfer ................................................................................................ 7

MT 102 Multiple Customer Credit Transfer ....................................................................... 51
MT 102+ Multiple Customer Credit Transfer ..................................................................... 94
MT 103 Single Customer Credit Transfer ......................................................................... 131
MT 103+ Single Customer Credit Transfer ....................................................................... 202
MT 104 Direct Debit and Request for Debit Transfer Message ....................................... 253
MT 105 EDIFACT Envelope ............................................................................................ 281
MT 106 EDIFACT Envelope ............................................................................................ 284
MT 107 General Direct Debit Message ............................................................................. 287
MT 110 Advice of Cheque(s) ............................................................................................ 312
MT 111 Request for Stop Payment of a Cheque ............................................................... 323
MT 112 Status of a Request for Stop Payment of a Cheque ............................................. 329
MT 121 Multiple Interbank Funds Transfer (EDIFACT FINPAY Message) ................... 335
MT 190 Advice of Charges, Interest and Other Adjustments ........................................... 337
MT 191 Request for Payment of Charges, Interest and Other Expenses .......................... 338
MT 192 Request for Cancellation ..................................................................................... 339

MT 195 Queries ................................................................................................................. 340
MT 196 Answers ............................................................................................................... 341
MT 198 Proprietary Message ............................................................................................ 342
MT 199 Free Format Message .......................................................................................... 343
Glossary of Terms ............................................................................................................. 344
31 August 2007 iii

Category 1 - Customer Payments and Cheques for SWIFTStandards MT October 2007
iv Message Reference Guide

Introduction
Introduction
Overview
Category 1 consists of the following types of customer related payment messages:
• customer credit transfers
• customer debit transfers
• cheque payments
The messages in this category deal with payments, or information about payments, in which the ordering party
or the beneficiary, or both, are not financial institutions.
Changes
This volume incorporates the following main changes and additions to Category 1 Customer Payments and
Cheques as noted in the Standards Release Guide (SRG) 2007:
• the deletion of a network validated rule in MT 101 Request for Transfer
• the addition of a new structured option (50F) to the existing field :50a: Ordering Customer including
network validation of field structure in MT 101 Request for Transfer, MT 102 Multiple Customer Credit
Transfer, MT 102+, MT 103 Single Customer Credit transfer, MT 103+, MT 103 REMIT
• some editorial enhancements throughout the document
IMPORTANT
This volume contains information effective as of the October 2007 Standards Release. Therefore the
September 2006 edition of the User Handbook Standards volumes remains effective until October 2007.
Volume Formatting Explanation

This volume of the Standards User Handbook set contains general information about the category and a
detailed description of each message type which is currently available for use. For each message type, the
following information is provided:
Message Type Scope

The scope specifies the Sender and Receiver of the message and provides an explanation on how the message
is used. In some messages, an example of the message flow is also provided.
Message Type Format Specifications

The format specifications are the rules for the layout of the message type. This information is provided in table
form with the following information:
31 August 2007 1
MT nnn (Message Type Name)
N
Status Tag Field Name Content/Options
o.
M 20 Transaction Reference Number 16x 1
M 21 Related Reference 16x 2
Mandatory Sequence A (Sequence Name)
M 25 Account Identification 35x 3
M 32a Value Date, Currency Code, Amount C or D 4
-----> Optional Repetitive Sequence B (Sequence Name)
O 52a Ordering Institution A or D 5
M 71B Details of Charges 6*35x 6
O 72 Sender to Receiver Information 6*35x 7
-----|
M = Mandatory O = Optional
• MT nnn (Message Type Name) provides the message type number and name
• Status indicates if the field is
- M - Mandatory
- O - Optional
The status M for fields in optional (sub)sequences means that the field must be present if the
(sub)sequence is present and is otherwise not allowed.
• Tag is the field identification.
• Field Name is the detailed name of the field tag, for this message type.
• Content/Options provides permitted field length and characteristics. For information concerning field
structure, notation and character restrictions, please see SWIFTStandards MT General Information.
• No. identifies the number of the field in the Field Specifications for the message type.
Some messages are separated into sequences of fields, as shown above. An arrow indicates that a sequence of
fields may be repeated.
MT Network Validated Rules

Network validated rules are validated on the network, ie, rules for which an error code is defined. Rules
specified in this section affect more than one field in the message, placing a condition on one of the fields
specified. They are identified as Cn, or conditional rules.
MT Usage Rules
Usage rules are not validated on the network, ie, rules for which no error code is defined, but are nevertheless
mandatory for the correct usage of the message. Rules specified in this section affect more than one field in the
message, or more than one SWIFT message.
2 Message Reference Guide

Introduction
MT Guidelines
Guidelines are not validated on the network and are not mandatory for the correct usage of the message. They
concern good practices. Guidelines specified in this section affect more than one field in the message, or more
than one SWIFT message.
MT Field Specifications
The rules for the use of each field in the message are specified in this section. Each field is identified by its
index number (as shown in the No. column of the MT Format Specifications), field tag and detailed field
name, followed by a description of the field, which may contain some or all of the following:
• FORMAT specifies the field formats which are allowed for the field.
• PRESENCE indicates if the field is mandatory, optional or conditional in its sequence.
• DEFINITION specifies the definition of the field in the message type.
• CODES lists all codes available for use in the field. If there is more than one subfield for which codes are
defined, each separate code list will be identified with a CODES heading. When a list of codes is validated
by the network, the error code will be specified.
• NETWORK VALIDATED RULES specifies rules that are validated on the network, ie, rules for which an
error code is defined. Generally, rules specified in this section affect only the field in which they appear. In
some cases, rules which are validated at the message level, ie, rules which affect more than one field, are
repeated in this section. This is the case when the rule does not affect the presence of the field, but
information within several fields, eg, a currency which must be the same for more than one field in the
message.
• USAGE RULES specifies rules that are not validated on the network, ie, rules for which no error code is
defined, but are nevertheless mandatory for the correct usage of the field. Rules specified in this section
affect only the field in which they appear.
• EXAMPLES provides one or more examples of the field as it will be formatted/used.
MT Mapping
MT mapping provides an explanation of how to map the fields of the message into another SWIFT message,
either of the same or a different message type.
MT Examples
Examples are provided to illustrate the correct use of a message. Examples always include the following
information:
• Narrative provides a brief description of a transaction
• Information Flow illustrates the relationships between the parties involved in the message. An
explanation of the flow diagram can be found in SWIFTStandards MT General Information.
• SWIFT Format provides the message using the defined SWIFT format, and providing an explanation,
where necessary, of the fields which have been used.
31 August 2007 3
Category 1 Message Types
The following table lists all message types defined in category 1.

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 SWIFTStandards MT General Information.
MT MT Name Purpose Authen. Max. MUG VDO

Length
101 Request For Requests to debit a customer's Y 10,000 Y Y

Transfer account held at another
institution
102 Multiple Customer Conveys multiple payment Y 10,000 Y Y

102+ Credit Transfer instructions between financial
institutions
103 Single Customer Instructs a funds transfer Y 10,000 N Y

103+ Credit Transfer
103 Single Customer Instructs a funds transfer Y 10,000 Y Y

REMIT Credit Transfer
104 Direct Debit and Conveys direct debit Y 10,000 Y Y

Request for Debit instructions or requests for
Transfer direct debits between financial
institutions
105 EDIFACT Envelope An envelope which conveys a Y 2,000 Y N

2k EDIFACT message
106 EDIFACT Envelope An envelope which conveys a Y 10,000 Y N

10k EDIFACT message
107 General Direct To order the debit of a debtor's Y 10,000 Y Y

Debit account and to collect payment
from this account
110 Advice of Cheque Advises or confirms the Y 2,000 N Y

issuance of a cheque to the
drawee bank
111 Request for Stop Requests the drawee bank to Y 2,000 N Y

Payment of a stop payment of a cheque
Cheque
112 Status of a Request Indicates action(s) taken in Y 2,000 N Y

for Stop Payment of attempting to stop payment of a
a Cheque cheque
121 Multiple Interbank Contains an EDIFACT FINPAY Y 10,000 Y N

Funds Transfer message
190 Advice of Charges, Advises an account owner of Y 2,000 N N

Interest and Other charges, interest and other
Adjustments adjustments

Category 1 Message Types
MT MT Name Purpose Authen. Max. MUG VDO

Length
191 Request for Requests payment of charges, Y 2,000 N N

Payment of interest or other expenses
Charges, Interest
and Other Expenses
192 Request for Requests the Receiver to Y 2,000 N N

Cancellation consider cancellation of the
message identified in the
request
195 Queries Requests information relating to Y 2,000 N N

a previous message or
amendment to a previous
message
196 Answers Responds to an MT 195 Query Y 2,000 N N

or MT 192 Request for
Cancellation or other message
where no specific message type
has been provided for a
response
198 Proprietary Contains formats defined and Y 10,000 N N

Message agreed to between users and for
those messages not yet live
199 Free Format Contains information for which Y 2,000 N N

Message no other message type has been
defined
Note: A Message User Group (MUG), for the purposes of this book, is a group of users who have voluntarily
agreed to support the specified message type and have registered with SWIFT to send or receive the
specified message type. These messages are indicated in the preceding table in the column MUG.
Registration is free of charge. To register to use one or more message types, submit a registration request
(Register to a Message User Group) through www.swift.com. To withdraw from a MUG, use the
Deregister from a Message User Group request.
These forms are available on www.swift.com > Ordering & Support > Ordering.
To get the list of other members of a particular MUG, send an MT 999 to the Customer Implementation
team (SWHQBEBBCOS).
31 August 2007 5
Euro - Impact on Category Message Standards
See the SWIFTStandards MT General Information volume for full details of the Euro-Related Information
(ERI) and the impact on SWIFTStandards MT message types.

MT 101
MT 101 Request for Transfer
Note: The use of this message type requires Message User Group (MUG) registration.
MT 101 Scope
This message is sent by a financial institution on behalf of a non-financial institution account owner, ie, the
ordering customer/instructing party, and is subsequently received by the receiving financial institution and
processed by the receiving financial institution or the account servicing financial institution.
It is used to move funds from the ordering customer's account(s) serviced at the receiving financial institution
or at the account servicing institution, or from an account(s) owned by the ordering customer which the
instructing customer has explicit authority to debit, eg, a subsidiary account.
The MT 101 can be used to order the movement of funds:
• between ordering customer accounts, or
• in favour of a third party, either domestically or internationally.
MT 101 Format Specifications

The MT 101 consists of two sequences:
• Sequence A General Information is a single occurrence mandatory sequence and contains information to
be applied to all individual transactions detailed in sequence B.
• Sequence B Transaction Details is a repetitive sequence; each occurrence provides details of one individual
transaction. Fields which appear in both sequences are mutually exclusive.
MT 101 Request for Transfer

Status Tag Field Name Content/Options No.
Mandatory Sequence A General Information
M 20 Sender's Reference 16x 1
O 21R Customer Specified Reference 16x 2
M 28D Message Index/Total 5n/5n 3
O 50a Instructing Party C or L 4
O 50a Ordering Customer F, G, or H 5
O 52a Account Servicing Institution A or C 6
O 51A Sending Institution [/1!a][/34x] 7

4!a2!a2!c[3!c]
M 30 Requested Execution Date 6!n 8
O 25 Authorisation 35x 9
End of Sequence A General Information
-----> Mandatory Repetitive Sequence B Transaction Details
M 21 Transaction Reference 16x 10
31 August 2007 7
O 21F F/X Deal Reference 16x 11
----->
O 23E Instruction Code 4!c[/30x] 12
-----|
M 32B Currency/Transaction Amount 3!a15d 13
O 50a Ordering Customer F, G, or H 15
O 52a Account Servicing Institution A or C 16
O 56a Intermediary A, C, or D 17
O 57a Account With Institution A, C, or D 18
M 59a Beneficiary No letter option or A 19
O 70 Remittance Information 4*35x 20
O 77B Regulatory Reporting 3*35x 21
O 33B Currency/Original Ordered Amount 3!a15d 22
M 71A Details of Charges 3!a 23
O 25A Charges Account /34x 24
O 36 Exchange Rate 12d 25
-----| End of Sequence B Transaction Details
M = Mandatory, O = Optional
MT 101 Network Validated Rules

C1 If an exchange rate is given in field 36, the corresponding forex deal must be referenced in field 21F
(Error code(s): D54).
Sequence B Sequence B
if field 36 is … then field 21F is …
Present Mandatory
Not present Optional
C2 In each occurrence of sequence B, if field 33B is present and 'amount' in field 32B is not equal to zero,
then field 36 must be present, otherwise field 36 is not allowed (Error code(s): D60).

MT 101
Within the same occurrence of sequence B
If field 33B is … And amount in field 32B … Then field 36 is …
Present Equals zero Not allowed
NOT equals zero Mandatory
NOT present Not applicable Not allowed
C3 If there is only one debit account, the ordering customer must be identified in field 50a (option F, G or
H) in sequence A. Conversely, if multiple debit accounts are used, they must be identified for every
transaction in field 50a (option F, G or H) of sequence B.
Consequently, field 50a (option F, G or H), must be present in either sequence A (index 5) or in each
occurrence of sequence B (index 15), but must never be present in both sequences, nor be absent from
both sequences (Error code(s): D61).
Sequence A In every occurrence of sequence B

if field 50a (option F, G or H) is … then field 50a (option F, G or H) is …
Present Not allowed
Not present Mandatory
C4 Field 50a (option C or L), may be present in either sequence A (index 4), or in one or more occurrences
of sequence B (index 14), but must not be present in both sequences A and B (Error code(s): D62).
Sequence A Sequence B
if field 50a (option C or L) is … then field 50a (option C or L) is …
Present Not allowed
Not present Optional in any occurrence
C5 If field 33B is present in sequence B, its currency code must be different from the currency code in field
32B in the same occurrence of sequence B (Error code(s): D68).
Examples:
Valid Invalid
:32B:USD1000, :32B:USD1000,00
:33B:CHF1200, :33B:USD1000,
:32B:CHF1200, :32B:CHF1200,
:33B:USD1000, :33B:CHF1000,00
C6 Field 52a may be present in either sequence A or in one or more occurrences of sequence B, but must
not be present in both sequences (Error code(s): D64).
31 August 2007 9
if field 52a is … then field 52a is …
Present Not allowed
C7 If field 56a is present, field 57a must also be present (Error code(s): D65).
If field 56a is … then field 57a is …
Present Mandatory
C8 If field 21R is present in sequence A, then in each occurrence of sequence B, the currency code in fields
32B must be the same (Error code(s): D98).
C9 In each occurrence of sequence B, the presence of fields 33B and 21F is dependent on the presence and
value of fields 32B and 23E as follows (Error code(s): E54).
Within the same occurrence of sequence B
If amount in field 32B

And field 23E is … Then field 33B is … And field 21F is …
…
Equals zero Present and code equals Mandatory Optional

EQUI
Present and code NOT Not allowed Not allowed

equals EQUI
NOT present Not allowed Not allowed
NOT equals zero Not applicable Optional Optional
MT 101 Usage Rules

• If field 21R is present in sequence A, and field 28D indicates that more than one message is chained for
this request for transfer instruction, the currency code must be the same for all occurrences of field 32B in
sequence B of all chained messages.
• In case of an equivalent amount transfer, identified with the code EQUI in field 23E, the transaction
amount in field 32B must equal zero.
• In case of sweeping, topping or zero balancing operations, identified with a code in field 23E, the
transaction amount in field 32B can equal zero.
• In case field 28D indicates that messages are chained, all messages belonging to the same chain must have
exactly the same sender's reference in field 20.
• In case field 28D indicates that messages are chained, sequence A must be repeated and be identical for all
messages belonging to the same chain.
• When the currency of the settlement amount is in euro and it is necessary to indicate the equivalent in
National Currency Denomination, the following guideline applies:
- field 32B contains the euro amount, to be executed by the receiver;

MT 101
- field 33B contains the currency and value of the instructed amount i.e. the NCD amount, equivalent to
field 32B;
- field 36 (due to network validated rule 2) contains the fixed conversion rate between the euro and the
National Denomination Currency amounts;
- field 21F (due to network validated rule 1) contains the value "NONREF".
The complete chain of parties and the transaction flow is illustrated by the following figure:
Ordering Customer Ordering

or Instructing Party Customer
50C or L 50G or H
Request
Sender
Funds
MT
MT 101
Funds
Receiver Account Servicing
52a Institution
Funds
Intermediary
56a
Funds
Account
With Institution 57a
Funds
Beneficiary
D0010016
59a
The parties mentioned in the chain are not necessarily different entities. The first column of the table below
shows the parties that can be omitted in an MT 101. The second column specifies the party which assumes the
role of the party in the first column, when it is not present:
If the following party is missing … Its function is assumed by …
Instructing party Ordering customer
Account servicing institution Receiver
Intermediary Account with institution
Account with institution Receiver
31 August 2007 11
MT 101 Field Specifications

1. Field 20: Sender's Reference
FORMAT
16x
PRESENCE
Mandatory in mandatory sequence A
DEFINITION
This field specifies the reference assigned by the Sender to unambiguously identify the message.
NETWORK VALIDATED RULES
This field must not start or end with a slash '/' and must not contain two consecutive slashes '//' (Error code(s):
T26).
USAGE RULES
The reference must be unique for each message (or chain of messages) and is part of the message
identification and transaction identification which is to be used in related queries, cancellations, etc.
2. Field 21R: Customer Specified Reference

FORMAT
Option R 16x
PRESENCE
Optional in mandatory sequence A
DEFINITION
This field specifies the reference to the entire message assigned by either the:
• instructing party, when present or
• ordering customer, when the instructing party is not present.
T26).
USAGE RULES
When this field is present, the ordering customer requests a single debit entry for the sum of the amounts of all
transactions in the instruction, even if this instruction is chained in several messages. If the field is not used, all
debit items are posted individually.
3. Field 28D: Message Index/Total

FORMAT
Option D 5n/5n (Message Index)/(Total)
PRESENCE
DEFINITION
This field chains different messages by specifying the sequence number in the total number of messages.

MT 101
USAGE RULES
Both the message index and the total number of messages allow the receiver to check that all transactions to be
executed have been received.
4. Field 50a: Instructing Party

FORMAT
Option C 4!a2!a2!c[3!c] (BEI)
Option L 35x (Party Identifier)
PRESENCE
Conditional (see rule C4) in mandatory sequence A
DEFINITION
This field identifies the customer which is authorised by the account owner/account servicing institution to
order all the transactions in the message.
The BIC must be a BEI. Please refer to the latest version of the BIC Directory - Corporations for more
information about BEIs. (Error code(s): T27, T28, T29, T45, E57).
USAGE RULES
This field must only be used when the instructing customer is not also the account owner.
5. Field 50a: Ordering Customer

FORMAT
Option F 35x (Party Identifier)
4*35x (Name & Address)
Option G /34x (Account)
4!a2!a2!c[3!c] (BEI)
Option H /34x (Account)
In option F, the following line formats must be used (Error code(s): T54):
Line 1 (subfield /34x (Account)
Party Identifier)
Lines 2-5 (subfield 1!n/33x (Number)(Details)
Name & Address)
Or
Line 1 (subfield 4!a/30x (Code)(Identifier)

Party Identifier)
Name & Address)
PRESENCE
DEFINITION
This field identifies the account owner whose account is to be debited with all transactions in sequence B.
31 August 2007 13
CODES
In option F, when subfield 1 Party Identifier is used with the (Code)(Identifier) format, one of following codes
must be used (Error code(s): T55):
ARNU Alien Registration The code followed by a slash, '/' must be followed by the ISO country code, a
Number 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 The code followed by a slash, '/' must be followed by the ISO country code, a
Identification Number slash, '/', the issuer of the number, a slash, '/' and the Customer Identification
Number.
DRLC Driver's License The code followed by a slash, '/' must be followed by the ISO country code, a
Number slash, '/', the issuing authority, a slash, '/' and the Driver's License Number.
EMPL Employer Number The code followed by a slash, '/' must be followed by the ISO country code, a
slash, '/', the registration authority, a slash, '/' and the Employer Number.
IBEI International Business The code followed by a slash, '/' must be followed by the International
Entity Identifier Business Entity Identifier.
NIDN National Identity The code followed by a slash, '/' must be followed by the ISO country code, a
Number slash, '/' and the National Identity Number.
SOSE Social Security The code followed by a slash, '/' must be followed by the ISO country code, a
Number slash, '/' and the Social Security Number.
TXID Tax Identification The code followed by a slash, '/' must be followed by the ISO country code, a
Number slash, '/' and the Tax Identification Number.
CODES
In option F, each line of subfield 2 Name & Address when present must start with one of the following
numbers (Error code(s): T56):
1 Name of the ordering The number followed by a slash, '/' must be followed by the name of the
customer ordering customer (where it is recommended that the surname precedes given
name(s)).
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 number followed by a slash, '/' must be followed by the ISO country code,
a slash '/' and Town (Town can be complemented by postal code (for example
zip), country subdivision (for example state, province, or county).
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 The number followed by a slash, '/' must be followed by the ISO country code,
Identification Number a slash, '/', the issuer of the number, a slash, '/' and the Customer Identification
Number.
7 National Identity The number followed by a slash, '/' must be followed by the ISO country code,
Number a slash, '/' and the National Identity Number.
8 Additional The number followed by a slash, '/' is followed by information completing the
Information Identifier provided in subfield 1 (Party Identifier) used with the
(Code)(Identifier) format.

MT 101

information about BEIs (Error code(s): T27, T28, T29, T45, E57).
USAGE RULES
Both the account number of the ordering customer at the Receiver or at the account servicing institution and
the name and address or the BEI of the ordering customer must be present.
In option F, subfield 1 (Party Identifier) used with the (Code)(Identifier) format: if additional 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 & Address) using number 8.
In option F, subfield 2 Name & Address:
• Each number must appear on a separate line.
• Numbers must appear in increasing numerical order.
• Numbers may be repeated if more than one line is needed to provide the information indicated by the
number for example 2 lines for address details.
• Number 2 must not be used without number 3 and vice versa.
• The use of number 8 is only allowed to continue information on the Identifier of the ordering customer
provided in subfield 1 (Party Identifier) used with the (Code)(Identifier) format.
EXAMPLE
Option F - Example 1
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
3/US/NEW YORK, NY 10017
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
6. Field 52a: Account Servicing Institution

FORMAT
Option A [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (BIC)
Option C /34x (Party Identifier)
PRESENCE
31 August 2007 15
DEFINITION
This field specifies the account servicing institution - when other than the Receiver - which services the
account of the account owner to be debited. This is applicable even if field 50a Ordering Customer contains an
IBAN.
CODES
In option A, Party Identifier may be used to indicate a national clearing system code.
The following codes may be used preceded by a double slash ('//'):
AT 5!n Austrian Bankleitzahl

AU 6!n Australian Bank State Branch (BSB) Code
BL 8!n German Bankleitzahl
CC 9!n Canadian Payments Association Payment Routing Number
ES 8..9n Spanish Domestic Interbanking Code
FW without 9 digit code Pay by Fedwire
GR 7!n HEBIC (Hellenic Bank Identification Code)
HK 3!n Bank Code of Hong Kong
IE 6!n Irish National Clearing Code (NSC)
IN 11!c Indian Financial System Code (IFSC)
IT 10!n Italian Domestic Identification Code
PL 8!n Polish National Clearing Code (KNR)
PT 8!n Portuguese National Clearing Code
SC 6!n UK Domestic Sort Code
CODES
In option C, Party Identifier may be used to indicate a national clearing system code.

CH 6!n CHIPS Universal Identifier
CP 4!n CHIPS Participant Identifier
FW 9!n Fedwire Routing Number
IN 11!n Indian Financial System Code (IFSC)
RU 9!n Russian Central Bank Identification Code

MT 101

SW 3..5n Swiss Clearing Code (BC code)
SW 6!n Swiss Clearing Code (SIC code)

The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28,
T29, T45).
The BIC must not be a BEI. Please refer to the latest version of the BIC Directory - Corporations for more
information about BEIs. This error code applies to all types of BICs referenced in a FIN message including
SWIFT BICs, non-SWIFT BICs, Masters, Synonyms, Live destinations and Test & Training destinations
(Error code(s): C05).
USAGE RULES
The coded information contained in field 52a should be meaningful to the Receiver of the message.
Option A is the preferred option.
If the account servicing institution cannot be identified by a BIC, option C should be used containing a 2!a
clearing system code preceded by a double slash '//'.
7. Field 51A: Sending Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field identifies the Sender of the message.
Field 51A is only valid in FileAct (Error code(s): D63).
USAGE RULES
At least the first eight characters of the BIC in this field must be identical to the originator of this FileAct
message.
The content of field 20 Sender's Reference together with the content of this field provides the message
identification which is to be used in the case of queries, cancellations, etc.
8. Field 30: Requested Execution Date

FORMAT
6!n (Date)
PRESENCE
DEFINITION
This field specifies the date on which all subsequent transactions should be initiated by the executing bank.
Date must be a valid date expressed as YYMMDD (Error code(s): T50).
31 August 2007 17
USAGE RULES
This is the date on which the ordering customer's account(s) is (are) to be debited.
9. Field 25: Authorisation

FORMAT
35x
PRESENCE
DEFINITION
This field specifies additional security provisions, eg, a digital signature, between the ordering
customer/instructing party and the account servicing financial institution.
10. Field 21: Transaction Reference

FORMAT
16x
PRESENCE
Mandatory in mandatory sequence B
DEFINITION
This field specifies the unambiguous reference for the individual transaction contained in a particular
occurrence of sequence B.
T26).
USAGE RULES
In transaction specific queries, cancellations, etc., the Sender's reference together with the content of this field
provides the transaction identification.
11. Field 21F: F/X Deal Reference

FORMAT
Option F 16x
PRESENCE
Conditional (see rules C1 and C9) in mandatory sequence B
DEFINITION
This field specifies the foreign exchange contract reference between the ordering customer and the account
servicing financial institution.
CODES
The following code may be used:
NONREF There is no underlying foreign exchange deal to this transaction

MT 101

T26).
12. Field 23E: Instruction Code

FORMAT
Option E 4!c[/30x] (Instruction Code)(Additional Information)
PRESENCE
Optional in mandatory sequence B
DEFINITION
This field specifies instructions to be used between the ordering customer and the account servicer.
CODES
One of the following codes must be used (Error code(s): T47).
CHQB This transaction contains a request that the beneficiary be paid via issuance of a cheque.
CMSW This transaction contains a cash management instruction, requesting to sweep the account of the
ordering customer.
CMTO This transaction contains a cash management instruction, requesting to top the account of the ordering
customer above a certain floor amount. The floor amount, if not pre-agreed by the parties involved,
may be specified after the code.
CMZB This transaction contains a cash management instruction, requesting to zero balance the account of the
ordering customer.
CORT This transaction contains a payment that is made in settlement of a trade, eg, foreign exchange deal,
securities transaction.
EQUI This transaction contains an instruction requesting to pay the beneficiary customer an amount in one
currency, equivalent to an instructed amount in a different currency.
INTC This transaction contains an intra-company payment, ie, a payment between two companies belonging
to the same group.
NETS This transaction contains a payment that should be settled via a net settlement system, if available.
OTHR Used for bilaterally agreed codes/information. The actual bilateral code/information needs to be
specified in Additional Information.
PHON This transaction requires the beneficiary to be contacted by telephone and should be followed by the
appropriate telephone number. This code is meant for the last financial institution in the chain.
REPA Payment has a related e-Payments reference.
RTGS This transaction contains a payment that should be settled via a real time gross settlement system, if
available.
URGP This transaction contains a time sensitive payment which should be executed in an expeditious
manner.

Additional Information is only allowed when Instruction Code consists of one of the following codes: CMTO,
PHON, OTHR and REPA (Error code(s): D66).
In each occurrence of Sequence B: when this field is repeated, the same code word must not be present more
than once with the exception of OTHR. The code word OTHR may be repeated (Error code(s): E46).
In each occurrence of sequence B: when this field is used more than once, the following combinations are not
allowed (Error code(s): D67).
31 August 2007 19
CHQB with CMSW

CHQB with CMTO
CHQB with CMZB
CHQB with CORT
CHQB with NETS
CHQB with PHON
CHQB with REPA
CHQB with RTGS
CHQB with URGP
CMSW with CMTO
CMSW with CMZB
CMTO with CMZB
CORT with CMSW
CORT with CMTO
CORT with CMZB
CORT with REPA
EQUI with CMSW
EQUI with CMTO
EQUI with CMZB
NETS with RTGS
For example:
Valid Invalid
:23E:URGP :23E:CHQB
:23E:CORT :23E:URGP
:23E:NETS
:23E:RTGS
USAGE RULES
Code REPA indicates that the payment is the result of an initiation performed via an e-payments product
between the customers. This code is intended for the beneficiary's bank who should act according to the
specifications of the e-payments product.
The use of EQUI is subject to agreements between the ordering customer and beneficiary customer and
between the ordering customer and his account servicing institution.
To facilitate the receiving bank's processing when multiple codes are used, the codes must appear in the
following order:
• instructions for the receiver of the message (CMSW, CMTO, CMZB, INTC, REPA, CORT, URGP)
• codes impacting the routing or composition of the resulting payment message (NETS, RTGS)
• codes containing instructions for one of the following parties in the transaction chain (CHQB, PHON)
• information codes (OTHR)

MT 101
13. Field 32B: Currency/Transaction Amount

FORMAT
Option B 3!a15d (Currency)(Amount)
PRESENCE
DEFINITION
This field specifies the currency and the amount of the subsequent transfer to be executed by the Receiver.
Currency must be a valid ISO 4217 currency code (Error code(s): T52).
The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in
the maximum length. The number of digits following the comma must not exceed the maximum number
allowed for the specified currency (Error code(s): C03, T40, T43).
USAGE RULES
The amount is subject to deduction of the Receiver's/beneficiary bank's charges if field 71A is BEN or SHA.

FORMAT
Option C 4!a2!a2!c[3!c] (BEI)
PRESENCE
Conditional (see rule C4) in mandatory sequence B
DEFINITION
This field identifies the customer which is authorised by the account owner/account servicing institution to
order the transactions in this particular occurrence of sequence B.
USAGE RULES
This field must only be used when the instructing customer is not also the account owner.

FORMAT
Option G /34x (Account)
4!a2!a2!c[3!c] (BEI)
Option H /34x (Account)
31 August 2007 21

Party Identifier)
Name & Address)
Or
4!a/30x (Code)(Identifier)
Name & Address)
PRESENCE
DEFINITION
This field identifies the ordering customer which is the account owner ordering the transaction in the same
occurrence of the sequence.
CODES
In option F, when subfield 1 Party Identifier is used with the (Code)(Identifier) format, one of the following
codes must be used (Error code(s): T55):
Number.
CODES

MT 101
name(s)).
building name).
Number.

USAGE RULES
Both the account number of the ordering customer at the Receiver or at the account servicing institution and
the name and address or the BEI of the ordering customer must be present.
issue.
EXAMPLE
:50F:/12345678
31 August 2007 23
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
16. Field 52a: Account Servicing Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the account servicing institution - when other than the Receiver - which services the
account of the account owner to be debited. This is applicable even if field 50a Ordering Customer contains an
IBAN.
CODES

CODES

MT 101


T29, T45).
USAGE RULES
The coded information contained in field 52a should be meaningful to the Receiver of the message.
If the account servicing institution cannot be identified by a BIC, option C should be used containing a 2!a
clearing system code preceded by a double slash '//'.
17. Field 56a: Intermediary

FORMAT
4!a2!a2!c[3!c] (BIC)
Option D [/1!a][/34x] (Party Identifier)
PRESENCE
31 August 2007 25
DEFINITION
This field specifies the financial institution through which the transaction must pass to reach the account with
institution.
CODES

NZ 6!n New Zealand National Clearing Code
CODES
In option C, or D, Party Identifier may be used to indicate a national clearing system code.


MT 101


T29, T45).
USAGE RULES
The intermediary may be a branch or affiliate of the Receiver or the account with institution, or an entirely
different financial institution.
When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //IN 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.
If the intermediary cannot be identified by a BIC, option C should be used containing a 2!a clearing system
code preceded by a double slash '//'.
Option D must only be used in exceptional circumstances: when the party cannot be identified by a BIC, when
there is a need to be able to specify a name and address, for example, due to regulatory considerations or when
there is a bilateral agreement between the Sender and the Receiver permitting its use.
When qualified by a clearing system code or an account number, the use of option D will enable the automated
processing of the instruction(s) by the Receiver.
18. Field 57a: Account With Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the financial institution which services the account for the beneficiary customer. This is
applicable even if field 59 or 59A contains an IBAN.
CODES
31 August 2007 27

CODES


T29, T45).

MT 101
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 (with or without the 9-digit number), //AU, //CP or //IN is used, it should appear
only once and in the first of the fields 56a and 57a of the payment instruction.
If the account with institution cannot be identified by a BIC, option C should be used containing a 2!a clearing
system code preceded by a double slash '//'.
19. Field 59a: Beneficiary

FORMAT
No letter option [/34x] (Account)
Option A [/34x] (Account)
4!a2!a2!c[3!c] (BIC/BEI)
PRESENCE
DEFINITION
This field identifies the beneficiary of the subsequent operation from the particular occurrence of sequence B.
The BIC/BEI must be a SWIFT registered address, either connected or non-connected (Error code(s): T27,
T28, T29, T45).
USAGE RULES
At least the name or BIC/BEI of the beneficiary customer is mandatory.
20. Field 70: Remittance Information

FORMAT
4*35x (Narrative)
PRESENCE
31 August 2007 29
DEFINITION
This field specifies details of the individual transactions which are to be transmitted to the beneficiary
customer.
CODES
One of the following codes may be used, placed between slashes:
INV Invoice (followed by the date, reference and details of the invoice).
IPI Unique reference identifying a related International Payment Instruction (followed by up to 20
characters).
RFB Reference for the beneficiary customer (followed by up to 16 characters).
ROC Ordering customer's reference.
USAGE RULES
For national 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, ie, this information only
needs to be conveyed by the Receiver.
Multiple references can be used, if separated with a double slash, '//'. Code must not be repeated between two
references of the same kind.
EXAMPLE
:70:/RFB/BET072
:70:/INV/abc/SDF-96//1234-234///ROC/98I
U87
21. Field 77B: Regulatory Reporting

FORMAT
Option B 3*35x (Narrative)
In addition to narrative text, the following line formats may be used:
Line 1 /8a/2!a[//additional information] (Code)(Country)(Narrative)

Lines 2-3 [//continuation of additional information] (Narrative)
PRESENCE
DEFINITION
This field specifies code(s) for the statutory and/or regulatory information required by the authorities in the
country of the Receiver or the Sender/originating customer.
CODES
When the residence of either the ordering customer or beneficiary customer is to be identified, the following
codes may be used, placed between slashes ('/'):
BENEFRES Residence of beneficiary customer

ORDERRES Residence of ordering customer

MT 101
USAGE RULES
Country 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.
22. Field 33B: Currency/Original Ordered Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the original currency and amount as specified by the ordering customer.
USAGE RULES
This field is used when the currency and amount are different from those specified in field 32B.
23. Field 71A: Details of Charges

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the applicable charges for the subsequent transfer of funds.
CODES
One of the following codes must be used (Error code(s): T08):
BEN All transaction charges, including the charges of the financial institution servicing the ordering
customer's account, for the subsequent credit transfer(s) are to be borne by the beneficiary customer.
OUR All transaction charges for the subsequent credit transfer are to be borne by the ordering customer.
SHA All transaction charges other than the charges of the financial institution servicing the ordering
customer account are borne by the beneficiary customer.
USAGE RULES
These charge codes cover potential charges associated with the sending of subsequent MTs 102, 103. Charges
for sending the MT 101 should be handled outside of this message type.
31 August 2007 31
24. Field 25A: Charges Account

FORMAT
Option A /34x (Account)
PRESENCE
DEFINITION
This field specifies the ordering customer's account number to which applicable transaction charges should be
separately applied.
USAGE RULES
When used, the account number must be different from the account number specified in field 50a Ordering
Customer.
25. Field 36: Exchange Rate

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate applied by the ordering customer/instructing party when converting the
original ordered amount to the transaction amount.
The integer part of Rate must contain at least one digit. A decimal comma is mandatory and is included in the
maximum length (Error code(s): T40, T43).
MT 101 Mapping
The following illustrates the mapping of a single-transaction MT 101 onto an equivalent MT 103:

MT 101
Sender Sender
MT 101 MT 103
Receiver Receiver
20 20
21R 13C
28D 23B
(c)
50C or L 23E
50F or G or H 26T
(b) (d)
52a 32A
51A 33B
30 36
25 50A or F or K
21 51A
21F 52a
23E 53a
32B 54a
(e)
56a 55a
(e)
57a 56a
59a 57a
70 59A or 59
(f)
77B 70
33B 71A
71A 71F
25A 71G
36 72
77B
D0010069
77T
National and Banking practices may differ from the mapping shown above.
Mapping onto an MT 103 core is shown for illustration purposes. A multiple MT 101 could also be mapped
onto an MT 102 or onto several MTs 103. Mapping onto an MT103+ may require more constraints.
Note:
• Fields 20, 21R, 28D, 51A, 25, 21F and 25A should not be mapped onto the MT 103.
• See (a) in the figure above.
If both field 50a Instructing Party (50C or L) and field 50a Ordering Customer (50F, G or H) are present in
the MT 101 then, per default, 50a Ordering Customer should be mapped onto the subsequent MT 103.
• See (b) in the figure above.
Field 30 of the MT 101 is used to construct subfield 1 of field 32A of the MT 103. Whenever relevant, the
Interbank Settlement Date of the MT 103 takes into account the instruction codes present in field 23E of
the MT 101 (for example RTGS).
• See (c) in the figure above.
As a general rule, field 23E of the MT 101 is mapped to field 23E of the MT 103. However codes CMSW,
CMTO, CMZB, NETS and URGP should be mapped in field 70 of the MT 103. Code EQUI is not mapped
to a field of the MT103, but its presence in the MT 101 will result in the presence of fields 32A, 33B and
36 in the MT 103.
Note:Some codes require specific mapping action at the executing institution, for example:
31 August 2007 33
• RTGS mapped from the MT 101 to the MT 103 may require the payment to be executed via an RTGS
system or code //RT to be added in field 57a of the MT 103
• CHQB in the MT 101 will lead to the issuance of a cheque by the executing institution when fields 56a
and 57a are not present or by specified correspondent when fields 56a and/or 57a are present
• PHON in the MT 101 should be mapped to PHOB in the MT 103
• See (d) in the figure above.
When present, field 33B of the MT 101 is mapped onto field 33B of the MT 103. If field 33B is not present
in the MT 101, field 32B of the MT 101 is mapped onto field 33B of the MT 103. In all other cases, field
32B of the MT 101 is used to build subfields 2 and 3 of field 32A of the MT 103.
Note:Charges for the processing of the MT 101 are to be accounted for separately and posted to the
account mentioned in field 25A of the MT 101, when present. Below charges relate to the processing
of the MT 103 only.
• If field 71A of the MT 101 contains SHA, field 32B of the MT 101 is mapped to subfields 2 and 3 of
field 32A of the MT 103.
• If field 71A of the MT 101 contains OUR and charges are known, charges for the entire transaction are
added to field 32B of the MT 101 and mapped in field 32A of the MT 103. In this case, field 71G of the
MT 103 may be present.
• If field 71A of the MT 101 contains OUR and charges are not known, field 32B of the MT 101 is
mapped onto field 32A of the MT 103 and field 71G is not present (in this case, the executing
institution will be charged back by the next party(ies) in the transaction chain).
• If field 71A contains BEN, charges of the executing bank are deducted from field 32B from the
received MT 101. The result is mapped onto field 32A of the MT 103. In this case, charges of the
executing bank will be quoted into field 71F of the MT 103.
• See (e) in the figure above.
Fields 56a and 57a:
- If both fields 56a and 57a are not present in the MT 101, the MT 101 triggers a book transfer at the
executing institution or issuance of a cheque.
- If both fields 56a and 57a are present, field 56a maps to the Receiver of the MT 103 and field 57a is
mapped in field 57a of the MT 103.
- If only field 57a is present in the MT 101, field 57a is mapped onto Receiver of the MT 103.
• See (f) in the figure above.
It is not mandatory to map field 21 of the MT 101 in the MT 103. However, if desired, it should be mapped
onto field 70 of the MT 103 as follows: :70:/ROC/value.
MT 101 Examples
Examples on field 50H occurring in Sequence A vs. Sequence B

The following examples illustrate the use of field 50H appearing in either sequence A or sequence B.
Background
A multinational Swiss pharmaceutical company, MAG-NUM, must frequently make £ Sterling payments to
different third party companies located in the U.K. MAG-NUM maintains several £ Sterling accounts with its
primary U.K. correspondent.

MT 101
Case 1: Ordering customer account appears in Sequence A; Single MT 101 with

single debit account.
This £ Sterling account holder wishes to make a payment to a third party U.K. supplier. The corresponding
MT 101 is:
Explanation Format
Sender BNKACH10
Message type 101
Receiver BNKAGB22
Message text
Sender's reference :20:FILEREF1
Customer specified reference :21R:UKSUPPLIER090901
Message Index/Total :28D:1/1
Ordering customer :50H:/8754219990

MAG-NUM INC.
GENERAL A/C
BANHOFFSTRASSE 30
ZURICH, SWITZERLAND
Requested execution date :30:090905
Transaction reference :21:TRANSREF1
Currency/transaction amount :32B:GBP12500,
Beneficiary :59:/1091282
Beneficiary 1
LOW STREET 1
LONDON, UK
Details of charges :71A:OUR
End of message text/trailer
Case 2: Ordering customer account appears in sequence A; Multiple MT 101 with

single debit account.
This £ Sterling account holder wishes to pay three different third party U.K. suppliers on the same date.
MAG-NUM needs to use the same £ Sterling account for all three payments. The corresponding MT 101 is:
Explanation Format
Sender BNKACH10
Message type 101
Receiver BNKAGB22
Message text: General information
31 August 2007 35
Explanation Format

MAG-NUM INC.
GENERAL A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
Transaction details 1
Beneficiary 1
LOW STREET 1
LONDON, UK
Beneficiary 2
HIGH STREET 1
LONDON, UK
Beneficiary3
PARK LANE 9
LONDON, UK
Case 3: Ordering customer account appears in Sequence B; Multiple MT 101 with

multiple debit accounts.
MAG-NUM wants to make payments out of three different £ Sterling accounts it maintains with its primary
U.K. correspondent. The corresponding MT 101 is:

MT 101
Explanation Format
Sender BNKACH10
Message type 101
Receiver BNKAGB22

MAG-NUM INC.
PRM SUPPLIER 1 A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
Beneficiary1
LOW STREET 1
LONDON, UK

MAG-NUM INC.
PRM SUPPLIER 1 A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
Beneficiary2
HIGH STREET 1
LONDON, UK
31 August 2007 37
Explanation Format
Ordering customer 50H:/5678908642

MAG-NUM INC.
PRM SUPPLIER 1 A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
Beneficiary3
PARK LANE 9
LONDON, UK
Examples on field 50L Instructing Party
Case 1: Parent company paying from a subsidiary account.

Company AXY in country XY wants to pay an invoice from its subsidiary TYZ's account in country YZ.
Company AXY is authorised to make payments from subsidiary TYZ's account.
Company AXY instructs its bank (BNKAXYLL) in country XY to send an MT 101 Request For Transfer to
the bank servicing the account for the subsidiary TYZ (BNKBYZLL) in country YZ, to request a payment to
be made from the account of subsidiary TYZ in favour of beneficiary BFD.
As the name of the subsidiary would be meaningless for the beneficiary BFD, the name of the parent company
AXY must appear in the payment message BNKBYZLL will generate.
BNKAXYLL
Parent
Company
AXY
50C or 50L
MT
MT 101
Subsidiary
Company Beneficiary
TYZ BFD
50F or G or H 59a
D0010017
BNKBYZLL
Case 2: Head Office paying from own account on behalf of multiple subsidiaries and
itself.
Walt Disney has concentrated its treasury cash management functions into one office, Walt Disney Company
in Los Angeles, California. All wire transfer transactions ordered by Walt Disney's subsidiaries - such as
Disney Stores, Disney Productions - are sent to the bank by Walt Disney Company.

MT 101
At its various banks, Walt Disney Company holds master concentration accounts which it uses (debits) to
cover any wire transfer transactions made through these banks. Payments which Walt Disney orders may be
initiated for itself, or on behalf of one of its subsidiaries.
Scenario:
Account number at Bank of America (to debit): 12345-67891
Account owner: Walt Disney Company
Subsidiaries: Disney Stores, Disney Productions
Ordering parties: Walt Disney Company, Disney Stores, Disney

Productions
Payments:
1. On behalf of Disney Stores, for 118,982.05 USD to Wung Lu Manufacturing at Hongkong and Shanghai
Banking Corporation (account number 60648929889) in Beijing, CN.
2. On behalf of Disney Productions, for 50,000 USD, to Tristan Recording Studios at Midland Bank (account
0010499) in London, GB.
3. On behalf of Walt Disney Company, for 377,250 USD, to River Paper Company at Wells Fargo Bank
(account number 26351-38947) in San Francisco, CA.
4. On behalf of Walt Disney Company, for 132,546.93 USD, to Pacific Telephone at Bank of America
(account 12334-98765) in San Francisco, CA.
Walt Disney requests its transfer via First National Bank of Chicago (FNBCUS44), which sends the MT 101
Request For Transfer to Bank of America, San Francisco (BOFAUS6S).
Payment Messages:
Explanation Format
Sender FNBCUS44
Message type 101
Receiver BOFAUS6S
Sender's reference :20:091106-DSNY0001
Ordering customer :50H:/12345-67891

WALT DISNEY COMPANY
MOUSE STREET 1
Los Angeles, CA
Transaction reference :21:DS091106WLMCN
Currency/transaction amount :32B:USD118982,05
Instructing party :50L:DISNEY STORES SANTA MONICA, CA
31 August 2007 39
Explanation Format
Account with institution :57A:HSBCCNSHBJG
Beneficiary :59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE.
BEIJING
Transaction reference :21:DP091106TRSGB
Currency/transaction amount :32B:USD50000,
Instructing party :50L:WALT DISNEY PRODUCTIONS

HOLLYWOOD CA
Account with institution :57A:MIDLGB22
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
BROMLEY, KENT
Transaction reference :21:WDC091106RPCUS
Instructing party :50L:WALT DISNEY COMPANY LOS ANGELES,

CA
Account with institution :57A:WFBIUS6S
Beneficiary :59:/26351-38947
RIVERS PAPER COMPANY
37498 STONE ROAD
SAN RAMON, CA
Transaction reference :21:WDC091106PTUS
Currency/transaction amount :32B:USD132546,93
Instructing party :50L:WALT DISNEY COMPANY LOS ANGELES,

CA
Beneficiary :59:/12334-98765
Pacific Telephone
San Francisco, CA.
End of message test/trailer

MT 101
The following payments are the corresponding MTs 103 that Bank of America sends for each applicable
payment specified in the above MT 101:
(1)
Explanation Format
Sender BOFAUS6S
Message type 103
Receiver HSBCCNSHBJG
Message text
Sender's reference :20:6S-091106WD0002
Bank Operation Code :23B:CRED
Value date, currency, amount :32A:091106USD118982,05
Ordering customer :50K:/12345-67891

WALT DISNEY COMPANY
MOUSE STREET 1
Los Angeles, CA
Beneficiary :59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE.
BEIJING
(2)
Explanation Format
Sender BOFAUS6S
Message type 103
Receiver MIDLGB22
Message text
Value date, currency, amount :32A:091106USD132546,93

WALT DISNEY COMPANY
MOUSE STREET 1
Los Angeles, CA
31 August 2007 41
Explanation Format
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
BROMLEY, KENT
(3)
Although this payment would probably be sent via Fedwire, the MT 103 is shown for illustration purposes.
Explanation Format
Sender BOFAUS6S
Message type 103
Receiver WFBIUS66
Message text
Value date, currency, amount :32A:091106USD377250,

WALT DISNEY COMPANY
MOUSE STREET 1
Los Angeles, CA
Beneficiary :59:/26351-38947
RIVERS PAPER COMPANY
37498 STONE ROAD
SAN RAMON, CA
(4)
Since this transaction results in a book transfer on Bank of America's books, no corresponding MT 103 is
generated. The beneficiary, Pacific Telephone, is advised of this payment via a balance reporting service and
printed statement.
A complete example
Finpetrol, a corporate customer located in Helsinki, Finland sends a multiple MT 101 Request for Transfer
payment message through its sending financial institution (UXXXFIHH) to the receiving financial institution
(CHXXUS33) with which it also maintains an account. Two transactions contained in this multiple payment
message request the Receiver to debit the ordering customer account, and effect payment to the associated
beneficiary customers. The third transaction requests the Receiver to repatriate funds held in an account
(account number 9102099999) at the branch of the Receiver (CHXXUS33BBB), for further credit to
Finpetrol's account held at the Receiver (account number 9020123100).

MT 101
Beneficiary Tony Baloney maintains an account with the Receiver (CHXXUS33), while beneficiary Softease
PC maintains an account with a financial institution other than the Receiver, namely the account with
institution (CHYYUS33). A software vendor invoice payment to Softease PC and a pension payment to Tony
Baloney, in euro (EUR), are contained within this multiple payment message.
Finpetrol supplements its existing agreements with the three financial institutions with which it maintains an
account, ie the sending financial institution (UXXXFIHH), the receiving financial institution (CHXXUS33),
and the account servicing financial institution (CHXXUS33BBB). The supplement to the existing agreements
establishes the basis for an agreement to exchange MT 101 messages.
UXXXFIHH
Finpetrol
request
MT 101
(MT 940)
Tony Baloney
funds cheque
CHXXUS33BBB CHXXUS33
MT 103
(or equivalent)
Softease PC
funds
D0010018
CHYYUS33
The details agreed upon by the MT 101 Request for Transfer parties, which are highlighted below for the
purpose of this message, are as follows:
• transaction charges have been agreed upon, specified and are not included in the transaction amount
• the exchange rate to be applied to the transaction is known in advance by the ordering customer
• FINPETROL wishes to have its portion of the associated transaction charges posted to a special charges
account number: 9101000123
In the interest of simplicity, only 3 transactions have been included in the following MT 101 message.
Explanation Format
Sending financial institution UXXXFIHH
Message type 101
Receiving financial institution CHXXUS33
Sender's reference :20:11FF99RR
31 August 2007 43
Explanation Format
Transaction reference :21:REF501
F/X deal reference :21F:UKNOWIT1234
Ordering customer :50F:/9020123100

1/FINPETROL INC.
2/ANDRELAE SPINKATU 7
3/FI/HELSINKI
Account with institution :57C://CP9999
Beneficiary :59:/756-857489-21
SOFTEASE PC GRAPHICS
34 BRENTWOOD ROAD
SEAFORD, NEW YORK 11246
Remittance information :70:/INV/19S95
Regulatory reporting :77B:/BENEFRES/US

//34 BRENTWOOD ROAD
//SEAFORD, NEW YORK 11246
Currency/original ordered amount :33B:EUR100000,
Details of charges :71A:SHA
Charges account :25A:/9101000123
Exchange rate :36:0,90
F/X deal reference :21F:UKNOWIT1234
Instruction code :23E:CHQB

1/FINPETROL INC.
3/FI/HELSINKI
Beneficiary :59:TONY BALONEY

3159 MYRTLE AVENUE
BROOKLYN, NEW YORK 11245
Remittance information :70:09-02 PENSION PAYMENT
Original ordered amount :33B:EUR2000,

MT 101
Explanation Format
Charges account :25A:/9101000123
Instruction code :23E:CMZB
Instruction code :23E:INTC
Currency/transaction amount :32B:0,

1/FINPETROL INC.
3/FI/HELSINKI
Account servicing institution :52A:CHXXUS33BBB
FINPETROL INC.
ANDRELAE SPINKATU 7
HELSINKI FINLAND
In the following statement message sent by CHXXUS33 to the Sender of the MT 101, the statement line
contains the transaction amounts as specified in Field 32B, transaction references as specified in field 21, and
the ordering customer account number as specified in field 50H, Account.
Explanation Format
Sender CHXXUS33
Message Type 940
Receiver UXXXFIHH
Message text
Sender's reference :20:MTRFT111
Account identification :25:9020123100
Statement number :28:101/01
Opening balance :60F:090326CUSD100000,
Statement line :61:090327D90000, S101REF501

//1010101011
Information to account owner :86:/REMI//INV/19S95
Statement line :61:090327D1800,S101REF502

//1010101012
Information to account owner :86:/REMI/03-02 PENSION PAYMENT//PAID

BY CHECK
31 August 2007 45
Explanation Format
Statement line :61:090327C73530,FCMZREF503

//101010BBB3
Information to account owner :86:/ORDP/CHXXUS33BBB
Closing balance :62F:090327CUSD81730,
MT 101 Operating Procedures

This message requires the implementation of special procedures, with its use governed by at least the
following two bilateral agreements:
• Between the account servicing financial institution and the ordering customer.
• Between the sending financial institution and the ordering customer.
Depending on local market practice, additional bilateral agreements may be required, for example:
• Between the sending financial institution and the receiving financial institution.
• Between the account servicing financial institution and the instructing party.
Institutions are recommended to use the MT 101 Operational Rules and Checklist as a guide for establishing
their agreements. These bilateral agreements cover the responsibilities/liabilities of the parties of the request
for transfer, the transaction amount limits, etc.
MT 101 Operational Rules & Checklist

This section provides a checklist for MT 101 payments. It is strongly recommended that these guidelines be
used by financial institutions as a basis for establishing bilateral or multilateral agreements for the processing
of request for transfer payments, ie payments transmitted by MT 101 via FIN, or FileAct.
It is also recommended that all items listed be covered in the bilateral or multilateral agreements. In order to
further facilitate the set up of these agreements, common procedures have been defined which financial
institutions, if they wish, may override.
The checklist is not intended to provide an exhaustive list of items, nor does SWIFT claim any responsibility
for it.
Bilateral Agreements, General Overview:

Bilateral Agreement 1:
Amends an existing agreement between the receiving financial institution and the ordering customer.
This agreement establishes the receiving financial institution's authorisation to accept and act upon ordering
customer requested payment instructions received from the sending financial institution. Responsibility of
effecting the actual movement of funds is an obligation of the receiving financial institution.
Amends an existing (electronic payments link) agreement between the sending financial institution and the
ordering customer.

MT 101
This agreement must clarify the obligations of the sending financial institution, including ensuring the
integrity of the message received from the ordering customer, and the monitoring of the delivery of the
message to the receiving financial institution.
The agreement should also state that the liability of the sending financial institution is limited to the delivery
of this message to the SWIFT network in a timely manner. In other words the sending financial institution is
not liable for the actual payment.
Establishes a bilateral agreement between financial institutions exchanging request for transfer messages.
This agreement, if necessary, should further clarify the inter-bank responsibilities of the financial institutions
involved in the request for transfer payment flow.
Establishes a bilateral agreement between the account servicing financial institution and the instructing
party/ordering customer.
This agreement, when used, allows the account owner to authorise the account servicing financial institution
to effect the transfers ordered by the ordering customer or instructing party.
Transaction Amount Limits

When financial institutions agree to define amount limits on the individual transactions, their limits should be
specified per currency.
When the agreement allows for transactions above amounts to which specific requirements apply, eg
regulatory reporting requirements, these requirements and their associated formatting should also be specified
in the agreement.
Charging Options and Amounts

There are three charging options as defined for use in the MT 101, ie OUR, SHA, BEN.
These charges can be an exact amount or formula (percentage). The charges cover the guarantee and
processing of transactions which the Receiver provides to the Sender, up to the transactions posting to the
Beneficiary's account, or execution of payment to the beneficiary's account with institution. The pricing of
incidental bank-customer services, eg the method of advice for daily/weekly/monthly statements, and their
subsequent charging, which may differ from institution to institution, are not considered to be part of the
charges.
Charges due to Charges per message (1) Charges per transaction (1)
(1) formula or exact amount
Dates & Time Frames

The sending financial institution and the receiving financial institution should agree on the time frame needed
by the Receiver to execute the payments accepted in its country. This time frame starts as of an agreed upon
cut-off time for receipt of incoming messages by the Receiver.
31 August 2007 47
Messages received before the Receiver's cut-off time, will be settled on a pre-agreed upon day which is X
number of days following the day of receipt D. For messages received after the Receiver's cut-off time, the
settlement time frame will be based on D+1.
D will also be the basis for calculating the requested execution date, ie the date on which the ordering
customer account is to be debited.
Currency 1 Currency 2
Receiver's cut-off time
Settlement time frame D (+) D (+)
Execution time frame for on/us D (+) D (+)

payments (until funds are on
account of Beneficiary)
Execution time frame for not on/us D (+) D (+)

payments (until funds are on the
Explanation:
D= Date of acceptance and receipt, meaning the message is received by Receiver before their cut-off
time;
-or-
D= Date of receipt, and, D + 1 = date of acceptance, meaning the message was received after the
Receiver's cut-off time on D.
Level of Controls/Checks and Acceptance of Messages/Transactions

Unless otherwise agreed, financial institutions will take as a basis for their controls/checks all current security
aspects of FIN or FileAct as defined in the SWIFT FIN and FileAct User Handbooks, as well as the MT 101
message syntax and semantics as defined in the MT 101 message specifications.
In order to achieve straight-through processing of the MT 101s exchanged, financial institutions should define
checks and controls related to the bilaterally agreed items.
Unless otherwise agreed/required, transactions passing the checks and controls are considered accepted and
therefore irrevocable, ie to be posted to the ordering customer account at the Receiver. In FileAct, the positive
acknowledgement sent by the Receiver confirms acceptance of the message received. In FIN, no specific
message is required.
If transactions do not pass the checks/controls, they will be rejected (see section 5 below).
Checks and controls performed by the Receiver, including error codes prior to the execution of the
transactions:
Checks/Controls Yes/No Error code
Transaction amount
Requested execution date
Validity of sending financial

institution

MT 101
Checks/Controls Yes/No Error code
Account number/validity of
ordering customer
Currency present
Account number/identification of
beneficiary
Remittance data (Length/Code)
Instructing code
Account balance
Credit limit
Other
Rejects/Returns of Messages/Transactions
For rejects due to a communication failure between the Sender and the Receiver, the existing FIN and FileAct
rules apply.
Unless otherwise agreed, messages properly received but failing to pass the checks as defined in section 4 (see
above) will be rejected by the Receiver without further processing.
When advising of the transaction/message rejection in FIN, financial institutions are recommended to use
either the MT 195, or another message type which follow the SWIFT payment reject guidelines. In FileAct,
financial institutions are recommended to use the negative acknowledgement to advise of the rejection.
The reject advice should contain, at a minimum, the reference of the rejected transaction/message and the
corresponding error code(s). The parties should bilaterally agree the maximum delay acceptable for the
Receiver to notify the sending financial institution, as well as possible related charges.
Unless otherwise agreed, the notification that is returned to the Sender exempts the Receiver from processing
the message. The sending financial institution will, after correction, resubmit the transaction/message.
The return of a rejected transaction/message to the sending financial institution after the transaction/message
has been posted to an account of the ordering customer at the Receiver, will cause a settlement. Unless
otherwise agreed, this settlement will adhere to the following rules:
• it should be in the same currency as the original transaction currency
• it should take place at a bilaterally agreed value date
• the original ordered transaction amount should remain unchanged
• the settlement should take place via the same account relationship(s)
• normal banking practice prevails.
All subscribers should agree on a maximum number of working days after receipt of the MT 101 for
rejecting/returning a transaction/message, and on the associated charges to be applied.
The following chart provides details regarding the transaction/message reject/return:
31 August 2007 49
Reject Return
Maximum delay from moment of

receipt to advice of the reject/return
to Sender
Charges due to the reject/return
A Reject occurs when the message and/or transaction has not yet been booked, ie, accounting has not yet
taken place.
A Return occurs when the message and/or transaction has already been booked, ie, accounting has already
taken place.
Cancellations
Unless otherwise agreed or required by law, messages properly received and accepted are to be considered as
irrevocable. Cancellation therefore should be the exception.
If, however, cancellations are accepted in the bilateral agreement, the following details should be agreed upon:
Details
Acceptable delay for the ordering customer to request

cancellation of message
Acceptable delay for acceptance and response by the

Receiver to such a request
Charges due to the Receiver as a result of such a request
It is recommended that request for cancellations be sent by MT 192 and responded to by MT 196.

MT 102
MT 102 Multiple Customer Credit Transfer
MT 102 Scope
This message is sent by or on behalf of the financial institution of the ordering customer(s) to another financial
institution for payment to the beneficiary customer.
It requests the Receiver to credit the beneficiary customer(s) directly or indirectly through a clearing
mechanism or another financial institution, or to issue a cheque to the beneficiary.
This message is used to convey multiple payment instructions between financial institutions for clean
payments. Its use is subject to bilateral/multilateral agreements between Sender and Receiver.
Amongst other things, these bilateral agreements cover the transaction amount limits, the currencies accepted
and their settlement. The multiple payments checklist included below is recommended as a guide for
institutions in the setup of their agreements.

The MT 102 consists of three sequences:
• Sequence A General Information is a single occurrence sequence and contains information which applies
to all individual transactions described in sequence B.
• Sequence B Transaction Details is a repetitive sequence. Each occurrence is used to provide details of one
individual transaction.
• Sequence C Settlement Details is a single occurrence sequence and contains information about the
settlement.
MT 102 Multiple Customer Credit Transfer

M 20 File Reference 16x 1
M 23 Bank Operation Code 16x 2

4!a2!a2!c[3!c]
O 50a Ordering Customer A, F, or K 4
O 52a Ordering Institution A, B, or C 5
O 26T Transaction Type Code 3!c 6
O 71A Details of Charges 3!a 8
31 August 2007 51
M 32B Transaction Amount 3!a15d 11
O 52a Ordering Institution A, B, or C 13
O 57a Account With Institution A or C 14
M 59a Beneficiary Customer No letter option or A 15
O 33B Currency/Instructed Amount 3!a15d 19
----->
O 71F Sender's Charges 3!a15d 21
-----|
O 71G Receiver's Charges 3!a15d 22
Mandatory Sequence C Settlement Details
M 32A Value Date, Currency Code, Amount 6!n3!a15d 24
O 19 Sum of Amounts 17d 25
O 71G Sum of Receiver's Charges 3!a15d 26
----->
O 13C Time Indication /8c/4!n1!x4!n 27
-----|
O 53a Sender's Correspondent A or C 28
O 54A Receiver's Correspondent [/1!a][/34x] 29

4!a2!a2!c[3!c]
End of Sequence C Settlement Details

C1 If field 19 is present in sequence C, it must equal the sum of the amounts in all occurrences of field 32B

MT 102
C2 The currency code in the fields 71G, 32B and 32A must be the same for all occurrences of these fields
in the message (Error code(s): C02).
C3 Field 50a must be present either in sequence A or in each occurrence of sequence B, but it must never
be present in both sequences, nor be absent from both sequences (Error code(s): D17).
If 50a in sequence A is … then 50a in each sequence B is …
Present Not allowed
C4 Field 71A must be present either in sequence A or in each occurrence of sequence B, but it must never
Sequence A In each occurrence of sequence B

if field 71A is … then field 71A is …
Present Not allowed
C5 If a field 52a, 26T or 77B is present in sequence A, that field must not be present in any occurrence of
sequence B. When a field 52a, 26T or 77B is present in any occurrence of sequence B, that field must
not be present in sequence A (Error code(s): D18).

Present Not allowed

if field 26T is … then field 26T is …
Present Not allowed

if field 77B is … then field 77B is …
Present Not allowed
C6 Field 36 (sequence A or sequence B) must be present in the message if there is any sequence B which
contains a field 33B with a currency code different from the currency code in field 32B; in all other
cases field 36 is not allowed in the message.
When a field 36 (sequence A or sequence B) is required, EITHER field 36 must be present in sequence
A and not in any sequence B, OR it must be present in every sequence B which contains fields 32B and
33B with different currency codes and must not be present in sequence A or any other sequence B
31 August 2007 53
If field 36 is present Then in minimum one And field 36 is not allowed in

occurrence of Seq. B field 33B any occurrence of Seq. B
must be present and currency
codes in fields 32B and 33B must
be different
Sequence A In each occurrence of Sequence B
And currency codes in

If field 36 is … If field 33B is … fields 32B and 33B are Then field 36 is …
…
Not present Present Equal Not allowed
Not equal Mandatory
Not present Not applicable Not allowed
C7 If field 23 contains the code CHQB, the Account Number must not be present in field 59a. In all other
cases, it is mandatory (Error code(s): D93).
If 23 contains … A/N line of 59a …
CHQB Forbidden
Other Mandatory
Examples:
Valid Invalid
:23:CHQB(CrLf) :23:CHQB(CrLf)
:59:xxxxx(CrLf) :59:/xxxxx(CrLf)
xxxxx(CrLf)
:23:CREDIT(CrLf) :23:CREDIT(CrLf)
:59:/xxxxx(CrLf) :59:xxxxx(CrLf)
xxxxx(CrLf) xxxxx(CrLf)
:23:CRTST(CrLf) :23:CRTST(CrLf)
:59:/xxxxx(CrLf) :59:xxxxx(CrLf)
xxxxx(CrLf) xxxxx(CrLf)
C8 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 in each occurrence of sequence B, otherwise field 33B is optional (Error code(s): D49).

MT 102
If country code of Sender's and country code of Receiver's

In each occurrence of Seq. B
BIC equals one of the listed BIC equals one of the listed
then field 33B is …
country codes country codes
Yes Yes Mandatory
Yes No Optional
No Yes Optional
No No Optional
Note:See Rule C10

C9 If field 71A in sequence A contains OUR, then field 71F is not allowed and field 71G is optional in any
occurrence of sequence B (Error code(s): E13).
In each occurrence of sequence B

In sequence A
if field 71A is …
then field(s) 71F is (are) … and field 71G is …
OUR Not allowed Optional
If field 71A in sequence B contains OUR, then field 71F is not allowed and field 71G is optional in the
same occurrence of sequence B (Error code(s): E13).
In the same occurrence of sequence B

In sequence B
if field 71A is …
Note:See rule C4 (rule C4 takes precedence over rule C9)

If field 71A in sequence A contains SHA, then fields 71F are optional and field 71G is not allowed in
any occurrence of sequence B (Error code(s): D50).

In sequence A
if field 71A is …
SHA Optional Not allowed
If field 71A in sequence B contains SHA, then fields 71F are optional and field 71G is not allowed in
the same occurrence of sequence B (Error code(s): D50).

In sequence B
if field 71A is …

If field 71A in sequence A contains BEN, then at least one occurrence of field 71F is mandatory in each
occurrence of sequence B and field 71G is not allowed (Error code(s): E15).
31 August 2007 55

In sequence A
if field 71A is …
BEN Mandatory Not allowed
If field 71A in sequence B contains BEN, then at least one occurrence of field 71F is mandatory in the
same occurrence of sequence B and field 71G is not allowed (Error code(s): E15).

In sequence B
if field 71A is …
Note:See rules C4 (rule C4 takes precedence over rule C9)

C10 If either field 71F (at least one occurrence) or field 71G are present in an occurrence of sequence B,
then field 33B is mandatory in the same occurrence of sequence B (Error code(s): D51).
If field 71F is … and field 71G is … then field 33B is …
Present Present Rejected (1)
Present Not present Mandatory
Not present Present Mandatory
Not present Not present Optional
(1) both fields 71F and 71G present is not a valid combination, see rule C9.
C11 If field 71G is present in an occurrence of sequence B, then field 71G is mandatory in the sequence C
If in any occurrence of sequence B in sequence C

field 71G is … then field 71G is …
Present Mandatory
MT 102 Usage Rules

• If a registered user receives an MT 102 without bilateral agreement with the Sender, the Receiver should
query the message according to normal banking practice.
• When sending the MT 102 via FileAct, institutions must use the payment-related profile.
Usage Rules for Amount Related Fields

There is a relationship between the amount related fields 33B, 32B, 36, 71G, 71F, 19 and 32A which may be
logically expressed in the following formulas:

MT 102
• For each occurrence of sequence B, the instructed amount in field 33B, adjusted with the exchange rate in
field 36, minus the Sender's charges in field(s) 71F, equals the transaction amount in field 32B.
• The sum of all transaction amounts in fields 32B, equals the total amount in field 19.
• The sum of all Receiver's charges in fields 71G of sequence B, equals the total Receiver's charges of field
71G in sequence C.
• The total amount in field 19 (or the sum of all transaction amounts in fields 32B), plus the total Receiver's
charges in field 71G of sequence C, equals the interbank settled amount in field 32A.
Presence of the fields mentioned above is subject to the conditional field rules C5, C6, C8, C9, C10 and C11.
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.
Sequence B
Sequence A
If field 71A is …
then field 32B is … field 71F is … and field 71G is …
OUR Net amount to be credited Not allowed Optional

to the Beneficiary.
Charges have been
prepaid by the ordering
customer.
SHA Amount as instructed by Optional Not allowed

the originator, eg, invoice
amount.
Receiver will deduct its
own charges.
BEN Amount as instructed by At least one occurrence Not allowed

the originator, after mandatory
sending bank has
deducted its charges.
charges.
Sequence C
Sequence A
If field 71A is …
then field 19 is … field 32A is … and field 71G is …
OUR Sum of field(s) 32B of Settlement Amount Sum of fields 71G of

sequence B equals field 19 plus field sequences B
71G of sequence C
SHA Not used Settlement Amount Not allowed

equals Sum of field(s)
32B of sequence B
BEN Not used Settlement Amount Not allowed

32B of sequence B
Examples Transaction A:
• Pay the equivalent of EUR1000,00 in GBP to a beneficiary in the United Kingdom
31 August 2007 57
• The exchange rate is 1 EUR for 0,61999 GBP

• Ordering bank's (sending bank's) transaction charge is EUR 5 (=GBP 3,1)
• Beneficiary bank's (receiving bank's) transaction charge is GBP 4 (=EUR 6,45)
Example A1: Charging option is OUR

A. Amount debited from the ordering customer's account
Original ordered amount EUR 1000,00
+ Sender's charges EUR 5,00
+ Receiver's charges EUR 6,45
= Debit amount EUR 1011,45
B. MT 102 extract:
Field Tag Content
Sequence B 32B GBP 619,99
33B EUR 1000,00
71A OUR
71G GBP 4,00
36 0,61999
Sequence C 19 GBP 619,99
32A GBP 623,99
71G GBP 4,00
C. The subsequent MT 950 shows one debit entry for GBP 623,99, ie, field 32A, sequence C.
D. Amount credited to the beneficiary:
Credit Amount GBP 619,99
Example A2: Charging option is SHA

A. Amount debited from the ordering customer's account:
Original ordered amount EUR 1000,00
B. MT 102 extract:

MT 102
Field Tag Content
33B EUR 1000,00
71A SHA
36 0,61999
Sequence C 32A GBP 619,99
Interbank Settlement Amount GBP 619,99
- Receiver's charges GBP 4,00
= Credit Amount GBP 615,99
Example A3: Charging option is BEN

A. Amount debited to the ordering customer's account:
Original ordered amount = Debit EUR 1000,00

amount
B. MT 102 extract:
Field Tag Content
33B EUR 1000,00
71A BEN
71F GBP 3,10
36 0,61999
Equivalent of ordered amount GBP 619,99
- Sender's charges GBP 3,10
= Credit amount GBP 612,89
31 August 2007 59
Examples Transaction B
• Pay GBP 1000,00 to a beneficiary in the United Kingdom
• The exchange rate is 1 EUR for 0,61999 GBP
• Ordering bank's (sending bank's) transaction charge is EUR 5 (=GBP 3,1)
• Beneficiary bank's (receiving bank's) transaction charge is GBP 4 (=EUR 6,45)
• The ordering customer has an account in euro
• Sender and Receiver's BIC are within the EU-country list
Example B1: Charging option is OUR

Debit on EUR account
Equivalent of ordered amount EUR 1612,93
B. MT 102 extract
Field Tag Content
33B GBP 1000,00
71A OUR
71G GBP 4,00
Sequence C 19 GBP 1000,00
32A GBP 1004,00
71G GBP 4,00
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 GBP1004,00, ie, field 32A, sequence C.
Original ordered amount = Credit GBP 1000,00

amount
Example B2: Charging option is SHA


MT 102
Debit on EUR-account
Equivalent of ordered amount EUR 1612,93
B. MT 102 extract:
Field Tag Content
33B GBP 1000,00
71A SHA
Amount in 32A GBP 1000,00
Example B3: Charging option is BEN

Debit on: EUR account
Equivalent of ordered amount = Debit amount EUR 1612,93
B. MT 102 extract:
Field Tag Content
33B GBP 1000,00
71A BEN
71F GBP 3,10
Note:field 36 does not have to be used since currency in fields 32A and 33B is the same.
31 August 2007 61
Original ordered amount GBP 1000,00
Note:The beneficiary is also advised of the Sender's charges of GBP 3,10

1. Field 20: File Reference
FORMAT
16x
PRESENCE
DEFINITION
T26).
USAGE RULES
This reference must be quoted in any related confirmation or statement, eg, MT 900 Confirmation of Debit
and/or 950 Statement Message.
The file reference must be unique for each file and is part of the file identification and transaction
identification which is used in case of queries, cancellations etc.
2. Field 23: Bank Operation Code

FORMAT
16x
To be formatted as:
6a
PRESENCE
DEFINITION
This field identifies the type of operation.
CODES
One of the following codes, or bilaterally agreed codes may be used:

MT 102
CHQB This message contains transactions requesting that the beneficiary be paid via issuance of a cheque.
CREDIT This message contains credit transfer(s) to be processed according to the pre-established bilateral
agreement between the Sender and the Receiver.
CRTST This message contains credit transfers for test purpose(s).
SPAY This message contains credit transfer(s) to be processed according to the SWIFTPay Service Level.
USAGE RULES
As tests in FIN should be done in Test & Training, the code CRTST is only valid when sent by a Test &
Training destination.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
USAGE RULES
The content of field 20, File Reference, together with the content of this field provides the message
identification which is to be used in case of file related queries, cancellations etc.
In FileAct, at least the first eight characters of the BIC in this field must be identical to the originator of the
FileAct message.

FORMAT
Option K [/34x] (Account)

Party Identifier)
Name & Address)
Or
31 August 2007 63

Party Identifier)
Name & Address)
PRESENCE
DEFINITION
This field identifies the customer ordering all transactions described in sequence B.
CODES
Number.
CODES
name(s)).
building name).

MT 102
Number.

T28, T29, T45).
USAGE RULES
If the account number of the ordering customer is present, it must be stated in Account.
issue.
EXAMPLE
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
:50F:DRLC/BE/BRUSSELS/NB0949042
1/DUPONT JACQUES
31 August 2007 65
2/HIGH STREET 6, APT 6C

3/BE/BRUSSELS
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
: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 is
123456789/8-1234567890.
5. Field 52a: Ordering Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
Option B [/1!a][/34x] (Party Identifier)
[35x] (Location)
PRESENCE
DEFINITION
This field specifies the financial institution, when different from the Sender, which instructed the Sender to
transmit all transactions described in sequence B. This is applicable even if field(s) 50a contain(s) an IBAN.
CODES


MT 102

CODES


T29, T45).
USAGE RULES
If the ordering institution cannot be identified by a BIC, option C should be used containing a 2!a clearing
system code preceded by a double slash ('//').
Option B is to be used to identify a branch of the Sender when that branch has neither a BIC nor a clearing
system code or when its clearing system code is meaningless for the Receiver.
31 August 2007 67
6. Field 26T: Transaction Type Code

FORMAT
Option T 3!c
PRESENCE
DEFINITION
This field identifies the nature of, purpose of and/or reason for all transactions described in sequence B, eg,
salaries, pensions or dividends.
USAGE RULES
Codes from the EUROSTAT list "Code List for Balance of Payments Collection Systems" may be used in this
field.
The information given is intended both for regulatory and statutory requirements and/or to provide
information to the beneficiary customer on the nature of the transaction.

FORMAT

PRESENCE
DEFINITION
This field specifies the code(s) for the statutory and/or regulatory information required by the authorities in the
country of the Receiver or Sender.
CODES
When the residence of either the ordering customer or the beneficiary customer is to be identified, the
following codes may be used, placed between slashes ('/'):

USAGE RULES
customer.
The information specified must not have been explicitly conveyed in another field and is valid for all
transactions described in sequence B.

FORMAT
Option A 3!a (Code)

MT 102
PRESENCE
DEFINITION
This field specifies which party will bear the charges for all transactions described in sequence B.
CODES
BEN All transaction charges are to be borne by the beneficiary customer.

OUR All transaction charges are to be borne by the ordering customer.
SHA Transaction charges on the Sender's side are to be borne by the ordering customer and transaction
charges on the Receiver's side are to be borne by the beneficiary customer.

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert all instructed amounts specified in field 33B in sequence
B.
USAGE RULES
This field must be present, when a currency conversion has been performed on the Sender's side.

FORMAT
16x
PRESENCE
DEFINITION
T26).
USAGE RULES
In transaction related queries, cancellations etc., the content of field 20 File Reference together with the
content of this field provides the transaction identification.
31 August 2007 69
11. Field 32B: Transaction Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the individual transaction amount remitted by the Sender to the Receiver.
USAGE RULES
This amount will, taking into account the charging option, be the basis for the Receiver to calculate the amount
to be credited to the beneficiary.
Depending on the charging option specified in field 71A, the content of field 32B is as follows:
• If field 71A is OUR, the net amount to be credited to the beneficiary, as charges have been prepaid by the
ordering customer.
• If field 71A is SHA, the amount as instructed by the originator, eg, invoice amount, of which the Receiver
will deduct its own charges.
• If field 71A is BEN, the amount as instructed by the originator minus the Senders' charges, and from which
amount the Receiver will deduct its charges.

FORMAT

Party Identifier)
Name & Address)
Or
Party Identifier)
Name & Address)

MT 102
PRESENCE
DEFINITION
This field identifies the customer ordering the transaction in this occurrence of the sequence.
CODES
Number.
CODES
name(s)).
building name).
31 August 2007 71
Number.

T28, T29, T45).
USAGE RULES
issue.
EXAMPLE
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
1/DUPONT JACQUES
3/BE/BRUSSELS

MT 102
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
123456789/8-1234567890.

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
DEFINITION
This field specifies the financial institution, when other than the Sender, which instructed the Sender to
transmit the transaction. This is applicable even if field(s) 50a contain(s) an IBAN.
CODES

31 August 2007 73
CODES


T29, T45).
USAGE RULES
If the ordering institution cannot be identified by a BIC, option C should be used containing a 2!a clearing
Option B is to be used to identify a branch of the Sender when that branch has neither a BIC nor a clearing
system code or when its clearing system code is meaningless for the Receiver.

FORMAT
4!a2!a2!c[3!c] (BIC)

MT 102
PRESENCE
DEFINITION
This field specifies the financial institution which services the account for the beneficiary customer identified
in the same sequence. This is applicable even if field 59 or 59A contains an IBAN.
CODES

RT Pay by Real Time Gross Settlement
ZA 6!n South African National Clearing Code
CODES

31 August 2007 75


T29, T45).
USAGE RULES
banks require that the code //FW appears in the optional Party Identifier of field 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 57a.
The code //RT is binding for the Receiver. If it is used with option A, it must not be followed by any other
information. If it is used with option C, it may be followed by another domestic clearing code.
If the account with institution cannot be identified by a BIC, option C should be used containing a 2!a clearing
15. Field 59a: Beneficiary Customer

FORMAT
PRESENCE
DEFINITION
This field specifies the customer to which the transaction amount should be transmitted.
T28, T29, T45).

MT 102
USAGE RULES
At least the name or the BIC/BEI of the beneficiary customer is mandatory.
If a BEI is specified, it must be meaningful for the financial institution that services the account for the
beneficiary customer.

FORMAT
4*35x (Narrative)
PRESENCE
DEFINITION
This field specifies details of the individual transaction which are to be transmitted to the beneficiary
customer.
CODES
One of the following codes may be used, placed between slashes ('/'):
characters).
USAGE RULES
This field must not contain information to be acted upon by the Receiver.
Due to national clearing restrictions, which vary significantly from country to country, the Sender must agree
to the maximum usable length of this field with the Receiver.
EXAMPLE
:70:/RFB/12345

FORMAT
Option T 3!c
PRESENCE
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the individual transaction, eg, salary, pension
or dividend.
CODES
field.
USAGE RULES
31 August 2007 77

FORMAT

PRESENCE
DEFINITION
This field specifies the codes for the statutory and/or regulatory information required by the authorities in the
country of the Receiver or the Sender.
CODES

USAGE RULES
customer.
19. Field 33B: Currency/Instructed Amount

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

MT 102
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 exchange took
place, field 32B equals 33B, if present.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges for the transaction in the same occurrence of sequence B.
CODES
BEN The transaction charges are to be borne by the beneficiary customer.

OUR The transaction charges are to be borne by the ordering customer.
SHA The transaction charges on the Sender's side are to be borne by the ordering customer and the
transaction charges on the Receiver's side are to be borne by the beneficiary customer.
21. Field 71F: Sender's Charges

FORMAT
Option F 3!a15d (Currency)(Amount)
PRESENCE
DEFINITION
This repetitive field specifies the currency and amount of the transaction charges deducted by the Sender 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 transaction amount in field 32B.
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. Ie, 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.
31 August 2007 79
22. Field 71G: Receiver's Charges

FORMAT
Option G 3!a15d (Currency)(Amount)
PRESENCE
DEFINITION
This field specifies the currency and amount of the transaction charges due to the Receiver.
USAGE RULES
The Receiver's charges are to be conveyed to the Receiver, not for transparency but for accounting reasons, ie,
to facilitate bookkeeping and to calculate or verify the total Receiver's charges amount stipulated in Sequence
C.

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert the instructed amount specified in field 33B in the same
USAGE RULES
This field must be present when a currency conversion has been performed on the Sender's side.
24. Field 32A: Value Date, Currency Code, Amount

FORMAT
Option A 6!n3!a15d (Date)(Currency)(Amount)
PRESENCE
Mandatory in mandatory sequence C
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.

MT 102

USAGE RULES
Where field 71A indicates OUR payments, this field contains the sum of the amounts specified in the fields 19
and 71G.
Where field 71A indicates SHA or BEN payments, this field contains the total of all fields 32B.
25. Field 19: Sum of Amounts

FORMAT
17d (Amount)
PRESENCE
Optional in mandatory sequence C
DEFINITION
This field specifies the sum of all amounts appearing in field 32B in each occurrence of sequence B.
allowed for the currency specified in field 32A (Error code(s): C03, T40, T43).
USAGE RULES
This field is only to be used where the sum of amounts is different from the settlement amount specified in
field 32A, ie, when one or more transactions in sequence B contains the charging option OUR in field 71A.
26. Field 71G: Sum of Receiver's Charges

FORMAT
PRESENCE
Conditional (see rule C11) in mandatory sequence C
DEFINITION
This field specifies the currency and accumulated amount of the transaction charges due to the Receiver.
If field 71G is present in sequence C, the amount must not equal '0' (Error code(s): D57).
31 August 2007 81
USAGE RULES
Where field 71A indicates OUR payments either in sequence A, or in one or more occurrences of sequence B,
this field identifies the sum of the charges due, which has been prepaid and included in the interbank
settlement amount.
For transparency or accounting reasons, this field is not to be used when field 71A, either in sequence A or in
all occurrences of sequence B, indicates BEN or SHA payments.
27. Field 13C: Time Indication

FORMAT
Option C /8c/4!n1!x4!n (Code)(Time indication)(Sign)(Time offset)
PRESENCE
DEFINITION
This repetitive field specifies one or several time indication(s) related to the processing of the payment
instruction.
CODES
CLSTIME The time by which the funding payment must be credited, with confirmation, to the CLS
Bank's account at the central bank, expressed in Central European Time (CET).
RNCTIME The time at which a TARGET payment has been credited at the receiving central bank,
expressed in Central European Time (CET).
SNDTIME The time at which a TARGET payment has been debited at the sending central bank,

Time indication must be a valid time expressed as HHMM (Error code(s): T38).
Sign is either "+" or "-" (Error code(s): T15).
Time offset is expressed as HHMM, where the hour component, ie, 'HH', must be in the range of 00 through
13,and the minute component, ie, '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).
EXAMPLE
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 (ie during winter time).
If the same instruction had been sent on 10 June (ie during summer time), time indication field would have
been completed as follows: :13C:/CLSTIME/0915+0200

MT 102
Offsets of local time zones against UTC are published in the green section of the BIC Directory.
28. Field 53a: Sender's Correspondent

FORMAT
4!a2!a2!c[3!c] (BIC)
Option C /34x (Account)
PRESENCE
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.
T29, T45).
USAGE RULES
Absence of this field implies that the bilaterally agreed account is to be used for settlement.
Option C must be used where only an account number is to be specified.
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 53a.
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.
When field 53a is present and contains a branch of the Sender, the need for a cover message is dependent 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, ie, MT 202/203 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 transaction and
the correspondent relationship between the Sender and the Receiver relative to that currency.
29. Field 54A: Receiver's Correspondent

FORMAT
4!a2!a2!c[3!c] (BIC)
31 August 2007 83
PRESENCE
DEFINITION
Where required, this field specifies the branch of the Receiver or another financial institution at which the
funds will be made available to the Receiver.
T29, T45).
USAGE RULES
The absence of fields 53a and 54A implies that the single direct account relationship between the Sender and
the Receiver, in the currency of the transfer, will be used.
In those cases where field 54A contains a branch of the Receiver, and is not preceded by field 53a, or field 53a
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 Receiver 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.
Field 54A containing the name of a financial institution other than the Receiver's branch must be preceded 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 transaction and
the correspondent relationship between the Sender and Receiver relative to that currency.
30. Field 72: Sender to Receiver Information

FORMAT
6*35x (Narrative - Structured Format)
The following line formats must be used:
Line 1 /8c/[additional information]

Lines 2-6 [//continuation of additional information]
or
[/8c/[additional information]]
PRESENCE

MT 102
DEFINITION
This field specifies additional information for the Receiver.
USAGE RULES
This field may be used to provide additional information to the Receiver where no other field is available. In
view of the possible delay of execution and/or rejection of the transaction(s), field 72 may only be used after
bilateral agreement between the Sender and the Receiver and in encoded form.
The codes REJT/RETN may be used in this field. If either of these codes is used in the first position of the first
line, placed between slashes ('/'), it is mandatory to follow the Payments Reject/Return Guidelines described in
the SWIFTStandards Usage Guidelines.
MT 102 Examples
Narrative
Consortia Pension Scheme, a corporate in Zürich requests its bank (BNKACHZZ) to execute a bulk of
payments. The bulk contains pension payments in Swiss Francs. The beneficiaries have their account with the
Belgian correspondent of BNKACHZZ.
BNKACHZZ established a bilateral agreement with its Belgian correspondent (BNKBBEBB) to exchange
MT 102s for low value transactions. Both banks agreed on a number of details, some of which are highlighted
for the purpose of this message:
• transaction charges due to BNKBBEBB for the guarantee and processing of on us payments up to the
posting to the beneficiary's account, are EUR 5, per transaction
• charges information is explicitly included in the message for control purposes
• charges are settled with the same value date as the sum of transaction amounts
• conversion, if necessary, is performed at the Sender's side. Consequently, transactions are always sent in
the currency of the receiving country
• the same exchange rate is applied for all transactions within a same message.
31 August 2007 85
Information Flow
Ordering Customer Consortia Pension Scheme

Zurich
50a
Sender BNKACHZZ
MT
(MT 950)
MT 102
Receiver BNKBBEBB
Beneficiary Customers 59a 59a

Johann Willems Joan Mills
D0010019
Brussels Brussels
SWIFT Message
Explanation Format
Sender BNKACHZZ
Message type 102
Receiver BNKBBEBB
File reference :20:5362/MPB
Bank operation code :23:CREDIT
Ordering customer :50K:/1234567890

CONSORTIA PENSION SCHEME
FRIEDRICHSTRASSE, 27
8022-ZURICH
Transaction reference :21:ABC/123

MT 102
Explanation Format
Transaction amount :32B:EUR1250,
Beneficiary customer :59:/001161685134

JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS
Remittance information :70:PENSION PAYMENT SEPTEMBER 2009
Original ordered amount :33B:CHF2000,
Receiver's charges/amount :71G:EUR5,

JOAN MILLS
AVENUE LOUISE 213
1050 BRUSSELS
Settlement details
Value date, currency code, amount :32A:090828EUR3135,
Sum of amounts :19:3125,
Sum of Receiver's charges/amount :71G:EUR10,
In the statement message sent by BNKBBEBB to its Swiss correspondent, the settlement amount as specified
in field 32A and the file 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:
SWIFT Message
Explanation Format
Sender BNKBBEBB
Message type 950
Receiver BNKACHZZ
Message text
Transaction reference number :20:112734
31 August 2007 87
Explanation Format
Statement number :28C:102/1
Opening balance :60F:C090827EUR72000,
Statement line :61:090828D3135,S1025362/MPB//1234T
Closing balance :62F:C090828EUR68865,
MT 102 Checklist
This document provides a checklist which is strongly recommended to be used by financial institutions as a
basis for setting up bilateral or multilateral agreements for the processing of crossborder customer payments,
ie, Credit Transfers transmitted by MT 102 via FIN or FileAct.
It is recommended that all items listed be covered in the bilateral or multilateral agreements. In order to further
facilitate the set up of these agreements, common procedures have been defined which financial institutions, if
they wish, may override.
The checklist is not intended to provide an exhaustive list of items nor does SWIFT claim any responsibility
for it.
Currencies Accepted, their Transaction Amount Limit and Settlement

Currencies Accepted
Unless otherwise agreed, multiple payment transactions are either expressed in the currency of the sending or
the receiving country. If financial institutions wish to accept third currencies this should be bilaterally agreed.
Transaction Amount Limit
If financial institutions agree to define amount limits to the individual transactions, they should specify them
per currency.
If the agreement allows for transactions above amounts to which specific requirements apply, eg, regulatory
reporting requirements, these requirements and their formatting should be specified as well in the agreement.
Settlement
Unless otherwise agreed, direct account relationship between the Sender and the Receiver will be used for the
booking of the transactions exchanged. However if they wish, financial institutions may also bilaterally agree
to include third reimbursement parties in the settlement.
Whatever the agreement, transactions contained in a same message will be booked in one single entry.
For each currency accepted, the amount limit, the account number(s) used for settlement, if other than the
normal one(s), and/or the third reimbursement party(ies) involved, if any, can be indicated in the chart below:
Transaction amount Third reimbursement

Currencies accepted Settlement account
limit institutions(s) if any

MT 102
Charges
Unless otherwise agreed, financial institutions will accept the charging options as defined and allowed for in
the MT 102. If financial institutions wish to accept only one option, this should be bilaterally agreed.
Financial institutions which accept the OUR option should agree on and specify the transaction charges in the
receiving country for 'on us' and if applicable 'not on us' payments.
These transaction charges can be an exact amount or formula (percentage) and cover the guarantee and
processing of transactions which the Receiver provides to the Sender until the execution in the receiving
country up to the posting to the beneficiary's account. The pricing of bank-customer services, eg, for the
method of advice - for daily/weekly/monthly statement for instance, being different from institution to
institution are considered not to be part of the charges.
Charges per message: Charges per

Type of payment: on
Charges due to: formula or exact transaction: formula or
us/not on us
amount exact amount
The above charges are preferably set for each trimester, if necessary semester. Changes to these charges should
be announced one month before the end of the term.
The messages sent as from that implementation date, will be subject to the new tariffs of the Receiver.
Charges Specifications in the MT 102
Unless otherwise agreed, the pre-agreed charges will be included in the MT 102s exchanged, as appropriate,
for information and control purposes and this in a consistent manner.
Unless otherwise agreed, charges will always be expressed in the same currency as the transaction amount(s)
and settlement amount of the message.
In case the charges amounts, due to the above rule, are quoted in a currency different to the one specified in the
bilateral agreement, the exchange rate should be quoted in the message exchanged.
Settlement Procedure for Charges
Unless otherwise agreed, financial institutions will separately indicate in the MT 102 the sum of charges due
to the Sender and/or to the Receiver, as appropriate.
The amount settled between financial institutions with the value date specified includes at a minimum the sum
of all transaction amounts. Whether the sum of charges due to the Sender and/or Receiver will also be included
in the settlement amount, will depend on the agreed settlement procedure for charges. Regarding this
procedure, financial institutions can agree that:
Charges are settled with same value date as the sum of

all transaction amounts and booked together

all transaction amounts but booked separately
Charges are settled periodically (once …)
Other
Only when using the first or second option, the settlement amount will include the sum of charges.
31 August 2007 89
Data Transmission and Bulking Criteria

Unless otherwise agreed, credit transfer transactions contained in the same MT 102 should be grouped as
follows:
• operations with same bank operation code
• operations in same currency
• operations with same settlement account/institution
• operations with same value date
Financial institutions should agree whether only head office or also branches can be the Sender and/or
Receiver of the MT 102 and whether FileAct and/or FIN will be used as transmission method:
BIC Bank1 BIC Bank2
Only head-office
Head office and all domestic

branches
Head office and a limited number of

domestic branches as listed: only
list location code and branch code
In case FileAct is selected, financial institutions should agree on the maximum size of the MT 102 and
whether more than one MT 102 may be contained within the same FileAct message. Financial institutions
should also decide whether an MT 102 can be split over two or more FileAct messages as this may have an
operational impact.
Number of MT 102(s) per FileAct MT 102 split over two or more

Maximum size of MT 102
message FileAct messages
Date and Time Frames

Financial institutions should agree on the timeframe needed by the Receiver to execute the payments accepted
in its country. This timeframe starts counting as of an agreed cut-off time for receipt of incoming messages by
the Receiver.
Messages received before cut-off time, will be settled on a pre-agreed day which is a (number of) day(s)
following the day of receipt (day of receipt = D). For messages received after cut-off time, the settlement
timeframe will be based on D+1.
D will also be the basis for calculating the execution dates (dates when the funds are available to the
Beneficiary).
Date of receipt/acceptance = D

MT 102
Settlement timeframe D (+) D (+)
Execution timeframe for on/us D (+) D (+)

account of the Beneficiary)
Execution timeframe for not on/us D (+) D (+)


Message Level
Unless otherwise agreed, financial institutions will take as a basis for their controls/checks all security aspects
of FIN or FileAct as defined in the SWIFT FIN and FileAct User Handbooks as well as the MT 102 message
syntax and semantics as defined in the MT 102 message specifications.
In order to achieve straight-through processing of the MT 102s exchanged, financial institutions should define
checks and controls relating to the bilaterally agreed items.
Unless otherwise agreed, messages passing the checks and controls, are considered accepted and therefore
irrevocable, ie, to be posted to the nostro/loro account. In FileAct, the positive Acknowledgement sent by the
Receiver confirms acceptance of the message received. In FIN, no specific message is required.
If messages do not pass the checks/controls, they will be rejected (see the next checkpoint).
Proposed checks and controls, relating to the bilaterally agreed items, performed by the Receiver and their
error codes:
Control/Check Yes/No Error Code
Settlement amount
Value date
Sender
Currencies present
Bulking criteria used
Information present in field 72
Bank operation code
Other
Transaction Level
Once the message is accepted, further checks are proposed to take place at transaction level. Only if
transaction(s) pass the checks, will they be executed. If not, they will be rejected (see the next checkpoint).
Proposed checks and controls performed by the Receiver including error codes prior to the execution of the
transactions:
31 August 2007 91
Account number of beneficiary
Transaction amount
Beneficiary bank identification
Length of remittance data
Other
Rejects of Messages and/or Transactions

Message Rejects:
For rejects due to a communication failure between the Sender and the Receiver, the existing FIN and FileAct
rules apply.
Unless otherwise agreed, messages properly received but failing to pass the message level checks (as defined
in the previous checkpoint) will be rejected by the Receiver without further processing. Financial institutions
are recommended to use the MT 195 in FIN or the negative acknowledgement in FileAct to advise the
rejection. The reject advice should contain at a minimum the reference of the rejected message and the error
code(s). The maximum delay acceptable for the Receiver to notify the Sender and possible related charges
should be bilaterally agreed.
Unless otherwise agreed, the notification returned to the Sender will exempt the Receiver from processing the
message. The Sender will, after correction, resubmit the message.
Transaction Rejects:
The return to the originator of transactions being rejected after the message which contained them has been
posted to a nostro/loro account (between the Sender and the Receiver), will cause a settlement. Unless
• the original transaction amount should remain unchanged
• the settlement should take place via the same account relationship
Financial institutions should agree on a maximum of working days after receipt of the MT 102 for rejecting a
transaction and on the charges applied.
The following chart provides details regarding the message/transaction rejects:
Reject of message Reject of transaction
Maximum delay as from moment of

receipt to advise the reject to Sender
Charges due to the reject

MT 102
Cancellations
Unless otherwise agreed, messages properly received and accepted are to be considered as irrevocable.
Cancellation therefore should be the exception.
If however cancellations are accepted in the bilateral agreement, the following details should be agreed:
BIC of Bank1 BIC of Bank2
Acceptable delay for the Sender to

request cancellation of message
Acceptable delay for acceptance

and response by the Receiver to
such request
Charges due to the Receiver of such

request
Financial institutions are proposed to send their request for cancellation by MT 192, for response by MT 196.
The possible interbank costs of the failure are supported by the Sender.
Modifications and Changes

Unless otherwise agreed, financial institutions will use the most up-to-date version of the MT 102 for the
transmission of their transactions.
Unless otherwise agreed, financial institutions will implement changes in the message specifications of the
MT 102 according to the implementation dates as announced by SWIFT
A Sender who has not done the necessary modifications in time may not be able to correctly format the
transactions concerned. In this case, the Receiver is not obliged to execute the transactions. Financial
institutions should agree who is liable for any costs arising from the non-execution of these transactions.
Unless otherwise agreed, the costs are to be supported by the Sender.
A Receiver who has not done the necessary modifications in time may not be able to process the transactions.
The Receiver will remain responsible for executing the transactions. Financial institutions should agree who is
liable for any costs arising from the non-execution of these transactions. Unless otherwise agreed, the costs are
to be supported by the Receiver.
31 August 2007 93
MT 102+ Multiple Customer Credit Transfer
The MT 102+ allows the exchange of multiple customer credit transfers using a restricted set of fields and
format options of the core MT 102 to make it straight through processable. The MT 102+ is a compatible
subset of the core MT 102 that is documented separately in this section.
The differences with the core MT 102 are:
• appropriate MT 102+ 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 and 57 may only be used with letter option A
• field 51A is not used in MT 102+. This message may only be used on the FIN SWIFT network since it
requires special validation
• field 23 may only contain codes CREDIT and SPAY
• subfield 1 (Account) of either field 59 or 59A is always mandatory
• field 72, code INS must be followed by a valid BIC
• field 72, codes REJT/RETN must not be used
• field 72 must not include ERI information.
IMPORTANT
To trigger the MT 102+ format validation, the user header of the message (block 3) is mandatory and
must contain the code STP in the validation flag field 119 ({3:{119:STP}}).
MT 102+ Scope
This message is sent by or on behalf of the financial institution of the ordering customer(s) to another financial
institution for payment to the beneficiary customer(s).
It requests the Receiver to credit the beneficiary customer(s) directly or indirectly through a clearing
mechanism or another financial institution.
This message is used to convey multiple payment instructions between financial institutions for clean
payments. Its use is subject to bilateral/multilateral agreements between Sender and Receiver.
Amongst other things, these bilateral agreements cover the transaction amount limits, the currencies accepted
and their settlement. The multiple payments checklist included below is recommended as a guide for
institutions in the setup of their agreements.
MT 102+ Format Specifications

The MT 102+ consists of three sequences:
• Sequence A General Information is a single occurrence sequence and contains information which applies
to all individual transactions described in sequence B.
• Sequence B Transaction Details is a repetitive sequence. Each occurrence is used to provide details of one
individual transaction.
• Sequence C Settlement Details is a single occurrence sequence and contains information about the
settlement.

MT 102+
MT 102+ Multiple Customer Credit Transfer

M 20 File Reference 16x 1
M 23 Bank Operation Code 16x 2
O 52A Ordering Institution [/1!a][/34x] 4

4!a2!a2!c[3!c]
M 32B Transaction Amount 3!a15d 10

4!a2!a2!c[3!c]
O 57A Account With Institution [/1!a][/34x] 13

4!a2!a2!c[3!c]
----->
-----|
M 32A Value Date, Currency Code, Amount 6!n3!a15d 23
31 August 2007 95
----->
-----|
O 53a Sender's Correspondent A or C 27

4!a2!a2!c[3!c]
MT 102+ Network Validated Rules

C1 If field 19 is present in sequence C, it must equal the sum of the amounts in all occurrences of field 32B
C2 The currency code in the fields 71G, 32B and 32A must be the same for all occurrences of these fields
in the message (Error code(s): C02).
C3 Field 50a must be present either in sequence A or in each occurrence of sequence B, but it must never
If 50a in sequence A is … then 50a in each sequence B is …
Present Not allowed
C4 Field 71A must be present either in sequence A or in each occurrence of sequence B, but it must never

Present Not allowed
C5 If a field 52A, 26T or 77B is present in sequence A, that field must not be present in any occurrence of
sequence B. When a field 52A, 26T or 77B is present in any occurrence of sequence B, that field must
not be present in sequence A (Error code(s): D18).

MT 102+

Present Not allowed

Present Not allowed

Present Not allowed
C6 Field 36 (sequence A or sequence B) must be present in the message if there is any sequence B which
contains a field 33B with a currency code different from the currency code in field 32B; in all other
cases field 36 is not allowed in the message.
When a field 36 (sequence A or sequence B) is required, EITHER field 36 must be present in sequence
A and not in any sequence B, OR it must be present in every sequence B which contains fields 32B and
33B with different currency codes and must not be present in sequence A or any other sequence B
If field 36 is present Then in minimum one And field 36 is not allowed in

occurrence of Seq. B field 33B any occurrence of Seq. B
must be present and currency
codes in fields 32B and 33B must
be different
And currency codes in

If field 36 is … If field 33B is … fields 32B and 33B are Then field 36 is …
…
Not present Present Equal Not allowed
Not equal Mandatory
31 August 2007 97
mandatory in each occurrence of sequence B, otherwise field 33B is optional (Error code(s): D49).
If country code of Sender's and country code of Receiver's In each occurrence of sequence
BIC equals one of the listed BIC equals one of the listed B
country codes country codes then field 33B is …
Yes Yes Mandatory
Yes No Optional
No Yes Optional
No No Optional
Note:See Rule C9
C8 If field 71A in sequence A contains OUR, then field 71F is not allowed and field 71G is optional in any
occurrence of sequence B (Error code(s): E13).

In sequence A
if field 71A is …
If field 71A in sequence B contains OUR, then field 71F is not allowed and field 71G is optional in the
same occurrence of sequence B (Error code(s): E13).

In sequence B
if field 71A is …

If field 71A in sequence A contains SHA, then fields 71F are optional and field 71G is not allowed in
any occurrence of sequence B (Error code(s): D50).

In sequence A
if field 71A is …
If field 71A in sequence B contains SHA, then fields 71F are optional and field 71G is not allowed in
the same occurrence of sequence B (Error code(s): D50).

In sequence B
if field 71A is …

MT 102+
If field 71A in sequence A contains BEN, then at least one occurrence of field 71F is mandatory in each
occurrence of sequence B and field 71G is not allowed (Error code(s): E15).

In sequence A
if field 71A is …
If field 71A in sequence B contains BEN, then at least one occurrence of field 71F is mandatory in the
same occurrence of sequence B and field 71G is not allowed (Error code(s): E15).

In sequence B
if field 71A is …

C9 If either field 71F (at least one occurrence) or field 71G are present in an occurrence of sequence B,
then field 33B is mandatory in the same occurrence of sequence B (Error code(s): D51).
If field 71F is … and field 71G is … then field 33B is …
Present Present Rejected (1)
Present Not present Mandatory
Not present Present Mandatory
Not present Not present Optional
(1) both fields 71F and 71G present is not a valid combination, see rule C8.
C10 If field 71G is present in an occurrence of sequence B, then field 71G is mandatory in the sequence C
If in any occurrence of sequence B in sequence C

field 71G is … then field 71G is …
Present Mandatory
C11 If the country codes of the Sender's and the Receiver's BIC are within the following list: AD, AT, BE,
MC, MQ, MT, NL, NO, PL, PM, PT, RE, RO, SE, SI, SJ, SK, SM, TF and VA, then in each occurrence
of sequence B the following apply:
• If field 57A is not present, the IBAN (ISO-13616) is mandatory in subfield Account of field 59a in
that occurrence of Seq. B (Error code(s): D19).
• If field 57A is present and the country code of the BIC in 57A is within the above list of country
codes, the IBAN (ISO-13616) is mandatory in subfield Account of field 59a in that occurrence of
Seq. B (Error code(s): D19).
31 August 2007 99
In all other cases, the presence of the IBAN (ISO-13616) is optional and its format is not validated in
subfield Account of field 59a.
In header of MT In each occurrence of sequence B
If country code and country code and country code Then an IBAN in
of Sender's BIC of Receiver's BIC of field 57A subfield Account
and field 57A is
equals one of the equals one of the equals one of the of field 59a in this
present
listed country listed country listed country occurrence of
codes codes codes Seq. B is …
Yes Yes No Not applicable Mandatory
Yes No No Not applicable Optional
No Yes No Not applicable Optional
No No No Not applicable Optional
Yes Yes Yes Yes Mandatory
Yes No Yes Yes Optional
No Yes Yes Yes Optional
No No Yes Yes Optional
Yes Yes Yes No Optional
Yes No Yes No Optional
No Yes Yes No Optional
No No Yes No Optional
MT 102+ Usage Rules

• If a registered user receives an MT 102+ without bilateral agreement with the Sender, the Receiver should
query the message according to normal banking practice.

There is a relationship between the amount related fields 33B, 32B, 36, 71G, 71F, 19 and 32A which may be
logically expressed in the following formulas:
• For each occurrence of sequence B, the instructed amount in field 33B, adjusted with the exchange rate in
field 36, minus the Sender's charges in field(s) 71F, equals the transaction amount in field 32B.
• The sum of all transaction amounts in fields 32B, equals the total amount in field 19.
• The sum of all Receiver's charges in fields 71G of sequence B, equals the total Receiver's charges of field
71G in sequence C.
• The total amount in field 19 (or the sum of all transaction amounts in fields 32B), plus the total Receiver's
charges in field 71G of sequence C, equals the interbank settled amount in field 32A.
Presence of the fields mentioned above is subject to the conditional field rules C5, C6, C7, C8, C9 and C10. 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.

MT 102+
Sequence B
Sequence A
if field 71A is …
then field 32B is … field 71F is … and field 71G is …
OUR Net amount to be credited Not allowed Optional

to the Beneficiary.
Charges have been
prepaid by the ordering
customer.
SHA Amount as instructed by Optional Not allowed

the originator, eg, invoice
amount.
own charges.
BEN Amount instructed by the At least one occurrence Not allowed

originator, after sending mandatory
bank has deducted its
charges.
charges.
Sequence C
Sequence A
if field 71A is …
then field 19 is … field 32A is … and field 71G is …
OUR Sum of field(s) 32B of Settlement Amount Sum of fields 71G of

sequence B equals field 19 plus field sequences B
71G of sequence C
SHA Not used Settlement Amount Not allowed

32B of sequence B
BEN Not used Settlement Amount Not allowed

32B of sequence B
MT 102+ Field Specifications

1. Field 20: File Reference
FORMAT
16x
PRESENCE
DEFINITION
31 August 2007 101


T26).
USAGE RULES
This reference must be quoted in any related confirmation or statement, eg, MT 900 Confirmation of Debit
and/or 950 Statement Message.
The file reference must be unique for each file and is part of the file identification and transaction
identification which is used in case of queries, cancellations etc.
2. Field 23: Bank Operation Code

FORMAT
16x
To be formatted as:
6a
PRESENCE
DEFINITION
CODES
CREDIT This message contains credit transfer(s) to be processed according to the pre-established bilateral
agreement between the Sender and the Receiver.
CRTST This message contains credit transfers for test purpose(s).
SPAY This message contains credit transfer(s) to be processed according to the SWIFTPay Service Level.
USAGE RULES
As tests in FIN should be done in Test & Training, the code CRTST is only valid when sent by a Test &
Training destination.

FORMAT

Party Identifier)

MT 102+

Name & Address)
Or
Party Identifier)
Name & Address)
PRESENCE
DEFINITION
This field identifies the customer ordering all transactions described in sequence B.
CODES
Number.
CODES
31 August 2007 103

name(s)).
building name).
Number.

T28, T29, T45).
USAGE RULES
issue.
EXAMPLE
:50F:/12345678
1/SMITH JOHN

MT 102+
2/299, PARK AVENUE

:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
1/DUPONT JACQUES
3/BE/BRUSSELS
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
123456789/8-1234567890.
4. Field 52A: Ordering Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the financial institution, when different from the Sender, which instructed the Sender to
transmit all transactions described in sequence B. This is applicable even if field(s) 50a contain(s) an IBAN.
CODES
Party Identifier may be used to indicate a national clearing system code.

31 August 2007 105



T29, T45).
USAGE RULES
The coded information contained in field 52A must be meaningful to the Receiver of the message.

FORMAT
Option T 3!c
PRESENCE
DEFINITION
This field identifies the nature of, purpose of and/or reason for all transactions described in sequence B, eg,
salaries, pensions or dividends.
CODES
field.
USAGE RULES
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.

FORMAT


MT 102+
PRESENCE
DEFINITION
country of the Receiver or Sender.
CODES
When the residence of either ordering customer or beneficiary customer is to be identified, the following codes
must be used, placed between slashes ('/'):

USAGE RULES
customer.
The information specified must not have been explicitly conveyed in another field and is valid for all
transactions described in sequence B.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges for all transactions described in sequence B.
CODES

SHA Transaction charges on the Sender's side are to be borne by the ordering customer and transaction
charges on the Receiver's side are to be borne by the beneficiary customer.

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert all instructed amounts specified in field 33B in sequence
B.
31 August 2007 107


USAGE RULES
This field must be present, when a currency conversion has been performed on the Sender's side.

FORMAT
16x
PRESENCE
DEFINITION
T26).
USAGE RULES
In transaction related queries, cancellations etc., the content of field 20 File Reference together with the
content of this field provides the transaction identification.
10. Field 32B: Transaction Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the individual transaction amount remitted by the Sender to the Receiver.
USAGE RULES
This amount will, taking into account the charging option, be the basis for the Receiver to calculate the amount
to be credited to the beneficiary.
Depending on the charging option specified in field 71A, the content of field 32B is as follows:
• If field 71A is OUR, the net amount to be credited to the beneficiary, as charges have been prepaid by the
ordering customer.
• If field 71A is SHA, the amount as instructed by the originator, eg, invoice amount, of which the Receiver
will deduct its own charges.

MT 102+
• If field 71A is BEN, the amount as instructed by the originator minus the Senders' charges, and from which
amount the Receiver will deduct its charges.

FORMAT

Party Identifier)
Name & Address)
Or

Party Identifier)
Name & Address)
PRESENCE
DEFINITION
This field identifies the customer ordering the transaction in this occurrence of the sequence.
CODES
Number.
31 August 2007 109

CODES
name(s)).
building name).
Number.

T28, T29, T45).
USAGE RULES
issue.

MT 102+

EXAMPLE
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
1/DUPONT JACQUES
3/BE/BRUSSELS
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
123456789/8-1234567890.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the financial institution, when other than the Sender, which instructed the Sender to
transmit the transaction. This is applicable even if field 50a contains an IBAN.
31 August 2007 111

CODES


T29, T45).
USAGE RULES
13. Field 57A: Account With Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the financial institution which services the account for the beneficiary customer identified
in the same sequence. This is applicable even if field 59 or 59A contains an IBAN.
CODES

MT 102+


T29, T45).
USAGE RULES
banks require that the code //FW appears in the optional Party Identifier of field 57A.
of field 57A.
The code //RT is binding for the Receiver. It must not be followed by any other information.

FORMAT
PRESENCE
DEFINITION
This field specifies the customer to which the transaction amount should be transmitted.
31 August 2007 113


Account must be present (Error code(s): E10).
T28, T29, T45).
If an IBAN must be present in Account (C11), the IBAN must be a valid IBAN (ISO-13616) (Error code(s):
D19, T73).
USAGE RULES
At least the name or the BEI of the beneficiary customer is mandatory.

FORMAT
4*35x (Narrative)
PRESENCE
DEFINITION
This field specifies details of the individual transaction which are to be transmitted to the beneficiary
customer.
CODES
characters).
USAGE RULES
This field must not contain information to be acted upon by the Receiver.
Due to national clearing restrictions, which vary significantly from country to country, the Sender must agree
to the maximum usable length of this field with the Receiver.
EXAMPLE
:70:/RFB/12345

FORMAT
Option T 3!c
PRESENCE

MT 102+
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the individual transaction, eg, salary, pension
or dividend.
CODES
field.
USAGE RULES

FORMAT

PRESENCE
DEFINITION
This field specifies the codes for the statutory and/or regulatory information required by the authorities in the
country of the Receiver or the Sender.
CODES

USAGE RULES
customer.

FORMAT
PRESENCE
31 August 2007 115

DEFINITION
USAGE RULES
side.
place, field 32A equals 33B, if present.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges for the transaction in the same occurrence of sequence B.
CODES
BEN The transaction charges are to be borne by the beneficiary customer.

OUR The transaction charges are to be borne by the ordering customer.
SHA The transaction charges on the Sender's side are to be borne by the ordering customer and the
transaction charges on the Receiver's side are to be borne by the beneficiary customer.

FORMAT
PRESENCE
DEFINITION

MT 102+

USAGE RULES
The net amount after deduction of the Sender's charges will be quoted as the transaction amount in field 32B.

FORMAT
PRESENCE
DEFINITION
USAGE RULES
The Receiver's charges are to be conveyed to the Receiver, not for transparency but for accounting reasons, ie,
to facilitate bookkeeping and to calculate or verify the total Receiver's charges amount stipulated in Sequence
C.

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert the instructed amount specified in field 33B in the same
31 August 2007 117

USAGE RULES
This field must be present when a currency conversion has been performed on the Sender's side.
23. Field 32A: Value Date, Currency Code, Amount

FORMAT
PRESENCE
DEFINITION
USAGE RULES
Where field 71A indicates OUR payments, this field contains the sum of the amounts specified in the fields 19
and 71G.
Where field 71A indicates SHA or BEN payments, this field contains the total of all fields 32B.

FORMAT
17d (Amount)
PRESENCE
DEFINITION
This field specifies the sum of all amounts appearing in field 32B in each occurrence of sequence B.
allowed for the currency specified in field 32A (Error code(s): C03, T40, T43).
USAGE RULES
This field is only to be used where the sum of amounts is different from the settlement amount specified in
field 32A, ie, when one or more transactions in sequence B contains the charging option OUR in field 71A.

FORMAT

MT 102+
PRESENCE
DEFINITION
This field specifies the currency and accumulated amount of the transaction charges due to the Receiver.
If field 71G is present in sequence C, the amount in field 71G must not equal '0' (Error code(s): D57).
USAGE RULES
Where field 71A indicates OUR payments either in sequence A, or in one or more occurrences of sequence B,
this field identifies the sum of the charges due, which has been prepaid and included in the interbank
settlement amount.
For transparency or accounting reasons, this field is not to be used when field 71A, either in sequence A or in
all occurrences of sequence B, indicates BEN or SHA payments.

FORMAT
PRESENCE
DEFINITION
instruction.
CODES

Time offset is expressed as 'HHMM', where the hour component, ie, 'HH', must be in the range of 00 through
13, and the minute component, ie, 'MM' must be in the range of 00 through 59. Any 'HH' or 'MM' component
31 August 2007 119

USAGE RULES
The time zone in which date and Time are expressed is to be identified by means of the offset against the UTC
EXAMPLE
Explanation:
• +0100 is the offset of CET against UTC in January (ie during winter time).

FORMAT
4!a2!a2!c[3!c] (BIC)
Option C /34x (Account)
PRESENCE
DEFINITION
T29, T45).
USAGE RULES
Absence of this field implies that the bilaterally agreed account is to be used for settlement.
Option C must be used where only an account number is to be specified.
credited or debited must be indicated in field 53a.
Receiver (or branch of the Receiver when specified in field 54A), then field 53A must be present.

MT 102+
When field 53A is present and contains a branch of the Sender, the need for a cover message is dependent on
54A, if present.
A branch of the Receiver may appear in field 53A if the financial institution providing reimbursement is both
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, ie, MT 202/203 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 transaction and
the correspondent relationship between the Sender and the Receiver relative to that currency.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
Where required, this field specifies the branch of the Receiver or another financial institution at which the
funds will be made available to the Receiver.
T29, T45).
USAGE RULES
The absence of fields 53a and 54A implies that the single direct account relationship between the Sender and
the Receiver, in the currency of the transfer, will be used.
In those cases where field 54A contains a branch of the Receiver, and is not preceded by field 53a, or field 53a
from its branch.
If field 54A contains a branch of the Receiver and field 53A contains a branch of the Sender, the Receiver will
field 54A.
If the branch of the Sender or other financial institution specified in field 53A is also the account servicer for
field 53A; the Receiver will be paid by the financial institution in field 54A.
31 August 2007 121


FORMAT

or
PRESENCE
DEFINITION
This field specifies additional information for the Receiver.
CODES
Unless bilaterally agreed otherwise between the Sender and the Receiver, the following code may be used,
placed between slashes ('/'):
INS The instructing institution which instructed the Sender to execute the transaction.

If the code /INS/ is used at the beginning of a line, it must be followed by a valid BIC and be the only
information about that line (Error code(s): T27, T28, T29, T44, T45, T46).
If the code /INS/ is present at the beginning of a line, it must not be used again at the beginning of any other
line (Error code(s): T47).
If the code /INS/ is used anywhere else than at the beginning of a line, it is treated as free text and is ignored as
far as validation is concerned. In this case, there is no validation of the following BIC either.
The codes /REJT/ or /RETN/ must not be used in this field (Error code(s): T81).
This field must not include ERI (Error code(s): T82).
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 information.
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 double
slash '//', and, if used, must begin on a new line. Narrative text should preferably be the last information 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.

MT 102+
MT 102+ Examples
Narrative
Consortia Pension Scheme, a corporate in Zürich requests its bank (BNKACHZZ) to execute a bulk of
payments. The bulk contains pension payments in Swiss Francs. The beneficiaries have their account with the
Belgian correspondent of BNKACHZZ.
BNKACHZZ established a bilateral agreement with its Belgian correspondent (BNKBBEBB) to exchange
MT 102s for low value transactions. Both banks agreed on a number of details, some of which are highlighted
for the purpose of this message:
• transaction charges due to BNKBBEBB for the guarantee and processing of on us payments up to the
posting to the beneficiary's account, are EUR 5, per transaction
• charges information is explicitly included in the message for control purposes
• charges are settled with the same value date as the sum of transaction amounts
• conversion, if necessary, is performed at the Sender's side. Consequently, transactions are always sent in
the currency of the receiving country
• the same exchange rate is applied for all transactions within a same message.
Information Flow

Zurich
50a
Sender BNKACHZZ
MT
(MT 950)
MT 102+
Receiver BNKBBEBB
Beneficiary Customers 59a 59a

Johann Willems Joan Mills
D0010067
Brussels Brussels
31 August 2007 123

SWIFT Message
Explanation Format
Sender BNKACHZZ
Message type 102+
Receiver BNKBBEBB
File reference :20:5362/MPB
Bank operation code :23:CREDIT

8022-ZURICH
Beneficiary customer :59:/BE68001161685134

JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS

JOAN MILLS
AVENUE LOUISE 213
1050 BRUSSELS
Settlement details
Value date, currency code, amount :32A:090828EUR3135,

MT 102+
Explanation Format
Sum of amounts :19:3125,
Sum of Receiver's charges/amount :71G:EUR10,
in field 32A and the file 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:
SWIFT Message
Explanation Format
Sender BNKBBEBB
Message type 950
Receiver BNKACHZZ
Message text
Statement line :61:090828D3135,S1025362/MPB//1234T
Closing balance :62F:C090828EUR68865,
MT 102+ Checklist
This document provides a checklist which is strongly recommended to be used by financial institutions as a
basis for setting up bilateral or multilateral agreements for the processing of crossborder customer payments,
ie, Credit Transfers transmitted by MT 102+ via FIN.
facilitate the set up of these agreements, common procedures have been defined which financial institutions, if
they wish, may override.
for it.
Currencies Accepted, their Transaction Amount Limit and Settlement

Currencies Accepted
Unless otherwise agreed, multiple payment transactions are either expressed in the currency of the sending or
the receiving country. If financial institutions wish to accept third currencies this should be bilaterally agreed.
Transaction Amount Limit
31 August 2007 125

If financial institutions agree to define amount limits to the individual transactions, they should specify them
per currency.
If the agreement allows for transactions above amounts to which specific requirements apply, eg, regulatory
reporting requirements, these requirements and their formatting should be specified as well in the agreement.
Settlement
Unless otherwise agreed, direct account relationship between the Sender and the Receiver will be used for the
booking of the transactions exchanged. However if they wish, financial institutions may also bilaterally agree
to include third reimbursement parties in the settlement.
Whatever the agreement, transactions contained in a same message will be booked in one single entry.
For each currency accepted, the amount limit, the account number(s) used for settlement, if other than the
normal one(s), and/or the third reimbursement party(ies) involved, if any, can be indicated in the chart below:
Transaction amount Third reimbursement

Currencies accepted Settlement account
limit institutions(s) if any
Charges
Unless otherwise agreed, financial institutions will accept the charging options as defined and allowed for in
the MT 102+. If financial institutions wish to accept only one option, this should be bilaterally agreed.
Financial institutions which accept the OUR option should agree on and specify the transaction charges in the
receiving country for 'on us' and if applicable 'not on us' payments.
These transaction charges can be an exact amount or formula (percentage) and cover the guarantee and
processing of transactions which the Receiver provides to the Sender until the execution in the receiving
country up to the posting to the beneficiary's account. The pricing of bank-customer services, eg, for the
method of advice - for daily/weekly/monthly statement for instance, being different from institution to
institution are considered not to be part of the charges.
Charges per message: Charges per

Type of payment: on
Charges due to: formula or exact transaction: formula or
us/not on us
amount exact amount
The above charges are preferably set for each trimester, if necessary semester. Changes to these charges should
be announced one month before the end of the term.
The messages sent as from that implementation date, will be subject to the new tariffs of the Receiver.
Charges Specifications in the MT 102+
Unless otherwise agreed, the pre-agreed charges will be included in the MT 102+s exchanged, as appropriate,
for information and control purposes and this in a consistent manner.
Unless otherwise agreed, charges will always be expressed in the same currency as the transaction amount(s)
and settlement amount of the message.

MT 102+
In case the charges amounts, due to the above rule, are quoted in a currency different to the one specified in the
bilateral agreement, the exchange rate should be quoted in the message exchanged.
Settlement Procedure for Charges
Unless otherwise agreed, financial institutions will separately indicate in the MT 102+ the sum of charges due
to the Sender and/or to the Receiver, as appropriate.
The amount settled between financial institutions with the value date specified includes at a minimum the sum
of all transaction amounts. Whether the sum of charges due to the Sender and/or Receiver will also be included
in the settlement amount, will depend on the agreed settlement procedure for charges. Regarding this
procedure, financial institutions can agree that:

all transaction amounts and booked together

all transaction amounts but booked separately
Charges are settled periodically (once …)
Other
Only when using the first or second option, the settlement amount will include the sum of charges.
Data Transmission and Bulking Criteria

Unless otherwise agreed, credit transfer transactions contained in the same MT 102+ should be grouped as
follows:
• operations with same bank operation code
• operations in same currency
• operations with same settlement account/institution
• operations with same value date
Financial institutions should agree whether only head office or also branches can be the Sender and/or
Receiver of the MT 102+:
BIC Bank1 BIC Bank2
Only head-office
Head office and all domestic

branches
Head office and a limited number of

domestic branches as listed: only
list location code and branch code
Date and Time Frames

Financial institutions should agree on the timeframe needed by the Receiver to execute the payments accepted
in its country. This timeframe starts counting as of an agreed cut-off time for receipt of incoming messages by
the Receiver.
31 August 2007 127

Messages received before cut-off time, will be settled on a pre-agreed day which is a (number of) day(s)
following the day of receipt (day of receipt = D). For messages received after cut-off time, the settlement
timeframe will be based on D+1.
D will also be the basis for calculating the execution dates (dates when the funds are available to the
Beneficiary).
Date of receipt/acceptance = D
Settlement timeframe D (+) D (+)
Execution timeframe for on/us D (+) D (+)

account of the Beneficiary)
Execution timeframe for not on/us D (+) D (+)


Message Level
Unless otherwise agreed, financial institutions will take as a basis for their controls/checks all security aspects
of FIN as defined in the SWIFT FIN User Handbook as well as the MT 102+ message syntax and semantics as
defined in the MT 102+ message specifications.
In order to achieve straight-through processing of the MT 102+s exchanged, financial institutions should
define checks and controls relating to the bilaterally agreed items.
Unless otherwise agreed, messages passing the checks and controls, are considered accepted and therefore
irrevocable, ie, to be posted to the nostro/loro account.
If messages do not pass the checks/controls, they will be rejected (see the next checkpoint).
Proposed checks and controls, relating to the bilaterally agreed items, performed by the Receiver and their
error codes:
Settlement amount
Value date
Sender
Currencies present
Bulking criteria used
Information present in field 72
Bank operation code
Other
Transaction Level

MT 102+
Once the message is accepted, further checks are proposed to take place at transaction level. Only if
transaction(s) pass the checks, will they be executed. If not, they will be rejected (see the next checkpoint).
Proposed checks and controls performed by the Receiver including error codes prior to the execution of the
transactions:
Account number of beneficiary
Transaction amount
Beneficiary bank identification
Length of remittance data
Other
Rejects of Messages and/or Transactions

Message Rejects:
For rejects due to a communication failure between the Sender and the Receiver, the existing FIN rules apply.
Unless otherwise agreed, messages properly received but failing to pass the message level checks (as defined
in the previous checkpoint) will be rejected by the Receiver without further processing. Financial institutions
are recommended to use the MT 195 to advise the rejection. The reject advice should contain at a minimum
the reference of the rejected message and the error code(s). The maximum delay acceptable for the Receiver to
notify the Sender and possible related charges should be bilaterally agreed.
Unless otherwise agreed, the notification returned to the Sender will exempt the Receiver from processing the
message. The Sender will, after correction, resubmit the message.
Transaction Rejects:
The return to the originator of transactions being rejected after the message which contained them has been
posted to a nostro/loro account (between the Sender and the Receiver), will cause a settlement. Unless
• the original transaction amount should remain unchanged
• the settlement should take place via the same account relationship
Financial institutions should agree on a maximum of working days after receipt of the MT 102 for rejecting a
transaction and on the charges applied.
The following chart provides details regarding the message/transaction rejects:
Reject of message Reject of transaction
Maximum delay as from moment of

receipt to advise the reject to Sender
Charges due to the reject
31 August 2007 129

Cancellations
Unless otherwise agreed, messages properly received and accepted are to be considered as irrevocable.
Cancellation therefore should be the exception.
If however cancellations are accepted in the bilateral agreement, the following details should be agreed:
BIC of Bank1 BIC of Bank2
Acceptable delay for the Sender to

request cancellation of message
Acceptable delay for acceptance

and response by the Receiver to
such request
Charges due to the Receiver of such

request
Financial institutions are proposed to send their request for cancellation by MT 192, for response by MT 196.
The possible interbank costs of the failure are supported by the Sender.
Modifications and Changes

Unless otherwise agreed, financial institutions will use the most up-to-date version of the MT 102+ for the
transmission of their transactions.
Unless otherwise agreed, financial institutions will implement changes in the message specifications of the
MT 102+ according to the implementation dates as announced by SWIFT
A Sender who has not done the necessary modifications in time may not be able to correctly format the
transactions concerned. In this case, the Receiver is not obliged to execute the transactions. Financial
institutions should agree who is liable for any costs arising from the non-execution of these transactions.
Unless otherwise agreed, the costs are to be supported by the Sender.
A Receiver who has not done the necessary modifications in time may not be able to process the transactions.
The Receiver will remain responsible for executing the transactions. Financial institutions should agree who is
liable for any costs arising from the non-execution of these transactions. Unless otherwise agreed, the costs are
to be supported by the Receiver.

MT 103
MT 103 Single Customer Credit Transfer
The MT 103 message can be exchanged in three different ways, depending on the business scenario in which
the message is used.
1. The core MT 103 is a General Use message, ie, no registration in a Message User Group (MUG) is
necessary to send and receive this message. It allows the exchange of single customer credit transfers using
all MT 103 fields, except field 77T (Envelope Contents). The MT 103 can be straight through processable
if the message is properly formatted according to pre-agreed bilateral/multilateral rules.
2. The MT 103 + is a General Use message, ie, no registration in a Message User Group is necessary to send
and receive this message. It allows the exchange of single customer credit transfers using a network
validated restricted set of fields and format options of the MT 103 to make it straight through processable.
The MT 103 + is a compatible subset of the core MT 103 and is documented separately after the MT103.
3. The MT 103 Extended Remittance Information MUG allows its subscribers to exchange MT 103 messages
with field 77T containing an extended amount of remittance information. This remittance information may
optionally be exchanged in a non-SWIFT format, such as EDIFACT or ANSI-X12.
Senders and Receivers who wish to use the MT 103 for the exchange of extended remittance data (up to
9,000 characters) will have to register for the Extended Remittance Information MUG.
All three ways of exchanging the MT103 message are available for worldwide use. To allow European
financial institutions to respect European regulations, additional network validation has been introduced when
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, ES, EE, 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.
Additional network validation for Europe:
• In the MT 103:
1. A mandatory presence of field 33B Currency/Instructed Amount.
• In the MT 103+:
1. A mandatory presence of field 33B Currency/Instructed Amount.
2. A mandatory IBAN account number in subfield 1 (Account) of field 59a Beneficiary Customer when
the Sender's and Receiver's BIC (and the BIC in field 57A if present) are within that same list of
country codes above.
When not subject to this additional network validation, a valid account number in the proper format can be
STP.
MT 103 Scope
This message type is sent by or on behalf of the financial institution of the ordering customer, directly or
through (a) correspondent(s), to the financial institution of the beneficiary customer.
It is used to convey a funds transfer instruction in which the ordering customer or the beneficiary customer, or
both, are non-financial institutions from the perspective of the Sender.
This message may only be used for clean payment instructions. It must not be used to advise the remitting
bank of a payment for a clean, eg, cheque, collection, nor to provide the cover for a transaction whose
completion was advised separately, eg, via an MT 400.
31 August 2007 131


----->
-----|
M 23B Bank Operation Code 4!c 3
----->
-----|
M 32A Value Date/Currency/Interbank Settled Amount 6!n3!a15d 6
M 50a Ordering Customer A, F, or K 9

4!a2!a2!c[3!c]
O 53a Sender's Correspondent A, B, or D 12
O 54a Receiver's Correspondent A, B, or D 13
O 55a Third Reimbursement Institution A, B, or D 14
O 56a Intermediary Institution A, C, or D 15
O 57a Account With Institution A, B, C, or D 16
----->
-----|

MT 103
O 77T Envelope Contents 9000z 24

C1 If field 33B is present and the currency code is different from the currency code in field 32A, field 36
must be present, otherwise field 36 is not allowed (Error code(s): D75).
and currency code in field 33B

If field 33B is … then field 36 is …
…
Present NOT equals currency code in Mandatory

field 32A
equals currency code in field 32A Not allowed
BG, BV, CH, CY, CZ, DE, DK, ES, EE, FI, FR, GB, GF, GI, GP, GR, HU, IE, IS, IT, LI, LT, LU, LV,
mandatory, otherwise field 33B is optional (Error code(s): D49).

BIC equals one of the listed BIC equals one of the listed then field 33B is …
Yes Yes Mandatory
Yes No Optional
No Yes Optional
No No Optional
Note:See also Network Validated Rule C16 (Error code(s): D51).

C3 If field 23B contains the code SPRI, field 23E may contain only the codes SDVA, TELB, PHOB, INTC
(Error code(s): E01).
If field 23B contains one of the codes SSTD or SPAY, field 23E must not be used (Error code(s): E02).
If field 23B is … then field 23E is …
SPRI Optional. It can contain only SDVA, TELB, PHOB

or INTC
SSTD Not allowed
SPAY Not allowed
Not equals SPRI, SSTD and SPAY Optional
31 August 2007 133

C4 If field 23B contains one of the codes SPRI, SSTD or SPAY, field 53a must not be used with option D
If field 23B is … then field 53a …
SPRI, SSTD or SPAY Must not be used with option D
C5 If field 23B contains one of the codes SPRI, SSTD or SPAY and field 53a is present with option B,
Party Identifier must be present in field 53B (Error code(s): E04).
C6 If field 23B contains one of the codes SPRI, SSTD or SPAY, field 54a may be used with option A only
SPRI, SSTD or SPAY May be used with option A only
C7 If field 55a is present, then 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 …
Present Mandatory Mandatory
Not present Optional Optional
C8 If field 23B contains one of the codes SPRI, SSTD or SPAY, field 55a may be used with option A only
SPRI, SSTD or SPAY May be used with option A only
C9 If field 56a is present, field 57a must also be present (Error code(s): C81).
If field 56a is … then field 57a is …
Present Mandatory
C10 If field 23B contains the code SPRI, field 56a must not be present (Error code(s): E16).
If field 23B contains one of the codes SSTD or SPAY, field 56a may be used with either option A or
option C. If option C is used, it must contain a clearing code (Error code(s): E17).
If field 23B is … then field 56a is …
SPRI Not allowed
SSTD or SPAY Allowed with option A or C only (if option C:

clearing code must be used)
C11 If field 23B contains one of the codes SPRI, SSTD or SPAY, field 57a may be used with option A,
option C or option D. Subfield 1 (Party Identifier) in option D must be present (Error code(s): E09).

MT 103
If field 23B is … then field 57a is …
SPRI, SSTD or SPAY Allowed only with options A, C or D (In option D:

Party Identifier is mandatory)
C12 If field 23B contains one of the codes SPRI, SSTD or SPAY, subfield 1 (Account) in field 59a
Beneficiary Customer is mandatory (Error code(s): E10).
C13 If any field 23E contains the code CHQB, subfield 1 (Account) in field 59a Beneficiary Customer is not
allowed (Error code(s): E18).
C14 Fields 70 and 77T are mutually exclusive (Error code(s): E12). Thus, the following combinations are
allowed:
Field 70 is … Field 77T is …
Present Not present
Not present Present
Not present Not present
C15 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(s) 71F is(are) … and field 71G is …
If field 71A contains BEN, then at least one occurrence of field 71F is mandatory and field 71G is not
BEN Mandatory (at least one Not allowed

occurrence)
C16 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 C15
(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).
C17 If field 56a is not present, no field 23E may contain TELI or PHOI (Error code(s): E44).
31 August 2007 135

then no occurrence of
If field 56a is … field 23E
subfield 1 may contain …
Not present TELI or PHOI
C18 If field 57a is not present, no field 23E may contain TELE or PHON (Error code(s): E45).
then no occurrence of
If field 57a is … field 23E
subfield 1 may contain …
Not present TELE or PHON
C19 The currency code in the fields 71G and 32A must be the same (Error code(s): C02).
MT 103 Usage Rules

• Field 77T can only be used if both Sender and Receiver of the message have subscribed to the Extended
Remittance Information MUG. Both the Sender and the Receiver must have agreed to the exchange of
MT 103 messages using field 77T. If the field is used, the Sender must set the validation flag to REMIT in
field 119 of the user header of the message. If field 77T is not present, the code of the validation flag must
not be REMIT.
• Field 72 may only be present when it is structured, ie, only contains coded information.
• When sending the message via FileAct, institutions must use the 'payments related' content type 1020 (see
FileAct User Handbook) which requires authentication and acknowledgement that the message will be
processed and submitted for execution. Institutions should bilaterally agree on the maximum size of the
message.

There is a relationship between the amount related fields 33B, 36, 71G, 71F and 32A which may be logically
expressed in the following formula:
• 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, C15 and C16. 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
• Exchange rate is 1 EUR for 0,61999 GBP
• Transaction charges on the Sender's side are EUR 5,00 (=GBP 3,1)
• Transaction charges on the Receiver's side are GBP 4 (=EUR 6,45)

MT 103

Instructed Amount EUR 1000,00
= Debit Amount EUR 1011,45
B. MT 103 extract:
Field Tag Content
33B EUR 1000,00
71A OUR
71G GBP 4,00
36 0,61999
32A GBP 623,99
C. The subsequent MT 950 shows one debit entry for GBP 623,99, ie, field 32A.
Interbank settlement amount GBP 623,99

Instructed amount EUR 1000,00
B. MT 103 extract:
Field Tag Content
33B EUR 1000,00
71A SHA
36 0,61999
32A GBP 619,99
31 August 2007 137


Instructed amount = Debit amount EUR 1000,00
B. MT 103 extract:
Field Tag Content
33B EUR 1000,00
71A BEN
71F GBP 3,1
36 0,61999
32A GBP 616,89
Equivalent of Instructed amount GBP 619,99
Examples: Transaction B
• Transaction charges on the Receiver's side are GBP 4,00 (=EUR 6,45)


MT 103
Equivalent of Instructed amount EUR 1612,93
B. MT 103 extract
Field Tag Content
33B GBP 1000,00
71A OUR
71G GBP 4,00
32A GBP 1004,00
C. The subsequent MT 950 shows one debit entry for GBP 1004, ie, field 32A.
Instructed amount = Credit amount GBP 1000,00

B. MT 103 extract:
Field Tag Content
33B GBP 1000,00
71A SHA
32A GBP 1000,00
31 August 2007 139

Note: field 36 does not have to be used since currency in fields 32A and 33B is the same

Equivalent of Instructed amount = EUR 1612,93

Debit amount
B. MT 103 extract:
Field Tag Content
33B GBP 1000,00
71A BEN
71F GBP 3,10
32A GBP 996,90
C. The subsequent MT 950 shows one debit entry for GBP 996,9 ie, field 32A.
Instructed amount GBP 1000,00
MT 103 Guidelines
• If the Sender and the Receiver wish to use their direct account relationship in the currency of the transfer,
then the MT 103 message will contain the cover for the customer transfer as well as the payment details.
• 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 transaction. The
MT 103 contains only the payment details and the Sender must cover the customer transfer by sending an
MT 202 General Financial Institution Transfer to a third bank. This payment method is called 'cover'.
• Where more than two financial institutions are involved in the payment chain, and if the MT 103 is sent
from one financial institution to the next financial institution in this chain, then the payment method is
called 'serial'.

MT 103
• If the Receiver does not service an account for the beneficiary customer, and no account servicing
institution is indicated, nor any alternative instructions given, then the Receiver will act upon the customer
credit transfer instruction in an appropriate manner of its choice.
• In order to allow better reconciliation by the beneficiary customer, the MT 103 supports full charges
transparency and structured remittance information.
• In order to allow better reconciliation by the Receiver, the MT 103 gives an unambiguous indication of the
interbank amount booked by the Sender/to be booked by the Receiver.
• The MT 103 gives the Sender the ability to identify in the message the level of service requested, ie, what
service is expected from the Receiver for a particular payment, eg, SWIFTPay, Standard or Priority or any
other bilaterally agreed service.
• The message also allows for the inclusion of regulatory information in countries where regulatory
reporting is requested.

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
T26).
USAGE RULES
This reference must be quoted in any related confirmation or statement, eg, MT 900, 910 and/or 950.
EXAMPLE
:20:Ref254

FORMAT
PRESENCE
Optional
DEFINITION
instruction.
CODES
31 August 2007 141


USAGE RULES
EXAMPLE
Explanation:
• + 0100 is the offset of CET against UTC in January (ie during winter time).
3. Field 23B: Bank Operation Code

FORMAT
Option B 4!c (Type)
PRESENCE
Mandatory
DEFINITION
CODES
CRED This message contains a credit transfer where there is no SWIFT Service Level involved.
CRTS This message contains a credit transfer for test purposes.

MT 103
SPAY This message contains a credit transfer to be processed according to the SWIFTPay Service Level.
SPRI This message contains a credit transfer to be processed according to the Priority Service Level.
SSTD This message contains a credit transfer to be processed according to the Standard Service Level.
USAGE RULES
The code CRTS should not be used on the FIN network.
EXAMPLE
:23B:SPAY

FORMAT
Option E 4!c[/30x] (Instruction)(Additional Information)
PRESENCE
Conditional (see rule C3)
DEFINITION
This field specifies an instruction.
CODES
Instruction must contain one of the following codes (Error code(s): T47):
SDVA Payment must be executed with same day value to the beneficiary.
INTC The payment is an intra-company payment, ie, a payment between two companies belonging to the
same group.
CORT Payment is made in settlement of a trade, eg, foreign exchange deal, securities transaction.
HOLD Beneficiary customer/claimant will call; pay upon identification.
CHQB Pay beneficiary customer only by cheque. The optional account number line in field 59 must not be
used.
PHOB Please advise/contact beneficiary/claimant by phone.
TELB Please advise/contact beneficiary/claimant by the most efficient means of telecommunication.
PHON Please advise account with institution by phone.
TELE Please advise account with institution by the most efficient means of telecommunication.
PHOI Please advise the intermediary institution by phone.
TELI Please advise the intermediary institution by the most efficient means of telecommunication.

Additional Information is only allowed when Instruction Code consists of one of the following codes: PHON,
PHOB, PHOI, TELE, TELB, TELI, HOLD or REPA (Error code(s): D97).
If this field is repeated, the codes must appear in the following order (Error code(s): D98):
SDVA
INTC
REPA
CORT
HOLD
31 August 2007 143

CHQB
PHOB
TELB
PHON
TELE
PHOI
TELI
When this field is used more than once, the following combinations are not allowed (Error code(s): D67):
SDVA with HOLD

SDVA with CHQB
INTC with HOLD
INTC with CHQB
REPA with HOLD
REPA with CHQB
REPA with CORT
CORT with HOLD
CORT with CHQB
HOLD with CHQB
PHOB with TELB
PHON with TELE
PHOI with TELI
If this field is repeated, the same code word 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.
EXAMPLE
:23E:CHQB
:23E:TELI/3226553478

FORMAT
Option T 3!c (Type)
PRESENCE
Optional
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the individual transaction, eg, salaries,
pensions, dividends.

MT 103
CODES
field.
USAGE RULES
EXAMPLE
:26T:K90
6. Field 32A: Value Date/Currency/Interbank Settled Amount

FORMAT
PRESENCE
Mandatory
DEFINITION
EXAMPLE
:32A:981209USD1000,00

FORMAT
PRESENCE
Conditional (see rules C2 and C16)
DEFINITION
USAGE RULES
31 August 2007 145

side.
EXAMPLE
:33B:USD1000,00

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert the instructed amount specified in field 33B.
USAGE RULES
side.
EXAMPLE
:36:0,9236

FORMAT

Party Identifier)
Name & Address)
Or

MT 103

Party Identifier)
Name & Address)
PRESENCE
Mandatory
DEFINITION
This field specifies the customer ordering the transaction.
CODES
Number.
CODES
name(s)).
building name).
31 August 2007 147

Number.

T28, T29, T45).
USAGE RULES
issue.
• Numbers may be repeated if more than one line is needed to provide the information indicated by the code
for example 2 lines for address details.
EXAMPLE
Option A
:50A:/293456-1254349-82
VISTUS31
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS

MT 103
1/DUPONT JACQUES
3/BE/BRUSSELS
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
123456789/8-1234567890.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
Optional
DEFINITION
USAGE RULES
At least the first 8 characters of the BIC in this field must be identical to the originator of this FileAct message.
The content of field 20, Sender's reference together with the content of this field provides the message
identification which is to be used in case of queries, cancellations etc.
EXAMPLE
:51A:ABNANL2A

FORMAT
4!a2!a2!c[3!c] (BIC)
31 August 2007 149

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

CODES
In option D, Party Identifier may be used to indicate a national clearing system code.


MT 103


T29, T45).
USAGE RULES
The coded information contained in field 52a must be meaningful to the Receiver of the message.
Option D should only be used when the ordering financial institution has no BIC.
EXAMPLE
:52A:ABNANL2A

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Conditional (see rules C4, C5, and C7)
DEFINITION
T29, T45).
USAGE RULES
Absence of this field implies that there is a unique account relationship between the Sender and the Receiver
or that the bilaterally agreed account is to be used for settlement.
31 August 2007 151

credited or debited must be indicated in field 53a, using option B with the party identifier only.
Receiver (or branch of the Receiver when specified in field 54a), then field 53a must be present.
54a, if present.
In all other cases, when field 53a is present, a cover message, ie, MT 202/203 or equivalent non-SWIFT must
When field 53B is used to specify a branch city name, it must always be a branch of the Sender.
EXAMPLE
:53A:ABNANL2A
13. Field 54a: Receiver's Correspondent

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
DEFINITION
This field specifies the branch of the Receiver or another financial institution at which the funds will be made
available to the Receiver.
T29, T45).
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, ie, intermediary reimbursement institution shall be specified in
field 54a and field 55a shall contain the Receiver's branch.

MT 103
Option B must only be used with a location.

In those cases where field 54a contains a branch of the Receiver, and is not preceded by field 53a, or field 53a
from its branch.
If field 54a contains a branch of the Receiver and field 53a contains a branch of the Sender, the Receiver will
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.
the Receiver, field 54a must not be present.
Field 54a containing the name of a financial institution other than the Receiver's branch must be preceded 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 transaction and
EXAMPLE
:54A:IRVTUS3N
14. Field 55a: Third Reimbursement Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
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.
T29, T45).
USAGE RULES
EXAMPLE
:55A:IRVTUS3N
31 August 2007 153

15. Field 56a: Intermediary Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
institution.
CODES

CODES


MT 103


T29, T45).
USAGE RULES
When one of the codes //FW (with or without the 9-digit number), //AU, //CP, //IN or //RT is used, it should
appear only once and in the first of the fields 56a and 57a of the payment instruction.
of field 56a or 57a.
information. If it is used with option C or D, it may be followed by another domestic clearing code.
Option A is always the preferred option.
Option C must be used containing a 2!a clearing system code preceded by a double slash '//'.
EXAMPLE
:56A:IRVTUS3N
31 August 2007 155


FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
DEFINITION
CODES

CODES


MT 103


T29, T45).
USAGE RULES
When one of the codes //FW (with or without the 9-digit number), //AU, //CP, //IN or //RT is used, it should
appear only once and in the first of the fields 56a and 57a of the payment instruction.
of field 56a or 57a.
information. If it is used with option C or D, it may be followed by another domestic clearing code.
Option C must be used containing a 2!a clearing system code preceded by a double slash '//'.
31 August 2007 157

EXAMPLE
:57A:ABNANL2A

FORMAT
PRESENCE
Mandatory
DEFINITION
This field specifies the customer which will be paid.
CODES
Account may contain one of the following codes preceded by a double slash ('//'):

T28, T29, T45).
USAGE RULES
At least the name or the BIC/BEI of the beneficiary customer is mandatory.
EXAMPLE
:59:/BE62510007547061
JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS

FORMAT
4*35x (Narrative)
PRESENCE
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

MT 103
characters).
USAGE RULES
70.
EXAMPLE
:70:/RFB/BET072
:70:/INV/abc/SDF-96//1234-234///ROC/98IU
87

FORMAT
Option A 3!a (Code)
PRESENCE
Mandatory
DEFINITION
This field specifies which party will bear the charges for the transaction.
CODES

SHA Transaction charges on the Sender's side are to be borne by the ordering customer, transaction charges
on the Receiver's side are to be borne by the beneficiary customer.
EXAMPLE
:71A:BEN

FORMAT
PRESENCE
31 August 2007 159

DEFINITION
USAGE RULES
The net amount after deduction of the Sender's charges will be quoted as the inter-bank settled amount in field
32A.
EXAMPLE
:71F:EUR8,00

FORMAT
PRESENCE
DEFINITION
If field 71G is present, the amount must not equal '0' (Error code(s): D57).
USAGE RULES
This field is conveyed for accounting reasons, ie, to facilitate bookkeeping.
Where field 71A indicates OUR payments, this field identifies the charges due, which have been prepaid and
included in the interbank settlement amount.
EXAMPLE
:71G:EUR5,50

MT 103

FORMAT

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, one of the following codes must be
used, placed between slashes ('/'):
ACC Instructions following are for the account with institution.

INT Instructions following are for the intermediary institution.
REC Instructions following are for the Receiver of the message.
USAGE RULES
field.
Use of field 72, particularly with uncoded instructions, may cause delay, because, in automated systems, the
presence of this field will normally require manual intervention.
It is strongly recommended to use the standard codes proposed above. In any case, where bilateral agreements
EXAMPLE
:72:/INS/ABNANL2A

FORMAT
31 August 2007 161


PRESENCE
Optional
DEFINITION
country of Receiver or Sender.
CODES
Where the residence of either ordering customer or beneficiary customer is to be identified, the following
codes may be used, placed between slashes ('/'):

USAGE RULES
customer.
EXAMPLE
:77B:/ORDERRES/BE//MEILAAN 1, 9000 GENT
24. Field 77T: Envelope Contents

FORMAT
Option T 9000z
PRESENCE
DEFINITION
This field can contain extended remittance information in different formats. The content of the field is subject
to bilateral agreements between the ordering customer and the Beneficiary.
CODES
ANSI The content of the field is in the ANSI/X12 format.

NARR The content of the field is narrative text.
SWIF The content of the field matches the structure proposed in field 70 of this message, ie, multiple
references can be used, if separated with a double slash, '//'. Codes must not be repeated between two
UEDI The content of the field is in the UN-EDIFACT format. The information will start with the UNH-
segment, which contains all necessary information to process the rest of the field.

MT 103

If the field is used, the Sender must set the validation flag to REMIT in field 119 of the User Header of the
message. If field 77T is not present, the code of the validation flag must not be REMIT (Error code(s): G06).
USAGE RULES
The presence of this field is subject to a special validation. It can only be included in messages that are sent
and/or received by those customers who have registered for the Extended Remittance Information MUG.
This field may contain any character defined in the 'z' character set. The 'z' character set contains the characters
of both the 'x' and 'y' character set extended with the characters {, @, _ and #:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
.,-()/='+:?!'%&*<>;
{@_#
Cr Lf Space
It is highly recommended to take great care when using the character string 'CrLf', since these characters are
used by the network to indicate an end of field or subfield.
EXAMPLE
:77T:/UEDI/UNH+123A5+FINPAY:D:98A:UN'DOC+ …
MT 103 Examples
MT 103 Examples for the Core MT 103, used outside any Service Level
Agreements
The message has the following layout:
N
o.
----->
O 13C Time indication /8c/4!n1!x4!n 2
-----|
M 23B Bank Operation Code CRED 3
----->
-----|
O 26T Transaction Type Code 3!a 5
31 August 2007 163

N
o.
M 50a Ordering Customer A, F or K 9

4!a2!a2!c[3!c]
O 53a Sender's Correspondent A, B or D 12
O 54a Receiver's Correspondent A, B or D 13
O 55a Third Reimbursement Institution A, B or D 14
O 56a Intermediary Institution A, C or D 15
O 57a Account With Institution A, B, C or D 16
M 59a Beneficiary Customer A or no letter option 17
----->
-----|
Example 1.1: Single Customer Credit Transfer with Direct Account Relationship
Narrative
Biodata G.m.b.H. orders UBS, Zürich, to pay euro 1,958.47 to ABN Amro Bank, Amsterdam, for the account
of H.F. Janssen.

MT 103
Information Flow
Ordering Customer Biodata GmbH

Zurich
50a
Sender UBS
Zurich
MT
MT 103
Receiver ABN Amro Bank

Amsterdam
Beneficiary Customer H.F. Janssen

Amsterdam
D0010020
59a
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Message type 103
Receiver ABNANL2A
Message text
Sender's reference :20:494931/DEV
Bank operation code :23B:CRED
Value date/currency/interbank settled amount :32A:090828EUR1958,47
Currency/Instructed Amount :33B:EUR1958,47

BIODATA GMBH
HOCHSTRASSE, 27
8022-ZURICH
SWITZERLAND

H.F. JANSSEN LEDEBOERSTRAAT 27
AMSTERDAM
31 August 2007 165

Explanation Format
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.
Example 1.2: Single Customer Credit Transfer Specifying Account for

Reimbursement
Narrative
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

Zurich
50a
Sender UBS
Zurich
MT
MT 103

Amsterdam

Amsterdam
D0010021
59a

MT 103
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Message type 103
Receiver ABNANL2A
Message text
Currency/Instructed amount :33B:EUR1958,47

BIODATA GMBH
HOCHSTRASSE, 27
8022-ZURICH
SWITZERLAND
Sender's correspondent (1) :53B:/219429055

AMSTERDAM
Remittance information (2) :70:/INV/18042-090715
Receiver's charges :71G:EUR2,50
(1) Field 53B indicates the account number of the Sender's account, serviced by the Receiver, which is to be
used for reimbursement 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 1.3: Single Customer Credit Transfer with Ordering and Account With
Institutions
Narrative
Franz Holzapfel G.m.b.H. orders Finanzbank AG, Eisenstadt, to pay, value 28 August 2009, US Dollars 850
into C. Won's account number 729615-941 with Oversea-Chinese Banking Cooperation, Singapore. The
payment is for July 2009 expenses.
Finanzbank AG, Eisenstadt, asks Bank Austria, Vienna, to make the payment. Both Bank Austria, Vienna, 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.
31 August 2007 167

Information Flow
Ordering Customer Franz Holzapfel GmbH

Vienna
50a
Ordering Institution Finanzbank AG

52a Eisenstadt
Sender Bank Austria

Vienna
MT
First MT 103
Receiver Citibank
New York
(Second MT 103)
Account With Institution Oversea-Chinese

57a Banking Cooperation
Singapore
Beneficiary Customer C. Won

Singapore
D0010022
59a
First SWIFT Message, MT 103
Explanation Format
Sender BKAUATWW
Message type 103
Receiver CITIUS33
Message text
Value date/currency/interbank settled amount :32A:090828USD850,

MT 103
Explanation Format

1/FRANZ HOLZAPFEL GMBH
2/GELBSTRASSE, 13
3/AT/VIENNA
Ordering institution :52D:FINANZBANK AG

EISENSTADT
Account with institution :57A:OCBCSGSG
Beneficiary customer :59:/729615-941

C.WON
PARK AVENUE 1
SINGAPORE
Remittance information :70:JULY 2009 EXPENSES
Mapping
The following illustrates the mapping of the first MT 103 onto the next MT 103:
MT 103 MT 103
S S
R R
20 20
23B 23B
32A 32A
50a 33B
52a 50a
57a 52a
59a 59a
70 70
71A 71A
71F
D0010046
72/INS/
Second SWIFT Message, MT 103
Explanation Format
Sender CITIUS33
Message type 103
Receiver OCBCSGSG
31 August 2007 169

Explanation Format
Message text
Currency/Instructed amount :33B:USD850,

2/GELBSTRASSE, 13
3/AT/VIENNA
Ordering institution :52D:FINANZBANK AG

EISENSTADT

C.WON
PARK AVENUE 1
SINGAPORE
Remittance information :70:JULY 2009 EXPENSES
Sender's charges :71F:USD10,
Sender to receiver information :72:/INS/BKAUATWW
Example 1.4: Single Customer Credit Transfer with Reimbursement Through Two
Institutions
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. The beneficiary is to be notified by phone at 20.527.19.60.
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
2. Sent to the next party in the transfer.
Note: The alternative selected is dependent on correspondent relationships and financial practice in the
countries involved.
Method 1 SWIFT MT 103 to the Party Closest to the Beneficiary

Bank Austria sends the following messages:
A. A customer transfer to ABN Amro Bank, Amsterdam.

MT 103
B. A cover message for the US dollar payment, which is provided through Chase Manhattan Bank, New York,
to ABN Amro Bank, New York.
Message A SWIFT MT 103 Single Customer Credit Transfer
Information Flow

Vienna
50a
Sender Bank Austria

Vienna
(Message B
MT 202)
Sender's Chase Manhattan Bank

Correspondent 53a New York
Message A (Receiver of MT 202)
MT
MT 103
Receiver's ABN Amro Bank
(Field 57a of MT 202)
(MT 910/950)
Amsterdam
Beneficiary Customer C. Klein

Amsterdam
D0010023
59a
SWIFT Message, MT 103
Explanation Format
Sender BKAUATWW
Message type 103
Receiver ABNANL2A
Message text
Sender's reference :20:394882
Instruction code :23E:PHOB/20.527.19.60
Value date/currency/interbank settled amount :32A:090828USD1121,50
31 August 2007 171

Explanation Format
Currency/Instructed amount :33B:USD1121,50

2/GELBSTRASSE, 13
3/AT/VIENNA
Sender's correspondent (1) :53A:CHASUS33
Receiver's correspondent (2) :54A:ABNAUS33

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
(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
MT 103 MT 202
S S
R R
20 20
23B 21
23E 32A
32A 57a
50a 58a
53a
54a
59a
71A
D0010047
Message B SWIFT MT 202 (Cover message)

MT 103
Information Flow
Sender Bank Austria

Vienna
Message B
MT
MT 202
Receiver Chase Manhattan Bank

(Message A New York
MT 103) (Field 53a in MT 103)
Account With ABN Amro Bank

Institution 57a New York
(Field 54a in MT 103)
Beneficiary ABN Amro Bank

Institution Amsterdam
D0010024
58a
(Receiver of MT 103)
Explanation Format
Sender BKAUATWW
Message type 202
Receiver CHASUS33
Message text
Related reference (1) :21:394882
Value date/currency code/amount :32A:090828USD1121,50
Account with institution :57A:ABNAUS33
Beneficiary institution :58A:ABNANL2A
(1) The related reference is the Sender's reference of the Single Customer Credit Transfer.
Method 2 SWIFT MT 103 to the Next Party in the Transaction
31 August 2007 173

Information Flow

Vienna
50a
Sender Bank Austria

Vienna
Message A
MT
MT 103

New York
(Message B
MT 103*)
Intermediary Institution ABN Amro Bank

56a New York
(Message C
MT 103)
Account With Institution ABN Amro Bank

57a Amsterdam

Amsterdam
D0010025
59a
* Or its equivalent domestic clearing message
Explanation Format
Sender BKAUATWW
Message type 103
Receiver CHASUS33
Message text

MT 103
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA
Intermediary institution (1) :56A:ABNAUS33
Account with institution (2) :57A:ABNANL2A

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
(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
MT 103 MT 103 MT 103
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/
D0010060
Message B 2nd SWIFT MT 103 (or its equivalent domestic clearing message)
31 August 2007 175

Information Flow

Vienna
50a
Ordering Institution Bank Austria

52a Vienna
(Message A, MT 103)
Sender Chase Manhattan Bank

New York
Message B
MT
MT 103

New York
(Message C, MT 103)

57a Amsterdam

D0010026
Amsterdam
59a
Explanation Format
Sender CHASUS33
Message type 103
Receiver ABNAUS33
Message text

MT 103
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA
Ordering institution (1) :52A:BKAUATWW

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
(1) The Sender of the initial MT 103 is Bank Austria, Vienna, which is the ordering institution in all
subsequent messages.
(2) ABN Amro Bank, Amsterdam, will receive the funds from the Receiver of this message, its New York office,
Message C 3rd SWIFT MT 103
31 August 2007 177

Information Flow

Vienna
50a

52A Vienna
(Message A, MT 103)
Instructing Institution Chase Manhattan Bank

72 New York
(Message B, MT 103)
Sender ABN Amro Bank

New York
Message C
MT
MT 103

Amsterdam

Amsterdam
D0010051
59a
Explanation Format
Sender ABNAUS33
Message type 103
Receiver ABNANL2A
Message text

MT 103
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
Sender to receiver information :72:/INS/CHASUS33
(1) The Sender of the initial MT 103 is Bank Austria, Vienna, which is the ordering institution in all
Example 1.5: Single Customer Credit Transfer with Three Reimbursement

Institutions
Narrative
Gian Angelo Imports, Naples, orders Banca Commerciale Italiana, Naples, to pay, value 12 June 2009, US
Dollars 5,443.99 to Banque Nationale de Paris, Grenoble, for account number 20041 01005 0500001M026 06
of Killy S.A., Grenoble, in payment of invoice 559661.
Banca Commerciale Italiana, Milan, makes the US Dollar payment through its US correspondent, Banca
Commerciale Italiana, New York, under reference 8861198-0706.
Payment is to be made to Banque Nationale de Paris, Paris, in favour of Banque Nationale de Paris, Grenoble,
through its US correspondent, Bank of New York, New York.
1. Message sent to party closest to the beneficiary, using a third reimbursement institution.
2. Message sent through several reimbursement institutions, using an account with institution.
3. Message sent to the next party in the transaction.
Note: Although this transfer may also be sent to the next party in the transaction, this method is not illustrated
here.
The alternative selected is dependent on correspondent relationships and financial practice of the
countries involved.
Method 1 Message Sent to Party Closest to the Beneficiary, Using a Third Reimbursement Institution
31 August 2007 179

Information Flow
Ordering Customer Gian Angelo Imports

Naples
50a
Ordering Institution Banca Commerciale

52a Italiana, Naples
(Message B
Sender MT 202) Banca Commerciale
Italiana, Milan
Sender's Banca Commerciale

Correspondent 53a Italiana, New York
(Message C, MT 205*)
Message A
Intermediary MT Bank of New York
Reimbursement 54a New York
Institution (Field 56a of MT 202)
(Message D, MT 202) MT 103
Third Banque Nationale

Reimbursement 55a de Paris, Paris
Institution (Field 57a of MT 202)
Receiver Banque Nationale
de Paris, Grenoble
(MT 910/950) (Field 58a of MT 202)
Beneficiary Customer Killy S.A.

Grenoble
D0010027
59a
Explanation Format
Sender BCITITMM
Message type 103
Receiver (1) BNPAFRPPGRE
Message text
Sender's reference :20:8861198-0706

MT 103
Explanation Format

1/GIAN ANGELO IMPORTS
2/LUNGO MORE 5
3/IT/NAPLES
Ordering institution :52A:BCITITMM500
Sender's correspondent (2) :53A:BCITUS33
Intermediary reimbursement institution (3) :54A:IRVTUS3N
Third reimbursement institution :55A:BNPAFRPP
Beneficiary customer :59:/20041010050500001M02606

KILLY S.A.
GRENOBLE
Remittance information (4) :70:/INV/559661
(1) The message is sent to Banque Nationale de Paris, Grenoble, the financial institution which is located
closest to the beneficiary customer.
(2) Banca Commerciale Italiana, New York, the sender's correspondent, will provide the funds to the
intermediary reimbursement institution, Bank of New York, N.Y.
(3) Bank of New York, New York, will receive the funds on behalf of Banque Nationale de Paris, Paris
(4) As the reference for the beneficiary is an invoice number, the code /INV/ is used, followed by the invoice
number.
Mapping
MT 103 MT 202 MT 205 MT 202
S S S S
R R R R
20 20 20 20
23B 21 21 21
32A 32A 32A 32A
33B 56a 52a 52a
50a 57a 57a 58a
52a 58a 58a 72/INS/
53a
54a
55a
59a
70
D0010049
71A
31 August 2007 181

Message B SWIFT MT 202 (Cover Message)
Information Flow
Sender Banca Commerciale Italiana

Milan
Message B
MT
MT 202
Receiver Banca Commerciale Italiana

New York
(Message C
MT 205*)
(Message A
MT 103)
Intermediary Bank of New York

56a New York
(Message D
MT 202)
Account Banque Nationale de Paris

With Institution 57a Paris
Beneficiary Banque Nationale de Paris

Institution 58a Grenoble
D0010028
Explanation Format
Sender BCITITMM
Message type 202
Receiver (1) BCITUS33
Message text
Related reference (2) :21:8861198-0706
Intermediary (3) :56A:IRVTUS3N

MT 103
Explanation Format
Account with institution (4) :57A:BNPAFRPP
Beneficiary institution :58A:BNPAFRPPGRE
(1) The message is sent to Banca Commerciale Italiana, New York, ordering transfer of the funds to Bank of
New York, New York.
(2) The related reference is the Sender's reference of the MT 103.
(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris, in favour of
Grenoble.
(4) Banque Nationale de Paris, Paris, will pay the funds to its Grenoble office, in cover of the transaction to
Killy, S.A.
Message C SWIFT MT 205 (or its equivalent domestic clearing message)
Information Flow
Ordering Banca Commerciale Italiana

Institution 52a Milan
(Message B
MT 202)

New York
Message C
MT
MT 205
(Message A
MT 103)
Receiver Bank of New York

New York
(Message D
MT 202)
Account Banque Nationale de Paris

With Institution 57a Paris

D0010029
31 August 2007 183

Explanation Format
Sender BCITUS33
Message type 205
Receiver (1) IRVTUS3N
Message text
Ordering institution :52A:BCITITMM
Account with institution (3) :57A:BNPAFRPP
(1) The message is sent to Bank of New York, New York.

(2) The related reference is the Sender's reference of the initial MT 103.
(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris, in favour of
Grenoble.
Message D SWIFT MT 202 General Financial Institution Transfer

MT 103
Information Flow

(Message B
MT 202)
Instructing Banca Commerciale Italiana

Institution 72 New York
(Message C
MT 205)
Sender Bank of New York

(Message A New York
MT 103) (Receiver of MT 205)
Message D
MT
MT 202
Receiver Banque Nationale de Paris

Paris

(Field 58a of MT 205) D0010030
Explanation Format
Sender IRVTUS3N
Message type 202
Receiver BNPAFRPP
Message text
Transaction reference number :20:GH45952-4587
31 August 2007 185

Explanation Format
Sender to receiver information> (2) :72:/INS/BCITUS33
(2) The instructing institution is Banca Commerciale Italiana, New York.
Method 2 Customer Transfer Sent Through Several Reimbursement Institutions Using an Account
With Institution
Message A SWIFT MT 103 Customer Transfer
Information Flow
Ordering Customer Gian Angelo Imports

Naples
50a
Ordering Institution Banca Commerciale

52a Italiana, Naples
(Message B
Sender MT 202) Banca Commerciale
Italiana, Milan
Sender's Banca Commerciale

Correspondent 53a Italiana, New York
(Message C Message A
MT 205*) MT
MT 103
Receiver's Bank of New York
(Message D
Receiver MT 910/950) Banque Nationale
de Paris, Paris
Account With Banque Nationale

Institution 57a de Paris, Grenoble
Beneficiary Customer Killy S.A.

D0010031
Grenoble
59a

MT 103
Explanation Format
Sender BCITITMM
Message type 103
Receiver (1) BNPAFRPP
Message text
Sender's reference :20:8861198-0706

1/GIAN ANGELO IMPORTS
2/LUNGO MORE 5
3/IT/NAPLES
Ordering institution :52A:BCITITMM500
Sender's correspondent (2) :53A:BCITUS33
Receiver's correspondent (3) :54A:IRVTUS3N
Account with institution :57A:BNPAFRPPGRE
Beneficiary customer :59:/20041010050500001M02606

KILLY S.A.
GRENOBLE
Remittance information (4) :70:/RFB/INVOICE 559661
(1) The message is sent to Banque Nationale de Paris, Paris, the financial institution which will provide the
funds to the account with institution.
(2) Banca Commerciale Italiana, New York, will provide the funds to the receiver's correspondent, Bank of
New York, New York.
(3) Bank of New York, New York, the receiver's correspondent, will receive the funds on behalf of Banque
Nationale de Paris, Paris.
(4) As the reference for the beneficiary can be contained in 16 characters, the code /RFB/ is used, followed by
the reference.
Mapping
31 August 2007 187

MT 103 MT 202 MT 205 MT 910
S S S S
R R R R
20 20 20 20
23B 21 21 21
32A 32A 32A 25
33B 57a 52a 32A
50a 58a 58a 52a
52a 56a
53a
54a
57a
59a
70
D0010050
71A
Message B SWIFT MT 202 (Cover Message)

MT 103
Information Flow

Milan
Message B
MT
MT 202
Receiver Banca Commerciale Italiana

New York
(Message A (Field 53a of MT 103)
MT 103)
(Message C
MT 205*)
Account Bank of New York

With Institution 57a New York
(Message D
MT 910/950)

Institution 58a Paris
D0010032
Explanation Format
Sender BCITITMM
Message type 202
Receiver (1) BCITUS33
Message text
Account with institution (3) :57A:IRVTUS3N
Beneficiary institution :58A:BNPAFRPP
(1) The message is sent to Banca Commerciale Italiana, New York, ordering transfer of the funds to Bank of
New York, New York.
31 August 2007 189

(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris.
Message C SWIFT MT 205 (or its equivalent domestic clearing message)
Information Flow

(Sender of MT 202)
(Message B
MT 202)

New York
Message C
(Message A MT
MT 103)
MT 205
Receiver Bank of New York

New York
(Message D
MT 910/950)

Institution 58a Paris
D0010033
Explanation Format
Sender BCITUS33
Message type 205
Receiver (1) IRVTUS3N
Message text

MT 103
Explanation Format
Beneficiary institution (3) :58A:BNPAFRPP
(1) The message is sent to Bank of New York, New York.

(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris.
Message D SWIFT Statement/Confirmation of Credit

Bank of New York, New York, will credit Banque Nationale de Paris with the funds.
The statement line for this credit on the customer statement (MT 950) will appear as:
:61:090612C5443,99S9108861198-0706//GH45952-4587
In addition, Bank of New York may send, prior to the statement, a Confirmation of Credit:
SWIFT Message, MT910
Explanation Format
Sender IRVTUS3N
Message type 910
Receiver BNPAFRPP
Message text
Transaction reference number :20:GH45952-4587
Intermediary (2) :56A:BCITUS33
(2) Banca Commerciale Italiana, New York, is the instructing institution.
Example 1.6: Customer Transfer with Currency Conversion
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 correspondent
of BNKACHZZ.
31 August 2007 191

Information Flow

Zürich
50a
Sender BNKACHZZ
MT
(MT 950)
MT 103
Receiver BNKBBEBB
Beneficiary Customer Johann Willems
D0010034
59a Brussels
Explanation Format
Sender BNKACHZZ
Message type 103
Receiver BNKBBEBB
Message text
Sender's reference :20:5362/MPB
Currency/Instructed amount :33B:CHF2000,

8022-ZURICH

JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS

MT 103
Explanation Format
Receiver's charges :71G:EUR5,
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
Message type 950
Receiver BNKACHZZ
Message text
Statement line :61:090828D1244,47S1035362/MPB//1234T
Closing balance :62F:C090828EUR98755,53
MT 103 Example for the core MT 103, used in a Service Level Agreement
Overview of Available Options for Party Fields

The available options for the party fields in the MT 103 message differ, depending on the SWIFT Service
Level Agreement indicated in field 23B. The following matrix gives an overview of the options that may be
used in the different scenarios. You can find full details under the conditional rules and the field specifications
of the respective fields.
31 August 2007 193

Payments Service Levels: Field 23B contains SPAY, SSTD or Other Usage: Field 23B
SPRI contains CRED or CRTS
52a A A
D D
53a A A
B (Account number only) B
D
54a A A
B (Branch only)
D
55a A A
B (Branch only)
D
56a Priority A A
Forbidden C (clearing code) C (clearing code)
D
57a A A
C B
D (with mandatory identifier) C
D
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:
N
o.
----->
-----|
M 23B Bank Operation Code SSTD or SPAY 3
----->
-----|

MT 103
N
o.

4!a2!a2!c[3!c]
----->
-----|
The message has the following layout for the SWIFT Priority Service Level:
N
o.
----->
-----|
M 23B Bank Operation Code SPRI 3
----->
-----|
31 August 2007 195

N
o.

4!a2!a2!c[3!c]
----->
-----|
Note: Field 56a Intermediary Institution is not allowed within the SWIFT Priority Service Level
Example 2.1: Single Customer Credit Transfer With Reimbursement Through Several
Institutions
Narrative
Amsterdam. The beneficiary is to be notified by phone at 20.527.19.60.
In this example, the MT 103 will be sent to the party closest to the beneficiary, through several reimbursement
institutions. It would also be possible to send the MT 103 to the next party in the transfer.
countries involved.

MT 103
SWIFT MT 103 to the Party Closest to the Beneficiary

BKAUATWW agreed on the Standard Service Level, as did its Dutch correspondent ABNANL2A.
Information Flow

Vienna
50a
Sender Bank Austria

Vienna
(MT 202)

MT
MT 103
(MT 910/950)
Amsterdam

Amsterdam
D0010035
59a
Explanation Format
Sender BKAUATWW
Message type 103
Receiver ABNANL2A
Message text
31 August 2007 197

Explanation Format
Bank operation code :23B:SSTD

2/GELBSTRASSE, 13
3/AT/VIENNA

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
Receiver.
MT 103 Example for the Extended Remittance Information MUG

In the following example Sender and Receiver subscribed to the MT 103 Extended Remittance Information
Message User Group. The message available for this group of users has the following layout:
MT 103 Single Customer Credit Transfer in the Extended Remittance Information MUG
N
o.
----->
-----|
M 23B Bank Operation Code 4!a 3
----->
-----|

MT 103
N
o.
----->
-----|
O 77T Envelope Contents 9000z 24
Example 3.1: Single Customer Credit Transfer
Narrative
Franz Holzapfel G.m.b.H. orders Bank Austria, Vienna, to pay euro 1,958.47 to ABN Amro Bank,
Amsterdam, for the account of H.F. Janssen, 50 26 64 959. Franz Holzapfel G.m.b.H. does this by using an
EDIFACT payment order with remittance advice information. He agreed with H.F. Janssen on the format of
this information. Bank Austria, Vienna, and ABN Amro Bank, Amsterdam, agreed on the way they exchange
EDIFACT Remittance Information.
BKAUATWW subscribed to the MT 103 Extended Remittance Information Message User Group, as did its
Dutch correspondent ABNANL2A.
31 August 2007 199

Information Flow

Vienna
50a
Sender BKAUATWW
MT
(MT 950)
MT 103
Receiver ABNANCZA
D0010036
59a Amsterdam
Explanation Format
Sender BKAUATWW
Message type 103
Receiver ABNANL2A
Message text

2/GELBSTRASSE, 13
3/AT/VIENNA

H.F. JANSSEN
LEDEBOERSTRAAT 27
AMSTERDAM

MT 103
Explanation Format
Envelope contents :77T:/UEDI/UNH+123A5+FINPAY:D:98A:UN'

DOC+ …
currency of the transfer, between the Sender and Receiver will be used.
31 August 2007 201

MT 103+ Single Customer Credit Transfer
The MT 103+ is a General Use message, ie, no registration in a Message User Group is necessary to send and
receive this message. It allows the exchange of single customer credit transfers using a restricted set of fields
and format options of the core MT 103 to make it straight through processable. The MT 103+ is a compatible
subset of the core MT 103 that is documented separately.
The differences with the core MT 103 are:
• appropriate MT 103+ 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 53 may only be used with letter options A and B
• field 51A is not used in MT 103+. 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
• if field 53a is used with option B, Party Identifier must be used
• subfield 1 (Account) of either field 59 or 59A is always mandatory
• field 72, code INS must be followed by a valid BIC
• field 72, codes REJT/RETN must not be used
• field 72 must not include ERI information.
IMPORTANT
To trigger the MT 103+ format validation, the user header of the message (block 3) is mandatory and
must contain the code STP in the validation flag field 119 ({3:{119:STP}}).
MT 103+ Scope
This message type is sent by, or on behalf of, the financial institution of the ordering customer, directly or
through (a) correspondent(s), to the financial institution of the beneficiary customer.
It is used to convey a funds transfer instruction in which the ordering customer or the beneficiary customer, or
both, are non-financial institutions from the perspective of the Sender.
This message may only be used for clean payment instructions. It must not be used to advise the remitting
bank of a payment for a clean, eg, cheque, collection, nor to provide the cover for a transaction whose
completion was advised separately, eg, via an MT 400.
MT 103+ Format Specifications

----->

MT 103+
-----|
M 23B Bank Operation Code 4!c 3
----->
-----|
M 50a Ordering Customer A, F, or K 9

4!a2!a2!c[3!c]
O 53a Sender's Correspondent A or B 11

4!a2!a2!c[3!c]
O 55A Third Reimbursement Institution [/1!a][/34x] 13

4!a2!a2!c[3!c]
O 56A Intermediary Institution [/1!a][/34x] 14

4!a2!a2!c[3!c]

4!a2!a2!c[3!c]
----->
-----|
MT 103+ Network Validated Rules

C1 If field 33B is present and the currency code is different from the currency code in field 32A, field 36
must be present, otherwise field 36 is not allowed (Error code(s): D75).
31 August 2007 203

and currency code in field 33B

If field 33B is … then field 36 is …
…
Present NOT equal currency code in field Mandatory

32A
Equals currency code in field Not allowed

32A
mandatory, otherwise field 33B is optional (Error code(s): D49).

BIC equals one of the listed BIC equals one of the listed then field 33B is …
Yes Yes Mandatory
Yes No Optional
No Yes Optional
No No Optional
Note:See also Network Validated Rule C8 (Error code(s): D51).

C3 If field 23B contains the code SPRI, field 23E may contain only the codes SDVA or INTC (Error
code(s): E01).
If field 23B contains one of the codes SSTD or SPAY, field 23E must not be used (Error code(s): E02).
If field 23B is … then field 23E is …
SPRI Optional. It may contain only SDVA or INTC
SSTD Not allowed
SPAY Not allowed
Not equal SPRI, SSTD and SPAY Optional
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 …
Present Mandatory Mandatory
Not present Optional Optional
C5 If field 56A is present, field 57A must also be present (Error code(s): C81).

MT 103+
If field 56A is … then field 57A is …
Present Mandatory
C6 If field 23B contains the code SPRI, field 56A must not be present (Error code(s): E16).
If field 23B is … then field 56A is …
SPRI Not allowed
SSTD or SPAY Optional
C7 If field 71A contains OUR, then field 71F is not allowed and field 71G is optional (Error code(s): E13).
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 contains BEN, then at least one occurrence of field 71F is mandatory and field 71G is not
BEN Mandatory (at least one Not allowed

occurrence)
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).
MC, MQ, MT, NL, NO, PL, PM, PT, RE, RO, SE, SI, SJ, SK, SM, TF and VA, then the following
apply:
• If field 57A is not present, the IBAN (ISO-13616) is mandatory in subfield Account of field 59a
• If field 57A is present and the country code of the 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).
31 August 2007 205

In all other cases, the presence of the IBAN (ISO-13616) is optional and its format is not validated in
subfield Account of field 59a.
If country code and country code and country code

of Sender's BIC of Receiver's BIC of field 57A then an IBAN in
and field 57A is
equals one of the equals one of the equals one of the subfield Account
present
listed country listed country listed country of field 59a is …
codes codes codes
Yes Yes No Not applicable Mandatory
Yes No No Not applicable Optional
No Yes No Not applicable Optional
No No No Not applicable Optional
Yes Yes Yes Yes Mandatory
Yes No Yes Yes Optional
No Yes Yes Yes Optional
No No Yes Yes Optional
Yes Yes Yes No Optional
Yes No Yes No Optional
No Yes Yes No Optional
No No Yes No Optional
MT 103+ Usage Rules

There is a relationship between the amount related fields 33B, 36, 71G, 71F and 32A which may be logically
expressed in the following formula:
• 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 Receiver's side are GBP 4 (=EUR 6,45)


MT 103+
Instructed Amount EUR 1000,00
= Debit Amount EUR 1011,45
B. MT 103+ extract:
Field Tag Content
33B EUR 1000,00
71A OUR
71G GBP 4,00
36 0,61999
32A GBP 623,99

Instructed amount EUR 1000,00
B. MT 103+ extract:
Field Tag Content
33B EUR 1000,00
71A SHA
36 0,61999
32A GBP 619,99
31 August 2007 207


Instructed amount = Debit amount EUR 1000,00
B. MT 103+ extract:
Field Tag Content
33B EUR 1000,00
71A BEN
71F GBP 3,1
36 0,61999
32A GBP 616,89
Equivalent of Instructed amount GBP 619,99
Examples: Transaction B
• Transaction charges on the Receiver's side are GBP 4,00 (=EUR 6,45)


MT 103+
B. MT 103+ extract
Field Tag Content
33B GBP 1000
71A OUR
71G GBP 4,00
32A GBP 1004,
Instructed amount = Credit amount GBP 1000,00

B. MT 103+ extract:
Field Tag Content
71A SHA
32A GBP 1000,
31 August 2007 209

Note: field 36 does not have to be used since currency in fields 32A and 33B is the same

Equivalent of Instructed amount = EUR 1612,93

Debit amount
B. MT 103+ extract:
Field Tag Content
33B GBP 1000,00
71A BEN
71F GBP 3,10
32A GBP 996,90
C. The subsequent MT 950 shows one debit entry for GBP 996,9 ie, field 32A.
Instructed amount GBP 1000,00
MT 103+ Guidelines
• If the Sender and the Receiver wish to use their direct account relationship in the currency of the transfer,
then the MT 103+ message will contain the cover for the customer transfer as well as the payment details.
• 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 transaction. The MT
103+ contains only the payment details and the Sender must cover the customer transfer by sending an MT
202 General Financial Institution Transfer to a third bank. This payment method is called 'cover'.
• Where more than two financial institutions are involved in the payment chain, and if the MT 103+ 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+ supports full charges
transparency and structured remittance information.
• In order to allow better reconciliation by the Receiver, the MT 103+ gives an unambiguous indication of
the interbank amount booked by the Sender/to be booked by the Receiver.

MT 103+
• The MT 103+ gives the Sender the ability to identify in the message the level of service requested, ie, what
service is expected from the Receiver for a particular payment, eg, SWIFTPay, Standard or Priority or any
other bilaterally agreed service.
• The message also allows for the inclusion of regulatory information in countries where regulatory
reporting is requested.
MT 103+ Field Specifications

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
T26).
USAGE RULES
This reference must be quoted in any related confirmation or statement, eg, MT 900, 910 and/or 950.
EXAMPLE
:20:Ref254

FORMAT
PRESENCE
Optional
DEFINITION
instruction.
CODES

31 August 2007 211


USAGE RULES
EXAMPLE
Explanation:
• + 0100 is the offset of CET against UTC in January (ie during winter time).
3. Field 23B: Bank Operation Code

FORMAT
Option B 4!c (Type)
PRESENCE
Mandatory
DEFINITION
CODES
CRED This message contains a credit transfer where there is no SWIFT Service Level involved.
CRTS This message contains a credit transfer for test purposes.
SPAY This message contains a credit transfer to be processed according to the SWIFTPay Service Level.
SPRI This message contains a credit transfer to be processed according to the Priority Service Level.
SSTD This message contains a credit transfer to be processed according to the Standard Service Level.
USAGE RULES
The code CRTS should not be used on the FIN network.
EXAMPLE
:23B:SPAY

MT 103+

FORMAT
Option E 4!c[/30x] (Instruction)
PRESENCE
DEFINITION
This field specifies an instruction.
CODES
Instruction must contain one of the following codes (Error code(s): T48):
SDVA Payment must be executed with same day value to the beneficiary.
INTC The payment is an intra-company payment, ie, a payment between two companies belonging to the
same group.
CORT Payment is made in settlement of a trade, eg, foreign exchange deal, securities transaction.

Additional Information is only allowed when Instruction Code consists of the following code: REPA (Error
code(s): D97).
If this field is repeated, the codes must appear in the following order (Error code(s): D98):
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 word 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.
EXAMPLE
:23E:SDVA

FORMAT
Option T 3!c (Type)
PRESENCE
Optional
31 August 2007 213

DEFINITION
This field identifies the nature of, purpose of, and/or reason for the individual transaction, eg, salaries,
pensions, dividends.
CODES
field.
USAGE RULES
EXAMPLE
:26T:K90
6. Field 32A: Value Date/Currency/Interbank Settled Amount

FORMAT
PRESENCE
Mandatory
DEFINITION
EXAMPLE
:32A:981209USD1000,00

FORMAT
PRESENCE
DEFINITION

MT 103+
USAGE RULES
side.
EXAMPLE
:33B:USD1000,00

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert the instructed amount specified in field 33B.
USAGE RULES
side.
EXAMPLE
:36:0,9236

FORMAT

Party Identifier)
31 August 2007 215


Name & Address)
Or
Party Identifier)
Name & Address)
PRESENCE
Mandatory
DEFINITION
This field specifies the customer ordering the transaction.
CODES
codes must be used (Error code(s): T55)
Number.
CODES

MT 103+
name(s)).
building name).
Number.

T28, T29, T45).
USAGE RULES
issue.
EXAMPLE
Option A
:50A:/SE1350000000054910000011
VWVOSES1
31 August 2007 217

:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
1/DUPONT JACQUES
3/BE/BRUSSELS
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
123456789/8-1234567890.

FORMAT
4!a2!a2!c[3!c] (BIC)
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


MT 103+


T29, T45).
USAGE RULES
EXAMPLE
:51A:ABNANL2A

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
DEFINITION
If field 53a is present with option B, Party Identifier must be present in field 53B (Error code(s): E04).
T29, T45).
31 August 2007 219

USAGE RULES
Absence of this field implies that there is a unique account relationship between the Sender and the Receiver
or that the bilaterally agreed account is to be used for settlement.
credited or debited must be indicated in field 53B with the party identifier only.
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 dependent on
54A, if present.
A branch of the Receiver may appear in field 53A if the financial institution providing reimbursement is both
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, ie, MT 202/203 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 transaction and
EXAMPLE
:53A:CITIUS33

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the branch of the Receiver or another financial institution at which the funds will be made
available to the Receiver.
T29, T45).
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, ie, 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.

MT 103+
If field 54A contains a branch of the Receiver and field 53A contains a branch of the Sender, the Receiver will
field 54A.
If the branch of the Sender or other financial institution specified in field 53A is also the account servicer for
field 53A; the Receiver will be paid by the financial institution in field 54A.
EXAMPLE
:54A:IRVTUS3N
13. Field 55A: Third Reimbursement Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
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.
T29, T45).
EXAMPLE
:55A:IRVTUS3N
14. Field 56A: Intermediary Institution

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
31 August 2007 221

DEFINITION
institution.
CODES


T29, T45).
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.
banks require that the code //FW appears in the optional Party Identifier of field 56A or 57A.
of field 56A or 57A.
EXAMPLE
:56A:IRVTUS3N

MT 103+
15. Field 57A: Account With Institution

FORMAT
4!a2!a2!c[3!c]
PRESENCE
DEFINITION
CODES


T29, T45).
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.
banks require that the code //FW appears in the optional Party Identifier of field 56A or 57A.
31 August 2007 223

of field 56A or 57A.
EXAMPLE
:57A:ABNANL2A

FORMAT
PRESENCE
Mandatory
DEFINITION
This field specifies the customer which will be paid.
CODES
Account may contain one of the following codes preceded by a double slash ('//'):

Account must be present (Error code(s): E10).
T28, T29, T45).
If an IBAN must be present in Account (C10), the IBAN must be a valid IBAN (ISO-13616) (Error code(s):
D19, T73).
USAGE RULES
At least the name or the BEI of the beneficiary customer is mandatory.
EXAMPLE
:59:/BE62510007547061
JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS

FORMAT
4*35x (Narrative)
PRESENCE
Optional

MT 103+
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
characters).
USAGE RULES
70.
EXAMPLE
:70:/RFB/BET072
:70:/INV/abc/SDF-96//1234-234///ROC/98I
U87

FORMAT
Option A 3!a (Code)
PRESENCE
Mandatory
DEFINITION
This field specifies which party will bear the charges for the transaction.
CODES

SHA Transaction charges on the Sender's side are to be borne by the ordering customer, transaction charges
on the Receiver's side are to be borne by the beneficiary customer.
EXAMPLE
:71A:BEN
31 August 2007 225


FORMAT
PRESENCE
DEFINITION
USAGE RULES
The net amount after deduction of the Sender's charges will be quoted as the inter-bank settled amount in field
32A.
EXAMPLE
:71F:EUR8,00

FORMAT
PRESENCE
DEFINITION
If field 71G is present, the amount must not equal '0' (Error code(s): D57).
USAGE RULES
This field is conveyed for accounting reasons, ie, to facilitate bookkeeping.
Where field 71A indicates OUR payments, this field identifies the charges due, which have been prepaid and
included in the interbank settlement amount.

MT 103+
EXAMPLE
:71G:EUR5,50

FORMAT

or
PRESENCE
Optional
DEFINITION
CODES
Unless bilaterally agreed otherwise between the Sender and the Receiver, the following code may be used,
placed between slashes ('/'):

If the code /INS/ is used at the beginning of a line, it must be followed by a valid BIC and be the only
information about that line (Error code(s): T27, T28, T29, T44, T45, T46).
If the code /INS/ is present at the beginning of a line, it must not be used again at the beginning of any other
line (Error code(s): T47).
If the code /INS/ is used anywhere else than at the beginning of a line, it is treated as free text and is ignored as
far as validation is concerned. In this case, there is no validation of the following BIC either.
The codes /REJT/ or /RETN/ must not be used in this field (Error code(s): T81).
This field must not include ERI (Error code(s): T82).
USAGE RULES
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
31 August 2007 227

EXAMPLE
:72:/INS/ABNANL2A

FORMAT

PRESENCE
Optional
DEFINITION
country of Receiver or Sender.
CODES
When the residence of either ordering customer or beneficiary customer is to be identified, the following codes
may be used, placed between slashes ('/'):

USAGE RULES
customer.
EXAMPLE
:77B:/ORDERRES/BE//MEILAAN 1, 9000 GENT
MT 103+ Examples
MT 103+ Examples for the MT 103+, used outside any Service Level
Agreements
The message has the following layout:

MT 103+
N
o.
----->
-----|
M 23B Bank Operation Code CRED 3
----->
O 23E Instruction Code 4!c 4
-----|
M 50a Ordering Customer A or K 9

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]
----->
-----|
31 August 2007 229

N
o.
Example 1.1: Single Customer Credit Transfer with Direct Account Relationship
Narrative
of H.F. Janssen.
Information Flow
Ordering Customer Bioadata GmbH

Zurich
50a
Sender UBS
Zurich
MT
MT 103+

Amsterdam

Amsterdam
D0010052
59a
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Message type 103+
Receiver ABNANL2A
Message text

MT 103+
Explanation Format

BIODATA GMBH
HOCHSTRASSE, 27
8022-ZURICH
SWITZERLAND
Beneficiary customer :59:/NL76502664959

AMSTERDAM
currency of the transfer, between the Sender and the Receiver will be used.
Example 1.2: Single Customer Credit Transfer Specifying Account for

Reimbursement
Narrative
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.
31 August 2007 231

Information Flow

Vienna
50a
Sender UBS
Zurich
MT
MT 103+

Amsterdam

Amsterdam
D0010053
59a
SWIFT Message
Explanation Format
Sender UBSWCHZH80A
Message type 103+
Receiver ABNANL2A
Message text
Currency/Instructed amount :33B:EUR1958,47

BIODATA GMBH
HOCHSTRASSE, 27
8022-ZURICH
SWITZERLAND
Sender's correspondent (1) :53B:/219429055

AMSTERDAM

MT 103+
Explanation Format
Remittance information (2) :70:/INV/18042-090715
Receiver's charges :71G:EUR2,50
(1) Field 53B indicates the account number of the Sender's account, serviced by the Receiver, which is to be
used for reimbursement 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 1.3: Single Customer Credit Transfer with Ordering and Account With
Institutions
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, Singapore. The payment
is for July 2009 expenses.
Bank Austria, Eisenstadt, asks its head office in Vienna, to make the payment. Both Bank Austria, Vienna, 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.
31 August 2007 233

Information Flow

Vienna
50a

52A Eisenstadt
Sender Bank Austria

Vienna
MT
First MT 103+
Receiver Citibank
New York
(Second MT 103+)
Account With Institution Oversea-Chinese

57A Banking Cooperation
Singapore
Beneficiary Customer C. Won

Singapore
D0010054
59a
First SWIFT Message, MT 103+
Explanation Format
Sender BKAUATWW
Message type 103+
Receiver CITIUS33
Message text

MT 103+
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA
Ordering institution :52A:BKAUATWWEIS
Account with institution :57A:OCBCSGSG

C.WON
PARK AVENUE 1
SINGAPORE
Remittance information :70:/RFB/EXPENSES 7/2009
Mapping
The following illustrates the mapping of the first MT 103+ onto the next MT 103+:
MT 103+ MT 103+
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/
Second SWIFT Message, MT 103+
Explanation Format
Sender CITIUS33
Message type 103+
Receiver OCBCSGSG
31 August 2007 235

Explanation Format
Message text
Currency/Instructed amount :33B:USD850,

2/GELBSTRASSE, 13
3/AT/VIENNA
Ordering institution :52A:BKAUATWWEIS

C.WON
PARK AVENUE 1
SINGAPORE
Remittance information :70:/RFB/EXPENSES 7/2009
Sender to receiver information :72:/INS/BKAUATWW
Example 1.4: Single Customer Credit Transfer with Reimbursement Through Two
Institutions
Narrative
Amsterdam.
1. Sent to the party closest to the beneficiary, through several reimbursement institutions
2. Sent to the next party in the transfer.
countries involved.
Method 1 SWIFT MT 103+ to the Party Closest to the Beneficiary


MT 103+
Message A SWIFT MT 103+ Single Customer Credit Transfer
Information Flow

Vienna
50a
Sender Bank Austria

Vienna
(Message B
MT 202)

Correspondent 53A New York
Message A (Receiver of MT 202)
MT
MT 103+
(MT 910/950)
Amsterdam

Amsterdam D0010056
59a
SWIFT Message, MT 103+
Explanation Format
Sender BKAUATWW
Message type 103+
Receiver ABNANL2A
Message text
31 August 2007 237

Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
Receiver.
Mapping
MT 103+ MT 202+
S S
R R
20 20
23B 21
23E 32A
32A 57a
50a 58a
53A
54A
59a
71A
D0010057
Message B SWIFT MT 202 (Cover message)

MT 103+
Information Flow
Sender Bank Austria

Vienna
Message B
MT
MT 202

(Message A New York
MT 103+) (Field 53A in MT 103)
Account With ABN Amro Bank

Institution 57a New York
(Field 54A in MT 103)
Beneficiary ABN Amro Bank

Institution Amsterdam
D0010058
58a
Explanation Format
Sender BKAUATWW
Message type 202
Receiver CHASUS33
Message text
Related reference (1) :21:394882
Account with institution :57A:ABNAUS33
Beneficiary institution :58A:ABNANL2A
(1) The related reference is the Sender's reference of the Single Customer Credit Transfer.
Method 2 SWIFT MT 103+ to the Next Party in the Transaction
Message A SWIFT MT 103+ Single Customer Credit Transfer
31 August 2007 239

Information Flow

Vienna
50a
Sender Bank Austria

Vienna
Message A
MT
MT 103+

New York
(Message B
MT 103+*)
Intermediary Institution ABN Amro Bank

56A New York
(Message C
MT 103+)

57A Amsterdam

Amsterdam
D0010059
59a
Explanation Format
Sender BKAUATWW
Message type 103+
Receiver CHASUS33
Message text

MT 103+
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA
Intermediary institution (1) :56A:ABNAUS33

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
(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,
Mapping
MT 103+ MT 103+ MT 103+
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
Message B 2nd SWIFT MT 103+ (or its equivalent domestic clearing message)
31 August 2007 241

Information Flow

Vienna
50a

52A Vienna
(Message A, MT 103+)
Sender Chase Manhattan Bank

New York
Message B
MT
MT 103+

New York
(Message C, MT 103+)

57A Amsterdam

D0010061
Amsterdam
59a
Explanation Format
Sender CHASUS33
Message type 103+
Receiver ABNAUS33
Message text

MT 103+
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
(1) The Sender of the initial MT 103+ is Bank Austria, Vienna, which is the ordering institution in all
(2) ABN Amro Bank, Amsterdam, will receive the funds from the Receiver of this message, its New York office,
Message C 3rd SWIFT MT 103+ (or its equivalent domestic clearing message)
31 August 2007 243

Information Flow

Vienna
50a

52A Vienna
(Message A, MT 103+)
Instructing Institution Chase Manhattan Bank

72 New York
(Message B, MT 103+)
Sender ABN Amro Bank

New York
Message C
MT
MT 103+

Amsterdam

Amsterdam
D0010062
59a
Explanation Format
Sender ABNAUS33
Message type 103+
Receiver ABNANL2A
Message text

MT 103+
Explanation Format

2/GELBSTRASSE, 13
3/AT/VIENNA

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
Sender to receiver information :72:/INS/CHASUS33
(1) The Sender of the initial MT 103+ is Bank Austria, Vienna, which is the ordering institution in all
Example 1.5: Customer Transfer with Currency Conversion
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 correspondent
of BNKACHZZ.
31 August 2007 245

Information Flow

Zürich
50a
Sender BNKACHZZ
MT
(MT 950)
MT 103+
Receiver BNKBBEBB
Beneficiary Customer Johann Willems
D0010063
59a Brussels
Explanation Format
Sender BNKACHZZ
Message type 103+
Receiver BNKBBEBB
Message text
Sender's reference :20:5362/MPB
Currency/Instructed amount :33B:CHF2000,

8022-ZURICH

JOHANN WILLEMS
RUE JOSEPH II, 19
1040 BRUSSELS

MT 103+
Explanation Format
Receiver's charges :71G:EUR5,
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
Message type 950
Receiver BNKACHZZ
Message text
Statement line :61:090828D1244,47S1035362/MPB//1234T
Closing balance :62F:C090828EUR98755,53
MT 103+ Example for the MT 103+, used in a Service Level 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:
N
o.
----->
31 August 2007 247

N
o.
-----|
M 23B Bank Operation Code SSTD or SPAY 3
----->
-----|

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]
----->
-----|
The message available for this group has the following layout for the Priority Service Level:

MT 103+
N
o.
----->
-----|
M 23B Bank Operation Code SPRI 3
----->
-----|

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]
----->
-----|
31 August 2007 249

N
o.
Example 2.1: Single Customer Credit Transfer With Reimbursement Through Several
Institutions
Narrative
Amsterdam.
In this example, the MT 103+ will be sent to the party closest to the beneficiary, through several
reimbursement institutions. It would also be possible to send the MT 103+ to the next party in the transfer.
countries involved.
SWIFT MT 103+ to the Party Closest to the Beneficiary

BKAUATWW agreed on the Standard Service Level, as did its Dutch correspondent ABNANL2A.

MT 103+
Information Flow

Vienna
50a
Sender Bank Austria

Vienna
(MT 202)

MT
MT 103+
(MT 910/950)
Amsterdam

Amsterdam
D0010064
59a
Explanation Format
Sender BKAUATWW
Message type 103+
Receiver ABNANL2A
Message text
Bank operation code :23B:SSTD

2/GELBSTRASSE, 13
3/AT/VIENNA
31 August 2007 251

Explanation Format

C. KLEIN
BLOEMENGRACHT 15
AMSTERDAM
Receiver.

MT 104
MT 104 Direct Debit and Request for Debit Transfer Message
Note: The use of this message type requires Message User Group (MUG) registration(s).
MT 104 Scope
The MT 104 is used to convey customer direct debit instructions between financial institutions.
The MT 104 can be:
• sent by the creditor's bank, or another financial institution, to the debtor's bank, or another financial
institution, on behalf of the creditor/instructing party to order the debit of the debtor's account and to
collect payment from this account.
• or sent between two financial institutions on behalf of a creditor/instructing party to request the direct debit
of the debtor's account in the Receiver's country and subsequently to credit the creditor's account
maintained by the Receiver or one of its branches.

• Sequence B Transaction Details is a repetitive mandatory sequence; each occurrence provides details of
one individual transaction.
• Sequence C Settlement Details is a single occurrence optional sequence. When the message is used as a
Request for Direct Debit message, this sequence is not used. When the message is used as a Direct Debit
message, this sequence is mandatory and provides further settlement information for all transactions
mentioned in sequence B.
MT 104 Direct Debit and Request for Debit Transfer Message

O 21R Customer Specified Reference 16x 2
O 21E Registration Reference 35x 4

4!a2!a2!c[3!c]
O 50a Creditor A or K 8
O 52a Creditor's Bank A, C, or D 9
31 August 2007 253

O 21C Mandate Reference 35x 16
O 21D Direct Debit Reference 35x 17
M 32B Currency and Transaction Amount 3!a15d 19
O 57a Debtor's Bank A, C, or D 23
M 59a Debtor No letter option or A 24
Optional Sequence C Settlement Details
M 32B Currency and Settlement Amount 3!a15d 33
O 71F Sum of Sender's Charges 3!a15d 35

MT 104

C1 If field 23E is present in sequence A and contains RFDD then field 23E must be present in all
occurrences of sequence B. If field 23E is present in sequence A and does not contain RFDD then field
23E must not be present in any occurrence of sequence B. If field 23E is not present in sequence A then
field 23E must be present in all occurrences of sequence B (Error code(s): C75):
if field 23E is … then field 23E is …
Present and equals RFDD Mandatory in all occurrences
Present and not equals RFDD Not allowed
Not present Mandatory in all occurrences
C2 Field 50a (option A or K), must be present in either sequence A (index 8) or in each occurrence of
sequence B (index 21), but must never be present in both sequences, nor be absent from both sequences
Sequence A In every occurrence of Sequence B

if field 50a (option A or K) is … then field 50a (option A or K) is …
Present Not allowed
Not present Mandatory in all occurrences
C3 When present in sequence A, fields 21E, 26T, 52a, 71A, 77B and 50a (option C or L) must,
independently of each other, not be present in any occurrence of sequence B. When present in one or
more occurrences of sequence B, fields 21E, 26T, 52a, 71A, 77B and 50a (option C or L) must not be
present in sequence A (Error code(s): D73).
Present Not allowed
Present Not allowed
Present Not allowed
31 August 2007 255

Present Not allowed
Present Not allowed
Present Not allowed
C4 If field 21E is present in sequence A, then the second occurrence of field 50a (option A or K), must also
be present in sequence A. In each occurrence of sequence B, if field 21E is present, then the second
occurrence of field 50a (option A or K), must also be present in the same occurrence (Error code(s):
D77):
Sequence A Sequence A
if field 21E is … then field 50a (option A or K) is …
Present Mandatory
Not present Optional (See C2)
Present Mandatory
Not present Optional (See C2, C12)
C5 In sequence A, if field 23E is present and contains RTND then field 72 must be present, in all other
cases - ie field 23E not present, or field 23E does not contain RTND - field 72 is not allowed (Error
code(s): C82):
if field 23E is … then field 72 is …
Present and equals RTND Mandatory
Present and not equals RTND Not allowed
Not present Not allowed

MT 104
C6 If field 71F is present in one or more occurrence of sequence B, then it must also be present in
Sequence C, and vice-versa (Error code(s): D79).
If field 71G is present in one or more occurrence of sequence B, then it must also be present in
sequence C, and vice-versa (Error code(s): D79).
Sequence B Sequence C
if field 71F is … then field 71F is …
Present Mandatory
if field 71G is … then field 71G is …
Present Mandatory
C7 In each occurrence of sequence B, if field 33B is present then the currency code or the amount, or both,
must be different between fields 33B and 32B (Error code(s): D21).
Examples:
Valid Invalid
:32B:USD1, :32B:USD1,
:33B:USD2, :33B:USD0001,
:32B:USD1, :32B:USD1,
:33B:EUR1, :33B:USD1,00
:32B:USD1, :32B:USD1,00
:33B:EUR2, :33B:USD0001,
C8 In any occurrence of sequence B, if field 33B is present and the currency codes in fields 32B and 33B
are different, then field 36 must be present. Otherwise, field 36 must not be present (Error code(s):
D75).
C9 If sequence C is present and if the amount in field 32B of sequence C is equal to the sum of the
amounts of the fields 32B of sequence B, then field 19 must not be present. Otherwise field 19 must be
present (Error code(s): D80).
C10 If field 19 is present in sequence C then it must be equal to the sum of the amounts in all occurrences of
field 32B in sequence B (Error code(s): C01).
C11 The currency code in fields 32B and 71G in sequences B and C must be the same for all occurrences of
these fields in the message (Error code(s): C02).
The currency code in the charges fields 71F (in sequences B and C) must be the same for all
occurrences of these fields in the message (Error code(s): C02).
C12 In sequence A, if field 23E is present and contains RFDD, then:
• in sequence A field 21R is optional
• and in sequence B the fields 21E, 50a (option A or K), 52a, 71F, 71G must not be present
• and sequence C must not be present.
31 August 2007 257

Otherwise, ie, in sequence A field 23E does not contain RFDD or field 23E is not present:
• in sequence A field 21R must not be present
• and in sequence B the fields 21E, 50a (option A or K), 52a, 71F, 71G are optional
• and sequence C must be present.
(Error code(s): C96)
Sequence B and fields

Sequence A Sequence A 21E, 50a (option A or
and sequence C is …
if field 23E is … then field 21R is … K), 52a, 71F and 71G
are …
Present and equals Optional Not allowed Not allowed

RFDD
Present and not equals Not allowed Optional Mandatory

RFDD
Not present Not allowed Optional Mandatory
C13 If field 23E in sequence A is present and contains RFDD, then field 119 of User Header must be
present and contain RFDD. If field 23E in sequence A is not present or does not contain RFDD, then
field 119 of User Header must not be present (Error code(s): C94).
Sequence A User Header

Present and equals RFDD Mandatory and must contain RFDD
Present and not equals RFDD Not allowed
MT 104 Guidelines
The MT 104 message can be exchanged in two different Message Users Groups (MUGs), depending on the
business scenario for which the message is used.
• The Direct Debit MUG, allows its subscribers to exchange Direct Debit instructions via an MT 104;
proceeds of the Direct Debits being credited to the Sender's account at the Receiver and ultimately to the
Ordering Customer/Instructing Party.
• The Request for Direct Debit MUG allows its subscribers to exchange request for Direct Debit instructions
via an MT 104; proceeds of these Direct Debits being directly credited to a customer's account maintained
at the Receiver.
Depending on the MUG that is used, certain fields are subject to special validation (see network validated
rules and field specifications). They can only be used by the institutions who have registered in the
corresponding MUG.
If the Sender has registered in the Request for Direct Debit MUG and wants to send a Request for Direct Debit
message, he must set the validation flag -field 119 of the User Header- of the message to "RFDD" which
indicates that the message is a Request for Direct Debit.
If the Sender has registered in the Direct Debit MUG and wants to send a Direct Debit message, he must not
use the validation flag -field 119 of the User Header- of the message.

MT 104
The MT 104 under the "Direct Debit Order" MUG
or
Creditor or Creditor
Instructing Party
50C 50A
or or
50L 50K
Creditor's Bank
52a
Sender
MT
Funds
MT 104
Debtor
Funds
59a
Receiver Funds
57a
Debtor
Funds Funds
59a
Debtor D0010042
59a
In this scenario there can be one or several instructing parties and one or several ordering customers ordering
direct debits to be processed in the receiving country with a repatriation of funds on sending bank's account
and then on the creditor's account.
31 August 2007 259

The MT 104 under the "Request for Direct Debit" MUG
or
Instructing Party
50C 50A
or or
50L 50K
Sender
Account
Relationship
MT
MT 104
Debtor
Funds
59a
Receiver Funds
57a
Debtor
Funds Funds
Funds 59a
Debtor
59a
Account Serving
D0010043
Institution 52a
If the following party is missing … Their function is assumed by …
Creditor's bank (field 52a) Sender (S) in the Direct Debit scenario Receiver (R) in
the Request for Direct Debit
Instructing Party (field 50C or 50L) Creditor (field 50A or 50K)
Debtor's bank (field 57a) Receiver (R)
The use of the MT 104 is subject to bilateral/multilateral agreements between the Sender and the Receiver.
Amongst other things, these bilateral agreements cover information about transaction amount limits and
definitions of direct debit schemes. The MT 104 Checklist at the end of this chapter is recommended as a
guide for institutions in the setup of their agreements.

FORMAT
16x

MT 104
PRESENCE
DEFINITION
T26).
USAGE RULES
This field must be unique for each message and is part of the file identification and transaction identification
which is used in case of queries, cancellations, etc.
2. Field 21R: Customer Specified Reference

FORMAT
Option R 16x
PRESENCE
DEFINITION
This field specifies the reference to the entire message assigned by either the:
• instructing party, when present or
• ordering customer, when the instructing party is not present.
T26).

FORMAT
Option E 4!c[/30x] (Type)(Additional Information)
PRESENCE
DEFINITION
This field identifies the type of the direct debit instructions contained in the message.
CODES
Type must contain one of the following codes (Error code(s): T47):
AUTH This message contains pre-authorised direct debit instructions to be processed according to the terms
and conditions of the direct debit contract and/or mandate.
NAUT This message contains non pre-authorised direct debit instructions.
OTHR Used for bilaterally agreed codes/information. The actual bilateral code/information will be specified
in the second subfield.
RFDD This message contains request for direct debit instructions.
RTND A previously sent MT 104 is being returned, ie, rejected, reversed or revoked.
31 August 2007 261


The narrative second subfield can only be used in combination with OTHR (Error code(s): D81).
4. Field 21E: Registration Reference

FORMAT
Option E 35x
PRESENCE
DEFINITION
This field contains the registration reference authorising a creditor to take part in a direct debit scheme.

FORMAT
6!n (Date)
PRESENCE
DEFINITION
This field specifies the requested execution date valid for all transactions contained in the MT 104. The
requested execution date is the date on which the Sender requests the Receiver to execute all transactions
contained in sequence B.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
USAGE RULES
message.
The content of field 20 Sender's reference together with the content of this field provides the file identification
which is to be used in the case of queries, cancellations, etc.

MT 104

FORMAT
Option C 4!a2!a2!c[3!c] (BIC/BEI)
PRESENCE
DEFINITION
This field specifies the customer which is authorised by the creditor/account servicing institution to order all
the transactions in the message.
T28, T29, T45).
USAGE RULES
This field must only be used when the instructing party is not also the creditor.
8. Field 50a: Creditor

FORMAT
PRESENCE
Conditional (see rules C2 and C4) in mandatory sequence A
DEFINITION
This field specifies the creditor whose account is to be credited with all transactions in sequence B. In case the
MT 104 is used under the request for Direct Debit scenario, this account is held at the Receiver. In all other
cases, the account is maintained at the Sender or the account servicing institution specified in field 52a.
T28, T29, T45).
USAGE RULES
At a minimum, the name or BIC/BEI of the creditor must be present. Under the Request for Direct Debit
scenario, Account is mandatory.
9. Field 52a: Creditor's Bank

FORMAT
4!a2!a2!c[3!c] (BIC)
31 August 2007 263

PRESENCE
DEFINITION
This field specifies the creditor's bank, even if field 50A or 50K contain an IBAN, which orders all
transactions in the message.
CODES

CODES


MT 104


T29, T45).
USAGE RULES
If the creditor's bank cannot be identified by a BIC, option C should be used containing a 2!a clearing system
code preceded by a double '//'.
Option D must only be used when there is a need to be able to specify a name and address, eg, due to
regulatory considerations.

FORMAT
Option T 3!c (Type)
PRESENCE
DEFINITION
This field identifies the nature of, purpose of, and/or reason for all transactions in the message, eg, invoices,
subscriptions, instalment payments.
USAGE RULES
The information given is intended both for regulatory and statutory requirements and to provide information to
the debtor on the nature of the transaction.
Codes must be agreed upon bilaterally.

FORMAT
In addition to narrative text, structured text with the following line formats may be used:
PRESENCE
31 August 2007 265

DEFINITION
country of the Receiver and/or the Sender.
CODES
When the residence of either creditor or debtor is to be identified, the following codes may be used, placed
between slashes ('/'):
BENEFRES Residence of debtor

ORDERRES Residence of creditor
USAGE RULES
Country consists of the ISO country code of the country of residence of the creditor or the debtor.
The information required is covered in the pre-established bilateral agreement between the Sender and the
Receiver.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges:
• under the Direct Debit scenario, for all transactions in the message.
• under the Request for Direct Debit scenario, for all subsequent direct debits contained in the message.
CODES
BEN All transaction charges are to be borne by the debtor.

OUR All transaction charges are to be borne by the creditor.
SHA Under the Direct Debit scenario, the following definition applies: Transaction charges on the Sender's
side are to be borne by the creditor, transaction charges on the Receiver's side are to be borne by the
debtor. The Sender and the Receiver should be understood as the Sender and the Receiver of the
MT 104. Under the Request for Direct Debit scenario, the following definition applies: All transaction
charges other than the charges of the Receiver servicing the creditor's account are borne by the debtor.
Receiver should be understood as Receiver of the MT 104 (RFDD).

FORMAT
6*35x (Narrative-Structured Format)

MT 104

or
PRESENCE
DEFINITION
This field specifies additional information for the Receiver, ie, Sender of the original message regarding the
reason for a return, ie, reversal, rejection or revocal.
CODES
The following codes must be used in this field in the first position of the first line, placed between slashes ('/').
It is mandatory to follow the Payments Reject/Return Guidelines described in the SWIFTStandards Usage
Guidelines (Error code(s): D82).
REJT Reject
RETN Return
USAGE RULES
The Reject/Return mechanism is used to reject or return all the transactions within the MT 104 message due to
for example non-compliance with the domestic scheme requirements. For rejects or returns of a single
transaction within the MT 104 (that is, sequence B), the MT 195 should be used as per the SWIFTStandards
Usage Guidelines.

FORMAT
16x
PRESENCE
DEFINITION
This field contains the unique reference for the individual transaction.
T26).
USAGE RULES
In related transactions the Sender's reference together with the content of this field provides the transaction
identification. This reference must be unique within one single message.

FORMAT
PRESENCE
31 August 2007 267

DEFINITION
This field identifies or further specifies the type of direct debit instruction in the same occurrence of sequence
B.
CODES
AUTH This occurrence of sequence B contains a pre-authorised direct debit instruction to be processed
according to the terms and conditions of the direct debit contract and/or mandate.
NAUT This occurrence of sequence B contains a non pre-authorised direct debit instruction.

16. Field 21C: Mandate Reference

FORMAT
Option C 35x
PRESENCE
DEFINITION
This field contains the reference of the direct debit mandate which has been agreed upon between the creditor
and the debtor.
17. Field 21D: Direct Debit Reference

FORMAT
Option D 35x
PRESENCE
DEFINITION
This field further identifies the direct debit transaction.

FORMAT
Option E 35x
PRESENCE
DEFINITION

MT 104
19. Field 32B: Currency and Transaction Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and the amount to be debited from the debtor's account, subject to addition of
charges if field 71A equals BEN or SHA. The debtor's account is identified in field 59a of the same occurrence
of sequence B.

FORMAT
PRESENCE
DEFINITION
This field specifies the customer which is authorised by the creditor/account servicing institution to order the
direct debit transaction in this particular occurrence of sequence B.
T28, T29, T45).
USAGE RULES
This field must only be used when the instructing party is not also the ordering customer.

FORMAT
Option K [/34x] (Party Identifier)
PRESENCE
Conditional (see rules C2, C4, and C12) in mandatory sequence B
DEFINITION
This field specifies the creditor whose account is to be credited with the direct debit transaction in this
particular occurrence of sequence B.
31 August 2007 269


T28, T29, T45).
USAGE RULES
At a minimum, the name or BIC/BEI of the creditor must be specified.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the creditor's bank, even if field 50A or 50K contain an IBAN, which orders the transaction
in the particular occurrence of sequence B.
CODES

CODES

MT 104


T29, T45).
USAGE RULES
23. Field 57a: Debtor's Bank

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
31 August 2007 271

DEFINITION
This field specifies the bank which holds the account(s) of the debtor and which will execute the associated
transaction in this occurrence of sequence B. This is applicable even if field 59A or 59 contains an IBAN.
CODES

CODES


MT 104


T29, T45).
USAGE RULES
When field 57a is not present, it means that the Receiver is also the debtor's bank
If the debtor's bank cannot be identified by a BIC, option C should be used containing a 2!a clearing system
When qualified by a clearing system code or an account number, the use of option D will enable the
automated processing of the instruction(s) by the Receiver.
24. Field 59a: Debtor

FORMAT
PRESENCE
DEFINITION
This field specifies the debtor whose account will be debited according to the direct debit instruction specified
in this occurrence of sequence B.
Although the presence of Account is optional in the field format, for the purpose of this message the Account
of the debtor must be present (Error code(s): E10).
T28, T29, T45).

FORMAT
4*35x (Narrative)
31 August 2007 273

PRESENCE
DEFINITION
This field specifies details of the individual direct debit which are to be transmitted to the debtor.
CODES
characters).
RFB Reference for the debtor (followed by up to 16 characters).
USAGE RULES
70.
The information specified in this field is intended only for the debtor, ie, this information only needs to be
conveyed by the Receiver.

FORMAT
Option T 3!c (Type)
PRESENCE
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the transaction in the particular occurrence of
sequence B, eg, invoices, subscriptions, instalment payments.
USAGE RULES

FORMAT
In addition to narrative text, structured text with the following line formats may be used:

MT 104
PRESENCE
DEFINITION
CODES
When the residence of either creditor or debtor is to be identified, the following codes may be used placed

USAGE RULES
Receiver.

FORMAT
PRESENCE
DEFINITION
This field specifies the original currency and amount as ordered by the creditor when different from the
transaction currency and amount specified in field 32B of the same occurrence of sequence B.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges:
• under the Direct Debit scenario, for the direct debit transaction in this particular occurrence of sequence B.
• under the Request for Direct Debit scenario, for the subsequent direct debit transaction in this particular
31 August 2007 275

CODES

SHA Under the Direct Debit scenario, the following definition applies: Transaction charges on the Sender's
side are to be borne by the creditor, transaction charges on the Receiver's side are to be borne by the
debtor. The Sender and the Receiver should be understood as the Sender and the Receiver of the
MT 104. Under the Request for Direct Debit scenario, the following definition applies: All transaction
charges other than the charges of the Receiver servicing the creditor's account are borne by the debtor.
Receiver should be understood as Receiver of the MT 104 (RFDD).

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and amount of the charges due to the Sender for the individual transaction.

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and amount of the charges due to the Receiver for the individual transaction.

FORMAT
12d (Rate)
PRESENCE

MT 104
DEFINITION
This field specifies the exchange rate used to convert the original ordered amount specified in field 33B into
the currency of the transaction amount (field 32B) in this occurrence of sequence B.
33. Field 32B: Currency and Settlement Amount

FORMAT
PRESENCE
Mandatory in conditional (see rule C12) sequence C
DEFINITION
This field specifies the currency and the total settlement amount.
USAGE RULES
If charges are settled immediately, the settlement amount may also include the total charges, if appropriate.
Because the field can only contain a 15d amount, care must be taken that transactions are only combined in a
single MT 104 which do not lead to a total amount that exceeds the 15d limit.

FORMAT
17d (Amount)
PRESENCE
Conditional (see rule C9) in conditional (see rule C12) sequence C
DEFINITION
This field specifies the sum of all transaction amounts appearing in field 32B in each occurrence of sequence
B.
allowed for the currency specified in field 32B (Error code(s): C03, T40, T43).
35. Field 71F: Sum of Sender's Charges

FORMAT
31 August 2007 277

PRESENCE
DEFINITION
This field specifies the total amount of the charges due to the Sender.

FORMAT
PRESENCE
DEFINITION
This field specifies the total amount of the charges due to the Receiver.

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional in conditional (see rule C12) sequence C
DEFINITION
This field specifies, where required, the account or branch of the Sender through which the Sender wants to be
reimbursed by the Receiver.
T29, T45).

MT 104
USAGE RULES
When there is a single direct account relationship, in the currency of the transaction, between the Receiver and
the Sender, and this is the account to be used for crediting the Sender, field 53a must not be present.
In those cases where there are multiple direct account relationships, in the currency of the transaction(s),
between the Receiver and the Sender, and one of these accounts is to be used for reimbursement, the account
to be credited must be indicated in field 53a, using option B (with the account number only).
If there is no direct account relationship, in the currency of the transaction, between the Receiver and the
Sender, then field 53a must be present (with a party identifier and bank identifier).
the currency of the transaction and the relationship between the Receiver and the branch of the Sender.
A branch of the Receiver may appear in field 53a if the financial institution where the funds must be credited
is both the Sender's correspondent and a branch of the Receiver. In this case, the Sender will be paid at the
Receiver's branch identified in field 53a.
In all other cases, when field 53a is present, a cover message (ie, MT202/203 or equivalent non-SWIFT) must
be sent by the Receiver to the financial institution identified in field 53a.
The use and interpretation of field 53a is, in all cases, dictated by the currency of the transaction and the
correspondent relationship between the Receiver and the Sender relative to that currency.
MT 104 Examples
Because the MT 104 can be used differently in different countries, no universal example can be provided.
A Country Section illustrating the use of the MT 104 in different countries is separately issued as Category 1 -
Usage Guidelines.
MT 104 Operational Rules and Checklist

This section provides a checklist which can be used by banks as a basis for setting up bilateral or multilateral
agreements for the processing of cross-border customer direct debit messages, ie, debit transfers transmitted
by MT 104 via FIN or FileAct.
facilitate the set up of these agreements, common procedures have been defined, which banks, if they wish,
may overwrite.
It is recommended that the law of the debtor's country be applied for the entire transaction, including any
rejections/revocations or reversals.
In order to properly effect cross-border debit transfers, it is highly recommended that the parties on the
creditor's side clearly understand the national practice of the debtor's country, eg, revocation deadlines. It is
therefore strongly recommended that banks consult the country section in addition to the list below to ensure
that all relevant items are covered in their bilateral agreements.
for it:
• Currencies accepted
• Transaction amount limit
• Settlement
31 August 2007 279

• Type(s) of debit transfer(s)

• Charging options and amounts
• Charges specifications in the MT 104
• Settlement procedures for charges
• Data transmission and bulking criteria
• Dates and time frames
• Message level controls
• Transaction level controls
• Rejects of messages and/or transactions
• Cancellations
• Modifications and changes

MT 105
MT 105 EDIFACT Envelope
MT 105 Scope
This message is sent by a financial institution to another financial institution. It is used as an envelope to
convey an EDIFACT message.

M 27 Sequence of Total 1!n/1!n 1
M 12 Sub-Message Type 3!n 4
M 77F EDIFACT Message 1800y 5

There are no network validated rules for this message type.
MT 105 Usage Rules

• When using this message you are requested to refer to the official Message Implementation Guidelines
(MIGs) which contain full details on the format specifications and field specifications.
• The use and content of this message is governed by an established bilateral agreement between the Sender
and Receiver.
• The SWIFT character set 'x' ONLY must be used in fields 27, 20, 21 and 12.
• The EDIFACT syntax and level A character set (the 'y' character set on the SWIFT Network), as defined in
the EDIFACT syntax rules (ISO 9735), must be used in field 77F.
• It may not be possible to fit the entire EDIFACT message to be embedded in field 77F into one MT 105.
When this is the case the EDIFACT message may be divided at any point within the text up to the
maximum field capacity for 77F of 1800 characters. An additional MT 105(s) should then be sent until the
entire EDIFACT message has been conveyed. An alternative is to utilise the greater capacity of the
MT 106. However, this is subject to a bilateral agreement between the Sender and Receiver.
• When more than one message is required to convey the details of the EDIFACT message embedded in field
77F the content of field 21 Related Reference of the MT 105 must be the same for all the messages in the
series.
31 August 2007 281

• It should be noted that, as is the case for all SWIFT messages, the last field in the message (77F) must be
followed by a 'CrLf-', to indicate 'End of Text'.
• It is recommended that EDIFACT messages be transported one at a time (ie, that two or more messages are
not put in a single MT 105).

1. Field 27: Sequence of Total
FORMAT
1!n/1!n (Message Number)(Sequence Number)
PRESENCE
Mandatory
DEFINITION
The sequence of total specifies the rank of this message in the series and the total number of messages in the
series.
USAGE RULES
When only one MT 105 is necessary the content of field 27 will be '1/1'.
A maximum number of 9 messages may be sent in a series, in the instance below the content of field 27 in the
last message of the series will be '9/9'.
EXAMPLE
In the second of three messages, field 27 will be '2/3'.
2. Field 20: Transaction Reference Number

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the Sender's unambiguous identification of the transaction.
T26).
USAGE RULES
The detailed form and content of this field are at the discretion of the Sender.
3. Field 21: Related Reference

FORMAT
16x
PRESENCE
Mandatory

MT 105
DEFINITION
This field contains the reference to the associated (enveloped) EDIFACT message.
T26).
USAGE RULES
The content of this field should reflect, up to a maximum of 16, the significant characters of the
Document/Message Number (Data Element 1004) in the Beginning of the Message (BGM) segment of the
EDIFACT message embedded in field 77F. When more than one MT 105 is sent to convey the EDIFACT
message, the content of field 21, must be the same for each MT 105 in the series.
This requirement is to facilitate the unambiguous re-association of the separate 'pages' of the transaction, and
also to provide a direct link to the EDIFACT message in case of further processing, eg, cancellation.
4. Field 12: Sub-Message Type

FORMAT
3!n
PRESENCE
Mandatory
DEFINITION
This field contains the identification of the EDIFACT message contained within field 77F by its recognized
numeric code.
CODES
The following list of codes is currently available for use in field 12 of the MT 105:
FINPAY Customer payment (Numeric code: to be allocated)

REMADV Remittance Advice (Numeric code: 381)
5. Field 77F: EDIFACT Message

FORMAT
Option F 1800y
PRESENCE
Mandatory
DEFINITION
This field contains the EDIFACT message being sent by the Sender to the Receiver.
USAGE RULES
For the purposes of this message, the EDIFACT syntax, as defined in the EDIFACT syntax rules (ISO 9735),
must be used in this field. Please refer to the appropriate volume of the EDIFACT Message Implementation
Guidelines (MIGs) for guidance on how to complete the EDIFACT message that will be contained in this
field.
When the content of field 27: Sequence of Total is other than 1/1, ie, more than one MT 105 is required to
convey the contents of the EDIFACT message, the EDIFACT message may be divided at any point up to the
maximum field capacity of 1800 characters.
31 August 2007 283

MT 106 Scope
This message is sent by a financial institution to another financial institution. It is used as an envelope to
convey an EDIFACT message.

M 27 Sequence of Total 1!n/1!n 1
M 12 Sub-Message Type 3!n 4
M 77G EDIFACT Message 9800y 5

MT 106 Usage Rules

• When using this message you are requested to refer to the official Message Implementation Guidelines
(MIGs) which contain full details on the format specifications and field specifications.
• The use and content of this message is governed by an established bilateral agreement between the Sender
and Receiver.
• The SWIFT character set 'x' ONLY must be used in fields 27, 20, 21 and 12.
• The EDIFACT syntax and level A character set (the 'y' character set on the SWIFT Network), as defined in
the EDIFACT syntax rules (ISO 9735), must be used in field 77G.
• It may not be possible to fit the entire EDIFACT message to be embedded in field 77G into one MT 106.
When this is the case the EDIFACT message may be divided at any point within the text up to the
maximum field capacity for 77G of 9800 characters. An additional MT 106(s) should then be sent until the
entire EDIFACT message has been conveyed.
• When more than one message is required to convey the details of the EDIFACT message embedded in field
77G the content of field 21 Related Reference of the MT 106 must be the same for all the messages in the
series.
• It should be noted that, as is the case for all SWIFT messages, the last field in the message (77G) must be
followed by a 'CrLf-', to indicate 'End of Text'.

MT 106
• It is recommended that EDIFACT messages be transported one at a time (i.e., that two or more messages
are not put in a single MT 106).

1. Field 27: Sequence of Total
FORMAT
1!n/1!n (Message Number)(Sequence Number)
PRESENCE
Mandatory
DEFINITION
The sequence of total specifies the rank of this message in the series and the total number of messages in the
series.
USAGE RULES
When only one MT 106 is necessary the content of field 27 will be '1/1'.
A maximum number of 9 messages may be sent in a series, in the instance below the content of field 27 in the
last message of the series will be '9/9'.
EXAMPLE
In the second of three messages, field 27 will be '2/3'.

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the Sender's unambiguous identification of the transaction.
T26).
USAGE RULES
Its detailed form and content are at the discretion of the Sender.
3. Field 21: Related Reference

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the reference to the associated (enveloped) EDIFACT message.
31 August 2007 285

USAGE RULES
The content of this field should reflect, up to a maximum of 16, the significant characters of the
Document/Message Number (Data Element 1004) in the Beginning of Message (BGM) segment of the
EDIFACT message embedded in field 77G. When more than one MT 106 is sent to convey the EDIFACT
message the content of field 21 must be the same for each MT 106 in the series.
This requirement is to facilitate the unambiguous re-association of the separate 'pages' of the transaction, and
also to provide a direct link to the EDIFACT message in case of further processing.
4. Field 12: Sub-Message Type

FORMAT
3!n
PRESENCE
Mandatory
DEFINITION
This field contains the identification of the EDIFACT message contained within field 77G by its recognized
numeric code.
CODES
The following list of codes is currently available for use in field 12 of the MT 106:
FINPAY Customer payment (Numeric code: to be allocated)

REMADV Remittance Advice (Numeric code: 381)
5. Field 77G: EDIFACT Message

FORMAT
Option G 9800y
PRESENCE
Mandatory
DEFINITION
This field contains the EDIFACT message being sent by the Sender to the Receiver.
USAGE RULES
For the purposes of this message, the EDIFACT syntax, as defined in the EDIFACT syntax rules (ISO 9735),
must be used in this field. Please refer to the appropriate volume of the EDIFACT Message Implementation
Guidelines (MIGs) for guidance on how to complete the EDIFACT message that will be contained in this
field.
When the content of field 27: Sequence of Total is other than 1/1, ie, more than one MT 106 is required to
convey the contents of the EDIFACT message, the EDIFACT message may be divided at any point up to the
maximum field capacity of 9800 characters.

MT 107
MT 107 General Direct Debit Message
MT 107 Scope
This message is sent by the creditor's financial institution or another financial institution, to the debtor's
financial Institution or another financial institution, on behalf of the creditor, to order the debit of the debtor's
account and to collect payment from this account.

• Sequence B Transaction Details is a repetitive mandatory sequence; each occurrence provides details of
one individual transaction. Fields which appear in both sequences A and B are mutually exclusive.
• Sequence C Settlement Details is a single occurrence mandatory sequence and provides further settlement
information for all transactions mentioned in sequence B.
MT 107 General Direct Debit Message


4!a2!a2!c[3!c]
31 August 2007 287

O 21C Mandate Reference 35x 15
O 21D Direct Debit Reference 35x 16
M 32B Currency and Transaction Amount 3!a15d 18
O 57a Debtor's Bank A, C, or D 22
M 59a Debtor No letter option or A 23
M 32B Currency and Settlement Amount 3!a15d 32
O 71F Sum of Sender's Charges 3!a15d 34

C1 Fields 23E and the second occurrence field 50a (option A or K) must, independently of each other, be
present either in sequence A or in each occurrence of sequence B, but not in both (Error code(s): D86):

MT 107

Present Not allowed

if field 50a (option A or K) is … then field 50a (option A or K) is …
Present Not allowed
C2 When present in sequence A, fields 21E, 26T, 77B, 71A, 52a and 50a (option C or L) must,
independently of each other, not be present in any occurrence of sequence B. When present in one or
more occurrences of sequence B, fields 21E, 26T, 77B, 71A, 52a and 50a (option C or L) must not be
present in sequence A (Error code(s): D73):
Present Not allowed
Present Not allowed
Present Not allowed
Present Not allowed
31 August 2007 289

Present Not allowed
Present Not allowed
C3 If field 21E is present in sequence A, then field 50a (option A or K), must also be present in sequence
A. In each occurrence of sequence B, if field 21E is present, then field 50a (option A or K) must also be
present in the same occurrence (Error code(s): D77):
Present Mandatory
Present Mandatory
C4 In sequence A, if field 23E is present and contains RTND then field 72 must be present, in all other
cases - ie, field 23E not present, or field 23E does not contain RTND - field 72 is not allowed (Error
code(s): C82):
equals RTND Mandatory
not equals RTND Not allowed
C5 If, independently of each other, fields 71F and 71G are present in one or more occurrence of sequence
B, then they must also be present in sequence C, and vice versa (Error code(s): D79):

MT 107
if field 71F is … then field 71F is …
Present Mandatory
if field 71G is … then field 71G is …
Present Mandatory
C6 In each occurrence of sequence B, if field 33B is present, then the currency code or the amount, or both,
must be different between fields 33B and 32B (Error code(s): D21).
Examples:
Valid Invalid
:32B:USD1, :32B:USD1,
:33B:USD2, :33B:USD0001,
:32B:USD1, :32B:USD1,
:33B:EUR1, :33B:USD1,00
:32B:USD1, :32B:USD1,00
:33B:EUR2, :33B:USD0001,
C7 In any occurrence of sequence B, if field 33B is present and the currency codes in fields 32B and 33B
are different, then field 36 must be present. Otherwise, field 36 must not be present (Error code(s):
D75).
C8 The sum of the amounts of fields 32B in sequence B must be put either in field 32B of sequence C
when no charges are included, or be put in field 19 of sequence C. In the former case, field 19 must not
be present (Error code(s): D80). In the latter case, Field 19 must equal the sum of the amounts in all
occurrences of field 32B in sequence B (Error code(s): C01).
C9 The currency code in fields 32B and 71G in sequences B and C must be the same for all occurrences of
these fields in the message (Error code(s): C02).
The currency code in the charges fields 71F (in sequences B and C) must be the same for all
occurrences of these fields in the message (Error code(s): C02).
MT 107 Usage Rules

The entire chain of parties and the transaction flow is illustrated by the following figure:
31 August 2007 291

or
Instructing Party
50C 50A
or or
50L 50K
Creditor's Bank
52a
Sender
MT
Funds
MT 107
Debtor
Funds
59a
Receiver Funds
57a
Debtor
Funds Funds
59a
Debtor
59a D0010044
If the following party is missing … Their function is assumed by …
Creditor's bank (field 52a) Sender
Instructing Party (field 50C or 50L) Creditor (field 50A or 50K)
Debtor's bank (field 57a) Receiver
The use of the MT 107 is subject to bilateral/multilateral agreements between the Sender and the Receiver.
Amongst other things, these bilateral agreements cover information about transaction amount limits and
definitions of direct debit schemes. The MT 107 Checklist at the end of this chapter is recommended as a
guide for institutions in the setup of their agreements.

MT 107

FORMAT
16x
PRESENCE
DEFINITION
T26).
USAGE RULES
This field must be unique for each message and is part of the file identification and transaction identification
which is used in case of queries, cancellations, etc.

FORMAT
PRESENCE
DEFINITION
This field identifies the type of the direct debit instructions contained in the message.
CODES
Type must contain one of the following codes (Error code(s): T47):
AUTH This message contains pre-authorised direct debit instructions to be processed according to the terms
and conditions of the direct debit contract and/or mandate.
NAUT This message contains non pre-authorised direct debit instructions.
RTND A previously sent MT 107 is being returned, ie, rejected, reversed or revoked.


FORMAT
Option E 35x
PRESENCE
31 August 2007 293

DEFINITION

FORMAT
6!n (Date)
PRESENCE
DEFINITION
This field specifies the requested execution date valid for all transactions contained in the MT 107. The
requested execution date is the date on which the Sender requests the Receiver to execute all transactions
contained in sequence B.
Date must be a valid date expressed as YYMMDD. (Error code(s): T50).

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
USAGE RULES
message.

FORMAT
PRESENCE
DEFINITION
This field specifies the instructing party ordering all transactions of the message.
T28, T29, T45).

MT 107
USAGE RULES

FORMAT
PRESENCE
Conditional (see rules C1 and C3) in mandatory sequence A
DEFINITION
This field specifies the creditor ordering all transactions in the message.
At least one line of the Name and Address must be present (Error code(s): T77).
T28, T29, T45).
USAGE RULES
The name of the creditor must be specified. If the account of the creditor is present, it must be specified in
Account.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the creditor's bank, even if field 50A or 50K contain an IBAN, which orders all
transactions in the message.
CODES

31 August 2007 295


CODES


T29, T45).
USAGE RULES

MT 107

FORMAT
Option T 3!c (Type)
PRESENCE
DEFINITION
This field identifies the nature of, purpose of, and/or reason for all transactions in the message, eg, invoices,
subscriptions, installment payments.
USAGE RULES

FORMAT

PRESENCE
DEFINITION
CODES
When the residence of either creditor or debtor is to be identified, the following codes may be used, placed

USAGE RULES
Receiver.
31 August 2007 297


FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges for all transactions in the message.
CODES
One of the following codes must be used (Error code(s): T08)

SHA Transaction charges on the Sender's side are to be borne by the creditor, transaction charges on the
Receiver's side are to be borne by the debtor. The Sender and the Receiver should be understood as the
Sender and the Receiver of the MT 107.

FORMAT

or
PRESENCE
DEFINITION
This field specifies additional information for the Receiver, ie, Sender of the original message regarding the
reason for a return, ie, reversal, rejection or revocation of the whole message.
CODES
The following codes must be used in this field in the first position of the first line, placed between slashes ('/')
. It is mandatory to use these codes according to the Payments Reject/Return Guidelines described in the
SWIFTStandards Usage Guidelines (Error code(s): T82).
REJT Reject
RETN Return
USAGE RULES
The Reject/Return mechanism is used to reject or return all the transactions within the MT 107 message due to
for example non-compliance with the domestic scheme requirements. For rejects or returns of a single
transaction within the MT 107 (that is, sequence B), the MT 195 should be used as per the SWIFTStandards
Usage Guidelines.

MT 107

FORMAT
16x
PRESENCE
DEFINITION
This field contains the unique reference for the individual transaction.
T26).
USAGE RULES
In related transactions the Sender's reference together with the content of this field provides the transaction
identification.

FORMAT
PRESENCE
DEFINITION
This field identifies the type of direct debit instruction in the occurrence of sequence B.
CODES
AUTH This occurrence of sequence B contains a pre-authorised direct debit instruction to be processed
according to the terms and conditions of the direct debit contract and/or mandate.
NAUT This occurrence of sequence B contains a non pre-authorised direct debit instruction.

15. Field 21C: Mandate Reference

FORMAT
Option C 35x
PRESENCE
DEFINITION
This field contains the reference of the direct debit mandate which has been agreed upon between the creditor
and the debtor.
31 August 2007 299

16. Field 21D: Direct Debit Reference

FORMAT
Option D 35x
PRESENCE
DEFINITION
This field further identifies the direct debit transaction.

FORMAT
Option E 35x
PRESENCE
DEFINITION
18. Field 32B: Currency and Transaction Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and the amount to be debited from the debtor's account, subject to addition of
charges if field 71A equals BEN or SHA. The debtor's account is identified in field 59a of the same occurrence
of sequence B.

FORMAT
PRESENCE
DEFINITION
This field specifies the instructing party ordering the transaction in this particular occurrence of sequence B.

MT 107

T28, T29, T45).
USAGE RULES

FORMAT
PRESENCE
DEFINITION
This field specifies the creditor ordering the transaction in this particular occurrence of sequence B.
At least one line of the Name and Address must be present (Error code(s): T77).
T28, T29, T45).
USAGE RULES
At a minimum, the name of the creditor must be specified. If the account of the creditor is present, it must be
specified in Account.

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the creditor's bank, even if field 50A or 50K contain an IBAN, which orders the transaction
in this particular occurrence of sequence B.
CODES
31 August 2007 301


CODES


T29, T45).

MT 107
USAGE RULES
22. Field 57a: Debtor's Bank

FORMAT
4!a2!a2!c[3!c] (BIC)
PRESENCE
DEFINITION
This field specifies the bank which holds the account(s) of the debtor and which will execute the associated
transaction in this occurrence of sequence B. This is applicable even if field 59A or 59 contains an IBAN.
CODES

CODES
31 August 2007 303



T29, T45).
USAGE RULES
When field 57a is not present, it means that the Receiver is also the debtor's bank
If the debtor's bank cannot be identified by a BIC, option C should be used containing a 2!a clearing system
When qualified by a clearing system code or an account number, the use of option D will enable the
automated processing of the instruction(s) by the Receiver.

MT 107
23. Field 59a: Debtor

FORMAT
PRESENCE
DEFINITION
This field specifies the debtor whose account will be debited according to the direct debit instruction specified
in this occurrence of sequence B.
Account of the debtor must be present (Error code(s): E10).
T28, T29, T45).

FORMAT
4*35x (Narrative)
PRESENCE
DEFINITION
This field specifies details of the individual direct debit which are to be transmitted to the debtor.
CODES
characters).
RFB Reference for the debtor (followed by up to 16 characters).
USAGE RULES
70.
The information specified in this field is intended only for the debtor, ie, this information only needs to be
conveyed by the Receiver.
31 August 2007 305


FORMAT
Option T 3!c (Type)
PRESENCE
DEFINITION
This field identifies the nature of, purpose of, and/or reason for the transaction in the particular occurrence of
sequence B, eg, invoices, subscriptions, instalment payments.
USAGE RULES

FORMAT

PRESENCE
DEFINITION
CODES
When the residence of either creditor or debtor is to be identified, the following codes may be used placed

USAGE RULES
Receiver.

FORMAT

MT 107
PRESENCE
DEFINITION
This field specifies the original currency and amount as ordered by the creditor when different from the
transaction currency and amount specified in field 32B of the same occurrence of sequence B.

FORMAT
Option A 3!a (Code)
PRESENCE
DEFINITION
This field specifies which party will bear the charges for the transaction in this particular occurrence of
sequence B.
CODES

SHA Transaction charges on the Sender's side are to be borne by the creditor, transaction charges on the
Receiver's side are to be borne by the debtor. The Sender and the Receiver should be understood as the
Sender and the Receiver of the MT 107.

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and amount of the charges due to the Sender for the individual transaction.
31 August 2007 307


FORMAT
PRESENCE
DEFINITION
This field specifies the currency and amount of the charges due to the Receiver for the individual transaction.

FORMAT
12d (Rate)
PRESENCE
DEFINITION
This field specifies the exchange rate used to convert the original ordered amount specified in field 33B into
the currency of the transaction amount (field 32B) in this occurrence of sequence B.
32. Field 32B: Currency and Settlement Amount

FORMAT
PRESENCE
DEFINITION
This field specifies the currency and the total settlement amount.
USAGE RULES
If charges are settled immediately, the settlement amount may also include the total charges, if appropriate.

MT 107
Because the field can only contain a 15d amount, care must be taken that transactions are only combined in a
single MT 107 which do not lead to a total amount that exceeds the 15d limit.

FORMAT
17d (Amount)
PRESENCE
DEFINITION
This field specifies the sum of all transaction amounts appearing in field 32B in each occurrence of sequence
B.
allowed for the currency specified in field 32B (Error code(s): C03, T40, T43).
34. Field 71F: Sum of Sender's Charges

FORMAT
PRESENCE
DEFINITION
This field specifies the total amount of the charges due to the Sender.

FORMAT
PRESENCE
DEFINITION
This field specifies the total amount of the charges due to the Receiver.
31 August 2007 309


FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
DEFINITION
This field specifies, where required, the account or branch of the Sender through which the Sender wants to be
reimbursed by the Receiver.
T29, T45).
USAGE RULES
When there is a single direct account relationship, in the currency of the transaction, between the Receiver and
the Sender, and this is the account to be used for crediting the Sender, field 53a must not be present.
In those cases where there are multiple direct account relationships, in the currency of the transaction(s),
between the Receiver and the Sender, and one of these accounts is to be used for reimbursement, the account
to be credited must be indicated in field 53a, using option B (with the account number only).
If there is no direct account relationship, in the currency of the transaction, between the Receiver and the
Sender, then field 53a must be present (with a party identifier and bank identifier).
the currency of the transaction and the relationship between the Receiver and the branch of the Sender.
A branch of the Receiver may appear in field 53a if the financial institution where the funds must be credited
is both the Sender's correspondent and a branch of the Receiver. In this case, the Sender will be paid at the
Receiver's branch identified in field 53a.
In all other cases, when field 53a is present, a cover message (ie, MT 202/203 or equivalent non-SWIFT) must
be sent by the Receiver to the financial institution identified in field 53a.
The use and interpretation of field 53a is, in all cases, dictated by the currency of the transaction and the
correspondent relationship between the Receiver and the Sender relative to that currency.
MT 107 Examples
Because the MT 107 can be used differently in different countries, no universal example can be provided.
A Country Section illustrating the use of the MT 107 in different countries is separately issued as Category 1 -
Usage Guidelines.

MT 107
MT 107 Operational Rules and Checklist

This section provides a checklist which can be used by banks as a basis for setting up bilateral or multilateral
agreements for the processing of cross-border customer direct debit messages, ie, debit transfers transmitted
by MT 107 via FIN or FileAct.
facilitate the set up of these agreements, common procedures have been defined, which banks, if they wish,
may overwrite.
It is recommended that the law of the debtor's country be applied for the entire transaction, including any
rejections/revocations or reversals.
In order to properly effect cross-border debit transfers, it is highly recommended that the parties on the
creditor's side clearly understand the national practice of the debtor's country, eg, revocation deadlines. It is
therefore strongly recommended that financial institutions consult the country section in addition to the list
below to ensure that all relevant items are covered in their bilateral agreements.
for it:
• Currencies accepted
• Transaction amount limit
• Settlement
• Type(s) of debit transfer(s)
• Charging options and amounts
• Charges specifications in the MT 107
• Settlement procedures for charges
• Data transmission and bulking criteria
• Dates and time frames
• Message level controls
• Transaction level controls
• Rejects of messages and/or transactions
• Cancellations
• Modifications and changes
31 August 2007 311

MT 110 Advice of Cheque(s)
MT 110 Scope
This multiple message is sent by a drawer bank, or a bank acting on behalf of the drawer bank to the bank on
which a/several cheque(s) has been drawn (the drawee bank).
It is used to advise the drawee bank, or confirm to an enquiring bank, the details concerning the cheque(s)
referred to in the message.

MT 110 Advice of Cheque(s)
O 53a Sender's Correspondent A, B, or D 2
O 54a Receiver's Correspondent A, B, or D 3
----->
M 21 Cheque Number 16x 5
M 30 Date of Issue 6!n 6
M 32a Amount A or B 7
O 52a Drawer Bank A, B, or D 8
M 59 Payee [/34x] 9
4*35x
-----|

C1 The repetitive sequence must not be present more than ten times (Error code(s): T10).
C2 The currency code in the amount field 32a must be the same for all occurrences of this field in the
message (Error code(s): C02).

FORMAT
16x

MT 110
PRESENCE
Mandatory
DEFINITION
T26).

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional
DEFINITION
This field specifies the account or branch of the Sender or another bank through which the Sender will
reimburse the Receiver.
T29, T45).
USAGE RULES
The absence of fields 53a and 54a implies that the single direct account relationship between the Sender and
the Receiver, in the currency of the cheques, will be used.
credited or debited must be indicated in field 53a, using option B with the party identifier only.
Receiver (or branch of the Receiver when specified in field 54a), then field 53a must be present.
54a, if present.
In all other cases, when field 53a is present, a cover message, ie MT 202/203 or equivalent non-SWIFT, must
31 August 2007 313

3. Field 54a: Receiver's Correspondent

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional
DEFINITION
This field specifies the branch of the Receiver or another bank at which the funds will be made available to the
Receiver.
T29, T45).
USAGE RULES
The absence of fields 53a and 54a implies that the single direct account relationship between the Sender and
the Receiver, in the currency of the cheques, will be used.
In those cases where field 54a contains a branch of the Receiver, and is not preceded by field 53a, or field 53a
from its branch.
If field 54a contains a branch of the Receiver and field 53a contains a branch of the Sender, the Receiver will
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.
the Receiver, field 54a must not be present.
Field 54a containing the name of a financial institution other than the Receiver's branch must be preceded 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 transaction and

MT 110

FORMAT
6*35x (Narrative)
In addition to narrative text, structured text with the following formats may be used:

or
PRESENCE
Optional
DEFINITION
CODES
Unless bilaterally agreed otherwise between the Sender and the Receiver, one of the following codes must be
used placed between slashes ('/'):
ACC Instructions following are for the account with institution.

INT Instructions following are for the intermediary institution.
REC Instructions following are for the Receiver of the message.
USAGE RULES
Use of field 72, particularly with uncoded instructions, may cause delay, because, in automated systems, the
presence of this field will normally require manual intervention.
It is strongly recommended to use the standard codes proposed above. However, where bilateral agreements
covering the use of codes in this field are in effect, the code must conform to the structure of this field.
field.
This field may include ERI to transport dual currencies, as specified in the chapter entitled "Euro-Impact on
Category 1 Message Standards".
In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may
be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes,
followed by the exchange rate, format 12d, and terminated with another slash.
31 August 2007 315

EXAMPLE
:72:/INS/ABNANL2A
5. Field 21: Cheque Number

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the number of the cheque being advised.
T26).
6. Field 30: Date of Issue

FORMAT
6!n (Date)
PRESENCE
Mandatory
DEFINITION
This field contains the date on which the cheque was drawn.
7. Field 32a: Amount

FORMAT
PRESENCE
Mandatory
DEFINITION
This field specifies the currency and amount of the cheque for which the Sender has credited the Receiver with
the cheque amount; it may also specify the value date.
Currency must be the same for all occurrences of this field in the message (Error code(s): C02).

MT 110
USAGE RULES
Option A will be used when the Sender has credited the Receiver with the cheque amount.
8. Field 52a: Drawer Bank

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional
DEFINITION
This field identifies the drawer bank.
CODES

CODES
In option B, or D, Party Identifier may be used to indicate a national clearing system code.

31 August 2007 317



T29, T45).
USAGE RULES
This field is used when the drawer bank is a branch of the Sender or a bank other than the Sender of the
message.
9. Field 59: Payee

FORMAT
[/34x] (Account)
PRESENCE
Mandatory
DEFINITION
This field identifies the beneficiary of the cheque.
USAGE RULES
Account must not be used.

MT 110
MT 110 Examples
Single Advice of Cheque
Narrative
On December 11, 2009, Citibank, Los Angeles, issues its cheque number 9100089, drawn on Citibank, New
York's account with Dresdner Bank A.G., Frankfurt.
The cheque is in the amount of euro 1,800. The payee is Gunther Heiliger, Marburg.
Citibank sends an MT 110 to Dresdner Bank, advising it of the cheque, under reference DR98121110192.
Information Flow
Sender Citibank
(Drawer Bank) Los Angeles
MT
Sender's MT 110 Citibank

Cheque
Receiver Dresdner Bank
(Drawee Bank) Frankfurt
Payee Gunther Heiliger

59
D0010038
SWIFT Message
Explanation Format
Sender CITIUS33LAX
Message type 110
Receiver DRESDEFF
Message text
Transaction reference number :20:DR09121110192
Sender's correspondent (1) :53A:CITIUS33
Number of the cheque :21:9100089
Date the cheque was issued :30:091211
31 August 2007 319

Explanation Format
Currency and amount of cheque :32B:EUR1800,
Payee of the cheque :59:GUNTHER HEILIGER

MARBURG
(1) Field 53A indicates the bank for which the Receiver services an account, which is to be used for
reimbursement.
Multiple Advice of Cheque(s)
Narrative
On August 5, 2009, KBC, Brussels, advises Lloyds Bank, London (reference CHQ293844), of several
cheques, issued by its branches, as follows:
Number Date Amount Branch Payee
(1) G304987 09/07/31 GBP 135.66 Leuven Peter Bogaert Leuven

(KREDBEBB100)
(2) G304988 09/08/03 GBP 523.00 Leuven Anna Smythe Leuven
(3) G305766 09/08/04 GBP 324.00 Brugge (KREDBE88) Georg Grut Brugge

MT 110
Information Flow
KBC KBC
Leuven Brugge
(Drawer Bank) (Drawer Bank)
52a 52a
Sender KBC
Brussels
MT
Cheques Cheque
MT 110
Receiver Lloyds Bank

London
Payee
59 59 59
D0010039
Peter Bogaert Anna Smythe Georg Grut
Leuven Leuven Brugge
SWIFT Message
Explanation Format
Sender KREDBEBB
Message type 110
Receiver LOYDGB2L
Message text
Transaction reference number :20:CHQ293844
Number of the cheque :21:G304987
Currency and amount of cheque :32B:GBP135,66
Drawer bank :52A:KREDBEBB100
Payee of the cheque :59:PETER BOGAERT

LEUVEN
31 August 2007 321

Explanation Format
Currency and amount of cheque :32B:GBP523,
Drawer bank :52A:KREDBEBB100
Payee of the cheque :59:ANNA SMYTHE

LEUVEN
Currency and amount of cheque :32B:GBP324,
Drawer bank :52A:KREDBE88
Payee of the cheque :59:GEORGE GRUT

BRUGGE

MT 111
MT 111 Request for Stop Payment of a Cheque
MT 111 Scope
This single message type is sent by a drawer bank, or a bank acting on behalf of the drawer bank, to the bank
on which a cheque has been drawn (the drawee bank).
It is used to request stop payment of the cheque referred to in the message.

MT 111 Request for Stop Payment of a Cheque
O 59 Payee [/34x] 6
4*35x
O 75 Queries 6*35x 7

MT 111 Usage Rules

• This message must not be used to request stop payment of a cheque which was issued without a specified
payee.
• This message always requires a response, preferably by an MT 112 Status of a Request for Stop Payment
of a Cheque.
MT 111 Guidelines
Information concerning national policies and procedures for stop payments may be found in the General
Information Section (green) of the International Bank Identifier Code Directory (BIC Directory).
31 August 2007 323


FORMAT
16x
PRESENCE
Mandatory
DEFINITION
T26).

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the number of the cheque for which stop payment is being requested.
T26).

FORMAT
6!n (Date)
PRESENCE
Mandatory
DEFINITION

FORMAT
PRESENCE
Mandatory

MT 111
DEFINITION
This field specifies the currency and amount of the cheque; it may also specify the value date.
USAGE RULES
When an MT 110 has been sent for the referenced cheque, the contents of this field must be the same as in the
MT 110.
When no MT 110 has been sent, Option A will be used when the Sender has previously credited the Receiver
with the cheque amount.
In all other cases, option B will be used.

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional
DEFINITION
This field identifies the drawer bank.
CODES

31 August 2007 325


CODES


T29, T45).
USAGE RULES
This field is used when the drawer bank is a branch of the Sender or a bank other than the Sender of the
message.

MT 111
6. Field 59: Payee

FORMAT
[/34x] (Account)
PRESENCE
Optional
DEFINITION
USAGE RULES
7. Field 75: Queries

FORMAT
6*35x (Narrative)
PRESENCE
Optional
DEFINITION
This field may contain either the reason for stopping the payment of the cheque or a request for reimbursement
authorisation.
CODES
The following code numbers have been defined for this message:
/3/ We have been advised that the beneficiary did not receive payment/cheque. Please state if and when
the transaction was effected.
/18/ Please authorise us to debit your account.
/19/ Please refund cover to credit of (1) … (account/place).
/20/ Cheque/draft not debited as of closing balance of statement (1) … (number) dated (2) …
(YYMMDD).
/21/ Cheque has been stolen/lost.
USAGE RULES
Where a message contains more than one query, each query must appear on a separate line.
Numbers in brackets, eg, (1), mean that supplementary information is required. This supplementary
information must be the first information following the code number.
When supplement (2) is used, ie, two different pieces of supplementary information are provided, the second
piece of information should be preceded by a slash '/'.
MT 111 Examples
Narrative
On January 14, 2009, Citibank, Los Angeles, issues a request for a stop payment on cheque number 9100089,
drawn on Citibank, New York's account with Dresdner Bank A.G., Frankfurt.
31 August 2007 327

The draft has apparently been lost in transit.

Citibank sends an MT 111 to Dresdner Bank, under reference 41387931STP.
Information Flow
Sender Citibank
MT
MT 111
Receiver Dresdner Bank

D0010040
SWIFT Message
Explanation Format
Sender CITIUS33
Message type 111
Receiver DRESDEFF
Message text
Transaction reference number :20:41387931STP
Payee of the cheque :59:GUNTHER HEILIGER MARBURG
Reason for stop payment request :75:/21/

MT 112
MT 112 Status of a Request for Stop Payment of a Cheque
MT 112 Scope
This message type is sent by the drawee bank (on which a cheque is drawn) to the drawer bank or the bank
acting on behalf of the drawer bank.
It is used to indicate what actions have been taken in attempting to stop payment of the cheque referred to in
the message.

MT 112 Status of a Request for Stop Payment of a Cheque
O 59 Payee [/34x] 6
4*35x
M 76 Answers 6*35x 7

MT 112 Usage Rules

This message may respond to an earlier MT 111 Request for Stop Payment of a Cheque.

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
31 August 2007 329


T26).

FORMAT
16x
PRESENCE
Mandatory
DEFINITION
This field contains the number of the cheque to which this message refers.
T26).

FORMAT
6!n (Date)
PRESENCE
Mandatory
DEFINITION

FORMAT
PRESENCE
Mandatory
DEFINITION
This field identifies the currency and amount of the cheque; it may also specify the value date.

MT 112
USAGE RULES
When the message is in response to an MT 111 Request for Stop Payment of a Cheque, the contents of this
field must be the same as field 32a of the MT 111.
If the request for stop payment has not been received via an MT 111, option A will be used when the drawer
bank has previously credited the drawee bank with the cheque amount. It contains the value date, currency
code and amount of the cheque.
In all other cases, option B must be used.

FORMAT
4!a2!a2!c[3!c] (BIC)
[35x] (Location)
PRESENCE
Optional
DEFINITION
This field identifies the drawer bank when other than the Sender.
CODES

CODES
31 August 2007 331



T29, T45).
USAGE RULES
This field will be used when the drawer bank is a branch of the Receiver or a bank other than the Receiver of
the message.
6. Field 59: Payee

FORMAT
[/34x] (Account)
PRESENCE
Optional
DEFINITION

MT 112
USAGE RULES
7. Field 76: Answers

FORMAT
6*35x (Narrative)
PRESENCE
Mandatory
DEFINITION
This field must include information as to whether or not the stop payment has been effected. In addition, a
response should be given to any request for reimbursement authorisation.
CODES
The following answer code numbers have been defined.
/2/ We hereby confirm that the transaction has been effected and advised on (1) … in response to
(YYMMDD). Query 3 or 20
/10/ We authorise you to debit our account. in response to
Query 18
/11/ Cover refunded to the credit of (1) … (account/place). in response to
Query 19
/12/ Stop instructions are not acceptable. (Reason).
/13/ Stop instructions duly recorded. (Further details, where applicable). in response to
Query 21
/14/ Stop instructions valid until (1) … (YYMMDD).
USAGE RULES
Where a message contains more than one answer, each answer must appear on a separate line.
Numbers in brackets, eg, (1), mean that supplementary information is required. This supplementary
information must be the first information following the code number.
MT 112 Examples
Narrative
On January 15, 2010, Dresdner Bank, Frankfurt, confirms the placement of its stop payment on draft number
9800089, drawn on Citibank, New York's account.
Dresdner Bank sends an MT 112 to Citibank, Los Angeles, under reference 287299329892.
31 August 2007 333

Information Flow
Sender Dresdner Bank

MT
(MT 111)
MT 112
Receiver Citibank
D0010041
SWIFT Message
Explanation Format
Sender DRESDEFF
Message type 112
Receiver CITIUS33
Message text
Payee of the cheque :59:GUNTHER HEILIGER

MARBURG
Answer (1) :76:/13/

/14/090711
(1) /13/ is confirmation that the stop payment has been effected; /14/ indicates the date until which the stop
payment will be in effect.

MT 121
MT 121 Multiple Interbank Funds Transfer (EDIFACT FINPAY

Message)
MT 121 Scope
This message is used by a financial institution to send an EDIFACT FINPAY message to another financial
institution.

This message has no predefined SWIFT format. The complete text block - up to the defined maximum number
of characters - is available for the contents of the EDIFACT FINPAY message. No SWIFT specific field tags
are used. The resulting text block will appear as '{4:yyy … yyyCrLf-}' where '{4:' is the text block header,
'yyy … yyy' represents the EDIFACT FINPAY message and 'CrLf-}' is the text block trailer.
MT 121 Multiple Interbank Funds Transfer (EDIFACT FINPAY Message)

M none EDIFACT FINPAY Message Contents 9900y 1

MT 121 Guidelines
• It is recommended to implement the EDIFACT FINPAY message with the segments of the currently
accepted EDIFACT directory. Any deviation should be governed by a bilateral agreement between the
Sender and the Receiver.
• This message cannot be used for EDIFACT FINPAY messages exceeding the maximum length specified
above. Longer EDIFACT FINPAY messages can, however, be sent using multiple MT 106s.
• Retrieval of this message will be possible according to all normal criteria except field 20 Transaction
Reference Number.
• Control of delivery of this message will be possible according to all normal criteria. When control of
delivery is based on the message category, this message will be grouped with the other Category 1
messages.
• In common group messages, the MT 121 can only be described using a narrative description because this
message contains no tagged mandatory field and the common group messages do not support the 'y'
character set. Wherever, field 21 Related Reference is mandatory in the common group message, it is
recommended to use the text 'EDIFACT FINPAY' because the MT 121 does not contain a field 20
Transaction Reference Number and the common group messages do not support the 'y' character set.
31 August 2007 335


1. EDIFACT FINPAY Message Contents
FORMAT
9900y (no field tag)
PRESENCE
Mandatory
DEFINITION
This field contains the EDIFACT FINPAY message.
USAGE RULES
The contents of this field will not be validated except for the use of the 'y' character set, ie, EDIFACT level
A/ISO 9735.
The effective maximum length of this field in a real message depends on the length of the added SWIFT
headers and trailers. The field length will not be validated separately but only via the implementation rule
defining the maximum length of the complete message.

MT 190
MT 190 Advice of Charges, Interest and Other Adjustments
Please refer to Category n - Common Group Messages, Chapter n90 Advice of Charges, Interest and Other
Adjustments for details concerning this message type.
31 August 2007 337

MT 191 Request for Payment of Charges, Interest and Other

Expenses
Please refer to Category n - Common Group Messages, Chapter n91 Request for Payment of Charges, Interest
and Other Expenses for details concerning this message type.

MT 192
MT 192 Request for Cancellation
Please refer to Category n - Common Group Messages, Chapter n92 Request for Cancellation for details
concerning this message type.
31 August 2007 339

MT 195 Queries
Please refer to Category n - Common Group Messages, Chapter n95 Queries for details concerning this
message type.

MT 196
MT 196 Answers
Please refer to Category n - Common Group Messages, Chapter n96 Answers for details concerning this
message type.
31 August 2007 341

MT 198 Proprietary Message
Please refer to Category n - Common Group Messages, Chapter n98 Proprietary Message for details

MT 199
MT 199 Free Format Message
Please refer to Category n - Common Group Messages, Chapter n99 Free Format Message for details
31 August 2007 343

Glossary of Terms
In addition to the definitions which appear in SWIFTStandards MT General Information, Glossary of Terms,
the following terms apply to category 1 message types:
Available Funds
Funds available for transfer or withdrawal in cash.
Bankleitzahl
An eight digit numeric code used to identify banks in Germany. It may only be assigned, changed or
cancelled by Deutsche Bundesbank, in Germany.
CHIPS (Clearing House Interbank Payments System)
A private telecommunications payment service operated by the New York Clearing House Association
for banks in the New York area, which handles US dollar payments only.
CHIPS Participant
A bank authorized to send and receive payments on the CHIPS system.
CHIPS Participant ID (ABA Number)
A unique number identifying a CHIPS participant. The first four digits are the participant's number,
followed by a one digit group identifier. For SWIFT purposes, only the first four digits of the CHIPS
Participant ID will be used.
CHIPS Settling Participant
A CHIPS Participant responsible for the settlement of its own CHIPS net debit or credit position at the
end of the CHIPS business day.
CHIPS Universal Identifier (U.I.D.)
A unique six digit number assigned by CHIPS to identify an account.
Cover Payment
The reimbursement of a correspondent for a payment.
Debit Transfer Contract
The agreement between the creditor and its own account-holding institution, relating to the services
offered and under what terms. It is accepted without reference in the text, that there is an underlying
contract between the creditor and the debtor for the service which has been provided, and which
requires payment. Agreement also exists between the account-holding institution and the body which
acts as the data processing centre and/or clearing centre for direct debit transactions.
Debit Transfer Mandate
A debit transfer mandate is an agreement between a creditor and a debtor and possibly the debtor's
bank. It authorises the creditor to debit the debtor's account according to the terms of the debit transfer
mandate.
Drawee Bank
The bank on which a cheque is drawn. It is the bank which is expected to accept and pay a cheque.
Drawer Bank
The bank which signs the cheque giving an order to another bank (drawee bank) to pay the amount for
which the cheque is drawn.
Federal Funds
US dollars on deposit at a Federal Reserve Bank in the United States.
Fedwire
A payment service operated by the US Federal Reserve System as a private wire network for transfers
between financial institutions having accounts at the Federal Reserve Bank.

Glossary of Terms
Fedwire Routing Number

A nine digit numeric code used to identify banks in the United States.
Funds Transfer
Complete movement of funds between the originator and the beneficiary. A funds transfer may consist
of one or more funds transfer transactions.
Funds Transfer Transaction
The movement of funds directly between two parties, involving no intermediaries other than a payment
or communications service.
Immediate Funds
Same day funds in which the settlement is simultaneous with execution of the transaction.
Instructing Party
The party instructing the Sender to execute a transaction.
Intermediary Reimbursement Institution
For SWIFT purposes, an institution receiving funds on behalf of the Receiver's Correspondent from the
Sender's Correspondent.
Originator
Initiator of the transfer instructions. Equivalent to the ordering customer, eg, field 50a in the MT 103.
Originator's Institution
Identifies the financial institution which is acting for the Originator of the transfer. Equivalent to the
ordering institution, eg, field 52a in the MT 103.
Payee
The beneficiary of a cheque.
Remitter
The party which is the source of funds in a payment order.
Same Day Funds
The funds available for transfer today, or for withdrawal in cash, subject to the settlement of the
transaction through the payment mechanism used.
Settlement
A transfer of funds to complete one or more prior transactions made, subject to final accounting.
31 August 2007 345

MT100

Uploaded by

Document Informationclick to expand document informationMT 100 Reference Guide

Document Informationclick to expand document information

Copyright:

Available Formats

MT100

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MT100

Uploaded by

Copyright:

Available Formats

SWIFTStandards

Category 1 - Customer Payments and Cheques

Message Reference Guide

SWIFTStandards Intellectual Property Rights (IPR) Policy - End-User License Agreement

The English version of SWIFT documentation is the only official version.

Trademarks and Patents

SWIFT is the trading name of S.W.I.F.T. SCRL.

Euro - Impact on Category Message Standards .................................................................... 6

MT 101 Request for Transfer ................................................................................................ 7

MT 102+ Multiple Customer Credit Transfer ..................................................................... 94

MT 103 Single Customer Credit Transfer ......................................................................... 131

MT 103+ Single Customer Credit Transfer ....................................................................... 202

MT 105 EDIFACT Envelope ............................................................................................ 281

MT 106 EDIFACT Envelope ............................................................................................ 284

MT 107 General Direct Debit Message ............................................................................. 287

MT 110 Advice of Cheque(s) ............................................................................................ 312

MT 111 Request for Stop Payment of a Cheque ............................................................... 323

MT 112 Status of a Request for Stop Payment of a Cheque ............................................. 329

MT 190 Advice of Charges, Interest and Other Adjustments ........................................... 337

MT 192 Request for Cancellation ..................................................................................... 339

MT 196 Answers ............................................................................................................... 341

MT 198 Proprietary Message ............................................................................................ 342

MT 199 Free Format Message .......................................................................................... 343

Glossary of Terms ............................................................................................................. 344

31 August 2007 iii

iv Message Reference Guide

Volume Formatting Explanation

Message Type Scope

Message Type Format Specifications

MT nnn (Message Type Name)

M 20 Transaction Reference Number 16x 1

M 21 Related Reference 16x 2

Mandatory Sequence A (Sequence Name)

M 25 Account Identification 35x 3

M 32a Value Date, Currency Code, Amount C or D 4

-----> Optional Repetitive Sequence B (Sequence Name)

O 52a Ordering Institution A or D 5

M 71B Details of Charges 6*35x 6

O 72 Sender to Receiver Information 6*35x 7

MT Network Validated Rules

2 Message Reference Guide

Category 1 Message Types

The following table lists all message types defined in category 1.

MT MT Name Purpose Authen. Max. MUG VDO

101 Request For Requests to debit a customer's Y 10,000 Y Y

102 Multiple Customer Conveys multiple payment Y 10,000 Y Y

103 Single Customer Instructs a funds transfer Y 10,000 N Y

103 Single Customer Instructs a funds transfer Y 10,000 Y Y

104 Direct Debit and Conveys direct debit Y 10,000 Y Y

105 EDIFACT Envelope An envelope which conveys a Y 2,000 Y N

106 EDIFACT Envelope An envelope which conveys a Y 10,000 Y N

107 General Direct To order the debit of a debtor's Y 10,000 Y Y

110 Advice of Cheque Advises or confirms the Y 2,000 N Y

111 Request for Stop Requests the drawee bank to Y 2,000 N Y

112 Status of a Request Indicates action(s) taken in Y 2,000 N Y

121 Multiple Interbank Contains an EDIFACT FINPAY Y 10,000 Y N

190 Advice of Charges, Advises an account owner of Y 2,000 N N

4 Message Reference Guide