Standards MT November 2021 General Information This document provides information about all Standards MT (message type) categories, and explains the general rules, conventions, and principles for the Standards MTs. The document explains the organisation of the Standards documentation and the benefits of message standards. This document also provides a description of the ISO Business Identifier Code. This document is for all SWIFT customers (this includes operators and application developers), vendors, and service bureaux. 23 July 2021 Link to this document: https://www2.swift.com/go/book/book31821 Standards MT November 2021 General Information Table of Contents Table of Contents Preface............................................................................................................................................................... 4 Significant Changes..........................................................................................................................................5 1 2 Standards MT Volumes Description...................................................................................................... 6 1.1 Volume/Chapter Explanation................................................................................................................... 6 1.2 Standards MT Volumes........................................................................................................................... 7 1.3 Formatting Explanation.......................................................................................................................... 11 Introduction to Standards MT.............................................................................................................. 16 2.1 Reason for Standards MT......................................................................................................................16 2.2 Standards Development and Implementation Process..........................................................................16 2.3 Standards Maintenance Process...........................................................................................................16 2.4 Message Envelope Structure.................................................................................................................17 2.5 Message Validation Description.............................................................................................................18 3 Business Identifier Code (BIC).............................................................................................................19 4 Characters..............................................................................................................................................20 5 6 7 4.1 SWIFT Character Set (X Character Set)............................................................................................... 20 4.2 EDIFACT Level A Character Set (Y Character Set).............................................................................. 20 4.3 Information Service Character Set (Z Character Set)............................................................................20 4.4 Representation of Non-SWIFT Characters............................................................................................21 Message Structure and Message Types..............................................................................................23 5.1 SWIFT Message Structure.................................................................................................................... 23 5.2 SWIFT Message Types ........................................................................................................................ 23 5.3 Message Length and Structure..............................................................................................................47 5.4 Message Structure Example..................................................................................................................48 Field Structure and Field Formatting Rules........................................................................................49 6.1 General Rules........................................................................................................................................49 6.2 Field Structure ...................................................................................................................................... 49 6.3 Field Formatting ....................................................................................................................................52 Euro-Related Information (ERI) ........................................................................................................... 70 7.1 23 July 2021 Deletion of National Currency Denomination (NCD) Currency Codes.................................................. 70 2 Standards MT November 2021 General Information Table of Contents 7.2 Euro-Related Information (ERI)............................................................................................................. 70 7.3 Message Specific Guidelines on the Use of ERI................................................................................... 73 7.4 ERI Validation and Examples................................................................................................................ 79 Legal Notices................................................................................................................................................... 90 23 July 2021 3 Standards MT November 2021 General Information Preface Preface Purpose of the document This document provides information about all Standards MT (message type) categories, and explains the general rules, conventions, and principles for the Standards MTs. The document explains the organisation of the Standards documentation and the benefits of message standards. This document also provides a description of the ISO Business Identifier Code. Audience This document is for all SWIFT customers (this includes operators and application developers), vendors, and service bureaux. CAUTION 23 July 2021 This volume contains information effective as of the November 2021 Standards release. Therefore the 24 July 2020 edition of the Standards MT User Handbook volumes remains effective until November 2021. 4 Standards MT November 2021 General Information Significant Changes Significant Changes The following tables list significant changes to the content of the Standards MT General Information since the 24 July 2020 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document. 23 July 2021 New information Location Addition of MT 761, MT 765, MT 775, MT 785, MT 786, and MT 787 SWIFT Message Types on page 23 Updated information Location Update name of MT 760 and MT 767 SWIFT Message Types on page 23 Network validated rules Option F: Party Identifier/Name and Address on page 61 5 Standards MT November 2021 General Information Standards MT Volumes Description 1 Standards MT Volumes Description 1.1 Volume/Chapter Explanation Standards MT volumes All SWIFT messages exchanged between users must accord with the message text standards described in the Standards MT volumes. To achieve this, it may be necessary for some users to make changes to their policies and procedures to bring their communications in line with those of the SWIFT community. The Standards MT volumes describe the message text standards which have been developed by representatives from the user community, and which are currently in effect. They consist of: • Standards MT General Information • General Field Definitions Plus Ten category volumes containing the respective message text standards: • Category 1 - Customer Payments and Cheques - Message Reference Guide • Category 2 - Financial Institution Transfers - Message Reference Guide • Category 3 - Treasury Markets - Foreign Exchange, Money Markets, and Derivatives This category consists of 2 volumes: - Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message Reference Guide - Volume 1 (MT 300 - MT 341) - Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message Reference Guide - Volume 2 (MT 350 - MT 399) • Category 4 - Collections and Cash Letters - Message Reference Guide • Category 5 - Securities Markets This category consists of 4 volumes: • - Category 5 - Securities Markets - Message Reference Guide - Volume 1 (MT 500 - MT 518) - Category 5 - Securities Markets - Message Reference Guide - Volume 2 (MT 519 - MT 543) - Category 5 - Securities Markets - Message Reference Guide - Volume 3 (MT 544 - MT 567) - Category 5 - Securities Markets - Message Reference Guide- Volume 4 (MT 568 - MT 599) Category 6 This category consists of 2 books: 23 July 2021 - Category 6 - Treasury Markets - Commodities - Message Reference Guide - Category 6 - Reference Data - Message Reference Guide • Category 7 - Documentary Credits and Guarantees/Standby Letters of Credit - Message Reference Guide • Category 8 - Travellers Cheques - Message Reference Guide • Category 9 - Cash Management and Customer Status - Message Reference Guide • Category n - Common Group Messages - Message Reference Guide 6 Standards MT November 2021 General Information Standards MT Volumes Description Additional Standards MT volumes To assist users, usage guidelines have been published in additional Standards MT volumes for specific categories of messages. These volumes contain guidelines for using message standards. The volumes are: • Standards MT Usage Guidelines • Category 3 - Treasury Markets - Foreign Exchange, Money Markets and Derivatives Message Usage Guidelines • Category 5 - Securities Markets Message Usage Guidelines Additional volumes are issued separately for: • advance information, published as the Standards Release Guide • supplementary information, as appropriate 1.2 Standards MT Volumes 1.2.1 Standards MT General Information Volume Overview The Standards MT General Information volume contains information which is pertinent to all categories of messages. It includes, for example, an explanation of how the information is organised, the benefits of using message standards, and the description of the Business Identifier Code. Chapters description Chapter Description 1 - Standards MT Volumes Description on page 6 This chapter contains: 2 - Introduction to Standards MT on page 16 23 July 2021 • a description of the information which is contained in each volume of the Standards MT documentation set • an explanation of the presentation of field definitions, category information, and message type formats This chapter contains: • a description of the reasons message standards are needed, including the benefits realised through their proper use • information about the method used by SWIFT to update current standards, and to develop new ones, in order to ensure compatibility with current financial practices • a list of the standard development organisations SWIFT consults with when developing message text formats and definitions • a brief description of the format checking performed by the SWIFT system on outgoing SWIFT messages 7 Standards MT November 2021 General Information Standards MT Volumes Description Chapter Description 3 - Business Identifier Code (BIC) on page 19 This chapter contains a brief description of the Business Identifier Code. For more information on the BIC format and use of the BIC in SWIFT messages, see the BIC Policy. 4 - Characters on page 20 This chapter lists the allowable characters in the X-, Y-, and Zcharacter sets. 5- Message Structure and This chapter contains: Message Types on page • definitions and illustrations of the structure of a message 23 • a description of the purpose of the category designation within the message type (MT) number and how the category may be used to aid the internal routing of messages • a list of all SWIFT message types 6 - Field Structure and In addition to general rules for field structure and field Field Formatting Rules on formatting, this chapter also covers field formatting rules for page 49 the following elements: • Dates • Numbers • Currency Codes • Party Identification • Times • Value Date Ordering 7- Euro-Related This chapter contains guidelines for using existing SWIFT Information (ERI) on page message standards for transactions involving the euro. 70 1.2.2 Standards MT General Field Definitions Plus Overview The General Field Definitions Plus provides a general description of all message-text fields. It also provides information about the FIN error codes and the FIN system messages. Information which applies to fields in a specific message, for example, field usage and codes, is found in the description of the message type within the Standards category message reference guides. 23 July 2021 8 Standards MT November 2021 General Information Standards MT Volumes Description Description The General Field Definitions Plus contains a description of each field, including: 1.2.3 • format options • definition • network validated rules • usage rules • relevant message types • codes Category Volumes: Message Text Standards Message text standards for individual messages within each category are contained in the category volumes: • Category 1 - Customer Payments and Cheques • Category 2 - Financial Institution Transfers • Category 3 - Treasury Markets - Foreign Exchange, Money Markets, and Derivatives • Category 4 - Collection and Cash Letters • Category 5 - Securities Markets • Category 6 - Treasury Markets - Commodities • Category 6 - Reference Data • Category 7 - Documentary Credits and Guarantees/Standby Letters of Credit • Category 8 - Travellers Cheques • Category 9 - Cash Management and Customer Status • Category n - Common Group Messages Each volume provides the information as described in the following table: 23 July 2021 Section Description Introduction This section contains a description of the function and use of the message category. It also indicates what has changed in the book since its previous publication, and explains how the book, and each message type, is structured. Category Message Types This section lists and briefly describes the message types defined within the category. It also indicates: • whether the message type requires authentication • the maximum length allowed • whether the use of the message type requires registration with SWIFT in a Message User Group • information about how to register for a Message User Group 9 Standards MT November 2021 General Information Standards MT Volumes Description Section Description Message Type Description This section contains detailed descriptions of each message type within the category. Including: Glossary of Terms 1.2.4 • MT Scope • MT Format Specifications • MT Network Validated Rules • MT Usage Rules • MT Guidelines • MT Field Specifications • MT Mapping • MT Examples • additional information about the MT as required Terms and definitions that are used throughout the category. Additional Volumes Additional volumes contain recommendations for using messages in specific business situations. They also provide special information about more than one message type, or across more than one category of message type. These usage guidelines are recommendations and are provided for information. They do not form part of the SWIFT message text standards. 23 July 2021 Volume Description Standards MT Usage Guidelines This document explains how to use message standards. In addition, the document identifies specific issues that relate to message standards, and provides clarification (and examples) of message standards. This document is for all users of Standards messages. Category 3 - Treasury Markets Foreign Exchange, Money Markets and Derivatives Message Usage Guidelines This document provides information about support for derivatives in Standards Category 3 messages. In particular, the document contains specific information about the MT 300, MT 305, MT 306, and MT 396, as well as guidance that is equally relevant to other MTs. This document is for users of Standards Category 3 messages that trade derivatives. Category 5 - Securities Markets Message Usage Guidelines This document provides information about the ISO 15022 securities message standards for trade initiation and confirmation, settlement and reconciliation, and corporate actions. This document is for all users of ISO 15022 securities message standards. 10 Standards MT November 2021 General Information Standards MT Volumes Description 1.3 Formatting Explanation 1.3.1 Field Definition Format The General Field Definitions Plus contains the following information per field. Name Description Definition A description of the field. Additional information which applies to a specific category, or message type, will appear in the field specifications for that message type. Format Options The specification of available options, or alternative formatting possibilities, for the field. The format options include restrictions on length and types of characters allowed. 1.3.2 Usage Rules Additional information pertaining to use of the field. Network Validated Rules Any restrictions on use, for example, a double slash '//' is not permitted within field 20. Message Type Use A matrix showing the message types which use the specified field. Codes A matrix showing the message types which use the specified code. Message Type Descriptions Introduction The ten category volumes contain general information for the category and the detailed description of each message type. For each message type, the following information is provided. Note 23 July 2021 For the ISO 15022 securities messages in Category 5, the format specification and field specifications are presented in a slightly different way. For further explanations, see Category 5 - Securities Markets Message Usage Guidelines. 11 Standards MT November 2021 General Information Standards MT Volumes Description Example of an information flow The following symbols are used to identify the parties involved in the message flow: Legend Originator of the transaction Financial institution Bank Corporate Customer Sender or Receiver Other parties involved in the transaction MT The actual SWIFT Message MT nnn MT nnn Another SWIFT message involved in the transaction Financial institution or customer relationship Financial institution Bank Corporate Customer D0200001 Final recipient In the diagrams, each customer, or financial institution, is identified by the tag number of the corresponding field, for example, 50a, Ordering Customer. Message type scope The scope of a message specifies the sender and receiver of the message and provides an explanation about how the message is used. In some messages, an example of the message flow is also provided. 23 July 2021 12 Standards MT November 2021 General Information Standards MT Volumes Description Message type format specifications MT nnn (Message Type name) The format specifications are the rules for the layout of the message type. This information is provided in a table as shown below: Status Tag Field Name Content/Options No. M 20 Transaction Reference Number 16x 1 M 21 Related Reference 16x 2 Mandatory Sequence A (Sequence Name) M 25 Account Identification 35x 3 M 32A Value Date, Currency Code, Amount 6!n3!a15d 4 ----> Optional Repetitive Sequence B (Sequence Name) O 52a Ordering Institution A or D 5 M 71B Detail of Charges 6*35x 6 O 72 Sender to Receiver Information 6*35x 7 ----| M = Mandatory O = Optional - Network Validated Rules may apply MT nnn (Message Type name) provides the message type number and name. The table headings have the following meanings: • Status indicates if the field is: - M = Mandatory - O = Optional - Network Validated Rules may apply The status M for fields in optional (sub)sequences means that the field must be present if the (sub)sequence is present, and is otherwise not allowed. • Tag is the field identification. • Field Name is the detailed name of the field tag, for this message type. • Content/Options provides permitted field length and characteristics. • No. identifies the number of the field in the field specifications for the message type. It is also called Index. Only fields and field tag options, which are shown in the message format, may be used in that message type. 23 July 2021 13 Standards MT November 2021 General Information Standards MT Volumes Description Some message formats are separated into sequences of fields, as shown below. An arrow indicates that a sequence of fields may be repeated: Status Tag Field Name Content/Options No. First sequence 1 2 ----> Second sequence 3 4 ----| Third sequence 5 6 7 M = Mandatory O = Optional - Network Validated Rules may apply The arrows (----> and ----|) indicate that the second sequence may be repeated. MT network validated rules Network validated rules are validated on the network, that is, they are identified with an error code. Rules specified in this section affect more than one field in the message, placing a "condition" on one of the fields specified. They are identified as Cn, or conditional rules. For example, in the MT 202, a rule states that if field 56a (Intermediary) is present, then field 57a (Account With Institution) must also be present (Error code C81). MT usage rules Usage rules are not validated on the network, that is, no error code is defined for them, but are nevertheless mandatory for the correct usage of the message. Rules specified in this section affect more than one field in the message, or more than one SWIFT message. MT market practice rules Market practice rules specify the rules published by a recognised Market Practice Group, for example, for Category 5, the Securities Market Practice Group (SMPG). Market practice rules indicate the existence of a global market practice document on the business process in which the concerned field or message type is used. The absence of a market practice rule notation does not mean that no market practices exist for the concerned field or message type. The presence of a market practice rule is merely an indicator of a known market practice. Furthermore, readers should be aware that in addition to global market practices there may also be country-specific requirements that should be considered when using the field or message type. 23 July 2021 14 Standards MT November 2021 General Information Standards MT Volumes Description MT guidelines Guidelines are not validated on the network and are not mandatory for the correct usage of the message. They concern good practices. Guidelines specified in this section affect more than one field in the message, or more than one SWIFT message. MT field specifications The rules for the use of each field in the message are specified in this section. Each field is identified by its index number (as shown in the No. column of the MT format specifications), field tag and detailed field name, followed by a description of the field. The description may contain some, or all, of the following: 1. FORMAT specifies the field formats which are allowed in the field. 2. PRESENCE indicates if the field is mandatory, optional, or conditional in its sequence. 3. DEFINITION specifies the definition of the field in this sequence of the message type. 4. CODES lists all codes available for use in the field. If there is more than one subfield for which codes are defined, each separate code list will be identified with a CODES heading. When a list of codes is validated by the network, the error code will be specified. 5. NETWORK VALIDATED RULES specifies rules that are validated on the network, that is, rules for which an error code is defined. Generally, rules specified in this section affect only the field in which they appear. In some cases, rules which are validated at the message level, that is, rules which affect more than one field, are repeated in this section. This is the case when the rule does not affect the presence of the field, but information within several fields, for example, a currency which must be the same for more than one field in the message. 6. USAGE RULES specifies rules that are not validated on the network, that is, rules for which no error code is defined, but are nevertheless mandatory for the correct usage of the field. Rules specified in this section affect only the field in which they appear. 7. EXAMPLES provides one or more examples of the field as it will be formatted/used. MT mapping MT mapping explains how to map the fields of the message into another SWIFT message, either of the same, or a different, message type. MT example Examples are provided to illustrate the correct use of a message. Examples always include: • narrative, which provides a brief description of a transaction • information flow, which illustrates the relationships between the parties involved in the message (see below diagram) • SWIFT format, which provides the message using the defined SWIFT format, and providing an explanation, where necessary, of the fields which have been used The sender, receiver, and message type are summarily identified. Trailer contents are not shown. Note 23 July 2021 For further information about the header and trailer, see the FIN Service Description. 15 Standards MT November 2021 General Information 2 Introduction to Standards MT 2.1 Reason for Standards MT Introduction to Standards MT Why Standards MT? The message text standards have been developed to support the business transactions of SWIFT users. To ensure that the multitude of practices and conventions of users are in harmony, financial messages transmitted via the SWIFT network must adhere to the message text standards. Standards enable financial institutions to move from manual to automated initiation and processing of financial transactions. Key benefits There are important benefits which result from standardisation of messages. These include: 2.2 • automation • reduced risk of errors and misunderstandings • reduced operating costs • improved productivity • increased efficiency in processing of messages (routing and preparation) • faster and more cost effective account reconciliation • ability to maintain more comprehensive management information Standards Development and Implementation Process Published processes For details about the standards development and implementation process, see the Standards MT Development and Maintenance Processes. This document was approved by the SWIFT Board of Directors in 2011 and updated in 2018, approved by the Banking Services Committee at the December 2018 meeting. 2.3 Standards Maintenance Process Published processes For details about the standards maintenance process, see the Standards MT Development and Maintenance Processes. This document was approved by the SWIFT Board of Directors. Maintenance projects Maintenance projects aim at maintaining the functionality of existing standards. They are carried out to bring existing standards in line with business changes, or to correct technical problems. 23 July 2021 16 Standards MT November 2021 General Information Introduction to Standards MT There are two ways to submit maintenance requests (change requests) to SWIFT, as follows: • through User Group Chairpersons • through representative market practice groups in which there are SWIFT members Note Individual users and members may only submit maintenance requests to their User Group Chairperson (requests submitted directly to SWIFT are returned). Maintenance deliverables The deliverables are the following: 1. Fifteen months prior to implementation (SR-15), SWIFT publishes a high-level document (for budget and resource allocation). It highlights the potential scope and size of the subject maintenance release, based on the change requests received. These changes must still be validated by a working group and some of them may be reworded, redefined, or even removed. 2. Eleven months prior to implementation (SR-11), SWIFT publishes a revised, high-level document (for budget and resource allocation), which shows only those change requests that were approved by the working groups and accepted by a country vote. 3. Ten months prior to implementation (SR-10), the Standards Release Guide (SRG) provides details of the changes published in the revised, high-level document. 4. An exceptional fast-track maintenance process can be announced in December (SR-10) and can result in additional changes to the Standards Release Guide which will then be published latest seven months prior to implementation (SR-7). 5. Three months prior to implementation (SR-3), the Standards MT User Handbook is available on www.swift.com. 6. The changes are implemented on the network on the Standards release (SR-0) date. Approval process Sixteen months prior to a planned Standards release date (SR-16), the SWIFT Standards department analyses all received change requests. They send the outcome of this analysis to a Maintenance Working Group (MWG) for discussion and approval. MWGs include experts in the business domain and, ideally, in the standards to be maintained. Members are country representatives appointed by their respective User Group Chairperson. The message text formats are developed in line, or in consultation, with various bodies: 1. MWGs review and agree on the validity of the change requests. 2. Country vote takes place on MWG-agreed changes. 3. The Board Standards Committee must approve the country-vote results before the changes are considered final and published in the final-SRG. For more details about any of the processes described in this section, see Standards on www.swift.com, or contact the Support team. 2.4 Message Envelope Structure All messages (financial and system) conform to a defined structure, generally including a header, a message text and a trailer. Note 23 July 2021 For further details about the message structure, see the FIN Service Description. 17 Standards MT November 2021 General Information 2.5 Introduction to Standards MT Message Validation Description Rule The SWIFT system validates the structure of all messages sent via the FIN network. If the SWIFT system finds an error, it will reject the message and inform the sender by a negative acknowledgement (NAK). The NAK will display a text error. Where possible, it will also give the location of the text error by indicating the number of the line on which the error occurred. Exceptions Exceptions to this rule, which may be based on either system constraints or on the logical layout of the message or field, include: • An error code and line number which relates to a network validated rule violation. In these situations, the system may give the line number of the last text line of the message, or if the error occurred within a repetitive sequence, the line number relative to either the beginning or end of the sequence. • An error code and line number which indicate a text error on the previous line. Note For additional information about error codes, see the FIN Error Codes. Some errors, for example, an invalid message type, will prevent any further message validation by the SWIFT system. Message text validation Validation of message text includes checking the following: 23 July 2021 • the correct sequence of fields • the presence of mandatory fields, that is, those required in the message type being sent • the presence of only those permitted optional fields for the message type • correct content, for example, numbers or letters and length for each field/subfield; in some cases, codes are validated • the permitted character set • the presence of the decimal comma in numbers and amounts • in amounts, the correct number of digits appears after the decimal comma for the currency of the message field, for example, not more than 2 for USD • the sum of individual amounts in the message is equal to the sum of amounts • date validity, for example, day not higher than 31 • conditional relationships, that is, the network validated rules for each message type. Depending on system constraints, not all conditional relationships will be validated by the SWIFT system • codes, where an error code is specified in the field specifications of the message description 18 Standards MT November 2021 General Information 3 Business Identifier Code (BIC) Business Identifier Code (BIC) Overview In the financial environment, a number of telecommunication services have defined coding schemes for identifying financial institutions as well as corporate entities. As a result, many financial institutions and some corporates have more than one code assigned, while others have no codes assigned. To ensure the availability of a unique identifier, an International Standard - ISO 9362 - has been established. This standard specifies a universal method for identifying financial institutions and is intended to facilitate automated processing of telecommunication messages. SWIFT is the designated ISO Registration Authority for these ISO codes, and is responsible for their assignment and subsequent publication. BICs in messages Business Identifier Codes (BICs) are used in certain fields of messages (for example, field 53A, Sender's Correspondent, or field 59A, Beneficiary Customer) to identify a party in the transaction. ISO 9362 allows alphanumeric values for the first 4 characters in the BIC, but SWIFT has implemented a more restrictive structure in message types only allowing alphabetic indications for the party prefix (BIC format 4!a2!a2!c[3!c] ). SWIFT, as registration authority, has no plans to issue BICs with numeric characters in the first 4 characters. When a BIC is available (for example, the party to be specified has been assigned a BIC), it should be used whenever possible, as it is standardised and can therefore be automatically processed by the receiver. Both financial institutions and non-financial institutions can be identified with a BIC. Related information For more information about the BIC format and use of the BIC in SWIFT messages, see the BIC Policy on swift.com. 23 July 2021 19 Standards MT November 2021 General Information 4 Characters 4.1 SWIFT Character Set (X Character Set) Characters Description Computer-based terminals communicating with SWIFT use EBCDIC code. When an "x" is indicated in the format of a field, the character set is as follows: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+ CrLf Space The characters Cr and Lf must never be used as single characters and must only be used together in the sequence CrLf, that is, LfCr is not allowed. When the character sequence CrLf is used in a field format with several lines, it is used to indicate the end of one line of text and the start of the next line of text. 4.2 EDIFACT Level A Character Set (Y Character Set) Description In field 77F of MT 105, the EDIFACT level A character set, as defined in ISO 9735, is used. When a "y" is indicated in the format of the field, the character set is as follows: ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 .,-()/='+:?!"%&*<>; Space Other characters are not allowed (Error code M60). 4.3 Information Service Character Set (Z Character Set) Description Some MT fields allow even a broader range of characters to provide additional information. When a "z" is indicated in the format of the field, the characters set is as follows: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 .,-()/='+:?!"%&*<>;{ 23 July 2021 20 Standards MT November 2021 General Information Characters @#_ Cr Lf Space Other characters are not allowed, including the curly bracket '}' (Error code M60). In a field format with several lines, the characters Cr and Lf must never be used as single characters and must only be used together in the sequence CrLf, that is, LfCr is not allowed. When CrLf is used in such fields, it will be interpreted as the end of one line of text and the start of the next line of text. In all other fields, the characters Cr and Lf may be used as single characters or in sequence, such as, CrLf or LfCr. 4.4 Representation of Non-SWIFT Characters Description A number of characters are not allowed in one or more of the SWIFT character sets. To use these characters in a field where the format does not allow it, SWIFT recommends using the character's hexadecimal EBCDIC code, preceded by two question marks (??) as escape sequence. The use of this encoding must be bilaterally agreed between the sender and receiver of the message. The following table lists all the SWIFT EBCDIC codes that can be used for the basic Latin characters that are not found in the X character set: 23 July 2021 Character Description EBCDIC < Less-than sign 4C ! Exclamation mark 4F & Ampersand 50 | Vertical bar 5A $ Dollar 5B * Asterisk 5C ; Semicolon 5E ^ Circumflex 5F % Percent sign 6C _ Low line (underscore) 6D > Greater-than sign 6E ` Grave accent 79 # Number sign 7B @ Commercial At sign 7C 21 Standards MT November 2021 General Information Characters Character Description EBCDIC = Equal sign 7E " Quotation mark 7F ~ Tilde A1 [ Left square bracket AD ] Right square bracket BD { Left curly bracket C0 } Right curly bracket D0 \ Reverse solidus (backslash) E0 Example The character @ will be represented as ??7C in a field that is restricted to characters from the X character set. 23 July 2021 22 Standards MT November 2021 General Information Message Structure and Message Types 5 Message Structure and Message Types 5.1 SWIFT Message Structure Overview All financial messages must conform to the rules of one of the message types described in the Standards MT volumes. Message type (MT) Message structure The message type is composed of three digits, generally defined as: Category Group MT nnn D0200003 Type Where: Category Usually describes, at a general level, the underlying business function of the message. For example: Category 1 = Customer Payments and Cheques. Group Describes the function of the message within the specified category. For example: 11n = Category 1 Cheque Payment Messages. Type Describes the specific function. For example: 112 = Status of a Request for Stop Payment of a Cheque. From the message type (which is located in the header of a message), the receiver of a message can help to determine the message's business and function, as well as the details of its composition. This section provides the general rules for message types. Detailed specifications pertaining to individual messages can be found in the related category volumes. More information concerning the FIN message structure can be found in the FIN Operations Guide. 5.2 SWIFT Message Types Overview The following table lists all message types defined in the Standards MT volumes, effective as of the November 2021 Standards release. 23 July 2021 23 Standards MT November 2021 General Information Message Structure and Message Types For each message type, there is a short description, an indicator that the message type is signed (Y or N), the maximum message length (either 2,000 or 10,000) and whether the use of the message requires registration within a Message User Group (Y or N). Note A Message User Group, for the purposes of this book, is a group of users who have voluntarily agreed to support the specified message type and have registered with SWIFT to send or receive the specified message type. These messages are indicated in the following table, in the column "MUG". (More information about Message User Groups follows this table.) List of Message Types MT MT Name Purpose Signed(1) Max Length MUG 101 Request For Transfer Requests to debit a customer's account held at the receiver or at another institution. Y 10,000 Y 102 Multiple Customer Credit Transfer Conveys multiple payment instructions between financial institutions. Y 10,000 Y Single Customer Credit Transfer Instructs a funds transfer. Y 10,000 N 103 REMIT Single Customer Credit Transfer Instructs a fund transfer. Y 10,000 Y 104 Direct Debit and Request for Debit Transfer Message Conveys direct debit instructions and requests for direct debits between financial institutions. Y 10,000 Y 105 EDIFACT Envelope An envelope which conveys a 2k EDIFACT message. Y 2,000 Y 107 General Direct Debit Conveys direct debit Message instructions between financial institutions. Y 10,000 Y 110 Advice of Cheque(s) Advises or confirms the Y issuance of a cheque to the drawee bank. 2,000 N 111 Request for Stop Payment of a Cheque Y 2,000 N 112 Status of a Request Indicates action(s) taken in Y for Stop Payment of attempting to stop payment a Cheque of a cheque. 2,000 N 102 STP 103 103 STP 23 July 2021 Requests the drawee bank to stop payment of a cheque. 24 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 190 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, and other adjustments. Y 2,000 N 191 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 192 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 195 Queries Requests information relating to a previous message or amendment to a previous message. Y 2,000 N 196 Answers Responds to an MT 195 Y Query or MT 192 Request for Cancellation or other message where no specific message type has been provided for a response. 2,000 N 198 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 199 Free Format Message Contains information for which no other message type has been defined. Y 2,000 N 200 Financial Institution Transfer for its Own Account Requests the movement of Y the sender's funds to its account at another financial institution. 2,000 N 201 Multiple Financial Institution Transfer for its Own Account Multiple of the MT 200. Y 2,000 N 202 General Financial Institution Transfer Requests the movement of funds between financial institutions except if the transfer is related to an underlying customer credit transfer that was sent with the cover method, in which case the MT 202 COV must be used. Y 10,000 N 25 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 202 COV General Financial Institution Transfer Requests the movement of funds between financial institutions, related to an underlying customer credit transfer that was sent with the cover method. Y 10,000 N 203 Multiple General Financial Institution Transfer Multiple of the MT 202. Y 2,000 N 204 Financial Markets Direct Debit Message Claims funds from SWIFT member banks. Y(2) 2,000 Y 205 Financial Institution Transfer Execution Further transmits a transfer Y request domestically except if the transfer is related to an underlying customer credit transfer that was sent with the cover method, in which case the MT 205 COV must be used. 10,000 N 205 COV Financial Institution Transfer Execution Further transmits a transfer Y request domestically, related to an underlying customer credit transfer that was sent with the cover method. 10,000 N 210 Notice to Receive Notifies the receiver that it will receive funds for the sender's account. Y 2,000 N 290 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments. Y 2,000 N 291 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 292 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 295 Queries Requests information relating to a previous message or amendment to a previous message. 2,000 N Y 26 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 296 Answers 298 Signed(1) Max Length MUG Responds to an MT 295 Y Queries message or an MT 292 Request for Cancellation or other message where no specific message type has been provided for a response. 2,000 N Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 299 Free Format Message Contains information for which no other message type has been defined. Y 2,000 N 300 Foreign Exchange Confirmation Confirms information agreed to in the buying/ selling of two currencies. N 10,000 N 304 Advice/Instruction of Advises of or instructs a Third Party Deal settlement of a third party foreign exchange deal. Y 10,000 Y 305 Foreign Currency Confirms information N Option Confirmation agreed to in the buying and selling of vanilla options on currencies. 2,000 N 306 Foreign Currency Confirms information N Option Confirmation agreed to in the buying and selling of exotic options on currencies. 10,000 N 320 Fixed Loan/Deposit Confirmation Confirms the terms of a contract relative to a fixed loan/deposit transaction. N 10,000 N 321 Instruction to Settle a Third Party Loan/ Deposit Advises the trade details Y and instructs the settlement of a fixed term loan/deposit done with a third party financial institution. 10,000 Y 330 Call/Notice Loan/ Deposit Confirmation Confirms the terms of a contract relative to a call/ notice loan/deposit transaction. N 10,000 N 340 Forward Rate Agreement Confirmation Confirms the details of a forward rate agreement. N 10,000 N 27 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 341 Forward Rate Agreement Settlement Confirmation Confirms the settlement details of a forward rate agreement. N 10,000 N 350 Advice of Loan/ Deposit Interest Payment Advises of a loan/deposit interest payment. N 10,000 N 360 Single Currency Interest Rate Derivative Confirmation Confirms the details of a single currency interest rate derivative swap, cap, collar or floor. N 10,000 N 361 Cross Currency Interest Rate Swap Confirmation Confirms the details of a N cross currency interest rate swap transaction. 10,000 N 362 Interest Rate Reset/ Confirms or advises the Advice of Payment reset rates of the floating interest rate(s) in a single or cross-currency interest rate derivative transaction and/or the payment of interest at the end of an interest period. N 2,000 N 364 Single Currency Interest Rate Derivative Termination/ Recouponing Confirmation Confirms the details of the partial or full termination or recouponing of a single currency interest rate swap, cap, collar, or floor. N 10,000 N 365 Cross Currency Interest Rate Swap Termination/ Recouponing Confirmation Confirms the details of the partial or full termination or recouponing of a cross currency interest rate swap. N 10,000 N 370 Netting Position Advice Advises the netting position N of a currency. 10,000 N 380 Foreign Exchange Order Orders to purchase or sell a specific amount of a certain currency. Y 10,000 Y 381 Foreign Exchange Order Confirmation Confirms the execution of an FX order previously sent. Y 10,000 Y 390 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments. N 2,000 N 28 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 391 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. N 2,000 N 392 Request for Cancellation Requests the receiver to N consider cancellation of the message identified in the request. 2,000 N 395 Queries Requests information relating to a previous message or amendment to a previous message. N 2,000 N 396 Answers Responds to an MT 395 N Queries or an MT 392 Request for Cancellation or other message where no specific message type has been provided for a response. 2,000 N 398 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. N 10,000 N 399 Free Format Message Contains information for which no other message type has been defined. N 2,000 N 400 Advice of Payment Advises of a payment under a collection or part thereof. It also handles the settlement of proceeds. Y 2,000 N 410 Acknowledgement Acknowledges receipt of a collection. It also specifies if the collecting bank does not intend to act in accordance with the collection instruction. Y 2,000 N 412 Advice of Acceptance Informs the remitting bank Y of the acceptance of one or more drafts under one collection instruction. 2,000 N 416 Advice of NonPayment/NonAcceptance Advises of the nonpayment or nonacceptance under a previously received collection. 10,000 Y Y 29 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 420 Tracer Enquires about documents sent for collection. Y 2,000 N 422 Advice of Fate and Request for Instructions Advises the remitting bank of the fate of one or more collection documents; usually accompanied by one or more questions or requests. Y 2,000 N 430 Amendment of Instructions Amends collection instructions. Y 2,000 N 450 Cash Letter Credit Advice Confirms that the face Y amount of cash letter(s) received has been credited under usual reserve (subject to final payment). 2,000 N 455 Cash Letter Credit Adjustment Advice Advises the account owner of adjustments made to its account (related to a previous credit for a cash letter). Y 2,000 N 456 Advice of Dishonour Advises the account owner that financial document(s) included in the cash letter have been dishonoured for reasons specified in the advice. Y 2,000 N 490 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. Y 2,000 N 491 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 492 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 495 Queries Requests information relating to a previous message or amendment to a previous message. 2,000 N Y 30 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 496 Answers Responds to an MT 495 Queries message or MT 492 Request for Cancellation or other messages where no specific message type has been provided for the response. Y 2,000 N 498 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 499 Free Format Message Contains information for which no other message type has been defined. Y 10,000 N 500 Instruction to Register Instructs the registration, deregistration or reregistration of a financial instrument at the registration provider. Y 10,000 N 501 Confirmation of Registration or Modification Confirms the registration, deregistration or reregistration of a beneficial owner or shareholder with the registration provider. Y 10,000 N 502(3) Order to Buy or Sell Instructs the purchase or Y sale of a given quantity of a specified financial instrument under specified conditions. 10,000 N 503 Collateral Claim Requests new or additional Y collateral, or the return or recall of collateral. 10,000 Y 504 Collateral Proposal Proposes new or additional Y collateral. 10,000 Y 505 Collateral Substitution Proposes or requests the substitution of collateral held. Y 10,000 Y 506 Collateral and Provides the details of the Exposure Statement valuation of both the collateral and the exposure. Y 10,000 Y 31 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 507 Collateral Status and Processing Advice 508 Signed(1) Max Length MUG Advises the status of a Y collateral claim, a collateral proposal, or a proposal/ request for collateral substitution. 10,000 Y Intra-Position Advice Reports on the movement of securities within the holding. Y 10,000 N 509(3) Trade Status Message Provides information about the status of a previously executed trade. Y 10,000 N 510 Registration Status and Processing Advice Advises the status of a registration instruction or modification. Y 10,000 N 513 Client Advice of Execution Provides brief and early Y information about a securities deal, for example, a block trade that is to be allocated before final confirmation. 10,000 N 514 Trade Allocation Instruction Instructs the allocation of a block trade. Y 10,000 N 515(3) Client Confirmation Provides a detailed of Purchase or Sale accounting of financial instruments purchased or sold by the sender on behalf of the receiver or its client. It may also convey the payment details of the purchase or sale. It may also be sent by, or via an ETC service provider. Y 10,000 N 516 Securities Loan Confirmation Confirms the details of a securities loan, including collateral arrangements. It may also confirm the details of a partial recall or return of securities previously out on loan. Y 2,000 N 517 Trade Confirmation Affirmation Positively affirms the details of a previously received confirmation/ contract note. Y 10,000 N 32 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 518 Market-Side Securities Trade Confirmation 519 Signed(1) Max Length MUG Confirms the details of a Y trade and, where necessary, its settlement to a trading counterparty. 10,000 N Modification of Client Details Instructs the modification of Y client details at the registration provider. 10,000 N 524 Intra-Position Instruction Instructs the movement of securities within the holding. 10,000 N 526 General Securities Lending/Borrowing Message Requests the borrowing of Y securities or notifies the return or recall of securities previously out on loan. It may also be used to list securities available for lending. 2,000 N 527 Triparty Collateral Instruction Performs a specific action on a collateral management transaction. Y 10,000 Y 530 Transaction Processing Command Requests the modification Y of a processing indicator or other non-matching information. 10,000 N 535 Statement of Holdings Reports at a specified time, Y the quantity and identification of securities and other holdings which the account servicer holds for the account owner. 10,000 N 536 Statement of Transactions Provides details of Y increases and decreases of holdings which occurred during a specified period. 10,000 N 537 Statement of Pending Transactions Provides details of pending Y increases and decreases of holdings at a specified time. 10,000 N 538 Statement of IntraPosition Advices Provides details of Y increases and decreases in securities within the holding during a specified period. 10,000 N Y 33 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 540 Receive Free 541 Signed(1) Max Length MUG Instructs a receipt of Y financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction. 10,000 N Receive Against Payment Instructs a receipt of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction. Y 10,000 N 542 Deliver Free Instructs a delivery of Y financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction. 10,000 N 543 Deliver Against Payment Instructs a delivery of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction. Y 10,000 N 544 Receive Free Confirmation Confirms a receipt of Y financial instruments free of payment. It may also be used to cancel or reverse a confirmation. 10,000 N 545 Receive Against Payment Confirmation Confirms a receipt of financial instruments against payment. It may also be used to cancel or reverse a confirmation. Y 10,000 N 546 Deliver Free Confirmation Confirms a delivery of Y financial instruments free of payment. It may also be used to cancel or reverse a confirmation. 10,000 N 547 Deliver Against Payment Confirmation Confirms a delivery of financial instruments against payment. It may also be used to cancel or reverse a confirmation. 10,000 N Y 34 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 548 Settlement Status and Processing Advice Advises the status of a settlement instruction or replies to a cancellation request. Y 10,000 N 549 Request for Statement/Status Advice Requests a statement or a status message. Y 10,000 N 558 Triparty Collateral Status and Processing Advice Provides validation results and status advice re collateral instructions and proposed collateral movements. Y 10,000 Y 564 Corporate Action Notification Provides an account owner Y with details of a corporate action event and the choices available to the account owner. It also provides the account owner with details on the impact a corporate action event will have on a safekeeping or cash account, for example, entitlement calculation. 10,000 N 565 Corporate Action Instruction Instructs the custodian on Y the investment decision made by an account owner relative to a corporate action event. 10,000 N 566 Corporate Action Confirmation Confirms to the account owner that securities and/or cash have been credited/debited to an account as a result of a corporate action event. Y 10,000 N 567 Corporate Action Status and Processing Advice Indicates the status, or a change in status, of a corporate action-related transaction previously instructed by, or executed on behalf of, the account owner. Y 10,000 N 568 Corporate Action Narrative Provides complex instructions or narrative details relating to a corporate action event. Y 10,000 N 35 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 569 Triparty Collateral and Exposure Statement Provides the details of the valuation of both the collateral and the exposure. Y 10,000 Y 575 Report of Combined Reports on all securities Activity and cash activity for a given combination of safekeeping and cash accounts. Y 10,000 Y 576 Statement of Open Orders Provides details of orders to buy or to sell financial instruments, as at a specified date, which have been accepted by the sender, but which have not yet been executed. Y 10,000 N 578 Settlement Allegement Advises the account owner that a counterparty has alleged a settlement instruction on the account owner's account. Y 10,000 N 581 Collateral Adjustment Message Claims or notifies a change Y in the amount of collateral held against securities out on loan or for other reasons. 2,000 N 586 Statement of Settlement Allegements Provides details of pending Y settlement allegements. 10,000 N 590 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. Y 2,000 N 591 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 592 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 595 Queries Requests information relating to a previous message or amendment to a previous message. 2,000 N Y 36 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 596 Answers 598 Signed(1) Max Length MUG Responds to an MT 595 Y Queries or MT 592 Request for Cancellation or other message where no specific message type has been provided for the response. 2,000 N Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 599 Free Format Message Contains information for which no other message type has been defined. Y 2,000 N 600 Commodity Trade Confirmation Confirms the details of a commodity trade and its settlement. N 2,000 N 601 Commodity Option Confirmation Confirms the details of a commodity option contract. N 2,000 N 604 Commodity Transfer/Delivery Order Instructs the receiver to Y transfer by book-entry, or physically deliver, a specified type and quantity of commodity to a specified party. 2,000 N 605 Commodity Notice to Receive Notifies the receiver of an N impending book-entry transfer or physical delivery of a specified type and quantity of commodity. 2,000 N 606 Commodity Debit Advice Advises the receiver of a debit entry to a specified commodity account. N 2,000 N 607 Commodity Credit Advice Advises the receiver of a credit entry to a specified commodity account. N 2,000 N 608 Statement of a Provides the details of all Commodity Account bookings to a commodity account. N 2,000 N 620 Commodity Fixed Loan/Deposit Confirmation N 10,000 Y Confirms a commodity fixed term loan/deposit contract. 37 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types Signed(1) Max Length MUG Standing Settlement Requests SWIFT to create Instruction Update the MT 671 from the MT Notification Request 670 and send to financial institutions. Y 10,000 N 671 Standing Settlement Specifies standing Instruction Update settlement instructions for Notification one or more currencies. Y 10,000 N 690 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. Y 2,000 N 691 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 692 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 695 Queries Requests information relating to a previous message or amendment to a previous message. Y 2,000 N 696 Answers Responds to an MT 695 Queries message or MT 692 Request for Cancellation or other messages where no specific message type has been provided for the response. Y 2,000 N 698 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 699 Free Format Message Contains information for which no other message type has been defined. Y 2,000 N 700 Issue of a Indicates the terms and Documentary Credit conditions of a documentary credit. Y 10,000 N 701 Issue of a Continuation of an MT 700 Documentary Credit for fields 45a, 46a, and 47a. Y 10,000 N MT MT Name 670 Purpose 38 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name 705 Purpose Signed(1) Max Length MUG Pre-Advice of a Provides brief advice of a Y Documentary Credit documentary credit for which full details will follow. 2,000 N 707 Amendment to a Informs the receiver of Documentary Credit amendments to the terms and conditions of a documentary credit. Y 10,000 N 708 Amendment to a Continuation of an MT 707. Y Documentary Credit 10,000 N 710 Advice of a Third Advises the receiver of the Bank's or a Nonterms and conditions of a Bank's documentary credit. Documentary Credit Y 10,000 N 711 Advice of a Third Continuation of an MT 710. Y Bank's or a NonBank's Documentary Credit 10,000 N 720 Transfer of a Advises the transfer of a Documentary Credit documentary credit, or part thereof, to the bank advising the second beneficiary. Y 10,000 N 721 Transfer of a Continuation of an MT 720. Y Documentary Credit 10,000 N 730 Acknowledgement Acknowledges the receipt Y of a documentary credit message and may indicate that the message has been forwarded according to instructions. It may also be used to account for bank charges or to advise of acceptance or rejection of an amendment of a documentary credit. 2,000 N 732 Advice of Discharge Advises that documents Y received with discrepancies have been taken up. 2,000 N 734 Advice of Refusal 10,000 N Advises the refusal of documents that are not in accordance with the terms and conditions of a documentary credit. Y 39 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 740 Authorisation to Reimburse Requests the receiver to honour claims for reimbursement of payment(s) or negotiation(s) under a documentary credit. Y 2,000 N 742 Reimbursement Claim Provides a reimbursement Y claim to the bank authorised to reimburse the sender or its branch for its payments/ negotiations. 2,000 N 744 Notice of NonConforming Reimbursement Claim Notifies the receiver that the sender considers the claim, on the face of it, as not to be in accordance with the instruction in the Reimbursement Authorisation for the reason(s) as stated in this message. Y 2,000 N 747 Amendment to an Authorisation to Reimburse Informs the reimbursing Y bank of amendments to the terms and conditions of a documentary credit, relative to the authorisation to reimburse. 2,000 N 750 Advice of Discrepancy Advises of discrepancies and requests authorisation to honour documents presented that are not in accordance with the terms and conditions of the documentary credit. 10,000 N 752 Authorisation to Pay, Accept or Negotiate Advises a bank which has Y requested authorisation to pay, accept, negotiate, or incur a deferred payment undertaking that the presentation of the documents may be honoured, notwithstanding the discrepancies, provided they are otherwise in order. 2,000 N Y 40 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 754 Advice of Payment/ Acceptance/ Negotiation 756 Advice of Reimbursement or Payment 759 Ancillary Trade Requests or provides Structured Message information, such as a fraud alert or a financing request, concerning an existing trade transaction such as a documentary credit, demand guarantee, standby letter of credit or an undertaking (for example, a guarantee, surety, etc.). 760 Issue of a Demand Guarantee/Standby Letter of Credit Issues or requests the issue of a guarantee or standby letter of credit. 761 765 Signed(1) Max Length MUG Advises that documents Y have been presented in accordance with the terms of a documentary credit and are being forwarded as instructed. This message type also handles the payment/ negotiation. 2,000 N Advises of the Y reimbursement or payment for a drawing under a documentary credit in which no specific reimbursement instructions or payment provisions were given. 2,000 N Y 10,000 N Y 10,000 N Issue of a Demand Guarantee/Standby Letter of Credit May specify the terms and Y conditions of the undertaking, and for a counter-undertaking, may specify the requested terms and conditions of the local undertaking. This message is sent in addition to an MT 760, when the information in the undertaking exceeds the maximum message size of the MT 760. 10,000 N Guarantee/Standby Letter of Credit Demand Demands payment under Y an undertaking and may include a request to extend the expiry date. 10,000 N 41 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 767 Amendment to a Demand Guarantee/ Standby Letter of Credit 768 Acknowledgement of a Guarantee/ Standby Message Signed(1) Max Length MUG Amends a guarantee or Y standby letter of credit which has been previously issued or requests the amendment of a guarantee which the sender has previously requested to be issued. 10,000 N Acknowledges the receipt of a guarantee or standby letter of credit message and may indicate that action has been taken according to instructions. Y 2,000 N 769 Advice of Reduction Advises that a bank has Y or Release been released of its liability for a specified amount under its guarantee or standby letter of credit. 2,000 N 775 Amendment to a Demand Guarantee/ Standby Letter of Credit May specify the terms and Y conditions of the undertaking, and for a counter-undertaking, may specify the requested terms and conditions of the local undertaking. This message is sent in addition to an MT 767, when the information in the undertaking would otherwise exceed the maximum message size of the MT 767. 10,000 N 785 Guarantee/Standby Letter of Credit NonExtension Notification Notifies the beneficiary, if Y applicable, via one or more advising parties, of the non-extension of the referenced undertaking beyond the current expiry date. 2,000 N 786 Guarantee/Standby Letter of Credit Demand Refusal Used by the party obligated Y on the undertaking and to whom a demand for payment has been made, to notify the beneficiary that the demand has been refused. 10,000 N 42 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 787 Guarantee/Standby Letter of Credit Amendment Response Sent to the bank that issued the undertaking amendment (guarantee, demand guarantee, standby letter of credit, or dependent undertaking), either directly or via one or more advising parties, to indicate acceptance or rejection by the beneficiary of the amendment. Y 2,000 N 790 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. Y 2,000 N 791 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 792 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 795 Queries Requests information relating to a previous message or amendment to a previous message. Y 2,000 N 796 Answers Responds to an MT 795 Queries message or MT 792 Request for Cancellation or other messages where no specific message type has been provided for the response. Y 2,000 N 798 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 799 Free Format Message Contains information for which no other message type has been defined. Y 10,000 N 43 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose 801 T/C Multiple Sales Advice 802 Signed(1) Max Length MUG Provides the details Y (excluding the settlement details) of the sales of travellers cheques in cases where the data is lengthy or includes data from several selling agents. 2,000 N T/C Settlement Advice Provides the settlement details of multiple sales of travellers cheques. Y 2,000 N 890 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. Y 2,000 N 891 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. Y 2,000 N 892 Request for Cancellation Requests the receiver to Y consider cancellation of the message identified in the request. 2,000 N 895 Queries Requests information relating to a previous message or amendment to a previous message. Y 2,000 N 896 Answers Responds to an MT 895 Queries message or MT 892 Request for Cancellation or other messages where no specific message type has been provided for the response. Y 2,000 N 898 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. Y 10,000 N 899 Free Format Message Contains information for which no other message type has been defined. Y 2,000 N 900 Confirmation of Debit Advises an account owner of a debit to its account. N 2,000 N 44 Standards MT November 2021 General Information 23 July 2021 Message Structure and Message Types MT MT Name Purpose Signed(1) Max Length MUG 910 Confirmation of Credit Advises an account owner of a credit to its account. N 2,000 N 920 Request Message Requests the account N servicing institution to send an MT 940, 941, 942, or 950. 2,000 N 935 Rate Change Advice Advises the receiver of general rate change(s) and/or rate change(s) which applies to a specific account other than a call/ notice loan/deposit account. N 2,000 N 940 Customer Provides balance and Statement Message transaction details of an account to a financial institution on behalf of the account owner. N 2,000 N 941 Balance Report Provides balance information of an account to a financial institution on behalf of the account owner. N 2,000 N 942 Interim Transaction Report Provides balance and N transaction details of an account, for a specified period of time, to a financial institution on behalf of the account owner. 2,000 N 950 Statement Message Provides balance and transaction details of an account to the account owner. N 2,000 N 970 Netting Statement Provides balance and transaction details of a netting position as recorded by a netting system. N 2,000 N 971 Netting Balance Report Provides balance information for specified netting position(s). N 2,000 N 972 Netting Interim Statement Advises interim balance and transaction details of a netting position as recorded by a netting system. N 2,000 N 45 Standards MT November 2021 General Information MT MT Name Purpose Signed(1) Max Length MUG 973 Netting Request Message Requests an MT 971 or 972 containing the latest available information. N 2,000 N 985 Status Enquiry Requests an MT 986. N 2,000 N 986 Status Report Provides business-related information about a customer or institution. N 2,000 N 990 Advice of Charges, Interest and Other Adjustments Advises an account owner of charges, interest, or other adjustments to its account. N 2,000 N 991 Request for Payment of Charges, Interest and Other Expenses Requests payment of charges, interest, or other expenses. N 2,000 N 992 Request for Cancellation Requests the receiver to N consider cancellation of the message identified in the request. 2,000 N 995 Queries Requests information relating to a previous message or amendment to a previous message. N 2,000 N 996 Answers Responds to an MT 995 N Queries or MT 992 Request for Cancellation or other messages where no specific message type has been provided for the response. 2,000 N 998 Proprietary Message Contains formats defined and agreed to between users and for those messages not yet live. N 10,000 N 999 Free Format Message Contains information for which no other message type has been defined. N 2,000 N (1) (2) (3) 23 July 2021 Message Structure and Message Types A Relationship Management Application (RMA) authorisation is required in order to sign a message with the exception of the MT 670 and MT 671. Although the MT 670 and MT 671 are signed there is no need to set up RMA for these two messages as they are exchanged between the user and SWIFT. For more details on the signing of MT 670 and MT 671, see the FIN Operations Guide. Special registration is needed for the MT 204 - see the FIN Service Description for details. The use of MT 502, MT 509, and MT 515 for investment funds is subject to restrictions - the messages may only be sent or received by institutions that are members of the Funds Closed User Group. For more information, see https://www.swift.com/ our-solutions/global-financial-messaging/securities-messages/funds-distribution/funds-migration or email funds@swift.com. 46 Standards MT November 2021 General Information Message Structure and Message Types Message User Group registration procedure Registration is free of charge. To register to use one or more message types (MTs), submit a registration request (Order Message User Group) through www.swift.com. To withdraw from a Message User Group, use the Terminate your Message User Group subscription. To get the list of other members of a particular Message User Group, please contact Support. 5.3 Message Length and Structure Rules There are several rules which must be followed when structuring financial messages: • There are two alternative message length limitations for financial messages, as explained below. For both alternatives, there is a difference between the message length calculation on input and on output. The total number of characters always includes headers and trailers. (See SWIFT Message Types on page 23 for information about the maximum length per message type.) Alternatives: 23 July 2021 - The number of characters allowed by the SWIFT system on input from a computer-based terminal is 2,000. On output to a computer-based terminal, the system will limit the number of characters to 2,600. - The number of characters allowed by the SWIFT system on input from a computer-based terminal is 10,000. On output to a computer-based terminal, the system will limit the number of characters to 10,600. The number of characters permitted on output for retrieved messages, including headers and trailers, is 11,325. • When calculating the message length, all characters in the message header blocks, the text block, and the trailers block are counted. This includes the beginning of block and end of block characters { and }. Also included in the count are each occurrence of the two characters Cr and Lf that indicate the start of each new line in the text block. • The format of each message type specifies a number of fixed and variable length fields. The presence of these fields may be mandatory or optional. • A field which is not specified in the format specifications for a particular message type must never appear. • A field may appear only once in a sequence, unless repetition is specifically allowed. • Fields are separated by a unique field separator. 47 Standards MT November 2021 General Information 5.4 Message Structure and Message Types Message Structure Example Example: structure of an MT 103 The following example illustrates the structure of a financial message (MT 103) as input by the sender. {1:F01OELBATWWAXXX0975000073} Basic header block {2:I103ABNANL2AXXXXU3003} Application header block {3:{113:URGT}{108:INTLPMTS}{121:5798a701-effe-42e5-8d14-eec27ea3d8ec}} User header block {4: (CrLf) :20:494932/DEV (CrLf) :23B:CRED (CrLf) :32A:030731EUR1958,47 (CrLf) :33B:EUR1958,47 (CrLf) :50K:FRANZ HOLZAPFEL GMBH (CrLf) Text block VIENNA (CrLf) :59:H.F. JANSSEN (CrLf) LEDEBOERSTRAAT 27 (CrLf) AMSTERDAM (CrLf) :70:/INV/ 18042 910412 (CrLf) -} {5:{CHK:123456789ABC}} Note 23 July 2021 Trailer block D0200004 :71A:SHA (CrLf) Basic header, application header, user header, text and trailers blocks are not separated by CrLf. In the above example, the blocks have been shown on separate lines for purposes of clarity. 48 Standards MT November 2021 General Information Field Structure and Field Formatting Rules 6 Field Structure and Field Formatting Rules 6.1 General Rules The following general rules apply to all fields: • The field length and type of character(s), for example, letters, numbers, are specified in the General Field Definitions Plus and in the field specifications for individual message types. • Unless otherwise stated in the Standards MT General Field Definitions Plus or message field specifications, all specified subfields must be present: • - in the order (that is, sequence) specified - with no separator symbols (except a slash '/' or double slash '//' when specified) Square brackets, [ ], around the format of a particular subfield (in a field containing more than one subfield), indicate that the subfield is optional within that field. For example, if the format for a field is '16x[/4x]', up to 16 characters must be present. The following 4 characters, preceded by a slash '/', are optional, and therefore need not be present in the field. • Parentheses, ( ), around the format of two or more subfields indicate that what precedes the brackets applies to all the subfields listed within the brackets. For example, the field format 4*(1!n/33x) indicates that 4 lines are allowed in the field and each line must start with a digit, followed by a slash ('/'), followed by a maximum of 33 characters. • A field format may be shown on two or more lines: 3!n 6!n When this is the case, the information must be formatted with the CrLf character sequence separating each line. Note 6.2 In the ISO 15022 securities messages, generic fields are used to specify Party, Amount, Date, Reference and Other types of data. For further explanation of this approach, see Category 5 - Securities Markets Message Usage Guidelines. Field Structure Structure Delimiter Field tag number Letter option : nn [a] : 23 July 2021 D0200005 Delimiter 49 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Rules Field structure must comply with the following rules: • Each field is identified by a tag which consists of two digits, or two digits followed by a letter option. • Lower case "a" next to the field tag number indicates that there are different formats available to capture the information for this field. When this field is used in an MT, a specific format must be indicated by replacing the lower case "a" with an upper case letter option. An upper case letter next to the field tag number refers to the format option that will be used for validating this field. • Each field consists of a colon :, followed by a tag, followed by another colon :, and then the field content. • The following character restrictions apply to the field content: - The field content must not start with a Carriage Return, Line Feed (CrLf). - The field content must not be composed entirely of blank characters. - Within the field content, apart from the first character of the field content, a colon : or hyphen - must never be used as the first character of a line. - Except for fields 15a and 77E, a field must consist of at least one meaningful character. (See the General Field Definitions Plus for formatting requirements.) • Fields are separated by a 'Field Separator within Text' (CrLf). • The first field in a message is preceded by a 'Start of Text' (CrLf:) and the last field in a message is followed by an 'End of Text' (CrLf-). • See Characters on page 20 for the correct use of the characters Cr and Lf. • Field content may be composed of one or several subfields. When subfields appear on separate lines, the Carriage Return, Line Feed (CrLf), which is not included in the number of characters for the length of the subfield, serves as the subfield separator. Subfields: - Subfields may themselves be of fixed or variable length. - The order of subfields is fixed. - When necessary, subfields are separated by special symbols, for example, / or //. - Subfields must not be entirely composed of blank characters. - Subfields and/or components must consist of at least one meaningful character. • If a field content contains mandatory and optional subfields, then at least all of the mandatory subfields must appear when that field is used. • The specification of field or subfield content may consist of: - restrictions on the length of field or subfield content, using the descriptions listed in Restrictions on Length on page 51 - special formats, for example, for numbers and dates - codes, for example, currency codes (See the BIC Plus, which is available for download from www.swiftrefdata.com.) • 23 July 2021 In some messages, the field specifications may indicate specific characters, or sets of characters, for inclusion in the text of the field. 50 Standards MT November 2021 General Information Field Structure and Field Formatting Rules These take the following forms: - codes, for example, AMEND, TRF, or 08 - slash / or double slash // - slash or double slash followed by a code, for example, //CH or /FIXED - slash followed by a code and another slash, for example, /REC/ Note All codes must be in uppercase alphabetic characters. When codes contain a mix of alphabetic and numeric characters, the alphabetic character must also be in uppercase. Restrictions on Length Restrictions on length Types of Characters Allowed nn maximum length (minimum is 1) n numeric digits (0 through 9) only nn-nn minimum and maximum length a alphabetic letters (A through Z), upper case only c alphabetic letters (upper case) and digits only h hexadecimal letters A through F (upper case) and digits only x any character of the X permitted set (General FIN application set) upper and lower case allowed (SWIFT Character Set (X Character Set) on page 20) y any character of the EDIFACT level A character set as defined in ISO 9735 upper case only (EDIFACT Level A Character Set (Y Character Set) on page 20) z any character as defined by the Information Service (Information Service Character Set (Z Character Set) on page 20) d decimals e blank space nn! nn*nn fixed length maximum number of lines times maximum line length Examples 23 July 2021 2n up to 2 digits 3!a exactly 3 uppercase letters 4*35x up to 4 lines of up to 35 characters each 16-64h at least 16 and up to 64 hexadecimal characters 51 Standards MT November 2021 General Information Field Structure and Field Formatting Rules 6.3 Field Formatting 6.3.1 Dates Formats Format: 4!n Format: 6!n Format: 8!n Rules Dates are represented as either: 4, 6, or 8 digit integers, that is, in ISO form MMDD, YYMMDD, or YYYYMMDD Where: • YY = last 2 digits of the year • YYYY = all four digits of the year • MM = month • DD = day No blank spaces or other characters are permitted. Examples: • 1129 = 29 November • 211129 = 29 November 21 • 20211129 = 29 November 2021 The six-digit date thus ranges from 2001 to 2060. On the FIN network, there is an additional restriction for the year range where the date is affected by the Value Date Ordering process (Value Date Ordering on page 69). The valid date range of 2001 to 2060 applies to (list not exhaustive): 6.3.2 • field 30, in MTs: 101, 104, 107, 110, 111, 112, 201, 203, 204, and 210 • field 32A, in MTs: 102, 102 STP, 103, 103 REMIT, 103 STP, 110, 111, 112, 200, 202, 202 COV, 205, 205 COV, and 910 Numbers Format nn...nn, nn...n Integer part 23 July 2021 D0200006 Fractional part (optional) 52 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Usage rules Wherever they represent a numeric value, numbers always take the same form: • The integer part must contain at least one digit. • Decimal points are not permitted. A decimal comma ',' shall precede the fractional part. • The maximum length includes the decimal comma. • The fractional part may be missing, but the decimal comma must always be present. • Neither blank spaces, nor any symbols other than the decimal comma are permitted. • The integer part is mandatory in the number component, and at least one character must appear. Leading zeros are allowed. • Normally, when a number represents an amount of money, the number of places following the decimal comma may not exceed the number of decimal digits valid for the specified currency. The specifications for the individual message types will indicate the fields where this is not the case. Details regarding the allowable fractional parts for each currency code may be found in the BIC Plus which is available on www.swiftrefdata.com. Examples 6.3.3 Valid Invalid 000,00 0000 0, 0 0,67 .67 0,25 ,25 100000, 100.000 25768, 25-768 99999999, 999.999.999 100, 100 10500,00 10500.00 5,25 5 1/4 Currency Codes Format Format: 3!a Description A currency code must be a valid ISO 4217 currency code, which normally consists of a two-letter ISO country code followed by a third letter denoting the particular currency or type of funds. 23 July 2021 53 Standards MT November 2021 General Information 6.3.4 Field Structure and Field Formatting Rules Party Identification Parties may be represented in several ways: • Identifier Code (BIC) • branch (city) of the sender or the receiver • name and address • other identification codes, for example, account number When necessary, party identification can be supplemented by an account number line preceding other party information. 6.3.4.1 Party Identifier Overview When further identification of a party, for example, specification of an account number to be credited, is necessary, the party identifier should be used. Format: [/1a][/34x] Where: Subfield 1 Subfield 2 [/1a] Specifies which account is involved: /C The receiver's account serviced by the sender is credited. /D The sender's account serviced by the receiver is debited. [/34x] The account number information, preceded by a slash '/'. Rules When the party identifier is present, the following rules apply: • The party specified in the field with the account must be the account owner. The optional party identifier must specify the account known to the account servicing institution. • Extreme care must be taken when formatting the party identifier, for example, when only subfield 2 '[/34x]' is entered, and its first and third characters consist of '/', the system can only presume that both subfields 1 and 2 are present. It will then qualify the second character for either code 'C' or 'D', and NAK the message if one or the other is not present (Error code T51). Note Other examples of fields impacted by this form of validation are: • 42A, 42D • 50D, 50F*, 51A, 51D, 52A, 52B, 52D, 53A, 53B, 53D, 54A, 54B, 54D, 55A, 55B, 55D, 56A, 56B, 56D, 57A, 57B, 57D, 58A, 58B, 58D • 82A, 82B, 82D, 83A, 83D, 84A, 84B, 84D, 85A, 85B, 85D, 86A, 86B, 86D, 87A, 87B, 87D, 88A, 88B, 88D * See additional structure for party identifier in section Option F: Party Identifier/Name and Address on page 61. 23 July 2021 54 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Additional rules The following additional rules apply: • An account specified in field 58a or 59a must be owned by that party and must be serviced by the financial institution in field 57a or, if field 57a is absent, by the receiver. • An account specified in field 57a must be owned by that party and must be serviced by the financial institution in field 56a or, if field 56a is absent, by the receiver. • An account specified in field 56a must be owned by that party and must be serviced by the receiver. • In field 53a, when an account is used it normally indicates: - which account is to be used for reimbursement, if multiple accounts in the currency of the transaction are serviced for the other party. In this case, the account should be specified. - whether the sender's account serviced by the receiver, or the receiver's account serviced by the sender, is to be used for reimbursement, if they both service accounts for each other in the currency of the transaction. In this case, the account to be debited or credited shall be indicated in the party identifier by either the code /C or /D, or the account, or both. In both cases, this information should be specified in field 53a with the format option B (party identifier only). Examples Valid Invalid :53A:/C/12-12 CITIUS33CHI :53A:/6/12-12 CITIUS33CHI :53B:/D/24-24 :53B:/A/24-24 :53D:/52/48-48 John Doe 122 Peyton Place Elyria, OH 22216 :53D:/:/48-48 John Doe 122 Peyton Place Elyria, OH 22216 :87E:FREE /C/12-12 CHASUS33 :87E:APMT /A/12-12 CHASUS33 :87F:APMT /D/12-12 John Doe 122 Peyton Place Elyria, OH 22216 :87F:APMT /:/48-48 John Doe 122 Peyton Place Elyria, OH 22216 Example Bank A in New York services an account in USD for Bank B in London. Bank B also services, in London, a USD account (number 567-3245-01) for Bank A. Bank A sends a USD transfer to Bank B, using its USD account in London, serviced by Bank B, for reimbursement. Bank A will request that Bank B debit its account in London as follows: :53B:/D/567-3245-01 Note 23 July 2021 In certain message types, there are exceptions to the rules for use of the party identifier detailed in this section, for example, field 57a in Category 3 messages. In those cases, the intended use of the party identifier is described in the relevant field specification for the message type. 55 Standards MT November 2021 General Information 6.3.4.2 Field Structure and Field Formatting Rules Option No Letter: Name and Address Format [/34x] (Account) 4*35x (Name and Address) Definition Name and address of the party, with an optional account. Network validated rules If the first line of this field starts with a slash '/', then it is assumed that Account is present and then at least 1 line of Name and Address must be present (Error code T77). Usage rules If Account is absent, then Name and Address must not start with a slash '/'. Field assigned to this option 59 6.3.4.3 Option A: Identifier Code Format [/1a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code) Definition Identifier code such as a BIC. Optionally, the account of the party. Network validated rules Identifier Code must be a registered BIC (Error codes T27, T28, T29 and T45). Fields assigned to this option • 41A*, 42A • 50A**, 51A, 52A, 53A, 54A, 55A, 56A, 57A, 58A, 59A • 82A, 83A, 84A, 85A, 86A, 87A, 88A Note When this option is used, the SWIFT system will validate the correctness of the Identifier Code, that is, to ensure that it is registered: either connected or nonconnected. (*) Field 41A does not have the optional party identifier, but does have an additional subfield. See Option D: Name and Address on page 57 on the use of clearing codes. (**) Field 50A has the format [/34x] for Party Identifier. 23 July 2021 56 Standards MT November 2021 General Information 6.3.4.4 Field Structure and Field Formatting Rules Option B: Branch of Sender/Receiver Format [/1a][/34x] (Party Identifier) [35x] (Location) Usage rules When used, at least one line must be present. An account number only, not followed by any other identification, is allowed (field 53a). For field 52a, the field specifications for individual message types specify whether this option identifies a branch of the sender or the receiver. In field 53a, this option specifies either the account to be debited or credited, or a branch of the sender, that is, of the financial institution specified in the sender's address in the header. In fields 54a and 57a, this option specifies a branch of the receiver, that is, of the financial institution specified in the receiver's address in the header. Fields assigned this option 52B, 53B, 54B, 55B, 57B, 58B 82B, 84B, 85B, 87B, 88B 6.3.4.5 Option C: Account Number/Party Identifier Format /34x (Account) Definition A code uniquely identifying an account and/or party. In the MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, and 104, clearing codes may be used. Fields assigned this option 51C, 52C, 53C, 56C, 57C, 58C 82C, 83C, 85C, 87C, 88C Note 6.3.4.6 See Option D: Name and Address on page 57 on the use of clearing codes. Option D: Name and Address Format 23 July 2021 [/1a][/34x] (Party Identifier) 4*35x (Name and Address) 57 Standards MT November 2021 General Information Note Field Structure and Field Formatting Rules This option is used when no other option is available. This information also applies to fields 50 (when option representing name and address is selected) and 59 (without letter option). Definition Name and address and, optionally, the account or clearing code of the party. Network validated rules If the first line of this field starts with a slash '/', then it is assumed that Party Identifier is present and then at least 1 line of Name and Address must be present (Error code T77). Usage rules When the party identification is provided by name and address (whether by full postal address or informal identification), the following rules apply: • at least one line of the name and address must be present, in addition to the party identifier • the street address must be on a new line following the name • when a city is present, it must be on the last line, with the postal code (zip, etc.), state and country identification Although more than one element of an address may appear on each line, care should be taken that, when possible, no element, for example, street address, should be spread over more than one line. If a Party Identifier is absent, then Name and Address must not start with a slash '/'. National clearing codes list When the party identifier is used to indicate a national clearing system code preceded by a double slash '//', the following codes may be used: 23 July 2021 AT 5!n Austrian Bankleitzahl AU 6!n Australian Bank State Branch (BSB) Code BL 8!n German Bankleitzahl CC 9!n Canadian Payments Association Payment Routing Number CH 6!n CHIPS Universal Identifier CN 12..14n China National Advanced Payment System (CNAPS) Code CP 4!n CHIPS Participant Identifier ES 8..9n Spanish Domestic Interbanking Code FW 9!n Fedwire Routing Number GR 7!n HEBIC (Hellenic Bank Identification Code) HK 3!n Bank Code of Hong-Kong IE 6!n Irish National Clearing Code 58 Standards MT November 2021 General Information Field Structure and Field Formatting Rules IN 11!n Indian Financial System Code (IFSC) is the identification scheme defined by the Reserve Bank of India IT 10!n Italian Domestic Identification Code NZ 6!n New Zealand National Clearing Code PL 8!n Polish National Clearing Code (KNR) PT 8!n Portuguese National Clearing Code RT Pay by Real Time Gross Settlement RU 9!n Russian Central Bank Identification Code SC 6!n UK Domestic Sort Code SW 3..5n Swiss Clearing Code (BC code) SW 6!n Swiss Clearing Code (SIC code) ZA 6!n South African National Clearing Code In some messages, some of these clearing codes may also be used with option A, that is, the MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, and 104. This is indicated with the field specifications of each message type. When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //RT is used, it should appear only once, and in the first of the fields 56a and 57a of the payment instruction. When it is necessary that an incoming SWIFT payment be made to the party in this field via Fedwire, US banks require that the code FW appears in the optional Party Identifier. When it is necessary that an incoming SWIFT payment be made to the party in this field via a realtime gross settlement system (RTGS), the code RT should appear in the optional Party Identifier. Option D must only be used in exceptional circumstances, that is, when the party cannot be identified by a BIC, and when there is a bilateral agreement between the sender and the receiver permitting its use. Unless qualified by a clearing system code or an account number, the use of option D may prevent the automated processing of the instruction(s) by the receiver. National clearing codes formats List of codes and formats: • The Australian BSB code is the identification scheme defined by APCA (Australian Payments Clearing Association). Its structure is either: for financial institutions with an extensive branch network: 23 July 2021 - 2!n = Bank Code - 1!n = State Code - 3!n = Branch Code 59 Standards MT November 2021 General Information Field Structure and Field Formatting Rules or for institutions with a small network: • - 3!n = Bank Code - 3!n = Branch Code The Bank Code for Hong-Kong is structured as follows: - • • • • • • • • 23 July 2021 3!n = Bank Code The Hellenic Bank Identification Code (HEBIC) is the identification scheme defined by the Hellenic Bank Association. Its structure is: - 3!n = Bank Code - 4!n = Branch Code The Indian Financial System Code (IFSC) is the identification scheme defined by the Reserve Bank of India. Its structure is: - 4!a = Bank Code (same as party prefix in BIC - ISO 9362) - 1!n = Zero - Reserved for future use - 6!c = Branch Code The structure of the Irish NSC code is 2!n4!n, where: - 2!n = Bank Code - 4!n = Branch Code The Italian ITBI code is the identification scheme defined by ABI (Associazione Bancaria Italiana). Its structure is: - 5!n = Bank Code (ABI) - 5!n = Branch Code (CAB) The New Zealand Bank/Branch Code is the identification scheme defined by NZBA (New Zealand Bankers Association). Its structure is: - 2!n = Bank Code - 4!n = Branch Code The Portuguese National Clearing code is defined by the Banco de Portugal. Its structure is 4! n4!n, where: - 4!n = Bank Code (IFRI), potentially containing leading zeros - 4!n = Branch Code (BLCI) which is unique for each branch and locally assigned by the financial institution The Russian Central Bank Identification Code is to be considered as one, uniform, indivisible code. Its structure is 2!n2!n2!n3!n, where: - 2!n = Country Code. The first position is always 0 and is not shown in the database of the Central Bank of Russia. - 2!n = Region Code within the country - 2!n = Code of the division of the Central Bank in the region - 3!n = Bank Code The South African National Clearing code is defined by BankServ, the South African Bankers Services Company Ltd. Its structure is 3!n3!n, where: - 3!n = Bank Code, potentially with leading zeros - 3!n = Branch Code, potentially with leading zeros 60 Standards MT November 2021 General Information • Field Structure and Field Formatting Rules The Spanish Domestic Interbanking Code is the identification scheme defined by CCI (Centro de Cooperacion Interbancaria). Its structure is: - 4!n = Bank Code - 4!n = Branch Code - [1!n] = Check Digit Fields assigned to this option 42D 50D, 51D, 52D, 53D, 54D, 55D, 56D, 57D, 58D 82D, 83D, 84D, 85D, 86D, 87D, 88D Note 6.3.4.7 Field 41D does not have the optional party identifier but does have an additional subfield. Option F: Party Identifier/Name and Address Format [35x] (Party Identifier) 4*35x (Name and Address) The following line formats must be used (Error code(s): T54): Line 1 (subfield Party Identifier) /34x (Account) Line 2-5 (subfield Name and Address) 1!n/33x (Number)(Details) Line 1 (subfield Party Identifier) 4!a/2!a/27x (Code)(Country Code)(Identifier) Line 2-5 (subfield Name and Address) 1!n/33x (Number)(Details) Line 1 (subfield Party Identifier) [/34x] (Account) Line 2-5 (subfield Name and Address) 1!n/33x (Number)(Details) Or Or Definition Name and address in a structured format to facilitate straight-through processing. 23 July 2021 61 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Codes When Party Identifier is used with the (Code)(Country Code)(Identifier) format, for example in field 50F Ordering Customer, one of the following codes must be used: ARNU Alien Registration Number The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Alien Registration Number. CCPT Passport Number The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Passport Number. CUST Customer Identification Number The code followed by a slash, '/' must be followed by the ISO country code of the issuer of the number, a slash, '/', the issuer of the number, a slash, '/' and the Customer Identification Number. DRLC Driver's License Number The code followed by a slash, '/' must be followed by the ISO country code of the issuing authority, a slash, '/', the issuing authority, a slash, '/' and the Driver's License Number. EMPL Employer Number The code followed by a slash, '/' must be followed by the ISO country code of the registration authority, a slash, '/', the registration authority, a slash, '/' and the Employer Number. NIDN National Identity Number The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the National Identity Number. SOSE Social Security Number The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Social Security Number. TXID Tax Identification Number The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Tax Identification Number. Codes On each line of Name and Address, subfield Number must contain one of the following values (Error code(s): T56): 23 July 2021 1 Name of the Ordering Customer The number followed by a slash, '/' must be followed by the name of the ordering customer. 2 Address Line The number followed by a slash, '/' must be followed by an address line (Address Line can be used to provide for example, street name and number, or building name). 62 Standards MT November 2021 General Information 3 Field Structure and Field Formatting Rules Country and Town The first occurrence of number 3 must be followed by a slash, '/', the ISO country code, and optionally a slash '/' followed by additional details. Other occurrence(s) of number 3 must be followed by a slash '/' and the continuation of additional details. Additional details can contain town, which can be complemented by postal code (for example zip) and country subdivision (for example state, province, or county). The country code and town should, preferably, indicate the country and town of residence. Some option F fields also allow for these values in Number: 4 Date of Birth The number followed by a slash, '/' must be followed by the date of birth in the YYYYMMDD format. 5 Place of Birth The number followed by a slash, '/' must be followed by the ISO country code, a slash '/' and the place of birth. 6 Customer Identification Number The number followed by a slash, '/' must be followed by the ISO country code of the issuer of the number, a slash, '/', the issuer of the number, a slash, '/' and the customer identification number. 7 National Identity Number The number followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the national identity number. 8 Additional Information The number followed by a slash, '/' is followed by information completing one of the following: • the Identifier provided in subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format • the Customer Identification Number provided in subfield 2 (Name and Address) with number 6 • the National Identity Number provided in subfield 2 (Name and Address) with number 7 Network validated rules In subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country Code must be a valid ISO country code (Error code(s): T73). In subfield 2 (Name and Address): 23 July 2021 • The first line must start with number 1 (Error code(s): T56). • Numbers must appear in numerical order (Error code(s): T56). • A line starting with number 3 must be present (Error code(s): T56). • The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s): T73). • Numbers 1, 2, and 3 may be repeated. The same number must not occur more than 2 times (Error code(s): T56). 63 Standards MT November 2021 General Information • Field Structure and Field Formatting Rules Option F fields that also allow the numbers 4 – 8 in Number, for example field 50F, have these additional network validated rules: - Number 4 must not be used without number 5 and vice versa (Error code(s): T56). - Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local to the sender, must not be later than the date on which the message is successfully sent to SWIFT (Error code(s): T50). - Numbers 5, 6, and 7 must be followed by a valid ISO country code (Error code(s): T73), a slash '/' and additional Details (Error code(s): T56). - Numbers 4, 5, 6, 7, and 8 must not be repeated (Error code(s): T56). - The use of number 8 is only allowed in the following instances (Error code(s): T56): ▪ to continue information on the Identifier of the ordering customer provided in subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format ▪ to continue information on the Customer Identification Number provided in subfield 2 (Name and Address) following number 6 ▪ to continue information on the National Identity Number provided in subfield 2 (Name and Address) following number 7 Usage rules • In subfield 2: numbers 1, 2, and 3 may be repeated. • In subfield 2: if number 2 is present, the first occurrence of number 3 must include the town in additional details. For ordering customer: • • Subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if additional space is required for providing the Identifier of the ordering customer, one of the following options must be used: - First option (preferred): identify the ordering customer with a different identifier where the length is not an issue. - Second option: continue the information in subfield 2 (Name and Address) using number 8. Subfield 2 (Name and Address): if additional space is required for providing the Customer Identification Number (number 6) or the National Identity Number (number 7) of the ordering customer, one of the following options must be used: - First option (preferred): identify the ordering customer with a different identifier where the length is not an issue. - Second option: continue the information in subfield 2 (Name and Address) using number 8. Field assigned to this option 50F, 59F 6.3.4.8 Option G: Identifier Code Format 23 July 2021 /34x (Account) 4!a2!a2!c[3!c] (Identifier Code) 64 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Definition Identifier code of the party with mandatory account number. Network validated rules Identifier Code must be a registered BIC (Error codes T27, T28, T29, and T45). Fields assigned to this option 50G, 52G 6.3.4.9 Option H: Name and Address Format /34x (Account) 4*35x (Name and Address) Definition Name and address of the party with a mandatory account. Field assigned to this option 50H 6.3.4.10 Option J: Party Identification with no Party Identifier Format 5*40x (Narrative) Definition Identification of the party. Codes In option J, Party Identification must be specified as a list of pairs (Code)(Value) and one or more of the following codes and formats must be used (Error code(s): T78). The codes must be placed between slashes ('/'). 23 July 2021 Code Format Description ABIC 4!a2!a2!c[3!c] or 4!a Identifier Code ACCT 34x account followed by the account number ADD1 35x address followed by the first line of the address ADD2 35x address followed by the second line of the address CITY 35x city followed by the name of city (and state, country) 65 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Code Format Description CLRC 35x Clearing Code followed by a clearing code LEIC 18!c2!n Legal Entity Identifier NAME 34x name followed by the name NETS - a net settlement is taking place SSIS - standard settlement instructions are used The codes do not need to be put on separate lines. It is the '/' at the beginning of a code, not the end-of-line, that marks the end of the information behind the previous code. As a result, the narrative following the code may not contain a slash '/'. The end-of-line may be part of the narrative text following the code, but it is to be ignored when reading the field. However, the end-of-line may not be part of the code. Examples /ABIC/BNKAXA11/NAME/BANK A OF XANADU(CrLf) /NAME/BANK A OF XANADU/ABIC/BNKAXA11(CrLf) /ABIC/BNKAXA11(CrLf) /NAME/BANK A OF XANADU(CrLf) /ABIC/BNKAXA11/NAME/BRANCH B OF THE(CrLf) SECOND NATIONAL BANK A OF XANADU(CrLf) Fields assigned to this option 53J, 56J, 57J, 58J 82J, 83J, 84J, 85J, 86J, 87J, 88J. 6.3.4.11 Option K: Name and Address Format [/34x] (Account) 4*35x (Name and Address) Definition Name and address of the party, with an optional account. Network validated rules If the first line of this field starts with a slash '/', then it is assumed that Account is present and then at least 1 line of Name and Address must be present (Error code T77). Usage rules If Account is absent, then Name and Address must not start with a slash '/'. Field assigned to this option 50K 23 July 2021 66 Standards MT November 2021 General Information 6.3.4.12 Field Structure and Field Formatting Rules Option L: Party Identification Format 35x (Narrative) Definition Identification of the party Field assigned to this option 50L 6.3.4.13 Option P: Party Format :4!c//4!a2!a2!c[3!c] (Qualifier)(Identifier Code) Definition Identification of the party, with a qualifier and an identifier code such as a BIC. Field assigned to this option 95P 6.3.4.14 Option Q: Party Format :4!c//4*35x (Qualifier) (Name and Address) Definition Identification of the party, with a qualifier and name and address. Field assigned to this option 95Q 6.3.4.15 Option R: Party Format :4!c/8c/34x (Qualifier) (Data Source Scheme) (Proprietary Code) Definition Identification of the party, with a qualifier, issuer code and proprietary code. Field assigned to this option 95R 23 July 2021 67 Standards MT November 2021 General Information 6.3.4.16 Field Structure and Field Formatting Rules Option S: Party Format :4!c/[8c]/4!c/2!a/30x (Qualifier) (Data Source Scheme) (Type of ID) (Country code) (Alternate ID) Definition Identification of the party, with a qualifier, an optional issuer code, type of ID, country code and alternate ID. Field assigned to this option 95S 6.3.4.17 Option T: Party Format :4!c//2*35x (Qualifier) (Name) Definition Identification of the party, with a qualifier and name. Field assigned to this option 95T 6.3.4.18 Option U: Party Format :4!c//3*35x (Qualifier) (Name) Definition Identification of the party, with a qualifier and names. Field assigned to this option 95U 6.3.5 Times Formats 4!n 6!n 23 July 2021 68 Standards MT November 2021 General Information Field Structure and Field Formatting Rules Rules Times are represented as either four or six digit integers, that is, in form HHMM or HHMMSS respectively, where (Error code T38): • H = hour • M = minutes • S = seconds No blank spaces or other characters are permitted. Examples 0000 1200 235959 6.3.6 Value Date Ordering Overview The SWIFT system allows the receiver to request value date ordering of its value date sensitive messages. The value date sensitive messages are: • MT 910 • all Category 1 and Category 2 messages containing fields 30 or 32A, or both 30 and 32A, except common group messages 192, 292, 195, 295, 196, and 296 The valid range of value dates implemented on the SWIFT system for these MTs is from 2001 to 2060, and must meet the following requirements: • allowed: a year component, for example, "YY" in the range of 01 through 60, of an ISO defined six digit integer date "YYMMDD" • not allowed: any "YY" component outside of this range Example ACKed NAKed :32A:061130USD1, :30:181130 :32A:611130USD1, :30:791130 For the purpose of value date ordering, if there is more than one value date field in a message, the lesser date will be selected: MTxxx :30:151218 :32A:200103USD123000,00 Value date = 18 December 2015 Value date = 03 January 2020 In this example, field 30 Value Date (18 December 2015) is selected for value date ordering of the message. Error code T50 is returned after an invalid value date. 23 July 2021 69 Standards MT November 2021 General Information Euro-Related Information (ERI) 7 Euro-Related Information (ERI) 7.1 Deletion of National Currency Denomination (NCD) Currency Codes On 1 March 2002, ISO announced the deletion of the National Currency Denomination (NCD) currency codes from the official ISO currency code table 4217. The currencies concerned are ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE, and XEU. On 1 January 2007, ISO announced a similar deletion for the SIT. For certain message types, when NCDs are used as the currency of settlement, SWIFT validates to ensure that the value date is not after the date on which the currencies ceased to be a legal tender: • When ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, the value date must not be after 31 December 2001. • When the Slovenian currency code SIT is used, the value date must not be after 31 December 2006. • When the Cyprus currency code CYP or the Maltese currency code MTL are used, the value date must not be after 31 December 2007. • When the Slovakian currency code SKK is used, the value date must not be after 31 December 2008. • When the Estonian currency code EEK is used, the value date must not be after 31 December 2010. • When the Latvian currency code LVL is used, the value date must not be after 31 December 2013. • When the Lithuanian currency code LTL is used, the value date must not be after 31 December 2014. Until further notice, and where allowed (NCDs cannot be used in settlement amount fields), SWIFT will continue to support NCD currency codes (for example, instructed amounts, ERI) in the relevant fields of its message types. 7.2 Euro-Related Information (ERI) This section discusses what is meant by Euro-Related Information (ERI). 7.2.1 ERI Content Euro-Related Information (ERI) refers to the following data: • original currency • original amount • transaction charges The original currency and amount in ERI is the equivalent of the information in the field containing the amount which is used for interbank settlement of the transaction. This field may contain additional information, for example, value date. 23 July 2021 70 Standards MT November 2021 General Information Euro-Related Information (ERI) ERI may be specified in one of several free-text fields preceded by a code. As of Standards release 2001, the use of ERI was extended to non-European currencies and beyond the transition period of 3 years. In the Corporate Action messages within Category 5, codes are used to indicate the processing of redenominations. 7.2.2 ERI Usage Guidelines and Rules Introduction The specification of ERI is always optional. If used, however, the rules specified in this section apply. If a network validated rule mandates the presence of an exchange rate field where both the transaction amount and the original ordered amount are quoted (for example, field 36 in the MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107), this rule remains effective. In the case of euro-related currencies, the exchange rate field must specify the value of the fixed euro conversion rate. See ERI Validation and Examples on page 79 for details of specific ERI validation rules. Usage rules The following rules must be adhered to but are not validated by the network: • ERI may be used only when the message does not have a specific existing field to specify the information. If specific fields have been defined in a message to contain the original currency and amount, these fields, and not ERI, should be used to indicate the original currency and amount. For example, all ISO 15022 compliant Category 5 Trade Initiation and Confirmation (TIC), Settlement and Reconciliation (S&R), and Corporate Action (CA) messages contain specific fields for this purpose, as does the MT 103. • As with all other information occurring in fields 72, 77A, or 79, ERI is for information purposes only. In the case of a discrepancy between ERI and the settlement amount (for example, net proceeds), specified in the message, the information in the settlement amount prevails. Usage guidelines Guidelines when specifying fields are: • If no specific fields are available to specify the original currency and amount, ERI may be used in any message type containing a free text field 72, 77A, or 79. The use of ERI is not restricted to specific message types. See Messages Likely to Contain ERI on page 73. • The preferred field for specifying ERI is field 72. If not present, field 77A should be used. If there is no field 72 nor 77A, then field 79 should be used. • If ERI is specified in field 72, 77A, or 79, it should appear on the first line whenever possible. Whatever line is used, the ERI should always appear on the first position of that line. • For message types that do not contain a field 72, 77A, nor 79, there are only two that may need to specify a second currency: MTs 940 and 942. For these two cases, subfield 9 of field 61 should be used to specify ERI. If this subfield is used for other purposes, field 86 should be used to specify ERI. It is recommended that the sender of the MT 940/942 advises the receiver whenever field 86 is used to contain ERI. 23 July 2021 71 Standards MT November 2021 General Information 7.2.3 Euro-Related Information (ERI) • Where the settlement amount is part of a repetitive sequence which does not contain a free text field, the message should be used as a single transaction message, that is, one message should be used per transaction. • Where transaction charges are specified in ERI, this information must appear after the code / CHGS/. This will not necessarily be processed by the receiver. • ERI is designed to be passed on unchanged in the appropriate message types throughout the entire transaction, that is, throughout the chain of messages relating to the transaction. Therefore it should appear in the appropriate SWIFT messages related to the transaction. ERI Structure Format Field 72 6*35x Field 77A 20*35x Field 79 35*50x Definition In addition to previously defined sender to receiver information, or other narrative information, these fields may include Euro-Related Information (ERI) for information purposes. ERI indicates currency conversion details, related to the conversion of the original currency into a settlement currency, found in free text fields. It is recommended that ERI be structured in these free text fields, using codes. Codes The following codes must be used /OCMT/ 3!a15d/ O Original currency and amount. If no charges are specified, then the original currency and amount will be the equivalent of the transaction amount specified in the message. /CHGS/ 3!a15d/ O Currency and amount of the transaction charges. When the BEN option is used in payments and related messages, that is, all transaction charges are to be paid by the beneficiary customer, the charges amount has been deducted from the original amount to obtain the settlement amount specified in the message. Usage rules The network will validate the structure of ERI, but not the content, see section ERI Validation and Examples on page 79 for details. 23 July 2021 72 Standards MT November 2021 General Information Euro-Related Information (ERI) Example :72:/OCMT/GBP2525,/ /CHGS/EUR2,40/ 7.3 Message Specific Guidelines on the Use of ERI This section lists message types which: 7.3.1 • are likely to contain ERI • contain a special field for original amount • are to be validated against a specified value date Messages Likely to Contain ERI List of message types that can contain ERI in a free text field The following lists message types that are likely to contain Euro-Related Information (ERI) in a free text field. Message types that already contain a field to specify an original currency and amount, are not included here. If there are business requirements to specify ERI in other message types, these should be similarly specified in a free text field 72, 77A, or 79, as explained in ERI Structure on page 72. This list is therefore not exhaustive. 23 July 2021 MT MT Name Settlement Amount Repetitive/N ERI Field on Repetitive Field Repetitive/N on Repetitive 202 General Financial Institution Transfer 32A Value Date, Currency Code, Amount NR 72 NR 202 COV General Financial Institution Transfer 32A Value Date, Currency Code, Amount NR 72 NR 203 Multiple General Financial Institution Transfer 32B Currency Code, R Amount 72 R 204 Financial Markets Direct Debit Message 32B Currency Code, R Amount 72 R 205 Financial Institution Transfer Execution 32A Value Date, Currency Code, Amount NR 72 NR 205 COV Financial Institution Transfer Execution 32A Value Date, Currency Code, Amount NR 72 NR 400 Advice of Payment 33A Proceeds Remitted NR 72 NR 73 Standards MT November 2021 General Information 7.3.2 Euro-Related Information (ERI) MT MT Name Settlement Amount Repetitive/N ERI Field on Repetitive Field Repetitive/N on Repetitive 450 Cash Letter Credit Advice 32A Value Date, Currency Code, Amount R 72 NR 455 Cash Letter Credit Adjustment Advice 33a Value Date and Adjustment Amount R 72 NR 456 Advice of Dishonour 33D Total Amount Debited R 72 NR 581 Collateral Adjustment Message 34B Outstanding Collateral Value NR 72 NR 752 Authorisation to Pay, Accept or Negotiate 33a Net Amount NR 72 NR 754 Advice of Payment/ Acceptance/Negotiation 34a Total Amount Claimed NR 72 NR 756 Advice of Reimbursement or Payment 33A Amount Reimbursed or Paid NR 72 NR 768 Acknowledgement of a Guarantee/Standby Message 32a Amount of Charges NR 72 NR 769 Advice of Reduction or Release 32a Amount of Charges NR 72 NR 900 Confirmation of Debit 32A Value Date, Currency Code, Amount NR 72 NR 910 Confirmation of Credit 32A Value Date, Currency Code, Amount NR 72 NR 940 Customer Statement Message subfield 5 of field 61 R 61/9 or 86 R 942 Interim Transaction Report subfield 5 of field 61 R 61/9 or 86 R Messages Containing a Special Field for Original Amount List of message types containing a special field for original amount The following lists message types that already have a special field for specifying an original amount to be transferred. This list is not exhaustive, as there may be other messages with special fields specifying an original amount. 23 July 2021 74 Standards MT November 2021 General Information Euro-Related Information (ERI) MT MT Name Settlement Repetitive/N ERI Field Amount Field on Repetitive Repetitive/N on Repetitive 101 Request for Transfer 32B R 33B R 102 Multiple 32B Customer Credit Transfer R 33B R Single 32A Customer Credit Transfer NR 33B NR 104 Direct Debit and Request for Debit Transfer 32B R 33B R 107 General Direct 32B Debit Message R 33B R 513 Client Advice of Execution 19A::SETT NR 19A::OCMT NR 514 Trade Allocation Instruction 19A::SETT NR 19A::OCMT NR 515 Client 19A::SETT Confirmation of Purchase or Sale NR 19A::OCMT NR 518 Market-Side Securities Trade Confirmation 19A::SETT NR 19A::OCMT NR 541 Receive Against Payment 19A::SETT NR 19A::OCMT NR 543 Deliver Against 19A::SETT Payment NR 19A::OCMT NR 545 Receive Against Payment Confirmation 19A::ESTT NR 19A::OCMT NR 547 Deliver Against 19A::ESTT Payment Confirmation NR 19A::OCMT NR 102 STP 103 103 REMIT 103 STP 23 July 2021 75 Standards MT November 2021 General Information 7.3.3 Euro-Related Information (ERI) MT MT Name Settlement Repetitive/N ERI Field Amount Field on Repetitive Repetitive/N on Repetitive 564 Corporate Action Notification 19A::ESTT NR 19A::OCMT NR 566 Corporate Action Confirmation 19A::ESTT NR 19A::OCMT NR Messages with Value Date Validation List of message types used to transfer amounts in National Currency Denominations The following table contains messages that can be used to transfer amounts in National Currency Denominations (NCDs). If ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE or XEU is used, the value date has to be equal to, or before 31 December 2001. If SIT is used, the value date has to be equal to, or before 31 December 2006. If CYP or MTL is used, the value date has to be equal to, or before 31 December 2007. If SKK is used, the value date has to be equal to, or before 31 December 2008. If EEK is used, the value date has to be equal to, or before 31 December 2010. If LVL is used, the value date has to be equal to, or before 31 December 2013. If LTL is used, the value date has to be equal to, or before 31 December 2014. If these validations against value date fail, the message will be NAKed (Error code E76). Note Statement messages are not validated against value date, since they are generally the result of earlier validated messages. Furthermore, accounts are no longer held in any of the discontinued National Currency Denominations (NCDs) mentioned above. Currencies concerned The currencies concerned are ATS, BEF, CYP, DEM, EEK, ESP, FIM, FRF, GRD, IEP, ITL, LUF, LTL, LVL, MTL, NLG, PTE, SIT, SKK, and XEU. The table gives the message description, the field containing the NCD amount and the field containing the value date. MT MT Name NCD Amount Field Value Date Field 101 Request for Transfer 32B in sequence B (each occurrence) 30 in sequence A 102 Multiple Customer Credit Transfer 32A in sequence C 32A in sequence C 32A in sequence C 32A in sequence C 102 STP 103 23 July 2021 Single Customer Credit 32A Transfer 32A 76 Standards MT November 2021 General Information MT NCD Amount Field Value Date Field 103 REMIT 32A 32A 103 STP 32A 32A Direct Debit and Request for Debit Transfer Message 32B (each occurrence) 30 in sequence A 32B (each occurrence) 30 in sequence A 107 General Direct Debit Message 32B in sequence C 30 in sequence A 200 Financial Institution Transfer for its Own Account 32A 32A 201 Multiple Financial Institution Transfer for its Own Account 32B (each occurrence 30 202 General Financial Institution Transfer 32A 32A 202 COV General Financial Institution Transfer 32A 32A 203 Multiple General Financial Institution Transfer 32B (each occurrence) 30 204 Financial Markets Direct Debit Message 32B (each occurrence) 30 205 Financial Institution Transfer Execution 32A 32A 205 COV Financial Institution Transfer Execution 32A 32A 210 Notice to Receive 32B (each occurrence) 30 400 Advice of Payment 33A 33A 450 Cash Letter Credit Advice 32A (each occurrence) 32A 455 Cash Letter Credit Adjustment Advice 32A 32A 33C 33C 33D 33D 32D (each occurrence) 33D 104 104RFDD 456 23 July 2021 Euro-Related Information (ERI) MT Name Advice of Dishonour 77 Standards MT November 2021 General Information MT MT Name NCD Amount Field Value Date Field 513 Client Advice of Execution Sequence C Order Details Field 19A Qualifier SETT Sequence C Order Details Field 98a Qualifier SETT (1) Sequence D3 Amounts Field 19A Qualifier SETT Sequence C Order Details Field 98a Qualifier SETT (1) Sequence B Confirmation Details Field 19A Qualifier SETT Sequence B Confirmation Details Field 98a Qualifier SETT (1) Sequence C3 Amounts Field 19A Qualifier SETT Sequence B Confirmation Details Field 98a Qualifier SETT (1) Sequence C Confirmation Details Field 19A Qualifier SETT Sequence C Confirmation Details Field 98a Qualifier SETT Sequence D3 Amounts Field 19A Qualifier SETT Sequence C Confirmation Details Field 98a Qualifier SETT Sequence B Confirmation Details Field 19A Qualifier SETT Sequence B Confirmation Details Field 98a Qualifier SETT Sequence C3 Amounts Field 19A Qualifier SETT Sequence B Confirmation Details Field 98a Qualifier SETT 514 515 518 23 July 2021 Euro-Related Information (ERI) Trade Allocation Instruction Client Confirmation of Purchase or Sale Market-Side Securities Trade Confirmation 541 Receive Against Payment Sequence E3 Amount Field 19A Qualifier SETT Sequence B Trade Details Field 98a Qualifier SETT 543 Deliver Against Payment Sequence E3 Amount Field 19A Qualifier SETT Sequence B Trade Details Field 98a Qualifier SETT 545 Receive Against Payment Confirmation Sequence E3 Amount Field 19A Qualifier ESTT Sequence B Trade Details Field 98a Qualifier SETT (1) 547 Deliver Against Payment Confirmation Sequence E3 Amount Field 19A Qualifier ESTT Sequence B Trade Details Field 98a Qualifier SETT (1) 564 Corporate Action Notification Seq E2 Cash Movement Field 19B Qualifier ENTL Sequence E2 Cash Movement Field 98a Qualifier PAYD(2) 78 Standards MT November 2021 General Information MT MT Name NCD Amount Field Value Date Field 564 Corporate Action Notification Sequence E2 Cash Movements Field 19B Qualifier ENTL (each occurrence) Sequence E2 Cash Movements Field 98a Qualifier VALU(3) 566 Corporate Action Confirmation Sequence D2 Cash Movement Field 19B Qualifier PSTA Sequence D2 Cash Movement Field 98a Qualifier POST 730 Acknowledgement 32D 32D 734 Advice of Refusal 33A 33A 742 Reimbursement Claim 34A 34A 752 Authorisation to Pay, Accept or Negotiate 33A 33A 754 Advice of Payment/ Acceptance/ Negotiation 34A 34A 756 Advice of Reimbursement or Payment 33A 33A 768 Acknowledgement of a Guarantee/Standby Message 32D 32D 769 Advice of Reduction or Release 32D 32D 802 T/C Settlement Advice 32A 32A 900 Confirmation of Debit 32A 32A 910 Confirmation of Credit 32A 32A (1) (2) (3) 7.4 Euro-Related Information (ERI) If the settlement date in the optional field is not specified, the message will be accepted. If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is used, the validation is not performed). If the Value Date component is not present, then the validation is not performed (for example: MT 564 seq. E2, if :98B:: is used, the validation is not performed). ERI Validation and Examples This section details the validation of the ERI information and provides examples that give correct and incorrect messages. 23 July 2021 79 Standards MT November 2021 General Information 7.4.1 Euro-Related Information (ERI) General ERI Validation Rules Rules Codes and format: • /OCMT/3!a15d/ • /CHGS/3!a15d/ Where: • The currency component 3!a must be a valid currency code (Error code T52). • The amount component 15d following the currency code must be formatted according to the field formatting rules given in section Numbers on page 52. If not properly formatted, the system will NAK the message with Error codes T40, T43, T33, or other generic error codes as deemed necessary. • The amount component 15d will not be checked on the maximum number of decimal digits allowed for the relevant currency code. • The codes /OCMT/ and /CHGS/ will trigger ERI validation regardless of their location in the field, that is the codes may be present anywhere in a line; they do not have to be at the start of a line. Examples - currency codes The currency code XYZ is invalid. The messages are NAKed: • :79:/OCMT/XYZ150,/(CrLf) /CHGS/EUR1,(CrLf) • :77A:xxx/OCMT/EUR5000,/CHGS/XYZ1,/CrLf) Examples - amount components The amount components are invalid. The messages are NAKed: • :86:/OCMT/EUR,12/(CrLf) • :86:/OCMT/EUR123/(CrLf) Note The amount component must be followed by a slash '/' (Error code T31). In the following example the amount component is invalid. The message is NAKed: :86:/OCMT/EUR1,23(CrLf) 7.4.2 Messages and Fields Impacted Rules The ERI validation will be performed in fields: • • 23 July 2021 72, 77A, and/or 79 of all messages except in the following cases: - field 72 in the MTs 102, 102 STP, 103, 103 REMIT, 103 STP, 104, and 107 - field 77A in the MTs 300, 305, 306, 340, 341, 360, 361, 600, and 601 - field 79 in the MTs n92, n95, n96, and n99 61 (subfield 9) and 86, of the MTs 940 and 942 80 Standards MT November 2021 General Information Euro-Related Information (ERI) Examples The messages are not NAKed: • OCMT is validated :79:xxxxx/OCMT/EUR10,25/xxxxx(CrLf) • OCMT and CHGS are validated :79:xxxxx/OCMT/EUR10,25/(CrLf) /CHGS/EUR1,/(CrLf) 7.4.3 No ERI Validation Hierarchy between the Fields Rules Note that if the same field specification is re-used in the message, the ERI validation will be performed. This is usually the case where a field is defined in a loop, that is, a repetitive block of fields or sequence. Example For example, if fields 72, 77A, and 79 are all present in a message, and the ERI validation is defined for that message, the system will apply the ERI validation in the three types of fields. 7.4.4 /CHGS/ is only Validated if /OCMT/ is Present Rule The ERI validation for the code /CHGS/ (6 characters) will be performed only if it immediately follows /OCMT/3!a15d/ in the same occurrence of that field. Therefore, if /OCMT/ is present in field 72, and /CHGS/ is present in field 79 (but /OCMT/ is not present in 79), the system does not validate the format following /CHGS/ in field 79. Example In the following example, CHGS is not validated because OCMT is missing. The message is not NAKed: :86:xxxxx/CHGS/EUR1,40/xxxxx(CrLf) 7.4.5 Sequence of Codes is Required Rule Within a field, the sequence of the codes /OCMT/ and /CHGS/ is relevant. It is only if /OCMT/ appears immediately before /CHGS/ that the ERI validation will be applied to / CHGS/. Example 1 - structured field 72 CHGS is validated. The message is not NAKed: :72:/INS/BANKCCCY/OCMT/EUR12345,/(CrLf) /CHGS/EUR20,/xxxxx(CrLf) 23 July 2021 81 Standards MT November 2021 General Information Euro-Related Information (ERI) Example 2 - free format field 79 OCMT is validated. The message is not NAKed: :79:xyz/OCMT/EUR1234,00//CHGS/EUR40,00/xxx(CrLf) Example 3 - free format field 72 Only OCMT is validated because CHGS does not follow immediately OCMT. The message is not NAKed: :72:xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR1000,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) /CHGS/EUR5,/(CrLf) //xxxxxxxxxx(CrLf) Note If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the ERI and will not be subject to the ERI validation. Example 4 - structured field 72 Only OCMT is validated. The message is not NAKed: :72:/CHGS/EUR12,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) Example 5 - free format field 79 Only OCMT is validated. The message is not NAKed: :79:xyz/CHGS/EUR4,00/xxx/OCMT/EUR1234,00/xxx(CrLf) Example 6 - structured field 72 OCMT and the second occurrence of CHGS are validated. The message is not NAKed: :72:/CHGS/EUR1,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/(CrLf) /CHGS/EUR12,/xxxxx(CrLf) 7.4.6 Double Codes are not Allowed in one Field Rule In one occurrence of a field where the ERI validation must be performed, the codes /OCMT/ and / CHGS/ must not be used more than once. Note Since the presence of /OCMT/ triggers the validation of /CHGS/, a double /CHGS/ will be NAKed only if /OCMT/ is present in the same field. If the ERI validation fails due to a duplicated code, it will result - whichever field was validated - in the existing Error code T47. The line number of the first field in sequence in the message where the error occurred, will be indicated, together with the error code. Example 1 - structured field 72 OCMT is found twice. The message is NAKed: :72:/OCMT/EUR12345,/(CrLf) //xxxxxx(CrLf) /OCMT/EUR100,/xxxxx(CrLf) 23 July 2021 82 Standards MT November 2021 General Information Euro-Related Information (ERI) Example 2 - field 61 OCMT is found twice. The message is NAKed: :61:9809010931C3500,25FCHK304955//4958843(CrLf) /OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf) Example 3 - free format field 79 OCMT is found twice. The message is NAKed: :79:xyz/OCMT/EUR1234,00//OCMT/EUR40,00/xxx(CrLf) Example 4 - free format field 72 CHGS is found twice. The message is NAKed: :72:xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR10000,/(CrLf) /CHGS/EUR100,/xxxxxxxxxx(CrLf) /CHGS/EUR50,/(CrLf) //xxxxxxxxxx(CrLf) Note If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognised as part of the ERI and thus not be subject to the ERI validation. Example 5 - structured field 72 OCMT and the second occurrence of CHGS, are validated. The message is not NAKed: :72:/CHGS/EUR12,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/(CrLf) /CHGS/EUR50,/(CrLf) //xxxxxxxxxx(CrLf) Example 6 - free format field 79 OCMT and the second occurrence of CHGS, are validated. The message is not NAKed: :79:xyz/CHGS/EUR4,00//OCMT/EUR1234,00//CHGS/EUR4,00/(CrLf) 7.4.7 Consistent with Current Standards Rule In all fields where the ERI validation is defined, the generic that is, current, validation must still be performed. Example Field 72 is always checked for maximum 6 lines, with a maximum of 35 characters per line. Field 72, structured format, the first line must begin with a '/', and the second through sixth line (optional), must begin with a '/' or a '//'. 7.4.8 Maximum Use of the Generic Format Definition Rule In order to maximise the use of all characters allowed in the generic format, the codes /OCMT/, / CHGS/, as well as the data (3!a15d/), may be split across lines. 23 July 2021 83 Standards MT November 2021 General Information Euro-Related Information (ERI) Examples Narrative format of information that follows ERI-related codes split across lines: :72:xxxxx/OCMT/EUR12345,(CrLf) 12//CHGS/ (CrLf) EUR12,/(CrLf) Structured format of ERI-related codes split across lines: :72:/INS/BANKCCCY/OCMT/EUR1234,//CH(CrLf) //GS/EUR1,/xxxxxxx(CrLf) Narrative format of ERI-related codes split across lines: :77A:xxxxx/OC(CrLf) MT/EUR100,/(CrLf) 7.4.9 No ERI Validation Rules SWIFT does not perform network validation on the Euro-Related Information in: • Fields 72 and 79, if the REJT or RETN codes are present, that is, the special REJT/RETN validation for fields 72 and 79 prevails • MT 104 • Common Group message types (Category n) 7.4.10 Details of the ERI Validation Implementation 7.4.10.1 Field 61, subfield 9 Format [34x] Validation The system performs the following validation: 1. If subfield 9 in field 61 is present, then validates according to the format 34x: • if the check here above is OK, then goes to point 2 • otherwise the message is NAKed with the corresponding error code 2. Scans for /OCMT/ If /OCMT/ is: 23 July 2021 • not present, then performs next field validation • present more than once, then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ 84 Standards MT November 2021 General Information Euro-Related Information (ERI) If format is: - valid, then goes to point 3 - invalid, then NAK the message with the corresponding error code and terminates the validation 3. Checks for /CHGS/ immediately after /OCMT/3!a15d/ If /CHGS/ is: • not present, then performs next field validation • present more than once, then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: 7.4.10.2 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation Field 72 (Structured Format) Format <INSTR> first line [(CrLf)(<INSTR> or //33x)] optionally, lines 2 to 6 where <INSTR> is defined as: • /1!a/[32x] or • /2!a/[31x] or • /3!a/[30x] or • /4!a/[29x] or • /5!a/[28x] or • /6!a/[27x] or • /7!a/[26x] or • /8!a/[25x] Validation The system performs the following validation: 1. Maximum 6 lines, maximum 35 characters per line (X character set) 2. First line as <INSTR>, per the format defined here above 3. Second through sixth line If present, defined as : <INSTR> or //33x: • if the 3 checks here above are OK, then goes to point 4 • otherwise the message is NAKed, with the corresponding error code 4. Throughout the field content, removes all (CrLf//), if any 5. Throughout the field content, removes all (CrLf), if any 23 July 2021 85 Standards MT November 2021 General Information Euro-Related Information (ERI) 6. Scans for /OCMT/ If /OCMT/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: - valid, then goes to point 7 - invalid, then NAK the message with the corresponding error code and terminates the validation 7. Checks for /CHGS/ immediately after /OCMT/3!a15d/ If /CHGS/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: 7.4.10.3 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation Field 72 (Narrative) Format 35x[(CrLf)35x], optionally lines 2 to 6 Validation The system performs the following validation: 1. Maximum 6 lines, maximum 35 characters per line (X character set) 2. Second through sixth line, if present, defined as 35x If present, defined as 35x: • if the 2 checks are OK, then goes to point 3 • otherwise the message is NAKed with the corresponding error code 3. Throughout the field content, removes all (CrLf), if any 4. Scans for /OCMT/ If /OCMT/ is: 23 July 2021 • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • is present only once, then validates the format 3!a15d/ 86 Standards MT November 2021 General Information Euro-Related Information (ERI) If format is: - valid, then goes to point 5 - invalid, then NAK the message with the corresponding error code and terminates the validation 5. Checks for /CHGS/ immediately after /OCMT/3!a15d/ If /CHGS/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: 7.4.10.4 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation Field 77A (Narrative) Format 35x[(CrLf)35x], optionally lines 2 to 20 Validation The system performs the following validation: 1. Maximum 20 lines, maximum 35 characters per line (X character set) 2. Second through 20th line If present, defined as 35x: • if the 2 checks here above are OK, then goes to point 3 • otherwise the message is NAKed with the corresponding error code 3. Throughout the field content, removes all (CrLf), if any 4. Scans for /OCMT/ If /OCMT/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format 3!a15d/ is: - valid, then goes to point 5 - invalid, then NAK the message with the corresponding error code and terminates the validation 5. Checks for /CHGS/ immediately after /OCMT/3!a15d/ 23 July 2021 87 Standards MT November 2021 General Information Euro-Related Information (ERI) If /CHGS/ is: • not present, then performs next field validation • present more than once, then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: 7.4.10.5 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation Field 79 (Narrative) Format 50x [(CrLf)50x], optionally lines 2 to 35 Validation The system performs the following validation: 1. Maximum 35 lines, maximum 50 characters per line (X character set) 2. Second through 35th line If present, defined as 50x: • if the 2 checks (point 1) are OK, then goes to point 3 • otherwise the message is NAKed with the corresponding error code 3. Throughout the field content, removes all (CrLf), if any 4. Scans for /OCMT/ If /OCMT/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: - valid, then goes to point 5 - invalid, then NAK the message with the corresponding error code and terminates the validation 5. Checks for /CHGS/ immediately after /OCMT/3!a15d/ If /CHGS/ is: 23 July 2021 • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ 88 Standards MT November 2021 General Information Euro-Related Information (ERI) If format is: 7.4.10.6 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation Field 86 (Narrative) Format 65x [(CrLf)65x], optionally lines 2 to 6 Validation The system performs the following validation: 1. Maximum 6 lines, maximum 65 characters per line (X character set) 2. Second through sixth line If present, defined as 65x: • if the 2 checks (point 1) are OK, then goes to point 3 • otherwise the message is NAKed, with the corresponding error code 3. Throughout the field content, removes all (CrLf), if any 4. Scans for /OCMT/ If /OCMT/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: - valid, then goes to point 5 - invalid, then NAK the message with the corresponding error code and terminates the validation 5. Checks for /CHGS/ immediately after /OCMT/3!a15d/ If /CHGS/ is: • not present, then performs next field validation • present more than once (double), then NAK the message with the Error code T47 and terminates the validation • present only once, then validates the format 3!a15d/ If format is: 23 July 2021 - valid, then goes to next field validation - invalid, then NAK the message with the corresponding error code and terminates the validation 89 Standards MT November 2021 General Information Legal Notices Legal Notices Copyright SWIFT © 2021. All rights reserved. Disclaimer The information in this publication may change from time to time. You must always refer to the latest available version. SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy - End-User License Agreement, available at www.swift.com > About Us > Legal > IPR Policies > SWIFT Standards IPR Policy. Translations The English version of SWIFT documentation is the only official and binding version. Trademarks SWIFT is the trade name of S.W.I.F.T. SC. The following are registered trademarks of SWIFT: 3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, the Standards Forum logo, the SWIFT logo, SWIFT gpi with logo, the SWIFT gpi logo, and UETR. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners. 23 July 2021 90