Trading operations generally require several distinct functions from their API(s) - such as trading, market data, risk control and connectivity to other systems. Whether they actually get them in the right combination and of the right quality is quite another matter. The traditional approach - often justified in the name of simplicity - is to try and squeeze all these functions into a single API. Apart from inflicting redundant functionality on clients (and charging them for it) this "chuck it all in together" approach often also results in compromises when it comes to performance. Another important aspect of any vendor's API strategy is what sits behind it. In an ideal world clients have access to a variety of APIs so they can pick the one(s) best suited to their requirements, but the best API functionality in the world will never compensate for a supporting infrastructure that runs like a slug or exhibits wild swings in latency.
In the world of automated trading, the speed with which things can go very right or wrong is phenomenal. A trading model that runs seriously awry can quickly consume all available margin as well as disrupting markets. This inevitably means that risk management absolutely cannot be of the "phone up later" variety; it has to be as real time as the trading it risk manages.
There is therefore much to be said for a trading API that also integrates a high performance risk management layer, so that any minor trading model glitches remain minor. However, this approach also has to recognise that some trading operations will already have some/all of their own risk infrastructure and will not wish to pay for duplication. Therefore trading businesses will ideally want a risk management layer in an API that they can use totally, partially or not at all as required. And pay accordingly.
The option of having a risk management layer available in an API is enormously powerful, particularly when the API is connected to back office systems. Operational efficiency is hugely increased, as all existing account numbers and settings (such as P&L, position size, instrument and currency limits) can be uploaded automatically through the API - rather than spending an age manually keying them all (doubtless complete with added errors).
There are further benefits to this approach after initial set up is complete. For example, the back office system could be connected to the API to feed in data such as open positions, initial margins and cash balances from the previous trading session, so all information at the start of the day is always current and correct. A further advantage is performance; because the risk layer is within the API, it will typically respond faster in relation to trading activity than an external risk system, as it does not have to cross an API boundary to communicate with a trading application. In addition, because it is internal, further performance enhancements may be possible by fine tuning the infrastructure layer that sits behind the API.
These benefits become all the greater if they can be leveraged across multiple markets. Having to maintain multiple individual trading interfaces to trading platforms is a major overhead; having to manage risk across all those interfaces is an even bigger one. Therefore the API that encapsulates all the required trading interfaces alongside robust risk functionality not only reduces risk, it also massively reduces time and cost overheads. Furthermore, in the current environment, where time to market of a new trading model (especially a multi venue one) is increasingly an issue of competitive advantage, it has a very direct benefit for P&L and return on intellectual capital too.
The option of integrating risk management into the API is valuable across a wide range of trading businesses. For example, some retail broking and trading venues have been able to run their entire platform on just this sort of API. In view of the large numbers of individual traders involved, the workflow benefits of easy connectivity to back office systems are clearly considerable.
Other businesses, such as multi-region trading arcades, also benefit from this type of API. For example, rules can be defined that automatically adjust trading limit parameters based upon time or performance. New traders often have to serve a probationary period with tight limits that are gradually expanded over time if their performance warrants it; this process can now be run automatically. By the same token, risk limits across individual arcades can be automatically redistributed in accordance with local market hours and liquidity.
FIX is obviously a hugely important common standard in capital markets, but most FIX API vendors only offer the vanilla FIX engine without the option of integrated market data. For clients who have previously sourced and integrated the data feeds they require, this is not an issue. However, for everyone else it is a significant omission that is expensive to remedy. The option of integrating rich market data alongside trading activity in a single FIX API radically increases implementation efficiency and reduces time to market. Users still have all the advantages of direct connectivity to FIX-compliant order and portfolio management systems (OMS/PMS), but also enjoy completely integrated market data.
Where a buyside client is using a FIX API for DMA, the performance of their clearer's pre-exchange risk management layer becomes critical. This obviously needs to be as transparent and as fast as possible, but without compromising effectiveness. A related point is that interpretation of what a FIX message contains tends to vary from firm to firm, as does account field usage. Any FIX API provider therefore needs to be able to offer a customisation service that will modify and maintain the interface between a sellside firm and the client FIX message.
Finally, there is the question of how efficiently the FIX API provider translates and routes incoming FIX messages to individual trading venues. Ideally a lean binary format is needed, so that once an order leaves the (hopefully equally lean) risk management layer it is routed as rapidly as possible to its final destination.
Data feed API
Where trading firms need a separate data feed API, speed is obviously a major consideration but so also is the flexibility of the feed when it comes to integrating third party sources that may include more than just price or volume data. The corollary to this is whether any associated trading engine is able to recognise and use these non-standard data sources.
All this can of course be accomplished in house by individual trading firms, but this is obviously a major undertaking. A simpler, quicker and less risky strategy is to use an API provider that can offer both a flexible multi-source data feed API and a trading engine that will understand whatever it is sent by API. In
addition to conventional market data, this could include anything from economic forecasts to machine readable news.
As mentioned earlier, while a vendor's ability to offer a choice of API is important, the quality of the infrastructure that supports this is also vital. Particularly where a trading firm is accessing multiple markets as well as trading through risk managed accounts, the quality of this internal plumbing and messaging has a massive influence on overall performance.
Realistically, any API provider who cannot move messages from order initiation, through their risk management layer and to the exchange gateway in under 300 microseconds on a simultaneous multi market basis isn't a serious player. Furthermore, this has to be done consistently; delivering 50% of messages in 125 microseconds and the remainder at assorted values over 2 milliseconds is of little use to a trading operation.
The $64K question any trading firm has to ask itself is whether implementing trading infrastructure in house actually adds alpha. For some, such as those in certain high frequency niches, it may. For many others, it won't; for this second group, getting a strategy into the market faster by using a suitable API that removes all the plumbing headaches adds far more value.
Which only leaves the matter of evaluating how well possible API providers are able to balance features, speed and flexibility in accordance with the individual user's needs. Some users will be less concerned with latency than with ease of connectivity to their OMS/PMS - others vice versa. Ultimately, all any trader requires are the right tools to get the job done without paying for unneeded functionality. Simple requirement - but few API vendors can truly satisfy it...