Category 1 Customer Payments & Cheques

7/27/2019 Category 1 Customer Payments & Cheques

1/478

SWIFTStandards

Category 1

Customer Payments & Cheques

November 2002 Standards Release

September 2002 edition


2/478

Legal Notices

IMPORTANT NOTE: You may install and use this publication only if you have entered into the relevant licence agreementwith SWIFT. Please refer to such licence agreement to determine what you may or may no t do with it. Note however that inthe case of a 'Single User Licence', this publication must be installed on a standalone machine for access by one person atany one time, and references to "organisation" in these notices are to the ordering customer (BIC 8). In the case of a 'Server Licence', this publication can also be installed on a server for access within the organisation of the ordering customer (BIC8), and references to "organisation" are then to all those SWIFT Users belonging to the same group as the ordering customer (BIC8) for traffic aggregation purposes.

Copyright

Copyright S.W.I.F.T. SCRL ("SWIFT"), avenue Adle 1, B-1310 La Hulpe, Belgium, 2002. All rights reserved. No part of this publication may be copied or reproduced, stored in a retrieval system, sold or transferred to any person, in whole or in

part, in any manner or form or on any media, without the prior written permission of SWIFT. The recipient is, however,authorised to copy or reproduce this publication within its own organisation as may be reasonably necessary for the purposefor which it is supplied. Any such copy or reproduction will include the following: acknowledgement of the source,reference and date of publication, and all notices set out on this page.

Confidentiality

This publication may contain proprietary and/or confidential information of SWIFT and/or its suppliers. The recipientshould not disclose this publication outside its organisation without the prior written permission of SWIFT.

Disclaimer

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

Trademarks and Patents

SWIFT, S.W.I.F.T., the SWIFT logo, Sibos, Accord and SWIFT-derived product and service names - such as but not limitedto SWIFTNet and SWIFTAlliance - are trademarks of S.W.I.F.T. SCRL. SWIFT is the trading name of S.W.I.F.T. SCRL. Allother product or company names that may be mentioned in this publication are trademarks or registered trademarks of their respective owners. Patent pending: SWIFTNet - TrustAct - e-paymentsPlus.

September 2002 edition


3/478

Table of Contents

November 2002 Standards Release iii

Table of Contents

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

Category 1 Message Types.................................................................................................... 5

Euro Impact on Category 1 Message Standards................................................................. 9

MT 100 Customer Transfer ................................................................................................. 20

MT 101 Request for Transfer .............................................................................................. 67

MT 102 Multiple Customer Credit Transfer ..................................................................... 115

MT 102+ Multiple Customer Credit Transfer ................................................................... 164

MT 103 Single Customer Credit Transfer ......................................................................... 206

MT 103+ Single Customer Credit Transfer ...................................................................... 297

MT 104 Direct Debit and Request for Debit Transfer Message ....................................... 360

MT 105 EDIFACT Envelope ............................................................................................ 396

MT 106 EDIFACT Envelope ............................................................................................ 400

MT 107 General Direct Debit Message ............................................................................. 404

MT 110 Advice of Cheque(s) ............................................................................................ 435

MT 111 Request for Stop Payment of a Cheque ............................................................... 448

MT 112 Status of a Request for Stop Payment of a Cheque ............................................. 456

MT 121 Multiple Interbank Funds Transfer (EDIFACT FINPAY Message) ................... 464

MT 190 Advice of Charges, Interest and Other Adjustments ........................................... 466

MT 191 Request for Payment of Charges, Interest and Other Expenses .......................... 467

MT 192 Request for Cancellation ..................................................................................... 468

MT 195 Queries ................................................................................................................. 469

MT 196 Answers ............................................................................................................... 470

MT 198 Proprietary Message ............................................................................................ 471

MT 199 Free Format Message .......................................................................................... 472


4/478

Category 1 - Customer Payments & Cheques

iv November 2002 Standards Release

Glossary of Terms ............................................................................................................. 473


5/478

Introduction

November 2002 Standards Release 1

Introduction

OverviewCategory 1 consists of the following types of customer related payment messages:

customer credit transfers

customer debit transfers

cheque payments

The messages in this category deal with payments, or information about payments, in which theordering party or the beneficiary, or both, are not financial institutions.

ChangesThis volume incorporates the following main changes and additions to Category 1 Customer Payments & Cheques as noted in the Standards Release Guide (SRG) 2002 and the relevantupdates to the SRG 2002:

possibility to include EUROSTAT codes in field 26T of MT 102, MT 102+, MT 103 and MT103+,

BEIs are expanded to include Treasury ETC Service Provider (TESP),

amendment of the Italian Clearing Code,

addition of the South African Clearing Code in Option A in field 57a of MT 100, MT 102,MT103,

update of ERI information,

update of examples.

IMPORTANT

This volume contains information effective as of the November 2002 Standards Release.

Therefore the September 2001 edition of the User Handbook Standards volumes remainseffective until November 2002.

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


6/478


2 November 2002 Standards Release

Message Type Scope

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

Message Type Format Specifications

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

MT nnn (Message Type Name)

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

Status indicates if the field is

- M Mandatory

- O Optional

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

Tag is the field identification.

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

Status Tag Field Name Content/Options No.

M 20 Transaction Reference Number 16x 1

M 21 Related Reference 16x 2

Mandatory Sequence A (Sequence Name)

M 25 Account Identification 35x 3

M 32a Value Date, Currency Code, Amount C or D 4

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

O 52a Ordering Institution A or D 5

M 71B Details of Charges 6*35x 6

O 72 Sender to Receiver Information 6*35x 7

-----|

M = Mandatory O = Optional


7/478

Introduction


Content/Options provides permitted field length and characteristics. For informationconcerning field structure, notation and character restrictions, please see Standards GeneralInformation.

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

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

MT Network Validated Rules

Network validated rules are validated on the network, ie, rules for which an error code isdefined. Rules specified in this section affect more than one field in the message, placing acondition on one of the fields specified. They are identified as Cn , or conditional rules.

MT Usage Rules

Usage rules are not validated on the network, ie, rules for which no error code is defined, but arenevertheless mandatory for the correct usage of the message. Rules specified in this section

affect more than one field in the message, or more than one SWIFT message.

MT Guidelines

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

MT Field Specifications

The rules for the use of each field in the message are specified in this section. Each field isidentified by its index number (as shown in the No. column of the MT Format Specifications),field tag and detailed field name, followed by a description of the field, which may containsome or all of the following:

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

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

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

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

NETWORK VALIDATED RULES specifies rules that are validated on the network, ie,rules for which an error code is defined. Generally, rules specified in this section affect only


8/478



the field in which they appear. In some cases, rules which are validated at the message level,ie, rules which affect more than one field, are repeated in this section. This is the case whenthe rule does not affect the presence of the field, but information within several fields, eg, acurrency which must be the same for more than one field in the message.

USAGE RULES specifies rules that are not validated on the network, ie, rules for which noerror code is defined, but are nevertheless mandatory for the correct usage of the field. Rulesspecified in this section affect only the field in which they appear.

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

MT MappingMT mapping provides an explanation of how to map the fields of the message into another SWIFT message, either of the same or a different message type.

MT Example

Examples are provided to illustrate the correct use of a message. Examples always include the

following information:

Narrative provides a brief description of a transaction

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

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


9/478

Category 1 Message Types



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

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

Information volume.

MT MT Name Purpose Authen. Max.Length

MUG VDO

100 Customer Transfer

Instructs a fundstransfer

Y 2,000 N Y

101 Request For Transfer

Requests to debit acustomer's accountheld at another institution

Y 10,000 Y Y

102102+

MultipleCustomer CreditTransfer

Conveys multiple paymentinstructions

between financialinstitutions

Y 10,000 Y Y

103103+

Single Customer Credit Transfer


Y 10,000 N Y

103 REMIT Single Customer Credit Transfer


Y 10,000 Y Y

104 Direct Debit andRequest for

Debit Transfer

Conveys directdebit instructions

or requests for direct debits

between financialinstitutions

Y 10,000 Y Y

105 EDIFACTEnvelope

An envelope whichconveys a 2k EDIFACT message

Y 2,000 Y N


10/478



106 EDIFACTEnvelope

An envelope whichconveys a 10k EDIFACT message

Y 10,000 Y N

107 General DirectDebit

To order the debitof a debtorsaccount and tocollect payment

from this account

Y 10,000 Y Y

110 Advice of Cheque

Advises or confirms theissuance of acheque to thedrawee bank

Y 2,000 N Y

111 Request for Stop

Payment of aCheque

Requests the

drawee bank tostop payment of acheque

Y 2,000 N Y

112 Status of aRequest for StopPayment of aCheque

Indicates action(s)taken in attemptingto stop payment of a cheque

Y 2,000 N Y

121 MultipleInterbank FundsTransfer

Contains anEDIFACT FINPAYmessage

Y 10,000 Y N

190 Advice of Charges,Interest andOther Adjustments

Advises an accountowner of charges,interest and other adjustments

Y 2,000 N N

191 Request for Payment of Charges,Interest andOther Expenses

Requests paymentof charges, interestor other expenses

Y 2,000 N N


MUG VDO


11/478



Note:

A MUG, for the purposes of this book, is a group of users who have voluntarily agreed to support the specified message type and have registered with SWIFT to send or receive the specified message type. These messages are indicated in the preceding table in the column

MUG.

192 Request for Cancellation

Requests theReceiver toconsider cancellation of themessage identifiedin the request

Y 2,000 N N

195 Queries Requests

informationrelating to a

previous messageor amendment to a

previous message

Y 2,000 N N

196 Answers Responds to anMT 195 Query or MT 192 Request

for Cancellation or other messagewhere no specificmessage type has

been provided for aresponse

Y 2,000 N N

198 ProprietaryMessage

Contains formatsdefined and agreedto between usersand for thosemessages not yetlive

Y 10,000 N N

199 Free FormatMessage

Containsinformation for which no other message type has

been defined

Y 2,000 N N


MUG VDO


12/478



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

the destination of the requesting institution, ie, the 8 character BIC the message type or specific usage of the specified message type

the contact name and telephone number within the institution

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

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

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

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

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


13/478

Euro Impact on Category 1 Message Standards



Deletion of the National Currency Denomination (NCD) CurrencyCodes

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

For certain message types, when an NCD is used as the currency of settlement, SWIFT validates

to ensure the value date is before 1 January 2002, when these currencies stopped to be legaltender. This validation has been introduced on the network in July 2001.

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

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

ERI Content

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

original currency,

original amount,

transaction charges.

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

ERI may be specified in free-text field 72 preceded by a code. As of Standards Release 2001,

the use of ERI was extended to non-European currencies, and beyond the transition period of 3years.

ERI Usage Guidelines and Rules, Relevant for Category 1

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

Network Validated Rules,


14/478



Usage Rules,

Usage Guidelines.

Network validated rules must be complied with and are validated by the network. Usage rulesalso must be complied with, although they are not validated by the network. Usage guidelinesare recommendations on how to specify ERI.

Network Validated Rules

If a network validated rule mandates the presence of an exchange rate field where both thetransaction amount and the original ordered amount are quoted, (eg, field 36 in the MTs 101,

102, 103, 104, 107) this rule remains effective. In the case of euro-related currencies, theexchange rate field must specify the value of the fixed euro conversion rate.

Usage Rules

1. ERI may be used only when the message does not have a specific existing field to specifythe information.

If specific fields have been defined in a message to contain the original currency and

amount, these fields, and not ERI, should be used to indicate the original currency andamount. For example, category 1 messages, like the MT 103, contain specific fields for this

purpose.

2. As with all other information occurring in field 72, ERI is for information purposes only.

In the case of a discrepancy between ERI and the settlement amount specified in themessage, the information in the settlement amount prevails.

Usage Guidelines1. If no specific fields are available to specify the original currency and amount, ERI may be

used in any message type containing a free text field 72, ie, the use of ERI is not restricted tospecific message types.

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

exhaustive.2. If ERI is specified in field 72, it should appear on the first line whenever possible. Whatever

line is used, the ERI should always appear on the first position of that line.

3. Where the settlement amount is part of a repetitive sequence which does not contain a freetext field, the message should be used as a single transaction message, ie, one messageshould be used per transaction.

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


15/478



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

ERI Structure

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

are likely to contain ERI

contain a special field for original amount

are to be validated against a specified value date

FORMAT Field 72 6*35x

DEFINITION In addition to previously defined Sender to Receiver information, or other narrative information, field 72 may include euro-related information (ERI) for

information purposes. ERI indicates currency conversion details, related to theconversion of the original currency into a settlement currency, found in field 72.It is recommended that ERI be structured using codes.

CODES The following codes must be used:

/OCMT/ 3!a15d/ O Original currency and amount.If no charges are specified then the originalcurrency and amount will be the equivalent of

the transaction amount specified in themessage.

/CHGS/ 3!a15d/ O Currency and amount of the transactioncharges.When the BEN option is used in payments andrelated messages, ie, all transaction chargesare to be paid by the beneficiary customer, thecharges amount has been deducted from the

original amount to obtain the settlementamount specified in the message.

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

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


16/478



Messages Likely to Contain ERI

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

field 72. Message types that already contain a field to specify an original currency and amount,are not included here.

If there are business requirements to specify ERI in other message types, these should besimilarly specified in field 72 as explained in the section entitled ERI Structure.

Therefore, this list is not exhaustive.

Messages Containing a Special Field for Instructed AmountThe following lists message types that already have a special field for specifying an instructedamount to be transferred. This list is not exhaustive as there may be other messages with specialfields specifying an instructed amount.

MT MT Name Settlement AmountField

Repetitive/Non-Repetitive

ERIField

Repetitive/Non-

Repetitive

100 Customer Transfer

32A Value Date,Currency Code,Amount

NR 72 NR

MT MT Name SettlementAmount Field

Repetitive/Non-

Repetitive

InstructedAmount

Field

Repetitive/Non-

Repetitive

101 Request for Transfer 32B R 33B R

102 Multiple Customer Credit Transfer

32B R 33B R

102+ Multiple Customer Credit Transfer

32B R 33B R

103 Single Customer Credit Transfer

32A NR 33B NR

103+ Single Customer Credit Transfer

32A NR 33B NR


17/478



Messages with Value Date Validation

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

This validation is performed since 30 July 2001.

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

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

PTE and XEU.

103REMIT

Single Customer Credit Transfer

32A NR 33B NR

104 Direct Debit andRequest for Transfer

32B R 33B R

107 General Direct Debit 32B R 33B R

MT MT Name NCD Amount FieldValue Date

Field

100 Customer Transfer 32A 32A

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

30 in Seq A

102102+

Multiple Customer CreditTransfer

32A in Seq C 32A in Seq C

MT MT Name SettlementAmount Field

Repetitive/Non-

Repetitive

InstructedAmount

Field

Repetitive/Non-

Repetitive


18/478



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

General ERI Validation Rules

Codes and format:

/OCMT/3!a15d/

/CHGS/3!a15d/

where:

the currency component 3!a must be a valid ISO currency code T52

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

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

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

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

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

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

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

:72:/OCMT/EUR123/(CrLf)

103 CORE103+

103 REMIT

Single Customer Credit Transfer 32A 32A

104104 RFDD

Direct Debit and Request for Debit Transfer Message

32B (each occurrence) 30 in Seq A

107 General Direct Debit Message 32B in Seq C 30 in Seq A

MT MT Name NCD Amount FieldValue Date

Field


19/478



Note: The amount component must be followed by a slash character, / T31. In the followingexample the amount component is invalid. The message is NAKed

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

Messages and fields impacted

The ERI validation will be performed in fields:

72 Structured Format and 72 Narrative, of all messages except the MTs 104, 192, 195, 196and 199

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

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

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

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

No ERI validation hierarchy between the fields

Note, if the same Field Specification is re-used in the message, the ERI validation will be performed. This is usually the case where a field is defined in a loop, ie, a repetitive block of fields or sequence.

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

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

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

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

Sequence of codes is required

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

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

Example 1 (structured field 72):

:72:/RCB/BANKCCCY/OCMT/EUR12345,/(CrLf)


20/478



/CHGS/EUR100,/xxxxx(CrLf)

Example 2 (free format field 72):

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

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


:72:xxxxxxxxxx(CrLf)

//xxxxxxxxxx(CrLf)/OCMT/EUR10000,/xxxxx(CrLf)//xxxxxxxxxx(CrLf)/CHGS/EUR50,/(CrLf)//xxxxxxxxxx(CrLf)

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

In the following examples only OCMT is validated. The message is not NAKed:Example 4 (structured field 72):

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


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

In the following example, OCMT and the second occurrence of CHGS are validated. Themessage is not NAKed:

Example 6 (structured field 72):

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

E I C 1 M S d d


21/478



Details of the ERI Validation Implementation

Field 72 (Structured format)

The system will perform the following validation:

1. Maximum 6 lines, maximum 35 characters per line ( character set)

2. First line as , per the format defined here above

3. Second through sixth line, if present, defined as: OR

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

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

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

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

6. Scan for /OCMT/

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

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

c. If /OCMT/ is present only once, then validate the format

If format is valid, then go to point 7

If format is not valid, then NAK the message with the corresponding error code andterminate the validation

FORMAT first line

[(CrLf)(or // 33x)]

optionally, 2d through 6th line

where isdefined as:

//32x or

//31x or

//30x or

//29x or

//28x or

//27x or

//26x or

//25x

Category 1 Customer Payments & Cheques


22/478



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

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

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

c. If /CHGS/ is present only once, then validate the format

If format is valid, then go to next field validation


Field 72 (Narrative)

The system will perform the following validation:

1. Maximum 6 lines, maximum 35 characters per line ( character set)

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

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

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

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

4. Scan for /OCMT/

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

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

c. If /OCMT/ is present only once, then validate the format

If format is valid, then go to point 5


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

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

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

c. If /CHGS/ is present only once, then validate the format

If format is valid, then go to next field validation

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



23/478






24/478

g y y q


MT 100 Customer Transfer

Note: the MT 100 Customer Transfer will be removed from the SWIFT network with StandardsRelease 2003. All users should migrate to the MT 103 Single Customer Credit Transfer

before the removal of the MT 100.

MT 100 ScopeThis message type is sent by or on behalf of the financial institution of the ordering customer,

directly or through (a) correspondent(s), to the financial institution of the beneficiary customer.It is used to convey a funds transfer instruction in which the ordering customer or the

beneficiary customer, or both, are non-financial institutions from the perspective of the Sender.

This message may only be used for clean payment instructions. It must not be used to advise theremitting bank of a payment for a clean, eg, cheque, collection.

MT 100 Format SpecificationsMT 100 Customer Transfer


M 20 Transaction Reference Number 16x 1

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

M 50 Ordering Customer 4*35x 3

O 52a Ordering Institution A or D 4

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

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

O 56a Intermediary A or D 7

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

M 59 Beneficiary Customer [/34x]4*35x

9

O 70 Details of Payment 4*35x 10

MT 100


25/478


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

C2 The code /RCB/ may only be used in field 72 if both field 53a and field 54a are present inthe message (Error code(s): C74).

MT 100 Usage Rules At a minimum, either field 50 Ordering Customer or field 59 Beneficiary Customer must be

a non-financial institution. If the Sender and the Receiver have a single direct account relationship, in the currency of

the transfer, and this account is to be used for reimbursement, fields 53a and/or 54a must notappear in the message. In all other cases, the relevant reimbursement details will be specifiedin fields 53a and/or 54a in line with the field specifications.

Where the Receiver does not service an account for the beneficiary customer and there is nofield 57a Account With Institution or alternative instructions in field 72, the Receiver shall

effect payment in an appropriate manner of its choice.

MT 100 Field Specifications

1. Field 20: Transaction Reference Number

FORMAT

PRESENCE

Mandatory

DEFINITION

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

O 71A Details of Charges 3!a 11

O 72 Sender to Receiver Information 6*35x 12

M = Mandatory O = Optional

16x




26/478


NETWORK VALIDATED RULES

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

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

FORMAT

PRESENCE

MandatoryDEFINITION

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


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

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

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

3. Field 50: Ordering Customer

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the originator of the transfer.

USAGE RULES

Where the originator is also the Sender of the message, this field must contain the name of theSender.

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

4*35x (Name & Address)

MT 100


27/478


4. Field 52a: Ordering Institution

FORMAT

PRESENCE

Optional

DEFINITIONThis field specifies the financial institution of the ordering customer, when different from theSender.


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

USAGE RULESThe optional Party Identifier must not be present.

Option A is the preferred option.

5. Field 53a: Sender's Correspondent

FORMAT

PRESENCEOptional

DEFINITION

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

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

(Party Identifier)(BIC)

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

(Party Identifier)(Name & Address)

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


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

(Party Identifier)(Location)

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




28/478




USAGE RULES

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

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

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

present.

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

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

paid by its branch in field 53a.

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

When field 53B is used to specify a branch city name, it must always be a branch of the Sender.The use and interpretation of fields 53a and 54a is, in all cases, dictated by the currency of thetransaction and the correspondent relationship between the Sender and the Receiver relative tothat currency.

6. Field 54a: Receiver's Correspondent

FORMAT

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


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


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


MT 100


29/478


PRESENCE

Optional

DEFINITIONThis field specifies the branch of the Receiver or another financial institution at which the fundswill be made available to the Receiver.



USAGE RULESWhere funds will be made available to the Receiver at its branch through a financial institutionother than that indicated in field 53a, this financial institution, ie, intermediary reimbursementinstitution, shall be specified in field 54a and field 72 shall contain the ISO Bank Identifier Code of the Receiver's branch, preceded by /RCB/.

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

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

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

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

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

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

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

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



30/478


7. Field 56a: Intermediary

FORMAT

PRESENCE

Optional

DEFINITIONThis field specifies a party between the Receiver and the account with institution through whichthe transaction must pass.

CODES

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

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

with option A:

CODES

with option D:

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


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


AT 5!n Austrian Bankleitzahl

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

BL 8!n German Bankleitzahl

CC 9!n Canadian Payments Association Payment Routing Number

ES 8..9n Spanish Domestic Interbanking CodeFW without 9 digit code Pay by Fedwire

GR 7!n HEBIC (Hellenic Bank Identification Code)

HK 3!n Bank Code of Hong Kong

IE 6!n Irish National Clearing Code (NSC)

IN 11!c Indian Financial System Code (IFSC)

IT 10!n Italian Domestic Identification Code

NZ 6!n New Zealand National Clearing Code

PT 8!n Portuguese National Clearing Code

RT Pay by Real Time Gross Settlement

SC 6!n UK Domestic Sort Code

MT 100


31/478




USAGE RULES

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

When it is necessary that an incoming SWIFT payment be made to the party in this field viaFedwire, US banks require that the code //FW appears in the optional Party Identifier of field56a or 57a.

When it is necessary that an incoming SWIFT payment be made to the intermediary or theaccount with institution via real-time gross settlement (RTGS), the code //RT should appear inthe optional Party Identifier of field 56a or 57a.





CH 6!n CHIPS Universal Identifier

CP 4!n CHIPS Participant Identifier

ES 8..9n Spanish Domestic Interbanking Code

FW 9!n Fedwire Routing Number

GR 7!n HEBIC (Hellenic Bank Identification Code)HK 3!n Bank Code of Hong Kong





PT 8!n Portuguese National Clearing CodeRT Pay by Real Time Gross Settlement

RU 9!n Russian Central Bank Identification Code


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

SW 6!n Swiss Clearing Code (SIC code)



32/478


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


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

EXAMPLE

:56A://FWCHASUS33

8. Field 57a: Account With Institution

FORMAT

PRESENCE

Conditional (C1)

DEFINITION

This field specifies the financial institution - when other than the Receiver - which services theaccount for the beneficiary customer. This is applicable even if field 59 contains an IBAN.

CODES

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

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

with option A:

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


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


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







FW without 9 digit code Pay by Fedwire

MT 100


33/478


CODES

with option D:

GR 7!n HEBIC (Hellenic Bank Identification Code)

HK 3!n Bank Code of Hong Kong

IE 6!n Irish National Clearing Code (NSC)IN 11!c Indian Financial System Code (IFSC)



PT 8!n Portuguese National Clearing Code

RT Pay by Real Time Gross Settlement


ZA 6!n South African National Clearing Code






CP 4!n CHIPS Participant Identifier


FW 9!n Fedwire Routing Number

GR 7!n HEBIC (Hellenic Bank Identification Code)HK 3!n Bank Code of Hong Kong





PT 8!n Portuguese National Clearing CodeRT Pay by Real Time Gross Settlement

RU 9!n Russian Central Bank Identification Code


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

SW 6!n Swiss Clearing Code (SIC code)

ZA 6!n South African National Clearing Code



34/478




USAGE RULES

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

When it is necessary that an incoming SWIFT payment be made to the party in this field viaFedwire, US banks require that the code //FW appears in the optional Party Identifier of field

56a or 57a.When it is necessary that an incoming SWIFT payment be made to the intermediary or theaccount with institution via real-time gross settlement (RTGS), the code //RT should appear inthe optional Party Identifier of field 56a or 57a.

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


Option B is to be used to identify a branch of the Receiver when that branch has neither a BIC or a clearing code or when its clearing code is meaningless for the Receiver.

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

9. Field 59: Beneficiary Customer

FORMAT

PRESENCE

Mandatory

DEFINITION

This field specifies the beneficiary customer.

CODES

The following code may be used in Account preceded by a double slash (//):

[/34x]4*35x

(Account)(Name & Address)


MT 100


35/478


USAGE RULES

An account number in this field must always designate the account number of the beneficiarycustomer with its account servicing institution, ie, the Receiver or the party in field 57a.

10. Field 70: Details of Payment

FORMAT

PRESENCE

Optional

DEFINITION

This field contains transaction details for the beneficiary customer.

CODES

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

USAGE RULES

For national clearing purposes, the Sender must check with the Receiver regarding lengthrestrictions of field 70.

The information specified in this field is intended only for the beneficiary customer, ie, thisinformation only needs to be conveyed by the Receiver.

Multiple references can be used, if separated with a double slash, //. Code must not be repeated between two references of the same kind.

When /RFB/ is used, it must be placed at the beginning of a line. It must be followed by areference for the beneficiary of 16 characters maximum. This must be the only information onthe first line of the field.

11. Field 71A: Details of Charges

FORMAT

PRESENCE

Optional

4*35x (Narrative)

INV Invoice (followed by the date, reference and details of the invoice).RFB Reference for the beneficiary customer (followed by up to 16 characters).

ROC Ordering customer's reference.

Option A 3!a (Code)



36/478


DEFINITION

This field specifies by which party charges are to be borne.

CODESOne of the following codes must be used (Error code(s): T08):

USAGE RULES

The absence of this field implies that charges, if any, are to be borne by the beneficiarycustomer.

12. Field 72: Sender to Receiver Information

FORMAT

The following line formats must be used:

PRESENCE

Optional

DEFINITION

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

CODES

Codes must be placed between slashes (/):

1. Parties: Where it is necessary to identify parties involved in the transaction which have not been identified in other fields:

BEN Charges are to be borne by the beneficiary customer.

OUR Charges are to be borne by the Sender.

6*35x (Narrative - Structured Format)

Line 1 /8c/[additional information]

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

MT 100


37/478


CODES

2. Method of Payment

CODES

3. Method of Advice

The codes REJT/RETN may be used in this field. If either of the codes is used in the first position of the first line, placed between slashes (/), it is mandatory to follow the GenericPayment Reject Mechanism described in Standards Usage Guidelines.

USAGE RULES

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

ACC Instructions following are for the account with institution.

INS The instructing institution (if other than the ordering institution) which instructed the

Sender to execute the transaction. The use of an ISO Bank Identifier Code is stronglyrecommended. A maximum of two lines may be used.

RCB Receiver's correspondent.Where funds will be made available to the Receiver at its branch through a financialinstitution other than that indicated in field 53a, this financial institution, ie, intermediaryreimbursement institution, shall be specified in field 54a and field 72 shall contain the ISOBank Identifier Code of the Receiver's branch, preceded by /RCB/.

BENONLY Payment to be made to the beneficiary customer only, eg, pension payments.

CHEQUE Pay only by cheque.

CORPTRAD The payment is made in settlement of a trade, eg, foreign exchange deal, securitiestransaction.

HOLD Identification instructions may follow, beneficiary customer will call; pay uponidentification.

INTRACOM The payment is an intra-company payment, ie, a payment between two companies belonging in the same group.

PHON Please advise account with institution by phone.

PHONBEN Please advise/contact beneficiary/claimant by phone.

PHONIBK Please advise the intermediary by phone.

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

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

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



38/478


Each item for which a code exists must start with that code and may be completed withadditional information.

Each code used must be between slashes and appear at the beginning of a line. It may befollowed by additional narrative text.

Narrative text relating to a preceding code, which is continued on the next line(s), must startwith a double slash //, and, if used, must begin on a new line. Narrative text should preferably

be the last information in this field.

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

It is strongly recommended to use the standard codes proposed above. However, where bilateralagreements covering the use of codes in this field are in effect, the code must conform to thestructure of this field.

This field may include ERI to transport dual currencies, as specified in the chapter entitledEuro-Impact on Category 1 Message Standards.

In order to comply with the EC-directive on cross border credit transfers, the optional code wordEXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is

placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

EXAMPLE

:72:/INS/ABNANL2A

MT 100 Examples

Example 1 Customer Transfer

Narrative

Biodata G.m.b.H. orders UBS, Zrich, to pay euro 1,958.47 to ABN Amro Bank, Amsterdam,for the account of H.F. Janssen.

MT 100


39/478


Information Flow

SWIFT Message

Explanation Format

Sender UBSWCHZH80A

Message type 100

Receiver ABNANL2A

Message text

Transaction reference number :20:494931/DEV

Value date/currency code/amount :32A:020527EUR1958,47

Ordering customer :50:BIODATA GMBHZURICH

59

50

D 0 0 1 0 0 0 1

UBSZurich

Biodata GmbHZurich

ABN Amro BankAmsterdam

Sender

Receiver

H.F. JanssenAmsterdam

Beneficiary Customer

Ordering Customer

MT 100

MT



40/478


Example 2 Customer transfer specifying account for reimbursement

Narrative

Biodata G.m.b.H. orders UBS, Zrich, to pay euro 1,958.47 to ABN Amro Bank, Amsterdam,for the account of H.F. Janssen, in payment of invoice number 18042 dated 15 April 2002.

As there is more than one account relationship in the currency of the transfer between theSender and Receiver, UBS specifies that account number 219-4290555-81 should be used for reimbursement.

Beneficiary customer :59:H.F. JANSSENLEDEBOERSTRAAT 27AMSTERDAM

End of message text/trailer

Note:

No reimbursement party has been indicated in the above message. The direct account relationship, inthe currency of the transfer, between the Sender and Receiver will be used.

Explanation Format


41/478



42/478


Example 3 Customer transfer with ordering and account with institutions

Narrative

Bitmap G.m.b.H. orders Adler und Co, Zrich, to pay, value 27 May 2002, euro 850 into K.Desmid's account number 729615-941 with ABN Amro Bank, Zeist. The payment is for April2002 expenses.

Adler und Co, asks UBS, Zrich, to make the payment, which in turn, pays through ABN AmroBank's Amsterdam office.

Sender's correspondent (1) :53B:/219-4290555-81

Beneficiary customer :59:H.F. JANSSENLEDEBOERSTRAAT 27AMSTERDAM

Details of payment (2) :70:/INV/18042-020415


Note: (1) Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used

for reimbursement in the transfer.(2) As the reference for the beneficiary is an invoice number, the code /INV/ is used, followed by theinvoice number.

Explanation Format

MT 100

Information Flow


43/478


Information Flow

59

50

52a

57a

D 0 0 1 0 0 0 3

UBSZurich

Bitmap GmbHZurich


Sender

Receiver

K. DesmidZeist


Ordering Customer

Adler und CoZurich

Ordering Institution

ABN Amro BankZeist

Account With Institution

(MT 100)

MT 100

MT


SWIFT Message


44/478


SW essage

Example 4 Customer transfer with intermediary

Narrative

Value March 18, 2002, Mayne Bookbinders, Inc. of Boston, Massachusetts, requestsBankBoston, to pay pounds sterling 6,500 to Mayne Publishers, Chichester, which has itsaccount (number 3902993) at Barclays Bank, plc, Chichester (UK Domestic Sort Code202062).

BankBoston instructs its correspondent, Midland Bank, London to make the payment under reference PO39887221. The payment instruction will be routed through Barclays Bank,London.

Explanation Format

Sender UBSWCHZH80A

Message Type 100

Receiver ABNANL2A

Message text

Transaction reference number :20:494938/DEVValue date/currency code/amount :32A:020527EUR850,

Ordering customer :50:BITMAP GMBHZURICH

Ordering institution :52D:ADLER UND CO.ZURICH

Account with institution :57B:ZEIST

Beneficiary customer :59:/729615-941K. DESMID

Details of payment :70:APRIL 2002 EXPENSES

End of Message Text/Trailer

MT 100

Information Flow


45/478


59

50

56a

D 0 0 1 0 0 0 4

BankBostonBoston

Mayne Bookbinders, Inc.Boston

Midland BankLondon

Sender

Receiver

Mayne PublishersChichester


Ordering Customer

Barclays BankLondon

Intermediary

57aBarclays Bank

Chichester


MT 100

MT


SWIFT Message


46/478


Example 5 Customer transfer with reimbursement through several institutions

Narrative

Value May 27, 2002, Franz Holzapfel G.m.b.H. orders Bank Austria, Vienna, to pay US dollars1,121.50 to C. Klein, Bloemengracht 15, Amsterdam, whose account number 723491 is withABN Amro Bank, Amsterdam. The beneficiary is to be notified by phone at 20.527.19.60.

Bank Austria uses reference 394882.

This transfer may be sent via SWIFT using one of the following methods:

1. Sent to the party closest to the beneficiary, through several reimbursement institutions

2. Sent to the next party in the transfer.

Note: The alternative selected is dependent on correspondent relationships and financial practice in the countries involved.

Explanation Format

Sender FNBBUS33

Message Type 100

Receiver MIDLGB22

Message text

Transaction reference number :20:PO39887221Value date/currency code/amount :32A:020318GBP6500,

Ordering customer :50:MAYNE BOOKBINDERS, INCBOSTON

Intermediary :56A:BARCGB22

Account with institution :57D://SC202062

BARCLAYS BANKCHICHESTER

Beneficiary customer :59:/3902993MAYNE PUBLISHERS


MT 100

Method 1 SWIFT MT 100 to the party closest to the beneficiary


47/478


Bank Austria sends the following messages:

A. A customer transfer to ABN Amro Bank, Amsterdam.B. A cover message for the US dollars payment, which is provided through Chase Manhattan

Bank, New York, to ABN Amro Bank, New York.

Message A SWIFT MT 100 Customer Transfer

Information Flow

59

50

53a

D 0 0 1 0 0 0 5

Bank AustriaVienna

Franz Holzapfel GmbHVienna

ABN Amro BankAmsterdam(Field 58a of MT 202)

Sender

Receiver

C. KleinAmsterdam


Ordering Customer

Chase Manhattan BankNew York(Receiver of MT 202)

Sender's Correspondent

MT 100

54aABN Amro BankNew York(Field 57a of MT 202)

Receiver's Correspondent

(MT 202)

(MT 910/950)

MT


SWIFT Message


48/478


Explanation Format

Sender BKAUATWW

Message Type 100

Receiver ABNANL2A

Message text

Transaction reference number :20:394882Value date/currency code/amount :32A:020527USD1121,50

Ordering customer :50:FRANZ HOLZAPFEL GMBHVIENNA

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

Receiver's correspondent (2) :54A:ABNAUS33

Beneficiary customer :59:/723491C. KLEINBLOEMENGRACHT 15AMSTERDAM

Sender to receiver information :72:/PHONBEN/20.527.19.60


Note:

(1) Field 53A indicates the institution which is to provide the funds to the Receiver on behalf of theSender.(2) Field 54A is the receiver's correspondent the institution which will receive the funds on behalf of the Receiver.

MT 100

Message B SWIFT MT 202 (Cover Message)


49/478


Information Flow

SWIFT Message

Explanation Format

Sender BKAUATWW

Message Type 202

Receiver CHASUS33

Message text

Transaction reference number :20:203998988

Related reference (1) :21:394882

58a

57a

D 0 0 1 0 0 0 6

Bank AustriaVienna

Chase Manhattan BankNew York(Field 53a in MT 100)

Sender

Receiver

(MT 100)

ABN Amro BankAmsterdam(Receiver of MT 100)

BeneficiaryInstitution

ABN Amro BankNew York(Field 54a in MT 100)


MT 202

MT


Explanation Format


50/478


Value date/currency code/amount :32A:020527USD1121,50

Account with institution :57A:ABNAUS33

Beneficiary institution :58A:ABNANL2A


Note:

(1) The related reference is the TRN of the corresponding customer transfer.

MT 100

Method 2 SWIFT MT 100 to the next party in the transaction


51/478



Information Flow

59

50

56a

D 0 0 1 0 0 0 7

Bank AustriaVienna


Chase Manhattan BankNew York

Sender

Receiver

(MT 100*)

(MT 100)

C. KleinAmsterdam


* Or its equivalent domestic clearing message

Ordering Customer

ABN Amro BankNew York

Intermediary

57aABN Amro BankAmsterdam


MT 100

MT


SWIFT Message


52/478


Explanation Format

Sender BKAUATWW

Message type 100

Receiver CHASUS33

Message text




Intermediary (1) :56A:ABNAUS33

Account with institution (2) :57A:ABNANL2A




Note:

(1) The intermediary, ABN Amro Bank, New York, will receive the funds from the Receiver of thismessage, Chase Manhattan Bank, New York.(2) ABN Amro Bank, Amsterdam, will receive the funds from the Intermediary, its New York office, for credit to the beneficiary's account.

MT 100

Message B 2nd SWIFT MT 100 (or its equivalent domestic clearing message)


53/478


Information Flow

59

50

52a

57a

D 0 0 1 0 0 0 8

Chase Manhattan BankNew York


ABN Amro BankNew York

Sender

Receiver

C. KleinAmsterdam


Ordering Customer

Bank AustriaVienna




(MT 100)

MT 100

MT


SWIFT Message


54/478


Example 6 Customer transfer with several reimbursement institutions

Narrative

Gian Angelo Imports, Naples, orders Banca Commerciale Italiana, Naples, to pay, value 8October 2002, US Dollars 5,443.99 to Banque Nationale de Paris, Grenoble, for accountnumber 40899-5433A of Killy S.A., Grenoble, in payment of invoice 559661.

Banca Commerciale Italiana, Milan, makes the US dollar payment through its UScorrespondent, Banca Commerciale Italiana, New York, under reference 8861198-0706.

Explanation Format

Sender CHASUS33

Message type 100

Receiver ABNAUS33

Message text




Ordering institution (1) :52A:BKAUATWW

Account with institution (2) :57A:ABNANL2A




Note:

(1) The Sender of the initial MT 100 is Bank Austria, Vienna, which is the ordering institution in all subsequent messages.(2) ABN Amro Bank, Amsterdam, will receive the funds from the Receiver of this message, its New York office, for credit to the beneficiary's account.

MT 100

Payment is to be made to Banque Nationale de Paris, Paris, in favour of Banque Nationale deParis, Grenoble, through its US correspondent, Bank of New York, New York.


55/478


This transfer may be sent via SWIFT using one of the following methods:

1. Message sent to party closest to the beneficiary, using an intermediary reimbursementinstitution.

2. Message sent through several reimbursement institutions, using an account with institution.

3. Message sent to the next party in the transaction.

Note: Although this transfer may also be sent to the next party in the transaction, this method isnot illustrated here.

The alternative selected is dependent on correspondent relationships and financial practice of the countries involved.


Method 1 Message sent to party closest to the beneficiary, using an intermediaryreimbursement institution


56/478



Information Flow

59

50

52a

54a

D 0 0 1 0 0 0 9

Banca CommercialeItaliana, Milan

Gian Angelo Imports

Naples

Banque Nationalede Paris, Grenoble(Field 58a of MT 202)

Sender

Receiver

Killy S.A.Grenoble



Ordering Customer

Bank of New York

New York(Field 56a of MT 202)

Intermediary

Reimbursement Institution MT 100

Message A

Banca CommercialeItaliana, Naples


Banca CommercialeItaliana, New York(Receiver of MT 202)

Sender's Correspondent 53a

72/RCB/

Banque Nationalede Paris, Paris(Field 57a of MT 202)


(Message B

(Message C, MT 205*)

(Message D, MT 202)

MT 202)

(MT 910/950)

MT

MT 100

SWIFT Message


57/478


Explanation Format

Sender BCITITMM

Message type 100

Receiver (1) BNPAFRPPGRE

Message text

Transaction reference number :20:8861198-0706Value date/currency code/amount :32A:021008USD5443,99

Ordering customer :50:GIAN ANGELO IMPORTSNAPLES

Ordering institution :52A:BCITITMM500

Sender's correspondent (2) :53A:BCITUS33

Intermediary reimbursement. institution (3) :54A:IRVTUS3N

Beneficiary customer :59:/40899-5433AKILLY S.A.GRENOBLE

Details of payment (4) :70:/INV/559661

Sender to receiver information (5) :72:/RCB/BNPAFRPP


Note:

(1) The message is sent to Banque Nationale de Paris, Grenoble, the financial institution which islocated closest to the beneficiary customer.(2) Banca Commerciale Italiana, New York, the Sender's correspondent, will provide the funds to theintermediary reimbursement institution, Bank of New York, N.Y.

(3) Bank of New York, New York, will receive the funds on behalf of Banque Nationale de Paris, Paris(4) As the reference for the beneficiary is an invoice number, the code /INV/ is used, followed by theinvoice number.(5) Banque Nationale de Paris, Paris, is the Receiver's correspondent.


Message B SWIFT MT 202 General Financial Institution Transfer (Cover message)


58/478


Information Flow

58a

56a

D 0 0 1 0 0 1 0

Banca Commerciale ItalianaMilan

Banca Commerciale ItalianaNew York(Field 53a of MT 100)

Sender

Receiver

(MT 205*)

(MT 202)

Banque Nationale de ParisGrenoble(Receiver of MT 100)

Beneficiary Institution


Bank of New YorkNew York(Field 54a of MT 100)

Intermediary

MT 202

57a

Banque Nationale de Paris

Paris(Field 72/RCB/ of MT 100)


MT

MT 100

SWIFT Message


59/478


Explanation Format

Sender BCITITMM

Message type 202

Receiver (1) BCITUS33

Message text


Related reference (2) :21:8861198-0706


Intermediary (3) :56A:IRVTUS3N

Account with institution (4) :57A:BNPAFRPP

Beneficiary institution :58A:BNPAFRPPGRE


Note:

(1) The message is sent to Banca Commerciale Italiana, New York, ordering transfer of the funds to Bank of New York, New York.(2) The related reference is the transaction reference number of the MT 100.(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris, in favour of

Banque Nationale de Paris, Grenoble.(4) Banque Nationale de Paris, Paris, will pay the funds to its Grenoble office, in cover of thetransaction to Killy, S.A.


Message C SWIFT MT 205 Financial Institution Transfer Execution (or itsequivalent domestic clearing message)


60/478


Information Flow

52a

57a

D 0 0 1 0 0 1 1

Banca Commerciale ItalianaNew York(Receiver of MT 202)



Sender

Receiver

(MT 202)

Banque Nationale de ParisGrenoble(Field 58a of MT 205)



Banque Nationale de ParisParis

(Field 57a of MT 202)


58a

MT 205

MT

MT 100

SWIFT Message

l


61/478


Explanation Format

Sender BCITUS33

Message type 205

Receiver (1) IRVTUS3N

Message text




Ordering institution :52A:BCITITMM

Account with institution (3) :57A:BNPAFRPP



Note:

(1) The message is sent to Bank of New York, New York.(2) The related reference is the TRN of the initial MT 100.(3) Bank of New York, New York, will pay the funds to Banque Nationale de Paris, Paris, in favour of

Banque Nationale de Paris, Grenoble.


Message D SWIFT MT 202 General Financial Institution Transfer

Information Flow


62/478


Information Flow

SWIFT Message

Explanation Format

Sender IRVTUS3N

Message Type 202

Receiver BNPAFRPP

52a

72

D 0 0 1 0 0 1 2

Bank of New YorkNew York(Receiver of MT 205)


Banque Nationale de ParisParis(Field 57a of MT 205)

Sender

Receiver

Banque Nationale de ParisGrenoble(Field 58a of MT 205)



Banca Commerciale ItalianaNew YorkInstructing Institution

MT 202

58a

MT

MT 100

Message text

Explanation Format


63/478


Transaction reference number :20:GH45952-4587



Ordering institution :52A:BCITITMM


Sender to receiver information (2) :72:/INS/BCITUS33


Note:

(1) The related reference is the TRN of the initial MT 100.(2) The instructing institution is Banca Commerciale Italiana, New York.


Method 2 Customer Transfer sent through several reimbursement institutionsusing an account with institution


64/478



Information Flow

59

50

52a

54a

D 0 0 1 0 0 1 3

Banca CommercialeItaliana, Milan

Gian Angelo ImportsNaples

Banque Nationalede Paris, Paris(Field 58a of MT 202)

Sender

Receiver

Killy S.A.Grenoble



Ordering Customer



MT 100

Message A

Banca CommercialeItaliana, Naples


Banca CommercialeItaliana, New York(Receiver of MT 202)

Sender's Correspondent 53a

57aBanque Nationale

de Paris, Grenoble

Account With

Institution

(Message B

(Message CMT 205*)

MT 202)

MT

(Message DMT 910/950)

MT 100

SWIFT Message

Explanation Format


65/478


p

Sender BCITITMM

Message Type 100

Receiver (1) BNPAFRPP

Message text

Transaction reference number :20:8861198-0706


Ordering customer :50:GIAN ANGELO IMPORTSNAPLES

Ordering institution :52A:BCITITMM500

Sender's correspondent (2) :53A:BCITUS33

Receiver's correspondent (3) :54A:IRVTUS3N

Account with institution :57A:BNPAFRPPGRE

Beneficiary customer :59:/40899-5433KILLY S.AGRENOBLE

Details of payment(4) :70:/INV/559661


Note:

(1) The message is sent to Banque Nationale de Paris, Paris, the financial institution which will providethe funds to the account with institution.(2) Banca Commerciale Italiana, New York, will provide the funds to the Receiver's correspondent,

Bank of New York, New York.

(3) Bank of New York, New York, the Receiver's correspondent, will receive the funds on behalf of Banque Nationale de Paris, Paris.(4) As the reference for the beneficiary is an invoice number, the code /INV/ is used, followed by theinvoice number.


Message B SWIFT MT 202 General Financial Institution Transfer (Cover message)


66/478


Information Flow

SWIFT Message

Explanation Format

Sender BCITITMM

Message Type 202

Receiver (1) BCITUS33

Message text

58a

57a

D 0 0 1 0 0 1 4


Banca Commerciale ItalianaNew York(Field 53a in MT 100)

Sender

Receiver

(MT 205*)

(MT 910/950)

Banque Nationale de ParisParis(Receiver of MT 100)



Bank of New YorkNew York(Field 54a in MT 100)


MT 202

MT

MT 100


Explanation Format

7/27/2019 Category 1

Documents

Category 1 Customer Payments & Cheques