New Standards for Market Data

Transcription

1 Authors: Yuval Cohen, Alex Wolcough Date: October 12, 2012 Paper designation: White paper 1.1 This document is copyright to Etrading Software Limited. No part of this document may be distributed or reproduced without prior consent from Etrading Software Limited. Etrading Software Limited shall not be liable (except to the extent required by law) for any errors or omissions contained in this publication. Etrading Software Limited 32 Threadneedle St London, EC2R 8AY web: telephone:

2 1. Introduction With the ever-increasing volume of real-time data and pressure to deliver that data faster, exchanges have continued to develop a new and diverse range of protocols. With each new protocol comes the need for software vendors and investment banks to develop and maintain new feed handlers, and with that, increasing cost. Compound the issue with the spectre of the Intellectual Property Right challenges that have become infamous in the retail technology space between the likes of Google, Apple and Samsung, and the situation does not improve. Fix Adapted for STreaming (FAST), the first successful attempt at an industry-wide market data protocol, has been dealt a blow by a patent infringement case. A number of major market participants will be taken to court later this year by Realtime Data, who have claimed that an aspect of the protocol, already used by a number of key trading venues, software vendors and banks, has breached their patent. Some firms have already settled out of court rather than risking an unfavourable outcome ahead of the hearing in November 2012, while others are moving to different protocols or reverted to older protocols requiring more bandwidth, both adding further cost and complexity to the industry. Bringing increasing costs to an industry that is currently looking to reduce the financial impact of its technology should be raising alarm bells. Finding a common market data protocol standard that addresses the current and future data rates needs to be found and, from a technical perspective, a stand-alone solution could be found relatively easily. However, looking at a protocol purely from this dimension is unlikely to bring the cost benefits to industry. A significant effort must also be made to ensure industry adoption as well as avoiding the intellectual property minefield. Both these aspects have to be actively considered right from the start, in the design stage of the protocol. In this paper, we explore these issues further and how a joint technical, legal and adoption approach could significantly improve the chances of bringing real benefits to the industry. Page 2 of 15

3 2. Background Developing electronic protocols for transmitting market data has stretched back over many decades. Today, the financial sector has seen a proliferation of protocols operating across a number of dimensions, as venues attempt to deal with the needs of different asset classes, increasing volumes of data, reliability and permissioning. These differences extend over many dimensions and include: Application protocols: XDP, ITCH, EBS, Pitch, EMDI. RWF. Network protocols: Multicast UDP vs. TCP Furthermore, the venues that do use multicast UDP, have different: o initialisation steps o implementations to handle lost (and unordered) messages Compression protocols: FAST vs. ZLIB vs. none (other compression protocols are rarely used in the industry) With all these differences, it is understandably difficult to implement a common feed handler that will serve most of the existing venues API protocols for market data. So with every new protocol, came the requirement for a new feed handler and the associated cost for developing and maintaining a new piece of software. The benefits of a common protocol for the financial sector were already apparent in the early nineties. When the Financial Information exchange (FIX) protocol was first used to send order messages between Fidelity Investments and Salomon Brothers, the creators were already looking to set this up as an open standard. In the last couple of decades, the FIX standard has stood out as the industry s most successful open pre-trade and trade protocol to date. Spearheading the industry with the equity markets, the protocol was soon expanding into the derivatives, foreign exchange and fixed income markets. By the turn of the millennium, a significant number of venues implementing a central limit order book converged to utilise FIX for trading. Key commonalities between these venues were: Network protocol: Standard point-to-point TCP connections were used. Communication protocol: Although venues used different versions of FIX, the most regularly used FIX messages e.g. NewOrderSingle[35=D] and ExecutionReport[35=8] and most FIX fields e.g. CLOrderID[11], OrderStatus[39] are common to all versions and have the same (or very similar) enumerations. Page 3 of 15

4 Compression protocol: At this stage, there was no compression. The protocols transfer FIX messages over TCP in standard text format: ASCII. However, the venues had not converged in a similar fashion for transmitting market data. Although the FIX protocol had messages that could carry market data, it wasn t particularly efficient at carrying large volumes of data. With the increasing volumes of data seen on the equity and derivative markets, alternative protocols such as ITCH, OMNET, Infolect, XMAPI, LIFFE Connect API, VALUES API and ICE API continued to be developed. Which firms benefited from the convergence of the trading protocols? Banks that traded with multiple execution venues had to maintain large development teams in order to develop and maintain the on-going protocol changes. Individual protocols used by only a single execution venue, often resulted in expertise sitting with sole individuals. This often resulted in significantly higher resource costs because of the knowledge scarcity and significant risk to the bank of the individual moving away to another bank. The arrival of FIX and the adoption by a number of trading venues benefited these organisations the most. Implementing small amendments to the FIX trading protocol, became significant easier and faster task than implementing similar changes in other trading protocols. In most of the banks, knowledge of the FIX protocol became a widely understood commodity with more than one member of the gateway team being able to make changes easily. Why did the execution venues that implemented FIX for their trading protocol, not implement the same protocol for their market data? The needs for transmitting market data differed significantly from the requirements of trading protocols. The principal differences were the sheer volume of data and the need to get that data to the consumer as fast as possible as automated electronic trading changed the face of the financial market place. Whilst some execution venues such as FX platforms needed to convey just a few hundred market data messages per second, other execution venues, typically equity and exchange traded derivative platforms, needed to send price updates and trades at a rate of over a million messages per second during peak. Peak messages rates still continue to grow with some execution venues planning for more than 10 million market data messages per second in 2013, requiring a bandwidth of over 3 Gigabytes per second. Clearly, there was an opportunity for the industry to look at a standard for an open market data protocol that was fit for purpose and in 2005, work started on Fix Adapted for Streaming. Page 4 of 15

5 3. The FAST revolution Quick Adoption Fix Adapted for STreaming, or FAST as it s commonly known, was designed at the outset to support high-throughput, low latency communication and specifically aimed at publishing Market Data. Not only did the protocol meet the business needs of the financial community by providing a flexible open standard, it outperformed many of the optimised binary protocols that already existed. For example, in a comparison between FAST vs. ITCH protocols, using live ITCH market data, the FAST achieved approximately 65% lower bandwidth utilization and a 25% faster encoding and decoding speeds 1. The raw encoding and decoding speeds of FAST were in the range of 10 million messages per second. In addition to that, FAST has significant advantage of flexibility when defining messages types and messages structures, making it a highly attractive protocol to the financial community. As soon as the FAST version 1.0 was ready in early 2006, exchanges adopted it and soon it was used in production at a number or major exchanges and venues including CME, NYSE, Euronext, the London Stock Exchange, the International Securities Exchange, ICAP, Eurex, Xetra, SGX and more. It was a success story for the FAST protocol, and for a short while the industry believed that FAST was the best solution for a market data protocol standard. Unfortunately, this view was soon to be tainted. A Legal Challenge In 24 August 2011, a firm called Realtime Data claimed to own six patents protecting compression technologies including FAST. Realtime Data offered a Covenant Not to Sue through ICAP Patent Brokerage, effectively selling the right to use these compression technologies for a significant fee. Exactly one month later, Realtime Data filed several court cases for the infringement of US patents. The table below summarize the three cases: Realtime Data vs. US Patents infringement Case # in NY Southern district court CME NASDAQ OMX BATS NYSE Euronext NYSY ARCA CBOE, NYME & others 7,714,747 7,777,651 1:2011cv :2011cv :2011cv FIXGLOBALTRADING Page 5 of 15

6 Realtime Data vs. US Patents infringement Case # in NY Southern district court Bloomberg Thomson Reuters Others 7,714,747 7,777,651 1:2011cv :2011cv06700 Morgan Stanley Goldman Sachs JP Morgan chase HSBC Southwest Securities BNY ConvergEx Credit Suisse Others 7,161,506 7,400,274 6,624,761 7,417,568 1:2011cv :2011cv :2011cv :2011cv06704 As of, hearings for these cases are still on-going. To date, the case has made some progress in the favour of FAST with the following ruling from Judge Katherine Forrest stating that : For the reasons set forth above, defendants' motion for partial summary judgment is GRANTED. Claims 1, 7, 8 and 13 of the '747 Patent [US Patent 7,714,747] and Claims 1, 4, 6, 7 and 12 of the '651 Patent [US Patent 7,777,651] fail to comply with the definiteness and written description requirements of 25 U.S.C. 112 and thus, [these patents] are invalid Damage Done? Despite the early ruling above, the FAST protocol has already suffered damage from these patent infringement cases. Earlier in 2012, many of the exchanges including ISE, BATS, and NASDAQ decided to eliminate FAST from their external protocols. Other exchanges like CME decided to remove FAST operators, effectively removing the compression of messages and therefore increasing the necessary communication bandwidth required to get market data from the exchange. According to an announcement on the CME website on August 13 th 2012 : The life cycle of the FIX/FAST protocol, including streamlined FIX/FAST, is rapidly approaching its end CME Group continues to evaluate a next-generation market data protocol. Furthermore, it is unlikely that any of the exchanges will rush back to use FAST if Realtime Data do fail to defend their patent. Page 6 of 15

7 The current environment of patent infringement litigation has meant that firms are increasingly concerned about letting in another Trojan Horse, where open source standards are adopted, only to be jumped on later by opportunistic patent trolls looking for licenses or expensive covenants not to sue. So what is the alternative? Let the proliferation of protocols continue, driving costs up again or look at creating an alternative open standard with the appropriate protections in place. Page 7 of 15

8 4. Considerations for a setting a standard As mentioned in the introduction, if a new open standard for market data is going to be successfully introduced to the financial markets, a broader approach is going to be needed. As well as the technical stream, a significant effort in mitigating against legal issues and promoting adoption from the outset will be essential. We look at each of these streams below: The Technical Challenge When defining or selecting an existence a market data protocol, there are a number technical dimensions to consider. Some of the major points are listed below: Network Protocol: There are significant differences between TCP to UDP. Below are few examples: o Packet header size: the header size of a single TCP packet is 20 bytes, whilst the header size of a UDP packet is only 8 bytes. The 12 bytes difference multiplied by 1,000,000 packets per second will generate a difference of a few megabytes. o IP addressing: Unicast vs. Multicast (vs. Broadcast vs. Anycast). Some execution venues have implemented broadcast environment sending the data over UDP multicast. This enables the execution venues to send one message to many (or all) of their clients at once. It also gains the benefit of fairness where all clients have equal potential to receive messages at the same time o Reliability and ordering of data packets: Whilst TCP provides a level of certainty that the data transferred remains intact and arrives in the same order in which it was sent; UDP does not. UDP provides no level of assurance that messages or packets sent would reach the intended listener at all: message order and reliability needs to be managed at the application layer. Encoding of Data Types: There are many ways to represent the same data types. Below are few examples: o FIX represent most data types in ASCII format. Therefore, the integer 8 requires a single byte followed by a delimiter while the integer requires 5 bytes followed by a delimiter. Page 8 of 15

9 o Binary protocols, like OUCH usually represent an integer in 4 bytes regardless of the integer value. Encoding/Decoding Overhead: Encoding and decoding between the message format and the internal representation required by an application requires some level of processing. Different encoding will result in completely different requirements of CPU either by the execution venue that encodes the messages or by the receivers that decode the messages. Message Content: The approach to message content can vary widely. Some protocols try to avoid sending any duplicate content, however this often requires the receiver to build and maintain data structures in order to process the current message. Below are few examples: o Order Book Updates: When an order at a price level gets taken, some venues will send a message to remove that order, expecting that the receiving application to create and maintain the image of the entire order book in the correct order and then apply the change to it; Other venues will maintain the entire order book in the correct order on behalf of the client and send a partial or complete image every time a change is made on the order book. o Implied prices: Sending implied or derived prices add more messages to the network but ensure that calculations are consistent. Some execution venues leave the calculation of implied prices to their clients. There are plenty of examples where legacy protocols require redundant or duplicate fields in each message. Messages Format: As well as the content, the representation of data within a message needs considering as well: Page 9 of 15

10 o Delimiter: Is there a need to define a delimiter between fields in the message? If so, which delimiter is used? How to differentiate between the delimiter and content. o Message header: Most protocols have a header but for what purpose? A few aspects to consider: Addressing, Message description, Security. o Fields structure: The fields structure and the relationship between fields is in the core of each market data protocols. Amongst others, there are differences between: Size of fields fixed size vs. variable size Order between fields Repeating fields behaviour Existence of fields names Compression: Some protocols compress their messages before sending them. The main example is FAST protocol which uses compression for each field. When considering a compression method, there is a need to compare the CPU overhead to compress/uncompressed messages vs. the compressibility factor. Recovery Process: The design of a protocol must also consider unreliable connections where clients may frequently connect and disconnect during trading hours. Clients should still be able to quickly build entire order books for a large number of instruments. Appendix I details where the current trend for protocols sit today. Page 10 of 15

11 Market Adoption It is in no-one s interest to see yet another esoteric market data protocol launched by a single execution venue, so it is important that there is real focus on market adoption right from the start of the project. Aspects that must be considered are: Asset Class and Market Models: A venue will not use a protocol if it cannot publish the data it needs to get to its clients in the correct way. Not only does the price data need to support the asset class that is traded, it also needs to be able to accommodate the market or trading model of the venue as well. Documentation of the Protocol: Any protocol should have rich supporting documentation that not only specifies message formats but also illustrates workflows and business use cases by example, reducing ambiguity and the likelihood of divergence. New markets requiring low latency protocols: Finding clusters or communities of new users looking for improved technology should turn out early adopters. o Regulation continues to be a driver for change and with more demand for transparency, a tranche of new venues will be launched (SEFs in the US and OTFs in the Euro Zone) o Existing FX venues are now seeing volumes increase and the demand for lower latency data. Expect the single bank portals to move away from FIX soon. Legal Considerations The extent to which patents have been filed and used to protect what most technologist would consider standard practice is now becoming quite alarming for some. Most of these patents are designed to be an overt way of defending licensable product or technology where the license is offered on a reasonable basis. However, there have been cases where patents have been lodged and held silently while industries adopt the associated technologies. It is only when the technology is widely adopted these firms show their card and sue for breach of patent. In defining a new protocol, it will be essential to understand where the patents exist and then which could be used, or need to be avoided, at the technical design phase so at completion, there is an understanding what licenses are required (if any) and what legal protection needs to be put in place. Page 11 of 15

12 It is clearly important that when the protocol is complete, the community can be confident that the danger of being sued for breach of patent is significantly reduced. Page 12 of 15

13 5. Conclusion In light of the elimination of the FAST protocol by many exchanges during 2012 there is a pressing need for the industry to converge on a new market data standard rather than witness a proliferation of venue specific alternatives. In looking to provide a protocol that the industry can freely use for market data, a broader approach will be needed that not only considers the technical challenge but also addresses the legal issues as well. However, the task to develop a new market data protocol, to protect it from Intellectual Property Right challenges and ensure adoption is a significant project in itself. It will also need to be a funded initiative if it is going to receive the correct level of effort and attention to succeed. A collaborative project between market participants providing dedicated resources to the initiative is the most likely route for success. This path will have significant advantages: It will reduce the costs for each of the participating firms Broader global participation will significantly improve the technical solution Wide consultation with venues and pressure from a broader representation of their user community will improve likelihood of adoption A collaboration made up from a significant representation of market participants is likely to receive better support from Standards organisations and Regulatory bodies and have a greater chance of success. Page 13 of 15

14 Appendix I: Recent Trends in Market Data Protocols In recent years, the large and liquid execution venues have tended to adopt protocols with the following attributes: Attribute Trend Network protocol UDP multicast Message content Focus on minimum content. e.g. Order book updates sent as single order updates rather than Order book images Broad range of encoding and message formats used. Encoding of data types Examples include: FAST: uses a single bit delimiter, compressed data, OUCH and ITCH: uses binary fixed length message size with no delimiter. Message Format Other initiatives include: Google buffers protocol and ASN.1 protocol used in other industries are currently being investigated for suitability in market data space Recovery process UDP multicast commonly used, however protocol does not support message order or reliable delivery. Broad range of application level reliability and recovery paradigms used. Page 14 of 15

15 About Etrading Software Etrading Software was founded in 2005 with the goal of bringing efficiency and stability to the burgeoning electronic trading markets. As experts in etrading processes, the partners and their senior team have a track record of implementing key projects and strategies for existing and new participants to the etrading market place. However, as the business environment and markets matured it has become increasingly obvious to Etrading Software that individual corporate endeavour is not going to be enough to rationalize and standardize the processes and infrastructure at etrading. In addition, new budgetary constraints are also forcing businesses and their technology departments to think differently. Banks recognize that they should not be competing on protocol nor on the information that constitutes a vanilla deal. By collaborating with each other and agreeing standards to which they and the electronic markets adhere, they will be able to reduce costs and increase portability and focus on true areas of competitive advantage. Etrading Software is instrumental in this process. As a trusted partner, we bring together key participants, provide technical leadership and drive the group towards agreement and syndication. Etrading Software Limited 32 Threadneedle St London, EC2R 8AY info@etradingsoftware.com web: telephone: Page 15 of 15