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.
These issues, based on our experience, can be addressed in the following ways:
- Our system uses 100% pure Java 1.6 technology. Write-once/run-anywhere JVM technology provides true platform independence. For example, all common operating systems (Solaris/Unix/Linux/Windows), CPU’s (Intel/Sun/AMD) and addressing modes (32/64 bit) are supported with no changes to the product.
- Java is a mature server-side development platform, whose performance can approach - and in some cases - better a traditional C++ system. The run-time memory management and dynamic recompilation/optimization provided by modern JVM’s can yield high-performing systems with enhanced stability.
- To achieve low latencies, MetaBit’s FIX based exchange connectivity code optimization has targeted high cost operations (in terms of execution speed) such as transformation, data serialization, persistence and logging.
- To achieve a consistent performance, the spikes in latency must be reduced. Common sources of spikes are usually thread interaction and garbage collection. Our threading model ensures thread contention is kept to a minimum. Garbage collection is also dramatically reduced via optimization of memory allocations and use of techniques such as object pooling.
- Careful use of concurrent coding strategies allows the system to remain thread-safe whilst scaling from a few to 100 VS’s with almost no degradation in performance.
- Extensibility is achieved via use of a generic order object model for the core system. Pluggable adapters are provided for FIX (currently versions 4.0 to 4.4) and specific exchange connectivity for Japan’s exchanges.
Since 2008, low latency trading access, inclusive of proximity hosting, has become a focal point of Japan’s exchanges. The efforts to stimulate more offshore direct trading access to Japan’s markets has given the FIX Protocol a long deserved opportunity to prove its capacity to service the industry with a cost-efficient trading protocol, and low latency throughput which neatly dispels its reputation as being slow.
With the Tokyo Commodity Exchange now using FIX, the hope among the FIX community is that organizations such as the TSE will revisit their decision not to offer a high performance FIX gateway to their exchange systems. Our firm belief, supported by markets worldwide, is that that the FIX Protocol represents a sound value proposition for an exchange to attract increased liquidity.
Case Study
Implementing FIX for the Tokyo Commodity Exchange Trading System
The Tokyo Commodity Exchange Inc, (TOCOM) was in, recent history, Japan’s first exchange to offer its broker members a FIX Gateway in addition to a native API for their new exchange system. TOCOM selected the world’s largest exchange system provider, NASDAQ OMX, to provide their exchange system. The decision was based on performance, scalability and stability combined with NTTData as TOCOM’s local integration and support partner.
In mid 2008, MetaBit was appointed by NASDAQ OMX as a partner in Japan to build the FIX gateway into the exchange system. The mandate was to build a FIX gateway, adding minimal additional latency, and to offer domestic and offshore members of TOCOM the opportunity to route their FIX order flow directly into the new NASDAQ OMX exchange system.
The key challenge was to build a FIX exchange gateway that would be competitive with the native API in terms of performance and low latency.
MetaBit has built a FIX gateway using the same technology framework as its current TSE, OSE and JASDAQ connectivity. At the core of the architecture is the Orc CameronFIX engine. The resulting TOCOM FIX gateway now offers consistent low-latency and high throughput performance.
TOCOM’s decision to champion FIX-based market access and to adopt an exchange platform from a non-Japanese vendor not only provides TOCOM’s members with a state-of-the-art execution venue but also places TOCOM in a leadership position among the Japanese exchanges.
On 7 May 2009, TOCOM’s new exchange system successfully went live and trading hours have already been extended to 11pm and will shift into a 24-hour trading service at a later stage.
