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.
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.
Another factor to consider when testing daily loss limits is the definition of the "start of the day." In the MT5 Strategy Tester, the local time corresponds to the broker's server time; consequently, the Expert Advisor (EA) calculates the start of the day based on the broker's midnight. Many proprietary trading firms, however, reset the day according to their own specific time zone, which may differ from the broker's midnight by several hours. In such cases, a single "bad day" during testing might be split across two separate "days" (or vice versa), meaning your 90% limit in the test will not align with the firm's actual rules.
To address this, I identify the firm's reset time from their official rules, convert it to the broker's server time, and apply this setting to the EA. Furthermore, I configure the EA to log the account equity at the start of each day, allowing me to verify whether these figures match the values used by the firm.
good one with the reset time, i had the same mismatch. There is a second part to it I'd check in the firm rules. Some firms start the day from the balance at reset, others from the higher of balance and equity. If you go into the reset with a floating profit, the second one gives you less room the next day than the EA thinks.
So I log both numbers at the reset, not only equity.
In 1-minute OHLC mode, the Strategy Tester only generates 4 price points per minute, so an intra-bar equity drop is only detected at the next simulated tick. Using real ticks (and logging the equity at detection vs. after closing) avoids this gap. Here is a concise daily equity loss-limit guard in MQL5:
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
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,
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.
In 1-minute OHLC mode, the Strategy Tester only generates 4 price points per minute, so an intra-bar equity drop is only detected at the next simulated tick. Using real ticks (and logging the equity at detection vs. after closing) avoids this gap. Here is a concise daily equity loss-limit guard in MQL5: