By David Chapel
In January 2010, the Tokyo Stock Exchange (TSE) launches its new, high-profile, Arrowhead exchange trading system for cash equities. TSE defines Arrowhead as its next generation trading system combining low latency with high reliability and scalability. However, to the surprise of many in the global trading community, Arrowhead will not include a FIX gateway. MetaBit Systems’ David Chapel examines the decision and argues that the Japanese exchange should reconsider the decision.
In September 2008, the Tokyo Stock Exchange (TSE) announced its plans for ‘Remote Trading Participant Services’ that would allow offshore firms, with no branch in Japan, direct market participation – a novel proposition in Japan. Initially, during the tender phase, TSE considered offering a FIX Gateway to the new Arrowhead system, however, a survey of exchange participants indicated that broker members had minimal interest in the global communication protocol.
The survey results came as a surprise to many, but a closer look at the TSE broker members shows it leans heavily towards smaller domestic players. Currently, TSE has 106 broker members, including foreign securities firms that have registered their local entities as a ‘General Domestic Trading Participant’, and 11 foreign members. Of these only around 40 members (split almost evenly between foreign securities firms, including those registered via their Japanese legal entity and domestic securities firms offering international trades) would possibly see the need for a FIX gateway.
Given the advantages that a FIX gateway would have offered to Arrowhead’s future Remote Trading Participants interested in the protocols ability to interact with a local exchange through a standardized API, we would urge the TSE to reconsider its decision, despite the current low demand among its domestic members.
Why not FIX it?
FIX is not a new concept in Japan. At MetaBit, we have offered a FIX-to-native exchange gateway to all major securities exchanges in Japan since 2004. The development of Arrowhead provided our company with the catalyst to re-architecture the existing FIX gateway with a focus on low latency and scalability. This need for speed was particularly important given the belief among exchanges that FIX is slow. Our aim was to bring FIX-to-native exchange connectivity below 500 microseconds of additional latency under sustained load, a goal which we have more than achieved. In addition, we have made extensive use of the Orc CameronFIX Universal Server to provide the core FIX connectivity.
Technical challenges and solutions for FIX
During the development of our upgraded FIX gateway, we had to consider the following technical challenges of providing a FIX implementation for direct exchange connectivity:
- Performance is paramount; request latency (time to exchange) and request throughput (requests per second) represent the key metrics. Larger global members require sub-millisecond latency with throughput exceeding 1000 orders/second.
- For scalability, most Japanese exchange architectures require multiple physical connections (so called Virtual Server or VS’s). Each VS is limited to a certain throughput by the exchange; higher throughputs can only be achieved by a broker member subscribing more VS’s. Due to cost, smaller and mid-tier brokers typically subscribe to 20 to 40 VS whilst it is common for large members to run above 100 VS’s per exchange. Efficiently managing and load balancing across such a large number of connections leads to a significant increase in complexity.
- Each exchange API has a unique message protocol and message structure. Creating a standardized multi-exchange product requires custom FIX mapping for each implementation. It is the aim to keep custom FIX tags to a minimum possible whilst adhering to the global FIX Protocol.
- The FIX API is a simple asynchronous model, well suited to high throughput bidirectional messaging. However, Japan’s older exchange APIs use a synchronous delivery model, providing batched order requests (20 orders per batch) to increase throughput. This complicates mapping between the FIX- and the native exchange API and increases implementation complexity.
- Members can run many different types of hardware and operating systems; hence a vendor needs to support as many systems as possible.
