Continuing from the previous three articles on programmatic trading real code:

Hard-core dry goods - details and thoughts on automated real-time trading of quantitative trading systems (1. Problems and difficulties)

Quantitative Trading System - Automated Firm Offer Details and Thoughts (2. Firm Offer Purpose)

Quantitative Trading System - Automated Real Offer Details and Thoughts (3. Processing Skills)

Here we will continue to talk about the multi-strategy trading system and the market center in the overall structure of the real offer code.

Preface

In the trading industry, especially futures contracts, several high-leverage trading masters will appear every once in a while, and the principal of 100,000 yuan can easily turn into tens of millions. However, almost all of these people were like meteors streaking across the night sky. After a brief dazzling moment, they disappeared silently.

On the other hand, another group of veteran traders who have been doing business for a long time are submissive all day long, talking about the unknowable future, fearing the market, and black swans coming at any time. At the same time, they use very low leverage to open positions and try and make mistakes. The direction is like a grass on the wall, swinging left and right, without the determination and courage of a master. But for some reason, this group of people has been active in the market. Although the leverage is low, their positions are not small.

In the human nature of the trading world, stars are easy to come by, but birthday stars are hard to find.

As a surviving quantitative trader, I think one of the more important points in trading is to realize the necessity of multiple strategies. It is still difficult to implement multi-strategy in subjective trading because manpower is limited (unless it hires multiple traders like an institution) and the market runs 24/7 and it is easy to miss entry points. However, programmatic trading is relatively easy to implement. Programming loses the ability of the human brain and eyes to identify price trend patterns, but it has stronger execution power and a stronger ability to copy strategies and disperse positions, which has advantages and disadvantages.

With multi-target, multi-strategy and multi-parameters, capital positions are naturally dispersed. There is no longer an exciting opening and closing of a single profit or loss, but the pursuit of smoothing the capital curve as much as possible.

Overview

The picture below is the general architecture diagram of a set of my real code.

图片

The entire architecture is divided into two parts. One is an independent market center, and the other is the trading program responsible for implementing the strategy logic.

Usually I start a program with one account, and their policy parameters and account keys are distinguished by configuration files, so that the code can be completely shared and the code version is easier to manage. Some parameters of the strategy can be slightly different, mainly to stagger certain operations so that they do not suddenly run at the same time.

When there were few strategies before, I started a Python program with each sub-strategy, but later I found that the server memory was not enough. Because a Python program alone occupies about 60M of memory. If there are more strategies and are copied to several accounts, it will quickly occupy a lot of memory. Although you can pay more for a more powerful server, it is also troublesome to manage and maintain. In the end, it was changed to what it is now. Based on accounts, similar strategies on different currencies (multiple currencies and multiple parameters) are grouped into one group, and then a group of strategies is a Python app. After running it, I feel that this combination model is very good for the layout of multiple accounts and multiple strategies. It is very convenient for code management and real-time operation and maintenance.

The advantage of one sub-strategy for one Python app is that the code can be much simpler. However, just imagine, if your strategy is run on the top 40 major coins, and then each coin runs 3 different strategies, then it will be 120 sub-strategies. If you add three more accounts, it will be 360 ​​sub-strategies. This model It would be unsustainable.

When there are few apps, you can first use a terminal such as tmux to output log information in real time, which is very convenient for monitoring in the early stages of program operation. After the code is stable in the later period, operation and maintenance software such as pm2 will be used for management. Just analyze the log file regularly in the future.

In the case of multiple targets and multiple strategies, an independent market center must be standard. The various market information obtained can be shared between multiple trading programs, that is, the strategy modules on the left side of the picture above.

Quote Center

The picture below is a more detailed picture of the market center module.

图片

First of all, you can set the k-line symbols to be obtained through the configuration file, so that it is easier to change the type in the future.

If it is multi-period, then you can obtain their common divisor period k-line, and then each strategy can resample according to its own needs.

If you want to simplify things once and for all, then it is best to directly obtain the 15-minute K-line, because mid- and low-frequency strategies, especially trend following, with a cycle of less than 15 minutes, are basically difficult to make money in the long run.

For example, if you have a 15-minute, 1-hour, or 4-hour strategy, then the market center only needs to obtain the 15-minute K-line. If the k-line length of the large period after the resample is not enough, then you have to save more k-lines of 15 minutes in the database at the startup time.

Because websocket only pushes the latest updated k-line information, if your strategy uses a relatively large k-line cycle and a long lookback time, such as 4 hours of ma150, then it will be 600 hours (25 days) of data, 15 If one k line per minute is required, 2,400 are needed. This depends on the one-time acquisition and saving through the rest api when the market center is started, as the basis for subsequent continuous updates.

I divided the entire market center into two apps. In fact, it can also be combined into one app, but it is more robust to separate them. Let’s talk about the secondary Plan B first.

PlanB

As mentioned in several previous articles, this is mainly to prevent PlanA's websocket from being disconnected. It is used as a temporary backup, especially at the exit moment of the strategy, to avoid that the price has already reversed for a certain distance and the exit position has not been exited. Causing more unexpected losses.

PlanB is very simple. It mainly uses the public_get_ticker_price function to obtain the latest prices of all perpetual contracts at once. This is also the latest price information compiled by B An himself.

Currently, B'an has more than 200 perpetual contracts. If we obtain the latest prices one by one, we must ensure that the price of each product is updated every 3 seconds. The API will be called more than 4,000 times in one minute, which must exceed the limit. No. possible. However, the api weight of the function mentioned earlier is only 2. If it is used once every 3 seconds, it will only consume 40 api quotas per minute. There is no need to worry about exceeding the quota.

After my test, basically Binance aggregates the prices of all contracts once in about 1 to 2 seconds, so for the backup price of medium and low-frequency strategies, a delay of about 5 seconds is completely sufficient.

If your requirements are not high, you can even use it to synthesize rough K-lines for all contracts, completely avoiding the use of websocket. Even if this kind of K-line cannot be used for trading, it can also be used for scanning the whole market information, and then providing entry points for subjective traders based on their own designed strategy algorithms, such as moving average divergence and convergence, simple pattern recognition, etc. Signal. Otherwise, how can you see so many coins? If you have a good day trader, this tool may be useful to assist in trading. I have written similar tools for others before. It is really good when the market is good, but the market has not been good recently.

Of course, this solution is only of practical use when trading many coins. Otherwise, it is better to directly obtain the handicap BBO price of each variety.

Also note that the backup price information must be used frequently in the main code. For example, it is used to calculate the amount of fiat funds corresponding to the position and the approximate profit and loss rate, which does not require very precise data. Because code snippets and information that are not frequently used may have broken down a long time ago and you may not even know it until it is used. Anyone who has written a lot of code knows that this kind of appendix code can easily be accidentally changed without realizing it.

Plan A

The main code of the market center. This app has 4 main functions.

  1. Get historical base candlesticks. As mentioned earlier in the article, every time you start, you must ensure that every K line required by all strategies is present.

  2. websocket management. This module is a little more complicated and needs to handle various disconnection situations, reconnection, etc. Every time the exchange pushes new k-line data, the data of the latest bar of the k-line in the database is updated.

  3. In addition to the K-line data, I also put the accuracy information updates of each variety in the market center. That is, the public_get_exchangeinfo function obtains the various order prices and the minimum precision of the order quantity, and then converts them into a convenient dictionary type. This way all strategies can be shared.

  4. The last step is to check, a simple sanity check is enough. Check whether the K-lines obtained are continuous and there are no omissions, and then regularly compare them one by one with the K-lines obtained by the rest api, whether the price gap with the price obtained by PlanB is too large, etc. In short, it’s just a matter of comparison and inspection so that errors can be discovered early.

These are probably the core structure of my mid- to low-frequency strategy market. If necessary, the account update information can also be obtained through websocket. But this is a little more troublesome and won't be used most of the time.