Hi, all my strategies enter and exit trades 1 period after the backtest. This often results in a loss in real money when the backtest shows a profit and vice versa. I would post screenshots but as a new user I can’t post more than ine
As far as I can tell looking at the code, we’re setting the birth time of the last closed candle as the time of trade, when we should be setting the close time. It’s more a visual bug than anything else.
Your strategy has a trading frequency of 1 hour.
The candle 19:00-20:00 just closed and 20:00-21:00 just opened so we check the entry rules using the 19:00-20:00 candle and a few hundred more preceding it to calculate the technical indicators. There is a signal so we open a position, however instead of using the close time of the 19:00-20:00 candle, which is 20:00, we use the birth time, which is 19:00 - this is where the confusion comes from as, naturally, when simulating a strategy, we use the current time when executing a trade, which would be 20:00 in this case.
I hope my explanation was not too confusing. This will be fixed as to avoid further confusion in the future.
But the two show different prices on open and close and therefore the backtest gives a different result to actual trading. I can’t see how this could be described as just a visualisation issue. I don’t agree with your explanation but any improvement would be appreciated.
The examples in the screenshots aren’t the best as they all result in profit whereas on many occasions the backtest shows a profit whereas the real trading is a loss.
The difference in price is due to the trading lag which we’re currently working hard on reducing to a minimum. The backtest is using the close price of the last candle, and the running strategy is using the current price of the instrument, which naturally has changed by the time the signal is executed. With the reduction of this trading lag (which occurs mostly when you’ve connected the strategy to a Trading 212 account) these price differences should become much smaller, unless the market is terribly volatile.
Nikola, I’ve been looking at the graphs and values on trading 212 to try and understand you. As far as I can see the real/simulated trading is a period late of the trigger (bollinger bands - bar opens below upper after opening above). If I understand you correctly that should say bar opens bar after bar opens below upper after opening above. Is that correct?
I’ll keep an eye on this topic. I agree with Nd76. I wrote about it already in October.
I also add that it doesn’t matter if you use simulation or trading212. Results against backtest are the same.
Thanks reix2x, I have added a new post to alert others. I think the main problem is with triggers “bar opens above/below…”. Regardless of what price is shown in the backtest, simulation or real the trade is one period too late. Less sure about other triggers.
I don’t think this is just a visualisation problem. Here are some screenshots
(sell position dragged over the weekend and not closed still)
If you look into Trading 212 history
we can confirm indeed that if the position was opened 1 bar earlier (like in backtest), it would have closed with profit already.
We do understand, that real-time trading is different than backtesting as there is a lag in real-time communicating systems (even if you make it small - there will still be a lag). But the above issue shows that backtest is not very reliable. What we want from this is more reliable backtest, so if we can’t fix “the lag” making real-time trading the same as backtest, maybe we should explicitly “shift” the backtest positions 1 bar to have more reliable backtest results. In other words, the backtest result will account for the lag.
Can we at least have the option of “shifting” the position open times manually when performing the backtest?
The one period delay that causes varying results in comparison with the backtest also happens on simulated strategies, so this can’t be explained by the t212/broker lag. If strategies are not able to use the most recent bar in entry/exit calculations when running it would be better to have this represented in the backtest too.
I can confirm that, with our new engine release next week, running strategies will always use the latest bar, when calculating signals. More info on what this release entails will be available soon.
Another step towards representative backtests, I can’t wait!