swift standards category 2 financial institution transfers

SWIFTStandards

Category 2Financial Institution Transfers

May 2005 Standards Release

March 2005 edition

Copyright

Copyright © S.W.I.F.T. SCRL ("SWIFT"), avenue Adèle 1, B-1310 La Hulpe, Belgium, 2005. All rights reserved. No part of this publication may be copied or reproduced, stored in a retrieval system, sold or transferred to any person, in whole or in part, in any manner or form or on any media, without the prior written permission of SWIFT. The recipient is, however, authorised to copy or reproduce this publication within its own organisation as may be reasonably necessary for the purpose for which it is supplied. Any such copy or reproduction will include the following: acknowledgement of the source, reference and date of publication, and all notices set out on this page.

Confidentiality

This publication may contain proprietary and/or confidential information of SWIFT and/or its suppliers. The recipient should not disclose this publication to third parties without the prior written permission of SWIFT.

Disclaimer

Although SWIFT has used reasonable efforts to ensure accuracy of its contents, SWIFT assumes no liability for any inadvertent error or omission that may appear in this publication. The information in this publication is the latest available at the date of its production, and may change from time to time.

Translations

SWIFT official documentation is published in English only. Even where SWIFT has exceptionally permitted the translation of the documentation, only the English version is valid.

Warning to all Users

Access to SWIFT Products and Services is subject to certain eligibility criteria and other conditions. SWIFT Users should always refer to their contractual arrangements with SWIFT and, as relevant, to the Message Usage Restriction tables contained in the FIN Service Description, to ascertain which portions of the SWIFT Products and Services described in this document apply to them.

Trademarks and Patents

SWIFT, S.W.I.F.T., the SWIFT logos, Sibos, SWIFTNet, SWIFTAlliance, SWIFTStandards, SWIFTReady and Accord are trademarks of S.W.I.F.T. SCRL. Other SWIFT-derived product and service names, such as but not limited to SWIFTSolutions and SWIFTSupport, are tradenames of S.W.I.F.T. SCRL. SWIFT is the trading name of S.W.I.F.T. SCRL. All other product or company names that may be mentioned in this publication are tradenames, trademarks or registered trademarks of their respective owners. Patent pending: SWIFTNet.

March 2005 edition

Table of Contents

Table of Contents

Introduction ........................................................................................................................... 1

Category 2 Message Types.................................................................................................... 5

Euro – Impact on Category 2 Message Standards................................................................. 9

MT 200 Financial Institution Transfer for its Own Account .............................................. 21

MT 201 Multiple Financial Institution Transfer for its Own Account ................................ 34

MT 202 General Financial Institution Transfer ................................................................... 49

MT 203 Multiple General Financial Institution Transfer .................................................... 72

MT 204 Financial Markets Direct Debit Message .............................................................. 94

MT 205 Financial Institution Transfer Execution ............................................................. 113

MT 206 Cheque Truncation Message ............................................................................... 131

MT 207 Request For Financial Institution Transfer .......................................................... 166

MT 210 Notice to Receive ................................................................................................ 187

MT 256 Advice of Non-Payment of Cheques ................................................................... 197

MT 290 Advice of Charges, Interest and Other Adjustments ........................................... 216

MT 291 Request for Payment of Charges, Interest and Other Expenses .......................... 217

MT 292 Request for Cancellation ..................................................................................... 218

MT 295 Queries ................................................................................................................. 219

MT 296 Answers ............................................................................................................... 220

MT 298 Proprietary Message ............................................................................................ 221

MT 299 Free Format Message .......................................................................................... 222

Glossary of Terms ............................................................................................................. 223

May 2005 Standards Release iii

Category 2 - Financial Institution Transfers

iv May 2005 Standards Release

Introduction

Introduction

OverviewCategory 2 consists of four types of messages exchanged between and on behalf of financial institutions. These are:

• financial institution transfers, which are orders for the movement of funds, originated by a financial institution, in favour of itself or another financial institution.

• notice to receive, which notifies a financial institution of funds which are to be received for the Sender's account.

• payment messages issued by financial institutions to claim funds from SWIFT member banks.

• cheque truncation messages, to debit, obtain credit or inform of non-payment of truncated cheques.

The messages in this category deal with payments, or information about payments, in which all parties in the transaction are financial institutions.

ChangesThis volume incorporates the following changes to Category 2 Financial Institution Transfers as noted in the Standards Release Guide (SRG) 2005 and the relevant updates to the SRG 2005:

• BEIs are expanded to include SMDP (Securities Market Data Providers),

• deletion of the MT 293 Information Service Message.

IMPORTANT

This volume contains information effective as of the May 2005 Standards Release. Therefore the Standards volumes as published on the User Handbook August 2004 edition remain effective until May 2005.

Volume Formatting ExplanationCategory 2 of the Standards User Handbook set contains general information about the category and a detailed description of each message type which is currently available for use. For each message type, the following information is provided:

May 2005 Standards Release 1


Message Type Scope

The scope specifies the Sender and Receiver of the message and provides an explanation on how the message is used. In some messages, an example of the message flow is also provided.

Message Type Format Specifications

The format specifications are the rules for the layout of the message type. This information is provided in table form with the following information:

MT nnn (Message Type Name)

• MT nnn (Message Type Name) provides the message type number and name

• Status indicates if the field is

- M – Mandatory

- O – Optional

The status M for fields in optional (sub)sequences means that the field must be present if the (sub)sequence is present and is otherwise not allowed.

• Tag is the field identification

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

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 C or D 4

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

O 52a Ordering Institution A or D 5

M 71B Details of Charges 6*35x 6

O 72 Sender to Receiver Information 6*35x 7

-----|

M = Mandatory O = Optional

2 May 2005 Standards Release

Introduction

• Content/Options provides permitted field length and characteristics. For information concerning field structure, notation and character restrictions, please see Standards General Information..

• No. identifies the number of the field in the Field Specifications for the message type.

Some messages are separated into sequences of fields, as shown above. An arrow indicates that a sequence of fields may be repeated.

MT Network Validated Rules

Network validated rules are validated on the network, ie, rules for which an error code is defined. 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.

MT Usage Rules

Usage rules are not validated on the network, ie, rules for which no error code is defined, 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 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, which may contain some or all of the following:

• FORMAT specifies the field formats which are allowed for the field.

• PRESENCE indicates if the field is mandatory, optional or conditional in its sequence.

• DEFINITION specifies the definition of the field in this sequence of the message type.

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

• NETWORK VALIDATED RULES specifies rules that are validated on the network, ie, 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, ie, 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, eg, a currency which must be the same for more than one field in the message.

• USAGE RULES specifies rules that are not validated on the network, ie, 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.

• EXAMPLES provides one or more examples of the field as it will be formatted/used.

MT Mapping

MT mapping provides an explanation of 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 the following information:

• Narrative provides a brief description of a transaction

• Information Flow illustrates the relationships between the parties involved in the message. An explanation of the flow diagram can be found in Standards General Information.

• SWIFT Format provides the message using the defined SWIFT format, and providing an explanation, where necessary, of the fields which have been used.


Category 2 Message Types


The following table lists all message types defined in category 2.

For each message type, there is a short description, an indicator whether the message type requires authentication (Y/N), the maximum message length on input (2,000 or 10,000 characters), whether the use of the message requires registration with SWIFT for use in a message user group (Y/N) and wether value date ordering (VDO) can be requested for the message (Y/N). Value date ordering criteria are described in section 5.4.6 of the General Information volume.

MT MT Name Purpose Authen.Max.

LengthMUG VDO

200 Financial Institution Transfer for its Own Account

Requests the movement of the Sender's funds to its account at another financial institution

Y 2,000 N Y

201 Multiple Financial Institution Transfer for its Own Account

Multiple of the MT 200 Y 2,000 N Y

202 General Financial Institution Transfer

Requests the movement of funds between financial institutions

Y 2,000 N Y

203 Multiple General Financial Institution Transfer

Multiple of the MT 202 Y 2,000 N Y

204 Financial Markets Direct Debit Message

Claims funds from SWIFT member banks

Y 2,000 Y Y

205 Financial Institution Transfer Execution

Further transmits a transfer request domestically

Y 2,000 N Y



206 Cheque Truncation Message

Conveys information on one or more truncated cheques in order to debit or obtain credit under usual reserve

Y 10,000 Y Y

207 Request for Financial Institution Transfer

Requests to debit an ordering financial institution's account held at the receiving financial institution or the account servicing financial institution

Y 10,000 Y Y

210 Notice to Receive

Notifies the Receiver that it will receive funds for the Sender's account

Y 2,000 N Y

256 Advice of Non-Payment of Cheques

Informs the Sender of one or more previously sent MT 206s of non-payment of one or more truncated cheques. It may also be used to specify dishonoured items that result in reversing a previous payment settlement

Y 10,000 Y Y

290 Advice of Charges, Interest and Other Adjustments

Advises an account owner of charges, interest or other adjustments

Y 2,000 N N

291 Request for Payment of Charges, Interest and Other Expenses

Requests payment of charges, interest or other expenses

Y 2,000 N N


LengthMUG VDO



Note:

A MUG, for the purposes of this book, is a group of users which 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 preceding table in the column ‘MUG’.

Registration is free of charge. It is done by sending an MT 999 to SWHQBEBBCOS to the attention of Customer Implementation. To register, the following information must be provided:

• the destination of the requesting institution, ie, the 8 character BIC

• the message type or specific usage of the specified message type

• the contact name and telephone number within the institution

• whether the request is for test and training or live operation, or both

• the requested activation date for testing and training and/or live operation.

292 Request for Cancellation

Requests the Receiver to consider cancellation of the message identified in the request

Y 2,000 N N

295 Queries Requests information relating to a previous message or amendment to a previous message

Y 2,000 N N

296 Answers Responds to an MT 295 Queries message or an MT 292 Request for Cancellation or other message where no specific message type has been provided for a response

Y 2,000 N N

298 Proprietary Message

Contains formats defined and agreed to between users and for those messages not yet live

Y 10,000 N N

299 Free Format Message

Contains information for which no other message type has been defined

Y 2,000 N N


LengthMUG VDO



Activation occurs every Monday. A period of about three weeks is needed between the registration request and the actual activation period.

A user can choose to withdraw from the group. This is done by sending SWIFT a similar request to withdraw.

Upon request to Customer Implementation (see the SWIFT address above), information can be obtained regarding other members of the MUG.


Euro – Impact on Category 2 Message Standards


Deletion of the National Currency Denomination (NCD) Currency Codes

On 1 March 2002, ISO announced the deletion of the NCD currency codes from the official ISO currency code table 4217.

For certain message types, when an NCD is used as the currency of settlement, SWIFT validates to ensure the value date is before 1 January 2002, when these currencies stopped to be legal tender. This validation has been introduced on the network in July 2001.

Until further notice, and where allowed (NCDs cannot be used in settlement amount fields), SWIFT will continue to support NCD currency codes (eg, instructed amounts, ERI) in the relevant fields of its message types.

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

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, eg, value date.

ERI may be specified in free-text field 72, 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.

ERI Usage Guidelines and Rules, Relevant for Category 2

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

• Usage Rules,



• Usage Guidelines.

Usage rules must be complied with, although they are not validated by the network.

Usage guidelines are recommendations on how to specify ERI.

Usage Rules

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 specified in the message, the information in the settlement amount prevails.

Usage Guidelines

1. 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, ie, the use of ERI is not restricted to specific message types.

See the section entitled ‘Messages Likely to Contain ERI’. This section lists, for each message type, the field to specify the settlement amount and the field to specify the original amount. The list is provided to facilitate the implementation of different systems: it is not exhaustive.

2. If ERI is specified in field 72, 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.

3. 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, ie, one message should be used per transaction.

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

5. ERI is designed to be passed on unchanged in the appropriate message types throughout the entire transaction, ie, throughout the chain of messages relating to the transaction. Therefore, it should appear in the appropriate SWIFT messages related to the transaction.



ERI Structure

Message-Specific Guidelines on the Use of ERIThis chapter lists category 2 message types which:

• are likely to contain ERI

• are to be validated against a specified value date

Messages Likely to Contain ERI

The following lists message types that are likely to contain euro-related information (ERI) in field 72.

FORMAT Field 72 6*35x

DEFINITION In addition to previously defined Sender to Receiver information,or other narrative information, field 72 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 field 72.It is recommended that ERI be structured 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, ie, all transaction charges are to be paid by the beneficiary customer, the charges amount has been deducted from the original amount to obtain the settlement amount specified in the message.

USAGE RULES The network will validate the structure of ERI, but not the content.

EXAMPLE :72:/OCMT/USD504938,//CHGS/EUR2,40/



If there are business requirements to specify ERI in other message types, these should be similarly specified in field 72 as explained in the section entitled ERI Structure. Therefore, this list is not exhaustive.

Messages with Value Date Validation

The following list contains messages that can be used to transfer amounts in National Currency Denominations (NCDs). If so, the value date has to be equal to, or before 31 December 2001. If this validation against value date fails, the message will be NAKed (Error Code 'E76'). The list gives the message description, the field containing the NCD amount and the field containing the value date.

This validation is performed since 30 July 2001.

Statement messages are not validated against value date, since they are generally the result of one of the earlier validated messages. Due to the importance of statements it is best not to risk rejection of these messages. Furthermore accounts are not held in NCD since 1 January 2002. Consequently, since that date, statement messages must not contain NCDs.

The currencies concerned are ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE and XEU

MT MT NameSettlement Amount

Field

Repetitive/Non-

Repetitive

ERI Field

Repetitive/Non-

Repetitive

202 General Financial Institution Transfer

32A Value Date, Currency Code, Amount

NR 72 NR


32B Currency Code, Amount

R 72 R



R 72 R


32A Value Date, Currency Code, Amount

NR 72 NR



R 72 NR



ERI Validation and ExamplesThis chapter details the validation of the ERI information and provides examples that give correct and incorrect messages.

General ERI Validation Rules

Codes and format:

• /OCMT/3!a15d/

• /CHGS/3!a15d/

where:

• the currency component ‘3!a’ must be a valid ISO currency code (Error code(s): T52).

• the amount component ‘15d’ following the currency code must be formatted according to the Field Formatting Rules given in Section 5.4.2 Numbers of the Standards General Information. If not properly formatted the system will NAK the message with Error Code T40, T43, T33 or other generic error codes as deemed necessary.

MT MT Name NCD Amount FieldValue Date

Field

200 Financial Institution Transfer for its Own Account

32A 32A

201 Multiple Fincancial Institution Transfer for its Own Account

32B (each occurrence) 30

202 General Financial Institution Transfer 32A 32A






32A 32A


32B (each occurrence) 30 in Seq A

210 Notice to Receive 32B (each occurrence) 30



• the amount component ‘15d’ will not be checked on the maximum number of decimal digits allowed for the relevant currency code.

In the following examples the currency code ‘XYZ’ is invalid. The message is NAKed:

• :72:/OCMT/XYZ150,/(CrLf)/CHGS/EUR1,(CrLf)

• :72:xxxxx/OCMT/EUR10000,//CHGS/XYZ1,/(CrLf)

In the following examples the amount components are invalid. The message is NAKed:

• :72:/OCMT/EUR,12/(CrLf)

• :72:/OCMT/EUR123/(CrLf)

Note: The amount component must be followed by a slash character, ‘/’ (Error code(s): T31). In the following example the amount component is invalid. The message is NAKed

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

Messages and fields impacted

The ERI validation will be performed in fields:

• 72 Structured Format and 72 Narrative, of all messages except the MTs 292, 295, 296 and 299

In the following example OCMT is validated. The message is not NAKed:

• :72:xxxxx/OCMT/EUR10,25/xxxxx(CrLf)

In the following example OCMT and CHGS are validated. The message is not NAKed:

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

No ERI validation hierarchy between the fields

Note, 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, ie, a repetitive block of fields or sequence.

/CHGS/ is only validated if /OCMT/ is present

The ERI validation for the code /CHGS/ (6 characters) will be performed only if it immediately follows /OCMT/3!a15d/ in the same occurrence of that field. Therefore, if /OCMT/ is present in a first occurrence of field 72 and /CHGS/ is present in a following occurrence of field 72 (but /OCMT/ is not present in that field 72), then the system does not validate the format following /CHGS/ in the second field 72.



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

• :72:xxxxx/CHGS/EUR1,40/xxxxx(CrLf)

Sequence of codes is required

Within a field, the sequence of the codes /OCMT/ and /CHGS/ is relevant. Only if /OCMT/ appears immediately before /CHGS/, will the ERI validation be applied to /CHGS/.

In the following examples OCMT and CHGS are validated. The message is not NAKed:

Example 1 (structured field 72):

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

Example 2 (free format field 72):

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

In the following example only OCMT is validated because CHGS does not immediately follow OCMT. The message is not NAKed:


• :72:xxxxxxxxxx(CrLf)//xxxxxxxxxx(CrLf)/OCMT/EUR10000,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)/CHGS/EUR50,/(CrLf)//xxxxxxxxxx(CrLf)

Note: If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognized as part of the ERI and will not be subject to the ERI validation.

In the following examples only OCMT is validated. The message is not NAKed:


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


• :72:xyz/CHGS/EUR4,00/xxx/OCMT/EUR1234,0(CrLf)//0/xxx(CrLf)



In the following example, 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)

Double codes are not allowed in one field

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

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

In the following examples OCMT is found twice. The messages are NAKed:


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


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

In the following example 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 recognized as part of the ERI and thus not be subject to the ERI validation.



In the following example OCMT and the second occurrence of CHGS are validated. The messages are not NAKed.


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


• :72:xyz/CHGS/EUR4,00//OCMT/EUR1234,00//(CrLf)//CHGS/EUR4,00/(CrLf)

Consistent with current standards

In all fields where the ERI validation is defined, the ‘generic’, ie, current, validation must still be performed. For example,

a. field 72 is always checked for maximum 6 lines, with a maximum of 35 characters per line.

b. field 72, structured format, the first line must begin with a ‘/’, and the second through sixth line (optional), must begin with a ‘/’ or a ‘//’.

Maximum use of the generic format definition

In order to maximize 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.

Example in narrative format of information that follows ERI related codes, split across lines:

• :72:xxxxx/OCMT/EUR12345,(CrLf)12//CHGS/E(CrLf)UR12,/(CrLf)

Example in structured format of ERI related codes, split across lines:

• :72:/INS/BANKCCCY/OCMT/EUR1234,//CH(CrLf)//GS/EUR1,/xxxxxxx(CrLf)

Example in narrative format of ERI related codes, split across lines:

• :72:xxxxx/OC(CrLf)MT/EUR100,/(CrLf)



No ERI validation performed in … :

• field 72, if the REJT or RETN codes are present, ie, the special REJT/RETN validation for fields 72 prevails.

• MTs 292, 295, 296 and 299.

Details of the ERI Validation Implementation

Field 72 (Structured format)

The system will perform 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>

a. If the 3 checks here above are OK, then go to point 4

b. Otherwise the message is NAK with the corresponding error code

4. Throughout the field content remove all (CrLf‘//’), if any

5. Throughout the field content remove all (CrLf), if any

6. Scan for /OCMT/

a. If /OCMT/ is not present, then perform next field validation

b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation

c. If /OCMT/ is present only once, then validate the format <3!a15d>>

FORMAT <INSTR> first line

[(CrLf)(<INSTR> or ‘//’ 33x)] optionally, 2d through 6th line

where <INSTR> is definied 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



• If format is valid, then go to point 7

• If format is not valid, then NAK the message with the corresponding error code and terminate the validation

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

a. If /CHGS/ is not present, then perform next field validation

b. If /CHGS/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation

c. If /CHGS/ is present only once, then validate the format <3!a15d/>

• If format is valid, then go to next field validation


Field 72 (Narrative)

The system will perform 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

a. If the 2 checks here above are OK, then go to point 3

b. Otherwise the message is NAK with the corresponding error code

3. Throughout the field content remove all (CrLf), if any

4. Scan for /OCMT/

a. If /OCMT/ is not present, then perform next field validation

b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation

c. If /OCMT/ is present only once, then validate the format <3!a15d/>

• If format is valid, then go to point 5.


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

a. If /CHGS/ is not present, then perform next field validation

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



b. If /CHGS/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation

c. If /CHGS/ is present only once, then validate the format <3!a15d/>

• If format is valid, then go to the next field validation

• If format is not valid, then NAK the message with the corresponding error code and terminate the validation.


MT 200

MT 200 Financial Institution Transfer for its Own Account

MT 200 ScopeThis message type is sent by an account owner to one of its account servicing institutions.

It is used to request the movement of funds from an account that the Receiver services for the Sender to an account that the Sender has, in the same currency, with another financial institution.

MT 200 Format Specifications

MT 200 Financial Institution Transfer for its Own Account

MT 200 Network Validated RulesThere are no network validated rules for this message type.

MT 200 Usage Rules• The beneficiary of this transfer is always the Sender.

• The Receiver and the account with institution are normally in the same country.



M 32A Value Date, Currency Code, Amount 6!n3!a15d 2

O 53B Sender's Correspondent [/1!a][/34x][35x]

3

O 56a Intermediary A or D 4

M 57a Account With Institution A, B or D 5





• In those cases where the account owner wishes to instruct its account servicing institution either to transfer funds between two accounts serviced by the Receiver, or to debit its account with the Receiver and to credit one of its several accounts at an account with institution, the MT 202 General Financial Institution Transfer or the MT 203 Multiple Financial Institution Transfer must be used.

• In those cases where the sender wants the account servicing institution to do a book transfer the MT 202 General financial institution transfer or the MT 203 Multiple financial institution transfer must be used.

MT 200 Field Specifications

1. Field 20: Transaction Reference Number

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the reference assigned by the Sender to unambiguously identify the message.

NETWORK VALIDATED RULES

This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).

2. Field 32A: Value Date, Currency Code, Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the value date, currency and amount to be transferred.


Date must be a valid date expressed as YYMMDD (Error code(s): T50).

Currency must be a valid ISO 4217 currency code (Error code(s): T52).

16x

Option A 6!n3!a15d (Date) (Currency) (Amount)


MT 200

The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

3. Field 53B: Sender's Correspondent

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the account of the Sender which is to be debited.

USAGE RULES

In those cases where there are multiple direct account relationships, in the currency of the transaction, between the Sender and the Receiver, and one of these accounts is to be used, the account to be debited must be indicated in this field with the Party Identifier only.

When there is a single direct account relationship, in the currency of the transaction, between the Sender and the Receiver, and this is the account to be used for reimbursement, field 53B must not be present.

4. Field 56a: Intermediary

FORMAT

PRESENCE

Optional

DEFINITION

This field identifies a party between the Receiver and the account with institution through which the transaction must pass.

CODES

Party Identifier may be used to indicate a national clearing system code.

The following codes may be used, preceded by a double slash ‘//’:

Option B [/1!a][/34x][35x]

(Party Identifier)(Location)

Option A [/1!a][/34x]4!a2!a2!c[3!c]

(Party Identifier)(BIC)

Option D [/1!a][/34x]4*35x

(Party Identifier) (Name & Address)



with option A:

CODES

with option D:

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

ES 8..9n Spanish Domestic Interbanking Code

FW without 9 digit code Pay by Fedwire

GR 7!n HEBIC (Hellenic Bank Identification Code)

HK 3!n Bank Code of Hong Kong

IE 6!n Irish National Clearing Code (NSC)

IN 11!c Indian Financial System Code (IFSC)

IT 10!n Italian Domestic Identification Code

PT 8!n Portuguese National Clearing Code

RT Pay by Real Time Gross Settlement

SC 6!n UK Domestic Sort Code

ZA 6!n South African National Clearing Code





CH 6!n CHIPS Universal Identifier

CP 4!n CHIPS Participant Identifier


FW 9!n Fedwire Routing Number








MT 200


The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45).

The BIC must not be a BEI. Please refer to the latest version of the BIC Directory - Corporations for more information on BEIs. This error code applies to all types of BICs referenced in a FIN message including SWIFT BICs, non-SWIFT BICs, Masters, Synonyms, Live destinations and Test & Training destinations. (Error code(s): C05).

USAGE RULES

When one of the codes //FW (with or without the 9-digit number), //AU, //CP, //IN 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 real-time gross settlement (RTGS), the code //RT should appear in the optional Party Identifier.

The code //RT is binding for the Receiver. If it is used with option A, it must not be followed by any other information. If it is used with option D, it may be followed by another domestic clearing code.

Option A must be used whenever possible.

Option D must only be used in exceptional circumstances, ie, 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.


RU 9!n Russian Central Bank Identification Code


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

SW 6!n Swiss Clearing Code (SIC code)




5. Field 57a: Account With Institution

FORMAT

PRESENCE

Mandatory

DEFINITION

This field identifies the financial institution to which the funds (owned by the Sender and originally placed with the Receiver) are to be transferred.

CODES


The following codes may be used preceded by a double slash ‘//’:

with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x

(Party Identifier)(Name & Address)

















MT 200

CODES

with option D:




USAGE RULES





























6. Field 72: Sender to Receiver Information

FORMAT

The following line formats must be used:

PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver or another party identified in the field.

CODES

One or more of the following codes may be used, placed between slashes (‘/’):

6*35x (Narrative - Structured Format)

Line 1 /8c/[additional information]

Lines 2-6 [//continuation of additional information]or[/8c/[additional information]]

ACC Instructions following are for the account with institution

INT Instructions following are for the intermediary

PHON Please advise account with institution by phone

PHONIBK Please advise intermediary by phone


MT 200

The codes /REJT/ or /RETN/ may be used in this field. If either of these codes is used in the first position of the first line, it is mandatory to follow the Generic Payment Reject Mechanism described in Standards Usage Guidelines.

USAGE RULES

Field 72 must never be used for information for which another field is intended.

Each item of information contained in this field must be preceded by a code which specifically indicates the party for which it is intended.

Codes must be placed between slashes and at the beginning of a line. Additional explanatory information, which may be continued on the next lines, is preceded by a double slash ‘//’.

Narrative text that is not qualified by a code, must start with a double slash ‘//’ on a new line, and should preferably be the last information in this field.

It is strongly recommended to use the standard codes. However, where bilateral agreements covering the use of codes in this field are in effect, the code must conform to the structure of this field.

Use of field 72, particularly with uncoded instructions, may cause delay, because in automated systems, the presence of this field will normally require manual intervention.

This field may contain ERI to transport dual currencies, as explained in the chapter ‘Euro – Impact on Category 2 Message Standards’.

In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

MT 200 Examples

Example 1 Financial Institution Transfer for its Own Account with an AccountWith Institution

Narrative

Value 24 May 2002 UBS, Zürich requests ABN Amro Bank, Amsterdam, to transfer euro 1,000,000 to its account at ING Bank, Amsterdam.

REC Instructions following are for the Receiver

TELE Please advise the account with institution by the most efficient means of telecommunication

TELEIBK Please advise the intermediary by the most efficient means of telecommunication.



The reference for this transaction is 23/200516DEV.

Information Flow

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 200

Receiver ABNANL2A

Message text

Transaction reference number 20:23/200516DEV

Value date/currency code/amount 32A:020524EUR1000000,

57a

D00

2000

1

UBSZurich

ABN Amro BankAmsterdam

Sender

Receiver

(MT 910/950)

(MT 205*)

ING BankAmsterdam

Account With Institution

MT 200

* Or its equivalent domestic clearing message

MT


MT 200

Example 2 Financial Institution Transfer for its Own Account with an Intermediary

Narrative

Value 24 May 2002, Bank Austria, Vienna, requests Chase Manhattan Bank, New York, to transfer US Dollars 1,000,000 to its account at Citibank N.A., Miami, through Citibank N.A., New York.

Bank Austria requests Chase to debit account 34554-3049 for this transfer, using reference 39857579.

Account with institution (1) 57A:INGBNL2A

End of message text/trailer

Note:(1) The Sender's account at the account with institution is to be credited with the funds.

Explanation Format



Information Flow

SWIFT Message

Explanation Format

Sender BKAUATWW

Message type 200

Receiver CHASUS33

Message text

Transaction reference number :20:39857579

Value date/currency code/amount :32A:020524USD1000000,

Sender's correspondent (1) :53B:/34554-3049

Intermediary :56A:CITIUS33

56a

D00

2000

2

Bank AustriaVienna

Chase Manhattan Bank, New York

Sender

Receiver

(MT 910/950)(MT 205*)

Citibank N.A.New York

Intermediary

Citibank N.A.Miami

AccountWith Institution

MT 200


57a

MT


MT 200

Account with institution (2) :57A:CITIUS33MIA


Note:(1) The Sender's account which is to be debited at Chase Manhattan Bank, New York.(2) The Sender's account at the account with institution which is to be credited with the funds in the transfer.

Explanation Format



MT 201 Multiple Financial Institution Transfer for its Own Account

MT 201 ScopeThis multiple message type is sent by an account owner to one of its account servicing institutions.

It is used to request the movement of funds from an account that the Receiver services for the Sender to several accounts that the Sender has, in the same currency, with other financial institutions.

MT 201 Format SpecificationsThe MT 201 consists of two types of sequences:

• The first sequence provides details of the transaction between the Sender and Receiver, ie, the value date and total amount to be transferred, the Sender's correspondent and any other information about this transaction, as necessary.

• The second sequence, which must appear at least twice and, in order to expedite processing, not more than ten times. It provides details of each transaction between the Receiver and a financial institution to which the funds will be transferred. Each sequence includes a TRN, the amount and currency code to be transferred, the identification of the financial institution(s) to which the funds will be transferred and any other information about the transaction, as necessary.

MT 201 Multiple Financial Institution Transfer for its Own Account


M 19 Sum of Amounts 17d 1

M 30 Value Date 6!n 2

O 53B Sender's Correspondent [/1!a][/34x][35x]

3


----->


M 32B Currency Code, Amount 3!a15d 6


MT 201

MT 201 Network Validated RulesC1 The amount in field 19 must equal the sum of the amounts in all occurrences of field 32B

(Error code(s): C01).

C2 The currency code in the amount field 32B must be the same for all occurrences of this field in the message (Error code(s): C02).

C3 The repetitive sequence must appear at least twice, but not more than ten times (Error code(s): T11, T10).

MT 201 Usage Rules• Where the account owner wishes to instruct its account servicing institution either to transfer

funds between two accounts serviced by the Receiver, or to debit its account with the Receiver and to credit one of its several accounts at an account with institution, the MT 202 General Financial Institution Transfer or the MT 203 Multiple General Financial Institution Transfer must be used.

• In those cases where the sender wants the account servicing institution to do a book transfer the MT 202 General financial institution transfer or the MT 203 Multiple financial institution transfer must be used.

• The beneficiary of each transfer is always the Sender.


1. Field 19: Sum of Amounts

FORMAT


M 57a Account With Institution A, B or D 8


-----|


17d (Amount)




PRESENCE

Mandatory

DEFINITION

This field contains the sum of all amounts appearing in each occurrence of field 32B in the message.


The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32B (Error code(s): C03, T40, T43).

2. Field 30: Value Date

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the value date for all transactions in the message.



3. Field 53B: Sender's Correspondent

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the account of the Sender which is to be debited.

USAGE RULES

This field should be used when the Receiver services more than one account for the Sender in the currency of the transactions.

6!n (Date)

Option B [/1!a][/34x][35x]



MT 201

In those cases where there are multiple direct account relationships, in the currency of the transaction, between the Sender and the Receiver, and one of these accounts is to be used, the account to be debited must be indicated in this field with the Party Identifier only.

When there is a single direct account relationship, in the currency of the transaction, between the Sender and the Receiver, and this is the account to be used for reimbursement, field 53B must not be present.


FORMAT


PRESENCE

Optional

DEFINITION

This field specifies additional information which applies to every transaction in the message.

CODES












TELEIBK Please advise the intermediary by the most efficient means of telecommunication



USAGE RULES




Narrative text that is not qualified by a code, must start with a double slash ‘//’ on a new line, and should preferably be the last information in this field.






FORMAT

PRESENCE

Mandatory

DEFINITION

The Transaction Reference Number (TRN) specifies the reference assigned by the Sender to unambiguously identify the message.



USAGE RULES

A different TRN must be assigned to each transaction in the message.

16x


MT 201

6. Field 32B: Currency Code, Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the currency and amount to be transferred in each individual transaction within the message.





FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the party between the Receiver and the account with institution through which the transaction must pass.

CODES



with option A:

Option B 3!a15d (Currency) (Amount)

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x




CODES

with option D:
































MT 201



The BIC must not be a BEI. Please refer to the latest version of the BIC Directory - Corporations for more information on BEIs. This error code applies to all types of BICs referenced in a FIN message including SWIFT BICs, non-SWIFT BICs, Masters, Synonyms, Live destinations and Test & Training destinations.(Error code(s): C05).

USAGE RULES















FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the financial institution to which the funds (owned by the Sender and originally placed with the Receiver) are to be transferred.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x


















MT 201

CODES

with option D:




USAGE RULES






























FORMAT


PRESENCE

Optional

DEFINITION

This field contains additional information which applies to the transaction specified.

CODES










MT 201


USAGE RULES




Narrative text that is not qualified by a code, must start with a double slash ‘//’ on a new line, and, should preferably be the last information in this field.





MT 201 Examples

Narrative

Value 28 May 2002, UBS, Zürich requests ABN Amro Bank, Amsterdam, to transfer euro 61,000 to its accounts at the following financial institutions:






Information Flow

ING Bank, Amsterdam EUR 5000,

SNS Bank Nederland NV, Amsterdam EUR 7500,

ABN Amro Bank, Rotterdam EUR 12500,

Crédit Lyonnais, Paris EUR 6000,

Deutsche Bank AG, Frankfurt by telex throughING Bank, Amsterdam

EUR 30000,

56aD

0020

003

UBSZurich


ING BankAmsterdam

ING BankAmsterdam

SNS Bank Nederland NVAmsterdam

ABN AmroBankRotterdam

CréditLyonnaisParis

Deutsche Bank AGFrankfurt

Sender

Receiver

Intermediary


MT 201

57a 57a 57a 57a 57a

MT


MT 201

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 201

Receiver ABNANL2A

Message text

Sum of amounts in the message :19:61000,

Value date :30:020528

Transaction reference number (1) :20:1234/22

Currency code and amount :32B:EUR5000,

Account with institution :57A:INGBNL2A



Account with institution :57A:BBSPNL2A



Account with institution :57B:ROTTERDAM



Account with institution :57A:CRLYFRPP



Intermediary :56A:INGBNL2A

Account with institution :57A:DEUTDEFF



Sender to Receiver information :72:/TELE/


Note: There are 5 requests for transfer within the message

Explanation Format


MT 202

MT 202 General Financial Institution Transfer

MT 202 ScopeThis message is sent by or on behalf of the ordering institution directly, or through correspondent(s), to the financial institution of the beneficiary institution.

It is used to order the movement of funds to the beneficiary institution.

This message may also be sent to a financial institution servicing multiple accounts for the Sender to transfer funds between these accounts. In addition it can be sent to a financial institution to debit an account of the Sender serviced by the Receiver and to credit an account, owned by the Sender at an institution specified in field 57a.


MT 202 General Financial Institution Transfer

Status Tag Field Name Content/Options No



----->

O 13C Time Indication /8c/4!n1!x4!n 3

-----|



O 53a Sender's Correspondent A, B or D 6

O 54a Receiver's Correspondent A, B or D 7


O 57a Account With Institution A, B or D 9

M 58a Beneficiary Institution A or D 10





MT 202 Network Validated RulesC1 If field 56a is present, then field 57a must also be present (Error code(s): C81).

MT 202 Usage Rules• All parties to the transaction must be financial institutions.

• The transfer of funds between the ordering institution and the beneficiary institution is always related to another transaction. Field 21 must refer to this transaction.

• If the Sender wishes to instruct the Receiver to debit its account serviced by the Receiver and to credit one of its several accounts at an institution specified in field 57a, field 58A must contain the number of the account to be credited and the name of the Sender.

If the Sender wishes to instruct the Receiver that funds are to be moved between two accounts owned by the Sender and serviced by the Receiver, field 53B must specify the number of the account to be debited and field 58A the number of the account to be credited and the name of the Sender.



FORMAT

PRESENCE

Mandatory

DEFINITION




2. Field 21: Related Reference

FORMAT

16x

16x


MT 202

PRESENCE

Mandatory

DEFINITION

This field contains a reference to the related transaction

CODES

If the Sender is not the originator of the transaction and no related reference is received, the code NONREF must be used in this field.



USAGE RULES

If the related message is an MT 103 Single Customer Credit Transfer, this field will contain the field 20 Sender’s Reference of that MT 103.

In all other cases, this field will contain a reference to the related transaction which is meaningful to the beneficiary institution, eg, the common reference in an MT 300 Foreign Exchange Confirmation, field 21 of an MT 202 General Financial Institution Transfer, an MT 205 Financial Institution Transfer Execution or an MT 400 Advice of Payment.

3. Field 13C: Time Indication

FORMAT

PRESENCE

Optional

DEFINITION

This repetitive field specifies one or several time indication(s) related to the processing of the payment instruction.

CODES

One of the following codes may be used, placed between slashes (‘/’):

Option C /8c/4!n1!x4!n (Code)(Time indication)(Sign)(Time offset)




Time indication must be a valid time expressed as HHMM (Error code(s): T38).

Sign is either "+" or "-" (Error code(s): T15).

Time offset is expressed as ‘HHMM’, where the hour component, ie, ‘HH’, must be in the range of 00 through 13, and the minute component, ie, ‘MM’, must be in the range of 00 through 59. Any ‘HH’ or ‘MM’ component outside of these range checks will be disallowed (Error code(s): T16).

USAGE RULES

The time zone in which Time is expressed is to be identified by means of the offset against the UTC (Coordinated Universal Time - ISO 8601).

EXAMPLE

Assume a financial institution in London is sending a payment instruction on 5 January related to CLS in which it indicates that money has to be funded to CLS bank by 09.15 CET.

Time indication field will be completed as follows:

:13C:/CLSTIME/0915+0100

Explanation:

0915 is the time by which the money has to be funded to CLS bank. It has been agreed that CLSTIME is to be indicated in CET (see codes above).

+ 0100 is the offset of CET against UTC in January (ie during winter time).

If the same instruction had been sent on 10 June (ie during summer time), time indication field would have been completed as follows:

:13C:/CLSTIME/0915+0200

Offsets of local time zones against UTC are published in the green section of the BIC Directory.


FORMAT

CLSTIME The time by which the funding payment must be credited, with confirmation, to the CLS Bank's account at the central bank, expressed in Central European Time (CET).

RNCTIME The time at which a TARGET payment has been credited at the receiving central bank, expressed in Central European Time (CET).

SNDTIME The time at which a TARGET payment has been debited at the sending central bank, expressed in Central European Time (CET).



MT 202

PRESENCE

Mandatory

DEFINITION






5. Field 52a: Ordering Institution

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the ordering institution when other than the Sender of the message.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x











CODES

with option D:





























MT 202

USAGE RULES

When the Sender of an initial MT 202 is also the ordering institution, ie, this field is not used, that Sender will be identified in this field in any subsequent messages as the ordering institution.

This field must be forwarded to the beneficiary institution.

The coded information contained in field 52a must be meaningful to the Receiver of the message.

Option A is the preferred option.

Option D should only be used when the ordering financial institution has no BIC.

6. Field 53a: Sender's Correspondent

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the account or branch of the Sender or another financial institution through which the Sender will reimburse the Receiver.




USAGE RULES

When the Sender instructs the Receiver to transfer funds between two accounts owned by the Sender and serviced by the Receiver, this field must be used with option B to identify the account to be debited.

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x




If there is no direct account relationship, in the currency of the transaction, between the Sender and the Receiver (or branch of the Receiver when specified in field 54a), then field 53a must be present.

When field 53a is present and contains a branch of the Sender, the need for a cover message is dependent on the currency of the transaction, the relationship between the Sender and the Receiver and the contents of field 54a, if present.

A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both the Sender's correspondent and a branch of the Receiver, and the Sender intends to send a cover message to the branch of the Receiver. In this case, the Receiver will be paid by its branch in field 53a.

In all other cases, when field 53a is present, a cover message, ie, MT 202/203 or equivalent non-SWIFT, must be sent to the financial institution identified in field 53a.

When field 53B is used to specify a branch city name, it must always be a branch of the Sender.

The absence of fields 53a and 54a implies that the single direct account relationship between the Sender and Receiver, in the currency of the transfer, will be used.

The use and interpretation of fields 53a and 54a is, in all cases, dictated by the currency of the transaction and the correspondent relationship between the Sender and the Receiver relative to that currency.

7. Field 54a: Receiver's Correspondent

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the branch of the Receiver or another financial institution at which the funds will be made available to the Receiver.



Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x



MT 202


USAGE RULES

The absence of fields 53a and/or 54a implies that the single direct account relationship between the Sender and Receiver, in the currency of the transfer, will be used.

In those cases where field 54a contains a branch of the Receiver, and is not preceded by field 53a, or field 53a contains an account of the Sender serviced by the Receiver's branch, the Receiver will claim reimbursement from its branch.

If field 54a contains a branch of the Receiver and field 53a contains a branch of the Sender, the Receiver will claim reimbursement from its branch or will be paid by its branch, depending on the currency of the transfer and the relationship between the Sender and the Receiver.

In all other cases where field 54a contains a branch of the Receiver, the Receiver will be paid by its branch in field 54a.

A branch of the Sender must not appear in field 54a.

If the branch of the Sender or other financial institution specified in field 53a is also the account servicer for the Receiver, field 54a must not be present.

Field 54a containing the name of a financial institution other than the Receiver's branch must be preceded by field 53a; the Receiver will be paid by the financial institution in field 54a.

The use and interpretation of fields 53a and 54a is in all cases dictated by the currency of the transaction and the correspondent relationship between the Sender and the Receiver relative to that currency.


FORMAT

PRESENCE

Optional

DEFINITION


Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x




CODES



with option A:

CODES

with option D:




























MT 202




USAGE RULES

When one of the codes //FW (with or without the 9-digit number), //AU, //CP, //IN or //RT is used, it should appear only once and in the first of the fields 56a, 57a and 58a of the payment instruction.


















FORMAT

PRESENCE

Conditional (C1)

DEFINITION

This field identifies the financial institution, when other than the Receiver, which will pay or credit the beneficiary institution.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x


















MT 202

CODES

with option D:




USAGE RULES





























10. Field 58a: Beneficiary Institution

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the financial institution which has been designated by the ordering institution as the ultimate recipient of the funds being transferred.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x








MT 202

CODES

with option D:




































USAGE RULES

When the Sender instructs the Receiver to either credit one of several accounts owned by the Sender at an institution specified in field 57a, or transfer funds between two accounts owned by the Sender and serviced by the Receiver, option A must be used to specify the account to be credited and the name of the Sender.

It is strongly recommended that when clearing payments take precedence over book transfer and book transfer is requested, Party Identifier be used to specify the account of the beneficiary.








FORMAT





MT 202

PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver.

CODES



USAGE RULES







BNF Information following is for the beneficiary

INS The instructing institution which instructed the Sender to execute the transaction



PHONBEN Please advise/contact beneficiary/claimant by phone




TELEBEN Please advise the beneficiary/claimant by the most efficient means of telecommunication








MT 202 Examples

Example 1 MT 202 as a Cover Payment

Narrative

Value 27 May 1998, Franz Holzapfel G.m.b.H. orders Bank Austria, Vienna, to pay pounds sterling 1,285.40 into H.F. Janssen's account (number 125-00698) with ABN Amro Bank, Amsterdam.

Bank Austria sends two SWIFT messages:

A. A customer transfer request to ABN Amro Bank, Amsterdam, using reference 494934/DEV.

B. A cover message for the Pounds Sterling payment, which is provided through its account number 15158000 at Midland Bank, London.


MT 202

Information Flow

Message A SWIFT MT 103 Single Customer CreditTransfer

SWIFT Message, MT 103

Explanation Format

Sender BKAUATWW

Message type 103

Receiver ABNANL2A

Message text

Transaction reference number :20:494934/DEV

Bank operation code :23B:CRED

Value date/currency code/amount :32A:980527GBP1285,40

Currency/Instructed Amount :33B:GBP1285,40

50

53a

D00

2000

4

Bank AustriaVienna

Franz Holzapfel GmbHVienna

ABN Amro BankAmsterdam(Field 58a of MT 202)

Sender

Receiver

Ordering Customer

Midland BankLondon(Receiver of MT 202)

Sender'sCorrespondent

(Message BMT 202)

MT 103

Message AMT



Message B SWIFT MT 202 Cover Message

Information Flow

Ordering customer :50K:FRANZ HOLZAPFEL GMBH VIENNA

Sender's correspondent (1) :53A:MIDLGB22

Beneficiary customer :59:/125-00698 H.F. JANSSEN LEDEBOERSTRAAT 27 AMSTERDAM

Details of charges :71A:SHA


Note:(1) Field 53A indicates the institution which is to provide the funds to the Receiver on behalf of the Sender.

Explanation Format

58a

D00

2000

5

Bank AustriaVienna

Midland BankLondon(Field 53a in MT 103)

Sender

Receiver

(Message AMT 103)

ABN Amro BankAmsterdam(Receiver of MT 103)

Beneficiary Institution

MT 202

Message BMT


MT 202


Example 2 MT 202 with Time Indication

Narrative

On 5 January, a CLS settlement member (BANKGB2L) receives an instruction from CLS Bank to fund JPY 5,000,000 by 07.00 AM CET to CLS Bank.

BANKGB2L sends an MT 202 to their JPY nostro correspondent (BANKJPJT), indicating that the funds need to be credited to CLS Bank by 07.00 AM CET.

Explanation Format

Sender BKAUATWW

Message type 202

Receiver MIDLGB22

Message Text

Transaction reference number :20:213804/887

Related reference (1) :21:494934/DEV

Value date/currency code/amount :32A:980527GBP1285,40

Account used for reimbursement :53B:/15158000

Beneficiary institution :58A:ABNANL2A


Note:(1) The related reference is the TRN of the MT 100 Customer Transfer.



Information Flow

SWIFT Message

In the MT 202 which BANKGB2L sends to its JPY correspondent BANKJPJT, it can indicate the time by which BANKJPJT has to credit the funds to CLS bank as follows:

:13C:/CLSTIME/0700+0100

whereby

• 0700 is the time by which the funds have to be credited to CLS Bank. By convention CLS time instructions are quoted in CET.

• +0100 is the offset (during wintertime) of CET against UTC.

Upon receipt of the MT 202, BANKJPJT can recalculate the CET time indication into its local time by comparing the offset in 13C to its own offset against UTC. Japan is UTC +0900, therefore BANKJPJT knows it has to process the instruction before 15.00 local time in Japan.

D00

2002

1

Central Bankof Japan

BANKJPJT

BANKUS33BANKGB2L

CLS Bank

MT300

MT300

MT202 or local clearing

equivalent

Pay in ScheduleMT202


MT 202

Offsets of local delta time zones against UTC are published in the green section of the BIC directory.



MT 203 Multiple General Financial Institution Transfer

MT 203 ScopeThis multiple message is sent by or on behalf of the ordering institution directly, or through correspondent(s), to the financial institution(s) of several beneficiary institution(s). The message contains several transactions.

It is used to order the movement of funds to each beneficiary institution.

This message may also contain order(s) for the movement of the Sender's own funds in favour of itself. This is the case when the Receiver services multiple accounts for the Sender and the funds are to be transferred between these accounts. In addition, it can be sent to a financial institution to debit an account of the Sender serviced by the Receiver and to credit an account owned by the Sender at an institution specified in field 57a.


• The first sequence provides details of the transaction between the Sender and Receiver, ie, the value date and total amount to be transferred, as well as any other information about this transaction, as necessary.

• The second sequence must appear at least twice and, in order to expedite processing, not more than ten times. It provides details of each transaction between the Receiver and a financial institution to which the funds will be transferred. Each sequence includes a TRN, the reference of the related transaction, the amount and currency code to be transferred, the identification of the beneficiary institution and any other institution(s) through which the funds will pass and any other information about the transaction, as necessary.

MT 203 Multiple General Financial Institution Transfer






O 54a Receiver's Correspondent A, B or D 5



MT 203




C3 The repetitive sequence must appear at least twice, but not more than ten times (Error code(s): T11, T10).

C4 If field 56a is present in a transaction, then field 57a must also be present (Error code(s): C81).

MT 203 Usage Rules• All parties to the transactions must be financial institutions.

• If the Sender wishes to instruct the Receiver to debit its account serviced by the Receiver and to credit one of its several accounts at an institution specified in field 57a, field 58A in the related sequence must contain the number of the account to be credited and the name of the Sender.

If the Sender wishes to instruct the Receiver that funds are to be moved between two accounts owned by the Sender and serviced by the Receiver, field 53B must specify the

----->








-----|





number of the account to be debited and field 58A, in the sequence relating to this order, must specify the number of the account to be credited and the name of the Sender.

• Each transfer of funds between the ordering institution and a beneficiary institution is always related to another transaction. Field 21 must refer to this transaction.



FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the sum of all amounts appearing in each occurrence of field 32B in the message.


The integer part of the Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32B (Error code(s): C03, T40, T43).


FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the value date for all transactions in the message.



17d (Amount)

6!n (Date)


MT 203


FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the ordering institution when other than the Sender of the message.

CODES


The following codes may be used preceded by a double slash (‘//’):

with option A:

CODES

with option D:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x




















USAGE RULES

When the Sender of an initial MT 203 message is also the ordering institution ie, this field is not used, that Sender will be identified in this field in any subsequent messages as the ordering institution.

This field must be forwarded to each beneficiary institution.























MT 203


FORMAT

PRESENCE

Optional

DEFINITION





USAGE RULES

When the Sender instructs the Receiver to transfer funds between two accounts owned by the Sender and serviced by the Receiver, this field must be used with option B to identify the account to be debited.


If there is no direct account relationship, in the currency of the transaction, between the Sender and the Receiver (or branch of the Receiver when specified in field 54a), then field 53a must be present.

When field 53a is present and contains a branch of the Sender, the need for a cover message is dependent on the currency of the transaction, the relationship between the Sender and the Receiver and the contents of field 54a, if present.

A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both the Sender's Correspondent and a branch of the Receiver, and the Sender

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x




intends to send a cover message to the branch of the Receiver. In this case, the Receiver will be paid by its branch in field 53a.

In all other cases, when field 53a is present, a cover message, ie, MT202/203 or equivalent non-SWIFT, must be sent to the financial institution identified in field 53a.


The use and interpretation of fields 53a and 54a is, in all cases, dictated by the currency of the transaction and the correspondent relationship between the Sender and Receiver relative to that currency.

5. Field 54a: Receiver's Correspondent

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the branch of the Receiver or another financial institution at which the funds will be made available to the Receiver.




USAGE RULES


In those cases where field 54a contains a branch of the Receiver, and is not preceded by field 53a, or field 53a contains an account of the Sender serviced by the Receiver's branch, the Receiver will claim reimbursement from its branch.

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x



MT 203

If field 54a contains a branch of the Receiver and field 53a contains a branch of the Sender, the Receiver will claim reimbursement from its branch or will be paid by its branch, depending on the currency of the transfer and the relationship between the Sender and the Receiver.

In all other cases where field 54a contains a branch of the Receiver, the Receiver will be paid by its branch in field 54a.

A branch of the Sender must not appear in field 54a.

If the branch of the Sender or other financial institution specified in field 53a is also the account servicer for the Receiver, field 54a must not be present.

Field 54a containing the name of a financial institution other than the Receiver's branch must be preceded by field 53a; the Receiver will be paid by the financial institution in field 54a.

The use and interpretation of fields 53a and 54a is in all cases dictated by the currency of the transaction and the correspondent relationship between the Sender and Receiver relative to that currency.


FORMAT


PRESENCE

Optional

DEFINITION


CODES











USAGE RULES










FORMAT









16x


MT 203

PRESENCE

Mandatory

DEFINITION

The Transaction Reference Number (TRN) specifies the reference assigned by the Sender to unambiguously identify the message.



USAGE RULES

A different TRN must be assigned to each transaction in the message.


FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains a reference to the related transaction.



USAGE RULES

If the related message is an MT 103 Single Customer Credit Transfer, this field will contain the field 20 Sender’s Reference of that MT 103.

In all other cases, this field will contain a reference to the related transaction which is meaningful to the beneficiary institution, eg, the common reference in an MT 300 Foreign Exchange Confirmation, field 21 of an MT 202 General Financial Institution Transfer or MT 400 Advice of Payment.

If the Sender is not the originator of the transaction and no related reference is received, the code NONREF must be used in this field.

16x




FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the currency and amount to be transferred for the transaction in the sequence.





FORMAT

PRESENCE

Optional

DEFINITION


CODES



with option A:


Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 203

CODES

with option D:




































USAGE RULES













MT 203


FORMAT

PRESENCE

Conditional (C4)

DEFINITION

This field specifies the financial institution, when other than the Receiver, which will pay or credit the beneficiary institution.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x



















CODES

with option D:




USAGE RULES























MT 203







FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the financial institution which has been designated by the ordering institution as the ultimate recipient of the funds being transferred.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x









CODES

with option D:
































MT 203




USAGE RULES

When the Sender instructs the Receiver to either credit one of several accounts owned by the Sender at an institution specified in field 57a, or transfer funds between two accounts owned by the Sender and serviced by the Receiver, option A must be used in the related sequence to specify the account to be credited and the name of the Sender.

It is strongly recommended that in those cases where clearing payments take precedence over book transfer and book transfer is requested, the Party Identifier be used to specify the account number of the beneficiary institution.








FORMAT





PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver or other party specified. This information is relevant to the specific transaction in the sequence.

CODES



USAGE RULES


















MT 203




This field may contain ERI to transport dual currencies, as explained in the chapter ‘Euro – Impact on Category 2 Message Standards'.


MT 203 Examples

Narrative

Value 28 May 2002, UBS, Zürich requests ABN Amro Bank, Amsterdam, to transfer euro 5,000,000 as follows:

ING Bank NV, Amsterdamin favour of Morgan Guaranty Trust Co., New York

EUR 500,000

SNS Bank Nederland NV, Amsterdamin favour of Mellon Bank, London

EUR 1,500,000

Citibank, Amsterdamin favour of Citibank, New York

EUR 1,000,000

Dresdner Bank AG, Frankfurt EUR 2,000,000



Information Flow

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 203

Receiver ABNANL2A

Message text

D00

2000

6

UBSZurich


MorganGuaranty Trust CoNew York

Mellon BankLondon

CitibankNew York

ING BankAmsterdam

SNS Bank Nederland NVAmsterdam

CitibankAmsterdam

DresdnerBankFrankfurt

Sender

Receiver

Account WithInstitution

BeneficiaryInstitution

MT 203

58a

57a 57a 57a

58a 58a 58a

MT


MT 203

Sum of amounts in the message :19:5000000,


Transaction reference number (1) :20:2345

Related reference :21:789022


Account with institution :57A:INGBNL2A

Beneficiary institution :58A:MGTCUS33


Related reference :21:ABX2270


Account with institution :57A:BBSPNL2A

Beneficiary institution :58A:MELNGB2X


Related reference :21:CO 2750/26


Account with institution :57A:CITINL2X

Beneficiary institution :58A:CITIUS33


Related reference :21:DRESFF2344BKAUWW


Beneficiary institution :58A:DRESDEFF


(1) There are 4 transfer orders within the message.

Explanation Format



MT 204 Financial Markets Direct Debit Message

Note: The use of this message type requires Message User Group (MUG) registration.

MT 204 ScopeThis message is sent by an exchange or clearing house, or another financial institution to a SWIFT member or submember, to instruct the Receiver of the message to debit the account(s) of a third party specified in the message and to pay or credit the corresponding amount in favour of the Sender of the message.


• Sequence A Common Elements – Reimbursement Details, is a single occurrence sequence and contains default information which is valid for all individual transactions described in sequence B and the total amount to be reimbursed.

• Sequence B Transaction Details, is a repetitive sequence. Each occurrence gives the details concerning one debit.

MT 204 Financial Markets Direct Debit Message


Sequence A Common Elements – Reimbursement Details





O 58a Beneficiary Institution A or D 5


-----> Repetitive Sequence B Transaction Details


O 21 Related Reference 16x 8


MT 204




C3 The repetitive sequence must not appear more than ten times (Error code(s): T10).

MT 204 Usage Rules• This message requires the implementation of special procedures, its use is governed by

bilateral agreements between counterparties. In order to be able to send or receive this message, the interested customers need to formally request SWIFT to be activated within the FIN subapplication group which controls the use of this message.



FORMAT

PRESENCE

Mandatory

DEFINITION


M 32B Transaction Amount 3!a15d 9

M 53a Debit Institution A, B or D 10


-----|


16x






USAGE RULES

This field is intended to ensure proper cross referencing of all related sequences, as well as to provide a unique reference. This reference should normally be quoted in any related reimbursement payments, eg, MT 202 General Financial Institution Transfer, MT 910 Confirmation of Credit and/or MT 950 Statement Message when reimbursement is by a single net amount.


FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the sum of the amounts appearing in each occurrence of field 32B.


The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32B (Error code(s): C03, T40, T43).


FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the value date which the Receiver is requested to apply to all individual transactions in the message. This value will, subject to bilateral agreement, determine the value date to be applied to the reimbursement made by the Receiver in favour of the Sender of the message.

17d (Amount)

6!n (Date)


MT 204




FORMAT

PRESENCE

Optional

DEFINITION

This field identifies the financial institution at which the Sender wishes to receive reimbursement from the Receiver.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x
















CODES

with option D:




























MT 204

USAGE RULES

When one of the codes //FW (with or without the 9-digit number), //AU, //RT, //IN or //CP is used, it should appear only once and in the first of the fields 57a and 58a of the payment instruction.







FORMAT

PRESENCE

Optional

DEFINITION

This field identifies the beneficiary institution, which is always the Sender.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x




CODES

with option D:
































MT 204




USAGE RULES

When one of the codes //FW (with or without the 9-digit number), //AU, //RT, //IN or //CP is used, it should appear only once and in the first of the fields 57a and 58a of the payment instruction.







FORMAT











PRESENCE

Optional

DEFINITION


CODES





CUST The amount to be debited corresponds to a margin call on segregated customer (client) trades/account

CUSTMAR The amount to be debited corresponds to initial/original margin on customer trades (customer account margin)

CUSTVAR The amount to be debited corresponds to variation margin on customer trades (customer account variation)

HOUSE The amount to be debited corresponds to a margin call on house trades (proprietary funds)

HOUSEMAR The amount to be debited corresponds to initial/original margin on house trades (house account margin)

HOUSEVAR The amount to be debited corresponds to variation margin on house trades (house account variation)

METALS Metals call

MKTMAR The amount to be debited corresponds to initial/original margin on market-maker (specialist) trades/account (market-maker account margin)

MKTMKR The amount to be debited corresponds to a margin call on market-maker (specialist) trades/account

MKTVAR The amount to be debited corresponds to variation margin on market-maker (specialist) trades/account (market-maker account variation)

MMPLDG Market-maker pledge

OPTPREM Options premium


TENDER The amount to be debited corresponds to a payment in respect of a tender (delivery)


MT 204


USAGE RULES







This field may contain ERI to transport dual currencies, as explained in the chapter Euro – Impact on Category 2 Message Standards.


FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the reference assigned by the Sender to unambiguously identify the specific transaction.



VARIATN General variation

XMGN Cross-margin account (covers positions hedged, offset or spread over two exchanges)

XMGNMAR Cross-margin account margin (for initial/original margin)

XMGNVAR Cross-margin account margin (for variation margin)

16x



USAGE RULES

This reference should normally be quoted in any related reimbursement payments, eg, MT 202 General Financial Institution Transfer, MT 910 Confirmation of Credit and/or MT 950 Statement Message when reimbursement is by individual amount(s), sent to the Sender.


FORMAT

PRESENCE

Optional

DEFINITION

This field contains a reference attributed by the debit institution to the related transaction.



USAGE RULES

This reference would normally be quoted in any related MT 900 Confirmation of Debit or MT 950 Statement Message, sent to the debit institution.

9. Field 32B: Transaction Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the currency and the amount to be debited to the debit institution identified in field 53a of the same sequence.




16x



MT 204

10. Field 53a: Debit Institution

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the financial institution which is to be debited with the transaction amount.




USAGE RULES

Optional Party Identifier may be used to specify the account number to be debited.


Option D must only be used in exceptional circumstances, ie, when the debit institution cannot be identified by a BIC, and when there is a bilateral agreement between the Sender and Receiver permitting its use. Unless qualified by an account number, the use of option D may prevent the automated processing of the instruction(s) by the Receiver.


FORMAT


Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x






PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver or another party specified. This information is relevant to the specific transaction in the sequence.

CODES





CUST The amount to be debited corresponds to a margin call on segregated customer (client) trades/account

CUSTMAR The amount to be debited corresponds to initial/original margin on customer trades (customer account margin)

CUSTVAR The amount to be debited corresponds to variation margin on customer trades (customer account variation)

HOUSE The amount to be debited corresponds to a margin call on house trades (proprietary funds)

HOUSEMAR The amount to be debited corresponds to initial/original margin on house trades (house account margin)

HOUSEVAR The amount to be debited corresponds to variation margin on house trades (house account variation)

METALS Metals call

MKTMAR The amount to be debited corresponds to initial/original margin on market-maker (specialist) trades/account (market-maker account margin)

MKTMKR The amount to be debited corresponds to a margin call on market-maker (specialist) trades/account

MKTVAR The amount to be debited corresponds to variation margin on market-maker (specialist) trades/account (market-maker account variation)

MMPLDG Market-maker pledge

OPTPREM Options premium


TENDER The amount to be debited corresponds to a payment in respect of a tender (delivery)


MT 204


USAGE RULES








MT 204 Examples

Example 1 The Exchange and the Member have a Common Correspondent Bank

Narrative

The Chicago Mercantile sends an MT 204 to Northern Trust with the instruction to debit the account of Merrill Lynch and to credit its account 1234-ABC, with value date September 21st 1998.

VARIATN General variation

XMGN Cross-margin account (covers positions hedged, offset or spread over two exchanges)

XMGNMAR Cross-margin account margin (for initial/original margin)

XMGNVAR Cross-margin account margin (for variation margin)



Information Flow


Explanation Format

Sender XCMEUS4C

Message type 204

Receiver CNORUS44

Message text

Message reference number :20:XCME REF1

Sum of amounts :19:50000,


Beneficiary institution :58A:/1234-ABCXCMEUS4C

Transaction reference number :20:XCME REF2

Related reference :21:MANDATEREF1

53a

D00

2000

7

The Chicago Mercantile Exchange

Northern TrustChicago

Senderand Beneficiary Institution (58a)

Receiver

Merril LynchNew York

(MT 900Confirmation

of Debit)

(MT 910Confirmation

of Credit)

MT 204

MT


MT 204

The common correspondent bank sends confirmations of credit and debit to the exchange (MT 910) and exchange member (MT 900) as shown below:

SWIFT Message, MT 910, Confirmation of Credit

SWIFT Message, MT 900, Confirmation of Debit

Transaction amount :32B:USD50000,

Debit institution :53A:MLNYUS33


Explanation Format

Sender CNORUS44

Message type 910

Receiver XCMEUS4C

Message text

Transaction reference number :20:MB REF A

Related reference :21:XCME REF1

Account identification :25:ACCOUNT ID OF XCME


Ordering institution :52A:XCMEUS4C


Explanation Format

Sender CNORUS44

Message type 900

Receiver MLNYUS33

Message text

Explanation Format



Example 2 The Exchange does not want to use the account relationship with thecommon correspondent and wants the funds to be transferred to another institution

Narrative

The Chicago Mercantile Exchange asks its member Merrill Lynch International Bank, New York to put up a margin of 50,000 USD.

The Northern Trust Company is the settlement bank of Merrill Lynch at the Chicago Mercantile Exchange.

The Chicago Mercantile sends an MT 204 to Northern Trust with the instruction to debit the account of Merrill Lynch and to credit its account serviced by First National Bank of Chicago in Chicago with a value date September 21st, 1998.

Transaction reference number :20:MB REF B


Account identification :25:ACCOUNT ID OF MLNY


Ordering institution :52A:XCMEUS4C


Explanation Format


MT 204

Information Flow


Explanation Format

Sender XCMEUS4C

Message type 204

Receiver CNORUS44

Message text

Transaction reference number :20:XCME REF1

Sum of amounts :19:50000,


Account with institution :57A:FNBCUS44

Message reference number :20:XCME REF2


53a

D00

2000

8

The Chicago Mercantile Exchange

Northern TrustChicago

Senderand Beneficiary Institution (58a)

Receiver

First ChicagoChicago

Merril LynchNew York

57a

(MT 900Confirmation

of Debit)

(MT 910Confirmation

of Credit)

MT 204

CHIPS

MT



Transaction amount :32B:USD50000,

Debit institution :53A:MLNYUS33


Explanation Format


MT 205

MT 205 Financial Institution Transfer Execution

MT 205 ScopeThis message is sent by the Receiver of a category 2 transfer message, ie, MT 200, 201, 202, 203 or 205, directly or through correspondent(s), to another financial institution located in the same country as the Sender.

It is used to further transmit a funds transfer instruction domestically.


MT 205 Financial Institution Transfer Execution

MT 205 Network Validated RulesC1 If field 56a is present, then field 57a must also be present (Error code(s): C81).




----->

O 13C Time Indication /8c/4!n1!x4!n 3

-----|


M 52a Ordering Institution A or D 5











FORMAT

PRESENCE

Mandatory

DEFINITION





FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains a reference to the related transaction.



USAGE RULES

If the previous message is an MT 202, 203 or 205, this field contains the field 21 Related Reference of that message.

If the previous message is an MT 200 or 201, this field contains the field 20 Transaction Reference Number of that message.

3. Field 13C: Time Indication

FORMAT

16x

16x

Option C /8c/4!n1!x4!n (Code) (Time indication) (Sign) (Time offset)


MT 205

PRESENCE

Optional

DEFINITION

This repetitive field specifies one or several time indication(s) related to the processing of the payment instruction.

CODES

One of the following codes may be used, placed between slashes (‘/’):


Time indication must be a valid time expressed as HHMM (Error code(s): T38).

Sign is either "+" or "-" (Error code(s): T15).

Time offset is expressed as 'HHMM', where the hour component, ie, 'HH', must be in the range of 00 through 13, and the minute component, ie, 'MM', must be in the range of 00 through 59. Any 'HH' or 'MM' component outside of these range checks will be disallowed (Error code(s): T16).

USAGE RULES

The time zone in which Time is expressed is to be identified by means of the offset against the UTC (Coordinated Universal Time - ISO 8601).

EXAMPLE

Assume a financial institution in London is sending a payment instruction on 5 January related to CLS in which it indicates that money has to be funded to CLS bank by 09.15 CET.

Time indication field will be completed as follows:

:13C:/CLSTIME/0915+0100

Explanation:

0915 is the time by which the money has to be funded to CLS bank. It has been agreed that CLSTIME is to be indicated in CET (see codes above).

+ 0100 is the offset of CET against UTC in January (ie during winter time).

CLSTIME The time by which the funding payment must be credited, with confirmation, to the CLS Bank’s account at the central bank, expressed in Central European Time (CET).

RNCTIME The time at which a TARGET payment has been credited at the receiving central bank, expressed in Central European Time (CET).

SNDTIME The time at which a TARGET payment has been debited at the sending central bank, expressed in Central European Time (CET).



If the same instruction had been sent on 10 June (ie during summer time), time indication field would have been completed as follows:

:13C:/CLSTIME/0915+0200

Offsets of local time zones against UTC are published in the green section of the Bic Directory.


FORMAT

PRESENCE

Mandatory

DEFINITION







FORMAT

PRESENCE

Mandatory

DEFINITION

This field identifies the ordering institution from the initial message.

CODES




Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 205

with option A:

CODES

with option D:


































USAGE RULES

If there was no ordering institution specified in the initial message, the Sender of that message will be the ordering institution in this message.

This field must be forwarded to the beneficiary institution.





FORMAT

PRESENCE

Optional

DEFINITION





Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x



MT 205




USAGE RULES

In those cases where there are multiple direct account relationships, in the currency of the transaction, between the Sender and the Receiver, and one of these accounts is to be used for reimbursement, the account to be credited or debited must be indicated in field 53a, using option B with the account number line only.

If there is no direct account relationship, in the currency of the transaction, between the Sender and the Receiver, then field 53a must be present.

A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both the Sender's Correspondent and a branch of the Receiver, and the Sender intends to send a cover message to the branch of the Receiver. In this case, the Receiver will be paid by its branch in field 53a.

When there is a single direct account relationship, in the currency of the transaction, between the Sender and the Receiver, and this is the account to be used for reimbursement, field 53a must not be present.


The use and interpretation of field 53a is, in all cases, dictated by the currency of the transaction and the correspondent relationship between the Sender and Receiver relative to that currency.


FORMAT

PRESENCE

Optional

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x




DEFINITION

This field specifies the party between the Receiver and the account with institution through which this transaction must pass.

CODES



with option A:

CODES

with option D:

























MT 205




USAGE RULES






















FORMAT

PRESENCE

Conditional (C1)

DEFINITION

This field specifies the financial institution, when other than the Receiver, which is to pay or credit the beneficiary institution.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option B [/1!a][/34x][35x]


Option D [/1!a][/34x]4*35x


















MT 205

CODES

with option D:




USAGE RULES






























FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the ultimate recipient of the funds being transferred.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x









MT 205

CODES

with option D:



































USAGE RULES





If the initial transfer message is an MT 200 or 201, this field will be identical to the contents of field 52a in this message.




FORMAT






MT 205

PRESENCE

Optional

DEFINITION


CODES



USAGE RULES







BNF Information following is for the Beneficiary















MT 205 Examples

Narrative

Deutsche Bank, Frankfurt, receives the following MT 202 General Financial Institution Transfer from UBS, Zürich.

Explanation Format

Sender UBSWCHZH80A

Message Type 202

Receiver DEUTDEFF

Message Text

Transaction Reference Number :20:203998988

Related Reference :21:394882

Value Date/Currency Code/Amount :32A:020528EUR1121,50

Account With Institution :57A:DEUTDEHH

Beneficiary Institution :58A:OSCBDEH1

End of Message Text/Trailer


MT 205

Information Flow

As a result of this message, Deutsche Bank, Frankfurt, sends an MT 205 to Deutsche Bank, Hamburg:

SWIFT Message

Explanation Format

Sender DEUTDEFF

Message Type 205

Receiver DEUTDEHH

Message Text

Transaction reference number :20:3004GH3882

Related reference (1) :21:394882

52a

D00

2000

9

Deutsche BankFrankfurt(Receiver of MT 202)

UBSZurich

Deutsche BankHamburg(Field 57a in MT 202)

Sender

Receiver

Otto M. Schroder BankHamburg


Ordering Institution

MT 205

(MT 202)

58a

MT



Note:

(1) Related reference of the transaction which resulted in this message, ie, field 21 of the MT 202.

(2) As there was no ordering institution in the MT 202 which resulted in this message, the Sender of the MT 202 will become the ordering institution.

Value date/currency code/amount :32A:020528EUR1121,50

Ordering institution (2) :52A:UBSWCHZH80A

Beneficiary Institution :58A:OSCBDEH1


Explanation Format


MT 206

MT 206 Cheque Truncation Message


MT 206 ScopeThis message is sent from the beneficiary's financial institution, directly or through one or more other financial institutions, to the issuer's financial institution to convey information about one or more truncated cheques, in the same currency. It is used to debit or obtain credit under usual reserve.

In case of travellers cheques, this message may also be sent to a travellers cheque issuer.

This message may not be used to convey information about truncated cheques sent on a collection basis.

MT 206 Format SpecificationsThe MT 206 consists of three types of sequences:

• Sequence A Common Elements is a non-repetitive sequence and contains information applicable to all individual cheques detailed in sequence B.

• Sequence B Cheque Details is a repetitive sequence where each occurrence provides details of an individual cheque.

• Sequence C Settlement Information is a non-repetitive sequence and contains settlement information applicable to all cheques detailed in sequence B.

MT 206 Cheque Truncation Message


Mandatory Sequence A Common Elements

M 20 Sender's Reference 16x 1

M 28E Message Index/Total 5n/4!c 2

M 23E Cheque Type 4!c[/30x] 3

O 17A Cheque Truncation Indicator 1!a 4

O 52a Safekeeper A, C or D 5

-----> Mandatory Repetitive Sequence B Cheque Details



MT 206 Network Validated RulesC1 If field 23E contains TRAV, then either field 21D or field 29a must be present, but not

both (Error code(s): E11).

C2 If field 23E contains GENC or OTHR and there is no field 29a, the following fields must be present (Error code(s): E19):

M 44A Transaction Reference Number 65x 6

O 21D Cheque Number 35x 7

O 21E Cheque Reference Number 35x 8

O 29a Code Line F or G 9

M 32J Cheque Amount 15d 10

O 58a Issuer's Financial Institution A, C or D 11

O 25 Issuer's Account Number/Code 35x 12

O 26E Represented Cheque Entry 2n 13

O 30 Date of Issue/Encashment 6!n 14

O 39C Place of Issue/Encashment 4*35x 15

O 52a Safekeeper A, C or D 16


-----|

Mandatory Sequence C Settlement Information

O 32A Value Date, Currency Code and Sum of Settlement Amounts

6!n3!a15d 18

O 57a Account With Institution (for Settlement) A, C or D 19

O 58B Beneficiary Institution's Account (for Settlement) [/1!a][/34x][35x]

20

O 19 Settlement Amount 17d 21




MT 206

• field 58a Issuer's Financial Institution

• field 25 Issuer's Account Number/Code

• field 21D Cheque Number

If field 29a is present, the following fields must not be present (Error code(s): E20):

• field 58a Issuer's Account Number/Code

• field 21D Cheque Number

C3 When field 52a is present in sequence A, it must not be present in any occurrence of sequence B.

Conversely, if field 52a is present in any occurrence of sequence B, it must not be present in sequence A (Error code(s): D64).

C4 Field 32A must only be present if field 28E contains the code LAST or ONLY (Error code(s): E21).

If field 23E in sequence A contains GENC or OTHR, and if

field 29a in sequence B is …

then field 21D in sequence B is

…

then field 25 in sequence B is

…

then field 58a in sequence B

is …

Not present Mandatory Mandatory Mandatory

If field 23E in sequence A contains GENC or ‘OTHR’ and if

field 29a in sequence B is …

then field 21D in sequence B is

…

then field 25 in sequence B is

…

then field 58a in sequence B

is …

Present Not allowed Optional Not allowed

If field 52a in sequence A is …then field 52a in any occurrence of sequence

B is …

Present Not allowed

Not present Optional

If field 52a in any occurrence of sequence B is …

then field 52a in sequence A is …

Present Not allowed




C5 Field 19 must only be present if field 28E contains the code MORE or LAST (Error code(s): E22).

C6 When field 28E contains ONLY, the amount specified in field 32A must be equal to the sum of all occurrences of field 32J in sequence B (Error code(s): E23).

When field 28E contains MORE or LAST, field 19 must be equal to the sum of all occurrences of field 32J in sequence B (Error code(s): E24).

MT 206 Usage Rules• The MT 206 can only be sent and/or received by financial institutions which have registered

with SWIFT to send and/or receive the MT 206/MT 256. If a registered user receives an MT 206 without bilateral agreement with the Sender, the Receiver should query the message according to normal banking practice.

• When sending a large number of truncated cheques, it may not be possible to fit them all into one MT 206. In that case:

- Additional MTs 206 must be sent, and they are chained using field 28E.

- All fields present in sequence A except field 28E must be repeated and contain exactly the same content.

- Field 32A of the last message must contain the sum of all fields 19 of all chained messages.

- Field 23E must contain the same value in all messages.

- The currency code in fields 32A of all messages must be the same.

If field 28E in sequence A contains … then field 32A in sequence C is …

LAST Mandatory

MORE Not allowed

ONLY Mandatory

If field 28E in Sequence A contains … then field 19 in Sequence C is …

LAST Mandatory

MORE Mandatory

ONLY Not allowed


MT 206

• The use of this message is subject to bilateral/multilateral agreements between Sender/beneficiary's financial institution and Receiver of the truncation message and where necessary, between the issuer's financial institution and the issuer.


1. Field 20: Sender's Reference

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the reference assigned by the Sender to unambiguously identify the instruction.



EXAMPLE

:20:Ref254

2. Field 28E: Message Index/Total

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the message number and where it is positioned in a chain of messages, or it specifies that it is the only message.

CODES

Total must contain one of following codes (Error code(s): T97):

16x

Option E 5n/4!c (Message Index) (Total)



USAGE RULES

It is recommended that messages be sent in sequence.

All messages belonging to the same sequence must have exactly the same sender's reference in field 20.

When more than one message is needed to convey all information, this field chains different messages by specifying the sequence number in the total number of messages.

EXAMPLE

The first message is

:20:Ref254:28E:1/MORE

and the second is

:20:Ref254:28E:2/MORE

and the third and last message is

:20:Ref254:28E:3/LAST

3. Field 23E: Cheque Type

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the type of cheque that has been truncated.

CODES

Type must contain one of following codes (Error code(s): T47):

LAST This is the last message in a chain of messages.

MORE More messages are following; this is not the last message in the chain of messages.

ONLY This is the one and only message, ie, no chain of messages.

Option E 4!c[/30x] (Type) (Other Code)


MT 206


Subfield 2, Other Code, may only be used after the code OTHR (Error code(s): D81).

USAGE RULES

The code OTHR may only be used when bilaterally agreed. When used, Other Code, must also be present.

EXAMPLE

:23E:GENC

4. Field 17A: Cheque Truncation Indicator

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies whether or not the paper cheque is being sent separately.

CODES

Indicator must contain one of the following codes (Error code(s): T36):

USAGE RULES

This field must be used if this is not covered by the bilateral/multilateral agreement and otherwise must not be present.

EXAMPLE

:17A:Y

GENC General cheques.

OTHR Other type of cheque. This will be followed by a bilaterally agreed code to specify the type of cheque.

TRAV Travellers cheques.

Option A 1!a (Indicator)

N The paper cheque is following.

Y The paper cheque remains at the place of truncation.



5. Field 52a: Safekeeper

FORMAT

PRESENCE

Conditional (C3)

DEFINITION

This field identifies the party at which all truncated cheques, ie, the originals, are securely stored.

CODES



with option A:

CODES

with option C or D:

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option C /34x (Party Identifier)

Option D [/1!a][/34x]4*35x
















MT 206




USAGE RULES



Option D should only be used when the safekeeper has no BIC.

EXAMPLE

:52A:GEBABEBB





















6. Field 44A: Transaction Reference Number

FORMAT

PRESENCE

Mandatory

DEFINITION

This number is generated by the beneficiary's financial institution to identify the transaction that this truncated cheque represents.

EXAMPLE

:44A:abc-1234

7. Field 21D: Cheque Number

FORMAT

PRESENCE

Conditional (C1 and C2)

DEFINITION

This field contains the number of the cheque, which is normally inserted on the cheque by the issuer's financial institution.

EXAMPLE

:21D:000024014014612

8. Field 21E: Cheque Reference Number

FORMAT

PRESENCE

Optional

DEFINITION

This field contains the reference of the cheque generated by the beneficiary's financial institution.

Option A 65x

Option D 35x

Option E 35x


MT 206

USAGE RULES

The cheque reference number is usually the archive reference (microfilm) and is as such used as a link to the physical item.

EXAMPLE

:21E:888014612

9. Field 29a: Code Line

FORMAT

PRESENCE

Conditional (C1)

DEFINITION

This field contains all the information from the code line, ie, the encoded line generally located at the bottom of the cheque which in most cases can be read optically or magnetically, of the original cheque.

USAGE RULES

This field can be subdivided into its different parts with option G using an index to separate them, or it can be completely unstructured, untreated and unaltered using option F.

It may contain any character defined in the ‘z’ character set. The ‘z’ character set contains the characters of both the ‘x’ and ‘y’ character set extended with the characters ‘@’ and ‘#’:

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

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

0 1 2 3 4 5 6 7 8 9

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

@ #

Cr Lf Space

It is highly recommended to take great care when using the character string ‘CrLf’, since these characters are used by the network to indicate an end of field or subfield. Since option F only has 4 subfields, five ‘CrLf’ in the code line would cause a NAK by the network. Also, within option G, after a ‘CrLf’, a number and a slash are expected.

Option F 4*35z (Full Code Line)

Option G 9*1!n/33z (Index) (Partial Code Line)



EXAMPLE

Looking at the cheque from left to right, if the code line on the cheque is xxxxxx yyyyyyyyyyy zzzzzz then this field can be used as follows:

with option G:

:29G:1/xxxxxx2/yyyyyyyyyyy3/zzzzzz

with option F:

:29F:xxxxxx yyyyyyyyyyy zzzzzz

10. Field 32J: Cheque Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the amount of the cheque being truncated (without the currency code).


The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32A (Error code(s): C03, T40, T43).

EXAMPLE

:32J:10000,

11. Field 58a: Issuer's Financial Institution

FORMAT

Option J 15d (Amount)

Option A [/1!a][/34x]4!a2!a2!c[3!c]



Option D [/1!a][/34x]4*35x



MT 206

PRESENCE

Conditional (C2)

DEFINITION

This field identifies the issuer's financial institution.

CODES



with option A:

CODES

with options C or D:












PT 8!n Portugese National Clearing Code















USAGE RULES



EXAMPLE

:58A:ABNANL2A

12. Field 25: Issuer's Account Number/Code

FORMAT

PRESENCE

Conditional (C2)













35x (Account)


MT 206

DEFINITION

This field identifies the issuer based on the account number appearing on the cheque.

EXAMPLE

:25:BE33123456789012

13. Field 26E: Represented Cheque Entry

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the number of times a cheque has been previously presented without being honoured.

EXAMPLE

:26E:1

this cheque has been presented once before

14. Field 30: Date of Issue/Encashment

FORMAT

PRESENCE

Optional

DEFINITION

This field contains the date written on the cheque when it was prepared by the issuer.



USAGE RULES

In the case of travellers cheques, this is the date of encashment.

EXAMPLE

:30:990102

Option E 2n (Number)

6!n (Date)



15. Field 39C: Place of Issue/Encashment

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the place where the cheque was issued.

USAGE RULES

In the case of travellers cheques, this is the place of encashment.

EXAMPLE

:39C:MANCHESTERGREAT BRITAIN

16. Field 52a: Safekeeper

FORMAT

PRESENCE

Conditional (C3)

DEFINITION

This field identifies the party at which the truncated cheque, ie, the original, is securely stored.

CODES



with option A:

Option C 4*35x (Place)

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option C /34x (Account)

Option D [/1!a][/34x]4*35x






MT 206

CODES

with option C or D:


































USAGE RULES



Option D should only be used when the safekeeper has no BIC.

EXAMPLE

:52A:GEBABEBB


FORMAT


PRESENCE

Optional

DEFINITION


CODES





MANU Manual operation (automated truncation not possible)

OTHR This code is followed by a bilaterally agreed code or other bilaterally agreed structured information


MT 206

USAGE RULES









EXAMPLE

:72:/STAL/

18. Field 32A: Value Date, Currency Code and Sum of Settlement Amounts

FORMAT

PRESENCE

Conditional (C4)

DEFINITION

This field contains the value date which is to be applied to the funds that must be debited from the Receiver's account, or credited to the Sender's account, or the account of another party as specified in the bilateral agreement (see also the checklist on value dates). This is followed by,

REMI This code is followed by bilaterally agreed remittance information

STAL We think this cheque is stale dated but we still ask for payment

TRAN Transaction Type code (any sub-codes to be agreed upon bilaterally)




first the (common) currency for all the truncated cheques, and then the sum of all settlement amounts.





USAGE RULES

If messages are chained, ie, field 28E does not contain ONLY, this field must contain the sum of all occurrences of field 19 in the chained messages.

EXAMPLE

or

19. Field 57a: Account With Institution (for Settlement)

FORMAT

PRESENCE

Optional

message 1: message 2: message 3:

:28E:1/MORE :28E:2/MORE :28E:3/LAST

… … …

:19:10000, :19:5000, :32A:990106USD18000,:19:3000,

message 1:

:28E:1/ONLY

…

:32A:990106USD12500

Option A [/1!a][/34x]4!a2!a2!c[3!c]



Option D [/1!a][/34x]4*35x



MT 206

DEFINITION

This field identifies the account with institution at which the Sender wants to have the funds credited.

CODES



with option A:

CODES






























USAGE RULES

This field may only be used where the settlement is not following the same route as the cheque truncation message.




EXAMPLE

:57A:MIDLGB2L

20. Field 58B: Beneficiary Institution's Account (for Settlement)

FORMAT











Option B [/1!a][/34x][35x]



MT 206

PRESENCE

Optional

DEFINITION

This field specifies the account number of the financial institution which is the ultimate recipient of the funds being transferred.

USAGE RULES

The Party Identifier is to be used to specify the account to be credited, where:

• there are multiple direct account relationships in the currency of the transaction between the Sender and account with institution

• one of these accounts is to be used for reimbursement

• there is no bilaterally agreed account.

EXAMPLE

:58B:/123-45678

21. Field 19: Settlement Amount

FORMAT

PRESENCE

Conditional (C5)

DEFINITION

If messages are chained, ie, field 28E does not contain the code ONLY, this field contains the settlement amount for this message.


The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32A, if present (Error code(s): C03, T40, T43).

EXAMPLE

:28E:9/MORE…:32J:5300:32J:5000…:19:10300,

17d (Amount)



MT 206 MappingMapping of an MT 206 into a subsequent MT 206 (Receiver of first MT 206 becomes Sender of the second MT 206)

Mapping of an MT 206 into a subsequent MT 202. (The Receiver of the MT 206 has a direct account relationship with the account with institution of the Sender in field 57a.)

Mapping of an MT 206 into a subsequent MT 202. (The Receiver of the MT 206 has no direct account relationship with the account with institution of the Sender in field 57a.)

S

20

28E

...

32A

57a

58a

19

R

S

20

28E

...

32A

57a

58a

19

R

MT 206 MT 206

D00

2001

6

S

20

32A

57a

58a

R

S

20

21

32A

58a

R

MT 206 MT 202

D00

2001

7


MT 206

* If there is no direct account relationship between the party specified in field 57a of the MT 206 and the Receiver of the MT 206, then the Receiver of the related MT 202 becomes the common correspondent between the party specified in field 57a of the MT 206 and the Receiver of the MT 206. The party specified in field 57a of the MT 206 becomes field 57a of the related MT 202.

MT 206 Examples

Example 1 Travellers Cheques sent via an MT 206 with an Account With Institution

Narrative

On December 1st 1998, Standard Bank of South Africa, Johannesburg (SBZAZAJJ), encashes and truncates the following Thomas Cook travellers cheques:

TRN Cheque Number Amount

Cheque 1 981201ABCD123456 GB11111111 GBP20,

Cheque 2 9812010EFGH111123 HB22222222 GBP50,

Cheque 3 9812010IJKL235693 EB33333333 GBP10,

Cheque 4 981201ZZZZ123456AA GB66666666 GBP20,

Cheque 5 981201XXXX258950 HB88888888 GBP50,

Cheque 6 981201YYYY569333 EB99999999 GBP10,

S

20

32A

57a

58a

R*

S

20

21

32A

57a*

58a

R*

MT 206 MT 202

D00

2001

8



Standard Bank of South Africa wants the funds to be remitted on its account (555-888-9) with Natwest, London (NWBKGB2L) with value date 981207.

Since Thomas Cook, London, has a multiple direct account relationship with Midland Bank, London (MIDLGB22), it will reimburse SBZAZAJJ using their account 123456 held with Midland Bank.

As per its bilateral agreement, SBZAZAJJ safekeeps the original paper cheques.

For the purpose of this example, two MT 206 are sent, each containing three items.

Message A SWIFT MT 206 Cheque Truncation Message

Information Flow

D00

2001

0

Standard Bankof South AfricaJohannesburg

Tony Baloney

Thomas CookLondon

Sender/Beneficiary's F.I.

Receiver/Issuer

NatwestLondon

Midland BankLondon

Account WithInstitution

Beneficiary

Paper Cheque(start of process)

(MT 910/950)

PresentsTravellers Cheques

MT 206 (MT 205*)

(MT 202)


MT

57


MT 206

SWIFT Message, MT 206 (1) and (2)

Explanation Format

Sender SBZAZAJJ

Message type 206 (1)

Receiver COOKGB22

Message text

Sender's reference :20:981201123456AA

Message index/total :28E:1/MORE

Cheque type :23E:TRAV

Safekeeper :52A:SBZAZAJJ

Transaction reference number :44A:981201ABCD123456

Cheque number :21D:GB11111111

Cheque amount :32J:20,

Date of issue/encashment :30:981201

Transaction reference number :44A:9812010EFGH111123

Cheque number :21D:HB22222222


Date of encashment :30:981201

Transaction reference number :44A:9812010IJKL235693

Cheque number :21D:EB33333333



Settlement amount :19:80,




Explanation Format

Sender SBZAZAJJ

Message type 206 (2)

Receiver COOKGB22

Message text

Sender's reference :20:981201123456AA

Message index/total :28E:2/LAST

Cheque type :23E:TRAV

Safekeeper :52A:SBZAZAJJ

Transaction reference number :44A:981201ZZZZ123456AA

Cheque number :21D:GB66666666



Transaction reference number :44A:981201XXXX258950

Cheque number :21D:HB88888888



Transaction reference number :44A:981201YYYY569333

Cheque number :21D:EB99999999



Value date, currency code and sum of settlement amounts

:32A:981207GBP160,

Account with institution :57A:NWBKGB2L

Beneficiary institution's account :58B:/555-888-9

Settlement amount :19:80,



MT 206

Message B SWIFT MT 202 General Financial Institution Transfer

Information Flow


Explanation Format

Sender COOKGB22

Message type 202

Receiver MIDLGB22

Message text

Transaction reference number :20:IPD/00001/PAIDS

D00

2001

1


Tony Baloney

Thomas CookLondon


Sender

NatwestLondon

Midland BankLondon

(MT 910/950)

PresentsTravellers Cheques

MT 206

(MT 205*)

MT 202* Or its equivalent domestic clearing message


Receiver

MT

57

58



Example 2 General Cheques sent via an MT 206

Narrative

On 8 January 2002, the following cheques are truncated by the Fortis Bank, Brussels (GEBABEBB):

Cheque 1: Kreissparkasse in Siegburg (WELADED1), EUR 1000, cheque number 0007206657588 account 3869999 issued on 011212 in Oostende in favour of CMB, reference 3855026.

Cheque 2: Stadtsparkasse in Dusseldorf (DUSSDEDD), EUR 500, cheque number 000721111 account 45678912 issued on 011214 in Namur in favour of Sofitel Wepion, reference 3855027.

Handling of the cheques is centralised in Fortis Bank, Brussels which truncates these cheques and sends them that same day to its German correspondent, Westdeutsche Landesbank Girozentrale, Dusseldorf (WELADEDD).

There exists a bilateral agreement between Fortis Bank, Brussels and Westdeutsche Landesbank Girozentrale, Dusseldorf. As per this agreement, for cheques in euro, the Westdeutsche’s euro account held with Fortis Bank, Brussels will be debited with value date D+4.

Related reference :21:981201123456AA

Value date, currency code and amount :32A:981207GBP160,

Sender's correspondent :53B:/123456

Account with institution :57A:NWBKGB2L

Beneficiary institution :58A:/555-888-9SBZAZAJJ


TRN Cheque Number Amount Issuer's A/C

Cheque 1 3855026 0007206657588 EUR1000, 3869999

Cheque 2 3855027 0000721111 EUR500, 45678912

Explanation Format


MT 206

Information Flow


Explanation Format

Sender GEBABEBB

Message type 206

Receiver WELADEDD

Message text

Sender's reference :20:291342/0071115

Message index/total :28E:1/ONLY

Cheque type :23E:GENC

D00

2001

2

Fortis BankBrussels

Westdeutsche LandesbankGirozentrale, Dusseldorf

KreissparkasseSiegburg

StadtsparkasseDusseldorf

Sender

Receiver

(MT 206*)

MT 206

(MT 206)

* Equivalent of a MT 206 is sent to non-S.W.I.F.T. User

MT

DraweeBanks



MT 206 ChecklistIt is strongly recommended that the following checklist be used by financial institutions as a basis for setting up bilateral or multilateral agreements for processing truncated cheques.

It is recommended that all items listed be covered in the bilateral or multilateral agreements. In order to further facilitate the setting up of these agreements, common procedures have been defined which financial institutions may choose to override.

The checklist is not intended to provide an exhaustive list of items nor does SWIFT claim any responsibility for it. Topics may include:

Currency & amount

• Specify minimum and maximum amounts per type of cheque

• Specify currencies accepted per type of cheque

Cheque truncation indicator :17A:Y

Safekeeper :52A:GEBABEBB

Transaction reference number :44A:3855026

Cheque number :21D:0007206657588


Issuer's financial institution :58A:WELADED1

Issuer's Account Number/Code :25:3869999

Transaction reference number :44A:3855027

Cheque number :21D:000721111


Issuer's financial institution :58A:DUSSDEDD

Issuer's account number/code :25:45678912

Value date, currency code and total settlement amount

:32A:020114EUR1500,


Explanation Format


MT 206

• Set out the procedure to follow when there is a discrepancy between the code line and another field, eg, the amount

• Unless otherwise agreed, cheque truncation messages are expressed in either the currency of the sending or the receiving country. If financial institutions wish to accept third currencies this should be bilaterally agreed.

Rules & regulations covering cheque truncation

• Enumerate (inter)national laws and regulations

• Specify regulatory reporting requirements

• Specify the period within which a cheque can be protested, per type of cheque/place of issue (see also ‘Dates and Time frames’)

• Specify data or fields in the MTs 206 and 256 that are mandatory for legal purposes and processing requirements

• Define stale date

• List the criteria for cheque truncation

• An existing cash letter agreement could be extended to cater for cheque truncation as well. This may simplify the new agreement.

Responsibility

• Endorsement issue – Agree on procedures to follow, eg, normally the beneficiary's financial institution must endorse that the party that cashes the cheque is the legitimate beneficial party

• Back of cheque – Since it is very difficult to automatically truncate this information, the truncation agreement should make it the truncating party's responsibility to ensure that the truncated cheques contain all legally required endorsements.

• Define the responsible parties at each stage of the whole process, eg, whether or not the beneficiary's financial institution can determine stale dated cheques. Also the agreement should establish the party responsible for verifying certain parts, eg, Code Line, of the truncated cheque.

• The capture and verification of the Code Line are key elements to the success of check truncation. Therefore, establish ways of avoiding bad code lines such as:

- using a specific control key to help manual keying when the code line is unreadable

- avoiding double truncation of a cheque through automatic checking at the point of capture.



Paper cheque

• Specify which party must safekeep the original

• Agree the period the original must be kept

• Agree whether or not the cheque (or a copy) must be sent to the drawee bank and if so when

• Agree the route the paper cheque must follow, if any (where it differs from the truncation route).

Supported types of truncated cheques

• Agree bilateral codes to indicate the type of electronic cheque/model/format.

Charges

• Define the types of charges, per type of cheque, the currency and the amount

• Define the charging period, eg, once a month

• Unless otherwise agreed, charges will always be expressed in the same currency as the transaction amount(s) and settlement amount of the message.

Settlement

• Where there is a direct account relationship between the Sender and Receiver of the MT 206, ie, field 57a is not present, the MT 206 can be used as a financial message to request to credit the account of the Sender automatically. If field 57a is present, an MT 202 must be sent to the party specified in that field.

• Whatever the agreement, transactions contained in a message will always be booked as a single entry.

Administration

• Define the contact address, eg, postal address, department, telephone number, fax number, to be used in the event of questions.

Dates and Time frames

• Agree on the time frame required by the Receiver of the MT 206 to execute the payment of valid truncated cheques. This time frame starts at an agreed cut-off time for receipt of incoming messages by the Receiver.


MT 206

Messages received before the cut-off time, will receive final settlement on a pre-agreed day which is a (number of) day(s) following the day of receipt (day of receipt = D).

For messages received after cut-off time, the final settlement time frame will be based on D+1.

D is the basis for calculating the value date, ie, date when the funds are available to the Beneficiary.

• Agree the time frames for sending back charges.

• Determine the period in which items may be returned/dishonoured, and how such items should be conveyed, eg, CD-ROM, diskette, Internet, mail.

Remittance Information

• Agree whether any, and if so which, information should be conveyed in field 72 through the use of bilaterally agreed codes.



MT 207 Request For Financial Institution Transfer


MT 207 ScopeThis message is used to move funds from the ordering financial institution's account, serviced at the receiving financial institution or at the account servicing institution, or from an account(s) owned by the ordering institution for which the initiating institution has explicit authority to debit, eg, a subsidiary account.

It can be used to order the movement of funds:

• between the ordering institution's accounts, or

• in favour of a third party, either domestically or internationally.

The message is sent by a financial institution on behalf of the ordering financial institution, ie, the account owning financial institution, or on behalf of the initiating financial institution. It is subsequently received by a financial institution and processed by this receiving financial institution or another account servicing financial institution.

The complete chain of parties and the transaction flow is illustrated by the following figure:


MT 207

The parties mentioned in the chain are not necessarily different entities. The first column of the table below shows the parties that can be omitted in an MT 207. The second column specifies the party which assumes the role of the party in the first column, when it is not present:

If the following party is missing… Its function is assumed by …

Initiating institution Ordering institution

58a

51A 52G

52a

56a

D00

2002

0

Funds

Funds

Funds

Request

Funds

Funds


Account ServicingInstitution

Sender

Receiver

BeneficiaryInstitution

Initiating Institution

Intermediary

MT 207

57aAccount With Institution

MT



MT 207 Format SpecificationsThe MT 207 consists of two sequences:

• Sequence A General Information is a single occurrence mandatory sequence and contains information to be applied to all individual transactions detailed in sequence B.

• Sequence B Transaction Details is a repetitive sequence; each occurrence provides details of one individual transaction.

MT 207 Request for Financial Institution Transfer

Account servicing institution Receiver

Intermediary Account with institution

Account with institution Receiver


Mandatory Sequence A General Information


O 21R Specified Reference of the Ordering Institution 16x 2

M 28D Message Index/Total 5n/5n 3

M 30 Requested Execution Date 6!n 4

O 51A Initiating Institution [/1!a][/34x]4!a2!a2!c[3!c]

5

M 52G Ordering Institution /34x4!a2!a2!c[3!c]

6

O 52a Account Servicing Institution A or C 7


-----> Mandatory Repetitive Sequence B Transaction Details

M 21 Transaction Reference 16x 9

---->

O 23E Instruction Code 4!c[/30x] 10

If the following party is missing… Its function is assumed by …


MT 207

MT 207 Network Validated RulesC1 In each occurrence of Sequence B: If field 56a is present then field 57a must also be

present (Error code(s): D65).

MT 207 Usage Rules• If field 21R is present in sequence A, and field 28D indicates that more than one message is

chained for this request for transfer instruction, the currency code must be the same for all occurrences of field 32B in sequence B of all chained messages.

• In case field 23E identifies with a code a sweeping (CMSW), topping (CMTO) or zero balancing (CMZB) operation, the transaction amount in field 32B can equal zero.

• In case field 28D indicates that messages are chained, all messages belonging to the same chain must have exactly the same sender's reference in field 20.

• In case field 28D indicates that messages are chained, sequence A must be repeated and be identical for all messages belonging to the same chain.

----|

M 32B Currency/Transaction Amount 3!a15d 11


O 57a Account With Institution A, C or D 13


-----|


If field 56a is … then field 57a is …

Present Mandatory







FORMAT

PRESENCE

Mandatory

DEFINITION




USAGE RULES

The reference must be unique for each message (or chain of messages) and is part of the message identification and transaction identification which is to be used in related queries, cancellations, etc.

2. Field 21R: Specified Reference of the Ordering Institution

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the reference to the entire message assigned by either the:

• initiating institution, when present or

• ordering institution, when the initiating institution is not present.



16x

Option R 16x


MT 207

USAGE RULES

When this field is present, the ordering institution requests a single debit entry for the sum of the amounts of all transactions in the instruction, even if this instruction is chained in several messages. If the field is not used, all debit items are posted individually.

3. Field 28D: Message Index / Total

FORMAT

PRESENCE

Mandatory

DEFINITION

This field chains different messages by specifying the sequence number in the total number of messages.

USAGE RULES

Both the message index and the total number of messages allow the receiver to check that all transactions to be executed have been received.

4. Field 30: Requested Execution Date

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the date on which all subsequent transactions should be initiated by the executing bank.



USAGE RULES

This is the date on which the ordering institution's account is to be debited.

Option D 5n/5n (Message Index)/(Total)

6!n (Date)



5. Field 51A: Initiating Institution

FORMAT

PRESENCE

Optional

DEFINITION

This field identifies the institution which is authorised by the ordering institution/account servicing institution to order all the transactions in the message.




USAGE RULES

This field must only be used when the initiating institution is not also the ordering institution.

Optional Party Identifier must not be used.

6. Field 52G: Ordering Institution

FORMAT

PRESENCE

Mandatory

DEFINITION

This field identifies the account owning financial institution whose account is to be debited with all transactions in sequence(s) B.



Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option G /34x4!a2!a2!c[3!c]

(Account)(BIC)


MT 207


USAGE RULES

Account contains the account number of the ordering institution at the Receiver or at the account servicing institution.

BIC contains the identification of the ordering institution.

7. Field 52a: Account Servicing Institution

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the account servicing institution - when other than the Receiver - which services the account of the ordering institution to be debited.

CODES



with option A:

Option A [/1!a][/34x]4!a2!a2!c[3!c]








FW Without 9 digit code Pay by Fedwire







CODES

with option C:




USAGE RULES

The coded information contained in field 52a should be meaningful to the Receiver of the message.























MT 207


If the account servicing institution cannot be identified by a BIC, option C should be used containing a 2!a clearing system code preceded by a double slash ‘//’.


FORMAT


PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver, ie, Sender of the original message regarding the reason for a return, ie, reversal, rejection or revocal.

CODES

The codes REJT or RETN must be used in this field in the first position of the first line, placed between slashes (‘/’). It is mandatory to follow the Generic Payment Reject Mechanism described in Standards Usage Guidelines.


The first element in line 1 must contain either code /RETN/ or /REJT/ (Error code(s): D82).

USAGE RULES

The Reject/Return mechanism is used to reject or return all the transactions within the MT 207 message. For returns or rejections of a single transaction within the MT 207 (ie, sequence B), the MT 295 should be used as per the Standards Usage Guidelines.

9. Field 21: Transaction Reference

FORMAT

PRESENCE

Mandatory

6*35x (Narrative - Structured Format )



16x



DEFINITION

This field specifies the unambiguous reference for the individual transaction contained in a particular occurrence of sequence B.



USAGE RULES

In transaction specific queries, cancellations, etc., the Sender's reference together with the content of this field provides the transaction identification.

10. Field 23E: Instruction Code

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies instructions for the subsequent parties in the transaction chain.

CODES

One of the following codes must be used (Error code(s): T47).

Option E 4!c[/30x] (Instruction Code) (Additional Information)

CMSW This transaction contains a cash management instruction, requesting to sweep the account of the ordering institution.

CMTO This transaction contains a cash management instruction, requesting to top the account of the ordering institution above a certain floor amount. The floor amount, if not pre-agreed by the parties involved, may be specified after the code.

CMZB This transaction contains a cash management instruction, requesting to zero balance the account of the ordering institution.

CORT This transaction contains a payment that is made in settlement of a trade, eg, foreign exchange deal, securities transaction.

NETS This transaction contains a payment that should be settled via a net settlement system, if available.

OTHR Used for bilaterally agreed codes/information. The actual bilateral code/information needs to be specified in Additional Information.


MT 207


Additional Information is only allowed when Instruction Code consists of one of the following codes: CMTO, PHON or OTHR (Error code(s): D66).

In each occurrence of Sequence B: when this field is used more than once, the following combinations are not allowed (Error code(s): D67).

In each occurrence of Sequence B: when this field is repeated, the same code word must not be present more than once with the exception of OTHR. The code word OTHR may be repeated (Error code(s): E46).

USAGE RULES

To facilitate the receiving bank's processing when multiple codes are used, the codes must appear in the following order:

• instructions for the receiver of the message (CMSW, CMTO, CMZB, CORT, URGP)

• codes impacting the routing or composition of the resulting payment message (NETS, RTGS)

• codes containing instructions for one of the following parties in the transaction chain (PHON)

• information codes ( OTHR)

PHON This transaction requires the beneficiary to be contacted by telephone and should be followed by the appropriate telephone number.This code is meant for the institution closest to the beneficiary institution

RTGS This transaction contains a payment that should be settled via a real time gross settlement system, if available.

URGP This transaction contains a time sensitive payment which should be executed in an expeditious manner.

CMSW with CMTO

CMSW with CMZB

CMTO with CMZB

CORT with CMSW

CORT with CMTO

CORT with CMZB

NETS with RTGS



11. Field 32B: Currency/Transaction Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the currency and amount of the subsequent transfer to be executed by the Receiver.


Currency must be the same for all occurrences of this field (Error code(s): C02).




FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the financial institution between the Receiver and the account with institution, through which the transaction must pass.

CODES



with option A:


Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 207

CODES

with option D:


































USAGE RULES

The intermediary may be a branch or affiliate of the Receiver or the account with institution, or an entirely different financial institution.

When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //IN is used, it should appear only once and in the first of the fields 56a, 57a and 58a 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 of field 56a, 57a or 58a.


Option D must only be used when there is a need to be able to specify a name and address, eg, due to regulatory considerations.


FORMAT

PRESENCE

Conditional (C1)




Option A [/1!a][/34x]4!a2!a2!c[3!c]



Option D [/1!a][/34x]4*35x



MT 207

DEFINITION

This field specifies the financial institution - when other than the Receiver - which services the account for the beneficiary institution.

CODES



with option A:

CODES

with options C and D:





























USAGE RULES






FORMAT

PRESENCE

Mandatory









Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 207

DEFINITION

This field specifies the beneficiary financial institution of the subsequent operation from the particular occurrence of sequence B.

CODES



with option A:

CODES

with option D:





























USAGE RULES



Party Identifier may contain the beneficiary financial institution's account number.

If the message is used to request the transfer of funds between the ordering financial institution's accounts, this field must contain the BIC of this institution.



MT 207 Examples

Narrative

The Canadian Imperial Bank of Commerce, Canada (CIBCCATT) owns a euro account (account number 123456) at Deutsche Bank, Frankfurt (DEUTDEFF).










MT 207

The Canadian Imperial Bank of Commerce is a customer of Deutsche Bank, Toronto (DEUTCATT) and instructs this bank via a proprietary link to ask Deutsche Bank, Frankfurt to make a euro payment to Banco Bilbao Vizcaya Argentaria, Madrid, via an RTGS system, using CIBCCATT's EUR account at DEUTDEFF.

Information Flow

SWIFT Message

Explanation Format

Sender DEUTCATT

Message type 207

Receiver DEUTDEFF

Message text - General Information

Sender’s Reference :20:ABCDEF

Message Index/Total :28D:1/1

Requested Execution Date :30:020110

D00

2002

2

CIBCCATT

MT 207

TARGETsystem

Instruction

BBVAESMMDEUTDEFF

DEUTCATT



Ordering Institution :52G:/123456CIBCCATT

Message text - Transaction Details 1

Transaction Reference :21:REFBOF123

Instruction Code :23E:RTGS

Currency/Transaction Amount :32B:EUR500000,

Beneficiary Institution :58A:BBVAESMM


Explanation Format


MT 210

MT 210 Notice to Receive

MT 210 ScopeThis message type is sent by an account owner to one of its account servicing institutions.

It is an advance notice to the account servicing institution that it will receive funds to be credited to the Sender's account.


MT 210 Notice to Receive

MT 210 Network Validated RulesC1 The repetitive sequence must not appear more than ten times (Error code(s): T10).

C2 Either field 50a or field 52a, but not both, must be present in a repetitive sequence (Error code(s): C06).



O 25 Account Identification 35x 2


----->



O 50a Ordering Customer C or no option letter 6



-----|




C3 The currency code must be the same for all occurrences of field 32B in the message (Error code(s): C02).



FORMAT

PRESENCE

Mandatory

DEFINITION




EXAMPLE

:20:oref1000

2. Field 25: Account Identification

FORMAT

PRESENCE

Optional

DEFINITION

This field identifies the account to be credited with the incoming funds.

If field 50a is… then field 52a is …

Present Not allowed

Not present Mandatory

16x

35x (Account)


MT 210

USAGE RULES

This field is used when the Receiver services more than one account for the Sender.


FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the value date of all incoming funds specified in this message.




FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the content of field 20 Transaction Reference Number, or other reference, eg, Common Reference, of the related transaction.



EXAMPLE

:21:ref1234


FORMAT

PRESENCE

Mandatory

6!n (Date)

16x




DEFINITION

This field specifies the currency and amount to be received.




6. Field 50a: Ordering Customer

FORMAT

PRESENCE

Conditional (C2)

DEFINITION

This field specifies the ordering party when it is not a financial institution.


The BIC must be a BEI. Please refer to the latest version of the BIC Directory - Corporations for more information on BEIs. (Error code(s): T27, T28, T29, T45, E57).


FORMAT

PRESENCE

Conditional (C2)

DEFINITION

This field specifies the ordering party when it is a financial institution.

CODES


Option C 4!a2!a2!c[3!c] (BEI)

No option letter 4*35x (Name & Address)

Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 210


with option A:

CODES

with option D:


































USAGE RULES

When the Sender is also the ordering institution, it will be repeated in this field.





FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the financial institution from which the Receiver is to receive the funds.

CODES



with option A:




Option A [/1!a][/34x]4!a2!a2!c[3!c]


Option D [/1!a][/34x]4*35x



MT 210

CODES

with option D:




































USAGE RULES

This field is used when the intermediary institution is other than the ordering party.



MT 210 Examples

Narrative

Value 22 February 1998, Berliner Bank, Berlin, as a result of a foreign exchange deal (Common Reference – BEBEBB0023CRESZZ) with Credit Suisse, Zurich, is expecting US Dollars 230,000 to be credited to its account at Chase Manhattan Bank, New York.

The funds will be paid through Citibank, New York.

Berliner Bank sends an MT 210, using reference 318393.





MT 210

Information Flow


Explanation Format

Sender BEBEDEBB

Message type 210

Receiver CHASUS33

Message text

Transaction reference number :20:318393

Value Date :30:980222

Related reference (1) :21:BEBEBB0023CRESZZ

D00

2001

3

Berliner BankBerlin

Crédit SuisseZurich

Chase ManhattanBank, New York

Sender

Receiver

CitibankNew York

Intermediary


56a

52a

(MT 202)

MT 210

(MT 205*)


MT

(MT 300)

(MT 300)



Currency code and amount :32B:USD230000,

Ordering institution :52A:CRESCHZZ

Intermediary (2) :56A:CITIUS33


Note:(1) Field 21 of the incoming funds transfer. In this case, the reference contained in field 21 is a common reference from the related foreign exchange transaction.It will also appear in field 21 of the related funds transfer instruction(2) The financial institution from which the funds will be received.

Explanation Format


MT 256

MT 256 Advice of Non-Payment of Cheques


MT 256 ScopeThis message is sent by the Receiver of one or more MT 206s. It is used to inform the Sender of (a) previously sent MT 206(s) of the non-payment of specified truncated cheques.

This message may only be used to specify dishonoured items that result in reversing a previous payment settlement.

MT 256 Format SpecificationsThe MT 256 consists of three types of sequences:

• Sequence A Common Elements is a non-repetitive sequence and contains information applicable to all individual cheques detailed in sequence B.

• Sequence B Cheque Details is a repetitive sequence where each occurrence provides details of an individual cheque.

• Sequence C Settlement Details is a non-repetitive sequence and contains settlement information applicable to all cheques detailed in sequence B.

MT 256 Advice of Non-Payment of Cheques


Mandatory Sequence A Common Elements


O 21 Related Message Reference 16x 2

----->Mandatory Repetitive Sequence B Cheque Details

M 44A Transaction Reference Number 65x 3

O 21 Related Message Reference 16x 4

O 21D Cheque Number 35x 5

O 21E Cheque Reference Number 35x 6

M 23E Reason for Non-Payment/Dishonour 4!c[/30x] 7



MT 256 Network Validated RulesC1 If field 37J is present, then field 71G must also be present (Error code(s): E25).

C2 The amount specified in field 71L in sequence C must be equal to the sum of all occurrences of field 71F in sequence B (Error code(s): E26).

M 32J Cheque Amount 15d 8

O 37J Interest Rate 12d 9

O 71G Interest Charges 3!a15d 10

O 71F Sender's Charges 3!a15d 11

O 71H Issuer's Financial Institution Charges 3!a15d 12

-----|Mandatory Sequence C Settlement Details

M 32A Value Date, Currency Code and Total Amount Claimed

6!n3!a15d 13

O 30 Original Value Date 6!n 14

O 19 Total Cheque Amount 17d 15

O 71J Sum of Interest Charges 3!a15d 16

O 71L Sum of Sender's Charges 3!a15d 17

O 71K Sum of Issuer's Financial Institution Charges 3!a15d 18

O 57a Account With Institution (for Settlement) A, C or D 19

O 58B Beneficiary Institution's Account (for Settlement) [/1!a][/34x][35x]

20


If field 37J in sequence B is… then field 71G in sequence B is…

Present Mandatory




MT 256

C3 The amount specified in field 71J in sequence C must be equal to the sum of all occurrences of field 71G in sequence B (Error code(s): E27).

C4 The currency code in the amount fields (71F, 71G, 71H, 71J, 71K, 71L, 32A) must be the same for all occurrences of these fields in the message (Error code(s): C02).

C5 If no changes are included, field 32A in sequence C contains the sum of the amounts of all fields 32J in sequence B. Field 19 must not be present (Error code(s): D80).

C6 If charges are included, field 19 must be present. It must contain the sum of amounts of all fields 32J in sequence B (Error code(s): C01).

C7 Field 21 must be present either in sequence A, or in all occurrences of sequence B (Error code(s): E28).

C8 If field 71F is present in any occurrence of sequence B, then field 71L must be present in sequence C. Otherwise, field 71L is not allowed (Error code(s): E29).

C9 If field 71G is present in any occurrence of sequence B, then field 71J must be present in sequence C. Otherwise, field 71J is not allowed (Error code(s): E30).

C10 If field 71H is present in any occurrence of sequence B, then field 71K must be present in sequence C. Otherwise, field 71K is not allowed (Error code(s): E31).

If field 21 in sequence A is… then field 21 in sequence B is…

Present Not allowed

Not present Mandatory in all occurrences

If field 21 in sequence B is… then field 21 in sequence A is…

Present Not allowed

Not present Mandatory

If field 71F in sequence B is… then field 71L in sequence C is…

Present in any occurrence Mandatory

Not present in any occurrence Not allowed

If field 71G in sequence B is… then field 71J in sequence C is…





C11 The amount specified in field 71K in sequence C must be equal to the sum of all occurrences of field 71H in sequence B (Error code(s): E32).

MT 256 Usage Rules• The MT 256 can only be sent or received by financial institutions which have registered with

SWIFT to send or receive the MT 206/MT 256. If a registered user receives an MT 256 without bilateral agreement with the Sender, the Receiver should query the message according to normal banking practice.

• This message must not be used to specify reasons that at a later stage could lead to a non-payment, eg, a request for a photocopy to check the signature. For this, an MT 295 Queries must be used, for which special codes are provided.

• For dishonoured cheques in different currencies, different MT 256s must be used.

• When the Sender does not have authority to debit the Receiver's account, the Receiver of the MT 256 must credit the account according to the specified value date.

• Field 30 may only be used if the original value date differs from the value date provided in this field. Absence of field 30 implies that the value date in field 32A is taken from the original MT 206.



FORMAT

PRESENCE

Mandatory

DEFINITION


If field 71H in sequence B is… then field 71K in sequence C is…



16x


MT 256



EXAMPLE

:20:oref1000

2. Field 21: Related Message Reference

FORMAT

PRESENCE

Conditional (C7)

DEFINITION

This field contains the Sender's reference of the previously received MT 206 Cheque Truncation Message, ie, field 20 of the original MT 206.



EXAMPLE

:21:ref1234

3. Field 44A: Transaction Reference Number

FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the TRN, field 20 of the previously received MT 206, generated by the beneficiary's financial institution, which identifies the transaction that this dishonoured cheque represents.

EXAMPLE

:44A:abc12354

16x

Option A 65x



4. Field 21: Related Message Reference

FORMAT

PRESENCE

Conditional (C7)

DEFINITION

This field contains the Sender's reference of the previously received MT 206 Cheque Truncation Message in case this MT 256 is informing of the non-payment of cheques in the same currency that were included in different MTs 256.



EXAMPLE

:21:ref1234

5. Field 21D: Cheque Number

FORMAT

PRESENCE

Optional

DEFINITION

This field contains the number of the cheque that has been dishonoured, normally inserted on the cheque by the issuer's financial institution.

USAGE RULES

This field must be the same as the cheque number specified in the original MT 206.

EXAMPLE

:21D:9987434

6. Field 21E: Cheque Reference Number

FORMAT

16x

Option D 35x

Option E 35x


MT 256

PRESENCE

Optional

DEFINITION

This field contains the reference of the cheque, as generated by the beneficiary's financial institution.

USAGE RULES

This reference is usually the archive reference (microfilm) and is as such used as a link to the physical item.

This field must be quoted if it is present in the original MT 206.

EXAMPLE

:21E:888014612

7. Field 23E: Reason for Non-Payment/Dishonour

FORMAT

PRESENCE

Mandatory

DEFINITION

This field indicates why a cheque was dishonoured.

CODES

Code must contain one of the following codes (Error code(s): T47):

Option E 4!c[/30x] (Code) (Narrative)

AMAM Amount exceeds the amount limit allowed for this account.

AMTL Amount exceeds the truncation limit as defined in the bilateral agreement (min. or max. amount).

CLOS Closed account.

COLN Error in code line.

DRAW Refer to drawer.

DUPL Duplicate cheque information.

FRAU Fraudulent cheque.

FROZ (Legally) Frozen account.

FRWD Forward dated cheque.

INCH Cheque number invalid.




Narrative may only be used in combination with the code OTHR (Error code(s): D81).

USAGE RULES

The code OTHR may only be used when bilaterally agreed. When used, Narrative must also be present.

EXAMPLE

:23E:INSI

8. Field 32J: Cheque Amount

FORMAT

PRESENCE

Mandatory

DEFINITION

This field contains the amount specified on the dishonoured cheque.


The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the currency specified in field 32A (Error code(s): C03, T40, T43).

USAGE RULES

This field must be the same as the cheque amount specified in the original MT 206.

INSF Insufficient funds.

INSI Insufficient information.

INVA Account number invalid.

NELI Cheques not eligible for truncation.

NMAT Currency and account do not match.

OTHR Other followed by a bilaterally agreed code to specify a reason which is not covered by the above.

REVO Revocation.

STLD Stale cheque, ie, deposited too late relative to the issue date.

STOP Stop payment of a cheque.

Option J 15d (Amount)


MT 256

EXAMPLE

:32J:100000,

9. Field 37J: Interest Rate

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the interest rate to be collected from the Sender of the MT 206.


The integer part of Rate must contain at least one digit. A decimal comma is mandatory and is included in the maximum length (Error code(s): T40, T43).

10. Field 71G: Interest Charges

FORMAT

PRESENCE

Conditional (C1)

DEFINITION

This field specifies the currency and the interest charges due to the Sender of the MT 256.




USAGE RULES

These interest charges are computed at a prevailing interest rate (field 37J) from the original value date (field 30) up to the date when recovery of funds is expected to take place (field 32A).

EXAMPLE

:71G:USD3,

Option J 12d (Rate)

Option G 3!a15d (Currency) (Amount)



11. Field 71F: Sender's Charges

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the currency and the charges due to the Sender of the MT 256, if different from the issuer's financial institution, for the above specified reason.




EXAMPLE

:71F:USD3,

12. Field 71H: Issuer's Financial Institution Charges

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the currency and the charges due to the issuer's financial institution, for the above specified reason.




EXAMPLE

:71H:USD8,

Option F 3!a15d (Currency) (Amount)

Option H 3!a15d (Currency) (Amount)


MT 256

13. Field 32A: Value Date, Currency Code and Total Amount Claimed

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the date when the recovery of funds is expected to take place, followed by the currency and the total amount to be claimed.





EXAMPLE

:32A:961201USD1350,

14. Field 30: Original Value Date

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the value date that appeared on the related MT 206.



USAGE RULES

As this message is sent after provisional credit has been given to the beneficiary, any consequential interests can also be taken into account, by specifying that date. In this case, ie, when back-valuing is applied, no separate fields must be used to indicate the interest charges.

EXAMPLE

:30:980108


6!n (Date)



15. Field 19: Total Cheque Amount

FORMAT

PRESENCE

Conditional (C5, C6)

DEFINITION

This field specifies the sum of all occurrences of field 32J in sequence B.


The integer part of the Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of decimal digits in field 19 must not exceed the maximum for its corresponding currency in field 32A in sequence C (Error code(s): C03, T40, T43).

EXAMPLE

:19:1350,

16. Field 71J: Sum of Interest Charges

FORMAT

PRESENCE

Conditional (C9)

DEFINITION

This field specifies the currency and the sum of all occurrences of field 71G in sequence B.




EXAMPLE

:71J:USD50,

17d (Amount)

Option J 3!a15d (Currency) (Amount)


MT 256

17. Field 71L: Sum of Sender's Charges

FORMAT

PRESENCE

Conditional (C8)

DEFINITION

This field specifies the currency and the sum of all occurrences of field 71F in sequence B.




EXAMPLE

:71L:USD234,

18. Field 71K: Sum of Issuer's Financial Institution Charges

FORMAT

PRESENCE

Conditional (C10)

DEFINITION

This field specifies the currency and the sum of all occurrences of field 71H in sequence B.




EXAMPLE

:71K:USD343,

Option L 3!a15d (Currency) (Amount)

Option K 3!a15d (Currency) (Amount)



19. Field 57a: Account With Institution (for Settlement)

FORMAT

PRESENCE

Optional

DEFINITION

This field identifies the account with institution at which the Sender wants to have the funds (re)credited.

CODES



with option A:

CODES


Option A [/1!a][/34x]4!a2!a2!c[3!c]



Option D [/1!a][/34x]4*35x

















MT 256




USAGE RULES

This field may only be used where the settlement does not follow the same route as the MT 256 (this message).



Option D must only be used in exceptional circumstances, ie, 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.

EXAMPLE

:57A:MIDLGB2L

20. Field 58B: Beneficiary Institution's Account (for Settlement)

FORMAT

PRESENCE

Optional

DEFINITION

This field specifies the account number of the financial institution which is the ultimate recipient of the funds being (re)transferred (i.e. the Receiver of the MT 206).

USAGE RULES

Party Identifier is to be used to specify the account to be credited, where

• there are multiple direct account relationships in the currency of the transaction between the Sender and account with institution

• one of these accounts is to be used for reimbursement

• there is no bilaterally agreed account.

EXAMPLE

:58B:/123-45678

MT 256 MappingMapping of an MT 206 into a subsequent MT 256 (Receiver of the MT 206 becomes Sender of the MT 256).

Option B [/1!a][/34x][35x]



MT 256

MT 256 Examples

Narrative

On December 10, 1998, Thomas Cook, London informs Standard Bank of South Africa, Johannesburg that the following travellers cheques are dishonoured in the MT 206 it received from Standard Bank of South Africa (message reference 981201123456AA).

20

28E

23E

17A

52a

44A

21D

21E

29a

32J

58a

25

26E

30

39C

52a

72

32A

57a

58a

19

20

21*

44A

21

21D

21E

23E

32J

37J

71G

71F

71H

32A

30

19

71J

71L

71K

57a

58a

MT 206 MT 256

D00

2001

9

* If the MT 256 is a reply to several different MT 206s, ie, with differing fields 20, thenfield 20 of this MT becomes field 21 in Sequence B of the MT 256.



Since Thomas Cook, London has already reimbursed Standard Bank of South Africa, it wants to have the funds recredited to its account held at Midland Bank, London (account number 123456), back-valuing the amount with the value date used on the original MT 206 (original value date 981207).

Information Flow


TRN Cheque Number Amount Reason for dishonour

Cheque 1 9812010IJKL235693 EB33333333 GBP10, Stopped cheque

Cheque 2 981201ZZZZ123456AA GB66666666 GBP20, Invalid cheque number

Explanation Format

Sender COOKGB22

Message Type 256

Receiver SBZAZAJJ

D00

2001

4

Thomas CookLondon


Sender

Receiver

Midland BankLondon

NatwestLondon

(MT 910/950)

MT 256MT 206

(MT 205*)

(MT 202)

MT




MT 256

MT 256 ChecklistFor a checklist of topics that should be included in bilateral or multilateral agreements for processing truncated cheques, see MT 206 Checklist.

Message Text

Sender's Reference :20:IPD/S0001/PAIDS

Related Message Reference :21:981201123456AA

Transaction Reference Number :44A:981201IJKL235693

Cheque Number :21D:EB33333333

Reason for Non-Payment/Dishonour :23E:STOP

Cheque Amount :32J:10,

Transaction Reference Number :44A:981201ZZZZ123456AA

Cheque Number :21D:GB66666666

Reason for Non-Payment/Dishonour :23E:INCH

Cheque Amount :32J:20,

Value Date, Currency Code and Total Amount Claimed

:32A:981207GBP30,

Account With Institution :57A:MIDLGB22

Beneficiary Institution's Account :58B:/123456


Explanation Format




MT 290 Advice of Charges, Interest and Other Adjustments

Please refer to Category n – Common Group Messages, Chapter n90 Advice of Charges, Interest and Other Adjustments for details concerning this message type.

MT 291


MT 291 Request for Payment of Charges, Interest and Other Expenses

Please refer to Category n – Common Group Messages, Chapter n91 Request for Payment of Charges, Interest and other Expenses for details concerning this message type.



MT 292 Request for Cancellation

Please refer to Category n – Common Group Messages, Chapter n92 Request for Cancellation for details concerning this message type.

MT 295


MT 295 Queries

Please refer to Category n – Common Group Messages, Chapter n95 Queries for details concerning this message type.



MT 296 Answers

Please refer to Category n – Common Group Messages, Chapter n96 Answers for details concerning this message type.

MT 298


MT 298 Proprietary Message

Please refer to Category n – Common Group Messages, Chapter n98 Proprietary Message for details concerning this message type.



MT 299 Free Format Message

Please refer to Category n – Common Group Messages, Chapter n99 Free Format Message for details concerning this message type.

Glossary of Terms

Glossary of Terms

In addition to the definitions which appear in Standards General Information, Glossary of Terms, the following terms apply to category 2 message types:

Available FundsFunds available for transfer or withdrawal in cash.

BankleitzahlAn eight digit numeric code used to identify banks in Germany. It may only be assigned, changed or cancelled by Deutsche Bundesbank, in Germany.

CHIPS (Clearing House Interbank Payments System)A private telecommunications payment service operated by the New York Clearing House Association for banks in the New York area, which handles US dollar payments only.

CHIPS ParticipantA bank authorised to send and receive payments on the CHIPS system.

CHIPS Participant ID (ABA Number)A unique number identifying a CHIPS participant. The first four digits are the participant's number, followed by a one digit group identifier. For S.W.I.F.T. purposes, only the first four digits of the CHIPS Participant ID will be used.

CHIPS Settling ParticipantA CHIPS Participant responsible for the settlement of its own CHIPS net debit or credit position at the end of the CHIPS business day.

CHIPS Universal IdentifierA unique six digit number assigned by CHIPS to identify an account.

Cover PaymentThe reimbursement of a correspondent bank for a payment.

Federal FundsUS dollars on deposit at a Federal Reserve Bank in the United States.

FedwireA payment service operated by the US Federal Reserve System as a private wire network for transfers between financial institutions having accounts at the Federal Reserve Bank.

Fedwire Routing NumberA nine digit numeric code used to identify banks in the United States.

Funds TransferComplete movement of funds between the originator and the beneficiary. A funds transfer may consist of one or more funds transfer transactions.



Funds Transfer TransactionThe movement of funds directly between two parties, involving no intermediaries other than a payment or communications service.

Immediate FundsSame day funds in which the settlement is simultaneous with execution of the transaction.

Instructing PartyThe party instructing the Sender to execute a transaction.

OriginatorInitiator of the transfer instructions. Equivalent to the ordering institution (field 52a) in the MT 202.

Originator's InstitutionIdentifies the financial institution which is acting for the originator of the transfer.

RemitterThe party which is the source of funds in a payment order.

Same Day FundsThe funds available for transfer today, or for withdrawal in cash, subject to the settlement of the transaction through the payment mechanism used.

SettlementA transfer of funds to complete one or more prior transactions made, subject to final accounting.


swift standards category 2 financial institution transfers

Documents

covers positions

normal banking

westdeutsche

rec tele teleibk

prior written

sc sw sw

coordinated

require manual