Get best of the week

How not to lose all the money in a couple of minutes or risk management in algorithmic trading



The content of the article


Introduction


Now the situation is not simple both in the world and in stock trading. Many traders suddenly become millionaires, while others instantly lose all their money. High market volatility provides a good opportunity for algorithmic traders to earn. And in order to sleep peacefully and not to dream, black swans need to protect their accounts from furious robots and other troubles of algorithmic trading.

“The Algotrader is asleep - the trade is on! ” - some traders like to say. But the reality is not so simple. Where do you think algorithmic trading begins? From connecting to the exchange or writing an algorithm? For a professional participant, trading begins with the development of risk management .

It is believed that algorithmic trading is much more effective than classical trading. Because robots do not have emotional solutions, they are ready to work 24/7, they know exactly when to buy and when to sell, they make transactions at a speed not accessible to an ordinary person. However, by virtue of their superpowers, they create an increased class of risks.
For example, a well-known case that went down in history as  “Revenge of cars” caused losses of $ 460 million, or a broken robot caused losses of $ 4.3 million or failures on the Moscow Exchangeleading to stops and losses for traders, etc. One such incident is sufficient and trading accounts may be irreparably damaged. This is especially true if the trade is marginal, when the price of the error increases several times.

A trader cannot know how much he will earn, but he must know exactly how much he can lose. In fact, any trading comes down to risk control, and profit is a reward for observing them.

In this article, I will try to disclose, if possible, the potential risks associated with the execution of trading algorithms in real trading and measures to protect against breakdowns in the trading system. At the same time, I will not touch upon money management , diversification of the trading portfolio and the logic of trading strategies, this is a different story.

1. Architectural solutions


Before proceeding to the classification of risks, I will talk a little bit about standard solutions in the trading part of algorithmic trading.

From requirements to the speed of execution of applications, trading robots are built in different ways. If this HFT (for example, arbitrage or market-making ) is sensitive to delays, then they try to minimize the application path from the algorithm to the exchange and the account in delays is spent in microseconds. As a rule, such algorithms have a specific architecture and are optimized for a specific strategy. In this case, risk management is integrated directly into the strategy.

Basically, trading strategies are in position from a few minutes to several hours, and the less time the algorithm is in position, the easier it is to control risks. However, with an increase in the frequency of transactions, commission costs increase, which reduces the profitability of the algorithms. So trading strategies try to find a balance between risk and profit.

Trading algorithms are rarely traded one at a time. Typically, these are whole families of strategies that are collected in portfolios to diversify and stabilize the Equity curve . At the same time, exchange data for trading algorithms can come from various sources, and applications can be sent to various exchanges. At the core of the trading system are enginesthat route and optimize data between algorithms and exchanges (see Figure 1). Usually there are other engines, for example, for working with historical data or backtesting, but for the sake of simplification I do not show them.


Fig. 1. The architectural scheme for the trading server.

2. General classification of risks


  • 2.1. Infrastructure risks
  • 2.2. Problems connecting to the exchange / broker
  • 2.3. Problems in the logic of trading strategies

2.1. Infrastructure risks


The main share of problems in this class is associated with trading servers. For algorithmic trading, even a very powerful PC is not suitable for many reasons: unreliable equipment, unstable Internet connection, poor power supply, etc.

The main risks:

  • full / partial loss of server performance;
  • emergency restart of the operating system;
  • physical server failure.

The quality of solving these problems, as a rule, depends on your budget and the requirements of your trading algorithms.

2.1.1. Solution options


  • Exchange colocation. Ideal and most expensive option. It is usually used in highly profitable HFT algorithms or in large companies, for example, banks, where this infrastructure is reused for other trading solutions.
  • Virtual / dedicated server rental. If you are not a large hedge fund or a private trader, then you probably use this option. A simple, easily customizable and scalable solution. You can always find a provider that matches the price / quality parameters.
  • . . , / , .

2.1.2.


  • / . TIER III uptime 99,98% . .
  • . , . .
  • The power reserve is at least 40-50% (CPU, RAM, SSD) compared to the usual trading mode. As a rule, on strong movements in the market, the load in the data flows increases and algorithms begin to actively execute transactions. At this crucial moment, there should not be any brakes on your servers.

2.2. Connectivity issues


On exchanges and brokers, technical failures occur from time to time. For example, the operation of the trading platform of Sberbank crashed or was "underworked" on the Moscow Exchange , the exchange closed for lunch , the Moscow Exchange suspended trading due to a failure , etc.

The main risks:

  • connection breaks;
  • high delays;
  • incorrect data;
  • partial data loss.


2.2.1. Connection breaks


Connection break information can be obtained in several ways:

  • Connector Events API - Connected , Disconnected .
  • Using connection verification algorithms such as Heartbeat , which are usually present in the API.
  • Indirectly. By the lack of data in the data streams.

You can configure the connection so that if the connection is lost / disconnected, the exchange will withdraw active orders or close positions. However, you need to be careful with this functionality, since in case of short breaks, an unplanned closing of positions will more likely lead to losses and more harm than help.

Moreover, it often happens that when something breaks, it breaks completely and the first options for warning about breaks do not work and only indirectly manage to find out that something went wrong.

2.2.2. Data problems


To begin, consider the main types of stock data. Depending on the type of connector and exchange, these data do not vary much, but basically the plus or minus are the same.

Incoming changes:

  • Exchange glasses / orderbook
  • Deals
  • Applications
  • Line items
  • Balance

Outgoing data:

  • Registration Applications

Incoming and outgoing data can come from one or from different connections. It happens that one of the threads can fall off "quietly", while the rest will work in normal mode. Even if the data comes from the same source, you still need to monitor each stream individually.

Data problems are usually resolved by implementing tracking algorithms such as WatchDog . All threads must pass through these modules.

WatchDogs track:

  • frequency of data updates in the stream;
  • timestamp delays in data and current time;
  • upon the availability of data determines the presence of communication with the exchange.

If for a certain time no data has come from the connector or delays exceed the maximum allowable, then the corresponding events are generated and decisions are made on further actions.

For the correct calculation of delays, an independent system for accurate synchronization of system time must be implemented. For example, with NTP servers .

2.2.3. Solution options


If the above problems occur, the system should immediately disconnect the data streams from the algorithms and try to reconnect with the given frequency and number of attempts. It must be borne in mind that there are completely justified, previously unforeseen causes of breaks. For example, due to a shortened trading session on national holidays or an unexpected update to the API and other unreasoned scenarios. In each particular connection, reconnection must be approached individually. Otherwise, the excessive number of reconnection attempts can be perceived by the exchange as a spam attack and lead to account blocking.

After reconnecting and downloading the lost data, it is necessary to notify the trading algorithms about the restoration of work and transfer the lost data to them. Algorithms should analyze the changes that have taken place and decide what to do next. Remain in the current position, change it or close it completely. This logic should be implemented in every trading strategy.

The order of restoration of work:

  • reconnect;
  • upload lost data;
  • notify communication recovery algorithms;
  • transfer lost data to the algorithms;
  • switch streams in real time;
  • The trading logic of the algorithms should normalize their positions and re-place orders.

Similarly, in the case of problematic data or a partial loss of functionality, you must first completely restore the connection and normalize the data flows. It is impossible to trade with partial working capacity, it is obvious that this will not end with anything good.

2.3. Problems in the logic of trading strategies


The most dangerous, insidious and unpredictable problems lurk in the programmed logic of trading strategies. No matter how thoughtful trading algorithms may be, it is impossible to foresee all scenarios. Various factors and their combination can give rise to unexpected behavior. Moreover, some errors may lurk for years and "emerge" at the most unexpected moment.

2.3.1. Classification of problems


  1. Errors in applications:
    • Negative price / volume;
    • Reverse direction;
    • Wrong type, etc.
  2. API errors:
    • Not all fields are filled in the transaction;
    • Using an outdated version of the API;
    • ..
  3. :
    • ;
    • ;
    • ;
    • « »;
    • .
  4. :
    • ;
    • ;
    • .
  5. :
    • ;
    • .
  6. :
    • ;
    • ;
    • ;
    • .
  7. :
    • ;
    • ;
    • A large number of applications that do not lead to transactions.
  8. Lack of exception handling in program code of trading strategies

However, some errors may give rise to others. For example, stopping the algorithm due to a gross error will lead to a violation of the position and, as a consequence, a violation of limits.

2.3.2. Solution options


The solution to these problems comes down to controlling applications and limits of trading strategies (see section 3). Moreover, any exception in the program code should lead to an immediate stop of the problematic algorithm and the withdrawal of all its active applications.

3. Monitoring applications and limits of trading strategies


Perhaps these are the most important ways to manage the risks of the trading system. Any mistake will eventually lead to a deviation in the position, applications and cash. The task is to notice these changes as quickly as possible and take action promptly.

Checks can be divided into two types:
3.1. Basic verification of applications
3.2. Limit analysis and control

3.1. Basic application verification


All outgoing requests should be checked for:

  • gross mistakes;
  • correctness and sufficiency of data for the API;
  • compliance with the specifications of traded instruments;
  • compliance with bidding regulations, etc.

These checks are carried out before sending applications to the exchange. The sooner an error is found, the easier it will be to eliminate its consequences. Do not wait for obvious errors to come from the connector. It’s better to solve problems before they appear. In addition, sending erroneous transactions can give rise to various sanctions by the exchange.

3.2. Limit control


To control limits, the following is checked:
3.2.1. Change in balance and position before placing a request
3.2.2. Change in current balance and position
3.2.3. Price and volume of application
3.2.4. Application Behavior

3.2.1. Analysis of changes in balance and position before placing an application


Before submitting an application for registration, a potential change in the balance and position in case of execution of the application is checked. If there is an excess of the limit for this algorithm, then the order is not sent, and an error message is sent to the trading strategy.

3.2.2. Analysis of changes in the current balance and position


Limits are formed on changes in the traded volume and position on instruments for time periods: 15 sec, 30 sec, 1 min, 5 min, 15 min, 1 hour, 1 day. Constant monitoring of changes over time periods will allow you to see the deviation in behavior and stop trading, until the moment when the deviation becomes critical.

It happens that problems with the algorithm do not appear immediately. He can begin to "merge" slowly and without breaking the limits for a short period of time. You can wake up in the morning and find a significant drawdown due to one not much “broken” algorithm. Do we need it? We do not need it.

3.2.3. Price and volume analysis


Before sending the application for registration, the limit on exceeding the maximum and minimum volume in the application is checked. Unfortunately, no one canceled the arithmetic errors in formulas and calculations.

It is important, if possible, to check the deviation of the bid price from the average market price. To do this, check the price from other sources for a similar trading instrument. These checks are especially relevant if trading is conducted on an illiquid exchange or an abnormally high volatility is observed for a traded instrument.

If the changes exceed the specified limits, then applications are rejected before being sent to the exchange.

3.2.4. Application Behavior Analysis


Checked here:

  • the number of applications that do not lead to transactions;
  • number of active applications;
  • application frequency for periods of 1 sec, 3 sec, 5 sec, 15 sec, 30 sec, 1 min.

Exchanges have their own limits on the number of active orders and the frequency of their submission, if they exceed access to trading, they can be suspended. And it will be possible to normalize positions only manually.

One of the most dangerous and risky situations is when a trading robot starts to buy and sell uncontrollably, placing a huge number of orders per second. Before the robot picks up a large position or winds up a commission, this protection should work. At a minimum, she must give extra time so that other protective mechanisms can work.

These checks are carried out at several levels:

1. At the connector level.Connector protection “slows down” applications when the exposure frequency approaches the maximum. This is necessary so as not to lose access to the exchange. These measures are extreme, so it is important to correctly calculate the load on the connector in advance.

2. At the level of a trading strategy. If the algorithm exceeds its limit on the frequency of filing applications, then it is forcibly stopped with an error. In this case, all previously submitted active applications are removed.

4. Integration of risk management into the architectural solution


The integration of risk management can be divided into two main parts (see Fig. 2):

  • PRE-TRADE includes basic control of orders, control of the price and volume of the order, control of changes in balance and position before the order is submitted, the behavior of orders is also analyzed here.
  • POST-TRADE includes checks for connection breaks and the correctness of market data, constant monitoring of changes in balance and current positions is carried out, the behavior of orders is also analyzed here.



Fig. 2. The scheme of integration of risk management in the architectural solution for the trading server.

5. Logging and reporting


Do not forget that non-standard situations also occur and today they can’t do without human intervention even in highly automated systems. Therefore, if something went wrong, you must immediately notify all interested parties (traders, developers, the manager) by automatically sending messages by mail, sms, telegrams or in any other convenient way. Ideally, there should always be a duty trader who monitors the performance of the trading system.

In the event of a failure, you need to quickly find the problem, fix it and return the trading system to work. To do this, it is necessary to maintain detailed trade and system logs, especially in highly loaded systems with a large flow of applications. If the causes of the failure are not found, then the next failure can be fatal. The exchange, as a rule, does not forgive mistakes and immediately punishes the ruble.

Conclusion


Usually, they begin to “fasten” risk management to trading algorithms in the last turn, when a couple of incidents have already happened and the understanding has come that one cannot do without it.

Just as safety measures are written in blood, so risk management in algorithmic trading is written in margin calls and merged accounts.

However, if you correctly build a trading system and set up risk management, you can sleep peacefully and be sure that “ Algotrader is asleep - the trade is on! ” Good trading to

everyone!

More articles:


All Articles