___ _ _ _ _ _ _____ _ _ ____ _
|_ _|_ __ | |_ ___| | (_) __ _ ___ _ __ | |_ |_ _| __ __ _ __| (_)_ __ __ _ | __ ) ___ | |_
| || '_ \| __/ _ \ | | |/ _` |/ _ \ '_ \| __| | || '__/ _` |/ _` | | '_ \ / _` | | _ \ / _ \| __|
| || | | | || __/ | | | (_| | __/ | | | |_ | || | | (_| | (_| | | | | | (_| | | |_) | (_) | |_
|___|_| |_|\__\___|_|_|_|\__, |\___|_| |_|\__| |_||_| \__,_|\__,_|_|_| |_|\__, | |____/ \___/ \__|
|___/ |___/
₿ Ξ ₳ ₮ ✕ ◎ ● Ð Ł Ƀ Ⱥ ∞ ξ ◈ ꜩ ɱ ε ɨ Ɓ Μ Đ ⓩ Ο Ӿ Ɍ ȿ
📈 Intelligent Trading Signals 📉 https://t.me/intelligent_trading_signals
The project is aimed at developing an intelligent trading bot for automated trading cryptocurrencies using state-of-the-art machine learning (ML) algorithms and feature engineering. The project provides the following major functionalities:
The signaling service is running in cloud and sends its signals to this Telegram channel:
📈 Intelligent Trading Signals 📉 https://t.me/intelligent_trading_signals
Everybody can subscribe to the channel to get the impression about the signals this bot generates.
Currently, the bot is configured using the following parameters:
There are silent periods when the score in lower than the threshold and no notifications are sent to the channel. If the score is greater than the threshold, then every minute a notification is sent which looks like
₿ 24.518 📉📉📉 Score: -0.26
The first number is the latest close price. The score -0.26 means that it is very likely to see the price lower than the current close price.
If the score exceeds some threshold specified in the model then buy or sell signal is generated which means that it is a good time to do a trade. Such notifications look as follows:
🟢 BUY: ₿ 24,033 Score: +0.34
For the signaler service to work, a number of ML models must be trained and the model files available for the service. All scripts run in batch mode by loading some input data and storing some output files. The batch scripts are located in the scripts
module.
If everything is configured then the following scripts have to be executed:
python -m scripts.download_binance -c config.json
python -m scripts.merge -c config.json
python -m scripts.features -c config.json
python -m scripts.labels -c config.json
python -m scripts.train -c config.json
python -m scripts.signals -c config.json
python -m scripts.train_signals -c config.json
Without a configuration file the scripts will use the default parameters which is useful for testing purposes and not intended for showing good performance. Use sample configuration files which are provided for each release like config-sample-v0.6.0.jsonc
.
The main configuration parameter for the both scripts is a list of sources in data_sources
. One entry in this list specifies a data source as well as column_prefix
used to distinguish columns with the same name from different sources.
Download the latest historic data: python -m scripts.download_binance -c config.json
Merge several historic datasets into one dataset: python -m scripts.merge -c config.json
This script is intended for computing derived features:
python -m scripts.features -c config.json
The list of features to be generated is configured via feature_sets
list in the configuration file. How features are generated is defined by the feature generator each having some parameters specified in its config section.
talib
feature generator relies on the TA-lib technical analysis library. Here an example of its configuration: "config": {"columns": ["close"], "functions": ["SMA"], "windows": [5, 10, 15]}
itbstats
feature generator implements functions which can be found in tsfresh like scipy_skew
, scipy_kurtosis
, lsbm
(longest strike below mean), fmax
(first location of maximum), mean
, std
, area
, slope
. Here are typical parameters: "config": {"columns": ["close"], "functions": ["skew", "fmax"], "windows": [5, 10, 15]}
itblib
feature generator implemented in ITB but most of its features can be generated (much faster) via talibtsfresh
generates functions from the tsfresh libraryThis script is similar to feature generation because it adds new columns to the input file. However, these columns describe something that we want to predict and what is not known when executing in online mode. For example, it could be price increase in future:
python -m scripts.labels -c config.json
The list of labels to be generated is configured via label_sets
list in the configuration. One label set points to the function which generates additional columns. Their configuration is very similar to feature configurations.
highlow
label generator returns True if the price is higher than the specified threshold within some future horizonhighlow2
Computes future increases (decreases) with the conditions that there are no significant decreases (increases) before that. Here is its typical configuration: "config": {"columns": ["close", "high", "low"], "function": "high", "thresholds": [1.0, 1.5, 2.0], "tolerance": 0.2, "horizon": 10080, "names": ["first_high_10", "first_high_15", "first_high_20"]}
topbot
Deprecatedtopbot2
Computes maximum and minimum values (labeled as True). Every labelled maximum (minimum) is guaranteed to be surrounded by minimums (maximums) lower (higher) than the specified level. The required minimum difference between adjacent minimums and maximums is specified via level
parameters. The tolerance parameter allows for including also points close to the maximum/minimum. Here is a typical configuration: "config": {"columns": "close", "function": "bot", "level": 0.02, "tolerances": [0.1, 0.2], "names": ["bot2_1", "bot2_2"]}
This script uses the specified input features and labels to train several ML models:
python -m scripts.train -c config.json
prediction-metrics.txt
file with the prediction scores for all modelsConfiguration:
model_store.py
train_features
labels
algorithms
The goal of this step is to aggregate the prediction scores generated by different algorithms for different labels. The result is one score which is supposed to be consumed by the signal rules on the next step. The aggregation parameters are specified in the score_aggregation
section. The buy_labels
and sell_labels
specify input prediction scores processed by the aggregation procedure. window
is the number of previous steps used for rolling aggregation and combine
is a way how two score types (buy and labels) are combined into one output score.
The score generated by the aggregation procedure is some number and the goal of signal rules is to make the trading decisions: buy, sell or do nothing. The parameters of the signal rules are described in the trade_model
.
This script simulates trades using many buy-sell signal parameters and then chooses the best performing signal parameters:
python -m scripts.train_signals -c config.json
This script starts a service which periodically executes one and the same task: load latest data, generate features, make predictions, generate signals, notify subscribers:
python -m service.server -c config.json
There are two problems:
python -m scripts.predict_rolling -c config.json
python -m scripts.train_signals -c config.json
The configuration parameters are specified in two files:
service.App.py
in the config
field of the App
class-c config.jsom
argument to the services and scripts. The values from this config file will overwrite those in the App.config
when this file is loaded into a script or serviceHere are some most important fields (in both App.py
and config.json
):
data_folder
- location of data files which are needed only for batch offline scriptssymbol
it is a trading pair like BTCUSDT
labels
List of column names which are treated as labels. If you define a new label used for training and then for prediction then you need to specify its name herealgorithms
List of algorithm names used for trainingtrain_features
List of all column names used as input features for training and prediction.buy_labels
and sell_labels
Lists of predicted columns used for signalstrade_model
Parameters of the signaler (mainly some thresholds)trader
is a section for trader parameters. Currently, not thoroughly tested.collector
These parameter section is intended for data collection services. There are two types of data collection services: synchronous with regular requests to the data provider and asynchronous streaming service which subscribes to the data provider and gets notifications as soon as new data is available. They are working but not thoroughly tested and integrated into the main service. The current main usage pattern relies on manual batch data updates, feature generation and model training. One reason for having these data collection services is 1) to have faster updates 2) to have data not available in normal API like order book (there exist some features which use this data but they are not integrated into the main workflow).See sample configuration files and comments in App.config for more details.
Every minute, the signaler performs the following steps to make a prediction about whether the price is likely to increase or decrease:
Notes:
Starting the service: python3 -m service.server -c config.json
The trader is working but not thoroughly debugged, particularly, not tested for stability and reliability. Therefore, it should be considered a prototype with basic functionality. It is currently integrated with the Signaler but in a better design should be a separate service.
Backtesting
External integrations