General Mt SWIFT

NEXT VERSI

ON

NEXT VERSI

ON

Standards MT November 2010

General InformationThis 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 Standardsdocumentation and the benefits of message standards. This document also provides a description of the ISO BusinessIdentifier Code. This document is for all SWIFT customers (this includes operators and application developers), vendors,and service bureaux.

23 July 2010

Standards

NEXT VERSI

ON

NEXT VERSI

ON

Table of Contents

.Preface .............................................................................................................................................................................4

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

1.1 Volume/Chapter Explanation ................................................................................................................... 5

1.2 Standards MT Volumes ............................................................................................................................ 6

1.3 Formatting Explanation .......................................................................................................................... 10

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

2.1 Reason for Standards MT ...................................................................................................................... 15

2.2 Standards Development and Implementation Process ..................................................................... 15

2.3 Standards Maintenance Process .......................................................................................................... 15

2.4 Message Envelope Structure ................................................................................................................ 16

2.5 Message Validation Description ........................................................................................................... 17

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

3.1 Introduction ............................................................................................................................................... 18

3.2 Business Identifier Code Structure ....................................................................................................... 18

3.3 Using BICs in SWIFT Messages .......................................................................................................... 19

3.4 Standards for SWIFT BICs and non-SWIFT BICs ............................................................................. 19

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

4.1 SWIFT Message Structure .................................................................................................................... 23

4.2 SWIFT Message Types .......................................................................................................................... 23

4.3 Message Length and Structure ............................................................................................................. 44

4.4 Message Structure Example ................................................................................................................. 45

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

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

6 Characters ........................................................................................................................................................ 49

6.1 SWIFT Character Set (X Character Set) ............................................................................................. 49

6.2 EDIFACT Level A Character Set (Y Character Set) .......................................................................... 49

6.3 Information Service Character Set (Z Character Set) ....................................................................... 49

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

7.1 General Rules .......................................................................................................................................... 50

7.2 Dates ......................................................................................................................................................... 50

7.3 Numbers ................................................................................................................................................... 51

7.4 Currency Codes ....................................................................................................................................... 52

7.5 Party Identification ................................................................................................................................... 52

7.6 Times ......................................................................................................................................................... 67

7.7 Value Date Ordering ............................................................................................................................... 67


2 General Information

NEXT VERSI

ON

NEXT VERSI

ON

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

8.1 Deletion of National Currency Denomination (NCD) Currency Codes ........................................... 69

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

8.3 Message Specific Guidelines on the Use of ERI ............................................................................... 72

8.4 ERI Validation and Examples ................................................................................................................ 79

.Legal Notices ...............................................................................................................................................................91

Table of Contents

23 July 2010 3

NEXT VERSI

ON

NEXT VERSI

ON

PrefaceSignificant changes

The following tables list all significant changes to the content of the MT General Informationsince the 24 July 2009 edition. These tables do not include editorial changes that SWIFT makesto improve the usability and comprehension of the document.

New information Location

Addition of field 70G of MT 564 6.3, "Information Service Character Set (ZCharacter Set)" on page 49

Addition of a new section for option no letter 7.5.2, "Option No Letter: Name and Address" onpage 54

Addition of a new rule section for option D 7.5.6, "Option D: Name and Address" on page 56

Addition of a new section for option F 7.5.7, "Option F: Party Identifier / Name andAddress" on page 60

Addition of a new section for option G 7.5.8, "Option G: Identifier Code" on page 63

Addition of a new rule section for option K 7.5.11, "Option K: Name and Address" onpage 65

Introduction of the Euro in Estonia 8.1, "Deletion of National Currency Denomination(NCD) Currency Codes" on page 69

8.3.3, "Messages with Value Date Validation" onpage 75

Updated information Location

BIC/BEI change. BIC now stands for businessidentifier code. The concept of BEI (business entityidentifier) has been removed. Financial institutionBIC replaces the former BIC concept. Non-financialinstitution BIC replaces the former BEI concept.

Changes apply throughout the document

Allow the "metals messages" to be used for non-metals, that is change the names and scopes ofthe suite of messages to "commodities" rather than"metals". This also means changing the names offields that contain "metal" to "commodity" andrevising the definitions accordingly.

1.1, "Volume/Chapter Explanation" on page 5

1.2.3, "Category Volumes: Message TextStandards" on page 8

4.2, "SWIFT Message Types " on page 23

Update format of code /NAME/ for option J Partyidentification with no Party Identifier

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

Deleted information Location

Deletion of references to BEI Changes apply throughout the document

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

4.2, "SWIFT Message Types " on page 23

8.3.3, "Messages with Value Date Validation" onpage 75

Warning This volume contains information effective as of the November 2010 StandardsRelease. Therefore the 24 July 2009 edition of the User Handbook Standards MTvolumes remains effective until November 2010.



NEXT VERSI

ON

NEXT VERSI

ON

1 Standards MT Volumes Description

1.1 Volume/Chapter ExplanationStandards MT volumes

All SWIFT messages exchanged between users must accord with the message text standardsdescribed in the Standards MT volumes. To achieve this, it may be necessary for some users tomake changes to their policies and procedures to bring their communications in line with thoseof the SWIFT community.

The Standards MT volumes describe the message text standards which have been developedby 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

This volume consists of 2 books:

– Commodities

– Syndications

• Category 7 - Documentary Credits and Guarantees

• Category 8 - Travellers Cheques

• Category 9 - Cash Management and Customer Status

• Category n - Common Group Messages

Additional Standards MT volumes

To assist users, usage guidelines have been published in three additional Standards MTvolumes for specific categories of messages. These volumes contain guidelines for usingmessage 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

Standards MT Volumes Description

23 July 2010 5

NEXT VERSI

ON

NEXT VERSI

ON

Additional volumes are issued separately for:

• advance information, published as the Standards Release Guide

• supplementary information, as appropriate

1.2 Standards MT Volumes

1.2.1 Standards MT General Information Volume

Overview

The Standards MT General Information volume contains information which is pertinent to allcategories of messages. It includes, for example, an explanation of how the information isorganised, the benefits of using message standards and the description of the BusinessIdentifier Code.

Chapters description

Chapter Description

1 - "Standards MTVolumes Description"

This chapter contains:

• a description of the information which is contained in eachvolume of the Standards MT volume set

• an explanation of the presentation of field definitions,category information and message type formats

2 - "Introduction toStandards MT"


• a description of the reasons message standards areneeded, including the benefits realised through theirproper use

• information about the method used by SWIFT to updatecurrent standards, and to develop new ones, in order toensure compatibility with current financial practices

• a list of the standard development organisations SWIFTconsults with when developing message text formats anddefinitions

• a brief description of the format checking performed by theSWIFT system on outgoing SWIFT messages

3 - "Business IdentifierCode (BIC)"


• a description of the purpose and development of theBusiness Identifier Code

• information regarding the nature and format of thecomponents of the Business Identifier Code (BIC)

• an explanation on the use of non-SWIFT (not connected)BICs and SWIFT (connected) BICs



NEXT VERSI

ON

NEXT VERSI

ON

Chapter Description

4 - "Message Structureand Message Types"


• definitions and illustrations of the structure of a message

• a description of the purpose of the category designationwithin the Message Type (MT) number and how thecategory may be used to aid the internal routing ofmessages

• a list of all SWIFT message types

5 - "Field Structure" This chapter contains:

• a definition and illustration of the structure and generalformat 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 numberline and format options)

6 "Characters" This chapter lists the allowable characters in the X-, Y-, andZ-character sets.

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

• Dates

• Numbers

• Currency Codes

• Party Identification

• Times

• Value Date Ordering

8 - "Euro-RelatedInformation (ERI) "

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

1.2.2 Standards MT General Field Definitions Plus Volume

Overview

This online publication is available only on the User Handbook Online. It allows you to searchfor specific pieces of information, easily and quickly as information is sorted by MT or by fieldtag.

The Standards MT General Field Definitions plus provides a general description of all message-text fields. It also provides information about the FIN error codes.

Information which applies to fields in a specific message, for example, field usage and codes, isfound in the description of the message type within the Standards category message referenceguides.


23 July 2010 7

NEXT VERSI

ON

NEXT VERSI

ON

Description

The Standards MT General Field Definitions plus contains a description of each field tag,including:

• format options

• definition

• network validated rules

• usage rules

• relevant message types

• codes

1.2.3 Category Volumes: Message Text Standards

Overview

Message text standards for individual messages within each category are contained in thecategory volumes:

• Category 1 - Customer Payments and Cheques

• Category 2 - Financial Institution Transfers

• Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives

• Category 4 - Collection and Cash Letters

• Category 5 - Securities Markets

• Category 6 - Treasury Markets - Commodities

• Category 6 - Treasury Markets - Syndications

• Category 7 - Documentary Credits and Guarantees

• Category 8 - Travellers Cheques

• Category 9 - Cash Management and Customer Status

• Category n - Common Group Messages

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

Section Description

Introduction This section contains a description of the function anduse of the message category. It also indicates whathas changed in the book since its previous publication,and explains how the book, and each message type, isstructured.

Category Message Types This section lists and briefly describes the messagetypes defined within the category. It also indicates:

• whether the message type requires authentication

• the maximum length allowed



NEXT VERSI

ON

NEXT VERSI

ON

Section Description

• whether the use of the message type requiresregistration with SWIFT in a Message User Group

• information about how to register for a MessageUser Group

Message Type Description This section contains detailed descriptions of eachmessage type within the category.

Including:

• MT Scope

• MT Format Specifications

• MT Network Validated Rules

• MT Usage Rules

• MT Guidelines

• MT Field Specifications

• MT Mapping

• MT Examples

• additional information about the MT as required

Glossary of Terms Terms and definitions that are used throughout thecategory.

1.2.4 Additional Volumes

Overview

Three additional volumes contain recommendations for using messages in specific businesssituations. They also provide special information about more than one message type, or acrossmore than one category of message type. These usage guidelines are recommendations andare provided for information. They do not form part of the SWIFT message text standards.

Volume Description

Standards MT Usage Guidelines This volume recommends the use of messages forspecific business situations.

Standards - Category 1 Customer -Payments and Cheques - MessageUsage Guidelines

This volume contains information for using Category1 message types. Currently this volume contains theMT 104 Country Section.

Standards - Category 5 - SecuritiesMarkets - Message UsageGuidelines

This volume contains additional information for usingthe Category 5 message types. It explains how theISO 15022 messages relate to each other, and theparties involved. It also includes a general outline ofthe structure of each new message.


23 July 2010 9

NEXT VERSI

ON

NEXT VERSI

ON

1.3 Formatting Explanation

1.3.1 Field Definition Format

Overview

The Standards MT General Field Definitions plus contains the following information per field.

Name Description

Definition A description of the field. Additional information whichapplies to a specific category, or message type, willappear in the field specifications for that message type.

Format Options The specification of available options, or alternativeformatting possibilities, for the field.

The format options include restrictions on length andtypes of characters allowed.

Usage Rules Additional information pertaining to use of the field.

Network Validated Rules Any restrictions on use, for example, a double slash '//'is not permitted within field 20.

Message Type Use A matrix showing the message types which use thespecified field.

Codes A matrix showing the message types which use thespecified code.

1.3.2 Message Type Descriptions

Introduction

The ten category volumes contain general information for the category and the detaileddescription of each message type. For each message type, the following information isprovided.

Note For the ISO 15022 securities messages in Category 5, the format specification andfield specifications are presented in a slightly different way. For further explanationssee Category 5 - Securities Markets - Message Usage Guidelines.

Example of an information flow

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



NEXT VERSI

ON

NEXT VERSI

OND

0200

001

Sender orReceiver

Other parties involvedin the transaction

Financialinstitution

Bank Corporate

Originator of thetransaction

The actual SWIFTMessage

Another SWIFT messageinvolved in the transaction

Financial institution orcustomer relationship

Final recipient

MT nnn

Customer

Legend

MT nnn

MT

Financialinstitution

Bank Corporate

Customer

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

Message type scope

The scope specifies the sender and receiver of the message and provides an explanation onhow the message is used. In some messages, an example of the message flow is alsoprovided.

Message type format specifications

The format specifications are the rules for the layout of the message type. This information isprovided in table form as shown below:


23 July 2010 11

NEXT VERSI

ON

NEXT VERSI

ON

MT nnn (Message Type name)

Status Tag Field Name Content/Options No.

M 20 Transaction Reference Number 16x 1

M 21 Related Reference 16x 2

Mandatory Sequence A (Sequence Name)

M 25 Account Identification 35x 3

M 32A Value Date, Currency Code,Amount

6!n3!a15d 4

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

O 52a Ordering Institution A or D 5

M 71B Detail of Charges 6*35x 6

O 72 Sender to Receiver Information 6*35x 7

----|

M = Mandatory O = Optional

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.

• Tag is the field identification.

• Field Name is the detailed name of the field tag, for this message type.

• Content/Options provides permitted field length and characteristics.

• No. identifies the number of the field in the Field Specifications for the message type. It isalso called Index.

Only fields and field tag options, which are shown in the message format, may be used in thatmessage type.

Some of the fields in the format have names different from those in Standards MT General FieldDefinitions plus. The name in the Message Type Format overrides that given in the StandardsMT General Field Definitions plus.

Some message formats are separated into sequences of fields, as shown below. An arrowindicates that a sequence of fields may be repeated.


First sequence

1

2

---->



NEXT VERSI

ON

NEXT VERSI

ON


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 errorcode. 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 arenevertheless mandatory for the correct usage of the message. Rules specified in this sectionaffect more than one field in the message, or more than one SWIFT message.

MT market practice rules

Market practice rules specify the rules published by a recognised Market Practice Group, forexample, for category 5, the Securities Market Practice Group (SMPG). It informs the reader ofthe existence of a global market practice document on the business process in which theconcerned field or message type is used. The absence of a market practice rule notation doesnot mean that no market practices exist for the concerned field or message type. The presenceof a market practice rule is merely an indicator of a known market practice. Furthermore,readers should be aware that in addition to global market practices there may also be country-specific requirements that should be considered when using the field or message type.

MT guidelines

Guidelines are not validated on the network and are not mandatory for the correct usage of themessage. They concern good practices. Guidelines specified in this section affect more thanone field in the message, or more than one SWIFT message.

MT field specifications

The rules for the use of each field in the message are specified in this section. Each field isidentified by its index number (as shown in the No. column of the MT format specifications), fieldtag 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

NEXT VERSI

ON

NEXT VERSI

ON

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 forwhich 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 onlythe field in which they appear. In some cases, rules which are validated at the messagelevel, that is, rules which affect more than one field, are repeated in this section. This is thecase when the rule does not affect the presence of the field, but information within severalfields, for example, a currency which must be the same for more than one field in themessage.

f. USAGE RULES specifies rules that are not validated on the network, that is, rules for whichno 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

• information flow, which illustrates the relationships between the parties involved in themessage (see below diagram)

• SWIFT format, which provides the message using the defined SWIFT format, and providingan explanation, where necessary, of the fields which have been used

The sender, receiver and message type are summarily identified. Trailer contents are notshown.

Note For further information about the header and trailer, see the FIN ServiceDescription.



NEXT VERSI

ON

NEXT VERSI

ON

2 Introduction to Standards MT

2.1 Reason for Standards MTWhy Standards MT?

The message text standards have been developed to support the business transactions ofSWIFT users. To ensure that the multitude of practices and conventions of users are inharmony, financial messages transmitted via the SWIFT network must adhere to the messagetext standards.

Standards enable financial institutions to move from manual to automated initiation andprocessing of financial transactions.

Key benefits

There are important benefits which result from standardisation of messages. These include:

• automation

• reduced risk of errors and misunderstandings

• reduced operating costs

• improved productivity

• increased efficiency in processing of messages (routing and preparation)

• faster and more cost effective account reconciliation

• the ability to maintain more comprehensive management information

2.2 Standards Development and ImplementationProcess

Board Paper 828 (R)

For details about the standards development and implementation process, please refer toBP828 (R) - Standards development and implementation process, rev.3, approved by theSWIFT Board of Directors in 2007.

This paper is available upon request from National User Group Chairpersons or from the SWIFTStandards Department.

2.3 Standards Maintenance ProcessIntroduction

Maintenance projects aim at maintaining the functionality of existing standards. They are carriedout 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

Introduction to Standards MT

23 July 2010 15

NEXT VERSI

ON

NEXT VERSI

ON

Note Individual users and members may only submit maintenance requests to their UserGroup 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 subjectmaintenance release, based on the change requests received. These changes must still bevalidated by a Working Group and some of them may be reworded, redefined or evenremoved.

2. Eleven months prior to implementation (SR-11), SWIFT publishes a revised, high-leveldocument (for budget and resource allocation), which shows only those change requeststhat 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) providesdetails of the changes published in the revised, high-level document.

4. Five months prior to implementation (SR-5), the User Handbook is available onwww.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 Standardsdepartment analyses all received change requests. They send the outcome of this analysis to aMaintenance Working Group (MWG) for discussion and approval.

MWGs include experts in the business domain and, ideally, in the standards to be maintained.Members are country representatives appointed by their respective User Group Chairperson.

The message text formats are developed in line, or in consultation, with various bodies:

1. MWGs review and agree on the validity of the change requests.

2. Country vote takes place on MWG-agreed changes.

3. The Board Standards Committee must approve the country-vote results before the changesare considered final and published in the final-SRG.

For more details on any of the processes described in this section, please visit Standards onwww.swift.com, or contact the Support team.

2.4 Message Envelope StructureOverview

All messages (financial and system) conform to a defined structure, generally including aheader, a message text and a trailer.

Note For further details about the message structure, see the FIN Service Description.



https://www2.swift.com/uhbonline/books/home/index.htm

http://www.swift.com/

NEXT VERSI

ON

NEXT VERSI

ON

2.5 Message Validation DescriptionRule

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 anegative acknowledgement (NAK). The NAK will display a text error. Where possible, it will alsogive the location of the text error by indicating the number of the line on which the erroroccurred.

Exceptions

Exceptions to this rule, which may be based on either system constraints or on the logical layoutof the message or field, include:

• An error code and line number which relates to a network validated rule violation. In thesesituations the system may give the line number of the last text line of the message, or if theerror occurred within a repetitive sequence, the line number relative to either the beginning orend 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 validationby the SWIFT system.

Message text validation

Validation of message text includes checking the following:

• the correct sequence of fields

• the presence of mandatory fields, that is, those required in the message type being sent

• the presence of only those permitted optional fields for the message type

• correct content, for example, numbers or letters and length for each field/subfield; in somecases, codes are validated

• the permitted character set

• the presence of the decimal comma in numbers and amounts

• that in amounts, the correct number of digits appears after the decimal comma for thecurrency 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 theSWIFT system

• codes, where an error code is specified in the Field Specifications of the message description

Introduction to Standards MT

23 July 2010 17

NEXT VERSI

ON

NEXT VERSI

ON

3 Business Identifier Code (BIC)

3.1 IntroductionOverview

In the financial environment, a number of telecommunication services have defined codingschemes for identifying financial institutions as well as corporate entities. As a result, manyfinancial institutions and some corporates have more than one code assigned, while othershave no codes assigned.

To ensure the availability of a unique identifier, an International Standard - ISO 9362 - has beenestablished. This standard specifies a universal method for identifying financial institutions andis intended to facilitate automated processing of telecommunication messages.

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

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

When a BIC is available (for example, the party to be specified has been assigned a BIC), itshould be used whenever possible, as it is standardised and can therefore be automaticallyprocessed by the receiver.

Both financial institutions and non-financial institutions can be identified with a BIC.

3.2 Business Identifier Code Structure

3.2.1 Components of a Business Identifier Code

Description

The Business Identifier Code (BIC) consists of eight or eleven characters, comprised of the firstthree, or all four of the following components:

INSTITUTION CODE 4!a

COUNTRY CODE 2!a

LOCATION CODE 2!c

BRANCH CODE [3!c]

3.2.2 SWIFT and non-SWIFT BICs

Description

Business Identifier Codes (BICs) must be registered codes, either connected (referred to as aSWIFT BIC) or not connected (referred to as a non-SWIFT BIC).

For financial institutions, corporate institutions, or funds, which are not SWIFT users (that iswhich are not connected), the eighth character of the BIC must be the digit '1'.



NEXT VERSI

ON

NEXT VERSI

ON

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 MessagesIdentifying 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" onpage 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. TheSWIFT 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 afinancial institution or a non-financial institution is allowed in the party field. "Financial institutionBIC" is used if only financial institution details are allowed in the party field and "non-financialinstitution 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 StandardsMT 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.

The directory is published on a monthly basis. All registered ISO 9362 BICs including branchcodes, are published in the BIC Directory by default. A user can request that a BIC beregistered but not published. Unpublished BICs may only be used where there is a bilateralagreement between the sender and the receiver. Unpublished 8-character SWIFT BICs mayonly be used in the header of a message and not as Identifier Code in fields, for example, 53a,58a..., of a message.

Note For further information, contact End-to-End Ordering, S.W.I.F.T. SCRL, AvenueAdèle 1, B-1310 La Hulpe, Belgium (SWIFT BIC: SWHQBEBBCOS).

3.4 Standards for SWIFT BICs and non-SWIFT BICsIntroduction

This section describes the standards for registered SWIFT BICs and non-SWIFT BICs used inSWIFT messages.

Details regarding SWIFT's policy concerning the use of SWIFT BICs can also be found in theFIN Service Description.

Business Identifier Code (BIC)

23 July 2010 19

NEXT VERSI

ON

NEXT VERSI

ON

3.4.1 Components of a BIC

Introduction

All SWIFT BICs and non-SWIFT BICs have the same basic structure except that non-SWIFTBICS must specify the digit '1' in the eighth position. For addressing purposes, the BIC is usedwith an additional character in the ninth position, shown as the logical terminal code:

D02

0000

2

Logical terminal code

Institution code

Country code

Location code

Branch code

SWIFT Destination

a a a a a a c c c c c c

1 2 3 4 5 6 7 8 9 10 11 12

Logical Terminal Identifier

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

Institution code

The four-digit institution code is unique to each institution, and identifies the institutionworldwide.

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

• SWIFT will allow an institution to use the institution code of another, if agreed by theinstitution code owner.

Country code

The country code identifies the country or geographical territory in which the user is located. Itconsists of the ISO two-alphabetic character country code, for example, CL = Chile. Thecountry 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 orgeographical territory, the region and/or city in which the user is located.



NEXT VERSI

ON

NEXT VERSI

ON

The first component of the location code is the region code. It consists of one alphanumericcharacter (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 alphanumericcharacter (excluding the digit '0' and the letter 'O' - the digit '0' is dedicated to test and trainingdestinations). Where required, the suffix code enables a subdivision within a region or city, ordistinguishes destinations with the same institution code, country code and region code. Fornon-SWIFT BICs, this suffix code must be '1'.

Logical terminal code

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

Branch code

The branch code is an optional component for all BICs. However, once registered, andpublished 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 toidentify:

• a 100 %-owned branch of the requestor's institution

• a department within the requestor's institution

The following restrictions exist for branch code registration:

• '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 thatindicated 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 messagetypes in accordance with the receiver's responsibility and liability as defined in the FINService Description.

• An institution may request that a branch code not be published. All unpublished branch codesmust be covered by a bilateral agreement between sender and receiver.

3.4.2 SWIFT BIC

Description

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

Business Identifier Code (BIC)

23 July 2010 21

NEXT VERSI

ON

NEXT VERSI

ON

Each user must register and publish at least one 8-character SWIFT BIC of a geographicalnature per country. These codes are sufficient for the SWIFT system to determine where todeliver a message.

In addition to the 8-character SWIFT BIC registered in the country, the user may requestadditional SWIFT BICs. These additional SWIFT BICs in the same country may only define ageographical location. The first six characters (institution code, country code) must be identicalto the first six characters of the existing SWIFT BIC. Functional references are prohibited for 8-character SWIFT BICs.

Additional 8-character SWIFT BICs may be registered un-published. These un-published BICsmay 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 Directorypublications. 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 thenext 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.



NEXT VERSI

ON

NEXT VERSI

ON

4 Message Structure and Message Types

4.1 SWIFT Message StructureOverview

All financial messages must conform to the rules of one of the message types described in theStandards MT volumes.

Message Type (MT)

The message type is composed of three digits, generally defined as:

Message Structure

D02

0000

3

Category

Group

Type

MT nnn

Where:

Category Usually describes, at a general level, the underlying businessfunction of the message. For example: Category 1 = CustomerPayments and Cheques.

Group Describes the function of the message within the specifiedcategory. For example: 11n = Category 1 Cheque PaymentMessages.

Type Describes the specific function. For example: 112 = Status ofa Request for Stop Payment of a Cheque.

From the message type (which is located in the header of a message), the receiver of amessage can help to determine the message's business and function, as well as the details ofits composition.

This section provides the general rules for message types. Detailed specifications pertaining toindividual messages can be found in the related Category volumes. More informationconcerning the FIN message structure can be found in Part C of the FIN Operations Guide.

4.2 SWIFT Message TypesOverview

The following table lists all message types defined in the Standards MT volumes, effective in theNovember 2010 Standards Release.

For each message type, there is a short description, an indicator that the message type requiresauthentication (Y or N), the maximum message length (either 2,000 or 10,000) and whether theuse of the message requires registration within a Message User Group (Y or N).

Message Structure and Message Types

23 July 2010 23

NEXT VERSI

ON

NEXT VERSI

ON

Note A Message User Group, for the purposes of this book, is a group of users whohave voluntarily agreed to support the specified message type and have registeredwith SWIFT to send or receive the specified message type. These messages areindicated in the following table, in the column 'MUG'. (More information aboutMessage User Groups follows this table.)

List of Message Types

MT MT Name Purpose Authen MaxLength

MUG

101 Request ForTransfer

Requests to debit acustomer's account held atanother institution.

Y 10,000 Y

102 Multiple CustomerCredit Transfer

Conveys multiple paymentinstructions betweenfinancial institutions.

Y 10,000 Y

102+

103 Single CustomerCredit Transfer

Instructs a funds transfer. Y 10,000 N

103+

103REMIT

Single CustomerCredit Transfer

Instructs a fund transfer. Y 10,000 Y

104 Direct Debit andRequest for DebitTransfer Message

Conveys direct debitinstructions and requestsfor direct debits betweenfinancial institutions.

Y 10,000 Y

105 EDIFACT Envelope An envelope whichconveys a 2k EDIFACTmessage.

Y 2,000 Y

107 General DirectDebit Message

Conveys direct debitinstructions betweenfinancial institutions.

Y 10,000 Y

110 Advice ofCheque(s)

Advises or confirms theissuance of a cheque tothe drawee bank.

Y 2,000 N

111 Request for StopPayment of aCheque

Requests the drawee bankto stop payment of acheque.

Y 2,000 N

112 Status of a Requestfor Stop Payment ofa Cheque

Indicates action(s) taken inattempting to stoppayment of a cheque.

Y 2,000 N

190 Advice of Charges,Interest and OtherAdjustments

Advises an account ownerof charges, interest andother adjustments.

Y 2,000 N

191 Request forPayment ofCharges, Interestand OtherExpenses

Requests payment ofcharges, interest or otherexpenses.

Y 2,000 N

192 Request forCancellation

Requests the receiver toconsider cancellation ofthe message identified inthe request.

Y 2,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

195 Queries Requests informationrelating to a previousmessage or amendment toa previous message.

Y 2,000 N

196 Answers Responds to an MT 195Query or MT 192 Requestfor Cancellation or othermessage where nospecific message type hasbeen provided for aresponse.

Y 2,000 N

198 ProprietaryMessage

Contains formats definedand agreed to betweenusers and for thosemessages not yet live.

Y 10,000 N

199 Free FormatMessage

Contains information forwhich no other messagetype has been defined.

Y 2,000 N

200 Financial InstitutionTransfer for its OwnAccount

Requests the movement ofthe sender's funds to itsaccount at anotherfinancial institution.

Y 2,000 N

201 Multiple FinancialInstitution Transferfor its Own Account

Multiple of the MT 200. Y 2,000 N

202 General FinancialInstitution Transfer

Requests the movement offunds between financialinstitutions except if thetransfer is related to anunderlying customer credittransfer that was sent withthe cover method, in whichcase the MT 202 COVmust be used.

Y 10,000 N

202 COV General FinancialInstitution Transfer

Requests the movement offunds between financialinstitutions, related to anunderlying customer credittransfer that was sent withthe cover method.

Y 10,000 N

203 Multiple GeneralFinancial InstitutionTransfer

Multiple of the MT 202. Y 2,000 N

204 Financial MarketsDirect DebitMessage

Claims funds from SWIFTmember banks.

Y 2,000 Y

205 Financial InstitutionTransfer Execution

Further transmits atransfer requestdomestically except if thetransfer is related to anunderlying customer credittransfer that was sent withthe cover method, in whichcase the MT 205 COVmust be used.

Y 10,000 N


23 July 2010 25

NEXT VERSI

ON

NEXT VERSI

ON


MUG

205 COV Financial InstitutionTransfer Execution

Further transmits atransfer requestdomestically, related to anunderlying customer credittransfer that was sent withthe cover method.

Y 10,000 N

207 Request forFinancial InstitutionTransfer

Requests to debit anordering financialinstitution's account held atthe receiving financialinstitution or the accountservicing financialinstitution.

Y 10,000 Y

210 Notice to Receive Notifies the receiver that itwill receive funds for thesender's account.

Y 2,000 N

256 Advice of Non-Payment ofCheques

Informs the sender of oneor more previously sentcheque truncationmessages of non-paymentof one or more truncatedcheques. It may also beused to specifydishonoured items thatresult in reversing aprevious paymentsettlement.

Y 10,000 Y


Advises an account ownerof charges, interest orother adjustments.

Y 2,000 N



Y 2,000 N



Y 2,000 N


Y 2,000 N

296 Answers Responds to an MT 295Queries message or anMT 292 Request forCancellation or othermessage where nospecific message type hasbeen provided for aresponse.

Y 2,000 N



Y 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG



Y 2,000 N

300 Foreign ExchangeConfirmation

Confirms informationagreed to in the buying/selling of two currencies.

N 10,000 N

303 Forex/CurrencyOption AllocationInstruction

Instructs the allocation of ablock trade (forex orcurrency option).

N 10,000 Y

304 Advice/Instructionof a Third PartyDeal

Advises of or instructssettlement of a third partyforeign exchange deal.

Y 10,000 Y

305 Foreign CurrencyOptionConfirmation

Confirms informationagreed to in the buyingand selling of vanillaoptions on currencies.

N 2,000 N

306 Foreign CurrencyOptionConfirmation

Confirms informationagreed to in the buyingand selling of exoticoptions on currencies.

N 10,000 N

307 Advice/Instructionof a Third Party FXDeal

Advises of or instructssettlement of a third partyforeign exchange deal.

Y 10,000 Y

320 Fixed Loan/DepositConfirmation

Confirms the terms of acontract relative to a fixedloan/deposit transaction.

N 10,000 N

321 Instruction to Settlea Third Party Loan/Deposit

Advises the trade detailsand instructs thesettlement of a fixed termloan/deposit done with athird party financialinstitution.

Y 10,000 Y

330 Call/Notice Loan/DepositConfirmation

Confirms the terms of acontract relative to a call/notice loan/deposittransaction.

N 10,000 N

340 Forward RateAgreementConfirmation

Confirms the details of aforward rate agreement.

N 10,000 N

341 Forward RateAgreementSettlementConfirmation

Confirms the settlementdetails of a forward rateagreement.

N 10,000 N

350 Advice of Loan/Deposit InterestPayment

Advises of a loan/depositinterest payment.

N 10,000 N

360 Single CurrencyInterest RateDerivativeConfirmation

Confirms the details of asingle currency interestrate derivative swap, cap,collar or floor.

N 10,000 N


23 July 2010 27

NEXT VERSI

ON

NEXT VERSI

ON


MUG

361 Cross CurrencyInterest Rate SwapConfirmation

Confirms the details of across currency interestrate swap transaction.

N 10,000 N

362 Interest RateReset/ Advice ofPayment

Confirms or advises thereset rates of the floatinginterest rate(s) in a singleor cross-currency interestrate derivative transactionand/or the payment ofinterest at the end of aninterest period.

N 2,000 N

364 Single CurrencyInterest RateDerivativeTermination/RecouponingConfirmation

Confirms the details of thepartial or full termination orrecouponing of a singlecurrency interest rateswap, cap, collar, or floor.

N 10,000 N

365 Cross CurrencyInterest Rate SwapTermination/RecouponingConfirmation

Confirms the details of thepartial or full termination orrecouponing of a crosscurrency interest rateswap.

N 10,000 N

380 Foreign ExchangeOrder

Orders to purchase or sella specific amount of acertain currency.

Y 10,000 Y

381 Foreign ExchangeOrder Confirmation

Confirms the execution ofan FX order previouslysent.

Y 10,000 Y


Advises an account ownerof charges, interest orother adjustments.

N 2,000 N



N 2,000 N



N 2,000 N


N 2,000 N

396 Answers Responds to an MT 395Queries or an MT 392Request for Cancellationor other message whereno specific message typehas been provided for aresponse.

N 2,000 N


Contains formats definedand agreed to between

N 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

users and for thosemessages not yet live.



N 2,000 N

400 Advice of Payment Advises of a paymentunder a collection or partthereof. It also handles thesettlement of proceeds.

Y 2,000 N

405 Clean Collection Conveys instructions toobtain payment oracceptance againstspecified conditions. Themessage is used for cleancollections only andsupports financialdocuments such asaccepted and non-accepted bills of exchangeand promissory notes.

Y 10,000 Y

410 Acknowledgement Acknowledges receipt of acollection. It also specifiesif the collecting bank doesnot intend to act inaccordance with thecollection instruction.

Y 2,000 N

412 Advice ofAcceptance

Informs the remitting bankof the acceptance of oneor more drafts under onecollection instruction.

Y 2,000 N

416 Advice of Non-Payment/ Non-Acceptance

Advises of the non-payment or non-acceptance under apreviously receivedcollection.

Y 10,000 Y

420 Tracer Enquires about documentssent for collection.

Y 2,000 N

422 Advice of Fate andRequest forInstructions

Advises the remitting bankof the fate of one or morecollection documents;usually accompanied byone or more questions orrequests.

Y 2,000 N

430 Amendment ofInstructions

Amends collectioninstructions.

Y 2,000 N

450 Cash Letter CreditAdvice

Confirms that the faceamount of cash letter(s)received has been creditedunder usual reserve(subject to final payment).

Y 2,000 N

455 Cash Letter CreditAdjustment Advice

Advises the account ownerof adjustments made to itsaccount (related to aprevious credit for a cashletter).

Y 2,000 N


23 July 2010 29

NEXT VERSI

ON

NEXT VERSI

ON


MUG

456 Advice ofDishonour

Advises the account ownerthat financial document(s)included in the cash letterhave been dishonoured forreasons specified in theadvice.

Y 2,000 N


Advises an account ownerof charges, interest orother adjustments to itsaccount.

Y 2,000 N



Y 2,000 N



Y 2,000 N


Y 2,000 N

496 Answers Responds to an MT 495Queries message or MT492 Request forCancellation or othermessages where nospecific message type hasbeen provided for theresponse.

Y 2,000 N



Y 10,000 N



Y 10,000 N

500 Instruction toRegister

Instructs the registration,deregistration orreregistration of a financialinstrument at theregistration provider.

Y 10,000 N

501 Confirmation ofRegistration orModification

Confirms the registration,deregistration orreregistration of abeneficial owner orshareholder with theregistration provider.

Y 10,000 N

502 Order to Buy or Sell Instructs the purchase orsale of a given quantity ofa specified financialinstrument under specifiedconditions.

Y 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

503 Collateral Claim Requests new oradditional collateral, or thereturn or recall ofcollateral.

Y 10,000 Y

504 Collateral Proposal Proposes new oradditional collateral.

Y 10,000 Y

505 CollateralSubstitution

Proposes or requests thesubstitution of collateralheld.

Y 10,000 Y

506 Collateral andExposureStatement

Provides the details of thevaluation of both thecollateral and theexposure.

Y 10,000 Y

507 Collateral Statusand ProcessingAdvice

Advises the status of acollateral claim, a collateralproposal, or a proposal/request for collateralsubstitution.

Y 10,000 Y

508 Intra-PositionAdvice

Reports on the movementof securities within theholding.

Y 10,000 N

509 Trade StatusMessage

Provides information aboutthe status of a previouslyexecuted trade.

Y 10,000 N

510 Registration Statusand ProcessingAdvice

Advises the status of aregistration instruction ormodification.

Y 10,000 N

513 Client Advice ofExecution

Provides brief and earlyinformation about asecurities deal, forexample, a block trade thatis to be allocated beforefinal confirmation.

Y 10,000 N

514 Trade AllocationInstruction

Instructs the allocation of ablock trade.

Y 10,000 N

515 Client Confirmationof Purchase or Sale

Provides a detailedaccounting of financialinstruments purchased orsold by the sender onbehalf of the receiver or itsclient. It may also conveythe payment details of thepurchase or sale. It mayalso be sent by, or via anETC service provider.

Y 10,000 N

516 Securities LoanConfirmation

Confirms the details of asecurities loan, includingcollateral arrangements. Itmay also confirm thedetails of a partial recall orreturn of securitiespreviously out on loan.

Y 2,000 N


23 July 2010 31

NEXT VERSI

ON

NEXT VERSI

ON


MUG

517 Trade ConfirmationAffirmation

Positively affirms thedetails of a previouslyreceived confirmation/contract note.

Y 10,000 N

518 Market-SideSecurities TradeConfirmation

Confirms the details of atrade and, wherenecessary, its settlementto a trading counterparty.

Y 10,000 N

519 Modification ofClient Details

Instructs the modificationof client details at theregistration provider.

Y 10,000 N

524 Intra-PositionInstruction

Instructs the movement ofsecurities within theholding.

Y 10,000 N

526 General SecuritiesLending/BorrowingMessage

Requests the borrowing ofsecurities or notifies thereturn or recall ofsecurities previously outon loan. It may also beused to list securitiesavailable for lending.

Y 2,000 N

527 Triparty CollateralInstruction

Performs a specific actionon a collateralmanagement transaction.

Y 10,000 Y

528 ETC Client-SideSettlementInstruction

Sent by an ETC serviceprovider, it communicatesearly settlementinformation to a custodianor clearing agent about aclient-side trade.

Y 10,000 N

529 ETC Market-SideSettlementInstruction

Sent by an ETC serviceprovider, it communicatesearly settlementinformation to a custodianor clearing agent about amarket-side trade.

Y 10,000 N

530 TransactionProcessingCommand

Requests the modificationof a processing indicator orother non-matchinginformation.

Y 10,000 N

535 Statement ofHoldings

Reports at a specifiedtime, the quantity andidentification of securitiesand other holdings whichthe account servicer holdsfor the account owner.

Y 10,000 N

536 Statement ofTransactions

Provides details ofincreases and decreasesof holdings which occurredduring a specified period.

Y 10,000 N

537 Statement ofPendingTransactions

Provides details of pendingincreases and decreasesof holdings at a specifiedtime.

Y 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

538 Statement of Intra-Position Advices

Provides details ofincreases and decreasesin securities within theholding during a specifiedperiod.

Y 10,000 N

540 Receive Free Instructs a receipt offinancial instruments freeof payment. It may also beused to request acancellation or pre-advisean instruction.

Y 10,000 N

541 Receive AgainstPayment

Instructs a receipt offinancial instrumentsagainst payment. It mayalso be used to request acancellation or pre-advisean instruction.

Y 10,000 N

542 Deliver Free Instructs a delivery offinancial instruments freeof payment. It may also beused to request acancellation or pre-advisean instruction.

Y 10,000 N

543 Deliver AgainstPayment

Instructs a delivery offinancial instrumentsagainst payment. It mayalso be used to request acancellation or pre-advisean instruction.

Y 10,000 N

544 Receive FreeConfirmation

Confirms a receipt offinancial instruments freeof payment. It may also beused to cancel or reversea confirmation.

Y 10,000 N

545 Receive AgainstPaymentConfirmation

Confirms a receipt offinancial instrumentsagainst payment. It mayalso be used to cancel orreverse a confirmation.

Y 10,000 N

546 Deliver FreeConfirmation

Confirms a delivery offinancial instruments freeof payment. It may also beused to cancel or reversea confirmation.

Y 10,000 N

547 Deliver AgainstPaymentConfirmation

Confirms a delivery offinancial instrumentsagainst payment. It mayalso be used to cancel orreverse a confirmation.

Y 10,000 N

548 Settlement Statusand ProcessingAdvice

Advises the status of asettlement instruction orreplies to a cancellationrequest.

Y 10,000 N


23 July 2010 33

NEXT VERSI

ON

NEXT VERSI

ON


MUG

549 Request forStatement/ StatusAdvice

Requests a statement or astatus message.

Y 10,000 N

558 Triparty CollateralStatus andProcessing Advice

Provides validation resultsand status advice recollateral instructions andproposed collateralmovements.

Y 10,000 Y

559 Paying Agent'sClaim

Claims reimbursement ofincome or redemptionproceeds, or acombination of both.

Y 2,000 N

564 Corporate ActionNotification

Provides an accountowner with details of acorporate action event andthe choices available tothe account owner. It alsoprovides the accountowner with details on theimpact a corporate actionevent will have on asafekeeping or cashaccount, for example,entitlement calculation.

Y 10,000 N

565 Corporate ActionInstruction

Instructs the custodian onthe investment decisionmade by an account ownerrelative to a corporateaction event.

Y 10,000 N

566 Corporate ActionConfirmation

Confirms to the accountowner that securities and/or cash have beencredited/debited to anaccount as a result of acorporate action event.

Y 10,000 N

567 Corporate ActionStatus andProcessing Advice

Indicates the status, or achange in status, of acorporate action-relatedtransaction previouslyinstructed by, or executedon behalf of, the accountowner.

Y 10,000 N

568 Corporate ActionNarrative

Provides complexinstructions or narrativedetails relating to acorporate action event.

Y 10,000 N

569 Triparty Collateraland ExposureStatement

Provides the details of thevaluation of both thecollateral and theexposure.

Y 10,000 Y

574(1) IRS 1441 NRA-IRSBeneficial Owners'List

Provides owner or pooledincome information for aperiod of time arrangedbetween the intermediaryand the withholding agent.

Y 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

574(2) IRS 1441 NRA-Form W8-BEN

Certifies the foreign statusof a beneficial owner forUnited States taxwithholding.

Y 10,000 N

575 Report ofCombined Activity

Reports on all securitiesand cash activity for agiven combination ofsafekeeping and cashaccounts.

Y 10,000 Y

576 Statement of OpenOrders

Provides details of ordersto buy or to sell financialinstruments, as at aspecified date, which havebeen accepted by thesender, but which have notyet been executed.

Y 10,000 N

577 Statement ofNumbers

Provides certificatenumbers of securities.

Y 10,000 N

578 SettlementAllegement

Advises the account ownerthat a counterparty hasalleged a settlementinstruction on the accountowner's account.

Y 10,000 N

579 Certificate Numbers Replaces or supplementsthe 'certificate numbers'field in a primary message,for example, MT 577.

Y 2,000 N

581 CollateralAdjustmentMessage

Claims or notifies achange in the amount ofcollateral held againstsecurities out on loan orfor other reasons.

Y 2,000 N

582 ReimbursementClaim or Advice

Claims reimbursement offunds paid on behalf of thereceiver or of securitiesreceived which are due tothe sender. It may alsoadvise that funds and/orsecurities have or will beremitted by the sender infavour of the receiver.

Y 2,000 N

584 Statement of ETCPending Trades

Provides statuses anddetails of executed tradeswhich are not yet matchednor affirmed.

Y 10,000 N

586 Statement ofSettlementAllegements

Provides details of pendingsettlement allegements.

Y 10,000 N

587 Depositary ReceiptInstruction

Instructs the issuance orrelease of a depositaryreceipt from/to ordinaryshares, or the conversionfrom one type ofdepositary receipt toanother.

Y 10,000 N


23 July 2010 35

NEXT VERSI

ON

NEXT VERSI

ON


MUG

588 Depositary ReceiptConfirmation

Confirms the issuance orrelease of a depositaryreceipt from/to ordinaryshares, or the conversionfrom one type ofdepositary receipt toanother.

Y 10,000 N

589 Depositary ReceiptStatus andProcessing Advice

Advises the status, orchange in status, of adepositary receipt.

Y 10,000 N



Y 2,000 N



Y 2,000 N



Y 2,000 N


Y 2,000 N

596 Answers Responds to an MT 595Queries or MT 592Request for Cancellationor other message whereno specific message typehas been provided for theresponse.

Y 2,000 N



Y 10,000 N



Y 2,000 N

600 Commodity TradeConfirmation

Confirms the details of acommodity trade and itssettlement.

N 2,000 N

601 Commodity OptionConfirmation

Confirms the details of acommodity option contract.

N 2,000 N

604 CommodityTransfer/DeliveryOrder

Instructs the receiver totransfer by book-entry, orphysically deliver, aspecified type and quantityof commodity to aspecified party.

Y 2,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

605 Commodity Noticeto Receive

Notifies the receiver of animpending book-entrytransfer or physicaldelivery of a specified typeand quantity of commodity.

N 2,000 N

606 Commodity DebitAdvice

Advises the receiver of adebit entry to a specifiedcommodity account.

N 2,000 N

607 Commodity CreditAdvice

Advises the receiver of acredit entry to a specifiedcommodity account.

N 2,000 N

608 Statement of aCommodityAccount

Provides the details of allbookings to a commodityaccount.

N 2,000 N

609 Statement ofCommodityContracts

Identifies all outstandingcommodity contracts, as ata specified date for whichconfirmations have beenexchanged.

N 2,000 N

620 Commodity FixedLoan/DepositConfirmation

Confirms a commodityfixed term loan/depositcontract.

N 10,000 Y

643 Notice ofDrawdown/Renewal

Provides notice of theborrower(s) request fordrawdown(s)/renewal(s)on a given date.

Y 2,000 N

644 Advice of Rate andAmount Fixing

Specifies the interest rateand, if applicable, theexchange rate, for the nextinterest period.

Y 2,000 N

646 Payment ofPrincipal and/or ofInterest

Advises of payments and/or prepayments ofprincipal and/or of interestwith the same value date,but not related to anysubsequent drawing orrenewal.

Y 2,000 N

649 General SyndicatedFacility Message

Provides forcommunications related tosyndicated facilities forwhich no specific messagehas been defined.

Y 2,000 N



Y 2,000 N



Y 2,000 N


Requests the receiver toconsider cancellation of

Y 2,000 N


23 July 2010 37

NEXT VERSI

ON

NEXT VERSI

ON


MUG

the message identified inthe request.


Y 2,000 N

696 Answers Responds to an MT 695Queries message or MT692 Request forCancellation or othermessages where nospecific message type hasbeen provided for theresponse.

Y 2000 N



Y 10,000 N



Y 2,000 N

700 Issue of aDocumentaryCredit

Indicates the terms andconditions of adocumentary credit.

Y 10,000 N

701 Issue of aDocumentaryCredit

Continuation of an MT 700for fields 45a, 46a and47a.

Y 10,000 N

705 Pre-Advice of aDocumentaryCredit

Provides brief advice of adocumentary credit forwhich full details willfollow.

Y 2,000 N

707 Amendment to aDocumentaryCredit

Informs the receiver ofamendments to the termsand conditions of adocumentary credit.

Y 10,000 N

710 Advice of a ThirdBank's or a Non-Bank'sDocumentaryCredit

Advises the receiver of theterms and conditions of adocumentary credit.

Y 10,000 N

711 Advice of a ThirdBank'sDocumentaryCredit


Y 10,000 N

720 Transfer of aDocumentaryCredit

Advises the transfer of adocumentary credit, or partthereof, to the bankadvising the secondbeneficiary.

Y 10,000 N

721 Transfer of aDocumentaryCredit


Y 10,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

730 Acknowledgement Acknowledges the receiptof a documentary creditmessage and may indicatethat the message hasbeen forwarded accordingto instructions. It may alsobe used to account forbank charges or to adviseof acceptance or rejectionof an amendment of adocumentary credit.

Y 2,000 N

732 Advice ofDischarge

Advises that documentsreceived withdiscrepancies have beentaken up.

Y 2,000 N

734 Advice of Refusal Advises the refusal ofdocuments that are not inaccordance with the termsand conditions of adocumentary credit.

Y 10,000 N

740 Authorisation toReimburse

Requests the receiver tohonour claims forreimbursement ofpayment(s) ornegotiation(s) under adocumentary credit.

Y 2,000 N

742 Re-imbursementClaim

Provides a reimbursementclaim to the bankauthorised to reimbursethe sender or its branch forits payments/ negotiations.

Y 2,000 N

747 Amendment to anAuthorisation toReimburse

Informs the reimbursingbank of amendments tothe terms and conditions ofa documentary credit,relative to the authorisationto reimburse.

Y 2,000 N

750 Advice ofDiscrepancy

Advises of discrepanciesand requests authorisationto honour documentspresented that are not inaccordance with the termsand conditions of thedocumentary credit.

Y 10,000 N

752 Authorisation toPay, Accept orNegotiate

Advises a bank which hasrequested authorisation topay, accept, negotiate orincur a deferred paymentundertaking that thepresentation of thedocuments may behonoured, notwithstandingthe discrepancies,provided they areotherwise in order.

Y 2,000 N


23 July 2010 39

NEXT VERSI

ON

NEXT VERSI

ON


MUG

754 Advice of Payment/Acceptance/Negotiation

Advises that documentshave been presented inaccordance with the termsof a documentary creditand are being forwardedas instructed. Thismessage type alsohandles the payment/negotiation.

Y 2,000 N

756 Advice of Re-imbursement orPayment

Advises of thereimbursement or paymentfor a drawing under adocumentary credit inwhich no specificreimbursement instructionsor payment provisionswere given.

Y 2,000 N

760 Guarantee Issues or requests theissue of a guarantee.

Y 10,000 N

767 GuaranteeAmendment

Amends a guaranteewhich has been previouslyissued or requests theamendment of a guaranteewhich the sender haspreviously requested to beissued.

Y 10,000 N

768 Acknowledgementof a GuaranteeMessage

Acknowledges the receiptof a guarantee messageand may indicate thataction has been takenaccording to instructions.

Y 2,000 N

769 Advice ofReduction orRelease

Advises that a bank hasbeen released of its liabilityfor a specified amountunder its guarantee.

Y 2,000 N



Y 2,000 N



Y 2,000 N



Y 2,000 N


Y 2,000 N

796 Answers Responds to an MT 795Queries message or MT792 Request for

Y 2,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

Cancellation or othermessages where nospecific message type hasbeen provided for theresponse.



Y 10,000 N



Y 10,000 N

800 T/C Sales andSettlement Advice[Single]

Provides the sale andsettlement details for thesale of travellers chequesby a single selling agent.

Y 2,000 N

801 T/C Multiple SalesAdvice

Provides the details(excluding the settlementdetails) of the sales oftravellers cheques incases where the data islengthy or includes datafrom several sellingagents.

Y 2,000 N

802 T/C SettlementAdvice

Provides the settlementdetails of multiple sales oftravellers cheques.

Y 2,000 N

824 T/C InventoryDestruction/Cancellation Notice

Notifies the issuer of thedestruction/cancellation oftravellers cheque inventoryheld by the selling agent. Itmay also request a sellingagent to destroy/canceltravellers chequeinventory.

Y 2,000 N



Y 2,000 N



Y 2,000 N



Y 2,000 N


Y 2,000 N

896 Answers Responds to an MT 895Queries message or MT892 Request for

Y 2,000 N


23 July 2010 41

NEXT VERSI

ON

NEXT VERSI

ON


MUG

Cancellation or othermessages where nospecific message type hasbeen provided for theresponse.



Y 10,000 N



Y 2,000 N

900 Confirmation ofDebit

Advises an account ownerof a debit to its account.

N 2,000 N

910 Confirmation ofCredit

Advises an account ownerof a credit to its account.

N 2,000 N

920 Request Message Requests the accountservicing institution to sendan MT 940, 941, 942 or950.

N 2,000 N

935 Rate ChangeAdvice

Advises the receiver ofgeneral rate change(s)and/or rate change(s)which applies to a specificaccount other than a call/notice loan/depositaccount.

N 2,000 N

940 CustomerStatementMessage

Provides balance andtransaction details of anaccount to a financialinstitution on behalf of theaccount owner.

N 2,000 N

941 Balance Report Provides balanceinformation of an accountto a financial institution onbehalf of the accountowner.

N 2,000 N

942 Interim TransactionReport

Provides balance andtransaction details of anaccount, for a specifiedperiod of time, to afinancial institution onbehalf of the accountowner.

N 2,000 N

950 StatementMessage

Provides balance andtransaction details of anaccount to the accountowner.

N 2,000 N

970 Netting Statement Provides balance andtransaction details of anetting position asrecorded by a nettingsystem.

N 2,000 N



NEXT VERSI

ON

NEXT VERSI

ON


MUG

971 Netting BalanceReport

Provides balanceinformation for specifiednetting position(s).

N 2,000 N

972 Netting InterimStatement

Advises interim balanceand transaction details of anetting position asrecorded by a nettingsystem.

N 2,000 N

973 Netting RequestMessage

Requests an MT 971 or972 containing the latestavailable information.

N 2,000 N

985 Status Enquiry Requests an MT 986. N 2,000 N

986 Status Report Provides business-relatedinformation about acustomer or institution.

N 2,000 N



N 2,000 N



N 2,000 N



N 2,000 N


N 2,000 N

996 Answers Responds to an MT 995Queries or MT 992Request for Cancellationor other messages whereno specific message typehas been provided for theresponse.

N 2,000 N



N 10,000 N



N 2,000 N

(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

NEXT VERSI

ON

NEXT VERSI

ON

Message User Group registration procedure

Registration is free of charge. To register to use one or more Message Types (MTs), submit aregistration request (Register to a Message User Group) through www.swift.com. To withdrawfrom 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 theCustomer Implementation team (SWHQBEBBCOS).

4.3 Message Length and StructureRules

There are several rules which must be followed when structuring financial messages:

• There are two alternative message length limitations for financial messages, as explainedbelow. For both alternatives, there is a difference between the message length calculation oninput 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 permessage type.)

Alternatives:

– The number of characters allowed by the SWIFT system on input from a computer-basedterminal is 2,000. On output to a computer-based terminal the system will limit the numberof characters to 2,600.

– The number of characters allowed by the SWIFT System on input from a computer-basedterminal is 10,000. On output to a computer-based terminal the system will limit thenumber of characters to 10,600. The number of characters permitted on output forretrieved messages, including headers and trailers, is 11,325.

• The format of each message type specifies a number of fixed and variable length fields. Thepresence of these fields may be mandatory or optional.

• A field which is not specified in the format specifications for a particular message type mustnever appear.

• A field may appear only once in a sequence, unless repetition is specifically allowed.

• Fields are separated by a unique field separator.



http://www.swift.com/ordering/old_ordering_configuration/existing_customers/43718/messaging_services/change_subscription/fin_service_configuration/register_to_a_message_user_group.page?lang=en

http://www.swift.com/ordering/old_ordering_configuration/existing_customers/43718/messaging_services/change_subscription/fin_service_configuration/deregister_from_a_message_user_group.page

NEXT VERSI

ON

NEXT VERSI

ON

4.4 Message Structure ExampleExample: structure of an MT 103

The following example illustrates the structure of a financial message (MT 103) as input by thesender.

D0200004

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

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

-}

{5:{CHK:123456789ABC}}

Basic header block

Application header block

User header block

Text block

Trailer block

Note Basic Header, Application Header, User Header, Text and Trailers Blocks are notseparated by CrLf. In the above example, the blocks have been shown on separatelines for purposes of clarity.


23 July 2010 45

NEXT VERSI

ON

NEXT VERSI

ON

5 Field Structure

5.1 OverviewField structure

D02

0000

5

Field tag number

Delimiter

Letter option

Delimiter

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

• Field structure consists of a colon ':', followed by a tag, followed by a colon ':' and the fieldcontent.

• 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

– within field content, apart from the first character of the field, a colon ':' or hyphen '-' mustnever 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 amessage is followed by an 'End of Text' (CrLf-).

• The Carriage Return, Line Feed character must always appear as a sequence. Thissequence shall only be used to indicate start of text, as a field separation within text, toindicate 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 notincluded in the number of characters for the length of the subfield, serves as the subfieldseparator.

Subfields:

– subfields may themselves be of fixed or variable length

– the order of subfields is fixed



NEXT VERSI

ON

NEXT VERSI

ON

– 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 themandatory 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 thefollowing table:

Restrictions on Length Types of Characters Allowed

nn maximum length(minimum is 1)

n numeric digits (0 through 9) only

nn-nn minimum andmaximum length

a alphabetic letters (A through Z), uppercase only

c alphabetic letters (upper case) and digitsonly

h hexadecimal letters A through F (uppercase) and digits only

nn! fixed length x any character of the X permitted set(General FIN application set) upper andlower case allowed ("SWIFT CharacterSet (X Character Set)" on page 49)

y any character of the EDIFACT level Acharacter set as defined in ISO 9735upper case only ("Information ServiceCharacter Set (Z Character Set)" onpage 49)

z any character as defined by theInformation Service ("SWIFT CharacterSet (X Character Set)" on page 49)

nn*nn maximum number oflines times maximumline length

e blank space

d decimals

Examples

2n up to 2 digits

3!a always 3 letters

4*35x up to 4 lines of up to 35 characters each

16-64h at least 16 and up to 64 hexadecimal digits

– 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 ofcharacters, for inclusion in the text of the field.

These take the following forms:

– codes, for example, AMEND, TRF or 08

Field Structure

23 July 2010 47

NEXT VERSI

ON

NEXT VERSI

ON

– 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 mixof alpha and numeric characters, the alpha character must also be in uppercase.



NEXT VERSI

ON

NEXT VERSI

ON

6 Characters

6.1 SWIFT Character Set (X Character Set)Description

Computer-based terminals communicating with SWIFT use EBCDIC code. The character set isas follows:

a b c d e f g h i j k l m n o p q r s t u v w x y z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9

/ - ? : ( ) . , ' + { }

CR LF Space

Although part of the character set, the curly brackets are permitted as delimiters and cannot beused 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. Thischaracter set is as follows:


0 1 2 3 4 5 6 7 8 9

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

Space

Other characters are not allowed (Error Code M60).

6.3 Information Service Character Set (Z CharacterSet)

Description

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

a b c d e f g h i j k l m n o p q r s t u v w x y z


0 1 2 3 4 5 6 7 8 9

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

@ # _

CrLf Space

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

Characters

23 July 2010 49

NEXT VERSI

ON

NEXT VERSI

ON

7 Field Formatting Rules

7.1 General RulesOverview

The following general rules apply to all fields:

• The field length and type of character(s), for example, letters, numbers, are specified in theStandards MT General Field Definitions plus and in the field specifications for individualmessage types.

• Unless otherwise stated in the Standards MT General Field Definitions plus or message fieldspecifications, 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 onesubfield), 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 (whenthe field is used). The following 4 characters, preceded by a slash '/', are optional, andtherefore need not be present in the field.

• A field format may be shown on two or more lines:

3!n

6!n

When this is the case, the information must be formatted with the CrLf character separatingeach line.

Note In the ISO 15022 securities messages, generic fields are used to specify Party,Amount, Date, Reference and Other types of data. For further explanation of thisapproach see Category 5 Securities Markets - Message Usage Guidelines.

7.2 DatesFormats

Format: 4!n

Format: 6!n

Format: 8!n

Rules

Dates are represented as either: 4, 6 or 8 digit integers, that is, in ISO form MMDD,YYMMDD or YYYYMMDD

Where:

• YY = last 2 digits of the year



NEXT VERSI

ON

NEXT VERSI

ON

• 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 asfollows:

If the year, (YY) is greater than 79, the date refers to the 20th century. If the year is 79 or less,the date refers to the 21st century:

If YY > 79 YYMMDD = 19YYMMDD

else YYMMDD = 20YYMMDD

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

On the FIN network, there is an additional restriction for the year range where the date isaffected 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 NumbersFormat

D02

0000

6

Fractional part (optional)

Integer part

nn...nn, nn...n

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.

Field Formatting Rules

23 July 2010 51

NEXT VERSI

ON

NEXT VERSI

ON

• 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 mustappear. Leading zeros are allowed.

• Normally, when a number represents an amount of money, the number of places followingthe decimal comma may not exceed the number of decimal digits valid for the specifiedcurrency. The specifications for the individual message types will indicate the fields wherethis is not the case. Details regarding the allowable fractional parts for each currency codemay be found in the BIC Directory.

Examples

Valid Invalid

000,000,0,670,25100000,25768,99999999,100,10500,005,25

00000.67,25100.00025-768999.999.99910010500.005 1/4

7.4 Currency CodesFormat

Format: 3!a

Description

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

7.5 Party IdentificationIntroduction

Parties may be represented in several ways:

• Identifier Code (BIC)

• branch (city) of the sender or the receiver

• name and address

• other identification codes, for example, account number

When necessary, party identification can be supplemented by an account number linepreceding other party information.



NEXT VERSI

ON

NEXT VERSI

ON

7.5.1 Party Identifier

Overview

When further identification of a party, for example, specification of an account number to becredited, is necessary, the party identifier should be used.

Format: [/1a][/34x]

Where:

Subfield 1 [/1a] Specifies which account is involved:

/C The receiver's account serviced by the sender is credited.

/D The sender's account serviced by the receiver is debited.

Subfield 2 [/34x] The account number information, preceded by a slash '/'.

Rules

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

• The party specified in the field with the account must be the account owner. The optionalparty identifier must specify the account known to the account servicing institution.

• Extreme care must be taken when formatting the party identifier, for example, when onlysubfield 2 '[/34x]' is entered, and its first and third characters consist of '/', the system canonly presume that both subfields 1 and 2 are present. It will then qualify the second characterfor either code 'C' or 'D', and NAK the message if one or the other is not present (Error CodeT51).

Note Other fields impacted by this form of validation are:

• 42A, 42D.

• 50D, 50F*, 51A, 51D, 52A, 52B, 52D, 53A, 53B, 53D, 54A, 54B, 54D, 55A, 55B,55D, 56A, 56B, 56D, 57A, 57B, 57D, 58A, 58B, 58D.

• 82A, 82B, 82D, 83A, 83D, 84A, 84B, 84D, 85A, 85B, 85D, 86A, 86B, 86D, 87A,87B, 87D, 88A, 88B, 88D.

* See additional structure for party identifier in section 7.5.7, "Option F: PartyIdentifier / Name and Address" on page 60

Additional Rules

The following additional rules apply:

• An account specified in field 58a or 59a must be owned by that party and must be servicedby 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 thefinancial 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 thereceiver.


23 July 2010 53

NEXT VERSI

ON

NEXT VERSI

ON

• 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 thetransaction 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 servicedby the sender, is to be used for reimbursement, if they both service accounts for eachother in the currency of the transaction. In this case, the account to be debited or creditedshall 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 (partyidentifier only).

Examples

Valid Invalid

:53A:/C/12-12CITIUS33CHI

:53A:/6/12-12CITIUS33CHI

:53B:/D/24-24 :53B:/A/24-24

:53D:/52/48-48John Doe122 Peyton PlaceElyria, OH 22216

:53D:/:/48-48John Doe122 Peyton PlaceElyria, OH 22216

:87E:FREE/C/12-12CHASUS33

:87E:APMT/A/12-12CHASUS33

:87F:APMT /D/12-12John Doe122 Peyton PlaceElyria, OH 22216

:87F:APMT /:/48-48 John Doe122 Peyton PlaceElyria, OH 22216

Example

Bank A in New York services an account in USD for Bank B in London. Bank B also services, inLondon, a USD account (number 567-3245-01) for Bank A.

Bank A sends a USD transfer to Bank B, using its USD account in London, serviced by Bank B,for reimbursement. Bank A will request that Bank B debit its account in London as follows:

53B:/D/567-3245-01

Note In certain message types there are exceptions to the rules for use of the partyidentifier detailed in this section, for example, Field 57a in category 3 messages. Inthose cases, the intended use of the party identifier is described in the relevantfield specification for the message type.

7.5.2 Option No Letter: Name and Address

Format

[/34x] (Account)

4*35x (Name and Address)

Definition

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



NEXT VERSI

ON

NEXT VERSI

ON

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

Format

[/1a][/34x] (Party Identifier)

4!a2!a2!c[3!c] (Identifier Code)

Definition

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

Network 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 eighthposition 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

• 50A**, 51A, 52A, 53A, 54A, 55A, 56A, 57A, 58A, 59A

• 82A, 83A, 84A, 85A, 86A, 87A, 88A

Note When this option is used, the SWIFT system will validate the correctness of theIdentifier Code, that is, to ensure that it is registered : either connected or non-connected.

(*) Field 41A does not have the optional party identifier, but does have anadditional 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.

7.5.4 Option B: Branch of Sender/Receiver

Format


[35x] (Location)


23 July 2010 55

NEXT VERSI

ON

NEXT VERSI

ON

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 optionidentifies 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 thesender, 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 financialinstitution specified in the receiver's address in the header.

Fields assigned this option

52B, 53B, 54B, 55B, 57B, 58B

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

7.5.5 Option C: Account Number/Party Identifier

Format

/34x (Account)

Definition

A code uniquely identifying an account and/or party.

In the MTs 101, 102, 103 and 104, clearing codes may be used.

Fields assigned this option

51C, 52C, 53C, 56C, 57C, 58C

82C, 83C, 85C, 87C, 88C

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

7.5.6 Option D: Name and Address

Format



Note This option is used when no other option is available.

This information also applies to fields 50 (when option representing name andaddress is selected) and 59 (without letter option).

Definition

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



NEXT VERSI

ON

NEXT VERSI

ON

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 addressor 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 andcountry identification

Although more than one element of an address may appear on each line, care should be takenthat, when possible, no element, for example, street address, should be spread over more thanone line.

National clearing codes list

When the party identifier is used to indicate a national clearing system code preceded by adouble slash '//', the following codes may be used:

AT 5!n Austrian Bankleitzahl

AU 6!n Australian Bank State Branch (BSB) Code

BL 8!n German Bankleitzahl

CC 9!n Canadian Payments Association Payment Routing Number

CH 6!n CHIPS Universal Identifier

CP 4!n CHIPS Participant Identifier

ES 8..9n Spanish Domestic Interbanking Code

FW 9!n Fedwire Routing Number

GR 7!n HEBIC (Hellenic Bank Identification Code)

HK 3!n Bank Code of Hong-Kong

IE 6!n Irish National Clearing Code

IN 11!n Indian Financial System Code (IFSC) is the identification schemedefined by the Reserve Bank of India

IT 10!n Italian Domestic Identification Code

PL 8!n Polish National Clearing Code (KNR)

PT 8!n Portuguese National Clearing Code

RU 9!n Russian Central Bank Identification Code

SC 6!n UK Domestic Sort Code

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

SW 6!n Swiss Clearing Code (SIC code)

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


23 July 2010 57

NEXT VERSI

ON

NEXT VERSI

ON

When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //RT is used, itshould 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 viaFedwire, 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 areal-time gross settlement system (RTGS), the code RT should appear in the optional PartyIdentifier.

Option D must only be used in exceptional circumstances, that is, when the party cannot beidentified by a BIC, and when there is a bilateral agreement between the sender and thereceiver 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 (AustralianPayments 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


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

– 3!n = Bank Code

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

– 3!n = Bank Code


• The Indian Financial System Code (IFSC) is the identification scheme defined by theReserve 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

– 6!c = Branch code

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

– 2!n = Bank code

– 4!n = Branch code



NEXT VERSI

ON

NEXT VERSI

ON

• The Italian ITBI code is the identification scheme defined by ABI (Associazione BancariaItaliana). 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 (NewZealand Bankers Association). Its structure is:

– 2!n = Bank Code


• The Portuguese National Clearing code is defined by the Banco de Portugal. Its structure is4!n4!n, where:

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

– 4!n = Branch Code (BLCI) which is unique for each branch and locally assigned by theFinancial Institution.

• The Russian Central Bank Identification Code is to be considered as one, uniform, indivisiblecode. 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 theCentral Bank of Russia.

– 2!n = Region Code within the country

– 2!n = Code of the division of the Central Bank in the region

– 3!n = Bank Code

• The South African National Clearing code is defined by BankServ, the South AfricanBankers Services Company Ltd. Its structure is 3!n3!n, where:

– 3!n = Bank code, potentially with leading zeros

– 3!n = Branch code, potentially with leading zeros

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

– 4!n = Bank Code


– [1!n] = Check Digit


42D

50D, 51D, 52D, 53D, 54D, 55D, 56D, 57D, 58D

82D, 83D, 84D, 85D, 86D, 87D, 88D

Note Field 41D does not have the optional party identifier but does have an additionalsubfield.


23 July 2010 59

NEXT VERSI

ON

NEXT VERSI

ON

7.5.7 Option F: Party Identifier / Name and Address

Format

[35x] (Party Identifier)


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

Line 1 (subfield Party Identifier) /34x (Account)

Line 2-5 (subfield Name andAddress

1!n/33x (Number)(Details)

Or

Line 1 (subfield Party Identifier) 4!a/2!a/27x (Code)(Country Code)(Identifier)

Line 2-5 (subfield Name andAddress

1!n/33x (Number)(Details)

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 ofthe following codes must be used:

ARNU Alien Registration Number The code followed by a slash, '/' must be followed by theISO country code, a slash, '/' and the Alien RegistrationNumber.

CCPT Passport Number The code followed by a slash, '/' must be followed by theISO country code, a slash, '/' and the Passport Number.

CUST Customer Identification The code followed by a slash, '/' must be followed by theISO country code of the issuer of the number, a slash,'/', the issuer of the number, a slash, '/' and theCustomer Identification Number.

DRLC Driver's License Number The code followed by a slash, '/' must be followed by theISO country code of the issuing authority, a slash, '/', theissuing authority, a slash, '/' and the Driver's LicenseNumber.

EMPL Employer Number The code followed by a slash, '/' must be followed by theISO country code of the registration authority, a slash, '/',the registration authority, a slash, '/' and the EmployerNumber.

NIDN National Identity Number The code followed by a slash, '/' must be followed by theISO country code, a slash, '/' and the National IdentityNumber.

SOSE Social Security Number The code followed by a slash, '/' must be followed by theISO country code, a slash, '/' and the Social SecurityNumber.

TXID Tax Identification Number The code followed by a slash, '/' must be followed by theISO country code, a slash, '/' and the Tax IdentificationNumber.



NEXT VERSI

ON

NEXT VERSI

ON

Codes

Each line of subfield 2 Name and Address when present must start with one of the followingnumbers:

1 Name of the orderingcustomer

The number followed by a slash, '/' must be followed bythe name of the ordering customer (where it isrecommended that the surname precedes givenname(s)).

2 Address Line The number followed by a slash, '/' must be followed byan Address Line (Address Line can be used to providefor example, street name and number, or buildingname).

3 Country and Town The number followed by a slash, '/' must be followed bythe ISO country code, a slash '/' and Town (Town can becomplemented by postal code (for example zip), countrysubdivision (for example state, province, or county).

4 Date of Birth The number followed by a slash, '/' must be followed bythe Date of Birth in the YYYYMMDD format.

5 Place of Birth The number followed by a slash, '/' must be followed bythe ISO country code, a slash '/' and the Place of Birth.

6 Customer IdentificationNumber

The number followed by a slash, '/' must be followed bythe ISO country code of the issuer of the number, aslash, '/', the issuer of the number, a slash, '/' and theCustomer Identification Number.

7 National Identity Number The number followed by a slash, '/' must be followed bythe ISO country code, a slash, '/' and the NationalIdentity Number.

8 Additional Information The number followed by a slash, '/' is followed byinformation 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 insubfield 2 (Name and Address) with number 6.

• the National Identity Number provided in subfield 2(Name and Address) with number 7.


Subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country Codemust be a valid ISO country code (Error code(s): T73).

Subfield 2 (Name and Address):

• The first line must start with number 1 (Error code(s): T56).

• Numbers must appear in numerical order (Error code(s): T56).

• Number 2 must not be used without number 3 (Error code(s): T56).

• Number 4 must not be used without number 5 and vice versa (Error code(s): T56).


23 July 2010 61

NEXT VERSI

ON

NEXT VERSI

ON

• Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local tothe sender, must not be later than the date on which the message is successfully sent toSWIFT (Error code(s): T53).

• Numbers 3, 5, 6 and 7 must be followed by a valid ISO country code (Error code(s): T73), aslash '/' 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.

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

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 additionalspace is required for providing the Identifier of the ordering customer, one of the followingoptions must be used:

1. First option (preferred): Identify the ordering customer with a different identifier where thelength is not an issue.

2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.

Subfield 2 (Name and Address): if additional space is required for providing the CustomerIdentification Number (number 6) or the National Identity Number (number 7) of the orderingcustomer, one of the following options must be used:

1. First option (preferred): Identify the ordering customer with a different identifier where thelength is not an issue.

2. Second option: Continue the information in subfield 2 (Name and Address) using number 8.

Examples

Example 1

:50F:/123456781/SMITH JOHN2/299, PARK AVENUE3/US/NEW YORK, NY 10017Example 2

:50F:/BE300012163714111/PHILIPS MARK4/197208305/BE/BRUSSELSExample 3



NEXT VERSI

ON

NEXT VERSI

ON

:50F:DRLC/BE/BRUSSELS/NB09490421/DUPONT JACQUES2/HIGH STREET 6, APT 6C3/BE/BRUSSELSExample 4

:50F:NIDN/DE/1212312343421/MANN GEORG6/DE/ABC BANK/1234578293Example 5

:50F:CUST/DE/ABC BANK/123456789/8-1234561/MANN GEORG2/LOW STREET 73/DE/FRANKFURT8/7890This means that the customer identification number of Mann Georg assigned by ABC Bank is123456789/8-1234567890.


50F

7.5.8 Option G: Identifier Code

Format

/34x (Account)

4!a2!a2!c[3!c] (Identifier Code)

Definition

Identifier code of the party with mandatory account number.


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


50G, 52G

7.5.9 Option H: Name and Address

Format

/34x (Account)


Definition

Name and address of the party with a mandatory account.


50H


23 July 2010 63

NEXT VERSI

ON

NEXT VERSI

ON

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 ornot:

Code Format Description

/ABIC/ 4!a2!a2!c[3!c] or4!a

the BIC or 'UKWN' if BIC not known

/ACCT/ 34x account followed by the account number

/NAME/ 34x name followed by the name

/ADD1/ 35x address followed by the first line of the address

/ADD2/ 35x address followed by the second line of the address

/CITY/ 35x city followed by the name of city (and state, country)

/USFW/ 9!n FedWire followed by FedWire Routing Number

/USCH/ 6!n CHIPS followed by CHIPS UID

/GBSC/ 6!n CHAPS followed by CHAPS sort code

/CLRC/ 35x Clearing Code followed by a clearing code

/NETS/ - a net settlement is taking place

/SSIS/ - standard settlement instructions are used

The codes do not need to be put on separate lines. It is the '/' at the beginning of a code, not theend-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 bepart of the narrative text following the code, but it is to be ignored when reading the field.However, the end-of-line may not be part of the code.

Examples

/ABIC/BNKAXA11/NAME/BANK A OF XANADU(CrLf)/NAME/BANK A OF XANADU/ABIC/BNKAXA11(CrLf)/ABIC/BNKAXA11(CrLf) /NAME/BANK A OF XANADU(CrLf)/ABIC/BNKAXA11/NAME/BRANCH B OF THE(CrLf)SECOND NATIONAL BANK A OF XANADU(CrLf)


53J, 56J, 57J, 58J

82J, 83J, 84J, 85J, 86J, 87J, 88J.



NEXT VERSI

ON

NEXT VERSI

ON

7.5.11 Option K: Name and Address

Format

[/34x] (Account)


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


50K

7.5.12 Option L: Party Identification

Format

35x (Narrative)

Definition

Identification of the party


50L

7.5.13 Option P: Party

Format

:4!c//4!a2!a2!c[3!c] (Qualifier)(IdentifierCode)

Definition

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


95P

7.5.14 Option Q: Party

Format

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


23 July 2010 65

NEXT VERSI

ON

NEXT VERSI

ON

Definition

Identification of the party, with a qualifier and name and address.


95Q

7.5.15 Option R: Party

Format

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

Definition

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


95R

7.5.16 Option S: Party

Format

:4!c/[8c]/4!c/2!a/30x (Qualifier) (Data Source Scheme) (Type of ID) (Countrycode) (Alternate ID)

Definition

Identification of the party, with a qualifier, an optional issuer code, type of ID, country code andalternate ID.


95S

7.5.17 Option T: Party

Format

:4!c//2*35x (Qualifier) (Name)

Definition

Identification of the party, with a qualifier and name.


95T

7.5.18 Option U: Party

Format

:4!c//3*35x (Qualifier) (Name)



NEXT VERSI

ON

NEXT VERSI

ON

Definition

Identification of the party, with a qualifier and names.


95U

7.6 TimesFormats

4!n

6!n

Rules

Times are represented as either four or six digit integers, that is, in form HHMM or HHMMSSrespectively, where (Error Code T38):

• H = Hour

• M = Minutes

• S = Seconds

No blank spaces or other characters are permitted.

Examples

00001200235959

7.7 Value Date OrderingOverview

The SWIFT system allows the receiver to request value date ordering of its value date sensitivemessages.

The value date sensitive messages are:

• MT 910

• all Category 1 and Category 2 messages containing fields 30 or 32A, or both 30 and 32A,except common group messages 192, 292, 195, 295, 196 and 296

The valid range of value dates implemented on the SWIFT system for these MTs is from 1980to 2060, and must meet the following requirements:

• allowed: a year component, for example, 'YY' in the range of 80 through 60, of an ISOdefined six digit integer date 'YYMMDD'

• not allowed: any 'YY' component outside of this range, for example, 'YY' in the range of 61through 79


23 July 2010 67

NEXT VERSI

ON

NEXT VERSI

ON

Example

ACKed NAKed

:32A:601130USD1,:32A:801130USD1,

: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 ofthe message. Error code 'T50' is returned after an invalid value date.



NEXT VERSI

ON

NEXT VERSI

ON

8 Euro-Related Information (ERI)

8.1 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 areATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE, and XEU. On 1 January2007, ISO announced a similar deletion for the SIT.

For certain message types, when NCDs are used as the currency of settlement, SWIFTvalidates to ensure that the value date is not after the date on which the currencies ceased tobe a legal tender:

• When ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, thevalue date must not be after 31 December 2001.

• When the Slovenian currency code SIT is used, the value date must not be after 31December 2006.

• When the Cyprus currency code CYP or the Maltese currency code MTL are used, the valuedate must not be after 31 December 2007.

• When the Slovakian currency code SKK is used, the value date must not be after 31December 2008.

• When the Estonian currency code EEK is used, the value date must not be after 31December 2010.

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) inthe relevant fields of its message types.

8.2 Euro-Related Information (ERI)Introduction

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

8.2.1 ERI Content

Overview

Euro-Related Information (ERI) refers to the following data:

• original currency

• original amount

• transaction charges

Euro-Related Information (ERI)

23 July 2010 69

NEXT VERSI

ON

NEXT VERSI

ON

The original currency and amount in ERI is the equivalent of the information in the fieldcontaining the amount which is used for interbank settlement of the transaction. This field maycontain additional information, for example, value date.

ERI may be specified in one of several free-text fields preceded by a code. As of StandardsRelease 2001, the use of ERI was extended to non-European currencies and beyond thetransition period of 3 years.

In the Corporate Action messages within Category 5, codes are used to indicate the processingof redenominations.

8.2.2 ERI Usage Guidelines and Rules

Introduction

The specification of ERI is always optional. If used, however, the rules specified in this sectionapply.

These rules include:

• 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 thetransaction amount and the original ordered amount are quoted (for example, field 36 in theMTs 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

The following rules must be adhered to:

• ERI may be used only when the message does not have a specific existing field to specifythe 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. Forexample, all ISO 15022 compliant Category 5 Trade Initiation and Confirmation (TIC),Settlement and Reconciliation (S&R) and Corporate Action (CA) messages contain specificfields for this purpose, as does the MT 103.

• As with all other information occurring in fields 72, 77A or 79, ERI is for information purposesonly.

In the case of a discrepancy between ERI and the settlement amount (for example, netproceeds), specified in the message, the information in the settlement amount prevails.

Usage guidelines

Guidelines when specifying fields are:

• If no specific fields are available to specify the original currency and amount, ERI may beused in any message type containing a free text field 72, 77A or 79. The use of ERI is notrestricted to specific message types. See "Messages Likely to Contain ERI" on page 72.



NEXT VERSI

ON

NEXT VERSI

ON

• The preferred field for specifying ERI is field 72. If not present, field 77A should be used. Ifthere 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 mayneed 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 isused for other purposes, field 86 should be used to specify ERI. It is recommended that thesender 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 freetext field, the message should be used as a single transaction message, that is, onemessage should be used per transaction.

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

• ERI is designed to be passed on unchanged in the appropriate message types throughoutthe 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

Format

Field 72 6*35x

Field 77A 20*35x

Field 79 35*50x

Definition

In addition to previously defined sender to receiver information, or other narrative information,these fields may include Euro-Related Information (ERI) for information purposes. ERI indicatescurrency conversion details, related to the conversion of the original currency into a settlementcurrency, found in free text fields.

It is recommended that ERI be structured in these free text fields, using codes.

Codes

The following codes must be used

/OCMT/ 3!a15d/ O Original currency and amount.

If no charges are specified then theoriginal currency and amount will be theequivalent of the transaction amountspecified in the message.


23 July 2010 71

NEXT VERSI

ON

NEXT VERSI

ON

/CHGS/ 3!a15d/ O Currency and amount of the transactioncharges.

When the BEN option is used inpayments and related messages, that is,all transaction charges are to be paid bythe beneficiary customer, the chargesamount has been deducted from theoriginal amount to obtain the settlementamount 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 ERIIntroduction

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 afree text field. Message types that already contain a field to specify an original currency andamount, are not included here.

If there are business requirements to specify ERI in other message types, these should besimilarly 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 SettlementAmount Field

Repetitive /NonRepetitive

ERIField

Repetitive/NonRepetitive

202 GeneralFinancialInstitutionTransfer

32A Value Date,Currency Code,Amount

NR 72 NR

202COV

GeneralFinancialInstitutionTransfer


NR 72 NR

203 Multiple GeneralFinancialInstitutionTransfer

32B CurrencyCode, Amount

R 72 R



NEXT VERSI

ON

NEXT VERSI

ON



ERIField


204 FinancialMarkets DirectDebit Message


R 72 R

205 FinancialInstitutionTransferExecution


NR 72 NR

205COV

FinancialInstitutionTransferExecution


NR 72 NR

207 Request forFinancialInstitutionTransfer


R 72 NR

400 Advice ofPayment

33A ProceedsRemitted

NR 72 NR

405 Clean Collection 32a Proceeds to beRemitted in seq C

NR 72, seqA

NR

32a Proceeds to beRemitted in subseqB3

N(1) 72, seqB

NR

450 Cash LetterCredit Advice


R 72 NR

455 Cash LetterCreditAdjustmentAdvice

33a Value Date andAdjustment Amount

R 72 NR

456 Advice ofDishonour

33D Total AmountDebited

R 72 NR

559 Paying Agent'sClaim

34A Net Proceeds NR 72 NR

581 CollateralAdjustmentMessage

34B OutstandingCollateral Value

NR 72 NR

582 ReimbursementClaim or Advice

34A Net AmountClaimed/Paid

NR 79 NR

752 Authorisation toPay, Accept orNegotiate

33a Net Amount NR 72 NR

754 Advice ofPayment/Acceptance/Negotiation

34a Total AmountClaimed

NR 72 NR

756 Advice ofReimbursementor Payment

33A AmountReimbursed or Paid

NR 72 NR


23 July 2010 73

NEXT VERSI

ON

NEXT VERSI

ON



ERIField


768 Acknowledgement of aGuaranteeMessage

32a Amount ofCharges

NR 72 NR

769 Advice ofReduction orRelease

32a Amount ofCharges

NR 72 NR

900 Confirmation ofDebit


NR 72 NR

910 Confirmation ofCredit


NR 72 NR

940 CustomerStatementMessage

subfield 5 of field 61 R 61/9 or86

R

942 InterimTransactionReport

subfield 5 of field 61 R 61/9 or86

R

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

8.3.2 Messages Containing a Special Field for OriginalAmount

List of message types containing a special field for original amount

The following lists message types that already have a special field for specifying an originalamount to be transferred. This list is not exhaustive, as there may be other messages withspecial fields specifying an original amount.

MT MT Name SettlementAmountField


ERI Field Repetitive/NonRepetitive

101 Request forTransfer

32B R 33B R

102 MultipleCustomerCredit Transfer

32B R 33B R

102+

103 SingleCustomerCredit Transfer

32A NR 33B NR

103+

103REMIT

104 Direct Debitand Requestfor DebitTransfer

32B R 33B R

107 General DirectDebit Message

32B R 33B R



NEXT VERSI

ON

NEXT VERSI

ON

MT MT Name SettlementAmountField


ERI Field Repetitive/NonRepetitive

513 Client Adviceof Execution

19A::SETT NR 19A::OCMT NR

514 TradeAllocationInstruction


515 ClientConfirmationof Purchase orSale


518 Market-SideSecuritiesTradeConfirmation


528 ETC Client-SideSettlementInstruction


529 ETC Market-SideSettlementInstruction


541 ReceiveAgainstPayment


543 DeliverAgainstPayment


545 ReceiveAgainstPaymentConfirmation

19A::ESTT NR 19A::OCMT NR

547 DeliverAgainstPaymentConfirmation


564 CorporateActionNotification


566 CorporateActionConfirmation


584 Statement ofETC PendingTrades


8.3.3 Messages with Value Date Validation

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

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


23 July 2010 75

NEXT VERSI

ON

NEXT VERSI

ON

If ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, the valuedate 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 generallythe result of earlier validated messages. Furthermore, accounts are no longer heldin any of the discontinued National Currency Denominations (NCDs) mentionedabove.

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 fieldcontaining the value date.

MT MT Name NCD Amount Field Value Date Field

101 Request for Transfer 32B in Seq B (eachoccurrence)

30 in Seq A

102 Multiple CustomerCredit Transfer

32A in Seq C

32A in Seq C

32A in Seq C

32A in Seq C102+

103 CORE Single CustomerCredit Transfer

32A 32A

103+ 32A 32A

103 REMIT 32A 32A

104 Direct Debit andRequest for DebitTransfer Message

32B (each occurrence) 30 in Seq A

104RFDD 32B (each occurrence) 30 in Seq A

107 General Direct DebitMessage

32B in Seq C 30 in Seq A

200 FI Transfer for its OwnAccount

32A 32A

201 Multiple FI Transfer forits Own Account

32B (each occurrence 30

202 General FI Transfer 32A 32A

202 COV General FI Transfer 32A 32A

203 Multiple General FITransfer

32B (each occurrence) 30

204 Financial MarketsDirect Debit Message

32B (each occurrence) 30

205 FI Transfer Execution 32A 32A

205 COV FI Transfer Execution 32A 32A



NEXT VERSI

ON

NEXT VERSI

ON


207 Request for FITransfer Message

32B (each occurrence 30 in Seq A

210 Notice to Receive 32B (each occurrence) 30

400 Advice of Payment 33A 33A

405 Clean Collection 32C in Subseq. B3(each occurrence)

32C

32D in Seq C 32D

450 Cash Letter CreditAdvice

32A (each occurrence) 32A

455 Cash Letter CreditAdjustment Advice

32A 32A

33C 33C

33D 33D

456 Advice of Dishonour 32D (each occurrence) 33D

513 Client Advice ofExecution

Seq C Order DetailsField 19A QualifierSETT

Seq C Order DetailsField 98a QualifierSETT (1)

Seq D3 Amounts Field19A Qualifier SETT

Seq C Order DetailsField 98a QualifierSETT (1)

514 Trade AllocationInstruction

Seq B ConfirmationDetails Field 19AQualifier SETT

Seq B ConfirmationDetails Field 98aQualifier SETT (1)

Seq C3 Amounts Field19A Qualifier SETT

Seq B ConfirmationDetails Field 98aQualifier SETT (1)

515 Client Confirmation ofPurchase or Sale

Seq C ConfirmationDetails Field 19AQualifier SETT

Seq C ConfirmationDetails Field 98aQualifier SETT

Seq D3 Amounts Field19A Qualifier SETT

Seq C ConfirmationDetails Field 98aQualifier SETT

518 Market-Side SecuritiesTrade Confirmation


Seq B ConfirmationDetails Field 98aQualifier SETT



528 ETC Client-SideSettlement Instruction



Seq B ConfirmationDetails Field 19AQualifier SEBL





23 July 2010 77

NEXT VERSI

ON

NEXT VERSI

ON


529 ETC Market-SideSettlement Instruction





541 Receive AgainstPayment

Seq E3 Amounts Field19A Qualifier SETT

Seq B Trade DetailsField 98a QualifierSETT

543 Deliver AgainstPayment

Seq E3 Amounts Field19A Qualifier SETT

Seq B Trade DetailsField 98a QualifierSETT

545 Receive AgainstPayment Confirmation

Seq E3 Amounts Field19A Qualifier ESTT

Seq B Trade DetailsField 98a QualifierSETT (1)

547 Deliver AgainstPayment Confirmation

Seq E3 Amounts Field19A Qualifier ESTT

Seq B Trade DetailsField 98a QualifierSETT (1)


Seq E2 CashMovement Field 19BQualifier ENTL

Seq E2 CashMovement Field 98aQualifier PAYD(2)


Seq E2 CashMovements Field 19BQualifier ENTL (eachoccurrence)

Seq E2 CashMovements Field 98aQualifier VALU(3)

566 Corporate ActionConfirmation

Seq D2 CashMovement Field 19BQualifier PSTA

Seq D2 CashMovement Field 98aQualifier POST

584 Statement of ETCPending Trades

Seq B2b Trade DetailsField 19A QualifierSETT (eachoccurrence)

Seq B2b Trade DetailsField 98a QualifierSETT (1)

Seq B2b2 AmountsField 19A QualifierSETT

Seq B2b Trade DetailsField 98a QualifierSETT (1)

Seq C1c Trade DetailsField 19A QualifierSETT

Seq C1c Trade DetailsField 98a QualifierSETT (1)

Seq C1c2 AmountsField 19A Qualifier

Seq C1c Trade DetailsField 98a QualifierSETT (1)

730 Acknowledgement 32D 32D

734 Advice of Refusal 33A 33A

742 Reimbursement Claim 34A 34A

752 Authorisation to Pay,Accept or Negotiate

33A 33A

754 Advice of Payment/Acceptance/Negotiation

34A 34A



NEXT VERSI

ON

NEXT VERSI

ON


756 Advice ofReimbursement orPayment

33A 33A

768 Acknowledgement of aGuarantee Message

32D 32D

769 Advice of Reduction orRelease

32D 32D

800 T/C Sales andSettlement Advice[Single]

32A in Seq B 32A in Seq B

802 T/C Settlement Advice 32A 32A

900 Confirmation of Debit 32A 32A

910 Confirmation of Credit 32A 32A

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

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

98B:: is used, the validation is not performed)

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

98B:: is used, the validation is not performed)

8.4 ERI Validation and ExamplesIntroduction

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

8.4.1 General ERI Validation Rules

Rules

Codes and format:

• /OCMT/3!a15d/

• /CHGS/3!a15d/

Where:

• The currency component 3!a must be a valid currency code (Error Code T52).

• The amount component 15d following the currency code must be formatted according to theField 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 orother generic error codes as deemed necessary.

• The amount component 15d will not be checked on the maximum number of decimal digitsallowed for the relevant currency code.


23 July 2010 79

NEXT VERSI

ON

NEXT VERSI

ON

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 CodeT31). In the following example the amount component is invalid. The message isNAKed:

:86:/OCMT/EUR1,23(CrLf)

8.4.2 Messages and Fields Impacted

Rules

The ERI validation will be performed in fields:

• 72 Structured Format, 72 ISITC Structured Format, 72 Narrative, 77A and/or 79, of allmessages except the MTs 104, n92, n95, n96 and n99

• 61 (subfield 9) and 86, of the MTs 940 and 942

Examples

The messages are not NAKed:

• OCMT is validated

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

• OCMT and CHGS are validated

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

8.4.3 No ERI Validation Hierarchy between the Fields

Rules

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

Example

For example, if fields 72, 77A and 79 are all present in a message, and the ERI validation isdefined for that message, the system will apply the ERI validation in the three types of fields.



NEXT VERSI

ON

NEXT VERSI

ON

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

Rule

The ERI validation for the code /CHGS/ (6 characters) will be performed only if it immediatelyfollows /OCMT/3!a15d/ in the same occurrence of that field. Therefore, if /OCMT/ is present infield 72, and /CHGS/ is present in field 79 (but /OCMT/ is not present in 79), the system doesnot validate the format following /CHGS/ in field 79.

Example

In the following example, CHGS is not validated because OCMT is missing. The message is notNAKed:

:86:xxxxx/CHGS/EUR1,40/xxxxx(CrLf)

8.4.5 Sequence of Codes is Required

Rule

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

It is only if /OCMT/ appears immediately before /CHGS/ that the ERI validation will be appliedto /CHGS/.

Example 1 - structured field 72

CHGS is validated. The message is not NAKed:

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

Example 2 - free format field 79

OCMT is validated. The message is not NAKed:

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


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

:72:xxxxxxxxxx(CrLf)//xxxxxxxxxx(CrLf)/OCMT/EUR1000,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)/CHGS/EUR5,/(CR)//xxxxxxxxxx(CrLf)Note: if /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the ERI andwill not be subject to the ERI validation.


Only OCMT is validated. The message is not NAKed:

:72:/CHGS/EUR12,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)//xxxxxxxxxx(CrLf)/OCMT/EUR12345,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)


23 July 2010 81

NEXT VERSI

ON

NEXT VERSI

ON


Only OCMT is validated. The message is not NAKed:

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


OCMT and the second occurrence of CHGS are validated. The message is not NAKed:

:72:/CHGS/EUR1,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)//xxxxxxxxxx(CrLf)/OCMT/EUR12345,/(CrLf)/CHGS/EUR12,/xxxxx(CrLf)

8.4.6 Double Codes are not Allowed in one Field

Rule

In one occurrence of a field where the ERI validation must be performed, the codes /OCMT/and /CHGS/ must not be used more than once.

Note 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 messagewhere the error occurred, will be indicated, together with the error code.


OCMT is found twice. The message is NAKed:

:72:/OCMT/EUR12345,/(CrLf)//xxxxxx(CrLf)/OCMT/EUR100,/xxxxx(CrLf)

Example 2 - field 61


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



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


CHGS is found twice. The message is NAKed:

:72:xxxxxxxxxx(CrLf)//xxxxxxxxxx(CrLf)/OCMT/EUR10000,/(CrLf)/CHGS/EUR100,/xxxxxxxxxx(CrLf)/CHGS/EUR50,/(CR)//xxxxxxxxxx(CrLf)

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



NEXT VERSI

ON

NEXT VERSI

ON


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)


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 Consistent with Current Standards

Rule

In all fields where the ERI validation is defined, the generic that is, current, validation must stillbe 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 Maximum Use of the Generic Format Definition

Rule

In order to maximise the use of all characters allowed in the generic format, the codes /OCMT/, /CHGS/, as well as the data (3!a15d/), may be split across lines.

Examples

Narrative format of information that follows ERI-related codes split across lines:

:72:xxxxx/OCMT/EUR12345,(CrLf)12//CHGS/ (CrLf)EUR12,/(CrLf)Structured format of ERI-related codes split across lines:

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

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


23 July 2010 83

NEXT VERSI

ON

NEXT VERSI

ON

8.4.9 No ERI Validation

Rules

SWIFT does not perform network validation on the Euro-Related Information in:

• Fields 72 and 79, if the REJT or RETN codes are present, that is, the special REJT/RETNvalidation 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.

2. Scan for /OCMT/

If /OCMT/ is:

• not present, then perform next field validation

• present more than once, then NAK the message with the error code T47 and terminatethe validation

• present only once, then validate the format <3!a15d/>

If format is:

– valid, then go to point 3

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

3. Check for /CHGS/ immediately after /OCMT/3!a15d/.

If /CHGS/ is:






NEXT VERSI

ON

NEXT VERSI

ON

If format is:

– valid, then go to next field 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:

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

• /<2!a>/[31x] or

• /<3!a>/[30x] or

• /<4!a>/[29x] or

• /<5!a>/[28x] or

• /<6!a>/[27x] or

• /<7!a>/[26x] or

• /<8!a>/[25x]

Validation


1. maximum 6 lines, maximum 35 characters per line (<X> character set)

2. first line as <INSTR>, per the format defined here above

3. second through sixth line

If present, defined as : <INSTR> or <'//' 33x>:

• if the 3 checks here above are OK, then go to point 4

• otherwise the message is NAKed, with the corresponding error code

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

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

6. scans for /OCMT/

If /OCMT/ is:


• present more than once (double), then NAK the message with the error code T47 andterminates the validation

• present only once, then validates the format <3!a15d/>


23 July 2010 85

NEXT VERSI

ON

NEXT VERSI

ON

If format is:


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

7. checks for /CHGS/ immediately after /OCMT/3!a15d/

If /CHGS/ is:

• not present, then performs next field validation



If format is:



8.4.10.3 Field 72 (Narrative)

Format

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

Validation



2. second through sixth line, if present, defined as 35x

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


4. scans for /OCMT/

If /OCMT/ is:



• is present only once, then validates the format <3!a15d/>



NEXT VERSI

ON

NEXT VERSI

ON

If format is:



5. checks for /CHGS/ immediately after /OCMT/3!a15d/.

If /CHGS/ is:




If format is:



8.4.10.4 Field 77A (Narrative)

Format

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

Validation



2. second through 20th line


• if the 2 checks here above are OK, then go to point 3



4. scans for /OCMT/

If /OCMT/ is:





23 July 2010 87

NEXT VERSI

ON

NEXT VERSI

ON

If format <3!a15d/> is:




If /CHGS/ is:




If format is:




Format

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

Validation



2. second through 35th line


• if the 2 checks (point 1) are OK, then go to point 3



4. scans for /OCMT/

If /OCMT/ is:






NEXT VERSI

ON

NEXT VERSI

ON

If format is:




If /CHGS/ is:




If format is:




Format

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

Validation



2. second through sixth line


• if the 2 checks (point 1) are OK, then go to point 3

• otherwise the message is NAKed, with the corresponding error code


4. scans for /OCMT/

If /OCMT/ is:





23 July 2010 89

NEXT VERSI

ON

NEXT VERSI

ON

If format is:




If /CHGS/ is:


• present more than once (double), then NAK the message with the error code T47 andterminate the validation


If format is:





NEXT VERSI

ON

NEXT VERSI

ON

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 publicationoutside 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 latestavailable 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 inthis publication are trade names, trademarks, or registered trademarks of their respective owners.

Legal Notices

23 July 2010 91

http://www.swift.com/

General Mt SWIFT

Documents

Transcript of General Mt SWIFT