Direct Market Access (DMA) is the common term used to define the physical connectivity and programmatic access supporting the ability to interact with buy and sell orders for traded products/contracts directly to automated trading systems (ATS) liquidity pools. Direct Market Access trading is the process of trading through the aforementioned channels.
These liquidity pools may be public exchanges with a Central Limit Order Book (CLOB) that matches buy and sell orders. DMA access provides visibility of the state of the central order book enables firms to trade with high probability knowledge of the state of the current bids and offers on the order book.
There is a distinction between “Lit”, and “unlit”, or dark, liquidity pools. A lit liquidity pool allows trader visibility of the amount of liquidity in terms of orders and prices on the bid and offer (buyer and seller) sides of the order book whereas a dark pool will not show the order book orders and prices. For the context of the descriptions here we will consider primarily “lit” pools where DMA access supports trading products on the CLOB bid and offer awaiting a trade matching event.
Access to the liquidity pools CLOB are limited to authorised institutional market participants and technical access is via the direct market access (DMA) application program interfaces (APIs) exposed by the venues.
Generally, these DMA APIs include a market data feed for disseminating market data events, an order entry API for inserting buy and sell orders into the order book, order state feed for monitoring orders in the market on behalf of the participant, and post-trade feeds for executed orders (i.e. trades).
Each of the DMA APIs are designed and optimised specifically for the function that they are designed to perform. It is useful to make a distinction between true direct market access and indirect market access.
As already described, direct market access is direct interaction with the APIs exposed by the liquidity pool. The key concept here is “direct” – meaning that the API is optimised for interacting with the order book without going through another processing layer or service that adds latency.
Indirect market access meaning that orders are routed to the liquidity pool via another processing layer – for example via what we describe as an aggregator who provides access to multiple liquidity pools via a single API.
There are advantages and disadvantages to each of direct and indirect. Generally - direct access is faster (lower latency interactions with the order book) but the venue DMA APIs are technically complex. This complexity costs significant time and development money to implement, optimise and keep up to date with low level API changes.
In contrast indirect access introduces a simpler to integrate API (often FIX Protocol based) that is more industry standardised and for which industry standard FIX Engine implementations can be used. This indirect approach does add processing hops to the order flow which costs time thus introduces latency. This access mechanism lends itself to quicker integration to get access to multiple markets, lower costs in terms of implementation and reduces the maintenance overhead by abstracting many of the actual liquidity pool DMA API changes.
Thus each of direct and indirect market access are valid based on the context of the target trade of the strategy. Where optimal latency is a requirement then true DMA access is mandatory.
We describe this difference between direct and indirect market access as the cost vs performance curve.
On the left we have low cost access, but high latency/slow speed. On the far right we have Ultra Low Latency and Low Latency Direct Market Access (ULLDMA and LLDMA respectively) but the costs to develop and support that access method are high.
Here we are focusing on DMA (i.e. direct) so we will continue to develop this topic.
We have mentioned optimal latency and there are other considerations and physical requirements for DMA. A trading strategy will be conceived, developed, calibrated and tested based on gaining a trading advantage. This doesn’t necessarily mean that the strategy needs to be the fastest to interact with the order book for buy, sell and cancel events, but often it will need to be fast. How fast it needs to be is part of the calibration process of the trading framework.
In automated trading strategies, the executing strategy code logic will consume market data feeds and generate order entry events. The strategy code will often be compiled with the requisite DMA API software development kits (SDKs) and deployed on physical machines running in the target liquidity pool colocation facilities. Here the laws of physics start to matter – the physical length of network cabling and being physically close to the liquidity pool CLOB order matching engine matters.
Interacting with liquidity pools requires integrating with either Direct Market Access or Indirect Market Access APIs. The former are faster but technically more complex. The latter are slower but quicker to integrate with based on industry standards.
It is worth defining some other common terms that are used in this context - High Frequency Trading (HFT) is commonly used to describe market participants using automated trading logic interacting with the liquidity pools at speeds much faster than a human interaction. The term is quite loosely defined and has developed into a somewhat negative term associated with undesirable and illegal market manipulation. However the words remain an accurate description for very large portions of current trading volumes on major liquidity pools in that the trading volume is automated at speeds beyond the ability of human “click-traders” to compete. The term “algorithmic trading” is probably more socially acceptable with less negative press.