After The 9 Steps

Published at 1728213359.462966

The 9 Steps to Develop Algorithms is mandatory to achieve the first live algorithm. Soon after, there will be a need to improve a system with multiple live algorithms. The following are the next 6 advanced steps that algorithmic traders may consider to develop after “The 9 Steps”, making a total of 15 Steps to elevate the trading system to a new level.

1. Monitoring System 

System monitoring may not be vital for a single algorithm system with minimal daily orders like smart beta strategy. Though, in the context of complex portfolios and high frequency trading, algorithmic traders will absolutely lose track of the current status of the portfolio without an internal monitoring system. For instance, a pair trading strategy that opens and closes hundreds of positions every day is surely cannot be monitored by common sense.   

In addition to tracking portfolios and orders, a monitoring system can assist algorithmic traders monitoring in other important aspects including:

  • Live_run bugs 

  • Price hub

  • Network latency

  • System speed

Thus, a monitoring system may be the very next step after an algorithmic trader had successfully achieved the first live run algorithm.

2. Live Configuration 

It is quite common that an algorithm may need to be improvised some key parameters through time or allowing experts to interfere at some point in time especially with semi-automated trading algorithms. Without an upgrade, any change of parameter may need to stop the live running code, change the parameter then start it all over again. 

This method does work though it brings along a lot of downside effects. First, the system had to be stopped for any change of parameter. This will reduce the efficiency of the system. Also, it affects data integrity if the stop frequency is high enough. Second, errors in the adjustment process will become much more likely since it is direct code adjusting which is counter-productive in terms of system development. Not to mention, critical errors will likely happen sooner or later because to be human is to err. Third, it will make the system extremely hard to collaborate since the code is not a stable version and any adjustment will always need someone who is familiar with the code base. 

To solve this issue, a live configuration feature such as a website needs to be deployed. This feature will not only solve all the downside risks but also enhance flexibility of the system.   

3. Multi-Algo Optimization 

This topic had been describe thoroughly in 3 following topics:

4. Speed Optimization

For some algorithms, the better the speed, the better the efficiency. There are many part to optimize speed of an algorithm including:

  • Choice of data source

  • Choice of network

  • Choice of data storage

  • Choice of data processing

  • Choice of brokerage’s API

For an algorithmic trading firm, any choice should be made carefully based on data because measuring speed in milliseconds is not a technical challenge anymore. In the Vietnam stock market, an optimal choice may not hold for long, thus regular evaluation is a good practice. 

5. Risk Control

In the development process, there will always be errors. This should be aware as a must not a probability. Errors may come in many forms such as: internal system errors, third party errors, data errors, or human errors. Many errors may happen only in extreme conditions that pass all the test cases. Thus, identifying these errors to minimize risk may be the first thought though it is almost impossible to prevent all of them as the system architecture may never prevent some things that have never happened before.

A risk control system is a recommended approach to identify potential error signals then actively freeze the system until the issue is verified and resolved. At Algotrade, there are 3 layers of risk control: semi-auto risk control, automatic algorithmic risk control and full system risk control. 

6. Disaster Recovery

No matter how robust a system is, a black swan event will eventually occur at the most unexpected moment. Without a disaster recovery system, everything will become so fragile at the point of crisis. Operations may shut down completely, code may be lost, data might be encryted. Resolving such issues could take months. Therefore, implementing a disaster recovery system with following key features is highly recommended:

  • At a different location with the current operation server.

  • Automation update data from the code base.

  • Prevent overwriting on core system code base (anti ransomware).

  • Fast deployment time (less than 24 hours) for production after disaster.

Disaster recovery systems should be invested for sustainable growth of the algorithmic trading system. The ideal scenario is, of course, it will never need to be used.

 

At Algotrade, we believe that after implementing all 15 steps in live operations, we have achieved our first stable system. We hope that our tacit knowledge may be beneficial for others pursuing a similar path.