fication). The timestamps, the sizes and the dispersion of orders should confirm/negate the fact that the compared strategies act on the same or similar underlying market patterns. At the same time, a similar execution latency, measured at the same location and the same machine, should at least strengthen the assumption of similarity of the underlying functionalities.
2.4
System Architectures for AT
Algorithmic Trading and risk platforms can be considered three-tier systems, where the first tier consists of external communication elements, the second tier is responsible for internal communication, and finally the third layer provides the actual business logic. Cisco’s Trading Floor [Risca, 2008] presents a good representation of a typical architecture of a trading & risk system.
Figure 2.3: Cisco Trading Floor Architecture [Risca, 2008], where ECN is an acronym for Electronic Communication Network.
2.4.1
External Communication Layer
The bottom layer of the Cisco’s Trading Floor represents a wider, external communication layer and a low-level hardware & network architecture of the trading floor. This also comprises the external sys- tems with which the trading floor exchanges information. The performance of the platform depends on various interrelated factors with the most important one being the speed of the underlying hardware and networks. Consequently, when considering the architecture of this type of financial systems, the emphasis needs to be put on the hardware and connectivity. Apart from the hardware and network, the operating systems on which the platform relies must also be chosen with care. In majority of cases the platform is distributed amongst many servers in a cloud (the operating system on the servers needs to be able to deliver such distributed functionality). When speed is of essence (and in majority of cases it is),
2.4. System Architectures for AT 31
the customization of the underlying hardware, software and network architecture is paramount. One can consider dedicated hardware for specific needs of either a fast execution, storage or multi-processing. Kernels of utilized operating systems can be tailored to specific needs of the underlying hardware as well as the platform. All the unnecessary drivers may be removed, and the kernel may be optimized and recompiled to support a particular need. The network architecture may also be optimized by reor- ganization of its structure, collocation of services with markets and exchanges, and also by utilization of dedicated connection lines. In addition to the architecture and organization of the network, the com- munication protocols also play a major role; they need to be able to transport information - quite often a substantial volume of it - in the quickest possible way, with a guaranteed delivery.
The Cisco’s Trading Floor also defines the external communication layer from the data-streams perspec- tive, and it specifies the ’market data’ stream and the ’trading orders’ stream. The ’market data’ stream [Risca, 2008]”carries pricing information for financial instruments, news, and other value-added infor- mation such as analytics. It is unidirectional and very latency sensitive, typically delivered over UDP multicast. It is measured in updates/sec. and in Mbps. Market data flows from one or multiple exter- nal feeds, coming from market data providers like stock exchanges, data aggregators, and ECNs. Each provider has their own market data format. The data is received by feed handlers, specialized applica- tions which normalize and clean the data and then send it to data consumers, such as pricing engines, algorithmic trading applications, or human traders”. The ’trading orders’ stream [Risca, 2008]”is a type of traffic that carries the actual trades. It is bi-directional and very latency sensitive. It is measured in messages/sec. and Mbps. The orders originate from a buy side or sell side firm and are sent to trading venues like an Exchange or ECN for execution”.
2.4.2
Internal Communication Layer
The middle layer of the Ciscos Trading Floor is a service layer that allows internal communication within the platform. The internal communication is a backbone of every enterprise-size platform. It needs to be reliable and fast, it also needs to be flexible and modular. The internal communication is necessary as a result of the distribution of elements of the platform. A modern approach to development of trading & risk platforms incorporates both the service and event-oriented methodologies.
From the functional point of view, the internal communication layer of an enterprise trading & risk environment can be divided into three types of application components: the components that produce information, the components that consume information and the components that both publish and sub- scribe. Every middleware communication bus provides multiple data streams (queues or memory-less topics) that allow communication of publishers with subscribers. Such data streams ensure that groups of subscribers receive only the relevant information provided by the groups of publishers connected to a particular data stream.
2.4. System Architectures for AT 32
2.4.3
Business Logic Layer
The top layer of the Ciscos Trading Floor describes the logic behind all the modules of the platform. Typically, this includes: the connectivity engines, data aggregation units, data processing elements, or- der management & routing, execution elements, trading strategy elements, graphical and programmatic interfaces, monitoring tools and many more, depending on the requirements and specification. These are described below.
The FIX (Financial Information eXchange) Engine module:The most common format for the order and market data transport is the FIX protocol ([Cameron, 2009]). The applications which handle FIX messages are called FIX Engines. They are designed to send/receive high volumes of FIX messages, translate the messages to relevant internal formats of the architecture and interface it to all the relevant modules of the platform. The FIX Engine must be able to handle multiple streams at once, and be able to deal with reconnections, requotes and message synchronization issues. The FIX Engine also needs to be capable of handling different versions of the FIX protocol and non-standard FIX messages customized by the information providers.
The Feed Handlers:When the market data is handled by the FIX Engine and passed to the rest of the elements of the system, it needs to be cleansed, processed and aggregated. The Feed Handler module provides functionalities to clean the data from outliers, gaps and other statistically significant problems to make sure that the data is of high quality. The Feed Handler module is also responsible for processing the data to provide data analytics. It also provides aggregation facilities to store the cleansed and processed data in the database, for a future use by other elements.
The Price Engine:According to ([Consulting, 2008]), the goal of the engine is to allow an automatic pricing of securities, using inputs from different market sources and adopting financially consistent pric- ing models. The Price Engine needs to be designed to support concurrent, real-time calculations for hundreds of assets at the same time. The engine leverages the robust financial models and they need to allow only a minimal number of market operations to efficiently control large amount of securities. The engine processes prices from different sources, and performs data compression and filtering to obtain an internal best price upon which all subsequent calculations are based. When the reference securities change their market prices, the engine handles the logical dependencies, sending recalculation signals to the correct models and instruments.
The pricing models utilized in the engine generate prices for the target assets using one or more bench- mark securities. Usually, benchmark instruments are chosen for their high liquidity and because they consistently represent market variations. The Price Engine models map the benchmark variations into price variations, for the target security, by applying a pricing parameter. The financial meaning of the pricing parameter depends on the model. All pricing models in the Price Engine should be automatically
2.4. System Architectures for AT 33
calibrated to the market prices. This automatically defines the pricing parameter in order to reproduce the market best prices.
The Risk Modelling:The risk engine ([Kumar, 2009]) is a management system designed to identify all significant risks associated with a given set of assets. The engine provides a set of comprehensive measurement tools to assess, control and communicate risk. It incorporates the advanced statistical anal- yses, the proprietary valuation models provided by the Price Engine, and the advanced data aggregation provided by the Feed Handler module.
One of the goals of the engine is to identify and manage a risk exposure within a given portfolio of assets and calculate the full Profit and Loss (P&L) distribution at every level of exposure. Understanding financial risk requires more than one single number. Therefore, the engine needs to be able to provide a robust analytical framework to calculate and communicate a variety of statistics and measures. The engine often contains an analytical suite including a library of historical market-stress scenarios, as well as a set of functionalities, to evaluate trading asset sensitivities to a variety of selected risk factors. The Risk Engine uses a robust analytical framework that includes a Monte Carlo simulation-based Value-at- Risk (VaR) analysis as well as other risk measures available, such as exposures and sensitivities to ’the Greeks’ (delta, duration, gamma, etc.).
The Order Management:The Engine (sometimes called Order Management System, OMS) is used for a rapid order entry and processing. It facilitates and manages the order execution, typically through the FIX Engine. The Order Management systems often aggregate the orders from different channels to provide a uniform view.
The engine allows input of single and multi-asset orders to the system for routing to the pre-established destinations (often through a Smart Order Routing module). Apart from issuing the orders, the engine also allows to change, cancel and update orders. Additional functionality of the engine is an ability to handle execution reports and an ability to access information on orders entered into the system, including detail on all open orders and on previously completed orders.
The Algorithmic Trading:The module supports the use of trading strategies that issue and manage orders with use of an embedded logic coded within the algorithm of the strategy. This allows the logic of the algorithm to decide on aspects of the order such as the optimal timing, price, or quantity of the order. The module supports a variety of strategies, including market making, inter-market spreading, arbitrage, directional or pure speculation. The investment decision and implementation may be augmented at any stage and is usually supported by the analysis of data provided by the Feed Handlers, the Price Engine, the Risk Modelling and the Order Management. The module plays a role of a manager of all the handled strategies, providing functionality to enable/disable selected strategies and modify factors of the strategies that are being executed.