System Architecture Of Automated Trading Systems

Introduction

In this post we will look at a basic system architecture of fully
automated trading systems.
An algorithmic trading system is a program that automatically trades
stuff on a market. This stuff could be anything ranging from
derivatives to forex.
Today nearly all brokers provide an API for automated trading.
Many proprietary trading desks plug their own software to these
brokers. For example you could have a VBA-macro in your excel file
that is plugged to an exchange. Then you see the current price in your
spreadsheet and are able to trade through excel.
In this post I want to talk about fully automated trading. So the
trading signals are not generated by humans but instead
algorithmically.
You should know a little bit about object oriented programming to
understand this article. My approach is to explain the objects in the
order of information flow, except the logging facilities.

Price Stream

The first important part of an algorithmic trading system is the price
feed. This is basically a separate thread which streams the current
prices from the exchange. Mostly this works via HTTP streams or the FIX
protocol.
A more advanced price handler could even provide the whole order book.
Sometimes these prices cover multiple financial instruments. On
these price signals the rest of the trading system depends.

Trading Strategy

The trading strategy is the heart of a trading system. It receives the
prices and generates buy or sell signals. This module is perhaps the
most closely guarded secret of any fund.

Risk Management module

Before executing the buy or sell signals the risk management module
determines if the orders are in line with risk management objectives.
The risk management module also determines the order size. This could
be according to any criterion, e.g., the (fractional) Kelly criterion.
When
trading multiple instruments a portfolio class could also be
incorporated in the risk management.
The risk management module creates other events which are processed by
the execution handler.

Execution Handler

Finally we can execute the order. If we have a big order simply buying or
selling all in one go is a bad idea, since then we suffer
significant slippage. To this end we have an algorithmic execution
handler. Here we can offer more sophisticated execution algorithms
trying to match a benchmark like VWAP, TWAP oder POV.
If trading on multiple exchanges, for example in the case of arbitrage
trading, the execution handler also has to incorporate a routing
object which is responsible for routing the orders to the best
exchange.

Logging facilities

Throughout all of these modules there have to be logging facilities
and perhaps a graphical user interface to see the current state of the
system. This should provide accounting to see and evaluate the
performance of the system. Furthermore it could help to restore the
current state of the system if it crashes. Another obvious reason to
have this module is to help in tracking down errors.