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

In our blog, we have already written about important stages in the development of mechanical trading systems, the choice of market strategies and their testing on historical data . In today's article, we will summarize the previously described information and tell you how newcomers to the stock market should approach the creation of their first trading robot to avoid common mistakes.

The choice of technology: the ability to compromise

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

• Trade speed, i.e. the execution of trade operations themselves - the speed of issuing an order, the speed of receiving a response from the exchange, the speed of processing by the robot itself
• Versatility and customizability of the robot for working with new markets, financial instruments, variants of algorithms
• The speed of development and making significant changes.

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

The concept of speed includes two different, albeit interrelated tasks. The first of them 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, right down 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

Equally important is the choice of robot architecture. Here compromises are also possible - for example, whether to make a robot “sharpened” to a specific market, an exchange gateway, a system with one algorithm, or maybe even a limited set of tools? This optimization allows you to achieve additional performance gains.

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

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

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

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

If the robot requires significant calculations that do not require carrying them out in real time, but are used to optimize the trading parameters in the background, then the use of exotic things like interpreted languages ​​Python, R etc. can be quite viable (one of them - scripting TradeScript , more about the creation of robots on it is told here and here ). There are also implementations of these tools that are compatible with .Net technology.



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

To summarize the discussion on the development environment, we can recommend the following three-tier architecture.

Stage # 1

Rather primitive, but the fastest robot, performing a simple set of operations. In essence, his task is to quickly take from the market or issue a simple or synthetic asset to the market, using 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, the "wrapper" around it. It combines the functions of a more sophisticated control of 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 back-testing and selection of parameters. This third level is not directly related to the first two trading, but there is a fundamental connection: it is here that tests of new algorithms on historical data are carried out, new parameters are chosen for the existing algorithms.

It is for testing new ideas and hypotheses on historical data (and not to observe how the trading of the tools created in the first two stages goes) the creator of the robot must spend most of his working time.



Image: chicagosean

A good development style is considered to be a situation in which an algorithm written for a third-level system “as it is”, without making changes to the code after the tests, can be transferred to the trading module. It’s worthwhile to implement this level using the technologies that allow you to achieve maximum comfort and speed of development.

There are exceptions in which the described scheme looks different - for example, fast high-frequency (HFT) robots are essentially limited to the first level, eliminating all unnecessary body kits, and complex option models may require support for computing on graphics cards, for example using CUDA. At the same time, for 80% of tasks, such a division into three levels seems to be the most justified.

Stages of creating a trading robot

The development of a robot is a cyclic process that consists of several stages.

Idea

Initially, the future algorithmic trader has an idea, an understanding of any trading process, or an awareness of the existence of inefficiencies that can be used to make a profit.

Backtesting

Subsequently, the emerging trading idea needs to be “driven away on 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 full log of stock glasses taking into account the movement of orders in them .

Cost analysis

An important stage, which newcomers to the stock market often underestimate, is to analyze both mandatory (commissions, position transfer rates, repos, etc.) and possible additional badly predictable costs (price slippage when making a deal, unanticipated infrastructure delays at strong movements in the market).



Image: GETTY IMAGES

The cumulative amount of such expenses affects the average transaction value. There are many algorithms that are on the verge of profitability, and a poor estimate of such additional expenses can create the illusion of successfully finding a grail where it is not there at all.

Writing a robot and its "combat" testing

Actually, the coding of the robot is, although very important, but still the most commonplace task (provided that the correct choice of architecture, working ideas, etc.).

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

The most effective approach is trading 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-volume transactions. Let the amounts be quite small, but the risk of real money gives a fundamentally different understanding of the trading processes - only this way can they be realized and successfully modeled in the future.

Most likely, immediately after the start of trading, the result will not be exactly the same as originally planned, so the developer will have to go back a couple of steps more than once and not two and fix something.

If the strategy has earned on small amounts of funds, but for its successful operation it is required to increase the volume, you need to gradually move towards this - there will certainly be problems and losses of funds on this path, which means you will need to again be engaged in strategy and code optimization.

In the spring of 2012, I suddenly earned extra money, not realizing where they 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 overvalued as a big plus. I earned about 1.5 million rubles, but at the same time, the profit was the reason for my serious transformation of the system, so that in the future there would be no unexpected failures.

- Deputy Managing Director of ITinvest Alexey Afanasyevsky, an interview with F & O magazine

Stable (possible) work

After some time of constant optimization, the algorithm (perhaps) 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 at this very moment the reality strikes back and forces the creator of the robot to roll back a few steps back, up to and including revising the entire trading strategy in principle.

findings

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 stock exchange, news, trading time, news release time, the relationship between economics and politics, and so on.
All these parameters will have different weight in the case of creating different types of robots - high-frequency trading requires fast execution, for a directional robot it is a good understanding of technical and / or fundamental processes, for various types of arbitration good statistical methods. At the same time, it is necessary to understand that in a pure form such a “classification of robots” does not exist - each product, to varying degrees, “climbs into a glade of different approaches at the same time.

IT professionals who would like to try their hand at creating robots must first pull up their knowledge of the stock market (this is helped by specialized literature), and only then go 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 the start of work on a trading robot, you should be prepared to create a universal tool for making money and then retire and only watch the increase in the bill fail. Algorithmic trading is an interesting, but long and continuous work to improve itself and its understanding of the world and the market as its expression. If a person is interested in doing this, the creation of robots will become just a tool for getting results, and not an end in itself.

In preparing the material, information was used from an interview with the Deputy Managing Director of ITinvest Alexey Afanasyevsky to 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 fix everything promptly.