Professional Documents
Culture Documents
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.
20 July 2018
Standards MT November 2018 Table of Contents
General Information
Table of Contents
Preface............................................................................................................................................................... 4
4 Characters..............................................................................................................................................20
4.1 SWIFT Character Set (X Character Set)............................................................................................... 20
4.2 EDIFACT Level A Character Set (Y Character Set)...............................................................................20
4.3 Information Service Character Set (Z Character Set)............................................................................20
4.4 Representation of Non-SWIFT Characters............................................................................................21
20 July 2018 2
Standards MT November 2018 Table of Contents
General Information
Legal Notices................................................................................................................................................... 93
20 July 2018 3
Standards MT November 2018 Preface
General Information
Preface
Significant changes
The following tables list all significant changes to the content of the Standards MT General
Information since the 20 July 2017 edition. These tables do not include editorial changes that
SWIFT makes to improve the usability and comprehension of the document.
Removal of network validated rule and example Option A: Identifier Code on page 57
CAUTION This volume contains information effective as of the November 2018 Standards
release. Therefore the 20 July 2017 edition of the Standards MT User Handbook
volumes remains effective until November 2018.
20 July 2018 4
Standards MT November 2018 Standards MT Volumes Description
General Information
20 July 2018 5
Standards MT November 2018 Standards MT Volumes Description
General Information
Chapters description
Chapter Description
20 July 2018 6
Standards MT November 2018 Standards MT Volumes Description
General Information
Chapter Description
For more information on the BIC format and use of the BIC in
SWIFT messages, see the BIC Policy .
4 - Characters on page This chapter lists the allowable characters in the X-, Y-, and Z-
20 character sets.
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 50 the following elements:
• Dates
• Numbers
• Currency Codes
• Party Identification
• Times
• Value Date Ordering
20 July 2018 7
Standards MT November 2018 Standards MT Volumes Description
General Information
Description
The General Field Definitions Plus contains a description of each field tag, including:
• format options
• definition
• network validated rules
• usage rules
• relevant message types
• codes
Section Description
20 July 2018 8
Standards MT November 2018 Standards MT Volumes Description
General Information
Section Description
Category Message Types This section lists and briefly describes the message
types defined within the category. It also indicates:
Including:
• MT Scope
• MT Format Specifications
• MT Network Validated Rules
• MT Usage Rules
• MT Guidelines
• MT Field Specifications
• MT Mapping
• MT Examples
• additional information about the MT as required
Glossary of Terms Terms and definitions that are used throughout the
category.
Volume Description
Standards MT Usage Guidelines This document recommends the use of messages for
specific business situations.
20 July 2018 9
Standards MT November 2018 Standards MT Volumes Description
General Information
Volume Description
Category 3 - Treasury Markets - This document provides information about support for
Foreign Exchange, Money Markets derivatives in Standards category 3 messages. In
and Derivatives Message Usage particular, the document contains specific information
Guidelines 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.
Name Description
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.
20 July 2018 10
Standards MT November 2018 Standards MT Volumes Description
General Information
20 July 2018 11
Standards MT November 2018 Standards MT Volumes Description
General Information
Legend
Originator of the
transaction
Sender
or
Receiver
MT
The actual SWIFT
Message
MT nnn
Financial institution or
customer relationship
Final recipient
D0200001
In the diagrams, each customer, or financial institution, is identified by the tag number of the
corresponding field, for example, 50a, Ordering Customer.
20 July 2018 12
Standards MT November 2018 Standards MT Volumes Description
General Information
The format specifications are the rules for the layout of the message type. This information is
provided in table form as shown below:
----|
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.
20 July 2018 13
Standards MT November 2018 Standards MT Volumes Description
General Information
Some message formats are separated into sequences of fields, as shown below. An arrow
indicates that a sequence of fields may be repeated:
First sequence
---->
Second Sequence
----|
Third sequence
The arrows (----> and ----|) indicate that the second sequence may be repeated.
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.
20 July 2018 14
Standards MT November 2018 Standards MT Volumes Description
General Information
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 For further information about the header and trailer, see the FIN Service Description.
20 July 2018 15
Standards MT November 2018 Introduction to Standards MT
General Information
2 Introduction to Standards MT
Key benefits
There are important benefits which result from standardisation of messages. These include:
• automation
• reduced risk of errors and misunderstandings
• reduced operating costs
• improved productivity
• increased efficiency in processing of messages (routing and preparation)
• faster and more cost effective account reconciliation
• ability to maintain more comprehensive management information
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.
20 July 2018 16
Standards MT November 2018 Introduction to Standards MT
General Information
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. Three months prior to implementation (SR-3), the Standards MT User Handbook is available on
www.swift.com.
5. The changes are implemented on the network on the Standards release (SR-0) date.
Approval process
Sixteen months prior to a planned Standards release date (SR-16), the SWIFT Standards
department analyses all received change requests. They send the outcome of this analysis to a
Maintenance Working Group (MWG) for discussion and approval.
MWGs include experts in the business domain and, ideally, in the standards to be maintained.
Members are country representatives appointed by their respective User Group Chairperson.
The message text formats are developed in line, or in consultation, with various bodies:
1. MWGs review and agree on the validity of the change requests.
2. Country vote takes place on MWG-agreed changes.
3. The Board Standards Committee must approve the country-vote results before the changes are
considered final and published in the final-SRG.
For more details on any of the processes described in this section, please visit Standards on
www.swift.com, or contact the Support team.
20 July 2018 17
Standards MT November 2018 Introduction to Standards MT
General Information
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.
20 July 2018 18
Standards MT November 2018 Business Identifier Code (BIC)
General Information
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 on the BIC format and use of the BIC in SWIFT messages, see the BIC Policy
on swift.com.
20 July 2018 19
Standards MT November 2018 Characters
General Information
4 Characters
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.
20 July 2018 20
Standards MT November 2018 Characters
General Information
@#_
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.
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:
! Exclamation mark 4F
& Ampersand 50
| Vertical bar 5A
$ Dollar 5B
* Asterisk 5C
; Semicolon 5E
^ Circumflex 5F
% Percent sign 6C
` Grave accent 79
# Number sign 7B
20 July 2018 21
Standards MT November 2018 Characters
General Information
@ Commercial At sign 7C
= Equal sign 7E
~ Tilde A1
Example
The character @ will be represented as ??7C in a field that is restricted to characters from the X
character set.
20 July 2018 22
Standards MT November 2018 Message Structure and Message Types
General Information
Message Structure
The message type is composed of three digits, generally defined as:
Category
Group
Type
D0200003
MT nnn
Where:
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.
20 July 2018 23
Standards MT November 2018 Message Structure and Message Types
General Information
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.)
20 July 2018 24
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 25
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 26
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 27
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 28
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 29
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 30
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 31
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 32
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 33
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 34
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 35
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 36
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 37
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 38
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 39
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 40
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 41
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 42
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 43
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 44
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 45
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 46
Standards MT November 2018 Message Structure and Message Types
General Information
20 July 2018 47
Standards MT November 2018 Message Structure and Message Types
General Information
(1) A Relationship Management Application (RMA) authorisation is required in order to sign a message with the exception of the
MT 670 and MT 671. Although the MT 670 and MT 671 are signed there is no need to set up RMA for these two messages as
they are exchanged between the user and SWIFT. For more details on the signing of MT 670 and MT 671, see the FIN
Operations Guide.
(2) Special registration is needed for the MT 204 - see the FIN Service Description for details.
(3) The use of MT 502, MT 509, and MT 515 for investment funds is subject to restrictions - the messages may only be sent or
received by institutions that are members of the Funds Closed User Group. For more information, please visit https://
www.swift.com/our-solutions/global-financial-messaging/securities-messages/funds-distribution/funds-migration or email
funds@swift.com.
20 July 2018 48
Standards MT November 2018 Message Structure and Message Types
General Information
• 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.
{4: (CrLf)
:20:494932/DEV (CrLf)
:23B:CRED (CrLf)
:32A:030731EUR1958,47 (CrLf)
:33B:EUR1958,47 (CrLf)
LEDEBOERSTRAAT 27 (CrLf)
AMSTERDAM (CrLf)
:70:/INV/ 18042 910412 (CrLf)
:71A:SHA (CrLf)
D0200004
-}
Note Basic Header, Application Header, User Header, Text and Trailers Blocks are not
separated by CrLf. In the above example, the blocks have been shown on separate
lines for purposes of clarity.
20 July 2018 49
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Delimiter
Field tag number
Letter option
Delimiter
D0200005
: nn [a] :
20 July 2018 50
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Rules
Field structure must comply with the following rules:
• Each field is identified by a tag which consists of two digits, or two digits followed by a letter
option.
• Each field consists of a colon :, followed by a tag, followed by another colon :, and then the
field content.
• The following character restrictions apply to the field content:
- The field content must not start with a Carriage Return, Line Feed (CrLf).
- The field content must not be composed entirely of blank characters.
- Within the field content, apart from the first character of the field content, a colon : or hyphen
- must never be used as the first character of a line.
- Except for fields 15a and 77E, a field must consist of at least one meaningful character. (See
the 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 52
- 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.)
• In some messages, the field specifications may indicate specific characters, or sets of
characters, for inclusion in the text of the field.
These take the following forms:
- codes, for example, AMEND, TRF, or 08
- slash / or double slash //
- slash or double slash followed by a code, for example, //CH or /FIXED
20 July 2018 51
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Restrictions on Length
Examples
2n up to 2 digits
20 July 2018 52
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
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:
Examples:
• 1129 = November 29
• 941129 = 94 November 29
• 19941129 = 1994 November 29
The date field formatted as 6!n (YYMMDD) distinguishes between the 20th and 21st century as
follows:
If the year, (YY) is greater than 79, the date refers to the 20th century. If the year is 79 or less, the
date refers to the 21st century:
20 July 2018 53
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
6.3.2 Numbers
Format
nn...nn, nn...n
D0200006
Integer part
Usage rules
Wherever they represent a numeric value, numbers always take the same form:
• The integer part must contain at least one digit.
• Decimal points are not permitted. A decimal comma ',' shall precede the fractional part.
• The maximum length includes the decimal comma.
• The fractional part may be missing, but the decimal comma must always be present.
• Neither blank spaces, nor any symbols other than the decimal comma are permitted.
• The integer part is mandatory in the number component, and at least one character must
appear. Leading zeros are allowed.
• Normally, when a number represents an amount of money, the number of places following the
decimal comma may not exceed the number of decimal digits valid for the specified currency.
The specifications for the individual message types will indicate the fields where this is not the
case. Details regarding the allowable fractional parts for each currency code may be found in
the BIC Plus which is available on www.swiftrefdata.com.
Examples
Valid Invalid
000,00 0000
0, 0
0,67 .67
0,25 ,25
100000, 100.000
25768, 25-768
99999999, 999.999.999
100, 100
10500,00 10500.00
5,25 5 1/4
20 July 2018 54
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
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.
Where:
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).
20 July 2018 55
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
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 :53A:/6/12-12
CITIUS33CHI CITIUS33CHI
:53B:/D/24-24 :53B:/A/24-24
:53D:/52/48-48 :53D:/:/48-48
John Doe John Doe
122 Peyton Place 122 Peyton Place
Elyria, OH 22216 Elyria, OH 22216
:87E:FREE :87E:APMT
/C/12-12 /A/12-12
CHASUS33 CHASUS33
:87F:APMT :87F:APMT
/D/12-12 /:/48-48
John Doe John Doe
122 Peyton Place 122 Peyton Place
Elyria, OH 22216 Elyria, OH 22216
20 July 2018 56
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Example
Bank A in New York services an account in USD for Bank B in London. Bank B also services, in
London, a USD account (number 567-3245-01) for Bank A.
Bank A sends a USD transfer to Bank B, using its USD account in London, serviced by Bank B, for
reimbursement. Bank A will request that Bank B debit its account in London as follows:
53B:/D/567-3245-01
Note In certain message types, there are exceptions to the rules for use of the party
identifier detailed in this section, for example, field 57a in category 3 messages. In
those cases, the intended use of the party identifier is described in the relevant field
specification for the message type.
[/34x] (Account)
Definition
Name and address of the party, with an optional account.
Usage rules
If Account is absent, then Name and Address must not start with a slash '/'.
Definition
Identifier code such as a BIC. Optionally, the account of the party.
20 July 2018 57
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
[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.
/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.
20 July 2018 58
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Definition
Name and address and, optionally, the account or clearing code of the party.
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 '/'.
20 July 2018 59
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
In some messages, some of these clearing codes may also be used with option A, that is, the MTs
101, 102, 102 STP, 103, 103 REMIT, 103 STP, and 104. This is indicated with the field
specifications of each message type.
When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //RT is used, it
should appear only once, and in the first of the fields 56a and 57a of the payment instruction.
When it is necessary that an incoming SWIFT payment be made to the party in this field via
Fedwire, US banks require that the code FW appears in the optional Party Identifier.
When it is necessary that an incoming SWIFT payment be made to the party in this field via a real-
time gross settlement system (RTGS), the code RT should appear in the optional Party Identifier.
Option D must only be used in exceptional circumstances, that is, when the party cannot be
identified by a BIC, and when there is a bilateral agreement between the sender and the receiver
permitting its use. Unless qualified by a clearing system code or an account number, the use of
option D may prevent the automated processing of the instruction(s) by the receiver.
20 July 2018 60
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
20 July 2018 61
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Or
Or
20 July 2018 62
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Definition
Name and address in a structured format to facilitate straight through processing.
Codes
When Party Identifier is used with the (Code)(Country Code)(Identifier) format, for example in field
50F Ordering Customer, one of the following codes must be used:
ARNU Alien Registration Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Alien Registration
Number.
CCPT Passport Number The code followed by a slash, '/' must be followed by the
ISO country code, a slash, '/' and the Passport Number.
CUST Customer Identification 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):
1 Name of the Ordering Customer The number followed by a slash, '/' must be followed by the
name of the ordering customer.
20 July 2018 63
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
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.
20 July 2018 64
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
• The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s):
T73).
• Option F fields that also allow the numbers 4 – 8 in Number, for example field 50F, have these
additional network validated rules:
- Number 4 must not be used without number 5 and vice versa (Error code(s): T56).
- Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local to
the sender, must not be later than the date on which the message is successfully sent to
SWIFT (Error code(s): T50).
- Numbers 5, 6, and 7 must be followed by a valid ISO country code (Error code(s): T73), a
slash '/' and additional Details (Error code(s): T56).
- Numbers 4, 5, 6, 7, and 8 must not be repeated (Error code(s): T56).
- The use of number 8 is only allowed in the following instances (Error code(s): T56):
▪ to continue information on the Identifier of the ordering customer provided in subfield 1
(Party Identifier) used with the (Code)(Country Code)(Identifier) format.
▪ to continue information on the Customer Identification Number provided in subfield 2
(Name and Address) following number 6.
▪ to continue information on the National Identity Number provided in subfield 2 (Name and
Address) following number 7.
Usage rules
• In subfield 2: Numbers 1, 2, and 3 may be repeated.
• In subfield 2: if number 2 is present, the first occurrence of number 3 must include the town in
additional details.
For ordering customer:
• Subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if additional
space is required for providing the Identifier of the ordering customer, one of the following
options must be used:
- First option (preferred): Identify the ordering customer with a different identifier where the
length is not an issue.
- Second option: Continue the information in subfield 2 (Name and Address) using number 8.
• Subfield 2 (Name and Address): if additional space is required for providing the Customer
Identification Number (number 6) or the National Identity Number (number 7) of the ordering
customer, one of the following options must be used:
- First option (preferred): Identify the ordering customer with a different identifier where the
length is not an issue.
- Second option: Continue the information in subfield 2 (Name and Address) using number 8.
20 July 2018 65
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
/34x (Account)
Definition
Identifier code of the party with mandatory account number.
/34x (Account)
Definition
Name and address of the party with a mandatory account.
5*40x (Narrative)
Definition
Identification of the party.
Codes
The following codes can be used with this option. Depending on the field tag and message type,
some codes may or may not be used, may exclude each other or not, or may be mandatory or not:
20 July 2018 66
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
/CITY/ 35x city followed by the name of city (and state, country)
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)
20 July 2018 67
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
[/34x] (Account)
Definition
Name and address of the party, with an optional account.
Usage rules
If Account is absent, then Name and Address must not start with a slash '/'.
35x (Narrative)
Definition
Identification of the party
Definition
Identification of the party, with a qualifier and an identifier code such as a BIC.
20 July 2018 68
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Definition
Identification of the party, with a qualifier and name and address.
Definition
Identification of the party, with a qualifier, issuer code and proprietary code.
Definition
Identification of the party, with a qualifier, an optional issuer code, type of ID, country code and
alternate ID.
Definition
Identification of the party, with a qualifier and name.
20 July 2018 69
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
Definition
Identification of the party, with a qualifier and names.
6.3.5 Times
Formats
4!n
6!n
Rules
Times are represented as either four or six digit integers, that is, in form HHMM or HHMMSS
respectively, where (Error code T38):
• H = Hour
• M = Minutes
• S = Seconds
No blank spaces or other characters are permitted.
Examples
0000
1200
235959
20 July 2018 70
Standards MT November 2018 Field Structure and Field Formatting Rules
General Information
The valid range of value dates implemented on the SWIFT system for these MTs is from 1980 to
2060, and must meet the following requirements:
• allowed: a year component, for example, 'YY' in the range of 80 through 60, of an ISO defined
six digit integer date 'YYMMDD'
• not allowed: any 'YY' component outside of this range, for example, 'YY' in the range of 61
through 79
Example
ACKed NAKed
:32A:601130USD1, :32A:611130USD1,
:30:801130 :30:791130
For the purpose of value date ordering, if there is more than one value date field in a message, the
lesser date will be selected:
MTxxx
In this example, field 30 Value Date (18 December 1995) is selected for value date ordering of the
message. Error code T50 is returned after an invalid value date.
20 July 2018 71
Standards MT November 2018 Euro-Related Information (ERI)
General Information
20 July 2018 72
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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.
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 75.
• 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.
20 July 2018 73
Standards MT November 2018 Euro-Related Information (ERI)
General Information
• 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.
Field 72 6*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
Usage rules
The network will validate the structure of ERI, but not the content, see section ERI Validation and
Examples on page 82 for details.
20 July 2018 74
Standards MT November 2018 Euro-Related Information (ERI)
General Information
Example
:72:/OCMT/GBP2525,/
/CHGS/EUR2,40/
20 July 2018 75
Standards MT November 2018 Euro-Related Information (ERI)
General Information
20 July 2018 76
Standards MT November 2018 Euro-Related Information (ERI)
General Information
103 STP
20 July 2018 77
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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.
20 July 2018 78
Standards MT November 2018 Euro-Related Information (ERI)
General Information
20 July 2018 79
Standards MT November 2018 Euro-Related Information (ERI)
General Information
33D 33D
20 July 2018 80
Standards MT November 2018 Euro-Related Information (ERI)
General Information
20 July 2018 81
Standards MT November 2018 Euro-Related Information (ERI)
General Information
(1) If the settlement date in the optional field is not specified, the message will be accepted.
(2) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is
used, the validation is not performed).
(3) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is
used, the validation is not performed).
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 54.
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.
20 July 2018 82
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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)
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)
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.
20 July 2018 83
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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)
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.
20 July 2018 84
Standards MT November 2018 Euro-Related Information (ERI)
General Information
//xxxxxxxxxx(CrLf)
/OCMT/EUR12345,/xxxxx(CrLf)
//xxxxxxxxxx(CrLf)
Example 2 - field 61
OCMT is found twice. The message is NAKed:
:61:9809010931C3500,25FCHK304955//4958843(CrLf)
/OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf)
20 July 2018 85
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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
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 '//'.
20 July 2018 86
Standards MT November 2018 Euro-Related Information (ERI)
General Information
Examples
Narrative format of information that follows ERI-related codes split across lines:
:72:xxxxx/OCMT/EUR12345,(CrLf)
12//CHGS/ (CrLf)
EUR12,/(CrLf)
Validation
The system performs the following validation:
1. If subfield 9 in field 61 is present, then validates according to the format 34x:
• if the check here above is OK, then goes to point 2
• otherwise the message is NAKed with the corresponding error code
2. Scans for /OCMT/
If /OCMT/ is:
• not present, then performs next field validation
• present more than once, then NAK the message with the Error code T47 and terminates the
validation
• present only once, then validates the format 3!a15d/
20 July 2018 87
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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:
- valid, then goes to next field validation
- invalid, then NAK the message with the corresponding error code and terminates the
validation
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
20 July 2018 88
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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:
• 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/
20 July 2018 89
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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:
- valid, then goes to next field validation
- invalid, then NAK the message with the corresponding error code and terminates the
validation
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/
20 July 2018 90
Standards MT November 2018 Euro-Related Information (ERI)
General Information
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:
- valid, then goes to next field validation
- invalid, then NAK the message with the corresponding error code and terminates the
validation
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:
• 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/
20 July 2018 91
Standards MT November 2018 Euro-Related Information (ERI)
General Information
If format is:
- valid, then goes to next field validation
- invalid, then NAK the message with the corresponding error code and terminates the
validation
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:
- valid, then goes to next field validation
- invalid, then NAK the message with the corresponding error code and terminates the
validation
20 July 2018 92
Standards MT November 2018 Legal Notices
General Information
Legal Notices
Copyright
SWIFT © 2018. All rights reserved.
Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.
SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR
Policy - End-User License Agreement, available at www.swift.com > About Us > Legal > IPR
Policies > SWIFT Standards IPR Policy.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT:
the SWIFT logo, SWIFT, SWIFTNet, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this publication
are trade names, trademarks, or registered trademarks of their respective owners.
20 July 2018 93