Downloaded 270 times
Uploaded byQuantInsti
Technology Edge in Algo Trading: Traditional Vs Automated Trading System Architecture
The document discusses the evolution of trading system architectures from traditional to automated. Traditionally, trading systems consisted of components to access market data, store historical data, analyze data, input trades, and route orders. With automation and high-frequency trading, latency had to be reduced to milliseconds requiring event processing and order generation to move to servers. Architectures now feature complex event processing engines, risk management checks, standardized FIX protocols, data normalization, order routing, extensive data storage, and replay capabilities for backtesting. Overall the document outlines how trading systems have been optimized for speed and automation to facilitate high-frequency algorithmic trading.
More Related Content
Similar to Technology Edge in Algo Trading: Traditional Vs Automated Trading System Architecture
Technology Edge in Algo Trading: Traditional Vs Automated Trading System Architecture
- 1. 1 Technology Edge inAlgo Trading Sameer Kumar 14th March, 2015 FINBRIDGE 2015
- 2. 2 It's the Latency,Stupid http://rescomp.stanford.edu/~cheshire/rants/Latency.html Well known and referenced article “a network link with low bandwidth can be made better with money, but network link with bad latency cannot be helped” This was the scene in 1996, when bandwidth was the constraint. Speeds were in Kbps. Cheshire later become Wizard at Apple. Pioneering Zeroconf
- 3. 3 Misnomer – BadTerminology Would you say that a Boeing 747 is three times "faster" than a Boeing 737? Of course not. They both cruise at around 500 miles per hour. The difference is that the 747 carries 500 passengers where as the 737 only carries 150. The Boeing 747 is three times bigger than the Boeing 737, not faster. Now, if you wanted to go from New York to London, the Boeing 747 is not going to get you there three times faster. It will take just as long as the 737. In fact, if you were really in a hurry to get to London quickly, you'd take Concorde, which cruises around 1350 miles per hour. It only seats 100 passengers though, so it's actually the smallest of the three. Size and speed are not the same thing. On the other hand, If you had to transport 1500 people and you only had one aeroplane to do it, the 747 could do it in three trips where the 737 would take ten, so you might say the Boeing 747 can transport large numbers of people three times faster than a Boeing 737, but you would never say that a Boeing 747 is three times faster than a Boeing 737.
- 4. 4 Traditional Trading SystemArchitecture • Traditionally a trading system would consist of – A system to read data from the market – A storehouse of historical data – A tool to analyse historical data – A system where the trader can input his trading decisions – A system to route orders to the exchange
- 5. 5 Traditional Trading SystemArchitecture • A system to read data from the market Workshop on Algorithmic & High Frequency Trading Market Data Exchange
- 6. 6 Traditional Trading SystemArchitecture • A storehouse of historical data – Which could also be directly purchased from third party data vendor directly Workshop on Algorithmic & High Frequency Trading Market Data Exchange Data Warehouse / Storehouse of historical data Data Vendor
- 7. 7 Traditional Trading SystemArchitecture • A subset of the database is queried and stored locally for operational uses Workshop on Algorithmic & High Frequency Trading Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor
- 8. 8 Traditional Trading SystemArchitecture • The trader’s tool would then analyze current data against patterns discovered in the operational data store Workshop on Algorithmic & High Frequency Trading Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor
- 9. 9 Traditional Trading SystemArchitecture • The trader’s tool would then generate orders which will be forwarded to the order management tool Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders
- 10. 10 Traditional Trading SystemArchitecture • The order manager would then route the orders to the exchange Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders
- 11. 11 Traditional Trading SystemArchitecture • The data warehouse would also probably store records of orders sent out Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders
- 12. 12 Traditional Trading SystemArchitecture • The whole system could be broken down to three components Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders
- 13. 13 Traditional Trading SystemArchitecture • The exchange (and other data sources) – i.e. the external world Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders Exchange
- 14. 14 Traditional Trading SystemArchitecture • The server – which is mostly a data store Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders Server Exchange
- 15. 15 Traditional Trading SystemArchitecture • The applications in the trader’s pc which do all the processing Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operational Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders Application Server Exchange
- 16. 16 Traditional Trading SystemArchitecture • If data operations are simple… operational data store can be in application layer (trader’s pc) Workshop on Algorithmic & High Frequency Trading Order Manager Market Data Operatio nal Data Store Exchange Data Warehouse / Storehouse of historical data Data Vendor Trader’s tool Main Centre of operations – analyzing market data wrt to historical data in operational data store and generating orders Application Server Exchange
- 17. 17 Automated Trading SystemArchitecture • With the advent of DMA & automated trading, the following changes in architecture took place: – Latency between Event Occurrence & Order Generation had to be reduced to an order of milliseconds and lower. – Order Management had to be made more robust to handle generation of thousands of orders in a second – Risk Management had to be done in real time and without human intervention Workshop on Algorithmic & High Frequency Trading
- 18. 18 Automated Trading SystemArchitecture • To generate orders quickly, market events are now handled in the server instead of the application - in the CEP module Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange
- 19. 19 Automated Trading SystemArchitecture • Complex mathematical operations are handled in a dedicated calculation block in the server block (e.g. Options Greeks calculations) Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Maths Calc
- 20. 20 Automated Trading SystemArchitecture • The role of the application layer has reduced drastically – (i) an input screen for strategy settings Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI Maths Calc
- 21. 21 Automated Trading SystemArchitecture • The role of the application layer has reduced drastically – (ii) a monitor of position & orders Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Maths Calc
- 22. 22 Automated Trading SystemArchitecture • The role of the application layer has reduced drastically – (iii) preliminary fat finger RMS checker Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc
- 23. 23 Automated Trading SystemArchitecture • RMS is now automated and checked by the OMS before an order is generated Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS
- 24. 24 Automated Trading SystemArchitecture • Because RMS is automated, a second level of monitoring is necessary – an overall global position monitor Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor
- 25. 25 Automated Trading SystemArchitecture • With Multiple destinations being connected to the automated systems, standardized protocols (FIX) became the norm Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X
- 26. 26 Automated Trading SystemArchitecture • This also necessitated adding data normalizer block in the market data adaptors to convert data from multiple exchanges into a standard format Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer
- 27. 27 Automated Trading SystemArchitecture • Moreover, an Order Router had to be added to the OMS to route orders from the same OMS to multiple exchanges Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router
- 28. 28 Automated Trading SystemArchitecture • Regulatory requirements have complicated storage requirements – requiring storage of trade information in addition to market data Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store
- 29. 29 Automated Trading SystemArchitecture • And obviously it should be able to read information from third party vendors as well Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Data Vendor
- 30. 30 Automated Trading SystemArchitecture • Moreover, the CEP engine has its own storage requirements of event history to identify future opportunities Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Event History Data Vendor
- 31. 31 Automated Trading SystemArchitecture • Complex functionality third party applications have to be tightly integrated with all the blocks Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Event History Adaptor for third party apps – R, Matlab, etc Data Vendor
- 32. 32 Automated Trading SystemArchitecture • Independent data management tools to verify the sanity of the information have to configured Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Event History Adaptor for third party apps – R, Matlab, etc Data Retrieval Data Vendor
- 33. 33 Automated Trading SystemArchitecture • To be able to back-test strategies, two components are required: (i) replay of stored data Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Event History Adaptor for third party apps – R, Matlab, etc Data Retrieval Data Vendor Replay of stored data
- 34. 34 Automated Trading SystemArchitecture • To be able to back-test strategies, two components are required: (ii) a simulator destination instead of an actual exchange Workshop on Algorithmic & High Frequency Trading Application Order Manager Market Data Complex Event Processing engine Exchange 1 Storage Application Server Exchange Strategy Settings UI State Mgmt (PnL + Position) Order / Execution Monitor Within application RMS Maths Calc RMS Admin Monitor Exchange 2 F I X F I X Data Normalizer Order Router Back office record MktData Store Event History Adaptor for third party apps – R, Matlab, etc Data Retrieval Data Vendor Replay of stored data Simulator exchange
- 35. 35 Introduction to lowlatency • Technology – State of Art • Approach to latency improvement • Latest in Low Latency -approaches and technologies being deployed to achieve low latency
- 36. 36 Why aim forLow Latency or Lowest? • It may be necessary to lower latency just to remain competitive • The strategy demands low latency, perhaps. • It may be desirable to improve latency to stop getting picked off by competitors • With introduction of Colocations and increasing focus in remaining fastest in the market, significant capital is invested. However it can all go waste, if correct technology is not identified and implemented. • The issue is that latency is difficult to quantify. As a result the value of latency improvement, though easily understood, is extremely difficult to quantify • Lower latency systems cost a lot more to build and deploy. Hence the objective should be to find the right balance between investment and return on investment in low latency
- 37. 37 Latencies – Strategywise Citihub, 2009
- 38. 38 Current Scenario • SynchronizedMarkets – Correlated • Volumes and Trades have increased • Orders per Trade has increased drastically • Synchronized Trading Patterns • Need to increase throughput and lower latency simultaneously • CPUs not getting faster – since 2007. Only cores are being added, not the frequency. Moore’s Law is failing
- 39. 39 Performance Degradation withThroughput http://www.ibm.com/developerworks/websphere/library/techarticles/0706_lou/0706_lou.html
- 40. 40 Causes of Degradation •Massive headroom to allow for bursts typically 10:1 (like bridges and dams) • Can be triggered by a shortage of any one of it’s resources: – CPU cycles – Memory – I/O channel capacity – Disk transfers – Network transfers • Shortage of one can trigger another e.g. shortage of memory causing CPU Typical system response time against throughput and I/O thrashing • Distributed deployments add an order of magnitude more complexity
- 41. 41 Parallel computing • Amdahl'slaw, also known as Amdahl's argument,is used to find the maximum expected improvement to an overall system when only part of the system is improved. It is often used in parallel computing to predict the theoretical maximum speedup using multiple processors.
- 42.
- 43.
- 44. 44 Spread Networks Estimated roundtriptime for an ordinary cable is 14.5 milliseconds, giving users of Spread Networks a slight advantage. • In October 2012, Spread Networks announced latency improvements, bringing the estimated roundtrip time from 13.1 milliseconds to 12.98 milliseconds. • Some companies, such as McKay Brothers and Tradeworx, are using air-based transmission to offer lower estimated roundtrip times (9 milliseconds and 8.5 milliseconds respectively) that are very close to the theoretical minimum possible (about 7.5-8 milliseconds).
- 45.
- 46. 46 How to askbandwidth question “For this feed, how much bandwidth is needed to protect 99.99% of packets from loss with no more than 100 microseconds of latency to be experienced during the busy 1 second of the trading day”
- 47. 47 Indian context • Thescenario is generally broken down into colocation ( 1+ Gbps) and non- colocation ( 20+ Mbps). • Exchanges provides Tick-by-tick which may require taking separate lines.
- 48. 48 Latency Breakdown • Latencycan be broken down into the following components • L = P + N + S + I + AP – P is Propagation time - sending the bits along the wire, speed of light constrained – N is Network packet processing – routing, switching and protection – S is Serialization time - pulling the bits on/off the wire – I is Interrupt handling time – receiving the packet on a server – AP is Application Processing time
- 49.
- 50. 50 Tips • Servers –Fastest Cores, Cache, • Operating Systems – RT kernels • Fastest Network Infra (Switches, Routers ) • Retune the TCP stack (e.g. i/o buffer size ) • Program Runtime – isolcpus, stack bypass • Solid State Drives ( SSD ) • Latency Tuning – TCP_NODELAY, sendfile(2), Lock Free Codes
- 51.
- 52. 52 Thank you! To LearnAutomated Trading Email: [email protected] Connect With Us: SINGAPORE 11 Collyer Quay, #10-10, The Arcade, Singapore - 049317 Phone: +65-6221-3654 INDIA A-309, Boomerang, Chandivali Farm Road, Powai, Mumbai - 400 072 Phone: +91-022-61691400