Swift Old Version Document PDF

Standards MT November 2016
General Information
This document provides information about all Standards MT (Message Type) categories, and explains the general rules,
conventions, and principles for the Standards MTs. The document explains the organisation of the Standards
documentation and the benefits of message standards. This document also provides a description of the ISO Business
Identifier Code. This document is for all SWIFT customers (this includes operators and application developers), vendors,
and service bureaux.
22 July 2016
General Information Table of Contents
Table of Contents
Preface......................................................................................................................................................4
1 Standards MT Volumes Description.............................................................................................5

1.1 Volume/Chapter Explanation......................................................................................................... 5
1.2 Standards MT Volumes................................................................................................................. 6
1.3 Formatting Explanation............................................................................................................... 10
2 Introduction to Standards MT.....................................................................................................16

2.1 Reason for Standards MT........................................................................................................... 16
2.2 Standards Development and Implementation Process............................................................... 16
2.3 Standards Maintenance Process................................................................................................ 16
2.4 Message Envelope Structure...................................................................................................... 17
2.5 Message Validation Description.................................................................................................. 17
3 Business Identifier Code (BIC)................................................................................................... 19
4 Characters.................................................................................................................................... 20
4.1 SWIFT Character Set (X Character Set)..................................................................................... 20
4.2 EDIFACT Level A Character Set (Y Character Set).....................................................................20
4.3 Information Service Character Set (Z Character Set)................................................................. 20
4.4 Representation of Non-SWIFT Characters..................................................................................21
5 Message Structure and Message Types.................................................................................... 23

5.1 SWIFT Message Structure.......................................................................................................... 23
5.2 SWIFT Message Types .............................................................................................................. 23
5.3 Message Length and Structure................................................................................................... 50
5.4 Message Structure Example....................................................................................................... 50
6 Field Structure and Field Formatting Rules.............................................................................. 52

6.1 General Rules............................................................................................................................. 52
6.2 Field Structure ............................................................................................................................ 53
6.3 Field Formatting ......................................................................................................................... 55
7 Euro-Related Information (ERI) ................................................................................................. 75

7.1 Deletion of National Currency Denomination (NCD) Currency Codes........................................ 75
22 July 2016 2
General Information Table of Contents
7.2 Euro-Related Information (ERI)................................................................................................... 75

7.3 Message Specific Guidelines on the Use of ERI......................................................................... 78
7.4 ERI Validation and Examples...................................................................................................... 85
Legal Notices......................................................................................................................................... 97
22 July 2016 3
General Information Preface
Preface
Significant changes
The following tables list all significant changes to the content of the MT General Information
since the 24 July 2015 edition. These tables do not include editorial changes that SWIFT makes
to improve the usability and comprehension of the document.
New information Location
Addition of clearing code CN Option D: Name and Address on page 61
How to calculate message length Message Length and Structure on page 50
Updated information Location
Update of rules ERI Usage Guidelines and Rules on page 76
Accomodate definition of field 59F Option F: Party Identifier/Name and Address on

page 65
Deleted information Location
No ERI validation on MTs 96n No ERI Validation on page 90
Removal of unnecessary characters (chevrons) Details of the ERI Validation Implementation on

around field format page 90
CAUTION This volume contains information effective as of the November 2016 Standards
release. Therefore the 24 July 2015 edition of the Standards MT User Handbook
volumes remains effective until November 2016.
22 July 2016 4
General Information Standards MT Volumes Description
1 Standards MT Volumes Description

1.1 Volume/Chapter Explanation
Standards MT volumes
All SWIFT messages exchanged between users must accord with the message text standards
described in the Standards MT volumes. To achieve this, it may be necessary for some users to
make changes to their policies and procedures to bring their communications in line with those
of the SWIFT community.
The Standards MT volumes describe the message text standards which have been developed
by representatives from the user community, and which are currently in effect.
They consist of:
• MT General Information
• Standards MT General Field Definitions Plus
Ten Category volumes containing the respective message text standards:
• Category 1 - Customer Payments and Cheques
• Category 2 - Financial Institution Transfers
• Category 3 - Treasury Markets - Foreign Exchange, Money Markets, and Derivatives
This category consists of 2 volumes:
- Volume 1: MT 300 - MT 341
- Volume 2: MT 350 - MT 399
• Category 4 - Collections and Cash Letters
• Category 5 - Securities Markets
This category consists of 4 volumes:
- Volume 1: MT 500 - MT 518
- Volume 2: MT 519 - MT 543
- Volume 3: MT 544 - MT 567
- Volume 4: MT 568 - MT 599
• Category 6
This category consists of 3 books:
- Commodities
- Syndications
- Reference Data
• Category 7 - Documentary Credits and Guarantees
• Category 8 - Travellers Cheques
• Category 9 - Cash Management and Customer Status
• Category n - Common Group Messages
22 July 2016 5
Additional Standards MT volumes

To assist users, usage guidelines have been published in two additional Standards MT volumes
for specific categories of messages. These volumes contain guidelines for using message
standards.
The two volumes are:
• Standards MT Usage Guidelines
• Category 5 - Securities Markets - Message Usage Guidelines
Additional volumes are issued separately for:
• advance information, published as the Standards Release Guide
• supplementary information, as appropriate
1.2 Standards MT Volumes
1.2.1 Standards MT General Information Volume
Overview
The Standards MT General Information volume contains information which is pertinent to all
categories of messages. It includes, for example, an explanation of how the information is
organised, the benefits of using message standards, and the description of the Business
Identifier Code.
Chapters description
Chapter Description
1 - Standards MT This chapter contains:

Volumes Description on
• a description of the information which is contained in each
page 5
volume of the Standards MT volume set
• an explanation of the presentation of field definitions,
category information, and message type formats
2 - Introduction to This chapter contains:

Standards MT on page
• a description of the reasons message standards are
16
needed, including the benefits realised through their
proper use
• information about the method used by SWIFT to update
current standards, and to develop new ones, in order to
ensure compatibility with current financial practices
• a list of the standard development organisations SWIFT
consults with when developing message text formats and
definitions
• a brief description of the format checking performed by the
SWIFT system on outgoing SWIFT messages
22 July 2016 6
Chapter Description
3 - Business Identifier This chapter contains a brief description of the Business

Code (BIC) on page 19 Identifier Code.
For more information on the BIC format and use of the BIC in
SWIFT messages, see the SWIFT BIC Policy.
4 - Characters on page This chapter lists the allowable characters in the X-, Y-, and Z-
20 character sets.
5- Message Structure and This chapter contains:

Message Types on page
• definitions and illustrations of the structure of a message
23
• a description of the purpose of the category designation
within the message type (MT) number and how the
category may be used to aid the internal routing of
messages
• a list of all SWIFT message types
6 - Field Structure and In addition to general rules for field structure and field
Field Formatting Rules on formatting, this chapter also covers field formatting rules for
page 52 the following elements:
• Dates
• Numbers
• Currency Codes
• Party Identification
• Times
• Value Date Ordering
7- Euro-Related This chapter contains guidelines for using existing SWIFT

Information (ERI) on page message standards for transactions involving the euro.
75
1.2.2 Standards MT General Field Definitions Plus
Overview
This online publication is available only on the User Handbook Online. It allows the user to
search for specific pieces of information, easily and quickly as information is sorted by MT or by
field tag.
The Standards MT General Field Definitions Plus provides a general description of all message-
text fields. It also provides information about the FIN error codes.
Information which applies to fields in a specific message, for example, field usage and codes, is
found in the description of the message type within the Standards category message reference
guides.
22 July 2016 7
Description
The Standards MT General Field Definitions Plus contains a description of each field tag,
including:
• format options
• definition
• network validated rules
• usage rules
• relevant message types
• codes
1.2.3 Category Volumes: Message Text Standards
Message text standards for individual messages within each category are contained in the
category volumes:
• Category 1 - Customer Payments and Cheques
• Category 2 - Financial Institution Transfers
• Category 3 - Treasury Markets - Foreign Exchange, Money Markets, and Derivatives
• Category 4 - Collection and Cash Letters
• Category 5 - Securities Markets
• Category 6 - Treasury Markets - Commodities
• Category 6 - Treasury Markets - Syndications
• Category 6 - Reference Data
• Category 7 - Documentary Credits and Guarantees
• Category 8 - Travellers Cheques
• Category 9 - Cash Management and Customer Status
• Category n - Common Group Messages
Each volume provides the information as described in the following table:
Section Description
Introduction This section contains a description of the function

and use of the message category. It also indicates
what has changed in the book since its previous
publication, and explains how the book, and each
message type, is structured.
22 July 2016 8
Section Description
Category Message Types This section lists and briefly describes the message
types defined within the category. It also indicates:
• whether the message type requires
authentication
• the maximum length allowed
• whether the use of the message type requires
registration with SWIFT in a Message User Group
• information about how to register for a Message
User Group
Message Type Description This section contains detailed descriptions of each

message type within the category.
Including:
• MT Scope
• MT Format Specifications
• MT Network Validated Rules
• MT Usage Rules
• MT Guidelines
• MT Field Specifications
• MT Mapping
• MT Examples
• additional information about the MT as required
Glossary of Terms Terms and definitions that are used throughout the
category.
1.2.4 Additional Volumes
Two additional volumes contain recommendations for using messages in specific business
situations. They also provide special information about more than one message type, or across
more than one category of message type. These usage guidelines are recommendations and
are provided for information. They do not form part of the SWIFT message text standards.
Volume Description
Standards MT Usage Guidelines This document recommends the use of messages for
specific business situations.
Standards - Category 5 - Securities This document contains additional information for

Markets - Message Usage using the Category 5 message types. It explains how
Guidelines the ISO 15022 messages relate to each other, and
the parties involved. It also includes a general outline
of the structure of each new message.
22 July 2016 9
1.3 Formatting Explanation
1.3.1 Field Definition Format
The Standards MT General Field Definitions Plus contains the following information per field.
Name Description
Definition A description of the field. Additional information which

applies to a specific category, or message type, will
appear in the field specifications for that message type.
Format Options The specification of available options, or alternative

formatting possibilities, for the field.
The format options include restrictions on length and
types of characters allowed.
Usage Rules Additional information pertaining to use of the field.
Network Validated Rules Any restrictions on use, for example, a double slash '//'
is not permitted within field 20.
Message Type Use A matrix showing the message types which use the
specified field.
Codes A matrix showing the message types which use the

specified code.
1.3.2 Message Type Descriptions
Introduction
The ten category volumes contain general information for the category and the detailed
description of each message type.
For each message type, the following information is provided.
Note For the ISO 15022 securities messages in Category 5, the format specification and
field specifications are presented in a slightly different way. For further
explanations, see Category 5 - Securities Markets - Message Usage Guidelines.
Example of an information flow

The following symbols are used to identify the parties involved in the message flow:
22 July 2016 10
Legend
Originator of the
transaction
Financial Bank Corporate Customer

institution
Sender
or
Receiver
Other parties involved

in the transaction
MT
The actual SWIFT
Message
MT nnn
Another SWIFT message

MT nnn
involved in the transaction
Financial institution or
customer relationship
Final recipient
D0200001
Financial Bank Corporate Customer

institution
In the diagrams, each customer, or financial institution, is identified by the tag number of the
corresponding field, for example, 50a, Ordering Customer.
Message type scope

The scope of a message 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.
22 July 2016 11
Message type format specifications
MT nnn (Message Type name)
The format specifications are the rules for the layout of the message type. This information is
provided in table form as shown below:
Status Tag Field Name Content/Options No.
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, 6!n3!a15d 4

Amount
----> Optional Repetitive Sequence B (Sequence Name)
O 52a Ordering Institution A or D 5
M 71B Detail of Charges 6*35x 6
O 72 Sender to Receiver Information 6*35x 7
----|
M = Mandatory O = Optional - Network Validated Rules may apply
MT nnn (Message Type name) provides the message type number and name.
The table headings have the following meanings:
• Status indicates if the field is:
- M = Mandatory
- O = Optional - Network Validated Rules may apply
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.
• No. identifies the number of the field in the Field Specifications for the message type. It is
also called Index.
Only fields and field tag options, which are shown in the message format, may be used in that
message type.
22 July 2016 12
Some message formats are separated into sequences of fields, as shown below. An arrow
indicates that a sequence of fields may be repeated:
Status Tag Field Name Content/Options No.
First sequence
---->
Second Sequence
----|
Third sequence
M = Mandatory O = Optional - Network Validated Rules may apply
The arrows (----> and ----|) indicate that the second sequence may be repeated.
MT network validated rules
Network validated rules are validated on the network, that is, they are identified with an error
code. 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.
For example, in the MT 202, a rule states that if field 56a (Intermediary) is present, then field
57a (Account With Institution) must also be present (Error code C81).
MT usage rules
Usage rules are not validated on the network, that is, no error code is defined for them, 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.
MT market practice rules
Market practice rules specify the rules published by a recognised Market Practice Group, for
example, for category 5, the Securities Market Practice Group (SMPG). Market practice rules
indicate the existence of a global market practice document on the business process in which
the concerned field or message type is used. The absence of a market practice rule notation
does not mean that no market practices exist for the concerned field or message type. The
presence of a market practice rule is merely an indicator of a known market practice.
Furthermore, readers should be aware that in addition to global market practices there may also
22 July 2016 13
be country-specific requirements that should be considered when using the field or message
type.
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.
The description may contain some, or all, of the following:
1. FORMAT specifies the field formats which are allowed in the field.
2. PRESENCE indicates if the field is mandatory, optional, or conditional in its sequence.
3. DEFINITION specifies the definition of the field in this sequence of the message type.
4. 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.
5. NETWORK VALIDATED RULES specifies rules that are validated on the network, that is,
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, that is, 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, for example, a currency which must be the same for more than one field in the
message.
6. USAGE RULES specifies rules that are not validated on the network, that is, 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.
7. EXAMPLES provides one or more examples of the field as it will be formatted/used.
MT mapping
MT mapping explains how to map the fields of the message into another SWIFT message,
either of the same, or a different, message type.
MT example
Examples are provided to illustrate the correct use of a message.
Examples always include:
• narrative, which provides a brief description of a transaction
• information flow, which illustrates the relationships between the parties involved in the
message (see below diagram)
• SWIFT format, which provides the message using the defined SWIFT format, and providing
an explanation, where necessary, of the fields which have been used
The sender, receiver, and message type are summarily identified. Trailer contents are not
shown.
22 July 2016 14
Note For further information about the header and trailer, see the FIN Service
Description.
22 July 2016 15
General Information Introduction to Standards MT
2 Introduction to Standards MT
2.1 Reason for Standards MT
Why Standards MT?
The message text standards have been developed to support the business transactions of
SWIFT users. To ensure that the multitude of practices and conventions of users are in
harmony, financial messages transmitted via the SWIFT network must adhere to the message
text standards.
Standards enable financial institutions to move from manual to automated initiation and
processing of financial transactions.
Key benefits
There are important benefits which result from standardisation of messages. These include:
• automation
• reduced risk of errors and misunderstandings
• reduced operating costs
• improved productivity
• increased efficiency in processing of messages (routing and preparation)
• faster and more cost effective account reconciliation
• ability to maintain more comprehensive management information
2.2 Standards Development and Implementation Process

Published processes
For details about the standards development and implementation process, see the Standards
MT Development and Maintenance Processes at swift.com > Ordering & Support > User
Handbook Home. This document was approved by the SWIFT Board of Directors in 2011.
2.3 Standards Maintenance Process

Published processes
For details about the standards maintenance process, see the Standards MT Development and
Maintenance Processes at swift.com > Ordering & Support > User Handbook Home. This
document was approved by the SWIFT Board of Directors in 2011.
Maintenance projects
Maintenance projects aim at maintaining the functionality of existing standards. They are carried
out to bring existing standards in line with business changes, or to correct technical problems.
There are two ways to submit maintenance requests (change requests) to SWIFT, as follows:
• through User Group Chairpersons
• through representative market practice groups in which there are SWIFT members
Note Individual users and members may only submit maintenance requests to their User
Group Chairperson (requests submitted directly to SWIFT are returned).
22 July 2016 16
Maintenance deliverables
The deliverables are the following:
1. Fifteen months prior to implementation (SR-15), SWIFT publishes a high-level document (for
budget and resource allocation). It highlights the potential scope and size of the subject
maintenance release, based on the change requests received. These changes must still be
validated by a Working Group and some of them may be reworded, redefined or even
removed.
2. Eleven months prior to implementation (SR-11), SWIFT publishes a revised, high-level
document (for budget and resource allocation), which shows only those change requests
that were approved by the working groups and accepted by a country vote.
3. Ten months prior to implementation (SR-10), the Standards Release Guide (SRG) provides
details of the changes published in the revised, high-level document.
4. Three months prior to implementation (SR-3), the Standards MT User Handbook is available
on www.swift.com.
5. The changes are implemented on the network on the Standards release (SR-0) date.
Approval process
Sixteen months prior to a planned Standards release date (SR-16), the SWIFT Standards
department analyses all received change requests. They send the outcome of this analysis to a
Maintenance Working Group (MWG) for discussion and approval.
MWGs include experts in the business domain and, ideally, in the standards to be maintained.
Members are country representatives appointed by their respective User Group Chairperson.
The message text formats are developed in line, or in consultation, with various bodies:
1. MWGs review and agree on the validity of the change requests.
2. Country vote takes place on MWG-agreed changes.
3. The Board Standards Committee must approve the country-vote results before the changes
are considered final and published in the final-SRG.
For more details on any of the processes described in this section, please visit Standards on
www.swift.com, or contact the Support team.
2.4 Message Envelope Structure

All messages (financial and system) conform to a defined structure, generally including a
header, a message text and a trailer.
Note For further details about the message structure, see the FIN Service Description.
2.5 Message Validation Description

Rule
The SWIFT system validates the structure of all messages sent via the FIN network.
If the SWIFT system finds an error, it will reject the message and inform the sender by a
negative acknowledgement (NAK). The NAK will display a text error. Where possible, it will also
give the location of the text error by indicating the number of the line on which the error
occurred.
22 July 2016 17
Exceptions
Exceptions to this rule, which may be based on either system constraints or on the logical layout
of the message or field, include:
• An error code and line number which relates to a network validated rule violation. In these
situations, the system may give the line number of the last text line of the message, or if the
error occurred within a repetitive sequence, the line number relative to either the beginning
or end of the sequence.
• An error code and line number which indicate a text error on the previous line.
Note For additional information about error codes, see the FIN Error Codes.
Some errors, for example, an invalid message type, will prevent any further message validation
by the SWIFT system.
Message text validation
Validation of message text includes checking the following:
• the correct sequence of fields
• the presence of mandatory fields, that is, those required in the message type being sent
• the presence of only those permitted optional fields for the message type
• correct content, for example, numbers or letters and length for each field/subfield; in some
cases, codes are validated
• the permitted character set
• the presence of the decimal comma in numbers and amounts
• that, in amounts, the correct number of digits appears after the decimal comma for the
currency of the message field, for example, not more than 2 for USD
• that the sum of individual amounts in the message is equal to the sum of amounts
• date validity, for example, day not higher than 31
• conditional relationships, that is, the network validated rules for each message type.
Depending on system constraints, not all conditional relationships will be validated by the
SWIFT system
• codes, where an error code is specified in the Field Specifications of the message
description
22 July 2016 18
General Information Business Identifier Code (BIC)
3 Business Identifier Code (BIC)

Overview
In the financial environment, a number of telecommunication services have defined coding
schemes for identifying financial institutions as well as corporate entities. As a result, many
financial institutions and some corporates have more than one code assigned, while others have
no codes assigned.
To ensure the availability of a unique identifier, an International Standard - ISO 9362 - has been
established. This standard specifies a universal method for identifying financial institutions and
is intended to facilitate automated processing of telecommunication messages.
SWIFT is the designated ISO Registration Authority for these ISO codes, and is responsible for
their assignment and subsequent publication.
BICs in messages
ISO 9362 Business Identifier Codes (BICs) are used in certain fields of messages (for example,
field 53a, Sender's Correspondent, or field 59A, Beneficiary Customer) to identify a party in the
transaction.
When a BIC is available (for example, the party to be specified has been assigned a BIC), it
should be used whenever possible, as it is standardised and can therefore be automatically
processed by the receiver.
Both financial institutions and non-financial institutions can be identified with a BIC.
Related information
For more information on the BIC format and use of the BIC in SWIFT messages, see the SWIFT
BIC Policy on swift.com.
22 July 2016 19
General Information Characters
4 Characters
4.1 SWIFT Character Set (X Character Set)
Description
Computer-based terminals communicating with SWIFT use EBCDIC code. The character set is
as follows:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
/-?:().,'+
CrLf Space
The characters Cr and Lf must never be used as single characters and must only be used
together in the sequence CrLf, that is, LfCr is not allowed.
When the character sequence CrLf is used in a field format with several lines, it is used to
indicate the end of one line of text and the start of the next line of text.
4.2 EDIFACT Level A Character Set (Y Character Set)

Description
In field 77F of MT 105, the EDIFACT level A character set, as defined in ISO 9735, is used. This
character set is as follows:
0123456789
.,-()/='+:?!"%&*<>;
Space
Other characters are not allowed (Error code M60).
4.3 Information Service Character Set (Z Character Set)

Description
In fields 70F of MT 568, field 70G of the MT 564, and 77T of MT 103 REMIT, the allowed
character set is as follows:
abcdefghijklmnopqrstuvwxyz
0123456789
.,-()/='+:?!"%&*<>;{
@#_
Cr Lf Space
22 July 2016 20
Other characters are not allowed, including the curly bracket '}' (Error code M60).
In a field format with several lines, the characters Cr and Lf must never be used as single
characters and must only be used together in the sequence CrLf, that is, LfCr is not allowed.
When CrLf is used in such fields, it will be interpreted as the end of one line of text and the start
of the next line of text.
In all other fields, the characters Cr and Lf may be used as single characters or in sequence,
such as, CrLf or LfCr.
4.4 Representation of Non-SWIFT Characters

Description
A number of characters are not allowed in one or more of the SWIFT character sets. To use
these characters in a field where the format does not allow it, SWIFT recommends using the
character's hexadecimal EBCDIC code, preceded by two question marks (??) as escape
sequence. The use of this encoding must be bilaterally agreed between the sender and receiver
of the message.
The following table lists all the SWIFT EBCDIC codes that can be used for the basic Latin
characters that are not found in the X character set:
Character Description EBCDIC
< Less-than sign 4C
! Exclamation mark 4F
& Ampersand 50
| Vertical bar 5A
$ Dollar 5B
* Asterisk 5C
; Semicolon 5E
^ Circumflex 5F
% Percent sign 6C
_ Low line (underscore) 6D
> Greater-than sign 6E
` Grave accent 79
# Number sign 7B
@ Commercial At sign 7C
= Equal sign 7E
22 July 2016 21
Character Description EBCDIC
" Quotation mark 7F
~ Tilde A1
[ Left square bracket AD
] Right square bracket BD
{ Left curly bracket C0
} Right curly bracket D0
\ Reverse solidus (backslash) E0
Example
The character @ will be represented as ??7C in a field that is restricted to characters from the X
character set.
22 July 2016 22
General Information Message Structure and Message Types
5 Message Structure and Message Types

5.1 SWIFT Message Structure
Overview
All financial messages must conform to the rules of one of the message types described in the
Standards MT volumes.
Message Type (MT)
Message Structure
The message type is composed of three digits, generally defined as:
Category
Group
Type
D0200003
MT nnn
Where:
Category Usually describes, at a general level, the underlying business

function of the message. For example: Category 1 = Customer
Payments and Cheques.
Group Describes the function of the message within the specified

category. For example: 11n = Category 1 Cheque Payment
Messages.
Type Describes the specific function. For example: 112 = Status of a

Request for Stop Payment of a Cheque.
From the message type (which is located in the header of a message), the receiver of a
message can help to determine the message's business and function, as well as the details of
its composition.
This section provides the general rules for message types. Detailed specifications pertaining to
individual messages can be found in the related Category volumes. More information
concerning the FIN message structure can be found in the FIN Operations Guide.
5.2 SWIFT Message Types

Overview
The following table lists all message types defined in the Standards MT volumes, effective as of
the November 2016 Standards release.
22 July 2016 23
For each message type, there is a short description, an indicator that the message type is
signed (Y or N), the maximum message length (either 2,000 or 10,000) and whether the use of
the message requires registration within a Message User Group (Y or N).
Note A Message User Group, 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 following table, in the column "MUG". (More information about
Message User Groups follows this table.)
List of Message Types
MT MT Name Purpose Signed(1) Max MUG

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

Transfer customer's account held at
the receiver or at another
institution.
102 Multiple Customer Conveys multiple payment Y 10,000 Y

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

Credit Transfer
103 STP
103 Single Customer Instructs a fund transfer. Y 10,000 Y

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

Request for Debit instructions and requests
Transfer Message for direct debits between
financial institutions.
105 EDIFACT Envelope An envelope which conveys Y 2,000 Y

a 2k EDIFACT message.
107 General Direct Debit Conveys direct debit Y 10,000 Y

Message instructions between
financial institutions.
110 Advice of Cheque(s) Advises or confirms the Y 2,000 N

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

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

for Stop Payment of attempting to stop payment
a Cheque of a cheque.
22 July 2016 24

Length
190 Advice of Charges, Advises an account owner Y 2,000 N

Interest and Other of charges, interest, and
Adjustments other adjustments.
191 Request for Requests payment of Y 2,000 N

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

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

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

Query 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 Y 10,000 N

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

Message which no other message
type has been defined.
200 Financial Institution Requests the movement of Y 2,000 N

Transfer for its Own the sender's funds to its
Account account at another financial
institution.
201 Multiple Financial Multiple of the MT 200. Y 2,000 N

Institution Transfer
for its Own Account
22 July 2016 25

Length
202 General Financial Requests the movement of Y 10,000 N

Institution Transfer funds between financial
institutions except if the
transfer is related to an
underlying customer credit
transfer that was sent with
the cover method, in which
case the MT 202 COV
must be used.
202 COV General Financial Requests the movement of Y 10,000 N

Institution Transfer funds between financial
institutions, related to an
underlying customer credit
transfer that was sent with
the cover method.
203 Multiple General Multiple of the MT 202. Y 2,000 N

Financial Institution
Transfer
204 Financial Markets Claims funds from SWIFT Y(2) 2,000 Y

Direct Debit member banks.
Message
205 Financial Institution Further transmits a transfer Y 10,000 N

Transfer Execution request domestically
except if the transfer is
related to an underlying
customer credit transfer
that was sent with the
cover method, in which
case the MT 205 COV
must be used.
205 COV Financial Institution Further transmits a transfer Y 10,000 N

Transfer Execution request domestically,
related to an underlying
customer credit transfer
that was sent with the
cover method.
207 Request for Requests to debit an Y 10,000 Y

Financial Institution ordering financial
Transfer institution's account held at
the receiving financial
institution or the account
servicing financial
institution.
22 July 2016 26

Length
210 Notice to Receive Notifies the receiver that it Y 2,000 N

will receive funds for the
sender's account.
256 Advice of Non- Informs the sender of one Y 10,000 Y

Payment of or more previously sent
Cheques cheque truncation
messages of non-payment
of one or more truncated
cheques. It may also be
used to specify
dishonoured items that
result in reversing a
previous payment
settlement.

Interest and Other of charges, interest, or

and Other
Expenses

request.

a previous message.

Queries message or an MT
292 Request for
Cancellation or other
message where no specific
message type has been
provided for a response.

users and for those
22 July 2016 27

Length

300 Foreign Exchange Confirms information N 10,000 N

Confirmation agreed to in the buying/
selling of two currencies.
303 Forex/Currency Instructs the allocation of a N 10,000 Y

Option Allocation block trade (forex or
Instruction currency option).
304 Advice/Instruction of Advises of or instructs Y 10,000 Y

a Third Party Deal settlement of a third party
foreign exchange deal.
305 Foreign Currency Confirms information N 2,000 N

Option Confirmation agreed to in the buying and
selling of vanilla options on
currencies.
306 Foreign Currency Confirms information N 10,000 N

Option Confirmation agreed to in the buying and
selling of exotic options on
currencies.
307 Advice/Instruction of Advises of or instructs Y 10,000 Y

a Third Party FX settlement of a third party
Deal foreign exchange deal.
320 Fixed Loan/Deposit Confirms the terms of a N 10,000 N

Confirmation contract relative to a fixed
loan/deposit transaction.
321 Instruction to Settle Advises the trade details Y 10,000 Y

a Third Party Loan/ and instructs the settlement
Deposit of a fixed term loan/deposit
done with a third party
financial institution.
330 Call/Notice Loan/ Confirms the terms of a N 10,000 N

Deposit contract relative to a call/
Confirmation notice loan/deposit
transaction.
340 Forward Rate Confirms the details of a N 10,000 N

Agreement forward rate agreement.
Confirmation
22 July 2016 28

Length
341 Forward Rate Confirms the settlement N 10,000 N

Agreement details of a forward rate
Settlement agreement.
Confirmation
350 Advice of Loan/ Advises of a loan/deposit N 10,000 N

Deposit Interest interest payment.
Payment
360 Single Currency Confirms the details of a N 10,000 N

Interest Rate single currency interest
Derivative rate derivative swap, cap,
Confirmation collar or floor.
361 Cross Currency Confirms the details of a N 10,000 N

Interest Rate Swap cross currency interest rate
Confirmation swap transaction.
362 Interest Rate Reset/ Confirms or advises the N 2,000 N

Advice of Payment reset rates of the floating
interest rate(s) in a single
or cross-currency interest
rate derivative transaction
and/or the payment of
interest at the end of an
interest period.
364 Single Currency Confirms the details of the N 10,000 N

Interest Rate partial or full termination or
Derivative recouponing of a single
Termination/ currency interest rate swap,
Recouponing cap, collar, or floor.
Confirmation
365 Cross Currency Confirms the details of the N 10,000 N

Interest Rate Swap partial or full termination or
Termination/ recouponing of a cross
Recouponing currency interest rate swap.
Confirmation
370 Netting Position Advises the netting position N 10,000 N

Advice of a currency
380 Foreign Exchange Orders to purchase or sell Y 10,000 Y

Order a specific amount of a
certain currency.
22 July 2016 29

Length
381 Foreign Exchange Confirms the execution of Y 10,000 Y

Order Confirmation an FX order previously
sent.
390 Advice of Charges, Advises an account owner N 2,000 N

391 Request for Requests payment of N 2,000 N

and Other
Expenses
392 Request for Requests the receiver to N 2,000 N

request.
395 Queries Requests information N 2,000 N

a previous message.
396 Answers Responds to an MT 395 N 2,000 N

Queries or an MT 392
Request for Cancellation or
other message where no
specific message type has
been provided for a
response.
398 Proprietary Contains formats defined N 10,000 N

users and for those
399 Free Format Contains information for N 2,000 N

400 Advice of Payment Advises of a payment Y 2,000 N

under a collection or part
thereof. It also handles the
settlement of proceeds.
22 July 2016 30

Length
410 Acknowledgement Acknowledges receipt of a Y 2,000 N

collection. It also specifies
if the collecting bank does
not intend to act in
accordance with the
collection instruction.
412 Advice of Informs the remitting bank Y 2,000 N

Acceptance of the acceptance of one or
more drafts under one
collection instruction.
416 Advice of Non- Advises of the non- Y 10,000 Y

Payment/Non- payment or non-
Acceptance acceptance under a
previously received
collection.
420 Tracer Enquires about documents Y 2,000 N

sent for collection.
422 Advice of Fate and Advises the remitting bank Y 2,000 N

Request for of the fate of one or more
Instructions collection documents;
usually accompanied by
one or more questions or
requests.
430 Amendment of Amends collection Y 2,000 N

Instructions instructions.
450 Cash Letter Credit Confirms that the face Y 2,000 N

Advice amount of cash letter(s)
received has been credited
under usual reserve
(subject to final payment).
455 Cash Letter Credit Advises the account owner Y 2,000 N

Adjustment Advice of adjustments made to its
account (related to a
previous credit for a cash
letter).
456 Advice of Dishonour Advises the account owner Y 2,000 N

that financial document(s)
included in the cash letter
have been dishonoured for
reasons specified in the
advice.
22 July 2016 31

Length

Adjustments other adjustments to its
account.

and Other
Expenses

request.

a previous message.

Queries message or MT
492 Request for
messages where no
been provided for the
response.

users and for those

500 Instruction to Instructs the registration, Y 10,000 N

Register deregistration or
reregistration of a financial
instrument at the
registration provider.
22 July 2016 32

Length
501 Confirmation of Confirms the registration, Y 10,000 N

Registration or deregistration or
Modification reregistration of a
beneficial owner or
shareholder with the
502(3) Order to Buy or Sell Instructs the purchase or Y 10,000 N

sale of a given quantity of a
specified financial
instrument under specified
conditions.
503 Collateral Claim Requests new or additional Y 10,000 Y

collateral, or the return or
recall of collateral.
504 Collateral Proposal Proposes new or additional Y 10,000 Y

collateral.
505 Collateral Proposes or requests the Y 10,000 Y

Substitution substitution of collateral
held.
506 Collateral and Provides the details of the Y 10,000 Y

Exposure Statement valuation of both the
collateral and the exposure.
507 Collateral Status Advises the status of a Y 10,000 Y

and Processing collateral claim, a collateral
Advice proposal, or a proposal/
request for collateral
substitution.
508 Intra-Position Reports on the movement Y 10,000 N

Advice of securities within the
holding.
509(3) Trade Status Provides information about Y 10,000 N

Message the status of a previously
executed trade.
510 Registration Status Advises the status of a Y 10,000 N

and Processing registration instruction or
Advice modification.
22 July 2016 33

Length
513 Client Advice of Provides brief and early Y 10,000 N

Execution information about a
securities deal, for
example, a block trade that
is to be allocated before
final confirmation.
514 Trade Allocation Instructs the allocation of a Y 10,000 N

Instruction block trade.
515(3) Client Confirmation Provides a detailed Y 10,000 N

of Purchase or Sale accounting of financial
instruments purchased or
sold by the sender on
behalf of the receiver or its
client. It may also convey
the payment details of the
purchase or sale. It may
also be sent by, or via an
ETC service provider.
516 Securities Loan Confirms the details of a Y 2,000 N

Confirmation securities loan, including
collateral arrangements. It
may also confirm the
details of a partial recall or
return of securities
previously out on loan.
517 Trade Confirmation Positively affirms the Y 10,000 N

Affirmation details of a previously
received confirmation/
contract note.
518 Market-Side Confirms the details of a Y 10,000 N

Securities Trade trade and, where
Confirmation necessary, its settlement to
a trading counterparty.
519 Modification of Instructs the modification of Y 10,000 N

Client Details client details at the
524 Intra-Position Instructs the movement of Y 10,000 N

Instruction securities within the
holding.
22 July 2016 34

Length
526 General Securities Requests the borrowing of Y 2,000 N

Lending/Borrowing securities or notifies the
Message return or recall of securities
previously out on loan. It
may also be used to list
securities available for
lending.
527 Triparty Collateral Performs a specific action Y 10,000 Y

Instruction on a collateral
management transaction.
530 Transaction Requests the modification Y 10,000 N

Processing of a processing indicator or
Command other non-matching
information.
535 Statement of Reports at a specified time, Y 10,000 N

Holdings the quantity and
identification of securities
and other holdings which
the account servicer holds
for the account owner.
536 Statement of Provides details of Y 10,000 N

Transactions increases and decreases of
holdings which occurred
during a specified period.
537 Statement of Provides details of pending Y 10,000 N

Pending increases and decreases of
Transactions holdings at a specified
time.
538 Statement of Intra- Provides details of Y 10,000 N

Position Advices increases and decreases in
securities within the holding
during a specified period.
540 Receive Free Instructs a receipt of Y 10,000 N

financial instruments free of
payment. It may also be
used to request a
cancellation or pre-advise
an instruction.
22 July 2016 35

Length
541 Receive Against Instructs a receipt of Y 10,000 N

Payment financial instruments
against payment. It may
also be used to request a
an instruction.
542 Deliver Free Instructs a delivery of Y 10,000 N

financial instruments free of
used to request a
an instruction.
543 Deliver Against Instructs a delivery of Y 10,000 N

against payment. It may
also be used to request a
an instruction.
544 Receive Free Confirms a receipt of Y 10,000 N

Confirmation financial instruments free of
used to cancel or reverse a
confirmation.
545 Receive Against Confirms a receipt of Y 10,000 N

Confirmation against payment. It may
also be used to cancel or
reverse a confirmation.
546 Deliver Free Confirms a delivery of Y 10,000 N

Confirmation financial instruments free of
used to cancel or reverse a
confirmation.
547 Deliver Against Confirms a delivery of Y 10,000 N

Confirmation against payment. It may
also be used to cancel or
reverse a confirmation.
548 Settlement Status Advises the status of a Y 10,000 N

and Processing settlement instruction or
Advice replies to a cancellation
request.
22 July 2016 36

Length
549 Request for Requests a statement or a Y 10,000 N

Statement/Status status message.
Advice
558 Triparty Collateral Provides validation results Y 10,000 Y

Status and and status advice re
Processing Advice collateral instructions and
proposed collateral
movements.
559 Paying Agent's Claims reimbursement of Y 2,000 N

Claim income or redemption
proceeds, or a combination
of both.
564 Corporate Action Provides an account owner Y 10,000 N

Notification with details of a corporate
action event and the
choices available to the
account owner. It also
provides the account owner
with details on the impact a
corporate action event will
have on a safekeeping or
cash account, for example,
entitlement calculation.
565 Corporate Action Instructs the custodian on Y 10,000 N

Instruction the investment decision
made by an account owner
relative to a corporate
action event.
566 Corporate Action Confirms to the account Y 10,000 N

Confirmation owner that securities
and/or cash have been
credited/debited to an
account as a result of a
corporate action event.
567 Corporate Action Indicates the status, or a Y 10,000 N

Status and change in status, of a
Processing Advice corporate action-related
transaction previously
instructed by, or executed
on behalf of, the account
owner.
22 July 2016 37

Length
568 Corporate Action Provides complex Y 10,000 N

Narrative instructions or narrative
details relating to a
corporate action event.
569 Triparty Collateral Provides the details of the Y 10,000 Y

and Exposure valuation of both the
Statement collateral and the exposure.
574(4) IRS 1441 NRA-IRS Provides owner or pooled Y 10,000 N

Beneficial Owners' income information for a
List period of time arranged
between the intermediary
and the withholding agent.
574(5) IRS 1441 NRA- Certifies the foreign status Y 10,000 N

Form W8-BEN of a beneficial owner for
United States tax
withholding.
575 Report of Combined Reports on all securities Y 10,000 Y

Activity and cash activity for a
given combination of
safekeeping and cash
accounts.
576 Statement of Open Provides details of orders Y 10,000 N

Orders to buy or to sell financial
instruments, as at a
specified date, which have
been accepted by the
sender, but which have not
yet been executed.
577 Statement of Provides certificate Y 10,000 N

Numbers numbers of securities.
578 Settlement Advises the account owner Y 10,000 N

Allegement that a counterparty has
alleged a settlement
instruction on the account
owner's account.
579 Certificate Numbers Replaces or supplements Y 2,000 N

the "certificate numbers"
field in a primary message,
for example, MT 577.
22 July 2016 38

Length
581 Collateral Claims or notifies a change Y 2,000 N

Adjustment in the amount of collateral
Message held against securities out
on loan or for other
reasons.
586 Statement of Provides details of pending Y 10,000 N

Settlement settlement allegements.
Allegements

account.

and Other
Expenses

request.

a previous message.

Queries or MT 592
other message where no
response.

users and for those

22 July 2016 39

Length
600 Commodity Trade Confirms the details of a N 2,000 N

Confirmation commodity trade and its
settlement.
601 Commodity Option Confirms the details of a N 2,000 N

Confirmation commodity option contract.
604 Commodity Instructs the receiver to Y 2,000 N

Transfer/Delivery transfer by book-entry, or
Order physically deliver, a
specified type and quantity
of commodity to a specified
party.
605 Commodity Notice Notifies the receiver of an N 2,000 N

to Receive impending book-entry
transfer or physical delivery
of a specified type and
quantity of commodity.
606 Commodity Debit Advises the receiver of a N 2,000 N

Advice debit entry to a specified
commodity account.
607 Commodity Credit Advises the receiver of a N 2,000 N

Advice credit entry to a specified
commodity account.
608 Statement of a Provides the details of all N 2,000 N

Commodity Account bookings to a commodity
account.
609 Statement of Identifies all outstanding N 2,000 N

Commodity commodity contracts, as at
Contracts a specified date for which
confirmations have been
exchanged.
620 Commodity Fixed Confirms a commodity N 10,000 Y

Loan/Deposit fixed term loan/deposit
Confirmation contract.
643 Notice of Provides notice of the Y 2,000 N

Drawdown/Renewal borrower(s) request for
drawdown(s)/renewal(s) on
a given date.
22 July 2016 40

Length
644 Advice of Rate and Specifies the interest rate Y 2,000 N

Amount Fixing and, if applicable, the
exchange rate, for the next
interest period.
646 Payment of Advises of payments Y 2,000 N

Principal and/or of and/or prepayments of
Interest principal and/or of interest
with the same value date,
but not related to any
subsequent drawing or
renewal.
649 General Syndicated Provides for Y 2,000 N

Facility Message communications related to
syndicated facilities for
which no specific message
has been defined.
670 Standing Settlement Requests SWIFT to create Y 10,000 N

Instruction Update the MT 671 from the MT
Notification Request 670 and send to financial
institutions.
671 Standing Settlement Specifies standing Y 10,000 N

Instruction Update settlement instructions for
Notification one or more currencies.

account.

and Other
Expenses

request.

a previous message.
22 July 2016 41

Length

692 Request for
messages where no
response.

users and for those

700 Issue of a Indicates the terms and Y 10,000 N

Documentary Credit conditions of a
documentary credit.
701 Issue of a Continuation of an MT 700 Y 10,000 N

Documentary Credit for fields 45a, 46a, and
47a.
705 Pre-Advice of a Provides brief advice of a Y 2,000 N

Documentary Credit documentary credit for
which full details will follow.
707 Amendment to a Informs the receiver of Y 10,000 N

Documentary Credit amendments to the terms
and conditions of a
documentary credit.
710 Advice of a Third Advises the receiver of the Y 10,000 N

Bank's or a Non- terms and conditions of a
Bank's documentary credit.
Documentary Credit
711 Advice of a Third Continuation of an MT 710 Y 10,000 N

Bank's or a Non- for fields 45a, 46a, and
Bank's 47a.
Documentary Credit
22 July 2016 42

Length
720 Transfer of a Advises the transfer of a Y 10,000 N

Documentary Credit documentary credit, or part
thereof, to the bank
advising the second
beneficiary.
721 Transfer of a Continuation of an MT 720 Y 10,000 N

Documentary Credit for fields 45a, 46a, and
47a.
730 Acknowledgement Acknowledges the receipt Y 2,000 N

of a documentary credit
message and may indicate
that the message has been
forwarded according to
instructions. It may also be
used to account for bank
charges or to advise of
acceptance or rejection of
an amendment of a
documentary credit.
732 Advice of Discharge Advises that documents Y 2,000 N

received with discrepancies
have been taken up.
734 Advice of Refusal Advises the refusal of Y 10,000 N

documents that are not in
accordance with the terms
and conditions of a
documentary credit.
740 Authorisation to Requests the receiver to Y 2,000 N

Reimburse honour claims for
reimbursement of
payment(s) or
negotiation(s) under a
documentary credit.
742 Re-imbursement Provides a reimbursement Y 2,000 N

Claim claim to the bank
authorised to reimburse the
sender or its branch for its
payments/ negotiations.
22 July 2016 43

Length
747 Amendment to an Informs the reimbursing Y 2,000 N

Authorisation to bank of amendments to the
Reimburse terms and conditions of a
documentary credit,
relative to the authorisation
to reimburse.
750 Advice of Advises of discrepancies Y 10,000 N

Discrepancy and requests authorisation
to honour documents
presented that are not in
accordance with the terms
and conditions of the
documentary credit.
752 Authorisation to Pay, Advises a bank which has Y 2,000 N

Accept or Negotiate requested authorisation to
pay, accept, negotiate, or
incur a deferred payment
undertaking that the
presentation of the
documents may be
honoured, notwithstanding
the discrepancies, provided
they are otherwise in order.
754 Advice of Payment/ Advises that documents Y 2,000 N

Acceptance/ have been presented in
Negotiation accordance with the terms
of a documentary credit
and are being forwarded as
instructed. This message
type also handles the
payment/ negotiation.
756 Advice of Re- Advises of the Y 2,000 N

imbursement or reimbursement or payment
Payment for a drawing under a
documentary credit in
which no specific
reimbursement instructions
or payment provisions were
given.
760 Guarantee/Standby Issues or requests the Y 10,000 N

Letter of Credit issue of a guarantee.
22 July 2016 44

Length
767 Guarantee/Standby Amends a guarantee which Y 10,000 N

Letter of Credit has been previously issued
Amendment or requests the amendment
of a guarantee which the
sender has previously
requested to be issued.
768 Acknowledgement Acknowledges the receipt Y 2,000 N

of a Guarantee/ of a guarantee message
Standby Message and may indicate that
action has been taken
according to instructions.
769 Advice of Reduction Advises that a bank has Y 2,000 N

or Release been released of its liability
for a specified amount
under its guarantee.

account.

and Other
Expenses

request.

a previous message.

792 Request for
messages where no
response.
22 July 2016 45

Length

users and for those

800 T/C Sales and Provides the sale and Y 2,000 N

Settlement Advice settlement details for the
[Single] sale of travellers cheques
by a single selling agent.
801 T/C Multiple Sales Provides the details Y 2,000 N

Advice (excluding the settlement
details) of the sales of
travellers cheques in cases
where the data is lengthy or
includes data from several
selling agents.
802 T/C Settlement Provides the settlement Y 2,000 N

Advice details of multiple sales of
travellers cheques.
824 T/C Inventory Notifies the issuer of the Y 2,000 N

Destruction/ destruction/cancellation of
Cancellation Notice travellers cheque inventory
held by the selling agent. It
may also request a selling
agent to destroy/cancel
travellers cheque inventory.

account.

and Other
Expenses

request.
22 July 2016 46

Length

a previous message.

892 Request for
messages where no
response.

users and for those

900 Confirmation of Advises an account owner N 2,000 N

Debit of a debit to its account.
910 Confirmation of Advises an account owner N 2,000 N

Credit of a credit to its account.
920 Request Message Requests the account N 2,000 N

servicing institution to send
an MT 940, 941, 942, or
950.
935 Rate Change Advises the receiver of N 2,000 N

Advice general rate change(s)
and/or rate change(s)
which applies to a specific
account other than a call/
notice loan/deposit
account.
940 Customer Provides balance and N 2,000 N

Statement Message transaction details of an
account to a financial
institution on behalf of the
account owner.
22 July 2016 47

Length
941 Balance Report Provides balance N 2,000 N

information of an account
to a financial institution on
behalf of the account
owner.
942 Interim Transaction Provides balance and N 2,000 N

Report transaction details of an
account, for a specified
period of time, to a financial
institution on behalf of the
account owner.
950 Statement Message Provides balance and N 2,000 N

transaction details of an
account to the account
owner.
970 Netting Statement Provides balance and N 2,000 N

transaction details of a
netting position as
recorded by a netting
system.
971 Netting Balance Provides balance N 2,000 N

Report information for specified
netting position(s).
972 Netting Interim Advises interim balance N 2,000 N

Statement and transaction details of a
netting position as
recorded by a netting
system.
973 Netting Request Requests an MT 971 or N 2,000 N

Message 972 containing the latest
available information.
985 Status Enquiry Requests an MT 986. N 2,000 N
986 Status Report Provides business-related N 2,000 N

information about a
customer or institution.
990 Advice of Charges, Advises an account owner N 2,000 N

account.
22 July 2016 48

Length
991 Request for Requests payment of N 2,000 N

and Other
Expenses
992 Request for Requests the receiver to N 2,000 N

request.
995 Queries Requests information N 2,000 N

a previous message.
996 Answers Responds to an MT 995 N 2,000 N

Queries or MT 992
other messages where no
response.
998 Proprietary Contains formats defined N 10,000 N

users and for those
999 Free Format Contains information for N 2,000 N

(1) A Relationship Management Application (RMA) authorisation is required in order to sign a message with the exception of
the MT 670 and MT 671. Although the MT 670 and MT 671 are signed there is no need to set up RMA for these two
messages as they are exchanged between the user and SWIFT. For more details on the signing of MT 670 and MT 671,
see the FIN Operations Guide.
(2) Special registration is needed for the MT 204 - see the FIN Service Description for details.
(3) The use of MT 502, MT 509, and MT 515 for investment funds is subject to restrictions - the messages may only be sent
or received by institutions that are members of the Funds Closed User Group. For more information, please visit https://
www.swift.com/our-solutions/global-financial-messaging/securities-messages/funds-distribution/funds-migration or email
funds@swift.com.
(4) The appropriate format validation of the IRS Beneficial Owners' List of the MT 574 IRS 1441 NRA is triggered by the code
IRSLST in field 119 ({3:{119:IRSLST}}) of the user header of the message (block 3).
(5) The appropriate format validation of the IRS Form W8-BEN of the MT 574 IRS 1441 NRA is triggered by the code
W8BENO in field 119 ({3:{119:W8BENO}}) of the user header of the message (block 3).
22 July 2016 49
Message User Group registration procedure

Registration is free of charge. To register to use one or more Message Types (MTs), submit a
registration request (Order Message User Group) through www.swift.com. To withdraw from a
Message User Group, use the Terminate your Message User Group subscription.
To get the list of other members of a particular Message User Group, send an MT 999 to the
Customer Implementation team (SWHQBEBBCOS).
5.3 Message Length and Structure

Rules
There are several rules which must be followed when structuring financial messages:
• There are two alternative message length limitations for financial messages, as explained
below. For both alternatives, there is a difference between the message length calculation on
input and on output. The total number of characters always includes headers and trailers.
(See SWIFT Message Types on page 23 for information about the maximum length per
message type.)
Alternatives:
- The number of characters allowed by the SWIFT system on input from a computer-based
terminal is 2,000. On output to a computer-based terminal, the system will limit the
number of characters to 2,600.
- The number of characters allowed by the SWIFT system on input from a computer-based
terminal is 10,000. On output to a computer-based terminal, the system will limit the
number of characters to 10,600. The number of characters permitted on output for
retrieved messages, including headers and trailers, is 11,325.
• When calculating the message length, all characters in the message header blocks, the text
block, and the trailers block are counted. This includes the beginning of block and end of
block characters { and }. Also included in the count are each occurrence of the two
characters Cr and Lf that indicate the start of each new line in the text block.
• The format of each message type specifies a number of fixed and variable length fields. The
presence of these fields may be mandatory or optional.
• A field which is not specified in the format specifications for a particular message type must
never appear.
• A field may appear only once in a sequence, unless repetition is specifically allowed.
• Fields are separated by a unique field separator.
5.4 Message Structure Example

Example: structure of an MT 103
The following example illustrates the structure of a financial message (MT 103) as input by the
sender.
22 July 2016 50
{1:F01OELBATWWAXXX0975000073} Basic header block
{2:I103ABNANL2AXXXXU3003} Application header block
{3:{113:URGT}{108:INTLPMTS}} User header block
{4: (CrLf)
:20:494932/DEV (CrLf)
:23B:CRED (CrLf)
:32A:030731EUR1958,47 (CrLf)
:33B:EUR1958,47 (CrLf)
:50K:FRANZ HOLZAPFEL GMBH (CrLf) Text block

VIENNA (CrLf)
:59:H.F. JANSSEN (CrLf)
LEDEBOERSTRAAT 27 (CrLf)
AMSTERDAM (CrLf)
:70:/INV/ 18042 910412 (CrLf)
:71A:SHA (CrLf)
D0200004
-}
{5:{CHK:123456789ABC}} Trailer block
Note Basic Header, Application Header, User Header, Text and Trailers Blocks are not
separated by CrLf. In the above example, the blocks have been shown on separate
lines for purposes of clarity.
22 July 2016 51
General Information Field Structure and Field Formatting Rules
6 Field Structure and Field Formatting Rules

6.1 General Rules
The following general rules apply to all fields:
• The field length and type of character(s), for example, letters, numbers, are specified in the
Standards MT General Field Definitions Plus and in the field specifications for individual
message types.
• Unless otherwise stated in the Standards MT General Field Definitions Plus or message field
specifications, all specified subfields must be present:
- in the order (that is, sequence) specified
- with no separator symbols (except a slash '/' or double slash '//' when specified)
• Square brackets, [ ], around the format of a particular subfield (in a field containing more than
one subfield), indicate that the subfield is optional within that field.
For example, if the format for a field is '16x[/4x]', up to 16 characters must be present. The
following 4 characters, preceded by a slash '/', are optional, and therefore need not be
present in the field.
• Parentheses, ( ), around the format of two or more subfields indicate that what precedes the
brackets applies to all the subfields listed within the brackets.
For example, the field format 4*(1!n/33x) indicates that 4 lines are allowed in the field and
each line must start with a digit, followed by a slash ('/'), followed by a maximum of 33
characters.
• A field format may be shown on two or more lines:
3!n
6!n
When this is the case, the information must be formatted with the CrLf character sequence
separating each line.
Note In the ISO 15022 securities messages, generic fields are used to specify Party,
Amount, Date, Reference and Other types of data. For further explanation of
this approach, see Category 5 - Securities Markets - Message Usage
Guidelines.
22 July 2016 52
6.2 Field Structure

Structure
Delimiter
Field tag number
Letter option
Delimiter
D0200005
: nn [a] :
Rules
Field structure must comply with the following rules:
• Each field is identified by a tag which consists of two digits, or two digits followed by a letter
option.
• Each field consists of a colon :, followed by a tag, followed by another colon :, and then the
field content.
• The following character restrictions apply to the field content:
- The field content must not start with a Carriage Return, Line Feed (CrLf).
- The field content must not be composed entirely of blank characters.
- Within the field content, apart from the first character of the field content, a colon : or
hyphen - must never be used as the first character of a line.
- Except for fields 15a and 77E, a field must consist of at least one meaningful character.
(See the Standards MT General Field Definitions Plus for formatting requirements.)
• Fields are separated by a 'Field Separator within Text' (CrLf).
• The first field in a message is preceded by a 'Start of Text' (CrLf:) and the last field in a
message is followed by an 'End of Text' (CrLf-).
• See Characters on page 20 for the correct use of the characters Cr and Lf.
• Field content may be composed of one or several subfields.
When subfields appear on separate lines, the Carriage Return, Line Feed (CrLf), which is
not included in the number of characters for the length of the subfield, serves as the subfield
separator.
Subfields:
- Subfields may themselves be of fixed or variable length.
- The order of subfields is fixed.
- When necessary, subfields are separated by special symbols, for example, / or //.
- Subfields must not be entirely composed of blank characters.
- Subfields and/or components must consist of at least one meaningful character.
• If a field content contains mandatory and optional subfields, then at least all of the
mandatory subfields must appear when that field is used.
22 July 2016 53
• The specification of field or subfield content may consist of:

- restrictions on the length of field or subfield content, using the descriptions listed in
Restrictions on Length on page 54
- special formats, for example, for numbers and dates
- codes, for example, currency codes
(See the BIC Directory, which is available for download from www.swiftrefdata.com.)
• In some messages, the field specifications may indicate specific characters, or sets of
characters, for inclusion in the text of the field.
These take the following forms:
- codes, for example, AMEND, TRF, or 08
- slash / or double slash //
- slash or double slash followed by a code, for example, //CH or /FIXED
- slash followed by a code and another slash, for example, /REC/
Note All codes must be in uppercase alphabetic characters. When codes contain a mix
of alphabetic and numeric characters, the alphabetic character must also be in
uppercase.
Restrictions on Length
Restrictions on Length Types of Characters Allowed
nn maximum length n numeric digits (0 through 9) only

(minimum is 1)
nn-nn minimum and a alphabetic letters (A through Z), upper

maximum length case only
c alphabetic letters (upper case) and digits

only
h hexadecimal letters A through F (upper

case) and digits only
nn! fixed length x any character of the X permitted set

(General FIN application set) upper and
lower case allowed (SWIFT Character
Set (X Character Set) on page 20)
y any character of the EDIFACT level A

character set as defined in ISO 9735
upper case only (EDIFACT Level A
Character Set (Y Character Set) on page
20)
z any character as defined by the

Information Service (Information Service
Character Set (Z Character Set) on page
20)
22 July 2016 54
Restrictions on Length Types of Characters Allowed
nn*nn maximum number of d decimals

lines times maximum
line length e blank space
Examples
2n up to 2 digits
3!a exactly 3 uppercase letters
4*35x up to 4 lines of up to 35 characters each
16-64h at least 16 and up to 64 hexadecimal characters
6.3 Field Formatting
6.3.1 Dates
Formats
Format: 4!n
Format: 6!n
Format: 8!n
Rules
Dates are represented as either: 4, 6, or 8 digit integers, that is, in ISO form MMDD,
YYMMDD, or YYYYMMDD
Where:
• YY = last 2 digits of the year
• YYYY = all four digits of the year
• MM = month
• DD = day
No blank spaces or other characters are permitted.

Examples:
• 1129 = November 29
• 941129 = 94 November 29
• 19941129 = 1994 November 29
The date field formatted as 6!n (YYMMDD) distinguishes between the 20th and 21st century as
follows:
22 July 2016 55
If the year, (YY) is greater than 79, the date refers to the 20th century. If the year is 79 or less,
the date refers to the 21st century:
If YY > 79 YYMMDD = 19YYMMDD
else YYMMDD = 20YYMMDD
The six-digit date thus ranges from 1980 to 2079.

On the FIN network, there is an additional restriction for the year range where the date is
affected by the Value Date Ordering process (Value Date Ordering on page 73).
The valid date range of 1980 to 2060 applies to:
• field 30, in MTs: 101, 104, 107, 110, 111, 112, 201, 203, 204, 207, 210, and 256
• field 32A, in MTs: 102, 102 STP, 103, 103 REMIT, 103 STP, 110, 111, 112, 200, 202, 202
COV, 205, 205 COV, 256, 900, and 910
6.3.2 Numbers
Format
nn...nn, nn...n
Fractional part (optional)
D0200006
Integer part
Usage rules
Wherever they represent a numeric value, numbers always take the same form:
• The integer part must contain at least one digit.
• Decimal points are not permitted. A decimal comma ',' shall precede the fractional part.
• The maximum length includes the decimal comma.
• The fractional part may be missing, but the decimal comma must always be present.
• Neither blank spaces, nor any symbols other than the decimal comma are permitted.
• The integer part is mandatory in the number component, and at least one character must
appear. Leading zeros are allowed.
• Normally, when a number represents an amount of money, the number of places following
the decimal comma may not exceed the number of decimal digits valid for the specified
currency. The specifications for the individual message types will indicate the fields where
this is not the case. Details regarding the allowable fractional parts for each currency code
may be found in the BIC Directory download file (CU***.txt file), which is available on
www.swiftrefdata.com.
22 July 2016 56
Examples
Valid Invalid
000,00 0000
0, 0
0,67 .67
0,25 ,25
100000, 100.000
25768, 25-768
99999999, 999.999.999
100, 100
10500,00 10500.00
5,25 5 1/4
6.3.3 Currency Codes
Format
Format: 3!a
Description
A currency code must be a valid ISO 4217 currency code, which normally consists of a two-
letter ISO country code followed by a third letter denoting the particular currency or type of
funds.
6.3.4 Party Identification
Parties may be represented in several ways:

• Identifier Code (BIC)
• branch (city) of the sender or the receiver
• name and address
• other identification codes, for example, account number
When necessary, party identification can be supplemented by an account number line preceding
other party information.
6.3.4.1 Party Identifier
Overview
When further identification of a party, for example, specification of an account number to be
credited, is necessary, the party identifier should be used.
Format: [/1a][/34x]
22 July 2016 57
Where:
Subfield 1 [/1a] Specifies which account is involved:
/C The receiver's account serviced by the sender is credited.
/D The sender's account serviced by the receiver is debited.
Subfield 2 [/34x] The account number information, preceded by a slash '/'.
Rules
When the party identifier is present, the following rules apply:
• The party specified in the field with the account must be the account owner. The optional
party identifier must specify the account known to the account servicing institution.
• Extreme care must be taken when formatting the party identifier, for example, when only
subfield 2 '[/34x]' is entered, and its first and third characters consist of '/', the system can
only presume that both subfields 1 and 2 are present. It will then qualify the second
character for either code 'C' or 'D', and NAK the message if one or the other is not present
(Error code T51).
Note Other fields impacted by this form of validation are:
• 42A, 42D.
• 50D, 50F*, 51A, 51D, 52A, 52B, 52D, 53A, 53B, 53D, 54A, 54B, 54D, 55A, 55B,
55D, 56A, 56B, 56D, 57A, 57B, 57D, 58A, 58B, 58D.
• 82A, 82B, 82D, 83A, 83D, 84A, 84B, 84D, 85A, 85B, 85D, 86A, 86B, 86D, 87A,
87B, 87D, 88A, 88B, 88D.
* See additional structure for party identifier in section Option F: Party Identifier/
Name and Address on page 65.
Additional rules
The following additional rules apply:
• An account specified in field 58a or 59a must be owned by that party and must be serviced
by the financial institution in field 57a or, if field 57a is absent, by the receiver.
• An account specified in field 57a must be owned by that party and must be serviced by the
financial institution in field 56a or, if field 56a is absent, by the receiver.
• An account specified in field 56a must be owned by that party and must be serviced by the
receiver.
• In field 53a, when an account is used it normally indicates:
- which account is to be used for reimbursement, if multiple accounts in the currency of the
transaction are serviced for the other party. In this case, the account should be specified
- whether the sender's account serviced by the receiver, or the receiver's account serviced
by the sender, is to be used for reimbursement, if they both service accounts for each
other in the currency of the transaction. In this case, the account to be debited or credited
shall be indicated in the party identifier by either the code /C or /D, or the account, or both
In both cases, this information should be specified in field 53a with the format option B (party
identifier only).
22 July 2016 58
Examples
Valid Invalid
:53A:/C/12-12 :53A:/6/12-12
CITIUS33CHI CITIUS33CHI
:53B:/D/24-24 :53B:/A/24-24
:53D:/52/48-48 :53D:/:/48-48
John Doe John Doe
122 Peyton Place 122 Peyton Place
Elyria, OH 22216 Elyria, OH 22216
:87E:FREE :87E:APMT
/C/12-12 /A/12-12
CHASUS33 CHASUS33
:87F:APMT :87F:APMT
/D/12-12 /:/48-48
John Doe John Doe
122 Peyton Place 122 Peyton Place
Elyria, OH 22216 Elyria, OH 22216
Example
Bank A in New York services an account in USD for Bank B in London. Bank B also services, in
London, a USD account (number 567-3245-01) for Bank A.
Bank A sends a USD transfer to Bank B, using its USD account in London, serviced by Bank B,
for reimbursement. Bank A will request that Bank B debit its account in London as follows:
53B:/D/567-3245-01
Note In certain message types, there are exceptions to the rules for use of the party
identifier detailed in this section, for example, field 57a in category 3 messages. In
those cases, the intended use of the party identifier is described in the relevant
field specification for the message type.
6.3.4.2 Option No Letter: Name and Address
Format
[/34x] (Account)
4*35x (Name and Address)
Definition
Name and address of the party, with an optional account.
Network validated rules
If the first line of this field starts with a slash '/', then it is assumed that Account is present and
then at least 1 line of Name and Address must be present (Error code T77).
22 July 2016 59
Usage rules
If Account is absent, then Name and Address must not start with a slash '/'.
Field assigned to this option
59
6.3.4.3 Option A: Identifier Code
Format
[/1a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code)
Definition
Identifier code such as a BIC. Optionally, the account of the party.
Identifier Code must be a registered BIC (Error codes T27, T28, T29 and T45).
For institutions which are not SWIFT users, that is, which are not yet connected, the eighth
position must consist of the digit '1'.
Examples
The following example shows BICs of non-connected users, without, and with, a branch
identifier:
:53A:CHBAKHH1
:54A:CHBLGB21BBB
Fields assigned to this option

• 41A*, 42A
• 50A**, 51A, 52A, 53A, 54A, 55A, 56A, 57A, 58A, 59A
• 82A, 83A, 84A, 85A, 86A, 87A, 88A
Note When this option is used, the SWIFT system will validate the correctness of the
Identifier Code, that is, to ensure that it is registered : either connected or non-
connected.
(*) Field 41A does not have the optional party identifier, but does have an additional
subfield.
See Option D: Name and Address on page 61 on the use of clearing codes.
(**) Field 50A has the format [/34x] for Party Identifier.
6.3.4.4 Option B: Branch of Sender/Receiver
Format
22 July 2016 60
[35x] (Location)
Usage rules
When used, at least one line must be present.
An account number only, not followed by any other identification, is allowed (field 53a).
For field 52a, the field specifications for individual message types specify whether this option
identifies a branch of the sender or the receiver.
In field 53a, this option specifies either the account to be debited or credited, or a branch of the
sender, that is, of the financial institution specified in the sender's address in the header.
In fields 54a and 57a, this option specifies a branch of the receiver, that is, of the financial
institution specified in the receiver's address in the header.
Fields assigned this option
52B, 53B, 54B, 55B, 57B, 58B
82B, 84B, 85B, 87B, 88B
6.3.4.5 Option C: Account Number/Party Identifier
Format
/34x (Account)
Definition
A code uniquely identifying an account and/or party.
In the MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, and 104, clearing codes may be
used.
Fields assigned this option
51C, 52C, 53C, 56C, 57C, 58C
82C, 83C, 85C, 87C, 88C
Note See Option D: Name and Address on page 61 on the use of clearing codes.
6.3.4.6 Option D: Name and Address
Format
Note This option is used when no other option is available.

This information also applies to fields 50 (when option representing name and
address is selected) and 59 (without letter option).
22 July 2016 61
Definition
Name and address and, optionally, the account or clearing code of the party.
If the first line of this field starts with a slash '/', then it is assumed that Party Identifier is present
and then at least 1 line of Name and Address must be present (Error code T77).
Usage rules
When the party identification is provided by name and address (whether by full postal address
or informal identification), the following rules apply:
• at least one line of the name and address must be present, in addition to the party identifier
• the street address must be on a new line following the name
• when a city is present, it must be on the last line, with the postal code (zip, etc.), state and
country identification
Although more than one element of an address may appear on each line, care should be taken
that, when possible, no element, for example, street address, should be spread over more than
one line.
If a Party Identifier is absent, then Name and Address must not start with a slash '/'.
National clearing codes list
When the party identifier is used to indicate a national clearing system code preceded by a
double slash '//', the following codes may be used:
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
CH 6!n CHIPS Universal Identifier
CP 4!n CHIPS Participant Identifier
CN 12..14n China National Advanced Payment System (CNAPS) Code
ES 8..9n Spanish Domestic Interbanking Code
FW 9!n Fedwire Routing Number
GR 7!n HEBIC (Hellenic Bank Identification Code)
HK 3!n Bank Code of Hong-Kong
IE 6!n Irish National Clearing Code
IN 11!n Indian Financial System Code (IFSC) is the identification scheme

defined by the Reserve Bank of India
22 July 2016 62
IT 10!n Italian Domestic Identification Code
PL 8!n Polish National Clearing Code (KNR)
PT 8!n Portuguese National Clearing Code
RU 9!n Russian Central Bank Identification Code
SC 6!n UK Domestic Sort Code
SW 3..5n Swiss Clearing Code (BC code)
SW 6!n Swiss Clearing Code (SIC code)
In some messages, some of these clearing codes may also be used with option A, that is, the
MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, and 104. This is indicated with the field
specifications of each message type.
When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //RT is used, it
should appear only once, and in the first of the fields 56a and 57a of the payment instruction.
When it is necessary that an incoming SWIFT payment be made to the party in this field via
Fedwire, US banks require that the code FW appears in the optional Party Identifier.
When it is necessary that an incoming SWIFT payment be made to the party in this field via a
real-time gross settlement system (RTGS), the code RT should appear in the optional Party
Identifier.
Option D must only be used in exceptional circumstances, that is, when the party cannot be
identified by a BIC, and when there is a bilateral agreement between the sender and the
receiver permitting its use. Unless qualified by a clearing system code or an account number,
the use of option D may prevent the automated processing of the instruction(s) by the receiver.
National clearing codes formats
List of codes and formats:
• The Australian BSB code is the identification scheme defined by APCA (Australian
Payments Clearing Association).
Its structure is either:
for financial institutions with an extensive branch network:
- 2!n = Bank Code
- 1!n = State Code
- 3!n = Branch Code
or for institutions with a small network:
- 3!n = Bank Code
- 3!n = Branch Code
• The Bank Code for Hong-Kong is structured as follows:
- 3!n = Bank Code
22 July 2016 63
• The Hellenic Bank Identification Code (HEBIC) is the identification scheme defined by the
Hellenic Bank Association. Its structure is:
- 3!n = Bank Code
- 4!n = Branch Code
• The Indian Financial System Code (IFSC) is the identification scheme defined by the
Reserve Bank of India. Its structure is:
- 4!a = Bank Code (same as party prefix in BIC - ISO 9362)
- 1!n = Zero - Reserved for future use
- 6!c = Branch Code
• The structure of the Irish NSC code is 2!n4!n, where:
- 2!n = Bank Code
- 4!n = Branch Code
• The Italian ITBI code is the identification scheme defined by ABI (Associazione Bancaria
Italiana). Its structure is:
- 5!n = Bank Code (ABI)
- 5!n = Branch Code (CAB)
• The New Zealand Bank/Branch Code is the identification scheme defined by NZBA (New
Zealand Bankers Association). Its structure is:
- 2!n = Bank Code
- 4!n = Branch Code
• The Portuguese National Clearing code is defined by the Banco de Portugal. Its structure is
4!n4!n, where:
- 4!n = Bank Code (IFRI), potentially containing leading zeros
- 4!n = Branch Code (BLCI) which is unique for each branch and locally assigned by the
• The Russian Central Bank Identification Code is to be considered as one, uniform,
indivisible code. Its structure is 2!n2!n2!n3!n, where:
- 2!n = Country Code. The first position is always 0 and is not shown in the database of the
Central Bank of Russia.
- 2!n = Region Code within the country
- 2!n = Code of the division of the Central Bank in the region
- 3!n = Bank Code
22 July 2016 64
• The South African National Clearing code is defined by BankServ, the South African
Bankers Services Company Ltd. Its structure is 3!n3!n, where:
- 3!n = Bank Code, potentially with leading zeros
- 3!n = Branch Code, potentially with leading zeros
• The Spanish Domestic Interbanking Code is the identification scheme defined by CCI
(Centro de Cooperacion Interbancaria). Its structure is:
- 4!n = Bank Code
- 4!n = Branch Code
- [1!n] = Check Digit
42D
50D, 51D, 52D, 53D, 54D, 55D, 56D, 57D, 58D
82D, 83D, 84D, 85D, 86D, 87D, 88D
Note Field 41D does not have the optional party identifier but does have an additional
subfield.
6.3.4.7 Option F: Party Identifier/Name and Address
Format
[35x] (Party Identifier)
The following line formats must be used (Error code(s): T54):
Line 1 (subfield Party Identifier) /34x (Account)
Line 2-5 (subfield Name and 1!n/33x (Number)(Details)

Address
Or
Line 1 (subfield Party Identifier) 4!a/2!a/27x (Code)(Country Code)(Identifier)
Line 2-5 (subfield Name and 1!n/33x (Number)(Details)

Address
Or
Line 1 (subfield Party Identifier) [/34x] (Account)
Line 2-5 (subfield Name and 1!n/33x (Number)(Name and Address

Address Details)
22 July 2016 65
Definition
Name and address in a structured format to facilitate straight through processing.
Codes
When Party Identifier is used with the (Code)(Country Code)(Identifier) format, for example in
field 50F Ordering Customer, one of the following codes must be used:
ARNU Alien Registration Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Alien Registration
Number.
CCPT Passport Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Passport Number.
CUST Customer Identification The code followed by a slash, '/' must be followed by the
Number ISO country code of the issuer of the number, a slash, '/',
the issuer of the number, a slash, '/' and the Customer
Identification Number.
DRLC Driver's License Number The code followed by a slash, '/' must be followed by the
ISO country code of the issuing authority, a 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 of the registration authority, a slash, '/',
the registration authority, a slash, '/' and the Employer
Number.
NIDN National Identity Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the National Identity
Number.
SOSE Social Security Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Social Security
Number.
TXID Tax Identification Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Tax Identification
Number.
Codes
On each line of Name and Address, subfield Number must contain one of the following values
(Error code(s): T56):
1 Name of the Ordering The number followed by a slash, '/' must be followed by
Customer the name of the ordering customer.
2 Address Line The number followed by a slash, '/' must be followed by

an address line (Address Line can be used to provide for
example, street name and number, or building name).
22 July 2016 66
3 Country and Town The first occurrence of number 3 must be followed by a

slash, '/', the ISO country code, and optionally a slash '/'
followed by additional details.
Other occurrence(s) of number 3 must be followed by a
slash '/' and the continuation of additional details.
Additional details can contain town, which can be
complemented by postal code (for example zip) and
country subdivision (for example state, province, or
county).
The country code and town should, preferably, indicate
the country and town of residence.
Some option F fields also allow for these values in Number:
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 Identification The number followed by a slash, '/' must be followed by

Number the ISO country code of the issuer of the number, a
slash, '/', the issuer of the number, a slash, '/' and the
customer identification number.
7 National Identity Number The number followed by a slash, '/' must be followed by
the ISO country code, a slash, '/' and the national identity
number.
8 Additional Information The number followed by a slash, '/' is followed by

information completing one of the following:
• the Identifier provided in subfield 1 (Party Identifier)
used with the (Code)(Country Code)(Identifier)
format.
• the Customer Identification Number provided in
subfield 2 (Name and Address) with number 6.
• the National Identity Number provided in subfield 2
(Name and Address) with number 7.

In subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country
Code must be a valid ISO country code (Error code(s): T73).
In subfield 2 (Name and Address):
• The first line must start with number 1 (Error code(s): T56).
• Numbers must appear in numerical order (Error code(s): T56).
• Number 2 must not be used without number 3 (Error code(s): T56).
22 July 2016 67
• The first occurrence of number 3 must be followed by a valid ISO country code (Error
code(s): T73).
• Option F fields that also allow the numbers 4 – 8 in Number, for example field 50F, have
these additional network validated rules:
- Number 4 must not be used without number 5 and vice versa (Error code(s): T56).
- Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local
to the sender, must not be later than the date on which the message is successfully sent
to SWIFT (Error code(s): T50).
- Numbers 5, 6, and 7 must be followed by a valid ISO country code (Error code(s): T73), a
slash '/' and additional Details (Error code(s): T56).
- Numbers 4, 5, 6, 7, and 8 must not be repeated (Error code(s): T56).
- The use of number 8 is only allowed in the following instances (Error code(s): T56):
▪ to continue information on the Identifier of the ordering customer provided in subfield 1
(Party Identifier) used with the (Code)(Country Code)(Identifier) format.
▪ to continue information on the Customer Identification Number provided in subfield 2
(Name and Address) following number 6.
▪ to continue information on the National Identity Number provided in subfield 2 (Name
and Address) following number 7.
Usage rules
• In subfield 2: Numbers 1, 2, and 3 may be repeated.
• In subfield 2: if number 2 is present, the first occurrence of number 3 must include the town
in additional details.
For ordering customer:
• Subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if
additional space is required for providing the Identifier of the ordering customer, one of the
following options must be used:
- First option (preferred): Identify the ordering customer with a different identifier where the
length is not an issue.
- Second option: Continue the information in subfield 2 (Name and Address) using number
8.
• Subfield 2 (Name and Address): if additional space is required for providing the Customer
Identification Number (number 6) or the National Identity Number (number 7) of the ordering
customer, one of the following options must be used:
- First option (preferred): Identify the ordering customer with a different identifier where the
length is not an issue.
- Second option: Continue the information in subfield 2 (Name and Address) using number
8.
50F, 59F
22 July 2016 68
6.3.4.8 Option G: Identifier Code
Format
/34x (Account)
4!a2!a2!c[3!c] (Identifier Code)
Definition
Identifier code of the party with mandatory account number.
Identifier Code must be a registered BIC (Error codes T27, T28, T29, and T45).
50G, 52G
6.3.4.9 Option H: Name and Address
Format
/34x (Account)
Definition
Name and address of the party with a mandatory account.
50H
6.3.4.10 Option J: Party Identification with no Party Identifier
Format
5*40x (Narrative)
Definition
Identification of the party.
Codes
The following codes can be used with this option. Depending on the field tag and message type,
some codes may or may not be used, may exclude each other or not, or may be mandatory or
not:
22 July 2016 69
Code Format Description
/ABIC/ 4!a2!a2!c[3!c] or the BIC or 'UKWN' if BIC not known

4!a
/ACCT/ 34x account followed by the account number
/ADD1/ 35x address followed by the first line of the address
/ADD2/ 35x address followed by the second line of the address
/CITY/ 35x city followed by the name of city (and state, country)
/CLRC/ 35x Clearing Code followed by a clearing code
/GBSC/ 6!n CHAPS followed by CHAPS sort code
/LEIC/ 18!c2!n Legal Entity Identifier
/NAME/ 34x name followed by the name
/NETS/ - a net settlement is taking place
/SSIS/ - standard settlement instructions are used
/USCH/ 6!n CHIPS followed by CHIPS UID
/USFW/ 9!n FedWire followed by FedWire Routing Number
The codes do not need to be put on separate lines. It is the '/' at the beginning of a code, not the
end-of-line, that marks the end of the information behind the previous code.
As a result, the narrative following the code may not contain a slash '/'. The end-of-line may be
part of the narrative text following the code, but it is to be ignored when reading the field.
However, the end-of-line may not be part of the code.
Examples
/ABIC/BNKAXA11/NAME/BANK A OF XANADU(CrLf)
/NAME/BANK A OF XANADU/ABIC/BNKAXA11(CrLf)
/ABIC/BNKAXA11(CrLf) /NAME/BANK A OF XANADU(CrLf)
/ABIC/BNKAXA11/NAME/BRANCH B OF THE(CrLf)
SECOND NATIONAL BANK A OF XANADU(CrLf)

53J, 56J, 57J, 58J
82J, 83J, 84J, 85J, 86J, 87J, 88J.
6.3.4.11 Option K: Name and Address
Format
[/34x] (Account)
22 July 2016 70
Definition
Name and address of the party, with an optional account.
If the first line of this field starts with a slash '/', then it is assumed that Account is present and
then at least 1 line of Name and Address must be present (Error code T77).
Usage rules
If Account is absent, then Name and Address must not start with a slash '/'.
50K
6.3.4.12 Option L: Party Identification
Format
35x (Narrative)
Definition
Identification of the party
50L
6.3.4.13 Option P: Party
Format
:4!c//4!a2!a2!c[3!c] (Qualifier)(Identifier Code)
Definition
Identification of the party, with a qualifier and an identifier code such as a BIC.
95P
6.3.4.14 Option Q: Party
Format
:4!c//4*35x (Qualifier) (Name and Address)
Definition
Identification of the party, with a qualifier and name and address.
22 July 2016 71

95Q
6.3.4.15 Option R: Party
Format
:4!c/8c/34x (Qualifier) (Data Source Scheme) (Proprietary Code)
Definition
Identification of the party, with a qualifier, issuer code and proprietary code.
95R
6.3.4.16 Option S: Party
Format
:4!c/[8c]/4!c/2!a/30x (Qualifier) (Data Source Scheme) (Type of ID) (Country

code) (Alternate ID)
Definition
Identification of the party, with a qualifier, an optional issuer code, type of ID, country code and
alternate ID.
95S
6.3.4.17 Option T: Party
Format
:4!c//2*35x (Qualifier) (Name)
Definition
Identification of the party, with a qualifier and name.
95T
6.3.4.18 Option U: Party
Format
:4!c//3*35x (Qualifier) (Name)
22 July 2016 72
Definition
Identification of the party, with a qualifier and names.
95U
6.3.5 Times
Formats
4!n
6!n
Rules
Times are represented as either four or six digit integers, that is, in form HHMM or HHMMSS
respectively, where (Error code T38):
• H = Hour
• M = Minutes
• S = Seconds
No blank spaces or other characters are permitted.
Examples
0000
1200
235959
6.3.6 Value Date Ordering
Overview
The SWIFT system allows the receiver to request value date ordering of its value date sensitive
messages.
The value date sensitive messages are:
• MT 910
• all Category 1 and Category 2 messages containing fields 30 or 32A, or both 30 and 32A,
except common group messages 192, 292, 195, 295, 196, and 296
The valid range of value dates implemented on the SWIFT system for these MTs is from 1980 to
2060, and must meet the following requirements:
• allowed: a year component, for example, 'YY' in the range of 80 through 60, of an ISO
defined six digit integer date 'YYMMDD'
• not allowed: any 'YY' component outside of this range, for example, 'YY' in the range of 61
through 79
Example
ACKed NAKed
22 July 2016 73
:32A:601130USD1, :32A:611130USD1,
:30:801130 :30:791130
For the purpose of value date ordering, if there is more than one value date field in a message,
the lesser date will be selected:
MTxxx
:30:951218 Value date = 18th December 1995

:32A:020103USD123000,00
Value Date = 3rd January 2002
In this example, field 30 Value Date (18 December 1995) is selected for value date ordering of
the message. Error code T50 is returned after an invalid value date.
22 July 2016 74
General Information Euro-Related Information (ERI)
7 Euro-Related Information (ERI)

7.1 Deletion of National Currency Denomination (NCD) Currency
Codes
On 1 March 2002, ISO announced the deletion of the National Currency Denomination (NCD)
currency codes from the official ISO currency code table 4217. The currencies concerned are
ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE, and XEU. On 1 January 2007,
ISO announced a similar deletion for the SIT.
For certain message types, when NCDs are used as the currency of settlement, SWIFT
validates to ensure that the value date is not after the date on which the currencies ceased to be
a legal tender:
• When ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, the
value date must not be after 31 December 2001.
• When the Slovenian currency code SIT is used, the value date must not be after 31
December 2006.
• When the Cyprus currency code CYP or the Maltese currency code MTL are used, the value
date must not be after 31 December 2007.
• When the Slovakian currency code SKK is used, the value date must not be after 31
December 2008.
• When the Estonian currency code EEK is used, the value date must not be after 31
December 2010.
• When the Latvian currency code LVL is used, the value date must not be after 31 December
2013.
• When the Lithuanian currency code LTL is used, the value date must not be after 31
December 2014.
Until further notice, and where allowed (NCDs cannot be used in settlement amount fields),
SWIFT will continue to support NCD currency codes (for example, instructed amounts, ERI) in
the relevant fields of its message types.
7.2 Euro-Related Information (ERI)

This section discusses what is meant by Euro-Related Information (ERI).
7.2.1 ERI Content
Euro-Related Information (ERI) refers to the following data:

• original currency
• original amount
• transaction charges
The original currency and amount in ERI is the equivalent of the information in the field
containing the amount which is used for interbank settlement of the transaction. This field may
contain additional information, for example, value date.
22 July 2016 75
ERI may be specified in one of several free-text fields preceded by a code. As of Standards
release 2001, the use of ERI was extended to non-European currencies and beyond the
transition period of 3 years.
In the Corporate Action messages within Category 5, codes are used to indicate the processing
of redenominations.
7.2.2 ERI Usage Guidelines and Rules
Introduction
The specification of ERI is always optional. If used, however, the rules specified in this section
apply.
If a network validated rule mandates the presence of an exchange rate field where both the
transaction amount and the original ordered amount are quoted (for example, field 36 in the MTs
101, 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107), this rule remains effective. In the case
of euro-related currencies, the exchange rate field must specify the value of the fixed euro
conversion rate.
See ERI Validation and Examples on page 85 for details of specific ERI validation rules.
Usage rules
The following rules must be adhered to but are not validated by the network:
• ERI may be used only when the message does not have a specific existing field to specify
the information.
If specific fields have been defined in a message to contain the original currency and
amount, these fields, and not ERI, should be used to indicate the original currency and
amount. For example, all ISO 15022 compliant Category 5 Trade Initiation and Confirmation
(TIC), Settlement and Reconciliation (S&R) and Corporate Action (CA) messages contain
specific fields for this purpose, as does the MT 103.
• As with all other information occurring in fields 72, 77A, or 79, ERI is for information
purposes only.
In the case of a discrepancy between ERI and the settlement amount (for example, net
proceeds), specified in the message, the information in the settlement amount prevails.
Usage guidelines
Guidelines when specifying fields are:
• If no specific fields are available to specify the original currency and amount, ERI may be
used in any message type containing a free text field 72, 77A, or 79. The use of ERI is not
restricted to specific message types. See Messages Likely to Contain ERI on page 78.
• The preferred field for specifying ERI is field 72. If not present, field 77A should be used. If
there is no field 72 nor 77A, then field 79 should be used.
• If ERI is specified in field 72, 77A, or 79, it should appear on the first line whenever possible.
Whatever line is used, the ERI should always appear on the first position of that line.
• For message types that do not contain a field 72, 77A, nor 79, there are only two that may
need to specify a second currency: MTs 940 and 942.
For these two cases, subfield 9 of field 61 should be used to specify ERI. If this subfield is
used for other purposes, field 86 should be used to specify ERI. It is recommended that the
sender of the MT 940/942 advises the receiver whenever field 86 is used to contain ERI.
22 July 2016 76
• Where the settlement amount is part of a repetitive sequence which does not contain a free
text field, the message should be used as a single transaction message, that is, one
message should be used per transaction.
• Where transaction charges are specified in ERI, this information must appear after the code /
CHGS/. This will not necessarily be processed by the receiver.
• ERI is designed to be passed on unchanged in the appropriate message types throughout
the entire transaction, that is, throughout the chain of messages relating to the transaction.
Therefore it should appear in the appropriate SWIFT messages related to the transaction.
7.2.3 ERI Structure
Format
Field 72 6*35x
Field 77A 20*35x
Field 79 35*50x
Definition
In addition to previously defined sender to receiver information, or other narrative information,
these fields may include Euro-Related Information (ERI) for information purposes. ERI indicates
currency conversion details, related to the conversion of the original currency into a settlement
currency, found in free text fields.
It is recommended that ERI be structured in these free text fields, using codes.
Codes
The following codes must be used
/OCMT/ 3!a15d/ O Original currency and amount.

If no charges are specified then the
original currency and amount will be the
equivalent of the transaction amount
specified in the message.
/CHGS/ 3!a15d/ O Currency and amount of the transaction

charges.
When the BEN option is used in
payments and related messages, that is,
all transaction charges are to be paid by
the beneficiary customer, the charges
amount has been deducted from the
original amount to obtain the settlement
amount specified in the message.
Usage rules
The network will validate the structure of ERI, but not the content, see section ERI Validation
and Examples on page 85 for details.
22 July 2016 77
Example
:72:/OCMT/GBP2525,/
/CHGS/EUR2,40/
7.3 Message Specific Guidelines on the Use of ERI

This section lists message types which:
• are likely to contain ERI
• contain a special field for original amount
• are to be validated against a specified value date
7.3.1 Messages Likely to Contain ERI
List of message types that can contain ERI in a free text field
The following lists message types that are likely to contain Euro-Related Information (ERI) in a
free text field. Message types that already contain a field to specify an original currency and
amount, are not included here.
If there are business requirements to specify ERI in other message types, these should be
similarly specified in a free text field 72, 77A, or 79, as explained in ERI Structure on page 77.
This list is therefore not exhaustive.
MT MT Name Settlement Amount Repetitive/N ERI Repetitive/N

Field on Repetitive Field on Repetitive
202 General Financial 32A Value Date, NR 72 NR

Institution Transfer Currency Code,
Amount
202 General Financial 32A Value Date, NR 72 NR

COV Institution Transfer Currency Code,
Amount
203 Multiple General 32B Currency Code, R 72 R

Financial Institution Amount
Transfer
204 Financial Markets Direct 32B Currency Code, R 72 R

Debit Message Amount
205 Financial Institution 32A Value Date, NR 72 NR

Transfer Execution Currency Code,
Amount
205 Financial Institution 32A Value Date, NR 72 NR

COV Transfer Execution Currency Code,
Amount
207 Request for Financial 32B Currency Code, R 72 NR

Institution Transfer Amount
22 July 2016 78
MT MT Name Settlement Amount Repetitive/N ERI Repetitive/N

Field on Repetitive Field on Repetitive
400 Advice of Payment 33A Proceeds NR 72 NR

Remitted
450 Cash Letter Credit 32A Value Date, R 72 NR

Advice Currency Code,
Amount
455 Cash Letter Credit 33a Value Date and R 72 NR

Adjustment Advice Adjustment Amount
456 Advice of Dishonour 33D Total Amount R 72 NR

Debited
559 Paying Agent's Claim 34A Net Proceeds NR 72 NR
581 Collateral Adjustment 34B Outstanding NR 72 NR

Message Collateral Value
752 Authorisation to Pay, 33a Net Amount NR 72 NR

Accept or Negotiate
754 Advice of Payment/ 34a Total Amount NR 72 NR

Acceptance/Negotiation Claimed
756 Advice of 33A Amount NR 72 NR

Reimbursement or Reimbursed or Paid
Payment
768 Acknowledgement of a 32a Amount of NR 72 NR

Guarantee/Standby Charges
Message
769 Advice of Reduction or 32a Amount of NR 72 NR

Release Charges
900 Confirmation of Debit 32A Value Date, NR 72 NR

Currency Code,
Amount
910 Confirmation of Credit 32A Value Date, NR 72 NR

Currency Code,
Amount
940 Customer Statement subfield 5 of field 61 R 61/9 or R

Message 86
942 Interim Transaction subfield 5 of field 61 R 61/9 or R

Report 86
22 July 2016 79
7.3.2 Messages Containing a Special Field for Original Amount
List of message types containing a special field for original amount

The following lists message types that already have a special field for specifying an original
amount to be transferred. This list is not exhaustive, as there may be other messages with
special fields specifying an original amount.
MT MT Name Settlement Repetitive/N ERI Field Repetitive/N

Amount Field on Repetitive on Repetitive
101 Request for 32B R 33B R

Transfer
102 Multiple 32B R 33B R

Customer
102 STP Credit Transfer
103 Single 32A NR 33B NR

Customer
103 Credit Transfer
REMIT
103 STP
104 Direct Debit 32B R 33B R

and Request
for Debit
Transfer
107 General Direct 32B R 33B R

Debit Message
513 Client Advice 19A::SETT NR 19A::OCMT NR

of Execution
514 Trade 19A::SETT NR 19A::OCMT NR

Allocation
Instruction
515 Client 19A::SETT NR 19A::OCMT NR

Confirmation of
Purchase or
Sale
518 Market-Side 19A::SETT NR 19A::OCMT NR

Securities
Trade
Confirmation
541 Receive 19A::SETT NR 19A::OCMT NR

Against
Payment
22 July 2016 80
MT MT Name Settlement Repetitive/N ERI Field Repetitive/N

Amount Field on Repetitive on Repetitive
543 Deliver Against 19A::SETT NR 19A::OCMT NR

Payment
545 Receive 19A::ESTT NR 19A::OCMT NR

Against
Payment
Confirmation
547 Deliver Against 19A::ESTT NR 19A::OCMT NR

Payment
Confirmation
564 Corporate 19A::ESTT NR 19A::OCMT NR

Action
Notification
566 Corporate 19A::ESTT NR 19A::OCMT NR

Action
Confirmation
7.3.3 Messages with Value Date Validation
List of message types used to transfer amounts in National Currency Denominations

The following table contains messages that can be used to transfer amounts in National
Currency Denominations (NCDs).
If ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, the value
date has to be equal to, or before 31 December 2001.
If SIT is used, the value date has to be equal to, or before 31 December 2006.
If CYP or MTL is used, the value date has to be equal to, or before 31 December 2007.
If SKK is used, the value date has to be equal to, or before 31 December 2008.
If EEK is used, the value date has to be equal to, or before 31 December 2010.
If LVL is used, the value date has to be equal to, or before 31 December 2013.
If LTL is used, the value date has to be equal to, or before 31 December 2014.
If these validations against value date fail, the message will be NAKed (Error code E76).
Note Statement messages are not validated against value date, since they are generally
the result of earlier validated messages. Furthermore, accounts are no longer held
in any of the discontinued National Currency Denominations (NCDs) mentioned
above.
Currencies concerned
The currencies concerned are ATS, BEF, CYP, DEM, EEK, ESP, FIM, FRF, GRD, IEP, ITL, LUF,
LTL, LVL, MTL, NLG, PTE, SIT, SKK, and XEU.
22 July 2016 81
The table gives the message description, the field containing the NCD amount and the field
containing the value date.
MT MT Name NCD Amount Field Value Date Field
101 Request for Transfer 32B in sequence B 30 in sequence A

(each occurrence)
102 Multiple Customer 32A in sequence C 32A in sequence C

Credit Transfer
32A in sequence C 32A in sequence C
102 STP
103 Single Customer Credit 32A 32A

Transfer
103 REMIT 32A 32A
103 STP 32A 32A
104 Direct Debit and 32B (each occurrence) 30 in sequence A

Request for Debit
104RFDD Transfer Message 32B (each occurrence) 30 in sequence A
107 General Direct Debit 32B in sequence C 30 in sequence A

Message
200 Financial Institution 32A 32A

Transfer for its Own
Account
201 Multiple Financial 32B (each occurrence 30

Institution Transfer for
its Own Account
202 General Financial 32A 32A

202 COV General Financial 32A 32A

203 Multiple General 32B (each occurrence) 30

Transfer
204 Financial Markets 32B (each occurrence) 30

Direct Debit Message
205 Financial Institution 32A 32A

Transfer Execution
205 COV Financial Institution 32A 32A

Transfer Execution
22 July 2016 82
207 Request for Financial 32B (each occurrence 30 in Seq A

Message
210 Notice to Receive 32B (each occurrence) 30
400 Advice of Payment 33A 33A
450 Cash Letter Credit 32A (each occurrence) 32A

Advice
455 Cash Letter Credit 32A 32A

Adjustment Advice
33C 33C
33D 33D
456 Advice of Dishonour 32D (each occurrence) 33D
513 Client Advice of Sequence C Order Sequence C Order

Execution Details Field 19A Details Field 98a
Qualifier SETT Qualifier SETT (1)
Sequence D3 Amounts Sequence C Order

Field 19A Qualifier Details Field 98a
SETT Qualifier SETT (1)
514 Trade Allocation Sequence B Sequence B

Instruction Confirmation Details Confirmation Details
Field 19A Qualifier Field 98a Qualifier
SETT SETT (1)
Sequence C3 Amounts Sequence B

Field 19A Qualifier Confirmation Details
SETT Field 98a Qualifier
SETT (1)
515 Client Confirmation of Sequence C Sequence C

Purchase or Sale Confirmation Details Confirmation Details
Field 19A Qualifier Field 98a Qualifier SETT
SETT
Sequence D3 Amounts Sequence C

SETT Field 98a Qualifier SETT
22 July 2016 83
518 Market-Side Securities Sequence B Sequence B

Trade Confirmation Confirmation Details Confirmation Details
Field 19A Qualifier Field 98a Qualifier SETT
SETT
Sequence C3 Amounts Sequence B

SETT Field 98a Qualifier SETT
541 Receive Against Sequence E3 Amount Sequence B Trade

Payment Field 19A Qualifier Details Field 98a
SETT Qualifier SETT
543 Deliver Against Sequence E3 Amount Sequence B Trade

Payment Field 19A Qualifier Details Field 98a
SETT Qualifier SETT
545 Receive Against Sequence E3 Amount Sequence B Trade

Payment Confirmation Field 19A Qualifier Details Field 98a
ESTT Qualifier SETT (1)
547 Deliver Against Sequence E3 Amount Sequence B Trade

Payment Confirmation Field 19A Qualifier Details Field 98a
ESTT Qualifier SETT (1)
564 Corporate Action Seq E2 Cash Sequence E2 Cash

Notification Movement Field 19B Movement Field 98a
Qualifier ENTL Qualifier PAYD(2)
564 Corporate Action Sequence E2 Cash Sequence E2 Cash

Notification Movements Field 19B Movements Field 98a
Qualifier ENTL (each Qualifier VALU(3)
occurrence)
566 Corporate Action Sequence D2 Cash Sequence D2 Cash

Confirmation Movement Field 19B Movement Field 98a
Qualifier PSTA Qualifier POST
730 Acknowledgement 32D 32D
734 Advice of Refusal 33A 33A
742 Reimbursement Claim 34A 34A
752 Authorisation to Pay, 33A 33A

Accept or Negotiate
754 Advice of Payment/ 34A 34A

Acceptance/
Negotiation
22 July 2016 84
756 Advice of 33A 33A

Reimbursement or
Payment
768 Acknowledgement of a 32D 32D

Guarantee/Standby
Message
769 Advice of Reduction or 32D 32D

Release
800 T/C Sales and 32A in sequence B 32A in sequence B

Settlement Advice
[Single]
802 T/C Settlement Advice 32A 32A
900 Confirmation of Debit 32A 32A
910 Confirmation of Credit 32A 32A
(1) If the settlement date in the optional field is not specified, the message will be accepted.
(2) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is
used, the validation is not performed).
(3) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is
used, the validation is not performed).
7.4 ERI Validation and Examples

This section details the validation of the ERI information and provides examples that give correct
and incorrect messages.
7.4.1 General ERI Validation Rules
Rules
Codes and format:
• /OCMT/3!a15d/
• /CHGS/3!a15d/
Where:
• The currency component 3!a must be a valid currency code (Error code T52).
• The amount component 15d following the currency code must be formatted according to the
Field Formatting Rules given in section Numbers on page 56.
If not properly formatted, the system will NAK the message with Error codes T40, T43, T33,
or other generic error codes as deemed necessary.
22 July 2016 85
• The amount component 15d will not be checked on the maximum number of decimal digits
allowed for the relevant currency code.
• The codes /OCMT/ and /CHGS/ will trigger ERI validation regardless of their location in the
field, that is the codes may be present anywhere in a line; they do not have to be at the start
of a line.
Examples - currency codes

The currency code XYZ is invalid. The messages are NAKed:
• :79:/OCMT/XYZ150,/(CrLf)
/CHGS/EUR1,(CrLf)
• :77A:xxx/OCMT/EUR5000,/CHGS/XYZ1,/CrLf)
Examples - amount components

The amount components are invalid. The messages are NAKed:
• :86:/OCMT/EUR,12/(CrLf)
• :86:/OCMT/EUR123/(CrLf)
Note The amount component must be followed by a slash '/' (Error code T31). In the
following example the amount component is invalid. The message is NAKed:
:86:/OCMT/EUR1,23(CrLf)
7.4.2 Messages and Fields Impacted
Rules
The ERI validation will be performed in fields:
• 72, 77A, and/or 79 of all messages except in the following cases:
- field 72 in the MTs 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107, and 207
- field 77A in the MTs 300, 305, 306, 340, 341, 360, 361, 600, and 601
- field 79 in the MTs n92, n95, n96, and n99
• 61 (subfield 9) and 86, of the MTs 940 and 942
Examples
The messages are not NAKed:
• OCMT is validated
:79:xxxxx/OCMT/EUR10,25/xxxxx(CrLf)
• OCMT and CHGS are validated
:79:xxxxx/OCMT/EUR10,25/(CrLf)
/CHGS/EUR1,/(CrLf)
22 July 2016 86
7.4.3 No ERI Validation Hierarchy between the Fields
Rules
Note that if the same field specification is reused in the message, the ERI validation will be
performed. This is usually the case where a field is defined in a loop, that is, a repetitive block of
fields or sequence.
Example
For example, if fields 72, 77A, and 79 are all present in a message, and the ERI validation is
defined for that message, the system will apply the ERI validation in the three types of fields.
7.4.4 /CHGS/ is only Validated if /OCMT/ is Present
Rule
The ERI validation for the code /CHGS/ (6 characters) will be performed only if it immediately
follows /OCMT/3!a15d/ in the same occurrence of that field. Therefore, if /OCMT/ is present in
field 72, and /CHGS/ is present in field 79 (but /OCMT/ is not present in 79), the system does
not validate the format following /CHGS/ in field 79.
Example
In the following example, CHGS is not validated because OCMT is missing. The message is not
NAKed:
:86:xxxxx/CHGS/EUR1,40/xxxxx(CrLf)
7.4.5 Sequence of Codes is Required
Rule
Within a field, the sequence of the codes /OCMT/ and /CHGS/ is relevant.
It is only if /OCMT/ appears immediately before /CHGS/ that the ERI validation will be applied
to /CHGS/.
Example 1 - structured field 72

CHGS is validated. The message is not NAKed:
:72:/INS/BANKCCCY/OCMT/EUR12345,/(CrLf)
/CHGS/EUR20,/xxxxx(CrLf)
Example 2 - free format field 79

OCMT is validated. The message is not NAKed:
:79:xyz/OCMT/EUR1234,00//CHGS/EUR40,00/xxx(CrLf)
22 July 2016 87

Only OCMT is validated because CHGS does not follow immediately OCMT. The message is
not NAKed:
:72:xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/OCMT/EUR1000,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/CHGS/EUR5,/(CrLf)
//xxxxxxxxxx(CrLf)
Note: if /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the ERI and
will not be subject to the ERI validation.

Only OCMT is validated. The message is not NAKed:
:72:/CHGS/EUR12,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)

Only OCMT is validated. The message is not NAKed:
:79:xyz/CHGS/EUR4,00/xxx/OCMT/EUR1234,00/xxx(CrLf)

OCMT and the second occurrence of CHGS are validated. The message is not NAKed:
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/OCMT/EUR12345,/(CrLf)
/CHGS/EUR12,/xxxxx(CrLf)
7.4.6 Double Codes are not Allowed in one Field
Rule
In one occurrence of a field where the ERI validation must be performed, the codes /OCMT/
and /CHGS/ must not be used more than once.
Note Since the presence of /OCMT/ triggers the validation of /CHGS/, a double /CHGS/
will be NAKed only if /OCMT/ is present in the same field.
If the ERI validation fails due to a duplicated code, it will result - whichever field was validated -
in the existing Error code T47. The line number of the first field in sequence in the message
where the error occurred, will be indicated, together with the error code.
22 July 2016 88

OCMT is found twice. The message is NAKed:
:72:/OCMT/EUR12345,/(CrLf)
//xxxxxx(CrLf)
Example 2 - field 61
:61:9809010931C3500,25FCHK304955//4958843(CrLf)
/OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf)

:79:xyz/OCMT/EUR1234,00//OCMT/EUR40,00/xxx(CrLf)

CHGS is found twice. The message is NAKed:
:72:xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/CHGS/EUR100,/xxxxxxxxxx(CrLf)
/CHGS/EUR50,/(CrLf)
//xxxxxxxxxx(CrLf)
Note If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the
ERI and thus not be subject to the ERI validation.

OCMT and the second occurrence of CHGS, are validated. The message is not NAKed:
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/CHGS/EUR50,/(CrLf)
//xxxxxxxxxx(CrLf)

OCMT and the second occurrence of CHGS, are validated. The message is not NAKed:
:79:xyz/CHGS/EUR4,00//OCMT/EUR1234,00//CHGS/EUR4,00/(CrLf)
7.4.7 Consistent with Current Standards
Rule
In all fields where the ERI validation is defined, the generic that is, current, validation must still
be performed.
22 July 2016 89
Example
Field 72 is always checked for maximum 6 lines, with a maximum of 35 characters per line.
Field 72, structured format, the first line must begin with a '/', and the second through sixth line
(optional), must begin with a '/' or a '//'.
7.4.8 Maximum Use of the Generic Format Definition
Rule
In order to maximise the use of all characters allowed in the generic format, the codes /OCMT/, /
CHGS/, as well as the data (3!a15d/), may be split across lines.
Examples
Narrative format of information that follows ERI-related codes split across lines:
:72:xxxxx/OCMT/EUR12345,(CrLf)
12//CHGS/ (CrLf)
EUR12,/(CrLf)
Structured format of ERI-related codes split across lines:

:72:/INS/BANKCCCY/OCMT/EUR1234,//CH(CrLf)
//GS/EUR1,/xxxxxxx(CrLf)
Narrative format of ERI-related codes split across lines:

:77A:xxxxx/OC(CrLf)
MT/EUR100,/(CrLf)
7.4.9 No ERI Validation
Rules
SWIFT does not perform network validation on the Euro-Related Information in:
• Fields 72 and 79, if the REJT or RETN codes are present, that is, the special REJT/RETN
validation for fields 72 and 79 prevails
• MT 104
• Common Group message types (category n)
7.4.10 Details of the ERI Validation Implementation
7.4.10.1 Field 61, subfield 9
Format
[34x]
22 July 2016 90
Validation
The system performs the following validation:
1. If subfield 9 in field 61 is present, then validates according to the format 34x:
• if the check here above is OK, then goes to point 2
• otherwise the message is NAKed with the corresponding error code
2. Scans for /OCMT/
If /OCMT/ is:
• not present, then performs next field validation
• present more than once, then NAK the message with the Error code T47 and terminates
the validation
• present only once, then validates the format 3!a15d/
If format is:
- valid, then goes to point 3
- invalid, then NAK the message with the corresponding error code and terminates the
validation
3. Checks for /CHGS/ immediately after /OCMT/3!a15d/
If /CHGS/ is:
the validation
If format is:
- valid, then goes to next field validation
validation
7.4.10.2 Field 72 (Structured Format)
Format
<INSTR> first line
[(CrLf)(<INSTR> or //33x)] optionally, lines 2 to 6
where <INSTR> is defined as:

• /1!a/[32x] or
• /2!a/[31x] or
• /3!a/[30x] or
• /4!a/[29x] or
• /5!a/[28x] or
• /6!a/[27x] or
22 July 2016 91
• /7!a/[26x] or
• /8!a/[25x]
Validation
1. Maximum 6 lines, maximum 35 characters per line (X character set)
2. First line as <INSTR>, per the format defined here above
3. Second through sixth line
If present, defined as : <INSTR> or //33x:
• if the 3 checks here above are OK, then goes to point 4
• otherwise the message is NAKed, with the corresponding error code
4. Throughout the field content, removes all (CrLf//), if any
5. Throughout the field content, removes all (CrLf), if any
6. Scans for /OCMT/
If /OCMT/ is:
• present more than once (double), then NAK the message with the Error code T47 and
terminates the validation
If format is:
validation
If /CHGS/ is:
If format is:
validation
7.4.10.3 Field 72 (Narrative)
Format
35x[(CrLf)35x], optionally lines 2 to 6
22 July 2016 92
Validation
2. Second through sixth line, if present, defined as 35x
If present, defined as 35x:
• if the 2 checks are OK, then goes to point 3
4. Scans for /OCMT/
If /OCMT/ is:
• is present only once, then validates the format 3!a15d/
If format is:
validation
If /CHGS/ is:
If format is:
validation
7.4.10.4 Field 77A (Narrative)
Format
35x[(CrLf)35x], optionally lines 2 to 20
Validation
2. Second through 20th line
22 July 2016 93

• if the 2 checks here above are OK, then goes to point 3
4. Scans for /OCMT/
If /OCMT/ is:
If format 3!a15d/ is:
validation
If /CHGS/ is:
the validation
If format is:
validation
Format
50x [(CrLf)50x], optionally lines 2 to 35
Validation
2. Second through 35th line
• if the 2 checks (point 1) are OK, then goes to point 3
4. Scans for /OCMT/
22 July 2016 94
If /OCMT/ is:
If format is:
validation
If /CHGS/ is:
If format is:
validation
Format
65x [(CrLf)65x], optionally lines 2 to 6
Validation
2. Second through sixth line
• if the 2 checks (point 1) are OK, then goes to point 3
• otherwise the message is NAKed, with the corresponding error code
4. Scans for /OCMT/
If /OCMT/ is:
22 July 2016 95
If format is:
validation
If /CHGS/ is:
If format is:
validation
22 July 2016 96
General Information Legal Notices
Legal Notices
Copyright
SWIFT © 2016. All rights reserved.
Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.
SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR
Policy - End-User License Agreement, available at www.swift.com > About Us > Legal > IPR
Policies > SWIFT Standards IPR Policy.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT:
the SWIFT logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this
publication are trade names, trademarks, or registered trademarks of their respective owners.
22 July 2016 97

Swift Old Version Document PDF

Uploaded by

Document Information

Original Title

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

Swift Old Version Document PDF

Uploaded by

Copyright:

Available Formats

Standards MT November 2016

1 Standards MT Volumes Description.............................................................................................5

2 Introduction to Standards MT.....................................................................................................16

3 Business Identifier Code (BIC)................................................................................................... 19

5 Message Structure and Message Types.................................................................................... 23

6 Field Structure and Field Formatting Rules.............................................................................. 52

7 Euro-Related Information (ERI) ................................................................................................. 75

7.2 Euro-Related Information (ERI)................................................................................................... 75

New information Location

Addition of clearing code CN Option D: Name and Address on page 61

How to calculate message length Message Length and Structure on page 50

Updated information Location

Update of rules ERI Usage Guidelines and Rules on page 76

Accomodate definition of field 59F Option F: Party Identifier/Name and Address on

Deleted information Location

No ERI validation on MTs 96n No ERI Validation on page 90

Removal of unnecessary characters (chevrons) Details of the ERI Validation Implementation on

1 Standards MT Volumes Description

Additional Standards MT volumes

1.2 Standards MT Volumes

1.2.1 Standards MT General Information Volume

1 - Standards MT This chapter contains:

2 - Introduction to This chapter contains:

3 - Business Identifier This chapter contains a brief description of the Business

5- Message Structure and This chapter contains:

7- Euro-Related This chapter contains guidelines for using existing SWIFT

1.2.2 Standards MT General Field Definitions Plus

1.2.3 Category Volumes: Message Text Standards

Each volume provides the information as described in the following table:

Introduction This section contains a description of the function

Message Type Description This section contains detailed descriptions of each

1.2.4 Additional Volumes

Standards - Category 5 - Securities This document contains additional information for

1.3 Formatting Explanation

1.3.1 Field Definition Format

Definition A description of the field. Additional information which

Format Options The specification of available options, or alternative

Usage Rules Additional information pertaining to use of the field.

Codes A matrix showing the message types which use the

1.3.2 Message Type Descriptions

Example of an information flow

Financial Bank Corporate Customer

Other parties involved

Another SWIFT message

Financial Bank Corporate Customer

Message type scope

Message type format specifications

MT nnn (Message Type name)

Status Tag Field Name Content/Options No.

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, 6!n3!a15d 4

----> Optional Repetitive Sequence B (Sequence Name)

O 52a Ordering Institution A or D 5

M 71B Detail of Charges 6*35x 6

O 72 Sender to Receiver Information 6*35x 7

M = Mandatory O = Optional - Network Validated Rules may apply

Status Tag Field Name Content/Options No.

M = Mandatory O = Optional - Network Validated Rules may apply

2.2 Standards Development and Implementation Process

2.3 Standards Maintenance Process