The core of any successful automated trading operation involves development, deployment and support of software in three main areas:
1. pre-trade
2. trade
3. post-trade
What is pre-trade technology?
"Pre-trade" technology consists of a assorted instrument metadata identifiers and reference data tools for supported liquidity pools each with unique data formats for symbols/contracts, along with trading strategy build, calibration, back-testing and research tools.
What is trade technology?
"Trade" technology consists of market data feed parsers and order entry gateways. Exchanges, and more generally liquidity pools, offer different APIs for high-frequency/low latency and low-frequency/high latency market data feeds and order entry. The APIs will be either proprietary binary specifications or FIX Standards based and the automated trading application logic will need to integrate with these APIs.
The automated trading logic can process billions of market data messages per day, and will then make trading strategy decisions and insert order events back into the markets at latencies of single digit microseconds.
What is post-trade technology?
"Post-trade" technology consists of trade records, profit-and-loss calculators, trade settlement processing, taxes and other accounting requirements, order/trade surveillance, and order/trade capture for quantitative research.
These systems need to be deployed onto reliable infrastructure of co-located servers, high-throughput network stacks, to cloud-based platforms for scalable number crunching.
Direct Market Access API specifications
And this landscape is subject to continuous and often multifaceted change – new tradable products are created and new liquidity pools need to be accessed. The trading strategies are constantly being monitored, calibrated and tuned. The exchanges change the Direct Market Access (DMA) API specifications. The regulators change the rules. As do the tax jurisdictions.
Developers need to be extremely nimble to keep up.
Trading teams tend to work in small groups with tight feedback loops between the traders and the developers. They share in the success, or not, of the trading rewards.
The developers will be balancing between the options to develop-it-yourself (DIY) and to insource specific SDKs and libraries that provide read-to-use support functionality.
The pros and cons of DIY and insourcing Software Development Kits (SDKs)
Each of DIY and insourcing has pros and cons.
A major DIY pro is that custom code that is tightly scoped and can be optimised for the specific requirements, will do that job quickly and efficiently.
On the major cons side is slow speed to market and high development costs. Such custom code development takes time to design, build, test, deploy and also includes ongoing maintenance overheads.
The major pros of insourcing SDKs are reduced developments costs to build, improved rapid speed to market, and significantly reduced ongoing code maintenance overheads as the SDKs support exchange API changes.
On the cons side any general use SDKs/libraries are designed to cover a range of use cases and can be less optimised to specific use cases. So can be, but are not always, less performant than highly tuned DIY solutions.
Developing low level DMA protocol SDK components
Generally the trading strategy and business logic will be the key differentiator for a trading operation to succeed, or not. And it is that area in which development resources should spend most time. The optimal approach is to not burn time and money developing low level DMA protocol SDK components for the required markets. It is much more efficient to insource those and concentrate on the trading logic.
That is where the OnixS SDK offerings provide compelling benefits. Try the OnixS fully functional SDK evaluation distributions. They are designed specifically to address this solution space.
