Standards MT November 2016 - Usage Guidelines · PDF fileStandards MT November 2016 Usage...

Standards MT November 2016

Usage Guidelines

These usage guidelines explain how to use message standards. In addition, the document identifies specific issues thatrelate to message standards, and provides clarification (and examples) of message standards. This document is for allusers of Standards messages.

22 July 2016

Table of Contents

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

1 The MT 202 vs. the MT 910............................................................................................................5

1.1 Issue..............................................................................................................................................5

1.2 Clarification....................................................................................................................................5

1.3 Example........................................................................................................................................ 5

2 Book Transfer vs. Local Clearing in the MT 202/203.................................................................. 7

2.1 Issue..............................................................................................................................................7

2.2 Clarification....................................................................................................................................7

3 (Mis)Use of the MT 400 Advice of Payment................................................................................. 9

3.1 Issue..............................................................................................................................................9

3.2 Clarification....................................................................................................................................9

4 /C and /D Subfield in Account Number Lines in Payment Messages..................................... 13

4.1 Issue............................................................................................................................................13

4.2 Clarification..................................................................................................................................13

5 Use of Charges and Amounts Fields in the MT 754................................................................. 14

5.1 Issue............................................................................................................................................14

5.2 Clarification..................................................................................................................................14

6 The Cancellation of One or More Transactions in a Multiple Message.................................. 16

6.1 Issue............................................................................................................................................16

6.2 Clarification..................................................................................................................................16

6.3 Examples.....................................................................................................................................17

7 Code Words in Field 72 of the Category 1 and 2 Messages.................................................... 20

7.1 Issue............................................................................................................................................20

7.2 Clarification..................................................................................................................................20

7.3 Code Words Indicating the Party for which the Information or Instruction is Intended................ 20

7.4 Code Words Indicating Method of Advice, the Party to be Advised and Implicitly the

Advising Party............................................................................................................................. 21

Standards MT November 2016 Usage Guidelines Table of Contents

22 July 2016 2

7.5 Code Word Identifying the Party Involved in the Transaction which has not been Identified

in Other Fields............................................................................................................................. 21

8 US Clearing System Codes in SWIFT Payment Messages...................................................... 23

8.1 Issue............................................................................................................................................23

8.2 Clarification..................................................................................................................................23

9 Use of FR R.I.B. (Relevés d'Identité Bancaire) in SWIFT Payment Messages........................27

9.1 Issue............................................................................................................................................27

9.2 Clarification..................................................................................................................................27

10 System Validation of the Structure of Field 72 in the Categories 1 and 2 Messages............31

10.1 Issue............................................................................................................................................31

10.2 Clarification..................................................................................................................................31

10.3 Frequently Asked Questions....................................................................................................... 32

10.4 Examples.....................................................................................................................................33

11 Cancellation of an MT 103 Payment Instruction for which Cover has been Provided by

a Separate MT 202 COV...............................................................................................................36

11.1 Issue............................................................................................................................................36

11.2 Clarification..................................................................................................................................36

11.3 Options........................................................................................................................................ 37

12 Payments Reject/Return Guidelines.......................................................................................... 38

12.1 Payment Reject Guidelines......................................................................................................... 38

12.2 Payments Reject/Return Information...........................................................................................39

13 Customer Identification in the MTs 102, 103, and 103 REMIT for US Regulatory

Compliance.................................................................................................................................. 52

13.1 Issue............................................................................................................................................52

13.2 Customer Identification................................................................................................................52

Legal Notices......................................................................................................................................... 56

Standards MT November 2016 Usage Guidelines Table of Contents

22 July 2016 3

Preface

Introduction

This volume contains guidelines for using message standards. It is complemented by one otherMessage Usage Guidelines volume:

• Category 5 - Securities Markets Message Usage Guidelines - guidelines on the use of thesecurities messages

The usage guidelines are recommendations only, and do not form part of the Standards aspublished in the Standards volumes.

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

Significant changes

There are no significant changes to the content of the MT Usage Guidelines since the 24 July2015 edition.

Standards MT November 2016 Usage Guidelines Preface

22 July 2016 4

https://www2.swift.com/go/book/book33194/book33194/html

https://www2.swift.com/go/book/book31123/book31123/html

1 The MT 202 vs. the MT 910

1.1 Issue

What message should be sent upon receipt of an MT 202 ?

This section provides clarification of the message to be sent upon receipt of an MT 202 GeneralFinancial Institution Transfer. This message instructs payment to the account serviced by thereceiver, for the head office (specified in field 57a) of the Beneficiary Institution contained in field58a.

1.2 Clarification

In the context of Standards, each office and branch is considered to be a separate financialinstitution

In this case, the receiver of the MT 202 must send an MT 202 in reply to the party specified infield 57a. The receiver must not send an MT 910 Confirmation of Credit.

In the context of Standards, each office and branch is considered to be a separate financialinstitution. For this reason, the Beneficiary Institution is considered to be separate from its headoffice.

Furthermore, the MT 910 does not allow the specification of the party for which the transfer hasbeen made. Therefore, the head office would not be able to determine for which branch thefunds are intended.

1.3 Example

Banca Commerciale Italiana, Milan sends an MT 202 ordering its New York correspondent,Bank of New York, New York, to credit a USD account that it services to Banque Nationale deParis, Paris, in favour of Banque Nationale de Paris, Grenoble branch.

Bank of New York, New York, upon receipt of the MT 202, credits the USD account that itservices for Banque Nationale de Paris, Paris, and sends an MT 202 to Banque Nationale deParis, Paris, instructing further payment/credit to Banque Nationale de Paris, Grenoble.

Standards MT November 2016 Usage Guidelines The MT 202 vs. the MT 910

22 July 2016 5

D0

19

00

01

Banca Commerciale ItalianaMilan

Bank of New YorkNew York

Sender

Receiver

Banque Nationale de ParisParis

Account With

Institution

Banque Nationale de ParisGrenoble58a

57a

Beneficiary Institution

MT 202 in USD

(MT 202)

MT

Standards MT November 2016 Usage Guidelines The MT 202 vs. the MT 910

22 July 2016 6

2 Book Transfer vs. Local Clearing in the MT202/203

2.1 Issue

Book transfer or local clearing ?

When an MT 202/203 is sent in the local currency of the receiver, and the Beneficiary Institutionis domiciled in the same country, the beneficiary may be either credited in the books of thereceiver, or paid via a local clearing system. How should the sender format the MT 202/203 toclearly identify how payment should be effected?

2.2 Clarification

How to ensure book transfer or clearing

Whether the Beneficiary Institution is paid via the local clearing practice (for example, paymentthrough an automatic clearing system, or by cheque) depends on the existence of such asystem, and whether an account relationship exists in the currency of the transfer between thereceiver, or the Account With Institution, and the Beneficiary Institution. Use of an automaticclearing system normally takes precedence over any existing account relationship or othermeans of payment. Nevertheless, users are strongly recommended to contact theircorrespondents for details of local payment practices, as well as any specific requirements thattheir correspondents may have.

Practices are as follows:

• Where an automated system exists in the currency of the transfer, normal practice is to paythe beneficiary via that system, even if an account relationship exists between the receiver,or the Account With Institution, and the Beneficiary Institution. This practice is usuallyoverridden when the account number to be credited is specified in the account number lineof field 58a.

Therefore, to ensure payment by book transfer, the account number line of the BeneficiaryInstitution field must be used to specify the account to be credited.

• Where there is no automated system in the currency of the transfer, and an accountrelationship exists, the Beneficiary Institution will normally be credited by book transfer,unless otherwise indicated in field 72. If there is no account relationship, payment will bemade by cheque or some other means.

Some users are misusing the MT 202/203 in attempting to ensure either book transfer orclearing. For example, some users repeat the receiver of the MT 202/203 in field 57a, AccountWith Institution, to ensure book transfer; others repeat the Beneficiary Institution in field 57a toensure payment through the clearing system.

To ensure book transfer

The account number to be credited should be specified in the account number line of field 58a,Beneficiary Institution. If the account number is not known, or the sender is unsure of localclearing practice, instructions may be given in field 72, using appropriate code words. However,the use of field 72 may result in higher processing costs and should be avoided wheneverpossible.

Standards MT November 2016 Usage Guidelines Book Transfer vs. Local Clearing in the MT 202/203

22 July 2016 7

To ensure clearing

When a clearing system exists, an account number should not be specified in the accountnumber line of field 58a, Beneficiary Institution. Alternative identifiers, such as a FedwireRouting number or a CHIPS participant number may be used, where applicable.

Furthermore, if an automated clearing system does not exist, the alternative local clearingpractice to be used can be specified in field 72, using an appropriate code word (for example, /CHEQUE/). However, the use of field 72 may result in higher processing costs and should beavoided whenever possible.

Users should never attempt to ensure payment through the local clearing system by repeatingthe Beneficiary Institution in field 57a.

Standards MT November 2016 Usage Guidelines Book Transfer vs. Local Clearing in the MT 202/203

22 July 2016 8

3 (Mis)Use of the MT 400 Advice of Payment

3.1 Issue

Background

Numerous reports have been received on the misuse of the MT 400 Advice of Payment. Toclarify its proper use, the Documentary Services Working Group revised the scope of thismessage type.

There are two scenarios: firstly, when there is an existing account relationship between theRemitting Bank and the Collecting Bank, and secondly, where no such relationship exists.

3.2 Clarification

Example 1: existing account relationship

The Remitting Bank and the Collecting Bank have an account relationship in the currency of thecollection which is used for settlement in the following way:

• If authenticator keys have been exchanged between the Collecting Bank and the RemittingBank, the MT 400 is sent by the Collecting Bank to the Remitting Bank. As there is anaccount relationship, a cover payment (MT 202) should not be sent by the Collecting Bank -the MT 400 which has already been sent, suffices.

• If authenticator keys have been exchanged between a branch/affiliate of the Remitting Bankand a branch/affiliate of the Collecting Bank (and their account relationship is used), the MT400 is sent by the branch/affiliate of the Collecting Bank, to the branch/affiliate of theRemitting Bank. Field 52a contains the Collecting Bank, and field 58a the Remitting Bank.

Standards MT November 2016 Usage Guidelines (Mis)Use of the MT 400 Advice of Payment

22 July 2016 9

D0

19

00

02

Sender

Collecting Bank'sBranch/Affiliate(for example, Head Office)

Receiver

Remitting Bank'sBranch/Affiliate(for example, Head Office)

Remitting Bank58a

MT 400

Collecting Bank52a

Co

lle

cti

on

MT

As the account relationship between the branch/affiliate of the Collecting Bank and thebranch/affiliate of the Remitting Bank is used, a cover payment should not be sent.

The same applies if authenticator keys are exchanged between either a branch/affiliate of theCollecting Bank, or of the Remitting Bank, and the Remitting Bank or the Collecting Bank(that is, only field 52a is present in the message or only field 58a is present in the message),then the MT 400 is sent between the two parties that have the authenticator keys. This isprovided that their account relationship in the currency of the collection is used.

Example 2: no existing account relationship

Possible scenarios are as follows:

• If authenticator keys have been exchanged between the Collecting Bank and the Remittingbank, the following applies:

- The Collecting Bank sends an MT 400 to the Remitting Bank.

- The MT 400 will contain reimbursement instructions (fields 53a, 54a, and 57a).

- A cover payment (MT 202) in favour of the Remitting Bank (including the Remitting Bankscollection number in field 21) is sent by the Collecting Bank to its correspondent, asspecified in the MT 400.


22 July 2016 10

No existing account relationship

D0

19

00

03

MT 202

:21:COLLECTION NUMBERS

:58a:REMITTING BANK Sender

Collecting Bank'sBranch/Affiliate(for example, Head Office)

Receiver

Remitting Bank'sBranch/Affiliate(for example, Head Office)

Sender'sCorrespondent(Field 53a in MT 400)

(*)MT 400

MT 910/950

* It is assumed, in this case, that the Collecting and Remitting banks have a common correspondent

Co

lle

cti

on

MT

• If no authenticator keys have been exchanged between the Collecting Bank and theRemitting Bank, the Collecting Bank may send an MT 202 to its correspondent bank, withfield 58a containing the Remitting Bank and field 21 containing the Remitting Bank'scollection number. Any details, in addition to the collection number, which the CollectingBank wishes to provide to the Remitting Bank, should be specified in field 72 preceded bythe code word /BNF/.

Note The Collecting bank often sends an MT 400 to its correspondent, indicating theRemitting Bank in field 58a. This is a definite misuse of the MT 400. It createsconfusion at the bank receiving the MT 400, because they are not involved inthe collection. It also means that the collection will remain outstanding at theRemitting Bank.

• If authenticator keys have been exchanged between a branch/affiliate of the Remitting Bankand a branch/affiliate of the Collecting Bank (and their account relationship is not used), theMT 400 is sent by the branch/affiliate of the Collecting Bank to the branch/affiliate of theRemitting Bank. Field 52a contains the Collecting Bank, and field 58a contains the RemittingBank.

A cover payment (MT 202) in favour of the branch/affiliate of the Remitting Bank (that is, thereceiver of the MT 400, not the Remitting Bank indicated in field 58a of the MT 400) is sentto the sender's correspondent bank, as specified in the MT 400.

The same principle applies in those cases where authenticator keys are exchanged betweeneither a branch/affiliate of the Collecting Bank, or of the Remitting Bank, and the RemittingBank or the Collecting Bank (that is, only field 52a is present in the message or only field 58ais present in the message).


22 July 2016 11

Note Reports have been received of MT 103 Single Customer Credit Transfers, infavour of the customer of the Remitting Bank being sent either to the RemittingBank, or the Collecting Bank's correspondent. The Collecting Bank should neveruse the MT 103 in settlement of a collection, based on a collection instructionreceived from the Remitting Bank.

Authentication keys exchanged

D0

19

00

04

MT 202

:21:COLLECTION NUMBER

:58a:REMITTING BANK

Sender

Collecting Bank

Receiver

Remitting Bank

Sender'sCorrespondent(Field 53a in MT 400)

(*)

MT 400

MT 910/950

* It is assumed, in this case, that the Collecting and Remitting banks have a common correspondent

Co

lle

cti

on

52a

58a

MT


22 July 2016 12

4 /C and /D Subfield in Account Number Lines inPayment Messages

4.1 Issue

When to use /C or /D subfield

Clarification of when the first, optional, subfield (that is, /C or /D) should be used in the accountnumber line of party fields (that is, 52a, 53a, 54a, 56a, 57a, 58a and 59a) in payment messagetypes 102, 102 STP, 103, 103 REMIT, 103 STP, 200, 201, 202, 202 COV, 203, 205, and 205COV.

4.2 Clarification

Use of subfield /C and /D should be limited to field 53a

The use of this subfield is not necessary in party fields used to identify institutions andcustomers on the pay side of a payment instruction. If an account number is specified in thesefields (that is, 56a, 57a, 58a, and 59a), it will always be an account number owned by the partyidentified in that field - the party which is to be credited.

Similarly, the subfield is not necessary in the party field (52a) used to identify institutions on theoriginating side of a payment instruction. It is extremely unusual to quote an account number inthis field. If one is specified, it will be an account which has been debited.

In payment message types 102, 102 STP, 103, 103 REMIT, 103 STP, 200, 201, 202, 202 COV,203, 205, and 205 COV, the use of the first optional subfield in the account number line shouldbe limited to the reimbursement field 53a, and only in those cases where it is necessary tospecify whether the account identified is to be either credited or debited.

Standards MT November 2016 Usage Guidelines /C and /D Subfield in Account Number Lines in Payment Messages

22 July 2016 13

5 Use of Charges and Amounts Fields in the MT754

5.1 Issue

Correct use of the MT 754

Several comments have been received relative to the correct use of MT 754 Advice of Payment/Acceptance/Negotiation, particularly on the use of charges and amount fields, considering thevarious forms that a drawing under a documentary credit can take.

To clarify this, the Documentary Services Working Group has developed a matrix which displaysthe basic principles for the use of charges fields (that is, 71B and 73) and amount fields (that is,32a, 33B, and 34a) in the MT 754.

5.2 Clarification

Documentary credit available at and after sight

The following matrix illustrates the use of charges and amount fields in cases where adocumentary credit is available both at sight and after sight (the latter category covering creditsby deferred payment), and this for documentary credits with or without additional amountsand/or charges.

In the case of credits available after sight, a further distinction is made between up-front chargesand charges at maturity.

The second dimension of the matrix illustrates the fields to be used in both cases, where thereis debit authority and where the amount is to be claimed from the issuing or reimbursing bank.

Also, it shows whether a date field should contain a value date or a maturity date, andcorrespondingly the appropriate letter option to be used.

Documentary credit available at sight

Terms of reimbursement With additional amounts and/orcharges

Without additional amountsand/or charges

Authority to debit 32B

34A (Value Date)

[=32B +/- 33B, 71B, 73]

32A (Value Date)

Amount(s) to be claimed fromreimbursement/issuing bank

32B

34B

[=32B +/- 33B, 71B, 73]

32B

Standards MT November 2016 Usage Guidelines Use of Charges and Amounts Fields in the MT 754

22 July 2016 14

Documentary credit available after sight

Terms ofreimbursement

With additional amounts and/or charges Without additionalamounts and/orchargesCharges up-front Charges at maturity

Authority to debit 32A (Maturity Date)

34A (Value Date)

[=73, Charges only]

32B

34A (Maturity Date)

[=32B +/- 33B, 71B, 73]

32A (Maturity Date)

Amount(s) to be claimedfrom reimbursement/issuing bank

32A (Maturity Date)

34B (Value Date)

[=73, Charges only]

32B

34A (Maturity Date)

[=32B +/- 33B, 71B, 73]

32A (Maturity Date)

Standards MT November 2016 Usage Guidelines Use of Charges and Amounts Fields in the MT 754

22 July 2016 15

6 The Cancellation of One or More Transactions ina Multiple Message

6.1 Issue

How to use the MT n92

How should the MT n92 Request for Cancellation be used to cancel one or more transactions ina multiple message such as the MT 203? How can such cancellations be distinguished from thecancellation of the entire multiple message?

How do these rules apply to other multiple messages?

6.2 Clarification

The MT n92 cancels one or more transactions in a multiple message or the entire multiplemessage

The MT n92 enables a sender of a message to request the receiver to cancel that message.The MT n92 also caters for the cancellation of one or more transactions in a multiple message.

The cancellation of a multiple message should distinguish between the following types ofcancellation:

• the cancellation of the entire multiple message

• the cancellation of a single transaction contained in a multiple message

• the cancellation of several transactions but not the entire multiple message

Rules

To enable the receiver to clearly distinguish between these different cancellation requests, thefollowing rules are provided:

• If two or more transactions, but not all the transactions in a multiple message, are to becancelled, one MT n92 must be sent for each transaction to be cancelled.

• If an entire multiple message is to be cancelled, one MT n92 should be sent containing, infield 21, the contents of field 20 Transaction Reference Number applicable to the entiremultiple message.

When, as in the case of the MT 203 Multiple General Financial Institution Transfer, there isno field 20 applicable to the entire multiple message, the contents of field 20 in the firsttransaction should be used. Other multiple messages having no field 20 for the entiremessage, but one for each transaction include the MTs 450 Cash Letter Credit Advice, 456Advice of Dishonour, 604 Commodity Transfer/Delivery Order, and 559 Paying Agent'sClaim.

If the copy fields are used, at least all the mandatory fields in both the non-repetitive, and allthe repetitive, sequences must be present. Alternatively, field 79 may be used to indicate thatthe entire multiple message is to be cancelled, together with information to enable thereceiver to uniquely identify the message to be cancelled.

• If one transaction in a multiple message is to be cancelled, field 21 must be used to containthe transaction reference number associated with the unique transaction to be cancelled;that is, the contents of field 20 in the repetitive sequence related to that transaction.

Standards MT November 2016 Usage Guidelines The Cancellation of One or More Transactions in a Multiple

Message

22 July 2016 16

In those cases where there is no field 20 in the repetitive sequence (for example, the MTs210 Notice to Receive and 605 Commodity Notice to Receive), field 21 of the repetitivesequence to be cancelled must be specified in field 21 of the MT n92.

Furthermore, if the copy fields are used, a copy of at least the mandatory fields in the non-repetitive sequence, together with those in the relevant repetitive sequence, must be present.Fields contained in the repetitive sequences relating to transactions not to be cancelled,must not be present. In lieu of the copy fields, field 79 may be used to indicate that only onetransaction is to be cancelled, together with information to enable the receiver to uniquelyidentify the transaction to be cancelled.

• Where there is no field 20, or field 21, per transaction within a multiple message, the multiplemessage must be cancelled as a whole and, if necessary, a corrected version sent. Thesemultiple messages include the collection messages (that is, the MTs 410 Acknowledgement,412 Advice of Acceptance, 420 Tracer, 422 Advice of Fate and Request for Instructions and430 Amendment of Instructions), the travellers cheque messages (that is, category 8), andthe MT 935 Rate Change Advice.

6.3 Examples

How to use the MT n92

The following examples illustrate the use of the MT n92 to request the cancellation of the firsttransaction with a transaction reference number of 2345 for the amount of 1000000 EURcontained in an MT 203 sent by Österreichische Länderbank, Vienna, to Algemene BankNederland, Amsterdam. The MT 203 contains four transactions each with its own transactionreference number and related reference totalling 1 million EUR with a value date 020102.

Example 1

Using MT n92 - copy of mandatory fields of the transaction to be cancelled

SWIFT message Comments

OELBATWW292ABNANL2A:20:2356

-

:21:2345 Transaction reference number of the transaction to be cancelled.

:11S:2030201020001000072

MT of the original message to be cancelled. Date on which theoriginal message was sent. Session number and inputsequence number of the original message.

:19:1000000,:30:020102:20:2345:21:789022:32B:EUR100000,:58A:MGTCUS33

Copy of the mandatory fields in the fixed sequence and those ofthe repetitive sequence relating to the transaction to becancelled.

- End of message

Text/Trailer


Message

22 July 2016 17

Example 2

In lieu of the copy fields of the original message to be cancelled, field 79 could be used asshown below:

Using MT n92 with field 79 to cancel one transaction in a multiple message



-

:21:2345 Transaction reference number of the transaction to be cancelled.

:11S:2030201020001000072


:79:PLEASE CANCEL FIRST TRANSACTION WITH TRN 2345 AND RELATEDREFERENCE 789022 VALUE DATED 020102 FOR EUR100000, TO MGTCUS33.

Narrative description of transaction to be cancelled.

- End of message

Text/Trailer

Example 3

In cancelling the entire MT 203, field 21 must contain the transaction reference number of thefirst transaction. However, either field 79, or the copy fields, will indicate that the entire messageis to be cancelled, either in narrative text or the copy, of at least all the mandatory fields of boththe non-repetitive and the repetitive sequences:

Using MT n92 to cancel an entire MT 203



-

:21:2345 Transaction reference number of the first transaction.

:11S:2030201020001000072



Message

22 July 2016 18


:19:1000000,:30:020102:20:2345:21:789022:32B:EUR100000,:58A:MGTCUS33 :20:2346:21:ABX2270 :32B:EUR300000,:58A:MELNGB2L:20:2347:21:CO 2750/26:32B:EUR200000,:58A:CITIUS33:20:2348:21:DRESFF2344OELBWW:32B:EUR400000,:58A:DRESDEFF

Copy of the mandatory fields in the fixed sequence and those ofall repetitive sequences contained in the message to becancelled.

- End of message

Text/Trailer


Message

22 July 2016 19

7 Code Words in Field 72 of the Category 1 and 2Messages

7.1 Issue

How to use field 72

This section explains how to use code words in field 72 of Category 1 and 2 messages.

7.2 Clarification

Rules

The contents of field 72 in the MTs 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107, 200,201, 202, 202 COV, 203, 204, 205, and 205 COV must be preceded by a code word betweenslashes, indicating the party for which the information is intended, unless otherwise indicated byanother code word.

Specific code words have been defined for use in some of these messages, as noted in thespecifications for field 72 in the Standards General Field Definitions Plus or in the Category 1 -Customer Payments and Cheques and Category 2 - Financial Institution Transfers messagereference guides.

It should be emphasised that bilaterally-agreed code words may also be used in field 72,provided that they adhere to the required structure of maximum 8 characters and with therecommendation to use only uppercase alphabetic characters.

The following tables show SWIFT-defined code words available for use in field 72 of the paymentmessages.

7.3 Code Words Indicating the Party for which the Information orInstruction is Intended

Code words table

The following code words indicate the party for which the information or instruction is intended.

Code Description

/REC/ Instructions following are for the receiver of the message.

/INT/ Instructions are for the intermediary.

/ACC/ Instructions following are for the Account With Institution.

/BNF/ Information following is for the beneficiary. This code word may be usedin the MTs 202, 202 COV, 203, 204, 205, and 205 COV. This code wordmust not be used in the MT 103, as field 70, Remittance Information, isavailable for transaction details intended for the beneficiary. Nor shouldthis code word be used in MTs 200 and 201, as the beneficiary isalways the sender.

Standards MT November 2016 Usage Guidelines Code Words in Field 72 of the Category 1 and 2 Messages

22 July 2016 20

https://www2.swift.com/go/book/usgf/usgf/html

https://www2.swift.com/go/book/cat1/cat1/html



7.4 Code Words Indicating Method of Advice, the Party to beAdvised and Implicitly the Advising Party

Code words table

The following code words indicate the method of advice, the party to be advised and, implicitly,the advising party.

Code word Description

/PHONIBK/ The receiver is to telephone the intermediary.

/TELEIBK/ The receiver is to contact the intermediary via the most efficienttelecommunications means available.

/PHON/ The receiver (if no field 56a is present), or the intermediary, is totelephone the Account With Institution.

/TELE/ The receiver (if no field 56a is present), or the intermediary, is tocontact the Account With Institution via the most efficienttelecommunications means available.

/PHONBEN/ The last financial institution in the chain (that is, the receiver or theAccount With Institution) is to telephone the beneficiary.

/TELEBEN/ The last financial institution in the chain (that is, the receiver or theAccount With Institution) is to contact the beneficiary via the mostefficient telecommunications means available.

Note These codes are defined for use in specific messages and implicitly identify theparty for which the information is intended. Therefore, they must not be precededby another code identifying that party.

These codes should not be used in field 72 of the MT 103, as their equivalentshould be used in field 23E Instruction Code of the MT 103.

7.5 Code Word Identifying the Party Involved in the Transactionwhich has not been Identified in Other Fields

Code words table

The following code word identifies the party involved in the transaction which has not beenidentified in other fields, and is provided as information to the receiver.


22 July 2016 21

Code word Description

/INS/ The instructing institution is identified in field 72, preceded by this codeword, in those cases where this party is different from the orderingparty specified in field 52a. It identifies the party which instructed thesender to execute the transaction.

This code word is available for use in field 72 of the MTs 102 STP, 103,103 REMIT, 103 STP, 202, 202 COV, 203, 205, and 205 COV.

The use of an ISO Business Identifier Code is strongly recommended.A maximum of two lines may be used. In case of MTs 102 STP and103 STP an ISO financial institution BIC must be used.


22 July 2016 22

8 US Clearing System Codes in SWIFT PaymentMessages

8.1 Issue

Use of US clearing system codes in payment messages

Standards incorporate guidelines on the use of clearing system codes in the optional accountnumber line of selected party fields of the payment messages (that is, the MTs 101, 102, 102STP, 103, 103 REMIT, 103 STP, 104, 200, 201, 202, 202 COV, 203, 204, 205, and 205 COV).

The following sections provide additional information about the use of US clearing systemcodes, specifically:

• the CHIPS participant number

• the CHIPS UID

• the Fedwire number

8.2 Clarification

8.2.1 CP: CHIPS Participant Number

Rules

These codes are used to identify participants in the CHIPS system in the United States (that is,clearing banks). They are sometimes referred to as the CHIPS ABA numbers.

As of August 1992, the CHIPS participant number has been expanded from three, to four digits.Non-US banks, however, may continue to use the three-digit number in payment messages sentto US banks.

The following rules apply:

• If the institution can be identified by a financial institution BIC, the CHIPS participant numbershould not be used, as it provides redundant information (that is, an institution has only oneBIC and only one CP number).

• If a CHIPS participant number is quoted, option D (name and address) must be used. CHIPSparticipant numbers may be used in fields 56a, 57a, and 58a.

• Only one CHIPS participant number should be present in an instruction and should normallyidentify the first financial institution on the payment side of the instruction.

8.2.2 CH: CHIPS UID

Rules

These six-digit codes (that is, //CH followed by six digits) are used as party identifiers in CHIPSinstructions.

Contrary to the other codes defined in the Standards MT Category volumes, such as the CHIPSparticipant number or the Bankleitzahl, a CHIPS UID can identify not only a financial institution,but also a corporate customer.

Standards MT November 2016 Usage Guidelines US Clearing System Codes in SWIFT Payment Messages

22 July 2016 23

https://www2.swift.com/uhbonline/books/a2z/standards_mt.htm

The UID is very precise insofar as it identifies a specific account to which funds are to be paid.Therefore, to the extent that the account title is the same, an account owner may have anaccount with several different banks, yet only one UID. If an account owner has several accountswith the same bank, each account will have a different title (for example, A account, B account)and each account will be identified by a separate UID.

CHIPS UID example

ABC Company has accounts with AABKUS33, BBBKUS33, and CCBKUS33. At AABKUS33,ABC Company has an account entitled ABC Company which it uses for all its regular financialtransactions. It also has a separate account at the same bank entitled ABC Company ForeignBills, which it uses for its foreign bills-related transactions.

AT BBBKUS33, ABC Company has two accounts. The first is entitled ABC Company. Thesecond is entitled ABC Company Investment. At CCBKUS33, it has one account entitled ABCCompany.

Each of these five accounts has a unique account number attributed by the bank. However,these five accounts will be identified by only three UID numbers. All three ABC Companyaccounts will have the same UID, say 123456; the account entitled ABC Company Foreign Billswill have a different UID, say 135790 and the account entitled ABC Company Investment willhave another UID, say 024689.

Database view

In a database, these entries would appear as follows (the Account With Institution wouldnormally be identified by its CHIPS participant number):

Name/account title UID Account with institution Account number

ABC Company 123456 AABKUS33

BBBKUS33

CCBKUS33

238765

12987

456889

ABC Company Foreign Bills 135790 AABKUS33 6587654

ABC Company Investment 024689 BBBKUS33 67273

Clearly, UID number 123456 on its own does not identify where funds are to be paid - it merelyidentifies in whose favour they are to be paid. In other words, the UID identifies a beneficiary.Where funds are to be paid must be determined from the rest of the instruction.

Parties identified by a UID need not be geographically located in the United States. The accountidentified must, however, be on the books of one or more CHIPS participants located in theUnited States. In the example above, although ABC Company's address may be in say,Brussels, AABKUS33, BBBKUS33, and CCBKUS33 must be CHIPS participants.

A financial institution BIC on its own will generate a UID by default (assuming the institution hasa UID). However, because of the very specific nature of UIDs, it is recommended that if a UID isknown, it should be quoted.

If a CHIPS UID number is quoted, option D must be used. CHIPS UID numbers may be used infields 56a, 57a, 58a, and 59a.


22 July 2016 24

8.2.3 FW: Fedwire Number

Rules

These nine-digit codes are used to identify parties in the Fedwire payment system within theUnited States. Unlike other clearing system codes, their presence also instructs payment byFedwire.

Furthermore, the presence of the code FW without the Fedwire number, in those cases whereoption A has been used, specifies that payment is to be made through Fedwire. All Fedwirepayments are made through the Fedwire system to a branch of the Federal Reserve Bank, infavour of the party identified. The branch of the Federal Reserve Bank to which payment will bemade is determined from the first digits of the Fedwire number.

A Fedwire number can be attributed to parties who are not geographically located in the UnitedStates, provided that the account identified is on the books of one of the Federal ReserveBanks.

A financial institution BIC will generate a Fedwire number by default (assuming the institutionhas an account with a Federal Reserve Bank). Although rare, a party may have severalaccounts with the Federal Reserve Bank, each of which will have a different Fedwire number.Except for these rare cases, it is recommended that the BIC be used with the Fedwire code, butwithout the Fedwire number.

If a Fedwire number is quoted, option D must be used. Fedwire codes may be used in fields56a, 57a, and 58a.

8.2.4 Additional Observations on CP, CH, and FW

Observations

The CHIPS participant number (CP), CHIPS UID (CH), and Fedwire (FW) codes may be used inthe same instruction. However, logic suggests that each code should appear only once, and thatthe following rules should be respected:

• Since the Fedwire code FW indicates how payment should be made, it must only be used toidentify the first financial institution in the payment side of the instruction. Other parties in thechain may be identified by CHIPS UID numbers or financial institution BICs.

• A CHIPS participant number must also identify the first financial institution in the paymentside of the instruction. Other parties in the chain may be identified by CHIPS UID numbers orfinancial institution BICs.

• A CHIPS UID number may identify one or more of the parties on the payment side of theinstruction. It may identify the first financial institution on the payment side of the instruction.If this is a US institution and a CP number is available, the user must use a CP numberinstead of the CHIPS UID. If the US institution has a financial institution BIC, the user mustuse the BIC instead of a CP number.

• US codes, and other codes defined for use on SWIFT, identify parties in a national clearingsystem and therefore should only be used in instructions which will be paid through thatparticular clearing system. In other words, they should normally only be used in aninstruction sent to a bank located in the same country as the clearing system.

• With the exception of the US codes, different clearing system codes cannot appear in thesame instruction.


22 July 2016 25

8.2.5 Account Number or Clearing System Code

Recommendations

In all cases, using a clearing system code excludes the use of the account number line for anyother information. When both an account number and a clearing system code are known, achoice has to be made as to which one should be used. Recommendations are shown below.

The presence of an account number implies that the party so identified is to be credited on thebooks of the immediately preceding party, whereas a clearing system code generally identifieswhere the funds are to be paid. Thus, given the choice between an account number and aclearing system code, senders must decide how payment is to be effected by the receiverand/or any other institutions in the payment chain.

If payment by book transfer is required, it is recommended that the account number be used. Ifpayment is to be made through the clearing system to the party identified, then it isrecommended that the clearing system be used.

8.2.6 Option A or D

Option A vs. option D

Some codes can only be used with option D, some may be used only with option A and somemay be used with either. For the sender of a SWIFT message, such differentiation may notappear logical. For the receiver, however, the difference may be important.

Clearly a financial institution BIC can be processed automatically by the receiver of a message.Indeed, as noted above, a financial institution BIC will generate a default value for a clearingsystem code. Therefore, if a field is identified by the letter option A, the receiver will immediatelyknow that the field contains a piece of information (the financial institution BIC) that can beprocessed automatically.

The letter option D, on the other hand, tells the receiver that the party in the field is identified byfree text. Hence, routines can be developed to automatically process instructions on the basis ofthe letter option specified.

However, exception routines need to be incorporated for the account number line. The presenceof a forward slash in the first position of the field flags the presence of the optional accountnumber line. Depending on the party identified database, this may or may not be sufficient forthe receiver to automatically process the instruction.

A clearing system code, identified by two forward slashes in the first two positions of the field(that is, the account number line), gives the receiver information which can be processedautomatically. Once again, routines can be developed to process instructions on the basis of thepresence of a clearing system code.

The difficulty arises when both a clearing system code and a financial institution BIC are givenfor the same party: should the receiver process the instruction on the basis of the clearingsystem code, or the financial institution BIC? Which of the two should take precedence in thecase of a discrepancy? By using letter option D, this dilemma is avoided, as the letter optionimmediately tells the receiver that the text portion of the field cannot be automaticallyprocessed, thus ensuring that processing will be carried out based on the clearing system codespecified in the account number line.


22 July 2016 26

9 Use of FR R.I.B. (Relevés d'Identité Bancaire) inSWIFT Payment Messages

9.1 Issue

Use of R.I.B.

Standards incorporate guidelines on the use of clearing system codes (that is, Bankleitzahl,Canadian, CHAPS, CHIPS, and Fedwire) in the optional account number line of selected partyfields of the payment messages (MTs 101, 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 200,201, 202, 202 COV, 203, 205, and 205 COV).

In France, a similar concept exists, the Relevés d'Identité Bancaire or R.I.B. which enablesFrench banks to automatically process payment instructions received by them. Although aspecific code is not yet incorporated into the payment message standards to explicitly identify aR.I.B., this guideline is intended to help users understand how the R.I.B. can be used.

9.2 Clarification

R.I.B. Format

The R.I.B. is used in France to identify an account held in the books of a financial institution.The R.I.B. can therefore identify not only a private individual, but also a corporate customer.

The R.I.B. consists of 23 characters which identify not only the account number, but also thebank, and branch of the bank, at which the account is held. It also includes a check key.

R.I.B. format

D0190011

Check key

Account number

Branch code

Institution code

30750000500000012728Z61

R.I.B. - structure

Element Description

Bank Code The first element comprises a five-digit code which identifies thefinancial institution in France and is unique to the institution. There isa direct link between the four-character party prefix of a BIC and thefive-digit bank code of the R.I.B.

Branch Code The second element comprises a five-digit code which identifies thebranch of the institution where the account is held.

Standards MT November 2016 Usage Guidelines Use of FR R.I.B. (Relevés d'Identité Bancaire) in SWIFT Payment

Messages

22 July 2016 27

Element Description

Account Number The third element is an eleven alpha-numeric character code whichidentifies the account.

Check Key The fourth element is a two-digit check key calculated by analgorithm, which guarantees the integrity of the complete accountidentification.

The R.I.B. explicitly identifies two parties: the account-servicing financial institution and theaccount owner. In this respect, it is unlike the other clearing system codes, which only explicitlyidentify one party - either the financial institution or the account owner, but not both.

In terms of message formatting, use of the R.I.B. is extremely easy. It should be used in exactlythe same way as an account number, that is, it should appear in the same field as the accountowner. Where the R.I.B. is used in a letter-option party field (for example, 58a), it may be usedwith all letter options.

Since the R.I.B. contains information which identifies not only the beneficiary customer, but alsothe account domiciliation, it may be tempting to omit the Account With Institution (field 57a) fromthe payment instruction. The French banks strongly encourage senders to provide thisinformation, however, since it can be used as a further check to ensure that the payment iscorrectly executed. From the sender's viewpoint, this also means that no specific processing isrequired to produce a payment instruction to be sent to a French correspondent.

In those cases where the party identified by the R.I.B. in the account number line and the partyidentified in the text portion of the field are different, to the extent that it is possible for theFrench bank to clearly identify this difference, then the French bank would normally contact thesender for clarification. This situation will vary from bank to bank, however, depending on thebank's own procedures and agreements. Users are, therefore, strongly encouraged to clarify theposition with their correspondent(s).

Note Although the R.I.B. is an essential element in the straight-through processing ofpayment instructions sent to French banks, its use does not remove the need toexercise due care and attention when preparing instructions. The responsibility toprovide coherent payment instructions still resides with the sender (and, ultimately,with the Ordering Customer).

Example

Les Entreprises Dupont, Lille send their invoice number ED930212/045 amounting to EUR56,650 to Universal Imports, New York, requesting that payment be made to their account withFrench Bank, Lille. The invoice indicates the R.I.B. of Les Entreprises Dupont to be30750000500000012728Z61. Universal Imports therefore requests its bank, US Bank, NewYork to make the payment.

The US Bank has neither authenticator keys, nor an account relationship with French Bank,therefore it sends the instruction to its correspondent in Paris, Gallic Bank.

The following diagram illustrates the information flow between the parties to this transaction:


Messages

22 July 2016 28

R.I.B message information flow

59

50

D019

0012

US BankNew York

Universal ImportsNew York

Gallic BankParis

Sender

Receiver

Les Entreprise DupontLille

Beneficiary Customer

Ordering Customer

French Clearing System

57aFrench BankLille

Account With Institution

MT

MT

The SWIFT message - an MT 103 - sent by the US Bank, New York would be formatted like this:

Message format

Explanation Format

Sender USBAUS33

Message Type 103

Receiver GALLFRPP


Messages

22 July 2016 29

Explanation Format

Message Text

Transaction Reference Number :20:93060-0156

Bank Operation Code :23B:CRED

Value Date/Currency Code/Amount :32A:020102EUR56650,

Currency/Instructed Amount :33B:EUR56650,

Ordering Customer :50K:UNIVERSAL IMPORTS1 COMMERCIAL ROADNew York

Account with Institution :57A:BANKFR2L001

Beneficiary Customer :59:/30750000500000012728Z61LES ENTREPRISES DUPONTRUE DU LABRADORLILLE

Remittance Information :70:/RFB/ED930212/045

Details of Charges :71A:SHA

End of message

Text/Trailer


Messages

22 July 2016 30

10 System Validation of the Structure of Field 72 inthe Categories 1 and 2 Messages

10.1 Issue

Validation of field 72

This usage guideline explains how field 72 will be validated by SWIFT, and what code words aredefined by SWIFT for use within the field when it is used in the payments messages.

Background

The change in definition for field 72 was first introduced in May 1991 for payment messagesMTs 200, 201, 202, 202 COV, 203, 205, and 205 COV, and further expanded to include MTs102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107, and 204, that were added lately. This wassubsequently introduced to the Category 3 messages. This change states that 'Each item ofinformation in this field must be preceded by a code word which specifically indicates the partyfor which it is intended, unless the party for which the information is intended is alreadyindicated by the use of another code word (for example, /TELE/). Where bilateral agreementscovering the use of code words in this field are in effect, the code word must conform to thestructure for presenting code words in this field.

This requirement was introduced to ensure that the receivers of these messages would be ableto process them automatically, thereby avoiding confusion and delays. However, receivers willnot be alone in benefiting from the changes. Manual intervention and repair of payment andfinancial trading instructions result in higher costs being charged to the sender or theBeneficiary Customer. Errors resulting from the mis-interpretation of instructions reflect badly onall the parties involved in the instruction.

10.2 Clarification

Field 72 structure

The contents of field 72 in the MTs 102, 102 STP, 103, 103 REMIT, 103 STP, 104, 107, 200,201, 202, 202 COV, 203, 204, 205, and 205 COV must be preceded by a code word betweenslashes, indicating the party for which the information is intended, unless this is indicated by thecode word itself.

Specific code words have been defined for use in some of these messages, as noted in thespecifications for field 72 in the Standards General Field Definitions Plus or in the Category 1 -Customer Payments and Cheques and Category 2 - Financial Institution Transfers messagereference guides.

It should be emphasised that bilaterally agreed code words may also be used in field 72,provided that they adhere to the defined structure.

Field 72 is an optional field. If it is used, then the following structure must be used:

• The first line must begin with a single slash, followed by a code word (the code word mustconsist of at least one, and up to eight (upper-case), alphabetical characters), followed by asecond slash (that is, /8c/). The code word itself will not be checked by SWIFT, since thestandard specifically allows bilaterally-agreed code words to be used. Free text may follow

Standards MT November 2016 Usage Guidelines System Validation of the Structure of Field 72 in the Categories 1

and 2 Messages

22 July 2016 31

https://www2.swift.com/go/book/usgf/usgf/html




the second slash, up to the maximum number of characters allowed in the line (35characters, including the code word and slashes). The free text is optional; a complete set ofspace characters will be NAK.

• If the second and subsequent lines are used, each line must begin with either a code word,optionally followed by free text as described above, or a double slash, followed by at leastone, and up to thirty three, free text characters (that is, //33x). The double slash is used toindicate that the information is a continuation of the previous line. The free text after thedouble slash is mandatory; a complete set of space characters will be NAK.

SWIFT has defined certain code words which can be used in field 72. Other bilaterally-agreedcode words may also be used. Thus, SWIFT normally does not check the use of specific codewords in the field, nor ensure that a code word requiring information to follow is in fact followedby information. (See section Payments Reject/Return Guidelines on page 38.)

In order to facilitate the automatic processing of the information in field 72, there should be onlyone SWIFT-defined code word per line. Where bilaterally-agreed code words are being used,this requirement need not apply, since it is assumed that both sender and receiver are fullyconversant with the specific use of the field in those cases.

10.3 Frequently Asked Questions

Introduction

This section provides a list of frequently asked questions relating to the structure and contentsof field 72.

FAQs

Question Answer

Will I have to structure all information in field 72 ofall my SWIFT messages?

No. The additional validation checks will only applyto the message types listed at the beginning of thisguideline.

Can I use any code word in field 72 of the Paymentand Foreign Exchange, Money Markets andDerivative messages?

Yes. The new validation will not check that only thecode words listed in the message reference guidesare used. The code words in the messagereference guides are those agreed and defined bythe SWIFT User Community. Other code wordswhich have been agreed between senders andreceivers are also allowed, provided that they areno longer than eight (upper-case) alphabeticcharacters (8a) in length.

What will happen if the text information in my field72 contains a slash (/) character and, because thetext wraps over from one line to the next, the slashappears as the first character of a line?

Your message could be NAKed. When informationflows over several lines, each line should begin witha double slash (//) to indicate that it is acontinuation of the previous line. Provided yourespect this rule, the first character of the textportion of the line can be a slash (see example 3below).


and 2 Messages

22 July 2016 32

Question Answer

Can I put two code words in field 72 of thesemessages?

Yes and no. We strongly recommend that there beonly one code word per line, particularly whenSWIFT-defined code words are used. The reasonfor this is that it would enable a receiver toautomatically read and/or forward the informationcontained in the line. If, however, you are usingseveral bilaterally agreed code words and you knowthat the receiver will be able to interpret theinformation correctly, you may specify more thanone code word per line.

Can I ensure that I am formatting field 72 in myPayment and Foreign Exchange, Money Markets,and Derivative messages correctly?

Yes. You can use the enhanced Test and Trainingmode to check your messages. In full functionmode or local test mode, future messages whichyou send will be validated against the new releaserequirements.

10.4 Examples

Example of field 72 in an MT 103

:72:/INS/BCZACDKIBIC'CrLf'/REC/FOR THE ATTENTION OF DHR SMIDT'CrLf'//SPECIAL OPERATIONS'CrLf'The instruction has been received by the sender from Banque Commerciale du Congo,Kinshasa(/INS/), although this bank was not the original Ordering Institution which would havebeen identified in field 52a; the receiver is requested to pass the instruction to the attention ofDhr Smidt (/REC/).

The use of the code word /REC/ will probably prevent the instruction being processedautomatically in this case, since the information which follows requires interpretation.

Example of field 72 in an MT 202:

:72:/TELE/PHONE(+322)6553266/FAX6553801'CrLf'///TELEX+046/26532'CrLf'The sender has asked that the Account With Institution be advised by the most appropriate andefficient means of telecommunication available. The sender has provided phone, fax, and telexnumbers.

The sender has used a slash to separate the different elements. The second line starts withdouble slash, to indicate that it is a continuation of the first line. The third slash on the secondline is used to separate the FAX element from the TELEX element.

While a slash (/) is part of the valid SWIFT character set, we strongly recommend that anothercharacter be used, whenever possible, to avoid potential problems.


and 2 Messages

22 July 2016 33

Examples of field 72 in Category 1 and 2 messages

Following examples would fail the validation check and would be NAKed:

• :72:HAPPY CHRISTMAS'CrLf'Reason: the first line of the field does not contain a code word.

• :72://SPECIAL OPERATIONS'CrLf'/REC/FOR THE ATTENTION OF DHR SMIDT'CrLf'Reason: the first line of the field does not begin with a code word.

• :72:/REC/FOR THE ATTENTIONOF DHR SMIDT'CrLf'SPECIAL OPERATIONS'CrLf'Reason: the second line of the field does not begin with either a code word or a doubleslash.

• :72:/REC/eee'CrLf'Where e are blanks

Reason: the information following the code word /REC/ consists entirely of blank characters.

• :72:/REC/'CrLf'//'CrLf'Reason: there is no information following the //.

• :72:/REC/'CrLf'//eee'CrLf'Where e are blanks

Reason: the information following the // consists entirely of blank characters.

• :72:/REC/'CrLf'/bnf/'CrLf'Reason: the code word /bnf/, in the second line, is not in (upper-case) alphabetic characters.

• :72:/acc/'CrLf'/REC/'CrLf'Reason: the code word /acc/, in the first line, is not in (upper-case) alphabetic characters.

• :72:/REC/'CrLf'/INT/eee'CrLf'Where e are blanks

Reason: the information in the second line, following the code word /INT/, consists entirely ofblank characters.

• :72:/AAAAAAAAA/'CrLf'/REC/'CrLf'Reason: the code word /AAAAAAAAA/, in the first line, exceeds 8 characters.

• :72:/AAAAAAAA/12345678901234567890123456'CrLf'/REC/'CrLf'Reason: the contents of the first line exceeds 35 characters.

• :72:/AAAAAAAA/'CrLf'//3456789012345678901234567890123456'CrLf'


and 2 Messages

22 July 2016 34

Reason: the contents of the 2nd line exceeds 35 characters.

• :72:/123/'CrLf'//345678901234567890123456789012345'CrLf'Reason: the code word in the first line does not consist entirely of upper-case alphabeticcharacters.


and 2 Messages

22 July 2016 35

11 Cancellation of an MT 103 Payment Instructionfor which Cover has been Provided by a SeparateMT 202 COV

11.1 Issue

Cancel an MT 103 for which cover has been provided by a separate MT 202 COV

To cancel an MT 103 payment instruction, for which cover has been provided by a separate MT202 COV:

1. Should an MT 192 be sent to the receiver of the MT 103?

2. Should an MT 292 be sent to the receiver of the MT 202 COV?

3. Should an MT 192 be sent to the receiver of the MT 103 and an MT 292 to the receiver ofthe MT 202 COV?

4. Should an MT 192 be sent to the receiver of the MT 103 and no cover be sent at all?

The purpose of these guidelines is to give guidance on the best option to use, both from apractical and legal point of view.

11.2 Clarification

The MT 103 payment instruction and its cover, the MT 202 COV, should be considered as onetransaction

As practices vary widely and may impact the choice of a preferred option, the legal relationshipestablished between the sender and the receiver of the original MT 103 (that is, mandator andmandated party) must be taken into account. The receiver is therefore responsible for carryingout the mandate given by the sender.

The MT 103 payment instruction and its cover, the MT 202 COV, should be considered as onetransaction. Consequently, cancelling the original MT 103 should automatically trigger thecancellation by the receiver of the whole transaction, including the cover.

Standards MT November 2016 Usage Guidelines Cancellation of an MT 103 Payment Instruction for which Cover has

been Provided by a Separate MT 202 COV

22 July 2016 36

11.3 Options

Four options are presented below:

Option Advice

1) Sending an MT 192 to thereceiver of the MT103 is therecommended and mostlogical option.

The receiver of the MT 103 and MT 192 is responsible for requestingcancellation of the payment from the beneficiary if payment has alreadybeen effected, and for initiating the return of the funds through thecorrespondent chain, that is, reversing the MT 202 COV. The return ofthe funds is not cover for an MT 103 and therefore constitutes a normalfinancial institution transfer for which the MT 202 must be used.

By doing so, the receiver retains control of the funds, and does not runthe risk of having the cover reversed by its correspondent before consentis received from the beneficiary and debit authorisation is given to thereceiver's correspondent.

If cover is refunded in favour of the sender, the receiver must undertakeany adjustments for use of funds separately. Alternatively, the receivermust initiate the specific request to its correspondent to return the fundswith good value, or with compensation.

2) Sending an MT 292 to thereceiver of the MT 202 COV,which was sent in cover of theMT 103 present drawbacks.

Not only is Option 2 a longer procedure for both sender and receiver,since the correspondents will have to forward a request forreimbursement to the receiver, but in addition, it could result in thereceiver of the MT 103 being automatically debited by its correspondent.The receiver would then have to obtain restitution of the original paymentfrom the beneficiary.

3) Sending an MT 192 to thereceiver of the MT 103, and anMT 292 to the receiver of theMT 202 COV.

This option might appear as the fastest and surest way of obtainingreturn of the funds. However, it could result in the funds being returnedby the receiver before the request from the correspondent is received.This would cause confusion and duplication.

4) Sending an MT 192 to thereceiver of the MT 103 withoutsending any cover.

This option presents threats for both sender and receiver. This situationcould arise if the sender realises that a mistake has been made, andrequests cancellation of the MT 103 before the MT 202 COV instructionhas been sent.

The receiver will be put in a position of having received, and possiblyacted on, a bona-fide payment instruction for which it is entitled to expectreimbursement. If the beneficiary subsequently refuses to refund thepayment, the receiver will be out of funds.

The sender obviously does not want to be debited by its correspondentfor an instruction which should not have been sent. Nevertheless, therisk is that the receiver and/or beneficiary will refuse to refund theoriginal, or that the refund will not be effected with original value.

Standards MT November 2016 Usage Guidelines Cancellation of an MT 103 Payment Instruction for which Cover has

been Provided by a Separate MT 202 COV

22 July 2016 37

12 Payments Reject/Return Guidelines

12.1 Payment Reject Guidelines

Purpose of the Payment Reject Mechanism

The Generic Payment Reject Mechanism is designed to increase automation and removeambiguity. It is available in all payments messages used for payment rejects and returns.

Rejects versus returns

In order to avoid duplication of error codes, rejects and returns are considered as the result ofsemantic errors which are not validated by FIN, such as "account closed". FIN validation errors,such as "missing mandatory field", are still handled through negative acknowledgementsreturned by FIN.

From the receiver's point of view, rejects and returns can be defined as follows:

• Reject occurs when the message and/or transaction has not yet been booked; that is,accounting has not yet taken place.

• Return occurs when the message and/or transaction has already been booked; that is,accounting has already taken place, and an amount must be returned to the original sender.

Handling of charges

Charges can be defined as fees resulting from the rejection/return of the messages ortransactions.

Charges, and their application, vary extensively according to the following:

• differing country and market requirements

• individual business relationships, for example between bank and customer

• common banking practice

• details of charges codes

Due to these significantly different practices, it is not possible to specify a means of handlingcharges. The generic payment reject mechanism, however, caters for the possibility to reportcharges that have been deducted, or applied to payment rejects/returns.

Specification of the levied reject/return charges, that is, charges that have been applied to therejected/returned transaction (for example, deducted from the returned principal) should beincluded in order to assist the original sender of the message to reconcile differences inamounts.

Errors and reason codes

The error code list covers the majority of message text errors (that is, block 4) not validated byFIN. It can be used for both message (that is, file) level and transaction level rejects/returns andrepresents common, generic errors causing rejects/returns. It does not cover country-specificerrors.

The list is not intended to be exhaustive, and can be bilaterally extended. Space is foreseen toadd a textual reason for further explanation.

Time frames

A general rule is: as soon as possible (ASAP) and according to normal banking practice.

Standards MT November 2016 Usage Guidelines Payments Reject/Return Guidelines

22 July 2016 38

It was deemed inappropriate to state a specific time frame for issuing or acting upon a reject/return message, for the following reasons:

• differing country, local, bank-to-client relationship agreement requirements

• time frames usually stated/handled in bilateral/service agreements, and are subject tonormal banking practice

• complexity of, and variations in, the return process

• may be market-dictated and adhered to by market participants

Routing

As a general rule of good practice, the payment reject/return should always follow the sameroute as the original transaction. This ensures that all relevant information used in the originalpayment chain is contained in the reject/return message received by the original sender.

Rejection/return of individual transactions within the same message

Certain multiple transaction messages (for example, MTs 201, 203, and 204) contain more thanone field 72, that is, a field 72:

• in the non-repetitive sequence, (that is, at the file level)

• in the repetitive sequence, (that is, at transaction level)

The following guidelines should be followed in these cases:

• In cases where the mechanism is used to indicate that a message was rejected/returned dueto a file level error, field 72 of the non-repetitive sequence should be used.

• In cases where the mechanism is used to indicate that a message was rejected/returned dueto a transaction level error, an MT n95 should be used without the original messageappended to it. The field 79 of this MT n95 will contain the reject/return information for theerroneous transaction.

If several transactions have to be rejected/returned, several MTs n95 will have to be sent.

12.2 Payments Reject/Return Information

Information

Depending on the message type used to return or reject a payment, the information required toprocess the rejected/returned transaction must be placed in either field 72 or field 79.

The SWIFT system validates the format for the reject or return functionality whenever the firstsix characters in line 1 of either field 72 or 79 contain the character string /REJT/ or /RETN/.

MTs currently affected by this form of additional validation are the payment messages:

• MTs 102, 103, 103 REMIT, 104, 107, 110, 200, 201, 202, 202 COV, 203, 204, 205, 205 COV,and 207 for field 72.

The use of field 72 in the MT 104 and 107 must abide by the reject and return formattingrules or be NAK'd with conditional error code D82.

• MTs 195 and 295 for field 79 or, alternatively, field 72 when present in the appended copy ofthe underlying message.

• MTs 199 and 299 for field 79.

This mechanism is not intended for use in other message types.


22 July 2016 39

12.2.1 Field 72 or Field 79: Sender to Receiver Information/Narrative

Field 72 or field 79

FORMAT 6*35x (Field 72) / 35*50x (Field 79)

DEFINITION For the purposes of this guideline, this field details the reason for the return orrejection.

VALUES The following code words must be used to provide details on the return:

Line 1 /REJT/

or

/RETN/

2!n[1!a][/2c] M /REJT/ means a reject and isfollowed by the identification of thefield causing the reject or

/RETN/ means a return and isfollowed by the identification of thefield causing the return.

Line 2 /2!c2!n/ [29x] (for field 72)

or

[44x] (for field 79)

M Reason Code (see below),optionally followed by a textdescription of the precedingreason code.

Line 3 /MREF/ 16x M Sender's Reference, that is, field20 of the original message(Transaction Reference Number orFile Reference).

Line 4 /TREF/ 16x O Transaction Reference, that is,field 21 of the actual transaction,for example an MT 102 or MT 104.

Line 5 /CHGS/ 3!a15d O ISO currency code and chargesamount. This may contain relevant,levied reject/return charges, thatis, charges that have been appliedto the rejected/returnedtransaction (for example, deductedfrom the returned principal).

Line 6 /TEXT/ 29x (for field 72)

or

44x (for field 79)

O Some further narrative details.

The field causing the Reject or Return is identified by:

Field Description

2!n The field tag of the field in which the error occurred (for example, 32 denotes theerror occurred in field with tag 32).


22 July 2016 40

Field Description

[1!a] If applicable, this gives the letter option of the preceding field tag in which the erroroccurred, (for example, A after 32 means field 32A).

[/2c] If a field tag appears more than once in a message type, this alphanumeric codedetails the sequence in which the error occurred, (for example, /C after 32A meansthe error occurred in field 32A of sequence C, 59/B1 denotes the error occurred infield 59 of sequence B1).

The actual reason code must be one of the following codes (Error code T80):

Code Type Reason

AC01 Account Number Format of the account number specified is not correct.

AC02 Account Number Format of the account number specified is non-numeric.

AC03 Account Number Format of the account number specified is not valid forlocal sort/national clearing code.

AC04 Account Number Account number specified has been closed on thereceiver's books.

AC05 Account Number Account number specified is not a valid account at theAccount With Institution.

AC06 Account Number Account specified is blocked, prohibiting posting oftransactions against it.

AM01 Amount Specified transaction/message amount is equal to zero.

AM02 Amount Specified transaction/message amount is greater thanallowed maximum.

AM03 Amount Specified transaction/message amount is in a non-processable currency outside of existing agreement.

AM04 Amount Amount of funds available to cover specified transaction/message amount is insufficient.

AM05 Amount This transaction/message appears to have beenduplicated.

AM06 Amount Specified transaction amount is less than agreedminimum.

AM07 Amount Amount specified in transaction/message has beenblocked by regulatory authorities.

AM08 Amount Specified charges amount is not as agreed betweensender and receiver.


22 July 2016 41

Code Type Reason

BE01 Beneficiary Specification of beneficiary is not consistent withassociated account number.

BE02 Beneficiary Beneficiary specified is not known at associated sort/national clearing code.

BE03 Beneficiary Beneficiary specified no longer exists in the books.

BE04 Beneficiary Specification of beneficiary address, which is required forpayment, is missing/not correct.

BE05 Beneficiary Party who initiated the transaction/message is notrecognised by the beneficiary.

AG01 Agreement No agreement is on file at the receiver for affectingassociated transaction/message.

AG02 Agreement Bank Operation code specified in the transaction/message is not valid for receiver.

DT01 Date Invalid date (for example, wrong settlement date).

MS01 General Reason has not been specified due to sensitivities.

PY01 Party Unknown Account-With Institution.

RF01 Reference Transaction reference is not unique within the message.

RC01 Routing Code Routing code specified in the transaction/message hasan incorrect format.

RC02 Routing Code Routing code specified in the transaction/message is notnumeric.

RC03 Routing Code Routing code specified in the transaction/message is notvalid for local clearing.

RC04 Routing Code Routing code specified in the transaction/message refersto a closed branch.

RR01 Regulatory Requirement Specification of the ordering customer's account orunique identification needed for reasons of regulatoryrequirements is insufficient or missing.

RR02 Regulatory Requirement Specification of the ordering customer's name and/oraddress needed for regulatory requirements is insufficientor missing.

RR03 Regulatory Requirement Specification of the beneficiary customer's name and/oraddress needed for regulatory requirements is insufficientor missing.


22 July 2016 42

Code Type Reason

TM01 Receipt Time Associated transaction/message was received afteragreed processing cut-off time.

X1!c2!n Bilateral Refers to a reject/return code whose specification andmeaning has been bilaterally agreed to by Sending andReceiving parties.

12.2.2 Rules

Rules applicable to field 72 or field 79 of a Rejected/Return message

In order for the system to recognise a payment message considered as a candidate for reject orreturn format validation, the first six characters in line 1 of either field 72 or 79 must consist ofcode word /REJT/ or /RETN/.

The following examples are recognised as candidates for return or reject validation:

:72:/RETN/59(CrLf):79:/REJT/59(CrLf)The following example will not be recognised as a candidate for return or reject validation:

:72:/RJCT:/57A/XY99/Returned/MREF/xxxxx67890xxxxx6Once a payment message is considered as a reject/return message, the following rules are validfor either field 72 or 79:

Rule 1

Information following the code /RETN/ or /REJT/ must consist of the field causing the reject orreturn, and possibly other message elements (for example, letter option and sequenceidentification), which may be helpful to the sender in isolating the specific error.

See Field 72 or Field 79: Sender to Receiver Information/Narrative on page 40 for pertinentformatting requirements.

Rule 2

Each line must begin with a code word.

Example for rule 2 - Valid:

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/xxxxx67890xxxxx6(CrLf)/TREF/xxxxx67890xxxxx6(CrLf)/CHGS/USD1234,25(CrLf)/TEXT/12345xxxxx12345xxxxx123 45xxxx(CrLf)

Example for rule 2 - Invalid:

• :72:/RETN/59(CrLf)/AC01/(CrLf)xxxxx/MREF/67890xxxxx6(CrLf)/TREF/xxxxx67890xxxxx6(CrLf)/CHGS/USD1234,25(CrLf)/TEXT/12345xxxxx12345xxxxx1 2345xxxx(CrLf)


22 July 2016 43

Reason: the third line does not start with the code word /MREF/.

Rule 3

All code words must be in proper sequence.

Examples for rule 3 - Valid:

• :72:/RETN/59(CrLf) (Mandatory)

/AC01/12345xxxxx(CrLf) (Mandatory)

/MREF/xxxxx67890xxxxx6(CrLf) (Mandatory)

/TREF/xxxxx67890xxxxx6(CrLf) (Optional)

/CHGS/USD1234,25(CrLf) (Optional)

/TEXT/12345xxxxx(CrLf) (Optional)• :79:/RETN/59(CrLf) (Mandatory)

/AC01/(CrLf) (Mandatory)

/MREF/xxxxx67890xxxxx6(CrLf) (Mandatory)Note Narrative information following the reason code (for example, /AC01/) is

optional.

Examples for rule 3 - Invalid:

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/xxxxx67890xxxxx6(CrLf)

/CHGS/USD1234,25(CrLf)

/TREF/xxxxx67890xxxxx6(CrLf)/TEXT/12345xxxxx12345xxxxx1 2345xxxx(CrLf)Reason: codes /CHGS/ and /TREF/ are not in proper sequence.

• 72:/RETN/59(CrLf)

/MREF/xxxxx67890xxxxx6(CrLf)

/AC01/(CrLf)/TREF/x(CrLf)/CHGS/USD1234,25(CrLf)/TEXT/x(CrLf)Reason: code /MREF/ and reason code (for example, /AC01/) are not in proper sequence.

Rule 4

The code words described for lines 1, 2, and 3 are mandatory whereas for lines 4, 5, and 6 theyare optional.


22 July 2016 44


• :72:/RETN/59(CrLf)/AC01/xx67890xx67890xx6789(CrLf)/MREF/x(CrLf)

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/TREF/xxxxx67890xxxxx6(CrLf)/CHGS/BEF1234,(CrLf)/TEXT/xxx67890xx67890xxx6789(CrLf)


• :72:/RETN/59(CrLf)/AC01/(CrLf)Reason: the code /MREF/ is missing.

• :72:/RETN/59(CrLf)/MREF/xxxxx67890xxxxx6(CrLf)Reason: the reason code (for example, /AC01/) is missing.

Rule 5

A code word must not be split across lines.


• :72:/RETN/59(CrLf)/AC(CrLf)

01/(CrLf)/MREF/x(CrLf)Reason: the reason code (for example, /AC01/) is split across lines.

• :72:/RETN/59(CrLf)/AC01/xxxxx67890(CrLf)

xxxxx67890xxxxx6789(CrLf)/MREF/x(CrLf)Reason: the information following the reason code (for example, /AC01/) is split across lines.

Rule 6

A single line must not exceed the following number of characters:

• 35 characters in field 72

• 50 characters in field 79


• :72:/RETN/59(CrLf)/AC01/xxxxx67890xxxxx67890xxxxx67890(CrLf)/MREF/x(CrLf)Reason: information following the reason code (for example, /AC01/) exceeds 29 characters.

• :79:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/TREF/xxxxx67890xxxxx6(CrLf)/CHGS/EUR1234,(CrLf) /TEXT/xxxxx67890xxxxx67890xxxxx67890xxxxx67890xxxxx(CrLf)


22 July 2016 45

Reason: information following the code word /TEXT/ exceeds 44 characters.

Rule 7 - Field 72

For field 72, the maximum number of lines permitted is 6.

For field 72, the minimum number of lines required is 3.

Rule 8 - Field 79

For field 79, the maximum number of lines permitted is 35.

For field 79, the minimum number of lines required is 3.

Rule 9 - Additional lines

Additional lines of information following the line beginning with the code word /TEXT/ must bepreceded by double slashes: //.


• :79:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)//xxxxx67890xxxxx67890xx xxx67890xxx(CrLf)/xxxxx67890xxxxx67890xx xxx67890xxx(CrLf)Reason: one of the lines following the code word /TEXT/ is missing the double slash.

Example for rule 9 - Valid :

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)//xxxxx67890xxxxx67890xx xxx67890xxx(CrLf)//xxxxx67890xxxxx67890xx xxx67890xxx(CrLf)

Rule 10

Code words must not be duplicated.


• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)

/TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)

/TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)Reason: the code word /TEXT/ is used twice.

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/MREF/x(CrLf)Reason: the code word /MREF/ is used twice.

Rule 11

The information component following all code words, except for reason code (for example,/AC01/) is mandatory. This component must not be empty, nor consist entirely of blanks.


22 July 2016 46

Examples for rules 11 - Invalid:

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/(CrLf)/TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)

• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/eeeeeeCrLf) /TEXT/xxxxx67890xxxxx67890xx xxx6789(CrLf)Where e are blanks.

Rule 12

After the code /CHGS/, the number of digits following the decimal comma in the amount mustnot exceed the maximum number allowed for the currency specified (Error code C03).


• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/CHGS/USD1234,678(CrLf)

Rule 13

The ISO currency code following the code /CHGS/ must be valid (Error code T52).


• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)/CHGS/XYZ1234,67(CrLf)

Rule 14

The reason code must be one of the codes listed in the code word table matrix (see Field 72 orField 79: Sender to Receiver Information/Narrative on page 40), or be formatted according tothe rules given in the last entry of this same table.


• :72:/RETN/59(CrLf)/AA01/(CrLf)/MREF/x(CrLf)


• :72:/RETN/59(CrLf)/AC01/(CrLf)/MREF/x(CrLf)

• :72:/RETN/59(CrLf)/X101/(CrLf)/MREF/x(CrLf)

• :72:/RETN/59(CrLf)/XA01/(CrLf)/MREF/x(CrLf)


22 July 2016 47

12.2.3 Payment Reject Examples

Example 1: using an MT 103

In this example, the original content of field 72 is replaced with the payment reject informationstring.

MT 103 (original) in error MT 103 returning the message in error

Entry Date = 021125

Input session# = 0001

Input Sequence# = 000001

:20:Sample A:23B: CRED:32A:021125USD100,25:33B:USD100,25:50K:Franz Holzappel GMBH Vienna:59:H.F. Janssen:71A:SHA

Entry Date = 021126



:20:Return A:23B: CRED:32A:021125USD100,25:33B:USD100,25:50K:Franz Holzappel GMBHVienna:59:H.F. Janssen:71A:SHA:72:/REJT/59 /BE04//MREF/Sample A/CHGS/EUR20,

Example 2: using an MT 195 without the appended MT 103

In this example, field 79 consists of the payment reject information string.

MT 103 (original) in error MT 195 rejecting the message in error

Entry Date = 021125



:20:Sample 1:23B:CRED:32A:021125USD100,25:33B:USD100,25:50K:Franz Holzappel GMBHVienna:59:H.F. Janssen :71A:SHA

Entry Date = 021126



:20:Error 1:21:Sample 1 :75:/4/030102:11R:10302112500010000001:79:/REJT/59/BE04/Ben address incomplete/MREF/Sample 1

Example 3: using MT 195 with MT 103 embedded in field 79

In this example, field 79 consists of the payment reject information string and the originalmessage.


22 July 2016 48


Entry Date = 021125



:20:Sample 1:23B:CRED:32A:021125USD100,25:33B:USD100,25:50K:Franz Holzappel GMBHVienna:59:H.F. Janssen:71A:SHA

Entry Date = 021126



:20:Error 1:21:Sample 1:75:/4/030102:11R:10302112500010000001:79:/REJT/59/BE04/Ben address incomplete /MREF/Sample 1/TEXT/:20:Sample 1//:32A:021125USD100,25//:33B:USD100,25//:23B:CRED//:50K:Franz Holzappel GMBH//Vienna//:59:H.F. Janssen//:71A:SHA

Example 4 using MT 195 with the appended MT 103

In this example, the MT 195 contains a copy of the MT 103 with its field 72 replaced by thepayment reject information string.


Entry Date = 021125




Entry Date = 021126



:20:Error 2:21:Sample 2:75:/4/030102:11R:10302112500010000001:20:Sample 2:23B:CRED:32A:021125USD100,25:33B:USD100,25:50K:Franz Holzappel GMBHVienna:59:H.F. Janssen:71A:SHA:72:/REJT/59:/BE04/Ben address incomplete/MREF/Sample 2/CHGS/EUR30,00


22 July 2016 49

Example 5: using MT 199 with MT 103 embedded in field 79

In this example, field 79 consists of the payment reject information string and the originalmessage.


Entry Date = 021125




Entry Date = 021126



:20:Error 2:21:Sample 2:79:/RETN/59/BE04/Ben address incomplete /MREF/Sample 2/CHGS/EUR30,00/TEXT/:20:Sample 2//:23B:CRED//:32A:021125USD100,25//:33B:USD100,25//:50K:Franz Holzappel GMBH//Vienna//:59:H.F. Janssen//:71A:SHA

Examples 6 to 10

In the following examples, German Bank services a EUR account for Swedish Bank andSwedish Bank services a SEK account for German Bank.

Example 6

Original via MT 103, Return via MT 103

Situation Action taken

German Bank sends a EUR payment order (that is,an MT 103) to Swedish Bank, and Swedish Bankcan not execute.

Swedish Bank sends an MT 103 return message,therefore allowing the German Bank to withdrawtheir previously booked EUR from the SwedishBank's account.


22 July 2016 50

Example 7

Original via MT 103, Reject via MT 103


German Bank sends a SEK payment order (that is,an MT 103) to Swedish Bank, and Swedish Bankcan not execute.

Since the amount has not yet been booked on theSEK account of the German Bank, Swedish Banksends an MT 103 reject message.

Example 8

Original via MT 102, Reject via MT 195 (file level error)


German Bank sends SEK payments to SwedishBank via an MT 102. An error is detected on the filelevel and the Swedish Bank can not execute.

Since the amount has not yet been booked on theSEK account of the German Bank, Swedish Banksends an MT 195 reject message.

Example 9

Original via MT 102, Return via MT 195 (transaction level error)


German Bank sends SEK payments to SwedishBank via an MT 102. One transaction containedwithin the MT 102 cannot be executed by theSwedish Bank.

Swedish Bank sends an MT 195 return message.

Example 10

Original (third currency) via MT 103 plus associated MT 202 COV, Return via MT 103 andMT 202


German Bank sends a USD payment order (that is,an MT 103) to Swedish Bank, and Swedish Bankcan not execute.

Swedish Bank sends an MT 103 return message toGerman Bank, and an MT 202 to relevant UScorrespondent Bank, refunding the USD amount.


22 July 2016 51

13 Customer Identification in the MTs 102, 103, and103 REMIT for US Regulatory Compliance

13.1 Issue

Clear identification of originating and beneficiary parties

Regulatory and/or industry bodies are either looking at instituting, or are currently implementing,rules requiring financial institutions participating in their local clearing market to clearly identifythe originating and beneficiary parties in financial transactions. These regulations will apply topayments originating in the US - both cross-border and local clearing payments.

Financial institutions will be required to collect, retain and forward information such as:

• originator's full name, address and identifier

• account number/identifier or full name and address of the beneficiary

• execution date and amount of the transaction

• identification of the beneficiary's financial institution

In line with this requirement, when forwarding additional identification about the originator and/orthe beneficiary, the financial institutions in the US recommend the following formats to be used.

13.2 Customer Identification

13.2.1 Field 50K: Ordering Customer

Field block

FORMAT [/34x] (Account Number)

4*35x (Name and Address)

PRESENCE Mandatory

DEFINITION This field contains the originator of the transfer. When the originator is also thesender, this must contain the name/identifier of the sender.

RULES When required by regulatory authorities, an account number subfield or anotherIdentification subfield, but not both, must be present. One of the two followingrepresentations must be used:

Format 1:

/34x (account number)

4*35x (name and address)

Format 2:

/4!a/29x (type of identification) (identification)


Standards MT November 2016 Usage Guidelines Customer Identification in the MTs 102, 103, and 103 REMIT for US

Regulatory Compliance

22 July 2016 52

VALUES When FORMAT 2 is used, Type of Identification must contain one of the followingcode words, followed by the identification:

ARNU: Alien Registration Number (preceded by the ISO country code and aslash, /)

CCPT: Passport Number (preceded by the ISO country code and a slash, /)

CORP: Corporate Identification, that is, Identification Number of the Customer ina Corporation (preceded by the ISO country code, a slash, /, name of thecorporate and a slash, /)

DRLC: Driver's License Number (preceded by the ISO country code, a slash, /,state of issue and a slash, /)

OTHR: Other identification

TXID: Tax Identification Number/Social Security Number (preceded by the ISOcountry code and a slash, /)

Example - Format 1 :50K:/12345678JOHN SMITH299 PARK AVENUENEW YORK, NY 10017

Example - Format 2 :50K:/DRLC/US/NY/123-456-789JOHN SMITH444 MAIN STREET, APT, 6CFLUSHING, NEW YORK 11103

Example - Format 2 :50K:/TXID/US/121-23-1234JOHN SMITH444 MAIN STREET, APT, 6CFLUSHING, NEW YORK 11103

13.2.2 Field 59: Beneficiary

Field block

FORMAT [/34x] (account number)


PRESENCE Mandatory

DEFINITION This field contains the party designated by the ordering party as the ultimaterecipient of funds.

If available, an account number in this field must always identify the accountnumber of the Beneficiary Customer with its Account Servicing Institution.



22 July 2016 53

RULES If available, either the Account Number subfield, another Identification subfield, ora CHIPS Universal Identifier subfield must be present. One of the three followingrepresentations must be used:

Format 1:

/34x (account number)


Format 2:

/4!a/29x (type of identification) (identification)


Format 3:

//CH6!n (CHIPS Universal Identifier)


VALUES When FORMAT 2 is used, Type of Identification must contain one of the followingcode words, followed by the identification:

ARNU: Alien Registration Number (preceded by the ISO country code and aslash /)

CCPT: Passport Number (preceded by the ISO country code and a slash, /)

CORP: Corporate Identification, that is, Identification Number of the customer in acorporation (preceded by the ISO country code, a slash, /, name of the corporateand a slash /)

DRLC: Driver's License Number (preceded by the ISO country code, a slash, /,state of issue and a slash, /)

OTHR: Other identification

TXID: Tax Identification Number/Social Security Number (preceded by the ISOcountry code and a slash, /)

Example - Format 1 :59:/87654321PAUL WILLIAMS444 FIFTH AVE.APARTMENT 5ANEW YORK, NY 10023

Example - Format 2 :59:/CCPT/FR/654321PAUL RENARD 555 RUE D'ETOILEAPARTEMENT 4BPARIS, FRANCE

Example - Format 2 :59:/TXID/US/121-23-1234JOHN SMITH444 MAIN STREETAPARTMENT 6CFLUSHING, NEW YORK 11103



22 July 2016 54

Example - Format 3 :59://CH654321PAUL WILLIAMS444 FIFTH AVE. APARTMENT 5ANEW YORK, NY 10023



22 July 2016 55

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 thelatest 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 IPRPolicy - End-User License Agreement, available at www.swift.com > About Us > Legal > IPRPolicies > 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 thispublication are trade names, trademarks, or registered trademarks of their respective owners.

Standards MT November 2016 Usage Guidelines Legal Notices

22 July 2016 56

https://www.swift.com/about-us/legal/ipr-policies/standards-ipr-policy

https://www.swift.com/about-us/legal/ipr-policies/standards-ipr-policy

Date post:	23-Mar-2018
Category:	Documents
Upload:	trannga
View:	348 times
Download:	9 times

Standards MT November 2016 - Usage Guidelines · PDF fileStandards MT November 2016 Usage...

Documents