After graduation I moved into a small, empty, apartment in the city. My grandmother, I’ll never forget, told me that moving into a new house is like meeting someone for the first time, you need to pick one room and make it yours, go slowly through the house, be polite and introduce yourself, so that it can introduce itself to you.
It is with the same logic that I like to look on the different components of an automated trading system. There are several “rooms” like the data handler, signal generators, and order management system that we need go through to better understand the overall structure.
This article will focus on the order management system, as orders form the basis of any strategy and they need to be entered and routed to the correct destinations.
Order entry
The main information that an order needs to contain are the following:
- Security identifier (example: share code)
- Order direction (Long or Short)
- Order size (the quantity of the transaction)
- Price limits (example a limit order)
- Order type (Limit, Market, Pegged, other)
- Order Conditions (Day, GTC, GTC, OPG, IOC, FOK, other)
- Type of Algorithm used (VWAP, POV, Momentum, Stat Arb)
- Order Transmission (Broker, Exchange, ECN, ATS. Using either an API or FIX gateway)
This information is usually entered via a winform by the end user but for fully automated systems no winform is required, however in both cases it is recommended to have each order object stored in a relational database for record keeping.
A smart developer would also build in validation at this step, you need to make sure you check for fat finger slips, breaches of regulation/mandate, and a second confirmation that the user wants to place the order with the details of the transaction.
You may also want to build in some pre-trade analytics or transaction cost analysis if you are building a system where a user provides the input.
Order Routing
Once the system has captured an order it then needs to route it to the required destination, you will find that most venues have their own proprietary protocol for handling orders, therefore your order routing component will need to encode each order into the correct format.
Order Encoding
Order encoding simply refers to the correct format that an order object needs to be in, in order for the other party to handle the transaction. Some venues will make use of a custom application programming interface (API), however the new de-facto standard for sending information related to securities transactions is the Financial Information Exchange (FIX) protocol. (I am not going to expand on FIX here; it is a whole topic on its own.)
Order Transmission
Once the orders have been encoded they need to be sent to the required destination. The order related information needs be sent to the venue and then info regarding the transaction needs to be sent back from the venue.
There are several checks in place to make sure that order information is correctly sent and received. The venue will run various check sums and order length so that the FIX engine can confirm that the order received matches the expected order transmitted.
“When the FIX engine makes a connection it establishes a new session. All messages sent during this session are identified by a unique sequence number. Messages should be delivered in order so if an engine receives a message whose identifier is out of sequence it can issue a resend request.” (Barry Johnson, Algorithmic trading and DMA)
Once a transaction has been executed the venue will submit a Fill event back to the OMS containing the details of the completed transaction.
Lecture notes from QuantInsti EPAT
In addition to this I went one step further by including my class notes from the QuantInsti EPAT program on OMS. The following is directly taken from the notes and may help paint a picture of the process:
The Order Manager
The order manager generates and manages orders sent from the system to multiple destinations; moreover it also performs RMS in real time before sending an order.
The input to the order manager (OM) is the signal from the signal generator (your alpha or risk model)
The outputs of the OM are orders that need to be routed to exchanges or other destinations
It also needs to send notifications back to the application
As well as writing order information into a database
The trigger is handled by the OM implementer which maintains an overall state of orders
It does the pre-order RMS (max order size, net portfolio position, max trade value, etc)
And then checks the OM queue for each destination
If the queue is free, it then orders the OM engine to prepare a packet
This information is conveyed to the app and is also noted into the database
For FIX protocol destinations, the orders are generated in FIX format
Next the order router determines the destination of the order, and forwards the message to the correct line
I hope these notes help other students out there, a large reason why I write these articles are so they act as a study technique for me to retain all the material. I would like to give credit to Barry Johnson, Algorithmic Trading & DMA, as well as the QuantInsti team that provide the EPAT program.
If there are other great blog posts or articles that you would recommend we read please add it to the comments section below.
Next Step
If you’re a retail trader or a tech professional looking to start your own automated trading desk, start learning algo trading today! Begin with basic concepts like automated trading architecture, market microstructure, strategy backtesting system and risk management in automated trading.
