By La Formule FrançaisePublished 8 min read
Latency is the time consumed between an event in the market and a system acting on it. It is not one delay but a chain: observation, transport, calculation, order submission, venue processing and confirmation.
Speed matters only relative to the lifetime of the opportunity. When the edge disappears faster than the whole execution chain can complete, the strategy is not merely slow; it is testing a market state it cannot trade.
The market data is already old
A venue creates an event, packages it into a feed and sends it across a network. The strategy receives that message after each of those steps. The displayed price is therefore a report of a recent state, not direct access to the present one.
A historical file hides this distance because its rows are already complete and ordered. Live data can arrive late, out of sequence, duplicated or in bursts after a pause. Code written for tidy bars is being asked a different question when it meets a live stream.
Before speed is discussed, the system needs a rule for stale data: how old a message may be, what happens after a gap and which clock defines the measurement.
Calculation is only one part
The rule then consumes time parsing the message, updating its state, calculating a signal and deciding position size. This is the part most easily improved in code and therefore the part most often mistaken for the whole problem.
A faster calculation cannot recover time lost before the data arrived or after the order left. Optimising the rule while ignoring the network and venue produces a benchmark that describes the computer, not the trade.
The useful measurement marks each boundary separately. One total duration can show that the chain is slow; timestamps at each boundary show where.
The order joins another system
Submission is not execution. An order crosses the network, is authenticated and checked, then enters the venue's matching process. Other messages and orders may reach that process first.
That queue is why identical logic does not imply identical fills. Two systems can observe the same event and submit the same order, while their place in the queue leaves one filled and the other waiting.
A backtest that assigns every order the observed price has removed this entire stage. It tests the decision rule under imaginary execution rather than the complete system.
Opportunity has a lifetime
Not every strategy needs to be fast. A decision based on a slow change can tolerate a longer chain because the market condition it describes persists. A decision based on a brief imbalance cannot.
This creates the barrier to entry. Competing on short-lived information requires control of the feed, network path, hardware, software and venue access at the same time. Improving only one leaves the slowest stage in charge.
The question is therefore not whether a system has low latency in the abstract. It is whether its measured end-to-end delay is short enough for the event the strategy claims to trade.
Latency becomes slippage
While the order is travelling, available prices can change. The difference between the price used by the decision and the price available to the order appears as slippage, a missed fill or both.
This cost is selective. It tends to be most visible when many participants react to the same event, which is also when a demonstration is most tempted to assume an immediate fill.
A realistic test does not need to predict every queue. It does need to stop treating the signal price as a guaranteed execution price and show how the result changes when delay and fill uncertainty are present.
What to measure
Record the timestamp at source when available, arrival at the strategy, completion of calculation, submission, venue acknowledgement and fill. Keep rejected, partial and unfilled orders in the same record rather than deleting them from the sample.
Compare those measurements across ordinary and stressed periods. A system that is quick only when the market is quiet has not measured the condition in which speed matters most.
The result is not a recommendation or a performance claim. It is an engineering description of whether the system tested and the system operated are the same thing.