SWIFTStandards

Category 9 Cash Management & Customer Status

May 2005 Standards Release

March 2005 edition

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

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

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

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

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

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

Table of Contents

Table of Contents
Introduction ........................................................................................................................... 1 Category 9 Message Types.................................................................................................... 5 Euro – Impact on Category 9 Message Standards............................................................... 10 MT 900 Confirmation of Debit ........................................................................................... 24 MT 910 Confirmation of Credit .......................................................................................... 31 MT 920 Request Message ................................................................................................... 40 MT 935 Rate Change Advice .............................................................................................. 46 MT 940 Customer Statement Message ................................................................................ 52 MT 941 Balance Report ...................................................................................................... 67 MT 942 Interim Transaction Report .................................................................................... 77 MT 950 Statement Message ................................................................................................ 92 MT 960 Request for Service Initiation Message ............................................................... 105 MT 961 Initiation Response Message ............................................................................... 108 MT 962 Key Service Message .......................................................................................... 110 MT 963 Key Acknowledgement Message ........................................................................ 113 MT 964 Error Message ...................................................................................................... 115 MT 965 Error in Key Service Message ............................................................................. 118 MT 966 Discontinue Service Message .............................................................................. 121 MT 967 Discontinuation Acknowledgement Message ..................................................... 123 MT 970 Netting Statement ................................................................................................ 126 MT 971 Netting Balance Report ....................................................................................... 136 MT 972 Netting Interim Statement ................................................................................... 139 MT 973 Netting Request Message .................................................................................... 149 MT 985 Status Enquiry ..................................................................................................... 152

May 2005 Standards Release

iii

Category 9 - Cash Management & Customer Status

MT 986 Status Report ....................................................................................................... 156 MT 990 Advice of Charges, Interest and Other Adjustments ........................................... 160 MT 991 Request for Payment of Charges, Interest and Other Expenses .......................... 161 MT 992 Request for Cancellation ..................................................................................... 162 MT 995 Queries ................................................................................................................. 163 MT 996 Answers ............................................................................................................... 164 MT 998 Proprietary Message ............................................................................................ 165 MT 999 Free Format Message .......................................................................................... 166 Glossary of Terms ............................................................................................................. 167

iv

May 2005 Standards Release

Introduction

Introduction
Overview
Category 9 consists of five types of messages exchanged between financial institutions, either on behalf of themselves, other financial institutions, or customers. These are: 1. balance reporting messages, which provide both cash management and nostro reconciliation information (balance and transaction details). 2. an interest rate change(s) message, which provides a means of advising interest rate change(s) to the Receiver of the message. 3. netting messages (sent between financial institutions and netting systems), which enable financial institutions to receive balances and details about transactions which are included in the netting process. 4. status messages, which provide a mechanism for requesting and responding to businessrelated information about customers or institutions. 5. bilateral key exchange messages, which enable financial institutions to request, exchange and cancel authenticator keys with other financial institutions.

Changes
This book incorporates the changes to Category 9 Cash Management & Customer Status messages as noted in the Standards Release Guide (SRG) 2005 and the relevant updates to the SRG 2005: • BEIs are expanded to include SMDP (Securities Market Data Providers).

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

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

May 2005 Standards Release

1

Category 9 - Cash Management & Customer Status

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

Message Type Format Specifications
The format specifications are the rules for the layout of the message type. This information is provided in table form with the following information: MT nnn (Message Type Name)
Status M M Tag 20 21 Field Name Transaction Reference Number Related Reference Content/Op tions 16x 16x No. 1 2

Mandatory Sequence A (Sequence Name) M M 25 32a Account Identification Value Date, Currency Code, Amount 35x C or D 3 4

-----> Optional Repetitive Sequence B (Sequence Name) O M O -----| M = Mandatory O = Optional 52a 71B 72 Ordering Institution Details of Charges Sender to Receiver Information A or D 6*35x 6*35x 5 6 7

• •

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.

2

May 2005 Standards Release

Introduction

-

Content/Options provides permitted field length and characteristics. For information concerning field structure, notation and character restrictions, please see Standards General Information. No. identifies the number of the field in the Field Specifications for the message type.

-

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

MT Network Validated Rules
Network validated rules are validated on the network, ie, rules for which an error code is defined. Rules specified in this section affect more than one field in the message, placing a ‘condition’ on one of the fields specified. They are identified as Cn, or conditional rules.

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

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

MT Field Specifications
The rules for the use of each field in the message are specified in this section. Each field is identified by its index number (as shown in the No. column of the MT Format Specifications), field tag and detailed field name, followed by a description of the field, which may contain some or all of the following: • • • • FORMAT specifies the field formats which are allowed for the field. PRESENCE indicates if the field is mandatory, optional or conditional in its sequence. DEFINITION specifies the definition of the field in 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

May 2005 Standards Release

3

Category 9 - Cash Management & Customer Status

the field in which they appear. In some cases, rules which are validated at the message level, ie, rules which affect more than one field, are repeated in this section. This is the case when the rule does not affect the presence of the field, but information within several fields, eg, a currency which must be the same for more than one field in the message. • USAGE RULES specifies rules that are not validated on the network, ie, rules for which no error code is defined, but are nevertheless mandatory for the correct usage of the field. Rules specified in this section affect only the field in which they appear. EXAMPLES provides one or more examples of the field as it will be formatted/used.

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

MT Examples
Examples are provided to illustrate the correct use of a message. Examples always include the following information: • • • Narrative provides a brief description of a transaction Information Flow illustrates the relationships between the parties involved in the message. An explanation of the flow diagram can be found in Standards General Information. SWIFT Format provides the message using the defined SWIFT format, and providing an explanation, where necessary, of the fields which have been used.

4

May 2005 Standards Release

Category 9 Message Types

Category 9 Message Types
The following table lists all message types defined in category 9. For each message type, there is a short description, an indicator whether the message type requires authentication (Y or N), the maximum message length on input (2,000 or 10,000 characters), whether the use of the message requires registration with S.W.I F.T. for use in a message user group (Y or 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 900 910 920

MT Name Confirmation of Debit Confirmation of Credit Request Message

Purpose Advises an account owner of a debit to its account Advises an account owner of a credit to its account Requests the account servicing institution to send an MT 940, 941, 942 or 950 Advises the Receiver of general rate change(s) and/or rate change(s) which applies to a specific account other than a call/notice loan/deposit account Provides balance and transaction details of an account to a financial institution on behalf of the account owner Provides balance information of an account to a financial institution on behalf of the account owner

Authen. N N N

Max. Length 2,000 2,000 2,000

MUG N N N

VDO N Y N

935

Rate Change Advice

N

2,000

N

N

940

Customer Statement Message

N

2,000

N

N

941

Balance Report

N

2,000

N

N

May 2005 Standards Release

5

Category 9 - Cash Management & Customer Status

MT 942

MT Name Interim Transaction Report

Purpose Provides balance and transaction details of an account, for a specified period of time, to a financial institution on behalf of the account owner Provides balance and transaction details of an account to the account owner Initiates a Bilateral Key Exchange (BKE) process.

Authen. N

Max. Length 2,000

MUG N

VDO N

950

Statement Message

N

2,000

N

N

960

Request for Service Initiation Message Initiation Response Message Key Service Message

N

2,000

N

N

961

Acknowledges receipt of an MT 960 Contains a bilateral authenticator key for another financial institution Acknowledges receipt of the bilateral key sent in a previous MT 962 Responds to an MT 960, 961, 963, 966 or 967 if an error has been detected to report that error Responds to an MT 962 if an error has been detected and reports that error Discontinues one or several bilateral authenticator keys already in existence between the Sender and Receiver

N

2,000

N

N

962

N

2,000

N

N

963

Key Acknowledgem ent Message Error Message

N

2,000

N

N

964

N

2,000

N

N

965

Error in Key Service Message Discontinue Service Message

N

2,000

N

N

966

N

2,000

N

N

6

May 2005 Standards Release

Category 9 Message Types

MT 967

MT Name Discontinuation Acknowledgem ent Message

Purpose Acknowledges receipt of a previous MT 966 and confirms discontinuation of the authenticator key(s) specified in the MT 966 Provides balance and transaction details of a netting position as recorded by a netting system Provides balance information for specified netting position(s) Advises interim balance and transaction details of a netting position as recorded by a netting system Requests an MT 971 or 972 containing the latest available information Requests an MT 986 Provides business related information about a customer or institution Advises an account owner of charges, interest or other adjustments to its account Requests payment of charges, interest or other expenses

Authen. N

Max. Length 2,000

MUG N

VDO N

970

Netting Statement

N

2,000

N

N

971

Netting Balance Report Netting Interim Statement

N

2,000

N

N

972

N

2,000

N

N

973

Netting Request Message Status Enquiry Status Report

N

2,000

N

N

985 986

N N

2,000 2,000

N N

N N

990

Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses

N

2,000

N

N

991

N

2,000

N

N

May 2005 Standards Release

7

Category 9 - Cash Management & Customer Status

MT 992

MT Name Request for Cancellation

Purpose Requests the Receiver to consider cancellation of the message identified in the request Requests information relating to a previous message or amendment to a previous message Responds to an MT 995 Queries or MT 992 Request for Cancellation or other messages where no specific message type has been provided for the response Contains formats defined and agreed to between users and for those messages not yet live Contains information for which no other message type has been defined

Authen. N

Max. Length 2,000

MUG N

VDO N

995

Queries

N

2,000

N

N

996

Answers

N

2,000

N

N

998

Proprietary Message

N

10,000

N

N

999

Free Format Message

N

2,000

N

N

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’. Registration is free of charge. It is done by sending an MT 999 to SWHQBEBBCOS to the attention of Customer Implementation. To register the following information must be provided: • • • • • the destination of the requesting institution, ie, the 8 character BIC the message type or specific usage of the specified message type the contact name and telephone number within the institution whether the request is for test and training or live operation, or both the requested activation date for testing and training and/or live operation.

8

May 2005 Standards Release

Category 9 Message Types

Activation occurs every Monday. A period of about three weeks is needed between the registration request and the actual activation period. A user can choose to withdraw from the group. This is done by sending SWIFT a similar request to withdraw. Upon request to Customer Implementation (see the SWIFT address above), information can be obtained regarding other members of the MUG.

May 2005 Standards Release

9

Category 9 - Cash Management & Customer Status

Euro – Impact on Category 9 Message Standards
Deletion of the National Currency Denomination (NCD) Currency Codes
On 1 March 2002, ISO announced the deletion of the NCD currency codes from the official ISO currency code table 4217. For certain message types, when an NCD is used as the currency of settlement, SWIFT validates to ensure the value date is before 1 January 2002, when these currencies stopped to be legal tender. This validation has been introduced on the network in July 2001. Until further notice, and where allowed (NCDs cannot be used in settlement amount field), SWIFT will continue to support NCD currency codes (eg, instructed amounts, ERI) in the relevant fields of its message types.

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

ERI Content
Euro-Related Information (ERI) refers to the following data: • • • original currency, original amount, transaction charges.

The original currency and amount in ERI is the equivalent of the information in the field containing the amount which is used for interbank settlement of the transaction. This field may contain additional information, eg, value date. ERI may be specified in one or several free text fields preceded by a code word. As of Standards Release 2001, the use of ERI was extended to non-European currencies, and beyond the transition period of 3 years.

ERI Usage Guidelines and Rules, relevant for Category 9
The specification of ERI is always optional. If used, however, the rules and guidelines specified in this section apply. These rules and guidelines include: • Usage Rules

10

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

Usage Guidelines

Usage rules must be complied with, although they are not validated by the network. Usage guidelines are recommendations on how to specify ERI. Usage Rules As with all other information occurring in fields 72 or 79, ERI is for information purposes only. In the case of a discrepancy between ERI and the settlement amount specified in the message, the information in the settlement amount prevails. Usage Guidelines 1. If no specific fields are available to specify the original currency and amount, ERI may be used in any message type containing a free text field 72 or 79, ie, the use of ERI is not restricted to specific message types. See the section entitled ‘Messages Likely to Contain ERI’. This section lists, for each message type, the field to specify the settlement amount and the field to specify the original amount. The list is provided to facilitate the implementation of different systems: it is not exhaustive. 2. The preferred field for specifying ERI is field 72. If not present, field 79 should be used. 3. If ERI is specified in one of these fields, 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. 4. For message types that do not contain a field 72 or 79, there are only two that may need to specify a second currency: MTs 940 and 942. For these two cases, subfield 9 of field 61 should be used to specify ERI. If this subfield is used for other purposes, field 86 should be used to specify ERI. It is recommended that the Sender of the MT 940/942 advises the Receiver whenever field 86 is used to contain ERI. 5. Where the settlement amount is part of a repetitive sequence which does not contain a free text field, the message should be used as a single transaction message, ie, one message should be used per transaction. 6. Where transaction charges are specified in ERI, this information must appear after the code word /CHGS/. This will not necessarily be processed by the Receiver. 7. ERI is designed to be passed on unchanged in the appropriate message types throughout the entire transaction, ie, throughout the chain of messages relating to the transaction. Therefore, it should appear in the appropriate SWIFT messages related to the transaction. 8. The MTs 950, 970 and 972 remain unchanged and thus one message must be sent per currency.

May 2005 Standards Release

11

Category 9 - Cash Management & Customer Status

ERI Structure
FORMAT Field 72 Field 79 DEFINITION 6*35x 35*50x

In addition to previously defined Sender to Receiver Information, or other narrative information, these fields may include euro-related information (ERI) for information purposes. ERI indicates currency conversion details, related to the conversion of the original currency into a settlement currency, found in free text fields. It is recommended that ERI be structured in these free text fields using codes. The following code words must be used: /OCMT/ 3!a15d/ O Original currency and amount. If no charges are specified then the original currency and amount will be the equivalent of the transaction amount specified in the message. O Currency and amount of the transaction charges. When the BEN option is used in payments and related messages, ie, all transaction charges are to be paid by the beneficiary customer, the charges amount has been deducted from the original amount to obtain the settlement amount specified in the message.

CODES

/CHGS/

3!a15d/

USAGE RULES EXAMPLE

The network will validate the structure of ERI, but not the content. :72:/OCMT/USD504938,/ /CHGS/EUR2,40/

Message-Specific Guidelines on the Use of ERI
This chapter lists message types which • • are likely to contain ERI. are to be validated against a specified value date

Messages Likely to Contain ERI
The following lists message types that are likely to contain euro-related information (ERI) in a free text field.

12

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

If there are business requirements to specify ERI in other message types, these should be similarly specified in a free text field 72 or 79 as explained in Section ERI Structure. Therefore, this list is not exhaustive.

MT

MT Name

Settlement Amount Field

Repetitive /NonRepetitive NR NR R R

ERI Field 72 72 61/9 or 86 61/9 or 86

Repetitive /NonRepetitive NR NR R R

900 910 940 942

Confirmation of Debit Confirmation of Credit Customer Statement Message Interim Transaction Report

32A Value Date, Currency Code, Amount 32A Value Date, Currency Code, Amount subfield 5 of field 61 subfield 5 of field 61

Messages with Value Date Validation
The following list contains messages that can be used to transfer amounts in National Currency Denominations (NCDs). If so, the value date has to be equal to, or before 31 December 2001. If this validation against value date fails, the message will be NAKed (Error Code 'E76'). The list gives the message description, the field containing the NCD amount and the field containing the value date. This validation is performed since 30 July 2001. Statement messages are not validated against value date, since they are generally the result of one of the earlier validated messages. Due to the importance of statements it is best not to risk rejection of these messages. Furthermore accounts are not held in NCD since 1 January 2002. Consequently, since that date, statement messages must not contain NCDs. The currencies concerned are ATS, BEF, DEM, ESP, FIM, FRF, GRD, IEP, ITL, LUF, NLG, PTE and XEU

May 2005 Standards Release

13

Category 9 - Cash Management & Customer Status

MT 900 910

MT Name Confirmation of Debit Confirmation of Credit 32A 32A

NCD Amount Field

Value Date Field 32A 32A

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

General ERI Validation Rules
Codes and format: • • /OCMT/3!a15d/ /CHGS/3!a15d/

where: • • the currency component ‘3!a’ must be a valid ISO currency code (Error code(s): T52) the amount component ‘15d’ following the currency code must be formatted according to the Field Formatting Rules given in Section 5.4.2 Numbers of the SWIFT User Handbook, Standards General Information. If not properly formatted the system will NAK the message with Error Code T40, T43, T33 or other generic error codes as deemed necessary the amount component ‘15d’ will not be checked on the maximum number of decimal digits allowed for the relevant currency code

In the following examples the currency code ‘XYZ’ is invalid. The message is NAKed: • :79:/OCMT/XYZ150,/(CrLf) /CHGS/EUR1,(CrLf) • :79:xxxxx/OCMT/EUR10000,//CHGS/XYZ1,/(CrLf)

In the following examples the amount components are invalid. The message is NAKed: • • :86:/OCMT/EUR,12/(CrLf) :86:/OCMT/EUR123/(CrLf)

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

14

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

:86:/OCMT/EUR1,23(CrLf) Messages and fields impacted The ERI validation will be performed in fields: • • 72 Structured Format, 72 Narrative and/or 79, of all messages except the MTs 960, 964, 965, 966, 967, 992, 995, 996 and 999 61 (subfield 9) and 86, of the MTs 940 and 942

In the following example OCMT is validated. The message is not NAKed: • :79:xxxxx/OCMT/EUR10,25/xxxxx(CrLf)

In the following example OCMT and CHGS are validated. The message is not NAKed: • :79:xxxxx/OCMT/EUR10,25/(CrLf) /CHGS/EUR1,/(CrLf) No ERI validation hierarchy between the fields Note, if the same Field Specification is reused 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. For example, if fields 72and 79 are both present in a message, and the ERI validation is defined for that message, then the system will apply the ERI validation in the two types of fields. /CHGS/ is only validated if /OCMT/ is present The ERI validation for the code /CHGS/ (6 characters) will be performed only if it immediately follows /OCMT/3!a15d/ in the same occurrence of that field. Therefore, if /OCMT/ is present in field 72 and /CHGS/ is present in field 79 (but /OCMT/ is not present in 79), then the system does not validate the format following /CHGS/ in field 79. In the following example, CHGS is not validated because OCMT is missing. The message is not NAKed: • :86:xxxxx/CHGS/EUR1,40/xxxxx(CrLf)

Sequence of codes is required Within a field, the sequence of the codes /OCMT/ and /CHGS/ is relevant. Only if /OCMT/ appears immediately before /CHGS/, will the ERI validation be applied to /CHGS/. In the following examples OCMT and CHGS are validated. The message is not NAKed: Example 1 (structured field 72): • :72:/INS/BANKCCCY/OCMT/EUR12345,/(CrLf)

May 2005 Standards Release

15

Category 9 - Cash Management & Customer Status

/CHGS/EUR100,/xxxxx(CrLf) Example 2 (free format field 79): • :79:xyz/OCMT/EUR1234,00//CHGS/EUR40,00/xxx(CrLf)

In the following example only OCMT is validated because CHGS does not immediately follow OCMT. The message is not NAKed: Example 3 (free format field 72): • :72:xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR10000,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) /CHGS/EUR50,/(CR) //xxxxxxxxxx(CrLf) Note: If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognized as part of the ERI and will not be subject to the ERI validation. In the following examples only OCMT is validated. The message is not NAKed: Example 4 (structured field 72): • :72:/CHGS/EUR12,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) Example 5 (free format field 79): • :79:xyz/CHGS/EUR4,00/xxx/OCMT/EUR1234,00/xxx(CrLf)

In the following example, OCMT and the second occurrence of CHGS are validated. The message is not NAKed: Example 6 (structured field 72): • :72:/CHGS/EUR1,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/(CrLf) /CHGS/EUR12,/xxxxx(CrLf) Double codes are not allowed in one field In one occurrence of a field where the ERI validation must be performed, the codes /OCMT/ and /CHGS/ must not be used more than once.

16

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

Note: Since the presence of /OCMT/ triggers the validation of /CHGS/, a double /CHGS/ will be NAKed only if /OCMT/ is present in the same field. If the ERI validation fails due to a duplicated code, it will result – whichever field was validated – in the existing Error Code T47. The line number of the first field in sequence in the message where the error occurred will be indicated together with the error code. In the following examples OCMT is found twice. The messages are NAKed: Example 1 (structured field 72): • :72:/OCMT/EUR12345,/(CrLf) //xxxxxx(CrLf) /OCMT/EUR100,/xxxxx(CrLf) Example 2 (field 61): • :61:9809010931C3500,25FCHK304955//4958843(CrLf) /OCMT/EUR1101,//OCMT/EUR1020,25/(CrLf) Example 3 (free format field 79): • :79:xyz/OCMT/EUR1234,00//OCMT/EUR40,00/xxx(CrLf)

In the following example CHGS is found twice. The message is NAKed: Example 4 (free format field 72): • :72:xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR10000,/(CrLf) /CHGS/EUR100,/xxxxxxxxxx(CrLf) /CHGS/EUR50,/(CR) //xxxxxxxxxx(CrLf) Note: If /CHGS/ appears before /OCMT/, /CHGS/ will not be recognized as part of the ERI and thus not be subject to the ERI validation. In the following example OCMT and the second occurrence of CHGS are validated. The messages are not NAKed: Example 5 (structured field 72): • :72:/CHGS/EUR12,/xxxxx(CrLf) //xxxxxxxxxx(CrLf) //xxxxxxxxxx(CrLf) /OCMT/EUR12345,/(CrLf) /CHGS/EUR50,/(CR) //xxxxxxxxxx(CrLf) Example 6 (free format field 79):

May 2005 Standards Release

17

Category 9 - Cash Management & Customer Status

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

Consistent with current standards In all fields where the ERI validation is defined, the ‘generic’, ie, current validation must still be performed. For example, a. field 72 is always checked for maximum 6 lines, with a maximum of 35 characters per line. b. field 72, structured format, the first line must begin with a ‘/’, and the second through sixth line (optional), must begin with a ‘/’ or a ‘//’. Maximum use of the generic format definition In order to maximize the use of all characters allowed in the ‘generic’ format, the codes /OCMT/, /CHGS/, as well as the data (3!a15d/), may be split across lines. Example in narrative format of information that follows ERI related codes, split across lines: • :72:xxxxx/OCMT/EUR12345,(CrLf) 12//CHGS/E(CrLf) UR12,/(CrLf) Example in structured format of ERI related codes, split across lines: • :72:/INS/BANKCCCY/OCMT/EUR1234,//CH(CrLf) //GS/EUR1,/xxxxxxx(CrLf) Example in narrative format of ERI related codes, split across lines: • :79:xxxxx/OC(CrLf) MT/EUR100,/(CrLf) No ERI validation performed in…: • • • fields 72 and 79, if the REJT or RETN codes are present, ie, the special REJT/RETN validation for fields 72 and 79 prevails. MTs 992, 995, 996 and 999 MT's 96n (only used for BKE)

Details of the ERI Validation Implementation
Field 61, subfield 9
FORMAT [34x]

The system will perform the following validation:

18

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

1. If subfield 9 in field 61 is present, then validate according to the format 34x: a. If the check here above is OK, then go to point 2 b. Otherwise the message is NAKed with the corresponding error code 2. Scan for /OCMT/ a. If /OCMT/ is not present, then perform next field validation b. If /OCMT/ is present more than once, then NAK the message with the Error Code T47 and terminate the validation c. If /OCMT/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to point 3 If format is not valid, then NAK the message with the corresponding error code and terminate the validation

3. 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, then NAK the message with the Error Code T47 and terminate the validation c. If /CHGS/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to next field validation If format is not valid, then NAK the message with the corresponding error code and terminate the validation

Field 72 (Structured format)
FORMAT <INSTR> [(CrLf)(<INSTR> or ‘//’ 33x)] where <INSTR> is defined as: /<1!a>/32x or /<2!a>/31x or /<3!a>/30x or /<4!a>/29x or /<5!a>/28x or /<6!a>/27x or /<7!a>/26x or /<8!a>/25x first line optionally, 2d through 6th line

The system will perform the following validation: 1. Maximum 6 lines, maximum 35 characters per line (<X> character set)

May 2005 Standards Release

19

Category 9 - Cash Management & Customer Status

2. First line as <INSTR>, per the format defined here above 3. Second through sixth line, if present, defined as : <INSTR> OR <‘//’ 33x> a. If the 3 checks here above are OK, then go to point 4 b. Otherwise the message is NAK with the corresponding error code 4. Throughout the field content remove all (CrLf‘//’), if any 5. Throughout the field content remove all (CrLf), if any 6. Scan for /OCMT/ a. If /OCMT/ is not present, then perform next field validation b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /OCMT/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to point 7 If format is not valid, then NAK the message with the corresponding error code and terminate the validation

7. Check for /CHGS/ immediately after /OCMT/3!a15d/ a. If /CHGS/ is not present, then perform next field validation b. If /CHGS/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /CHGS/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to next field validation If format is not valid, then NAK the message with the corresponding error code and terminate the validation

Field 72 (Narrative)
FORMAT 35x [(CrLf)35x]0-5

The system will perform the following validation: 1. Maximum 6 lines, maximum 35 characters per line (<X> character set) 2. Second through sixth line, if present, defined as 35x a. If the 2 checks here above are OK, then go to point 3 b. Otherwise the message is NAK with the corresponding error code

20

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

3. Throughout the field content remove all (CrLf), if any 4. Scan for /OCMT/ a. If /OCMT/ is not present, then perform next field validation b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /OCMT/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to point 5 If format is not valid, then NAK the message with the corresponding error code and terminate the validation

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 <3!a15d/> • • If format is valid, then go to next field validation If format is not valid, then NAK the message with the corresponding error code and terminate the validation

Field 79 (Narrative)
FORMAT 50x [(CrLf)50x]0-34

The system will perform the following validation: 1. Maximum 35 lines, maximum 50 characters per line (<X> character set) 2. Second through 35th line, if present, defined as 50x a. If the 2 checks here above are OK, then go to point 3 b. Otherwise the message is NAK with the corresponding error code 3. Throughout the field content remove all (CrLf), if any 4. Scan for /OCMT/ a. If /OCMT/ is not present, then perform next field validation b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /OCMT/ is present only once, then validate the format <3!a15d/>

May 2005 Standards Release

21

Category 9 - Cash Management & Customer Status

• •

If format is valid, then go to point 5 If format is not valid, then NAK the message with the corresponding error code and terminate the validation

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 <3!a15d/> • • If format is valid, then go to next field validation If format is not valid, then NAK the message with the corresponding error code and terminate the validation

Field 86 (Narrative)
FORMAT 65x [(CrLf)65x]0-5

The system will perform the following validation: 1. Maximum 6 lines, maximum 65 characters per line (<X> character set) 2. Second through sixth line, if present, defined as 65x a. If the 2 checks here above are OK, then go to point 3 b. Otherwise the message is NAK with the corresponding error code 3. Throughout the field content remove all (CrLf), if any 4. Scan for /OCMT/ a. If /OCMT/ is not present, then perform next field validation b. If /OCMT/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /OCMT/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to point 5 If format is not valid, then NAK the message with the corresponding error code and terminate the validation

5. Check for /CHGS/ immediately after /OCMT/3!a15d/ a. If /CHGS/ is not present, then perform next field validation

22

May 2005 Standards Release

Euro – Impact on Category 9 Message Standards

b. If /CHGS/ is present more than once (double), then NAK the message with the Error Code T47 and terminate the validation c. If /CHGS/ is present only once, then validate the format <3!a15d/> • • If format is valid, then go to next field validation If format is not valid, then NAK the message with the corresponding error code and terminate the validation.

May 2005 Standards Release

23

Category 9 - Cash Management & Customer Status

MT 900 Confirmation of Debit
MT 900 Scope
This message type is sent by an account servicing institution to an account owner. It is used to notify the account owner of an entry which has been debited to its account. The entry will be further confirmed by statement.

MT 900 Format Specifications
MT 900 Confirmation of Debit
Status M M M M O O Tag 20 21 25 32A 52a 72 Field Name Transaction Reference Number Related Reference Account Identification Value Date, Currency Code, Amount Ordering Institution Sender to Receiver Information M = Mandatory O = Optional 16x 16x 35x 6!n3!a15d A or D 6*35x Content/Options No. 1 2 3 4 5 6

MT 900 Network Validated Rules
There are no network validated rules for this message type.

MT 900 Usage Rules
• • This message type is not normally sent if statements for the account are frequently transmitted. This message type does not normally result in any bookings. It is a confirmation to the Receiver (account owner) of a debit to its account.

24

May 2005 Standards Release

MT 900

MT 900 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field contains the reference number of the transaction which resulted in this message, eg, the field 20 Transaction Reference Number of the SWIFT payment instruction. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory

May 2005 Standards Release

25

Category 9 - Cash Management & Customer Status

DEFINITION This field identifies the account which has been debited. 4. Field 32A: Value Date, Currency Code, Amount FORMAT Option A PRESENCE Mandatory DEFINITION This field specifies the value date, currency code and amount of the debit. NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). 5. Field 52a: Ordering Institution FORMAT Option A Option D [/1!a][/34x] 4!a2!a2!c[3!c] [/1!a][/34x] 4*35x (Party Identifier) (BIC) (Party Identifier) (Name & Address) 6!n3!a15d (Date) (Currency) (Amount)

PRESENCE Optional DEFINITION This field identifies the institution which instructed the Sender to execute the transaction resulting in this debit, when other than the Receiver. 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:

26

May 2005 Standards Release

MT 900

AT AU BL CC ES FW GR HK IE IN IT PT SC

5!n 6!n 8!n 9!n 8..9n 7!n 3!n 6!n 11!c 10!n 8!n 6!n

Austrian Bankleitzahl Australian Bank State Branch (BSB) Code German Bankleitzahl Canadian Payments Association Payment Routing Number Spanish Domestic Interbanking Code HEBIC (Hellenic Bank Identification Code) Bank Code of Hong Kong Irish National Clearing Code (NSC) Indian Financial System Code (IFSC) Italian Domestic Identification Code Portuguese National Clearing Code UK Domestic Sort Code

without 9 digit code Pay by Fedwire

CODES with option D:
AT AU BL CC CH CP ES FW GR HK IE IN IT PT RU 5!n 6!n 8!n 9!n 6!n 4!n 8..9n 9!n 7!n 3!n 6!n 11!c 10!n 8!n 9!n Austrian Bankleitzahl Australian Bank State Branch (BSB) Code German Bankleitzahl Canadian Payments Association Payment Routing Number CHIPS Universal Identifier CHIPS Participant Identifier Spanish Domestic Interbanking Code Fedwire Routing Number HEBIC (Hellenic Bank Identification Code) Bank Code of Hong Kong Irish National Clearing Code (NSC) Indian Financial System Code (IFSC) Italian Domestic Identification Code Portuguese National Clearing Code Russian Central Bank Identification Code

May 2005 Standards Release

27

Category 9 - Cash Management & Customer Status

SC SW SW

6!n 3..5n 6!n

UK Domestic Sort Code Swiss Clearing Code (BC code) Swiss Clearing Code (SIC code)

NETWORK VALIDATED RULES The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45). The BIC must not be a BEI, ie must not be of subtype BEID, MCCO, TESP or TRCO (Error code(s): C05). USAGE RULES The coded information contained in field 52a must be meaningful to the Receiver of the message. Option A is the preferred option. Option D should only be used when the ordering financial institution has no BIC. 6. Field 72: Sender to Receiver Information FORMAT 6*35x (Narrative)

In addition to narrative text, structured text with the following line formats may be used: Line 1 Lines 2-6 /8c/[additional information] [//continuation of additional information] or [/8c/[additional information]]

PRESENCE Optional DEFINITION This field contains additional information for the Receiver. USAGE RULES This field may contain information only (ie, no instructions may be included). Additional explanatory information, which may be continued on the next lines, is preceded by a double slash ‘//’. Codes to be used may be agreed to bilaterally.

28

May 2005 Standards Release

MT 900

This field may contain ERI to transport dual currencies, as explained in the chapter 'Euro Impact on Category 9 Message Standards'. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

MT 900 Examples
Narrative Value 23 January 1998, Crédit Suisse, Zürich, requests Chase Manhattan Bank, New York, to pay US dollars 233,530 to Berliner Bank, Berlin, under reference 5482ABC. Chase sends the following confirmation to Crédit Suisse: Information Flow

Sender

Chase Manhattan Bank New York

MT

MT 900

Receiver

May 2005 Standards Release

D0090001

Crédit Suisse Zurich

29

Category 9 - Cash Management & Customer Status

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Related Reference Account Identification (1) Value Date, Currency Code, Amount End of Message Text/Trailer CHASUS33 900 CRESCHZZ

Format

:20:C11126A1378 :21:5482ABC :25:9-9876543 :32A:980123USD233530,

Note: (1) The number of the account that has been debited.

30

May 2005 Standards Release

MT 910

MT 910 Confirmation of Credit
MT 910 Scope
This message is sent by an account servicing institution to an account owner. It is used to notify the account owner of an entry which has been credited to its account. The entry will be further confirmed by statement.

MT 910 Format Specifications
MT 910 Confirmation of Credit
Status M M M M O O O O Tag 20 21 25 32A 50a 52a 56a 72 Field Name Transaction Reference Number Related Reference Account Identification Value Date, Currency Code, Amount Ordering Customer Ordering Institution Intermediary Sender to Receiver Information M = Mandatory O = Optional 16x 16x 35x 6!n3!a15d A or K A or D A or D 6*35x Content/Options No. 1 2 3 4 5 6 7 8

MT 910 Network Validated Rules
C1 Either field 50a or field 52a must be present, but not both (Error code(s): C06):
If field 50a is… Present Not present Not allowed Mandatory then field 52a is…

May 2005 Standards Release

31

Category 9 - Cash Management & Customer Status

MT 910 Usage Rules
• • This message type is not normally sent if statements for the account are frequently transmitted. This message type does not normally result in any bookings. It is a confirmation to the Receiver (account owner) of a credit to its account.

MT 910 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field contains the reference for the account owner (Receiver), eg, field 21, from the SWIFT message which resulted in this credit. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).

32

May 2005 Standards Release

MT 910

3.

Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the account which has been credited.

4.

Field 32A: Value Date, Currency Code, Amount FORMAT Option A PRESENCE Mandatory DEFINITION This field specifies the value date, currency code and amount of the credit. NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). 6!n3!a15d (Date) (Currency) (Amount)

5.

Field 50a: Ordering Customer FORMAT Option A Option K [/34x] 4!a2!a2!c[3!c] [/34x] 4*35x (Account) (BEI) (Account) (Name & Address)

PRESENCE Conditional (C1)

May 2005 Standards Release

33

Category 9 - Cash Management & Customer Status

DEFINITION This field identifies the customer which originated the transaction resulting in this credit. NETWORK VALIDATED RULES The BEI, ie, a BIC with subtype BEID, MCCO, TESP or TRCO, must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45, E57). USAGE RULES If the account number is present, it must be stated in Account. 6. Field 52a: Ordering Institution FORMAT Option A Option D [/1!a][/34x] 4!a2!a2!c[3!c] [/1!a][/34x] 4*35x (Party Identifier) (BIC) (Party Identifier) (Name & Address)

PRESENCE Conditional (C1) DEFINITION This field identifies the financial institution which originated the transaction resulting in this credit. 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:
AT AU BL CC ES FW GR HK IE 5!n 6!n 8!n 9!n 8..9n 7!n 3!n 6!n Austrian Bankleitzahl Australian Bank State Branch (BSB) Code German Bankleitzahl Canadian Payments Association Payment Routing Number Spanish Domestic Interbanking Code HEBIC (Hellenic Bank Identification Code) Bank Code of Hong Kong Irish National Clearing Code (NSC)

without 9 digit code Pay by Fedwire

34

May 2005 Standards Release

MT 910

IN IT PT SC

11!c 10!n 8!n 6!n

Indian Financial System Code (IFSC) Italian Domestic Identification Code Portuguese National Clearing Code UK Domestic Sort Code

CODES with option D:
AT AU BL CC CH CP ES FW GR HK IE IN IT PT RU SC SW SW 5!n 6!n 8!n 9!n 6!n 4!n 8..9n 9!n 7!n 3!n 6!n 11!c 10!n 8!n 9!n 6!n 3..5n 6!n Austrian Bankleitzahl Australian Bank State Branch (BSB) Code German Bankleitzahl Canadian Payments Association Payment Routing Number CHIPS Universal Identifier CHIPS Participant Identifier Spanish Domestic Interbanking Code Fedwire Routing Number HEBIC (Hellenic Bank Identification Code) Bank Code of Hong Kong Irish National Clearing Code (NSC) Indian Financial System Code (IFSC) Italian Domestic Identification Code Portuguese National Clearing Code Russian Central Bank Identification Code UK Domestic Sort Code Swiss Clearing Code (BC code) Swiss Clearing Code (SIC code)

NETWORK VALIDATED RULES The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45). The BIC must not be a BEI, ie must not be of subtype BEID, MCCO, TESP or TRCO (Error code(s): C05). USAGE RULES The coded information contained in field 52a must be meaningful to the Receiver of the message. Option A is the preferred option.

May 2005 Standards Release

35

Category 9 - Cash Management & Customer Status

Option D should only be used when the ordering financial institution has no BIC. 7. Field 56a: Intermediary FORMAT Option A Option D [/1!a][/34x] 4!a2!a2!c[3!c] [/1!a][/34x] 4*35x (Party Identifier) (BIC) (Party Identifier) (Name & Address)

PRESENCE Optional DEFINITION This field identifies the financial institution from which the Sender received the funds, when other than the ordering institution. NETWORK VALIDATED RULES The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45). The BIC must not be a BEI, ie must not be of subtype BEID, MCCO, TESP or TRCO (Error code(s): C05). 8. Field 72: Sender to Receiver Information FORMAT 6*35x (Narrative)

In addition to narrative text, structured text with the following line formats may be used: Line 1 Lines 2-6 /8c/[additional information] [//continuation of additional information] or [/8c/[additional information]]

PRESENCE Optional DEFINITION This field contains additional information for the Receiver.

36

May 2005 Standards Release

MT 910

USAGE RULES This field may contain information only, ie, no instructions may be included. Additional explanatory information, which may be continued on the next lines, is preceded by a double slash ‘//’. Codes to be used may be agreed to bilaterally. This field may contain ERI to transport dual currencies, as explained in the chapter ‘Euro Impact on Category 9 Message Standards’. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

MT 910 Examples
Narrative Chase Manhattan Bank, New York, informs ABN Amro Bank, Amsterdam, of a credit to its account number 6-9412771, by order of Bank Austria, Vienna. The value date of the credit is 27 May 1998, for US dollars 500,000, and is received from Bankers Trust Company, New York. Chase Manhattan sends the following confirmation to ABN Amro:

May 2005 Standards Release

37

Category 9 - Cash Management & Customer Status

Information Flow

Ordering Institution 52a

Bank Austria Vienna

Intermediary
56a

Bankers Trust Company New York

Sender

Chase Manhattan Bank New York

MT

MT 910

Receiver

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Related Reference Account Identification (1) CHASUS33 910 ABNANL2A

Format

:20:C11126C9224 :21:494936/DEV :25:6-9412771

38

May 2005 Standards Release

D0090002

ABN Amro Bank Amsterdam

MT 910

Explanation Value Date, Currency Code, Amount Ordering Institution Intermediary End of Message Text/Trailer

Format :32A:980527USD500000, :52A:BKAUATWW :56A:BKTRUS33

Note: (1) The number of the account that has been credited.

May 2005 Standards Release

39

Category 9 - Cash Management & Customer Status

MT 920 Request Message
Note: As this message may require the implementation of special procedures, its use is governed by bilateral agreements between correspondents.

MT 920 Scope
This multiple message is sent by an account owner, or a financial institution (concentrating institution) acting on behalf of an account owner, to an account servicing institution. It is used to request the account servicing institution to transmit one or more MT 940 Customer Statement(s), MT 941 Balance Report(s), MT 942 Interim Transaction Report(s), or MT 950 Statement Message(s) containing the latest information available for the account(s) identified in the message.

MT 920 Format Specifications
MT 920 Request Message
Status M -----> M M O O -----| M = Mandatory O = Optional 12 25 34F 34F Message Requested Account Identification Floor Limit Indicator Floor Limit Indicator 3!n 35x 3!a[1!a]15d 3!a[1!a]15d 2 3 4 5 Tag 20 Field Name Transaction Reference Number 16x Content/Options No. 1

MT 920 Network Validated Rules
C1 C2 If field 12 contains the value ‘942’, at least one field 34F must be present in the same repetitive sequence (Error code(s): C22). Within each repetitive sequence, when only one field 34F is present, the second subfield must not be used. When both fields 34F are present, subfield 2 of the first 34F must

40

May 2005 Standards Release

MT 920

contain the value ‘D’, and subfield 2 of the second 34F must contain the value ‘C’ (Error code(s): C23). C3 The currency code must be the same for each occurrence of the indicated fields within each repetitive sequence (Error code(s): C40).

MT 920 Usage Rules
• This message should only be used if the account owner(s) have authorised the financial institutions to transmit such information and according to agreed criteria.

MT 920 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 12: Message Requested FORMAT 3!n PRESENCE Mandatory DEFINITION This field identifies the message type which is being requested. CODES This field must contain one of the following message type numbers (Error code(s): T88):

May 2005 Standards Release

41

Category 9 - Cash Management & Customer Status

940 941 942 950

Customer Statement Balance Report Interim Transaction Report Statement Message

3.

Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the account for which the information is requested.

4.

Field 34F: Floor Limit Indicator FORMAT Option F PRESENCE Conditional (C1) DEFINITION This field specifies the minimum value (transaction amount) to be reported on the requested message. CODES When D/C Mark is present, it must contain the following code (Error code(s): T51):
D Debit floor limit

3!a[1!a]15d

(Currency) (D/C Mark) (Amount)

NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

42

May 2005 Standards Release

MT 920

When this field appears two times, Currency must be the same for each occurrence (Error code(s): C40). USAGE RULES When the field appears once, the floor limit applies to both debit and credit amounts. When different limits apply, both fields 34F must be present. 5. Field 34F: Floor Limit Indicator FORMAT Option F PRESENCE Conditional (C2) DEFINITION This field specifies the minimum value (transaction amount) to be reported on the requested message. CODES D/C Mark must contain the following code (Error code(s): T51):
C Credit floor limit

3!a[1!a]15d

(Currency) (D/C Mark) (Amount)

NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). When this field appears two times, Currency must be the same for each occurrence (Error code(s): C40). USAGE RULES When different limits apply, this field 34F must be present, with a credit indicator (‘C’).

May 2005 Standards Release

43

Category 9 - Cash Management & Customer Status

MT 920 Examples
Narrative Midland Bank, London, requests UBS, Zürich, to provide an interim transaction report for account number 123–45678, which is owned by Smythe Publications. The report is to list all debit amounts in excess of Swiss Francs 1,000,000 and all credit amounts in excess of Swiss Francs 100,000. Information Flow

Smythe Publications

Sender

Midland Bank London

MT

MT 920

Receiver

SWIFT Message

Explanation Sender Message Type Receiver Message Text MIDLGB22 920 UBSWCHZH80A

Format

44

May 2005 Standards Release

D0090003

UBS Zurich

MT 920

Explanation Transaction Reference Number Message type requested Account Identification Debit Amount Floor Limit Credit Amount Floor Limit End of Message Text/Trailer :20:3948 :12:942 :25:123-45678

Format

:34F:CHFD1000000, :34F:CHFC100000,

May 2005 Standards Release

45

Category 9 - Cash Management & Customer Status

MT 935 Rate Change Advice
MT 935 Scope
This multiple message is used by the Sender to advise interest rate change(s) to the Receiver. It is used to advise the details of: • • General interest rate change(s). Interest rate change(s) which apply to specific account(s), other than call/notice loan/deposit account(s), serviced by the Sender of the message for the Receiver.

Interest rate change(s) that can be advised by this message type include: NOTICE, CALL, PRIME, COMMERCIAL, BASE, CURRENT and DEPOSIT.

MT 935 Format Specifications
MT 935 Rate Change Advice
Status M -----> O O M -----> M -----| -----| O 72 Sender to Receiver Information M = Mandatory O = Optional 6*35x 6 37H New Interest Rate 1!a12d 5 23 25 30 Further Identification Account Identification Effective Date of New Rate 16x 35x 6!n 2 3 4 Tag 20 Field Name Transaction Reference Number 16x Content/Options No. 1

46

May 2005 Standards Release

MT 935

MT 935 Network Validated Rules
C1 C2 The repetitive sequence must appear at least once (Error code(s): T11), but not more than ten times (Error code(s): T10). Either field 23 or field 25, but not both, must be present in any repetitive sequence (Error code(s): C83).

MT 935 Usage Rules
• An MT 335 is to be used when advising an interest rate change relating to a specific call/notice loan/deposit.

MT 935 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 23: Further Identification FORMAT 16x The format is structured as: 3!a[2!n]11x PRESENCE Conditional (C2) (Currency) (Number of Days) (Function)

May 2005 Standards Release

47

Category 9 - Cash Management & Customer Status

DEFINITION This field specifies the kind of interest rate being advised, in those cases where it is not related to a specific account. CODES Function must contain one of the following codes identifying the function of the message:
BASE CALL COMMERCIAL CURRENT DEPOSIT NOTICE PRIME Used to advise a change in the base rate Used to advise a change in the call rate Used to advise a change in the commercial rate Used to advise a change in the interest rate applicable to current accounts Used to advise a change in the interest rate applicable to deposits Used to advise a change in the notice rate Used to advise a change in the prime rate

USAGE RULES Currency specifies the currency that applies to the rate. Number of Days specifies the number of days notice (eg, 07). It must only be used when Function is NOTICE. 3. Field 25: Account Identification FORMAT 35x PRESENCE Conditional (C2) DEFINITION This field identifies the relevant account, where the rate change relates to a specific account serviced by the Sender for the Receiver. 4. Field 30: Effective Date of New Rate FORMAT 6!n PRESENCE Mandatory (Date)

48

May 2005 Standards Release

MT 935

DEFINITION This field specifies the effective date of the rate being advised. NETWORK VALIDATED RULES Date must be a valid date expressed as YYMMDD (Error code(s): T50). 5. Field 37H: New Interest Rate FORMAT Option H PRESENCE Mandatory DEFINITION This field specifies the new interest rate being advised. CODES Indicator must contain one of the following codes:
C D The new interest rate is a credit rate. The new interest rate is a debit rate.

1!a12d

(Indicator) (Rate)

NETWORK VALIDATED RULES The integer part of Rate must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). USAGE RULES This field may be repeated, if required. Rate specifies the rate in decimal comma format. 6. Field 72: Sender to Receiver Information FORMAT 6*35x (Narrative)

In addition to narrative text, structured text with the following line formats may be used:

May 2005 Standards Release

49

Category 9 - Cash Management & Customer Status

Line 1

/8c/[additional information]

Additional explanatory information, which may be continued on the next lines, is preceded by a double slash ‘//’

Lines 2-6

[//continuation of additional information] or [/8c/[additional information]]

PRESENCE Optional DEFINITION This field contains additional information for the Receiver. CODES Codes to be used may be agreed to bilaterally. USAGE RULES Additional explanatory information, which may be continued on the next lines, is preceded by a double slash ‘//’.

MT 935 Examples
Narrative On 12 March 1997 Chase Manhattan Bank, New York advises all financial institutions to which it has given short term USD Floating Prime advances, of the new rate applicable, starting 14 March 1997. One of these financial institutions is Banque Indosuez, Brussels.

50

May 2005 Standards Release

MT 935

Information Flow

Sender

Chase Manhattan Bank New York

MT

MT 935

Receiver

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Further Identification Effective Date of New Rate New Interest Rate End of Message Text/Trailer :20:98031645 :23:USDPRIME :30:980314 :37H:D9,75 CHASUS33 935 BENLBEBB

Format

May 2005 Standards Release

D0090004

Banque Indosuez Brussels

51

Category 9 - Cash Management & Customer Status

MT 940 Customer Statement Message
Note: As this message may require the implementation of special procedures, its use is governed by bilateral agreements between correspondents.

MT 940 Scope
This message type is sent by an account servicing institution (reporting institution) to a financial institution (concentrating institution) which has been authorised by the account owner to receive it. It is used to transmit detailed information about all entries booked to the account.

MT 940 Format Specifications
MT 940 Customer Statement Message
Status M O M M M -----> O O -----| M O -----> O 65 Forward Available Balance 1!a6!n3!a15d 10 62a 64 Closing Balance (Booked Funds) Closing Available Balance (Available Funds) F or M 1!a6!n3!a15d 8 9 61 86 Statement Line Information to Account Owner * 6*65x 6 7 Tag 20 21 25 28C 60a Field Name Transaction Reference Number Related Reference Account Identification Statement Number/Sequence Number Opening Balance 16x 16x 35x 5n[/5n] F or M Content/Options No. 1 2 3 4 5

52

May 2005 Standards Release

MT 940

Status -----| O

Tag

Field Name

Content/Options

No.

86

Information to Account Owner M = Mandatory O = Optional * See Field Specifications below.

6*65x

11

MT 940 Network Validated Rules
C1 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. In addition, if field 86 is present, it must be present on the same page (message) of the statement as the related field 61 (Error code(s): C24). The first two characters of the three character currency code in fields 60a, 62a, 64 and 65 must be the same for all occurrences of these fields (Error code(s): C27).

C2

MT 940 Usage Rules
• • • This message should only be used if the account owner(s) have authorised the financial institutions to transmit such information. It must be used according to agreed criteria. Financial institutions which receive this message must not use the information for their own purposes. It is important that amounts be identical to those of the original transaction. For identification purposes, deductions, eg, charges above and beyond those previously accounted for, shall appear separately with the appropriate code. They shall use the same TRN as the original transaction, or other suitable reference if no TRN is available. Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information for one statement.

MT 940 Field Specifications
1. Field 20: Transaction Reference Number (TRN) FORMAT 16x PRESENCE Mandatory

May 2005 Standards Release

53

Category 9 - Cash Management & Customer Status

DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES The TRN may be the same or different for the separate messages of a statement consisting of several messages. 2. Field 21: Related Reference FORMAT 16x PRESENCE Optional DEFINITION If the MT 940 is sent in response to an MT 920 Request Message, this field must contain the field 20 Transaction Reference Number of the request message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the account for which the statement is sent. 4. Field 28C: Statement Number/Sequence Number FORMAT Option C 5n[/5n] (Statement Number) (Sequence Number) (Account)

54

May 2005 Standards Release

MT 940

PRESENCE Mandatory DEFINITION This field contains the sequential number of the statement, optionally followed by the sequence number of the message within that statement when more than one message is sent for one statement. USAGE RULES The statement number should be reset to 1 on 1 January of each year. If used, the sequence number always starts with 1. When several messages are sent to convey information about a single statement, the first message must contain ‘/1’ in Sequence Number. The sequence number must be incremented by one for each additional message. Both the statement number and sequence number enable the Receiver to put the different messages into sequence and thus form the complete statement. EXAMPLE The first message of a statement is :28C:235/1 The second messsage is :28C:235/2 and so on. 5. Field 60a: Opening Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) opening balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) opening balance is a credit balance. The (intermediate) opening balance is a debit balance.

May 2005 Standards Release

55

Category 9 - Cash Management & Customer Status

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). USAGE RULES This field must always be the same as field 62a (closing balance) of the previous customer statement message for this account. The first customer statement message for a specified period must contain field 60F (first opening balance); additional statement messages for the same statement period must contain field 60M (intermediate opening balance). 6. Field 61: Statement Line FORMAT 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] where: Subfield 1 2 3 4 5 6 7 8 9 Format 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x] Value Date (YYMMDD) Entry Date (MMDD) Debit/Credit Mark Funds Code (3rd character of the currency code, if needed) Amount Transaction Type Identification Code Reference for the Account Owner Account Servicing Institution's Reference Supplementary Details Name

56

May 2005 Standards Release

MT 940

PRESENCE Optional DEFINITION This field contains the details of each transaction. CODES Subfield 3, Debit/Credit Mark, must contain one of the following codes (Error code(s): T51):
D C RC RD Debit Credit Reversal of credit (debit entry) Reversal of debit (credit entry)

CODES Subfield 6, Transaction Type Identification Code, may be completed in one of three ways (Error code(s): T53):
1. For entries related to SWIFT transfer instructions and subsequent charge messages: Format: S3!n The last three characters will indicate the message type of the SWIFT message causing the entry (for debit entries) or the message type of the SWIFT message used to advise the account owner (for credit entries). 2. For entries related to payment and transfer instructions, including related charges messages, not sent through SWIFT or where an alpha description is preferred. Format: 3. N3!c For entries being first advised by the statement (items originated by the account servicing institution): Format: F3!c

CODES When formats (2) or (3) are used, the last three characters, ie, 3!c, may contain one of the following codes:
BOE BRF CHG CHK CLR Bill of exchange Brokerage fee Charges and other expenses Cheques Cash letters/Cheques remittance

May 2005 Standards Release

57

Category 9 - Cash Management & Customer Status

CMI CMN CMS CMT CMZ COL COM DCR DDT DIV EQA ECK FEX INT LBX LDP MSC RTI SEC STO TCK TRF VDA

Cash management item - No detail Cash management item - Notional pooling Cash management item - Sweeping Cash management item -Topping Cash management item - Zero balancing Collections (used when entering a principal amount) Commission Documentary credit (used when entering a principal amount) Direct Debit Item Dividends-Warrants Equivalent amount Eurocheques Foreign exchange Interest Lock box Loan deposit Miscellaneous Returned item Securities (used when entering a principal amount) Standing order Travellers cheques Transfer Value date adjustment (used with an entry made to withdraw an incorrectly dated entry – it will be followed by the correct entry with the relevant code)

NETWORK VALIDATED RULES Subfield 1, Value Date, must be a valid date expressed as YYMMDD (Error code(s): T50). The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). When the first character of subfield 6, Transaction Type Identification Code, is an ‘S’, the remaining characters must be in the range 100-999 (Error code(s): T18). USAGE RULES This field may be repeated within the constraints of the maximum input message length.

58

May 2005 Standards Release

MT 940

‘Original’ advices for charges, ie, the first time the account owner is informed of a charge, must be identified in subfield 6, Transaction Type Identification Code, with the transaction type code ‘FCHG’. The following rules apply to subfield 7, Reference for the Account Owner: • • At least one valid character other than a blank must be present. For debit entries, the purpose of this subfield is to identify, to the account owner, the instruction which caused the debit. Therefore, the content of this subfield is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. Credit entries may be the result of one of the following situations: 1. The account servicing institution is identifying, to the account owner the receipt of funds for its account as a result of a related transaction. In this case, the content of subfield 7, Reference for the Account Owner is the reference for the beneficiary (eg, field 21 Related Reference) of the related transaction. 2. The account servicing institution has issued a payment instruction to the account owner and the credit identified in this subfield is for that payment. The content of subfield 7, Reference for the Account Owner is the field 20 Transaction Reference Number (or its equivalent) of the payment instruction issued by the account servicing institution. • If no reference is available for subfield 7, Reference for the Account Owner, the code NONREF shall be used. The account servicing institution must then supply, in subfield 9, Supplementary Details, what it considers to be the best alternative information. This reference must be quoted in all cases when available. In cases where a transaction passes through several financial institutions, the original reference must always be forwarded. This reference must always be quoted against any charges or fees debited by the account servicing institution. Debits against standing instructions must show the reference of the standing instruction. In cases where a mutually agreed alternative reference exists (eg, in foreign exchange or money market transactions), this reference should then be used. If the statement entry concerns a cheque, the cheque number should be indicated in this subfield.

• • • •

The following rules apply to subfield 8, Account Servicing Institution's Reference: • The content of this subfield is the account servicing institution's own reference for the transaction.

May 2005 Standards Release

59

Category 9 - Cash Management & Customer Status

When the transaction has been initiated by the account servicing institution, this reference may be identical to subfield 7, Reference for the Account Owner. If this is the case, Account Servicing Institution’s Reference, subfield 8 may be omitted.

The following rules apply to subfield 9, Supplementary Details: • When no reference for the account owner is available, ie, subfield 7, Reference for the Account Owner contains NONREF, the account servicing institution should provide the best available alternative information in this subfield. Supplementary details may be provided when an advice has not been sent for a transaction, or to provide additional information to facilitate reconciliation. This field may contain ERI to transport dual currencies, as explained in the chapter 'Euro Impact on Category 9 Message Standards'. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

• • •

EXAMPLE (1) :61:9805270526C3500,25FCHK304955//4958843 (2) :61:9805270526C3500,25FCHK304955//4958843 ADDITIONAL INFORMATION 7. Field 86: Information to Account Owner FORMAT 6*65x PRESENCE Conditional (C1) DEFINITION This field contains additional information on the transaction detailed in the preceding statement line and which is to be passed on to the account owner. USAGE RULES This field may contain ERI to transport dual currencies, as explained in the chapter ‘Euro Impact on Category 9 Message Standards’. Since the charges field in the customer transfers is repetitive, it may be necessary to report more than one charges amount in the resulting statement. In this case, it is allowed to repeat the code word CHGS before the code word OCMT. The order in which the charges are specified is the same as in the customer transfers, ie, the order in which the charges have been taken during the (Narrative)

60

May 2005 Standards Release

MT 940

transaction. So, the last appearance of the code word CHGS always specifies the charges (if any) of the account servicing institution. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash. The code may be repeated if the account servicing institution wants to report an exchange rate that it applied, in addition to the exchange rate received in the instruction. The order in which the exchange rates are specified is the same as the order in which the rates have been applied during the transaction. So, the last appearance of the code word EXCH always specifies the rate applied by the account servicing institution. An ordering party is identified with the preceding code /ORDP/. The information following this code is copied from field 50a of the customer payment order, or field 52a (sender if field 52a is not present) of the financial institution transfer. The code should be used at the beginning of a line. In case of a debit item, a beneficiary party may be identified with the preceding code /BENM/. The information following this code is copied from field 59a of the customer payment order, or field 58a of the financial institution transfer. The code should be used at the beginning of a line. In case remittance information from field 70 of the payment instruction is to be included in this field, it should be preceded by the code /REMI/. In case the information in field 72 of the payment instruction is intended for the account owner, it should be copied into field 86 as it is. Codes used in field 72 of the payment instruction have therefore the same meaning in field 86 of the statement. If only free text is used in field 72, it is to be copied as it is since a code in field 86 will not add any value. 8. Field 62a: Closing Balance (Booked Funds) FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) closing balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance.

May 2005 Standards Release

61

Category 9 - Cash Management & Customer Status

CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) closing balance is a credit balance. The (intermediate) closing balance is a debit balance.

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). USAGE RULES The content of this field will be repeated in field 60a of the subsequent customer statement message for this account. If there is only one customer statement message transmitted for the period, this field must use tag option F, ie, 62F (final closing balance). When several messages are transmitted for the same statement period, all messages except the last message must contain field 62M (intermediate closing balance); the last message of the statement must contain field 62F. 9. Field 64: Closing Available Balance (Available Funds) FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the account owner (if credit balance) or the balance which is subject to interest charges (if debit balance). CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing available balance is a credit balance. The closing available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

62

May 2005 Standards Release

MT 940

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). 10. Field 65: Forward Available Balance FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the account owner (if a credit or debit balance) for the specified forward value date. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The forward available balance is a credit balance. The forward available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for that specific currency as specified in ISO 4217 (Error code(s): C03, T40, T43). USAGE RULES When there is more than one value date for the items booked to the account (in this or previous statement periods), this field will indicate the balance which will be available to the account owner on the date(s) indicated.

May 2005 Standards Release

63

Category 9 - Cash Management & Customer Status

11.

Field 86: Information to Account Owner FORMAT 6*65x PRESENCE Optional DEFINITION This field contains additional information on the statement as a whole. It is to be passed on to the account owner. (Narrative)

MT 940 Examples
Narrative Chase Manhattan Bank, New York, sends an MT 940 to Midland Bank, London, for account number 123–304958, of Transglobal Corp. The statement number is 123.
Closing Balance of Previous Statement (22 June 1998): USD 395,212,311.71 (Credit) Opening Balance as of 23 June 1998: USD 395,212,311.71 (Credit)

Transaction Details:
(1) Value date: 23 June 1998 Transaction type: non-SWIFT transfer Reference for the Account Owner: None Chase Manhattan Bank's Reference: 8951234 Details: Ordering Institution = Bk of NYC Western Cash Reserve (2) Value date: 25 June 1998 Transaction type: Settlement of F/X Contract Reference for the Account Owner: 036960 Chase Manhattan Bank's Reference: 8954321 Value Date: 26 June 1998 Transaction Type: Dividend Reference for the Account Owner: None Chase Manhattan Bank's Reference: 8846543 Information for the Account Owner: Dividend Loral Corp Preferred stock 1st quarter 1998 Credit: USD 5,700,000 Credit: USD 50,000,000

(3)

Credit: USD 200,000

64

May 2005 Standards Release

MT 940

Closing Book Balance as of 23 June 1998: Closing Available Balance: Forward Available Balance: As of 25 June 1998: As of 26 June 1998: General information: Prime rate as of today 11 pct

USD 451,112,311.71 (Credit) USD 445,212,311.71 (Credit) USD 450,912,311.71 (Credit) USD 451,112,311.71 (Credit)

Information Flow

Sender

Chase Manhattan Bank New York

MT

MT 940

Receiver

Midland Bank London

Transglobal Corp.
D0090005

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number :20:123456 CHASUS33 940 MIDLGB22

Format

May 2005 Standards Release

65

Category 9 - Cash Management & Customer Status

Explanation Account Identification Statement Number/Sequence Number Opening Balance 1st Transaction 2nd Transaction 3rd Transaction Information to Account Owner Closing Book Balance Closing Available Balance Forward Available Balance Forward Available Balance General Info to Acct Owner End of Message Text/Trailer :25:123-304958 :28C:123/1

Format

:60F:C980622USD395212311,71 :61:980623C50000000,NTRFNONREF//8951234 ORDER BK OF NYC WESTERN CASH RESERVE :61:980625C5700000,NFEX036960//8954321 :61:980626C200000,NDIVNONREF//8846543 :86:DIVIDEND LORAL CORP PREFERRED STOCK 1ST QUARTER 1998 :62F:C980623USD451112311,71 :64:C980623USD445212311,71 :65:C980625USD450912311,71 :65:C980626USD451112311,71 :86:PRIME RATE AS OF TODAY 11 PCT

66

May 2005 Standards Release

MT 941

MT 941 Balance Report
Note: As this message may require the implementation of special procedures, its use is governed by bilateral agreements between correspondents.

MT 941 Scope
This message type is sent by an account servicing institution (reporting institution) to a financial institution (concentrating institution) which has been authorised by the account owner to receive it. It is used to transmit balance information, reflecting the situation at the identified time in field 13D.

MT 941 Format Specifications
MT 941 Balance Report
Status M O M M O O O O M O -----> O 65 Forward Available Balance 1!a6!n3!a15d 11 Tag 20 21 25 28 13D 60F 90D 90C 62F 64 Field Name Transaction Reference Number Related Reference Account Identification Statement Number/Sequence Number Date/Time Indication Opening Balance Number and Sum of Entries Number and Sum of Entries Closing Balance (Booked Funds) Closing Available Balance (Available Funds) 16x 16x 35x 5n[/2n] 6!n4!n1!x4!n 1!a6!n3!a15d 5n3!a15d 5n3!a15d 1!a6!n3!a15d 1!a6!n3!a15d Content/Options No. 1 2 3 4 5 6 7 8 9 10

May 2005 Standards Release

67

Category 9 - Cash Management & Customer Status

Status -----| O

Tag

Field Name

Content/Options

No.

86

Information to Account Owner M = Mandatory O = Optional

6*65x

12

MT 941 Network Validated Rules
C1 The first two characters of the three character currency code in fields 60F, 90D, 90C, 62F, 64 and 65 must be the same for all occurrences of these fields (Error code(s): C27).

MT 941 Usage Rules
• • This message should only be used if the account owner(s) has (have) authorised the financial institutions to transmit such information. It must be used according to agreed criteria. Financial institutions which receive this message must not use the information for their own purposes.

MT 941 Field Specifications
1. Field 20: Transaction Reference Number (TRN) FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).

68

May 2005 Standards Release

MT 941

2.

Field 21: Related Reference FORMAT 16x PRESENCE Optional DEFINITION If the MT 941 is sent in response to an MT 920 Request Message, this field must contain the field 20 Transaction Reference Number of the request message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).

3.

Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the account for which the balance information is sent. (Account)

4.

Field 28: Statement Number/Sequence Number FORMAT 5n[/2n] PRESENCE Mandatory DEFINITION This field contains the sequential number of the report. USAGE RULES The sequence number is not required. (Statement Number) (Sequence Number)

May 2005 Standards Release

69

Category 9 - Cash Management & Customer Status

5.

Field 13D: Date/Time Indication FORMAT Option D PRESENCE Optional DEFINITION This field indicates the date, time and time zone at which the report was created. NETWORK VALIDATED RULES Date must be a valid date expressed as YYMMDD (Error code(s): T50). Time must be a valid time expressed as HHMM (Error code(s): T38). Sign is either "+" or "-" (Error code(s): T15). Time offset is expressed as 'HHMM', where the hour component, ie, 'HH', must be in the range of 00 through 13, and the minute component, ie, 'MM' must be in the range of 00 through 59. Any 'HH' or 'MM' component outside of these range checks will be disallowed (Error code(s): T16). USAGE RULES The time zone in which Time is expressed is to be identified by means of the offset against the UTC (Coordinated Universal Time - ISO 8601). EXAMPLE If a financial institution in New Zealand creates an MT 941 at 15.15 PM local time on 10 January 2002, Date/Time Indication field would be completed as follows: :13D:0201101515+1300 whereby 020110 is the date, 1515 is the local time in New Zealand and +1300 is the offset of local New Zealand time in January against UTC. Offsets of local time zones against UTC are published in the green section of the BIC Directory. 6!n4!n1!x4!n (Date) (Time) (Sign) (Offset)

6.

Field 60F: Opening Balance FORMAT Option F 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Optional

70

May 2005 Standards Release

MT 941

DEFINITION This field specifies, for the opening balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The opening balance is a credit balance. The opening balance is a debit balance.

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES This field must always be the same as field 62F of the previous statement or balance report. 7. Field 90D: Number and Sum of Entries FORMAT Option D PRESENCE Optional DEFINITION This field indicates the total number and amount of debit entries since the last statement or balance report. NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 5n3!a15d (Number) (Currency) (Amount)

May 2005 Standards Release

71

Category 9 - Cash Management & Customer Status

8.

Field 90C: Number and Sum of Entries FORMAT Option C PRESENCE Optional DEFINITION This field indicates the total number and amount of credit entries since the last statement or balance report. NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 5n3!a15d (Number) (Currency) (Amount)

9.

Field 62F: Closing Balance (Booked Funds) FORMAT Option F 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field contains the closing book balance for the account as of the end of the business day indicated. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing balance is a credit balance. The closing balance is a debit balance.

NETWORK VALIDATED RULES 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).

72

May 2005 Standards Release

MT 941

The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 10. Field 64: Closing Available Balance (Available Funds) FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the account owner (if credit balance) or the balance which is subject to interest charges (if debit balance). CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing available balance is a credit balance. The closing available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 11. Field 65: Forward Available Balance FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the account owner (if a credit or debit balance) for the specified forward value date. (D/C Mark) (Date) (Currency) (Amount)

May 2005 Standards Release

73

Category 9 - Cash Management & Customer Status

CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The forward available balance is a credit balance. The forward available balance is a debit balance.

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES When there is more than one value date for the items booked to the account (in this or previous statement periods), this field will indicate the balance which will be available to the account owner on the date(s) indicated. 12. Field 86: Information to Account Owner FORMAT 6*65x PRESENCE Optional DEFINITION This field contains additional information for the account owner. (Narrative)

MT 941 Examples
Narrative ABN Amro Bank, Amsterdam, in response to an MT 920 Request Message, sends an MT 941 to UBS, Zürich, for account number 6894-77381 of Biodata GmbH, for 04 June 2002 at 15:15 local time. The statement number is 212.

74

May 2005 Standards Release

MT 941

Opening Balance: Total Debits: 72 Total Credits: 44 Closing Book Balance: Closing Available Balance: Forward Available Balance: As of 05 June 2002:

euro euro euro euro euro euro

595,771.95 (Credit) 385,920 450,000 659,851.95 (Credit) 480,525.87 (Credit) 530,691.95 (Credit)

Information Flow

Sender

ABN Amro Bank Amsterdam

MT

MT 920

MT 941

Receiver

UBS Zurich

Biodata GmbH
D0090006

SWIFT Message

Explanation Sender Message Type Receiver ABNANL2A 941 UBSWCHZH80A

Format

May 2005 Standards Release

75

Category 9 - Cash Management & Customer Status

Explanation Message Text Transaction Reference Number Related Reference (MT 920) Account Identification Statement Number Date/Time Indication Opening Balance Number and Sum of Debits Number and Sum of Credits Closing Book Balance Closing Available Balance Forward Available Balance End of Message Text/Trailer :20:234567 :21:765432 :25:6894-77381 :28:212

Format

:13D:0206041515+0200 :60F:C020603EUR595771,95 :90D:72EUR385920, :90C:44EUR450000, :62F:C020604EUR659851,95 :64:C020604EUR480525,87 :65:C020605EUR530691,95

76

May 2005 Standards Release

MT 942

MT 942 Interim Transaction Report
Note: As this message may require the implementation of special procedures, its use is governed by bilateral agreements between correspondents.

MT 942 Scope
This message type is sent by an account servicing institution (reporting institution) to a financial institution (concentrating institution) which has been authorised by the account owner to receive it. It is used to transmit detailed and/or summary information about entries debited or credited to the account since: • • the last statement or balance report, or the last interim transaction report (sent in the period since the last statement or balance report).

MT 942 Format Specifications
MT 942 Interim Transaction Report
Status M O M M M O M -----> O O -----| 61 86 Statement Line Information to Account Owner * 6*65x 8 9 Tag 20 21 25 28C 34F 34F 13D Field Name Transaction Reference Number Related Reference Account Identification Statement Number/Sequence Number Floor Limit Indicator Floor Limit Indicator Date/Time Indication 16x 16x 35x 5n[/5n] 3!a[1!a]15d 3!a[1!a]15d 6!n4!n1!x4!n Content/Options No. 1 2 3 4 5 6 7

May 2005 Standards Release

77

Category 9 - Cash Management & Customer Status

Status O O O

Tag 90D 90C 86

Field Name Number and Sum of Entries Number and Sum of Entries Information to Account Owner M = Mandatory O = Optional * See Field Specifications

Content/Options 5n3!a15d 5n3!a15d 6*65x

No. 10 11 12

MT 942 Network Validated Rules
C1 C2 The first two characters of the three character currency code in fields 34F, 90D, and 90C must be the same (Error code(s): C27). When only one field 34F is present, the second subfield must not be used. When both fields 34F are present, subfield 2 of the first 34F must contain the value ‘D’, and subfield 2 of the second 34F must contain the value ‘C’ (Error code(s): C23).

MT 942 Usage Rules
• • • This message should only be used if the account owner(s) has (have) authorised the financial institutions to transmit such information. It must be used according to agreed criteria. Financial institutions which receive this message must not use the information for their own purposes. It is important that amounts be identical to those of the original transaction. For identification purposes, deductions, eg, charges above and beyond those previously accounted for, shall appear separately with the appropriate code. They shall use the same TRN as the original transaction, or other suitable reference if no TRN is available. Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information for one statement. Depending on financial practice and the agreement(s) between the account servicing institution and the account owner, the items reported in this message may or may not be considered as booked or available funds.

• •

78

May 2005 Standards Release

MT 942

MT 942 Field Specifications
1. Field 20: Transaction Reference Number (TRN) FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES The TRN may be the same or different for the separate messages of an interim report consisting of several messages. 2. Field 21: Related Reference FORMAT 16x PRESENCE Optional DEFINITION If the MT 942 is sent in response to an MT 920 Request Message, this field must contain the field 20 Transaction Reference Number of the request message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 25: Account Identification FORMAT 35x (Account)

May 2005 Standards Release

79

Category 9 - Cash Management & Customer Status

PRESENCE Mandatory DEFINITION This field identifies the account for which the interim transaction report is sent. 4. Field 28C: Statement Number/Sequence Number FORMAT Option C PRESENCE Mandatory DEFINITION This field contains the sequential number of the statement, optionally followed by the sequence number of the message within that statement when more than one message is sent for the statement. USAGE RULES The statement number should be reset to 1 on 1 January of each year. If used, the sequence number always starts with 1. When several messages are sent to convey information about a single statement, the first message must contain ‘/1’ in Sequence Number. The sequence number must be incremented by one for each additional message. Both the statement number and sequence number enable the Receiver to put the different messages into sequence and thus form the complete statement. EXAMPLE The first message of a statement is :28C:235/1 The second message is :28C:235/2 and so on. 5. Field 34F: Floor Limit Indicator (First Occurrence) FORMAT Option F PRESENCE Mandatory 3!a[1!a]15d (Currency) (D/C Mark) (Amount) 5n[/5n] (Statement Number) (Sequence Number)

80

May 2005 Standards Release

MT 942

DEFINITION This field specifies the minimum value (transaction amount) reported in the message. CODES When D/C Mark is present, it must contain the following code (Error code(s): T51):
D Debit floor limit

NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES When the field appears once, the floor limit applies to both debit and credit amounts. When different limits apply, both fields 34F must be present. 6. Field 34F: Floor Limit Indicator (Second Occurrence) FORMAT Option F PRESENCE Conditional (C2) DEFINITION This field specifies the minimum credit value (transaction amount) reported in the message. CODES D/C Mark must contain the following code (Error code(s): T51):
C Credit floor limit

3!a[1!a]15d

(Currency) (D/C Mark) (Amount)

NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

May 2005 Standards Release

81

Category 9 - Cash Management & Customer Status

USAGE RULES When different limits apply, this field 34F must be present, with a credit indicator (‘C’). 7. Field 13D: Date/Time Indication FORMAT Option D PRESENCE Mandatory DEFINITION This field indicates the date, time and time zone at which the report was created. NETWORK VALIDATED RULES Date must be a valid date expressed as YYMMDD (Error code(s): T50). Time must be a valid time expressed as HHMM (Error code(s): T38). Sign is either "+" or "-" (Error code(s): T15). Time offset is expressed as ‘HHMM’, where the hour component, ie, ‘HH’, must be in the range of 00 through 13, and the minute component, ie, ‘MM’ must be in the range of 00 through 59. Any ‘HH’ or ‘MM’ component outside of these range checks will be disallowed (Error code(s): T16). USAGE RULES The time zone in which Time is expressed is to be identified by means of the offset against the UTC (Coordinated Universal Time - ISO 8601). EXAMPLE If a financial institution in New Zealand creates an MT 942 at 15.15 PM local time on 10 January 2002, Date/Time Indication field would be completed as follows: :13D:0201101515+1300 whereby 020110 is the date, 1515 is the local time in New Zealand and +1300 is the offset of local New Zealand time in January against UTC. Offsets of local time zones against UTC are published in the green section of the BIC Directory. 8. Field 61: Statement Line FORMAT 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] 6!n4!n1!x4!n (Date) (Time) (Sign) (Offset)

82

May 2005 Standards Release

MT 942

where: Subfield 1 2 3 4 5 6 7 8 9 PRESENCE Optional DEFINITION This field contains the details of each transaction. CODES Subfield 3, Debit/Credit Mark, must contain one of the following codes (Error code(s): T51):
D C EC ED RC RD Debit Credit Expected credit Expected debit Reversal of credit (debit entry) Reversal of debit (credit entry)

Format 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x] Value Date (YYMMDD) Entry Date (MMDD) Debit/Credit Mark

Name

Funds Code (3rd character of the currency code, if needed) Amount Transaction Type Identification Code Reference for the Account Owner Account Servicing Institution's Reference Supplementary Details

CODES Subfield 6, Transaction Type Identification Code, may be completed in one of three ways (Error code(s): T53):

May 2005 Standards Release

83

Category 9 - Cash Management & Customer Status

1.

For entries related to SWIFT transfer instructions and subsequent charge messages: Format: S3!n The last three characters will indicate the message type of the SWIFT message causing the entry (for debit entries) or the message type of the SWIFT message used to advise the account owner (for credit entries).

2.

For entries related to payment and transfer instructions, including related charges messages, not sent through SWIFT or where an alpha description is preferred. Format: N3!c For entries being first advised by the statement (items originated by the account servicing institution): Format: F3!c

3.

CODES When formats (2) or (3) are used, the last three characters, ie, 3!c, may contain one of the following codes:
BOE BRF CHG CHK CLR CMI CMN CMS CMT CMZ COL COM DCR DDT DIV EQA ECK FEX INT LBX Bill of exchange Brokerage fee Charges and other expenses Cheques Cash letters/Cheques remittance Cash management item - No detail Cash management item - Notional pooling Cash management item - Sweeping Cash management item -Topping Cash management item - Zero balancing Collections (used when entering a principal amount) Commission Documentary credit (used when entering a principal amount) Direct Debit Item Dividends-Warrants Equivalent amount Eurocheques Foreign exchange Interest Lock box

84

May 2005 Standards Release

MT 942

LDP MSC RTI SEC STO TCK TRF VDA

Loan deposit Miscellaneous Returned item Securities (used when entering a principal amount) Standing order Travellers cheques Transfer Value date adjustment (used with an entry made to withdraw an incorrectly dated entry – it will be followed by the correct entry with the relevant code)

NETWORK VALIDATED RULES Subfield 1, Value Date, must be a valid date expressed as YYMMDD (Error code(s): T50). The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). When the first character of subfield 6, Transaction Type Identification Code, is an ‘S’, the remaining characters must be in the range 100-999 (Error code(s): T18). USAGE RULES This field may be repeated within the constraints of the maximum input message length. ‘Original’ advices for charges, ie, the first time the account owner is informed of a charge, must be identified in subfield 6, Transaction Type Identification Code, with the transaction type code ‘FCHG’. The following rules apply to subfield 7, Reference for the Account Owner: • • At least one valid character other than a blank must be present. For debit entries, the purpose of this subfield is to identify, to the account owner, the instruction which caused the debit. Therefore, the content of this subfield is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. Credit entries may be the result of one of the following situations: 1. The account servicing institution is identifying, to the account owner the receipt of funds for its account as a result of a related transaction. In this case, the content of subfield 7, Reference for the Account Owner is the reference for the beneficiary (eg, field 21 Related Reference) of the related transaction. 2. The account servicing institution has issued a payment instruction to the account owner and the credit identified in this subfield is for that payment. The content of subfield 7,

May 2005 Standards Release

85

Category 9 - Cash Management & Customer Status

Reference for the Account Owner is the field 20 Transaction Reference Number (or its equivalent) of the payment instruction issued by the account servicing institution. • If no reference is available for subfield 7, Reference for the Account Owner, the code NONREF shall be used. The account servicing institution must then supply, in subfield 9, Supplementary Details, what it considers to be the best alternative information. This reference must be quoted in all cases when available. In cases where a transaction passes through several financial institutions, the original reference must always be forwarded. This reference must always be quoted against any charges or fees debited by the account servicing institution. Debits against standing instructions must show the reference of the standing instruction. In cases where a mutually agreed alternative reference exists (eg, in foreign exchange or money market transactions), this reference should then be used. If the statement entry concerns a cheque, the cheque number should be indicated in this subfield.

• • • •

The following rules apply to subfield 8, Account Servicing Institution's Reference: • • The content of this subfield is the account servicing institution's own reference for the transaction. When the transaction has been initiated by the account servicing institution, this reference may be identical to subfield 7, Reference for the Account Owner. If this is the case, Account Servicing Institution’s Reference, subfield 8 may be omitted.

The following rules apply to subfield 9, Supplementary Details: • When no reference for the account owner is available, ie, subfield 7, Reference for the Account Owner contains NONREF, the account servicing institution should provide the best available alternative information in this subfield. Supplementary details may be provided when an advice has not been sent for a transaction, or to provide additional information to facilitate reconciliation. This field may include ERI, as specified in the chapter entitled “Euro – Impact on SWIFT Message Standards. This field may contain ERI to transport dual currencies, as explained in the chapter 'Euro Impact on Category 9 Message Standards'. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash.

• • • •

86

May 2005 Standards Release

MT 942

EXAMPLE (1) :61:9805270526C3500,25FCHK304955//4958843 (2) :61:9805270526C3500,25FCHK304955//4958843 ADDITIONAL INFORMATION 9. Field 86: Information to Account Owner FORMAT 6*65x PRESENCE Optional DEFINITION This field contains additional information on the transaction detailed in the preceding statement line which is to be passed on to the account owner. USAGE RULES This field may contain ERI to transport dual currencies, as explained in the chapter ‘Euro Impact on Category 9 Message Standards’. Since the charges field in the customer transfers is repetitive, it may be necessary to report more than one charges amount in the resulting statement. In this case, it is allowed to repeat the code word CHGS before the code word OCMT. The order in which the charges are specified is the same as in the customer transfers, ie, the order in which the charges have been taken during the transaction. So, the last appearance of the code word CHGS always specifies the charges (if any) of the account servicing institution. In order to comply with the EC-directive on cross border credit transfers, the optional code word EXCH may be used to transport an exchange rate. In line with ERI, the code word EXCH is placed between slashes, followed by the exchange rate, format 12d, and terminated with another slash. The code may be repeated if the account servicing institution wants to report an exchange rate that it applied, in addition to the exchange rate received in the instruction. The order in which the exchange rates are specified is the same as the order in which the rates have been applied during the transaction. So, the last appearance of the code word EXCH always specifies the rate applied by the account servicing institution. An ordering party is identified with the preceding code /ORDP/. The information following this code is copied from field 50a of the customer payment order, or field 52a (sender if field 52a is not present) of the financial institution transfer. The code should be used at the beginning of a line. (Narrative)

May 2005 Standards Release

87

Category 9 - Cash Management & Customer Status

In case of a debit item, a beneficiary party may be identified with the preceding code /BENM/. The information following this code is copied from field 59a of the customer payment order, or field 58a of the financial institution transfer. The code should be used at the beginning of a line. In case remittance information from field 70 of the payment instruction is to be included in this field, it should be preceded by the code /REMI/. In case the information in field 72 of the payment instruction is intended for the account owner, it should be copied into field 86 as it is. Codes used in field 72 of the payment instruction have therefore the same meaning in field 86 of the statement. If only free text is used in field 72, it is to be copied as it is since a code in field 86 will not add any value. 10. Field 90D: Number and Sum of Entries FORMAT Option D PRESENCE Optional DEFINITION This field indicates the total number and amount of debit entries. NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 11. Field 90C: Number and Sum of Entries FORMAT Option C PRESENCE Optional DEFINITION This field indicates the total number and amount of credit entries. NETWORK VALIDATED RULES Currency must be a valid ISO 4217 currency code (Error code(s): T52). 5n3!a15d (Number) (Currency) (Amount) 5n3!a15d (Number) (Currency) (Amount)

88

May 2005 Standards Release

MT 942

The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). 12. Field 86: Information to Account Owner FORMAT 6*65x PRESENCE Optional DEFINITION This field contains additional information on the message as a whole which is to be passed to the account owner. (Narrative)

MT 942 Examples
Narrative Merita Bank, Helsinki, in response to an MT 920 Request Message (reference 5678), sends an MT 942 to Midland Bank, London, for account number 123-45678 of Smythe Publications, for 26 June 2002, as of 12:00 Noon.
Debit Floor Limit: Credit Floor Limit: euro 100,000 euro 50,000

Transaction Details:
(1) Value Date: 26 June 2002 Debit: Transaction Type: Collections Reference for the Account Owner: ABCD Merita Bank's Reference: 12345 Value Date: 26 June 2002 Credit: Transaction Type: Foreign Exchange Reference for the Account Owner: 99485 Merita Bank's Reference: 678922 euro 210,000 euro 385,700 EUR 120,000

(2)

EUR 55,000

Total Debits: 9 Total Credits:87

May 2005 Standards Release

89

Category 9 - Cash Management & Customer Status

Information Flow

Sender

Merita Bank Helsinki

MT

MT 920

MT 942

Receiver

Midland Bank London

Smythe Publications
D0090007

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Related Reference (MT 920) Account Identification Entry Number/Page Number Debit Floor Limit Credit Floor Limit :20:345678 :21:5678 :25:123-45678 :28C:124/1 :34F:EURD100000, :34F:EURC50000, MRITFIHH 942 MIDLGB22

Format

90

May 2005 Standards Release

MT 942

Explanation Date/Time Indication 1st Transaction 2nd Transaction Number and Sum of Debits Number and Sum of Credits End of Message Text/Trailer

Format :13D:0206261200+300 :61:020626D120000,NCOLABCD//12345 :61:020626C55000,NFEX99485//678922 :90D:9EUR210000, :90C:87EUR385700,

May 2005 Standards Release

91

Category 9 - Cash Management & Customer Status

MT 950 Statement Message
MT 950 Scope
This message type is sent by an account servicing institution to an account owner. It is used to transmit detailed information about all entries, whether or not caused by a SWIFT message, booked to the account.

MT 950 Format Specifications
MT 950 Statement Message
Status M M M M -----> O -----| M O 62a 64 Closing Balance (Booked Funds) Closing Available Balance (Available Funds) M = Mandatory O = Optional * See the Field Specifications below. F or M 1!a6!n3!a15d 6 7 61 Statement Line * 5 Tag 20 25 28C 60a Field Name Transaction Reference Number Account Identification Statement Number/Sequence Number Opening Balance 16x 35x 5n[/5n] F or M Content/Options No. 1 2 3 4

MT 950 Network Validated Rules
C1 The first two characters of the three character currency code in fields 60a, 62a and 64 must be the same (Error code(s): C27).

MT 950 Usage Rules
• Charges, interest and other adjustments may be referenced as follows:

92

May 2005 Standards Release

MT 950

-

By reference to a previous MT n90 Advice of Charges, Interest and Other Adjustments message (for information regarding the formatting of the MTn90, see Category n – Common Group Messages). By original advice via this statement, under the following conditions: The charges must be unambiguously identified with a single associated underlying transaction, eg, the account owner's reference of the original transaction. The principal amount must be separately identified on the statement. The required references must fit the constraints of the statement line.

-

It is important that amounts should be identical to those of related messages. Charges which are clearly indicated in another message concerning the same entry, or which form an integral part of another message, eg, proceeds of a collection, do not need to be specifically indicated in the statement. Deductions, eg, charges, above and beyond those previously accounted for in a related message shall appear separately with the appropriate code. They shall use the same reference for the account owner or other suitable reference if no reference for the account owner is available. The account servicing institution must not ‘bulk’ separate transactions, charges, or charges with transactions. When booking multiple messages, individual transactions, eg, one entry per TRN (field 20), must be booked. It is recommended that statements be sent daily, ie, at the end of each business day, when movement in the account has occurred. If no movement has occurred, ie, no entries have been posted, it is recommended that the statement frequency should be monthly, and that the maximum interval between statements should not exceed one year. To facilitate manual reconciliation, it is recommended that statement entries be sorted by debits and credits and these by value date in ascending amounts. Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information for one statement.

• •

MT 950 Field Specifications
1. Field 20: Transaction Reference Number (TRN) FORMAT 16x PRESENCE Mandatory

May 2005 Standards Release

93

Category 9 - Cash Management & Customer Status

DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES The TRN may be the same or different for the separate messages of a statement consisting of several messages. 2. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the account for which the statement is sent. 3. Field 28C: Statement Number/Sequence Number FORMAT Option C PRESENCE Mandatory DEFINITION This field contains the sequential number of the statement, optionally followed by the sequence number of the message within that statement when more than one message is sent for the statement. EXAMPLE The first message of a statement is :28C:235/1 The second messsage is :28C:235/2 and so on. 5n[/5n] (Statement Number) (Sequence Number) (Account)

94

May 2005 Standards Release

MT 950

4.

Field 60a: Opening Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) opening balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) opening balance is a credit balance. The (intermediate) opening balance is a debit balance.

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES This field must always be the same as field 62a (closing balance) of the previous statement message for this account. The first statement message for a specified period must contain field 60F (first opening balance); additional statement messages for the same statement period must contain field 60M (intermediate opening balance).

May 2005 Standards Release

95

Category 9 - Cash Management & Customer Status

5.

Field 61: Statement Line FORMAT 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] where: Subfield 1 2 3 4 5 6 7 8 9 PRESENCE Optional DEFINITION This field contains the details of each transaction. CODES Subfield 3, Debit/Credit Mark, must contain one of the following codes (Error code(s): T51):
D C RC RD Debit Credit Reversal of credit (debit entry) Reversal of debit (credit entry)

Format 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x] Value Date (YYMMDD) Entry Date (MMDD) Debit/Credit Mark

Name

Funds Code (3rd character of the currency code, if needed) Amount Transaction Type Identification Code Reference for the Account Owner Account Servicing Institution's Reference Supplementary Details

96

May 2005 Standards Release

MT 950

CODES Subfield 6, Transaction Type Identification Code, may be completed in one of three ways (Error code(s): T53):
1. For entries related to SWIFT transfer instructions and subsequent charge messages: Format: S3!n The last three characters will indicate the message type of the SWIFT message causing the entry (for debit entries) or the message type of the SWIFT message used to advise the account owner (for credit entries). 2. For entries related to payment and transfer instructions, including related charges messages, not sent through SWIFT or where an alpha description is preferred. Format: 3. N3!c For entries being first advised by the statement (items originated by the account servicing institution): Format: F3!c

CODES When formats (2) or (3) are used, the last three characters, ie, 3!c, may contain one of the following codes:
BOE BRF CHG CHK CLR CMI CMN CMS CMT CMZ COL COM DCR DDT DIV ECK EQA Bill of exchange Brokerage fee Charges and other expenses Cheques Cash letters/Cheques remittance Cash management item - No detail Cash management item - Notional pooling Cash management item - Sweeping Cash management item -Topping Cash management item - Zero balancing Collections (used when entering a principal amount) Commission Documentary credit (used when entering a principal amount) Direct Debit Item Dividends–Warrants Eurocheques Equivalent amount

May 2005 Standards Release

97

Category 9 - Cash Management & Customer Status

FEX INT LBX LDP MSC RTI SEC STO TCK TRF VDA

Foreign exchange Interest Lock box Loan deposit Miscellaneous Returned item Securities (used when entering a principal amount) Standing order Travellers cheques Transfer Value date adjustment (used with an entry made to withdraw an incorrectly dated entry – it will be followed by the correct entry with the relevant code)

NETWORK VALIDATED RULES Subfield 1, Value Date, must be a valid date expressed as YYMMDD (Error code(s): T50). The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). When the first character of subfield 6, Transaction Type Identification Code, is an ‘S’, the remaining characters must be in the range 100-999 (Error code(s): T18). USAGE RULES This field may be repeated within the constraints of the maximum input message length. ‘Original’ advices for charges, ie, the first time the account owner is informed of a charge, must be identified in subfield 6, Transaction Type Identification Code, with the transaction type code ‘FCHG’. The following rules apply to subfield 7, Reference for the Account Owner: • • At least one valid character other than a blank must be present. For debit entries, the purpose of this subfield is to identify, to the account owner, the instruction which caused the debit. Therefore, the content of this subfield is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. Credit entries may be the result of one of the following situations: 1. The account servicing institution is identifying, to the account owner the receipt of funds for its account as a result of a related transaction. In this case, the content of subfield 7,

98

May 2005 Standards Release

MT 950

Reference for the Account Owner is the reference for the beneficiary (eg, field 21 Related Reference) of the related transaction. 2. The account servicing institution has issued a payment instruction to the account owner and the credit identified in this subfield is for that payment. The content of subfield 7, Reference for the Account Owner is the field 20 Transaction Reference Number (or its equivalent) of the payment instruction issued by the account servicing institution. • If no reference is available for subfield 7, Reference for the Account Owner, the code NONREF shall be used. The account servicing institution must then supply, in subfield 9, Supplementary Details, what it considers to be the best alternative information. This reference must be quoted in all cases when available. In cases where a transaction passes through several financial institutions, the original reference must always be forwarded. This reference must always be quoted against any charges or fees debited by the account servicing institution. Debits against standing instructions must show the reference of the standing instruction. In cases where a mutually agreed alternative reference exists (eg, in foreign exchange or money market transactions), this reference should then be used. If the statement entry concerns a cheque, the cheque number should be indicated in this subfield.

• • • •

The following rules apply to subfield 8, Account Servicing Institution's Reference: • • The content of this subfield is the account servicing institution's own reference for the transaction. When the transaction has been initiated by the account servicing institution, this reference may be identical to subfield 7, Reference for the Account Owner. If this is the case, Account Servicing Institution’s Reference, subfield 8 may be omitted.

The following rules apply to subfield 9, Supplementary Details: • When no reference for the account owner is available, ie, subfield 7, Reference for the Account Owner contains NONREF, the account servicing institution should provide the best available alternative information in this subfield. Supplementary details may be provided when an advice has not been sent for a transaction, or to provide additional information to facilitate reconciliation.

EXAMPLE (1) :61:9805270526C3500,25FCHK304955//4958843 (2) :61:9805270526C3500,25FCHK304955//4958843 ADDITIONAL INFORMATION

May 2005 Standards Release

99

Category 9 - Cash Management & Customer Status

6.

Field 62a: Closing Balance (Booked Funds) FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) closing balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) closing balance is a credit balance. The (intermediate) closing balance is a debit balance.

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES The contents of this field will be repeated in field 60a of the subsequent statement message for this account. If there is only one statement message transmitted for the period, this field must use tag option F, ie, 62F (final closing balance). When several messages are transmitted for the same statement period, all messages except the last message must contain field 62M (intermediate closing balance); the last message of the statement must contain field 62F.

100

May 2005 Standards Release

MT 950

7.

Field 64: Closing Available Balance (Available Funds) FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the account owner (if credit balance) or the balance which is subject to interest charges (if debit balance). CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing available balance is a credit balance. The closing available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

MT 950 Examples
Narrative On 28 May, 2002, ABN Amro Bank, Amsterdam, sends a statement of account to UBS, Zürich. The statement contains the following information: Account Number 123-456789 Statement Number 102 Opening Balance: euro (EUR) 3,723,495 (Credit) Transaction Details:

May 2005 Standards Release

101

Category 9 - Cash Management & Customer Status

(1)

Value Date: 28-05-02 Transaction Type: Cheque Reference for the Account Owner: 78911 ABN's Reference: 123464

Debit: EUR 30.2

(2)

Value Date: 28-05-02 Transaction Type: Cheque Reference for the Account Owner: 67822 ABN's Reference: 123460

Debit: EUR 250

(3)

Value Date: 28-05-02 Transaction Type: SWIFT MT 103 Reference for the Account Owner: 494933/DEV ABN's Reference: PO64118 Details: Favour K. DESMID

Debit: EUR 450

(4)

Value Date: 28-05-02 Transaction Type: Cheque Reference for the Account Owner: 45633 ABN's Reference: 123456

Debit: EUR 500

(5)

Value Date: 28-05-02 Transaction Type: Cheque Reference for the Account Owner: 56728 ABN's Reference: 123457

Debit: EUR 2,500

(6)

Value Date: 28-05-02 Transaction Type: SWIFT MT 200 Reference for the Account Owner: 23/200516 ABN's Reference: 47829 Details: Order Rotterdam

Debit: EUR 5,000

(7)

Value Date: 28-05-02 Transaction Type: First time charge

Debit: EUR 1.2

102

May 2005 Standards Release

MT 950

Reference for the Account Owner: 494935/DEV ABN's Reference: 67914 (8) Value Date: 28-05-02 Transaction Type: SWIFT MT 103 Reference for the Account Owner: 494931 ABN's Reference: 3841188 Details: Favour H. F. Janssen (9) Value Date: 28-05-02 Transaction Type: SWIFT MT 103 Reference for the Account Owner: 494935 ABN's Reference: 3841189 Details: Favour H. F. Janssen Closing Book Balance: EUR 3709865,13 (Credit) Debit: EUR 3,840 Debit: EUR 1,058.47

Information Flow

Sender

ABN Amro Bank Amsterdam

MT

MT 950

Receiver

May 2005 Standards Release

D0090008

UBS Zurich

103

Category 9 - Cash Management & Customer Status

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Account Identification Statement Number Opening Balance 1st Transaction 2nd Transaction 3rd Transaction 4th Transaction 5th Transaction 6th Transaction 7th Transaction 8th Transaction 9th Transaction Closing Balance End of Message Text/Trailer :20:123456 :25:123-456789 :28C:102 ABNANL2A 950 UBSWCHZH80A

Format

:60F:C020527EUR3723495, :61:020528D1,2FCHG494935/DEV//67914 :61:020528D30,2NCHK78911//123464 :61:020528D250,NCHK67822//123460 :61:020528D450,S103494933/DEV//PO64118 FAVOUR K. DESMID :61:020528D500,NCHK45633//123456 :61:020528D1058,47S103494931//3841188 FAVOUR H.F. JANSSEN :61:020528D2500,NCHK56728//123457 :61:020528D3840,S103494935//3841189 FAVOUR H.F. JANSSEN :61:020528D5000,S20023/200516//47829 ORDER ROTTERDAM :62F:C020528EUR3709865,13

Note:The transactions appear in the message sorted in ascending amounts, and therefore the order does not correspond to the order in which they are listed in the narrative description of this example.

104

May 2005 Standards Release

MT 960

MT 960 Request for Service Initiation Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 960 Scope
This message is sent from one SWIFT user to another SWIFT user to initiate a Bilateral Key Exchange (BKE) process. The request in this message is an RSI class Cryptographic Service Message.

MT 960 Format Specifications
MT 960 Request for Service Initiation Message
Status M O M Tag 20 79 91A Field Name Transaction Reference Number Narrative Request for Service Initiation M = Mandatory O = Optional *See Field Specifications Content/Options 16x 35*50x * No. 1 2 3

MT 960 Network Validated Rules
There are no network validated rules for this message type.

MT 960 Guidelines
• If the request is agreed, the Receiver of the MT 960 must return the requested certificate using an MT 961, otherwise the request is rejected.

May 2005 Standards Release

105

Category 9 - Cash Management & Customer Status

MT 960 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 79: Narrative FORMAT 35*50x PRESENCE Optional DEFINITION This field contains information in narrative form. 3. Field 91A: Request for Service Initiation FORMAT Option A CSM(MCL/RSI1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e SVR/CVO) (Narrative)

PRESENCE Mandatory

106

May 2005 Standards Release

MT 960

DEFINITION This field contains a request.

May 2005 Standards Release

107

Category 9 - Cash Management & Customer Status

MT 961 Initiation Response Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 961 Scope
This message is sent by the Receiver of an MT 960 Request for Service Initiation Message to the Sender of the MT 960 to acknowledge receipt of the request and to deliver a certificate in order to continue the Bilateral Key Exchange process. The acknowledgement in this message is an RSM class of Cryptographic Service Message.

MT 961 Format Specifications
MT 961 Initiation Response Message
Status M M M Tag 20 21 91B Field Name Transaction Reference Number Related Reference Response Service Message M = Mandatory O = Optional *See Field Specifications 16x 16x * Content/Options No. 1 2 3

MT 961 Network Validated Rules
There are no network validated rules for this message type.

MT 961 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory

108

May 2005 Standards Release

MT 961

DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the content of field 20 Transaction Reference Number of the MT 960 to which it responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 91B: Response Service Message FORMAT Option B CSM(MCL/RSM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e CV/160-288h)

PRESENCE Mandatory DEFINITION This field contains a response message.

May 2005 Standards Release

109

Category 9 - Cash Management & Customer Status

MT 962 Key Service Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 962 Scope
This message is sent by the Receiver of an MT 961 Initiation Response Message to the Sender of the MT 961 to send a bilateral authenticator key as part of the bilateral key exchange process. The bilateral key in enciphered form in this message is contained in a KSM class Cryptographic Service Message.

MT 962 Format Specifications
MT 962 Key Service Message
Status M M M Tag 20 21 91C Field Name Transaction Reference Number Related Reference Key Service Message M = Mandatory O = Optional *See Field Specifications 16x 16x * Content/Options No. 1 2 3

MT 962 Network Validated Rules
There are no network validated rules for this message type.

MT 962 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory

110

May 2005 Standards Release

MT 962

DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the content of field 20 Transaction Reference Number of the MT 961 to which it responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 91C: Key Service Message FORMAT Option C CSM(MCL/KSM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e CV/160-288h1!e BE/128-256h1!e BES/128-256h1!e ND/.1!n.16!c1!e EDK/12!n1!e CTP/14h1!e MAC/4!h1!e4!h)

PRESENCE Mandatory

May 2005 Standards Release

111

Category 9 - Cash Management & Customer Status

DEFINITION This field contains a key service message.

112

May 2005 Standards Release

MT 963

MT 963 Key Acknowledgement Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 963 Scope
This message is sent by the Receiver of an MT 962 Key Service Message to acknowledge receipt of the bilateral key. This acknowledgement is an RSM class Cryptographic Service Message.

MT 963 Format Specifications
MT 963 Key Acknowledgement Message
Status M M M Tag 20 21 91D Field Name Transaction Reference Number Related Reference Response Service Message M = Mandatory O = Optional *See Field Specifications 16x 16x * Content/Options No. 1 2 3

MT 963 Network Validated Rules
There are no network validated rules for this message type.

MT 963 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory

May 2005 Standards Release

113

Category 9 - Cash Management & Customer Status

DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the contents of field 20 Transaction Reference Number of the MT 962 to which it responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 91D: Response Service Message FORMAT Option D CSM(MCL/RSM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e MAC/4!h1!e4!h)

PRESENCE Mandatory DEFINITION This field contains a response service message.

114

May 2005 Standards Release

MT 964

MT 964 Error Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 964 Scope
This message is sent by the Receiver of an MT 960 Request for Service Initiation Message, MT 961 Initiation Response Message, MT 963 Key Acknowledgement Message, MT 966 Discontinue Service Message or MT 967 Discontinuation Acknowledgement Message to the Sender if an error has been detected in that message. The error code is contained in an ESM class Cryptographic Service Message.

MT 964 Format Specifications
MT 964 Error Message
Status M M M M Tag 20 21 79 91E Field Name Transaction Reference Number Related Reference Additional Error Comments Error on RSI, RSM or DSM M = Mandatory O = Optional *See Field Specifications 16x 16x 35*50x * Content/Options No. 1 2 3 4

MT 964 Network Validated Rules
There are no network validated rules for this message type.

MT 964 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x

May 2005 Standards Release

115

Category 9 - Cash Management & Customer Status

PRESENCE Mandatory DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the contents of field 20 Transaction Reference Number of the MT 960, MT 961, MT 963, MT 966 or MT 967 to which this message responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 79: Additional Error Comments FORMAT 35*50x PRESENCE Mandatory DEFINITION This field must be used to add comments on the error code(s) contained in field 91E. USAGE RULES Use of this field may require manual intervention by the Receiver. (Narrative)

116

May 2005 Standards Release

MT 964

4.

Field 91E: Error on RSI, RSM or DSM FORMAT Option E CSM(MCL/ESM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e [IDA/16!c1!e] ERF/1!a[15a])

PRESENCE Mandatory DEFINITION This field contains an error message.

May 2005 Standards Release

117

Category 9 - Cash Management & Customer Status

MT 965 Error in Key Service Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 965 Scope
This message is sent by the Receiver of an MT 962 Key Service Message to the Sender if an error has been detected in that message. The error code is contained in an ESM class Cryptographic Service Message.

MT 965 Format Specifications
MT 965 Error in Key Service Message
Status M M M M Tag 20 21 79 91F Field Name Transaction Reference Number Related Reference Additional Error Comments Error on KSM M = Mandatory O = Optional *See Field Specifications 16x 16x 35*50x * Content/Options No. 1 2 3 4

MT 965 Network Validated Rules
There are no network validated rules for this message type.

MT 965 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory

118

May 2005 Standards Release

MT 965

DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the contents of field 20 Transaction Reference Number of the MT 962 to which this message responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 79: Additional Error Comments FORMAT 35*50x PRESENCE Mandatory DEFINITION This field must be used to add comments on the error code(s) contained in field 91F. USAGE RULES Use of this field may require manual intervention by the Receiver. (Narrative)

May 2005 Standards Release

119

Category 9 - Cash Management & Customer Status

4.

Field 91F: Error on KSM FORMAT Option F CSM(MCL/ESM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e IDA/16!c1!e CTP/14h1!e [CTR/14h1!e] ERF/1!a[15a])

PRESENCE Mandatory DEFINITION This field contains an error in key service message.

120

May 2005 Standards Release

MT 966

MT 966 Discontinue Service Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 966 Scope
This message is sent by a financial institution to another financial institution with which it has exchanged bilateral keys. It is used to discontinue one or several bilateral authenticator keys already in existence between the Sender and Receiver. The identification of the keys to be discontinued are contained in a DSM class Cryptographic Service Message.

MT 966 Format Specifications
MT 966 Discontinue Service Message
Status M O M Tag 20 79 91G Field Name Transaction Reference Number Additional Comments Discontinue Service Message M = Mandatory O = Optional *See Field Specifications 16x 35*50x * Content/Options No. 1 2 3

MT 966 Network Validated Rules
There are no network validated rules for this message type.

MT 966 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory

May 2005 Standards Release

121

Category 9 - Cash Management & Customer Status

DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 79: Additional Comments FORMAT 35*50x PRESENCE Optional DEFINITION This field should be used to add comments on the discontinuation of keys in field 91G. USAGE RULES Use of this field may require manual intervention by the Receiver. 3. Field 91G: Discontinue Service Message FORMAT Option G CSM(MCL/DSM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e IDD/[16!c]1!e [IDD/[16!c]1!e]0-5 IDA/16!c1!e MAC/4!h1!e4!h) (Narrative)

PRESENCE Mandatory DEFINITION This field contains a discontinue service message

122

May 2005 Standards Release

MT 967

MT 967 Discontinuation Acknowledgement Message
Note: This message may only be sent between financial institutions in an automated exchange of authenticator keys.

MT 967 Scope
This message is sent by the Receiver of an MT 966 Discontinue Service Message to the Sender. It is used to acknowledge receipt of the previous MT 966 and confirms discontinuation of the authenticator key(s) specified in the MT 966.

MT 967 Format Specifications
MT 967 Discontinuation Acknowledgement Message
Status M M O M Tag 20 21 79 91H Field Name Transaction Reference Number Related Reference Additional Comments Response Service Message M = Mandatory O = Optional *See Field Specifications 16x 16x 35*50x * Content/Options No. 1 2 3 4

MT 967 Network Validated Rules
There are no network validated rules for this message type.

MT 967 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x

May 2005 Standards Release

123

Category 9 - Cash Management & Customer Status

PRESENCE Mandatory DEFINITION This field specifies a reference assigned by the Sender to identify the key exchange. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES It is recommended that the TRN be assigned as a common reference for all messages initiated during a bilateral key exchange. 2. Field 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the contents of field 20 Transaction Reference Number of the MT 966 to which this message responds. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 79: Additional Comments FORMAT 35*50x PRESENCE Optional DEFINITION This field should be used to add comments on the discontinuation of keys in field 91H. USAGE RULES Use of this field may require manual intervention by the Receiver. (Narrative)

124

May 2005 Standards Release

MT 967

4.

Field 91H: Response Service Message FORMAT Option H CSM(MCL/RSM1!e RCV/4!a[2!a[2!c[8c]]]1!e ORG/4!a[2!a[2!c[8c]]]1!e IDD/[16!c]1!e IDD/[16!c]1!e]0-5 MAC/4!h1!e4!h)

PRESENCE Mandatory DEFINITION This field contains a response service message.

May 2005 Standards Release

125

Category 9 - Cash Management & Customer Status

MT 970 Netting Statement
Note: This message may only be sent and received after prior arrangement between a user and SWIFT

MT 970 Scope
This message type is sent at pre-arranged times from a netting system to a subscriber to the netting system. It is used to provide detailed information about all the transactions which have been recorded by the netting system involving the receiving financial institution. All transactions are reported once only in an MT 970 Netting Statement.

MT 970 Format Specifications
MT 970 Netting Statement
Status M M M M -----> O -----| M O 62a 64 Closing Balance Closing Available Balance M = Mandatory O = Optional *See the Field Specifications below. F or M 1!a6!n3!a15d 6 7 61 Statement Line * 5 Tag 20 25 28C 60a Field Name Transaction Reference Number Account Identification Statement Number/Sequence Number Opening Balance 16x 35x 5n[/5n] F or M Content/Options No. 1 2 3 4

126

May 2005 Standards Release

MT 970

MT 970 Network Validated Rules
C1 The first two characters of the three character currency code in fields 60a, 62a and 64 must be the same (Error code(s): C27).

MT 970 Usage Rules
• • Entries must be sorted by ascending amount, within debits and credits. Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information in one statement.

MT 970 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies a reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES The TRN may be the same or different for the separate messages of a netting statement consisting of several messages. 2. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory

May 2005 Standards Release

127

Category 9 - Cash Management & Customer Status

DEFINITION This field identifies the netting position for which the netting statement is sent. 3. Field 28C: Statement Number/Sequence Number FORMAT Option C PRESENCE Mandatory DEFINITION This field contains the statement number of the netting statement, optionally followed by the sequence number of the message within that statement, when more than one message is sent for the statement. EXAMPLE The first message of a statement is :28C:235/1 The second messsage is :28C:235/2 and so on. 4. Field 60a: Opening Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount) 5n[/5n] (Statement Number) (Sequence Number)

PRESENCE Mandatory DEFINITION This field specifies for the (intermediate) opening balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) opening balance is a credit balance. The (intermediate) opening balance is a debit balance.

128

May 2005 Standards Release

MT 970

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES This field must always be the same as field 62a (closing balance) of the previous netting statement message (if any) for this netting position. The first netting statement message of a statement must contain field 60F (first opening balance). Subsequent messages of the same statement must contain field 60M (intermediate opening balance). 5. Field 61: Statement Line FORMAT 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] where: Subfield 1 2 3 4 5 6 7 8 9 Format 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x] Value Date (YYMMDD) Entry Date (MMDD) Debit/Credit Mark Funds Code (3rd character of the currency code, if needed) Amount Transaction Type Identification Code Reference for the Account Owner Account Servicing Institution's Reference Supplementary Details Name

May 2005 Standards Release

129

Category 9 - Cash Management & Customer Status

PRESENCE Optional DEFINITION This field contains the details of each transaction. CODES Subfield 3, Debit/Credit Mark, must contain one of the following codes (Error code(s): T51):
D C RC RD Debit Credit Reversal of credit (debit entry) Reversal of debit (credit entry)

CODES Subfield 6, Transaction Type Identification Code, may be completed in one of three ways (Error code(s): T53):
1. For entries related to SWIFT transfer instructions and subsequent charge messages: Format: S3!n The last three characters will indicate the message type of the SWIFT message causing the entry (for debit entries) or the message type of the SWIFT message used to advise the account owner (for credit entries). 2. For entries related to payment and transfer instructions, including related charges messages, not sent through SWIFT or where an alpha description is preferred. Format: 3. N3!c For entries being first advised by the statement (items originated by the account servicing institution): Format: F3!c

CODES When formats (2) or (3) are used, the last three characters, ie, 3!c, may contain one of the following codes:
BOE BRF CHG CHK CLR Bill of exchange Brokerage fee Charges and other expenses Cheques Cash letters/Cheques remittance

130

May 2005 Standards Release

MT 970

CMI CMN CMS CMT CMZ COL COM DCR DDT DIV ECK EQA FEX INT LBX LDP MSC RTI SEC STO TCK TRF VDA

Cash management item - No detail Cash management item - Notional pooling Cash management item - Sweeping Cash management item -Topping Cash management item - Zero balancing Collections (used when entering a principal amount) Commission Documentary credit (used when entering a principal amount) Direct Debit Item Dividends-Warrants Eurocheques Equivalent amount Foreign exchange Interest Lock box Loan deposit Miscellaneous Returned item Securities (used when entering a principal amount) Standing order Travellers cheques Transfer Value date adjustment (used with an entry made to withdraw an incorrectly dated entry – it will be followed by the correct entry with the relevant code)

NETWORK VALIDATED RULES Subfield 1, Value Date, must be a valid date expressed as YYMMDD (Error code(s): T50). The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). When the first character of subfield 6, Transaction Type Identification Code, is an ‘S’, the remaining characters must be in the range 100-999 (Error code(s): T18). USAGE RULES This field may be repeated within the constraints of the maximum input message length.

May 2005 Standards Release

131

Category 9 - Cash Management & Customer Status

‘Original’ advices for charges, ie, the first time the account owner is informed of a charge, must be identified in subfield 6, Transaction Type Identification Code, with the transaction type code ‘FCHG’. The following rules apply to subfield 7, Reference for the Account Owner: • • At least one valid character other than a blank must be present. For debit entries, the purpose of this subfield is to identify, to the account owner, the instruction which caused the debit. Therefore, the content of this subfield is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. Credit entries may be the result of one of the following situations: 1. The account servicing institution is identifying, to the account owner the receipt of funds for its account as a result of a related transaction. In this case, the content of subfield 7, Reference for the Account Owner is the reference for the beneficiary (eg, field 21 Related Reference) of the related transaction. 2. The account servicing institution has issued a payment instruction to the account owner and the credit identified in this subfield is for that payment. The content of subfield 7, Reference for the Account Owner is the field 20 Transaction Reference Number (or its equivalent) of the payment instruction issued by the account servicing institution. • If no reference is available for subfield 7, Reference for the Account Owner, the code NONREF shall be used. The account servicing institution must then supply, in subfield 9, Supplementary Details, what it considers to be the best alternative information. This reference must be quoted in all cases when available. In cases where a transaction passes through several financial institutions, the original reference must always be forwarded. This reference must always be quoted against any charges or fees debited by the account servicing institution. Debits against standing instructions must show the reference of the standing instruction. In cases where a mutually agreed alternative reference exists (eg, in foreign exchange or money market transactions), this reference should then be used. If the statement entry concerns a cheque, the cheque number should be indicated in this subfield.

• • • •

The following rules apply to subfield 8, Account Servicing Institution's Reference: • The content of this subfield is the account servicing institution's own reference for the transaction.

132

May 2005 Standards Release

MT 970

When the transaction has been initiated by the account servicing institution, this reference may be identical to subfield 7, Reference for the Account Owner. If this is the case, Account Servicing Institution’s Reference, subfield 8 may be omitted.

The following rules apply to subfield 9, Supplementary Details: • When no reference for the account owner is available, ie, subfield 7, Reference for the Account Owner contains NONREF, the account servicing institution should provide the best available alternative information in this subfield. Supplementary details may be provided when an advice has not been sent for a transaction, or to provide additional information to facilitate reconciliation.

EXAMPLE (1) :61:9805270526C3500,25FCHK304955//4958843 (2) :61:9805270526C3500,25FCHK304955//4958843 ADDITIONAL INFORMATION 6. Field 62a: Closing Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) closing balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) closing balance is a credit balance. The (intermediate) closing balance is a debit balance.

NETWORK VALIDATED RULES 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).

May 2005 Standards Release

133

Category 9 - Cash Management & Customer Status

The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES The content of this field will be repeated in field 60a of the subsequent netting statement message for this netting position. All netting statement messages of a statement, except the last message, must contain field 62M (intermediate closing balance); the last message of the statement must contain field 62F (final closing balance). 7. Field 64: Closing Available Balance FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the Receiver (if credit balance) or the balance which is subject to interest charges (if debit balance). CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing available balance is a credit balance. The closing available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

134

May 2005 Standards Release

MT 970

MT 970 Examples
For examples of this message type, please refer to the Service Description of the netting system concerned.

May 2005 Standards Release

135

Category 9 - Cash Management & Customer Status

MT 971 Netting Balance Report
Note: This message may only be sent and received after prior arrangement between a user and SWIFT

MT 971 Scope
This message type is sent, on request or at pre-arranged times, from a netting system to a subscriber to the netting system and to other authorised receivers. It is used to advise the netting balance(s), at the time of transmission, for one or more financial institutions.

MT 971 Format Specifications
MT 971 Netting Balance Report
Status M -----> M M -----| M = Mandatory O = Optional 25 62F Account Identification Final Closing Balance 35x 1!a6!n3!a15d 2 3 Tag 20 Field Name Transaction Reference Number 16x Content/Options No. 1

MT 971 Network Validated Rules
There are no network validated rules for this message type.

MT 971 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x

136

May 2005 Standards Release

MT 971

PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify this message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the netting position for which the balance is being sent. 3. Field 62F: Final Closing Balance FORMAT Option F PRESENCE Mandatory DEFINITION This field contains the balance for the netting position identified in field 25. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The final closing balance is a credit balance. The final closing balance is a debit balance.

1!a6!n3!a15d

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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).

May 2005 Standards Release

137

Category 9 - Cash Management & Customer Status

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

MT 971 Examples
For examples of this message type, please refer to the Service Description for the netting system concerned.

138

May 2005 Standards Release

MT 972

MT 972 Netting Interim Statement
Note: This message may only be sent and received after prior arrangement between a user and SWIFT

MT 972 Scope
This message type is sent, on request or at pre-arranged times, from a netting system to a subscriber to the netting system. It is used to provide detailed information about transactions which have been recorded by the netting system involving the receiving financial institution.

MT 972 Format Specifications
MT 972 Netting Interim Statement
Status M M M M -----> O -----| M O 62a 64 Closing Balance Closing Available Balance M = Mandatory O = Optional * See the Field Specifications below. F or M 1!a6!n3!a15d 6 7 61 Statement Line * 5 Tag 20 25 28C 60a Field Name Transaction Reference Number Account Identification Statement Number/Sequence Number Opening Balance 16x 35x 5n[/5n] F or M Content/Options No. 1 2 3 4

MT 972 Network Validated Rules
C1 The first two characters of the three character currency code in fields 60a, 62a and 64 must be the same (Error code(s): C27).

May 2005 Standards Release

139

Category 9 - Cash Management & Customer Status

MT 972 Usage Rules
• • • Transactions may appear in more than one netting interim statement if more than one is generated for the same netting position. Entries must be sorted by ascending amount, within debits and credits. Since the length of a SWIFT message is restricted to the maximum input length, several messages may be required to accommodate all the information for one statement.

MT 972 Field Specifications
1. Field 20: Transaction Reference Number (TRN) FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify this message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). USAGE RULES The TRN may be the same or different for the separate messages of a netting statement consisting of several messages. 2. Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the netting position for which the netting interim statement is sent.

140

May 2005 Standards Release

MT 972

3.

Field 28C: Statement Number/Sequence Number FORMAT Option C PRESENCE Mandatory DEFINITION This field contains the statement number of the netting interim statement, optionally followed by the sequence number of the message within the statement, when more than one message is sent for the statement. EXAMPLE The first message of a statement is :28C:235/1 The second messsage is :28C:235/2 and so on. 5n[/5n] (Statement Number) (Sequence Number)

4.

Field 60a: Opening Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) opening balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) opening balance is a credit balance. The (intermediate) opening balance is a debit balance.

NETWORK VALIDATED RULES 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).

May 2005 Standards Release

141

Category 9 - Cash Management & Customer Status

The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES This field must always be the same as field 62a (closing balance) of the previous netting interim statement message for this netting position. The first netting interim statement message of a statement must contain field 60F (first opening balance); subsequent messages of the same statement must contain field 60M (intermediate opening balance). 5. Field 61: Statement Line FORMAT 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] where: Subfield 1 2 3 4 5 6 7 8 9 PRESENCE Optional Format 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x] Value Date (YYMMDD) Entry Date (MMDD) Debit/Credit Mark Funds Code (3rd character of the currency code, if needed) Amount Transaction Type Identification Code Reference for the Account Owner Account Servicing Institution's Reference Supplementary Details Name

142

May 2005 Standards Release

MT 972

DEFINITION This field contains the details of each transaction. CODES Subfield 3, Debit/Credit Mark, must contain one of the following codes (Error code(s): T51):
D C RC RD Debit Credit Reversal of credit (debit entry) Reversal of debit (credit entry)

CODES Subfield 6, Transaction Type Identification Code, may be completed in one of three ways (Error code(s): T53):
1. For entries related to SWIFT transfer instructions and subsequent charge messages: Format: S3!n The last three characters will indicate the message type of the SWIFT message causing the entry (for debit entries) or the message type of the SWIFT message used to advise the account owner (for credit entries). 2. For entries related to payment and transfer instructions, including related charges messages, not sent through SWIFT or where an alpha description is preferred. Format: 3. N3!c For entries being first advised by the statement (items originated by the account servicing institution): Format: F3!c

CODES When formats (2) or (3) are used, the last three characters, ie, 3!c, may contain one of the following codes:
BOE BRF CHG CHK CLR CMI CMN Bill of exchange Brokerage fee Charges and other expenses Cheques Cash letters/Cheques remittance Cash management item - No detail Cash management item - Notional pooling

May 2005 Standards Release

143

Category 9 - Cash Management & Customer Status

CMS CMT CMZ COL COM DCR DDT DIV ECK EQA FEX INT LBX LDP MSC RTI SEC STO TCK TRF VDA

Cash management item - Sweeping Cash management item -Topping Cash management item - Zero balancing Collections (used when entering a principal amount) Commission Documentary credit (ussed when entering a principal amount) Direct Debit Item Dividends-Warrants Eurocheques Equivalent amount Foreign exchange Interest Lock box Loan deposit Miscellaneous Returned item Securities (used when entering a principal amount) Standing order Travellers cheques Transfer Value date adjustment (used with an entry made to withdraw an incorrectly dated entry – it will be followed by the correct entry with the relevant code)

NETWORK VALIDATED RULES Subfield 1, Value Date, must be a valid date expressed as YYMMDD (Error code(s): T50). The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50). The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length (Error code(s): T40, T43). When the first character of subfield 6, Transaction Type Identification Code, is an ‘S’, the remaining characters must be in the range 100-999 (Error code(s): T18). USAGE RULES This field may be repeated within the constraints of the maximum input message length.

144

May 2005 Standards Release

MT 972

‘Original’ advices for charges, ie, the first time the account owner is informed of a charge, must be identified in subfield 6, Transaction Type Identification Code, with the transaction type code ‘FCHG’. The following rules apply to subfield 7, Reference for the Account Owner: • • At least one valid character other than a blank must be present. For debit entries, the purpose of this subfield is to identify, to the account owner, the instruction which caused the debit. Therefore, the content of this subfield is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. Credit entries may be the result of one of the following situations: 1. The account servicing institution is identifying, to the account owner the receipt of funds for its account as a result of a related transaction. In this case, the content of subfield 7, Reference for the Account Owner is the reference for the beneficiary (eg, field 21 Related Reference) of the related transaction. 2. The account servicing institution has issued a payment instruction to the account owner and the credit identified in this subfield is for that payment. The content of subfield 7, Reference for the Account Owner is the field 20 Transaction Reference Number (or its equivalent) of the payment instruction issued by the account servicing institution. • If no reference is available for subfield 7, Reference for the Account Owner, the code NONREF shall be used. The account servicing institution must then supply, in subfield 9, Supplementary Details, what it considers to be the best alternative information. This reference must be quoted in all cases when available. In cases where a transaction passes through several financial institutions, the original reference must always be forwarded. This reference must always be quoted against any charges or fees debited by the account servicing institution. Debits against standing instructions must show the reference of the standing instruction. In cases where a mutually agreed alternative reference exists (eg, in foreign exchange or money market transactions), this reference should then be used. If the statement entry concerns a cheque, the cheque number should be indicated in this subfield.

• • • •

The following rules apply to subfield 8, Account Servicing Institution's Reference: • The content of this subfield is the account servicing institution's own reference for the transaction.

May 2005 Standards Release

145

Category 9 - Cash Management & Customer Status

When the transaction has been initiated by the account servicing institution, this reference may be identical to subfield 7, Reference for the Account Owner. If this is the case, Account Servicing Institution’s Reference, subfield 8, may be omitted.

The following rules apply to subfield 9, Supplementary Details: • When no reference for the account owner is available, ie, subfield 7, Reference for the Account Owner contains NONREF, the account servicing institution should provide the best available alternative information in this subfield. Supplementary details may be provided when an advice has not been sent for a transaction, or to provide additional information to facilitate reconciliation.

EXAMPLE (1) :61:9805270526C3500,25FCHK304955//4958843 (2) :61:9805270526C3500,25FCHK304955//4958843 ADDITIONAL INFORMATION 6. Field 62a: Closing Balance FORMAT Option F Option M 1!a6!n3!a15d 1!a6!n3!a15d (D/C Mark) (Date) (Currency) (Amount) (D/C Mark) (Date) (Currency) (Amount)

PRESENCE Mandatory DEFINITION This field specifies, for the (intermediate) closing balance, whether it is a debit or credit balance, the date, the currency and the amount of the balance. CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The (intermediate) closing balance is a credit balance. The (intermediate) closing balance is a debit balance.

NETWORK VALIDATED RULES 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).

146

May 2005 Standards Release

MT 972

The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43). USAGE RULES The contents of this field will be repeated in field 60a (opening balance) of the subsequent netting interim statement message for this netting position. All netting interim statement messages of a statement, except the last message, must contain field 62M (intermediate closing balance); the last message of the statement must contain field 62F (final closing balance). 7. Field 64: Closing Available Balance FORMAT 1!a6!n3!a15d PRESENCE Optional DEFINITION This field indicates the funds which are available to the Receiver (if credit balance) or the balance which is subject to interest charges (if debit balance). CODES D/C Mark must contain one of the following codes (Error code(s): T51):
C D The closing available balance is a credit balance. The closing available balance is a debit balance.

(D/C Mark) (Date) (Currency) (Amount)

NETWORK VALIDATED RULES 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. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).

May 2005 Standards Release

147

Category 9 - Cash Management & Customer Status

MT 972 Examples
For examples of this message type, please refer to the Service Description of the netting system concerned.

148

May 2005 Standards Release

MT 973

MT 973 Netting Request Message
Note: This message may only be sent and received after prior arrangement between a user and SWIFT

MT 973 Scope
This message type is sent by a financial institution to a netting system. It is used to request the netting system to transmit an MT 971 Netting Balance Report, an MT 972 Netting Interim Statement or an MT 998 Proprietary Message containing the latest available information.

MT 973 Format Specifications
MT 973 Netting Request Message
Status M -----> M M -----| M = Mandatory O = Optional 12 25 Message Type Account Identification 3!n 35x 2 3 Tag 20 Field Name Transaction Reference Number 16x Content/Options No. 1

MT 973 Network Validated Rules
There are no network validated field rules for this message type.

MT 973 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x

May 2005 Standards Release

149

Category 9 - Cash Management & Customer Status

PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 2. Field 12: Message Type FORMAT 3!n PRESENCE Mandatory DEFINITION This field identifies the message type which is being requested. CODES This field must contain one of the following message type numbers (Error code(s): T88):
971 972 998 Netting Balance Report Netting Interim Statement Proprietary Message

3.

Field 25: Account Identification FORMAT 35x PRESENCE Mandatory DEFINITION This field identifies the netting position for which balance or transaction detail information is requested.

150

May 2005 Standards Release

MT 973

MT 973 Examples
For examples of this message type, please refer to the Service Description and Functional Requirement Specifications for the netting system concerned.

May 2005 Standards Release

151

Category 9 - Cash Management & Customer Status

MT 985 Status Enquiry
MT 985 Scope
This message type is sent by a financial institution, to another financial institution, to request an MT 986 Status Report.

MT 985 Format Specifications
MT 985 Status Enquiry
Status M O M O Tag 20 57a 59 75 Field Name Transaction Reference Number Account With Institution Enquired Party Queries M = Mandatory O = Optional 16x A, B or D [/34x] 4*35x 6*35x Content/Options No. 1 2 3 4

MT 985 Network Validated Rules
There are no network validated rules for this message type.

MT 985 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message.

152

May 2005 Standards Release

MT 985

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 57a: Account With Institution FORMAT Option A Option B Option D [/1!a][/34x] 4!a2!a2!c[3!c] [/1!a][/34x] [35x] [/1!a][/34x] 4*35x (Party Identifier) (BIC) (Party Identifier) (Location) (Party Identifier) (Name & Address)

PRESENCE Optional DEFINITION This field identifies the financial institution and/or branch of the financial institution of the enquired party. NETWORK VALIDATED RULES The BIC must be a SWIFT registered address, either connected or non-connected (Error code(s): T27, T28, T29, T45). The BIC must not be a BEI, ie must not be of subtype BEID, MCCO, TESP or TRCO (Error code(s): C05). USAGE RULES When this information is known, it should be specified, even when it is the Receiver of the message. 3. Field 59: Enquired Party FORMAT [/34x] 4*35x PRESENCE Mandatory DEFINITION This field specifies the party about which information is requested. (Account) (Name & Address)

May 2005 Standards Release

153

Category 9 - Cash Management & Customer Status

USAGE RULES When an account number is provided, it is the account number on the books of the Receiver. 4. Field 75: Queries FORMAT 6*35x PRESENCE Optional DEFINITION This field is used when information other than general credit information is requested for the enquired party. USAGE RULES This field contains a narrative explanation of the information requested. (Narrative)

MT 985 Examples
Narrative Chase Manhattan Bank, New York, requests Midland Bank, London, to provide credit information about its customer XXX Corporation, located at 110 Highgrove Street, London. Chase Manhattan will send an MT 985 to request this information.

154

May 2005 Standards Release

MT 985

Information Flow

Sender

Chase Manhattan Bank New York

MT

MT 985

Receiver

Midland Bank London

XXX Corp.
D0090009

SWIFT Message

Explanation Sender Message Type Receiver Message Text Transaction Reference Number Account With Institution (1) Enquired Party (2) End of Message Text/Trailer :20:44985789 :57A:MIDLGB22 CHASUS33 985 MIDLGB22

Format

:59:XXX CORPORATION 110 HIGHGROVE ST LONDON

Note: (1) Field 57A identifies the financial institution, in this case the Receiver, of the enquired party. (2) The name of the party about which information is requested.

May 2005 Standards Release

155

Category 9 - Cash Management & Customer Status

MT 986 Status Report
MT 986 Scope
This message type is sent by a financial institution, to another financial institution, to provide general credit information, without responsibility, about an individual or an institution.

MT 986 Format Specifications
MT 986 Status Report
Status M M O M Tag 20 21 59 79 Field Name Transaction Reference Number Related Reference Enquired Party Narrative 16x 16x [/34x] 4*35x 35*50x M = Mandatory O = Optional Content/Options No. 1 2 3 4

MT 986 Network Validated Rules
There are no network validated rules for this message type.

MT 986 Field Specifications
1. Field 20: Transaction Reference Number FORMAT 16x PRESENCE Mandatory DEFINITION This field specifies the reference assigned by the Sender to unambiguously identify the message.

156

May 2005 Standards Release

MT 986

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 21: Related Reference FORMAT 16x PRESENCE Mandatory DEFINITION This field must contain the content of field 20 Transaction Reference Number of the MT 985 which requested the information in this message. NETWORK VALIDATED RULES This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26). 3. Field 59: Enquired Party FORMAT [/34x] 4*35x PRESENCE Optional DEFINITION This field specifies the party about which information is provided. USAGE RULES When an account number is provided, it is the account on the books of the Sender. 4. Field 79: Narrative FORMAT 35*50x PRESENCE Mandatory (Narrative) (Account) (Name & Address)

May 2005 Standards Release

157

Category 9 - Cash Management & Customer Status

DEFINITION This field contains the information requested.

MT 986 Examples
Narrative Midland Bank, London, provides credit information about its customer XXX Corporation, located at 110 Highgrove Street, London, to Chase Manhattan Bank, New York. Information Flow

Sender

Midland Bank London

MT

MT 986

Receiver

Chase Manhattan Bank New York

XXX Corp.
D0090010

SWIFT Message

Explanation Sender Message Type Receiver MIDLGB22 986 CHASUS33

Format

158

May 2005 Standards Release

MT 986

Explanation Message Text Transaction Reference Number Related Reference Enquired Party :20:INQ3531 :21:44985789

Format

:59:XXX CORPORATION 110 HIGHGROVE ST LONDON :79:XXX CORP HAS ORGANISATION

Narrative End of Message Text/Trailer

May 2005 Standards Release

159

Category 9 - Cash Management & Customer Status

MT 990 Advice of Charges, Interest and Other Adjustments
Please refer to Category n – Common Group Messages , Chapter MT n90 Advice of Charges, Interest and Other Adjustments for details concerning this message type.

160

May 2005 Standards Release

MT 991

MT 991 Request for Payment of Charges, Interest and Other Expenses
Please refer to Category n – Common Group Messages , Chapter MT n91 Request for Payment of Charges, Interest and Other Expenses for details concerning this message type.

May 2005 Standards Release

161

Category 9 - Cash Management & Customer Status

MT 992 Request for Cancellation
Please refer to Category n – Common Group Messages , Chapter MT n92 Request for Cancellation for details concerning this message type.

162

May 2005 Standards Release

MT 995

MT 995 Queries
Please refer to Category n – Common Group Messages , Chapter MT n95 Queries for details concerning this message type.

May 2005 Standards Release

163

Category 9 - Cash Management & Customer Status

MT 996 Answers
Please refer to Category n – Common Group Messages , Chapter MT n96 Answers for details concerning this message type.

164

May 2005 Standards Release

MT 998

MT 998 Proprietary Message
Please refer to Category n – Common Group Messages, Chapter MT n98 Proprietary Message for details concerning this message type.

May 2005 Standards Release

165

Category 9 - Cash Management & Customer Status

MT 999 Free Format Message
Please refer to Category n – Common Group Messages , Chapter MT n99 Free Format Message for details concerning this message type.

166

May 2005 Standards Release

Glossary of Terms

Glossary of Terms
In addition to the definitions which appear in Standards General Information, Glossary of Terms, the following terms apply to Category 9 message types: Account Servicing Institution A financial institution which is a depository for an account. Account Servicing Institution's Reference A reference assigned by the account servicing institution to identify the transaction. (This is the reference to which the account owner refers in cases of inquiry to that financial institution.) Available Balance The balance at the disposal of the account owner on the date specified. The specific formula for the calculation of the balance is dependent upon national, local, legal or bilateral agreement/conventions/requirements. Available Funds Funds available for transfer or withdrawal in cash. Bulking The practice of totalling the amounts of a number of transactions to provide a single accounting entry. Closing Available Balance Amount at the disposal of the account owner at the close of the statement period. Closing Balance Balance of entries posted to the account at the close of the statement period. Concentrating Bank A bank authorised by the account owner to receive, collate and report status and movement information on behalf of the Account Owner's customer(s). Credit Advice An advice by the account servicing institution of a credit to the account of the Receiver (Account Owner). This advice must not be used to transmit payment instructions. Debit Advice An advice by the account servicing institution of a debit to the account of the Receiver (Account Owner). Due From Account See ‘Nostro Account’. Due To Account See ‘Vostro Account’.

May 2005 Standards Release

167

Category 9 - Cash Management & Customer Status

ECU Netting System A multi-lateral payment netting service operated by S.W.I.F.T./S.S.P. on behalf of the ECU Banking Association, with settlement through the Bank for International Settlement. Enquired Party The individual or institution about which information is requested or provided. Entry Any debit or credit item posted to an account. Entry Date Date on which entries are made in the records of an account. Forward Available Balance The balance of the booked items that will be available to the account owner on a specified future date. Immediate Funds Same day funds in which the settlement is simultaneous with execution of the transaction. Intermediary The financial institution from which an account servicing institution receives funds for an Account Owner. Intermediate Closing Balance Balance of entries posted to the account as reflected in the statement ‘page’ (message) of a statement consisting of multiple ‘page’ (messages). Intermediate Opening Balance Intermediate closing balance as reflected in the previous statement ‘page’ (message) of a statement consisting of multiple ‘pages’ (messages). Lockbox A financial service provided for the rapid collection of a customer's receivables and rapid credit to the customer's account. Loro Account See ‘Vostro Account’ Netting Balance The balance of entries posted to a netting position by a netting system. Netting Position The record of entries processed by a netting system on behalf of a financial institution.

168

May 2005 Standards Release

Glossary of Terms

Nostro Account A record kept by an account owner of an account serviced on its behalf by an Account Servicing Institution. It is also known as a Due From account. Opening Balance Closing balance of the previous statement. Reference for the account owner The reference which identifies the transaction to the Account Owner. Reference for the Beneficiary See ‘Reference for the Account Owner’. Reporting Bank The bank transmitting the information about accounts serviced by them. Statement Line Information related to one entry in a statement message. Statement Number A number for the sequential identification of statements. It may have a subfield indicating the ‘page’ number. Vostro Account An account serviced by a bank on behalf of an account owner Bank. It is also known as a Loro Account or Due To Account.

May 2005 Standards Release

169

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.