Currently I am taking a class about software architectures. For this class each student chooses a system, defines its architectural requirements, and designs a solution capable of satisfying those requirements. I chose an algorithmic trading system because of the technological challenge and because I love financial markets. Algorithmic trading systems (ATs) use computational algorithms to make trading decisions, submit orders, and manage orders after submission. In recent years ATs have gained popularity and now account for the majority of trades put through international exchanges. Distinction is made between programmed trading and algorithmic trading. Programmed trading involves breaking up large markets orders into packets of smaller shares. In this article, programmed trading is considered a security requirement of an ATs.

Algorithmic trading systems introduction

Speaking generally, there are five types of market participants: retail investors, proprietary traders, market makers, buy-side institutions, and sell-side institutions. ATs are most used by proprietary buy-side institutions, but this dynamic is changing. Algorithmic trading as a service (ATAAS) makes algorithmic trading accessible to the retail investor (see appendix). This article describes the architectural requirements for an ATs used by a proprietary buy-side institution. At the top most level, an ATs has three functions: make trading decisions, create trading orders, and manage those orders after submission. Beneath these there are a host of more detailed functional requirements, some of which may be satisfied by the architecture.

Software architecture introduction

A lot of debate still surrounds the definition of what a software architecture is. In the context of this article, software architecture is defined as the infrastructure within which application components providing user functionality can be specified, deployed, and executed. A software system should satisfy its functional and non-functional requirements. Functional requirements specify the functions of the systems' components. Non functional requirements specify measures through which system performance is measured. A software system that satisfies its' functional requirements, may still not meet user expectations e.g. an ATs that can submit trades, but not in a timely manner, would cause financial losses. The software architecture basically provides an infrastructure which satisfies the non functional requirements, and within which components that satisfy functional requirements can be deployed, and executed. Algorithmic trading system requirements can therefore be broadly be divided into functional and non-functional requirements.

Functional requirements

Beneath the 'make trading decisions' top level requirement there are three high level requirements:

1. Get market data - download, filter, and store structured and unstructured data. Structured data includes real time market data from Reuters or Bloomberg transmitted using a protocol e.g. FIX. Unstructured data includes news and social media data.
2. Define trading strategy - specify new trading rules and strategies. Trading rule consist of an indicator, an inequality, and a numerical value e.g. "PE ratio" < 10. Trading rules are structured into a decision tree to define a trading strategy (illustrated below).
3. Analyze securities against trading strategy - for each security, obtain data and filter it through the trading strategy to determine which security to buy. Additionally: for each open position, determine which security to sell. Note: this requirement could vary.

Beneath the 'create trading orders' top level requirement there are two high level requirements:

1. Get trade information - for each decision, get the security symbol, price, quantity, etc.
2. Create trading order - for each decision, specify an order type and add trade information. There are six order types: long, short, market, limit, stop, and conditional.

Beneath the 'manage orders' top level requirement there are three high level requirements:

1. Manage pending orders - for each order, validate and confirm that order
2. Route / submit orders - route each order to an exchange, dark pool, or brokerage
3. Manage submitted orders - track status of each submitted order, if order is matched then create an open position. If order is not matched then stop that order.

Non-functional requirements

There are many non functional requirements which are traded off between each another e.g. increased performance often comes at an increased total cost of ownership. Non-functional algorithmic trading system requirements include,

• Scalability - is the ability of a system to cope and perform under an increased or expanding workload. An ATs should be scalable with respect to the number of data feeds in processes, number of exchanges it trades on, and the securities it can trade.
• Performance - is the amount of work accomplished by a system compared to the time and resources required to do that work. An ATs should have quick response times (back to the market) and high processing and network throughput.
• Modifiability - is the ease with which the system can be changed. An ATs should have easily modifiable trading strategies and data processing
• Reliability - is the accuracy and dependability of a system to produce correct outputs for the inputs it receives. Because errors and bugs in an ATs can result in huge losses and fines, reliability is crucial. See the Knight capital debacle for evidence of this.
• Auditability - is the ease with which the system can be audited. Recent high profile cases of ATs going haywire have put ATs' in the spotlight for audit firms. They should therefore be auditable both from a financial, compliance, and IT point of view.
• Security - is the safety of an organization against criminal activity such as terrorism, theft, or espionage. Because trading strategies are proprietary and represent valuable intellectual property they must be secured. Additionally, to protect the ATs from hunted, orders should be obfuscated using programmed trading strategies.
• Fault tolerance - is the ability of a system to continue operating properly after a fault or failure. This is similar to reliability, except that the ATs should continue to be reliable even after a fault to avoid financial losses.
• Interoperability - is the ease with which the system is able to operate with a diverse range of related systems. This is important for an ATs which may be required to interface with order management systems, portfolio management systems, risk management systems, accounting systems, and even banking systems.

Overview of architectural scope

The architectural scope is the set of services supported by the architecture which are consumed by components to meet their functional and non functional requirements. A more detailed breakdown of this architectural scope is available in the detailed requirements document. At a high-level the following services would need to be provided by the architecture:

• A modifiable data pre-processing environment - which supports multiple data streams, filters for irrelevant data, and temporal data partitioning
• A distributed processing environment - which supports multiple processing units (clusters), real-time performance monitoring, a message oriented communication framework, scheduling of temporal data sets, load balancing, and data replication
• Individual processing units - which supports in-memory queues, and complex event processing (on temporal data)
• A storage area network (SAN) - which supports temporal data aggregation, continuous querying, and logging (for audit trails)
• A data recovery (DR) environment - replicates the SAN and order management system
• An integration environment - which exposes a standard API for components and connects internal and external components to one another
• An order management system - which supports concurrent input streams, passive redundancy and load-balancing, ACID criteria on orders, an audit trail, and is replicated
• A system usage environment - which supports multiple user profiles and exposes a fully managed front-end to the algorithmic trading system

Access and integration requirements

Access requirements describe ways in which users may access the system's components. An algorithmic trading system should expose three interfaces: an interface to define new trading rules, trading strategies, and data sources; a back-end interface for system administrators to add clusters and configure the architecture; and a read-only audit interface for checking IT controls and user access rights. Pre-requisites for integrating between components and external systems are called integration requirements. The algorithmic trading system should support file based integration, message based integration, and database integration. As such, the following requirements should be satisfied by the architecture:

• Database integration - support ODBC, JDBC, ADO, and XQC
• File based integration - support CSV, XML, and JSON files
• Message based integration - support FIX, FAST, and FIXatdl

Architectural constraints

Architectural constraints are factors which constrain the performance of the architecture being built. The two constraints I will mention here are physical network constraints, and regulatory constraints. Physical network constraints are placed on a system as a result of poor telecommunications networks. To mitigate this constraint the system should be built where network latency is minimized. Another way to mitigate network constraints is to co-locate the algorithmic trading system with the market exchange. That having been said, the decision to co-locate introduces additional processing and space constraints.

Regulatory constraints are introduced through laws and regulations, which are mostly country and exchange specific. This is an increasingly important factor in the design and implementation of an algorithmic trading system because algorithmic trading is becoming more regulated after the 2010 flash crash. Speaking generally, an ATs should at least comply with the the SEC's rules regarding system compliance and integrity (SCI), the EMEA guidelines for algorithmic trading systems, the ISO 9000 algorithmic trading standards (AT9000), and the international financial reporting standards (IFRS).

Conclusion

Algorithmic trading system architectures are complicated by the strict non functional requirements expected of the system and the wide range of regulatory and compliance requirements governing automated trading. Because of these complexities, careful consideration should be paid to the design and implementation of the system architecture. In designing an open source algorithmic trading architecture I hope to point out those architectural requirements that are often overlooked at the onset of designing such systems. The requirements identified in this document are unlikely to be complete and will inevitably evolve over time. The second installment of this article will include my design for a software architecture meeting the above mentioned requirements. For more information about algorithmic trading, please feel free to contact me.

To download a copy of my report please click here. For a full list of sources please see the report

Appendix

ATAAS service providers include, but are not limited to:

1. Quantopian.com - users define quantitative trading strategies in Python and can back-test them. Users can also execute those strategies on live markets. Quantopian recently received a 6.7 million USD investment to extend their services.
2. EquaMetrics - using RIZM users visually build new algorithmic trading strategies, back-test those strategies, and execute those strategies on live markets. EquaMetrics recently announced new funding for RIZM valued at 4.5 million USD.
3. Brokerages - some brokerages allow traders to create trading bots which automatically execute their trading strategies.