Backtesting is a core feature of third-party software like AmiBroker, TradingView, and MetaTrader. Below is a detailed analysis of the basic modules necessary to develop a system for backtesting.

Benefits of Backtesting Module

To institutional investors or professional algorithmic trading, backtesting is a critical screening phase to assess an algorithm’s performance in the future.

When the number of algorithms to test increases, these tasks repeat and lead to a requirement for a standardized testing process. There’s now a need to build standardized testing modules that specialize in testing historical data.

Developing algorithms on testing modules that simulate real trading at the same time allow reusability. Investors will work more efficiently on these modules without the need to program two separate versions.

Last but not least, testing modules are built in a simulated environment. They help limit errors caused by changing between different running environments. It also increases the similarity of test transactions to real trading ones.

Direction to Develop Backtesting Modules

Testing modules for an algorithm typically have three essential parts.

Simulate securities companies. This is a must-have to test trading algorithms on historical data in the long run. This part is to set up a simulated security company to receive orders, match orders, or even cancel orders from trading algorithms. Depending on the virtual account and real market conditions at the time of receiving a simulated order request, it decides to accept or reject the orders. After receiving new orders, it relies on market movements to match orders similar to real trading. A simulated security company has the basic features of a real company, without special cases such as partial order matching. Simulating securities companies requires lots of effort. However, in the long run, it helps investors test algorithms on historical data as objectively as possible.

Program trading algorithms. Trading algorithms can receive past data, return trading signals, and execute transactions with a simulated securities company to build a transaction history. The key point is the same piece of code can be applied in all stages: backtesting, forward testing, and real trading.

Reports. A backtesting system needs to standardize test reports to facilitate horizontal development. The basic parameters that should be included are:

• Total asset over time;

• Profit;

• Maximum drawdown;

• Sharpe ratio;

• Ratio of opening profitable/losing positions;

• Expected value when profitable;

• Expected value at loss;

• Longest profit streak;

• Longest losing streak;

• Drawdown statistics.

Transaction history is recommended to be exported in Excel format for easy access, inspection, editing, and illustration.

The logic of simulating securities companies and performance and risk assessment is the same for all algorithms. It should be developed separately for reuse in different algorithms. Investors can save effort and minimize programming errors. Developing these modules independently is to simulate the real market and to assess the performance so it will not be affected by any particular algorithm. The assessment will become as objective as possible.

How to  a Securities Company Simulator

Building a securities company simulator is a centerpiece of the backtesting module. In particular, it contains three main components:

• First is to build a paper trading broker that can receive orders, cancel orders, return order matches, and account status via API.
• Second is to determine whether an order can match, and in how much volume based on information obtained from market data (volume, price, buy, and sell) at the time of placing the order. The time will be in the past for testing past data, or in the present for testing future data. An example is from order matching: the simulator receives a limit order to buy at price X for ticker Y. If after receiving the order, and the order has not been canceled, the market price is less than or equal to X, then we can simulate that this order has been matched.
• Lastly, all information about placed orders, status, matching results, transaction costs, and account status at times should be saved in the database. These data will be used to assess the algorithm’s performance and risk metrics.

In Vietnam market, note that the period of testing past data has lots of deviations from operations. In addition to common problems like taxes, fees, and slippage, traders should be aware of the volume and unobserved matches. The insufficient volume will reduce the algorithm’s efficiency when operating in a real environment. Unobservable matching data will benefit algorithms using limit orders and negatively impact  using market orders.