category 2 - financial institution transfers - swift · pdf filestandards category 2 -...

Standards

Category 2 - Financial Institution Transfers

For Standards MT November 2016

Message Reference GuideThis reference guide contains the category 2 message text standards, including a detailed description of the scope, theformat specifications, the rules, the guidelines, and the field specifications of each message type.

22 July 2016

Table of ContentsIntroduction................................................................................................................................................. 4

Overview................................................................................................................................................. 4Changes ................................................................................................................................................. 4Volume Formatting Explanation .............................................................................................................4

Category 2 Message Types........................................................................................................................7Euro - Impact on Category Message Standards ......................................................................................10MT 200 Financial Institution Transfer for its Own Account ....................................................................... 11

MT 200 Scope ...................................................................................................................................... 11MT 200 Format Specifications.............................................................................................................. 11MT 200 Network Validated Rules ......................................................................................................... 11MT 200 Usage Rules............................................................................................................................ 11MT 200 Field Specifications .................................................................................................................12MT 200 Examples ................................................................................................................................19

MT 201 Multiple Financial Institution Transfer for its Own Account..........................................................22MT 201 Scope ......................................................................................................................................22MT 201 Format Specifications..............................................................................................................22MT 201 Network Validated Rules .........................................................................................................23MT 201 Usage Rules............................................................................................................................23MT 201 Field Specifications .................................................................................................................23MT 201 Examples ................................................................................................................................32

MT 202 General Financial Institution Transfer .........................................................................................35MT 202 Scope ......................................................................................................................................35MT 202 Format Specifications..............................................................................................................35MT 202 Network Validated Rules .........................................................................................................35MT 202 Usage Rules............................................................................................................................36MT 202 Field Specifications .................................................................................................................36MT 202 Examples ................................................................................................................................51

MT 202 COV General Financial Institution Transfer.................................................................................53MT 202 COV Scope .............................................................................................................................53MT 202 COV Format Specifications .....................................................................................................53MT 202 COV Network Validated Rules ................................................................................................54MT 202 COV Usage Rules ...................................................................................................................54MT 202 COV Market Practice Rules ....................................................................................................55MT 202 COV Field Specifications ........................................................................................................55MT 202 COV Examples........................................................................................................................82

MT 203 Multiple General Financial Institution Transfer ............................................................................85MT 203 Scope ......................................................................................................................................85MT 203 Format Specifications..............................................................................................................85MT 203 Network Validated Rules .........................................................................................................86MT 203 Usage Rules............................................................................................................................86MT 203 Field Specifications .................................................................................................................86MT 203 Examples ..............................................................................................................................102

MT 204 Financial Markets Direct Debit Message...................................................................................105MT 204 Scope ....................................................................................................................................105MT 204 Format Specifications............................................................................................................105MT 204 Network Validated Rules .......................................................................................................106MT 204 Usage Rules..........................................................................................................................106MT 204 Field Specifications ...............................................................................................................106MT 204 Examples .............................................................................................................................. 117

MT 205 Financial Institution Transfer Execution ....................................................................................121MT 205 Scope ....................................................................................................................................121MT 205 Format Specifications............................................................................................................121MT 205 Network Validated Rules .......................................................................................................121MT 205 Field Specifications ...............................................................................................................122MT 205 Examples ..............................................................................................................................135

MT 205 COV Financial Institution Transfer Execution............................................................................138

Category 2 - Financial Institution Transfers for Standards MT November 2016

2 Message Reference Guide

MT 205 COV Scope ...........................................................................................................................138MT 205 COV Format Specifications ...................................................................................................138MT 205 COV Network Validated Rules ..............................................................................................139MT 205 COV Usage Rules .................................................................................................................139MT 205 COV Market Practice Rules ..................................................................................................139MT 205 COV Field Specifications ......................................................................................................140MT 205 COV Examples......................................................................................................................165

MT 207 Request For Financial Institution Transfer ................................................................................170MT 207 Scope ....................................................................................................................................170MT 207 Format Specifications............................................................................................................171MT 207 Network Validated Rules .......................................................................................................172MT 207 Usage Rules..........................................................................................................................172MT 207 Field Specifications ...............................................................................................................172MT 207 Examples ..............................................................................................................................186

MT 210 Notice to Receive ......................................................................................................................188MT 210 Scope ....................................................................................................................................188MT 210 Format Specifications............................................................................................................188MT 210 Network Validated Rules .......................................................................................................188MT 210 Usage Rules..........................................................................................................................189MT 210 Field Specifications ...............................................................................................................189MT 210 Examples ..............................................................................................................................198

MT 256 Advice of Non-Payment of Cheques .........................................................................................200MT 256 Scope ....................................................................................................................................200MT 256 Format Specifications............................................................................................................200MT 256 Network Validated Rules .......................................................................................................201MT 256 Usage Rules..........................................................................................................................202MT 256 Field Specifications ...............................................................................................................203MT 256 Examples ..............................................................................................................................214MT 256 Checklist................................................................................................................................216

MT 290 Advice of Charges, Interest and Other Adjustments .................................................................219MT 291 Request for Payment of Charges, Interest and Other Expenses ..............................................220MT 292 Request for Cancellation ...........................................................................................................221MT 295 Queries......................................................................................................................................222MT 296 Answers ....................................................................................................................................223MT 298 Proprietary Message .................................................................................................................224MT 299 Free Format Message...............................................................................................................225Glossary of Terms...................................................................................................................................226Legal Notices.......................................................................................................................................... 227

Table of Contents

22 July 2016 3

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 financialinstitution, 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'saccount.

• 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 thetransaction are financial institutions.

ChangesCategory 2 - Financial Institution Transfers has not been impacted by the November 2016 Standards Release.

SWIFT continually applies editorial enhancements to its documentation to improve quality and ensureconsistency. These changes are not highlighted in any publication but are controlled in order to ensure thatthey have no impact on FIN validation.

IMPORTANT: This volume contains information effective as of the November 2016 StandardsRelease. Therefore the 24 July 2015 edition of the Standards MT User Handbookvolumes remains effective until November 2016.

Volume Formatting ExplanationThis volume of the Standards User Handbook set contains general information about the category and adetailed description of each message type which is currently available for use. For each message type, thefollowing information is provided:

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

Message Type Format SpecificationsThe format specifications are the rules for the layout of the message type. This information is provided in tableform with the following information:

MT nnn (Message Type Name)Status Tag Field Name Content/Options No.

M 20 Transaction Reference Number 16x 1

M 21 Related Reference 16x 2



Status Tag Field Name Content/Options No.

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

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

• Content/Options provides permitted field length and characteristics. For information concerning fieldstructure, notation and character restrictions, see the Standards MT 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 sequenceof fields may be repeated.

MT Network Validated RulesNetwork validated rules are validated on the network, that is, rules for which an error code is defined. Rulesspecified in this section affect more than one field in the message, placing a condition on one of the fieldsspecified. They are identified as Cn, or conditional rules.

MT Usage RulesUsage rules are not validated on the network, that is, rules for which no error code is defined, but arenevertheless mandatory for the correct usage of the message. Rules specified in this section affect more thanone field in the message, or more than one SWIFT message.

MT GuidelinesGuidelines 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, ormore than one SWIFT message.

Introduction

22 July 2016 5

MT Field SpecificationsThe rules for the use of each field in the message are specified in this section. Each field is identified by itsindex 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 the message type.

• CODES lists all codes available for use in the field. If there is more than one subfield for which codes aredefined, each separate code list will be identified with a CODES heading. When a list of codes is validatedby the network, the error code will be specified.

• NETWORK VALIDATED RULES specifies rules that are validated on the network, that is, rules for whichan error code is defined. Generally, rules specified in this section affect only the field in which they appear.In some cases, rules which are validated at the message level, that is, rules which affect more than onefield, are repeated in this section. This is the case when the rule does not affect the presence of the field,but information within several fields, for example, a currency which must be the same for more than onefield in the message.

• USAGE RULES specifies rules that are not validated on the network, that is, rules for which no error codeis defined, but are nevertheless mandatory for the correct usage of the field. Rules specified in this sectionaffect only the field in which they appear.

• MARKET PRACTICE RULES specifies rules published by the Payments Market Practice Group (PMPG).It informs the reader of the existence of a global market practice document on the business process inwhich the concerned field is used. The absence of a market practice rule notation does not mean that nomarket practices exist for the concerned field. The presence of a market practice rule is merely an indicatorof a known market practice. Furthermore, readers should be aware that in addition to global marketpractices there may also be country specific requirements that should be considered when using the field.For more details on PMPG market practice documentation, refer to www.pmpg.info.

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

MT MappingMT 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 ExamplesExamples are provided to illustrate the correct use of a message. Examples always include the followinginformation:

• Narrative provides a brief description of a transaction

• Information Flow illustrates the relationships between the parties involved in the message. Anexplanation of the flow diagram can be found in the Standards MT 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 TypesThe 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 is signed (Y/N),the maximum message length on input (2,000 or 10,000 characters), whether the use of the message requiresregistration with SWIFT for use in a message user group (Y/N) and whether value date ordering (VDO) can berequested for the message (Y/N). Value date ordering criteria are described in the Standards MT GeneralInformation.

MT MT Name Purpose Signed (1) Max.Length

MUG VDO

200 FinancialInstitutionTransfer for itsOwn Account

Requests the movement ofthe Sender's funds to itsaccount at another financialinstitution

Y 2,000 N Y

201 Multiple FinancialInstitutionTransfer for itsOwn Account

Multiple of the MT 200 Y 2,000 N Y

202 General FinancialInstitutionTransfer

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

Y 10,000 N Y

202COV

General FinancialInstitutionTransfer

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

Y 10,000 N Y

203 Multiple GeneralFinancialInstitutionTransfer

Multiple of the MT 202 Y 2,000 N Y

204 Financial MarketsDirect DebitMessage

Claims funds from SWIFTmember banks

Y 2,000 (2) Y Y

205 FinancialInstitutionTransferExecution

Further transmits a transferrequest domestically,except if the transfer isrelated to an underlyingcustomer credit transfer thatwas sent with the covermethod, in which case theMT 205 COV must be used.

Y 10,000 N Y

Category 2 Message Types

22 July 2016 7


MUG VDO

205COV

FinancialInstitutionTransferExecution

Further transmits a transferrequest domestically,related to an underlyingcustomer credit transfer thatwas sent with the covermethod.

Y 10,000 N Y

207 Request forFinancialInstitutionTransfer

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

Y 10,000 Y Y

210 Notice to Receive Notifies the Receiver that itwill receive funds for theSender's account

Y 2,000 N Y

256 Advice of Non-Payment ofCheques

Informs the Sender of oneor more previously sentcheque truncationmessages of non-paymentof one or more truncatedcheques. It may also beused to specify dishonoureditems that result inreversing a previouspayment settlement

Y 10,000 Y Y

290 Advice ofCharges, Interestand OtherAdjustments

Advises an account ownerof charges, interest or otheradjustments

Y 2,000 N N

291 Request forPayment ofCharges, Interestand OtherExpenses

Requests payment ofcharges, interest or otherexpenses

Y 2,000 N N

292 Request forCancellation

Requests the Receiver toconsider cancellation of themessage identified in therequest

Y 2,000 N N

295 Queries Requests informationrelating to a previousmessage or amendment toa previous message

Y 2,000 N N

296 Answers Responds to an MT 295Queries message or anMT 292 Request forCancellation or othermessage where no specificmessage type has beenprovided for a response

Y 2,000 N N




MUG VDO

298 ProprietaryMessage

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

Y 10,000 N N

299 Free FormatMessage

Contains information forwhich no other messagetype has been defined

Y 2,000 N N

(1) A Relationship Management Application (RMA) authorisation is required in order to sign a message.

(2) Special registration is needed for the MT 204 - see the FIN Service Description for details.

Note: A Message User Group (MUG), for the purposes of this book, is a group of users who havevoluntarily agreed to support the specified message type and have registered with SWIFT to send orreceive the specified message type. These messages are indicated in the preceding table in thecolumn MUG.Registration is free of charge. To register to use one or more message types, submit a registrationrequest (Order Message User Group) through the forms available on www.swift.com > Ordering& Support > Ordering > Order Products and Services > Message User Group (MUG).To withdraw from a MUG, use the Terminate your MUG subscription request. These forms areavailable at www.swift.com > Ordering & Support > Ordering > Terminate and deactivate >Message User Group (MUG).To get the list of other members of a particular MUG, send an MT 999 to the CustomerImplementation team (SWHQBEBBCOS).

Category 2 Message Types

22 July 2016 9

Euro - Impact on Category Message StandardsSee the Standards MT General Information for full details of the Euro-Related Information (ERI) and theimpact on Standards MT message types.



MT 200 Financial Institution Transfer for its OwnAccount

MT 200 ScopeThis message type is sent by an account owner to one of its account servicing institutions. All parties identifiedin the message must be financial institutions.

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

MT 200 Format SpecificationsMT 200 Financial Institution Transfer for its Own Account



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


M = Mandatory, O = Optional

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.

• In those cases where the financial institution account owner wishes to instruct its account servicinginstitution either to transfer funds between two accounts serviced by the Receiver, or to debit its accountwith the Receiver and to credit one of its several accounts at an account with institution, the MT 202General 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 202General financial institution transfer or the MT 203 Multiple financial institution transfer must be used.

MT 200 Financial Institution Transfer for its Own Account

22 July 2016 11

MT 200 Field Specifications

1. Field 20: Transaction Reference Number

FORMAT

16x

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

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

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

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

The codes XAU, XAG, XPD and XPT are not allowed, as these are codes for commodities for which thecategory 6 commodities messages must be used (Error code(s): C08).

3. Field 53B: Sender's Correspondent

FORMAT

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

(Party Identifier)(Location)



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 debitedmust 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 andthe Receiver, and this is the account to be used for reimbursement, field 53B must not be present.

4. Field 56a: Intermediary

FORMAT

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

(Party Identifier)(Identifier Code)

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

(Party Identifier)(Name and Address)

PRESENCE

Optional

DEFINITION

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

CODES

In option A, Party Identifier may be used to indicate a national clearing system code.

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

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

CN 12..14n China National Advanced Payment System (CNAPS) Code

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


22 July 2016 13

IE 6!n Irish National Clearing Code (NSC)

IN 11!c Indian Financial System Code (IFSC)

IT 10!n Italian Domestic Identification Code

PL 8!n Polish National Clearing Code (KNR)

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

CODES

In option D, Party Identifier may be used to indicate a national clearing system code.






CH 6!n CHIPS Universal Identifier


CP 4!n CHIPS Participant Identifier


FW 9!n Fedwire Routing Number









RU 9!n Russian Central Bank Identification Code


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

SW 6!n Swiss Clearing Code (SIC code)





Identifier Code must be a registered financial institution BIC (Error code(s): T27,T28,T29,T45).

Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in aFIN message including connected BICs, non-connected 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 shouldappear 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, USbanks 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 grosssettlement (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 otherinformation. 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: when the party cannot be identified by a financialinstitution BIC, when there is a need to be able to specify a name and address, for example, due to regulatoryconsiderations or when there is a bilateral agreement between the Sender and the Receiver permitting its use.

When qualified by a clearing system code or an account number, the use of option D will enable theautomated processing of the instruction(s) by the Receiver.

5. Field 57a: Account With Institution

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

Mandatory

DEFINITION

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

CODES




22 July 2016 15


















CODES






























USAGE RULES








6. Field 72: Sender to Receiver Information

FORMAT

6*35x (Narrative Structured Format)

The following line formats must be used:

Line 1 /8c/[additional information] (Code)(Narrative)

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

(Narrative)or(Code)(Narrative)


22 July 2016 17

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 in Code, placed between slashes ('/'):

ACC Account withinstitution

Instructions following are for the account with institution.

INT Intermediaryinstitution

Instructions following are for the intermediary institution.

PHON Telephone Please advise account with institution by phone.

PHONIBK Phone Intermediary Please advise intermediary by phone.

REC Receiver Instructions following are for the Receiver of the message.

TELE Telecommunication Please advise the account with institution by the most efficientmeans of telecommunication.

TELEIBK Telecommunication Please advise the intermediary by the most efficient means oftelecommunication.


If the first six characters in line 1 contain the character string /REJT/ or /RETN/, then it is mandatory to followthe Payments Reject/Return Guidelines described in the Standards MT Usage Guidelines(Error code(s): T80).

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 theparty 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 shouldpreferably be the last information in this field.

It is strongly recommended to use the standard codes. However, where bilateral agreements covering the useof 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, thepresence of this field will normally require manual intervention.

This field may contain ERI to transport dual currencies, as specified in the chapter entitled "Euro-RelatedInformation (ERI)" in the Standards MT General Information.

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



MT 200 Examples

Example 1: Financial Institution Transfer for its Own Account with anAccount With Institution

Narrative

Value 25 May 2009 UBS, Zürich requests ABN Amro Bank, Amsterdam, to transfer euro 1,000,000 to itsaccount at ING Bank, Amsterdam.

The reference for this transaction is 23/200516DEV.

Information Flow

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

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:090525EUR1000000,

Account with institution (1) 57A:INGBNL2A

End of message text/trailer

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


22 July 2016 19

Example 2: Financial Institution Transfer for its Own Account with anIntermediary

Narrative

Value 25 May 2009, Bank Austria, Vienna, requests Chase Manhattan Bank, New York, to transfer US Dollars1,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.

Information Flow

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



SWIFT Message

Explanation Format

Sender BKAUATWW

Message type 200

Receiver CHASUS33

Message text

Transaction reference number :20:39857579

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

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

Intermediary :56A:CITIUS33

Account with institution (2) :57A:CITIUS33MIA


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


22 July 2016 21

MT 201 Multiple Financial Institution Transfer for itsOwn Account

MT 201 ScopeThis multiple message type is sent by an account owner to one of its account servicing institutions. All partiesidentified in the message must be financial institutions.

It is used to request the movement of funds from an account that the Receiver services for the Sender toseveral 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, that is, the valuedate and total amount to be transferred, the Sender's correspondent and any other information about thistransaction, as necessary.

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

MT 201 Multiple Financial Institution Transfer for its Own AccountStatus Tag Field Name Content/Options No.

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


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


-----|




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 themessage (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 oneof its several accounts at an account with institution, the MT 202 General Financial Institution Transfer orthe MT 203 Multiple General Financial Institution Transfer must be used.

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

• The beneficiary of each transfer is always the Sender.


1. Field 19: Sum of Amounts

FORMAT

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 inthe maximum length. The number of digits following the comma must not exceed the maximum numberallowed for the currency specified in field 32B (Error code(s): C03,T40,T43).

2. Field 30: Value Date

FORMAT

6!n (Date)

MT 201 Multiple Financial Institution Transfer for its Own Account

22 July 2016 23

PRESENCE

Mandatory

DEFINITION

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



3. Field 53B: Sender's Correspondent

FORMAT

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


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

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 debitedmust 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 andthe 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













USAGE RULES




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






22 July 2016 25


FORMAT

16x

PRESENCE

Mandatory

DEFINITION

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



USAGE RULES

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

6. Field 32B: Currency Code, Amount

FORMAT

Option B 3!a15d (Currency)(Amount)

PRESENCE

Mandatory

DEFINITION

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








FORMAT

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


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


PRESENCE

Optional

DEFINITION

This field specifies the financial institution through which the transaction must pass to reach the account withinstitution.

CODES




















CODES



22 July 2016 27



























USAGE RULES











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

Mandatory

DEFINITION

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

CODES















22 July 2016 29







CODES






























USAGE RULES









FORMAT






PRESENCE

Optional

DEFINITION

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

CODES







22 July 2016 31








USAGE RULES




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





MT 201 ExamplesNarrative

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

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 through INGBank, Amsterdam

EUR 30000,



Information Flow

56a

D00

2000

3

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

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 201

Receiver ABNANL2A

Message text

Sum of amounts in the message :19:61000,

Value date :30:090528

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

Currency code and amount :32B:EUR5000,

Account with institution :57A:INGBNL2A



Account with institution :57A:BBSPNL2A




22 July 2016 33

Explanation Format

Account with institution :57B:ROTTERDAM



Account with institution :57A:CRLYFRPP



Intermediary :56A:INGBNL2A

Account with institution :57A:DEUTDEFF

Sender to Receiver information :72:/TELE/


(1) There are 5 requests for transfer within the message



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 thefinancial institution of the beneficiary institution. All parties identified in the message must be financialinstitutions.

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 transferfunds between these accounts. In addition it can be sent to a financial institution to debit an account of theSender serviced by the Receiver and to credit an account, owned by the Sender at an institution specified infield 57a.

This message must not be used to order the movement of funds related to an underlying customer credittransfer that was sent with the cover method. For these payments the MT 202 COV or MT 205 COV must beused.

MT 202 Format SpecificationsMT 202 General Financial Institution Transfer




----->

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


22 July 2016 35

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 toanother 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 oneof its several accounts at an institution specified in field 57a, field 58A must contain the number of theaccount 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 bythe Sender and serviced by the Receiver, field 53B must specify the number of the account to be debitedand field 58A the number of the account to be credited and the name of the Sender.



FORMAT

16x

PRESENCE

Mandatory

DEFINITION




2. Field 21: Related Reference

FORMAT

16x

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 NONREFmust be used in this field.





USAGE RULES

This field will contain a reference to the related transaction which is meaningful to the beneficiary institution,for example, the common reference in an MT 300 Foreign Exchange Confirmation, field 21 of an MT 202General Financial Institution Transfer, an MT 205 Financial Institution Transfer Execution or an MT 400 Adviceof Payment.

3. Field 13C: Time Indication

FORMAT

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

PRESENCE

Optional

DEFINITION

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

CODES

One of the following codes may be used in Code, placed between slashes ('/'):

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

RNCTIME Receive Time The time at which a TARGET2 payment was credited at thereceiving central bank, expressed in Central European Time(CET).

SNDTIME Send Time The time at which a TARGET2 payment was debited at thesending central bank, expressed in Central European Time(CET).

CODES

One of the following codes must be used in Sign (Error code(s): T15):

+ Plus The + sign.

- Minus The - sign.


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


22 July 2016 37

Time offset is expressed as 'HHMM', where the hour component, that is, 'HH', must be in the range of 00through 13, and the minute component, that is, '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 whichit 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 tobe indicated in CET (see codes above).

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

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

:13C:/CLSTIME/0915+0200

Offsets of local time zones against UTC are published in the BIC Directory download file (TZ***.txt file), whichis available on www.swiftrefdata.com.


FORMAT


PRESENCE

Mandatory

DEFINITION









5. Field 52a: Ordering Institution

FORMAT

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


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


PRESENCE

Optional

DEFINITION

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

CODES


















CODES





22 July 2016 39























USAGE RULES

When the Sender of an initial MT 202 is also the ordering institution, that is, this field is not used, that Senderwill 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

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 the account or branch of the Sender or another financial institution through which theSender will reimburse the Receiver.




USAGE RULES

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

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, theaccount to be credited or debited must be indicated in field 53a, using option B with the party identifier only.

If there is no direct account relationship, in the currency of the transaction, between the Sender and theReceiver (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 onthe currency of the transaction, the relationship between the Sender and the Receiver and the contents of field54a, if present.

A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both theSender's correspondent and a branch of the Receiver, and the Sender intends to send a cover message to thebranch 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, that is, 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 andReceiver, 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 andthe correspondent relationship between the Sender and the Receiver relative to that currency.


22 July 2016 41

7. Field 54a: Receiver's Correspondent

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 the branch of the Receiver or another financial institution at which the funds will be madeavailable to the Receiver.




USAGE RULES

The absence of fields 53a and/or 54a implies that the single direct account relationship between the Senderand 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 field53a contains an account of the Sender serviced by the Receiver's branch, the Receiver will claimreimbursement from its branch.

If field 54a contains a branch of the Receiver and field 53a contains a branch of the Sender, the Receiver willclaim reimbursement from its branch or will be paid by its branch, depending on the currency of the transferand 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 infield 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 theReceiver, field 54a must not be present.

Field 54a containing the name of a financial institution other than the Receiver's branch must be preceded byfield 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 andthe correspondent relationship between the Sender and the Receiver relative to that currency.




FORMAT

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


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


PRESENCE

Optional

DEFINITION


CODES




















CODES



22 July 2016 43



























USAGE RULES

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










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

Conditional (see rule C1)

DEFINITION

This field identifies the financial institution which will pay or credit the beneficiary institution.

CODES
















22 July 2016 45






CODES






























USAGE RULES

When field 57a is not present, it means that the Receiver is also the account with institution.








10. Field 58a: Beneficiary Institution

FORMAT

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


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


PRESENCE

Mandatory

DEFINITION

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

CODES







22 July 2016 47















CODES






























USAGE RULES

When the Sender instructs the Receiver to either credit one of several accounts owned by the Sender at aninstitution specified in field 57a, or transfer funds between two accounts owned by the Sender and serviced bythe 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 booktransfer is requested, Party Identifier be used to specify the account of the beneficiary.









FORMAT





22 July 2016 49



PRESENCE

Optional

DEFINITION

This field specifies additional information for the Receiver.

CODES




BNF Beneficiary Information following is for the beneficiary.

INS Instructinginstitution

The instructing institution which instructed the Sender orprevious institution in the transaction chain, to execute thetransaction.




PHONBEN TelephoneBeneficiary

Please advise/contact beneficiary/claimant by phone.




TELEBEN Telecommunication Please advise the beneficiary/claimant by the most efficientmeans of telecommunication.


TSU Trade ServicesUtility transaction

The code placed between slashes ('/') must be followed by theTSU transaction identifier, a slash ('/'), the invoice number, aslash ('/') and the amount paid.



USAGE RULES











The code INS may be repeated to specify all previously involved financial institutions in the transaction chain.

Instructing institutions should be indicated in the order in which they were involved in the transaction chain,that is, the first occurrence specifies the financial institution that received the instruction from the orderinginstitution and passed it on to the next institution in the transaction chain; the last occurrence always indicatesthe institution that instructed the sender of this message to execute the transaction.

MT 202 Examples

Example 1: MT 202 with Time IndicationNarrative

On 5 January, a CLS settlement member (BANKGB2L) receives an instruction from CLS Bank to fund JPY5,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 needto be credited to CLS Bank by 07.00 AM CET.


22 July 2016 51

Information Flow

D002

0021

Central Bankof Japan

BANKJPJT

BANKUS33BANKGB2L

CLS Bank

MT300

MT300

MT202 or local clearing

equivalent

Pay in ScheduleMT202

SWIFT Message

In the MT 202 which BANKGB2L sends to its JPY correspondent BANKJPJT, it can indicate the time by whichBANKJPJT 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 instructionsare 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 bycomparing the offset in 13C to its own offset against UTC. Japan is UTC +0900, therefore BANKJPJT knows ithas to process the instruction before 15.00 local time in Japan.

Offsets of local delta time zones against UTC are published in the BIC Directory download file (TZ***.txt file),which is available on www.swiftrefdata.com.



MT 202 COV General Financial Institution TransferThe MT 202 COV is a General Use message, that is, no registration in a Message User Group is necessary tosend and receive this message.

The message contains a mandatory sequence to include information on an underlying customer credit transferand has a maximum message length of 10,000 characters.

IMPORTANT: To trigger the MT 202 COV format validation, the user header of the message (block 3)is mandatory and must contain the code COV in the validation flag field 119({3:{119:COV}}).

MT 202 COV ScopeThis message is sent by or on behalf of the ordering institution directly, or through correspondent(s), to thefinancial institution of the beneficiary institution. All parties to the financial institution transfer (sequence A)must be financial institutions.

It must only be used to order the movement of funds related to an underlying customer credit transfer that wassent with the cover method.

The MT 202 COV must not be used for any other interbank transfer. For these transfers the MT 202 must beused.

MT 202 COV Format SpecificationsThe MT 202 COV consists of two sequences:

• Sequence A General Information is a single occurrence sequence and contains information on thefinancial institution transfer between the ordering institution and beneficiary institution.

• Sequence B Underlying Customer Credit Transfer Details is a single occurrence sequence and is used toprovide details on an individual underlying customer credit transfer that was sent with the cover method.

MT 202 COV General Financial Institution TransferStatus Tag Field Name Content/Options No.

Mandatory Sequence A General Information



----->


-----|





MT 202 COV General Financial Institution Transfer

22 July 2016 53






End of Sequence A General Information

Mandatory Sequence B Underlying Customer Credit Transfer Details

M 50a Ordering Customer A, F, or K 12


O 56a Intermediary Institution A, C, or D 14

O 57a Account With Institution A, B, C, or D 15

M 59a Beneficiary Customer No letter option, A, or F 16

O 70 Remittance Information 4*35x 17


O 33B Currency/Instructed Amount 3!a15d 19

End of Sequence B Underlying Customer Credit Transfer Details


MT 202 COV Network Validated RulesC1 If field 56a is present in sequence A, then field 57a must also be present in sequence A (Error code(s):

C81).

C2 If field 56a is present in sequence B, then field 57a must also be present in sequence B (Error code(s):C68).

MT 202 COV Usage Rules• All parties to the financial institution transfer (Sequence A) must be financial institutions.

• The transfer of funds between the ordering institution and the beneficiary institution is always related to anunderlying customer credit transfer. Field 21 must refer to the underlying transaction.

• The MT 202 COV must not be used to convey customer credit transfer instructions; it is used to order themovement of funds related to an underlying customer credit transfer that was sent with the cover method.

• Where an inward MT 202 COV results in an onward MT 202 COV or MT 205 COV, the reference from field21 of the inward message must be passed on unchanged in field 21 of the onward message.

• The MT 202 COV must not be forwarded to the beneficiary financial institution for reporting purposes.



MT 202 COV Market Practice RulesGuidelines for the use of the message have been published by the Payments Market Practice Group (PMPG).

For more details, see the market practice document Guidelines for use of the MT 202 COV onwww.pmpg.info.

MT 202 COV Field Specifications


FORMAT

16x

PRESENCE

Mandatory in mandatory sequence A

DEFINITION





FORMAT

16x

PRESENCE


DEFINITION

This field contains a reference to the related transaction(s).

CODES

If no related reference is available, the code NONREF must be used in this field.




22 July 2016 55

USAGE RULES

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

If an incoming message is an MT 202 COV and results in an outgoing MT 202 COV, this field will contain field21 Related Reference of the incoming message.


FORMAT


PRESENCE

Optional in mandatory sequence A

DEFINITION


CODES





CODES


+ Plus The + sign.

- Minus The - sign.






USAGE RULES


EXAMPLE



Explanation:




:13C:/CLSTIME/0915+0200



FORMAT


PRESENCE


DEFINITION








22 July 2016 57


FORMAT

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


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


PRESENCE


DEFINITION


CODES


















CODES




























USAGE RULES

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






22 July 2016 59


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


DEFINITION





USAGE RULES





A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both theSender's correspondent and a branch of the Receiver, and the Sender intends to send a cover message to thebranch 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, that is, MT 202 COV or equivalent non-SWIFT,must be sent to the financial institution identified in field 53a.


The absence of fields 53a and 54a implies that the single direct account relationship between the Sender andReceiver, 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 andthe correspondent relationship between the Sender and the Receiver relative to that currency.




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


DEFINITION





USAGE RULES








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


22 July 2016 61


FORMAT

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


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


PRESENCE


DEFINITION


CODES




















CODES






























USAGE RULES





22 July 2016 63






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

Conditional (see rule C1) in mandatory sequence A

DEFINITION


CODES






















CODES




























22 July 2016 65


USAGE RULES










FORMAT

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


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


PRESENCE


DEFINITION


CODES






















CODES





















22 July 2016 67









USAGE RULES

When the Sender instructs the Receiver to either credit one of several accounts owned by the Sender at aninstitution specified in field 57a, or transfer funds between two accounts owned by the Sender and serviced bythe 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 booktransfer is requested, Party Identifier be used to specify the account of the beneficiary.









FORMAT








PRESENCE


DEFINITION


CODES





















USAGE RULES




22 July 2016 69









12. Field 50a: Ordering Customer

FORMAT

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

(Account)(Identifier Code)

Option F 35x4*35x


Option K [/34x]4*35x

(Account)(Name and Address)

In option F, the following line formats must be used (Error code(s): T54):

Line 1 (subfield PartyIdentifier)

/34x (Account)

Lines 2-5 (subfieldName and Address)

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

Or


4!a/2!a/27x (Code)(Country Code)(Identifier)



PRESENCE

Mandatory in mandatory sequence B



DEFINITION

This field specifies the customer ordering the transaction.

CODES

In option F, when Party Identifier is used with the (Code)(Country Code)(Identifier) format, one of the followingcodes must be used in Code (Error code(s): T55):

ARNU Alien RegistrationNumber

The code followed by a slash, '/' must be followed by the ISO countrycode, a slash, '/' and the Alien Registration Number.

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

CUST CustomerIdentificationNumber

The code followed by a slash, '/' must be followed by the ISO countrycode of the issuer of the number, a slash, '/', the issuer of the number,a slash, '/' and the Customer Identification Number.

DRLC Driver's LicenceNumber

The code followed by a slash, '/' must be followed by the ISO countrycode of the issuing authority, a slash, '/', the issuing authority, a slash,'/' and the Driver's Licence Number.

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

NIDN National IdentityNumber

The code followed by a slash, '/' must be followed by the ISO countrycode, a slash, '/' and the National Identity Number.

SOSE Social SecurityNumber

The code followed by a slash, '/' must be followed by the ISO countrycode, a slash, '/' and the Social Security Number.

TXID Tax IdentificationNumber

The code followed by a slash, '/' must be followed by the ISO countrycode, a slash, '/' and the Tax Identification Number.

CODES

In option F, Number must contain one of the following values (Error code(s): T56):

1 Name of theOrdering Customer

The number followed by a slash, '/' must be followed by the name ofthe ordering customer.

2 Address Line The number followed by a slash, '/' must be followed by an addressline (Address Line can be used to provide, for example, street nameand number, or building name).

3 Country and Town The first occurrence of number 3 must be followed by a slash, '/', theISO country code and, optionally, additional details that are precededby a slash '/'.Other occurrences of number 3 must be followed by a slash '/' and thecontinuation of additional details.Additional details can contain town, which can be complemented bypostal code (for example zip) and country subdivision (for examplestate, province, or county). The country code and town should,preferably, indicate the country and town of residence.

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


22 July 2016 71

5 Place of Birth The number followed by a slash, '/' must be followed by the ISOcountry code, a slash '/' and the place of birth.

6 CustomerIdentificationNumber

The number followed by a slash, '/' must be followed by the ISOcountry code of the issuer of the number, a slash, '/', the issuer of thenumber, a slash, '/' and the customer identification number.

7 National IdentityNumber

The number followed by a slash, '/' must be followed by the ISOcountry code, a slash, '/' and the national identity number.

8 AdditionalInformation The number followed by a slash, '/' is followed by information that

completes one of the following:

• the identifier provided in subfield 1 (Party Identifier) used with the(Code)(Country Code)(Identifier) format.

• the customer identification number provided in subfield 2 (Nameand Address) with number 6.

• the national identity number provided in subfield 2 (Name andAddress) with number 7.


Identifier Code must be a registered BIC (Error code(s): T27,T28,T29,T45).

In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country Codemust be a valid ISO country code (Error code(s): T73).

In option F, subfield 2 (Name and Address):

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

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

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

• The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s): T73).

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

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

• Numbers 5, 6 and 7 must be followed by a valid ISO country code (Error code(s): T73), a slash '/' andadditional Details (Error code(s): T56).

• Numbers 4, 5, 6, 7 and 8 must not be repeated (Error code(s): T56).

• The use of number 8 is only allowed in the following instances (Error code(s): T56):

◦ to continue information on the Identifier of the ordering customer provided in subfield 1 (Party Identifier)used with the (Code)(Country Code)(Identifier) format.

◦ to continue information on the Customer Identification Number provided in subfield 2 (Name andAddress) following number 6.

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



USAGE RULES

The field must contain the ordering customer of the underlying customer credit transfer that was sent with thecover method.

MARKET PRACTICE RULES

Guidelines for the use of this field have been published by the Payments Market Practice Group (PMPG).

For more details, see the relevant market practice document on www.pmpg.info.


FORMAT

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


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


PRESENCE

Optional in mandatory sequence B

DEFINITION

This field specifies the financial institution of the ordering customer, when different from the Sender, even iffield 50a contains an IBAN.

CODES

















22 July 2016 73



CODES


























USAGE RULES

If the Ordering Institution field was present in the underlying customer credit transfer message that was sentwith the cover method, then this field must carry that Ordering Institution.



14. Field 56a: Intermediary Institution

FORMAT

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


Option C /34x (Party Identifier)

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


PRESENCE


DEFINITION


CODES















NZ 6!n New Zealand National Clearing Code






22 July 2016 75

CODES

In option C or D, Party Identifier may be used to indicate a national clearing system code.



























USAGE RULES

If the Intermediary Institution field was present in the underlying customer credit transfer message that wassent with the cover method, then this field must carry that Intermediary Institution.




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

Conditional (see rule C2) in mandatory sequence B

DEFINITION

This field specifies the financial institution which services the account for the beneficiary customer. This isapplicable even if field 59a contains an IBAN.

CODES






















22 July 2016 77

CODES





























USAGE RULES

If the Account With Institution field was present in the underlying customer credit transfer message that wassent with the cover method, then this field must carry that Account With Institution.



16. Field 59a: Beneficiary Customer

FORMAT

No letter option [/34x]4*35x




Option F [/34x]4*(1!n/33x)

(Account)(Number)(Name and Address Details)

PRESENCE


DEFINITION

This field specifies the customer which will be paid.

CODES


1 Name of theBeneficiaryCustomer

The number followed by a slash, '/' must be followed by the name ofthe beneficiary customer.

2 Address Line The number followed by a slash, '/' must be followed by an addressline (Address Line can be used to provide for example, street nameand number, building name or post office box number).

3 Country and Town The first occurrence of number 3 must be followed by a slash, '/', theISO country code and, optionally, additional details that are precededby a slash '/'.Other occurrence(s) of number 3 must be followed by a slash '/' andthe continuation of additional details.Additional details can contain town, which can be complemented bypostal code (for example zip) and country subdivision (for example,state, province, or county). The country code and town should,preferably, indicate the country and town of residence, as provided bythe ordering customer.

CODES

Account may contain one of the following codes, preceded by a double slash '//':




In option F, for subfields (Number)(Name and Address Details):


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


22 July 2016 79

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

• The first occurrence of number 3 must be followed by a valid ISO country code(Error code(s): T73).

USAGE RULES

The field must contain the beneficiary customer of the underlying customer credit transfer that was sent withthe cover method.

17. Field 70: Remittance Information

FORMAT

4*35x (Narrative)

PRESENCE


DEFINITION

This field specifies either the details of the individual transaction or a reference to another message containingthe details which are to be transmitted to the beneficiary customer.

CODES

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

INV Invoice Invoice (followed by the date, reference and details of the invoice).

IPI InternationalPaymentInstruction

Unique reference identifying a related International PaymentInstruction (followed by up to 20 characters).

RFB Reference forBeneficiary

Reference for the beneficiary customer (followed by up to 16characters).

ROC Reference ofCustomer

Ordering customer's reference.


The code placed between slashes ('/') must be followed by the TSUtransaction identifier, a slash ('/'), the invoice number, a slash ('/') andthe amount paid.

USAGE RULES

If the Remittance Information field was present in the underlying customer credit transfer message that wassent with the cover method, then this field must carry that Remittance Information.


FORMAT








PRESENCE


DEFINITION

This field specifies additional information for the Receiver or other party specified.

CODES

Unless bilaterally agreed otherwise between the Sender and the Receiver, one of the following codes must beused in Code, placed between slashes ('/'):




The instructing institution which instructed the Sender or previousinstitution in the transaction chain, to execute the transaction.




USAGE RULES

If the Sender to Receiver Information field was present in the underlying customer credit transfer message thatwas sent with the cover method, then this field must carry that Sender to Receiver Information.

19. Field 33B: Currency/Instructed Amount

FORMAT


PRESENCE


DEFINITION

This field specifies the currency and amount of the instruction. This amount is provided for informationpurposes and has to be transported unchanged through the transaction chain.





22 July 2016 81

USAGE RULES

If the Currency/Instructed Amount field was present in the underlying customer credit transfer message thatwas sent with the cover method, then this field must carry that Currency/Instructed Amount.

MT 202 COV Examples

Example 1: MT 202 COV as cover of MT 103Narrative

Value 27 May 2009, Mr. Big orders Bank A, Brussels to pay an invoice with number 1234 of USD 10,500.00 toMr. Small who has an account 987654321 with Bank B, London.

Bank A processes this transaction through cover method by sending:

A. A customer credit transfer message MT 103 to Bank B, using reference 090525/123COV.

B. A message MT 202 COV with reference 090525/124COV for the USD payment to its USD correspondentBank C, New York for credit of Bank B, London on their account 123444555 at Bank D, New York.

Information Flow

D00

2002

3

OrderingCustomer

Sender

Mr. BigBrussels

Message A

MT 910/950

Message B

Receiver'sCorrespondent

MT

MT 103

MT

BeneficiaryCustomer

Sender'sCorrespondent

Receiver

MT 202COV

MT 202COV or

equivalent

Bank ABrussels

Bank CNew York

Bank DNew York

Bank BLondon

Mr. SmallLondon

Message A SWIFT MT 103 Single Customer Credit TransferSWIFT Message, MT 103

Explanation Format

Sender AAAABEBB

Message type 103

Receiver BBBBGB22

Message text



Explanation Format

Sender's reference :20:090525/123COV

Bank operation code :23B:CRED

Value date/currency code/amount :32A:090527USD10500,00

Currency/Instructed Amount :33B:USD10500,00

Ordering customer :50F:/1235649821011/MR. BIG2/HIGH STREET 33/BE/BRUSSELS

Sender's correspondent :53A:CCCCUS33

Receiver's correspondent :54A:DDDDUS33

Beneficiary customer :59F:/9876543211/MR. SMALL2/LOW STREET 153/GB/LONDON

Remittance information :70:/INV/1234

Details of charges :71A:SHA


Message B SWIFT MT 202 COVInformation Flow

D00

2002

4Sender

Receiver

Message B

Message A

MT 910/950

Account withInstitution

MT103

MT 202COV

MT

MT

MT 202COV or

equivalent

Bank ABrussels

Bank CNew York

Bank DNew York

Bank BLondon

BeneficiaryInstitution

SWIFT Message, MT 202 COV

Explanation Format

Sender AAAABEBB


22 July 2016 83

Explanation Format

Message type 202

Receiver CCCCUS33

Validation flag 119:COV

Message Text: General Information

Transaction reference number :20:090525/124COV

Related reference (1) :21:090525/123COV


Account with Institution :57A:DDDDUS33

Beneficiary institution :58A:BBBBGB22

Underlying Customer Credit Transfer Details






(1) The related reference is the Sender's Reference of the MT 103 Customer Credit Transfer.



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.All parties identified in the message must be financial institutions.

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 isthe case when the Receiver services multiple accounts for the Sender and the funds are to be transferredbetween these accounts. In addition, it can be sent to a financial institution to debit an account of the Senderserviced 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, that is, the valuedate and total amount to be transferred, as well as any other information about this transaction, asnecessary.

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

MT 203 Multiple General Financial Institution TransferStatus Tag Field Name Content/Options No.







----->








22 July 2016 85



-----|



code(s): C01).


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 oneof its several accounts at a financial institution specified in field 57a, field 58A in the related sequence mustcontain 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 bythe Sender and serviced by the Receiver, field 53B must specify the number of the account to be debitedand field 58A, in the sequence relating to this order, must specify the number of the account to be creditedand the name of the Sender.

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



FORMAT

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 the Amount must contain at least one digit. A decimal comma is mandatory and is includedin the maximum length. The number of digits following the comma must not exceed the maximum numberallowed for the currency specified in field 32B (Error code(s): C03,T40,T43).


FORMAT

6!n (Date)

PRESENCE

Mandatory

DEFINITION

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




FORMAT

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


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


PRESENCE

Optional

DEFINITION


CODES









22 July 2016 87











CODES




























USAGE RULES

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

This field must be forwarded to each beneficiary institution.





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





USAGE RULES




22 July 2016 89




A branch of the Receiver may appear in field 53a if the financial institution providing reimbursement is both theSender's Correspondent and a branch of the Receiver, and the Sender intends to send a cover message tothe 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, that is, 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 andthe correspondent relationship between the Sender and Receiver relative to that currency.


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





USAGE RULES










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


FORMAT






PRESENCE

Optional

DEFINITION


CODES






The instructing institution which instructed the Sender toexecute the transaction.




22 July 2016 91

PHON Telephone Please advise intermediary by phone.










USAGE RULES










FORMAT

16x

PRESENCE

Mandatory



DEFINITION

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



USAGE RULES

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


FORMAT

16x

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 20Sender's Reference of that MT 103.

In all other cases, this field will contain a reference to the related transaction which is meaningful to thebeneficiary institution, for example, the common reference in an MT 300 Foreign Exchange Confirmation, field21 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 NONREFmust be used in this field.


FORMAT


PRESENCE

Mandatory


22 July 2016 93

DEFINITION

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






FORMAT

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


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


PRESENCE

Optional

DEFINITION


CODES






















CODES




























22 July 2016 95


USAGE RULES









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


DEFINITION

This field specifies the financial institution which will pay or credit the beneficiary institution.

CODES






















CODES





















22 July 2016 97









USAGE RULES










FORMAT

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


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


PRESENCE

Mandatory



DEFINITION


CODES




















CODES











22 July 2016 99



















USAGE RULES

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

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











FORMAT






PRESENCE

Optional

DEFINITION

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

CODES

















22 July 2016 101






USAGE RULES












Value 28 May 2009, UBS, Zürich requests ABN Amro Bank, Amsterdam, to transfer euro 5,000,000 asfollows:

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

D00

2000

6

UBSZurich


MorganGuaranty Trust CoNew York

Mellon BankLondon

CitibankNew York

ING BankAmsterdam

SNS Bank Nederland NVAmsterdam

CitibankAmsterdam

DresdnerBankFrankfurt

Sender

Receiver

Account WithInstitution


MT 203

58a

57a 57a 57a

58a 58a 58a

MT

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 203

Receiver ABNANL2A

Message text

Sum of amounts in the message :19:5000000,


Transaction reference number (1) (1) :20:2345

Related reference :21:789022


Account with institution :57A:INGBNL2A


22 July 2016 103

Explanation Format

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



MT 204 Financial Markets Direct Debit MessageNote: The use of this message type requires different Message User Group (MUG) registration from the

MUG registration for other messages types. See the FIN Service Description for details.

MT 204 ScopeThis message is sent by an exchange or clearing house, or another financial institution to a SWIFT member orsubmember, to instruct the Receiver of the message to debit the account(s) of a third party specified in themessage 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 containsdefault information which is valid for all individual transactions described in sequence B and the totalamount to be reimbursed.

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

MT 204 Financial Markets Direct Debit MessageStatus Tag Field Name Content/Options No.

Mandatory Sequence A Common Elements - Reimbursement Details





O 58a Beneficiary Institution A or D 5


End of Sequence A Common Elements - Reimbursement Details

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


O 21 Related Reference 16x 8

M 32B Transaction Amount 3!a15d 9

M 53a Debit Institution A, B, or D 10


-----| End of Sequence B Transaction Details


MT 204 Financial Markets Direct Debit Message

22 July 2016 105


code(s): C01).


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

MT 204 Usage RulesThis message requires the implementation of special procedures, its use is governed by bilateral agreementsbetween counterparties. In order to be able to send or receive this message, the interested customers need toformally request SWIFT to be activated within the FIN subapplication group which controls the use of thismessage.



FORMAT

16x

PRESENCE


DEFINITION




USAGE RULES

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


FORMAT

17d (Amount)



PRESENCE


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 inthe maximum length. The number of digits following the comma must not exceed the maximum numberallowed for the currency specified in field 32B (Error code(s): C03,T40,T43).


FORMAT

6!n (Date)

PRESENCE


DEFINITION

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




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


DEFINITION

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


22 July 2016 107

CODES




















CODES






























USAGE RULES

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





Option D must only be used in exceptional circumstances, that is, when the party cannot be identified by afinancial institution BIC and when there is a bilateral agreement between the Sender and the Receiverpermitting its use. Unless qualified by a clearing system code or an account number, the use of option D mayprevent the automated processing of the instruction(s) by the Receiver.


FORMAT

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


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



22 July 2016 109

PRESENCE


DEFINITION

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

CODES




















CODES






























USAGE RULES

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





Option D must only be used in exceptional circumstances, that is, when the party cannot be identified by afinancial institution BIC and when there is a bilateral agreement between the Sender and the Receiverpermitting its use. Unless qualified by a clearing system code or an account number, the use of option D mayprevent the automated processing of the instruction(s) by the Receiver.


22 July 2016 111


FORMAT






PRESENCE


DEFINITION


CODES





CUST Customer The amount to be debited corresponds to a margin call onsegregated customer (client) trades/account.

CUSTMAR Customer accountmargin

The amount to be debited corresponds to initial/original marginon customer trades (customer account margin).

CUSTVAR Customer accountvariation

The amount to be debited corresponds to variation margin oncustomer trades (customer account variation).

HOUSE House trade The amount to be debited corresponds to a margin call onhouse trades (proprietary funds).

HOUSEMAR House accountmargin

The amount to be debited corresponds to initial/original marginon house trades (house account margin).

HOUSEVAR House accountvariation

The amount to be debited corresponds to variation margin onhouse trades (house account variation).

METALS Metals Metals call.

MKTMAR Market-markeraccount margin

The amount to be debited corresponds to initial/original marginon market-maker (specialist) trades/account (market-makeraccount margin).

MKTMKR Market-markertrades/account

The amount to be debited corresponds to a margin call onmarket-maker (specialist) trades/account.

MKTVAR Market-markeraccount variation

The amount to be debited corresponds to variation margin onmarket-maker (specialist) trades/account (market-makeraccount variation).



MMPLDG Market-makerpledge

The amount corresponds to a market-maker pledge.

OPTPREM Options premium Options premium.


TENDER Tender The amount to be debited corresponds to a payment in respectof a tender (delivery).

VARIATN Variation General variation.

XMGN Cross marginaccount

Cross-margin account (covers positions hedged, offset orspread over two exchanges).

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

XMGNVAR Cross marginvariation

Cross-margin account margin (for variation margin).



USAGE RULES









FORMAT

16x

PRESENCE


DEFINITION

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


22 July 2016 113



USAGE RULES

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


FORMAT

16x

PRESENCE


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 StatementMessage, sent to the debit institution.

9. Field 32B: Transaction Amount

FORMAT


PRESENCE


DEFINITION

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






10. Field 53a: Debit Institution

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


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, that is, when the debit institution cannot beidentified by a financial institution BIC, and when there is a bilateral agreement between the Sender andReceiver permitting its use. Unless qualified by an account number, the use of option D may prevent theautomated processing of the instruction(s) by the Receiver.


FORMAT







22 July 2016 115

PRESENCE


DEFINITION

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

CODES





CUST Customer The amount to be debited corresponds to a margin call onsegregated customer (client) trades/account.

CUSTMAR Customer accountmargin

The amount to be debited corresponds to initial/original marginon customer trades (customer account margin).

CUSTVAR Customer accountvariation

The amount to be debited corresponds to variation margin oncustomer trades (customer account variation).

HOUSE House trade The amount to be debited corresponds to a margin call onhouse trades (proprietary funds).

HOUSEMAR House accountmargin

The amount to be debited corresponds to initial/original marginon house trades (house account margin).

HOUSEVAR House accountvariation

The amount to be debited corresponds to variation margin onhouse trades (house account variation).

METALS Metals Metals call.

MKTMAR Market-markeraccount margin

The amount to be debited corresponds to initial/original marginon market-maker (specialist) trades/account (market-makeraccount margin).

MKTMKR Market-markertrades/account

The amount to be debited corresponds to a margin call onmarket-maker (specialist) trades/account.

MKTVAR Market-markeraccount variation

The amount to be debited corresponds to variation margin onmarket-maker (specialist) trades/account (market-makeraccount variation).

MMPLDG Market-makerpledge

The amount corresponds to a market-maker pledge.

OPTPREM Options premium Options premium.


TENDER Tender The amount to be debited corresponds to a payment in respectof a tender (delivery).

VARIATN Variation General variation.

XMGN Cross marginaccount

Cross-margin account (covers positions hedged, offset orspread over two exchanges).



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

XMGNVAR Cross marginvariation

Cross-margin account margin (for variation margin).



USAGE RULES








MT 204 Examples

Example 1: The Exchange and the Member have a CommonCorrespondent Bank

Narrative

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


22 July 2016 117

Information Flow

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

SWIFT Message, MT 204

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

Transaction amount :32B:USD50000,

Debit institution :53A:MLNYUS33


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

SWIFT Message, MT 910, Confirmation of Credit

Explanation Format

Sender CNORUS44



Explanation Format

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


SWIFT Message, MT 900, Confirmation of Debit

Explanation Format

Sender CNORUS44

Message type 900

Receiver MLNYUS33

Message text

Transaction reference number :20:MB REF B


Account identification :25:ACCOUNT ID OF MLNY


Ordering institution :52A:XCMEUS4C


Example 2: The Exchange does not want to use the account relationshipwith the common correspondent and wants the funds to be transferredto another institution

Narrative

The Chicago Mercantile Exchange asks its member Merrill Lynch International Bank, New York to put up amargin 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 MerrillLynch and to credit its account serviced by First National Bank of Chicago in Chicago with a value date 21September 2009.


22 July 2016 119

Information Flow

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


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


Transaction amount :32B:USD50000,

Debit institution :53A:MLNYUS33




MT 205 Financial Institution Transfer Execution

MT 205 ScopeThis message is sent by the Receiver of a category 2 message that is, MT 200, 201, 202, 203 or 205, orequivalent (for example ISO 20022 Financial Institution Credit Transfer), directly, or through correspondent(s),to the financial institution of the beneficiary institution. All parties identified in the message must be financialinstitutions.

It is used to further transmit a funds transfer instruction where Sender and Receiver are located in the samecountry.

If the funds transfer instruction is related to an underlying customer credit transfer that was sent with the covermethod, then the MT 205 must not be used.

MT 205 Format SpecificationsMT 205 Financial Institution Transfer Execution




----->


-----|


M 52a Ordering Institution A or D 5







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


22 July 2016 121



FORMAT

16x

PRESENCE

Mandatory

DEFINITION





FORMAT

16x

PRESENCE

Mandatory

DEFINITION




USAGE RULES

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

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


FORMAT




PRESENCE

Optional

DEFINITION


CODES





CODES


+ Plus The + sign.

- Minus The - sign.




USAGE RULES


EXAMPLE



Explanation:




22 July 2016 123

If the same instruction had been sent on 10 June (that is during summer time), time indication field would havebeen completed as follows: :13C:/CLSTIME/0915+0200



FORMAT


PRESENCE

Mandatory

DEFINITION








FORMAT

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


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


PRESENCE

Mandatory

DEFINITION


CODES




















CODES




















22 July 2016 125








USAGE RULES

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






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







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, theaccount to be credited or debited must be indicated in field 53a, using option B with the account number lineonly.

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


When there is a single direct account relationship, in the currency of the transaction, between the Sender andthe 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 thecorrespondent relationship between the Sender and Receiver relative to that currency.


FORMAT

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


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


PRESENCE

Optional

DEFINITION


CODES











22 July 2016 127











CODES






























USAGE RULES









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


DEFINITION

This field specifies the financial institution which is to pay or credit the beneficiary institution.

CODES




22 July 2016 129


















CODES






























USAGE RULES










FORMAT

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


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



22 July 2016 131

PRESENCE

Mandatory

DEFINITION

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

CODES




















CODES






























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




22 July 2016 133



FORMAT






PRESENCE

Optional

DEFINITION


CODES










PHONBEN Telephonebeneficiary













USAGE RULES












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


22 July 2016 135

Explanation Format

Transaction Reference Number :20:203998988

Related Reference :21:394882

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

Account With Institution :57A:DEUTDEHH

Beneficiary Institution :58A:OSCBDEH1

End of Message Text/Trailer

Information Flow

52a

D00

2000

9

Deutsche BankFrankfurt(Receiver of MT 202)

UBSZurich

Deutsche BankHamburg(Field 57a in MT 202)

Sender

Receiver

Otto M. Schroder BankHamburg

Beneficiary Institution

Ordering Institution

MT 205

(MT 202)

58a

MT

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

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



Explanation Format

Ordering institution (2) :52A:UBSWCHZH80A

Beneficiary Institution :58A:OSCBDEH1


(1) Related reference of the transaction which resulted in this message, that is, 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 202will become the ordering institution.


22 July 2016 137

MT 205 COV Financial Institution Transfer ExecutionThe MT 205 COV is a General Use message, that is, no registration in a Message User Group is necessary tosend and receive this message.

The message contains a mandatory sequence to include information on an underlying customer credit transferand has a maximum message length of 10,000 characters.

IMPORTANT: To trigger the MT 205 COV format validation, the user header of the message (block 3)is mandatory and must contain the code COV in the validation flag field 119({3:{119:COV}}).

MT 205 COV ScopeThis message is sent by the Receiver of an MT 202 COV, MT 205 COV or equivalent (for example ISO 20022Financial Institution Credit Transfer), directly, or through correspondent(s), to the financial institution of thebeneficiary institution. All parties to the financial institution transfer (sequence A) must be financial institutions.

It is only used to further transmit a funds transfer instruction related to an underlying customer credit transferthat was sent with the cover method, where Sender and Receiver are located in the same country.

The MT 205 COV must not be used for any other interbank transfer.

MT 205 COV Format SpecificationsThe MT 205 COV consists of two sequences:

• Sequence A General Information is a single occurrence sequence and contains information on thefinancial institution transfer between the ordering institution and beneficiary institution.

• Sequence B Underlying Customer Credit Transfer Details is a single occurrence sequence and is used toprovide details on an individual underlying customer credit transfer that was sent with the cover method.

MT 205 COV Financial Institution Transfer ExecutionStatus Tag Field Name Content/Options No.




----->


-----|


M 52a Ordering Institution A or D 5










Mandatory Sequence B Underlying Customer Credit Transfer Details

M 50a Ordering Customer A, F, or K 11


O 56a Intermediary Institution A, C, or D 13

O 57a Account With Institution A, B, C, or D 14

M 59a Beneficiary Customer No letter option, A, or F 15

O 70 Remittance Information 4*35x 16


O 33B Currency/Instructed Amount 3!a15d 18

End of Sequence B Underlying Customer Credit Transfer Details


MT 205 COV Network Validated RulesC1 If field 56a is present in sequence A, then field 57a must also be present in sequence A (Error code(s):

C81).

C2 If field 56a is present in sequence B, then field 57a must also be present in sequence B (Error code(s):C68).

MT 205 COV Usage Rules• All parties to the financial institution transfer (Sequence A) must be financial institutions.

• The transfer of funds between the ordering institution and the beneficiary institution is always related to anunderlying customer credit transfer. Field 21 must refer to the underlying transaction.

• The MT 205 COV must not be used to convey customer credit transfer instructions; it is used to order themovement of funds related to an underlying customer credit transfer that was sent with the cover method.

• Where an inward MT 202 COV or MT 205 COV results in an onward MT 205 COV, the reference from field21 of the inward message must be passed on unchanged in field 21 of the onward message.

• The MT 205 COV must not be forwarded to the beneficiary financial institution for reporting purposes.

MT 205 COV Market Practice RulesGuidelines for the use of the message have been published by the Payments Market Practice Group (PMPG).

For more details, see the relevant market practice document on www.pmpg.info.

MT 205 COV Financial Institution Transfer Execution

22 July 2016 139

MT 205 COV Field Specifications


FORMAT

16x

PRESENCE


DEFINITION





FORMAT

16x

PRESENCE


DEFINITION


CODES

If no related reference is available, 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 field 20 Sender'sReference of that MT 103.

If an incoming message is an MT 202 COV or an MT 205 COV and results in an outgoing MT 205 COV, thisfield will contain field 21 Related Reference of the incoming message.




FORMAT


PRESENCE


DEFINITION


CODES





CODES


+ Plus The + sign.

- Minus The - sign.




USAGE RULES


EXAMPLE



22 July 2016 141


Explanation:




:13C:/CLSTIME/0915+0200



FORMAT


PRESENCE


DEFINITION








FORMAT

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


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


PRESENCE




DEFINITION


CODES


















CODES














22 July 2016 143














USAGE RULES

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






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




DEFINITION





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, theaccount to be credited or debited must be indicated in field 53a, using option B with the account number lineonly.

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


When there is a single direct account relationship, in the currency of the transaction, between the Sender andthe 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 thecorrespondent relationship between the Sender and Receiver relative to that currency.


FORMAT

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


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


PRESENCE


DEFINITION


CODES




22 July 2016 145


















CODES






























USAGE RULES









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



22 July 2016 147

PRESENCE


DEFINITION


CODES




















CODES






























USAGE RULES









22 July 2016 149



FORMAT

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


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


PRESENCE


DEFINITION


CODES






















CODES




























USAGE RULES




22 July 2016 151







FORMAT






PRESENCE


DEFINITION


CODES























USAGE RULES












FORMAT




22 July 2016 153

Option F 35x4*35x


Option K [/34x]4*35x




/34x (Account)



Or





PRESENCE


DEFINITION

This field specifies the customer ordering the transaction.

CODES


















CODES

























22 July 2016 155










USAGE RULES

The field must contain the ordering customer of the underlying customer credit transfer that was sent with thecover method.


FORMAT

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


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


PRESENCE


DEFINITION

This field specifies the financial institution of the ordering customer, when different from the Sender, even iffield 50a contains an IBAN.

CODES




















CODES
























22 July 2016 157




USAGE RULES

If an Ordering Institution field was present in the underlying customer credit transfer that was sent with thecover method, then this field must carry that Ordering Institution.

13. Field 56a: Intermediary Institution

FORMAT

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



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


PRESENCE


DEFINITION


CODES






















CODES




























22 July 2016 159


USAGE RULES

If an Intermediary Institution field was present in the underlying customer credit transfer that was sent with thecover method, then this field must carry that Intermediary Institution.


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


DEFINITION

This field specifies the financial institution which services the account for the beneficiary customer. This isapplicable even if field 59a contains an IBAN.

CODES























CODES



























22 July 2016 161




USAGE RULES

If an Account With Institution field was present in the underlying customer credit transfer that was sent with thecover method, then this field must carry that Account With Institution.

15. Field 59a: Beneficiary Customer

FORMAT

No letter option [/34x]4*35x




Option F [/34x]4*(1!n/33x)

(Account)(Number)(Name and Address Details)

PRESENCE


DEFINITION

This field specifies the customer which will be paid.

CODES


1 Name of theBeneficiaryCustomer

The number followed by a slash, '/' must be followed by the name ofthe beneficiary customer.

2 Address Line The number followed by a slash, '/' must be followed by an addressline (Address Line can be used to provide for example, street nameand number, building name or post office box number).

3 Country and Town The first occurrence of number 3 must be followed by a slash, '/', theISO country code and, optionally, additional details that are precededby a slash '/'.Other occurrence(s) of number 3 must be followed by a slash '/' andthe continuation of additional details.Additional details can contain town, which can be complemented bypostal code (for example zip) and country subdivision (for example,state, province, or county). The country code and town should,preferably, indicate the country and town of residence, as provided bythe ordering customer.



CODES

Account may contain one of the following codes, preceded by a double slash '//':




In option F, for subfields (Number)(Name and Address Details):


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

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

• The first occurrence of number 3 must be followed by a valid ISO country code(Error code(s): T73).

USAGE RULES

The field must contain the beneficiary customer of the underlying customer credit transfer that was sent withthe cover method.

16. Field 70: Remittance Information

FORMAT

4*35x (Narrative)

PRESENCE


DEFINITION

This field specifies either the details of the individual transaction or a reference to another message containingthe details which are to be transmitted to the beneficiary customer.

CODES

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

INV Invoice Invoice (followed by the date, reference and details of the invoice).

IPI InternationalPaymentInstruction

Unique reference identifying a related International PaymentInstruction (followed by up to 20 characters).

RFB Reference forBeneficiary

Reference for the beneficiary customer (followed by up to 16characters).

ROC Reference ofCustomer

Ordering customer's reference.


The code placed between slashes ('/') must be followed by the TSUtransaction identifier, a slash ('/'), the invoice number, a slash ('/') andthe amount paid.


22 July 2016 163

USAGE RULES

If a Remittance Information field was present in the underlying customer credit transfer that was sent with thecover method, then this field must carry that Remittance Information.


FORMAT






PRESENCE


DEFINITION

This field specifies additional information for the Receiver or other party specified.

CODES

Unless bilaterally agreed otherwise between the Sender and the Receiver, one of the following codes must beused in Code, placed between slashes ('/'):




The instructing institution which instructed the Sender or previousinstitution in the transaction chain, to execute the transaction.




USAGE RULES

If a Sender to Receiver Information field was present in the underlying customer credit transfer that was sentwith the cover method, then this field must carry that Sender to Receiver Information.

18. Field 33B: Currency/Instructed Amount

FORMAT


PRESENCE




DEFINITION

This field specifies the currency and amount of the instruction. This amount is provided for informationpurposes and has to be transported unchanged through the transaction chain.




USAGE RULES

If a Currency/Instructed Amount field was present in the underlying customer credit transfer that was sent withthe cover method, then this field must carry that Currency/Instructed Amount.

MT 205 COV Examples

Example 1: MT 205 COV as cover of MT 103Narrative

Value 27 May 2009, Mr. Big orders Bank A, Brussels to pay an invoice with number 1234 of USD 10,500.00 toMr. Small who has an account 987654321 with Bank B, London.

Bank A processes this transaction through cover method by sending:

A. A customer credit transfer message MT 103 to Bank B, using reference 090525/123COV.

B. A message MT 202 COV with reference 090525/124COV for the USD payment to its USD correspondentBank C, New York for credit of Bank B, Brussels on their account 123444555 at Bank D, New York.

Information Flow

MT 202COV

MT 205COV

D00

2002

6

Message A

Message B

MT 103

Message CMT

MT

MT

MT 910/950

OrderingCustomer

Sender

Mr. BigBrussels


BeneficiaryCustomer


Receiver

Bank ABrussels

Bank CNew York

Bank DNew YorkBank BLondon

Mr. SmallLondon


22 July 2016 165

Message A SWIFT MT 103 Single Customer Credit TransferSWIFT Message, MT 103

Explanation Format

Sender AAAABEBB

Message type 103

Receiver BBBBGB22

Message text

Sender's reference :20:090525/123COV

Bank operation code :23B:CRED




Sender's correspondent :53A:CCCCUS33

Receiver's correspondent :54A:DDDDUS33



Details of charges :71A:SHA




Message B SWIFT MT 202 COVInformation Flow

MT 202COV

MT 205COV

D00

2002

6

Message A

Message B

MT 103

Message CMT

MT

MT

MT 910/950

OrderingCustomer

Sender

Mr. BigBrussels


BeneficiaryCustomer


Receiver

Bank ABrussels

Bank CNew York


Mr. SmallLondon


Explanation Format

Sender AAAABEBB

Message type 202

Receiver CCCCUS33

Validation flag :119:COV


Transaction reference number :20:090525/124COV



Account with Institution :57A:DDDDUS33






22 July 2016 167

Explanation Format




(1) The related reference is the Sender's Reference of the MT 103 Customer Credit Transfer.

Message C SWIFT MT 205 COVOn receipt of the MT 202 COV from Bank A, Bank C, New York sends an MT 205 COV with reference987COV to Bank D, New York for credit of their client Bank B, Brussels on their account 123444555.

Information Flow

MT 202COV

MT 205COV

D00

2002

6

Message A

Message B

MT 103

Message CMT

MT

MT

MT 910/950

OrderingCustomer

Sender

Mr. BigBrussels


BeneficiaryCustomer


Receiver

Bank ABrussels

Bank CNew York


Mr. SmallLondon


Explanation Format

Sender CCCCUS33

Message type 205

Receiver DDDDUS33

Validation flag :119:COV


Transaction reference number :20:987COV



Ordering Institution :52A:AAAABEBB



Explanation Format








(1) The related reference is the related reference of the MT 202 COV.


22 July 2016 169

MT 207 Request For Financial Institution TransferNote: The use of this message type requires Message User Group (MUG) registration.

MT 207 ScopeThis message is used to move funds from the ordering financial institution's account, serviced at the receivingfinancial institution or at the account servicing institution, or from an account(s) owned by the orderinginstitution for which the initiating institution has explicit authority to debit, for example, 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, that is, the accountowning financial institution, or on behalf of the initiating financial institution. It is subsequently received by afinancial institution and processed by this receiving financial institution or another account servicing financialinstitution. All parties identified in the message must be financial institutions.

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

58a

51A 52G

52a

56a

D00

2002

0

Funds

Funds

Funds

Request

Funds

Funds


Account ServicingInstitution

Sender

Receiver


Initiating Institution

Intermediary

MT 207

57aAccount With Institution

MT



The parties mentioned in the chain are not necessarily different entities. The first column of the table belowshows the parties that can be omitted in an MT 207. The second column specifies the party which assumesthe 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

Account servicing institution Receiver

Intermediary Account with institution

Account with institution Receiver

MT 207 Format SpecificationsThe MT 207 consists of two sequences:

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

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

MT 207 Request For Financial Institution TransferStatus Tag Field Name Content/Options No.


M 20 Sender's Reference 16x 1

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

-----|

M 32B Currency/Transaction Amount 3!a15d 11


MT 207 Request For Financial Institution Transfer

22 July 2016 171


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


-----| End of Sequence B Transaction Details


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

If field 56a is ... Then field 57a is ...

Present Mandatory

Not present Optional

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

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 insequence 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 musthave 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 forall messages belonging to the same chain.


1. Field 20: Sender's Reference

FORMAT

16x

PRESENCE


DEFINITION






USAGE RULES

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

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

FORMAT

Option R 16x

PRESENCE


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.



USAGE RULES

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

3. Field 28D: Message Index/Total

FORMAT

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

PRESENCE


DEFINITION

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


22 July 2016 173

USAGE RULES

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

4. Field 30: Requested Execution Date

FORMAT

6!n (Date)

PRESENCE


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.

5. Field 51A: Initiating Institution

FORMAT

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


PRESENCE


DEFINITION

This field identifies the institution which is authorised by the ordering institution/account servicing institution toorder 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

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


PRESENCE


DEFINITION

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




USAGE RULES

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

Financial institution BIC contains the identification of the ordering institution.

7. Field 52a: Account Servicing Institution

FORMAT

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



PRESENCE


DEFINITION

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

CODES





22 July 2016 175















CODES

In option C, Party Identifier may be used to indicate a national clearing system code.



























USAGE RULES

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


If the account servicing institution cannot be identified by a financial institution BIC, option C should be usedcontaining a 2!a clearing system code preceded by a double slash '//'.


FORMAT






PRESENCE


DEFINITION

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

CODES

The following codes must be used in this field in the first position of the first line ( Code), placed betweenslashes ('/') (Error code(s): D82).

REJT Rejected Instruction rejected.

RETN Return Return.


22 July 2016 177


It is mandatory to follow the Payments Reject/Return Guidelines described in the Standards MT UsageGuidelines(Error code(s): T80).

USAGE RULES

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

9. Field 21: Transaction Reference

FORMAT

16x

PRESENCE


DEFINITION

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



USAGE RULES

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

10. Field 23E: Instruction Code

FORMAT

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

PRESENCE


DEFINITION

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

CODES

Instruction Code must contain one of the following codes (Error code(s): T47):



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

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

CMZB Zero balance theaccount

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

CORT Corporate trade Payment is made in settlement of a trade, for example, foreignexchange deal, securities transaction.

NETS Net SettlementSystem

This transaction contains a payment that should be settled via a netsettlement system, if available.

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

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

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

URGP Urgent Payment This transaction contains a time-sensitive payment which should beexecuted in an expeditious manner.


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 notallowed (Error code(s): D67).

CMSW with CMTO

CMSW with CMZB

CMTO with CMZB

CORT with CMSW

CORT with CMTO

CORT with CMZB

NETS with RTGS

In each occurrence of sequence B: when this field is repeated, the same code word must not be present morethan 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 thefollowing 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)


22 July 2016 179

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

• information codes ( OTHR)

11. Field 32B: Currency/Transaction Amount

FORMAT


PRESENCE


DEFINITION

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






FORMAT

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


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


PRESENCE


DEFINITION


CODES




















CODES






















22 July 2016 181






USAGE RULES

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

When one of the codes //FW (with or without the 9-digit number), //AU, //CP or //IN is used, it should appearonly 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, USbanks require that the code //FW appears in the optional Party Identifier of field 56a, 57a or 58a.





FORMAT

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



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


PRESENCE


DEFINITION

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

CODES




















CODES




















22 July 2016 183








USAGE RULES








FORMAT

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


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


PRESENCE


DEFINITION

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

CODES




















CODES




















22 July 2016 185








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.





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

The Canadian Imperial Bank of Commerce is a customer of Deutsche Bank, Toronto (DEUTCATT) andinstructs this bank via a proprietary link to ask Deutsche Bank, Frankfurt to make a euro payment to BancoBilbao Vizcaya Argentaria, Madrid, via an RTGS system, using CIBCCATT's EUR account at DEUTDEFF.



Information Flow

D00

2002

2

CIBCCATT

MT 207

TARGETsystem

Instruction

BBVAESMMDEUTDEFF

DEUTCATT

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

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



22 July 2016 187

MT 210 Notice to Receive

MT 210 ScopeThis message type is:

• sent by an account owner to one of its account servicing institutions.

• sent by a party authorised by the 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 theSender's account.

For use of messages in the corporate to bank environment, see the MT message implementation guide forcorporate customers available on www.swift.com.

MT 210 Format SpecificationsMT 210 Notice to Receive



O 25 Account Identification 35x 2


----->



O 50a Ordering Customer No letter option, C, or F 6



-----|


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

If field 50a is ... Then field 52a is ...

Present Not allowed

Not present Mandatory



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

MT 210 Usage RulesThis message should not be used for commodities. To notify a party of the receipt of commodities, the MT 605should be used.



FORMAT

16x

PRESENCE

Mandatory

DEFINITION

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



EXAMPLE

:20:oref1000

2. Field 25: Account Identification

FORMAT

35x (Account)

PRESENCE

Optional

DEFINITION

This field identifies the account to be credited with the incoming funds.

USAGE RULES

This field is used when the Receiver services more than one account for the Sender.


22 July 2016 189


FORMAT

6!n (Date)

PRESENCE

Mandatory

DEFINITION

This field contains the value date of all incoming funds specified in this message.




FORMAT

16x

PRESENCE

Mandatory

DEFINITION

This field contains the content of field 20 Transaction Reference Number, or other reference, for example,Common Reference, of the related transaction.



EXAMPLE

:21:ref1234


FORMAT


PRESENCE

Mandatory



DEFINITION

This field specifies the currency and amount to be received.






FORMAT

No letter option 4*35x (Name and Address)

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

Option F 35x4*35x




/34x (Account)



Or





PRESENCE


DEFINITION

This field specifies the ordering party when it is not a financial institution.

CODES





22 July 2016 191













CODES




















Identifier Code must be a non-financial institution BIC (Error code(s): T27,T28,T29,T45,E57).















USAGE RULES

If the account number of the ordering customer is known, it must be stated in Account.

In option F, subfield 2 (Name and Address): Numbers 1, 2 and 3 may be repeated.

In option F, subfield 2 (Name and Address): if number 2 is present, the first occurrence of number 3 mustinclude the town in additional details.


22 July 2016 193

In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if additionalspace is required for providing the Identifier of the ordering customer, one of the following options must beused:

1. First option (preferred): Identify the ordering customer with a different identifier where the length is not anissue.

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

In option F, subfield 2 (Name and Address): if additional space is required for providing the CustomerIdentification Number (number 6) or the National Identity Number (number 7) of the ordering customer, one ofthe following options must be used:

1. First option (preferred): Identify the ordering customer with a different identifier where the length is not anissue.

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

EXAMPLE

Option F - Example 1

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


:50F:/BE300012163714111/PHILIPS MARK4/197208305/BE/BRUSSELS


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


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


:50F:CUST/DE/ABC BANK/123456789/8-1234561/MANN GEORG2/LOW STREET 73/DE/FRANKFURT8/7890

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




FORMAT

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


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


PRESENCE


DEFINITION

This field specifies the ordering party when it is a financial institution.

CODES


















CODES





22 July 2016 195























USAGE RULES

When the Sender is also the ordering institution, it will be repeated in this field.





FORMAT

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




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


PRESENCE

Optional

DEFINITION

This field specifies the financial institution from which the Receiver is to receive the funds.

CODES



















CODES








22 July 2016 197





















USAGE RULES

This field is used when the intermediary institution is other than the ordering party.





Value 22 February 2010, 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 itsaccount at Chase Manhattan Bank, New York.



The funds will be paid through Citibank, New York.

Berliner Bank sends an MT 210, using reference 318393.

Information Flow

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)


Explanation Format

Sender BEBEDEBB

Message type 210

Receiver CHASUS33

Message text

Transaction reference number :20:318393

Value Date :30:100222

Related reference (1) :21:BEBEBB0023CRESZZ

Currency code and amount :32B:USD230000,

Ordering institution :52A:CRESCHZZ

Intermediary (2) :56A:CITIUS33


(1) Field 21 of the incoming funds transfer. In this case, the reference contained in field 21 is a commonreference from the related foreign exchange transaction. It will also appear in field 21 of the related fundstransfer instruction.

(2) The financial institution from which the funds will be received.


22 July 2016 199

MT 256 Advice of Non-Payment of ChequesNote: The use of this message type requires Message User Group (MUG) registration.

MT 256 ScopeThis message is sent by the Receiver of one or more cheque truncation messages. It is used to inform theSender of (a) previously sent cheque truncation message(s) of the non-payment of specified truncatedcheques.

This message may only be used to specify dishonoured items that result in reversing a previous paymentsettlement.

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 allindividual cheques detailed in sequence B.

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

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

MT 256 Advice of Non-Payment of ChequesStatus Tag Field Name Content/Options No.

Mandatory Sequence A Common Elements

M 20 Sender's Reference 16x 1

O 21 Related Message Reference 16x 2

End of Sequence A Common Elements

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

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

-----| End of Sequence B Cheque Details

Mandatory Sequence C Settlement Details

M 32A Value Date, Currency Code and Total AmountClaimed

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

End of Sequence C Settlement Details


MT 256 Network Validated RulesC1 If field 37J is present, then field 71G must also be present (Error code(s): E25).

If field 37J in sequence B is ... Then field 71G in sequence B is ...

Present Mandatory

Not present Optional

C2 The amount specified in field 71L in sequence C must be equal to the sum of all occurrences of field71F in sequence B (Error code(s): E26).

C3 The amount specified in field 71J in sequence C must be equal to the sum of all occurrences of field71G 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 alloccurrences of these fields in the message (Error code(s): C02).

C5 If the amount in field 32A of sequence C is equal to the sum of the amounts in the fields 32J ofsequence B, then field 19 must not be present; otherwise (that is the amount in field 32A of sequenceC is not equal to the sum of the amounts in fields 32J of sequence B), field 19 must be present (Errorcode(s): D80).

C6 If charges are included, field 19 must be present. It must contain the sum of amounts of all fields 32J insequence 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).

MT 256 Advice of Non-Payment of Cheques

22 July 2016 201

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

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

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

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

If field 71G in sequence B is ... Then field 71J in sequence C is ...



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 71H in sequence B is ... Then field 71K in sequence C is ...



C11 The amount specified in field 71K in sequence C must be equal to the sum of all occurrences of field71H 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 256. If a registered user receives an MT 256 without bilateral agreement with theSender, 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, forexample, a request for a photocopy to check the signature. For this, an MT 295 Queries must be used, forwhich 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 256must 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 cheque truncationmessage.


1. Field 20: Sender's Reference

FORMAT

16x

PRESENCE


DEFINITION

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



EXAMPLE

:20:oref1000

2. Field 21: Related Message Reference

FORMAT

16x

PRESENCE


DEFINITION

This field contains the Sender's reference of the previously received cheque truncation message.



EXAMPLE

:21:ref1234


22 July 2016 203

3. Field 44A: Transaction Reference Number

FORMAT

Option A 65x

PRESENCE


DEFINITION

This field contains the transaction reference number of the previously received cheque truncation message,generated by the beneficiary's financial institution, which identifies the transaction that this dishonouredcheque represents.

EXAMPLE

:44A:abc12354

4. Field 21: Related Message Reference

FORMAT

16x

PRESENCE


DEFINITION

This field contains the Sender's reference of the previously received cheque truncation message in case thisMT 256 is informing of the non-payment of cheques in the same currency that were included in different MTs256.



EXAMPLE

:21:ref1234

5. Field 21D: Cheque Number

FORMAT

Option D 35x

PRESENCE




DEFINITION

This field contains the number of the cheque that has been dishonoured, normally inserted on the cheque bythe issuer's financial institution.

USAGE RULES

This field must be the same as the cheque number specified in the original cheque truncation message.

EXAMPLE

:21D:9987434

6. Field 21E: Cheque Reference Number

FORMAT

Option E 35x

PRESENCE


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 cheque truncation message.

EXAMPLE

:21E:888014612

7. Field 23E: Reason for Non-Payment/Dishonour

FORMAT

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

PRESENCE


DEFINITION

This field indicates why a cheque was dishonoured.

CODES

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


22 July 2016 205

AMAM Amount exceedslimit

Amount exceeds the amount limit allowed for this account.

AMTL Amount exceedslimit

Amount exceeds the truncation limit as defined in the bilateralagreement (min. or max. amount).

CLOS Closed account The account specified is closed.

COLN Code line Error in code line.

DRAW Drawer Refer to drawer.

DUPL Duplicate Duplicate cheque information.

FRAU Fraudulent cheque Fraudulent cheque.

FROZ Frozen account (Legally) Frozen account.

FRWD Forward Forward dated cheque.

INCH Invalid chequenumber

The cheque number is invalid.

INSF Insufficient funds Insufficient funds.

INSI Insufficientinformation

Insufficient information.

INVA Invalid Account number is invalid.

NELI Not Eligible Cheques not eligible for truncation.

NMAT Non-Match Currency and account do not match.

OTHR Other Other followed by a bilaterally agreed code to specify a reason whichis not covered by the above.

REVO Revocation Revocation.

STLD Stale Stale cheque, that is, deposited too late relative to the issue date.

STOP Stop payment Stop payment of a cheque.


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

Option J 15d (Amount)



PRESENCE


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 inthe maximum length. The number of digits following the comma must not exceed the maximum numberallowed 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 cheque truncation message.

EXAMPLE

:32J:100000,

9. Field 37J: Interest Rate

FORMAT

Option J 12d (Rate)

PRESENCE


DEFINITION

This field specifies the interest rate to be collected from the Sender of the cheque truncation message.


The integer part of Rate must contain at least one digit. A decimal comma is mandatory and is included in themaximum length (Error code(s): T40,T43).

10. Field 71G: Interest Charges

FORMAT

Option G 3!a15d (Currency)(Amount)

PRESENCE


DEFINITION

This field specifies the currency and the interest charges due to the Sender of the MT 256.


22 July 2016 207




USAGE RULES

These interest charges are computed at a prevailing interest rate (field 37J) from the original value date (field30) up to the date when recovery of funds is expected to take place (field 32A).

EXAMPLE

:71G:USD3,

11. Field 71F: Sender's Charges

FORMAT

Option F 3!a15d (Currency)(Amount)

PRESENCE


DEFINITION

This field specifies the currency and the charges due to the Sender of the MT 256, if different from the issuer'sfinancial institution, for the above specified reason.




EXAMPLE

:71F:USD3,

12. Field 71H: Issuer's Financial Institution Charges

FORMAT

Option H 3!a15d (Currency)(Amount)

PRESENCE




DEFINITION

This field specifies the currency and the charges due to the issuer's financial institution, for the abovespecified reason.




EXAMPLE

:71H:USD8,

13. Field 32A: Value Date, Currency Code and Total Amount Claimed

FORMAT


PRESENCE

Mandatory in mandatory sequence C

DEFINITION

This field specifies the date when the recovery of funds is expected to take place, followed by the currencyand the total amount to be claimed.





EXAMPLE

:32A:961201USD1350,

14. Field 30: Original Value Date

FORMAT

6!n (Date)

PRESENCE

Optional in mandatory sequence C


22 July 2016 209

DEFINITION

This field specifies the value date that appeared on the related cheque truncation message.



USAGE RULES

As this message is sent after provisional credit has been given to the beneficiary, any consequential interestscan also be taken into account, by specifying that date. In this case, that is, when back-valuing is applied, noseparate fields must be used to indicate the interest charges.

EXAMPLE

:30:980108

15. Field 19: Total Cheque Amount

FORMAT

17d (Amount)

PRESENCE

Conditional (see rules C5 and C6) in mandatory sequence C

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 includedin the maximum length. The number of decimal digits in field 19 must not exceed the maximum for itscorresponding currency in field 32A in sequence C (Error code(s): C03,T40,T43).

EXAMPLE

:19:1350,

16. Field 71J: Sum of Interest Charges

FORMAT

Option J 3!a15d (Currency)(Amount)

PRESENCE

Conditional (see rule C9) in mandatory sequence C

DEFINITION

This field specifies the currency and the sum of all occurrences of field 71G in sequence B.






EXAMPLE

:71J:USD50,

17. Field 71L: Sum of Sender's Charges

FORMAT

Option L 3!a15d (Currency)(Amount)

PRESENCE


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

Option K 3!a15d (Currency)(Amount)

PRESENCE


DEFINITION

This field specifies the currency and the sum of all occurrences of field 71H in sequence B.




22 July 2016 211


EXAMPLE

:71K:USD343,

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

FORMAT

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



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


PRESENCE


DEFINITION

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

CODES





















CODES



























USAGE RULES

This field may only be used where the settlement does not follow the same route as the MT 256 (thismessage).


22 July 2016 213





EXAMPLE

:57A:MIDLGB2L

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

FORMAT

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


PRESENCE


DEFINITION

This field specifies the account number of the financial institution which is the ultimate recipient of the fundsbeing (re)transferred (that is the receiver of the cheque truncation message).

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 andaccount with institution

• one of these accounts is to be used for reimbursement

• there is no bilaterally agreed account.

EXAMPLE

:58B:/123-45678


On 10 December 2009, Thomas Cook, London informs Standard Bank of South Africa, Johannesburg that thefollowing travellers cheques are dishonoured in the cheque truncation message it received from StandardBank of South Africa (message reference 091201123456AA).

TRN Cheque Number Amount Reason for dishonour



Cheque 1 0912010IJKL235693 EB33333333 GBP10, Stopped cheque

Cheque 2 091201ZZZZ123456AA GB66666666 GBP20, Invalid chequenumber

Since Thomas Cook, London has already reimbursed Standard Bank of South Africa, it wants to have thefunds recredited to its account held at Midland Bank, London (account number 123456), back-valuing theamount with the value date used on the original cheque truncation message (original value date 091207).

Information Flow

D00

2001

4

Thomas CookLondon

Standard Bankof South AfricaJohannesburg

Sender

Receiver

Midland BankLondon

NatwestLondon

(MT 910/950)

MT 256 (MT 205*)

(MT 202)

MT



Chequetruncationmessage


Explanation Format

Sender COOKGB22

Message Type 256

Receiver SBZAZAJJ

Message Text

Sender's Reference :20:IPD/S0001/PAIDS

Related Message Reference :21:091201123456AA

Transaction Reference Number :44A:091201IJKL235693

Cheque Number :21D:EB33333333

Reason for Non-Payment/Dishonour :23E:STOP

Cheque Amount :32J:10,

Transaction Reference Number :44A:091201ZZZZ123456AA

Cheque Number :21D:GB66666666

Reason for Non-Payment/Dishonour :23E:INCH

Cheque Amount :32J:20,


22 July 2016 215

Explanation Format

Value Date, Currency Code and Total AmountClaimed

:32A:091207GBP30,

Account With Institution :57A:MIDLGB22

Beneficiary Institution's Account :58B:/123456


MT 256 ChecklistIt is strongly recommended that the following checklist be used by financial institutions as a basis for settingup 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 furtherfacilitate the setting up of these agreements, common procedures have been defined which financialinstitutions may choose to override.

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

Currency & amount• Specify minimum and maximum amounts per type of cheque

• Specify currencies accepted per type of cheque

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

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

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 cheque truncation message and the MT 256 that are mandatory for legalpurposes 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 maysimplify the new agreement.

Responsibility• Endorsement issue - Agree on procedures to follow, for example, 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 truncationagreement should make it the truncating party's responsibility to ensure that the truncated cheques containall legally required endorsements.

• Define the responsible parties at each stage of the whole process, for example, whether or not thebeneficiary's financial institution can determine stale dated cheques. Also the agreement should establishthe party responsible for verifying certain parts, for example, 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, for example, once a month

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

Settlement• Where there is a direct account relationship between the sender and receiver of the cheque truncation

message, the cheque truncation message can be used as a financial message to request to credit theaccount of the Sender automatically.

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

Administration• Define the contact address, for example, 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 cheque truncation message to execute the

payment of valid truncated cheques. This time frame starts at an agreed cut-off time for receipt of incomingmessages by the receiver.

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.


22 July 2016 217

D is the basis for calculating the value date, that is, 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 beconveyed, for example, 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 290 Advice of Charges, Interest and OtherAdjustments

See Category n - Common Group Messages, Chapter n90 Advice of Charges, Interest and Other Adjustmentsfor details concerning this message type.

MT 290 Advice of Charges, Interest and Other Adjustments

22 July 2016 219

MT 291 Request for Payment of Charges, Interest andOther Expenses

See Category n - Common Group Messages, Chapter n91 Request for Payment of Charges, Interest andOther Expenses for details concerning this message type.



MT 292 Request for CancellationSee Category n - Common Group Messages, Chapter n92 Request for Cancellation for details concerning thismessage type.

MT 292 Request for Cancellation

22 July 2016 221

MT 295 QueriesSee Category n - Common Group Messages, Chapter n95 Queries for details concerning this message type.



MT 296 AnswersSee Category n - Common Group Messages, Chapter n96 Answers for details concerning this message type.

MT 296 Answers

22 July 2016 223

MT 298 Proprietary MessageSee Category n - Common Group Messages, Chapter n98 Proprietary Message for details concerning thismessage type.



MT 299 Free Format MessageSee Category n - Common Group Messages, Chapter n99 Free Format Message for details concerning thismessage type.

MT 299 Free Format Message

22 July 2016 225

Glossary of TermsIn addition to the definitions which appear in Standards General Information, Glossary of Terms, the followingterms apply to category 2 message types:

Available Funds Funds available for transfer or withdrawal in cash.

Bankleitzahl An eight digit numeric code used to identify banks in Germany. It may onlybe assigned, changed or cancelled by Deutsche Bundesbank, in Germany.

CHIPS (Clearing HouseInterbank Payments System)

A private telecommunications payment service operated by the New YorkClearing House Association for banks in the New York area, whichhandles US dollar payments only.

CHIPS Participant A bank authorised to send and receive payments on the CHIPS system.

CHIPS Participant ID (ABANumber)

A unique number identifying a CHIPS participant. The first four digits arethe participant's number, followed by a one digit group identifier. ForSWIFT purposes, only the first four digits of the CHIPS Participant ID willbe used.

CHIPS Settling Participant A CHIPS Participant responsible for the settlement of its own CHIPS netdebit or credit position at the end of the CHIPS business day.

CHIPS Universal Identifier A unique six digit number assigned by CHIPS to identify an account.

Cover Payment The reimbursement of a correspondent bank for a payment.

Federal Funds US dollars on deposit at a Federal Reserve Bank in the United States.

Fedwire A payment service operated by the US Federal Reserve System as aprivate wire network for transfers between financial institutions havingaccounts at the Federal Reserve Bank.

Fedwire Routing Number A nine digit numeric code used to identify banks in the United States.

Funds Transfer Complete movement of funds between the originator and the beneficiary.A funds transfer may consist of one or more funds transfer transactions.

Funds Transfer Transaction The movement of funds directly between two parties, involving nointermediaries other than a payment or communications service.

Immediate Funds Same day funds in which the settlement is simultaneous with execution ofthe transaction.

Instructing Party The party instructing the Sender to execute a transaction.

Originator Initiator of the transfer instructions. Equivalent to the ordering institution(field 52a) in the MT 202.

Originator's Institution Identifies the financial institution which is acting for the originator of thetransfer.

Remitter The party which is the source of funds in a payment order.

Same Day Funds The funds available for transfer today, or for withdrawal in cash, subject tothe settlement of the transaction through the payment mechanism used.

Settlement A transfer of funds to complete one or more prior transactions made,subject to final accounting.



Legal Notices

Copyright

SWIFT © 2016. All rights reserved.

Disclaimer

The information in this publication may change from time to time. You must always refer to the latest available version.

SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement

SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy - End-User LicenseAgreement available at www.swift.com > About Us > Legal > IPR Policies > SWIFT Standards IPR Policy.

Translations

The English version of SWIFT documentation is the only official and binding version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT logo, SWIFT,SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and SWIFT Institute. Other product,service, or company names in this publication are trade names, trademarks, or registered trademarks of their respectiveowners.

Legal Notices

22 July 2016 227

category 2 - financial institution transfers - swift · pdf filestandards category 2 -...

Documents