How-to: What to consider when developing the first trading robot

In our blog, we already wrote about the important stages of developing mechanical trading systems, choosing strategies for working in the market and testing them on historical data . In today's article, we will summarize the previously stated information and talk about how newcomers to the stock market should approach the creation of their first trading robot in order to avoid common mistakes.

Choice of technology: the ability to compromise

Almost always, when creating software products, developers one way or another have to make certain compromises and seek a balance between several things. In the case of trading robots, three factors play an important role:

• Trading speed i.e. the execution of the trading operations themselves - the speed of the application, the speed of receiving a response from the exchange, the processing speed of the robot itself
• Versatility and customizability of the robot to work with new markets, financial instruments, algorithm options
• Development speed and significant changes.

In those cases where the speed is most important, the code should certainly be written in an effective low-level language. For these tasks very well suited and pure C ++ C (the use of C ++ in our interview told the developer of the terminal SmartX ). It also happens that fast robots are created almost in assembler - here it is worth mentioning the mechanisms of direct reading and writing data to the memory of a network card, bypassing the standard mechanisms of working through drivers, as well as working with "superfast programmable hardware" like FPGA.

The concept of speed includes two different, albeit interrelated tasks. The first of these is the optimization of the speed of interaction with the exchange (placing orders, receiving answers). For its successful solution, it is necessary not only to optimize the code and have good hardware, but also to take into account and use the features of the exchange architecture, up to the rack in which the server is located. The second task is to optimize the logic of the trading application itself.



Image: Businesswire

Architecture and Development Environment

An equally important point is the choice of robot architecture. Compromises are also possible here - for example, whether to make a robot “tailored” to a specific market, an exchange gateway, a system with one algorithm, or maybe even with a limited set of tools? Such optimization allows you to achieve additional performance gains.

Conversely, a more versatile product can increase the speed of development, as well as facilitate the use of the robot, but probably among the minuses of this approach will be lower productivity.

The type of future robot and the nature of the algorithms used are no less important in the choice of technologies. If you plan to create a high-frequency robot, then the use of C ++, and sometimes C, becomes simply necessary.

In the event that you need to automate a trading strategy that involves a small number of transactions (working according to the scheme “not be the fastest, but the smartest”) and the amount of “slippage” when entering a position can be negligible compared to both possible profit and and with a possible loss, the speed and ease of development come first.

Another compromise between the speed of work and the speed of development is .Net in any of its forms - C #, Visual Basic, and generally anything on this platform (this topic was also discussed in one of our previous materials ).

If the robot needs significant calculations that do not require real-time performance, but are used to optimize trading parameters in the background, then exotic things, such as interpreted Python, R languages ​​and the like, may also be viable (one of them - scripted TradeScript , more about creating robots on it is described here and here ). There are also implementations of these tools that are compatible with .Net technology.



An example of creating a simple trading strategy on TradeScript in the SmartX terminal.

To summarize the conversation about the development environment, we can recommend the following three-level architecture.

Stage # 1

A fairly primitive, but as fast as possible robot that performs a simple set of operations. In fact, its task is to quickly take from the market or to issue a simple or synthetic asset to the market, according to an extremely simple algorithm. This level is written in C, C ++, and assemblers of different levels.

Stage # 2

The control system of the parameters of the first level robot, a "wrapper" around it. It combines the functions of more complex control over the operation of the algorithm and the user interface, which includes control parameters and mechanisms for presenting trading results. You can implement such a product in C ++, C #, Java, or in general as a web application.

Stage # 3

System for back testing and selection of parameters. This third level is not directly related to the first two traders, but there is a fundamental connection: it is here that tests of new algorithms on historical data are carried out, new parameters are selected for existing algorithms.

It is for testing new ideas and hypotheses on historical data (and not for observing how the instruments created in the first two stages are being traded) that the robot creator should spend most of his working time.



Image: chicagosean

A good development style is a situation in which an algorithm written for a third-level system “as is”, without making changes to the code after testing, can be transferred to the trading module. It is worthwhile to engage in the implementation of this level using those technologies that allow us to achieve maximum comfort and development speed.

There are exceptions in which the described circuit looks different - for example, fast high-frequency (HFT) robots are essentially limited to the first level, excluding all unnecessary body kits, and complex optional models may require support for calculations on graphic cards, for example, using CUDA. Moreover, for 80% of tasks, such a division into three levels seems to be most justified.

Stages of creating a trading robot

Robot development is a cyclic process that consists of several stages.

Idea

Initially, the future algorithmic trader has an idea, an understanding of a trading process or a realization of the inefficiency that can be used to make a profit.

Backtesting

Subsequently, the emerging trading idea needs to be “driven away by history” - depending on the specific trading approach and timeframe, different historical data can be used for this - both “rough” candles, a tick sequence of transactions, and even a complete log of exchange glasses taking into account the movement of orders in them .

Cost Analysis

An important stage that newcomers to the stock market often underestimate is the analysis of both mandatory (commissions, position transfer rates, repos, etc.) and possible additional poorly predicted expenses (price slippage during the transaction, unforeseen delays in infrastructure at the time strong movements in the market).



Image: GETTY IMAGES

The cumulative amount of these costs affects the average transaction value. There are many algorithms that are on the verge of profitability, and a poor assessment of such additional costs can create the illusion of a successfully found grail where it is not in sight.

Writing a robot and its “combat” testing

Actually, coding a robot is, albeit a very important, but still the most banal task (subject to the right choice of architecture, working idea, etc.).

After writing the robot and debugging it (for this you can use the test access to the exchange with virtual money), the practical use of the algorithm begins.

The most effective approach is to trade for real money even during the testing period of the robot - you need to allocate a certain budget (you can say goodbye to it in advance) in order to be able to test the strategy on small transactions. Let the amounts be very small, but the risk of real money gives a fundamentally different understanding of trading processes - the only way they can be realized and successfully modeled in the future.

Most likely, immediately after the start of trading, the result will not be exactly what it was originally planned, so the developer will have to go back a couple of stages more than once or twice and fix something.

If the strategy has earned on small amounts of funds, but for its successful work it is necessary to increase the volume, you need to gradually move to this - there will also be problems and losses of funds on this path, which means that you will have to deal with optimization of the strategy and code again.

In the spring of 2012, I suddenly made extra money without understanding where it came from. It turned out that I had the wrong dollar hedge. At that moment, there was a strong movement on the RTS index, and my “basket” was overestimated as a big plus. I earned about 1.5 million rubles, but at the same time, the profit served as an occasion for me to seriously transform the system so that there would be no unexpected failures in the future.

- Alexey Afanasevsky, ITinvest Deputy Managing Director, interview with F&O magazine

Stable (possibly) work

After some time of constant optimization, the algorithm (possibly) will begin to consistently show acceptable results - this stage is fraught with a decrease in concentration (dreams of sports cars, yachts and villas in warm countries appear very quickly). It often happens that it is at this moment that reality strikes back and forces the creator of the robot to roll back several steps, up to revising the entire trading strategy in principle.

conclusions

In order to succeed in creating trading robots, it is necessary to take into account many factors: technology, platforms, gateways, mathematics, hardware, distance to the exchange, news, trading time, news release time, the relationship between economy and politics and so on.
All these parameters will have different weight in the case of creating different types of robots - for high-frequency trading you need fast execution, for a directed robot - a good understanding of technical and / or fundamental processes, for different types of arbitration good statistical methods. It should be understood that in pure form such a "classification of robots" does not exist - each product, to varying degrees, "crawls into a clearing of different approaches simultaneously.

IT professionals who would like to try their hand at creating robots need to first tighten their knowledge about the structure of the stock market (specialized literature helps in this), and only then proceed to the stage of writing code and experiments. On the way to creating a robot that achieves results, mistakes and financial losses are inevitable.

In any case, even before starting work on a trading robot, you should be prepared to create a universal tool for making money and then retire and only observe the increase in your account. Algorithmic trading is an interesting, but long and continuous work to improve yourself and your understanding of the world and the market as its expression. If a person is interested in doing this, then the creation of robots will become only a tool for obtaining a result, and not an end in itself.

In preparing the material, information was used from an interview with the deputy managing director of ITinvest Alexei Afanasyevsky for F&O magazine.

Picture on teaser: modernmarketsinitiative

PS If you notice a typo, a broken link or other inaccuracy, write us a personal message and we will quickly fix it.