The anatomy of a trading bot

 

In our blog, we will provide useful information for everyone about how to use the Trading bot, what should be considered in this process and why it should be used.

 

Table of Content

The anatomy of a trading bot

Start with the simplest case

Interlude: API connection

Introducing a real architecture

Ability to scale horizontally

The last level for backtesting

 

Finding your own trading bot in Python is not that far off as we suggest. This article, it will be given you important information on how you can improve the trading bot and why you should use them. As you know, a trading bot is something that receives data from sources and makes commercial decisions based on this data. The decisions for selling and buying end up buying and selling orders that are sent to an exchange for execution. At this point, we will focus on the structure and architecture of a bot like that. If you create the framework decoupled from the strategy, you can more easily change the strategy without having to change other things. Trading strategies are things that are not static and can change over time. If you want to constantly develop new strategies and test them, these methods will help you speed up your process much more.

 

In order for the benefit of everyone, here I will show the structure I developed in my bot. We will go step by step so that every detail is understandable. I will build from the simplest version to the full production version, adding parts and layers at each step. Let's start with the simplest case.

 

Start with the simplest case

 

In its simplest form, a trading bot receives data from the exchange and reads it, generates the logic of the trade, and then sends back the final updates to the exchange. Also, the trading bot needs to have something to do with the current positions. However, for the position, the exchange will only store your net position. So if you have multiple positions open at the same time, or even open and long simultaneously, there is no alternative to store this information locally yourself.

 

Interlude: API connection

The most common crypto-exchange APIs usually have 2 parts. These are classic endpoints that forward data to you on-demand, and WebSocket connections as real-time as soon become available. You probably want to use both in a production-ready trading bot. Orders and order updates are usually sent to the exchange via endpoints. You can then query regularly to get updates on orders. 

 

Introducing a real architecture

 

I will touch on another important point in bot production. This would be to separate the cleaning part from the trading logic. To be clear, this means introducing a framework around sanity checks and general cleaning business logic. This also ensures that open positions somehow persist and the bot “survives” on restart. This is a really important part.

 

Regardless of which generation point it is, your bot will be subject to new launches. The server should set up reboots as if they were running uninterrupted. You may miss some ticks and updates, however, you can keep track of open positions, the status of your algorithms, etc. You must not lose. And the whole part can be done in a general way as part of the housekeeping process. Additionally, you had better plan for coding errors and other possible situations. Obviously, if your expected status and net position do not match the data on the stock market, you need to have a plan for how to most effectively solve this issue. You can try to never increase your risk in the stock market and also decide to close positions in case of problems. As has been mentioned so far, there has been a lot of logic involved in making it safe for 24/7 use.

 

Ability to scale horizontally

 

Another great benefit of this split is the ability to easily add or change the trade logic itself, as well as the exchange. If you want to move the same strategy to another exchange, what you need to do here is to implement the API connector for that exchange and everything will be ready. Follow the same path for new strategies and their logic. Just apply the new logic within the defined structure of the bot and you can easily change or add them.

 

The last level for backtesting

 

For the last level of abstraction, I strongly emphasize that you need to take link management to another level outside of the actual trading robot. This sounds logical when you think about it because running the bot in a live environment requires some special handling with real-time data. The quantity of data in the market itself and the frequency of updates are very variable, and depending on the strategy, you probably do not need to strategize every single sign.

For instance, my strategies usually work on H4. Therefore, there is no need to transmit every tick every few milliseconds unless necessary, as this will use strategy redundantly and waste resources. That's why you should collect the data and update it every 30 seconds. Basically, you now have a layer that manages the data transfer between the exchange and the bot. For the simplest explanation, when the trading bot decides it makes sense, it provides an "onTick" method. 

 

In conclusion, managing to simulate executions on historic data needs to be shown as a science. If you are willing to manage this and dedicates yourself, you should know that you have to spare time for this process. To be honest, this circumstance indicates the amount of quality and trustworthiness of your results in backtesting. In the way that provides to run this bot, you need to pass these stages with these parameters. Doing this job flawlessly is for your benefit. You should trust this process because if you do not take attention enough and miss the steps, you will have to go back. In parallel, it will cost you much more. 

 

We hope that this article will be beneficial for you. We will continue to create useful works in order to get inspired by everyone. We are sure that we will achieve splendid things altogether. Keep on following for more.