INTRODUCTION

This page outlines the structure of the project and its software. It describes the architecture as well as the basic functionality of the modules. However, the exact workings of the signals are not discussed here. Additionally, the repository is not publicly accessible.

This page is still under construction. More information will be added gradually 🔍👀

SYSTEM ARCHITECTURE

Since this is not a typical software project, only the structure and project architecture are described here. A key feature of the project is its modular design, which ensures flexibility and expandability. The chart below illustrates how an algorithm implementation integrates into the overall process. The data feed provides current market data (such as prices, volume, etc.), which is sourced from the exchange and visualized in the trading platform. I use the Rithmic data feed and ATAS as charting software.

The trading platform acts as an interface between the trader and the broker. This connection is bidirectional: the trader sends orders to the broker, while the broker returns execution details and confirmations. The broker receives the orders and forwards them to the exchange for execution.

Version control was handled using branches, as the project cannot be forked while the repository does not belong to an organization. It is particularly important that changes to the main branch can be rolled out to all algorithms. For this, scripts are available to automate the merge and other steps. General adjustments and changes in the library are thus transferred to all modules at the push of a button, without the need for manual modification of module-specific implementations. The software build process also includes additional steps to ensure that the algorithm is created with the corresponding module name and integrated into the trading platform. However, the project is steadily growing, and so far, there has not been an opportunity to further expand the automation of the strategies.

TESTING AND OPTIMIZATION

Initially, the algorithms serve as visual signals and can be used in my daily live trading to support my trading decisions. The signals can be tested both under real market conditions and in the replay mode of the trading platform to observe and optimize the behavior and quality of the signals. Testing is conducted continuously as part of daily use. Since the logic of the signals is clearly defined, errors can be quickly identified.

Each implementation also includes a StatisticsLogging module, which allows for automated tests on larger datasets. Historical data can be loaded and evaluated with the click of a button, simplifying the evaluation of signals in a fully automated process. Different management styles (e.g., Fill or Kill, Stop Trailing) can be applied. In addition to a general stop setting, there is also the option to adjust risk management based on the most recent highs and lows. If the maximum risk is exceeded, the trade is not executed. This module will be described in more detail in the future.

Overall performance is mainly evaluated in backtests under real conditions. Since not every signal is traded, the performance cannot be easily assessed in a general way. It strongly depends on the targeted Reward Risk Ratio. With a low ratio, where the risk is high relative to the reward, the win rate increases since trades are less likely to be stopped out. However, losses also outweigh gains. Currently, no dynamic management has been implemented, making it difficult to create consistent evaluations across vastly different market conditions.

Another area still under development is a method for filtering out poor-quality signals without removing too many of the high-quality signals. Some signals are only valid at specific levels, so a clear definition of these areas is necessary. This is an ongoing development goal. Additionally, an intelligent, dynamic management system is planned, and further information will follow.

Additionally, addressing the time complexity of the algorithms is a key focus. Since the NASDAQ is an extremely dynamic market, signals must be calculated at high speed. I am continuously working to further optimize the time complexity of the modules. I will add some measurements soon.

Each algorithm is implemented via its own algorithm class, which inherits from a general Indicator Class. The OnCalculate method must be overridden in each algorithm class. This function is called with every new tick and ensures continuous data evaluation. A significant advancement in the development was the implementation of a comprehensive library of functions that integrates various approaches and calculations. Therefore, a large part of the functionality is implemented in the static CandleAnalysis class. Every algorithm has access to this class and can utilize its functionality, providing a unified, flexible, and scalable solution. This architecture allows for quick implementation of new signals. The modular structure enables existing algorithms to be quickly adapted and new ones added, allowing the system to scale to accommodate a growing number of algorithms and trading strategies. Today, various market situations can be identified with these algorithms. In addition to absorptions, volume patterns, and imbalances in market buy and sell orders, potential fake breakouts and interesting VPOCs (Volume Point of Control) are also now recognized. Below is an overview of the current repository.

Currently, the algorithms run through the trading platform’s interface. Once the algorithms have reached sufficient maturity, they will be directly connected to the data feed to reduce overhead. This will allow the data to be processed more quickly in the future, enabling orders to be transmitted to the broker with higher performance. That is shown in dashed lines in the image above.

Below is a class diagram. The ATAS implementation involves additional classes, so the class diagram here represents a simplified version that only shows the interaction between the algorithm and the trading platform.