Sie sind auf Seite 1von 91

Standards

General Information

23 July 2010

N EX T

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.

VE RS IO N

Standards MT November 2010

Standards MT November 2010

Table of Contents
. reface .............................................................................................................................................................................4 P 1 Standards MT Volumes Description ....................................................................................................... 5
1.1 1.2 1.3 Volume/Chapter Explanation ................................................................................................................... 5 Standards MT Volumes ............................................................................................................................ 6 Formatting Explanation .......................................................................................................................... 10

Introduction to Standards MT ................................................................................................................. 15


2.1 2.2 2.3 2.4 2.5 Reason for Standards MT ...................................................................................................................... 15 Standards Development and Implementation Process ..................................................................... 15 Standards Maintenance Process .......................................................................................................... 15 Message Envelope Structure ................................................................................................................ 16 Message Validation Description ........................................................................................................... 17

Business Identifier Code (BIC) ................................................................................................................ 18


3.1 3.2 3.3 3.4 Introduction ............................................................................................................................................... 18 Business Identifier Code Structure ....................................................................................................... 18 Using BICs in SWIFT Messages .......................................................................................................... 19 Standards for SWIFT BICs and non-SWIFT BICs ............................................................................. 19

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


4.1 4.2 4.3 4.4 SWIFT Message Structure .................................................................................................................... 23 SWIFT Message Types .......................................................................................................................... 23 Message Length and Structure ............................................................................................................. 44 Message Structure Example ................................................................................................................. 45

Field Structure ................................................................................................................................................ 46


5.1 Overview ................................................................................................................................................... 46

Characters ........................................................................................................................................................ 49
6.1 6.2 6.3 SWIFT Character Set (X Character Set) ............................................................................................. 49 EDIFACT Level A Character Set (Y Character Set) .......................................................................... 49 Information Service Character Set (Z Character Set) ....................................................................... 49

Field Formatting Rules ............................................................................................................................... 50


7.1 7.2 7.3 7.4 7.5 7.6 7.7 General Rules .......................................................................................................................................... 50 Dates ......................................................................................................................................................... 50 Numbers ................................................................................................................................................... 51 Currency Codes ....................................................................................................................................... 52 Party Identification ................................................................................................................................... 52 Times ......................................................................................................................................................... 67 Value Date Ordering ............................................................................................................................... 67

N EX T

VE RS IO N

General Information

Table of Contents

Euro-Related Information (ERI) .............................................................................................................. 69


8.1 8.2 8.3 8.4 Deletion of National Currency Denomination (NCD) Currency Codes ........................................... 69 Euro-Related Information (ERI) ............................................................................................................ 69 Message Specific Guidelines on the Use of ERI ............................................................................... 72 ERI Validation and Examples ................................................................................................................ 79

. egal Notices ...............................................................................................................................................................91 L

23 July 2010

N EX T

VE RS IO N
3

Standards MT November 2010

Preface
Significant changes The following tables list all significant changes to the content of the MT General Information since the 24 July 2009 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document.
New information Addition of field 70G of MT 564 Addition of a new section for option no letter Addition of a new rule section for option D Addition of a new section for option F Location 6.3, "Information Service Character Set (Z Character Set)" on page 49 7.5.2, "Option No Letter: Name and Address" on page 54 7.5.6, "Option D: Name and Address" on page 56 7.5.7, "Option F: Party Identifier / Name and Address" on page 60 7.5.8, "Option G: Identifier Code" on page 63 7.5.11, "Option K: Name and Address" on page 65 8.1, "Deletion of National Currency Denomination (NCD) Currency Codes" on page 69 8.3.3, "Messages with Value Date Validation" on page 75 Location

Addition of a new section for option G

Addition of a new rule section for option K Introduction of the Euro in Estonia

Updated information

N EX T
Deleted information Deletion of references to BEI

BIC/BEI change. BIC now stands for business Changes apply throughout the document identifier code. The concept of BEI (business entity identifier) has been removed. Financial institution BIC replaces the former BIC concept. Non-financial institution BIC replaces the former BEI concept. Allow the "metals messages" to be used for nonmetals, that is change the names and scopes of the suite of messages to "commodities" rather than "metals". This also means changing the names of fields that contain "metal" to "commodity" and revising the definitions accordingly. Update format of code /NAME/ for option J Party identification with no Party Identifier 1.1, "Volume/Chapter Explanation" on page 5 1.2.3, "Category Volumes: Message Text Standards" on page 8 4.2, "SWIFT Message Types " on page 23

Deletion of references to MTs that have been deleted in SRG 2011 (308, 645, 810, 812, 813, 820, 821, 822, 823)

Warning

This volume contains information effective as of the November 2010 Standards Release. Therefore the 24 July 2009 edition of the User Handbook Standards MT volumes remains effective until November 2010.

VE RS IO N
Location

7.5.10, "Option J: Party Identification with no Party Identifier " on page 64

Changes apply throughout the document 4.2, "SWIFT Message Types " on page 23 8.3.3, "Messages with Value Date Validation" on page 75

General Information

Standards MT Volumes Description

1
1.1

Standards MT Volumes Description


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

Standards MT General Field Definitions plus

Ten Category volumes containing the respective message text standards: Category 1 - Customer Payments and Cheques Category 2 - Financial Institution Transfers

Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Category 4 - Collections and Cash Letters Category 5 - Securities Markets Category 6

Additional Standards MT volumes To assist users, usage guidelines have been published in three additional Standards MT volumes for specific categories of messages. These volumes contain guidelines for using message standards. The three volumes are: Standards MT Usage Guidelines Category 1 - Customer Payments and Cheques - Message Usage Guidelines Category 5 - Securities Markets - Message Usage Guidelines
23 July 2010 5

N EX T
This volume consists of 2 books: Commodities Syndications Category 8 - Travellers Cheques

Category 7 - Documentary Credits and Guarantees

Category 9 - Cash Management and Customer Status Category n - Common Group Messages

VE RS IO N

Standards MT November 2010

Additional volumes are issued separately for: advance information, published as the Standards Release Guide supplementary information, as appropriate

1.2
1.2.1

Standards MT Volumes
Standards MT General Information Volume
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 1 - "Standards MT Volumes Description"

Overview

Description

This chapter contains:

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

N EX T
3 - "Business Identifier Code (BIC)"

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

This chapter contains: a description of the purpose and development of the Business Identifier Code information regarding the nature and format of the components of the Business Identifier Code (BIC) an explanation on the use of non-SWIFT (not connected) BICs and SWIFT (connected) BICs

VE RS IO N

General Information

Standards MT Volumes Description

Chapter 4 - "Message Structure and Message Types"

Description This chapter contains: definitions and illustrations of the structure of a message 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

5 - "Field Structure"

This chapter contains: a definition and illustration of the structure and general format restrictions on a field within a message an explanation of the rules for the formatting of dates, currency codes and parties (that is, the account number line and format options)

6 "Characters"

This chapter lists the allowable characters in the X-, Y-, and Z-character sets.

7"Field Formatting Rules" In addition to General Rules for field formatting, this chapter also covers field formatting rules for the following elements: Dates

Numbers

Currency Codes

Party Identification

1.2.2

Overview

23 July 2010

N EX T
Times 8 - "Euro-Related Information (ERI) "

Value Date Ordering

This chapter contains guidelines for using existing SWIFT message standards for transactions involving the euro.

Standards MT General Field Definitions Plus Volume


This online publication is available only on the User Handbook Online. It allows you to search for specific pieces of information, easily and quickly as information is sorted by MT or by field tag. The Standards MT General Field Definitions plus provides a general description of all messagetext fields. It also provides information about the FIN error codes. Information which applies to fields in a specific message, for example, field usage and codes, is found in the description of the message type within the Standards category message reference guides.

VE RS IO N

Standards MT November 2010

Description The Standards MT General Field Definitions plus contains a description of each field tag, including: format options definition network validated rules usage rules relevant message types codes

Overview

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

N EX T
Category 8 - Travellers Cheques
Section Introduction Category Message Types

Category 6 - Treasury Markets - Syndications Category 7 - Documentary Credits and Guarantees

Category 9 - Cash Management and Customer Status Category n - Common Group Messages

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


Description 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. 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

VE RS IO N

1.2.3

Category Volumes: Message Text Standards

General Information

Standards MT Volumes Description

Section

Description whether the use of the message type requires registration with SWIFT in a Message User Group information about how to register for a Message User Group

Message Type Description

This section contains detailed descriptions of each message type within the category. Including: MT Scope MT Format Specifications MT Network Validated Rules

Glossary of Terms

1.2.4

Additional Volumes

Overview

23 July 2010

N EX T
Volume Standards MT Usage Guidelines Standards - Category 1 Customer Payments and Cheques - Message Usage Guidelines Standards - Category 5 - Securities Markets - Message Usage Guidelines

Three 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.
Description This volume recommends the use of messages for specific business situations. This volume contains information for using Category 1 message types. Currently this volume contains the MT 104 Country Section. This volume contains additional information for using the Category 5 message types. It explains how the ISO 15022 messages relate to each other, and the parties involved. It also includes a general outline of the structure of each new message.

VE RS IO N
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.

Standards MT November 2010

1.3
1.3.1

Formatting Explanation
Field Definition Format
The Standards MT General Field Definitions plus contains the following information per field.
Name Definition Description 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. The specification of available options, or alternative formatting possibilities, for the field. The format options include restrictions on length and types of characters allowed. Additional information pertaining to use of the field. Any restrictions on use, for example, a double slash '//' is not permitted within field 20. A matrix showing the message types which use the specified field. A matrix showing the message types which use the specified code.

Overview

Format Options

Usage Rules Network Validated Rules Message Type Use Codes

1.3.2

Message Type Descriptions

Introduction

Example of an information flow

10

N EX T
Note

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

The following symbols are used to identify the parties involved in the message flow:

VE RS IO N

General Information

Standards MT Volumes Description

Legend

Originator of the transaction Financial institution Bank Corporate Customer Sender or Receiver

Other parties involved in the transaction

N EX T

VE RS IO N
MT

The actual SWIFT Message

MT nnn

MT nnn

Another SWIFT message involved in the transaction

Financial institution or customer relationship

Final recipient
D0200001

Financial institution

Bank

Corporate Customer

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 specifies the sender and receiver of the message and provides an explanation on how the message is used. In some messages, an example of the message flow is also provided. Message type format specifications The format specifications are the rules for the layout of the message type. This information is provided in table form as shown below:

23 July 2010

11

Standards MT November 2010

MT nnn (Message Type name) Status M M Tag 20 21 Field Name Transaction Reference Number Related Reference Content/Options 16x 16x No. 1 2

Mandatory Sequence A (Sequence Name) M M 25 32A Account Identification Value Date, Currency Code, Amount 35x 6!n3!a15d 3 4

----> Optional Repetitive Sequence B (Sequence Name) O M O ----| 52a 71B 72 Ordering Institution Detail of Charges Sender to Receiver Information A or D 6*35x 6*35x 5 6 7

M = Mandatory O = Optional

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

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.

N EX T
Tag is the field identification.
Status Tag Field Name

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. Some of the fields in the format have names different from those in Standards MT General Field Definitions plus. The name in the Message Type Format overrides that given in the Standards MT General Field Definitions plus. Some message formats are separated into sequences of fields, as shown below. An arrow indicates that a sequence of fields may be repeated.
Content/Options No.

First sequence 1 2 ---->


12 General Information

VE RS IO N

Standards MT Volumes Description

Status

Tag

Field Name

Content/Options

No.

Second Sequence 3 4 ----| Third sequence 5 6 7 M = Mandatory O = Optional

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, 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

MT guidelines

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: a. FORMAT specifies the field formats which are allowed in the field. b. PRESENCE indicates if the field is mandatory, optional, or conditional in its sequence.
23 July 2010 13

N EX T

Market practice rules specify the rules published by a recognised Market Practice Group, for example, for category 5, the Securities Market Practice Group (SMPG). It informs the reader of 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 countryspecific requirements that should be considered when using the field or message type.

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.

VE RS IO N

Standards MT November 2010

c. DEFINITION specifies the definition of the field in this sequence of the message type. d. 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. e. 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. f. 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. g. 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

14

N EX T
Note

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. For further information about the header and trailer, see the FIN Service Description.

VE RS IO N

General Information

Introduction to Standards MT

2
2.1

Introduction to Standards MT
Reason for Standards MT
Why Standards MT? The message text standards have been developed to support the business transactions of SWIFT users. To ensure that the multitude of practices and conventions of users are in harmony, financial messages transmitted via the SWIFT network must adhere to the message text standards. Standards enable financial institutions to move from manual to automated initiation and processing of financial transactions.

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

the ability to maintain more comprehensive management information

Board Paper 828 (R)

2.3

Introduction Maintenance projects aim at maintaining the functionality of existing standards. They are carried out to bring existing standards in line with business changes, or to correct technical problems. There are two ways to submit maintenance requests (change requests) to SWIFT, as follows: through User Group Chairpersons through representative market practice groups in which there are SWIFT members
23 July 2010 15

N EX T

2.2

Standards Development and Implementation Process


For details about the standards development and implementation process, please refer to BP828 (R) - Standards development and implementation process, rev.3, approved by the SWIFT Board of Directors in 2007. This paper is available upon request from National User Group Chairpersons or from the SWIFT Standards Department.

Standards Maintenance Process

VE RS IO N

Key benefits

Standards MT November 2010

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. Five months prior to implementation (SR-5), the 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.

2.4

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

16

N EX T

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.

Message Envelope Structure

VE RS IO N

General Information

Introduction to Standards MT

2.5
Rule

Message Validation Description


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: the correct sequence of fields

23 July 2010

N EX T
the permitted character set

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 presence of the decimal comma in numbers and amounts that in amounts, the correct number of digits appears after the decimal comma for the currency of the message field, for example, not more than 2 for USD that the sum of individual amounts in the message is equal to the sum of amounts date validity, for example, day not higher than 31 conditional relationships, that is, the network validated rules for each message type. Depending on system constraints, not all conditional relationships will be validated by the SWIFT system codes, where an error code is specified in the Field Specifications of the message description

VE RS IO N

17

Standards MT November 2010

3
3.1

Business Identifier Code (BIC)


Introduction
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.

Business Identifier Codes (BICs)

ISO 9362 Business Identifier Codes (BICs) are used in certain fields of messages (for example, field 53a, Sender's Correspondent, or field 59A, Beneficiary Customer) to identify a party in the transaction. When a BIC is available (for example, the party to be specified has been assigned a BIC), it should be used whenever possible, as it is standardised and can therefore be automatically processed by the receiver. Both financial institutions and non-financial institutions can be identified with a BIC.

3.2
3.2.1

Business Identifier Code Structure

Description

3.2.2

Description Business Identifier Codes (BICs) must be registered codes, either connected (referred to as a SWIFT BIC) or not connected (referred to as a non-SWIFT BIC). For financial institutions, corporate institutions, or funds, which are not SWIFT users (that is which are not connected), the eighth character of the BIC must be the digit '1'.
18 General Information

N EX T
INSTITUTION CODE COUNTRY CODE LOCATION CODE BRANCH CODE 2!c

Components of a Business Identifier Code


The Business Identifier Code (BIC) consists of eight or eleven characters, comprised of the first three, or all four of the following components:
4!a 2!a

SWIFT and non-SWIFT BICs

VE RS IO N
[3!c]

SWIFT is the designated ISO Registration Authority for these ISO codes, and is responsible for their assignment and subsequent publication.

Business Identifier Code (BIC)

The following illustrates a BIC of a non-connected institution, with and without a branch code:
:53A:CHBAHKH1 :54A:CHBLGB21BBB

3.3

Using BICs in SWIFT Messages


Identifying the message sender and receiver SWIFT financial and system messages may only be sent from and received by SWIFT users. Therefore, non-SWIFT Business Identifier Codes (BICs) (that is, those which contain the digit '1' in the eighth position) cannot be included in the header of a SWIFT message. BICs in the message text Several of the party fields in the text of financial message types (see "Party Identifier" on page 53) provide options to identify an institution or corporation by its Identifier Code. Published BICs may be used as Identifier Code in these party field options when selected. The SWIFT system validates the accuracy of the Identifier Code used. There are restrictions on the use of BIC in some of the party fields. "BIC" is used when either a financial institution or a non-financial institution is allowed in the party field. "Financial institution BIC" is used if only financial institution details are allowed in the party field and "non-financial institution BIC" is used if only non-financial institution details are allowed in the party field. Customers can find more information about party formats and validation rules in the Standards MT documentation. BIC Directory

ISO Business Identifier Codes are listed in the International Business Identifier Code Directory (BIC Directory), published by SWIFT as the ISO Registration Authority for ISO 9362.

3.4

Introduction This section describes the standards for registered SWIFT BICs and non-SWIFT BICs used in SWIFT messages. Details regarding SWIFT's policy concerning the use of SWIFT BICs can also be found in the FIN Service Description.

23 July 2010

N EX T
Note

The directory is published on a monthly basis. All registered ISO 9362 BICs including branch codes, are published in the BIC Directory by default. A user can request that a BIC be registered but not published. Unpublished BICs may only be used where there is a bilateral agreement between the sender and the receiver. Unpublished 8-character SWIFT BICs may only be used in the header of a message and not as Identifier Code in fields, for example, 53a, 58a..., of a message. For further information, contact End-to-End Ordering, S.W.I.F.T. SCRL, Avenue Adle 1, B-1310 La Hulpe, Belgium (SWIFT BIC: SWHQBEBBCOS).

Standards for SWIFT BICs and non-SWIFT BICs

VE RS IO N

19

Standards MT November 2010

3.4.1

Components of a BIC
All SWIFT BICs and non-SWIFT BICs have the same basic structure except that non-SWIFT BICS must specify the digit '1' in the eighth position. For addressing purposes, the BIC is used with an additional character in the ninth position, shown as the logical terminal code:
Institution code Country code Location code Logical terminal code Branch code

Introduction

a
1

a
2

a
3

a
4

a
5

SWIFT Destination

Logical Terminal Identifier


Note: a = Letters only c = Letters and digits only

VE RS IO N
a
6

c
7

c
8

c
9

10

11

12

Institution code

Country code The country code identifies the country or geographical territory in which the user is located. It consists of the ISO two-alphabetic character country code, for example, CL = Chile. The country code must reflect the geographical location of the business unit. A current list of ISO country codes may be found in the information section of the BIC Directory. The country code must reflect the geographical location of the business unit. Location code The location code consists of two alphanumeric characters, and identifies, within a country or geographical territory, the region and/or city in which the user is located.

20

N EX T

The four-digit institution code is unique to each institution, and identifies the institution worldwide. The institution code may be selected by the customer institution, subject to the following rules: An institution code is only valid when approved by SWIFT. A proposed code which is misleading will be rejected by SWIFT, for example, BANK, or GIRO. SWIFT will allow an institution to use the institution code of another, if agreed by the institution code owner.

General Information

D0200002

Business Identifier Code (BIC)

The first component of the location code is the region code. It consists of one alphanumeric character (the digits '0' '1' are not permitted). A region code is used to: split a country into geographical parts identify major commercial locations within a country represent a time zone in a country The second component of the location code is the suffix code. It consists of one alphanumeric character (excluding the digit '0' and the letter 'O' - the digit '0' is dedicated to test and training destinations). Where required, the suffix code enables a subdivision within a region or city, or distinguishes destinations with the same institution code, country code and region code. For non-SWIFT BICs, this suffix code must be '1'.

The terminal code identifies a specific terminal connection within a destination. It consists of one alphanumeric character (the digits '0' and '1' are not permitted). This code is not included in the BICs published in the BIC Directory. Branch code

The branch code is an optional component for all BICs. However, once registered, and published in the directory as part of a SWIFT user's BIC, its use is highly recommended. The branch code consists of three alphanumeric characters. A branch code can be registered to identify: a 100 %-owned branch of the requestor's institution a department within the requestor's institution

The following restrictions exist for branch code registration:

3.4.2

Description A SWIFT BIC is formed from the combination of an institution code, a country code and a location code.

23 July 2010

N EX T
SWIFT BIC

'X' is not permitted as the first character of a branch code. The branch code 'BIC' may not be used. The default branch code for SWIFT BICs which do not include a registered branch code is 'XXX'. Registration of a branch code denoting a geographical location in a country other than that indicated by the country code within the 8-character BIC, is prohibited. All registered and published branch codes must be able to receive and act upon all message types in accordance with the receiver's responsibility and liability as defined in the FIN Service Description. An institution may request that a branch code not be published. All unpublished branch codes must be covered by a bilateral agreement between sender and receiver.

VE RS IO N

Logical terminal code

21

Standards MT November 2010

Each user must register and publish at least one 8-character SWIFT BIC of a geographical nature per country. These codes are sufficient for the SWIFT system to determine where to deliver a message. In addition to the 8-character SWIFT BIC registered in the country, the user may request additional SWIFT BICs. These additional SWIFT BICs in the same country may only define a geographical location. The first six characters (institution code, country code) must be identical to the first six characters of the existing SWIFT BIC. Functional references are prohibited for 8character SWIFT BICs. Additional 8-character SWIFT BICs may be registered un-published. These un-published BICs may only be used on a bilateral basis between sender and receiver. Changes to SWIFT BICs may only be done at the time of the monthly BIC Directory publications. To be binding, these changes must be reflected in the BIC Directory. If the deadline for publication is passed, the change in SWIFT BIC may only be made in the next publication. Non-financial institutions can be further identified with one of the following subtypes: BEID (Business Entity Identifier) TRCO (Treasury Counterparty)

MCCO (Non-financial Institution in an MA-CUG) SMDP (Securities Market Data Provider) CORP (Corporate)

The list of subtypes is published in the Corporations section of the BIC Directory.

22

N EX T

VE RS IO N

General Information

Message Structure and Message Types

4
4.1

Message Structure and Message Types


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) The message type is composed of three digits, generally defined as:
Message Structure

VE RS IO N
Category Group Type

MT nnn

Where: Category

Usually describes, at a general level, the underlying business function of the message. For example: Category 1 = Customer Payments and Cheques. Describes the function of the message within the specified category. For example: 11n = Category 1 Cheque Payment Messages. Describes the specific function. For example: 112 = Status of a Request for Stop Payment of a Cheque.

Group

4.2

Overview The following table lists all message types defined in the Standards MT volumes, effective in the November 2010 Standards Release. For each message type, there is a short description, an indicator that the message type requires authentication (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).

23 July 2010

N EX T

Type

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 Part C of the FIN Operations Guide.

SWIFT Message Types

D0200003

23

Standards MT November 2010

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 101 MT Name Request For Transfer Multiple Customer Credit Transfer Single Customer Credit Transfer Single Customer Credit Transfer Purpose Requests to debit a customer's account held at another institution. Conveys multiple payment instructions between financial institutions. Instructs a funds transfer. Authen Y Max Length 10,000 MUG Y

102 102+ 103 103+ 103 REMIT 104

10,000

VE RS IO N
Y 10,000 Instructs a fund transfer. Y 10,000 Conveys direct debit instructions and requests for direct debits between financial institutions. Y 10,000 An envelope which conveys a 2k EDIFACT message. Conveys direct debit instructions between financial institutions. Y 2,000 Y 10,000 Advises or confirms the issuance of a cheque to the drawee bank. Requests the drawee bank to stop payment of a cheque. Y 2,000 Y 2,000 Y 2,000 Advises an account owner of charges, interest and other adjustments. Requests payment of charges, interest or other expenses. Y 2,000 Y 2,000 Requests the receiver to consider cancellation of the message identified in the request. Y 2,000

Y Y

Direct Debit and Request for Debit Transfer Message

105

EDIFACT Envelope

107

General Direct Debit Message Advice of Cheque(s)

N EX T
110

111

Request for Stop Payment of a Cheque

112

Status of a Request Indicates action(s) taken in for Stop Payment of attempting to stop a Cheque payment of a cheque. Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

190

191

192

24

General Information

Message Structure and Message Types

MT 195

MT Name Queries

Purpose Requests information relating to a previous message or amendment to a previous message. Responds to an MT 195 Query or MT 192 Request for Cancellation or other message where no specific message type has been provided for a response. Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined.

Authen Y

Max Length 2,000

MUG N

196

Answers

2,000

198

Proprietary Message

10,000

199

Free Format Message

VE RS IO N
Y 2,000 Y 2,000 Multiple of the MT 200. Y 2,000 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. Requests the movement of funds between financial institutions, related to an underlying customer credit transfer that was sent with the cover method. Multiple of the MT 202. Y 10,000 Y 10,000 Y 2,000 Claims funds from SWIFT member banks. Further transmits a transfer 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. Y 2,000 Y 10,000

200

Financial Institution Requests the movement of Transfer for its Own the sender's funds to its Account account at another financial institution. Multiple Financial Institution Transfer for its Own Account General Financial Institution Transfer

201

202

N EX T
202 COV General Financial Institution Transfer

203

Multiple General Financial Institution Transfer Financial Markets Direct Debit Message Financial Institution Transfer Execution

204

205

23 July 2010

25

Standards MT November 2010

MT 205 COV

MT Name Financial Institution Transfer Execution

Purpose Further transmits a transfer request domestically, related to an underlying customer credit transfer that was sent with the cover method.

Authen Y

Max Length 10,000

MUG N

207

Request for Financial Institution Transfer

Requests to debit an Y ordering financial institution's account held at the receiving financial institution or the account servicing financial institution. Notifies the receiver that it will receive funds for the sender's account. Y

10,000

210

Notice to Receive

2,000

256

Advice of NonPayment of Cheques

VE RS IO N
Informs the sender of one or more previously sent cheque truncation messages of non-payment of one or more truncated cheques. It may also be used to specify dishonoured items that result in reversing a previous payment settlement. Advises an account owner of charges, interest or other adjustments. Requests payment of charges, interest or other expenses. Y 10,000 Y 2,000 Y 2,000 Requests the receiver to consider cancellation of the message identified in the request. Requests information relating to a previous message or amendment to a previous message. Responds to an MT 295 Queries message or an MT 292 Request for Cancellation or other message where no specific message type has been provided for a response. Contains formats defined and agreed to between users and for those messages not yet live. Y 2,000 Y 2,000 Y 2,000 Y 10,000

290

Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

291

N EX T
292

295

Queries

296

Answers

298

Proprietary Message

26

General Information

Message Structure and Message Types

MT 299

MT Name Free Format Message Foreign Exchange Confirmation Forex/Currency Option Allocation Instruction Advice/Instruction of a Third Party Deal Foreign Currency Option Confirmation Foreign Currency Option Confirmation

Purpose Contains information for which no other message type has been defined. Confirms information agreed to in the buying/ selling of two currencies. Instructs the allocation of a block trade (forex or currency option). Advises of or instructs settlement of a third party foreign exchange deal. Confirms information agreed to in the buying and selling of vanilla options on currencies. Confirms information agreed to in the buying and selling of exotic options on currencies.

Authen Y

Max Length 2,000

MUG N

300

10,000

303

10,000

304

10,000

306

VE RS IO N
N 10,000 Advises of or instructs settlement of a third party foreign exchange deal. Y 10,000 Confirms the terms of a contract relative to a fixed loan/deposit transaction. Advises the trade details and instructs the settlement of a fixed term loan/deposit done with a third party financial institution. Confirms the terms of a contract relative to a call/ notice loan/deposit transaction. Confirms the details of a forward rate agreement. Confirms the settlement details of a forward rate agreement. Advises of a loan/deposit interest payment. Confirms the details of a single currency interest rate derivative swap, cap, collar or floor. N 10,000 Y 10,000 N 10,000 N 10,000 N 10,000 N 10,000 N 10,000

305

2,000

307

Advice/Instruction of a Third Party FX Deal

320

Fixed Loan/Deposit Confirmation Instruction to Settle a Third Party Loan/ Deposit

321

N EX T
330 Call/Notice Loan/ Deposit Confirmation Forward Rate Agreement Confirmation Forward Rate Agreement Settlement Confirmation Advice of Loan/ Deposit Interest Payment Single Currency Interest Rate Derivative Confirmation

340

341

350

360

23 July 2010

27

Standards MT November 2010

MT 361

MT Name Cross Currency Interest Rate Swap Confirmation Interest Rate Reset/ Advice of Payment

Purpose Confirms the details of a cross currency interest rate swap transaction. Confirms or advises the 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. Confirms the details of the partial or full termination or recouponing of a single currency interest rate swap, cap, collar, or floor. Confirms the details of the partial or full termination or recouponing of a cross currency interest rate swap. Orders to purchase or sell a specific amount of a certain currency. Confirms the execution of an FX order previously sent.

Authen N

Max Length 10,000

MUG N

362

2,000

364

365

Cross Currency Interest Rate Swap Termination/ Recouponing Confirmation Foreign Exchange Order

VE RS IO N
N 10,000 Y 10,000 Y 10,000 Advises an account owner of charges, interest or other adjustments. Requests payment of charges, interest or other expenses. N 2,000 N 2,000 Requests the receiver to consider cancellation of the message identified in the request. Requests information relating to a previous message or amendment to a previous message. Responds to an MT 395 Queries or an MT 392 Request for Cancellation or other message where no specific message type has been provided for a response. Contains formats defined and agreed to between N 2,000 N 2,000 N 2,000 N 10,000

Single Currency Interest Rate Derivative Termination/ Recouponing Confirmation

10,000

380

381

Foreign Exchange Order Confirmation Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

390

N EX T
391

392

395

Queries

396

Answers

398

Proprietary Message

28

General Information

Message Structure and Message Types

MT

MT Name

Purpose users and for those messages not yet live.

Authen

Max Length

MUG

399

Free Format Message Advice of Payment

Contains information for which no other message type has been defined. Advises of a payment under a collection or part thereof. It also handles the settlement of proceeds. Conveys instructions to obtain payment or acceptance against specified conditions. The message is used for clean collections only and supports financial documents such as accepted and nonaccepted bills of exchange and promissory notes. Acknowledges receipt of a collection. It also specifies if the collecting bank does not intend to act in accordance with the collection instruction. Informs the remitting bank of the acceptance of one or more drafts under one collection instruction. Advises of the nonpayment or nonacceptance under a previously received collection. Enquires about documents sent for collection. Advises the remitting bank of the fate of one or more collection documents; usually accompanied by one or more questions or requests. Amends collection instructions.

2,000

400

2,000

405

Clean Collection

10,000

410

Acknowledgement

VE RS IO N
Y 2,000 Y 2,000 Y 10,000 Y Y 2,000 2,000 Y 2,000 2,000 Confirms that the face Y amount of cash letter(s) received has been credited under usual reserve (subject to final payment). Advises the account owner of adjustments made to its account (related to a previous credit for a cash letter). Y 2,000

412

Advice of Acceptance

N EX T

416

Advice of NonPayment/ NonAcceptance

420 422

Tracer

N N

Advice of Fate and Request for Instructions

430 450

Amendment of Instructions Cash Letter Credit Advice

N N

455

Cash Letter Credit Adjustment Advice

23 July 2010

29

Standards MT November 2010

MT 456

MT Name Advice of Dishonour

Purpose Advises the account owner that financial document(s) included in the cash letter have been dishonoured for reasons specified in the advice. Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses.

Authen Y

Max Length 2,000

MUG N

490

Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

2,000

491

2,000

492

VE RS IO N
Requests the receiver to consider cancellation of the message identified in the request. Y 2,000 Requests information relating to a previous message or amendment to a previous message. 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. Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. Instructs the registration, deregistration or reregistration of a financial instrument at the registration provider. Confirms the registration, deregistration or reregistration of a beneficial owner or shareholder with the registration provider. Y 2,000 Y 2,000 Y 10,000 Y 10,000 Y 10,000 Y 10,000 Y 10,000

495

Queries

496

Answers

N EX T
498 Proprietary Message

499

Free Format Message

500

Instruction to Register

501

Confirmation of Registration or Modification

502

Order to Buy or Sell Instructs the purchase or sale of a given quantity of a specified financial instrument under specified conditions.

30

General Information

Message Structure and Message Types

MT 503

MT Name Collateral Claim

Purpose Requests new or additional collateral, or the return or recall of collateral. Proposes new or additional collateral. Proposes or requests the substitution of collateral held. Provides the details of the valuation of both the collateral and the exposure.

Authen Y

Max Length 10,000

MUG Y

504 505

Collateral Proposal Collateral Substitution Collateral and Exposure Statement Collateral Status and Processing Advice

Y Y

10,000 10,000

Y Y

506

10,000

507

VE RS IO N
Advises the status of a Y collateral claim, a collateral proposal, or a proposal/ request for collateral substitution. Reports on the movement of securities within the holding. Y 10,000 10,000 Provides information about the status of a previously executed trade. Advises the status of a registration instruction or modification. Y 10,000 Y 10,000 Provides brief and early Y information about a securities deal, for example, a block trade that is to be allocated before final confirmation. Instructs the allocation of a block trade. Y Y 10,000 10,000 10,000 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

508

Intra-Position Advice Trade Status Message

509

510

Registration Status and Processing Advice Client Advice of Execution

513

N EX T
514 515 Trade Allocation Instruction

N N

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. Securities Loan Confirmation

516

23 July 2010

31

Standards MT November 2010

MT 517

MT Name Trade Confirmation Affirmation

Purpose Positively affirms the details of a previously received confirmation/ contract note. Confirms the details of a trade and, where necessary, its settlement to a trading counterparty. Instructs the modification of client details at the registration provider. Instructs the movement of securities within the holding.

Authen Y

Max Length 10,000

MUG N

518

Market-Side Securities Trade Confirmation Modification of Client Details Intra-Position Instruction General Securities Lending/Borrowing Message

10,000

519

10,000

524

10,000

526

VE RS IO N
Requests the borrowing of securities or notifies the return or recall of securities previously out on loan. It may also be used to list securities available for lending. Performs a specific action on a collateral management transaction. Y 2,000 Y 10,000 Sent by an ETC service provider, it communicates early settlement information to a custodian or clearing agent about a client-side trade. Sent by an ETC service provider, it communicates early settlement information to a custodian or clearing agent about a market-side trade. Y 10,000 Y 10,000 Requests the modification Y of a processing indicator or other non-matching information. Reports at a specified time, the quantity and identification of securities and other holdings which the account servicer holds for the account owner. Provides details of increases and decreases of holdings which occurred during a specified period. Y 10,000 10,000 Y 10,000 Provides details of pending Y increases and decreases of holdings at a specified time. 10,000

527

Triparty Collateral Instruction ETC Client-Side Settlement Instruction

528

N EX T
529 ETC Market-Side Settlement Instruction

530

Transaction Processing Command

535

Statement of Holdings

536

Statement of Transactions

537

Statement of Pending Transactions

32

General Information

Message Structure and Message Types

MT 538

MT Name Statement of IntraPosition Advices

Purpose Provides details of increases and decreases in securities within the holding during a specified period. Instructs a receipt of financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction. Instructs a receipt of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction.

Authen Y

Max Length 10,000

MUG N

540

Receive Free

10,000

541

Receive Against Payment

10,000

542

Deliver Free

VE RS IO N
Instructs a delivery of financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction. 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 Y 10,000 Confirms a receipt of financial instruments free of payment. It may also be used to cancel or reverse a confirmation. Confirms a receipt of financial instruments against payment. It may also be used to cancel or reverse a confirmation. Confirms a delivery of financial instruments free of payment. It may also be used to cancel or reverse a confirmation. Confirms a delivery of financial instruments against payment. It may also be used to cancel or reverse a confirmation. Advises the status of a settlement instruction or replies to a cancellation request. Y 10,000 Y 10,000 Y 10,000 Y 10,000 Y 10,000

543

Deliver Against Payment

544

Receive Free Confirmation

N EX T
545 Receive Against Payment Confirmation

546

Deliver Free Confirmation

547

Deliver Against Payment Confirmation

548

Settlement Status and Processing Advice

23 July 2010

33

Standards MT November 2010

MT 549

MT Name Request for Statement/ Status Advice Triparty Collateral Status and Processing Advice

Purpose Requests a statement or a status message. Provides validation results and status advice re collateral instructions and proposed collateral movements. Claims reimbursement of income or redemption proceeds, or a combination of both. Provides an account owner 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.

Authen Y

Max Length 10,000

MUG N

558

10,000

559

Paying Agent's Claim

2,000

564

565

Corporate Action Instruction

VE RS IO N
Instructs the custodian on Y the investment decision made by an account owner relative to a corporate action event. 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 10,000 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. Provides complex instructions or narrative details relating to a corporate action event. Provides the details of the valuation of both the collateral and the exposure. Provides owner or pooled income information for a period of time arranged between the intermediary and the withholding agent. Y 10,000 Y 10,000 Y 10,000 Y 10,000

Corporate Action Notification

10,000

566

Corporate Action Confirmation

N EX T
567 Corporate Action Status and Processing Advice

568

Corporate Action Narrative

569

Triparty Collateral and Exposure Statement IRS 1441 NRA-IRS Beneficial Owners' List

574(1)

34

General Information

Message Structure and Message Types

MT 574(2)

MT Name IRS 1441 NRAForm W8-BEN

Purpose Certifies the foreign status of a beneficial owner for United States tax withholding. Reports on all securities and cash activity for a given combination of safekeeping and cash accounts. 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. Provides certificate numbers of securities.

Authen Y

Max Length 10,000

MUG N

575

Report of Combined Activity

10,000

576

Statement of Open Orders

10,000

577 578

Statement of Numbers Settlement Allegement

VE RS IO N
Y Y 10,000 10,000 Advises the account owner that a counterparty has alleged a settlement instruction on the account owner's account. Y 2,000 Claims or notifies a change in the amount of collateral held against securities out on loan or for other reasons. Y 2,000 Claims reimbursement of funds paid on behalf of the receiver or of securities received which are due to the sender. It may also advise that funds and/or securities have or will be remitted by the sender in favour of the receiver. Provides statuses and details of executed trades which are not yet matched nor affirmed. Y 2,000 Y 10,000 Provides details of pending Y settlement allegements. Instructs the issuance or release of a depositary receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another. Y 10,000 10,000

N N

579

Certificate Numbers Replaces or supplements the 'certificate numbers' field in a primary message, for example, MT 577. Collateral Adjustment Message

581

N EX T
582 Reimbursement Claim or Advice

584

Statement of ETC Pending Trades

586

Statement of Settlement Allegements Depositary Receipt Instruction

587

23 July 2010

35

Standards MT November 2010

MT 588

MT Name Depositary Receipt Confirmation

Purpose Confirms the issuance or release of a depositary receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another. Advises the status, or change in status, of a depositary receipt. Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses.

Authen Y

Max Length 10,000

MUG N

589

Depositary Receipt Status and Processing Advice Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

10,000

590

2,000

591

VE RS IO N
Y 2,000 Requests the receiver to consider cancellation of the message identified in the request. Y 2,000 Requests information relating to a previous message or amendment to a previous message. Responds to an MT 595 Queries or MT 592 Request for Cancellation or other message where no specific message type has been provided for the response. Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. Confirms the details of a commodity trade and its settlement. Confirms the details of a commodity option contract. Instructs the receiver to transfer by book-entry, or physically deliver, a specified type and quantity of commodity to a specified party. Y 2,000 Y 2,000 Y 10,000 Y 2,000 N 2,000 N Y 2,000 2,000

592

595

Queries

596

Answers

N EX T
598 Proprietary Message

599

Free Format Message

600

Commodity Trade Confirmation Commodity Option Confirmation Commodity Transfer/Delivery Order

601 604

N N

36

General Information

Message Structure and Message Types

MT 605

MT Name Commodity Notice to Receive

Purpose Notifies the receiver of an impending book-entry transfer or physical delivery of a specified type and quantity of commodity. Advises the receiver of a debit entry to a specified commodity account. Advises the receiver of a credit entry to a specified commodity account. Provides the details of all bookings to a commodity account.

Authen N

Max Length 2,000

MUG N

606

Commodity Debit Advice Commodity Credit Advice Statement of a Commodity Account Statement of Commodity Contracts

2,000

607

2,000

608

2,000

609

VE RS IO N
Identifies all outstanding commodity contracts, as at a specified date for which confirmations have been exchanged. Confirms a commodity fixed term loan/deposit contract. N 2,000 N 10,000 Provides notice of the borrower(s) request for drawdown(s)/renewal(s) on a given date. Y 2,000 Specifies the interest rate and, if applicable, the exchange rate, for the next interest period. Advises of payments and/ or prepayments of principal and/or of interest with the same value date, but not related to any subsequent drawing or renewal. Y 2,000 Y 2,000 Y 2,000 Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses. Y 2,000 Y 2,000 Requests the receiver to consider cancellation of Y 2,000

620

Commodity Fixed Loan/Deposit Confirmation Notice of Drawdown/ Renewal

643

644

Advice of Rate and Amount Fixing

N EX T
646 Payment of Principal and/or of Interest

649

General Syndicated Provides for Facility Message communications related to syndicated facilities for which no specific message has been defined. Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

690

691

692

23 July 2010

37

Standards MT November 2010

MT

MT Name

Purpose the message identified in the request.

Authen

Max Length

MUG

695

Queries

Requests information relating to a previous message or amendment to a previous message. 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. Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. Indicates the terms and conditions of a documentary credit.

2,000

696

Answers

2000

698

Proprietary Message

VE RS IO N
Y 10,000 Y 2,000 Y 10,000 Continuation of an MT 700 for fields 45a, 46a and 47a. Provides brief advice of a documentary credit for which full details will follow. Y 10,000 Y 2,000 Informs the receiver of amendments to the terms and conditions of a documentary credit. Advises the receiver of the terms and conditions of a documentary credit. Y 10,000 Y 10,000 Continuation of an MT 710 for fields 45a, 46a and 47a. Advises the transfer of a documentary credit, or part thereof, to the bank advising the second beneficiary. Continuation of an MT 720 for fields 45a, 46a and 47a. Y 10,000 Y 10,000 Y 10,000

699

Free Format Message Issue of a Documentary Credit Issue of a Documentary Credit Pre-Advice of a Documentary Credit

700

701

705

N EX T
707 Amendment to a Documentary Credit

710

Advice of a Third Bank's or a NonBank's Documentary Credit Advice of a Third Bank's Documentary Credit Transfer of a Documentary Credit

711

720

721

Transfer of a Documentary Credit

38

General Information

Message Structure and Message Types

MT 730

MT Name Acknowledgement

Purpose Acknowledges the receipt 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. Advises that documents received with discrepancies have been taken up. Advises the refusal of documents that are not in accordance with the terms and conditions of a documentary credit. Requests the receiver to honour claims for reimbursement of payment(s) or negotiation(s) under a documentary credit.

Authen Y

Max Length 2,000

MUG N

732

Advice of Discharge

2,000

734

Advice of Refusal

VE RS IO N
Y 10,000 Y 2,000 Provides a reimbursement claim to the bank authorised to reimburse the sender or its branch for its payments/ negotiations. Y 2,000 Informs the reimbursing Y bank of amendments to the terms and conditions of a documentary credit, relative to the authorisation to reimburse. Advises of discrepancies and requests authorisation to honour documents presented that are not in accordance with the terms and conditions of the documentary credit. Advises a bank which has 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. Y 2,000 10,000 Y 2,000

740

Authorisation to Reimburse

742

Re-imbursement Claim

N EX T
747 Amendment to an Authorisation to Reimburse

750

Advice of Discrepancy

752

Authorisation to Pay, Accept or Negotiate

23 July 2010

39

Standards MT November 2010

MT 754

MT Name Advice of Payment/ Acceptance/ Negotiation

Purpose Advises that documents 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.

Authen Y

Max Length 2,000

MUG N

756

Advice of Reimbursement or Payment

760 767

Guarantee Guarantee Amendment

VE RS IO N
Issues or requests the issue of a guarantee. Y 10,000 10,000 Amends a guarantee Y which has been previously issued or requests the amendment of a guarantee which the sender has previously requested to be issued. Acknowledges the receipt of a guarantee message and may indicate that action has been taken according to instructions. Y 2,000 Advises that a bank has Y been released of its liability for a specified amount under its guarantee. Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses. Y 2,000 2,000 Y 2,000 Requests the receiver to consider cancellation of the message identified in the request. Requests information relating to a previous message or amendment to a previous message. Responds to an MT 795 Queries message or MT 792 Request for Y 2,000 Y 2,000 Y 2,000

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 N

768

Acknowledgement of a Guarantee Message

N EX T
769 Advice of Reduction or Release

790

Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

791

792

795

Queries

796

Answers

40

General Information

Message Structure and Message Types

MT

MT Name

Purpose Cancellation or other messages where no specific message type has been provided for the response.

Authen

Max Length

MUG

798

Proprietary Message

Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. Provides the sale and settlement details for the sale of travellers cheques by a single selling agent. Provides the details (excluding the settlement details) of the sales of travellers cheques in cases where the data is lengthy or includes data from several selling agents.

10,000

799

Free Format Message T/C Sales and Settlement Advice [Single]

10,000

800

2,000

801

T/C Multiple Sales Advice

VE RS IO N
Y 2,000 Provides the settlement details of multiple sales of travellers cheques. Y 2,000 Notifies the issuer of the destruction/cancellation of travellers cheque inventory held by the selling agent. It may also request a selling agent to destroy/cancel travellers cheque inventory. Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses. Y 2,000 Y 2,000 Y 2,000 Requests the receiver to consider cancellation of the message identified in the request. Requests information relating to a previous message or amendment to a previous message. Responds to an MT 895 Queries message or MT 892 Request for Y 2,000 Y 2,000 Y 2,000

802

T/C Settlement Advice

824

T/C Inventory Destruction/ Cancellation Notice

N EX T
890 Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

891

892

895

Queries

896

Answers

23 July 2010

41

Standards MT November 2010

MT

MT Name

Purpose Cancellation or other messages where no specific message type has been provided for the response.

Authen

Max Length

MUG

898

Proprietary Message

Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. Advises an account owner of a debit to its account. Advises an account owner of a credit to its account.

10,000

899

Free Format Message Confirmation of Debit Confirmation of Credit

2,000

900 910 920

N N

2,000 2,000 2,000

N N N

Request Message

935

Rate Change Advice

VE RS IO N
Requests the account N servicing institution to send an MT 940, 941, 942 or 950. 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. Provides balance and transaction details of an account to a financial institution on behalf of the account owner. N 2,000 N 2,000 Provides balance information of an account to a financial institution on behalf of the account owner. Provides balance and transaction details of an account, for a specified period of time, to a financial institution on behalf of the account owner. Provides balance and transaction details of an account to the account owner. Provides balance and transaction details of a netting position as recorded by a netting system. N 2,000 N 2,000 N 2,000 N 2,000

940

N EX T

Customer Statement Message

941

Balance Report

942

Interim Transaction Report

950

Statement Message

970

Netting Statement

42

General Information

Message Structure and Message Types

MT 971

MT Name Netting Balance Report Netting Interim Statement

Purpose Provides balance information for specified netting position(s). Advises interim balance and transaction details of a netting position as recorded by a netting system. Requests an MT 971 or 972 containing the latest available information. Requests an MT 986. Provides business-related information about a customer or institution.

Authen N

Max Length 2,000

MUG N

972

2,000

973

Netting Request Message Status Enquiry Status Report

2,000

985 986

N N

2,000 2,000

N N

990

Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

VE RS IO N
Advises an account owner of charges, interest or other adjustments to its account. Requests payment of charges, interest or other expenses. N 2,000 N 2,000 Requests the receiver to consider cancellation of the message identified in the request. N 2,000 Requests information relating to a previous message or amendment to a previous message. Responds to an MT 995 Queries or MT 992 Request for Cancellation or other messages where no specific message type has been provided for the response. Contains formats defined and agreed to between users and for those messages not yet live. Contains information for which no other message type has been defined. N 2,000 N 2,000 N 10,000 N 2,000

991

992

N EX T

995

Queries

996

Answers

998

Proprietary Message

999

Free Format Message

(1) The appropriate format validation of the IRS Beneficial Owners' List of the MT 574 IRS 1441 NRA is triggered by the code IRSLST in field 119 ({3:{119:IRSLST}}) of the user header of the message (block 3). (2) The appropriate format validation of the IRS Form W8-BEN of the MT 574 IRS 1441 NRA is triggered by the code W8BENO in field 119 ({3:{119:W8BENO}}) of the user header of the message (block 3).

23 July 2010

43

Standards MT November 2010

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

4.3
Rules

Message Length and Structure


There are several rules which must be followed when structuring financial messages: There are two alternative message length limitations for financial messages, as explained below. For both alternatives, there is a difference between the message length calculation on input and on output. The total number of characters always includes headers and trailers. (See "SWIFT Message Types " on page 23 for information about the maximum length per message type.) Alternatives:

The number of characters allowed by the SWIFT system on input from a computer-based terminal is 2,000. On output to a computer-based terminal the system will limit the number of characters to 2,600. The number of characters allowed by the SWIFT System on input from a computer-based terminal is 10,000. On output to a computer-based terminal the system will limit the number of characters to 10,600. The number of characters permitted on output for retrieved messages, including headers and trailers, is 11,325. 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.

44

N EX T

VE RS IO N

General Information

Message Structure and Message Types

4.4

Message Structure Example


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

:50K:FRANZ HOLZAPFEL GMBH (CrLf) VIENNA (CrLf)

:59:H.F. JANSSEN (CrLf)

LEDEBOERSTRAAT 27 (CrLf) AMSTERDAM (CrLf)

:70:/INV/ 18042 910412 (CrLf) :71A:SHA (CrLf) -}

VE RS IO N
Text block Trailer block

23 July 2010

N EX T

{5:{CHK:123456789ABC}}

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.

D0200004

45

Standards MT November 2010

5
5.1

Field Structure
Overview
Field structure
Delimiter Field tag number Letter option Delimiter
D0200005

: nn [a] :
Rules

There are several rules which must be followed when structuring fields:

Each field is identified by a tag which consists of two digits, or two digits followed by a letter option. Field structure consists of a colon ':', followed by a tag, followed by a colon ':' and the field content. The following character restrictions are applied to field content: it must not start with a Carriage Return, Line Feed (CrLf) it must not be entirely composed of blank characters

46

N EX T
Subfields: the order of subfields is fixed

within field content, apart from the first character of the field, a colon ':' or hyphen '-' must never be used as the first character of a line except for fields 15a and 77E, a field must consist of at least one meaningful character (See the Standards MT General Field Definitions plus for formatting requirements)

Fields are separated by a 'Field Separator within Text' (CrLf:). The first field in a message is preceded by a 'Start of Text' (CrLf:) and the last field in a message is followed by an 'End of Text' (CrLf-). The Carriage Return, Line Feed character must always appear as a sequence. This sequence shall only be used to indicate start of text, as a field separation within text, to indicate a new line, and to indicate the end of text. 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 may themselves be of fixed or variable length

VE RS IO N

General Information

Field Structure

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 Whenever a field content contains mandatory and optional subfields, 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 the following table:
Restrictions on Length nn nn-nn maximum length (minimum is 1) minimum and maximum length Types of Characters Allowed n a c numeric digits (0 through 9) only alphabetic letters (A through Z), upper case only alphabetic letters (upper case) and digits only hexadecimal letters A through F (upper case) and digits only any character of the X permitted set (General FIN application set) upper and lower case allowed ("SWIFT Character Set (X Character Set)" on page 49) any character of the EDIFACT level A character set as defined in ISO 9735 upper case only ("Information Service Character Set (Z Character Set)" on page 49) any character as defined by the Information Service ("SWIFT Character Set (X Character Set)" on page 49) blank space decimals

nn!

fixed length

N EX T
nn*nn Examples 2n 3!a 4*35x 16-64h

maximum number of lines times maximum line length

special formats, for example, for numbers and dates codes, for example, currency codes (see the BIC Directory) 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
23 July 2010 47

VE RS IO N
h x y z e d up to 2 digits always 3 letters up to 4 lines of up to 35 characters each at least 16 and up to 64 hexadecimal digits

Standards MT November 2010

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 upper-case alphabetic characters. When codes contain a mix of alpha and numeric characters, the alpha character must also be in uppercase.

48

N EX T

VE RS IO N
General Information

Characters

6
6.1

Characters
SWIFT Character Set (X Character Set)
Description Computer-based terminals communicating with SWIFT use EBCDIC code. The character set is as follows: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+{} CR LF Space

Although part of the character set, the curly brackets are permitted as delimiters and cannot be used within the text of user-to-user messages (Error Code M60).

6.2

EDIFACT Level A Character Set (Y Character Set)


Description In field 77F of MT 105, the EDIFACT level A character set, as defined in ISO 9735, is used. This character set is as follows: ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789

6.3

Description

23 July 2010

N EX T
Space 0123456789 .,-()/='+:?!"%&*<>;{ @#_ CrLf Space

.,-()/='+:?!"%&*<>;

Other characters are not allowed (Error Code M60).

Information Service Character Set (Z Character Set)


In fields 70F of MT 568, field 70G of the MT 564, and 77T of MT 103, the allowed character set is as follows: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ

Other characters are not allowed, including the curly bracket '}' (Error Code M60).
49

VE RS IO N

Standards MT November 2010

7
7.1

Field Formatting Rules


General Rules
Overview The following general rules apply to all fields: The field length and type of character(s), for example, letters, numbers, are specified in the Standards MT General Field Definitions plus and in the field specifications for individual message types. Unless otherwise stated in the Standards MT General Field Definitions plus or message field specifications, all specified subfields must be present: in the order (that is, sequence) specified

with no separator symbols (except a slash '/' or double slash '//' when specified). 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 (when the field is used). The following 4 characters, preceded by a slash '/', are optional, and therefore need not be present in the field. A field format may be shown on two or more lines: 3!n 6!n

7.2

Formats

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

50

N EX T
Note

When this is the case, the information must be formatted with the CrLf character separating each line. 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.

Dates

Format: 4!n Format: 6!n Format: 8!n

VE RS IO N

General Information

Field Formatting Rules

YYYY = all four digits of the year MM = month DD = day No blank spaces or other characters are permitted. Examples: 1129 = November 29 941129 = 94 November 29 19941129 = 1994 November 29

The date field formatted as 6!n (YYMMDD) distinguishes between the 20th and 21st century as follows: If the year, (YY) is greater than 79, the date refers to the 20th century. If the year is 79 or less, the date refers to the 21st century:
If YY > 79 else YYMMDD = 19YYMMDD YYMMDD = 20YYMMDD

The six-digit date thus ranges from 1980 to 2079.

On the FIN network, there is an additional restriction for the year range where the date is affected by the Value Date Ordering process ("Value Date Ordering" on page 67) The valid date range of 1980 to 2060 applies to:

field 30, in MTs: 101, 104, 107, 110, 111, 112, 201, 203, 204, 207, 210, 256 field 32A, in MTs: 102, 103, 110, 111, 112, 200, 202, 202 COV, 205, 205 COV, 256, 910

7.3

Format

N EX T
Numbers

VE RS IO N
nn...nn, nn...n
Fractional part (optional) 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.
23 July 2010 51

D0200006

Standards MT November 2010

Neither blank spaces, nor any symbols other than the decimal comma are permitted. The integer part is mandatory in the number component, and at least one character must appear. Leading zeros are allowed. Normally, when a number represents an amount of money, the number of places following the decimal comma may not exceed the number of decimal digits valid for the specified currency. The specifications for the individual message types will indicate the fields where this is not the case. Details regarding the allowable fractional parts for each currency code may be found in the BIC Directory. Examples
Valid
000,00 0, 0,67 0,25 100000, 25768, 99999999, 100, 10500,00 5,25

Invalid
0000 0 .67 ,25 100.000 25-768 999.999.999 100 10500.00 5 1/4

7.4

Currency Codes
Format Format: 3!a Description

7.5

Introduction

52

N EX T
Identifier Code (BIC) name and address

A currency code normally consists of a two-letter ISO country code followed by a third letter denoting the particular currency or type of funds. For a complete list of ISO currency codes, please refer to the BIC Directory.

Party Identification
Parties may be represented in several ways:

branch (city) of the sender or the receiver

other identification codes, for example, account number When necessary, party identification can be supplemented by an account number line preceding other party information.

VE RS IO N

General Information

Field Formatting Rules

7.5.1

Party Identifier
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 [/1a] /C /D Subfield 2 [/34x] Specifies which account is involved: The receiver's account serviced by the sender is credited. The sender's account serviced by the receiver is debited. The account number information, preceded by a slash '/'.

Overview

Rules

When the party identifier is present, the following rules apply:

The party specified in the field with the account must be the account owner. The optional party identifier must specify the account known to the account servicing institution. Extreme care must be taken when formatting the party identifier, for example, when only subfield 2 '[/34x]' is entered, and its first and third characters consist of '/', the system can only presume that both subfields 1 and 2 are present. It will then qualify the second character for either code 'C' or 'D', and NAK the message if one or the other is not present (Error Code T51). Note Other fields impacted by this form of validation are: 42A, 42D.

Additional Rules

23 July 2010

N EX T

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 7.5.7, "Option F: Party Identifier / Name and Address" on page 60

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.

VE RS IO N

53

Standards MT November 2010

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
:53A:/C/12-12 CITIUS33CHI :53B:/D/24-24 :53D:/52/48-48 John Doe 122 Peyton Place Elyria, OH 22216 :87E:FREE /C/12-12 CHASUS33 :87F:APMT /D/12-12 John Doe 122 Peyton Place Elyria, OH 22216

Invalid

Example

7.5.2

Format
[/34x] 4*35x (Account) (Name and Address)

Definition Name and address of the party, with an optional account.

54

N EX T
53B:/D/567-3245-01

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:

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.

Option No Letter: Name and Address

VE RS IO N
:53B:/A/24-24 :53D:/:/48-48 John Doe 122 Peyton Place Elyria, OH 22216 :87E:APMT /A/12-12 CHASUS33 :87F:APMT /:/48-48 John Doe 122 Peyton Place Elyria, OH 22216

:53A:/6/12-12 CITIUS33CHI

General Information

Field Formatting Rules

Rules If Account is absent, then Name and Address must not start with a slash '/' (Error code: T77). Field assigned to this option 59

7.5.3

Option A: Identifier Code


[/1a][/34x] 4!a2!a2!c[3!c] (Party Identifier) (Identifier Code)

Format

Identifier code such as a BIC. Optionally, the account of the party. Network validation rules

Identifier Code must be a registered BIC (Error codes T27, T28, T29 and T45). For institutions which are not SWIFT users, that is, which are not yet connected, the eighth position must consist of the digit '1'. Examples

The following example shows BICs of non-connected users, without, and with, a branch code:
:53A:CHBAKHH1 :54A:CHBLGB21BBB

Fields assigned to this option 41A*, 42A

7.5.4

Format
[/1a][/34x] [35x] (Party Identifier) (Location)

23 July 2010

N EX T
Note

50A**, 51A, 52A, 53A, 54A, 55A, 56A, 57A, 58A, 59A 82A, 83A, 84A, 85A, 86A, 87A, 88A 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 56 on the use of clearing codes. (**) Field 50A has the format [/34x] for Party Identifier.

Option B: Branch of Sender/Receiver

VE RS IO N

Definition

55

Standards MT November 2010

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

7.5.5

Option C: Account Number/Party Identifier


/34x (Account)

Format

Definition

A code uniquely identifying an account and/or party.

In the MTs 101, 102, 103 and 104, clearing codes may be used. Fields assigned this option

51C, 52C, 53C, 56C, 57C, 58C 82C, 83C, 85C, 87C, 88C Note

7.5.6

Format

Definition Name and address and, optionally, the account or clearing code of the party.

56

N EX T
[/1a][/34x] 4*35x (Party Identifier) (Name and Address)

See "Option D: Name and Address" on page 56 on the use of clearing codes.

Option D: Name and Address

Note

This option is used when no other option is available. This information also applies to fields 50 (when option representing name and address is selected) and 59 (without letter option).

VE RS IO N
General Information

82B, 84B, 85B, 87B, 88B

Field Formatting Rules

Rules If a Party Identifier is absent, then Name and Address must not start with a slash '/' (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

National clearing codes list

When the party identifier is used to indicate a national clearing system code preceded by a double slash '//', the following codes may be used:
AT AU BL CC CH CP ES 5!n 6!n 8!n 9!n 6!n 4!n 8..9n 9!n 7!n 3!n Austrian Bankleitzahl

Australian Bank State Branch (BSB) Code German Bankleitzahl

Canadian Payments Association Payment Routing Number CHIPS Universal Identifier

CHIPS Participant Identifier

23 July 2010

N EX T
FW GR HK IE 6!n IN IT PL PT RU SC SW SW 11!n 10!n 8!n 8!n 9!n 6!n 3..5n 6!n

Spanish Domestic Interbanking Code Fedwire Routing Number HEBIC (Hellenic Bank Identification Code) Bank Code of Hong-Kong

Irish National Clearing Code Indian Financial System Code (IFSC) is the identification scheme defined by the Reserve Bank of India

Italian Domestic Identification Code Polish National Clearing Code (KNR) Portuguese National Clearing Code Russian Central Bank Identification Code UK Domestic Sort Code Swiss Clearing Code (BC code) Swiss Clearing Code (SIC code)

In some messages, some of these clearing codes may also be used with option A, that is, the MTs 101, 102, 103 and 104. This is indicated with the field specifications of each message type.

VE RS IO N

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.

57

Standards MT November 2010

When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //RT is used, it should appear only once, and in the first of the fields 56a and 57a of the payment instruction. When it is necessary that an incoming SWIFT payment be made to the party in this field via Fedwire, US banks require that the code FW appears in the optional Party Identifier. When it is necessary that an incoming SWIFT payment be made to the party in this field via a real-time gross settlement system (RTGS), the code RT should appear in the optional Party Identifier. Option D must only be used in exceptional circumstances, that is, when the party cannot be identified by a BIC, and when there is a bilateral agreement between the sender and the receiver permitting its use. Unless qualified by a clearing system code or an account number, the use of option D may prevent the automated processing of the instruction(s) by the receiver. National clearing codes formats List of codes and formats: The Australian BSB code is the identification scheme defined by APCA (Australian Payments Clearing Association). Its structure is either:

for financial institutions with an extensive branch network: 2!n = Bank Code 1!n = State Code 3!n = Branch Code

or for institutions with a small network: 3!n = Bank Code 3!n = Branch Code

58

N EX T
3!n = Bank Code 3!n = Bank Code 4!n = Branch Code 6!c = Branch code 2!n = Bank code 4!n = Branch code

The Bank Code for Hong-Kong is structured as follows:

The Hellenic Bank Identification Code (HEBIC) is the identification scheme defined by the Hellenic Bank Association. Its structure is:

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 institution code in BIC - ISO 9362) 1!n = Numerical zero - Reserved for future use

The structure of the Irish NSC code is 2!n4!n, where:

VE RS IO N

General Information

Field Formatting Rules

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 = 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

Fields assigned to this option 42D 50D, 51D, 52D, 53D, 54D, 55D, 56D, 57D, 58D 82D, 83D, 84D, 85D, 86D, 87D, 88D Note Field 41D does not have the optional party identifier but does have an additional subfield.

23 July 2010

N EX T
4!n = Bank Code 4!n = Branch Code [1!n] = Check Digit

The South African National Clearing code is defined by BankServ, the South African Bankers Services Company Ltd. Its structure is 3!n3!n, where: 3!n = Bank code, potentially with leading zeros 3!n = Branch code, potentially with leading zeros

The Spanish Domestic Interbanking Code is the identification scheme defined by CCI (Centro de Cooperacion Interbancaria). Its structure is:

VE RS IO N

4!n = Bank Code (IFRI), potentially containing leading zeros

59

Standards MT November 2010

7.5.7

Option F: Party Identifier / Name and Address


[35x] 4*35x (Party Identifier) (Name and Address)

Format

The following line formats must be used (Error code(s): T54):


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

Or

Line 2-5 (subfield Name and Address

Definition

Name and address in a structured format to facilitate straight through processing. Codes

When subfield 1 Party Identifier is used with the (Code)(Country Code)(Identifier) format, 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. The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Passport 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. 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. 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. The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the National Identity Number. The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Social Security Number. The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Tax Identification Number.

CCPT CUST

Passport Number

60

N EX T
Customer Identification DRLC EMPL Employer Number NIDN SOSE Social Security Number TXID

Driver's License Number

National Identity Number

Tax Identification Number

VE RS IO N
1!n/33x

Line 1 (subfield Party Identifier)

4!a/2!a/27x

(Code)(Country Code)(Identifier)

(Number)(Details)

General Information

Field Formatting Rules

Codes Each line of subfield 2 Name and Address when present must start with one of the following numbers:
1 Name of the ordering customer The number followed by a slash, '/' must be followed by the name of the ordering customer (where it is recommended that the surname precedes given name(s)). 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). The number followed by a slash, '/' must be followed by the ISO country code, a slash '/' and Town (Town can be complemented by postal code (for example zip), country subdivision (for example state, province, or county). The number followed by a slash, '/' must be followed by the Date of Birth in the YYYYMMDD format. The number followed by a slash, '/' must be followed by the ISO country code, a slash '/' and the Place of Birth. 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. The number followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the National Identity Number. 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.

Address Line

Country and Town

4 5 6

Date of Birth Place of Birth

Customer Identification Number

National Identity Number

Additional Information

Network validation rules

23 July 2010

N EX T
Subfield 2 (Name and Address):

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).

The first line must start with number 1 (Error code(s): T56). Numbers must appear in numerical order (Error code(s): T56). Number 2 must not be used without number 3 (Error code(s): T56). Number 4 must not be used without number 5 and vice versa (Error code(s): T56).

VE RS IO N

61

Standards MT November 2010

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): T53). Numbers 3, 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 3, 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.

Usage rules

If the account number of the ordering customer is present, it must be stated in Account. Subfield 2 (Name and Address): Numbers 1 and 2 may be repeated.

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: 1. First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue. 2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.

Examples

62

N EX T
Example 1
:50F:/12345678 1/SMITH JOHN 2/299, PARK AVENUE 3/US/NEW YORK, NY 10017

Subfield 2 (Name and Address): if additional space is required for providing the Customer Identification Number (number 6) or the National Identity Number (number 7) of the ordering customer, one of the following options must be used: 1. First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue. 2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.

Example 2
:50F:/BE30001216371411 1/PHILIPS MARK 4/19720830 5/BE/BRUSSELS

Example 3

VE RS IO N

to continue information on the National Identity Number provided in subfield 2 (Name and Address) following number 7.

General Information

Field Formatting Rules

:50F:DRLC/BE/BRUSSELS/NB0949042 1/DUPONT JACQUES 2/HIGH STREET 6, APT 6C 3/BE/BRUSSELS

Example 4
:50F:NIDN/DE/121231234342 1/MANN GEORG 6/DE/ABC BANK/1234578293

Example 5
:50F:CUST/DE/ABC BANK/123456789/8-123456 1/MANN GEORG 2/LOW STREET 7 3/DE/FRANKFURT 8/7890

Field assigned to this option 50F

7.5.8

Option G: Identifier Code


/34x 4!a2!a2!c[3!c] (Account)

Format

(Identifier Code)

Definition

Identifier code of the party with mandatory account number. Network validation rules

Fields assigned to this option 50G, 52G

7.5.9

Format
/34x 4*35x (Account) (Name and Address)

Definition Name and address of the party with a mandatory account. Field assigned to this option 50H

23 July 2010

N EX T

Identifier Code must be a registered BIC (Error codes T27, T28, T29, and T45).

Option H: Name and Address

VE RS IO N

This means that the customer identification number of Mann Georg assigned by ABC Bank is 123456789/8-1234567890.

63

Standards MT November 2010

7.5.10 Option J: Party Identification with no Party Identifier


Format
5*40x (Narrative)

Definition Identification of the party. Codes The following codes can be used with this option. Depending on the field tag and message type, some codes may or may not be used, may exclude each other or not, or may be mandatory or not:

/ABIC/ /ACCT/ /NAME/ /ADD1/ /ADD2/ /CITY/ /USFW/ /USCH/ /GBSC/ /CLRC/ /NETS/ /SSIS/

4!a2!a2!c[3!c] or 4!a 34x 34x 35x 35x 35x 9!n 6!n 6!n 35x -

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.

64

N EX T
-

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.

VE RS IO N
the BIC or 'UKWN' if BIC not known account followed by the account number name followed by the name CHIPS followed by CHIPS UID CHAPS followed by CHAPS sort code Clearing Code followed by a clearing code a net settlement is taking place standard settlement instructions are used

Code

Format

Description

address followed by the first line of the address address followed by the second line of the address city followed by the name of city (and state, country) FedWire followed by FedWire Routing Number

General Information

Field Formatting Rules

7.5.11 Option K: Name and Address


Format
[/34x] 4*35x (Account) (Name and Address)

Definition Name and address of the party, with an optional account. Rules If Account is absent, then Name and Address must not start with a slash '/' (Error code: T77). Field assigned to this option 50K

7.5.12 Option L: Party Identification


Format
35x (Narrative)

Definition Identification of the party Field assigned to this option 50L

7.5.13 Option P: Party


Format
:4!c//4!a2!a2!c[3!c]

Definition

Field assigned to this option 95P

7.5.14 Option Q: Party


Format
:4!c//4*35x (Qualifier) (Name and Address)

23 July 2010

N EX T

Identification of the party, with a qualifier and an identifier code such as a BIC.

VE RS IO N
(Qualifier)(Identifier Code)
65

Standards MT November 2010

Definition Identification of the party, with a qualifier and name and address. Field assigned to this option 95Q

7.5.15 Option R: Party


Format
:4!c/8c/34x (Qualifier) (Data Source Scheme) (Proprietary Code)

Definition

Field assigned to this option 95R

7.5.16 Option S: Party


Format
:4!c/[8c]/4!c/2!a/30x

(Qualifier) (Data Source Scheme) (Type of ID) (Country code) (Alternate ID)

Definition

Identification of the party, with a qualifier, an optional issuer code, type of ID, country code and alternate ID. Field assigned to this option 95S

7.5.17 Option T: Party


Format
:4!c//2*35x

Definition Identification of the party, with a qualifier and name. Field assigned to this option 95T

7.5.18 Option U: Party


Format
:4!c//3*35x
66

N EX T
(Qualifier) (Name) (Qualifier) (Name)
General Information

VE RS IO N

Identification of the party, with a qualifier, issuer code and proprietary code.

Field Formatting Rules

Definition Identification of the party, with a qualifier and names. Field assigned to this option 95U

7.6

Times
Formats 4!n 6!n

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

7.7

Overview

23 July 2010

N EX T
MT 910

Value Date Ordering


The SWIFT system allows the receiver to request value date ordering of its value date sensitive messages. The value date sensitive messages are:

all Category 1 and Category 2 messages containing fields 30 or 32A, or both 30 and 32A, except common group messages 192, 292, 195, 295, 196 and 296 The valid range of value dates implemented on the SWIFT system for these MTs is from 1980 to 2060, and must meet the following requirements: allowed: a year component, for example, 'YY' in the range of 80 through 60, of an ISO defined six digit integer date 'YYMMDD' not allowed: any 'YY' component outside of this range, for example, 'YY' in the range of 61 through 79

VE RS IO N

Rules

67

Standards MT November 2010

Example
ACKed
:32A:601130USD1, :32A:801130USD1,

NAKed
:30:61130USD1, :30:791130USD1,

For the purpose of value date ordering, if there is more than one value date field in a message, the lesser date will be selected:
MTxxx
:30:951218 :32A:020103USD123000,00

Value date = 18th December 1995 Value Date = 3rd January 2002

In this example, field 30 Value Date (18 December 1995) is selected for value date ordering of the message. Error code 'T50' is returned after an invalid value date.

68

N EX T

VE RS IO N
General Information

Euro-Related Information (ERI)

8
8.1

Euro-Related Information (ERI)


Deletion of National Currency Denomination (NCD) Currency Codes
Background 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.

8.2

Introduction

8.2.1

Overview Euro-Related Information (ERI) refers to the following data: original currency original amount transaction charges

23 July 2010

N EX T
ERI Content

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.

Euro-Related Information (ERI)


This section discusses what is meant by Euro-Related Information (ERI).

VE RS IO N

69

Standards MT November 2010

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

8.2.2

ERI Usage Guidelines and Rules


The specification of ERI is always optional. If used, however, the rules specified in this section apply. These rules include:

Introduction

The network validated rules must be complied with, and are validated by the network. The usage rules must be complied with, although they are not validated by the network. The usage guidelines are recommendations on how to specify ERI. Network validated rules

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, 103, 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. Usage rules

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 72.

70

N EX T

The following rules must be adhered to: 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.

VE RS IO N

General Information

Euro-Related Information (ERI)

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

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.

8.2.3

ERI Structure
Field 72 Field 77A Field 79 6*35x 20*35x 35*50x

Format

Definition

Codes

N EX T
The following codes must be used /OCMT/ 3!a15d/ O

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.

23 July 2010

VE RS IO N

Where transaction charges are specified in ERI, this information must appear after the code / CHGS/. This will not necessarily be processed by the receiver.

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.

71

Standards MT November 2010

/CHGS/

3!a15d/

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. Example
:72:/OCMT/GBP2525,/ /CHGS/EUR2,40/

8.3

Message Specific Guidelines on the Use of ERI


Introduction This section lists message types which: are likely to contain ERI

contain a special field for original amount

are to be validated against a specified value date

8.3.1

Messages Likely to Contain ERI

List of message types that can contain ERI in a free text field The following lists message types that are likely to contain Euro-Related Information (ERI) in a free text field. Message types that already contain a field to specify an original currency and amount, are not included here. If there are business requirements to specify ERI in other message types, these should be similarly specified in a free text field 72, 77A or 79, as explained in "ERI Structure" on page 71. This list is therefore not exhaustive.
MT MT Name Settlement Amount Field 32A Value Date, Currency Code, Amount 32A Value Date, Currency Code, Amount 32B Currency Code, Amount Repetitive / Non Repetitive NR ERI Field 72 Repetitive/ Non Repetitive NR

N EX T
202 General Financial Institution Transfer General Financial Institution Transfer Multiple General Financial Institution Transfer 202 COV

203

72

VE RS IO N
NR 72 NR R 72 R

General Information

Euro-Related Information (ERI)

MT

MT Name

Settlement Amount Field 32B Currency Code, Amount 32A Value Date, Currency Code, Amount 32A Value Date, Currency Code, Amount 32B Currency Code, Amount

Repetitive / Non Repetitive R

ERI Field 72

Repetitive/ Non Repetitive R

204

Financial Markets Direct Debit Message Financial Institution Transfer Execution Financial Institution Transfer Execution Request for Financial Institution Transfer Advice of Payment Clean Collection

205

NR

72

NR

205 COV

NR

72

NR

207

72

NR

400 405

450

Cash Letter Credit Advice Cash Letter Credit Adjustment Advice Advice of Dishonour

455

N EX T

456 559

Paying Agent's Claim Collateral Adjustment Message

581

582 752

Reimbursement Claim or Advice Authorisation to Pay, Accept or Negotiate Advice of Payment/ Acceptance/ Negotiation Advice of Reimbursement or Payment

754

756

23 July 2010

VE RS IO N
33A Proceeds Remitted NR NR 72 NR 32a Proceeds to be Remitted in seq C 72, seq A 72, seq B 72 NR NR 32a Proceeds to be Remitted in subseq B3 32A Value Date, Currency Code, Amount N(1) R NR 33a Value Date and Adjustment Amount R 72 NR 33D Total Amount Debited 34A Net Proceeds 34B Outstanding Collateral Value 34A Net Amount Claimed/Paid 33a Net Amount R NR NR 72 72 72 NR NR NR NR NR 79 72 NR NR 34a Total Amount Claimed NR 72 NR 33A Amount Reimbursed or Paid NR 72 NR
73

Standards MT November 2010

MT

MT Name

Settlement Amount Field 32a Amount of Charges

Repetitive / Non Repetitive NR

ERI Field 72

Repetitive/ Non Repetitive NR

768

Acknow ledgement of a Guarantee Message Advice of Reduction or Release Confirmation of Debit Confirmation of Credit Customer Statement Message Interim Transaction Report

769

32a Amount of Charges 32A Value Date, Currency Code, Amount 32A Value Date, Currency Code, Amount

NR

72

NR

900

NR

72

NR

910

NR

72

NR

940

942

(1) Subsequence B3 is non-repetitive within the repetitive sequence B.

8.3.2

Messages Containing a Special Field for Original Amount

List of message types containing a special field for original amount

N EX T

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

101 102

Request for Transfer

32B

102+ 103 103+ 103 REMIT 104

Multiple 32B Customer Credit Transfer Single 32A Customer Credit Transfer

Direct Debit and Request for Debit Transfer

32B

107

General Direct 32B Debit Message

74

VE RS IO N
subfield 5 of field 61 R 61/9 or 86 61/9 or 86 R subfield 5 of field 61 R R 33B 33B NR 33B NR R 33B R R 33B R

General Information

Euro-Related Information (ERI)

MT

MT Name

Settlement Amount Field 19A::SETT 19A::SETT

Repetitive/ Non Repetitive NR NR

ERI Field

Repetitive/ Non Repetitive NR NR

513 514

Client Advice of Execution Trade Allocation Instruction Client Confirmation of Purchase or Sale Market-Side Securities Trade Confirmation ETC ClientSide Settlement Instruction ETC MarketSide Settlement Instruction Receive Against Payment Deliver Against Payment Receive Against Payment Confirmation Deliver Against Payment Confirmation Corporate Action Notification

19A::OCMT 19A::OCMT

515

19A::SETT

NR

19A::OCMT

NR

518

19A::SETT

NR

19A::OCMT

NR

528

19A::SETT

529

19A::SETT

541

19A::SETT

543

19A::SETT

N EX T

545

19A::ESTT

547

19A::ESTT

564

19A::ESTT

566

Corporate Action Confirmation Statement of ETC Pending Trades

19A::ESTT

584

19A::ESTT

8.3.3

Messages with Value Date Validation


The following table contains messages that can be used to transfer amounts in National Currency Denominations (NCDs).

List of message types used to transfer amounts in National Currency Denominations

23 July 2010

VE RS IO N
NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR NR 19A::OCMT NR
75

Standards MT November 2010

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 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, 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 101 102 102+ 103 CORE 103+ MT Name NCD Amount Field 32B in Seq B (each occurrence) 32A in Seq C 32A in Seq C 32A 32A 32A 32B (each occurrence) 32B (each occurrence) 32B in Seq C 32A 32B (each occurrence 32A 32A 32B (each occurrence) 32B (each occurrence) 32A 32A Value Date Field

Request for Transfer Multiple Customer Credit Transfer Single Customer Credit Transfer

N EX T
103 REMIT 104 104RFDD 107 200 201 202 202 COV 203 204 205 205 COV Direct Debit and Request for Debit Transfer Message General Direct Debit Message FI Transfer for its Own Account Multiple FI Transfer for its Own Account General FI Transfer General FI Transfer Multiple General FI Transfer Financial Markets Direct Debit Message FI Transfer Execution FI Transfer Execution
76

VE RS IO N
30 in Seq A 32A in Seq C 32A in Seq C 32A 32A 32A 30 in Seq A 30 in Seq A 30 in Seq A 32A 30 32A 32A 30 30 32A 32A

General Information

Euro-Related Information (ERI)

MT 207 210 400 405

MT Name Request for FI Transfer Message Notice to Receive Advice of Payment Clean Collection

NCD Amount Field 32B (each occurrence 32B (each occurrence) 33A 32C in Subseq. B3 (each occurrence) 32D in Seq C

Value Date Field 30 in Seq A 30 33A 32C 32D 32A 32A 33C 33D

450 455

Cash Letter Credit Advice Cash Letter Credit Adjustment Advice

32A (each occurrence) 32A 33C 33D

456 513

Advice of Dishonour Client Advice of Execution

514

Trade Allocation Instruction

N EX T
515 Client Confirmation of Purchase or Sale 518 Market-Side Securities Trade Confirmation 528 ETC Client-Side Settlement Instruction
23 July 2010

VE RS IO N
32D (each occurrence) Seq C Order Details Field 19A Qualifier SETT 33D Seq D3 Amounts Field 19A Qualifier SETT Seq B Confirmation Details Field 19A Qualifier SETT Seq C3 Amounts Field 19A Qualifier SETT Seq C Confirmation Details Field 19A Qualifier SETT Seq D3 Amounts Field 19A Qualifier SETT Seq B Confirmation Details Field 19A Qualifier SETT Seq C3 Amounts Field 19A Qualifier SETT Seq B Confirmation Details Field 19A Qualifier SETT Seq B Confirmation Details Field 19A Qualifier SEBL Seq C3 Amounts Field 19A Qualifier SETT

Seq C Order Details Field 98a Qualifier SETT (1) Seq C Order Details Field 98a Qualifier SETT (1) Seq B Confirmation Details Field 98a Qualifier SETT (1) Seq B Confirmation Details Field 98a Qualifier SETT (1) Seq C Confirmation Details Field 98a Qualifier SETT Seq C Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT

77

Standards MT November 2010

MT 529

MT Name ETC Market-Side Settlement Instruction

NCD Amount Field Seq B Confirmation Details Field 19A Qualifier SETT Seq C3 Amounts Field 19A Qualifier SETT

Value Date Field Seq B Confirmation Details Field 98a Qualifier SETT Seq B Confirmation Details Field 98a Qualifier SETT Seq B Trade Details Field 98a Qualifier SETT Seq B Trade Details Field 98a Qualifier SETT Seq B Trade Details Field 98a Qualifier SETT (1) Seq B Trade Details Field 98a Qualifier SETT (1) Seq E2 Cash Movement Field 98a Qualifier PAYD(2) Seq E2 Cash Movements Field 98a Qualifier VALU(3) Seq D2 Cash Movement Field 98a Qualifier POST Seq B2b Trade Details Field 98a Qualifier SETT (1) Seq B2b Trade Details Field 98a Qualifier SETT (1) Seq C1c Trade Details Field 98a Qualifier SETT (1) Seq C1c Trade Details Field 98a Qualifier SETT (1) 32D 33A 34A 33A 34A

541

Receive Against Payment Deliver Against Payment Receive Against Payment Confirmation Deliver Against Payment Confirmation Corporate Action Notification

Seq E3 Amounts Field 19A Qualifier SETT Seq E3 Amounts Field 19A Qualifier SETT Seq E3 Amounts Field 19A Qualifier ESTT Seq E3 Amounts Field 19A Qualifier ESTT Seq E2 Cash Movement Field 19B Qualifier ENTL

543

545

547

564

564

Corporate Action Notification

566

Corporate Action Confirmation

N EX T
730 734 742 752 754 Acknowledgement Advice of Refusal Reimbursement Claim Authorisation to Pay, Accept or Negotiate Advice of Payment/ Acceptance/ Negotiation
78

584

Statement of ETC Pending Trades

VE RS IO N
Seq E2 Cash Movements Field 19B Qualifier ENTL (each occurrence) Seq D2 Cash Movement Field 19B Qualifier PSTA Seq B2b Trade Details Field 19A Qualifier SETT (each occurrence) Seq B2b2 Amounts Field 19A Qualifier SETT Seq C1c Trade Details Field 19A Qualifier SETT Seq C1c2 Amounts Field 19A Qualifier 32D 33A 34A 33A 34A

General Information

Euro-Related Information (ERI)

MT 756

MT Name Advice of Reimbursement or Payment Acknowledgement of a Guarantee Message Advice of Reduction or Release T/C Sales and Settlement Advice [Single] T/C Settlement Advice Confirmation of Debit Confirmation of Credit

NCD Amount Field 33A

Value Date Field 33A

768 769 800

32D 32D 32A in Seq B

32D 32D 32A in Seq B

802 900 910

32A 32A 32A

32A 32A 32A

(1) If the settlement date in the optional field is not specified, the message will be accepted.

(2) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if : 98B:: is used, the validation is not performed) (3) If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if : 98B:: is used, the validation is not performed)

8.4

ERI Validation and Examples


Introduction

This section details the validation of the ERI information and provides examples that give correct and incorrect messages.

8.4.1

Rules

23 July 2010

N EX T
Codes and format: /OCMT/3!a15d/ /CHGS/3!a15d/ Where:

General ERI Validation Rules

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 51. If not properly formatted, the system will NAK the message with Error Code 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.

VE RS IO N

79

Standards MT November 2010

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 character, '/' (Error Code T31). In the following example the amount component is invalid. The message is NAKed:
:86:/OCMT/EUR1,23(CrLf)

8.4.2
Rules

Messages and Fields Impacted


The ERI validation will be performed in fields:

72 Structured Format, 72 ISITC Structured Format, 72 Narrative, 77A and/or 79, of all messages except the MTs 104, n92, n95, n96 and n99 61 (subfield 9) and 86, of the MTs 940 and 942

8.4.3
Rules

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.

80

N EX T
The messages are not NAKed: OCMT is validated OCMT and CHGS are validated

Examples

:79:xxxxx/OCMT/EUR10,25/xxxxx(CrLf)

:79:xxxxx/OCMT/EUR10,25/(CrLf) /CHGS/EUR1,/(CrLf)

No ERI Validation Hierarchy between the Fields


Note that if the same field specification is reused in the message, the ERI validation will be performed. This is usually the case where a field is defined in a loop, that is, a repetitive block of fields or sequence.

VE RS IO N

General Information

Euro-Related Information (ERI)

8.4.4
Rule

/CHGS/ is only Validated if /OCMT/ is Present


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)

Rule

Within a field, the sequence of the codes /OCMT/ and /CHGS/ is relevant.

It is only if /OCMT/ appears immediately before /CHGS/ that the ERI validation will be applied to /CHGS/. Example 1 - structured field 72

CHGS is validated. The message is not NAKed:


:72:/INS/BANKCCCY/OCMT/EUR12345,/(CrLf) /CHGS/EUR20,/xxxxx(CrLf)

Example 2 - free format field 79

OCMT is validated. The message is not NAKed:

Example 3 - free format field 72

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)

23 July 2010

N EX T
:72:xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR1000,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) /CHGS/EUR5,/(CR) //xxxxxxxxxx(CrLf)

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

Only OCMT is validated because CHGS does not follow immediately OCMT. The message is not NAKed:

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.

VE RS IO N

8.4.5

Sequence of Codes is Required

81

Standards MT November 2010

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)

8.4.6
Rule

Double Codes are not Allowed in one Field


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 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)

Example 2 - field 61

Example 3 - free format field 79

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,/(CR) //xxxxxxxxxx(CrLf)

82

N EX T
Note

OCMT is found twice. The message is NAKed:


:61:9809010931C3500,25FCHK304955//4958843(CrLf) /OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf)

OCMT is found twice. The message is NAKed:


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

Note that if /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the ERI and thus not be subject to the ERI validation.
General Information

VE RS IO N

Euro-Related Information (ERI)

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,/(CR) //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)

8.4.7
Rule

Consistent with Current Standards


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 '//'.

8.4.8
Rule

Maximum Use of the Generic Format Definition

Examples

23 July 2010

N EX T
:77A:xxxxx/OC(CrLf) MT/EUR100,/(CrLf)

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.

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:

VE RS IO N

83

Standards MT November 2010

8.4.9
Rules

No ERI Validation
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) MTs 96n (only used for bilateral key exchange)

8.4.10 Details of the ERI Validation Implementation


8.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 validate according to the format 34x: If the check here above is OK, then go to point 2.

Otherwise the message is NAKed with the corresponding error code.

84

N EX T
If /OCMT/ is: If format is: valid, then go to point 3 3. If /CHGS/ is:

2.

Scan for /OCMT/

not present, then perform next field validation present more than once, then NAK the message with the error code T47 and terminate the validation present only once, then validate the format <3!a15d/>

invalid, then NAK the message with the corresponding error code and terminate the validation Check for /CHGS/ immediately after /OCMT/3!a15d/.

not present, then perform next field validation present more than once, then NAK the message with the error code T47 and terminate the validation present only once, then validate the format <3!a15d/>
General Information

VE RS IO N

Euro-Related Information (ERI)

If format is: valid, then go to next field validation invalid, then NAK the message with the corresponding error code and terminate the validation

8.4.10.2 Field 72 (Structured Format)


Format <INSTR> first line [(CrLf)(INSTR> or '//' 33x)] optionally, 2nd through 6th line where <INSTR> is defined as:

/<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

23 July 2010

N EX T
1. 2. 3. second through sixth line 4. 5. 6. scans for /OCMT/ If /OCMT/ is:

The system performs the following validation:

maximum 6 lines, maximum 35 characters per line (<X> character set) first line as <INSTR>, per the format defined here above

If present, defined as : <INSTR> or <'//' 33x>: if the 3 checks here above are OK, then go to point 4 otherwise the message is NAKed, with the corresponding error code

throughout the field content, removes all (CrLf'//'), if any throughout the field content, removes all (CrLf), if any

not present, then perform 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/>
85

VE RS IO N

/<1!a>/[32x] or

Standards MT November 2010

If format is: valid, then go 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/>

valid, then go to next field validation

invalid, then NAK the message with the corresponding error code and terminates the validation

8.4.10.3 Field 72 (Narrative)


Format 35x[(CrLf)35x] 0-5. Validation

The system performs the following validation:

86

N EX T
2. If present, defined as 35x: 3. 4. scans for /OCMT/ If /OCMT/ is:

1.

maximum 6 lines, maximum 35 characters per line (<X> character set) second through sixth line, if present, defined as 35x

if the 2 checks are OK, then go to point 3 otherwise the message is NAKed with the corresponding error code

throughout the field content, removes all (CrLf), if any

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/>

VE RS IO N

If format is:

General Information

Euro-Related Information (ERI)

If format is: valid, then go 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/>

valid, then go to next field validation

invalid, then NAK the message with the corresponding error code and terminates the validation

8.4.10.4 Field 77A (Narrative)


Format 35x[(CrLf)35x] 0-19 Validation

The system performs the following validation:

23 July 2010

N EX T
2. second through 20th line If present, defined as 35x: 3. 4. scans for /OCMT/ If /OCMT/ is:

1.

maximum 20 lines, maximum 35 characters per line (<X> character set)

if the 2 checks here above are OK, then go to point 3 otherwise the message is NAKed with the corresponding error code

throughout the field content, removes all (CrLf), if any

not present, then perform 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 validate the format <3!a15d/>

VE RS IO N

If format is:

87

Standards MT November 2010

If format <3!a15d/> is: valid, then go 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 perform next field validation present more than once, then NAK the message with the error code T47 and terminate the validation present only once, then validate the format <3!a15d/>

valid, then go to next field validation

invalid, then NAK the message with the corresponding error code and terminate the validation

8.4.10.5 Field 79 (Narrative)


Format 50x [(CrLf)50x] 0-34 Validation

The system performs the following validation:

88

N EX T
2. second through 35th line If present, defined as 50x: 3. 4. scans for /OCMT/ If /OCMT/ is:

1.

maximum 35 lines, maximum 50 characters per line (<X> character set)

if the 2 checks (point 1) are OK, then go to point 3 otherwise the message is NAKed with the corresponding error code

throughout the field content, removes all (CrLf), if any

not present, then perform 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 validate the format <3!a15d/>

VE RS IO N

If format is:

General Information

Euro-Related Information (ERI)

If format is: valid, then go 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 perform 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/>

valid, then go to next field validation

invalid, then NAK the message with the corresponding error code and terminates the validation

8.4.10.6 Field 86 (Narrative)


Format 65x [(CrLf)65x] 0-5 Validation

The system performs the following validation:

23 July 2010

N EX T
2. second through sixth line If present, defined as 65x: 3. 4. scans for /OCMT/ If /OCMT/ is:

1.

maximum 6 lines, maximum 65 characters per line (<X> character set)

if the 2 checks (point 1) are OK, then go to point 3 otherwise the message is NAKed, with the corresponding error code

throughout the field content, removes all (CrLf), if any

not present, then perform 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 validate the format <3!a15d/>

VE RS IO N

If format is:

89

Standards MT November 2010

If format is: valid, then go 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 perform next field validation present more than once (double), then NAK the message with the error code T47 and terminate the validation present only once, then validates the format <3!a15d/>

valid, then go to next field validation

invalid, then NAK the message with the corresponding error code and terminates the validation

90

N EX T

VE RS IO N

If format is:

General Information

Legal Notices

Legal Notices
Copyright SWIFT 2010. All rights reserved. You may copy this publication within your organisation. Any such copy must include these legal notices. Confidentiality This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT. Disclaimer The information in this publication may change from time to time. You must always refer to the latest available version on www.swift.com. 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 > Solutions > Standards > More information. Translations

The English version of SWIFT documentation is the only official version. Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners.

23 July 2010

N EX T

VE RS IO N

91

Verwandte Interessen