Description of the process of creating the architecture of an online trading system: hedge fund analyst approach / ITI Capital Blog

ITI_Capital June 9, 2016 at 14:57

Description of the process of creating the architecture of an online trading system: hedge fund analyst approach

Transfer

We write a lot about creating trading systems and creating tools for their development (from the brokerage system API to the robot designer inside the trading terminal ). Today we will focus on designing the architecture of an algorithmic trading system - this is the topic devoted to the material from the Turing Finance blog, written by quantitative analyst of the NMRQL hedge fund Stuart Reed.

In his article, the author describes the principles of creating an architecture for a trading system that would meet the requirements of ISO / IEC / IEEE 42010 and the standards for the description of software engineering architectural systems. According to these standards, the architecture description should contain various standardized architectural approaches and support the relationship between design solutions and system requirements. We present to your attention an adapted translation of this article.

Software selection

Disputes about what is a system architecture are still underway. In the context of the topic of the article, the author suggests understanding this as an internal infrastructure, the application components of which satisfy functional requirements, can be installed, deployed and launched. Non-functional requirements can be assessed through the quality of the system itself.

Even if all functional requirements are met, this does not mean that the system is assembled efficiently. Non-functional requirements must also be considered. We illustrate this idea with an example. Imagine the following picture: the trading system that you just purchased or built on your own makes the right trading decisions. But it is designed in such a way that neither a risk management organization nor accounting reports can be assigned to it. It is unlikely that such a system can be called completely satisfying the needs.

Architecture concept

At an abstract level, the concepts and basic mechanisms of the system are described. It is desirable with a deep and detailed study. At this stage, the trading system is “packaged” into an Event Driver Architecture. That, in turn, is divided into 4 layers and two separate approaches. Each of them uses its own references and its own patterns. Patterns are generally accepted structures for achieving specific tasks.

An event management architecture is an architecture that allows you to detect, produce, and destroy events or respond to them. Events can be: real-time market movements, complex events or trends, trading signals that are ordered in one way or another.

The concept of the trading system architecture is presented in the picture:

Reference architecture

If you use a construction metaphor, then the reference architecture is the same as the design of the load-bearing wall. It can be used to create rooms of various designs. The main thing is that it meets the basic requirements of building standards. Reference architecture is a kind of model that describes general structures and mechanisms that can be used to create specific architectural software with specific requirements.

The architecture for the algorithmic trading system uses spatial architecture (SBA) and the fundamental model-view-controller (MVC) pattern as references. Practices such as operational data storage (ODS), extraction, transformation, loading (ETL) and corporate data storage (Data Warehouse) are also suitable.

Model-view-controller is a pattern that divides the application model, user interactions, and the interface into three separate parts.
The spatial architecture establishes an infrastructure in which elements of the process that are poorly interconnected and interact with each other through allocated associative memory (picture below).

Model view controller

Spatial architecture

Structural approach

At the stage of constructing the structure, the components and sub-components of the trading system are determined. The structure determines how these components will be deployed within the physical infrastructure. A UML diagram (diagram in a unified modeling language) shows which components are included and how they are deployed. The figures show the deployment diagrams: common and for each of the layers.

Architectural Tactics

Tactics deals with the quality attributes of a model. The simplest example of how the system tries to adapt to quality requirements is the manipulation of an operational data set through continuous queries. These components are capable of continuously analyzing ODS to detect and retrieve complex events. Here is a list of tactics that are used in architecture:

Disintegrator pattern in the event queue.
Dedicated memory for the queue and order of events.
Continuous Query Language (CQL) for ODS.
Data filter for incoming information.
Algorithms for the distribution of incoming and export connections to bypass congestion.
Active Queue Management (AQM) and congestion notification system.
Counting resources with the ability to scale the system.
Active backup for every single fault.
Indexing and optimizing resilient structures in ODS.
Schedule regular backups and cleanup scripts for ODS.
Transaction stories to all databases.
Checksums for each row for error detection.
Time stamped events to ignore obsolete events.
Establishment of rules for confirming order for the maximum number of trading events.
Automated trading components use in-memory databases for analysis.
Two-level authentication in the user interface to activate the connection.
Encryption in the user interface to connect.
Observation pattern for managing surveys in MVC.

This list offers only a small number of design solutions that the author of the article was able to identify during the development of architecture for a trading system. The list is far from complete. At each level of detail, new tactics are added to meet functional and non-functional requirements. The picture shows three diagrams that describe the disintegrator pattern, filter pattern, and continuous query components:

"Behavioral" look

This architecture overview demonstrates how system components and layers should interact. It is very useful when you develop scripts to test the system and understand how everything works from beginning to end. This overview consists of sequence diagrams and activity diagrams. The latter show the internal processes of the trading system and how traders themselves interact with it. Examples of such diagrams are presented below.

Techniques and frameworks

The final step in developing the architecture of the software part of the trading system is to find suitable techniques and frameworks that can be used to implement it. The general rule here is to try to squeeze out everything that is possible from existing techniques, making sure that they meet functional and non-functional requirements. The framework in this case is a reference architecture. For example, the JBoss framework implements the JEE reference architecture. Here is a list of several techniques and frameworks that can be used to create the architecture of a trading system:

CUDA is a product of NVidia. She has several products at once that support high performance for calculations in financial modeling. You can achieve a 50-fold increase in performance, for example, to simulate Monte Carlo on a GPU instead of a CPU.
Apache river is a set of tools for creating distributed systems. He found applications as a framework for SBA pattern-based applications.
Apache Hadoop - This tool offers interesting solutions for big data problems. Can be deployed in a cluster environment to support CUDA technology.
AlgoTrader is an open access algorithmic trading platform. It can be deployed where automated trading components take place.
FIX Engine is a standalone application that supports financial information exchange protocols (FIX, FAST and FIXatdl).

It should be remembered that any components (techniques or frameworks) must have an API to ensure their compatibility.

Conclusion

The proposed version of the architecture meets the most general requirements of algorithmic trading systems. For such systems, the main load is carried by three factors that act in practice in different combinations:

Dependence on the external environment and exchange systems.
Non-functional requirements.
The evolution of architectural constraints.

The proposed architecture needs to be adapted based on the movement from case to case. It must comply with specific organizational, regulatory requirements and regional restrictions. Simply put, the article presented only a list of useful links that still need to be customized for individual needs.

Other related materials from ITinvest :

Tags:

Description of the process of creating the architecture of an online trading system: hedge fund analyst approach / ITI Capital Blog