Latency budgets for systematic strategies

Most people who have not worked inside this industry assume trading technology is about one thing: speed. Be first, or lose. It is a clean story and it is right for some strategies and wrong for a lot of others, ours included. Being fastest matters enormously if your edge lives in the first few microseconds after a price changes, when you are racing other systems to the same fleeting mispricing before it closes. Plenty of firms run that game and run it well. It is not ours.

Our strategies mostly work on horizons long enough that arriving a millisecond earlier or later changes almost nothing about whether a trade is good. What actually matters is knowing, in detail and with evidence, where every microsecond between a market event and our order landing on a venue goes. Call that a latency budget: an accounting broken into pieces small enough to reason about individually, rather than one number that tells you almost nothing about where to spend an afternoon. Get the budget wrong in one direction and you chase speed nobody’s edge depends on, burning engineering time on a millisecond that was never going to move your P&L. Get it wrong the other way and you ignore a slow piece that is quietly costing you fills every single day. Neither mistake announces itself. You only find out once you go looking properly.

The five contributors

We split the path from a market event to an order landing on a venue into five pieces and measure each on its own.

Market-data ingestion runs from the venue’s wire to a usable price inside our process: parsing the feed, rebuilding the book from an incremental update, and stamping the moment we believe the update happened. It is dominated by parsing cost and by physical distance from the feed, and we measure it against the timestamp the venue itself puts on the update, not against our clock alone, because a clock that only agrees with itself is not measuring anything.

Decision cost is the price of asking the model what to do given the new state, and it lives or dies on how much work the model performs per tick. A model that recomputes half its state from scratch on every update pays that cost every time; one that maintains incremental state pays once and updates cheaply after that. We time model entry and exit and track how the whole distribution shifts as we change the model, since the average alone hides where the cost sits.

Order construction is the dull one: turning an internal decision into bytes a venue’s gateway will accept, respecting whatever validation and sequencing that particular venue demands. It rarely dominates the budget, but it is where subtle bugs like to hide, because an order that is syntactically valid but semantically wrong fails silently rather than loudly, and you do not notice until the fills stop matching intent.

Network egress is the trip back out to the venue’s gateway, and it is mostly physics: distance, and how much contention there is on the wire in between. It is the most legible of the five, because it behaves the way a network engineer already expects it to.

Venue processing is the one piece we do not own at all. It happens inside somebody else’s matching engine, invisible to our instrumentation. We can only characterise it in distribution, by watching acknowledgement timestamps come back over enough orders to see its shape, and how that shape changes around auctions, news, or simply a busy Tuesday.

Four of the five are ours to speed up directly. The fifth we can only measure cleanly and plan around.

Percentile thinking

Once you have five distributions instead of one number, the next question is which part of each distribution actually matters, and the honest answer is almost never the mean.

Take a system where the median round trip sits comfortably inside budget but one order in a thousand takes fifty times longer. The mean looks fine. The p50 looks fine. The p99.9 is the number that describes what happens to your worst fills, and your worst fills are disproportionately the ones that move your P&L, because they cluster exactly where the market is moving fastest and where being late costs the most. Optimising the median while ignoring the tail is optimising the part of the distribution that was never going to hurt you.

Measuring the tail honestly is harder than it sounds, for two separate reasons. The first is clock synchronisation: if the clock stamping ingestion and the clock stamping the order disagree by more than the latency you are trying to measure, your percentiles are just describing clock drift. We synchronise every host on the hot path tightly and check it continuously, because a latency number built on an unsynchronised clock is a number about nothing.

The second is nastier, because it is invisible until somebody shows you where to look. It is called coordinated omission. If you only measure the latency of requests your system managed to issue, and the system falls behind under load, exactly the requests that would show the worst latency are the ones that never get issued at all, or get issued late and counted as though they started on time. The measurement quietly excludes its own worst cases, and the histogram comes back looking healthier than the system actually is. It is a bit like timing a queue with a stopwatch that only starts once you are already being served: everyone in the queue looks fast, because the clock never ran for the people standing there waiting. The correct fix is to timestamp from the moment the event itself happened. How this interacts with sampling and buffering upstream of your own instrumentation is a longer story, worth its own note one day, but I will park it here and get back to the tail itself.

Once you measure the tail honestly, it becomes the thing you manage: p50 tells you what a normal trade costs, p99.9 tells you what a bad day costs, and a bad day is where the money moves.

Basis points versus ticks

Whether any of this is worth chasing depends entirely on where your edge lives, and people skip past that question too quickly.

If your edge is a handful of ticks captured by being early to a signal that decays in microseconds, latency is the strategy, and every microsecond you shave is edge you keep instead of handing it to whoever got there first. Chase it relentlessly. In that game the tail is the whole game.

If your edge is measured in basis points on a horizon of minutes or longer, the calculation runs differently, and it is easy to get backwards. A 200 microsecond median execution with a heavy 50 millisecond tail is worse for most such strategies than a 1 millisecond median with a tight 2 millisecond tail, even though the first number reads far better on a slide. The first system is faster on a normal day and expensive on a bad one, and bad days are exactly when your model is trading against a market that has just moved, which is when a fifty millisecond miss costs something. The second system gives a little away on ordinary days and never surprises you on the ones that matter.

The real question is whether the distribution is predictable, and whether the edge you are chasing is big enough to survive the tail you actually realise once positions are live. Get that right and you rarely need to be fastest to be profitable.

Is colocation even worth it

Given all that, colocation deserves a more honest answer than the industry’s default “obviously yes.” For a strategy where microseconds are the edge, colocation is not optional, it is table stakes. For a longer-horizon systematic book like ours, the honest answer is usually no, and the money is better spent reducing variance and improving attribution than shaving a mean that was already comfortably inside budget.

Colocation buys a smaller, more predictable egress term, and that is a real thing to want. It also comes with an ongoing bill, and it ties you to one physical site in a way that gets expensive to undo later. If egress was never the binding constraint on your fills, colocation makes one of your five numbers smaller without moving the number that decides whether you make money. Pay for it only when the maths says the tail you are chasing genuinely lives in that term. A faster median on a slide is not a reason.

The discipline

What it actually takes is unglamorous discipline. Telemetry needs to timestamp every boundary without fudging the clock. Whoever handles attribution has to trace a slow fill back to the layer actually responsible for it. Underneath both of those, you need enough scepticism of your own measurements to go looking for coordinated omission before trusting a histogram that looks healthy.

The firms that get hurt by latency are rarely the slow ones. They are the ones who measured the wrong percentile, or measured the right one badly, and only found out once the tail arrived in size on a day the market was already moving against them. Most of this job is just refusing to let that be you.