Definition
Execution latency is the total time elapsed between the moment a client submits an order and the moment the execution confirmation is returned. This seemingly simple metric is actually the sum of multiple discrete stages, each adding measurable delay. Understanding the breakdown matters because different latency components have different causes, different magnitudes, and different implications for execution quality.
In FX, latency is typically measured in milliseconds (ms). Institutional participants may measure in microseconds. For retail execution, the total round-trip latency from order submission to fill confirmation typically ranges from 50ms to 500ms depending on the broker's technology stack, geographic setup, and LP configuration. Each millisecond of delay represents additional exposure to market movement.
What It Is / What It Is Not
What Latency IS
- The cumulative time from order submission to execution confirmation
- Composed of multiple stages: network, gateway, bridge, LP response
- Directly affects slippage risk -- longer latency = more market exposure
- Measurable and reportable as a distribution (median, P95, P99)
- A function of infrastructure quality, geography, and LP configuration
- Different for market orders vs limit orders vs stop orders
What Latency IS NOT
- Not the same as LP last look duration (that is one component within overall latency)
- Not constant -- varies by time of day, volatility, LP load
- Not solely the broker's fault -- network path and LP response are external factors
- Not always bad -- some latency is inherent and unavoidable in distributed systems
- Not a single number -- it is a distribution with outliers that matter most
- Not the same as platform charting delay (that affects display, not execution)
Latency Components
Each order passes through a chain of processing stages. The total latency is the sum of all stages. Identifying which stage contributes the most delay helps diagnose execution quality issues.
| Stage | Description | Typical Range |
|---|---|---|
| Client → Broker | Network transit from client device to broker server | 5-100ms (depends on geography and connection quality) |
| Gateway Processing | Broker server receives, validates, authenticates the order | 1-10ms |
| Bridge / SOR Logic | Price check, LP scoring, venue selection, order construction | 1-20ms |
| Broker → LP/ECN | Network transit from broker to LP (often via PoP/PB) | 1-50ms (co-located: sub-ms; cross-datacenter: 10-50ms) |
| LP Processing | LP receives order, runs risk checks, decides to fill/reject | 1-5ms (no last look) to 50-200ms (with last look) |
| LP → Broker | Execution report returned to broker | Same as outbound network path |
| Broker → Client | Confirmation delivered to client platform | Same as initial client-to-broker path |
Typical Total Round-Trip Timings
| Scenario | Typical Total | Notes |
|---|---|---|
| Institutional (co-located) | < 5ms | Server in same datacenter as LP/ECN; no last look |
| Professional (good setup) | 20-80ms | Dedicated server, direct LP, minimal hops |
| Retail (standard) | 50-200ms | Consumer internet, bridge + PoP chain, LP with last look |
| Retail (poor setup) | 200-500ms+ | High-latency connection, remote datacenter, slow LP response |
The difference between 50ms and 200ms may seem small, but at a rate of 1 pip per 100ms of market movement (during active sessions in EUR/USD), 150ms of additional latency represents approximately 1.5 pips of additional slippage risk on every market order. Over thousands of trades, this compounds significantly.
Where It Appears in the Execution Stack
Benefits & Trade-offs of Latency Awareness
| Factor | Detail | |
|---|---|---|
| Slippage reduction | Understanding latency sources helps identify fixable bottlenecks | |
| LP selection | Fast-responding LPs can be weighted higher in scoring to improve fills | |
| Infrastructure investment | Broker co-location and network optimization reduce controllable latency | |
| Cost of optimization | Low-latency infrastructure is expensive; cost is passed to clients | |
| Diminishing returns | Below ~20ms total, further optimization has minimal retail impact | |
| Last look dominance | LP last look window often dominates total latency and is outside broker control |
Common Marketing Claims vs Reality
| Claim | Reality |
|---|---|
| "Ultra-low latency execution" | Ultra-low typically means sub-1ms in institutional context. Retail brokers claiming this are usually referring to their server-to-LP leg only, not total round-trip including client network latency. |
| "Average execution: 40ms" | Ask what is measured: server-to-LP, or full client round-trip? Averages can be misleading; P95 and P99 values reveal outlier behavior during volatile conditions when latency matters most. |
| "Equinix NY4/LD4 co-location" | Co-location helps the broker-to-LP leg but does not help the client-to-broker leg. If you are trading from a home connection, the co-location benefit is limited to internal routing. |
What to look for in an Execution Policy
- Does the execution policy report average and P95/P99 execution latency?
- Is the measurement defined (full round-trip vs server-to-LP only)?
- Does the broker disclose its server locations and co-location setup?
- Are latency statistics broken down by order type (market, limit, stop)?
- Does the policy address how latency is monitored and optimized over time?
- Is there disclosure of LP last look windows and their impact on total latency?
See a Public Routing Disclosure Example
NDD.broker publishes detailed order routing and execution policy documentation, including LP composition, priority logic, and conflict mitigation. This serves as a reference implementation of the concepts described above.
Educational content only. This is not financial advice. Always consult qualified professionals before making trading decisions.