Skip to content
Learning path Gold Professional operator

Execution latency: order path, timestamps, and measurement

Execution latency comprises the delays between decision, submission, receipt, routing, acknowledgment, and fill reporting. It must be measured by segment with coherent clocks; it is not the same as slippage or execution quality.

In simple terms — Between a decision and its fill report sit the platform, network, broker, controls, router, and venue. A single “click-to-fill” number mixes technical delays, decision time, and the wait for a counterparty. Separate timestamps and coherent clocks are needed to locate a problem.

Execution latency is elapsed time across one or more stages of the order lifecycle. There is no single start and end point that suits every analysis. Possible measurements include signal-to-send, send-to-broker-receipt, routing, venue entry, acknowledgment, execution, and fill-report return.

The word “execution” may also refer to different events. An acknowledgment normally confirms receipt or acceptance, not a fill. An order may receive several partial fills. A non-marketable limit order can rest in a queue for minutes even though it crossed the technical infrastructure in milliseconds. Waiting for liquidity is not automatically technical latency.

Execution latency: measure each segment Consistent timestamps separate infrastructure, decision and fill waiting time. Lower latency ≠ a guaranteed fill or better price Execution latency: measure each segment Consistent timestamps separate infrastructure, decision and fill waiting time Signalevent or decision i Submitclient → broker i Controlsrisk and routing i Venuereceipt and sequence i Returnack and fill reports i Synchronized clocks · stated unit and percentile Lower latency ≠ a guaranteed fill or better price Cyclepedia diagram · Emiciclo
Each segment has a different timestamp and responsible system. Subtracting times recorded by unsynchronized clocks can produce a false measurement.

Components of the order path

Segment Example interval What it may include
Market data venue event → data received feed, consolidation, network, parsing
Decision data or signal → order generated logic, computation, human intervention
Client/broker client send → broker receipt platform, network, gateway
Broker internal receipt → forwarding validation, risk controls, throttling, routing
Broker/venue forwarding → venue entry network, gateway, and ingress queue
Venue entry → acknowledgment or match
Report venue event → message received execution feed, broker, and return network

The appropriate end-to-end interval depends on the question. An automated strategy may measure from the market-data timestamp to the fill report; a broker-routing audit may begin at first receipt of the order; a venue measures only events within its own perimeter.

Under SEC Rule 605, time of order receipt is the point at which an order is first captured by the receiving entity's automated system. That choice makes benchmarks and statistics comparable within the covered U.S. reporting perimeter. It is not necessarily the client's click time or entry into the matching engine.


Clocks, timestamps, and sequence

A timestamp is useful only when the following are known:

  • the clock that generated it;
  • the precise system point where it was applied;
  • its time zone or time reference;
  • its granularity and accuracy;
  • clock corrections, drift, and synchronization method;
  • handling of events with the same timestamp.

A monotonic clock, which is not subject to wall-clock adjustments, is preferable for measuring an interval within one machine. Reconstructing events across systems instead requires a common, traceable time base. Commission Delegated Regulation (EU) 2025/1155 requires entities within its MiFIR scope to synchronize business clocks to UTC, with accuracy levels that vary by activity and system. Articles 11–16 apply from 2 March 2026. It is a specific regulatory requirement, not evidence that every commercial timestamp is perfectly synchronized.

Subtracting a venue timestamp from a client timestamp without knowing the clock offset can even produce negative latency. A round-trip measurement on the same client avoids subtraction between clocks, but includes the outbound path, processing, and return path. Dividing it by two does not necessarily produce one-way latency because the two paths may be asymmetric.


A correctly interpreted example

On the client's monotonic clock:

  • the signal is generated at 0 ms;
  • the order is sent at 2 ms;
  • the acknowledgment is received at 24 ms;
  • the first fill report arrives at 80 ms.

The observations support a 2 ms local decision interval, 22 ms from submission to received acknowledgment, and 78 ms from submission to received fill report. They do not reveal where the 22 ms were spent or establish that the match occurred at 80 ms. The report may have reached the client after the event at the venue.

The 56 ms between acknowledgment and report may include queue waiting, lack of a counterparty, matching, and message transmission. If the order was passive, that interval mainly describes time to first fill, not network delay.

Locating the segment requires additional broker and venue timestamps with documented origins and synchronization, or controlled measurements of each part of the path.


Useful metrics

One average conceals spikes and long tails. An audit can report:

  • median, p95, p99, and maximum for each segment;
  • distributions by venue, instrument, and time window;
  • time to acknowledgment, time to first fill, and time to completion separately;
  • rates of timeouts, rejects, retries, and out-of-sequence messages;
  • difference between event timestamp and receipt timestamp;
  • quantity executed within each time interval.

The SEC includes speed and executed quantity among the dimensions of execution-quality statistics. Speed must nevertheless be read alongside price, fill rate, and order type. A venue that quickly returns a rejection does not provide the same outcome as one that completes the order, and an instant fill at a worse price is not automatically superior.


Latency, slippage, and quality

Latency and slippage may be correlated, particularly when quotes change quickly, but they are not synonyms, and correlation alone does not prove causation. During the delay, price may move favorably, a counterparty may arrive, or the order may remain unchanged. Slippage also depends on spread, depth, size, order type, and market impact.

Lower latency reduces some timing risks, but does not guarantee:

  • the best price;
  • a complete fill;
  • correct routing;
  • absence of adverse selection;
  • an economically justified infrastructure cost;
  • a sound trading decision.

Within its scope, MiFID II Article 27 lists price, costs, speed, likelihood of execution and settlement, size, and nature among best-execution factors. Speed is therefore one dimension, not the whole of execution quality.


Controls and limitations

Reproducible measurement requires defining events before analyzing logs. “Send” may mean the click, the API call, or departure from a gateway. “Fill” may mean the match at the venue, the broker report, or an interface update. Changing definitions between systems invalidates the comparison.

Useful controls also include:

  1. unique identifiers linking orders, acknowledgments, modifications, and fills;
  2. sequence numbers in addition to timestamps when granularity cannot separate events;
  3. retention of errors, cancellations, and residual quantities;
  4. periodic checks for drift and lost synchronization;
  5. segmentation by order type and market state;
  6. separation of market-data, decision, and infrastructure latency.

Common mistake — Comparing the local click timestamp with the venue timestamp as if they came from the same clock, or attributing the entire time to fill to the network. Without documented measurement points and clocks, the number cannot identify a cause.


Sources