Plataformas · Software · Provedores · Mercados
One broker puts an additional credit and exposure check in the order path, accepting a few hundred microseconds of delay to keep limits current. Another caches more risk state at the gateway and routes faster, accepting the operational burden of keeping that cache consistent. Both calls can be defensible. The problem is treating either as a pure speed decision rather than a control design with measurable consequences.
For a broker or prop firm, order routing latency is the elapsed time across a chain: client or strategy, edge, gateway, risk controls, route selection, network and venue. A slow print on a dashboard does not identify which component caused the delay. Nor does a low average prove that controls ran on every order or that routing decisions can be explained afterwards.
Latency work therefore belongs with risk, compliance and operations. Teams need to know where time is spent, what happens when a component fails, and which records support an execution review. The reporting and infrastructure coverage at Trading Technology regularly puts those operational questions in context.
Map the path before optimising it
Separate each clock and queue
Instrument order receipt at the network interface, application ingress, completion of each risk decision, route selection, outbound send, venue acknowledgement and fill. Use a monotonic clock for elapsed time inside a host. Keep wall-clock timestamps for correlation across systems, with clock health and uncertainty recorded. If every stage stamps an event using a different clock, subtracting timestamps can manufacture latency or hide it.
Queueing often matters more than the code path. A gateway that takes 100 microseconds to process an order can still add milliseconds when its worker pool is saturated or a downstream risk service is slow.
Record queue depth, service time, rejection reason and timeout outcome alongside latency. Keep the order identifier and decision version attached to each event, subject to the firm's privacy and retention rules.
Use ranges, not a single headline
The figures below are typical market ranges, not service guarantees. They vary with geography, hardware, protocol, traffic, product and venue. Treat them as a first diagnostic, then baseline the actual path under normal and stressed load.
| Path component | Typical market range | Common source of variation | Evidence to retain |
|---|---|---|---|
| Client connection to broker edge | 5-80 ms over public internet | Distance, last-mile network, TLS and packet loss | Edge receipt time, connection and packet metrics |
| Gateway parsing and normalisation | 20-300 μs | Message size, allocation, session load | Ingress and completion timestamps, software version |
| Pre-trade risk checks | 50-500 μs for local checks; 0.5-3 ms for more complex paths | Remote lookups, shared state, rule count and contention | Decision, limit version, inputs and timeout status |
| Route selection | 10-150 μs | Eligibility logic, market data freshness, fallback state | Eligible destinations, selected route and reason |
| Private network hop to venue | 10-100 μs one way when nearby | Distance, switches, cross-connect and congestion | Send time, interface counters and destination |
| Venue acknowledgement | 50-500 μs after arrival, often higher under load | Venue processing, message type and market conditions | Broker send time and venue acknowledgement time |
Do not add every high-end figure and call the result a benchmark. The stages may overlap, and the measurement boundary matters.
Compare the same order population and clock points. Track median, 95th, 99th and 99.9th percentile, plus timeout and reject rates. A 200-microsecond improvement at the median has little value if the 99.9th percentile worsens by 10 milliseconds during a busy open.
Make risk controls part of the route design
Keep checks explicit and fail safely
Pre-trade controls can include order size, price collars, credit, position, product eligibility and message-rate limits. Decide which checks must complete synchronously before release and which monitoring can run after execution.
That boundary should be documented for each order type and account class. A hard limit that is unavailable must not silently become a permissive default.
Local caches can reduce round trips, but they create a consistency problem. Specify how quickly limit changes reach every gateway, how stale state is detected, and what the gateway does while state is uncertain. A common pattern is a bounded cache age with a reject or hold path after expiry. The acceptable bound depends on the risk and product, not on a generic latency target.
Timeouts need the same care. If a risk service times out after an order has been sent, blindly retrying may create a duplicate. Give each request an idempotency key, distinguish "not released" from "release status unknown", and reconcile uncertain outcomes against the downstream session or venue. Test failover and recovery with orders in flight, not only with a clean service restart.
Retain the reason for a route
Routing logic can weigh venue availability, price, fees, liquidity, account permissions and product-specific restrictions. Preserve the candidate destinations and the reason for the selected route, including the market-data or configuration version used. This makes it possible to investigate whether a slow or poor execution followed the intended rules, a stale input, or a fallback.
For firms subject to best-execution or market-access obligations, the applicable record and control requirements depend on jurisdiction and business model. The practical engineering point is consistent: retain enough detail to reconstruct what the system knew and did at the time.
An execution report alone rarely explains a route choice. Review broker platform operations coverage alongside internal control documentation, rather than treating latency dashboards as a compliance record.
Measure tails and investigate exceptions
Build a per-stage latency budget and alert on deviations from the firm's own baseline. A 1-millisecond budget may be reasonable for one colocated path and meaningless for an internet-facing retail path. Segment by gateway, venue, order type and session. Keep burst periods and market opens in the analysis; averages across quiet overnight traffic can conceal the conditions that matter most.
Useful operational views include:
- End-to-end and per-stage percentiles, split by order type and destination.
- Queue depth, CPU saturation, garbage collection, packet loss and risk-service timeouts.
- Rejects, cancels and duplicate-prevention events, not just accepted orders.
- Route changes, fallback frequency, stale market data and configuration versions.
Set thresholds around action, not vanity. A rising 99th percentile should identify the owning service and provide a trace for a sample order.
Compare latency against fill quality, slippage, rejects and venue response. A faster route is not an improvement if it increases erroneous releases, sends orders to an unavailable destination or weakens the evidence needed to explain execution.
Changes to routing and risk logic should have an owner, approval record, test evidence and rollback path. Replay representative traffic where possible, then run controlled production checks with limits and monitoring in place.
Review the first sessions after a change for both latency distribution and control outcomes. Keep a known-good configuration available, and ensure operators can disable a destination without bypassing required risk checks.
Stop doing these things
- Stop reporting one average as the latency of the whole route.
- Stop subtracting timestamps from unsynchronised clocks.
- Stop treating a timed-out risk check as permission to release an order.
- Stop changing route weights without retaining the decision, approval and rollback evidence.
Perguntas frequentes
What causes order routing latency?
Latency accumulates across client connectivity, gateway processing, risk checks, route selection, network hops and venue processing. Queueing, remote service calls and packet loss can create much larger delays than the normal processing time of a single component.
How should brokers measure order routing latency?
Timestamp each meaningful stage, from receipt through risk decision and outbound send to venue acknowledgement. Use monotonic clocks for elapsed time within a host, correlate systems with monitored clock synchronisation, and report percentile distributions rather than averages alone.
Do pre-trade risk checks make routing slower?
They add processing time, typically from tens or hundreds of microseconds for local checks to milliseconds for more complex or remote paths. Caching can reduce delay but requires freshness limits, consistent updates and a defined fail-safe response.
What routing records should a broker retain?
Retain timestamps, risk decisions and relevant limit versions, candidate and selected destinations, route reasons, configuration versions, and venue acknowledgements. The exact retention and reporting obligations depend on jurisdiction and business model.
