Update on the Financial Information eXchange (FIX) Protocol
The Financial Information eXchange (FIX) Protocol originally evolved as a messaging standard for the equity market space, but with the growing trade volumes and successful adoption of FIX in the equity market, the need is now being felt for the adoption of FIX across other asset classes as well. Future projections indicate an increase in the trade volumes across fixed income, derivatives and foreign exchange. This will mandate the need for a standardized protocol for all pre- and post-trading activities across all asset classes.
A survey commissioned by FPL Global Education and Marketing Committee and conducted by TowerGroup, estimated that over the next two years FIX penetration levels are expected to rise to 70% over all trade stages and asset classes. The survey also noted that there was wider adoption of FIX across exchanges, which will fuel wider adoption of FIX across the market. These statistics are a signal for firms to start analyzing and assessing their capabilities for adopting FIX across all asset classes.
With the release of the latest version, FIX 5.0, which extends the functionality provided by FIX 4.4 released in April 2003 and based on the Transport Independence (TI) framework, it will be possible for firms to use different message versions within the same FIX session. This will not only reduce financial investments to support new releases but also allow FIX to be used by a wider audience. It will also address the concerns of the number of FIX versions available.
Since its inception in 1992 as a bilateral communications framework for equity trading between Fidelity Investments and Salomon Brothers, FIX has become the de-facto messaging standard for pre-trade and post-trade communication globally within the equity markets, and is now experiencing rapid expansion into supporting electronic execution of other asset classes as well. FIX allows firms to automate all aspects of pre- and post-trade processes and it delivers many benefits, such as greater trade efficiency, faster time to market, reduction in trade errors and cheaper access to liquidity.
The protocol is gathering increased momentum, as it continues to expand across other asset classes such as foreign exchange, fixed income and derivatives. There are many brokers and applications that have offered electronic execution of asset classes, but recent trends have seen a major uptake to trade these instruments and take advantage of the benefits that FIX can offer – most notably, direct order generation from trading models and STP, by the risk management and back-office systems of buy-side firms.
The initial expansion of FIX for equity included the modification of established workflows to cover new requirements without major changes in the way parties conducted their business. The changes were minor compared to what would be potentially required as electronic execution across other asset classes. FIX for equity required changes in workflows as some countries, for example, do not allow block trading. Once FIX executions were enabled, parties wanted to transmit other aspects of the trade-like account allocations, settlement instructions, and post-execution modifications – all in electronic format. The original implementation of FIX for equity markets was not difficult due to the widespread use of consistent security identifiers to represent instruments.
The size of the fixed income market certainly makes the idea of electronic transmission desirable. However, the complexity of the requirements makes the process significantly difficult. Unlike equities where the ticker and quantity can easily define the trade, fixed income requirements are more onerous. There is no consistent security identifier representing all instruments. It is important that security master data is accurate for all aspects of the trade to work – coupon, pay date, settlement date, etc. Also, the fragmentation that exists across various fixed income classes – government/sovereign, corporate and municipal – makes standardization even more difficult.
The sell side appears interested in fostering electronic communication for foreign exchange execution. This is probably due to the ubiquitous nature of foreign exchange transactions and the tighter execution margins, which in turn require higher levels of automation. Complexities exist in the foreign exchange implementation of FIX due to market practices. For example, unlike equity or fixed income, where block trading is the norm, some foreign exchange transactions require communication of account allocations on a pre-trade basis. If managers need to modify orders after communication to the counterparty, the workflow gets complicated. In addition, FIX must support two different communication flows (pre- and post-trade allocation communication) depending on the requirements of the counterparty.
The requirements for electronic execution of derivative transactions can, depending on the type of derivative, restrict the ability of effective bi-directional electronic execution communication between the counterparties. Exchange traded derivatives require standardized data elements and their existence makes it easier to implement a method of electronic execution. Other derivative transactions – interest rate and asset swaps – are so customizable between the parties that bi-directional communication will prove to be highly complex.
As FIX adoption expands, the industry must carefully consider the challenges that need to be overcome if FIX is to emerge from its equity centric origins to become the de-facto multi-asset standard.
Different vendors and counterparties support different versions of FIX (4.0, 4.2 and 4.4 are all in active use) and the interpretation of the standards can vary widely. At some level, enough commonality of design must exist so that all participants on a trade can process the data. As the FIX versions change, the different FIX messages they support also change. Information about what components of FIX a party is using, the messages, workflows and exceptions that they handle are unknown, thereby increasing the complexity. Also, to support multi-asset classes, firms using older versions of FIX (equity centric versions 4.0, 4.2) will have to upgrade to FIX 4.4 or higher. However, the challenge does not end there, firms will have to constantly upgrade to new releases until FIX for multi-asset classes becomes more comprehensive and mature. Thus, the bigger challenge is for firms to build scalable architectures to meet new changes in the most efficient and cost-effective manner.
Depending on the types of transactions being processed, a single system supported by associated exception handling may easily support direct back and forth messaging. Other parties may only support a staging communication method. This means that base data is transmitted to another system, and all execution related order management is handled separately from the originating system. The need to maintain order status between systems can result in differing states for the same order.
Fixed income increases the complexity of the FIX process. Often, the characteristics of the desired trade are known, but the actual instrument to be traded is not. Depending on the types of supported workflows (staging vs. direct), the methods for ensuring accurate identification of the security, and the ability to obtain complete and accurate terms and conditions, the requirements for accurate execution can be met. Meeting those requirements, however, results in a much more complex interaction between the trade parties when using a standard protocol.
While the FIX specification is open and free, implementing FIX requires planning, software, and network services. While obtaining and maintaining productive FIX connectivity can be a relatively inexpensive process, creating a large-scale, continuously operating FIX network across all asset classes, serving tens of thousands of users can easily be a hugely expensive proposition. Questions such as how much the new business will gain through this effort, what cost savings can be realized by more efficient operations and fewer failed trades need to be answered.
Successful implementation of FIX will require careful planning and assessment of current capabilities. Adequate benefits can be realized by the following approach.
Equity side peers who have been using FIX have considerable knowledge and lessons can be learnt for its successful implementation. The equity side has gained tremendous knowledge and experience with STP and FIX operations so leverage their knowledge and those of others who have experience in this area. The markets may be different in other asset classes when compared to equity, but the technology is easily transferable.
If your firm’s equity side is already engaging in electronic trading and FIX then your firm already has a FIX capable infrastructure in place. The strategy will be to learn what is already there and know how to leverage that to meet your requirements. A common FIX infrastructure can be built (provided it is FIX 4.4 or higher which supports multi-asset classes) and provide a messaging component as a common service to all the different trading desks. This is where cost savings can be realized by the firm in terms of software licences for the FIX engine, databases for persistence and data recovery, and external network access for communicating with counterparties.
There are indications that all asset classes will not only gain increasing importance and benefits but also complexity in the years to come. Firms that want to get ahead of competition in the long term should build their infrastructures in a way that can be scaled to meet upcoming demands and trends across all asset classes. For example the number of messages sent and received can increase by up to 100 times. Firms should ensure that their infrastructure is capable of scaling up to the rapid increase in messaging volumes. Also, it is imperative for firms to constantly upgrade to newer releases until there is maturity in the way FIX technology is used by the firm.
The flexible nature of the FIX protocol allows firms to be innovative in the services they provide. The disadvantage here is that to start a connection with a counterparty requires the parties to ensure that they are able to communicate with each other, which adds significant time and cost to FIX connectivity. It is thus recommended to strictly follow the protocol standardization. The trade-off is between protocol flexibility and its standardization.
FIX Protocol recently announced the pre-launch release of the Financial Information eXchange Protocol (FIX) version 5.0 that is now publicly available. The production-ready final release will be available this month.
FIX 5.0 significantly extends the functionality provided by the FIX 4.4 specification released in April 2003. Developed through the volunteer efforts of the FPL Global Technical Committee, FIX 5.0 addresses the latest issues faced by the financial services industry including growing market data volumes, increased regulatory pressure and the spread of electronic trading within additional product areas and throughout the trade lifecycle.
The significant feature of FIX 5.0 is its transport independence framework, which separates the FIX session layer from the application layer. This framework enables different message versions to be used within the same FIX session. For example, this will enable a firm to use FIX 4.4 allocation messages in the same FIXT.1.1 session carrying FIX 4.0 order and execution messages. Under the new framework, the session and application layer are now separately delineated. The session layer has been designated as FIXT.1.1 and the application layer as FIX.5.0 or earlier. This significantly reduces the financial investment required to support new releases while allowing FIX to be used with a wider audience of participants from the most demanding low latency users, to those requiring massive scalability. Firms can now enjoy the benefits of multi-asset messaging along with transport independence framework with FIX 5.0.
FIX is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. These market participants share a vision of a common, global language for the automated trading of financial instruments.
Firms use the protocol to transact in an electronic, transparent, cost efficient and timely manner. FIX is open and free, but it is not software. Rather, FIX is a specification around which software developers can create commercial or open-source software, as they see fit. As the market’s leading trade-communications protocol, FIX is integral to many order management and trading systems.
FIX protocol will be the dominant electronic trading standard, regardless of asset class, in the years ahead. FIX 4.4 contains new capabilities in a number of areas, including enhanced support for global fixed-income products, global derivatives, allocation and settlement, and much more. The latest release is FIX 5.0.