To implement a successful low latency trading strategy, Direct Market Access (DMA) APIs for the market data feed and order entry feeds are critical. Here we detail why market data handler and order entry SDK implementations are the answer to save strategy developers time and effort in deploying and maintaining venue specific order entry API logic, and maintaining market data consumer logic.
Why Market Data Handler SDKs?
Market data feeds are usually based on network broadcast protocols (UDP multicast) disseminating requisite product definition static data, order book snapshots and incremental updates on the order book.
For a trading framework or strategy that needs to understand the price levels in the order book, this means that it requires book building logic to apply snapshot messages and incremental order/price adjustments to the local book image. Network multicast messages are not guaranteed to be reliably delivered as network packets may be dropped which can invalidate the local book image. Thus market data messages are usually broadcast on two multicast group feeds (A and B) and sequenced for gap detection. The order book building logic listens to both A and B feeds and arbitrates between them for any gaps or delta in data arrival times, and the market data API will generally have a TCP recovery channel for gap filling where any market data update is missed and not present on either the A or B feeds.
The trading framework/strategy logic will listen via the market data handler API for book state and update events on specific products without having to handle the order book maintenance machinery logic.
The book building logic in the market data handler SDK is optional and includes access to the underlying decoded market data events for those who wish to consume them directly.
And the market data handler implementations are maintained in sync with the venue specific market data feed API updates – that is when a venue applies either major or minor DMA API updates then the SDK is updated within the support agreement service level agreement i.e. future proofing.
Quick to Deploy, Easy to Maintain
Overall the market data handler SDK implementations provide a quick to deploy, fully supported and updated, local image of the order book with full depth to save the strategy developers time and effort in deploying and maintaining market data consumer logic.
A good example of this implementation is the OnixS directConnect: CME MDP 3.0 Market Data Handler SDK implementation:
Why Order Entry SDKs?
The trading framework/strategy logic will consume market data events and generate order events to be inserted into the order book.
An order entry SDK will support the network and session layer protocol DMA API exposed by the venue and provide message encoding and application level message API to support the creation of valid orders.
In low latency contexts the speed with which these order entry events are accepted into the CLOB is critical, therefore the SDK includes optimisation techniques for threading, latency and minimising jitter for consistency of performance (determinism).
Again, using the CME by way of example, the CME Globex iLink 3 Binary Order Entry API SDK diagram overview illustrates how this SDK is designed:
Like the market data handler SDK, the order entry SDK implementations provide a quick to deploy, fully supported and updated order entry method to save the strategy developers time and effort in deploying and maintaining venue specific order entry API logic.
The design patterns for the OnixS directConnect venue specific market data handler and order entry handler SDK implementations are common so the same concepts apply for the available range of SDK implementations.
