Broker for MetaTrader 4: how to test execution speed

It changes the price distance available to a short-horizon system, the frequency of requotes or rejected modifications, and the realized deviation from the backtest entry model.

For a broker for MetaTrader 4, quoted spreads and commission are incomplete cost variables. Execution latency is the missing term. MT4 itself adds constraints: OrderSend() is synchronous, Expert Advisor code is single-threaded, and ticks received while OnTick() is still executing can be discarded. A low server ping does not remove these limits. It only reduces one component of the path.

The mechanics of MT4 execution

An MT4 market order has several latency components. The terminal sends a request, the request crosses the network, the broker validates it, the order is routed or internalized, a result returns to the terminal, and the EA resumes only after that result.

The relevant interval is not a single "speed" number. It is a distribution.

A useful decomposition is:

• Terminal-side delay. Time spent by the EA constructing price, volume, stop-loss, take-profit, and deviation parameters.
• Network latency. Round-trip time between the terminal or VPS and the broker's MT4 trade server.
• Broker processing latency. Time for validation, margin checks, risk controls, dealing logic, and liquidity routing.
• Market-state latency. Additional delay caused by changing quotes, price validation, rejected stops, or temporary liquidity gaps.
• EA blocking time. The period during which MT4 holds the EA at OrderSend() and prevents that code path from processing subsequent logic.

The first two terms are partly controllable. The broker processing term is the core broker-quality variable. The fourth term is state-dependent and cannot be summarized by a test conducted during a quiet market hour.

MT4 is not designed for concurrent order dispatch. OrderSend() blocks until the terminal receives either a ticket number or an error. A strategy that attempts to issue three independent market orders in immediate sequence is not submitting them in parallel. It is submitting one, waiting, then submitting the next.

This has a direct consequence for portfolio EAs. If the mean execution time is 250 ms, four sequential orders require approximately one second before accounting for terminal calculations and quote changes. The last order is exposed to a different market state than the first.

In MT4, low ping is a network measurement. Execution time is an end-to-end measurement.

The distinction matters most for scalping, news filters, cross-symbol arbitrage logic, and systems that modify protective stops after entry. For a daily trend system, a 150 ms difference may be immaterial. For a system targeting two to four points before costs, it can dominate expected value.

Start with the MT4 server ping

The fastest initial test is built into the terminal. In the lower-right corner of MT4, click the connection-status bars. The terminal displays available data centers and latency to each in milliseconds.

This is the baseline network latency. Record it before testing orders.

A low ping is useful, but it is not a fill benchmark. A 2 ms terminal-to-server reading can coexist with slow market-order confirmation if the broker's trade processing or liquidity path is slow. Conversely, a 25 ms ping can produce acceptable execution if server-side processing is stable.

The test should be repeated across several periods:

1. Liquid London–New York overlap. This provides the most relevant baseline for EUR/USD, GBP/USD, and other major pairs.

2. The first minutes after a major scheduled release. This measures degradation under quote velocity. It does not measure a guaranteed worst case.

3. The rollover window. Spreads, liquidity conditions, and server load can change materially near the daily session transition.

4. A low-liquidity Asian period. This is relevant for systems trading crosses or instruments whose active session is outside Europe and the United States.

5. The actual deployment location. A home connection test does not describe a VPS deployment. A VPS test does not describe a mobile or residential connection.

The ping should be logged with the date, server name, terminal build, and hosting location. One result has no statistical value. A sequence of observations allows an analyst to identify whether latency is stable, bimodal, or dependent on the session.

For MT4, the connection bar measures terminal-to-server communication. It does not expose the delay between the broker's server and a liquidity provider. It also does not identify whether a broker internalized the order, routed it externally, or applied an execution filter.

Audit the Terminal Journal before writing test code

The Journal tab provides the first direct execution audit. It contains timestamps with millisecond precision for trade-related messages. The basic method is to compare the time of the order request with the time at which MT4 reports that the order was opened, modified, closed, or rejected.

A representative sequence may include:

• A request entry such as order buy market.
• A confirmation entry such as order was opened.
• An error entry, if applicable, including off quotes, invalid price, requote, trade context busy, or insufficient funds.
• A modification entry for stop-loss or take-profit placement.

The difference between request and confirmation timestamps is a practical round-trip measure for that event. It includes terminal communication and broker response. It does not isolate broker processing from network time. That is acceptable for operational testing because the strategy experiences the combined delay.

A Journal audit should separate transaction types. A broker can show one latency profile for pending orders and another for market orders. Stop modifications often have a third profile.

The test should use the same symbol, volume, and order type as the live strategy. Testing a 0.01-lot EUR/USD order once does not characterize a system that trades larger size across GBP/JPY and XAU/USD. It only characterizes a single request under a single condition.

A useful sample has at least several dozen observations per order type and session. The analysis should report:

• Mean latency.
• Median latency.
• Standard deviation.
• 90th or 95th percentile latency.
• Maximum observed latency.
• Count and type of execution errors.
• Slippage relative to the requested price, separated into positive and negative outcomes.

The median is often more informative than the mean. A broker may produce a 100 ms median but a 700 ms 95th percentile. A strategy that enters only a few times per day may encounter the tail often enough for it to determine the drawdown profile.

The standard deviation matters for the same reason. Predictable 180 ms execution can be easier to model than execution that alternates between 80 ms and 650 ms.

Build a repeatable MQL4 latency test

Manual Journal inspection is necessary but inefficient for large samples. MQL4 can measure round-trip trade-request time with GetTickCount().

The procedure is direct:

1. Read GetTickCount() immediately before OrderSend().

2. Store the returned order ticket or error code.

3. Read GetTickCount() immediately after OrderSend() returns.

4. Calculate the difference between the two values.

5. Record the timestamp, symbol, direction, request price, fill price, spread, error code, and elapsed milliseconds in a CSV file or terminal log.

6. Repeat under predefined trading windows.

The result measures the blocking duration of the call. Since OrderSend() is synchronous, that duration is the time during which the EA cannot proceed past that instruction.

The method has limits. GetTickCount() is not a microsecond timer. Its practical resolution depends on the operating system timer and is typically around 10 to 16 ms. A measured result of 91 ms should not be interpreted as a precise 91.000 ms event. It is a measurement within the resolution of the clock.

It also rolls over after approximately 49.7 days. A long-running EA must handle the unsigned-counter reset. Otherwise, a valid trade request near the rollover point can be recorded as an invalid negative or excessively large duration.

The test EA should be minimal. It should not calculate indicators, scan multiple symbols, write large files synchronously, or run copy-trading logic in the same tick handler. Those operations contaminate the measurement.

A clean test configuration uses these parameters:

• One symbol per test run.
• Fixed lot size small enough to avoid material market impact.
• Fixed maximum deviation, documented in points.
• No martingale logic, recovery logic, or averaging.
• No indicator calculation inside the measurement interval.
• Separate tests for buy, sell, pending order placement, and modification.
• A cooldown interval that avoids accidental trade bursts.
• A unique magic number for all test transactions.
• Full logging of both successful orders and failed requests.

The error distribution is part of the result. A broker with 110 ms average fill time but repeated invalid-price or off-quote outcomes is not equivalent to a broker with 150 ms fills and stable acceptance. The first system may have a lower headline mean while producing a larger execution gap in live deployment.

A latency test that excludes failed orders measures only the successful subset. It understates operational risk.

The EA must also avoid assuming that every incoming tick is processed. MT4 does not queue a new tick if the previous OnTick() event remains in progress. It discards the new event. Under high quote frequency, a slow handler can therefore reduce the number of observed ticks without generating an obvious terminal error.

This is not solely a broker defect. It is an MT4 architecture constraint. Still, broker execution time can increase the probability of this failure mode because a blocking trade call extends the duration of the current event handler.

Separate home-network results from VPS results

Infrastructure changes the result materially. A standard residential connection commonly produces total MT4 execution times in the 500–700 ms range. A VPS placed near the broker's infrastructure commonly reduces total observed execution time into a 200–400 ms range. Neither range is a guarantee. Both combine network, terminal, and broker-side delays.

A VPS does not eliminate execution latency. It reduces geographic network distance and usually improves connection consistency. The broker still validates the request. The MT4 terminal still waits synchronously. The liquidity path still exists.

The operational benefit of a VPS is often lower variance rather than only a lower average. Residential connections introduce Wi-Fi interference, router queueing, ISP routing changes, background uploads, and local operating-system activity. A VPS removes several of these variables.

The deployment comparison should be run as a controlled experiment:

If the VPS reduces median execution from 600 ms to 250 ms but the 95th percentile remains near 900 ms during the same market periods, the primary constraint is not local connectivity. It is likely broker-side processing, market conditions, or both.

The same logic applies to server selection. Some brokers provide several MT4 server labels for live, demo, regional, or account-type configurations. The server with the lowest displayed ping is not automatically the best execution environment. It must be tested with actual trade requests.

The wider FX market routinely highlights headline connectivity claims, but trading infrastructure remains fragmented. The same gap often appears between a connectivity narrative and the actual execution path faced by a participant. In FX, the comparable mistake is treating a broker's connectivity claim as evidence of realized order latency.

Read ECN benchmarks without turning them into broker guarantees

Execution studies provide context, not a substitute for account-level testing. Reported 2026 benchmark results placed BlackBull Markets at approximately 72 ms for limit orders and 90 ms for market orders. Pepperstone was reported at approximately 77 ms for limit orders and 100 ms for market orders. The wider industry average was above 130 ms in the cited comparison set.

These figures are useful as external reference points. They are not transferable guarantees.

The result for a specific trader depends on:

• Account type and server allocation.
• Order type.
• Currency pair.
• Trade size.
• Time of day.
• Network location.
• Liquidity conditions.
• Maximum-deviation setting.
• Whether the order is marketable at the instant it reaches the server.
• Broker-side risk controls and routing decisions.

An ECN label does not resolve this analysis. "ECN" describes a claimed market-access structure, not a measured fill-time distribution. A market maker can return stable confirmations under certain conditions. An ECN-style account can show material delay if the liquidity path is congested or the request requires additional validation.

The correct comparison is empirical. Test two brokers with the same VPS region, the same EA, the same order schedule, and comparable account conditions. Then compare distributions rather than advertisements.

For a system whose theoretical pre-cost edge is \(E\), execution changes expected value through spread, commission, slippage, and delay-induced price movement. A simplified representation is:

\(E_{net} = E - C_{spread} - C_{commission} - C_{slippage} - C_{latency}\)

The latency term is not fixed. Its expected value rises with volatility, holding-period sensitivity, and the strategy's dependence on the first available quote. It is usually close to zero for slow systems. It can be the largest cost term for short-horizon systems.

The 30-second session timeout can distort isolated tests

MT4 has a trade connection session timeout of 30 seconds. After a period of inactivity, the next trade request may require re-authentication. That can add approximately 500 ms.

This creates a common test error. An analyst sends one order every few minutes, records a sequence of slow first requests, and attributes the full delay to the broker's execution engine. The test has measured session reconnection behavior as well.

The solution is to tag each observation by prior trade activity:

• Warm session: A request sent within the active trade connection period.
• Cold session: The first request after more than 30 seconds of inactivity.
• Post-error session: A request following a rejected transaction or connection disruption.

Cold-session observations should be excluded from headline latency statistics unless the live strategy also trades with that cadence. A scalping EA that issues orders every few seconds will not see the timeout cost. A signal-based EA that holds a position for hours and re-enters after a session close will see it routinely.

The same logic applies to forced re-authentication events. A broker maintenance window, a network blip, or a weekend rollover can place the next order request at the start of a new session. That observation belongs in a separate bucket.

Test the modification path, not only entries

Most EA failure stories attributed to execution quality actually start with stop-loss or take-profit modification. The fill of the initial market order is often acceptable. The problem is that the protective stop is placed, moved, or replaced later, and that secondary operation either rejects, requotes, or executes with material slippage against the strategy intent.

The modification path should be tested explicitly:

• Place a market order.
• After fill, modify the stop-loss to a tighter level.
• Measure the round-trip from modification request to confirmation.
• Repeat at intervals during the test window.

The expected behavior is that modification latency is lower than entry latency, because no liquidity lookup is required. A broker that returns 200 ms modifications during quiet periods and 900 ms modifications during news events is reporting a different operational risk profile from one that returns 350 ms modifications under all conditions.

Modification latency is where most trailing-stop and break-even systems actually fail in live deployment.

The trailing logic in the EA must also tolerate the measured modification delay. A trailing stop that issues a new OrderModify() request on every tick and expects confirmation within 50 ms will accumulate requotes and rejections on a broker whose modification path averages 250 ms. The strategy architecture and the broker latency must be matched.

Treat headlines and certifications as starting points, not conclusions

Marketing language about "institutional-grade execution," "low-latency matching," or "Equinix hosting" is a description of infrastructure intent. It is not a measurement of observed order latency on a retail MT4 account.

Regulatory certifications and external audits describe compliance with stated standards. They do not describe the median, the variance, or the failure modes that a specific EA will encounter.

The reliable path is repeatable measurement:

1. Define the exact order types, symbols, and sizes the live strategy will trade.

2. Run the test EA on the same broker server, on the same VPS region, for at least one full trading week.

3. Collect timestamps, error codes, fill prices, and request prices.

4. Compute the distribution and the error frequency.

5. Compare against the backtest assumptions for slippage and fill probability.

6. Re-test periodically, because broker routing and liquidity-provider configuration can change without notice.

Execution quality is a moving variable. A broker that performs well in a quiet market can degrade sharply during a Central-bank release. A broker that performs well on EUR/USD can perform differently on XAU/USD because of routing or contract-size handling. A broker that is stable on a London data center can behave differently on a New York data center.

The right mental model is that a broker for MetaTrader 4 is not a single object with a single latency number. It is a set of distributions indexed by server, account type, symbol, session, and order type. The trader who measures those distributions knows what the system will actually face. The trader who reads only the marketing page does not.