I run the backtest procedure for playing historical trade data through the MoonBot terminal’s BackTest window several times on the same “bin” file and the same strategy, but I get slightly different results each time, why is that?

: Interface configuration

In scalping, there is no repeatability of the result when running the same market record over and over again!
Just as two identical MoonBot terminals with the same strategies on two different VDS will not trade exactly the same in the real market, so two historical data runs with the same strategy will not give exactly the same result.

A backtest in scalping, and in particular in the MoonBot terminal, is needed not to repeat the result 1 in 1, but to look at the general behavior of strategies using various examples of market situations and adjust them optimally for them.

A detailed explanation of why, with two runs of the same historical trade data, the profit figures and even the number of trades on the same strategy may be different:

Unlike classical candle algorithms, where all the numbers are always clearly defined, and you can count “2+2=4” 10 times and always get the same result of “4” – in scalping, the numbers are random!

The reasons for the randomness are discussed below using the example of two MoonBot terminals that trade one pair simultaneously with the same settings from two different dedicated servers (VDS):

1) Lag of trades. Terminal 1 received trades 10ms later than the other, and placed its order 10ms later, and then the situation began to develop according to a completely different scenario: the first terminal bought and sold to the plus, and the second terminal bought later, DID NOT sell in the same place, and closed the deal on the stop. The more active the market is, the more pronounced this factor is. The most striking example is the “MoonStrike” strategy, where in the same situation one terminal manages to buy and the other does not.

The backtest runs in EMULATION mode and specifically has a built-in random delay factor to emulate this situation.

2) Recalculation of all parameters does not occur continuously due to discreteness. That is, the first terminal has calculated something, the second time it will calculate the new market state after T1. The second terminal makes the same calculation at a slightly different time T2, even 1ms of difference will lead to the fact that a new trade will be included in the calculation and the calculation result for the second terminal will be slightly different. Other calculated figures will lead to different order parameters, or the absence of detection on the second terminal.

The discreteness factor is also present in the backtest, since the moment of pressing the “Play” button is not synchronized with the cycles of market recalculation.

3) Similar things happen with a Sell order if you use certain Sell order management algorithms, for example: PriceDown (reducing the Sell order in time), SellLevel (adjusting the Sell order to the previous maximum price), SellShot (following the Sell order in the specified value ranges), SellSpread (adjusting the Sell order to the spread prices) and even StopLoss. The operation of reshuffling a Sell order is not instantaneous. Different moments of reshuffling Sell orders can lead to different final closing prices. The backtest has an emulation of the order reshuffle time: a random delay of 10-20 ms, just like on a real exchange.