Order routing latency: where the milliseconds go

At $100bn of annual routed notional, 0.1 basis points of avoidable execution cost is $1m. Latency can contribute to that cost when an order reaches a venue after prices or available liquidity have changed. It is not the only cause, and shaving microseconds does not guarantee better execution. But a slow or unstable route can turn into poorer fills, missed opportunities and higher support costs.

The useful question is not whether the trading stack is fast. It is where time accumulates between order creation and acknowledgement, how often delays occur, and whether the route still delivers the intended execution. A cost model should separate direct execution effects from engineering and operational expense.

Start with the cost of the route

Execution cost has several parts. Slippage measures the difference between the decision price and the achieved price.

Missed fills matter when a passive order loses queue priority or the market moves away before the order arrives. Adverse selection captures the risk that an order fills just before the price moves against it. Fees, rebates and venue mix also affect the result, but are not latency measures by themselves.

For a simple estimate, multiply annual routed notional by the change in execution cost in basis points. At $100bn, 0.1 basis points equals $1m; at $10bn, it equals $100,000.

Treat this as a sensitivity calculation, not a forecast. To attribute an improvement to routing, compare similar symbols, order types, time periods and market conditions, then control for venue and participation rate.

There are also costs outside the fill. A remote risk check may add a network dependency.

A congested gateway can create support incidents or cause bursts of rejects and cancels. Running a dedicated low-latency stack can mean more specialist staff, hardware, colocation and release controls. These expenses are justified only if the route improves the firm's measured outcome enough to cover them.

For operational analysis, keep execution quality, route duration and system availability as separate measures. A fast acknowledgement can still precede a poor fill. A slower route may be appropriate for a large order seeking discretion. The engineering target is predictable behaviour for the strategy and order type, not the smallest number in isolation.

Break the path into measurable stages

The table gives typical market ranges for a colocated, same-region route using a tuned electronic trading stack. It assumes steady-state conditions and measures each stage from entry to exit.

The figures are indicative, not service-level guarantees. A broker using a public network, remote risk service or different venue protocol can see substantially higher figures.

Do not add the p99 figures and call the result a route p99. Percentiles from separate stages do not necessarily occur on the same order, and their distributions can change under load. Measure end-to-end latency as well as stage timings, using a consistent clock and a clearly defined start and end event.

For a colocated route, a typical end-to-end order-to-acknowledgement range may sit around 0.2-2 milliseconds, depending on the venue, protocol and stack. A route across a regional or public network can take several milliseconds or more. The range matters less than whether the firm can explain its own distribution and identify the tail.

Find the queues, not just the slow functions

Median latency is useful for comparing a stable path. The p99 and p99.9 show what happens to a small share of orders, which may cluster during bursts, auctions or volatile markets. A component can have a low average processing time and still hold orders behind a full queue. Capture timestamps at each boundary, along with queue depth and system load.

• Application scheduling: thread contention, garbage collection, context switches and lock waits can add intermittent delay. A busy CPU is not proof of a bottleneck, so correlate host metrics with per-order timestamps.
• Risk and reference data: a local cache lookup can take microseconds, while a synchronous call to another service may add hundreds of microseconds or more. Remote checks also add a failure mode when that service slows or becomes unavailable.
• Gateway and protocol work: FIX parsing, message validation, session sequencing and encryption all use CPU. Batching can improve throughput, but waiting to build a batch adds latency for the first order in it.
• Network path: cross-connects, switches, NIC queues, retransmissions and route changes contribute delay. A short physical distance does not rule out queuing or packet loss.
• Venue and return path: acknowledgement timing depends on venue processing and network conditions in both directions. Separate the outbound order time from the acknowledgement receipt rather than treating the total as gateway processing time.

Clock quality determines whether these measurements are credible. Use hardware timestamps where available and synchronise machines with a method suitable for the required precision, such as PTP in a controlled environment.

Record clock offset and uncertainty. If the clocks disagree by 50 microseconds, a claimed 20-microsecond stage improvement is not persuasive.

Instrument at the point where an order enters and leaves each process, not just at log-write time. Logging can itself add delay, especially when synchronous disk or network writes sit on the order thread. Use a low-overhead event path, preserve raw timestamps, and sample only after validating that sampling does not hide burst behaviour.

Choose the right speed trade-off

Optimising a route means choosing which work belongs on the critical path. Moving checks out of that path may reduce latency, but can weaken risk controls or leave decisions based on stale state. Duplicating a risk limit locally can improve speed, for example, but then the system needs a defined update mechanism, an exposure bound during disconnection and a fail-closed policy.

Routing policy has similar trade-offs. A smart order router may inspect venue prices and available size before choosing a destination. That decision can improve execution, but it takes compute time and may act on market data that has already changed. A direct route avoids some selection work, yet can concentrate flow at a venue with less suitable liquidity. Test both using the same order population and market conditions.

Teams often get more value from removing unpredictable waits than from reducing an already small median. These choices are worth testing separately:

• Keep mandatory validation local where the control design allows it, and measure the cost of every synchronous service call.
• Set queue limits and apply back-pressure before a gateway becomes overloaded. Define whether the system rejects, delays or reroutes new orders.
• Compare FIX and native protocols using the same order flow. Native messaging may reduce parsing and message overhead, but adds vendor-specific integration and support work.
• Use dedicated cores or thread pinning only after profiling shows scheduling interference. These measures can reduce jitter but complicate capacity planning and deployment.
• Separate low-latency routes from high-throughput routes if their batching and queueing requirements conflict. Maintain a tested failover path rather than relying on an unmeasured backup.

For broker and prop infrastructure teams, the decision record should state the target order types, expected load, risk model, venue coverage and acceptable failure behaviour. The engineering comparison should include p50, p99, p99.9, reject rate and execution-quality measures. Trading Technology's coverage of trading infrastructure provides wider context for platform and connectivity decisions, but the firm's own measurements should set the operating target.

Build a benchmark that survives production

A useful benchmark reproduces the path that production uses. A microbenchmark of a parser can isolate protocol costs, but it does not include queueing, risk state, network hops or venue response. Run controlled component tests to locate costs, then validate the changes with representative traffic in a production-like environment.

Replay recorded order patterns, including bursts, cancels and rejects. Test normal load and a stressed case at the expected peak, rather than only sending a constant flow. Measure both throughput and latency: a configuration that improves p50 while sharply worsening p99 under a burst may be a regression for strategies sensitive to stale orders.

Keep timestamps and definitions consistent across releases. For each order, capture creation, risk start and end, route decision, gateway enqueue, socket send, venue acknowledgement and client notification where applicable.

Document whether a reported number is one-way, round-trip, application-to-ack or venue-to-venue. That prevents teams from comparing unlike measurements in design reviews.

Establish a baseline by symbol, venue, order type and session period. Include system load and market conditions, since open, close and news-driven bursts can change both queueing and venue response. Run the comparison long enough to capture those periods, and report sample size with each percentile. Do not discard slow observations without recording why.

Finally, attach an owner and threshold to each critical stage. Alert on sustained tail growth, queue depth and failed timestamp capture, not just average latency. A threshold should trigger investigation before it becomes an execution incident, while allowing for normal variation between venues and trading sessions. This week, add per-order timestamps at the OMS, risk service and gateway boundaries, then capture one representative session as your baseline.

#order routing #trading latency #smart order router #FIX gateway #pre-trade risk checks #execution quality #p99 latency #market connectivity