Testing a daily loss limit EA: why "1 minute OHLC" gave me 105% and real ticks gave 90% - page 2

One more thing that bit me when moving a loss lock from the tester to a live prop account: the "day" itself. The tester resets your daily counter at broker server midnight, but most prop firms reset at their own time (often 5 pm New York), and some measure from the day's starting value including open positions, not closed balance, so floating P&L at the reset counts against you. If the EA's day boundary doesn't match the firm's, the lock can be perfectly tested and still fire at the wrong level.

Two smaller ones:
- Include commission and swap in the number you check. On a busy day they add up, and the firm counts them.
- Leave room for the close itself. When the lock fires on a fast move, the closing fills come in worse than the trigger price, so a lock at 90% of the limit can finish the day a bit above that. Real ticks plus "Random delay" in the tester gives a rough idea of that gap.

Youness Kanbaou:
Did anyone else see big differences between modelling modes for equity-based logic?

Hi,

Yes, I think the results can be significantly different when entry or trade management rules depend on tick prices.

However, if the EA's logic is based on candle-close data and trades are opened at the beginning of the next candle, the differences should generally be smaller.

On the other hand, if the EA uses trailing stop-losses, break-even rules, or other logic that depends heavily on tick prices and the sequence of price movements, the differences can be much more significant.

I also think the lower the timeframe on which the EA runs, the greater the potential impact on the results. For example, when running an EA on H4, M1 data might provide sufficient accuracy for many strategies. However, for M5, M3, and especially M1 strategies, using only M1 OHLC data is less reliable because it doesn't capture the exact sequence of price movements within each candle.

Thanks,

Youness Kanbaou:
I was testing a daily loss lock in the Strategy Tester (100,000 account, 5% daily limit = 5,000, lock set at 90% of the limit).

With "1 minute OHLC" the lock fired late: the day closed at 105% of the limit. With "Every tick based on real ticks" it locked at 90.0% (−4,501), exactly as designed.

The reason: OHLC mode only knows 4 prices per minute. Inside a fast minute the equity can drop far below the level you check, and the tester never "sees" that drop until the next bar.

If you test anything that reacts to equity (loss limits, trailing equity stops, max drawdown guards), use real ticks or at least "Every tick". Otherwise the results look worse (or better) than reality.

Did anyone else see big differences between modelling modes for equity-based logic?
Equity-based logic is very sensitive to modelling mode, because OHLC and synthetic ticks invent the path between bars, so intrabar loss peaks and the moment your lock fires are guesses. Use "Every tick based on real ticks" for anything that reacts to equity, and make sure the broker's tick history is complete for the period. Then add a random execution delay in the tester, for example 100-500 ms, because a lock that fires on the tick still has to close positions at the next available price. To validate, compare the same days against your live or demo deal history: for each day, record peak intraday loss and the final close price per position, and see whether the tester's distribution brackets the live one. Gap opens and spread widening around rollover are where tester and live differ most, so keep a buffer, not a limit sitting exactly at the firm's threshold.

Thanks Sandro and Abdullah, both very useful points.

@Sandro: agreed. My test was on M1, and that’s where it showed most. On H4 with candle-close logic the gap between modes was much smaller.

@Abdullah: the random execution delay idea is a good one. I hadn’t added it, but it makes sense: the lock fires on the tick, yet the close still happens at the next available price. I’ll rerun with 100-500 ms and report back.

One more thing I noticed: on gap opens, even “Every tick based on real ticks” can’t lock at 90%, because the first tick of the day is already past the threshold. So a buffer below the firm’s limit is needed anyway, like you said.

I’ll compare tester peak intraday loss against demo history for the same days and post the numbers here.