Plataformas · Software · Provedores · Mercados
A one basis point execution penalty on $10 million of daily notional costs $1,000 a day, or about $250,000 over 250 trading days. That is the cost if the full flow suffers the penalty. Latency alone does not establish causation, but delayed decisions can expose orders to stale prices, missed queue priority and adverse selection. Treat order routing latency as a measurable execution risk, not a single number on a dashboard.
Start with the cost and define the clock
Measure the same interval
Write down the start and end events before comparing systems. Client-to-acknowledgement time includes client access, gateway processing, risk checks, routing and the return path. It is useful for service monitoring, but it does not tell you how long the order waited before reaching a venue. For that, measure gateway receipt to venue send, venue send to acknowledgement, and each internal stage separately.
Record event timestamps with a monotonic clock for durations, and keep wall-clock synchronisation for correlation across hosts. PTP is common in low-latency environments; verify offset and holdover behaviour rather than assuming the configuration is correct. Venue timestamps can use a different clock and mark a different event. Do not subtract them from local timestamps without checking the timestamp definitions and clock error.
Set a hop budget
The table gives typical market ranges for a well-configured electronic route. They are diagnostic bands, not service guarantees.
A venue, protocol, region, order type and load profile can move a component outside them. The figures are not additive in practice: stages overlap in some designs, while queuing under burst load can dominate the sum.
| Route component | Typical p50 range | Typical p99 range | What to inspect |
|---|---|---|---|
| Client network to broker edge | 0.3-3 ms | 2-20 ms | Region, access network, retransmits |
| Gateway decode and session handling | 0.05-0.3 ms | 0.2-2 ms | Thread contention, parsing, session load |
| Pre-trade risk checks | 0.05-0.5 ms | 0.5-5 ms | Remote calls, locks, limit refreshes |
| OMS or EMS queue and route decision | 0.05-0.8 ms | 0.5-10 ms | Queue depth, persistence, rule evaluation |
| Broker network to venue gateway | 0.05-0.5 ms | 0.1-2 ms | Cross-connect, switches, congestion |
| Venue processing to acknowledgement | 0.1-1 ms | 0.5-5 ms | Venue load, protocol and order state |
Use percentiles, not just averages. A route with a 0.4 ms median and a 15 ms p99 can be more damaging than one with a steady 1 ms response.
Preserve samples by venue, symbol, order type and market state. A single blended number hides the cases that create rejects or poor fills.
Find queues before optimising code
Risk and order management
Risk checks often contain more latency than the network. A synchronous call to a remote limit service, a contended account lock, or a database write on the hot path can add milliseconds and widen the tail.
Measure each check and separate checks that must complete before release from reporting or persistence work that can run asynchronously. Do not move a control off the path without an approved control design and a clear failure mode.
Instrument queue depth as well as processing time. If a single-threaded consumer receives 20,000 messages a second but drains 18,000, its backlog grows even when each individual handler is fast.
Track oldest-message age, rejected orders and recovery time after bursts. Apply backpressure or reject explicitly; an invisible queue converts overload into stale orders.
Network, protocol and venue
Network distance has a floor. Light in fibre travels roughly 5 microseconds per kilometre one way, before switches, route length and protocol handling.
A cross-region path can therefore cost several milliseconds round trip. Co-location or a cross-connect can reduce the network segment, but it will not repair slow risk checks or a congested application thread.
Check TCP retransmits, packet drops, NIC queues, interrupt placement and switch-buffer pressure. For FIX, inspect message parsing, session sequencing and resend behaviour. For binary protocols, measure decode and state-management costs too. A low median with retransmit-driven spikes is usually a network or host-path problem, not a reason to rewrite the router.
For a broader view of the systems behind broker platforms, Trading Technology's infrastructure coverage can help frame the operational context. Keep the investigation local to your measured route, however. Vendor latency claims rarely use your order mix, clocks or traffic peaks.
Choose routes on execution quality, not speed alone
The fastest acknowledgement is not automatically the best execution. Compare fill probability, price improvement, rejects, partial fills and slippage against a consistent arrival-price benchmark. A route that acknowledges in 300 microseconds but regularly fills at a worse price may cost more than one that takes 1 millisecond and reaches better liquidity.
Keep routing decisions explicit. For each destination, record eligibility, expected fees, available liquidity, throttles, session health and the fallback condition.
Revisit route weights when venue behaviour changes, rather than relying on static preferences set during initial integration. For retail flow, internalisation, last-look policies and disclosure requirements also affect what a route is permitted to do. Measure decision-to-send time separately from the venue response.
- Compare fill outcomes by symbol, order size, volatility and time of day.
- Report marketable and passive orders separately, including cancels and amendments.
- Distinguish a venue reject from a broker reject, and record the reason code.
- Test failover with live-like message rates, not only a quiet certification session.
Set a latency budget for each critical segment and alert on both p99 and sustained queue age. A practical first step is to define a budget from observed baseline data, then set a warning threshold at 1.5 times the baseline p99 and an incident threshold at twice baseline.
These are starting points, not universal limits. A strategy with a 2 ms decision horizon needs tighter controls than a low-frequency order workflow.
Run the route as a production control
Keep dashboards tied to decisions operators can take. Show latency by route and stage, alongside throughput, rejects, queue depth, session state and venue health. Retain enough high-resolution data to investigate short bursts, while using sampled or aggregated data for longer-term reporting. A daily average cannot explain a 40 ms spike during a market open.
Exercise operational cases regularly: a venue stops acknowledging, a session drops, a risk service becomes slow, or a network path degrades without failing outright. Define whether the system holds, cancels or reroutes each order state.
Blind retries can duplicate exposure or worsen congestion. Make idempotency, sequence recovery and operator permissions part of the test, then review evidence after each change. Stop doing these things:
- Stop treating round-trip time as a complete measure of execution quality.
- Stop optimising median latency while ignoring p99 and queue age.
- Stop retrying orders without checking state and duplicate risk.
- Stop changing routing weights without measuring fills and slippage afterwards.
Perguntas frequentes
What is order routing latency?
It is the time taken for an order to pass through the relevant routing stages, from a defined start event to a defined end event. Teams should separate client-to-acknowledgement time from internal processing and venue response time.
Which part of an order route usually adds the most latency?
Risk checks, application queues and network distance are common sources. The dominant component varies by architecture and traffic, so measure each stage and inspect tail latency rather than assuming the venue is responsible.
What is a reasonable p99 order routing latency?
There is no universal target because order type, region, venue and strategy horizon matter. Typical component ranges can be used as diagnostics, but set the production budget from measured baselines and the needs of the flow.
How should a broker measure trading latency?
Timestamp each meaningful event, use monotonic clocks for local durations, and verify clock synchronisation when correlating hosts. Report percentiles by route, venue, symbol and order type, with queue depth and rejects alongside latency.
Does lower routing latency always improve execution?
No. Faster routing can reduce exposure to stale prices or help preserve queue priority, but it does not guarantee a better fill. Compare execution outcomes such as slippage, fill rate, price improvement and rejects.
