Standards MT November 2021
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.
23 July 2021
Link to this document: https://www2.swift.com/go/book/book31821
Standards MT November 2021
General Information
Table of Contents
Table of Contents
Preface............................................................................................................................................................... 4
Significant Changes..........................................................................................................................................5
1
2
Standards MT Volumes Description...................................................................................................... 6
1.1
Volume/Chapter Explanation................................................................................................................... 6
1.2
Standards MT Volumes........................................................................................................................... 7
1.3
Formatting Explanation.......................................................................................................................... 11
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.............................................................................................................18
3
Business Identifier Code (BIC).............................................................................................................19
4
Characters..............................................................................................................................................20
5
6
7
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
Message Structure and Message Types..............................................................................................23
5.1
SWIFT Message Structure.................................................................................................................... 23
5.2
SWIFT Message Types ........................................................................................................................ 23
5.3
Message Length and Structure..............................................................................................................47
5.4
Message Structure Example..................................................................................................................48
Field Structure and Field Formatting Rules........................................................................................49
6.1
General Rules........................................................................................................................................49
6.2
Field Structure ...................................................................................................................................... 49
6.3
Field Formatting ....................................................................................................................................52
Euro-Related Information (ERI) ........................................................................................................... 70
7.1
23 July 2021
Deletion of National Currency Denomination (NCD) Currency Codes.................................................. 70
2
Standards MT November 2021
General Information
Table of Contents
7.2
Euro-Related Information (ERI)............................................................................................................. 70
7.3
Message Specific Guidelines on the Use of ERI................................................................................... 73
7.4
ERI Validation and Examples................................................................................................................ 79
Legal Notices................................................................................................................................................... 90
23 July 2021
3
Standards MT November 2021
General Information
Preface
Preface
Purpose of the document
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.
Audience
This document is for all SWIFT customers (this includes operators and application developers),
vendors, and service bureaux.
CAUTION
23 July 2021
This volume contains information effective as of the November 2021 Standards
release. Therefore the 24 July 2020 edition of the Standards MT User Handbook
volumes remains effective until November 2021.
4
Standards MT November 2021
General Information
Significant Changes
Significant Changes
The following tables list significant changes to the content of the Standards MT General Information
since the 24 July 2020 edition. These tables do not include editorial changes that SWIFT makes to
improve the usability and comprehension of the document.
23 July 2021
New information
Location
Addition of MT 761, MT 765, MT 775, MT 785, MT
786, and MT 787
SWIFT Message Types on page 23
Updated information
Location
Update name of MT 760 and MT 767
SWIFT Message Types on page 23
Network validated rules
Option F: Party Identifier/Name and Address on page
61
5
Standards MT November 2021
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:
•
Standards MT General Information
•
General Field Definitions Plus
Ten category volumes containing the respective message text standards:
•
Category 1 - Customer Payments and Cheques - Message Reference Guide
•
Category 2 - Financial Institution Transfers - Message Reference Guide
•
Category 3 - Treasury Markets - Foreign Exchange, Money Markets, and Derivatives
This category consists of 2 volumes:
-
Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message Reference Guide - Volume 1 (MT 300 - MT 341)
-
Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message Reference Guide - Volume 2 (MT 350 - MT 399)
•
Category 4 - Collections and Cash Letters - Message Reference Guide
•
Category 5 - Securities Markets
This category consists of 4 volumes:
•
-
Category 5 - Securities Markets - Message Reference Guide - Volume 1 (MT 500 - MT 518)
-
Category 5 - Securities Markets - Message Reference Guide - Volume 2 (MT 519 - MT 543)
-
Category 5 - Securities Markets - Message Reference Guide - Volume 3 (MT 544 - MT 567)
-
Category 5 - Securities Markets - Message Reference Guide- Volume 4 (MT 568 - MT 599)
Category 6
This category consists of 2 books:
23 July 2021
-
Category 6 - Treasury Markets - Commodities - Message Reference Guide
-
Category 6 - Reference Data - Message Reference Guide
•
Category 7 - Documentary Credits and Guarantees/Standby Letters of Credit - Message
Reference Guide
•
Category 8 - Travellers Cheques - Message Reference Guide
•
Category 9 - Cash Management and Customer Status - Message Reference Guide
•
Category n - Common Group Messages - Message Reference Guide
6
Standards MT November 2021
General Information
Standards MT Volumes Description
Additional Standards MT volumes
To assist users, usage guidelines have been published in additional Standards MT volumes for
specific categories of messages. These volumes contain guidelines for using message standards.
The volumes are:
•
Standards MT Usage Guidelines
•
Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message
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
Volumes Description on
page 6
This chapter contains:
2 - Introduction to
Standards MT on page
16
23 July 2021
•
a description of the information which is contained in each
volume of the Standards MT documentation set
•
an explanation of the presentation of field definitions,
category information, and message type formats
This chapter contains:
•
a description of the reasons message standards are
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
7
Standards MT November 2021
General Information
Standards MT Volumes Description
Chapter
Description
3 - Business Identifier
Code (BIC) on page 19
This chapter contains a brief description of the Business
Identifier Code.
For more information on the BIC format and use of the BIC in
SWIFT messages, see the BIC Policy.
4 - Characters on page
20
This chapter lists the allowable characters in the X-, Y-, and Zcharacter 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 49
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.
70
1.2.2
Standards MT General Field Definitions Plus
Overview
The General Field Definitions Plus provides a general description of all message-text fields. It also
provides information about the FIN error codes and the FIN system messages.
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.
23 July 2021
8
Standards MT November 2021
General Information
Standards MT Volumes Description
Description
The General Field Definitions Plus contains a description of each field, including:
1.2.3
•
format options
•
definition
•
network validated rules
•
usage rules
•
relevant message types
•
codes
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 - Reference Data
•
Category 7 - Documentary Credits and Guarantees/Standby Letters of Credit
•
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:
23 July 2021
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.
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
9
Standards MT November 2021
General Information
Standards MT Volumes Description
Section
Description
Message Type Description
This section contains detailed descriptions of each
message type within the category.
Including:
Glossary of Terms
1.2.4
•
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
Terms and definitions that are used throughout the
category.
Additional Volumes
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.
23 July 2021
Volume
Description
Standards MT Usage Guidelines
This document explains how to use message
standards. In addition, the document identifies
specific issues that relate to message standards, and
provides clarification (and examples) of message
standards. This document is for all users of
Standards messages.
Category 3 - Treasury Markets Foreign Exchange, Money Markets
and Derivatives Message Usage
Guidelines
This document provides information about support for
derivatives in Standards Category 3 messages. In
particular, the document contains specific information
about the MT 300, MT 305, MT 306, and MT 396, as
well as guidance that is equally relevant to other MTs.
This document is for users of Standards Category 3
messages that trade derivatives.
Category 5 - Securities Markets
Message Usage Guidelines
This document provides information about the ISO
15022 securities message standards for trade
initiation and confirmation, settlement and
reconciliation, and corporate actions. This document
is for all users of ISO 15022 securities message
standards.
10
Standards MT November 2021
General Information
Standards MT Volumes Description
1.3
Formatting Explanation
1.3.1
Field Definition Format
The 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.
1.3.2
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.
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
23 July 2021
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.
11
Standards MT November 2021
General Information
Standards MT Volumes Description
Example of an information flow
The following symbols are used to identify the parties involved in the message flow:
Legend
Originator of the
transaction
Financial
institution
Bank
Corporate Customer
Sender
or
Receiver
Other parties involved
in the transaction
MT
The actual SWIFT
Message
MT nnn
MT nnn
Another SWIFT message
involved in the transaction
Financial institution or
customer relationship
Financial
institution
Bank
Corporate Customer
D0200001
Final recipient
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 about how the message is used. In some messages, an example of the message flow
is also provided.
23 July 2021
12
Standards MT November 2021
General Information
Standards MT Volumes Description
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 a table 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,
Amount
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
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.
23 July 2021
13
Standards MT November 2021
General Information
Standards MT Volumes Description
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
1
2
---->
Second sequence
3
4
----|
Third sequence
5
6
7
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 be country-specific
requirements that should be considered when using the field or message type.
23 July 2021
14
Standards MT November 2021
General Information
Standards MT Volumes Description
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.
Note
23 July 2021
For further information about the header and trailer, see the FIN Service Description.
15
Standards MT November 2021
General Information
2
Introduction to Standards MT
2.1
Reason for Standards MT
Introduction to 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:
2.2
•
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
Standards Development and Implementation
Process
Published processes
For details about the standards development and implementation process, see the Standards MT
Development and Maintenance Processes. This document was approved by the SWIFT Board of
Directors in 2011 and updated in 2018, approved by the Banking Services Committee at the
December 2018 meeting.
2.3
Standards Maintenance Process
Published processes
For details about the standards maintenance process, see the Standards MT Development and
Maintenance Processes. This document was approved by the SWIFT Board of Directors.
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.
23 July 2021
16
Standards MT November 2021
General Information
Introduction to Standards MT
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).
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. An exceptional fast-track maintenance process can be announced in December (SR-10) and
can result in additional changes to the Standards Release Guide which will then be published
latest seven months prior to implementation (SR-7).
5. Three months prior to implementation (SR-3), the Standards MT User Handbook is available on
www.swift.com.
6. 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 about any of the processes described in this section, see 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
23 July 2021
For further details about the message structure, see the FIN Service Description.
17
Standards MT November 2021
General Information
2.5
Introduction to Standards MT
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.
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:
23 July 2021
•
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
•
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
•
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
18
Standards MT November 2021
General Information
3
Business Identifier Code (BIC)
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
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.
ISO 9362 allows alphanumeric values for the first 4 characters in the BIC, but SWIFT has
implemented a more restrictive structure in message types only allowing alphabetic indications for
the party prefix (BIC format 4!a2!a2!c[3!c] ). SWIFT, as registration authority, has no plans to issue
BICs with numeric characters in the first 4 characters.
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 about the BIC format and use of the BIC in SWIFT messages, see the BIC
Policy on swift.com.
23 July 2021
19
Standards MT November 2021
General Information
4
Characters
4.1
SWIFT Character Set (X Character Set)
Characters
Description
Computer-based terminals communicating with SWIFT use EBCDIC code. When an "x" is
indicated in the format of a field, 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. When
a "y" is indicated in the format of the field, the character set is as follows:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
.,-()/='+:?!"%&*<>;
Space
Other characters are not allowed (Error code M60).
4.3
Information Service Character Set (Z Character
Set)
Description
Some MT fields allow even a broader range of characters to provide additional information. When a
"z" is indicated in the format of the field, the characters set is as follows:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
.,-()/='+:?!"%&*<>;{
23 July 2021
20
Standards MT November 2021
General Information
Characters
@#_
Cr Lf Space
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:
23 July 2021
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
21
Standards MT November 2021
General Information
Characters
Character
Description
EBCDIC
=
Equal sign
7E
"
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.
23 July 2021
22
Standards MT November 2021
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
MT nnn
D0200003
Type
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 2021 Standards release.
23 July 2021
23
Standards MT November 2021
General Information
Message Structure and Message Types
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
Length
MUG
101
Request For
Transfer
Requests to debit a
customer's account held at
the receiver or at another
institution.
Y
10,000
Y
102
Multiple Customer
Credit Transfer
Conveys multiple payment
instructions between
financial institutions.
Y
10,000
Y
Single Customer
Credit Transfer
Instructs a funds transfer.
Y
10,000
N
103
REMIT
Single Customer
Credit Transfer
Instructs a fund transfer.
Y
10,000
Y
104
Direct Debit and
Request for Debit
Transfer Message
Conveys direct debit
instructions and requests
for direct debits between
financial institutions.
Y
10,000
Y
105
EDIFACT Envelope
An envelope which
conveys a 2k EDIFACT
message.
Y
2,000
Y
107
General Direct Debit Conveys direct debit
Message
instructions between
financial institutions.
Y
10,000
Y
110
Advice of Cheque(s) Advises or confirms the
Y
issuance of a cheque to the
drawee bank.
2,000
N
111
Request for Stop
Payment of a
Cheque
Y
2,000
N
112
Status of a Request Indicates action(s) taken in Y
for Stop Payment of attempting to stop payment
a Cheque
of a cheque.
2,000
N
102 STP
103
103 STP
23 July 2021
Requests the drawee bank
to stop payment of a
cheque.
24
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
190
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, and
other adjustments.
Y
2,000
N
191
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
192
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
195
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
Y
2,000
N
196
Answers
Responds to an MT 195
Y
Query or MT 192 Request
for Cancellation or other
message where no specific
message type has been
provided for a response.
2,000
N
198
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
199
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
2,000
N
200
Financial Institution
Transfer for its Own
Account
Requests the movement of Y
the sender's funds to its
account at another financial
institution.
2,000
N
201
Multiple Financial
Institution Transfer
for its Own Account
Multiple of the MT 200.
Y
2,000
N
202
General Financial
Institution Transfer
Requests the movement of
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.
Y
10,000
N
25
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
202 COV
General Financial
Institution Transfer
Requests the movement of
funds between financial
institutions, related to an
underlying customer credit
transfer that was sent with
the cover method.
Y
10,000
N
203
Multiple General
Financial Institution
Transfer
Multiple of the MT 202.
Y
2,000
N
204
Financial Markets
Direct Debit
Message
Claims funds from SWIFT
member banks.
Y(2)
2,000
Y
205
Financial Institution
Transfer Execution
Further transmits a transfer Y
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.
10,000
N
205 COV
Financial Institution
Transfer Execution
Further transmits a transfer Y
request domestically,
related to an underlying
customer credit transfer
that was sent with the
cover method.
10,000
N
210
Notice to Receive
Notifies the receiver that it
will receive funds for the
sender's account.
Y
2,000
N
290
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments.
Y
2,000
N
291
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
292
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
295
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
2,000
N
Y
26
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
296
Answers
298
Signed(1)
Max
Length
MUG
Responds to an MT 295
Y
Queries message or an MT
292 Request for
Cancellation or other
message where no specific
message type has been
provided for a response.
2,000
N
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
299
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
2,000
N
300
Foreign Exchange
Confirmation
Confirms information
agreed to in the buying/
selling of two currencies.
N
10,000
N
304
Advice/Instruction of Advises of or instructs
a Third Party Deal
settlement of a third party
foreign exchange deal.
Y
10,000
Y
305
Foreign Currency
Confirms information
N
Option Confirmation agreed to in the buying and
selling of vanilla options on
currencies.
2,000
N
306
Foreign Currency
Confirms information
N
Option Confirmation agreed to in the buying and
selling of exotic options on
currencies.
10,000
N
320
Fixed Loan/Deposit
Confirmation
Confirms the terms of a
contract relative to a fixed
loan/deposit transaction.
N
10,000
N
321
Instruction to Settle
a Third Party Loan/
Deposit
Advises the trade details
Y
and instructs the settlement
of a fixed term loan/deposit
done with a third party
financial institution.
10,000
Y
330
Call/Notice Loan/
Deposit
Confirmation
Confirms the terms of a
contract relative to a call/
notice loan/deposit
transaction.
N
10,000
N
340
Forward Rate
Agreement
Confirmation
Confirms the details of a
forward rate agreement.
N
10,000
N
27
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
341
Forward Rate
Agreement
Settlement
Confirmation
Confirms the settlement
details of a forward rate
agreement.
N
10,000
N
350
Advice of Loan/
Deposit Interest
Payment
Advises of a loan/deposit
interest payment.
N
10,000
N
360
Single Currency
Interest Rate
Derivative
Confirmation
Confirms the details of a
single currency interest
rate derivative swap, cap,
collar or floor.
N
10,000
N
361
Cross Currency
Interest Rate Swap
Confirmation
Confirms the details of a
N
cross currency interest rate
swap transaction.
10,000
N
362
Interest Rate Reset/ Confirms or advises the
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.
N
2,000
N
364
Single Currency
Interest Rate
Derivative
Termination/
Recouponing
Confirmation
Confirms the details of the
partial or full termination or
recouponing of a single
currency interest rate
swap, cap, collar, or floor.
N
10,000
N
365
Cross Currency
Interest Rate Swap
Termination/
Recouponing
Confirmation
Confirms the details of the
partial or full termination or
recouponing of a cross
currency interest rate
swap.
N
10,000
N
370
Netting Position
Advice
Advises the netting position N
of a currency.
10,000
N
380
Foreign Exchange
Order
Orders to purchase or sell
a specific amount of a
certain currency.
Y
10,000
Y
381
Foreign Exchange
Order Confirmation
Confirms the execution of
an FX order previously
sent.
Y
10,000
Y
390
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments.
N
2,000
N
28
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
391
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
N
2,000
N
392
Request for
Cancellation
Requests the receiver to
N
consider cancellation of the
message identified in the
request.
2,000
N
395
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
N
2,000
N
396
Answers
Responds to an MT 395
N
Queries or an MT 392
Request for Cancellation or
other message where no
specific message type has
been provided for a
response.
2,000
N
398
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
N
10,000
N
399
Free Format
Message
Contains information for
which no other message
type has been defined.
N
2,000
N
400
Advice of Payment
Advises of a payment
under a collection or part
thereof. It also handles the
settlement of proceeds.
Y
2,000
N
410
Acknowledgement
Acknowledges receipt of a
collection. It also specifies
if the collecting bank does
not intend to act in
accordance with the
collection instruction.
Y
2,000
N
412
Advice of
Acceptance
Informs the remitting bank Y
of the acceptance of one or
more drafts under one
collection instruction.
2,000
N
416
Advice of NonPayment/NonAcceptance
Advises of the nonpayment or nonacceptance under a
previously received
collection.
10,000
Y
Y
29
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
420
Tracer
Enquires about documents
sent for collection.
Y
2,000
N
422
Advice of Fate and
Request for
Instructions
Advises the remitting bank
of the fate of one or more
collection documents;
usually accompanied by
one or more questions or
requests.
Y
2,000
N
430
Amendment of
Instructions
Amends collection
instructions.
Y
2,000
N
450
Cash Letter Credit
Advice
Confirms that the face
Y
amount of cash letter(s)
received has been credited
under usual reserve
(subject to final payment).
2,000
N
455
Cash Letter Credit
Adjustment Advice
Advises the account owner
of adjustments made to its
account (related to a
previous credit for a cash
letter).
Y
2,000
N
456
Advice of Dishonour Advises the account owner
that financial document(s)
included in the cash letter
have been dishonoured for
reasons specified in the
advice.
Y
2,000
N
490
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
Y
2,000
N
491
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
492
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
495
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
2,000
N
Y
30
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
496
Answers
Responds to an MT 495
Queries message or MT
492 Request for
Cancellation or other
messages where no
specific message type has
been provided for the
response.
Y
2,000
N
498
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
499
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
10,000
N
500
Instruction to
Register
Instructs the registration,
deregistration or
reregistration of a financial
instrument at the
registration provider.
Y
10,000
N
501
Confirmation of
Registration or
Modification
Confirms the registration,
deregistration or
reregistration of a
beneficial owner or
shareholder with the
registration provider.
Y
10,000
N
502(3)
Order to Buy or Sell Instructs the purchase or
Y
sale of a given quantity of a
specified financial
instrument under specified
conditions.
10,000
N
503
Collateral Claim
Requests new or additional Y
collateral, or the return or
recall of collateral.
10,000
Y
504
Collateral Proposal
Proposes new or additional Y
collateral.
10,000
Y
505
Collateral
Substitution
Proposes or requests the
substitution of collateral
held.
Y
10,000
Y
506
Collateral and
Provides the details of the
Exposure Statement valuation of both the
collateral and the
exposure.
Y
10,000
Y
31
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
507
Collateral Status
and Processing
Advice
508
Signed(1)
Max
Length
MUG
Advises the status of a
Y
collateral claim, a collateral
proposal, or a proposal/
request for collateral
substitution.
10,000
Y
Intra-Position
Advice
Reports on the movement
of securities within the
holding.
Y
10,000
N
509(3)
Trade Status
Message
Provides information about
the status of a previously
executed trade.
Y
10,000
N
510
Registration Status
and Processing
Advice
Advises the status of a
registration instruction or
modification.
Y
10,000
N
513
Client Advice of
Execution
Provides brief and early
Y
information about a
securities deal, for
example, a block trade that
is to be allocated before
final confirmation.
10,000
N
514
Trade Allocation
Instruction
Instructs the allocation of a
block trade.
Y
10,000
N
515(3)
Client Confirmation Provides a detailed
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.
Y
10,000
N
516
Securities Loan
Confirmation
Confirms the details of a
securities loan, including
collateral arrangements. It
may also confirm the
details of a partial recall or
return of securities
previously out on loan.
Y
2,000
N
517
Trade Confirmation
Affirmation
Positively affirms the
details of a previously
received confirmation/
contract note.
Y
10,000
N
32
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
518
Market-Side
Securities Trade
Confirmation
519
Signed(1)
Max
Length
MUG
Confirms the details of a
Y
trade and, where
necessary, its settlement to
a trading counterparty.
10,000
N
Modification of
Client Details
Instructs the modification of Y
client details at the
registration provider.
10,000
N
524
Intra-Position
Instruction
Instructs the movement of
securities within the
holding.
10,000
N
526
General Securities
Lending/Borrowing
Message
Requests the borrowing of Y
securities or notifies the
return or recall of securities
previously out on loan. It
may also be used to list
securities available for
lending.
2,000
N
527
Triparty Collateral
Instruction
Performs a specific action
on a collateral
management transaction.
Y
10,000
Y
530
Transaction
Processing
Command
Requests the modification Y
of a processing indicator or
other non-matching
information.
10,000
N
535
Statement of
Holdings
Reports at a specified time, Y
the quantity and
identification of securities
and other holdings which
the account servicer holds
for the account owner.
10,000
N
536
Statement of
Transactions
Provides details of
Y
increases and decreases of
holdings which occurred
during a specified period.
10,000
N
537
Statement of
Pending
Transactions
Provides details of pending Y
increases and decreases of
holdings at a specified
time.
10,000
N
538
Statement of IntraPosition Advices
Provides details of
Y
increases and decreases in
securities within the holding
during a specified period.
10,000
N
Y
33
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
540
Receive Free
541
Signed(1)
Max
Length
MUG
Instructs a receipt of
Y
financial instruments free of
payment. It may also be
used to request a
cancellation or pre-advise
an instruction.
10,000
N
Receive Against
Payment
Instructs a receipt of
financial instruments
against payment. It may
also be used to request a
cancellation or pre-advise
an instruction.
Y
10,000
N
542
Deliver Free
Instructs a delivery of
Y
financial instruments free of
payment. It may also be
used to request a
cancellation or pre-advise
an instruction.
10,000
N
543
Deliver Against
Payment
Instructs a delivery of
financial instruments
against payment. It may
also be used to request a
cancellation or pre-advise
an instruction.
Y
10,000
N
544
Receive Free
Confirmation
Confirms a receipt of
Y
financial instruments free of
payment. It may also be
used to cancel or reverse a
confirmation.
10,000
N
545
Receive Against
Payment
Confirmation
Confirms a receipt of
financial instruments
against payment. It may
also be used to cancel or
reverse a confirmation.
Y
10,000
N
546
Deliver Free
Confirmation
Confirms a delivery of
Y
financial instruments free of
payment. It may also be
used to cancel or reverse a
confirmation.
10,000
N
547
Deliver Against
Payment
Confirmation
Confirms a delivery of
financial instruments
against payment. It may
also be used to cancel or
reverse a confirmation.
10,000
N
Y
34
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
548
Settlement Status
and Processing
Advice
Advises the status of a
settlement instruction or
replies to a cancellation
request.
Y
10,000
N
549
Request for
Statement/Status
Advice
Requests a statement or a
status message.
Y
10,000
N
558
Triparty Collateral
Status and
Processing Advice
Provides validation results
and status advice re
collateral instructions and
proposed collateral
movements.
Y
10,000
Y
564
Corporate Action
Notification
Provides an account owner Y
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.
10,000
N
565
Corporate Action
Instruction
Instructs the custodian on
Y
the investment decision
made by an account owner
relative to a corporate
action event.
10,000
N
566
Corporate Action
Confirmation
Confirms to the account
owner that securities
and/or cash have been
credited/debited to an
account as a result of a
corporate action event.
Y
10,000
N
567
Corporate Action
Status and
Processing Advice
Indicates the status, or a
change in status, of a
corporate action-related
transaction previously
instructed by, or executed
on behalf of, the account
owner.
Y
10,000
N
568
Corporate Action
Narrative
Provides complex
instructions or narrative
details relating to a
corporate action event.
Y
10,000
N
35
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
569
Triparty Collateral
and Exposure
Statement
Provides the details of the
valuation of both the
collateral and the
exposure.
Y
10,000
Y
575
Report of Combined Reports on all securities
Activity
and cash activity for a
given combination of
safekeeping and cash
accounts.
Y
10,000
Y
576
Statement of Open
Orders
Provides details of 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.
Y
10,000
N
578
Settlement
Allegement
Advises the account owner
that a counterparty has
alleged a settlement
instruction on the account
owner's account.
Y
10,000
N
581
Collateral
Adjustment
Message
Claims or notifies a change Y
in the amount of collateral
held against securities out
on loan or for other
reasons.
2,000
N
586
Statement of
Settlement
Allegements
Provides details of pending Y
settlement allegements.
10,000
N
590
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
Y
2,000
N
591
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
592
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
595
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
2,000
N
Y
36
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
596
Answers
598
Signed(1)
Max
Length
MUG
Responds to an MT 595
Y
Queries or MT 592
Request for Cancellation or
other message where no
specific message type has
been provided for the
response.
2,000
N
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
599
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
2,000
N
600
Commodity Trade
Confirmation
Confirms the details of a
commodity trade and its
settlement.
N
2,000
N
601
Commodity Option
Confirmation
Confirms the details of a
commodity option contract.
N
2,000
N
604
Commodity
Transfer/Delivery
Order
Instructs the receiver to
Y
transfer by book-entry, or
physically deliver, a
specified type and quantity
of commodity to a specified
party.
2,000
N
605
Commodity Notice
to Receive
Notifies the receiver of an
N
impending book-entry
transfer or physical delivery
of a specified type and
quantity of commodity.
2,000
N
606
Commodity Debit
Advice
Advises the receiver of a
debit entry to a specified
commodity account.
N
2,000
N
607
Commodity Credit
Advice
Advises the receiver of a
credit entry to a specified
commodity account.
N
2,000
N
608
Statement of a
Provides the details of all
Commodity Account bookings to a commodity
account.
N
2,000
N
620
Commodity Fixed
Loan/Deposit
Confirmation
N
10,000
Y
Confirms a commodity
fixed term loan/deposit
contract.
37
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
Signed(1)
Max
Length
MUG
Standing Settlement Requests SWIFT to create
Instruction Update
the MT 671 from the MT
Notification Request 670 and send to financial
institutions.
Y
10,000
N
671
Standing Settlement Specifies standing
Instruction Update
settlement instructions for
Notification
one or more currencies.
Y
10,000
N
690
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
Y
2,000
N
691
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
692
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
695
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
Y
2,000
N
696
Answers
Responds to an MT 695
Queries message or MT
692 Request for
Cancellation or other
messages where no
specific message type has
been provided for the
response.
Y
2,000
N
698
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
699
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
2,000
N
700
Issue of a
Indicates the terms and
Documentary Credit conditions of a
documentary credit.
Y
10,000
N
701
Issue of a
Continuation of an MT 700
Documentary Credit for fields 45a, 46a, and
47a.
Y
10,000
N
MT
MT Name
670
Purpose
38
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
705
Purpose
Signed(1)
Max
Length
MUG
Pre-Advice of a
Provides brief advice of a
Y
Documentary Credit documentary credit for
which full details will follow.
2,000
N
707
Amendment to a
Informs the receiver of
Documentary Credit amendments to the terms
and conditions of a
documentary credit.
Y
10,000
N
708
Amendment to a
Continuation of an MT 707. Y
Documentary Credit
10,000
N
710
Advice of a Third
Advises the receiver of the
Bank's or a Nonterms and conditions of a
Bank's
documentary credit.
Documentary Credit
Y
10,000
N
711
Advice of a Third
Continuation of an MT 710. Y
Bank's or a NonBank's
Documentary Credit
10,000
N
720
Transfer of a
Advises the transfer of a
Documentary Credit documentary credit, or part
thereof, to the bank
advising the second
beneficiary.
Y
10,000
N
721
Transfer of a
Continuation of an MT 720. Y
Documentary Credit
10,000
N
730
Acknowledgement
Acknowledges the receipt
Y
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.
2,000
N
732
Advice of Discharge Advises that documents
Y
received with discrepancies
have been taken up.
2,000
N
734
Advice of Refusal
10,000
N
Advises the refusal of
documents that are not in
accordance with the terms
and conditions of a
documentary credit.
Y
39
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
740
Authorisation to
Reimburse
Requests the receiver to
honour claims for
reimbursement of
payment(s) or
negotiation(s) under a
documentary credit.
Y
2,000
N
742
Reimbursement
Claim
Provides a reimbursement Y
claim to the bank
authorised to reimburse the
sender or its branch for its
payments/ negotiations.
2,000
N
744
Notice of NonConforming
Reimbursement
Claim
Notifies the receiver that
the sender considers the
claim, on the face of it, as
not to be in accordance
with the instruction in the
Reimbursement
Authorisation for the
reason(s) as stated in this
message.
Y
2,000
N
747
Amendment to an
Authorisation to
Reimburse
Informs the reimbursing
Y
bank of amendments to the
terms and conditions of a
documentary credit,
relative to the authorisation
to reimburse.
2,000
N
750
Advice of
Discrepancy
Advises of discrepancies
and requests authorisation
to honour documents
presented that are not in
accordance with the terms
and conditions of the
documentary credit.
10,000
N
752
Authorisation to
Pay, Accept or
Negotiate
Advises a bank which has Y
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.
2,000
N
Y
40
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
754
Advice of Payment/
Acceptance/
Negotiation
756
Advice of
Reimbursement or
Payment
759
Ancillary Trade
Requests or provides
Structured Message information, such as a
fraud alert or a financing
request, concerning an
existing trade transaction
such as a documentary
credit, demand guarantee,
standby letter of credit or
an undertaking (for
example, a guarantee,
surety, etc.).
760
Issue of a Demand
Guarantee/Standby
Letter of Credit
Issues or requests the
issue of a guarantee or
standby letter of credit.
761
765
Signed(1)
Max
Length
MUG
Advises that documents
Y
have been presented in
accordance with the terms
of a documentary credit
and are being forwarded as
instructed. This message
type also handles the
payment/ negotiation.
2,000
N
Advises of the
Y
reimbursement or payment
for a drawing under a
documentary credit in
which no specific
reimbursement instructions
or payment provisions were
given.
2,000
N
Y
10,000
N
Y
10,000
N
Issue of a Demand
Guarantee/Standby
Letter of Credit
May specify the terms and Y
conditions of the
undertaking, and for a
counter-undertaking, may
specify the requested
terms and conditions of the
local undertaking. This
message is sent in addition
to an MT 760, when the
information in the
undertaking exceeds the
maximum message size of
the MT 760.
10,000
N
Guarantee/Standby
Letter of Credit
Demand
Demands payment under
Y
an undertaking and may
include a request to extend
the expiry date.
10,000
N
41
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
767
Amendment to a
Demand Guarantee/
Standby Letter of
Credit
768
Acknowledgement
of a Guarantee/
Standby Message
Signed(1)
Max
Length
MUG
Amends a guarantee or
Y
standby letter of credit
which has been previously
issued or requests the
amendment of a guarantee
which the sender has
previously requested to be
issued.
10,000
N
Acknowledges the receipt
of a guarantee or standby
letter of credit message
and may indicate that
action has been taken
according to instructions.
Y
2,000
N
769
Advice of Reduction Advises that a bank has
Y
or Release
been released of its liability
for a specified amount
under its guarantee or
standby letter of credit.
2,000
N
775
Amendment to a
Demand Guarantee/
Standby Letter of
Credit
May specify the terms and Y
conditions of the
undertaking, and for a
counter-undertaking, may
specify the requested
terms and conditions of the
local undertaking. This
message is sent in addition
to an MT 767, when the
information in the
undertaking would
otherwise exceed the
maximum message size of
the MT 767.
10,000
N
785
Guarantee/Standby
Letter of Credit NonExtension
Notification
Notifies the beneficiary, if
Y
applicable, via one or more
advising parties, of the
non-extension of the
referenced undertaking
beyond the current expiry
date.
2,000
N
786
Guarantee/Standby
Letter of Credit
Demand Refusal
Used by the party obligated Y
on the undertaking and to
whom a demand for
payment has been made,
to notify the beneficiary that
the demand has been
refused.
10,000
N
42
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
787
Guarantee/Standby
Letter of Credit
Amendment
Response
Sent to the bank that
issued the undertaking
amendment (guarantee,
demand guarantee,
standby letter of credit, or
dependent undertaking),
either directly or via one or
more advising parties, to
indicate acceptance or
rejection by the beneficiary
of the amendment.
Y
2,000
N
790
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
Y
2,000
N
791
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
792
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
795
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
Y
2,000
N
796
Answers
Responds to an MT 795
Queries message or MT
792 Request for
Cancellation or other
messages where no
specific message type has
been provided for the
response.
Y
2,000
N
798
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
799
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
10,000
N
43
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
801
T/C Multiple Sales
Advice
802
Signed(1)
Max
Length
MUG
Provides the details
Y
(excluding the settlement
details) of the sales of
travellers cheques in cases
where the data is lengthy
or includes data from
several selling agents.
2,000
N
T/C Settlement
Advice
Provides the settlement
details of multiple sales of
travellers cheques.
Y
2,000
N
890
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
Y
2,000
N
891
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
Y
2,000
N
892
Request for
Cancellation
Requests the receiver to
Y
consider cancellation of the
message identified in the
request.
2,000
N
895
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
Y
2,000
N
896
Answers
Responds to an MT 895
Queries message or MT
892 Request for
Cancellation or other
messages where no
specific message type has
been provided for the
response.
Y
2,000
N
898
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
Y
10,000
N
899
Free Format
Message
Contains information for
which no other message
type has been defined.
Y
2,000
N
900
Confirmation of
Debit
Advises an account owner
of a debit to its account.
N
2,000
N
44
Standards MT November 2021
General Information
23 July 2021
Message Structure and Message Types
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
910
Confirmation of
Credit
Advises an account owner
of a credit to its account.
N
2,000
N
920
Request Message
Requests the account
N
servicing institution to send
an MT 940, 941, 942, or
950.
2,000
N
935
Rate Change
Advice
Advises the receiver of
general rate change(s)
and/or rate change(s)
which applies to a specific
account other than a call/
notice loan/deposit
account.
N
2,000
N
940
Customer
Provides balance and
Statement Message transaction details of an
account to a financial
institution on behalf of the
account owner.
N
2,000
N
941
Balance Report
Provides balance
information of an account
to a financial institution on
behalf of the account
owner.
N
2,000
N
942
Interim Transaction
Report
Provides balance and
N
transaction details of an
account, for a specified
period of time, to a financial
institution on behalf of the
account owner.
2,000
N
950
Statement Message Provides balance and
transaction details of an
account to the account
owner.
N
2,000
N
970
Netting Statement
Provides balance and
transaction details of a
netting position as
recorded by a netting
system.
N
2,000
N
971
Netting Balance
Report
Provides balance
information for specified
netting position(s).
N
2,000
N
972
Netting Interim
Statement
Advises interim balance
and transaction details of a
netting position as
recorded by a netting
system.
N
2,000
N
45
Standards MT November 2021
General Information
MT
MT Name
Purpose
Signed(1)
Max
Length
MUG
973
Netting Request
Message
Requests an MT 971 or
972 containing the latest
available information.
N
2,000
N
985
Status Enquiry
Requests an MT 986.
N
2,000
N
986
Status Report
Provides business-related
information about a
customer or institution.
N
2,000
N
990
Advice of Charges,
Interest and Other
Adjustments
Advises an account owner
of charges, interest, or
other adjustments to its
account.
N
2,000
N
991
Request for
Payment of
Charges, Interest
and Other
Expenses
Requests payment of
charges, interest, or other
expenses.
N
2,000
N
992
Request for
Cancellation
Requests the receiver to
N
consider cancellation of the
message identified in the
request.
2,000
N
995
Queries
Requests information
relating to a previous
message or amendment to
a previous message.
N
2,000
N
996
Answers
Responds to an MT 995
N
Queries or MT 992
Request for Cancellation or
other messages where no
specific message type has
been provided for the
response.
2,000
N
998
Proprietary
Message
Contains formats defined
and agreed to between
users and for those
messages not yet live.
N
10,000
N
999
Free Format
Message
Contains information for
which no other message
type has been defined.
N
2,000
N
(1)
(2)
(3)
23 July 2021
Message Structure and Message Types
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.
Special registration is needed for the MT 204 - see the FIN Service Description for details.
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, see https://www.swift.com/
our-solutions/global-financial-messaging/securities-messages/funds-distribution/funds-migration or email funds@swift.com.
46
Standards MT November 2021
General Information
Message Structure and Message Types
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, please contact Support.
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:
23 July 2021
-
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.
47
Standards MT November 2021
General Information
5.4
Message Structure and Message Types
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.
{1:F01OELBATWWAXXX0975000073}
Basic header block
{2:I103ABNANL2AXXXXU3003}
Application header block
{3:{113:URGT}{108:INTLPMTS}{121:5798a701-effe-42e5-8d14-eec27ea3d8ec}}
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)
-}
{5:{CHK:123456789ABC}}
Note
23 July 2021
Trailer block
D0200004
:71A:SHA (CrLf)
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.
48
Standards MT November 2021
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
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
6.2
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.
Field Structure
Structure
Delimiter
Field tag number
Letter option
: nn [a] :
23 July 2021
D0200005
Delimiter
49
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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.
•
Lower case "a" next to the field tag number indicates that there are different formats available to
capture the information for this field. When this field is used in an MT, a specific format must be
indicated by replacing the lower case "a" with an upper case letter option.
An upper case letter next to the field tag number refers to the format option that will be used for
validating this field.
•
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 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.
•
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 51
-
special formats, for example, for numbers and dates
-
codes, for example, currency codes
(See the BIC Plus, which is available for download from www.swiftrefdata.com.)
•
23 July 2021
In some messages, the field specifications may indicate specific characters, or sets of
characters, for inclusion in the text of the field.
50
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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
(minimum is 1)
n
numeric digits (0 through 9) only
nn-nn
minimum and
maximum length
a
alphabetic letters (A through Z), upper
case only
c
alphabetic letters (upper case) and digits
only
h
hexadecimal letters A through F (upper
case) and digits only
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)
d
decimals
e
blank space
nn!
nn*nn
fixed length
maximum number of
lines times maximum
line length
Examples
23 July 2021
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
51
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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 = 29 November
•
211129 = 29 November 21
•
20211129 = 29 November 2021
The six-digit date thus ranges from 2001 to 2060.
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 69).
The valid date range of 2001 to 2060 applies to (list not exhaustive):
6.3.2
•
field 30, in MTs: 101, 104, 107, 110, 111, 112, 201, 203, 204, and 210
•
field 32A, in MTs: 102, 102 STP, 103, 103 REMIT, 103 STP, 110, 111, 112, 200, 202, 202 COV,
205, 205 COV, and 910
Numbers
Format
nn...nn, nn...n
Integer part
23 July 2021
D0200006
Fractional part (optional)
52
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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 Plus which is available on www.swiftrefdata.com.
Examples
6.3.3
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
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.
23 July 2021
53
Standards MT November 2021
General Information
6.3.4
Field Structure and Field Formatting Rules
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]
Where:
Subfield 1
Subfield 2
[/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.
[/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 examples of 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 61.
23 July 2021
54
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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).
Examples
Valid
Invalid
:53A:/C/12-12
CITIUS33CHI
:53A:/6/12-12
CITIUS33CHI
:53B:/D/24-24
:53B:/A/24-24
:53D:/52/48-48
John Doe
122 Peyton Place
Elyria, OH 22216
:53D:/:/48-48
John Doe
122 Peyton Place
Elyria, OH 22216
:87E:FREE
/C/12-12
CHASUS33
:87E:APMT
/A/12-12
CHASUS33
:87F:APMT
/D/12-12
John Doe
122 Peyton Place
Elyria, OH 22216
:87F:APMT
/:/48-48
John Doe
122 Peyton Place
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
23 July 2021
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.
55
Standards MT November 2021
General Information
6.3.4.2
Field Structure and Field Formatting Rules
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).
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.
Network validated rules
Identifier Code must be a registered BIC (Error codes T27, T28, T29 and T45).
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 nonconnected.
(*) Field 41A does not have the optional party identifier, but does have an additional
subfield.
See Option D: Name and Address on page 57 on the use of clearing codes.
(**) Field 50A has the format [/34x] for Party Identifier.
23 July 2021
56
Standards MT November 2021
General Information
6.3.4.4
Field Structure and Field Formatting Rules
Option B: Branch of Sender/Receiver
Format
[/1a][/34x]
(Party Identifier)
[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
6.3.4.6
See Option D: Name and Address on page 57 on the use of clearing codes.
Option D: Name and Address
Format
23 July 2021
[/1a][/34x]
(Party Identifier)
4*35x
(Name and Address)
57
Standards MT November 2021
General Information
Note
Field Structure and Field Formatting Rules
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).
Definition
Name and address and, optionally, the account or clearing code of the party.
Network validated rules
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:
23 July 2021
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
CN
12..14n
China National Advanced Payment System (CNAPS) Code
CP
4!n
CHIPS Participant Identifier
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
58
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
IN
11!n
Indian Financial System Code (IFSC) is the identification scheme
defined by the Reserve Bank of India
IT
10!n
Italian Domestic Identification Code
NZ
6!n
New Zealand National Clearing Code
PL
8!n
Polish National Clearing Code (KNR)
PT
8!n
Portuguese National Clearing Code
RT
Pay by Real Time Gross Settlement
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)
ZA
6!n
South African National Clearing 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 realtime 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:
23 July 2021
-
2!n = Bank Code
-
1!n = State Code
-
3!n = Branch Code
59
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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:
-
•
•
•
•
•
•
•
•
23 July 2021
3!n = Bank Code
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
financial institution
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
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
60
Standards MT November 2021
General Information
•
Field Structure and Field Formatting Rules
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
Fields assigned to this option
42D
50D, 51D, 52D, 53D, 54D, 55D, 56D, 57D, 58D
82D, 83D, 84D, 85D, 86D, 87D, 88D
Note
6.3.4.7
Field 41D does not have the optional party identifier but does have an additional
subfield.
Option F: Party Identifier/Name and Address
Format
[35x]
(Party Identifier)
4*35x
(Name and Address)
The following line formats must be used (Error code(s): T54):
Line 1 (subfield Party Identifier)
/34x
(Account)
Line 2-5 (subfield Name and
Address)
1!n/33x
(Number)(Details)
Line 1 (subfield Party Identifier)
4!a/2!a/27x
(Code)(Country Code)(Identifier)
Line 2-5 (subfield Name and
Address)
1!n/33x
(Number)(Details)
Line 1 (subfield Party Identifier)
[/34x]
(Account)
Line 2-5 (subfield Name and
Address)
1!n/33x
(Number)(Details)
Or
Or
Definition
Name and address in a structured format to facilitate straight-through processing.
23 July 2021
61
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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 Number
The code followed by a slash, '/' must be followed by the
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):
23 July 2021
1
Name of the Ordering Customer The number followed by a slash, '/' must be followed by 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).
62
Standards MT November 2021
General Information
3
Field Structure and Field Formatting Rules
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 Number
The number followed by a slash, '/' must be followed by 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
Network validated rules
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):
23 July 2021
•
The first line must start with number 1 (Error code(s): T56).
•
Numbers must appear in numerical order (Error code(s): T56).
•
A line starting with number 3 must be present (Error code(s): T56).
•
The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s):
T73).
•
Numbers 1, 2, and 3 may be repeated. The same number must not occur more than 2 times
(Error code(s): T56).
63
Standards MT November 2021
General Information
•
Field Structure and Field Formatting Rules
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.
Field assigned to this option
50F, 59F
6.3.4.8
Option G: Identifier Code
Format
23 July 2021
/34x
(Account)
4!a2!a2!c[3!c]
(Identifier Code)
64
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
Definition
Identifier code of the party with mandatory account number.
Network validated rules
Identifier Code must be a registered BIC (Error codes T27, T28, T29, and T45).
Fields assigned to this option
50G, 52G
6.3.4.9
Option H: Name and Address
Format
/34x
(Account)
4*35x
(Name and Address)
Definition
Name and address of the party with a mandatory account.
Field assigned to this option
50H
6.3.4.10
Option J: Party Identification with no Party Identifier
Format
5*40x
(Narrative)
Definition
Identification of the party.
Codes
In option J, Party Identification must be specified as a list of pairs (Code)(Value) and one or more of
the following codes and formats must be used (Error code(s): T78).
The codes must be placed between slashes ('/').
23 July 2021
Code
Format
Description
ABIC
4!a2!a2!c[3!c] or
4!a
Identifier Code
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)
65
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
Code
Format
Description
CLRC
35x
Clearing Code followed by a clearing 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
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)
Fields assigned to this option
53J, 56J, 57J, 58J
82J, 83J, 84J, 85J, 86J, 87J, 88J.
6.3.4.11
Option K: 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).
Usage rules
If Account is absent, then Name and Address must not start with a slash '/'.
Field assigned to this option
50K
23 July 2021
66
Standards MT November 2021
General Information
6.3.4.12
Field Structure and Field Formatting Rules
Option L: Party Identification
Format
35x
(Narrative)
Definition
Identification of the party
Field assigned to this option
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.
Field assigned to this option
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.
Field assigned to this option
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.
Field assigned to this option
95R
23 July 2021
67
Standards MT November 2021
General Information
6.3.4.16
Field Structure and Field Formatting Rules
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.
Field assigned to this option
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.
Field assigned to this option
95T
6.3.4.18
Option U: Party
Format
:4!c//3*35x
(Qualifier) (Name)
Definition
Identification of the party, with a qualifier and names.
Field assigned to this option
95U
6.3.5
Times
Formats
4!n
6!n
23 July 2021
68
Standards MT November 2021
General Information
Field Structure and Field Formatting Rules
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 2001 to
2060, and must meet the following requirements:
•
allowed: a year component, for example, "YY" in the range of 01 through 60, of an ISO defined
six digit integer date "YYMMDD"
•
not allowed: any "YY" component outside of this range
Example
ACKed
NAKed
:32A:061130USD1,
:30:181130
:32A:611130USD1,
: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:151218
:32A:200103USD123000,00
Value date = 18 December 2015
Value date = 03 January 2020
In this example, field 30 Value Date (18 December 2015) is selected for value date ordering of the
message. Error code T50 is returned after an invalid value date.
23 July 2021
69
Standards MT November 2021
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.
23 July 2021
70
Standards MT November 2021
General Information
Euro-Related Information (ERI)
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 79 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 73.
•
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.
23 July 2021
71
Standards MT November 2021
General Information
7.2.3
Euro-Related Information (ERI)
•
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.
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 79 for details.
23 July 2021
72
Standards MT November 2021
General Information
Euro-Related Information (ERI)
Example
:72:/OCMT/GBP2525,/
/CHGS/EUR2,40/
7.3
Message Specific Guidelines on the Use of ERI
This section lists message types which:
7.3.1
•
are likely to contain ERI
•
contain a special field for original amount
•
are to be validated against a specified value date
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 72. This list is
therefore not exhaustive.
23 July 2021
MT
MT Name
Settlement Amount Repetitive/N ERI
Field
on Repetitive Field
Repetitive/N
on Repetitive
202
General Financial
Institution Transfer
32A Value Date,
Currency Code,
Amount
NR
72
NR
202
COV
General Financial
Institution Transfer
32A Value Date,
Currency Code,
Amount
NR
72
NR
203
Multiple General
Financial Institution
Transfer
32B Currency Code, R
Amount
72
R
204
Financial Markets Direct
Debit Message
32B Currency Code, R
Amount
72
R
205
Financial Institution
Transfer Execution
32A Value Date,
Currency Code,
Amount
NR
72
NR
205
COV
Financial Institution
Transfer Execution
32A Value Date,
Currency Code,
Amount
NR
72
NR
400
Advice of Payment
33A Proceeds
Remitted
NR
72
NR
73
Standards MT November 2021
General Information
7.3.2
Euro-Related Information (ERI)
MT
MT Name
Settlement Amount Repetitive/N ERI
Field
on Repetitive Field
Repetitive/N
on Repetitive
450
Cash Letter Credit
Advice
32A Value Date,
Currency Code,
Amount
R
72
NR
455
Cash Letter Credit
Adjustment Advice
33a Value Date and
Adjustment Amount
R
72
NR
456
Advice of Dishonour
33D Total Amount
Debited
R
72
NR
581
Collateral Adjustment
Message
34B Outstanding
Collateral Value
NR
72
NR
752
Authorisation to Pay,
Accept or Negotiate
33a Net Amount
NR
72
NR
754
Advice of Payment/
Acceptance/Negotiation
34a Total Amount
Claimed
NR
72
NR
756
Advice of
Reimbursement or
Payment
33A Amount
Reimbursed or Paid
NR
72
NR
768
Acknowledgement of a
Guarantee/Standby
Message
32a Amount of
Charges
NR
72
NR
769
Advice of Reduction or
Release
32a Amount of
Charges
NR
72
NR
900
Confirmation of Debit
32A Value Date,
Currency Code,
Amount
NR
72
NR
910
Confirmation of Credit
32A Value Date,
Currency Code,
Amount
NR
72
NR
940
Customer Statement
Message
subfield 5 of field 61
R
61/9 or
86
R
942
Interim Transaction
Report
subfield 5 of field 61
R
61/9 or
86
R
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.
23 July 2021
74
Standards MT November 2021
General Information
Euro-Related Information (ERI)
MT
MT Name
Settlement
Repetitive/N ERI Field
Amount Field on Repetitive
Repetitive/N
on Repetitive
101
Request for
Transfer
32B
R
33B
R
102
Multiple
32B
Customer
Credit Transfer
R
33B
R
Single
32A
Customer
Credit Transfer
NR
33B
NR
104
Direct Debit
and Request
for Debit
Transfer
32B
R
33B
R
107
General Direct 32B
Debit Message
R
33B
R
513
Client Advice
of Execution
19A::SETT
NR
19A::OCMT
NR
514
Trade
Allocation
Instruction
19A::SETT
NR
19A::OCMT
NR
515
Client
19A::SETT
Confirmation of
Purchase or
Sale
NR
19A::OCMT
NR
518
Market-Side
Securities
Trade
Confirmation
19A::SETT
NR
19A::OCMT
NR
541
Receive
Against
Payment
19A::SETT
NR
19A::OCMT
NR
543
Deliver Against 19A::SETT
Payment
NR
19A::OCMT
NR
545
Receive
Against
Payment
Confirmation
19A::ESTT
NR
19A::OCMT
NR
547
Deliver Against 19A::ESTT
Payment
Confirmation
NR
19A::OCMT
NR
102 STP
103
103
REMIT
103 STP
23 July 2021
75
Standards MT November 2021
General Information
7.3.3
Euro-Related Information (ERI)
MT
MT Name
Settlement
Repetitive/N ERI Field
Amount Field on Repetitive
Repetitive/N
on Repetitive
564
Corporate
Action
Notification
19A::ESTT
NR
19A::OCMT
NR
566
Corporate
Action
Confirmation
19A::ESTT
NR
19A::OCMT
NR
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.
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
(each occurrence)
30 in sequence A
102
Multiple Customer
Credit Transfer
32A in sequence C
32A in sequence C
32A in sequence C
32A in sequence C
102 STP
103
23 July 2021
Single Customer Credit 32A
Transfer
32A
76
Standards MT November 2021
General Information
MT
NCD Amount Field
Value Date Field
103 REMIT
32A
32A
103 STP
32A
32A
Direct Debit and
Request for Debit
Transfer Message
32B (each occurrence)
30 in sequence A
32B (each occurrence)
30 in sequence A
107
General Direct Debit
Message
32B in sequence C
30 in sequence A
200
Financial Institution
Transfer for its Own
Account
32A
32A
201
Multiple Financial
Institution Transfer for
its Own Account
32B (each occurrence
30
202
General Financial
Institution Transfer
32A
32A
202 COV
General Financial
Institution Transfer
32A
32A
203
Multiple General
Financial Institution
Transfer
32B (each occurrence)
30
204
Financial Markets
Direct Debit Message
32B (each occurrence)
30
205
Financial Institution
Transfer Execution
32A
32A
205 COV
Financial Institution
Transfer Execution
32A
32A
210
Notice to Receive
32B (each occurrence)
30
400
Advice of Payment
33A
33A
450
Cash Letter Credit
Advice
32A (each occurrence)
32A
455
Cash Letter Credit
Adjustment Advice
32A
32A
33C
33C
33D
33D
32D (each occurrence)
33D
104
104RFDD
456
23 July 2021
Euro-Related Information (ERI)
MT Name
Advice of Dishonour
77
Standards MT November 2021
General Information
MT
MT Name
NCD Amount Field
Value Date Field
513
Client Advice of
Execution
Sequence C Order
Details Field 19A
Qualifier SETT
Sequence C Order
Details Field 98a
Qualifier SETT (1)
Sequence D3 Amounts
Field 19A Qualifier
SETT
Sequence C Order
Details Field 98a
Qualifier SETT (1)
Sequence B
Confirmation Details
Field 19A Qualifier
SETT
Sequence B
Confirmation Details
Field 98a Qualifier
SETT (1)
Sequence C3 Amounts
Field 19A Qualifier
SETT
Sequence B
Confirmation Details
Field 98a Qualifier
SETT (1)
Sequence C
Confirmation Details
Field 19A Qualifier
SETT
Sequence C
Confirmation Details
Field 98a Qualifier SETT
Sequence D3 Amounts
Field 19A Qualifier
SETT
Sequence C
Confirmation Details
Field 98a Qualifier SETT
Sequence B
Confirmation Details
Field 19A Qualifier
SETT
Sequence B
Confirmation Details
Field 98a Qualifier SETT
Sequence C3 Amounts
Field 19A Qualifier
SETT
Sequence B
Confirmation Details
Field 98a Qualifier SETT
514
515
518
23 July 2021
Euro-Related Information (ERI)
Trade Allocation
Instruction
Client Confirmation of
Purchase or Sale
Market-Side Securities
Trade Confirmation
541
Receive Against
Payment
Sequence E3 Amount
Field 19A Qualifier
SETT
Sequence B Trade
Details Field 98a
Qualifier SETT
543
Deliver Against
Payment
Sequence E3 Amount
Field 19A Qualifier
SETT
Sequence B Trade
Details Field 98a
Qualifier SETT
545
Receive Against
Payment Confirmation
Sequence E3 Amount
Field 19A Qualifier
ESTT
Sequence B Trade
Details Field 98a
Qualifier SETT (1)
547
Deliver Against
Payment Confirmation
Sequence E3 Amount
Field 19A Qualifier
ESTT
Sequence B Trade
Details Field 98a
Qualifier SETT (1)
564
Corporate Action
Notification
Seq E2 Cash
Movement Field 19B
Qualifier ENTL
Sequence E2 Cash
Movement Field 98a
Qualifier PAYD(2)
78
Standards MT November 2021
General Information
MT
MT Name
NCD Amount Field
Value Date Field
564
Corporate Action
Notification
Sequence E2 Cash
Movements Field 19B
Qualifier ENTL (each
occurrence)
Sequence E2 Cash
Movements Field 98a
Qualifier VALU(3)
566
Corporate Action
Confirmation
Sequence D2 Cash
Movement Field 19B
Qualifier PSTA
Sequence D2 Cash
Movement Field 98a
Qualifier POST
730
Acknowledgement
32D
32D
734
Advice of Refusal
33A
33A
742
Reimbursement Claim
34A
34A
752
Authorisation to Pay,
Accept or Negotiate
33A
33A
754
Advice of Payment/
Acceptance/
Negotiation
34A
34A
756
Advice of
Reimbursement or
Payment
33A
33A
768
Acknowledgement of a
Guarantee/Standby
Message
32D
32D
769
Advice of Reduction or
Release
32D
32D
802
T/C Settlement Advice
32A
32A
900
Confirmation of Debit
32A
32A
910
Confirmation of Credit
32A
32A
(1)
(2)
(3)
7.4
Euro-Related Information (ERI)
If the settlement date in the optional field is not specified, the message will be accepted.
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).
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).
ERI Validation and Examples
This section details the validation of the ERI information and provides examples that give correct
and incorrect messages.
23 July 2021
79
Standards MT November 2021
General Information
7.4.1
Euro-Related Information (ERI)
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 52.
If not properly formatted, the system will NAK the message with Error codes T40, T43, T33, or
other generic error codes as deemed necessary.
•
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:
•
•
23 July 2021
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, and 107
-
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
80
Standards MT November 2021
General Information
Euro-Related Information (ERI)
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)
7.4.3
No ERI Validation Hierarchy between the Fields
Rules
Note that if the same field specification is re-used 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)
23 July 2021
81
Standards MT November 2021
General Information
Euro-Related Information (ERI)
Example 2 - free format field 79
OCMT is validated. The message is not NAKed:
:79:xyz/OCMT/EUR1234,00//CHGS/EUR40,00/xxx(CrLf)
Example 3 - free format field 72
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.
Example 4 - structured field 72
Only OCMT is validated. The message is not NAKed:
:72:/CHGS/EUR12,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/OCMT/EUR12345,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
Example 5 - free format field 79
Only OCMT is validated. The message is not NAKed:
:79:xyz/CHGS/EUR4,00/xxx/OCMT/EUR1234,00/xxx(CrLf)
Example 6 - structured field 72
OCMT and the second occurrence of CHGS are validated. The message is not NAKed:
:72:/CHGS/EUR1,/xxxxx(CrLf)
//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.
Example 1 - structured field 72
OCMT is found twice. The message is NAKed:
:72:/OCMT/EUR12345,/(CrLf)
//xxxxxx(CrLf)
/OCMT/EUR100,/xxxxx(CrLf)
23 July 2021
82
Standards MT November 2021
General Information
Euro-Related Information (ERI)
Example 2 - field 61
OCMT is found twice. The message is NAKed:
:61:9809010931C3500,25FCHK304955//4958843(CrLf)
/OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf)
Example 3 - free format field 79
OCMT is found twice. The message is NAKed:
:79:xyz/OCMT/EUR1234,00//OCMT/EUR40,00/xxx(CrLf)
Example 4 - free format field 72
CHGS is found twice. The message is NAKed:
:72:xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/OCMT/EUR10000,/(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.
Example 5 - structured field 72
OCMT and the second occurrence of CHGS, are validated. The message is not NAKed:
:72:/CHGS/EUR12,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
//xxxxxxxxxx(CrLf)
/OCMT/EUR12345,/(CrLf)
/CHGS/EUR50,/(CrLf)
//xxxxxxxxxx(CrLf)
Example 6 - free format field 79
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.
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.
23 July 2021
83
Standards MT November 2021
General Information
Euro-Related Information (ERI)
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]
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:
23 July 2021
•
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/
84
Standards MT November 2021
General Information
Euro-Related Information (ERI)
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:
•
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:
7.4.10.2
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
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
•
/7!a/[26x] or
•
/8!a/[25x]
Validation
The system performs the following 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
23 July 2021
85
Standards MT November 2021
General Information
Euro-Related Information (ERI)
6. Scans for /OCMT/
If /OCMT/ is:
•
not present, then performs next field validation
•
present more than once (double), 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 7
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
7. Checks for /CHGS/ immediately after /OCMT/3!a15d/
If /CHGS/ is:
•
not present, then performs next field validation
•
present more than once (double), 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:
7.4.10.3
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
Field 72 (Narrative)
Format
35x[(CrLf)35x], optionally lines 2 to 6
Validation
The system performs the following validation:
1. Maximum 6 lines, maximum 35 characters per line (X character set)
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
•
otherwise the message is NAKed with the corresponding error code
3. Throughout the field content, removes all (CrLf), if any
4. Scans for /OCMT/
If /OCMT/ is:
23 July 2021
•
not present, then performs next field validation
•
present more than once (double), then NAK the message with the Error code T47 and
terminates the validation
•
is present only once, then validates the format 3!a15d/
86
Standards MT November 2021
General Information
Euro-Related Information (ERI)
If format is:
-
valid, then goes to point 5
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
5. Checks for /CHGS/ immediately after /OCMT/3!a15d/
If /CHGS/ is:
•
not present, then performs next field validation
•
present more than once (double), 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:
7.4.10.4
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
Field 77A (Narrative)
Format
35x[(CrLf)35x], optionally lines 2 to 20
Validation
The system performs the following validation:
1. Maximum 20 lines, maximum 35 characters per line (X character set)
2. Second through 20th line
If present, defined as 35x:
•
if the 2 checks here above are OK, then goes to point 3
•
otherwise the message is NAKed with the corresponding error code
3. Throughout the field content, removes all (CrLf), if any
4. Scans for /OCMT/
If /OCMT/ is:
•
not present, then performs next field validation
•
present more than once (double), then NAK the message with the Error code T47 and
terminates the validation
•
present only once, then validates the format 3!a15d/
If format 3!a15d/ is:
-
valid, then goes to point 5
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
5. Checks for /CHGS/ immediately after /OCMT/3!a15d/
23 July 2021
87
Standards MT November 2021
General Information
Euro-Related Information (ERI)
If /CHGS/ 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:
7.4.10.5
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
Field 79 (Narrative)
Format
50x [(CrLf)50x], optionally lines 2 to 35
Validation
The system performs the following validation:
1. Maximum 35 lines, maximum 50 characters per line (X character set)
2. Second through 35th line
If present, defined as 50x:
•
if the 2 checks (point 1) are OK, then goes to point 3
•
otherwise the message is NAKed with the corresponding error code
3. Throughout the field content, removes all (CrLf), if any
4. Scans for /OCMT/
If /OCMT/ is:
•
not present, then performs next field validation
•
present more than once (double), 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 5
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
5. Checks for /CHGS/ immediately after /OCMT/3!a15d/
If /CHGS/ is:
23 July 2021
•
not present, then performs next field validation
•
present more than once (double), then NAK the message with the Error code T47 and
terminates the validation
•
present only once, then validates the format 3!a15d/
88
Standards MT November 2021
General Information
Euro-Related Information (ERI)
If format is:
7.4.10.6
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
Field 86 (Narrative)
Format
65x [(CrLf)65x], optionally lines 2 to 6
Validation
The system performs the following validation:
1. Maximum 6 lines, maximum 65 characters per line (X character set)
2. Second through sixth line
If present, defined as 65x:
•
if the 2 checks (point 1) are OK, then goes to point 3
•
otherwise the message is NAKed, with the corresponding error code
3. Throughout the field content, removes all (CrLf), if any
4. Scans for /OCMT/
If /OCMT/ is:
•
not present, then performs next field validation
•
present more than once (double), 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 5
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
5. Checks for /CHGS/ immediately after /OCMT/3!a15d/
If /CHGS/ is:
•
not present, then performs next field validation
•
present more than once (double), 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:
23 July 2021
-
valid, then goes to next field validation
-
invalid, then NAK the message with the corresponding error code and terminates the
validation
89
Standards MT November 2021
General Information
Legal Notices
Legal Notices
Copyright
SWIFT © 2021. 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. SC. The following are registered trademarks of SWIFT:
3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, the Standards Forum
logo, the SWIFT logo, SWIFT gpi with logo, the SWIFT gpi logo, and UETR. Other product, service,
or company names in this publication are trade names, trademarks, or registered trademarks of
their respective owners.
23 July 2021
90