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 characteristics ................................................. ................................................................. ..................... 80 Industry trends ....................................................... ................................................................. ..................... 81 Features & Components:.............................................................. ................................................................ 82 Market infrastructure cash Management .............................................................................. ..................... 84 Cash reporting for financial Institutions.................................................................................. ..................... 86
2|Page
Application models 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 Reviewing Treasury Operations ........................................ .............................................................. ............. 92 Assisting with with the selection selection of a Treasury Workstation Workstation .......................................................... ..................... 92
FX OPTIONS ON ACCORD™ FOR TREASURY ................................................................................................................. 93 Benefits: ...................................................... ................................................................. ................................ 93 How does Accord for Treasury work? ..................................................................................... ..................... 96 96
SWIFT AFFIRMATIONS ........................................................................................................................................ 100 Benefits ....................................................... ................................................................. .............................. 100 100 How SWIFTNet Affirmations works? ................................................................. ......................................... 101 Instruments supported by Affirmations ............................................................ ......................................... 102 SWIFT’S CLS®THIRD PARTY SERVICE ..................................................................................................................... 103 Benefits ....................................................... ................................................................. .............................. 103 103 How SWIFT’s CLS®Third Party Service works? .............................................................. .............................................................. .............................. 104 104 Case Study: TMS Infrastructure ............................................................... ................................................... 105
The business challenge .................................................................................................................................. 105
The technology solution ................................................................................................................................ 105
The activities .................................................................................................................................................. 105
Advice and experience ................................................................................................................................... 106
SECURITIES .................................................................................................................................................. 107 1 07 SWIFT IN THE SECURITIES MARKET ......................................................................................................................... 107 SWIFTNET FIX .................................................................................................................................................. 108 SWIFTNET FUNDS .............................................................................................................................................. 109 Why SWIFTNet Funds? ................................................................................................. .............................. 109 Benefits of using SWIFT ..................................................... ................................................................. ........ 110 110
ACCORD FOR SECURITIES ...................................................................................................................................... 111 Why do I need Accord for Accord for Securities Securities? ? ........................................................................................................ 111 What benefits does Accord for Securities bring? ............................................................................... ........ 111 111 Who can use Accord for Securities? ........................................................................................................... 112 1. Matching of trades between prime brokers and executing brokers ................................... ................... 113 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 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 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 inf rastructures 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 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 en suring its confidentiality and integrity. The opening up of SWIFT to the corporate community has not been without controversy many of SWIFT’s 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 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
9|Page
Traffic 226,435,208
Distribution 66.84%
69,782,890 42,530,731 338,748,829
20.60% 12.56% 100.00%
SWIFT Services SWIFT operates a number of services, primarily: system messages, i.e. Messages 1. General Purpose Application(GPA) - only allows system from a user to SWIFT and vice versa, ve rsa, 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 SWIFT’s 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 s hortest 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 SWIFT’s messaging services through specific system and operating centre enhancements.
2. Messaging zones Distributed architecture allocates traffic to zones. For technical and d ata 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 e xisting 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 SWIFT’s 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 z ones.
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) (bank-to-bank) to his Currency Correspondent (Sender’s Correspondent) Correspondent) Correspondent transfers funds to the Beneficiary Bank’s Currency Correspondent (typically through the local clearing in the instruction currency) Beneficiary Bank’s Correspondent pays fu nds to the Beneficiary Bank country/regional SWIFT service branch SWIFT service branch credits funds to Beneficiary bank branch’s 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. 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 SWIFT’s Relationship Management Application (RMA).
Optional FIN features These can significantly improve your y our 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 (T Copy). 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 institution’s 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: InterAct’s 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 institutions to transfer files in a secure and reliable 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: FileAct’s 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 SWIFT’s 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 e xchanges 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
BB
CC
Bank
Country
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 re leases 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 1 2 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 customer’s 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 co rrectly 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: 20022-1: 2004 and ISO 20022-2:2007 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 b y 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 up on 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 reje ction. 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 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 messages such as the 520 series of messages permit for a maximum message length of 2000 bytes. Statement type messages such as 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 n o 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 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 and "}" are also shown. The letters a,b,c,d, etc., are used in these these examples to identify the constituent parts 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 fundamental referencing of a particular message within an application session of a particular LT. The basic header has the same format for both both input and output messages. 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
BANKBEBBAXXX BANKBEBBAXXX
2222 123456}
1:
Block Identifier
Block identifier for a basic header block is always "1:".
F
Application Identifier
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)
Application Protocol Data Unit Identifier
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).
01
BANKBEBBAXXX LT Address
28 | P a g e
This 12-character SWIFT address, given in the basic header block, is the address of the sending LT (for input messages) or of the
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. 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
123456
29 | P a g e
Session Number
The session number identifies the session in which the message message was transmitted. transmitted. Within the basic header, the session number (four digits) is the user's current GPA or FIN session number. ("0000" - ISITC)
Sequence Number (ISN or OSN)
The sequence number always consists of six digits. It is the ISN of the sender's current current input session or the OSN of the receiver's current output session. ("000001" - ISITC)
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. 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:".
I
Input/Output Identifier
The input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message.
100
Message Type
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).
the 12-character SWIFT address BANKDEFFXXXX Recipient's Address This address is the of the recipient of the message, but with a Logical Terminal Code of "X". "X". If defines the 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: messages: for user-to-user user-to-user messages either "U" or "N" may be used
3
Delivery Monitoring
Delivery monitoring options apply only to FIN user-to-user messages. The chosen option is expressed as a single
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
U
3
003}
Application Header-Output: For output messages, the output application header defines the type of message, who sent it (and ( 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 910103BANKBEBBAXXX2222123456 910103 1201 N}
2:
Block Identifier
The block identifier for an application header block is always "2:".
0
Input/Output Identifier
The input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message.
100
Message Type
The message type consists of three digits which define the MT number of the message being output. The example used above is for for a Customer Transfer (MT 100).
Input Time
The input time (HHMM) is expressed in the sender's local time. time. If the message is a system system message, the input time is the time the message was generated by the system, expressed in Greenwich Mean Time. (GMT)
1200
910103BANK Message Input BEBBAXXX Reference (MIR) 2222123456
32 | P a g e
Every input message is assigned a unique Message Input Reference (MIR). (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 message within the system. The date given in the system MIR is the generation date in GMT.
910103
Output Date
The output date (YYMMDD) is the date local to the receiver.
1201
Output Time
The output time (HHMM) is expressed in the receiver's local time.
Message Priority
The message priority, for FIN messages only, is repeated in the FIN output application header. ("N" - ISITC default, no priority)
N
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 utilized to identify the version of the message standard applicable for processing and v alidating the particular message to which the header applies. It also allows a user to provide his form of reference 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. 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:
33 | P a g e
{108:abcdefgh12345678}}
Block Identifier
The block identifier for a user header block always has the value "3:".
{113:9601}
ISITC Version Identifier
{108:abcdefgh Message User 12345678} Reference (MUR)
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 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.
If an MUR is not specified, the TRN (from field 20: in the text of a user-to-user 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 contained in the TRN were in uppercase. The TRN will never be output as an MUR. 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 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. 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 user or by the system. Trailers always appear in block 5 of a SWIFT message. Each trailer appears as a separate sub block and is bounded by block delimiters. Each trailer begins with a three l etter code, followed by a colon, followed by the trailer information itself. For example, block 5 of a user-to-user 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 with SWIFT use EBCDIC code. The character set is as follows: follows: abcdefghijklmnopqrstuvwxyz 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 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
Customer transfers and cheques
MT2XX
Financial institution transfers
MT3XX
Treasury markets
MT4XX
Collections & cash letters
MT5XX
Securities
MT6XX
Precious metals and syndications
MT7XX
Documentary credits/guarantees
MT8XX
Travellers cheques
MT9XX
Cash management & customer status
MT0XX
System Messages
36 | P a g e
Category 1 – Customer Payments & Cheques MT 101
MT Name Request for Transfer
102 / 102+ Multiple Customer Credit Transfer 103 / 103+ Single Customer Credit Transfer / 103 REMIT 104 Direct Debit and Request for Debit Transfer Message EDIFACT Envelope 105 106 EDIFACT Envelope 107 General Direct Message
Purpose Requests to debit a customer’s account held at another institution Conveys multiple payment instructions between financial institutions Instructs a funds transfer
Conveys direct debit instructions and requests for direct debits between financial institutions An envelope which conveys a 2k EDIFACT message An envelope which conveys a 10k EDIFACT 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 Payment of a Cheque
Requests the drawee bank to stop payment of a cheque
112
Status of a Request for Stop Payment of a Cheque Multiple Interbank Funds Transfer
Indicates action(s) taken in attempting to stop payment of a cheque
121
Contains an EDIFACT FINPAY message
Category 2 – Financial Institution Transfers MT 200
201
202 203
204 205
37 | P a g e
MT Name Financial Institution Transfer for its Own Account Multiple Financial Institution Transfer for its Own Account General Financial Institution Transfer
Purpose Requests the movement of the Sender’s funds to its account at another financial institution Multiple of the MT 200
Requests the movement of funds between financial institutions
Multiple General Financial Institution Transfer Financial Markets Direct Debit Message
Multiple of the MT 202
Financial Institution Transfer Execution
Further transmits a transfer request domestically
Claims funds from SWIFT member banks
206
Cheque Truncation Message
207
Request for Financial Institution Transfer
210
Notice to Receive
Notifies the Receiver that it will receive funds for the Sender’s account
256
Advice of Non-Payment of Cheques
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 d ishonoured items that result in reversing a previous payment settlement
Conveys information on one or more truncated cheques in order to debit or obtain credit under usual reserve Requests to debit an ordering financial institution’s account held at the receiving financial institution or the account servicing financial institution
Category 3 – Treasury Markets – Foreign Exchange, Money Markets & Derivatives MT 300
MT Name Foreign Exchange Confirmation Forex/Currency Option Allocation Instruction
Purpose Confirms information agreed to in the buying/selling of two currencies Instructs the allocation of a block trade (forex or currency option)
304
Advice/Instruction of a Third Party Deal
Advises of or instructs settlement of a third party foreign exchange deal
305
Foreign Currency Option Confirmation
Confirms information agreed to in the buying and selling of vanilla options on currencies
306
Financial Markets Direct Debit Message
Confirms information agreed to in the buying and selling of exotic options on currencies
307
Advice/Instruction of a Third Party FX Deal
Advises of or instructs settlement of a third party foreign exchange deal
308
Instruction for a Gross/Net Settlement of Third Party FX Deals Fixed Loan/Deposit Confirmation
Informs which deals done on behalf of a third party area to be settled gross and which ones netted
321
Instruction to Settle a Third Party Loan/Deposit
Advises the trade details and instructs the settlement of a fixed term loan/deposit done with a third party financial institution
330
Call/Notice Loan/Deposit Confirmation
Confirms the terms of a contract relative to a call/notice loan/deposit transaction
340
Forward Rate Agreement Confirmation
Confirms the details of a forward rate agreement
341
Forward Rate Agreement Settlement Confirmation
Confirms the settlement details of a forward rate agreement
303
320
38 | P a g e
Confirms the terms of a contract relative to a fixed loan/deposit transaction
350
Advice of Loan/Deposit Interest Payment
360
Single Currency Interest Rate Derivative Confirmation
361
Cross Currency Interest Rate Swap Confirmation
Confirms the details of a cross currency interest rate swap transaction
362
Interest Rate Reset/Advice of Payment
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
364
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
365
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
380 381
Foreign Exchange Order Confirmation
Advises of a loan/deposit interest payment Confirms the details of a single currency interest rate derivative swap, cap, collar or floor
Confirms the execution of a FX Order Previously sent
Category 4 – Collection & Cash Letters MT 400
MT Name Advice of Payment
Purpose Advises of a payment under a collection or part thereof. It also handles the settlement of proceeds
405
Clean Collection
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
410
Acknowledgement
Acknowledges receipt of a collection. It also specifies if the collecting bank does not intend to act in accordance with the collection instruction
412
Advice of Acceptance
Informs the remitting bank of the acceptance of one or more drafts under one collection instruction
416
Advice of NonPayment/Non-Acceptance
Advises of the non-payment or non-acceptance under a
39 | P a g e
420 422
Tracer Advice of Fate and Request for Instructions
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
430
Amendment of Instructions Cash Letter Credit Advice
Amends collection instructions
450
Confirms that the face amount of cash letter(s) received has been credited under usual reserve (subject to final payment)
455
Cash Letter Credit Adjustment Advice
Advises the account owner of adjustments made to its account (related to a previous credit for a cash letter)
456
Advice of Dishonour
Advises the account owner that financial document(s) included in the cash letter have been dishonoured for reasons specified in the advice
Category 5 – Securities Markets MT 500
MT Name Instruction to Register
501
Confirmation of Registration or Modification
502
Order to Buy or Sell
503
Collateral Claim
504 505
Collateral Proposal Collateral Substitution
506
Collateral and Exposure Statement
507
Collateral Status and Processing Advice
508
Intra-Position Advice
509
Trade Status Message
510
Registration Status and Processing Advice
40 | P a g e
Purpose Instructs the registration, deregistration or reregistration of a financial instrument at the registration provider Confirms the registration, deregistration or reregistration of a beneficial owner or shareholder with the registration provider Instructs the purchase or sale of a given quantity of a specified financial instrument under specified conditions Requests new or additional collateral, or the return or recall of collateral Proposes new or additional collateral Proposes or requests the substitution of collateral held Provides the details of the valuation of both the collateral and the exposure Advises the status of a collateral claim, a collateral proposal, or a proposal/request for collateral substitution Reports on the movement of securities within the holding Provides information on the status of a previously executed trade Advises the status of a registration instruction or modification
513
Client Advice of Execution
Provides brief and early information about a securities deal, e.g., a block trade that is to be allocated before final confirmation
514 515
Trade Allocation Instruction Client Confirmation of Purchase or Sale
516
Securities Loan Confirmation
Instructs the allocation of a block trade Provides a detailed accounting of financial 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 Confirms the details of a securities loan, including collateral arrangements. It may also confirm the details of a partial recall or return of securities previously out on loan
517
Trade Confirmation Affirmation
Positively affirms the details of a previously received confirmation/contract note
518
Market-Side Securities Trade Confirmation
Confirms the details of a trade and where necessary, its settlement to a trading counterparty
519
Modification of Client Details
Instructs the modification of client details at the registration provider
524
Intra-Position Instruction
526
General Securities Lending/Borrowing Message
527
Tri-party Collateral Instruction ETC Client-Side Settlement Instruction
Instructs the movement of securities within the holding Requests the borrowing of securities or notifies the return or recall of securities previously out on loan. It may also be used to list securities avaliable for lending Performs a specific action on a collateral management transaction Sent by an ETC service provider, it communicates early settlement information to a custodian or clearing agent about a client-side trade
528
529
ETC Market-Side Settlement Instruction
Sent by ETC service provider, it communicates early settlement information to a custodian or clearing agent about a market-side trade
530
Transaction Processing Command
Requests the modification of a processing indicator or other non-matching information.
535
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
536
Statement of Transactions Transactions
Provides details of increases and decreases of holdings which occurred during a specified period
537
Statement of Pending Transaction
Provides details of pending increases and decreases of holdings at a specified time
538
Statement of Intra-Position Advices
Provides details of increases and decreases in securities within the holding during a specified period
41 | P a g e
540
Receive Free
Instructs a receipt of financial instruments free of payment. It may also be used to request re quest a cancellation or pre-advise an instruction
541
Receive Against Payment
Instructs a receipt of financial instruments against payment. It may also be used to request re quest a cancellation or pre-advise an instruction
542
Deliver Free
Instructs a delivery of financial instruments free of payment. It may also be used to request a cancellation or pre-advise an instruction
543
Deliver Against Payment
Instructs a delivery of financial instruments against payment. It may also be used to request re quest a cancellation or pre-advise an instruction
544
Receive Free Confirmation
Confirms a receipt of financial instruments free of payment. It may also be used to cancel or reverse a confirmation
545
Receive Against Payment Confirmation
Confirms a receipt of financial instruments against payment. It may also be used to cancel or reverse a confirmation
546
Deliver Free Confirmation
Confirms a delivery of financial instruments free of payment. It may also be used to cancel or reverse a confirmation
547
Deliver Against Payment Confirmation
Confirms a delivery of financial instruments against payment. It may also be used to cancel or reverse a confirmation
548
Settlement Status and Processing Advice
Advises the status of a settlement instruction or replies to a cancellation request
549
Request for Settlement/Status Advice
Requests a statement or a status message
558
Triparty Collateral Status and Processing Advice
559
Paying Agent’s Claim
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
564
Corporate Action Notification
565
Corporate Action Instruction
566
Corporate Action Confirmation
42 | P a g e
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
567
Corporate Action Status and Processing Advice
568
Corporate Action Narrative
569
Triparty Collateral and Exposure Statement
Provides the details of the valuation of both the collateral and the exposure
574
IRS 1441 NRA-IRS Beneficial Owners’ List
Provides owner or pooled income information for a period of time arranged between the intermediary and the withholding agent
574
IRS 1441 NRA-Form W8BEN
Certifies the foreign status of a beneficial owner for United States tax withholding
575
Report of Combined Activity Activity
Reports on all securities securities and cash activity for a given combination of safekeeping and cash accounts
576
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 ye t been executed
577 578
Statement of Numbers Settlement Allegement
Provides certificates numbers of securities Advises the account owner that a counterparty has alleged a settlement instruction on the account owner’s account
579
Certificate Numbers
Replaces or supplements the ‘certificate numbers’ field in a primary message, eg, MT 577
581
Collateral Adjustment Message
582
Reimbursements Claim or Advice
Claims or notifies a change in the amount of collateral held against securities out on loan or for other reasons Claims reimbursement of funds paid on behalf of 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
584
Statement of ETC Pending Trades
Provides statuses and details of executed trades which are not yet matched nor affirmed
586
Statement of Settlement Allegements
Provides details of pending settlement allegements
587
Depositary Receipt Instruction
Instructs the issuance or release of a depositary receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another
588
Depositary Receipt Confirmation
Confirms the issuance or release of a depositary receipt from/to ordinary shares, or the conversion from one type of depositary receipt to another
589
Depositary Receipt Status and Processing Advice
Advises the status, or change in status, of a depositary receipt
43 | P a g e
Indicates the status, or a change in status, of a corporate action-related transaction previously instructed by, or executed on behalf of, the account owner Provides complex instructions or narrative details relating to a corporate action event
Category 6 – Treasury Markets – Precious Metals MT 600
MT Name Precious Metal Trade Confirmation Precious Metal Option Confirmation
Purpose Confirms the details of a precious metal trade and its settlement Confirms the details of a precious metal option contract
604
Precious Metal Transfer/Delivery Order
Instructs the Receiver to transfer by book-entry, or physically deliver, a specified type and quantity of precious metal to a specified party
605
Precious Metal Notice to Receive
Notifies the Receiver of an impending book-entry transfer or physical delivery of a specified type and quantity of precious metal
606
Precious Metal Metal Debit Advice
Advises the Receiver of of a debit entry to a specified metal account
607
Precious Metal Credit Advice
Advises the Receiver of a credit entry to a specified metal account
608
Statement of a Metal Account Statement of Metal Contracts
601
643
Notice of Drawdown/Renewal
Provides the details of all bookings to a metal account Identifies all outstanding metal contracts, as at a specified date for which confirmations have been exchanged Provides notice of the Borrower(s) request for drawdown(s)/renewal(s) on a given date
644
Advice of Rate and Amount Fixing
Specifies the interest rate and, if applicable, the exchange rate, for the next interest period
645
Notice of Fee Due
646
Payment of Principal and/or of Interest
649
General Syndicated Facility Message
Specifies flat and variable fees, related to one Facility, due to the Receiver Advises of payments and/or prepayments of principal and/or of interest with the same value date, but not related to any subsequent drawing or renewal Provides for communications related to syndicated facilities for which no specific message has been defined
609
Category 7 – Documentary Credits & Guarantees MT 700
MT Name Issue of a Documentary Credit
Purpose Indicates the terms and conditions of a documentary credit
701
Issue of a Documentary Credit
Continuation of an MT 700 for fields 45a, 46a and 47a
44 | P a g e
705
Pre-Advice of a Documentary Credit
Provides brief advice of a documentary credit for which full details will follow
707
Amendment to a Documentary Credit
Informs the Receiver of amendments to the terms and conditions of a documentary credit
710
Advice of a Third Bank’s Documentary Credit
Advises the Receiver of the terms and conditions of a documentary credit
711
Advice of a Third Bank’s Documentary Credit
Continuation of an MT 710 for files 45a, 46 a and 47a
720
Transfer of a Documentary Credit
Advises the transfer of a documentary credit, or part thereof, to the bank advising the second beneficiary
721
Continuation of a MT 720 for files 45a, 46a and 47a
730
Transfer of a Documentary Credit Acknowledgement
732
Advice of Discharge
734
Advice of Refusal
Advises the refusal of documents that are not in accordance with the terms and conditions of a documentary credit
740
Authorisation to Reimburse
Requests the Receiver to honour claims for reimbursement of payment(s) or negotiation(s) under a documentary credit
742
Re-imbursement Claim
Provides a reimbursement claim to the bank authorised to reimburse the Sender or its branch for its payments/negotiations
747
Amendment to an Authorisation to Reimburse
Informs the reimbursing bank of amendments to the terms and conditions of a documentary credit, relative to the authorisation to reimburse
750
Advice of Discrepancy
752
Authorisation to Pay, Accept or Negotiate
Advises of discrepancies and requests authorisation to honour documents presented that are not in accordance with the terms and conditions of the documentary credit Advises a bank which has requested authorisation to 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
754
Advice of Payment/Acceptance/Ne gotiations
45 | P a g e
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 Advises that documents received with discrepancies have been taken up
Advises that documents have been presented in accordance with the terms of a documentary credit and are being forwarded as instructed.
756
Advice of Reimbursement or Payment
Advises of the reimbursement or payment for a drawing under a documentary credit in which no specific reimbursement instructions or payment provisions were given
760
Guarantee/Standby LC
767
Guarantee/ Standby LC Amendment
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
768
Acknowledgement of a Guarantee/ Standby LC Message
Acknowledges the receipt of a guarantee/ Standby LC message and may indicate that action has been taken according to instructions
769
Advice of Reduction or Release
Advises that a bank has been released of its liability for a specified amount under its guarantee
Category 8 – Travellers Cheques MT 800
MT Name T/C Sales and Settlement Advice [Single]
Purpose Provides the sale and settlement details for the sale of travellers cheques by a single selling agent
801
T/C Multiple Sales Advice
802
T/C Settlement Advice
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
810
T/C Refund Request
Requests the issuer to honour a claim for a refund for lost or stolen travellers cheques. It may also request authorisation to refund
812
T/C Refund Authorisation
813
T/C Refund Confirmation
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
820
Request for T/C Stock
Requests replenishment of the selling agent’s travellers cheque stock
821
T/C Inventory Addition
Provides general information regarding a shipment of travellers cheques
822
Trust Receipt Acknowledgement
Acknowledges the receipt of a shipment of travellers cheques from the issuer
823
T/C Inventory Transfer
Advises the issuer of a transfer of specified travellers cheque stock from one selling agent to another
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
MT Name Confirmation of Debit
910
Confirmation of Credit
920
Request Message
935
Rate Change Advice
940
Customer Statement Message
941
Balance Report
942
Interim Transaction Report
950
Statement Message
960
Request for Service Initiation Message Initiation Response Message Key Service Message
961 962
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
963
Key Acknowledgement Message
Acknowledges receipt of the bilateral key sent in a previous MT 962
964
Error Message
Responds to an MT 960, 961, 963, 966 or 967 if an error has been detected to report that error
965
Error in Key Service Message Discontinue Service Message
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
966
47 | P a g e
967
Discontinuation Acknowledgement Message
Acknowledges receipt of a previous MT 966 and confirms discontinuation of the authenticator key(s) specified in the MT 966
970
Netting Statement
Provides balance and transaction details of a netting position as recorded by a netting system
971
Netting Balance Report
Provides balance information for specified netting position(s)
972
Netting Interim Statement
Advises interim balance and transaction details of a netting position as recorded by a netting system
973
Netting Request Message
Requests an MT 971 or 972 containing the latest available information
985 986
Status Enquiry Status Report
Requests an MT 986 Provides business related information about a customer or institution
Category n – Common Group Messages MT n90
MT Name Advice of Charges, Interest and Other Adjustments
n91
Request for Payment of Charges, Interest and Other Expenses
n92
Request for Cancellation
n95
Queries
n96
Answers
n98
Proprietary Message
n99
Free Format Message
48 | P a g e
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
SWIFT MX The SWIFT Standards MX messages are listed according to the business area in which they have been defined.
Account Management MX
MX Name
acmt.001.001.0 2
AccountOpeningInstructionV 02
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
Purpose
The AccountOpeningInstructionV02 AccountOpeningInstructionV02 message instructs the opening of an account or the opening of an account and establishing an investment plan. AccountDetailsConfirmationV The AccountDetailsConfirmationV02 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 AccountModificationInstructionV02 onV02 message instructs the modification of an existing account. GetAccountDetailsV02 GetAccountDetailsV02 The GetAccountDetailsV02 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 AccountManagementStatusReportV02 eportV02 message provides the processing status of a previously received
Administration MX
MX Name
admi.001.001.01 ReportV01
admi.002.001.01 MessageRejectV01
49 | P a g e
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.
SystemEventNotificationV01 nV01 The SystemEventNotificationV01 SystemEventNotificationV01 message admi.004.001.01 SystemEventNotificatio is sent by a central system to notify the occurrence of an event in a central system.
Cash Management MX Identifier
MX Name
Purpose
camt.003.001.03
GetAccountV03
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.
camt.004.001.03
ReturnAccountV03
The ReturnAccountV03 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.
camt.005.001.03
GetTransactionV03
The GetTransactionV03 GetTransactionV03 message is sent by a member to the transaction administrator. It requests information about payment instructions held at the transaction administrator.
camt.006.001.02
ReturnTransactionV03 ReturnTransactionV03
The ReturnTransactionV03 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 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.007.001.02
ModifyTransactionV03
The ModifyTransactionV03 ModifyTransactionV03 message is sent by
50 | P a g e
a member to the transaction administrator. 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.
camt.008.001.03
CancelTransactionV03 CancelTransactionV03
The CancelTransactionV03 CancelTransactionV03 message is sent by a member to the transaction administrator. administrator. It requests the cancellation of one payment instruction held at the transaction administrator and sent by the member.
camt.008.002.02
RequestToCancelPaym ent02
The RequestToCancelPaymentV02 message is sent by a case creator/case assigner to a case assignee. It requests the cancellation of an original payment instruction.
camt.009.001.03
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.
camt.010.001.03
ReturnLimitV03
The ReturnLimitV03 message is sent by the transaction administrator 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.
camt.011.001.03
ModifyLimitV03
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
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).
camt.013.001.01
GetMemberV01
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.
camt.014.001.01
ReturnMemberV01
The ReturnMemberV01 message is sent by the transaction administrator 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.
camt.016.001.01
GetCurrencyExchange RateV01
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.
52 | P a g e
camt.017.001.01
ReturnCurrencyExcha ngeRateV01
The ReturnCurrencyExchangeRateV01 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 ReturnCurrencyExchangeRate message can be sent as a response to a related GetCurrencyExchangeRate 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 ationV01
The GetBusinessDayInformationV01 message is sent by a member to the transaction administrator. It requests information on different types of administrative data linked to the system.
camt.019.001.02
ReturnBusinessDayInf ormationV02
The ReturnBusinessDayInform ReturnBusinessDayInformationV02 ationV02 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 ReturnBusinessDayInfor mation message can be sent as a response to a related GetBusinessDayInformation GetBusinessDayInforma tion 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.020.001.01
GetGeneralBusinessInf The GetGeneralBusinessInform GetGeneralBusinessInformationV01 ationV01 ormationV01 message is sent by a member to the transaction administrator. 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.
camt.021.001.01
ReturnGeneralBusines sInformationV01
53 | P a g e
The ReturnGeneralBusines ReturnGeneralBusinessInformationV01 sInformationV01 message is sent by the transaction administrator to a member of the system. It
provides some or all of the members with information related to the processing of the system. The ReturnGeneralBusinessInformation ReturnGeneralBusinessI nformation message can be sent as a response to a related GetGeneralBusinessInformation GetGeneralBusinessInfor mation 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.
camt.024.001.02
ModifyStandingOrder V02
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.
camt.025.001.01
ReceiptV01
The ReceiptV02 message is sent by the transaction administrator 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.
camt.026.001.02
UnableToApplyV02
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.
camt.027.001.02
ClaimNonReceiptV02
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).
camt.0 camt.028. 28.001 001.02 .02
Additi Additiona onalPa lPaymen ymentIn tInff
The Additi Additiona onalPa lPayme ymentI ntInfo nforma rmatio tionV0 nV02 2
54 | P a g e
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 ionV02
The ResolutionOfInvestigationV02 message is 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.
camt.030.001.02
NotificationOfCaseAssi gnmentV02
The NotificationOfCaseAssignmenV02 NotificationOfCaseAssignmenV02 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.
camt.031.001.02
RejectCaseAssignment V02
The RejectCaseAssignmentV02 message is sent by a case assignee to a case creator/case assigner. It is used to reject a case.
camt.032.001.01
CancelCaseAssignmen t
The CancelCaseAssignment message is sent by a case creator/case assigner to a case assignee. It requests the cancellation of a case.
camt.033.001.02
RequestForDuplicateIn structionV02
The RequestForDuplicateInstructionV02 RequestForDuplicateInstructionV02 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.
camt.034.001.02
DuplicateInstructionV 02
The DuplicateInstructionV02 message is used by financial institutions, with their own office s, and/or with other financial institutions with which they have established bilateral agreements. It allows the exchange of duplicate payment instructions.
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.
camt.037.001.02
DebitAuthorisationRe questV02
The DebitAuthorisationRequestV02 message is sent by an account servicing institution to an account owner. It requests authorisation to debit an account.
camt.038.001.01
CaseStatusReportRequ est
The CaseStatusReportRequest message is sent by a case creator/case assigner to a case assignee. It requests the status of a case.
camt.039.001.02
CaseStatusReportV02 CaseStatusReportV02
The CaseStatusReportV02 CaseStatusReportV02 message is sent by a case assignee to a case creator/case assigner. It reports on the status of a case.
camt.040.001.03
FundEstimatedCashFo recastReportV03
The FundEstimatedCashForecastReportV03 FundEstimatedCashForecastReportV03 message reports the estimated cash incomings and outgoings of one or more investment funds on one or more trade dates.
camt.041.001.03
FundConfirmedCashFo recastReportV03
The FundConfirmedCashForecastReportV03 FundConfirmedCashForecastReportV03 message confirms the cash incomings and outgoings of one or more investment funds on one or more trade dates.
camt.042.001.03
FundDetailedEstimate dCashForecastReportV 03
TheFundDetailedEstimatedCashForecastRepor tV03 message reports the estimated cash incomings and outgoings, sorted by criteria defined by the user of one or more investment funds on one or more trade dates.
camt.043.001.03
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.
camt.044.001.02
FundConfirmedCashFo recastReportCancellati
56 | P a g e
The FundConfirmedCashForecastReportCancellatio
onV02
nV02 message cancels a previously sent FundConfirmedCashForecastReport FundConfirmedCashFore castReport message.
camt.045.001.02
FundDetailedConfirme dCashForecastReportC ancellationV02
The FundDetailedConfirmedCashForecastReportCa ncellationV02 message cancels a previously sent FundDetailedConfirmedCashForecastReport message.
camt.046.001.01
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.
camt.047.001.01
ReturnReservationV01
The ReturnReservationV01 message is sent by a member to the transaction administrator. 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 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.048.001.01
ModifyReservationV0 1
The ModifyReservationV01 message is sent by a member to the transaction administrator. administrator. It requests a modification of details of one or more reservation facilities set by the member and managed by the transaction administrator.
camt.049.001.01
DeleteReservationV01
The DeleteReservationV01 message is sent by a member to the transaction administrator. administrator. It requests a deletion of one or more reservation facilities set by the member and managed by the transaction administrator.
camt.050.001.01
LiquidityCreditTransfe rV01
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
57 | P a g e
being held at the transaction administrator. 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.
camt.052.001.01
BankToCustomerAcco untReportV01
The Bank-to-CustomerAccountReportV01 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.
camt.053.001.01
BankToCustomerState mentV01
The Bank-to-CustomerStatementmessagV01e 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.
camt.054.001.01
BankToCustomerDebit CreditNotificationV01
The Bank-toCustomerDebitCreditNotificationV01 CustomerDebitCreditNot ificationV01 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.
Derivatives MX Identifier
MX Name
Purpose
defp.001.001.01
ContractCreated
The ContractCreated ContractCreated notification message indicates that a contract has been created at the allocation level.
defp.002.001.01
ContractNovated
The ContractNovated ContractNovated message provides the recipient with the latest terms for a full or
58 | P a g e
partial novation of the indicated contract. defp.003.001.01
ContractIncreased
The ContractIncreased ContractIncreased message provides the recipient with the terms for an economic enlargement of the indicated contract.
defp.004.001.01
ContractPartialTerminatio n
The ContractPartialTermination ContractPartialTermination message indicates that a contract has been terminated partially.
defp.005.001.01
ContractFullTermination ContractFullTermination
The ContractFullTermination ContractFullTermination message provides the recipient with the latest terms for a full termination of the indicated contract.
defp.006.001.01
ContractCancelled
The ContractCancelled ContractCancelled notification allows a contract created by mistake to be cancelled entirely.
defp.007.001.01
RequestTradeConfirmatio n
The RequestTradeConfirmation allows a trading party to confirm a trade to its counterparty.
defp.008.001.01
ModifyTradeConfirmation ModifyTradeConfirmatio n
The ModifyTradeConfirmation allows a trading party to modify a trade previously confirmed to its counterparty.
defp.009.001.01
CancelTradeConfirmation CancelTradeConfirmatio n
defp.010.001.01
The CancelTradeConfirmation 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.
defp.011.001.01
ContractIncreasedCancelle The ContractIncreasedCancelled message d notifies the recipient that a ContractIncreased is cancelled.
defp.012.001.01
ContractPartialTerminatio nCancelled
The ContractPartialTerminationCanc ContractPartialTerminationCancelled elled notifies that a ContractPartialTermination ContractPartialTermination is cancelled.
defp.013.001.01
ContractFullTerminationC ancelled
The ContractFullTerminationCancelled ContractFullTerminationCancelled message notifies that a ContractFullTermination ContractFullTermination is cancelled.
Payments Clearing and Settlement MX Identifier
MX Name
Purpose
pacs.002.001.02
PaymentStatusReportV02 PaymentStatusReportV02
The PaymentStatusReportV02 PaymentStatusReportV02 message is
59 | P a g e
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 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.
pacs.004.001.01
PaymentReturnV01
The PaymentReturnV01 message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled.
pacs.006.001.01
PaymentCancellationRequ estV01
The PaymentCancellationR PaymentCancellationRequestV01 equestV01 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.
pacs.007.001.01
FIToFIPaymentReversalV0 1
The FIToFIPaymentReversalV01 message is sent by an agent to the next party in the payment chain. It reverses a payment previously executed.
pacs.008.001.01
FIToFICustomerCreditTran sferV01
The FIToFICustomerCreditTransferV01 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.
pacs.009.001.01
FinancialInstitutionCreditT ransferV01
The FinancialInstitutionCreditTransfer 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.
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.
pain.002.001.02
PaymentStatusReportV02 PaymentStatusReportV 02
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.
pain.006.001.01
PaymentCancellationRequest V01
The PaymentCancellationRequ PaymentCancellationRequestV01 estV01 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.007.001.01
CustomerPaymentReversalV0 1
The CustomerPaymentReversalV01 CustomerPaymentReversalV01 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 CustomerDirectDebitInitia CustomerDirectDebitInitiationV01 tionV01 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
MX Name
reda.001.001.03
PriceReportV03
reda.002.001.03
PriceReportCance llationV03
61 | P a g e
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.003.001.03
PriceReportCorre ctionV03
The PriceReportCorrectionV03 message corrects specific price information included in a previously sent PriceReport message.
Securities Events MX Identifier
MX Name
Purpose
seev.001.001.01
MeetingNotificatio nV01
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 nV01
The MeetingCancellationV01 message is sent by the party that sent the MeetingNotification Me etingNotification message to the original receiver. It is sent to cancel the previous MeetingNotification message previously sent or to advise the cancellation of a meeting.
seev.003.001.01
MeetingEntitlemen tNotificationV01
The MeetingEntitlementNotificationV01 message is 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.
seev.004.001.01
MeetingInstruction V01
seev.005.001.01
MeetingInstruction CancellationReque stV01
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 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 o riginal the MeetingInstruction message.
seev.006.001.01
62 | P a g e
MeetingInstruction StatusV01
The MeetingInstructionStatusV01 MeetingInstructionStatusV01 message is sent by the Receiver of the MeetingInstruction or
MeetingInstructionCancellationRequest to the Sender MeetingInstructionCancellationRequest of these messages. The message gives the status of a complete me ssage 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 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
MX Name
semt.001.001.02
SecuritiesMessage RejectionV02
semt.002.001.02
CustodyStatement OfHoldingsV02
semt.003.001.02
AccountingStatem entOfHoldingsV02
semt.004.001.02
CustodyStatement OfHoldingsCancella tionV02
semt.005.001.02
AccountingStatem entOfHoldingsCanc
63 | P a g e
Purpose The SecuritiesMessageRejectionV02 message rejects a previously received message on which action cannot be taken. The CustodyStatementOfHoldingsV02 CustodyStatementOfHoldingsV02 message provides detailed quantity and availability information for financial instrument holdings of a portfolio. The AccountingStatementOfHoldingsV02 AccountingStatementOfHoldingsV02 message provides valuation detail The CustodyStatementOfHoldingsCancellationV0 CustodyStatementOfHoldingsCancellationV02 2 message cancels a previously sent CustodyStatementOfHoldings message. The AccountingStatementOfHoldingsV02 AccountingStatementOfHoldingsV02 message cancels a previously sent AccountingStatementOfHoldings AccountingStatementO fHoldings message.
ellationV02 semt.006.001.02
StatementOfInvest mentFundTransacti onsV02
semt.007.001.02
StatementOfInvest mentFundTransacti onsCancellationV0 2
semt.008.001.01
RegulatoryTransact ionReport
semt.009.001.01
RegulatoryTransact ionReportCancellat ionRequest
semt.010.001.01
RegulatoryTransact ionReportStatus
semt.011.001.01
RegulatoryTransact ionReportCancellat ionStatus
The StatementOfInvestmentFundTransactions StatementOfInvestmentFundTransactionsV02 V02 message reports detailed transactions (increases and decreases) of holdings which occurred during a specified period of time. The StatementOfInvestmentFundTransactionsCancellation V02 message cancels a previously sent StatementOfInvestmentFundstransactions StatementOfInvestment Fundstransactions message. The RegulatoryTransactionReport message reports the transaction details of securities trades that have been executed on or off-exchange. The RegulatoryTransactionReportCancellatio RegulatoryTransactionReportCancellationRequest nRequest message is used to request the cancellation of one or more or all previously sent individual transactions reports. The RegulatoryTransactionReportStatus RegulatoryTransactionReportStatus message is used to provide the status of one or more or all previously received individual transactions reports. The RegulatoryTransactionReportCancellatio RegulatoryTransactionReportCancellationStatus nStatus message is used to provide the status of one or more or all previously received individual transactions reports cancellations requests.
Securities Settlement MX Identifier sese.001.001.02
sese.002.001.02
sese.003.001.02
sese.004.001.02
sese.005.001.02
64 | P a g e
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 TransferOutCancellationRequestV02 message ationRequestV02 requests the cancellation of a previously sent TransferOutInstruction TransferOutInstruction message. TransferOutConfir The TransferOutConfirmationV02 message confirms mationV02 the execution of a previously received TransferOutInstruction TransferOutInstruction message. ReversalOfTransfer The ReversalOfTransferOutConfirmationV02 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.006.001.02
TransferInCancellat ionRequestV02
sese.007.001.02
TransferInConfirma tionV02
sese.008.001.02
ReversalOfTransfer InConfirmationV02
sese.009.001.02
RequestForTransfe rStatusReportV02
sese.010.001.02
TransferCancellatio nStatusReportV02
sese.011.001.02
TransferInstruction StatusReportV02
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
65 | P a g e
account, either owned by the instructing party or by a third party. The TransferInCancellationRequestV02 message requests the cancellation of a previously sent TransferInInstruction TransferInInstruction essage. The TransferInConfirmationV02 message confirms the execution of a previously received TransferInInstruction message. The ReversalOfTransferInConfirmationV02 ReversalOfTransferInConfirmationV02 message reverses (cancels) a previously sent TransferInConfirmation essage. The RequestForTransferStatusReportV02 RequestForTransferStatusReportV02 message requests the status of a previously instructed transfer or the status of a reviously sent cancellation of transfer request. The TransferCancellationStatusReportV02 TransferCancellationStatusReportV02 message reports the status of a transfer in or transfer out cancellation request. The TransferInstructionStatusReportV02 TransferInstructionStatusReportV02 message reports the status of a previously received TransferInInstruction TransferInInstruction or TransferOutInstruction TransferOutInstruction message. The PEPOrISAOrPortfolioTransferInstructionV0 PEPOrISAOrPortfolioTransferInstructionV02 2 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 PEPOrISAOrPortfolioTransferConfirmationV0 PEPOrISAOrPortfolioTransferConfirmationV02 2 message confirms the execution of a previously received PEPOrISAOrPortfolioTransferInstruction PEPOrISAOrPortfolioTra nsferInstruction message. The message may be used to confirm the execution of one, many or all transfers contained in a previously received PEPOrISAOrPortfolioTransfer PEPOrISAOrPortfolioTra nsfer message. The PEPOrISAOrPortfolioTransferCancellationRequestV02 message requests the cancellation of a previously sent PEPOrISAOrPortfolioTransferInstruction PEPOrISAOrPortfolioTra nsferInstruction message. The message requests the cancellation of all transfer instructions contained within a previously sent PEPOrISAOrPortfolioTransferInstruction PEPOrISAOrPortfolioTra nsferInstruction message. The PEPOrISAOrPortfolioInformationV01 message provides
sese.019.001.01
RequestForPEPOrIS AOrPortfolioInform ationV01
information about one or more PEP or ISA or portfolio products held in a client's account. The RequestForPEPOrISAOrPortfolioInformatio RequestForPEPOrISAOrPortfolioInformationV01 nV01 message requests information about one or more PEP 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
setr.002.001.03
RedemptionBulkOr derCancellationReq uestV03
setr.003.001.03
RedemptionBulkOr derConfirmationV0 3
setr.004.001.03
RedemptionOrderV 03
setr.005.001.03
RedemptionOrderC ancellationRequest V03
setr.006.001.03
RedemptionOrderC onfirmationV03
66 | P a g e
Purpose The RedemptionBulkOrderV03 message bulks several individual redemption orders for one financial instrument into one bulk order for multiple accounts. The RedemptionBulkOrderCancellationRequestV03 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 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 RedemptionOrderCanc RedemptionOrderCancellationRequestV03 ellationRequestV03 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 RedemptionOrderConfirmationV03 message confirms the execution of a previously pre viously received RedemptionOrder message. The message may confirm the execution of one, many or all redemption orders contained in a
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
67 | P a g e
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 SubscriptionBulkOrderCancellationReq SubscriptionBulkOrderCancellationRequestV03 uestV03 derCancellationReq message uestV03 requests the cancellation of a previously sent SubscriptionBulkOrder. SubscriptionBulkOrder. The message may request the cancellation of one, many or all subscription orders contained in a previously received SubscriptionBulkOrder message. SubscriptionBulkOr The SubscriptionBulkOrderConfirmationV03 SubscriptionBulkOrderConfirmationV03 message derConfirmationV0 confirms the execution of a previously received 3 SubscriptionBulkOrder SubscriptionBulkOrder message. The message may confirm the execution of one, many or all subscription orders contained in a previously received SubscriptionBulkOrder SubscriptionBulkOrder message. SubscriptionOrder The SubscriptionOrderV03 message instructs the V03 subscription of one or more financial instruments for one investment fund account. SubscriptionMultip The SubscriptionOrderCancellationRequestV03 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 SubscriptionOrderConfirmationV03 message onfirmation V03 confirms the execution of a previously pre viously 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
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
68 | P a g e
instruments for a specified amount/quantity. SwitchOrderCancel The SwitchOrderCancellationRequestV03 SwitchOrderCancellationRequestV03 message lation RequestV03 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 OrderInstructionStatusReportV03 message atusReportV03 reports the status of a subscription, redemption or switch order prior to execution. OrderCancellationS The OrderCancellationStatusReportV03 OrderCancellationStatusReportV03 message tatusReportV03 reports the status of an order cancellation request that was previously received. RequestForOrderSt The RequestForOrderStatusReportV03 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 SubscriptionOrderConfirmationAmendment SubscriptionOrderConfirmationAmendmentV01 V01 onfirmationAmend message amends a previously sent mentV01 SubscriptionOrderConfirmation SubscriptionOrderConfir mation 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
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
69 | P a g e
SubscriptionBulkOrderConfirmation SubscriptionBulkOrderConfirmation message. RedemptionOrderC The onfirmationCancell RedemptionOrderConfirmationCancellationInstructio ationInstructionV0 nV01 1 message cancels one or more previously sent redemption order confirmations. RedemptionOrderC The RedemptionOrderConfirmationAmendmentV RedemptionOrderConfirmationAmendmentV01 01 onfirmationAmend message amends a previously sent mentV01 RedemptionOrderConfirmation RedemptionOrderConfirma tion message. RedemptionBulkOr The derConfirmationCa RedemptionBulkOrderConfirmationCancellationInstru ncellationInstru ctio ctionV01 nV01 message cancels a previously sent RedemptionBulkOrderConfirmation. RedemptionBulkOrderCo nfirmation. The message may be used to cancel one, many or all redemption order confirmations contained in a previously sent RedemptionBulkOrderConfirmation RedemptionBulkOrderCo nfirmation message. RedemptionBulkOr The derConfirmationA RedemptionBulkOrderConfirmationAmendmentV01 mendmentV01 message amends a previously sent RedemptionBulkOrderConfirmation RedemptionBulkOrderCo nfirmation message. SwitchOrderConfir The mationCancellation SwitchOrderConfirmationCancellationInstructionV01 InstructionV01 message cancels one or more previously sent switch order confirmations. SwitchOrderConfir The SwitchOrderConfirmationAmendmentV01 SwitchOrderConfirmationAmendmentV01 mationAmendmen message tV01 amends a previously pre viously sent SwitchOrderConfirmation message OrderConfirmation The OrderConfirmationStatusReportV01 OrderConfirmationStatusReportV01 message StatusReportV01 reports the status of an order confirmation or an order confirmation amendment. RequestForOrderC The RequestForOrderConfirmationStatusReport RequestForOrderConfirmationStatusReportV01 V01 onfirmationStatusR message requests the status of one or several order eportV01 confirmations.
Treasury MX Identifier
MX Name
Purpose
trea.006.001.02
CancelNonDelivera bleForwardValuati on V02
The CancelNonDeliverableForwardVa CancelNonDeliverableForwardValuationV02 luationV02 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.
trea.007.001.02
NonDeliverableFor wardNotification V02
The NonDeliverableForwardNotificationV02 message is sent by a central system to a participant to provide details of a non deliverable forward trade.
trea.008.001.02
StatusNotificationV 02
The StatusNotificationV02 StatusNotificationV02 message is sent by a central system to a participant to notify the current status of a foreign exchange option trade in the system.
trea.009.001.02
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.
trea.010.001.02
AmendForeignExch angeOption V02
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.
trea.011.001.02
CancelForeignExch angeOption V02
The CancelForeignExchangeOptionV02 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.
trea.012.001.02
ForeignExchangeO ptionNotification V02
The ForeignExchangeOptionNotificationV02 ForeignExchangeOptionNotificationV02 message is sent by a central system to a participant to notify the current status of a trade in the system.
trea.013.001.01
WithdrawalNotifica tionV01
The WithdrawalNotificationV01 message is sent by a 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
MX Name
Purpose
tsmt.001.001.02
Acknowledgement V02
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.
tsmt.002.001.02
ActivityReportV02
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.003.001.02
ActivityReportRequ estV02
The ActivityReportRequestV02 message is sent by 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.
tsmt.004.001.01
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.005.001.01
AmendmentAccept ance
The AmendmentAcceptance message is sent by the party requested to accept or reject an amendment to the matching application. It accepts an amendment request.
tsmt.006.001.02
AmendmentAccept anceNotificationV0 2
The AmendmentAcceptanceNotificationV02 AmendmentAcceptanceNotificationV02 message is sent by the matching application to the requester of an amendment. It notifies the acceptance of an amendment request.
tsmt.007.001.01
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.
tsmt.008.001.02
AmendmentRejecti onNotificationV02
The AmendmentRejectionNotificationV02 message is sent by the matching application to the requester of an amendment. It notifies the rejection of an amendment request.
tsmt.009.001.02
BaselineAmendme ntRequestV02
The BaselineAmendmentRequestV02message is sent by either party involved in a transaction to the matching application. It requests the amendment of an established baseline.
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 (InitialBaselineSubmissio n message, BaselineReSubmission message).
tsmt.011.001.02
BaselineReportV02
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.
tsmt.012.001.02
BaselineReSubmiss ionV02
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.013.001.02
DateSetMatchRepo rtV02
The DataSetMatchReportV02 message is sent by the 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 (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.
tsmt.014.001.02
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.
tsmt.015.001.02
DeltaReportV02
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.
tsmt.016.001.02
ErrorReportV02
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
72 | P a g e
matching application to process a received message. tsmt.017.001.02
ForwardDataSetSu bmissionReportV0 2
The ForwardDataSetSubmissionReportV02 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.
tsmt.018.001.02
FullPushThroughRe portV02
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 InitialBaselineSubmissio n or BaselineReSubmission or BaselineAmendmentRequest message.
tsmt.019.001.02
InitialBaselineSub missionV02
The InitialBaselineSubmissionV02 message is sent by the initiator of a transaction to the matching application. It initiates a transaction.
tsmt.020.001.01
MisMatchAcceptan ce
The MisMatchAcceptance message is sent by the party requested to accept or reject data set mismatches to the matching application. It accepts mismatches between data sets and the related baseline.
tsmt.021.001.02
MisMatchAcceptan ceNotificationV02
The MisMatchAcceptanceNotificationV02 MisMatchAcceptanceNotificationV02 message is sent by the matching application to the submitter of mis-matched data sets. It notifies the acceptance of mis-matched data sets.
tsmt.022.001.01
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.
tsmt.023.001.02
MisMatchRejection NotificationV02
The MisMatchRejectionNotificationV02 message is sent by the matching application to the submitter of mis-matched data sets. It notifies the rejection of mismatched data sets.
tsmt.024.001.02
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.
tsmt.025.001.02
StatusChangeNotifi cationV02
The StatusChangeNotificationV02 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.
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.
tsmt.027.001.01
StatusChangeRequ estAcceptance
The StatusChangeRequestAcceptance 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.
tsmt.028.001.02
StatusChangeRequ estNotificationV02
The StatusChangeRequestNotificationV02 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.
tsmt.029.001.01
StatusChangeRequ estRejection
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.
tsmt.030.001.02
StatusChangeRequ estRejectionNotific ationV02
The StatusChangeRequestRejectionNotifica StatusChangeRequestRejectionNotificationV02 tionV02 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.031.001.02
StatusExtensionAcc eptanceV02
The StatusExtensionAcceptanceV02 StatusExtensionAcceptanceV02 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 acceptance of a request to extend the status of a transaction.
tsmt.032.001.02
StatusExtensionNo tificationV02
The StatusExtensionNotificationV02 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.
tsmt.033.001.02
StatusExtensionRej ectionV02
The StatusExtensionRejectionV02 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.034.001.02
StatusExtensionRej ectionNotificationV
The StatusExtensionRejectionNotificatio StatusExtensionRejectionNotificationV02 nV02 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.
tsmt.035.001.02
StatusExtensionRe questV02
The StatusExtensionRequestV02message StatusExtensionRequestV02message is sent by either party involved in a transaction to the matching application. It requests the extension of the status of a transaction.
tsmt.036.001.02
StatusExtensionRe questNotificationV 02
The StatusExtensionRequestNotificationV StatusExtensionRequestNotificationV02 02 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.
tsmt.037.001.02
StatusReportV02
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.038.001.02
StatusReportReque stV02
The StatusReportRequestV02 message is sent by either party involved in a transaction to the matching application. It reports on the status of transactions registered in the matching application.
tsmt.039.001.02
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.
tsmt.040.001.02
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.
tsmt.041.001.02
TransactionReport V02
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.
tsmt.042.001.02
TransactionReport RequestV02
The TransactionReportRequestV02 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.
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: SWIFT’s single windo w allows you to rationalise your connectivity channels with: 1. Correspondent banks for clearing and settlement of d omestic or foreign currency payments using SWIFT’s payments clearing messaging services 2. High value payments clearing and/or settlement systems operating on a realtime gross settlement basis using SWIFT’s secure and reliable FIN domestic services for high value payment market infrastructures 3. Retail payments clearing systems using SWIFT’s cost efficient services for retail payments market infrastructures: infrastructures: the services help to clear “batches” of payments prior to settlement at discrete intervals, with or without ne tting.
SWIFT Application in Cash Management 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 SWIFT’s 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 SWIFT’s 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 20 022) 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 SWIFT’s Cash Reporting solution responds to the need to exchange re altime 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. management: Increase accurate measurement of global settlement — Improved risk management: 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 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 b een increasing industry interest in real-time information delivery in wholesale banking. This started with payment clearing systems’ requirements and has s pread 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, delive ry 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. SWIFT’s 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 se rvers from the user’s 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 SWIFT’s 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 today’s 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 SWIFT’s Easy E&I solution, c ombined 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 no t 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 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 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. SWIFT’s Accord for Securities service builds on Accor d 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 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 SWIFT’s 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 SWIFT’s 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 Accord’s 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 SWIFT’s 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 SWIFT’s 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 e ase. — 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 Treasury’s XML -based API enables institutes to feed fe ed 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 enable s 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
Accord’s 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 institution’s 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’ ‘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 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, confirmations, either generically or from specific counterpartie counterparties.“Even s.“Even for com plex FX options SWIFT takes financial liability for every duo of messages Accord has declared matched” Handling exceptions: managing the workflow Accord’s 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.
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.
Accord’s free Test and
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 Accord’s 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 Accord’s 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 today’s market environment. SWIFT’s 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, e nabling 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. infrastructure. It uses SWIFTNet PKI for authentication, access control and no repudiation. — It is easy to install, requiring only an Alliance WebStation with the Affirmation’s 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 SWIFT’s 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
SWIFT’s CLS®Third 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 SWIFT’s CLS®Third 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 me mber 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 o ne 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 system’s security requirements. In addition to security concerns, daily processes for retrieving statements and making payments through multiple statements were manual and e xtremely 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 Fr ance 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 and experience experience
These were advices of SWIFT project which was still in its relatively e arly 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. d ifficult to establish our total — Although the SWIFT project costs are not high, it was difficult 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 en gaged 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 rev iew these processes and see how they could be enhanced. e nhanced.
106 | P a g e
Securities SWIFT in the securities market Over the course of SWIFT’s 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. 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. SWIFT’s 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 ele ctronic securities trading is growing. Increasingly the Financial Information Exchange (FIX) protocol is the means that the financial community is using for electronic trading. SWIFTNet, SWIFT’s 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 SWIFT’s messaging solution delivering automation and 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 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
Why SWIFTNet Funds?
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
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
SWIFT’s 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 SWIFT’s Accord for Securities was initially developed to support SWIFT’s 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 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 platf orm. 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 pre-
settlement matching services provided by the local settlement agents. This creates unnecessary costs and risk. Using Accord for Securities, Se curities, 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 unterparty to the trade – automating the process and reducing costs and risk. the count Any type of institution that wants to replace faxes with automated electronic confirmations can benefit f rom this solution.
What benefits does Accord for Securities bring? Accord for Securities offers offers a single, central central matching solution for the entire community. community. Existing Accord customer customerss can re-use their existing investme i nvestment nt in Acc Accord ord,, SWIFT SWIFT connectivity and SWIFT messages to quickly and easily take advantage of Accord for Securities.
The solution addresses the needs of prime brokers by: —Im pr o vi n g the timeli timeliness ness of the the pre-sett pre-settlement lement 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 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 in dividual 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 t he executing broker’s 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
br okers 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 close a deal to trade 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 broker’s 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, o r 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 settlem ent 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 counterparty’s 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 ope rates 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
1831
1800 1577
1600 1400
1422
1355
1350 1210 1100
1200 930
1000 800 600 400 200
43
44
43
47
47
46
47
48
0 2000
2001
2002
2003
Trad Trade e SWIF WIFT Volum olumes es
2004
2 005
2 006
2 0 07
Paym Paymen entt SWIF SWIFT T Volu Volum mes
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 se lling process is the same cycle from the supplier’s 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 y ears, 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 b ased. 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 re alise 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, managi ng 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 en ables 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 seller’s 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 – Buyer’s and Seller’s Bank send the PO to TSU. TSU sends back match or mismatch. 2. Dataset – Seller’s b ank 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 p rocessing 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 corporate’s 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
Landed Costs Management
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.
Discrepancy Management
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.
Others
E.g. Contract management (matching data to contract to support payment); shipper visibility (data aggregation services built around visibility).
Risk Management
FX Hedging
Monitoring of transaction data enables a central treasury function to an ticipate 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.
Authenticated Purchase Order
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 n o apparent reason why payment should be refused provided performance occurs.
Compliance
Matched data can be fed into a bank’s 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.
Others
E.g. LC support (a preliminary data set match highlighting exceptions enables a bank to accelerate internal decision-making processes; c ollection 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).
128 | P a g e
In Sourcing Services
Document Preparation
Generation of shipping documents based on data received from corporate purchase order systems.
Data Matching Data Bureau
Reconciliation of accounts payable/receivable. If banks have visibility of purchase p urchase order and other supply chain data, they can begin to track and provide reports and analyses on supplier performance
Services
as a value-added service. This information may be relevant to buyer/seller relationships, price negotiations, dispute resolution, consolidation policy, etc.
Others
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 seller’s 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 buyer’s bank to provide non -recourse finance or early payment to a supplier. These faci lities may be linked to inventory in Finance transit, proof of delivery (e.g. a forwarder’s 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.
Others
E.g. Forfaiting (supplier’s bank discounts without recourse bills of exchange drawn on the buyer based on the guarantee of the buyer’s bank); asset securitisation (dependent upon the individual bank’s credit policy, enhanced cash flow forecasting could enable the purchase of receivables at a low and quantifiable risk).
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
Benefit to Bank
Benefit to Corporate
Data Matching
Handling Exceptions only
Earlier Detection of Discrepancies
Utility Approach
Lower Barrier to Market Entry
More banks providing supply chain services
New Client Referrals
Referrals from other TSU banks
New Client Referrals for Corporates
Defend Own Clients
Ability to Offer Supply Chain Services will help to retain clients
Corporates will benefit from TSU banks who will have a wider product offering
Idea Sharing
TSU banks can share best practices
Best practices learned from other TSU banks can be passed on to corporates whose banks are on TSU
Bank Payment Obligation
Easier for Seller’s Bank to Arrange Financing
Buyer: Secure Seller’s Supply of Products
Bank Payment Obligation Notice of Intent to Pay
Easier for Seller’s Bank to Arrange Financing Helps to Get Credit Approval for Pre-shipment financing
Seller: ease of financing
Notice of Intent to Pay Risk Sharing
Helps to Get Credit Approval for Pre-shipment financing Portfolio/Balance Sheet Management
More Document Data: Insurance and Certificate Linking Payment With TSU Transaction
To reflect current business requirement
Alternative arrangement to get financing Provides holistic view of the open account transaction
Provides Data Mining Foundation
Reconciles treasury and accounts receivable
133 | P a g e
Buyer: Secure Seller’s Supply of Products Seller: easier access to financing
