Make latency the experiment, not an excuse
Does the price behind a decision still exist when a trade request is processed? MT5 offers No Delay, Fixed Delay and Random Delay to test that assumption [1]. Treat a clean baseline as the start of an investigation, not proof of your broker's future fills.
Start with an operational question rather than a return target. Does the EA recognize an unsuccessful request? Can you explain why a stop adjustment was not accepted? Does its recorded position state agree with the tester's trade history? A changed profit figure might tell you where to investigate, but it cannot answer those questions by itself.
Freeze everything except the delay setting
Our suggested test record has one row per run: EA build, input file, broker history source, symbol, timeframe, date range, tick model, account assumptions, execution mode and delay. Keep the first nine items identical. Save a separate settings record for each run instead of overwriting a folder called latest. This is an experiment-design suggestion, not a platform requirement.
Compare no delay, a connection-representative fixed delay, a slower fixed delay and random delay. MT5 accepts preset or custom fixed values and can suggest server ping [1]. Choose the comparisons before examining results; otherwise the test can become another search for an attractive outcome.
Decide the acceptance criteria before opening the results. For example, every rejected request must remain distinguishable from an executed trade in your records. A run with missing diagnostic evidence is inconclusive, even when its equity curve looks attractive.
Random Delay is a stress model, not your broker's latency forecast
The documented random model assigns 90% probability to 0 to 8 seconds and 10% to 9 to 18 seconds [1]. These are simulated waits, not measurements from your account.
Use the fixed-delay runs for a controlled comparison first. Then use the random run to look for additional failure cases. Preserve each report and record the chosen mode. Do not discard an inconvenient run or keep rerunning until one looks reassuring. If repeated random runs disagree, that variation is part of the finding; it is not permission to select the prettiest result.
A useful worksheet separates business outcomes from software outcomes. Record trade count and drawdown in one area. In another, record unexplained rejections, mismatches between logged state and trade history, and requests whose outcome cannot be reconstructed. Zero observed faults in one run is narrower evidence than a general claim that the EA is reliable.
Worked example: investigate a requote, not imaginary parallel callbacks
In a hypothetical Instant Execution test, price moves beyond permitted deviation while a request is delayed, leading to a requote [1]. This is an illustrative scenario, not a BamaUp result or a rule for every execution mode.
Before testing, write down what the EA is expected to record when a request does not complete at the requested price. Afterward, match that decision to the reported outcome and the resulting account state. Do not simply increase the permitted deviation to make the failure disappear: that changes another assumption and belongs in a separately documented experiment.
Also avoid a common explanation error. MQL5 processes events sequentially. If a NewTick event is already queued or being processed, another NewTick is not added to that queue [2]. A delayed synchronous call does not mean a second OnTick callback executes concurrently inside the same EA. Timing-sensitive behavior still needs testing, but explain it using the actual event model.
Know where the simulation stops
Delay applies to EA trade operations, including pending-order placement and stop changes, but not to later server-side pending-order activation [1]. That boundary matters when interpreting the experiment.
Your next practical step is to run the matrix on a documented demo research setup and inspect a few changed or rejected requests before comparing total returns. Keep inputs fixed, save the evidence, and write one sentence explaining what each run did and did not establish. When a question depends on real terminal or server behavior that the tester cannot reproduce, mark it for a separate controlled demo check.
References were checked on 5 October 2026 (UTC). This workflow does not require funding a live account and makes no claim about future performance. Continue with the free Auto-Trading Foundations material or browse the journal for the complementary tick-model sensitivity workflow.
