Chapter 11
Communications Between Industry Participants
In Chapter 9 we learned that the principles of STP apply not just within the firm but also between the various firms involved in the transaction. In order to achieve STP individual firms have to be able to automate communications between other firms and other types of industry participants. This requires mutually agreed standards for the contents of messages as well as network facilities to transmit and receive these messages. All the world’s investment exchanges and settlement agents provide proprietary facilities of this kind and publish application programming interfaces (APIs) that detail how to interact with these applications.
As well as these proprietary systems there are a number of open systems that are used widely in the investment industry. Some of them are specific to some areas of the industry, such as individual instruments or individual stages in the trade cycle. There is, however, one standard, the SWIFT standard, that is used by all types of industry participants for most instrument types and at all stages of the trade cycle. Section 11.1 examines the role of SWIFT in detail.
In 1992 several industry participants set up the FIX standard, which is also widely used in the pre-settlement phases of the trade cycle. The FIX Protocol is examined in section 11.2. Other message standards are covered in section 11.3.
11.1 SWIFT
11.1.1 Introduction
The Society for Worldwide Interbank Financial Telecommunication (SWIFT) was founded in 1973, with the mission of creating a shared worldwide data processing and communications link together with a common language for international financial transactions. This was an ambitious project that had the backing of 239 banks in 15 countries.
The next few years were spent defining the message standards and building a secure store and forward telecommunications network. The first SWIFT message was sent in 1977.
Originally, SWIFT services were only available to firms that were regulated as banks, and the message standards only related to foreign exchange, money markets and interbank transfers. The first securities-related message standards were introduced in 1987, and membership was not offered to non-bank investment firms and fund managers until 1992.
By 2007 there were 2792 SWIFT participants in 208 countries, exchanging over 2.2 billion messages annually, growing at an annual rate of 21.3%. On 31 July 2007 a record number of 15912693 messages were sent.
SWIFT now offers standard messages that support all stages of the transaction lifecycle for most instrument classes. The only instrument class where SWIFT does not have significant market share is exchange-traded futures and options, where the proprietary message formats of the various exchanges and clearing houses are dominant.
By business type, the breakdown of these messages is shown in Figure 11.1.
Figure 11.1 SWIFT message volume analysis
11.1.2 SWIFT connectivity
SWIFT connectivity is based on the presence of:
1. A secure IP-based network
2. SWIFTnet Link software that provides security and ensures interoperability between users
3. The store and forward principle
The secure IP-based network
This is a highly secure telecommunications network that, since 2005, has been based on the IP protocol; which in turn is the set of communications protocols that implement the protocol stack on which the Internet runs. It is sometimes called the TCP/IP protocol suite, after the two most important protocols in it: the Transmission Control Protocol (TCP) and the Internet protocol suite (IP), which were also the first two defined.
SWIFTnet Link
SWIFTnet Link is a suite of software products that ensures technical interoperability between users by providing the functionality required to communicate over these services. It is licensed both to SWIFT member firms directly, and also to software vendors who are able to embed it in their own products. When SWIFT supplies it directly, it is embedded in a packaged software application called SWIFTAlliance™. Both Windows and UNIX platforms are supported by SWIFTnet Link. SWIFTAlliance and the third party products that compete with it are often referred to as SWIFT Gateway Systems.
SWIFTnet Link incorporates a set of XML-based application programming interfaces (APIs) which enable communication with SWIFT services. One of the most important components is SWIFTnet PKI.
SWIFTnet PKI
SWIFTnet PKI is the part of SWIFTnet Link that provides the security layer. When a firm agrees with another firm that they will send and/or receive SWIFT messages with one another, the first thing that they do is to exchange authenticator keys with one another, using the SWIFT network for this purpose. Authenticator keys encrypt the outgoing message, and ensure that only the recipient that it was intended for is able to de-encrypt it. SWIFTnet PKI uses digital certificates to provide the highest levels of authentication of institutions, end-users and servers. Digital certificates convey the trust between institutions and SWIFT as the trusted third party. SWIFTnet PKI is additional to the network security provided on the protocol and the connection level.
Key exchange ensures:
- Authenticity: Correspondents are guaranteed the identity of the originator of any instruction, statement, query or response. By verifying the signature, the receiver of a message can confirm that the sender specified in the header of the message the private key used for signing the message.
- Integrity: Correspondents are guaranteed that the data they receive exactly matches the original as produced by the sender. By verifying the signature the receiver of a message can confirm that the message content has not been changed during transmission.
- Non-repudiation: Correspondents are able to prove that the claimed originator has effectively signed the message, as it can be proved that the originator is the sole owner of the unique signing key needed to produce the digital signature.
- Confidentiality: The message-level encryption guarantees that only the intended recipient can read and interpret the data as it can be proved that the originator is the sole owner of the unique decryption key.
- Access control: The access for an individual to his or her private key stored in a smart card is controlled through a private password.
The store and forward principle
SWIFT connectivity is based on the store and forward principle. This is a communications technique in which messages are sent to an intermediate station where they are kept and sent at a later time to the final destination or to another intermediate station. Reasons for using this method include:
- Origin and destination stations may not be available for communications at the same time. This, in turn, could be because of:
– Time zone differences between the sender and the recipient
– The sender’s country and the recipient’s country have different working days and/or public holidays
– The recipient’s systems are not working due to hardware failure, software failure or “disasters” such as earthquake, civil unrest, etc.
- One or more circuits may not have enough capacity for peak traffic and there is a need to give priority to certain messages, without losing the others.
Interaction of the firm’s systems with the SWIFT network
Figure 11.2 shows the interaction between the sending firm’s systems, the SWIFT network and the receiving firm’s systems. The assumptions are that the sending firm is based in London, and is generating settlement instructions to be sent to a settlement agent in Tokyo. Tokyo is, of course, in a different time zone and uses a different public holiday calendar to London.
Figure 11.2 Swift message flow between participants
At the sending firm
1. Trades are captured in the relevant front-office system, and forwarded to the firm’s settlement system.
2. The settlement system enriches the trade with SSI details and any other relevant static data, and formats a settlement instruction message. This, in turn, is forwarded to the firm’s SWIFT Gateway application, where:
- The Gateway product validates the trade according to SWIFT’s network validation rules, which deal with field specifications (e.g. whether alpha or numeric content is required, whether fields are mandatory or optional, etc.) If a message fails validation then it is sent to a repair queue.
- The Gateway product provides facilities for manual authorisation of this instruction before it is sent out. The firm is able to set up business rules in the Gateway product to control policies that determine whether or not manual authorisation is required for different types and values of instruction.
- The Gateway product allows direct input through a user interface, shown in the figure. This allows users to set up business rules in the Gateway product, manually authorise transactions and repair transactions when necessary.
- Once the message has been validated and authorised it is then encrypted, and then sent to SWIFT. The message will, in fact, be received at one of SWIFT’s European hubs (there is more than one of these for business resilience reasons) but this fact is transparent to the sender.
At SWIFT
1. The message is received at the European hub, and time stamped with the date and time of receipt.
2. It is then network validated. If network validation is successful, the SWIFT sends an ACK (meaning acknowledged) message back to the sender confirming that it is able to process the message. If the message fails network validation, then SWIFT sends a NACK (not acknowledged) message back to the sender. This process is known as the ACK/NACK protocol.
3. SWIFT identifies that this message is destined for a firm in Tokyo, so it forwards it to one of its Asia Pacific hubs in real time.
4. The Asia Pacific hub then verifies whether the Tokyo firm is online to SWIFT. If it is, it forwards it to the member; if the member is not online it stores the message until it detects that the member has come online.
At the receiving firm
1. The message is received at this member firm’s Gateway system and de-encrypted.
2. The Gateway system then uses business rules that have been set up in this system to tell it what to do with the message. For example, if it is a settlement instruction message sent by one of the firm’s custody clients it may need to be forwarded to one business application; if it is an FX trade confirmation sent by a counterparty it might need to be forwarded to another business application.
3. There will be some messages where the identity of the destination system will not be clear to the Gateway system. This may be due to the quality of the data in the incoming message, lack of clarity and coverage in the business rules entered into the gateway system, or for some other reason. For this reason Gateway systems provide a human interface that incorporates the ability to display messages held in a repair queue and manually deal with them, as well as the ability to input the business rules in the first place.
11.1.3 SWIFT message standards
SWIFT devises agreed standards for the content, sequence and validation rules for the messages used by its members. It does this by a process of consultation with its member firms and the various trade associations that they belong to. Once SWIFT has confirmed a standard, then this standard is then adopted by the International Standards Organisation (ISO). The ISO is a United Nations-sponsored organisation that sets international standards that can be used in any type of business and are accepted around the world as proof that a business can provide assured quality. The ISO has appointed SWIFT as the “registration authority” of standards for financial services messages.
FIN messages, also known as MT messages
The range of SWIFT messages that was developed before 2000 are known as FIN messages. They are represented as tagged data. Each FIN message is assigned a message identifier code, such as MT300, which is a foreign exchange trade confirmation message. For this reason, FIN messages are often referred to as MT messages.
There are 176 different business-related MT messages (as well as some system management messages) and there are two ISO standards that govern the content of these messages. The scope of the MT message series is summarised in Table 11.1.
Table 11.1 SWIFT message series
In the relevant chapters this book will list the actual messages that are used by participants at each processing stage for each instrument type.
Underlying ISO standards for FIN messages
The ISO standard that governs all the series except for the MT500 series is ISO7775. This standard was developed during the 1980s and applied to all the messages that were developed up to 1997, including the then current MT500 series securities messages.
In the late 1990s SWIFT and its members realised that the original ISO7775 messages were too restrictive, did not reflect the full complexity of modern trading instruments and were still too ambiguous to ensure that full straight-through-processing could be achieved.
Thus was born the ISO15022 standard based on a data dictionary approach. Initially (in 1997) ISO15022 was applied to the securities message category as this represented the fastest growing usage of the SWIFT network. Old message types were replaced and many new ones introduced. ISO15022 trade initiation and confirmation messages were introduced in 1997 and settlement and reconciliation in 1998. There was no standards release in 1999 due to Y2K distractions, and the old MT500 series, ISO7775 standard message types were removed from the network in 2002.
Example of an FIN message
Figure 11.3 is an example of an FIN message. It is an MT950, which is a statement of a bank account sent by the account operator to the account holder.
Figure 11.3 Analysis of a SWIFT MT950 message
The message consists of:
1. A single header line that shows, inter alia, the BIC code of the sender and receiver, and the ID of the message type.
2. A single line of tagged data beginning with “:25:” – tag 25 shows the account number to which this message refers.
3. A single line of tagged data beginning with “:28:” – tag 28 shows the statement number and page number within this statement.
4. A single line of tagged data beginning with “:60F:” – tag 60 shows the opening balance of the account and the date of the opening balance.
5. Repeated lines of tagged data beginning with “:61:” – tag 61 shows each entry that was posted to the account. The format is as shown in Figure 11.4.
6. A single line of tagged data beginning with “:62M:” – tag 62 shows the closing balance of the account and the date of the closing balance.
Figure 11.4 MT950 tag 61 explained
If you add the money value of tag 60 – opening balance – to the money values of all the individual entries – the tag 61 rows – then the answer should be equal to the money value of the tag 62 line.
Although this is an example of an MT950 message, any other SWIFT message can be interpreted in this way. The explanations of the function of each message, together with the permitted contents of each tag within the message and the network validation rules, are available in the SWIFT Standards Documents that are made available to all SWIFT members.
New messaging developments – the MX messages
The tagged data structure of the MT message series has served the investment community well for many years, but many aspects of it are now somewhat dated. One of the main drivers for change is the growth of the use of Extensible Markup Language – better known as XML – throughout industry and commerce.
XML is a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. XML is a formal recommendation from the World Wide Web Consortium (W3C) similar to the language of today’s web pages, the Hypertext Markup Language (HTML).
SWIFT’s first implementation of XML and the new standard was in a series of messages designed for players in the mutual funds industry in 2003. SWIFT is currently in the process of developing XML-based message formats to replace all of the MT message series, in order to enable the transfer of richer data for more complex business transactions. The SWIFT website shows the current status of the migration program at any one time. There will be an indefinite coexistence period when members will be able to send and receive messages in either MT or MX formats. To support this coexistence period, SWIFT has developed translation rules in human readable form. The rules are provided for those MTs and MXs where equivalence is established and where the community of users has a need for translation support.
11.2 THE FINANCIAL INFORMATION EXCHANGE (FIX PROTOCOL)
The Financial Interface eXchange (FIX Protocol) was initiated in 1992 by a group of institutions and brokers interested in streamlining their trading processes. It is an open message standard controlled by no single entity, which can be structured to match the business requirements of each firm. At the time that the FIX Protocol was founded, institutions and brokers that were not banks had only recently become eligible to join SWIFT, and the founding firms were not satisfied with the ISO7775 securities messages that were then available on the SWIFT network.
FIX does not impose a single type of carrier (e.g. it will work with leased lines, private networks, Internet, etc.), or a single security protocol. It is, however, important to note that FIX is not a network in itself and that communication is made directly between each broker/institution pair by prior bilateral agreement. Thus a fund management institution may have 50 or 60 connections to brokers worldwide, some via the internet, others via direct dial or leased connections and still others connected via private networks such as Omgeo or Autex – see Chapter 12 for more information about Omgeo and Autex.
In summary each broker/institution connection can be thought of as a two-way conversational link taking place between applications at each end. These applications are often referred to as “FIX engines” and can operate either as standalone or fully integrated solutions.
The structure of the FIX Protocol organisation is based around a series of committees comprised of interested parties within the broking and institutional communities. These committees are focused on business, technical and regional issues with working groups examining the impact of new technology such as XML and potential expansion of the protocol to cover other users such as exchanges and ECNs (electronic crossing networks).
The protocol is defined at two levels: session and application. The session level is concerned with the delivery of data while the application level defines business-related data content. Broadly the business messages cover the communication between brokers and institutions of the following information:
- Indications of interest
- Orders and order acknowledgement
- Fills
- Account allocations
- News, Email, program trading lists
- Administrative messages
The protocol has been deliberately designed to support both domestic and cross-border trading in a varied spread of instrument and security types such as:
- Equities
- Bonds
- Depositary receipts
- Derivatives
- Futures
- Foreign exchange trading.
Because the FIX standards are “open source” they may be downloaded from the FIX Protocol website, www.fixprotocol.org.
The current version of the FIX Protocol is version 5.0, released in October 2006, but many market players will still be using version 4.4, released in April 2003. FIX Protocol Standard 4.4 and higher conforms to ISO15022. In 2001 the FIX Protocol organisation and SWIFT signed a memorandum of understanding which focused on convergence between pre-trade and post-trade processing in the use of ISO15022 XML.
11.3 OTHER MESSAGE STANDARDS
As well as the internationally recognised SWIFT and FIX standards, there are a number of proprietary message standards that are commonly used. Most commercial custodians, CSDs, ICSDs, exchanges and clearing houses publish APIs that enable member firms’ systems to communicate with their systems. In particular, it is worth noting that SWIFT standards are not widely used for communicating with derivative exchanges and their associated clearing houses. The proprietary standards of the exchanges and clearing houses have traditionally been dominant. However, from 2008 the Eurex exchange will be supporting the FIX Protocol.