Systematic Trading Infrastructure

12/02/10 11:14
A Systematic Trading Infrastructure consists of four main components; Market Data, Trading Models, Execution Services and Computer Systems. Creating a production ready infrastructure requires technical skills, relevant experience, and in-depth knowledge of trading and markets. There are some key things to consider when designing, developing and implementing a Systematic or High-Frequency trading infrastructure. The insight in this report comes from our experience in the field.

Design, Development and Implementation Considerations

/ Models / Implementation
Conventional wisdom holds that proven Alpha Generating Models are all you really need to be consistently profitable. It is true, without models there will be no profits. However, models are just half the battle. Implementation and data, make up the other half. The data speed needs to match the latency sensitivity of the model. In fact there is a risk/reward ratio that determines the optimal cost to data latency for a particular model. Implementation, on the other hand, is more of an art then a science. Poorly implemented models quickly run into fatal problems as models reach their half life.

Buy vs Build

Many parts of the trading infrastructure are increasingly becoming commoditized. Boutique sell side technology firms are creating excellent technologies that are worth the premiums to save time to production. Historical databases, low latency feeds, and specialized trading development software libraries are some examples. A major variable in the buy-vs-build decision is the completeness of the models in questions. When a model has a high confidence level and probability of instant success, the risk of not trading, becomes substantial.

Trading Models

Different types of models have their own special needs. High-Frequency models need to be aware of any order-cancelation fees on the various exchanges. “SloMo” models (10‘s of seconds between executions), need to take into account extra slippage on assumed fills.

Hardware

Hardware and software are becoming logically equivalent. However, decisions on the location of the hardware can get interesting. When trading on an individual exchange; co-locating the hardware is the ultimate solution. However, when the model trades on different exchanges, especially during an arbitrage or a hedge leg, the location of the hardware is more important. The location is dependent the amount of data from each location, the liquidity of each instrument, and the particular model itself. In general, the box should be at a location between both exchanges where all data has the same latency.

Software Development

There are many languages and platforms to develop the trading systems. At the end of the day, the decision comes down to implementation speed and flexibility vs execution speed. Take C#/.NET vs KDB+/Q/C++. Properly designed C# code with a proper library greatly speeds up the research/development/maintenance cycle of the trading system. C++/Q code with a KX database runs overwhelmingly faster when implementing CEP (complex event processing), especially when dealing with level 2 data.

Alpha vs Execution

Many 8+ Sharpe ratio high-frequency strategies started out as a simple execution strategy for a SloMo alpha strategy. In fact, most strategies that backtest well, can be broken down into alpha and execution strategies. When done right, each component of the strategy should be implemented with its correct programing language.. ex. Python, C# for alpha. C++, Q or OneTick for High-Frequency and execution.

Conclusion

Trading models are just half battle, data and implementation are the other half. Poor initial implementation leads to excessive down time. This down time usually occurs at the half-life of the model, when they need to be tweaked and maintained. Models with high Sharpe ratios have a new risk; the risk of not trading. The buy vs build answer is often tied the aforementioned risk. Hardware locations and software development languages/tools should be selected to match the collection of models, their latency sensitivity, and intricacies. Models tend to evolve in unanticipated ways. Therefore, they should be analyzed from the start and broken up into different components and implemented with each components proper technology.