Define the scope→02
Inspect the source→03
Record the limits
Key takeaways
From a retail terminal you can reliably measure client-observed request-to-fill time and slippage, but not most server-side processing alone. · Clock synchronisation, automated logging, and adequate sample size are essential to produce interpretable results. · Network, session state and market liquidity confound measurements; median and percentiles are more informative than simple averages.
What a retail terminal can and cannot measure
From a retail trading terminal you can produce two types of measurable evidence: (1) client-observed request-to-fill time — the elapsed time between when your terminal issues an order request and when you observe the executed trade; and (2) slippage — the difference between the requested price (or mid/quote at send time) and the executed price. These are direct, observable quantities on your side of the connection. What you cannot measure reliably from a single home terminal is the broker’s internal processing time in isolation, the behaviour of the matching engine, or whether another market participant affected the fill (for example front-running). Those require server-side logs, synchronized server timestamps, or independent co-located observers. Also note that demo accounts, VPS hosts, and live accounts can behave differently; any measurement should be annotated with the account type and server host.
Overview of the measurement approach
The aim is to log well‑defined events with accurate timestamps and to collect enough observations to characterise typical behaviour and tails. Basic approach: (A) synchronise your computer clock to a reliable time source (use NTP); (B) generate ordered tests (market orders or IOC orders) under controlled conditions and record a timestamp when the order is issued; (C) record the timestamp when the platform reports the fill and the executed price; (D) repeat to produce a sample and compute summary statistics (median, 90th/95th percentiles) and slippage distribution. Prefer automated logging to manual stopwatch methods. Manual timing introduces human reaction bias and jitter. Keep tests small to avoid market impact, and log contextual data such as symbol, order size, spread at send time, local ping to the broker host, time of day, and whether you used a VPN or VPS.
Tools and setup you can use at home
Essential tools: (1) a platform or API that lets you programmatically submit orders and capture timestamps (e.g. a broker API or an Expert Advisor in MT4/MT5); (2) NTP time synchronisation on the testing machine; (3) logging to a local file or database with millisecond resolution; (4) network diagnostics: ping, traceroute, and optionally packet capture (Wireshark) if you are comfortable with networking. If your platform does not expose millisecond timestamps, use an automated script or EA that captures the local system time immediately before sending the order and immediately after a fill event arrives. For network-level timing, ping measures ICMP round-trip time to the broker host but does not equal order request latency (which may use TCP or WebSocket). Packet capture can show the timestamps of TCP packets you send and the ack or response packets you receive, which helps separate local network delay from application-level delay, but most trading protocols are encrypted so you may not be able to see message contents—only timing and packet sizes.
Logging methodology — step by step
1) Prepare: ensure NTP is running and confirm clock accuracy to a few milliseconds if possible. Note your machine, OS, internet connection (ISP, wired/Wi‑Fi), and whether a VPN/VPS is used. 2) Instrumentation: implement code (script, EA or API client) that records: local timestamp at order submission (T_send), the price quoted or requested, platform-reported timestamp at fill or the local timestamp when the fill message is received (T_fill_local), executed price, order ID, and server-reported timestamps if provided. 3) Baseline network metrics: run ping and traceroute to the broker host at intervals during the test. Optionally run packet capture to obtain TCP-level send/receive timestamps. 4) Test plan: decide a sample size (hundreds of trades is common for distributional characterisation), randomise inter-order intervals to avoid queuing artefacts, and test at multiple times of day and market conditions. 5) Record metadata: market symbol, session (London/New York/Asia), spread at send, order size, and any platform alerts. Export logs promptly and preserve raw data for auditability.
How to interpret the numbers and their limitations
Interpretation must be cautious and contextual. The client-observed request-to-fill time equals network round-trip plus any local and server processing observed as the delay between your send timestamp and the received fill event. Without a server-supplied, trusted timestamp you cannot partition that delay precisely into network vs server-side components. Use robust statistics: median gives a sense of typical latency; 90th/95th percentiles show tail behaviour important for traders. Slippage should be reported in absolute price terms and in pips or percentage. Report the distribution, not just a single average, because means are sensitive to outliers. Do not infer intent or misconduct from timing or slippage alone. High latency or frequent re-pricing can be caused by network congestion, illiquid market conditions, or normal exchange behaviour. If you need to evaluate whether a broker’s execution meets regulatory standards, request their execution reports and server logs, and compare with your client logs; regulators or independent labs are required to draw conclusions from combined datasets.
Common confounders and how to reduce them
Network variability: Wi‑Fi, shared home networks and ISP routing introduce jitter. Use a wired connection or a reputable VPS near the broker’s server for controlled comparisons. Clock skew and drift: keep NTP enabled and verify offsets; without synchronized clocks you cannot compare client and server timestamps. Platform buffering and batching: some platforms batch outgoing messages or queue outgoing order requests; API vs GUI behaviour can differ. Broker-side features: last‑look, internalisation, or synthetic pricing can change fills in ways you cannot detect solely from client data. Market conditions: low liquidity, news events, and spread widening create slippage independent of connectivity. Session factors: your experience in the same session (warm vs cold TCP connection) may differ; include session metadata. Mitigations: automate tests, randomise timing, run tests across multiple sessions, record network diagnostics concurrently, and use statistical summaries. Always state which confounders you controlled for and which you could not.
Can I separate network latency from broker processing time using only my home PC?
Not completely. You can approximate network latency with ping and packet timestamps (e.g. Wireshark) to estimate round-trip time, and you can measure client-observed request-to-fill time. But without a trusted, server-side timestamp or broker participation you cannot reliably isolate server processing time from network delays.
Is it okay to run these tests on a live account?
Yes, but be cautious. Use very small order sizes to avoid market impact and margin risk. Alternatively run the same tests on the broker’s demo environment, but note that demo servers may be intentionally faster or otherwise different from live servers; always record whether data came from demo or live.
How many trades do I need to measure to get meaningful results?
There is no fixed number, but small samples (tens) are unreliable because latency distributions are typically skewed with fat tails. Aim for hundreds of observations per session and repeat tests across different sessions and market conditions. Report medians and upper percentiles (90th/95th) rather than just means.
If I find high latency or frequent slippage, what should I do next?
First, reproduce the tests while changing one factor at a time: wired vs Wi‑Fi, local PC vs VPS, different ISP, or different account type. Collect packet traces and platform logs and present them to the broker asking for clarification. If the broker cannot provide a plausible explanation, consider escalating to your regulator and keep your raw logs as evidence.
Sources
European Securities and Markets Authority (ESMA) (https://www.esma.europa.eu/)