S.W.I.F.T. S.W.I.F.T (SWIFT) is the acronym for the Society for Worldwide Interbank Financial Telecommunications.

. Its headquarters are in La Hulpe near Brussels, Belgium. It runs a worldwide network by which messages concerning financial transactions are exchanged between banks and other financial institutions globally. It was established as a cooperative society in 1973 under Belgian Law by 239 banks in 15 countries. It was started to establish a common language for financial transactions and a shared data processing system through a worldwide network communications network. Its fundamental operating procedure and rules were laid down in 1975 and the first message was sent in 1977. It operates as a non-profit making society. It has members in excess of 7000 in over 200 countries worldwide and handles over 7 million messages every day. Apart from a hub in Brussels, SWIFT has hubs in New York and in the Netherlands. The society functions round the clock for operational services of its members globally India joined the society in 1991. Initially only 41 banks in India participated. Presently because of its efficiency and the fact that nearly all banks world-wide are members, most banks in India are also members of SWIFT. In India bank locations are connected to the SWIFT regional processor in Mumbai. Membership of SWIFT Any bank / financial institution can become a member of the society by paying the relevant fees, subject to the terms and conditions and the approval of the society. On becoming a member, the new member is allotted an address called Bank Identification Code (BIC) of 8 characters. This address is circulated by the society to its members and only then can the new member can participate in the SWIFT system. The society updates the BIC Directory at regular intervals. How does SWIFT operate? SWIFT enables banks and institutions (its members) to send secure and reliable messages, since the entire transmission of messages is system based, with uniformity in language and format and authenticated at every level. Each member is provided with an interface-terminal with SWIFT Link Network(SLN). The sending banker / institutions transmit the message in the relevant format (formats are predesigned by SWIFT) to the SWIFT Hub (also called the FIN center) and the FIN center arranges to transmit to the beneficiarys bank / institution. In those countries where banks do not have many branches / offices, they operate through acorrespondent bank for all transactions. Where such correspondent banks services are availed, the process of transmitting message will need the details of such correspondent bank. It is also in the practice that different correspondents services are availed in different countries, and

different accounts are maintained for different banking purposes. When messages are transmitted through correspondent bank services, the additional details such as correspondent banks name, BIC address, account numbers are also to be included in the message, in the relevant column of the SWIFT format. The message transmitted through SWIFT is received within a few seconds by the ultimate beneficiary institution, if the receiver is logged in the interface. In case the receiving participant is not on, the messages are arranged in queue at the FIN center and whenever the receiver logs in the interface, the messages are pumped-in from the SWIFT hub to the beneficiarys interface. Messages and Fields In the SWIFT messages that are normally exchanged between banks have been divided into categories such as: Customer Transfers and Cheques. Financial Institution Transfers Financial Trading. Collections and Cash letters. Documentary Credits & Guarantees. Securities. Precious Metals and Syndications. Travelers Cheque.s Cash Management and Customer Status Supporting System Messages.. The serial number given against each category is known in SWIFT as the CATEGORY CODE. Under each category, various types of messages are sent / received by banks. For example, under the category Documentary Credit, messages pertaining to Issuance of L/C, Amendments to L/C, Reimbursement claim, Advice of discrepancy in documents etc., are transmitted by banks. Each of the above messages is considered as a MESSAGE TYPE. SWIFT has defined various message types not only under the category of Documentary credit but also under other categories. These messages types, normally referred to as MT, have been given a three digit identification number. The first digit of the MT indicates the category to which it belongs Normally the following details appear in any SWIFT message: Date and time of receipt of message Message Input Reference SWIFT Input Sender Receiver Transaction reference number Related Reference Date (YYMMDD)

 Currency Code Amount Narrative Precautions The sender should use the correct format prescribed for different purposes.The relevant columns in the format should be correctly filled in. Once the message is complete and sent, the SWIFT-FIN Center acknowledges the same with an ACK message. In case there is any technical / formatting error, the FIN center sends a NAK message (Not Acknowledged) with details of the error field. The sender has to make corrections in the relevant field/s and send the message again to the SWIFT FIN center. The sender, when he receives ACK copy from the SWIFT-FIN center, gets legal protection for any disputes, if any, in future. To maintain its secrecy, the society sends to each of its members, rectified / changed program intimations at regular intervals. Remittance through SWIFT What should a customer do to send a remittance through SWIFT? If a customer A decided to remit funds to another person B through SWIFT, he would instruct his banker to do so, mentioning the name of Bs bank, SWIFT code (if known to him) of Bs bank and Bs account number. The sending bank debits the account of A and does the needful. Banks undertake to effect remittances on behalf of their Resident and Non-Resident customers who expect the funds to be places at the disposal of the beneficiary in the shortest possible time. Advantages of SWIFT It is operational throughout the year 24 hours a day. Funds transfers are effected by the banks by using conventional instruments like DD, TT, etc., which though time tested can lead to duplication in payment and also gives scope for perpetration of fraud. Hence the need for a computerized solution was desired which would expedite payment and also eliminate the opportunity for commission of fraud or misappropriation of funds. The SWIFT method is totally system based and the duplication of message is cautioned and has minimized these difficulties Transmission of messages are immediate and all messages are acknowledged (either accepted or rejected). Information is confidential and is protected against unauthorized disclosure and tampering. SWIFT assumes financial liability for the accuracy and timely delivery of all validated messages from the point they enter the network to the point they leave the network. In case of trade related activities, the process of transmission of documentary credits / issue of guarantees too needed to be automated. SWIFT meets this requirement. Remittances and messages are transmitted in seconds to the beneficiary. Uniform Customs and Practices Boards International Remittance and Telecommunications Department supports the services in processing outgoing and incoming remittances for local and international funds transfers through SWIFT. Commonly Used SWIFT Formats Format 103 Customer Funds transfer from Correspondent banks

 Format 202 Institutional transfer Format 999 Free format, for any query /clarification Format 199 Customer payment query

SWIFT:Message Types
From Wikipedia, the free encyclopedia

SWIFT or Society for Worldwide Interbank Financial Telecommunication provides a network to allow financial and non-financial institutions (e.g. corporates) to transfer financial transactions through a 'financial message'. Currently SWIFT's network can support the following message standards
Contents
[hide]

1 SWIFT MT 2 ISO 15022 MT 3 ISO 20022 MX 4 See also 5 References

[edit]SWIFT

MT

SWIFT messages, developed by SWIFT Standards, consist of five blocks of data including three headers, message content, and a trailer. Message types are crucial to identifying content. All SWIFT messages include the literal "MT" (Message Type). This is followed by a 3-digit number that denotes the message type, category, and group. Consider the following example, which is an order to buy or sell via a third party:

Example MT304

The first digit (3) represents the category. A category denotes messages that relate to particular financial instruments or services such as Precious Metals (6), Treasury (3), or Travelers Cheques (8). The category denoted by 3 is Treasury Markets. The second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a Financial Institution Transfer.

The third digit (4) is the type that denotes the specific message. There are several hundred message types across the categories. The type represented by 4 is a notification. Overview of SWIFT MT Categories:

Message Type

Description

MT0xx

System Messages

MT1xx

Customer Payments and Cheques

MT2xx

Financial Institution Transfers

MT3xx

Treasury Markets

MT4xx

Collection and Cash Letters

MT5xx

Securities Markets

MT6xx

Treasury Markets - Metals and Syndications

MT7xx

Documentary Credits and Guarantees

MT8xx

Travellers Cheques

MT9xx [edit]ISO

Cash Management and Customer Status

15022 MT

Although ISO 15022 Message Types are different in their structure than the SWIFT MT, the naming convention remains the same. The following example will illustrate:

Example. MT 307

As with SWIFT MTs, the first digit (3) denotes the category. As above, this denotes Treasury Markets.

As with SWIFT MTs, the second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a Financial Institution Transfer. Finally, the third digit (7) denotes the specific message. In this case, similar to the MT 304, the 7 denotes Notification. The SWIFT MT 304 and the ISO 15022 MT 307 are equal but were created for different financial groups using different standards. These messages are generated using MessagePro.

[edit]ISO

20022 MX

A new message type expressed in XML syntax, which is more flexible and easier to implement than the previous generation of message types (MT). These message types are developed in accordance with ISO 20022 standard. Current syntax is as following: xxxx.nnn.aaa.bb xxxx is an alphabetic code in four positions (fixed length) identifying the Business Process, nnn is an alphanumeric code in three positions (fixed length) identifying the Message Functionality, aaa is a numeric code in three positions (fixed length) identifying a particular flavour (variant) of Message Functionality, bb is a numeric code in two positions (fixed length) identifying the version, and Consider the following example: TREA.001.001.02

TREA refers to Treasury 001 refers to NDF opening (notification) 001 refers to the variant 02 refers to the version message format, in this case version 2 of NDF opening type.

SWIFT Standards for MX Messages:

MX Identifier

Description

acmt.xxx.xxx.xx Account Management

admi.xxx.xxx.xx Administration

camt.xxx.xxx.xx Cash Management

defp.xxx.xxx.xx Derivatives

pacs.xxx.xxx.xx Payments Clearing and Settlement

pain.xxx.xxx.xx Payments Initiation

reda.xxx.xxx.xx Reference Data

seev.xxx.xxx.xx Securities Events

semt.xxx.xxx.xx Securities Management

sese.xxx.xxx.xx Securities Settlement

setr.xxx.xxx.xx

Securities Trade

trea.xxx.xxx.xx

Treasury

tsmt.xxx.xxx.xx Trade Services Management

SWIFT message types

SWIFT messages consist of five blocks of data including three headers, message content, and a trailer. Message types are crucial to identifying content. All SWIFT messages include the literal "MT" (Message Type). This is followed by a 3-digit number that denotes the message type, category, and group. Consider the following example, which is an order to buy or sell via a third party:

MT502
The first digit (5) represents the category. A category denotes messages that relate to particular financial instruments or services such as Precious Metals, Syndications, or Travelers Checks. The category denoted by 5 is Securities Markets.

The second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a Financial Institution Transfer. The third digit (2) is the type that denotes the specific message. There are several hundred message types across the categories. The type represented by 2 is a Third-Party Transfer. Each message is assigned unique identifiers. A 4-digit session number is assigned each time the user logs in. Each message is then assigned a 6-digit sequence number. These are then combined to form an ISN (Input Sequence Number) from the user's computer to SWIFT or an OSN (Output Sequence Number) from SWIFT to the user's computer. It is important to remember that terminology is always from the perspective of SWIFT and not the user. The Logical Terminal Address (12 character BIC), Day, Session and Sequence numbers combine to form the MIR (Message Input Reference) and MOR (Message Output Reference), respectively. For a full list of SWIFT message types, see All Things SWIFT: the SWIFT User Handbook.

SWIFT field structure

This section discusses the SWIFT field structure. A field is a logical subdivision of a message block A, which consists of a sequence of components with a starting field tag and delimiters. A field is always prefaced by a field tag that consists of two digits followed, optionally, by an alphabetic character. The alphabetic character is referred to as an option. For example, 16R is a tag (16) with an option (R) that indicates the start of a block; 16S is a tag (16) with an option (S) that indicates the end of a block. A field is always terminated by a field delimiter. The delimiter depends on the type of field used in a message block. There are two types of fields used in SWIFT messages: generic and non-generic. The type of field used in a SWIFT message block is determined by the Message Type. What follows is a discussion of these SWIFT field structures. For more on generic and non-generic fields and how to distinguish between them, see Part III, Chapter 3 of the SWIFT User Handbook Note: The symbol CRLF shown below is a control character and represents carriage return/line feed (0D0A in ASCII hex, 0D25 in EBCDIC hex). Non-generic fields The structure of non-generic fields in SWIFT message blocks is as follows: :2!n[1a]: data content<CRLF> Where: : = mandatory colon

2!n = numeric character, fixed length [1a] = one optional alphabetic character, letter option : = mandatory colon data content = the data content, which is defined separately for every tag <CRLF> = field delimiter The following is an example of a non-generic field: :20:1234<CRLF> :32A:...<CRLF> Note: In some cases (such as with the tag 15A...n), the data content is optional. Generic fields The structure of generic fields in SWIFT messages is as follows: :2!n1a::4!c'/'[8c]'/'data content where :2!n1a: = same format as non-generic fields, except that 1a is mandatory : = mandatory second colon (required in all generic fields) 4!c = qualifier '/' = first delimiter [8c] = issuer code or Data Source Scheme (DSS) '/' = second delimiter data content = See Part III, Chapter 3 of the SWIFT User Handbook for the format definition Note: Non-generic fields and generic fields cannot share the same field tag letter option letter. In order to distinguish between them easily, a colon is defined as the first character of the column Component Sequence. Generic fields are defined in the same section (Part III, Chapter 3 of the SWIFT User Handbook) as the non-generic fields. The following character restrictions apply to generic field data content: Second and subsequent lines within the data content must start with the delimiter CRLF.

Second and subsequent lines within the data content must never start with a colon (:) or a hyphen (-). The data content must end with the delimiter CRLF.

SWIFT message block structure

The connector supports SWIFT Financial Application (FIN) messages. They have the following structure: {1: Basic Header Block} {2: Application Header Block} {3: User Header Block} {4: Text Block or body} {5: Trailer Block} These five SWIFT message blocks include header information, the body of the message, and a trailer. All blocks have the same basic format: {n:...} The curly braces ({}) indicate the beginning and end of a block. n is the block identifier, in this case a single integer between 1 and 5. Each block identifier is associated with a particular part of the message. There is no carriage return or line feed (CRLF) between blocks. Blocks 3, 4, and 5 may contain sub-blocks or fields delimited by field tags. Block 3 is optional. Many applications, however, populate block 3 with a reference number so that when SWIFT returns the acknowledgement, it can be used for reconciliation purposes. Note: For further information on SWIFT message blocks, see Chapter 2 of the SWIFT User Handbook FIN System Messages Document. {1: Basic Header Block} The basic header block is fixed-length and continuous with no field delimiters. It has the following format: {1: (a) a) 1: = Block ID (always 1) b) Application ID as follows: F = FIN (financial application) A = GPA (general purpose application) L = GPA (for logins, and so on) c) Service ID as follows: 01 = FIN/GPA F (b) 01 (c) BANKBEBB (d) 2222 (e) 123456} (f)

 d)

21 = ACK/NAK

BANKBEBB = Logical terminal (LT) address. It is fixed at 12 characters; it must not have X in position 9. e) 2222 = Session number. It is generated by the user's computer and is padded with zeros. f) 123456 = Sequence number that is generated by the user's computer. It is padded with zeros. {2: Application Header Block} There are two types of application headers: Input and Output. Both are fixed-length and continuous with no field delimiter. The input (to SWIFT) structure is as follows: {2: (a) I (b) 100 (c) BANKDEFFXXXX (d) U (e) 3 (f) 003} (g)

2: = Block ID (always 2) b) I = Input c) 100 = Message type d) BANKDEFFXXXX = Receiver's address with X in position 9/ It is padded with Xs if no branch is required. e) U = the message priority as follows: S = System N = Normal U = Urgent f) 3 = Delivery monitoring field is as follows: 1 = Non delivery warning (MT010) 2 = Delivery notification (MT011) 3 = Both valid = U1 or U3, N2 or N g)

003 = Obsolescence period. It specifies when a non-delivery notification is generated as follows: Valid for U = 003 (15 minutes) Valid for N = 020 (100 minutes) The output (from SWIFT) structure is as follows: {2: (a) (h) a) 2: = Block ID (always 2) b) O = Output c) 100 = Message type d) 1200 = Input time with respect to the sender e) The Message Input Reference (MIR), including input date, with Sender's address f) 970103 = Output date with respect to Receiver g) 1201 = Output time with respect to Receiver h) N = Message priority as follows: S = System N = Normal U = Urgent {3: User Header Block} This is an optional block and has the following structure: {3: (a) a) 3: = Block ID (always 3) b) 113:xxxx = Optional banking priority code {113:xxxx} (b) {108:abcdefgh12345678} ( c) } O (b) 100 (c) 1200 (d) 970103BANKBEBBAXXX2222123456 (e) 970103 (f) 1201 (g) N}

c) This is the Message User Reference (MUR) used by applications for reconciliation with ACK. Note: Other tags exist for this block. They include tags (such as 119, which can contain the code ISITC on an MT521) that may force additional code word and formatting rules to validate the body of the message as laid down by ISITC (Industry Standardization for Institutional Trade Communication). For further information, see All Things SWIFT: the SWIFT User Handbook. {4: Text Block or body} This block is where the actual message content is specified and is what most users see. Generally the other blocks are stripped off before presentation. The format, which is variable length and requires use of CRLF as a field delimiter, is as follows: {4:CRLF :20:PAYREFTB54302 CRLF :32A:970103BEF1000000,CRLF :50:CUSTOMER NAME CRLF AND ADDRESS CRLF :59:/123-456-789 CRLF BENEFICIARY NAME CRLF AND ADDRESS CRLF -} The symbol CRLF is a mandatory delimiter in block 4. The example above is of type MT100 (Customer Transfer) with only the mandatory fields completed. It is an example of the format of an ISO 7775 message structure. Block 4 fields must be in the order specified for the message type in the appropriate volume of the SWIFT User Handbook. The content of the text block is a collection of fields. For more on SWIFT fields, see SWIFT field structure. Sometimes, the fields are logically grouped into sequences. Sequences can be mandatory or optional, and can repeat. Sequences also can be divided into subsequences. In addition, single fields and groups of consecutive fields can repeat. For example, sequences such as those in the SWIFT Tags 16R and 16S may have beginning and ending fields. Other sequences, such as Tag 15, have only a beginning field. In yet other message types, no specific tags mark the start or end of a field sequence. The format of block 4 field tags is: :nna: nn = Numbers a = Optional letter, which may be present on selected tags For example: :20: = Transaction reference number :58A: = Beneficiary bank

The length of a field is as follows: nn = Maximum length nn! = Fixed-length nn-nn = Minimum and maximum length nn * nn = Maimum number of lines times maximum line length The format of the data is as follows: n = Digits d = Digits with decimal comma h = Uppercase hexadecimal a = Uppercase letter c = Uppercase alphanumeric e = Space x = SWIFT character set y = Uppercase level A ISO 9735 characters z = SWIFT extended character set Some fields are defined as optional. If optional fields are not required in a specific message, do not include them because blank fields are not allowed in the message. /,word = Characters "as is" [...] = Brackets indicate an optional element For example: 4!c[/30x] This is a fixed 4 uppercase alphanumeric, optionally followed by a slash and up to 30 SWIFT characters. ISIN1!e12!c This is a code word followed by a space and a 12 fixed uppercase alphanumeric. Note: In some message types, certain fields are defined as conditional. For example, when a certain field is present, another field may change from optional to mandatory or forbidden. Certain fields

may contain sub-fields, in which case there is no CRLF between them. Validation is not supported. Certain fields have different formats that depend on the option that is chosen. The option is designated by a letter after the tag number, for example: :32A:000718GBP1000000,00 Value Date, ISO Currency, and Amount :32B:GBP1000000,00 ISO Currency and Amount Note: The SWIFT standards for amount formats are: no thousand separators are allowed (10,000 is not allowed, but 10000 is allowed); use a comma (not a decimal point) for a decimal separator (1000,45 = one thousand and forty-five hundredths). :58A:NWBKGB2L Beneficiary SWIFT address :58D:NatWest Bank Beneficiary full name and address Head Office London {5: Trailer Block} A message always ends in a trailer with the following format: {5: {MAC:12345678}{CHK:123456789ABC} This block is for SWIFT system use and contains a number of fields that are denoted by keywords such as the following: MAC Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination and a secret algorithm. Found on message categories 1,2,4,5,7,8, most 6s and 304. CHK Checksum calculated for all message types. PDE Possible Duplicate Emission added if user thinks the same message was sent previously DLM Added by SWIFT if an urgent message (U) has not been delivered within 15 minutes, or a normal message (N) within 100 minutes.

Messages
SWIFT offers a range of FIN standards - also called Message Types (MTs) - to initiate credit transfers and direct debits. A related set of standards is available to handle status reporting (rejections) and deal with exceptions and investigations. There are also standards that provide account related information exchanged between an account owner and an account servicing institution for cash management and reconciliation purposes.

MT 101 Requests for Transfer

Scope The MT 101 is sent by the corporate to the financial institution. It is used to move funds from the ordering customers account, serviced at the receiving financial institution or at the account servicing institution. Usage The MT 101 can contain one or more payment transactions. The sender of the MT 101 can ask for batch booking (one single debit entry) or transaction booking (one debit entry per transaction included in the MT 101). The MT 101 can be used to order the movement of funds, either domestically or internationally: Between ordering customer accounts In favor of a third party The account servicing bank can be the receiver of the message (see direct scenario), or can be a party further in the payment chain (see relay scenario): Direct scenario A customer orders its bank to instruct a payment from its account with that bank
Relay scenario A customer orders its bank to instruct a payment from its account with a second bank:

The receiving bank forwards the MT 101 to the account servicing institution. This institution will debit the customers account and initiate a credit transfer (in its books or by forwarding an MT102/103 or local credit transfer message).

MT 104 Direct Debit and Request for Direct Debit

Scope

The MT 104 is sent by the corporate to the financial institution. It is used to request the direct debit of the debtor's account in the receiver's country and subsequently to credit the creditor's account maintained by the receiver or one of its branches. Usage The message must be used in a request for debit transfer scenario. A customer orders its bank to start a direct debit and credit its account with him, or, a customer orders its bank to instruct a direct debit and credit its account with another bank. The account is owned by the customer. The receiving bank would forward the MT 104 cross-border, or start a domestic direct debit collection.

MT 199 Free Format Message

Scope This message type is normally used by financial institutions to send information for which another message type is not applicable. Usage It can be used as a status message to report reasons for a transaction instruction not being executed or as a message to reject a transaction. Message usage guidelines This is a free format message.

MT 192 Request for Cancellation

Scope This message type is sent by the corporate to the financial institution. It can be used to request to consider cancellation of the SWIFT message identified in the request. Usage An MT 192 can be sent to request the cancellation of one single transaction contained in the MT 101 or to request cancellation of the complete MT 101. The request for cancellation always requires a response. This can be done through MT 196, or through MT 199 subject to bilateral agreement. It is up to the receiving bank to define its cancellation policies.

Message usage guidelines The SWIFT User Handbook, Volume Standards Category n, Common Group Messages, n92 Request for Cancellation contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined.

MT 195 Queries and MT 196 Answers

Scope MT 195

This message type can be sent by the corporate to the financial institution. It can also be sent by the financial institution to the corporate. It is used to request information or clarification relating to a previously sent message, or to one or more transactions contained therein. A query may also be sent to request that an amendment be made to a previous message. Usage MT 195 must not be used to reject a previous message. MT 199 must be used for this purpose. The MT 195 always requires a response. This can be done through MT 196, or through MT 199 subject to bilateral agreement. Scope MT 196 This message type can be used to respond to an MT 192 Request for Cancellation or MT 195 Queries message. Message usage guidelines The SWIFT User Handbook, Volume Standards Category n, Common Group Messages, n95 Queries and n96 Answers contains full field specifications and network validated rules that must be adhered to. No specific message usage guidelines have been defined.

MT 999 Free Format Message

Scope This message type is normally used by financial institutions to send information for which another message type is not applicable. Usage It must only be used for scenarios pre-agreed between a corporate and its financial institution.

MT 900 Confirmation of Debit

Scope This message type is sent by an account servicing institution to an account owner (or a party authorized by the account owner to receive the information). 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. Usage 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 or party authorized by the account owner to receive the information) of a debit to its account.

MT 910 Confirmation of Credit

Scope This message is sent by an account servicing institution to an account owner (or a party authorized by the account owner to receive the information).

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. Usage 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 or party authorized by the account owner to receive the information) of a credit to its account.

MT 940 Customer Statement Message

Scope This message is used to transmit detailed information about all entries booked to an account, serviced by a financial institution. Usage In the bank-to-bank part of the payment chain, the MT 940 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorized by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 940: the forwarding institution forwards the MT 940 to the corporate (the account owner, or the party authorized by the account owner to receive the information). In a bank-to-corporate environment, however, the MT 940 is also to be used instead of the MT 950 directly between the account servicing financial institution and the corporate (the account owner, or the party authorized by the account owner to receive the information).

MT 941 Balance Report

Scope This message is used to transmit balance information, reflecting the situation at the identified time in field 13D. Usage In the bank-to-bank part of the payment chain, the MT 941 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorized by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 941: the forwarding institution forwards the MT 940 to the corporate (the account owner, or the party authorized by the account owner to receive the information). In a bank-to-corporate environment, however, the MT 941 can also be used directly between the account servicing financial institution and the corporate (the account owner, or the party authorized by the account owner to receive the information).

MT 942 Interim Transaction Report

Scope This message 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). Usage In the bank-to-bank part of the payment chain, the MT 942 is normally sent by an account servicing institution (reporting institution) to a financial institution (forwarding institution) which has been authorized by the account owner to receive it. In the bank-to-corporate environment, this relay scenario is also supported by the MT 942: the forwarding institution forwards the MT 942 to the corporate (the account owner, or the party authorized by the account owner to receive the information). In a bank-to-corporate environment however, the MT 942 is also to be used directly between the account servicing financial institution and the corporate (the account owner, or the party authorized by the account owner to receive the information).

MT 210 Notice to Receive

Scope This message type is sent by an account owner (or a party authorized by the account owner) to one of its account servicing institutions. It is an advance notice to the account servicing institution that it will receive funds to be credited to the sender's account. Usage This message will typically be used to ensure the account servicing institution is informed in advance of incoming funds in favour of the account owner. This message will allow the account servicing institution to have an early visibility of the incoming funds; it will help manage its liquidity and ensure the account owner get credited with good value date.

Treasury Markets Standards

MT 300 Foreign Exchange Confirmation
Scope This message is exchanged by or on behalf of the institutions or corporate, which have agreed to a foreign exchange contract. It is used to: confirm the details of a new contract between the parties confirm an exercised foreign currency option confirm the details of an amendment to a previously sent confirmation cancel a previously sent confirmation

Usage rules For the actual transfer of funds, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message. When the sender of the MT 300 is confirming a trade on behalf of another party, this other party must be indicated in field 82a of the message; otherwise, the identification of the sender itself must appear in field 82. This message can also be used to confirm a currency swap. In that case, two confirmations must be sent: a spot one and a forward one. Non Deliverable Forward Trades may be confirmed by adding the NDF specific data in field 77D. The opening of a Non Deliverable Forward Trade contains the original amounts and two elements specific to this type of trade, the valuation date and the settlement currency. For the closing of the trade, the message has to contain opposite conditions, for example a full amount bought and a full amount sold. The net amount to be settled is calculated by netting the opening and the closing amounts.

MT 320 Fixed Loan/Deposit Confirmation

Scope This message is exchanged to confirm a fixed term loan/deposit contract. It is exchanged by or on behalf of the institutions or corporate, who have agreed to a fixed term loan/deposit contract. Note In some markets, loan/deposit contracts are agreed on floating rates. The MT320 is not formatted to confirm floating rate contracts but bi-lateral agreements between parties are possible (see Message Guidelines and example). Usage rules For the actual transfer of funds, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message. When the sender of the MT 320 is confirming a trade on behalf of another party, this other party must be indicated in field 82a of the message, otherwise, the identification of the sender itself must appear in field 82.

MT 305 Foreign Currency Option Confirmation

Scope This message is exchanged by or on behalf of the institutions or corporate, which have agreed to a foreign currency option contract. It is used to: confirm the details of a new contract between the parties confirm the details of an amendment to a previously sent confirmation cancel a previously sent confirmation Usage rules For the actual transfer of the premium, other messages outside Category 3 are available, such as the MT 101, Request for Transfer message.

The underlying master agreement is by default ICOM but variations of ICOM, or ISDA master agreements may also be specified. This message must be used to confirm Vanilla, Deliverable currency options with American or European exercise. Barriers cannot be specified.

Securities Standards
SWIFT offers a range of ISO 15022 standards (MTs) to instruct and confirm the settlement of securities trades. A related set of standards is available for corporate action announcement, status, instructions, and confirmations. There are also ISO 15022 standards for the reporting of pending transactions, settled transactions and holdings. These statements are exchanged between an account servicer and an account owner for reconciliation purposes. The below section explains the above related MTs, and provides a series of guidelines facilitating the common usage of those message types. A set of business examples is provided at the end of this section.

Settlement, Status and Allegement Messages

The SWIFT User Handbook, Volume Standards Category 5, Securities Markets as well as SMPG Settlement & Reconciliation Final Market Practices serve as the main documents describing the standards.

MT 540-3 Settlement Instructions

Scope The MT 540-3 is sent by the corporate to the custodian bank. This message is used to: instruct the receipt or delivery of financial instruments free or against payment, physically or by bookentry, from a specified party (the function of the message is NEWM) request the cancellation of a previously sent instruction by the account owner (the function of the message is CANC) pre-advise of a forthcoming receipt or delivery of financial instruments free or against payment instruction (the function of the message is PREA). The instruction may be linked to other settlement instructions, for example, for a turnaround or back-toback or other transactions, for example, foreign exchange deal, using the linkages sequence. The MT 540 is used for Receive Free Instruction. The MT 541 is used for Receive against Payment Instruction. The MT 542 is used for Deliver Free Instruction. The MT 543 is used for Deliver against Payment Instruction. Message usage guidelines

The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 540-3 contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement instructions, the SMPG publications are the following: Equity and fixed income settlement global practice Securities lending and borrowing settlement Securities Standards 17 December 2008 57 Block trades Book transfer ISO 15022 message function usage ISO 15022 linkages usage Status reporting Pair-off Partial settlement Physical settlement Place of safekeeping Place of settlement Pre-advice (hold/release process) Repurchase agreement settlement Sell-buy/buy-sell back settlement Settlement instruction linked FX Country specific requirements (25+ countries)

MT 548 Settlement Statuses and Processing Advice

Scope The MT 548 is sent by the custodian bank to the corporate. This message is used to: advise the status of a settlement instruction (the function of the message is INST) As a reply to a cancellation request previously sent by the corporate (the function of the message is CAST) report on future settlement, or forward transactions, for example, free receipts for which no instruction is required, which have become binding to the corporate Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 3, MT 548, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of Settlement Status and Processing Advice, the SMPG publications are the following: ISO 15022 message function usage ISO 15022 linkages usage

 Status reporting (MT 548, 537)

MT 544-7 Settlement Confirmations

Scope The MT 544-7 is sent by the custodian bank to the corporate. This message is used to: confirm a delivery or receive of financial instruments against or free of payment (function of the message is NEWM) request the cancellation or reversal of a previously sent confirmation (function of the message is CANC or RVSL) The MT 544 is used to confirm a Receive Free Instruction The MT 545 is used to confirm a Receive against Payment Instruction The MT 546 is used to confirm a Deliver Free Instruction SWIFT for Corporate 62 Standards MT Messages Implementation Guidelines The MT 547 is used to confirm a Deliver against Payment Instruction Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 3, MT 544-7, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages.

MT 578 Settlement Allegement

Scope The MT 578 is sent by the custodian bank to the corporate. This message is used to: advise the corporate that counterparty has alleged a settlement instruction against the corporate account at the custodian, and that the custodian could not find the corresponding instruction (the function of the message is NEWM) request the cancellation or removal of a previously sent settlement allegement (the function of the message is CANC or REMO) Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 4, MT 578 contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement allegement, the SMPG publications are the following:

 ISO 15022 message function usage ISO 15022 linkages usage Settlement allegements (MT 578, 586)

Reconciliation Messages
The SWIFT User Handbook, Volume Standards Category 5, Securities Markets as well as SMPG Settlement & Reconciliation Final Market Practices serves as the main documents describing the standards. Reconciliation messages are sent by a custodian bank to a corporate. The choice of statement and the frequency is typically described in a service level agreement. It is however possible (When this service is offered) to request a statement using the MT 549 Request for Statement/Status Advice (for info on MT 549 formats, see the SWIFT User Handbook).

MT 537 Statement of Pending Transactions

Scope The MT 537 is sent by the custodian bank to the corporate. This message is used to: provide the corporate with the details of pending transactions at a specified moment in time. The message may contain details for all, or a selected quantity of securities for a specified safekeeping account. It may also give all, or a selected number of reasons why the transaction is pending. The statement may also include future settlement, or forward, transactions which have become binding to the account owner. The statement may be sorted per status or per transaction. (The function of the message is NEWM) request the cancellation of a previously sent statement (the function of the message is CANC) Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 537, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages.

On the Statement of Pending Transactions, the SMPG publications are the following: ISO 15022 message function usage ISO 15022 linkages usage Status reporting (MT 548, 537)

MT 536 Statement Transactions

Scope

The MT 536 is sent by the custodian bank to the corporate. This message is used to: provide the details of any increases and/or decreases of holdings, which may have occurred over a specified period of time, for all, or a selected quantity of securities in the safekeeping account which the custodian bank holds for the corporate request the cancellation of a previously sent statement (the function of the message is CANC) Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 536, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the Statement of Transactions, the SMPG publications are the following: ISO 15022 message function usage ISO 15022 linkages usage Statement of Transaction (MT 536 MP)

MT 535 Statements of Holdings

Scope The MT 535 is sent by the custodian bank to the corporate. This message is used to: Report on the quantity and identification of financial instruments which the custodian bank holds for the corporate at a specified moment in time (the function of the message is NEWM) When the message is sent by a custodian to a customer, the statement must be clearly identified as either custody, or an accounting statement. The custody statement reports on the availability and/or the location of security holdings, to facilitate trading and minimize settlement issues. The Accounting Statement provides valuations of the portfolio with details of each security holding, it is not used for trading purposes. request the cancellation of a previously sent statement (the function of the message is CANC) Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 2, MT 535, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporate must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the Statement of Transactions, the SMPG publications are the following: ISO 15022 message function usage ISO 15022 linkages usage Statement of Holdings (MT 535 MP)

MT 586 Statement of Settlement Allegements

Scope The MT 586 is sent by the custodian bank to the corporate. This message is used to: provide the details of pending settlement allegements, for all or selected securities in a specified safekeeping account, for a given point in time (the function of the message is NEWM) request the cancellation of a previously sent statement of settlement allegements (the function of the message is CANC) Message usage guidelines The SWIFT User Handbook, Volume Standards Category 5, volume 4, MT 586, contains full field specifications and network validated rules that must be adhered to. No corporate specific usage has been identified. Corporates must comply with the network validated and usage rules published in the User Handbook and to the SMPG recommendations existing for these messages. On the subject of settlement allegement, the SMPG publications are the following: ISO 15022 message function usage ISO 15022 linkages usage Settlement allegements (MT 578, 586)

Asset Servicing Messages Scope

MT 564
The MT 564 is sent by the custodian bank to the corporate. This message is used to: notify a corporate (account owner) with the details of a corporate action event occurring on an instrument that the corporate (account owner) holds (function of the message is NEWM) replace a previously sent notification with corrected or additional details (function of the message is REPL) inform about the entitlement details to the corporate (function of the message is REPE). According to the corporate action event type, the MT 564 entitlement calculation will specify the impact to the safekeeping account and/or the cash account based on: - The number of underlying shares held by the corporate (account owner) - The payment ratio and the terms of the offer (whether this is in the form of rights, shares, cash or options) - The option selected by the corporate (account owner) remind of a corporate action for which the corporate (account owner) must instruct (the function of the message is RMDR) withdraw a notification for an event that will finally not take place (the function of the message is WITH)

 request the cancellation of a previously sent notification that was, for example, sent by mistake (the function of the message is CANC)

MT 565
The MT 565 is sent by the corporate to the custodian bank. This message is used to: provide the custodian with instructions on how the corporate (account owner) wishes to proceed with a voluntary or mandatory (with options) corporate action event. Instructions include investment decisions regarding the exercise of rights issues, the election of stock, or cash, when the option is available, and decisions on the conversion or tendering of securities (function of the message is NEWM) request the cancellation of a previously sent instruction that was, for example, sent by mistake (the function of the message is CANC) Securities Standards 17 December 2008 75

MT 566
The MT 566 is sent by the custodian bank to the corporate. This message is used to: confirm to the corporate that securities and/or cash have been credited/debited to an account, as the result of a corporate action event (function of the message is NEWM) reverse a previously sent confirmation (the function of the message is REVR)

MT 567
The MT 567 is sent by the custodian bank to the corporate. This message is used to: advise the status, or a change in status, of a corporate-action-related transaction previously instructed by, or executed on behalf of, the corporate. This will include: - The acknowledgment/rejection of a corporate action instruction (function of the message is INST) or - The acknowledgment /rejection of a request to cancel an outstanding instruction (function of the message is CAST) - It may also be used to provide the reason a corporate action event has not been completed by the announced payment dates (function of the message is EVST)

MT 568
The MT 568 is sent by the custodian bank to the corporate or from the corporate to the custodian. Sent by the custodian bank to the corporate, this message is used to provide narrative details relating to a corporate action event. Sent by the corporate to the custodian bank, this message is used to provide complex instructions.