S.W.I.F.T.

Amruta Kadam10030141074 Sreyasi Roy 10030141084 Pranav Kataria 10030141114 Abhinav Misra 10030141124

SICSR MBA-IT BFM-II

9/29/2011

Index
INDEX .............................................................................................................................................................. 2 INTRODUCTION ............................................................................................................................................... 5 MISSION: .............................................................................................................................................................. 5 VISION .................................................................................................................................................................. 5 CONCRETE ACTIVITIES:.............................................................................................................................................. 6 SWIFT USERS.................................................................................................................................................... 7 SWIFT USERS ........................................................................................................................................................ 7 MARKET DISTRIBUTION ................................................................................................................................... 9 MARKET DISTRIBUTION (YEAR 2011) ......................................................................................................................... 9 REGIONAL DISTRIBUTION (YEAR 2011) ....................................................................................................................... 9 SWIFT SERVICES ............................................................................................................................................. 10 ARCHITECTURE .............................................................................................................................................. 11 DISTRIBUTED ARCHITECTURE ................................................................................................................................... 11 SWIFTNET NETWORK ..................................................................................................................................... 13 FIN .................................................................................................................................................................... 14 INTERACT ............................................................................................................................................................ 16 FILEACT............................................................................................................................................................... 18 BROWSE .............................................................................................................................................................. 19 SWIFT ADDRESSES ......................................................................................................................................... 21 BANK IDENTIFIER CODES (BICS) ............................................................................................................................... 21 IBAN (INTERNATIONAL BANK ACCOUNT NUMBER) ..................................................................................................... 22 STANDARDS ................................................................................................................................................... 24 SWIFT MESSAGES .......................................................................................................................................... 26 STRUCTURE OF A MESSAGE ..................................................................................................................................... 26 LENGTH OF A MESSAGE .......................................................................................................................................... 27 PRESENTATION OF A MESSAGE................................................................................................................................. 27 SWIFT CHARACTER SET ......................................................................................................................................... 36 CASH MANAGEMENT ..................................................................................................................................... 76 SWIFTNET BULK PAYMENTS .................................................................................................................................. 77 Benefits ........................................................................................................................................................ 77 Features & Components............................................................................................................................... 77 SWIFTNET CASH REPORTING ................................................................................................................................. 80 Benefits ........................................................................................................................................................ 80 Key characteristics ....................................................................................................................................... 80 Industry trends ............................................................................................................................................. 81 Features & Components:.............................................................................................................................. 82 Market infrastructure cash Management ................................................................................................... 84 Cash reporting for financial Institutions....................................................................................................... 86

2|Page

Application models....................................................................................................................................... 88 Exceptions and Investigations ...................................................................................................................... 88 Benefits: ....................................................................................................................................................... 89 The SWIFT E&I service: ................................................................................................................................. 89 Example of E&I Workflow: ........................................................................................................................... 90 TREASURY & DERIVATIVES ............................................................................................................................. 91 SWIFTNET ACCORD.............................................................................................................................................. 92 Reviewing Treasury Operations ................................................................................................................... 92 Assisting with the selection of a Treasury Workstation ............................................................................... 92 FX OPTIONS ON ACCORD FOR TREASURY ................................................................................................................. 93 Benefits: ....................................................................................................................................................... 93 How does Accord for Treasury work? .......................................................................................................... 96 SWIFT AFFIRMATIONS ........................................................................................................................................ 100 Benefits ...................................................................................................................................................... 100 How SWIFTNet Affirmations works? .......................................................................................................... 101 Instruments supported by Affirmations ..................................................................................................... 102 SWIFTS CLSTHIRD PARTY SERVICE ..................................................................................................................... 103 Benefits ...................................................................................................................................................... 103 How SWIFTs CLSThird Party Service works? ............................................................................................ 104 Case Study: TMS Infrastructure .................................................................................................................. 105
The business challenge .................................................................................................................................. 105 The technology solution ................................................................................................................................ 105 The activities .................................................................................................................................................. 105 Advice and experience ................................................................................................................................... 106

SECURITIES .................................................................................................................................................. 107 SWIFT IN THE SECURITIES MARKET ......................................................................................................................... 107 SWIFTNET FIX .................................................................................................................................................. 108 SWIFTNET FUNDS .............................................................................................................................................. 109 Why SWIFTNet Funds? ............................................................................................................................... 109 Benefits of using SWIFT .............................................................................................................................. 110 ACCORD FOR SECURITIES ...................................................................................................................................... 111 Why do I need Accord for Securities? ........................................................................................................ 111 What benefits does Accord for Securities bring? ....................................................................................... 111 Who can use Accord for Securities? ........................................................................................................... 112 1. Matching of trades between prime brokers and executing brokers ...................................................... 113 2. Matching of trades between custodians and executing brokers ........................................................... 115 3. Matching of trades between two executing brokers ............................................................................. 117 Key features of Accord for Securities ......................................................................................................... 118 SWIFTNET TRADE SERVICES UTILITY............................................................................................................. 120 THE EVOLUTION OF TRADE AND ADOPTION OF OPEN ACCOUNT TRADING. ..................................................................... 120 SUPPLY CHAIN CHALLENGES .................................................................................................................................. 121 Buyers and sellers are driven by different needs ........................................................................................ 122 Driving costs down ..................................................................................................................................... 122 Coping with growth.................................................................................................................................... 123 Managing working capital ......................................................................................................................... 123 Managing information flows ..................................................................................................................... 123 MEETING THE SUPPLY CHAIN CHALLENGE ................................................................................................................ 124

3|Page

WHAT IS SWIFTNET TRADE SERVICES UTILITY? ........................................................................................................ 124 TSU ENABLED SERVICES ....................................................................................................................................... 127 SIMPLE TSU OPEN ACCOUNT FLOW ....................................................................................................................... 131 TSU BENEFITS TO BANK AND CORPORATE................................................................................................................ 133

4|Page

Introduction
The Society for Worldwide Interbank Financial Telecommunication ("SWIFT") operates a worldwide financial messaging network which exchanges messages between banks and other financial institutions. SWIFT also markets software and services to financial institutions, much of it for use on the SWIFTNet Network, and ISO 9362 Bank Identifier Codes (BICs) are popularly known as "SWIFT codes".

Mission:
To enable interoperability between our members, their market infrastructures and their end-user communities

Vision
Embed Corporate Social Responsibility(CSR) in the SWIFT corporate mindset and make it an intrinsic part of the company strategy Leverage SWIFT's role as the CSR/sustainability facilitator within the financial industry

The majority of international interbank messages use the SWIFT network. As of September 2010, SWIFT linked more than 9,700 financial institutions in 209 countries and territories, who were exchanging an average of over 15 million messages per day. SWIFT transports financial messages in a highly secure way, but does not hold accounts for its members and does not perform any form of clearing or settlement. SWIFT does not facilitate funds transfer, rather, it sends payment orders, which must be settled via correspondent accounts that the institutions have with each other. Each financial institution, to exchange banking transactions, must have a banking relationship by either being a bank or affiliating itself with one or more particular business features. SWIFT has its headquarters in Belgium and has offices in the world's major financial centres and developing markets. SWIFT headquarters are located in La Hulpe, Belgium, near Brussels. SWIFT provides additional products and associated services through Arkelis N.V., a wholly owned subsidiary of SWIFT, the assets of which were acquired from SunGard in 2010. SWIFT does not hold funds nor does it manage accounts on behalf of customers, nor does it store financial information on an on-going basis. This activity involves the secure exchange of proprietary data while ensuring its confidentiality and integrity. The opening up of SWIFT to the corporate community has not been without controversy many of SWIFTs financial institution members felt corporate access would dis-intermediate banks if corporates could communicate with each other across the network they could perhaps cut financial institutions out of the loop. That is why corporate access has been developed in a measured way by SWIFT and its member banks. Even today, a significant number of banks still take a defensive approach towards offering corporate services through SWIFT. The first step to bring corporates on to SWIFT was the introduction of treasury

5|Page

confirmation messages in 1997, which allowed for limited activity from corporates, without enabling payments to be initiated through SWIFT or statements to be received. Payments (e.g. cross-border, domestic, corporate) Securities (e.g. equity, fixed income, funds) Treasury (e.g. foreign exchange, swaps, options) Trade Services (e.g. letters of credit)

Concrete activities:
Establish secure and reliable network application Standardize information flows (messages)

6|Page

SWIFT Users
SWIFT Users
Although originally the network was designed to support the requirements of Treasury and Correspondent banking operations, it has over the years allowed other institutions access to the services, albeit in some cases only to a limited degree. Currently the following categories of organization can access the service: Banks Trading Institutions Money Brokers Securities Broker Dealers Investment Management Institutions Clearing Systems and Central Depositories Recognized Exchanges Trust and Fiduciary Service Companies Subsidiary Providers of Custody and Nominees Treasury Counterparties

The Society is owned by its Members, and in order to become the member of the organization one must hold a Banking License. In return Members own shares in the society and have voting rights. SWIFT user categories The SWIFT user categories are defined in three main groups. Supervised Financial Institution This group also includes shareholders (Members). Non-Supervised Entity active in the financial industry Closed User Groups and Corporate entities. This group is composed of the following SWIFT user categories: Corporate, Financial Market Regulator, Payment System Participant, Securities Market Data Provider, Securities Market Infrastructure System Participant, Service Participant within Member Administered Closed User Group and Treasury Counterparty.

The eligibility criteria are described in the Corporate Rules.

7|Page

Shareholding Eligibility The following types of organisations are eligible for shareholding: Shareholder (Member) An eligible organisation holding a share in S.W.I.F.T. SCRL, including banks, eligible securities broker-dealers and regulated investment management institutions. Details about SWIFT shareholding can be found in the SWIFT Bylaws. Non-Shareholding Member A Non-Shareholding Member is an organisation which complies with the eligibility criteria of a Shareholder (Member), and which has either chosen not to or is prevented from becoming a Shareholder. Sub-Member A Sub-member is an organisation more than 50 percent directly or 100 percent indirectly owned by a shareholder and which meets the criteria set forth for shareholder. A Sub-member must be under full management control of the shareholder.

8|Page

Market Distribution
Market Distribution (Year 2011)
SWIFTNet FIN total traffic distribution and growth by market Data Traffic Distribution Payment ** 162,998,805 48.12% Securities 150,734,837 44.50% Treasury 20,313,239 6.00% Trade Finance 3,540,838 1.05% System 1,161,110 0.34% Total 338,748,829 100.00%

Regional Distribution (Year 2011)

Region Europe, Middle east, Africa Americas Asia-Pacific Total Traffic 226,435,208 69,782,890 42,530,731 338,748,829 Distribution 66.84% 20.60% 12.56% 100.00%

9|Page

SWIFT Services
SWIFT operates a number of services, primarily: 1. General Purpose Application(GPA) - only allows system messages, i.e. Messages from a user to SWIFT and vice versa, not from one user to another. 2. Financial Application (FIN) - which is the user to user service comprising, System Messages MT0nn, User to User Messages MT1nn through 9nn and Service Messages such as Acknowledgements. Additionally, SWIFT provide a number of services that are charged for over and above the normal fees. In summary these are: 3. Interbank File Transfer(IFT ) - For bulk file transfer of messages, for example low net value, high volume Retail payments. 4. ACCORD - A centralized confirmation matching bureau service. 5. Directory Services - An automated and centralized Standard Settlement Instruction service for message enrichment that at present is limited to Treasury and Payment information. 6. Real Time Gross Settlement (RTGS) (Y-copy) - Mostly used for sending a copy of a message or parts thereof to a third party, for example a Central Bank. 7. Country Specific (e.g. CREST, CHAPSEuro) - Where SWIFT is either the carrier of the messages or the supplier of additional network services

10 | P a g e

Architecture
Distributed Architecture
SWIFTs distributed architecture partitions messaging into zones, with pairs of operating centre cooperating to process and store traffic for each zone. To address the data protection concerns for zones like the European Zone, this architecture enables storing of the intra-zone data in the same zone.

OPC = Operating Center

Figure: Distributed architecture The distributed architecture is being implemented in two phases: Phase 1 calls for the minimum implementation possible that addresses European data protection concerns and delivers the highest priority resilience improvements. To implement phase 1 in the shortest possible period, SWIFT accelerated delivery by leasing data centre space from a hosting company. The new European operating centre OPC CH, will serve as the companion for the existing Netherlands operating centre to process and store traffic for the European Zone. The existing Netherlands operating centre serves as the companion to the US operating centre to process and store traffic for the Trans-Atlantic Zone. In other words, the Netherlands operating centre is the global operating centre. Phase 2 plans to further enhance the security and reliability of SWIFTs messaging services through specific system and operating centre enhancements.

2. Messaging zones
Distributed architecture allocates traffic to zones. For technical and data protection reasons, SWIFT allocates traffic to zones on a country-by-country basis. In other words, each country is hosted in either the European Zone or the Trans-Atlantic Zone. Upgraded customer interfaces connect to zones at the BIC8 level, with the country code in the BIC8 being used to determine the zone to which to connect.
11 | P a g e

FIN messages exchanged between compliant BIC8s connected to the same zone are processed and stored only in that zone; FIN messages exchanged between compliant BIC8s connected to different zones are processed and stored in both zones. SWIFTNet store-andforward storage and processing, for both messages and files, continues to be performed in the EU zone.

Inter-zone message processing and storage

3. Country to zone allocation

Distributed architecture requires the allocation of countries to zones. For reasons of data protection, the countries in the European Economic Area (EEA), Switzerland and other territories and dependencies considered a part of the European Union or associated with European countries have been assigned to the European Zone. To balance traffic and connections across zones, the default allocation of remaining countries is to the Trans-Atlantic Zone, except in cases where a country has requested to be included in the European messaging zone. This preference, expressed by the National Member Group Chairperson, reflects the majority opinion within the country.

4. Availability reporting
SWIFT reports on availability for SWIFTNet and FIN core messaging systems. These statistics, currently provided as weighted percentages, have historically reported on global availability. Starting in February 2010 SWIFT publishes availability information per zone.

12 | P a g e

SWIFTNet Network
SWIFT moved to its current IP Network infrastructure, known as SWIFTNet, from 2001 to 2005, providing a total replacement of the previous X.25 infrastructure. The process involved the development of new protocols that facilitate efficient messaging, using existing and new message standards. The adopted technology chosen to develop the protocols was XML, where it now provides a wrapper around all messages legacy or contemporary. The communication protocols can be broken down into:

SWIFTNet provides a basis for assuring business continuity and disaster recovery for the infrastructure of mission-critical financial applications that cross institutional boundaries. SWIFTNet is designed to satisfy institutional community requirements for interoperability of mission-critical financial software solutions. The communication protocols can be broken down into: FIN InterAct FileAct Browse

13 | P a g e

FIN
FIN is SWIFTs core messaging service. It enables financial institutions to exchange individual structured financial messages securely and reliably. FIN is used by over 8,000 financial institutions and their corporate customers worldwide to exchange 15 million messages per day across a wide range of business areas within the banking and securities industries. FIN works in store-and-forward mode, which makes it easy to exchange messages with a large number of correspondents, many of whom may not be online at the time of transmission. Store-and-forward removes the uncertainty and inconvenience of worrying about whether or not your correspondents are online at the time you send the message. Your message is delivered as soon as the recipient is ready to receive it. FIN provides an ideal way to send individual instructions, confirmations and reports to large numbers of correspondents, regardless of their geographical locations or time zones.

Payment Process Flow (Step-wise) 1. 2. 3. 4. 5. 6. 7. 8. 9. Customer Sends Payment Instruction to his Bank Branch Branch forwards instruction to Bank SWIFT service branch Customer branch sends a (Direct) Advice MT 103 - to the Beneficiary Bank Service branch instructs the payment (bank-to-bank) to his Currency Correspondent (Senders Correspondent) Correspondent transfers funds to the Beneficiary Banks Currency Correspondent (typically through the local clearing in the instruction currency) Beneficiary Banks Correspondent pays funds to the Beneficiary Bank country/regional SWIFT service branch SWIFT service branch credits funds to Beneficiary bank branchs books and sends a credit advice Beneficiary Bank branch credits the Beneficiary A/c and sends an advice to the Beneficiary Currency Correspondent sends an EOD Account Statement to the Beneficiary Bank Service Branch

14 | P a g e

Standard FIN features FIN includes the following key standard features: SWIFTNet PKI security: FIN offers authentication and integrity control based on the SWIFTNet PKI infrastructure. Closed user group control: Each FIN message is controlled for compliance with the predefined message exchange and closed user group rules that determine which users can send what type of messages to which other users. Non-compliant messages are not delivered. Message validation: FIN supports central message validation of a wide range of SWIFT MT standards, which are used across a broad range of business areas within the financial industry. Non-repudiation: In case of dispute, SWIFT is able to confirm that a message exchange did take place as claimed. Relationship Management: Users can control the FIN traffic they receive from others using SWIFTs Relationship Management Application (RMA). Optional FIN features These can significantly improve your operational control over your business: User-selectable priority: Messages can be flagged as urgent to allow for appropriate processing by your correspondents. Delivery notification: This provides confirmation that your correspondent received your message. Non-delivery warning: This informs you that a message remains undelivered after a certain period of time. Online retrievals: Users can retrieve SWIFTNet FIN messages they have exchanged in the previous 124 days. User broadcasts: Users can send broadcasts to all other FIN users, or to a group of users. FIN Copy: Selected FIN messages can be fully or partially copied to a central point (TCopy). In addition, their delivery to the intended destination can be made conditional on approval by the central point (Y-copy). This feature is frequently used in the context of highvalue payments clearing systems. FINInform: Some or all FIN messages sent or received by an institutions subsidiary or branch can also be fully or partially enabled to centrally process, or allow monitoring of activities, outsourcing or regulatory reporting.

15 | P a g e

InterAct

InterAct offers different working modes to meet your specific needs: Store-and-forward messaging: InterActs store-and-forward capability is designed for messages destined for a large number of correspondents, many of whom may not be online at the time of transmission. It removes the uncertainty and inconvenience of worrying about whether or not your correspondents are online at the time you send the message. The message is delivered as soon as the recipient is ready to receive it. As a result, SWIFTNet InterAct provides an ideal way to send individual instructions, confirmations and reports to large numbers of correspondents, even in different time zones. Real-time messaging: Real-time messaging offers an alternative to store-and forward to correspondents who are online at the time of transmission, such as market infrastructures or large correspondents expecting to receive an instruction or confirmation and that do not need store-and-forward added-value features. Real-time query and response: This is an interactive service typically used in the context of workstation based online enquiry or reporting systems. It is often used in conjunction with Browse.

Standard InterAct features InterAct includes the following key standard features: SWIFTNet PKI security: InterAct is secured with SWIFTNet PKI and offers message authentication, encryption and integrity control. Closed user group control: Each InterAct message is controlled for compliance with predefined closed user group rules that determine which users can send messages to which other users. Non-compliant messages are not delivered. Message validation: InterAct supports central message validation of XML-based SWIFT standards.

16 | P a g e

Advanced delivery control (store-and-forward mode): Interact offers a number of messaging features to control traffic delivery.

Optional InterAct features InterAct offers the following key optional features: User-selectable priority: Messages can be flagged as urgent to allow for appropriate processing by your correspondents. Delivery notification (store-andforward mode): This provides confirmation that your correspondent received your message. Non-repudiation of emission and reception: In case of dispute, this allows SWIFT to confirm that the message exchange did take place as claimed.

17 | P a g e

FileAct

FileAct enables financial institutions to transfer files in a secure and reliable manner. FileAct provides a cost-effective way to transfer bulk files in different formats to your correspondents, while leveraging the unparalleled security and reliability inherent in the SWIFTNet platform. Whether it is for bulk payments processing, transmission of cheque images, securities valueadded information and reporting, or other business areas such as central-bank reporting or corporate-to-bank instructions and reporting, most financial institutions require the ability to exchange files in a secure, reliable and cost-effective manner. FileAct allows you to do precisely that. The benefits are significant and extend far beyond the realms of traditional file transfer solutions. FileAct offers different working modes to meet your specific needs: Store-and-forward file transfer: FileActs store-and-forward capability removes the uncertainty and inconvenience of worrying about whether or not your correspondents are online at the time you transmit the file. The file is delivered as soon as the recipient is ready to receive it. As a result, it provides an ideal way to send files to large numbers of correspondents, some of which may be in different time zones. Real-time file transfer: Real-time file transfer allows an institution to send files to correspondents who are online at the time of transmission. It is an efficient and costeffective way to exchange files with market infrastructures or large institutions. Real-time file download: This is an interactive service typically used to download files from the system of a correspondent. It is often used to download files in the context of workstation-based systems. FileAct Header Copy: For selected files, SWIFT can copy the file header to a central point (T-Copy). In addition, the file delivery to the intended destination can be made conditional to an approval by the central point (Y-copy). This feature is typically used in the context of payments clearing systems.

18 | P a g e

FileAct features that Files supported Any character set Any content structure File size up to 250 Mbytes File transfer security Based on SWIFTNet PKI (managed certificates) Closed user group control Encryption Authentication control Integrity control Non-repudiation of emission and reception (optional)

Transfer reliability Automatic handling of intermittent communication failures Monitoring of transfer progress and status Delivery notification provides explicit confirmation of delivery by receiver (optional) Throughput management and traffic prioritisation

Enhanced header Dedicated optional header block to specify key business summary information (for example, number of payments or total amount) Allows file handling (such as routing) without having to open the file

Browse

19 | P a g e

Browse enables users to browse on financial online portals made available by financial institutions and market infrastructures on SWIFTNet. It combines the user friendliness of web technology with the security features offered by SWIFTNet. Financial institutions and market infrastructures that make their web portals available on SWIFTNet benefit from a more convenient and attractive delivery channel to their clients, while reducing costs and improving the security and reliability of their services. Browse features Browse includes the following key features: Browser-based: Access to a Browse service is via a standard Internet browser (such as Microsoft Internet Explorer) and the Alliance WebStation software. There is no need to install any software or hardware from the provider of the online portal. Browsing security: Browse exchanges are secured by the combined use of the Secure Socket Layer protocol and SWIFTs secure IP network. InterAct and FileAct security: Sensitive business or security data exchanges such as payment orders, confirmations, account balances, user IDs and passwords are exchanged through InterAct or SWIFTNet FileAct. Such exchanges benefit directly from all the features of these services, including their high security and reliability. Their use is made invisible to the person browsing. Closed user group control: Browse exchanges are only permitted within defined closed user groups

20 | P a g e

SWIFT Addresses
SWIFT addresses are used to not only indicate the final destination of the message but to also indicate parties within the individual message. It is the use of strictly codified addresses that enables the automation of Straight through Processing in conjunction with the fixed tag format of the messages themselves.

Bank Identifier Codes (BICs)

SWIFT network to have a BIC and these can therefore be used over other networks such as Telex. SWIFT is, however, the recognized ISO (International Standards Organization) body for assigning these. The following shows the general format of a BIC address AAAA Bank BB Country CC Location (D) LT (EEE) Branch

The first four characters represent the Bank code, for example NWBK (NatWest), DEUT (Deutsche Bank). The next two characters represent the ISO Country code, for example GB (United Kingdom), DE (Germany). The next two characters are the location code with some larger financial centers such as London and New York having two, 2L and 22, 33 and 3N respectively. These characters, the first 8, represent the mandatory portions and commonly within the body of a message this will be the normal format, for example NWBKGB2L (NatWest London), DEUTDEFF (Deutsche Bank Frankfurt). The presence of 0 (zero) in position 8 indicates that this is a test & training address. Test & Training is a facility which SWIFT gives its users to test new releases without interfering with live operations. When an organization first joins SWIFT they must spend two months sending messages in test & training before they are allowed to go live. Optionally a three character branch code can be added at the end of the address. For example NWBKGB2LBIR might be the Birmingham branch. These codes are primarily used for internal routing purposes within the bank, as the branches themselves do not have direct connection. Usage is often more common in some countries than others such as the heavy use by Italian banks. The Logical Terminal ID in position 9 will be present in the header of the message and identifies a logical channel connection to SWIFT. Some organizations may run more than 1 LT on the same CBT and these will be referred to as A, B, C, etc. For example: NWBKGB2LA. These are not published in the BIC directory and so all addresses within a message identifying the sender or other parties will not contain this character.
21 | P a g e

LTs will therefore always be padded out to 12 Characters by X's and SWIFT addresses are therefore either 8 or 11 characters. The presence of a 1 in position 8 denotes that this is not a SWIFT address but the organization has requested that an ISO identifier be allocated to them. For example NWBKGB21. Therefore, this address can be included in the body of a message but you cannot send a message via SWIFT to them. The presence of an X in position 8 denotes that the CBT which is processing traffic for this address is not physically in the same country as the Country Code states.

IBAN (International Bank Account Number)

An IBAN or International Bank Account Number is a series of alphanumeric characters that uniquely identifies a customers account held at a bank anywhere in the world. Cross-border transactions introduce a further level of complexity above that of domestic clearing, as there are many variations in the way countries undertake payment processing. Since it is unrealistic to expect the payment Originator to understand the subtleties of multiple domestic clearing systems, it is not surprising that error rates for international payments are significant. These errors frequently lead to payments being rejected, resulting in a negative impact on customer service and increased administration costs. The IBAN has been introduced to help reduce problems with cross-border transactions by providing a standard format for displaying and validating international bank account numbers. An International Bank Account Number typically contains a two-character ISO country code, two check digits for validation purposes followed by the domestic bank code and account number. Example of a UK IBAN:

The format of the IBAN helps to ensure that cross-border payments are processed correctly. The country code indicates the country in which the IBAN was issued and also acts as a reference to the structure of the domestic account number contained within the IBAN. In addition the check digits validate the complete IBAN to ensure it has been entered correctly and has not been corrupted.

22 | P a g e

IBAN has helped to structure cross-border transactions, it is only part of the solution to eliminating errors in payments. For example, it is quite feasible to generate a valid IBAN containing invalid domestic details which would result in the payment being rejected. IBAN validation is only one step in the process to correctly and efficiently route cross-border payments.

23 | P a g e

Standards
SWIFT has become the industry standard for syntax in financial messages. Messages formatted to SWIFT standards can be read by, and processed by, many well known financial processing systems, whether or not the message actually travelled over the SWIFT network. SWIFT cooperates with international organizations for defining standards for message format and content. SWIFT is also registration authority (RA) for the following ISO standards: ISO 9362: 1994 Banking telecommunication messages: Bank identifier codes ISO 10383: 2003 Securities and related financial instruments: Codes for exchanges and market identification (MIC) ISO 13616: 2003 IBAN Registry ISO 15022: 1999 Securities: Scheme for messages (Data Field Dictionary) (replaces ISO 7775) ISO 20022-1: 2004 and ISO 20022-2:2007 Financial services: UN Iversal Financial Industry message scheme

SWIFT offers a range of standards to initiate, and to clear and settle financial institution payments. A related set of standards is available to handle exceptions and investigations for these payments, as well as standards that provide account related information exchanged between an account owner and an account servicer.

24 | P a g e

MT
In the MT portfolio for financial institutions, the MT 202 is the de facto standard used to cover customer credit transfers, and to settle payments resulting from other business transactions such as securities and treasury transactions. Other Category 2 MTs are available for cheque truncation, financial market debits and requests for transfers. Common Group MTs can be used to handle queries, replies, rejects, returns and requests for cancellations. A set of Category 9 Cash Management MTs can be used by financial institutions to provide information on financial institution accounts for cash management and reconciliation purposes.

MX
ISO 20022 messages are available to execute financial institution credit transfers. Related messages are available to communicate about status, returns, reversals and requests for cancellations of the financial institution credit transfers. ISO 20022 exceptions and investigations messages allow parties involved in the payment to initiate queries and track replies related to the investigations. An interactive set of MX messages for interbank account information and cash management is available.

25 | P a g e

SWIFT Messages
SWIFT processes information (i.e., data, text, or commands) in the form of messages. SWIFT initially offers two applications 1. General Purpose Application (GPA) which controls how users communicate within SWIFT. 2. Financial Application (FIN) which controls the user to user messaging facilities within SWIFT. These together provide all of the messaging functions and facilities available to users. Actual appearance of a SWIFT message (whether on screen or on paper) is dependent upon how their Computer-based terminal (CBT) has been programmed and on any internal processing of SWIFT messages carried out within their own organization. A validation error in the application header, text or trailer block will result in a negative acknowledgment (NAK) indicating the reason for rejection. Each message received by the system is examined to determine whether it conforms to the format specification for that message type. The sequence in which the various parts of a SWIFT message are validated is as follows: 1. 2. 3. 4. 5. Basic header Application header User header Text Trailers

At the first validation failure, the appropriate error procedure is carried out (either session abortion or negative acknowledgment) and no further validation is performed on the message.

Structure of a Message
All SWIFT messages conform to a defined block structure. Each block of a message contains data of a particular type and is used for a particular purpose. Each block of message begins and ends with a curly bracket (or brace) character "{" and "}" respectively. All main blocks are numbered, and the block number followed by a colon (:) are always the first characters within any block.

A typical SWIFT user-to-user message may consist of: 1: Basic Header Block

26 | P a g e

2: Application Header Block 3: User Header Block 4: Text Block 5: Trailers Block Only block 1 (the Basic Header block) is mandatory for all messages. Blocks 2-5 are optional and depend upon the nature of the message and on the application in which the message is being sent or received. Blocks 1, 2 and 3 relate to header information, block 4 contains the text of the message, and block 5 contains trailer information. Blocks 3, 4 and 5 may contain sub-blocks (i.e., blocks within blocks) or fields delimited by field tags, depending on the nature of the message. At the first validation failure, the appropriate error procedure is carried out (either session abortion or negative acknowledgment) and no further validation is performed on the message.

Length of a Message
The type of SWIFT message will determine the maximum length allowed for the particular message. Individual transaction messages such as the 520 series of messages permit for a maximum message length of 2000 bytes. Statement type messages such as the 950 or 570 series of messages permit a maximum of 10,000 bytes.

Presentation of a Message
Each main block is sub-divided into a number of fields and each field contains particular information (e.g., date, time, LT address, session number, ISN, or a tag number followed by the appropriate variable content). All fields within header blocks 1 and 2 are of fixed length and are continuous - no field separators are used. In the case of the text of a user-to-user message, all message text within the Text block (block 4) begins with Carriage Return and Line Feed (CrLf) and ends with CrLf followed by a hyphen (-). Each field within the text begins with a tag number followed by a colon, followed by the appropriate variable content. For the purpose of clarity within this manual, some message examples are shown here with each block beginning a new line and with spaces separating the various fields within blocks. The block separators "{" and "}" are also shown. The letters a,b,c,d, etc., are used in these examples to identify the constituent parts of each block. An explanation of each part or field is given for each example.

27 | P a g e

1. Basic Header Block

The basic header is given in block 1 of a SWIFT message. It is the only compulsory header and appears on all user-to-user messages, system messages, system commands and acknowledgments. The basic header provides the fundamental referencing of a particular message within an application session of a particular LT. The basic header has the same format for both input and output messages. However, the information contained in the basic header is relative to the sender when the message is input but relative to the receiver when the same message is output. The following is an example of a basic input header, as it might appear at the beginning of a user-to-user message input within the FIN application. {1:F01BANKBEBBAXXX2222123456} but for clarity the components are shown separately: {1: F 01 1: BANKBEBBAXXX Block Identifier Application Identifier 2222 123456} Block identifier for a basic header block is always "1:". The application identifier identifies the application within which the message is being sent or received. The available options are: F=FIN (all user-to-user and FIN system messages)(used for ISITC) A=GPA (most GPA system messages and commands) L=GPA (certain GPA session control commands, e.g., LOGIN, LOGIN acknowledgments, ABORT) The Application Protocol Data Unit (APDU) Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, whether the message which follows is one of the following: User-to-user message System message Service message, e.g., a session control command (such as SELECT) Logical acknowledgment (such as ACK/SAK/UAK). This 12-character SWIFT address, given in the basic header block, is the address of the sending LT (for input messages) or of the

01

Application Protocol Data Unit Identifier

BANKBEBBAXXX LT Address

28 | P a g e

receiving the LT (for output messages), and includes the branch code. In the basic header, the Logical Terminal Code within the LT address is specific to the LT that has established the session in which the message is being transmitted (i.e. the sending LT for input messages or the receiving LT for output messages). A SWIFT address or BIC can be requested for any financial institution, whether or not you are a SWIFT member participant, by contacting SWIFT administration. The SWIFT address which will be assigned by SWIFT administration is comprised of the following: Bank Code 4 Characters Country Code 2 Characters Location Code 2 Characters Logical Terminal Code 1 Character Branch Code 3 Characters 2222 Session Number The session number identifies the session in which the message was transmitted. Within the basic header, the session number (four digits) is the user's current GPA or FIN session number. ("0000" - ISITC) The sequence number always consists of six digits. It is the ISN of the sender's current input session or the OSN of the receiver's current output session. ("000001" - ISITC)

123456

Sequence Number (ISN or OSN)

29 | P a g e

2. Application Header Block

The application header of a SWIFT message provides information about the message itself. The application header is given in block 2 of a SWIFT message. If differs according to whether the message is a GPA or a FIN message and whether the application header is attached to an input message or to a output message.

2:

Block Identifier

The block identifier for an application header block is always "2:". The input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message. The message type consists of three digits which define the MT number of the message being input. The example used above is for a Customer Transfer (MT 100).

Input/Output Identifier

100

Message Type

BANKDEFFXXXX Recipient's Address This address is the 12-character SWIFT address of the recipient of the message, but with a Logical Terminal Code of "X". If defines the destination to which the message should be sent. The system will replace the "X" with a specific Logical Terminal Code on delivery of the message. Institutions which are not part of the SWIFT network will be assigned a Branch Code of BIC. The branch code is mandatory and will be validated. The default of "XXX" may be used, as in the example above. U Message Priority This character (used within FIN application headers only) defines the priority by which a message shall be delivered. The possible values are: S = System U = Urgent N = Normal Message priority "S" must be used for user-tosystem messages: for user-to-user messages either "U" or "N" may be used Delivery monitoring options apply only to FIN user-to-user messages. The chosen option is expressed as a single

Delivery Monitoring

30 | P a g e

digit: 1 = Non-Delivery Warning 2 = Delivery Notification 3 = Non-Delivery Warning and Delivery Notification. If the message has priority 'U' then the user must request delivery monitoring option '1' or '3'. If the message has priority 'N', the user can request delivery monitoring option '2', or, by leaving the option blank, no delivery monitoring. 003 Obsolescence Period The obsolescence period defines the period of time after which a Delayed Message (DLM) trailer is added to a FIN user-to-user message when the message is delivered. For urgent priority messages, it is also the period of time after which, if the message remains undelivered, a Non-Delivery Warning is generated. The values for the obsolescence period are: 003 (15 minutes) for 'U' priority, and 020 (100 minutes) for 'N' priority.

Application Header Input: For input messages, the application header describes the type of message, whom it is for and how it should be sent. The following is an example of an input application header, as it might appear at the top of a user-to-user message, input within the FIN application:

31 | P a g e

{2: I

100 BANKDEFFXXXX

003}

Application Header-Output: For output messages, the output application header defines the type of message, who sent it (and when), and when it was delivered. GPA output application headers are similar to their FIN equivalents except that, for GPA, the message priority is not included. The following is an example of an output application header, as it might appear at the top of a user-to-user message output within the FIN Application: {2: 0 100 1200 910103BANKBEBBAXXX2222123456 910103 1201 N} 2: Block Identifier The block identifier for an application header block is always "2:". The input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message. The message type consists of three digits which define the MT number of the message being output. The example used above is for a Customer Transfer (MT 100). The input time (HHMM) is expressed in the sender's local time. If the message is a system message, the input time is the time the message was generated by the system, expressed in Greenwich Mean Time. (GMT) Every input message is assigned a unique Message Input Reference (MIR). This is a string of 28 characters which consists of the date the message was input (local to the sender), the sender's LT identifier and branch code, the sender's session number and sender's ISN. If the output message is system-generated, the system MIR will show a Pseudo-Logical Terminal (PLT) address, e.g., SWFTXXXXXXXX, identifying as the sender the particular suite of programs which generated the message within the system. The date given in the system MIR is the generation date in GMT.

Input/Output Identifier

100

Message Type

1200

Input Time

910103BANK Message Input BEBBAXXX Reference (MIR) 2222123456

32 | P a g e

910103

Output Date

The output date (YYMMDD) is the date local to the receiver. The output time (HHMM) is expressed in the receiver's local time. The message priority, for FIN messages only, is repeated in the FIN output application header. ("N" - ISITC default, no priority)

1201

Output Time

Message Priority

3. User Header Block Required for ISITC version control

ISITC :International Securities Association for Institutional Trade Communications The user header is an optional header available within the FIN application and is available for user-to-user messages only. This header block is mandatory as it is utilized to identify the version of the message standard applicable for processing and validating the particular message to which the header applies. It also allows a user to provide his form of reference for a particular message. A user header can only be assigned by the sender of a message and, if assigned, will always appear on the output message copy and on related system messages and acknowledgments. The user reference part of the user header may be used as one of the selection criteria in a SWIFT retrieval. The user header appears in block 3 of a SWIFT message. If used, at least one of the two possible sub-blocks must be defined. The following example shows the format of a user header: {3: {113:9601} 3: {108:abcdefgh12345678}} The block identifier for a user header block always has the value "3:".

Block Identifier

33 | P a g e

{113:9601}

ISITC Version Identifier

A version/release represents a snapshot in time of the status of the development and maintenance efforts of ISITC as of a specified date. Up to two releases per year may be approved for implementation and are identified by version control numbers. Tag 113 is used by ISITC to identify the version of the standard that applies to the message. Version identifiers are four digits long and identify the year the version was created (i.e. 1996 would be 96) as well as the version number (01 or 02) as there are a maximum of two versions of the standard per year. Tag 108 defines a free-format field in which users may specify their own reference of up to 16 characters of all the permitted character set.

{108:abcdefgh Message User 12345678} Reference (MUR)

If an MUR is not specified, the TRN (from field 20: in the text of a user-to-user message) is automatically copied into this field, but only on the system's storage media, and may be used for retrieval of the messages if the alphabetic characters contained in the TRN were in uppercase. The TRN will never be output as an MUR.

34 | P a g e

4. Text Block
The text of a SWIFT message (where applicable) is given in block 4 of a SWIFT message. An example of the text block in a typical FIN user-to-user message follows: {4: : 20: PAYREF- TB54302 : 32A:910103BEF1000000, : 50: CUSTOMER NAME AND ADDRESS : 59:/123-456-789 BENEFICIARY NAME AND ADDRESS -} In the text of user-to-user messages, CrLf is a mandatory delimiter. In those cases where character type "a", "a", "a", or "a" is used in the field format description, the alphabetic characters must be uppercase. The text part of a GPA message or a FIN system message differs only in that each text field is seen as a sub-block of block 4, with block delimiters at the beginning and end of each subblock. For example, the text block of a Non-Delivery Warning (MT 010) may appear as: {4 :{ 106:910103BANKBEBBAXXX1221654321} {108: ABCDEF} {431:07} {102:BANKUS33XXXX} {104: U}} (Note that the text block will be transmitted as a continuous string of characters without CrLf or blank characters inserted. In the above example, the sub-blocks have been shown on separate lines for purpose of clarity.) All Swift Text Messages have a maximum of 35 characters per line. In the event that the necessary information spans more than one line, the current line must end with a CrLf, and the subsequent line must begin with the "//" continuation character. e.g. :35B:678901234567890123456789012345CrLf //1234567890...

35 | P a g e

5. Trailers Block
General Trailers are added to a message for control purposes: or to indicate that special circumstances apply to the handling of the message: or to convey special/additional information. They may be added by the user or by the system. Trailers always appear in block 5 of a SWIFT message. Each trailer appears as a separate subblock and is bounded by block delimiters. Each trailer begins with a three letter code, followed by a colon, followed by the trailer information itself. For example, block 5 of a user-to-user message, sent with an authentication trailer and checksum trailer, may appear as: {5 :{ MAC: 41720873} {CHK: 123456789ABC}}

SWIFT Character Set

CBTs communicating with SWIFT use EBCDIC code. The character set is as follows: a bcd ef g hi jk l mn op q r s tu v wx yz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0 123456789 / - ? : ( ). , ' + {} Cr Lf Space

All alphabetic characters in all headers, and in text of user-to-system messages, must be in upper case. The system does not recognize lower case letters as equivalent to upper case. Although part of the character set, the curly brackets are only permitted as delimiters and cannot be used within the text of user-to-user message. SWIFT Messages Type of Messages MT1XX MT2XX MT3XX MT4XX MT5XX MT6XX MT7XX MT8XX MT9XX MT0XX Customer transfers and cheques Financial institution transfers Treasury markets Collections & cash letters Securities Precious metals and syndications Documentary credits/guarantees Travellers cheques Cash management & customer status System Messages

36 | P a g e

Category 1 Customer Payments & Cheques Purpose Requests to debit a customers account held at another institution 102 / 102+ Multiple Customer Credit Conveys multiple payment instructions between Transfer financial institutions 103 / 103+ Single Customer Credit Instructs a funds transfer / 103 Transfer REMIT 104 Direct Debit and Request Conveys direct debit instructions and requests for for Debit Transfer direct debits between financial institutions Message 105 EDIFACT Envelope An envelope which conveys a 2k EDIFACT message 106 EDIFACT Envelope An envelope which conveys a 10k EDIFACT message 107 General Direct Message To order the debit of a debtor's account and to collect payment from this account 110 Advice of Cheque(s) Advises or confirms the issuance of a cheque to the drawee bank 111 Request for Stop Requests the drawee bank to stop payment of a Payment of a Cheque cheque 112 Status of a Request for Indicates action(s) taken in attempting to stop Stop Payment of a payment of a cheque Cheque 121 Multiple Interbank Funds Contains an EDIFACT FINPAY message Transfer Category 2 Financial Institution Transfers MT 200 MT Name Financial Institution Transfer for its Own Account Multiple Financial Institution Transfer for its Own Account General Financial Institution Transfer Multiple General Financial Institution Transfer Financial Markets Direct Debit Message Financial Institution Transfer Execution Purpose Requests the movement of the Senders funds to its account at another financial institution Multiple of the MT 200 MT 101 MT Name Request for Transfer

201

202 203

Requests the movement of funds between financial institutions Multiple of the MT 202

204 205

Claims funds from SWIFT member banks Further transmits a transfer request domestically

37 | P a g e

206

Cheque Truncation Message Request for Financial Institution Transfer Notice to Receive Advice of Non-Payment of Cheques

207

210 256

Conveys information on one or more truncated cheques in order to debit or obtain credit under usual reserve Requests to debit an ordering financial institutions account held at the receiving financial institution or the account servicing financial institution Notifies the Receiver that it will receive funds for the Senders account Informs the Sender of one or more previously sent MT 206s of non-payment of one or more truncated cheques. It may also be used to specify dishonoured items that result in reversing a previous payment settlement

Category 3 Treasury Markets Foreign Exchange, Money Markets & Derivatives MT 300 303 304 305 306 307 308 MT Name Foreign Exchange Confirmation Forex/Currency Option Allocation Instruction Advice/Instruction of a Third Party Deal Foreign Currency Option Confirmation Financial Markets Direct Debit Message Advice/Instruction of a Third Party FX Deal Instruction for a Gross/Net Settlement of Third Party FX Deals Fixed Loan/Deposit Confirmation Instruction to Settle a Third Party Loan/Deposit Call/Notice Loan/Deposit Confirmation Forward Rate Agreement Confirmation Forward Rate Agreement Settlement Confirmation Purpose Confirms information agreed to in the buying/selling of two currencies Instructs the allocation of a block trade (forex or currency option) Advises of or instructs settlement of a third party foreign exchange deal Confirms information agreed to in the buying and selling of vanilla options on currencies Confirms information agreed to in the buying and selling of exotic options on currencies Advises of or instructs settlement of a third party foreign exchange deal Informs which deals done on behalf of a third party area to be settled gross and which ones netted Confirms the terms of a contract relative to a fixed loan/deposit transaction Advises the trade details and instructs the settlement of a fixed term loan/deposit done with a third party financial institution Confirms the terms of a contract relative to a call/notice loan/deposit transaction Confirms the details of a forward rate agreement Confirms the settlement details of a forward rate agreement

320 321

330

340 341

38 | P a g e

350 360

Advice of Loan/Deposit Advises of a loan/deposit interest payment Interest Payment Single Currency Interest Rate Confirms the details of a single currency interest Derivative Confirmation rate derivative swap, cap, collar or floor

361 362

Cross Currency Interest Rate Swap Confirmation Interest Rate Reset/Advice of Payment

364

365

380 381

Confirms the details of a cross currency interest rate swap transaction Confirms or advises the reset rates of the floating interest rate(s) in a single or cross-currency interest rate derivative transaction and/or the payment of interest at the end of an interest period Single Currency Interest Confirms the details of the partial or full termination or Rate Derivative recouponing of a single currency interest rate swap, Termination/Recouponing cap, collar or floor Confirmation Cross Currency Interest Confirms the details of the partial or full termination or Rate Swap recouponing of a cross, currency interest rate swap Termination/Recouponing Confirmation Foreign Exchange Order Orders to purchase or sell a specific amount of a certain currency Foreign Exchange Order Confirms the execution of a FX Order Previously sent Confirmation

Category 4 Collection & Cash Letters MT 400 405 MT Name Advice of Payment Clean Collection Purpose Advises of a payment under a collection or part thereof. It also handles the settlement of proceeds Conveys instructions to obtain payment or acceptance against specified conditions. The message is used for clean collections only and supports financial documents such as accepted and non-accepted bills of exchange and promissory notes Acknowledges receipt of a collection. It also specifies if the collecting bank does not intend to act in accordance with the collection instruction Informs the remitting bank of the acceptance of one or more drafts under one collection instruction Advises of the non-payment or non-acceptance under a

410

Acknowledgement

412 416

Advice of Acceptance Advice of NonPayment/Non-Acceptance

39 | P a g e

420 422

Tracer Advice of Fate and Request for Instructions Amendment of Instructions Cash Letter Credit Advice

430 450

Enquires about documents dent for collection Advises the remitting bank of the fate of one or more collection documents; usually accompanied by one or more questions or requests Amends collection instructions Confirms that the face amount of cash letter(s) received has been credited under usual reserve (subject to final payment) Advises the account owner of adjustments made to its account (related to a previous credit for a cash letter) Advises the account owner that financial document(s) included in the cash letter have been dishonoured for reasons specified in the advice

455 456

Cash Letter Credit Adjustment Advice Advice of Dishonour

Category 5 Securities Markets MT 500 MT Name Instruction to Register Purpose Instructs the registration, deregistration or reregistration of a financial instrument at the registration provider Confirmation of Confirms the registration, deregistration or reRegistration or Modification registration of a beneficial owner or shareholder with the registration provider Order to Buy or Sell Instructs the purchase or sale of a given quantity of a specified financial instrument under specified conditions Collateral Claim Requests new or additional collateral, or the return or recall of collateral Collateral Proposal Proposes new or additional collateral Collateral Substitution Proposes or requests the substitution of collateral held Collateral and Exposure Provides the details of the valuation of both the Statement collateral and the exposure Collateral Status and Advises the status of a collateral claim, a collateral Processing Advice proposal, or a proposal/request for collateral substitution Intra-Position Advice Reports on the movement of securities within the holding Trade Status Message Provides information on the status of a previously executed trade Registration Status and Advises the status of a registration instruction or Processing Advice modification

501

502

503 504 505 506 507

508 509 510

40 | P a g e

513

Client Advice of Execution

514 515

516

517 518 519 524 526

527 528

529

530 535

536 537 538

Provides brief and early information about a securities deal, e.g., a block trade that is to be allocated before final confirmation Trade Allocation Instruction Instructs the allocation of a block trade Client Confirmation of Provides a detailed accounting of financial Purchase or Sale instruments purchased or sold by the Sender on behalf or the Receiver or its client. It may also convey the payment details of the purchase or sale. It may also be sent by, or via an ETC service provider Securities Loan Confirms the details of a securities loan, including Confirmation collateral arrangements. It may also confirm the details of a partial recall or return of securities previously out on loan Trade Confirmation Positively affirms the details of a previously received Affirmation confirmation/contract note Market-Side Securities Confirms the details of a trade and where Trade Confirmation necessary, its settlement to a trading counterparty Modification of Client Instructs the modification of client details at the Details registration provider Intra-Position Instruction Instructs the movement of securities within the holding General Securities Requests the borrowing of securities or notifies the Lending/Borrowing return or recall of securities previously out on loan. Message It may also be used to list securities avaliable for lending Tri-party Collateral Performs a specific action on a collateral Instruction management transaction ETC Client-Side Settlement Sent by an ETC service provider, it communicates Instruction early settlement information to a custodian or clearing agent about a client-side trade ETC Market-Side Settlement Sent by ETC service provider, it communicates early Instruction settlement information to a custodian or clearing agent about a market-side trade Transaction Processing Requests the modification of a processing indicator Command or other non-matching information. Statement of Holdings Reports at a specified time, the quantity and identification of securities and other holdings which the account servicer holds for the account owner Statement of Transactions Provides details of increases and decreases of holdings which occurred during a specified period Statement of Pending Provides details of pending increases and decreases Transaction of holdings at a specified time Statement of Intra-Position Provides details of increases and decreases in Advices securities within the holding during a specified period

41 | P a g e

540

Receive Free

541

Receive Against Payment

542

Deliver Free

543

Deliver Against Payment

544

Receive Free Confirmation

545

Receive Against Payment Confirmation Deliver Free Confirmation

546

547

Deliver Against Payment Confirmation Settlement Status and Processing Advice Request for Settlement/Status Advice Triparty Collateral Status and Processing Advice Paying Agents Claim Corporate Action Notification

548 549 558

Instructs a receipt of financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction Instructs a receipt of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction Instructs a delivery of financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction Instructs a delivery of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction Confirms a receipt of financial instruments free of payment. It may also be used to cancel or reverse a confirmation Confirms a receipt of financial instruments against payment. It may also be used to cancel or reverse a confirmation Confirms a delivery of financial instruments free of payment. It may also be used to cancel or reverse a confirmation Confirms a delivery of financial instruments against payment. It may also be used to cancel or reverse a confirmation Advises the status of a settlement instruction or replies to a cancellation request Requests a statement or a status message Provides validation results and status advice re collateral instructions and proposed collateral movements Claims reimbursement of income or redemption proceeds, or a combination of both Provides an account owner with details of a corporate action event and the choices available to the account owner. It also provides the account owner with details on the impact a corporate action event will have on a safekeeping or cash account, eg, entitlement calculation Instructs the custodian on the investment decision made by an account owner relative to a corporate action event Confirms to the account owner that securities and/or cash have been credited/debited to an account as a result of a corporate action event

559 564

565

Corporate Action Instruction Corporate Action Confirmation

566

42 | P a g e

567

568 569 574

574 575 576

577 578

579 581

582

584 586 587

588

589

Corporate Action Status and Indicates the status, or a change in status, of a Processing Advice corporate action-related transaction previously instructed by, or executed on behalf of, the account owner Corporate Action Narrative Provides complex instructions or narrative details relating to a corporate action event Triparty Collateral and Provides the details of the valuation of both the Exposure Statement collateral and the exposure IRS 1441 NRA-IRS Beneficial Provides owner or pooled income information for a Owners List period of time arranged between the intermediary and the withholding agent IRS 1441 NRA-Form W8Certifies the foreign status of a beneficial owner for BEN United States tax withholding Report of Combined Activity Reports on all securities and cash activity for a given combination of safekeeping and cash accounts Statement of Open Orders Provides details of orders to buy or to sell financial instruments, as at a specified date, which have been accepted by the Sender, but which have not yet been executed Statement of Numbers Provides certificates numbers of securities Settlement Allegement Advises the account owner that a counterparty has alleged a settlement instruction on the account owners account Certificate Numbers Replaces or supplements the certificate numbers field in a primary message, eg, MT 577 Collateral Adjustment Claims or notifies a change in the amount of Message collateral held against securities out on loan or for other reasons Reimbursements Claim or Claims reimbursement of funds paid on behalf of Advice the Receiver or of securities received which are due to the Sender. It may also advise that funds and/or securities have or will be remitted by the Sender in favour of the Receiver Statement of ETC Pending Provides statuses and details of executed trades Trades which are not yet matched nor affirmed Statement of Settlement Provides details of pending settlement allegements Allegements Depositary Receipt Instructs the issuance or release of a depositary Instruction receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another Depositary Receipt Confirms the issuance or release of a depositary Confirmation receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another Depositary Receipt Status Advises the status, or change in status, of a and Processing Advice depositary receipt

43 | P a g e

Category 6 Treasury Markets Precious Metals MT 600 601 604 MT Name Precious Metal Trade Confirmation Precious Metal Option Confirmation Precious Metal Transfer/Delivery Order Purpose Confirms the details of a precious metal trade and its settlement Confirms the details of a precious metal option contract Instructs the Receiver to transfer by book-entry, or physically deliver, a specified type and quantity of precious metal to a specified party Precious Metal Notice to Notifies the Receiver of an impending book-entry Receive transfer or physical delivery of a specified type and quantity of precious metal Precious Metal Debit Advice Advises the Receiver of a debit entry to a specified metal account Precious Metal Credit Advises the Receiver of a credit entry to a specified Advice metal account Statement of a Metal Provides the details of all bookings to a metal Account account Statement of Metal Identifies all outstanding metal contracts, as at a Contracts specified date for which confirmations have been exchanged Notice of Provides notice of the Borrower(s) request for Drawdown/Renewal drawdown(s)/renewal(s) on a given date Advice of Rate and Amount Specifies the interest rate and, if applicable, the Fixing exchange rate, for the next interest period Notice of Fee Due Specifies flat and variable fees, related to one Facility, due to the Receiver Payment of Principal and/or Advises of payments and/or prepayments of of Interest principal and/or of interest with the same value date, but not related to any subsequent drawing or renewal General Syndicated Facility Provides for communications related to syndicated Message facilities for which no specific message has been defined

605

606 607 608 609

643 644 645 646

649

Category 7 Documentary Credits & Guarantees MT 700 701 MT Name Issue of a Documentary Credit Issue of a Documentary Credit Purpose Indicates the terms and conditions of a documentary credit Continuation of an MT 700 for fields 45a, 46a and 47a

44 | P a g e

705 707 710 711 720 721 730

Pre-Advice of a Documentary Credit Amendment to a Documentary Credit Advice of a Third Banks Documentary Credit Advice of a Third Banks Documentary Credit Transfer of a Documentary Credit Transfer of a Documentary Credit Acknowledgement

Provides brief advice of a documentary credit for which full details will follow Informs the Receiver of amendments to the terms and conditions of a documentary credit Advises the Receiver of the terms and conditions of a documentary credit Continuation of an MT 710 for files 45a, 46a and 47a Advises the transfer of a documentary credit, or part thereof, to the bank advising the second beneficiary Continuation of a MT 720 for files 45a, 46a and 47a

732 734

740

742

747

750

752

754

Acknowledges the receipt of a documentary credit message and may indicate that the message has been forwarded according to instructions. It may also be used to account for bank charges or to advise of acceptance or rejection of an amendment of a documentary credit Advice of Discharge Advises that documents received with discrepancies have been taken up Advice of Refusal Advises the refusal of documents that are not in accordance with the terms and conditions of a documentary credit Authorisation to Requests the Receiver to honour claims for Reimburse reimbursement of payment(s) or negotiation(s) under a documentary credit Re-imbursement Claim Provides a reimbursement claim to the bank authorised to reimburse the Sender or its branch for its payments/negotiations Amendment to an Informs the reimbursing bank of amendments to the Authorisation to terms and conditions of a documentary credit, relative Reimburse to the authorisation to reimburse Advice of Discrepancy Advises of discrepancies and requests authorisation to honour documents presented that are not in accordance with the terms and conditions of the documentary credit Authorisation to Pay, Advises a bank which has requested authorisation to Accept or Negotiate pay, accept, negotiate or incur a deferred payment undertaking that the presentation of the documents may be honoured, notwithstanding the discrepancies, provided they are otherwise in order Advice of Advises that documents have been presented in Payment/Acceptance/Ne accordance with the terms of a documentary credit gotiations and are being forwarded as instructed.

45 | P a g e

756

Advice of Reimbursement or Payment Guarantee/Standby LC Guarantee/ Standby LC Amendment

760 767

768

769

Acknowledgement of a Guarantee/ Standby LC Message Advice of Reduction or Release

Advises of the reimbursement or payment for a drawing under a documentary credit in which no specific reimbursement instructions or payment provisions were given Issues or requests the issue of a guarantee or Standby LC Amends a guarantee or Standby LC which has been previously issued or requests the amendment of a guarantee which the Sender has previously requested to be issued Acknowledges the receipt of a guarantee/ Standby LC message and may indicate that action has been taken according to instructions Advises that a bank has been released of its liability for a specified amount under its guarantee

Category 8 Travellers Cheques MT 800 801 MT Name T/C Sales and Settlement Advice [Single] T/C Multiple Sales Advice Purpose Provides the sale and settlement details for the sale of travellers cheques by a single selling agent Provides the details (excluding the settlement details) of the sales of travellers cheques in cases where the data is lengthy or includes data from several selling agents Provides the settlement details of multiple sales of travellers cheques Requests the issuer to honour a claim for a refund for lost or stolen travellers cheques. It may also request authorisation to refund Authorises, denies or defers a full or partial refund for cheques which have been lost or stolen Confirms and accounts for an authorised refund to a claimant. It may also indicate the amount to be reimbursed to the refund agent Requests replenishment of the selling agents travellers cheque stock Provides general information regarding a shipment of travellers cheques Acknowledges the receipt of a shipment of travellers cheques from the issuer Advises the issuer of a transfer of specified travellers cheque stock from one selling agent to another

802 810

T/C Settlement Advice T/C Refund Request

812

T/C Refund Authorisation

813

T/C Refund Confirmation

820 821 822 823

Request for T/C Stock T/C Inventory Addition Trust Receipt Acknowledgement T/C Inventory Transfer

46 | P a g e

824

T/C Inventory Destruction/Cancellation Notice

Notifies the issuer of the destruction/cancellation of travellers cheque inventory held by the selling agent. It may also request a selling agent to destroy/cancel travellers cheque inventory

Category 9 Cash Management & Customer Status MT 900 910 920 935 MT Name Confirmation of Debit Confirmation of Credit Request Message Rate Change Advice 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 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 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

940

Customer Statement Message Balance Report

941

942

Interim Transaction Report

950 960 961 962 963 964 965 966

Statement Message Request for Service Initiation Message Initiation Response Message Key Service Message Key Acknowledgement Message Error Message Error in Key Service Message Discontinue Service Message

47 | P a g e

967

Discontinuation Acknowledgement Message Netting Statement Netting Balance Report Netting Interim Statement Netting Request Message Status Enquiry Status Report

970 971 972 973 985 986

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 Purpose Advises an account owner of charges, interest or other adjustments to its account Requests payment of charges, interest or other expenses 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 n95 Queries or MT n92 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

Category n Common Group Messages MT n90 MT Name Advice of Charges, Interest and Other Adjustments Request for Payment of Charges, Interest and Other Expenses Request for Cancellation

n91 n92

n95

Queries

n96

Answers

n98

Proprietary Message

n99

Free Format Message

48 | P a g e

SWIFT MX The SWIFT Standards MX messages are listed according to the business area in which they have been defined. Account Management MX acmt.001.001.0 2 MX Name AccountOpeningInstructionV 02 Purpose The AccountOpeningInstructionV02 message instructs the opening of an account or the opening of an account and establishing an investment plan. AccountDetailsConfirmationV The AccountDetailsConfirmationV02 message 02 confirms the opening of an account, modification of an account or the provision of information requested in a previously send. GetAccountDetails message. AccountModificationInstructi The AccountModificationInstructionV02 onV02 message instructs the modification of an existing account. GetAccountDetailsV02 The GetAccountDetailsV02 message requests some or all details of a specific account. RequestForAccountManageme The ntStatusReportV02 RequestForAccountManagementStatusReport V02 message requests the status of an Account opening instruction AccountManagementStatusR The AccountManagementStatusReportV02 eportV02 message provides the processing status of a previously received

acmt.002.001.0 2

acmt.003.001.0 2 acmt.004.001.0 2 acmt.005.001.0 2

acmt.006.001.0 2

Administration MX MX Name admi.001.001.01 ReportV01 Purpose The ReportV01 message is used for general application level data reporting. A message may contain either a full report or one single tranche (part) of a report split in multi-tranches (multi-parts). The message contains a mechanism to support the correct reassembling of the reporting data by an application. The MessageRejectV01 message is sent by a central system to notify the rejection of a previously received message. It provides specific information about the rejection reason.

admi.002.001.01 MessageRejectV01

49 | P a g e

admi.004.001.01 SystemEventNotificationV01 The SystemEventNotificationV01 message is sent by a central system to notify the occurrence of an event in a central system. Cash Management MX Identifier camt.003.001.03 MX Name GetAccountV03 Purpose The GetAccountV03 message is sent by a member to the transaction administrator. It requests information on the details of one or more accounts held at the transaction administrator, including information on the balances. The ReturnAccountV03 message is sent by a member to the transaction administrator. It provides information on the details of one or more accounts held at the transaction administrator, including information on the balances. The ReturnAccount message can be sent as a response to a related GetAccount message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred. The GetTransactionV03 message is sent by a member to the transaction administrator. It requests information about payment instructions held at the transaction administrator. The ReturnTransactionV03 message is sent by the transaction administrator to a member of the system. It provides information on transactions and booked entries held at the transaction administrator. The ReturnTransactionV03 message can be sent as a response to a related GetTransaction message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred.

camt.004.001.03

ReturnAccountV03

camt.005.001.03

GetTransactionV03

camt.006.001.02

ReturnTransactionV03

camt.007.001.02
50 | P a g e

ModifyTransactionV03 The ModifyTransactionV03 message is sent by

a member to the transaction administrator. It requests one modification in one payment instruction held at the transaction administrator and sent by the member, debiting or crediting its account at the transaction administrator. camt.007.002.02 RequestToModifyPay mentV02 The RequestToModifyPaymentV02 message is sent by a case creator/case assigner to a case assignee. It requests the modification of characteristics of an original payment instruction. The CancelTransactionV03 message is sent by a member to the transaction administrator. It requests the cancellation of one payment instruction held at the transaction administrator and sent by the member.

camt.008.001.03

CancelTransactionV03

camt.008.002.02

RequestToCancelPaym The RequestToCancelPaymentV02 message is ent02 sent by a case creator/case assigner to a case assignee. It requests the cancellation of an original payment instruction. GetLimitV03 The GetLimitV03 message is sent by a member to the transaction administrator. It requests information on the details of one or more limits set by the member (or on behalf of the member) and managed by the transaction administrator. The ReturnLimitV03 message is sent by the transaction administrator to a member of the system. It provides information on the details of one or more limits set by the member (or on behalf of the member) and managed by the transaction administrator. The ReturnLimit message can be sent as a response to a related GetLimit message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred. The ModifyLimitV03 message is sent by a member to the transaction administrator. It requests modifications in the details of one particular limit set by the member and

camt.009.001.03

camt.010.001.03

ReturnLimitV03

camt.011.001.03

ModifyLimitV03

51 | P a g e

managed by the transaction administrator. Each ModifyLimit message can alter only one type of limit (current or default). camt.012.001.03 DeleteLimitV03 The DeleteLimitV03 message is sent by a member to the transaction administrator. It requests the deletion of one particular limit set by the member and managed by the transaction administrator. Each DeleteLimit message can only delete one type of current limit (risk or liquidity management limit). The GetMemberV01 message is sent by a member to the transaction administrator. It requests information on static data maintained by the transaction administrator and related to the participants in the system and their membership status vis--vis this system. The ReturnMemberV01 message is sent by the transaction administrator to a member of the system. It provides information on static data maintained by the transaction administrator and related to the participants in the system and their membership status vis--vis this system. The ReturnMember message can be sent as a response to a related GetMember message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred. camt.015.001.01 ModifyMemberV01 The ModifyMemberV01 message is sent by a member to the transaction administrator. It requests modifications to the static data related to the profile of a member that the transaction administrator maintains. The GetCurrencyExchangeRateV01 message is sent by a member to the transaction administrator. It requests information on static data maintained by the transaction administrator and related to currency exchange details as maintained for the system operations by the transaction administrator.

camt.013.001.01

GetMemberV01

camt.014.001.01

ReturnMemberV01

camt.016.001.01

GetCurrencyExchange RateV01

52 | P a g e

camt.017.001.01

ReturnCurrencyExcha ngeRateV01

The ReturnCurrencyExchangeRateV01 message is sent by the transaction administrator to a member of the system. It provides information on static data and related to currency exchange details as maintained for system operations by the transaction administrator. The ReturnCurrencyExchangeRate message can be sent as a response to a related GetCurrencyExchangeRate message (pull mode) or initiated by the account servicer (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred.

camt.018.001.01

GetBusinessDayInform The GetBusinessDayInformationV01 message ationV01 is sent by a member to the transaction administrator. It requests information on different types of administrative data linked to the system. ReturnBusinessDayInf ormationV02 The ReturnBusinessDayInformationV02 message is sent by the transaction administrator to a member of the system. It provides information on different types of administrative data linked to the system. The ReturnBusinessDayInformation message can be sent as a response to a related GetBusinessDayInformation message (pull mode), or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred.

camt.019.001.02

camt.020.001.01

GetGeneralBusinessInf The GetGeneralBusinessInformationV01 ormationV01 message is sent by a member to the transaction administrator. It requests information on a broadcast-type message previously sent by the transaction administrator to all or some of the members, giving information related to the processing business. ReturnGeneralBusines sInformationV01 The ReturnGeneralBusinessInformationV01 message is sent by the transaction administrator to a member of the system. It

camt.021.001.01

53 | P a g e

provides some or all of the members with information related to the processing of the system. The ReturnGeneralBusinessInformation message can be sent as a response to a related GetGeneralBusinessInformation message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred. camt.023.001.02 BackupPaymentV02 The BackupPaymentV02 message is sent by a member to the transaction administrator. It requests a liquidity transfer from the member to another participant in the system when the user is in recovery mode. The ModifyStandingOrderV02 message is sent by a member to the transaction administrator. It requests a change in the features of a permanent order for the transfer of funds between two accounts belonging to the same member and being held at the transaction administrator. The ReceiptV02 message is sent by the transaction administrator to a member of the system. It acknowledges the receipt of a message previously sent. The Receipt message is an application receipt acknowledgement and conveys information about the processing of the original message. The UnableToApplyV02 message is sent by a case creator/case assigner to a case assignee. It initiates an investigation of a payment instruction that cannot be executed or reconciled. The ClaimNonReceiptV02 message is sent by a case creator/case assigner to a case assignee. It initiates an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction). The AdditionalPaymentInformationV02

camt.024.001.02

ModifyStandingOrder V02

camt.025.001.01

ReceiptV01

camt.026.001.02

UnableToApplyV02

camt.027.001.02

ClaimNonReceiptV02

camt.028.001.02
54 | P a g e

AdditionalPaymentInf

ormationV02

message is sent by an account servicing institution to an account owner. It provides additional or corrected information on a payment instruction or statement entry, in order to allow reconciliation.

camt.029.001.02

ResolutionOfInvestigat The ResolutionOfInvestigationV02 message is ionV02 sent by a case assignee to a case creator/case assigner. It informs of the resolution of a case, and optionally provides details about the corrective action undertaken by the case assignee. NotificationOfCaseAssi The NotificationOfCaseAssignmenV02 gnmentV02 message is sent by a case assignee to a case creator/case assigner. It informs the case assigner of further action that is undertaken by the case assignee to process the case, eg, the assignment of the case to a next case assignee. RejectCaseAssignment V02 CancelCaseAssignmen t The RejectCaseAssignmentV02 message is sent by a case assignee to a case creator/case assigner. It is used to reject a case. The CancelCaseAssignment message is sent by a case creator/case assigner to a case assignee. It requests the cancellation of a case.

camt.030.001.02

camt.031.001.02

camt.032.001.01

camt.033.001.02

RequestForDuplicateIn The RequestForDuplicateInstructionV02 structionV02 message is sent by the case assignee to the case creator/case assigner. It requests a copy of the original payment instruction considered in the case. DuplicateInstructionV 02 The DuplicateInstructionV02 message is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. It allows the exchange of duplicate payment instructions.

camt.034.001.02

camt.035.001.01

ProprietaryFormatInve The ProprietaryFormatInvestigation message stigation is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. It is used as an envelope for a non standard message. It provides means to

55 | P a g e

manage an exception or investigation which falls outside the scope or capability of any other formatted message. It also allows financial institutions to use message types which are awaiting live implementation in the Exceptions & Investigations solution camt.036.001.01 DebitAuthorisationRes ponse The DebitAuthorisationResponse message is sent by an account owner to its account servicing institution. It is used to approve or reject a debit authorisation request. The DebitAuthorisationRequestV02 message is sent by an account servicing institution to an account owner. It requests authorisation to debit an account.

camt.037.001.02

DebitAuthorisationRe questV02

camt.038.001.01

CaseStatusReportRequ The CaseStatusReportRequest message is sent est by a case creator/case assigner to a case assignee. It requests the status of a case. CaseStatusReportV02 The CaseStatusReportV02 message is sent by a case assignee to a case creator/case assigner. It reports on the status of a case. The FundEstimatedCashForecastReportV03 message reports the estimated cash incomings and outgoings of one or more investment funds on one or more trade dates.

camt.039.001.02

camt.040.001.03

FundEstimatedCashFo recastReportV03

camt.041.001.03

FundConfirmedCashFo The FundConfirmedCashForecastReportV03 recastReportV03 message confirms the cash incomings and outgoings of one or more investment funds on one or more trade dates. FundDetailedEstimate TheFundDetailedEstimatedCashForecastRepor dCashForecastReportV tV03 message reports the estimated cash 03 incomings and outgoings, sorted by criteria defined by the user of one or more investment funds on one or more trade dates. FundDetailedConfirme The dCashForecastReportV FundDetailedConfirmedCashForecastReportV0 03 3 message reports the cash incomings and outgoings, sorted by criteria defined by the user of one or more investment funds on one or more trade dates. FundConfirmedCashFo The recastReportCancellati FundConfirmedCashForecastReportCancellatio

camt.042.001.03

camt.043.001.03

camt.044.001.02

56 | P a g e

onV02 camt.045.001.02

nV02 message cancels a previously sent FundConfirmedCashForecastReport message.

FundDetailedConfirme The dCashForecastReportC FundDetailedConfirmedCashForecastReportCa ncellationV02 message cancels a previously ancellationV02 sent FundDetailedConfirmedCashForecastReport message. GetReservationV01 The GetReservationV01 message is sent by a member to the transaction administrator. It requests information on the details of one or more reservation facilities set by the member and managed by the transaction administrator. The ReturnReservationV01 message is sent by a member to the transaction administrator. It provides information on the details of one or more reservation facilities set by the member and managed by the transaction administrator. The ReturnReservation message can be sent as a response to a related GetReservation message (pull mode) or initiated by the transaction administrator (push mode). The push of information can take place either at prearranged times or as a warning or alarm when a problem has occurred. The ModifyReservationV01 message is sent by a member to the transaction administrator. It requests a modification of details of one or more reservation facilities set by the member and managed by the transaction administrator. The DeleteReservationV01 message is sent by a member to the transaction administrator. It requests a deletion of one or more reservation facilities set by the member and managed by the transaction administrator. The LiquidityCreditTransferV01 message is sent by a member to the transaction administrator. It requests a transfer of funds between two accounts belonging to the same member or the same group of accounts, and

camt.046.001.01

camt.047.001.01

ReturnReservationV01

camt.048.001.01

ModifyReservationV0 1

camt.049.001.01

DeleteReservationV01

camt.050.001.01

LiquidityCreditTransfe rV01

57 | P a g e

being held at the transaction administrator. camt.051.001.01 LiquidityDebitTransfer V01 The LiquidityDebitTransferV01 message is sent by a member to the transaction administrator. It requests a transfer of funds between two accounts belonging to the same member or the same group of accounts, and being held at the transaction administrator. The Bank-to-CustomerAccountReportV01 message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. The Bank-to-CustomerStatementmessagV01e is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. The Bank-toCustomerDebitCreditNotificationV01 message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account.

camt.052.001.01

BankToCustomerAcco untReportV01

camt.053.001.01

BankToCustomerState mentV01

camt.054.001.01

BankToCustomerDebit CreditNotificationV01

Derivatives MX Identifier defp.001.001.01 MX Name ContractCreated Purpose The ContractCreated notification message indicates that a contract has been created at the allocation level. The ContractNovated message provides the recipient with the latest terms for a full or

defp.002.001.01

ContractNovated

58 | P a g e

partial novation of the indicated contract. defp.003.001.01 ContractIncreased The ContractIncreased message provides the recipient with the terms for an economic enlargement of the indicated contract. The ContractPartialTermination message indicates that a contract has been terminated partially. The ContractFullTermination message provides the recipient with the latest terms for a full termination of the indicated contract. The ContractCancelled notification allows a contract created by mistake to be cancelled entirely. The RequestTradeConfirmation allows a trading party to confirm a trade to its counterparty. The ModifyTradeConfirmation allows a trading party to modify a trade previously confirmed to its counterparty.

defp.004.001.01

ContractPartialTerminatio n ContractFullTermination

defp.005.001.01

defp.006.001.01

ContractCancelled

defp.007.001.01

RequestTradeConfirmatio n ModifyTradeConfirmation

defp.008.001.01

defp.009.001.01

CancelTradeConfirmation

defp.010.001.01

The CancelTradeConfirmation allows a trading party to cancel a trade previously confirmed to its counterparty. The ContractNovatedCancelled message ContractNovatedCancelled notifies the recipient that a ContractNovated is cancelled. ContractIncreasedCancelle The ContractIncreasedCancelled message d notifies the recipient that a ContractIncreased is cancelled. ContractPartialTerminatio nCancelled ContractFullTerminationC ancelled The ContractPartialTerminationCancelled notifies that a ContractPartialTermination is cancelled. The ContractFullTerminationCancelled message notifies that a ContractFullTermination is cancelled.

defp.011.001.01

defp.012.001.01

defp.013.001.01

Payments Clearing and Settlement MX Identifier pacs.002.001.02

59 | P a g e

MX Name PaymentStatusReportV02

Purpose The PaymentStatusReportV02 message is

sent by an instructed agent to the previous party in the payment chain. It informs this party about the positive or negative status of an instruction (either single or file). It can also report on a pending instruction. pacs.003.001.01 FlToFICustomerDirectDebi tV01 The FIToFICustomerDirectDebitV01 message is sent by the creditor agent to the debtor agent, directly or through other agents and/or a payment clearing and settlement system. It collects funds from a debtor account for a creditor. The PaymentReturnV01 message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled. The PaymentCancellationRequestV01 message is sent by the initiating party or any agent, to the next party in the payment chain. It requests the cancellation of an instruction previously sent. The FIToFIPaymentReversalV01 message is sent by an agent to the next party in the payment chain. It reverses a payment previously executed. The FIToFICustomerCreditTransferV01 message is sent by the debtor agent to the creditor agent, directly or through other agents and/or a payment clearing and settlement system. It moves funds from a debtor account to a creditor. The FinancialInstitutionCreditTransfer message is sent by a debtor financial institution to a creditor financial institution, directly or through other agents and/or a payment clearing and settlement system. It moves funds from a debtor account to a creditor, where both debtor and creditor are financial institutions.

pacs.004.001.01

PaymentReturnV01

pacs.006.001.01

PaymentCancellationRequ estV01

pacs.007.001.01

FIToFIPaymentReversalV0 1

pacs.008.001.01

FIToFICustomerCreditTran sferV01

pacs.009.001.01

FinancialInstitutionCreditT ransferV01

Payments Initiation MX Identifier

60 | P a g e

MX Name

Purpose

pain.001.001.02

CustomerCreditTransferInitia tionV02

The CustomerCreditTransferInitiationV02 message is sent by the initiating party to the forwarding agent or debtor agent. It requests movement of funds from the debtor's account to a creditor. The PaymentStatusReportV02 message is sent by an instructed agent to the previous party in the payment chain. It informs this party about the positive or negative status of an instruction (either single or file). It can also report on a pending instruction. The PaymentCancellationRequestV01 message is sent by the initiating party or any agent, to the next party in the payment chain. It requests the cancellation of an instruction previously sent.

pain.002.001.02

PaymentStatusReportV02

pain.006.001.01

PaymentCancellationRequest V01

pain.007.001.01

CustomerPaymentReversalV0 The CustomerPaymentReversalV01 1 message is sent by the initiating party to the next party in the payment chain. It reverses a payment previously executed.

pain.008.001.01

CustomerDirectDebitInitiatio nV01

The CustomerDirectDebitInitiationV01 message is sent by the initiating party to the forwarding agent or creditor agent. It requests single or bulk collection(s) of funds from one or various debtor's account(s) for a creditor.

Reference Data MX Identifier reda.001.001.03 MX Name PriceReportV03 Purpose The PriceReportV03 message reports the net asset value and price information for one or more financial instruments on specific trade dates and, optionally, to quote price variation information. The PriceReportCancellationV03 message cancels a previouslysent PriceReport message.

reda.002.001.03

PriceReportCance llationV03

61 | P a g e

reda.003.001.03

PriceReportCorre ctionV03

The PriceReportCorrectionV03 message corrects specific price information included in a previously sent PriceReport message.

Securities Events MX Identifier seev.001.001.01 MX Name MeetingNotificatio nV01 Purpose The MeetingNotificationV01 message is sent by a notifying party, eg, an issuer, its agent or an intermediary to a party holding y, the right to vote, to announce a shareholders meeting. It provides information on the participation details and requirements for the meeting, the vote parameters and the resolutions. seev.002.001.01 MeetingCancellatio The MeetingCancellationV01 message is sent by the nV01 party that sent the MeetingNotification message to the original receiver. It is sent to cancel the previous MeetingNotification message previously sent or to advise the cancellation of a meeting. MeetingEntitlemen The MeetingEntitlementNotificationV01 message is tNotificationV01 sent by an account servicer t to an issuer, its agent, an intermediary or an account owner to advise the entitlement in relation to a shareholders meeting. MeetingInstruction V01 The MeetingInstructionV01 message is sent by a party holding the right to vote to an intermediary, the issuer or its agent to request the receiving party to act upon one or several instructions. The MeetingInstruction message is used to register for a shareholders meeting, request blocking or registration of securities. It is used to assign a proxy, to specify the names of meeting attendees and to relay vote instructions per resolution electronically. The MeetingInstructionCancellationRequestV01 message is sent by the same party that sent the MeetingInstruction message. It is sent to request the cancellation of all instructions included in the original the MeetingInstruction message. seev.006.001.01 MeetingInstruction StatusV01 The MeetingInstructionStatusV01 message is sent by the Receiver of the MeetingInstruction or

seev.003.001.01

seev.004.001.01

seev.005.001.01

MeetingInstruction CancellationReque stV01

62 | P a g e

MeetingInstructionCancellationRequest to the Sender of these messages. The message gives the status of a complete message or of one or more specific instructions within the message. It can also be used used as a reminder to request voting instructions. seev.007.001.01 MeetingVoteExecu tionConfirmationV 01 The MeetingVoteExecutionConfirmationV01 is send by an issuer, its agent or an intermediary to confirm to the Sender of the MeetingInstruction message, the execution of their voting instruction. This message is sent after the meeting has taken place. seev.008.001.01 MeetingResultDiss eminationV01 The MeetingResultDisseminationV01 message is sent by an issuer, its agent or an intermediary to another intermediary, to a party holding the right to vote, to a registered security holder or to a beneficial holder to provide information on the voting results of a shareholders meeting. It may also provide information on the level of participation. This message is also used to notify an update

Securities Management MX Identifier semt.001.001.02 MX Name Purpose SecuritiesMessage The SecuritiesMessageRejectionV02 message rejects a previously received message on which action cannot RejectionV02 be taken. CustodyStatement The CustodyStatementOfHoldingsV02 message provides OfHoldingsV02 detailed quantity and availability information for financial instrument holdings of a portfolio. AccountingStatem The AccountingStatementOfHoldingsV02 message entOfHoldingsV02 provides valuation detail CustodyStatement The CustodyStatementOfHoldingsCancellationV02 OfHoldingsCancella message cancels a previously sent tionV02 CustodyStatementOfHoldings message. AccountingStatem The AccountingStatementOfHoldingsV02 message entOfHoldingsCanc cancels a previously sent AccountingStatementOfHoldings message.

semt.002.001.02

semt.003.001.02

semt.004.001.02

semt.005.001.02

63 | P a g e

ellationV02 semt.006.001.02 StatementOfInvest The StatementOfInvestmentFundTransactionsV02 mentFundTransacti message reports detailed transactions (increases and onsV02 decreases) of holdings which occurred during a specified period of time. StatementOfInvest The mentFundTransacti StatementOfInvestmentFundTransactionsCancellation onsCancellationV0 V02 message cancels a previously sent 2 StatementOfInvestmentFundstransactions message. RegulatoryTransact The RegulatoryTransactionReport message reports ionReport the transaction details of securities trades that have been executed on or off-exchange. RegulatoryTransact The RegulatoryTransactionReportCancellationRequest ionReportCancellat message is used to request the cancellation of one or ionRequest more or all previously sent individual transactions reports. RegulatoryTransact The RegulatoryTransactionReportStatus message is ionReportStatus used to provide the status of one or more or all previously received individual transactions reports. RegulatoryTransact The RegulatoryTransactionReportCancellationStatus ionReportCancellat message is used to provide the status of one or more ionStatus or all previously received individual transactions reports cancellations requests.

semt.007.001.02

semt.008.001.01

semt.009.001.01

semt.010.001.01

semt.011.001.01

Securities Settlement MX Identifier sese.001.001.02 MX Name TransferOutInstruc tionV02 Purpose The TransferOutInstructionV02 message instructs the delivery of a financial instrument, free of payment, to another of the instructing parties own accounts or to a third party. TransferOutCancell The TransferOutCancellationRequestV02 message ationRequestV02 requests the cancellation of a previously sent TransferOutInstruction message. TransferOutConfir The TransferOutConfirmationV02 message confirms mationV02 the execution of a previously received TransferOutInstruction message. ReversalOfTransfer The ReversalOfTransferOutConfirmationV02 message OutConfirmationV0 reverses (cancels) a previously sent 2 TransferOutConfirmation. TransferInInstructi The TransferInInstructionV02 message instructs the onV02 receipt of a financial instrument, free of payment, from another

sese.002.001.02

sese.003.001.02

sese.004.001.02

sese.005.001.02

64 | P a g e

sese.006.001.02

TransferInCancellat ionRequestV02 TransferInConfirma tionV02

sese.007.001.02

sese.008.001.02

ReversalOfTransfer InConfirmationV02 RequestForTransfe rStatusReportV02

sese.009.001.02

sese.010.001.02

TransferCancellatio nStatusReportV02 TransferInstruction StatusReportV02

sese.011.001.02

sese.012.001.02

PEPOrISAOrPortfoli oTransferInstructio nV02

sese.013.001.02

PEPOrISAOrPortfoli oTransferConfirma tionV02

sese.014.001.02

PEPOrISAOrPortfoli oTransferCancellati onRequestV02

sese.018.001.01

PEPOrISAOrPortfoli oInformationV01

account, either owned by the instructing party or by a third party. The TransferInCancellationRequestV02 message requests the cancellation of a previously sent TransferInInstruction essage. The TransferInConfirmationV02 message confirms the execution of a previously received TransferInInstruction message. The ReversalOfTransferInConfirmationV02 message reverses (cancels) a previously sent TransferInConfirmation essage. The RequestForTransferStatusReportV02 message requests the status of a previously instructed transfer or the status of a reviously sent cancellation of transfer request. The TransferCancellationStatusReportV02 message reports the status of a transfer in or transfer out cancellation request. The TransferInstructionStatusReportV02 message reports the status of a previously received TransferInInstruction or TransferOutInstruction message. The PEPOrISAOrPortfolioTransferInstructionV02 message instructs the transfer of financial instruments from the clients account at the old plan manager to the clients account at the new plan manager through a nominee account. The PEPOrISAOrPortfolioTransferConfirmationV02 message confirms the execution of a previously received PEPOrISAOrPortfolioTransferInstruction message. The message may be used to confirm the execution of one, many or all transfers contained in a previously received PEPOrISAOrPortfolioTransfer message. The PEPOrISAOrPortfolioTransferCancellationRequestV02 message requests the cancellation of a previously sent PEPOrISAOrPortfolioTransferInstruction message. The message requests the cancellation of all transfer instructions contained within a previously sent PEPOrISAOrPortfolioTransferInstruction message. The PEPOrISAOrPortfolioInformationV01 message provides

65 | P a g e

sese.019.001.01

information about one or more PEP or ISA or portfolio products held in a client's account. RequestForPEPOrIS The RequestForPEPOrISAOrPortfolioInformationV01 AOrPortfolioInform message requests information about one or more PEP ationV01 or ISA or portfolio products held in a client's account for which a transfer will be instructed at a later time.

Securities Trade MX Identifier setr.001.001.03 MX Name RedemptionBulkOr derV03 Purpose The RedemptionBulkOrderV03 message bulks several individual redemption orders for one financial instrument into one bulk order for multiple accounts. The RedemptionBulkOrderCancellationRequestV03 message requests the cancellation of a previously sent RedemptionBulkOrder message. The message may request the cancellation of one, many or all redemption orders contained in a previously sent RedemptionBulkOrder message. The RedemptionBulkOrderConfirmationV03 message confirms the execution of a previoulsy received RedmptionBulkOrder message. The message may confirm one, many or all redemption orders contained in a previously received RedemptionBulkOrder message. The RedemptionOrderV03 message instructs the redemption of one or more financial instruments for one investment fund account. The RedemptionOrderCancellationRequestV03 message requests the cancellation of a previously sent RedemptionOrder message. The message may request the cancellation of one, many or all redemption orders contained in a previously sent RedemptionOrder message. The RedemptionOrderConfirmationV03 message confirms the execution of a previously received RedemptionOrder message. The message may confirm the execution of one, many or all redemption orders contained in a

setr.002.001.03

RedemptionBulkOr derCancellationReq uestV03

setr.003.001.03

RedemptionBulkOr derConfirmationV0 3

setr.004.001.03

RedemptionOrderV 03 RedemptionOrderC ancellationRequest V03

setr.005.001.03

setr.006.001.03

RedemptionOrderC onfirmationV03

66 | P a g e

setr.007.001.03

setr.008.001.03

setr.009.001.03

setr.010.001.03

setr.011.001.03

setr.012.001.03

setr.013.001.03

previously received RedemptionOrder message. SubscriptionBulkOr The SubscriptionBulkOrderV03 message bulks several derV03 individual subscription orders for one financial instrument into one bulk order for multiple accounts. SubscriptionBulkOr The SubscriptionBulkOrderCancellationRequestV03 derCancellationReq message uestV03 requests the cancellation of a previously sent SubscriptionBulkOrder. The message may request the cancellation of one, many or all subscription orders contained in a previously received SubscriptionBulkOrder message. SubscriptionBulkOr The SubscriptionBulkOrderConfirmationV03 message derConfirmationV0 confirms the execution of a previously received 3 SubscriptionBulkOrder message. The message may confirm the execution of one, many or all subscription orders contained in a previously received SubscriptionBulkOrder message. SubscriptionOrder The SubscriptionOrderV03 message instructs the V03 subscription of one or more financial instruments for one investment fund account. SubscriptionMultip The SubscriptionOrderCancellationRequestV03 leOrderCancellatio message nRequestV03 requests the cancellation of a previously sent SubscriptionOrder message. The message may request the cancellation of one, many or all subscription orders contained in a previously sent SubscriptionOrder message. SubscriptionOrderC The SubscriptionOrderConfirmationV03 message onfirmation V03 confirms the execution of a previously received SubscriptionOrder message. The message may confirm the execution of one, many or all subscription orders contained in a previously received SubscriptionOrder message. SwitchOrder V03 The SwitchOrderV03 message instructs a switch transaction from a financial instrument or multiple financial instruments to a different specified financial instrument or

67 | P a g e

setr.014.001.03

setr.015.001.03

setr.016.001.03

setr.017.001.03

setr.018.001.03

setr.047.001.01

setr.048.001.01

setr.049.001.01

setr.050.001.01

instruments for a specified amount/quantity. The SwitchOrderCancellationRequestV03 message requests the cancellation of a previously sent SwitchOrder message. The message may request the cancellation of one, many or all switch orders contained in a previously sent SwitchOrder message. SwitchOrderConfir The SwitchOrderConfirmationV03 message confirms mationV03 the execution of a previously received SwitchOrder message. The message may confirm the execution of one, many or all switch orders contained in a previously received SwitchOrder message. OrderInstructionSt The OrderInstructionStatusReportV03 message atusReportV03 reports the status of a subscription, redemption or switch order prior to execution. OrderCancellationS The OrderCancellationStatusReportV03 message tatusReportV03 reports the status of an order cancellation request that was previously received. RequestForOrderSt The RequestForOrderStatusReportV03 message atusReportV03 requests the status of one or more order instruction or order cancellation request messages. SubscriptionOrderC The onfirmationCancell SubscriptionOrderConfirmationCancellationInstructio ationInstructionV0 nV01 1 message cancels one or more previously sent subscription order confirmations. SubscriptionOrderC The SubscriptionOrderConfirmationAmendmentV01 onfirmationAmend message amends a previously sent mentV01 SubscriptionOrderConfirmation message. SubscriptionBulkOr The derConfirmationCa SubscriptionBulkOrderConfirmationCancellationInstru ncellationInstru ctio ctionV01 nV01 message cancels one or more previously sent subscription order confirmations. SubscriptionBulkOr The derConfirmationA SubscriptionBulkOrderConfirmationAmendmentV01 mendmentV01 message amends a previously sent SwitchOrderCancel lation RequestV03

68 | P a g e

setr.051.001.01

setr.052.001.01

setr.053.001.01

setr.054.001.01

setr.055.001.01

setr.056.001.01

setr.057.001.01

setr.058.001.01

SubscriptionBulkOrderConfirmation message. The RedemptionOrderConfirmationCancellationInstructio nV01 message cancels one or more previously sent redemption order confirmations. RedemptionOrderC The RedemptionOrderConfirmationAmendmentV01 onfirmationAmend message amends a previously sent mentV01 RedemptionOrderConfirmation message. RedemptionBulkOr The derConfirmationCa RedemptionBulkOrderConfirmationCancellationInstru ncellationInstru ctio ctionV01 nV01 message cancels a previously sent RedemptionBulkOrderConfirmation. The message may be used to cancel one, many or all redemption order confirmations contained in a previously sent RedemptionBulkOrderConfirmation message. RedemptionBulkOr The derConfirmationA RedemptionBulkOrderConfirmationAmendmentV01 mendmentV01 message amends a previously sent RedemptionBulkOrderConfirmation message. SwitchOrderConfir The mationCancellation SwitchOrderConfirmationCancellationInstructionV01 InstructionV01 message cancels one or more previously sent switch order confirmations. SwitchOrderConfir The SwitchOrderConfirmationAmendmentV01 mationAmendmen message tV01 amends a previously sent SwitchOrderConfirmation message OrderConfirmation The OrderConfirmationStatusReportV01 message StatusReportV01 reports the status of an order confirmation or an order confirmation amendment. RequestForOrderC The RequestForOrderConfirmationStatusReportV01 onfirmationStatusR message requests the status of one or several order eportV01 confirmations. RedemptionOrderC onfirmationCancell ationInstructionV0 1

69 | P a g e

Treasury MX Identifier trea.006.001.02 MX Name CancelNonDelivera bleForwardValuati on V02 Purpose The CancelNonDeliverableForwardValuationV02 message is sent by a participant to a central system or to a counterparty to notify the cancellation of the valuation of a non deliverable trade previously confirmed by the sender. The NonDeliverableForwardNotificationV02 message is sent by a central system to a participant to provide details of a non deliverable forward trade.

trea.007.001.02

NonDeliverableFor wardNotification V02

trea.008.001.02

StatusNotificationV The StatusNotificationV02 message is sent by a 02 central system to a participant to notify the current status of a foreign exchange option trade in the system. CreateForeignExch angeOption V02 The CreateForeignExchangeOptionV02 message is sent by a participant to a central system or to a counterparty to confirm a foreign currency option contract. This message is only suitable for Simple (i.e. not Barrier) Vanilla (i.e. not Binary, Digital, Notouch) Foreign Exchange Options. The AmendForeignExchangeOptionV02 message is sent by a participant to a central system or to a counterparty to notify the amendment of a foreign currency option contract. This message is only suitable for Simple (i.e. not Barrier) Vanilla (i.e. not Binary, Digital, Notouch) Foreign Exchange Options. The CancelForeignExchangeOptionV02 message is sent by a participant to a central system or to a counterparty to notify the cancellation of a foreign currency option contract. This message is only suitable for Simple (i.e. not Barrier) Vanilla (i.e. not Binary, Digital, Notouch) Foreign Exchange Options. The ForeignExchangeOptionNotificationV02 message is sent by a central system to a participant to notify the current status of a trade in the system.

trea.009.001.02

trea.010.001.02

AmendForeignExch angeOption V02

trea.011.001.02

CancelForeignExch angeOption V02

trea.012.001.02

ForeignExchangeO ptionNotification V02

trea.013.001.01

WithdrawalNotifica The WithdrawalNotificationV01 message is sent by a tionV01 central system to notify the withdrawal of a trade which was previously notified to the receiver

70 | P a g e

Trade Services Management MX Identifier tsmt.001.001.02 MX Name Acknowledgement V02 Purpose The AcknowledgementV02 message is sent by the matching application to the party from which it received a message. It acknowledges the receipt of a message by the matching application. The ActivityReportV02 message is sent by the matching application to the requester of an activity report. It reports on all transactions for which an activity has taken place within a given time span.

tsmt.002.001.02

ActivityReportV02

tsmt.003.001.02

ActivityReportRequ The ActivityReportRequestV02 message is sent by estV02 either party involved in a transaction to the matching application. It requests a report on all transactions for which an activity has taken place within a given time span. ActivityReportSetU pRequest The ActivityReportSetUpRequest message is sent by either party involved in a transaction to the matching application. It requests the reset of the predetermined time at which an activity report is generated.

tsmt.004.001.01

tsmt.005.001.01

AmendmentAccept The AmendmentAcceptance message is sent by the ance party requested to accept or reject an amendment to the matching application. It accepts an amendment request. AmendmentAccept The AmendmentAcceptanceNotificationV02 message anceNotificationV0 is sent by the matching application to the requester of 2 an amendment. It notifies the acceptance of an amendment request. AmendmentRejecti on The AmendmentRejection message is sent by the party requested to accept or reject an amendment to the matching application. It rejects an amendment request. The AmendmentRejectionNotificationV02 message is sent by the matching application to the requester of an amendment. It notifies the rejection of an amendment request. The BaselineAmendmentRequestV02message is sent by either party involved in a transaction to the matching application. It requests the amendment of an established baseline.

tsmt.006.001.02

tsmt.007.001.01

tsmt.008.001.02

AmendmentRejecti onNotificationV02

tsmt.009.001.02

BaselineAmendme ntRequestV02

71 | P a g e

tsmt.010.001.02

BaselineMatchRep ortV02

The BaselineMatchReportV02 message is sent by the matching application to the parties involved in the establishment of a transaction. It informs about either the successful establishment of a transaction (baseline) or the mis-matches found between two baseline initiation messages (InitialBaselineSubmission message, BaselineReSubmission message). The BaselineReportV02 message is sent by the matching application to the parties involved in an amendment request or to the parties involved in a data set match. It reports either a pre-calculation or final calculation of the dynamic part of an established baseline. The BaselineReSubmissionV02 message is sent by either the counterparty or the initiator of a transaction (baseline) to the matching application. It is used by the counterparty to respond on the registration of a push-through transaction in the matching application or by the initiator or counterparty to re-send earlier mis-matched baseline information.

tsmt.011.001.02

BaselineReportV02

tsmt.012.001.02

BaselineReSubmiss ionV02

tsmt.013.001.02

DateSetMatchRepo The DataSetMatchReportV02 message is sent by the rtV02 matching application to the parties involved in a data set match. It either informs about the successful match of data sets submitted with the instruction match or pre-match (DataSetSubmission message) and the related baseline, or it informs about mismatches found between data sets submitted with the instruction match or pre-match (DataSetSubmission message) and the related baseline. DataSetSubmission V02 The DataSetSubmissionV02 message is sent by either party involved in the transaction to the matching application. It triggers either a match or a pre-match of the information submitted with the message. The DeltaReportV02 message is sent by the matching application to the parties involved in the request of a baseline amendment. It lists the differences between the established and the newly proposed baseline. The ErrorReportV02 message is sent by the matching application to the party from which it received a message. It informs about the inability of the

tsmt.014.001.02

tsmt.015.001.02

DeltaReportV02

tsmt.016.001.02

ErrorReportV02

72 | P a g e

matching application to process a received message. tsmt.017.001.02 ForwardDataSetSu bmissionReportV0 2 The ForwardDataSetSubmissionReportV02 message is sent by the matching application to the counterparty of the submitter of data sets. It passes on information related to the purchasing agreement(s) covered by the transaction(s) referred to in the message. The FullPushThroughReportV02 message is sent by the matching application to either party involved in a transaction. It passes on information that the matching application has received from either party. The forwarded information can originate from an InitialBaselineSubmission or BaselineReSubmission or BaselineAmendmentRequest message. The InitialBaselineSubmissionV02 message is sent by the initiator of a transaction to the matching application. It initiates a transaction.

tsmt.018.001.02

FullPushThroughRe portV02

tsmt.019.001.02

InitialBaselineSub missionV02

tsmt.020.001.01

MisMatchAcceptan The MisMatchAcceptance message is sent by the ce party requested to accept or reject data set mismatches to the matching application. It accepts mismatches between data sets and the related baseline. MisMatchAcceptan The MisMatchAcceptanceNotificationV02 message is ceNotificationV02 sent by the matching application to the submitter of mis-matched data sets. It notifies the acceptance of mis-matched data sets. MisMatchRejection The MisMatchRejection message is sent by the party requested to accept or reject data set mis-matches to the matching application. It rejects mis-matches between data sets and the related baseline. MisMatchRejection The MisMatchRejectionNotificationV02 message is NotificationV02 sent by the matching application to the submitter of mis-matched data sets. It notifies the rejection of mismatched data sets. ActionReminderV0 2 The ActionReminderV02 message is sent by the matching application to either party involved in a transaction that it is expecting to take an action. It reminds a party of an action that it is expected to take. The StatusChangeNotificationV02 message is sent by the matching application to the parties involved in the change of the status of a transaction. It informs about the change of a status.

tsmt.021.001.02

tsmt.022.001.01

tsmt.023.001.02

tsmt.024.001.02

tsmt.025.001.02

StatusChangeNotifi cationV02

73 | P a g e

tsmt.026.001.01

StatusChangeRequ est

The StatusChangeRequest message is sent by either party involved in a transaction to the matching application. It requests a change in the status of a transaction. The StatusChangeRequestAcceptance message is sent by the party requested to accept or reject the request of a change in the status of a transaction to the matching application. It informs about the acceptance of a request to change the status of a transaction. The StatusChangeRequestNotificationV02 message is sent by the matching application to the party requested to accept or reject the request of a change in the status of a transaction. It notifies the request of a change in the status of a transaction. The StatusChangeRequestRejection message is sent by the party requested to accept or reject the request of a change in the status of a transaction to the matching application. It informs about the rejection of a request to change the status of a transaction. The StatusChangeRequestRejectionNotificationV02 message is sent by the matching application to the submitter of a request to change the status of a transaction. It informs about the rejection of a request to change the status of a transaction.

tsmt.027.001.01

StatusChangeRequ estAcceptance

tsmt.028.001.02

StatusChangeRequ estNotificationV02

tsmt.029.001.01

StatusChangeRequ estRejection

tsmt.030.001.02

StatusChangeRequ estRejectionNotific ationV02

tsmt.031.001.02

StatusExtensionAcc The StatusExtensionAcceptanceV02 message is sent eptanceV02 by the party requested to accept or reject a request to extend the status of a transaction to the matching application. It informs about the acceptance of a request to extend the status of a transaction. StatusExtensionNo tificationV02 The StatusExtensionNotificationV02 message is sent by the matching application to the parties involved in a request to extend the status of a transaction. It informs about the acceptance of a request to extend the status of a transaction. The StatusExtensionRejectionV02 message is sent by the party requested to accept or reject a request to extend the status of a transaction to the matching application. It informs about the rejection of a request to extend the status of a transaction.

tsmt.032.001.02

tsmt.033.001.02

StatusExtensionRej ectionV02

tsmt.034.001.02

StatusExtensionRej The StatusExtensionRejectionNotificationV02 ectionNotificationV message is sent by the matching application to the

74 | P a g e

02

submitter of a request to extend the status of a transaction. It informs about the rejection of a request to extend the status of a transaction. The StatusExtensionRequestV02message is sent by either party involved in a transaction to the matching application. It requests the extension of the status of a transaction. The StatusExtensionRequestNotificationV02 message is sent by the matching application to the party requested to accept or reject a request to extend the status of a transaction. It notifies the request to extend the status of a transaction. The StatusReportV02 message is sent by the matching application to the requester of a status report. It reports on the status of transactions registered in the matching application.

tsmt.035.001.02

StatusExtensionRe questV02

tsmt.036.001.02

StatusExtensionRe questNotificationV 02

tsmt.037.001.02

StatusReportV02

tsmt.038.001.02

StatusReportReque The StatusReportRequestV02 message is sent by stV02 either party involved in a transaction to the matching application. It reports on the status of transactions registered in the matching application. StoreDataSetReque The StoreDataSetRequestV02 message is sent by the stV02 party specified in the baseline as data set submitter to the matching application. It requests the storage of data set(s) by the matching application. TimeOutNotificatio nV02 The TimeOutNotificationV02 message is sent by the matching application to the parties involved in a transaction. It informs that a transaction will be closed within a given span of time if no action is taken by either party. The TransactionReportV02 message is sent by the matching application to the requester of a transaction report. It reports on various details of transactions registered in the matching application. The TransactionReportRequestV02 message is sent by either party involved in a transaction to the matching application. It reports on details of transactions registered in the matching application.

tsmt.039.001.02

tsmt.040.001.02

tsmt.041.001.02

TransactionReport V02

tsmt.042.001.02

TransactionReport RequestV02

75 | P a g e

Cash Management
Economic changes in the payments landscape have forced the banking community to find new ways to reduce their operational costs, mitigate their liquidity risk and increase the revenue and efficiency of their core payment products. Under the pressure of regulators, the cash management service offering becomes more transparent to meet new customer expectations. While conforming to regulation is a must, service quality becomes a key differentiator. SWIFT has developed offerings in payments and cash management to help the banking community meet these urgent challenges: Enhance customer service: automate exceptions and investigations in order to reduce enquiry turn-around time and to provide transparency on enquiry status to your customers, provide a compelling value proposition for wholesale payments to corporates or person-to-person retail payments for immigrants (workers remittances) including mobile payments. Improve liquidity and risk management: SWIFT liquidity risk services support financial institutions in their efforts to build their liquidity dashboards and develop liquidity risk analytics in an efficient way. Increase operational efficiency and save costs: SWIFTs single window allows you to rationalise your connectivity channels with: 1. Correspondent banks for clearing and settlement of domestic or foreign currency payments using SWIFTs payments clearing messaging services 2. High value payments clearing and/or settlement systems operating on a realtime gross settlement basis using SWIFTs secure and reliable FIN domestic services for high value payment market infrastructures 3. Retail payments clearing systems using SWIFTs cost efficient services for retail payments market infrastructures: the services help to clear batches of payments prior to settlement at discrete intervals, with or without netting.

SWIFT Application in Cash Management

1. 2. 3.

SWIFTNet Bulk Payments SWIFTNet Cash Reporting SWIFTNet Exceptions and Investigations

76 | P a g e

SWIFTNet Bulk Payments

The Bulk Payments solution is designed to enable banks to exchange files of low-value payments, also called bulk payments, according to agreed operational and business rules and using SWIFT's industry-standard messaging services and payments message standards. Bulk Payments offers a secure, robust capability to help customers reduce their cost of exchanging bulk payment files with all counterparties. Bulk Payments can be centrally processed by Automated Clearing Houses (ACHs) or they can be exchanged and cleared bilaterally between banks. Credit transfers and direct debits are the most commonly used instruments.

Benefits
Reduced costs: A common platform generates savings and enables you to benefit from specific bulk payments pricing. Automation and straight-through processing: Through enhanced standardization and harmonized practices, in particular by implementing UNIFI (ISO 20022) standards. Removal of national barriers: For processing bulk payments and enabling interoperability between communities of users.

Features & Components

Standardized environment: A market requirement

In domestic environments, ACHs and banks use proprietary standards and communications technology to clear low value payments. For cross-border payments, correspondents have implemented a variety of file-transfer solutions, which include private lines, networks, and sometimes physical storage media. The use of SWIFTs FileAct messaging service is becoming increasingly widespread, and its interoperability provides compelling reasons to replace the above-mentioned technologies. The variety of payment formats that correspondents use to clear cross-border bulk payments hampers industry-wide straight-through processing and generates high end-toend transaction costs. Hence, the need for further harmonization and standardization.

77 | P a g e

A common technical platform

The power of SWIFTs secure IP network, SWIFTNet, is that it provides a common technical platform to support multiple business communication needs in a secure, reliable and costeffective way: 1. Between banks and domestic ACHs for such payments as salaries, expenses, and pensions. 2. Between banks and regional ACHs. 3. Between ACHs to ensure interoperability between domestic or regional payments systems. 4. Between banks and their correspondents on a bilateral basis at domestic and cross-border levels, such as for cross-border pension payments. 5. Between banks and their correspondents on a multilateral basis at domestic and cross-border levels, such as the Eurogiro network. In the Bulk Payments solution, FileAct is used as the main messaging service, allowing the transfer of payments files in a secure and resilient way. FileAct has recently been enhanced to further support the low value payments market. Enhancements include the possibility of
78 | P a g e

adding business information in the header of the file, and of copying this information to a third-party for further processing or authorization. FileAct is complemented by InterAct whenever there is a need to deal with urgent payments, for instance just before cut-off time. Bulk Payments is implemented in a series of closed user groups administered by SWIFT or by market infrastructures. It supports all clearing and settlement strategies of low value payments as described above.

Harmonized practices and rulebook

Harmonizing the way customers use FileAct is essential to decrease development costs and facilitate interoperability between payments systems. The Bulk Payments rulebook provides rules and guidelines for all Bulk Payments customers. It also defines agreed market practices and a minimum set of rules that SWIFT has established in conjunction with the industry. The main goals of the rulebook are: 1. To ensure the value of Bulk Payments as a whole to the industry by defining a minimum level of service that users undertake to support. 2. To facilitate the establishment of bilateral or multilateral agreements between users of the service. 3. To document and share best practices and recommendations that SWIFT has gathered in co-operation with pilot users and early adopters of the solution. Support of existing domestic formats and UNIFI (ISO 20022) standards

Message standards are another component of Bulk Payments, and each service will mandate a standard. To promote interoperability, UNIFI (ISO 20022) SWIFT MX message standards are available for use on all Bulk Payments services. SWIFT has based its MX messages on a new methodology and has adopted a new process to design and develop financial message standards beyond the existing set of FIN messages (known as MTs). The new approach uses XML technology and syntax, and provides new tools for application developers. The European Payments Council has selected UNIFI (ISO 20022) standards for the exchange of SEPA (Single Euro Payment Area) credit transfers and direct debits.

Competitive pricing

Bulk Payments includes a competitive pricing compared to alternative offerings. It is based on a price per payment, which is well adapted to the actual business model, and rewards wide market adoption through a tier approach.

79 | P a g e

The pricing of Bulk Payments applies to UNIFI (ISO 20022) standards as well as to all proprietary formats, without making distinctions between pricing levels. It is independent of the compression level and payment length, and supports the move to multiple settlement cycles throughout the day, as the price is independent of the file size. You can deploy Bulk Payments easily and securely through your single connection to SWIFTNet. The solution will lower your cost of exchanging low-value payments files by reusing your existing infrastructure in a harmonised way. Costs associated with proprietary connections and related security administration will also be substantially reduced.

SWIFTNet Cash Reporting

SWIFTs Cash Reporting solution responds to the need to exchange realtime information on cash held in accounts maintained at various counterparties. It enables you to benefit from real-time intraday cash reporting and to communicate in fully automated and standardised way with your counterparties.

Benefits
Service providers Benefits Improved customer service: Benefit from the competitive advantage gained by offering enhanced customer service to their customers Improved customer satisfaction: By offering timely information to their account owners, service providers allow them, for instance, to react earlier to non-receipts Service user Benefits Optimised balances: Improve monitoring of global cash positions, enabling better intraday (i.e. all previous day values plus transactions from today) liquidity management and reduced funding costs. Improved risk management: Increase accurate measurement of global settlement exposure and improve transparency of settlement risk Shorter reconciliation cycles: Improve error detection and resolution processes, enabling cost reductions linked to more efficient intraday reconciliation Earlier exception handling: Improve operational efficiency and achieve faster turnaround times in the investigation process End-to-end standardisation: Improve end-to-end STP (Straight Through Processing) through interoperability and full automation across the entire life cycle of the payment transaction High Efficiency: Real-time enables financial institutions to become much more efficient

Key characteristics
The role of SWIFT as trusted third party providing the SWIFTNet messaging infrastructure Reach to all players involved in the end-to-end transaction chain

80 | P a g e

Use on both domestic and cross-border levels SWIFT standards that are used globally Use of a common security scheme

Industry trends
Over the past few years, there has been increasing industry interest in real-time information delivery in wholesale banking. This started with payment clearing systems requirements and has spread into the bank-to-bank space. The need for standardised solutions is driven by: Centralisation of liquidity management and treasury functions Growing volumes of cross-border payments Increasing volumes of timepayments (payment versus payment, delivery versus payment, real-time gross settlement systems) Emergence of cross-border real-time payment settlement systems, in addition to existing domestic systems Increasing regulatory pressure on managing credit risk

81 | P a g e

Features & Components:

Standards responding to all reporting needs

The Cash Management message standards were developed to support the industry in addressing the changing cash management environment. The portfolio responds to a wide range of communication requirements and scenarios. It covers information related to transactions and balances, as well as the management of limits and reservation facilities. The messages support multiple business communication needs: 1. Between financial institutions 2. Between a financial institution and a clearing system service provider

Cash Reporting: a solution for financial institutions responding to real-time reporting needs

Cash Reporting focuses on the need for financial institutions to obtain real-time account balance and transaction information from one or more of their service providers. Cash Reporting is built on a set of components: 1. SWIFT XML messages: SWIFT XML messages are created in accordance with the UNIFI (ISO 20022) development principles. Cash reporting messages provide an

82 | P a g e

industry-wide solution for the exchange of transactional and balance information between an account owner and its account servicing institution. 2. SWIFTNet messaging services: Cash Reporting uses the InterAct messaging service in store-and forward mode, with centrally managed validation and nonrepudiation. 3. Applications: SWIFT works in partnership with thirdparty application vendors to make end-to-end solutions available to service providers and service users, and to ensure smooth and fast integration.

83 | P a g e

Market infrastructure cash Management

Payments markets

Market infrastructure cash management complements the implementation of realtime gross settlement systems using FIN and FIN Copy. SWIFTs interactive messaging services provide speed, throughput, and real-time operations. The diagram depicts the most common architecture, based on FIN Copy, for the transfer of payments instructions between two financial institutions. This is supplemented by InterAct for real-time reporting. The solution enables account owners to: 1. Improve management of settlement risk through real-time access to all payment instructions status and transaction details 2. Obtain real-time business data, such as limit information and warnings, in a standardized format 3. Modify priority of queued payments and cancel queued payments in a secure and standardised way Securities markets

Central securities depositories and international central securities depositories take advantage of market infrastructure cash management to provide their customers with realtime reporting on settled transactions and other transaction status. Such a service gives the
84 | P a g e

participants clear information on the expected or available balances in the securities settlement related cash accounts, allowing them to assess potential effects on their intraday liquidity management. The solution enables account owners to: 1. Determine the total amount of cash needed to settle transactions 2. Better manage liquidity based on detailed balance information 3. Have an intraday view on corporate actions cash bookings (The Intraday View includes account details of all previous day values plus transactions from today) Solution components

The solution is composed of three common components: SWIFT XML standards, messaging services, and applications. SWIFT provides dedicated SWIFTNet services for the central institution (service provider) to manage its cash management service with its participants (service users). This is complemented by the closed user group, which is designed to manage the communication between counterparties on the basis of configurable rules. The central institution defines the criteria for joining its dedicated SWIFTNet service and closed user group that allows participants to obtain and exchange account-related information. Within the closed user group, the central institution can choose from the set of SWIFT standards for cash management. The central institution also chooses the most appropriate SWIFT messaging service - FIN, InterAct, FileAct or Browse -that best supports its service offering. The SWIFTNet messaging services complement FIN store-and-forward: 1. InterAct provides interactive exchange of instructions between counterparties. Participants can instantaneously monitor foreign exchange and credit risk exposures. They can also manage liquidity and collateral throughout their branch networks in real-time. The instructions can be easily integrated into users back-office applications. 2. Browse provides secure browsing to facilitate online visual access to web servers based on the Internet standard https. It is used in conjunction with Alliance WebStation to access remote servers from the users desktop.

85 | P a g e

Cash reporting for financial Institutions

Cash Reporting enables account servicing institutions (service providers) and account owners (service users) to interactively exchange real-time information related to accounts serviced by service providers and owned by service users. Service providers can be clearing banks, custodians, (international) central securities depositories, vostro banks servicing accounts for brokerdealers, investment managers, and nostro banks. These accounts can be nostro or vostro accounts, settlement accounts, or other accounts. Identifying transactional and balance data in real-time across all currencies and time zones offers substantial benefits. Solution components

Cash Reporting is composed of the three common components - SWIFT XML standards, SWIFTNet messaging services, and applications, plus a rulebook. SWIFT supports and administers the Cash Reporting closed user group which allows its registered members to exchange account balance and transaction detail information using SWIFT XML standards. These messages are exchanged over InterAct in store-and-forward messaging mode. InterAct ensures the highest levels of confidentiality and integrity of all messages between correspondent banks, and enforces message validation by the network.

86 | P a g e

InterAct supports the delivery of real-time balance and transaction information to account owners in both the Auto-report and Query mode. In Auto-report mode (previously known as Push mode), the account servicing institution sends Return messages to the account owner. Messages can be sent as frequently as new entries are posted to the account or according to the business terms negotiated between the parties. In Query mode (previously known as Pull mode), the account owner initiates the information flow by sending a request for information, a Get message. The account servicing institution replies to the request with a Return message containing the information.

87 | P a g e

Application models

Cash Reporting supports both distributed and hosted application models: In the distributed model, account servicing institutions establish and maintain their own applications environment. They provide account owners with direct access to the data related to the accounts they service. Such applications may be outsourced for development to third party vendors. In a hosted model, a shared central utility is created, to which account servicing institutions submit cash related information. The data is distributed in real time and in a standard format to the various account owners that have subscribed to this model. Alternatively it can be made available to be queried by the account owners that have subscribed to the model. Queries to the central utility are made in a standard format.

Exceptions and Investigations

SWIFTs solution for Exceptions and Investigations supports the automation of paymentrelated enquiries, whether you are a financial institution or a corporate.

88 | P a g e

Benefits:
Save costs by automating enquiries: Potential staff cost savings for the industry as a whole have been estimated at 35% yearly; messaging cost savings at up to 30% yearly. Comply with regulation without adding more staff: A fully automated process allows you to acquire new business and sustain growing volumes caused by new and stricter industry regulations (eg- SEPA- Single Euro Payment Area) while maintaining the same customer SLAs and without needing to recruit additional staff. Reduce risk: An automated process reduces the risk linked to pending payments and considerably shortens your recovery time after disasters and outages. Improve customer service: You will offer your customers shortened investigations turnaround time as well as a fully transparent view on ongoing investigations. It will help them to better control their payables and receivables and improve their treasury management.

The SWIFT E&I service:

Choice of application: SWIFT provides an Easy E&I case management application. Alternatively, you can choose a SWIFTReady E&I application from a vendor, use E&I offered by a service bureau or enhance your own application. Standards: 16 structured XML messages can be used in 4 workflows to cover 80% of all payment enquiries: 1. Beneficiary claims non-receipt 2. Unable to apply 3. Request for modification 4. Request for cancellation Rulebook: Business and operational rules on message processing, like unique case ID and no-bypass rule further increase straight-through processing. Messaging: E&I messages are sent using InterAct in store-and-forward with message validation, end-to-end authentication and non-repudiation. Easy to implement: With a multitude of options on-site or as a service - E&I is easy to implement. In addition, classroom and online training courses are available. MT- MX syntax coexistence: In todays co-existence phase, E&I users have to support inquiries in MT and MX syntax - at the same time. All SWIFTReady E&I applications though, including SWIFTs Easy E&I solution, combined with the SN Services Directory make this transparent for the operator. The applications can process both MT and MX syntaxes, generate the message in the syntax the receiver supports and automatically translate an inbound message into the appropriate outbound message syntax if required.

89 | P a g e

Example of E&I Workflow:

Steps followed in above Workflow: 1. 2. 3. 4. 5. A creditor claims a due payment was not received. A claim non receipt E&I enquiry is sent on request of the Debtor. The enquiry reaches Bank C, after clearance from Bank A & Bank B. (Due to technical issue, payment was not processed by Creditor Bank C) Creditor Bank processes payment, sends statement and closes case by returning E&I case resolution message.

90 | P a g e

Treasury & Derivatives

Treasury functions was confined to funds management that are maintaining adequate cash balances to meet day-to-day requirements, deploying surplus funds generated in the operations and scouring funds to bridge occasional gaps in cash flow. It is also responsible to meet reserve requirements like minimum cash balance CRR (Cash Reserve Ratio) and investing funds in approved securities to the extent required under SLR (Statutory Liquidity Ratio). Now it is also evolved as profit centre, with its own trading and investment activities. It plays an active role in Assets-Liability Management. Derivative enables an investor to take a chance on the possibility of a price rise or fall even without the initial investment. Derivatives is thus an instrument whose value depends on the values of other more basic underlying variables like stock prices, exchange prices and interest rate.

SWIFT Applications for Treasury and Derivatives are:

1. SWIFTNet Accord 2. SWIFTNet Affirmations 3. SWIFTNet CLS (Continuous Linked Settlement) Third Party Service

91 | P a g e

SWIFTNet Accord
Accord for Treasury is a safe matching and exception handling solution for foreign exchange, money market and OTC derivative confirmations. It provides the combined benefits of both a central and an in-house system whether or not the counterparty is also an Accord subscriber. The Accord Consulting Services package can helps to improve the usage of Accord by auditing existing matching process and the activities performed by end-users. SWIFTs Accord for Securities service builds on Accord for Treasury, matching equity and fixed income trades enabling brokers, prime brokers and custodians to reduce the costs and risks involved in processing securities trades globally. This help to lower operational risk and obtain a reduced total cost of ownership through better usage of Accord. SWIFTNet Accord provides following benefits for improvement in Treasury Operations:

Reviewing Treasury Operations

It documents and assesses the operational flows, communication channels and messaging formats within operations and cash control. The analysis will map the processes and flows around daily liquidity/cash management and cash forecasting. The assessment will also evaluate opportunities to increase the timeliness of cash forecasting information from transfer agents, custodian banks, institutional investors, and other counterparties. SWIFT can help by reviewing current treasury operations including operational workflow and data/messaging flows.

Assisting with the selection of a Treasury Workstation

The study involves data gathering and analysis of SWIFT integration, requirements and objective comparative product analysis of SWIFTReady applications. Objective comparative product analysis among SWIFTReady applications including links to source data. Best practices when implementing a treasury workstation and integrating SWIFT standards for straight-through processing. Overview of SWIFT implementation models and best market practices for a phased approach and on-boarding of multi-bank relationships. Independent review of vendor evaluation/selection for a treasury workstation based on specific requirements.

92 | P a g e

FX options on Accord for Treasury

A real-time matching solution and exception handling tool for all FX options SWIFTs Accord for Treasury matching application can be safe matching and exception handling solution for both vanilla and exotic FX options. Accord for Treasury matches all foreign exchange, money market and OTC derivatives confirmations, but can be used just to match FX options if this is your requirement. Deployed on fault-tolerant, duplicated hardware, and made accessible through SWIFTs secure IP network, Accord for Treasury provides you with the combined benefits of both a central and an in-house system, whether or not your counterparty is also an Accord user.

Benefits:
Reducing operational risk Reducing operational risk is a key requirement for foreign exchange, money market and derivatives back offices. To minimise operational risk, institutions favour the use of real-time, automatic confirmation matching and exception handling solutions. By relying on a central matching system with close to 100% uptime and guaranteed matching results. In addition, Accord keeps the entire matching history and an audit trail of operator actions associated with transactions for seven days after maturity. This data can then be archived for another ten years, via Accords Long Term Archival facility. The potential for fraud is eliminated because SWIFT safeguards the integrity of data in the Accord central matching system. The matching results obtained by Accord have proved to be extremely reliable. SWIFT accepts financial liability for all matches it reports to its Accord subscribers. When both parties are subscribers to Accord, there is a 100% certainty that the matching results will be identical for both parties. This is valuable in the hectic environment of a back office, where there is little time to discuss with counter party issues, such as the status of a trade confirmation or whether further action is required. For all transactions covered by Accord which now includes securities SWIFT consults representative subsets of users to ensure the quality of matching rules is always in line with requirements. When new messages are being added, significant changes are being made or problems have arisen, SWIFT will hold workshops with users to get community level agreement on the best possible matching rules. A proven record of uptime Accord is deployed on a fault tolerant cluster of dedicated high availability servers. The design of the application and its links with SWIFTs messaging infrastructure are particularly resilient, ensuring Accord availability figures are uptime between 1 January 2001 and 31 December 2008 has increase up to 99.97%

93 | P a g e

Lowering total cost of ownership From a total cost of ownership perspective, Accord is more cost efficient than any local matching system. Using Accord eliminates the need for internal resources to keep a local matching system operational and to implement message standard changes within that application. It also eliminates the need for internal support, as SWIFT offers 24x7 Accord support free of charge to users. With the increasing frequency of exotic FX options, and the complexity of these transactions, it becomes less and less feasible to match them manually SWIFTs central matching solution enable to scale up whenever needed. Institutions with volumes ranging from a few hundred confirmations per month to tens of thousands per day use Accord with equal ease. Accord also reduces costs by offering a resilient environment with full support. With Accord, each physical site of institutes can act instantly as a back-up site for confirmation matching and exception handling processes. Additionally, in terms of staff numbers, using Accord as a single cross-asset class matching system is more cost effective than deploying several systems. Different systems usually carry their own training requirements, as well as installation, maintenance and internal support costs. Ease of access via GUI and/or API For exception handling and follow-up, the Accord GUI, deployed on an Alliance Web Station, provides operators with an efficient toolkit. In addition, applications have real-time access to all data available in Accord, via an XMLbased API. A key feature of Accord is that all data is stored centrally, enabling your authorised users to view or process data from locations anywhere in the world. This means it is possible to work as a team across any geographical distance, dynamically allocating the exception handling work to available staff, wherever they are located. Head offices may access data belonging to remote branches. They could, for example, take care of settlements, monitor the performance of the branches, or even conduct a remote audit.

Improving operational efficiency Accord provides single window access to treasury and derivative transactions. This is: Independent of financial instruments: Accord for Treasury can be deployed for any sub-section of OTC treasury business, for example only FX options, or even only exotics and also by counterparty or by currency traded. Counterparty independent: Accord does not require counter parties to be Accord subscribers as well. Carrier independent: Accord handles all confirmations, both sent and received, over the SWIFT network. In addition, Accord can be fed with non-SWIFT confirmations (by fax, email) sent to/received from parties not using FIN. Cost: Staff costs are the largest element in the cost structure of a trade, so staff efficiency is very important.
94 | P a g e

 GUI: The Accord GUI offers more than just a user-friendly graphical interface. A number of sophisticated background processes can eliminate the need for certain manual tasks, saving you time and increasing STP (Straight through processing) and efficiency. Increasing straight-through processing Accord for Treasurys XML-based API enables institutes to feed matching results or any other related data into other back office applications, dramatically increasing STP. The API for Accord is not software; it is simply a dictionary and a grammar for the language a banking application needs to speak in order to exchange information with the central Accord database. Accord also has sophisticated tools to customise matching rules in order to incrementally improve automatic matching rates, while preserving the reliability of the matching results. The exception handling functionality of Accord for Treasury contains a sophisticated toolbox to send chasers to counterparties. As errors in FX option transactions can be very laborious to describe, it can be use to set up detailed templates corresponding to the most frequently observed errors, to make sure counterparty receives full details of the error found in their confirmation. Between Accord users, such chasers are sent in real time and are automatically attached to the problem the two parties have in common. Matching non-SWIFT messages on Accord The Accord GUI supports a function called manual match which enables explicitly-authorised operators to handle low volumes of non-automated confirmations in reply to SWIFT confirmations sent. The function allows an unmatched message to be declared manually matched by an authorised operator. To automate the matching of larger volumes of nonSWIFT confirmations sent and/or received, Accord subscribers can submit copies of these messages, reformatted as MT 3xx messages. These are then submitted directly into Accord, where they are matched along with regular confirmations. In order to convert incoming hardcopy documents, firstly into a digital format and subsequently into the MT 3xx equivalent, SWIFT works with specialist technology providers. From an STP perspective, transactions confirmed with non-SWIFT messages, whether manually matched by an authorised operator or matched automatically by Accord, can be settled automatically.

95 | P a g e

How does Accord for Treasury work?

When a transaction has been agreed, both parties confirm by sending the appropriate SWIFT confirmation message, an MT 305 or MT 306 in the case of an (exotic) FX option. If either or both parties are Accord subscribers, SWIFT copies these messages to the central Accord matching service. This means that counterparties do not need to be Accord subscribers to match trades with them. Accord matches all confirmations and provides matching results in real time. Any subsequent messages sent for the same transaction (cancellations, corrections, changes) are automatically chained to the previous messages, and result in a real time update of the matching status. Accord functionality allows an institution to organise a single, global back office team across multiple centres, thereby enabling round-the-clock operations for all the financial instruments for which Accord caters.

Matching results

Accords common rule book covers many sophisticated matching rules, immediately available to anyone joining the service. In the case of exotic FX options, these rules have been defined in close cooperation with the major players in the market, and are very detailed and sophisticated. They are regularly adapted to cater for evolving market practices. In addition, subscribers can define their own rules for certain mismatched and unmatched fields in specific contexts. Accord matches incoming confirmations based on the common rule book, combined with these user-defined rules specified for that particular type of deal where appropriate.

96 | P a g e

This results in a higher level of automated matching rates, as superficial errors are resolved. Not all operators are allowed to create such additional personalised matching rules, and sophisticated tools are available for operators to manage their institutions set of rules. If a matched status is obtained based on the presence of a rule information is kept in the system. Once processed in Accord, a trade is defined as matched, mismatched or unmatched. Confirmations are classified as mismatched if they almost, but do not quite, match. A confirmation for which there is no corresponding match, nor a mismatched confirmation, is classified as unmatched. Accord ensures that only mismatched or unmatched confirmations contain real errors. For mismatched confirmations, or for specific unmatched confirmations, the offending fields are highlighted, thereby enabling an easier exception-handling follow-up. An operator can either send a chaser to the counterparty, identifying the error and requesting amendment, or force a match for this specific case or, more generally, create a customised matching rule. Accord can be taught to apply these rules when considering further confirmations, either generically or from specific counterparties.Even for complex FX options SWIFT takes financial liability for every duo of messages Accord has declared matched Handling exceptions: managing the workflow Accords task-based GUI is a powerful toolkit that helps organise the workflow among back office staff responsible for exception handling. Operators can define queries or tasks that keep them informed of the latest changes copied to the central database. For example, if a given mismatch is not a simple case that can be solved with a force-match or an additional rule, it can be flagged and escalated to another member in the team. The flag might indicate the need for further investigation or the sending of an amended confirmation. Authorisation levels for operators implementing exception handling processes may be configured per individual. The level may restrict the nature or importance of an item that can be handled, or could indicate that supervisory approval is needed for specific commands. It is straightforward to ask a counter party to send or correct its confirmation. You simply define the type of query (chaser message) you wish to send. The Accord GUI then takes care of inserting the relevant trade information into the template, so that your counter party can correct its confirmation.

Accords free Test and Training service Accord subscribers can use the free Test and Training facility to test their own back office applications after a component is deployed or when a new SWIFT Standards release is about to go live. This service is identical to the live Accord service, but can only be used by Test and Training SWIFT addresses.
97 | P a g e

Many parties have only recently implemented their capability to send MT 306 confirmations for exotic FX options, or are still developing this. It is very important for these players to make use of Accords free Test and Training facility to test once this functionality is ready. For complex transactions, generating syntactically well-formed messages is only a first step; reliably generating messages that mean what both sender and receiver believe they mean is much harder, but essential for an acceptable matching rate.

Accord Long Term Archival

The Long Term Archival facility allows your institution to eliminate the internal workload and operational risk which is associated with the production, maintenance and secure storage of archived data from Accord. This service automatically archives, on a daily basis, all confirmations with their matching history and associated operator actions. All relevant data is stored, including elements important for fraud prevention. The data is stored in a tamper-proof way for ten years beyond maturity. The resulting archives are accessible only to authorised individuals, and may be consulted online from any Alliance Web Station. A powerful search engine facilitates easy access to required data. Using SWIFT either as a prime or backup facility means that you benefit from an independent archival service provider with proven reliability, availability and resilience. This archival facility is an optional service offered to those members who subscribe to Accord.

98 | P a g e

24-hour support Accord subscribers are automatically entitled to SWIFT support. Use of Accords central matching service enables SWIFT support staff to analyse your query more efficiently. First-line support and product-specific assistance is provided by customer service centres, 24 hours a day, seven days a week. As an Accord subscriber have the flexibility of access to help from remote operators who can see data. A worldwide problem management and tracking system monitors each call until the customer confirms that the problem is solved to its satisfaction.

99 | P a g e

SWIFT Affirmations
Single-screen access to all treasury trades across all counterparties. Currently, many buy-side treasury market deals are either confirmed by email or fax or not confirmed at all. The operational and settlement risk introduced by this manual process is unacceptable in todays market environment. SWIFTs Affirmations application shows the details of all your trades with all your counterparties on a single screen. Accepting or rejecting them is done by a simple mouse click. As a result, your exposure to risk from unconfirmed trades is eliminated.

Benefits
Minimise risk A reduction in the time during which there is uncertainty about a trade enables operational risk to be minimised. Faster error detection prevents delays in processing, allows better management of exposure and reduces settlement risk. Reduce operational costs and improve efficiency and STP Using Affirmations means less manual intervention, such as handling faxes. This reduces processing costs. Operational efficiency is improved, enabling higher rates of straight-through processing (STP). Archival and audit trail An integrated audit trail provides binding evidence of trades which are securely stored at SWIFT. The optional Long Term Archive (LTA) enables you to outsource data storage to SWIFT. LTA stores all information related to a trade for a period of ten years from maturity date. User friendly search functionality provides easy access to archived data. Lower response time Trades appear in real time in the graphical user interface (GUI). User can agree or disagree within seconds. Chasers allow communicating instantaneously with Counter parties. Multiple asset class coverage Affirmation supports multiple asset classes foreign exchange (FX), FX options, money market instruments and interest rate swaps. Support SWIFT offers world-class customer support services, which are available on a 24/7 basis around the globe.

100 | P a g e

Access your data from anywhere Central storage means data can be accessed at anytime from anywhere. Operators can access data from different entities belonging to the same group. Manage future traffic growth There is no need to invest in system upgrades as traffic increases. It maintains a single view on all trades with all counterparties. Reuse your existing SWIFT infrastructure Affirmations build on existing SWIFT infrastructure. It uses SWIFTNet PKI for authentication, access control and no repudiation. It is easy to install, requiring only an Alliance WebStation with the Affirmations GUI.

How SWIFTNet Affirmations works?

The above figure illustrates the Affirmations process flow. 1. The trade is executed between two institutions. In the context of the Affirmations service, we refer to the two sides as submitting party (submits the trade

101 | P a g e

2.

3. 4. 5. 6.

confirmation to the service) and affirming party (accepts or rejects the trade), either directly or via a broker. The submitting party generates an MT 3xx confirmation and sends it to the central hub at SWIFT. To indicate that this confirmation is to be affirmed, you can use a code word in field 72 or the Affirmations GUI. The affirming party views all trades in a user-friendly GUI running inside SWIFTs Alliance Web Station. Specific buttons allow the user to accept or reject every transaction. At any stage, a chaser may also be sent to complement the acceptance or rejection. All actions are recorded in the Affirmations database and can be reviewed at any time. The submitting party can see the resulting status of his confirmations in the GUI in real time. Alternatively, a FIN message with the status of a trade can be sent for integration in back office systems. An API is available for even tighter integration.

Instruments supported by Affirmations

Affirmations cater for the following SWIFT message types: MT 300 Foreign Exchange Confirmation MT 305 Foreign Currency Option Confirmation (vanilla) MT 306 Foreign Currency Option Confirmation (exotic) MT 320 Fixed Loan/Deposit Confirmation MT 330 Call/Notice Loan/Deposit Confirmation MT 340 Forward Rate Agreement Confirmation MT 341 FRA Settlement Confirmation MT 360 Single Currency Interest Rate Swap Confirmation MT 361 Cross Currency Interest Rate Swap Confirmation MT 362 IRS Rate Reset Confirmation

102 | P a g e

SWIFTs CLSThird Party Service

Providing a global FX settlement solution for non-CLS members CLS (Continuous Linked Settlement) Bank provides a global settlement system that reduces bank and systemic risk. However, achieving significant reduction in settlement exposures requires a critical mass of settlement value. CLS members need to settle trades between themselves but may also act upon trades with non-CLS members (third parties). Many CLS members currently offer services to third parties whereby they input and settle trades on behalf of their third-party customer(s) with CLS Bank. Likewise, third parties communicate their foreign exchange transactions to their CLS settlement members. CLS members can use this SWIFT solution to obtain a real-time copy of an agreed subset of confirmation messages sent by their third-party customer. SWIFT provides a global comprehensive solution to support the communication flow between CLS members and third parties (most of whom already use SWIFT), so that they can provide cost effective services to their customers. Eligible for a third party Financial institutions that are not CLS members Any other SWIFT-eligible institution involved in cross-currency trading corporate. There are currently close to 1 million transactions per month.CLS members receive copies of their customers transactions via FIN (using an MT 398 envelope message). The process flow is described above.

Benefits
1. Reduced settlement risk 2. Low cost 3. Straight forward implementation

103 | P a g e

How SWIFTs CLSThird Party Service works?

As the third party exchanges an MT 300 or 305 1. With its counterparty, a copy of that MT 300 or 305 will go to the CLS Third Party Service hub. 2. The hub forwards a copy of the MT 300 or 305 to the CLS member servicing this specific third party using an MT 398. 3. The CLS member submits the information to CLS. 4. Gross Direct Input (GDI) or MT 304, and then receives the matching status from CLS. 5. This model offers a proven methodology and a straightforward implementation for both the third party and the CLS member, including Nostro account reporting using FIN messages. 6. These are actively used in the market.

104 | P a g e

Case Study: TMS Infrastructure

The business challenge

Each of banking systems has its own user IDs, passwords and control features, which would not be a problem if only one system. However, as the number of banking systems increases and the number of user names, passwords etc. proliferate, the level of complexity grows and the control could be compromised as users struggle to keep track of each systems security requirements. In addition to security concerns, daily processes for retrieving statements and making payments through multiple statements were manual and extremely time consuming and this effort was further replicated amongst business units, many of whom hold multiple bank accounts. Electronic banking environment was constraining ability to move accounts between banks to optimise our cash management. Elsewhere in the business were aware that the same issues were faced, especially in Precious Metals Marketing operations which also require access to multiple bank systems.
The technology solution

In Group Treasury there was need to communicate with key banking partners for obtaining statements and making payments across over 100 accounts on a daily basis. Also wanted to integrate banking information with TMS (Treasury management system), without having to implement and maintain multiple interfaces. The most obvious solution was to implement a single connection through which we could communicate with all of our banks. It is looked at various options: bank-owned multi-banking solutions; multi-bank solutions offered in domestic markets such as Switzerland, Germany and France and SWIFT Corporate Access. It was decided that a bank-owned solution created too much risk to an individual bank and reduced our bank independence. As an in-country solution did not give us sufficient scope to manage our international requirements, the logical solution was to implement SWIFT Corporate Access. This gave us the benefit of bank-independent connectivity across all banking partners using the secure, reliable channel (SWIFTNet) already used by banks to communicate with each other.
The activities

The first need to make was how to organise the business to make optimal use of SWIFT. Some companies have taken the opportunity to centralise payments into a payments factory, but treasury activities are centralised to a considerable extent, other parts of the business would also need access to SWIFT, such as metal trading operations in this case. Therefore, it is needed to organise infrastructure to enable business units to access SWIFT as well as integrating with TMS. Also have to decide what message types to exchange through SWIFT, and with what frequency. It was also important to create an infrastructure that would meet future needs, such as in precious metals.

105 | P a g e

Advice and experience

These were advices of SWIFT project which was still in its relatively early stages, so had not yet seen the full benefits, but it is already proving to be a highly successful project. SWIFT organisation was a valuable source of information. The people we worked with at SWIFT acted in an independent way when looking at the advantages or disadvantages of each connectivity model, and proved very helpful. Although the SWIFT project costs are not high, it was difficult to establish our total costs up-front. These included SWIFT membership costs (a relatively small cost); the setup and ongoing costs for the service bureau; the configuration work required by IT infrasture, and the set-up and messaging costs for our banks. For example, while envisaged that would pay transaction costs to our bank, it was not planned for the setup or development fees. When building the business case, it was recognised that being able to articulate the benefits in financial terms was very important. Working with an independent, internal resource (IT project manager within the group) to calculate some of the direct cost savings was helpful in adding credibility to business case. As the legal process took longer than anticipated, it is worth obtaining legal resource as soon as possible and building extra contingence into the project plan. Key providers: banks, system vendors and service bureau are critical to success, and therefore their commitment should be engaged early. Implementing SWIFT is a good opportunity to improve balance reporting and payment processes, so it is worth building in time within the project plan to review these processes and see how they could be enhanced.

106 | P a g e

Securities
SWIFT in the securities market
Over the course of SWIFTs history, more and more securities institutions have joined SWIFT. Today, investment managers, broker-dealers, custodians, securities depositories, clearing organisations, exchanges, virtual matching utilities, electronic trade providers, proxy voting service providers, transfer agents and fund administrators, rely on SWIFT to reduce the complexity, risk and cost of their domestic and international transactions. SWIFT facilitates standardised communications and processing at all levels of the lifecycle of equities and fixed income and investment funds transactions - from trade through to settlement and custody services. SWIFT securities messages, which are based on the ISO 15022 standard, provide enhanced straight-through processing and risk management in a consistent, coherent and uniform way. New securities messages are now being designed in XML for use on SWIFTNet, our advanced Internet Protocol-based messaging platform. SWIFTs priority is to drive standards convergence via ISO 15022 standards, with the ultimate goal of common industry standardisation under UNIFI (ISO 20022). The end result will be harmonised market practices and enhanced STP at an industry level. Securities Market Infrastructures can be divided into the following segments: Exchanges Matching Utilities Clearing Houses / Central Counterparties (CCPs) Central Securities Depositories (CSDs) Regulators / Financial Authorities

Specific Securities Market Infrastructures and SWIFTSolutions will be relevant for specific types of Securities institutions Broker/Dealers Clearers Custodians Investment Managers Settlement Agents

SWIFTNet Application for Securities

SWIFTNet FIX SWIFTNet Fund

Accord for Securities

107 | P a g e

SWIFTNet FIX
The demand for electronic securities trading is growing. Increasingly the Financial Information Exchange (FIX) protocol is the means that the financial community is using for electronic trading. SWIFTNet, SWIFTs IP-based network platform, now provides a complete service for FIX messaging to SWIFT customers - SWIFTNet FIX. The SWIFTNet FIX service was launched with the specific aim of providing new messaging services for the front office part of the transaction lifecycle. Underpinning its value proposition is the reality that institutions usage of front office electronic trading standards has become increasingly strategic and commercially vital. Electronic trading is moving from a nice to have, to a strategic necessity in many front offices. The full benefits of FIX messaging can now be realised through one connection to SWIFT. Additionally SWIFTNet FIX, when combined with industry standard ISO15022 messaging for clearing and settlement, provides SWIFT customers with messaging services covering the full securities transaction lifecycle. This combination provides a unique contribution to help customers in achieving greater STP.
However SWIFTNet FIX is obsolete today.

108 | P a g e

SWIFTNet Funds
SWIFTNet Funds is SWIFTs messaging solution delivering automation and STP to the funds industry through the combination of industry standards and the SWIFTNet messaging network. The service caters for both domestic and global cross-border fund distribution flows across the investment fund, hedge fund and pension fund markets. Messaging is based on UNIFI (ISO 20022) standards covering: account openings and maintenance, orders, status and confirmations, transfers, holdings and transactions statements, price reporting, and cash forecasting. SWIFTNet Funds covers the entire value-chain: Transactions, Transfers, Statements, Account Management, Price Reports and Cash Forecasts and it does this efficiently with STP cutting down on errors and reducing costs By adopting SWIFTNet Funds, the Funds trading processes become more efficient and effective. In order to implement SWIFTNet Funds, clients need to overcome some challenges: Connecting to interact, Transformations between the old mts and the new xml-based mxs, Managing the business logic, Monitoring and fixing messages.

The Funds industry involves many players Accounting Agent, Distributors, Transfer Agent ,Trustee, Cash Agent, Fund Manager, Concentrators, Investor,each using different communication channels. Funds in these hard times Inefficient and error-prone processing 10% of all faxes go missing. Difficulty to resolve disputes High labor costs No transparency to clients Not scalable More automation Less costs More efficiency More transparency Re-use existing investment in SWIFT Entire transaction lifecycle Domestic and cross-border Granularity - 68 MXs Scalable

Why SWIFTNet Funds?

109 | P a g e

Benefits of using SWIFT

Minimise risk, reduce costs

Distributors, fund management companies and transfer agents that have implemented SWIFT for fund distribution have reduced their operational cost of handling orders by 50% to 70%. Improve customer service

Automating order capture and reporting eliminates errors and allows information to be transported in a timely and secure manner. Distributors that have implemented SWIFT for order placement have been able to extend sales cut off times in their branches as the burden of manual handling is removed. Fund management companies and transfer agents can better respond to the reporting needs of their networks of distributors. Achieve scalability

SWIFTs scalable and robust messaging platform can easily be deployed to support large volumes and a large number of counterparties. This removes the burden and high cost of developing and maintaining proprietary solutions for each individual counterparty. Access trading partners worldwide

With over 8,300 financial institutions, including the majority of players active in the funds industry, SWIFT provides a single window to connect with your counterparties directly or via a concentrator or market infrastructure using the same message standards.

110 | P a g e

Accord for Securities

SWIFTs Accord for Securities was initially developed to support SWIFTs work with a group of major prime and executing brokers (including Citi, Credit Suisse, Goldman Sachs, Deutsche Bank and Bank of America Merrill Lynch) to create and operate a centralised presettlement solution for equity and fixed income trades executed by the global hedge fund community. This solution enables prime and executing brokers to automate trade- date matching, for quicker identification and speedier resolution of errors and a reduction in costly settlement failures. MT515 matching on Accord can also be used in other process flows, to replace faxed trade confirmations with electronic confirmations that can be automatically matched, further reducing the costs and risks for market participants of securities trade processing.

Why do I need Accord for Securities?

Discrepancies between trade details submitted by hedge funds to their prime brokers on one hand, and to their executing brokers on the other (or by investment manager to custodian banks and executing broker), are a source of considerable operational risk. Accord for Securities provides timely pre-settlement matching of securities trades. Any errors like to cause settlement failures are identified sooner, both reducing risk and the cost of the manual processing required to fixbreaks. In addition, it is estimated that up to 30 per cent of all fixed income and equity trades between investment banks are made directly between two such institutions, rather than via an exchange or trading platform. Current industry practice is to send a fax confirmation once a trade has been agreed, but not to check these faxes, and to instead rely on the presettlement matching services provided by the local settlement agents. This creates unnecessary costs and risk. Using Accord for Securities, each investment bank can send trade and settlement details for its OTC trades in an MT515 message to Accord to be matched with an MT515 sent by the counterparty to the trade automating the process and reducing costs and risk. Any type of institution that wants to replace faxes with automated electronic confirmations can benefit from this solution.

What benefits does Accord for Securities bring?

Accord for Securities offers a single, central matching solution for the entire community. Existing Accord customers can re-use their existing investment in Accord, SWIFT connectivity and SWIFT messages to quickly and easily take advantage of Accord for Securities. The solution addresses the needs of prime brokers by: Improving the timeliness of the pre-settlement matching process between executing and prime brokers; Automating the pre matching process between executing and prime brokers,
111 | P a g e

reducing the costs of manual exception processing Reducing the settlement failure rate for prime brokerage client and enabling prime brokers to improve their reporting to their hedge funds client. Accord for Securities enables executing brokers to: Retain and attract new hedge fund clients that want the solution to be used to improve service; Eliminate fax confirmations reducing cost and statement settlement failures rates; Improving on local settlement agents pre-settlement matching; Remove the risk of fraud with trade amends Better control of settlement risks such as a client claim to not know a trades.

Who can use Accord for Securities?

Accord matching of MT515 confirmations can be used: Between prime brokers and executing brokers to confirm equity and fixed income trades originating from hedge funds. It can also be used between custodians and executing brokers, for the confirmation of equity and fixed income trades originating from investment managers. Between two executing brokers, to confirm over-the-counter (OTC) fixed income and equity trades that are not automatically cleared by an exchange. Between two prime brokers, to support the transition of a hedge fund manager from one prime broker to another.

112 | P a g e

1. Matching of trades between prime brokers and executing brokers

The end-to-end flow of the Accord matching process for trades between a prime broker and an executing broker covers:

1. Trading - a hedge fund manager and an executing broker close a deal to trade securities. 2. Executing broker notifies Accord the executing broker sends an MT515 confirmation directly to Accord. Executing brokers send confirmations for individual trades throughout the business day. 3. Hedge fund manager notifies prime broker at the end of the business day, the prime broker receives a file from the hedge fund manager that contains all the trades of the day. 4. Prime broker notifies Accord for each trade in the file received from the hedge fund manager, the prime broker sends an MT515 confirmation to Accord.
113 | P a g e

5. Processing when the Accord central server receives the confirmations, it processes them in real time to produce matching results for the confirmations. 6. Monitoring and exception handling the two parties consult the matching results and details of the confirmations, using the Graphical User Interface (GUI). Accord will also be able to generate matching status updates via MT messages. The user can perform actions on the confirmation using the GUI, or, if necessary, can cancel and re-submit a MT 515 to correct a confirmation. The user can also send free-format messages (chasers) to the counterparty. At any time, the user can consult any changes to the matching results in real time. 7. Executing broker notifies agent the executing broker sends a notification of the trade to the agent, using an MT 540 series settlement instruction. 8. Prime broker and agent inform CSD the prime broker and the executing brokers agent send settlement instructions to the CSD. It is possible that the prime broker also uses an agent. In that case, the prime broker notifies the agent, and the agent sends the settlements instructions to the CSD.

114 | P a g e

2. Matching of trades between custodians and executing brokers

The matching process for trades involving a custodian and an executing broker. This flow is identical to the flow for trades between prime brokers and executing brokers, except that the asset manager takes the role of the hedge fund manager, and the custodian takes the role of the prime broker.

1. Trade Asset Manager and an executing broker close a deal to trade securities. 2. Executing broker notifies Accord the executing broker sends an MT515 confirmation directly to Accord. Executing brokers send confirmations for individual trades throughout the business day. 3. Asset Manager notifies Agent at the end of the business day, the Agent receives a file from the Asset manager that contains all the trades of the day.

115 | P a g e

4. Agent notifies Accord for each trade in the file received from the Asset Manager, the Agent sends an MT515 confirmation to Accord. 5. Processing when the Accord central server receives the confirmations, it processes them in real time to produce matching results for the confirmations. 6. Monitoring and exception handling the two parties consult the matching results and details of the confirmations, using the Graphical User Interface (GUI). Accord will also be able to generate matching status updates via MT messages. The user can perform actions on the confirmation using the GUI, or, if necessary, can cancel and re-submit a MT 515 to correct a confirmation. The user can also send free-format messages (chasers) to the counterparty. At any time, the user can consult any changes to the matching results in real time. 7. Agent notifies CSD the executing broker sends a notification of the trade to the agent, using an MT 54n series settlement instruction. The agents of both parties send settlement instructions to the CSD.

116 | P a g e

3. Matching of trades between two executing brokers

The figure below shows the matching process for trades involving two executing brokers. In this model, matching of trades can take place throughout the business day, because both parties submit MT515 confirmations to Accord whenever they make a trade.

1. Trading Two executing broker close a deal to trade securities. 2. Both Executing broker notifies Accord the executing broker sends an MT515 confirmation directly to Accord. Executing brokers send confirmations for individual trades throughout the business day. 3. Processing when the Accord central server receives the confirmations, it processes them in real time to produce matching results for the confirmations. Monitoring and exception handling the two parties consult the matching results and details of the
117 | P a g e

confirmations, using the Graphical User Interface (GUI). Accord will also be able to generate matching status updates via MT messages. The user can perform actions on the confirmation using the GUI, or, if necessary, can cancel and re-submit a MT 515 to correct a confirmation. The user can also send free-format messages (chasers) to the counterparty. At any time, the user can consult any changes to the matching results in real time. 4. Executing broker notifies agent the executing broker sends a notification of the trade to the agent, using an MT 540 series settlement instruction. 5. Agent informs CSD the prime broker and the executing brokers agent send settlement instructions to the CSD. It is possible that the prime broker also uses an agent. In that case, the prime broker notifies the agent, and the agent sends the settlements instructions to the CSD.

Key features of Accord for Securities

MT515s are sent direct to Accord and are not exchanged. MT515s have to be populated according to the requirements of the community. This ensures that a much higher quality of matching can be expected, and the whole community agrees to a central match status. No local matching alternatives are possible. Accord matches trade and settlement details The MT515 is populated with the details of the trade made as well as the settlement details (the standing settlement instructions (SSIs)) of both brokers. Accord is therefore effectively matching all the data that could be included in an MT54n Settlement Instruction. However, users can choose if they want to match both trade and SSIs, or just trade details. Rule Book A fully defined market practice has been developed that applies to the community of users. This describes business and operational rules that determine how to populate the MT515 to ensure the highest of matching rates. There is also a dedicated private user forum established on www.swiftcommunity.net that serves as a discussion forum and document repository. A proven, reliable matching algorithm Accord uses a reliable matching algorithm, proven in the FX and money markets and OTC derivatives businesses. The algorithm uses primary matching fields (fields that define a transaction and which all must match for the system to consider two confirmations as definitely concerning the same transaction) and secondary matching fields (fields that are about an aspect of the transaction, rather than defining it: the system will highlight discrepancies in these fields).
118 | P a g e

For both, Accord uses sophisticated matching styles, market-specific rounding algorithms and an intelligent system to handle matching of the meaning of messages, even where there are variations in the way in which the same content is conveyed in different messages. Tables for static data Included in Accord are tables used by the matching algorithm that a) set the settlement amount tolerance by Place of Settlement, and b) match a BIC of a settlement agent to a proprietary identifier used at a Place of Settlement. Integrating matching statuses in your back office application To allow human operators to directly access the service, Accord for Securities provides a Graphical User Interface. In addition, for parties that want to integrate their matching iresults into their own back office applications, to handle exceptions and automate settlement of matched trades, a customer of Accord for securities can be configured to receive MT messages containing the latest status of a confirmation (for example, matched, mismatched, cancelled, alleged), a reason code and key data elements from the counterpartys confirmation.

119 | P a g e

SWIFTNET Trade Services Utility

The Evolution of Trade and Adoption of Open Account Trading.
Trade finance has become synonymous with the issuance of letters of credit. However, There has been a significant move from this way of doing business. Estimates suggest that more than 80% of global trade is conducted on open account. Large corporates are trading on this basis in order to save costs and time, and smaller corporates are following suit. Lack of information visibility over the financial supply chain also presents challenges. There are 65 banks in 26 countries that have adopted a collaborative centralised matching utility called SWIFTNet Trade Services Utility, which is designed to help banks and their customers meet supply chain challenges. The value of global trade has grown from USD2tr in 1985 to more than USD17tr in 2006 and averaging 18% growth per annum (according to JPMorgan Chase statistics). More than 80% of the volume is cross border. Thirty years ago more than 80% of international trade was conducted using letters of credit or collections; today, less than 20% of international trade is done this way. The majority of international trade now operates on an open account basis. This can be seen below in the SWIFT trade and payment financial message traffic statistics (SWIFT is the industry-owned co-operative supplying secure, standardised messaging services to more than 8,100 financial institutions). The volume of SWIFT payment financial messages has grown continuously while the volume of SWIFT trade financial messages (letters of credit and collections messages) has been flat in recent years.

Fig . 1 Growth of International Trade

120 | P a g e

Fig. 2 SWIFT Financial Message Volumes

2000 1800 1600 1400 1200 1000 800 600 400 200 0 2000 2001 2002 2003 2004 2005 2006 2007 Trade SWIFT Volumes Payment SWIFT Volumes 43 43 44 47 47 46 47 48 930 1100 1350 1210 1355 1422 1577 1831

Supply Chain Challenges

The movement from letters of credit to open accounts has created new challenges for both companies (buyers and sellers) and financial institutions. Many companies recognise the importance of managing both the physical and financial supply chain to achieve cost reductions and process efficiencies. The buying process as shown in Figure 3 refers to the purchase-to-pay cycle, which is when the buyer makes a purchase. During the purchase-topay cycle, the buyer sources the suppliers, and receives and pays for the materials or goods purchased. On the other side, the selling process is the same cycle from the suppliers perspective and refers to the order-to-cash cycle which begins with a quote and ends with the payment received and invoice reconciled. These processes involve all functions within both companies such as procurement, risk assessment, fulfilment, payment and cash management. Companies are increasingly realising that taking a holistic approach towards these processes will be able to help improve efficiencies and eventually reduce costs.

121 | P a g e

Technology has been an important driver in the supply chain innovations, with enterprise resource planning (ERP) systems being used as early as the 1960s. ERP systems can certainly help companies with inventory management and material requirement planning, and hence improve efficiency in streamlining the processes and reducing costs throughout the chain. While the physical supply chain has advanced over the years, the financial supply chain has been left behind. The key challenge remains: how to effectively link the financial supply chain with the physical supply chain. The lack of visibility of this information is a major challenge for corporate. Those using the ERP system may be able to achieve process efficiencies; however, the information flows between buyers, sellers and the partners along the supply chain are not yet automated. These parties are very much paper based. In addition, the lack of the information visible to banks reduces the banks appetite for lending into the supply chain; this will impact the sources of funding for corporate. Today, companies are faced with various supply chain challenges.

Buyers and sellers are driven by different needs

Buyers are focused on increasing their days payable outstanding (DPO), while sellers try to reduce their days sales outstanding (DSO). The DPO refers to the number of days taken to pay suppliers whereas the DSO refers to the number of days for the company to collect payment from a completed sale. The lower the DSO, the faster payment is collected for the supplier and the longer the DPO, the better for the buyer in managing their cash flow. This discrepancy in the buyers and sellers needs is a key challenge to both companies.

Driving costs down

Another key challenge relates to driving costs down for both buyers and sellers. From the large buyers perspective, apart from extending DPO, there has already been a significant move away from letters of credit to open account trading. The move away from letters of credit: Most large corporations view the use of letters of credit as costly, paper driven and time consuming to process. The move away from letters of credit to open accounts is considered necessary to reduce costs. While intraAsia trade is mostly driven by letters of credit today, companies in Asia will certainly start to move away from letters of credit to cut costs. Price pressure: Another challenge in driving costs down is price pressure from large buyers. Buyers are still very pricing sensitive and sellers face strong competition not only from the existing competitors, but also from competitors from emerging economies. As a result, it is difficult for sellers to negotiate price increases. Keeping costs down from sellers is crucial and, in particular, for Chinese manufacturers, the appreciation of the Chinese currency is also threatening the bottom line and making Chinese sellers less competitive in the current economic environment.

122 | P a g e

Coping with growth

World trade is growing (averaging 18% growth per annum), and both buyers and sellers are experiencing growth pressure. While we recognise that growth yields better revenue and profits, the challenge is the risks associated with growth. These risks can be both financial and operational. Some buyers start to introduce new measures for better quality control and these impose new costs for their partners. Recognising the growing pain of their suppliers, large buyers began to realise that working in collaboration with their partners can help reduce costs and risks. Financially, large buyers started to offer vendor finance programmes to support their partners in their liquidity. Some buyers provide these finance programmes directly through discounting the invoices and effectively reducing the DPO; some buyers choose to work closely with their banks to help improve the liquidity of their partners.

Managing working capital

Managing working capital is essential for both buyers and sellers. Typically, the group treasurer from the buyer realises that extended credit terms may in the short term pose some gains in keeping costs down, but in the long run, will drive prices up as eventually these costs will be passed back to the buyer. Managing working capital is not just improving working capital, but also understanding partners needs along the supply chain and helping partners to gain easy access to cheaper financing, ensuring adequate resources and liquidity to support operations. From the suppliers perspective, effective management of working capital is crucial to managing trade growth. Many suppliers will need to look beyond self-financing. Where traditionally, under letters of credit, suppliers have easy access to finance from banks, in particular, they are able to secure pre and post-shipment finance. Moving away from letters of credit to open account trading, suppliers will need to look at various supply chain finance programmes, bearing in mind that they are not standardised across the financial industry. Pre-shipment finance also is a challenge for suppliers under open accounts. For banks to offer pre-shipment finance, the banks need to have a good track record and history from both the buyers and sellers. Most often this information is not easily available.

Managing information flows

The value of information flows between the buyers and sellers processes within and between companies cannot be underestimated. According to industry analysts (from HSBC), in the paper-based environment that exists today, matching of purchase orders, notice of goods received, invoices, certificates, etc. can take about 55 days to complete. If a buyer has a DPO (Days payable outstanding) of 60 days and it takes 55 days to complete the document-checking and approval processes for payment, there is not much room to provide any financing options for their supply chain partners. On the other hand, the visibility of this information is also crucial to take a holistic approach through the entire supply chain process. Problem areas can be identified more easily and solutions can be proposed. Companies are constantly sourcing solutions to integrate the information between the physical and financial supply chain.
123 | P a g e

One of the key challenges in managing the flow of information is where most buyers and sellers may be able to use technology, such as ERP systems, to automate their internal processes and improve efficiencies. However, the information flow between the buyers, sellers and partners is not automated. Documents that are exchanged using open accounts are still very much paper based and manually checked by the buyers, hence there is a lack of information visibility from both sides. Getting suppliers to be automated on a platform poses challenges for buyers, and from the sellers perspective, managing multiple platforms from different buyers does not necessarily reduce costs and manpower. There is a constant struggle between how to manage and reuse data along the supply chain to help reduce costs and develop effective working capital management.

Meeting the Supply Chain Challenge

Supply chain management is not new to the industry and for many years companies have been working together closely with their partners to meet supply chain challenges. Over the years, banks have also been involved in solving financial supply chain challenges and developing various supply chain programmes to help improve process efficiency as well as offer open accounts financing options for corporate. SWIFT responded to the move towards open accounts with the development and deployment of the SWIFTNet Trade Services Utility (TSU), which became commercially available in April 2007. There were 18 banks in eight countries that worked closely with SWIFT to jointly develop TSU. At that time, the industry realised that a collaborative approach must be adopted by all parties to make sure that data throughout the supply chain process could be stored, re-used and passed on in a standardised and automated manner. The TSU is a collaborative centralised matching utility that is designed to help banks meet the supply chain challenge. Banks build individually on the core functionality of the TSU to offer competitive services that are complementary to their existing offerings to their corporate customers.

What is SWIFTNet Trade Services Utility?

The TSU is an interbank data matching and workflow engine. It enables banks to standardise transactions and reduce costs, and match transactions to reduce risk and error. The TSU also tracks transactions, enabling banks to lend at different stages in the transaction process, and increases banks comfort levels by increasing visibility of information in open account transactions. The current release of the TSU offers three broad functions: Matching purchase order information for buyer and seller banks: Buyer and seller banks enter the purchase order information from their buyer or seller into the TSU and the TSU matches this information and provides a match report to both banks involved. Buyer and seller bank collaboration in the transaction means that the TSU not only authenticates the purchase order information, but also increases the visibility of

124 | P a g e

information for both banks. In effect, the TSU increases the comfort of the banks in offering finance services along the supply chain. Matching commercial data (e.g. invoice) and transport data (e.g. bill of lading) against purchase orders and providing a match report for both buyer and seller banks: When a seller ships goods and an invoice or bill of lading is produced, this information is entered into the TSU by the banks and the information is matched against the purchase order. The TSU automates the matching of these documents and provides match reports. The TSU thus provides various triggers for banks to step into the process and offer process management or finance programmes. Reporting functionality: Banks can request various reports from the TSU to enhance the visibility of track records and transaction history to help make decisions or support the credit rating process.

The TSU is invisible from a corporate perspective. The TSU is a bank-to-bank service which enhances communication between banks, offers a standardised messaging platform and helps to improve the visibility of information. Since its launch in April 2007, 65 banks in 26 countries have registered for the TSU service. It is evolving with the industry, with a second product release planned for March 2009. The second release offers a standardised bank payment obligation (BPO) and allows matching of additional data from insurance and certificates. The BPO is important in helping banks to offer lending services, whereby a buyer bank or an obligor bank can at any point of time in the transaction offer a seller bank a payment guarantee on the underlying transaction. This BPO will effectively help the sellers bank in offering pre- or post-shipment finance to the seller, and by standardising the BPO the TSU will further drive industry adoption.

125 | P a g e

Fig. 4 High Level Functionality of TSU

1. Baseline Buyers and Sellers Bank send the PO to TSU. TSU sends back match or mismatch. 2. Dataset Sellers bank submits TSU invoice and shipment information. TSU compares to PO and sends back match or mismatch. 3. Reports Transaction History, Data Mining across entire BIC or specific customer.

126 | P a g e

TSU Enabled Services

Fig.5 TSU Services

Beyond the delivery of financing solutions, the Trade Services Utility also complements banks evolving supply chain strategies focusing on liquidity management and processing efficiency. The identification of trigger points along the supply chain creates the opportunity for banks to provide a variety of value-added services linked to the optimisation of the corporates cash conversion cycle. Examples include the in-sourcing of accounts payable/receivable and/or account reconciliation, cash forecasting and a variety of risk mitigation services. The delivery of these and other services may be done on a phased basis, according to the needs of the individual corporate.

127 | P a g e

Bank Services Offered to Buyers and Sellers

Cash Forecasting

Data matching throughout the transaction lifecycle improves the quality of information and enables corporate treasurers to predict with greater accuracy their cash flow movements and liquidity requirements, reducing the cost of funding. The ability to capture actual shipping, handling and import fees and roll these into cost of goods sold enables buyers to extend stock control to goods in transit and build true cost into the pricing model. Delays cost money. The automatic notification of significant events, e.g. amendments, approvals, delays, shipment dates etc., potentially linked to the assignment of an action, creates an early warning system for discrepancy reporting and an audit trail when resolved. E.g. Contract management (matching data to contract to support payment); shipper visibility (data aggregation services built around visibility).

Landed Costs Management

Discrepancy Management

Others

Risk Management

FX Hedging

Monitoring of transaction data enables a central treasury function to anticipate receipts and payables in different currencies and act as a clearing house to hedge net exposure through multilateral netting. Alternatively, forward contracts can be used to hedge individual transaction exposures. The TSU can become a vehicle for a bank to authenticate to its correspondent the identity of its corporate customer and the content/accuracy of a purchase agreement. The bank may also verify that there is no apparent reason why payment should be refused provided performance occurs. Matched data can be fed into a banks compliance engine in order to satisfy regulatory requirements, e.g. Office of Foreign Assets Control (OFAC), Basel II. Each bank has the responsibility to complete its own compliance checks before submission to the TSU. E.g. LC support (a preliminary data set match highlighting exceptions enables a bank to accelerate internal decision-making processes; collection support (this may be a new service as documents under collection are not checked by the banks); shipping guarantee (enabling the buyer to take control of goods without a bill of lading).

Authenticated Purchase Order

Compliance

Others

128 | P a g e

In Sourcing Services

Document Preparation Data Matching Data Bureau Services Others

Generation of shipping documents based on data received from corporate purchase order systems.

Reconciliation of accounts payable/receivable. If banks have visibility of purchase order and other supply chain data, they can begin to track and provide reports and analyses on supplier performance as a value-added service. This information may be relevant to buyer/seller relationships, price negotiations, dispute resolution, consolidation policy, etc. E.g. Hosting (to support the processing requirements of other banks either on a white label or fully disclosed basis).

Financing

Pre-Shipment Finance

The matching of purchase order data creates opportunities for a sellers bank to make informed decisions regarding the provision of working capital facilities to selected suppliers. This may be linked to work in progress under a buyer support programme or a vendor-managed inventory. The matching of commercial and/or transport data sets to the purchase order

Post-Shipment again creates opportunities for a buyers bank to provide non-recourse finance or early payment to a supplier. These facilities may be linked to inventory in Finance transit, proof of delivery (e.g. a forwarders cargo receipt) or buyer approved invoices. Factoring/ Invoice Discounting Provision of non-recourse finance to the supplier based on a percentage of the invoice value. These facilities may be extended once the commercial data has been matched by the TSU. E.g. Forfaiting (suppliers bank discounts without recourse bills of exchange drawn on the buyer based on the guarantee of the buyers bank); asset securitisation (dependent upon the individual banks credit policy, enhanced cash flow forecasting could enable the purchase of receivables at a low and quantifiable risk).

Others

129 | P a g e

Fig. 6 Pre Shipment Finance

Fig. 7 Post Shipment Finance

130 | P a g e

Simple TSU Open Account Flow

131 | P a g e

132 | P a g e

TSU Benefits to Bank and Corporate TSU Feature

Data Matching Utility Approach New Client Referrals Defend Own Clients

Benefit to Bank
Handling Exceptions only Lower Barrier to Market Entry Referrals from other TSU banks Ability to Offer Supply Chain Services will help to retain clients TSU banks can share best practices

Benefit to Corporate
Earlier Detection of Discrepancies More banks providing supply chain services New Client Referrals for Corporates Corporates will benefit from TSU banks who will have a wider product offering Best practices learned from other TSU banks can be passed on to corporates whose banks are on TSU Buyer: Secure Sellers Supply of Products Seller: ease of financing Buyer: Secure Sellers Supply of Products Seller: easier access to financing Alternative arrangement to get financing Provides holistic view of the open account transaction Reconciles treasury and accounts receivable

Idea Sharing

Bank Payment Obligation Bank Payment Obligation Notice of Intent to Pay Notice of Intent to Pay Risk Sharing More Document Data: Insurance and Certificate Linking Payment With TSU Transaction

Easier for Sellers Bank to Arrange Financing Easier for Sellers Bank to Arrange Financing Helps to Get Credit Approval for Pre-shipment financing Helps to Get Credit Approval for Pre-shipment financing Portfolio/Balance Sheet Management To reflect current business requirement Provides Data Mining Foundation

133 | P a g e