Execution / Latency
Low-latency trading: where the milliseconds actually go
“Low latency” is the most quoted and least measured number in retail trading. A broker will advertise it, a vendor will claim it, and almost nobody will show you the round trip. Here is what the term should mean, how the budget is actually spent, and why colocation usually beats a faster CPU.
What low-latency trading means in practice
Low-latency trading means acting on a market observation before the opportunity disappears. It is not a property of a platform, an indicator or a hosting plan; it is a property of the whole path between seeing a price and owning a position. If the opportunity lasts fifty milliseconds and your path takes eighty, the strategy does not have a latency problem — it has no strategy.
That is why latency only becomes meaningful when it is expressed as a budget rather than a boast. A number without a break-down tells you nothing about which part you could remove. So the useful exercise is to split the round trip into its four components and check each one.
A horizon, not a speed
Holding periods of seconds need milliseconds; holding periods of days need none. Latency matters in proportion to how briefly the edge exists.
End to end
Feed plus decision plus transport plus venue. Quoting only the decision time is the most common way to make a slow system look fast.
Measurable
If it cannot be instrumented, it cannot be improved. A path that reports its own round-trip time is the only version worth trusting.
The four places your round trip is spent
Every order pays the same four tolls, and the one people optimise is rarely the one that matters.
1. Feed
How the price reaches your system: the broker’s market data feed, its depth, and how often the quote refreshes. A stale feed makes a fast system slow in the only way that counts.
2. Decision
The time your logic takes to turn a tick into an order. This is the cheapest part to improve, which is why it is the part every backtest measures and every vendor quotes.
3. Transport
The physical distance to the execution venue, travelled twice. On a short horizon this is usually the largest controllable component — and the one that cannot be optimised in software.
4. Venue
Queueing, matching and the broker’s internal path. You rarely control it, but you can measure it and route around the slow routes.
Colocation: why distance beats CPU
Light in fibre covers roughly 200,000 kilometres per second, which sounds fast until you remember that a round trip from a home office to a London matching engine and back is a few thousand kilometres of cable, switching and routing. Colocation means putting your server in the same facility as the liquidity you trade, so that distance shrinks to metres. In FX and metals the standard sites are LD4 and LD5 in London and Equinix facilities in New York; you can read what those facilities physically are on Equinix’s London pages.
The practical consequence is that a modest server next to the venue will beat an expensive server two hundred miles away, every time. This is why serious deployment plans start with where the box sits and only then discuss what runs on it — and why “we host on a fast VPS” is not an answer to a latency question.
Physical proximity
The metres between your server and the matching engine are the cheapest milliseconds to remove, because you remove them once.
Consistent routing
A short path is also a predictable one. Fewer hops means less variance, and variance is what turns a modelled edge into a random one.
Protocol still matters
Proximity only helps if the order travels as a message. That is the job of the FIX API, not of the hosting provider.
Measuring latency honestly
There are three numbers people confuse, and only the last one is useful.
Internal processing
How long your own code takes. Easy to measure, easy to optimise, and almost never the bottleneck people believe it is.
Ping time
Network round-trip to the venue with no order attached. Useful as a ceiling, misleading as a promise, because it excludes matching.
Tick to acknowledgement
The real number: from the moment the price is observed to the moment the broker confirms the order. Everything else is a proxy for this.
It is also worth separating the average from the tail. A path with a 20 ms median and a 400 ms ninety-ninth percentile will occasionally hand you a terrible fill at the worst moment — which, on a strategy that refuses bad fills, is a missed trade rather than a loss, and on one that accepts them is a loss.
When latency matters, and when it does not
Latency work is expensive, so it should be spent where it changes the outcome. A trend strategy holding positions for days gains nothing from a co-located box. A strategy that captures a displaced print or a momentary liquidity gap gains almost everything.
It matters
Scalping, tick-level mean reversion, displaced-print and liquidity-taking strategies, and any HFT system with a short holding period.
It matters less
Swing and position strategies, and anything whose signal is measured in hours. Here the cost model matters; the milliseconds do not.
It never fixes a bad model
Speed improves the odds that a real edge is captured. It cannot create one, and it cannot rescue a strategy whose cost floor exceeds its average move.
How XTRSK approaches latency
XTRSK treats latency as a budget rather than a claim. PULSE-X runs on FIX 4.4 with fill-or-kill orders and a controlled path from tick to acknowledgement; NIC-X looks for displaced prints and takes them immediately or not at all. Both are routed with direct market access so the venue and the server location are chosen for the strategy rather than inherited from a hosting plan.
The result is published on the live account page, and the reasoning behind which strategies are allowed to trade is set out on the quantitative trading page.
Latency questions
What counts as low latency in FX trading?
For retail-accessible systems, a tick-to-acknowledgement round trip in the tens of milliseconds is a working low-latency path. Institutional market-making operates orders of magnitude faster, but that is a different market.
Is a VPS enough for low-latency trading?
A VPS in the right data centre can be. A VPS in the wrong city is a slow connection with good uptime — the location matters more than the label.
Does colocation guarantee better fills?
No. It removes transport time and reduces variance. Whether that improves the fill still depends on the venue, the order type and the strategy.
Why does variance matter as much as speed?
Because a strategy is sized around assumptions. If the ninety-ninth percentile of your round trip is twenty times the median, the cost model has to defend a much wider range.
Can I reduce latency without moving servers?
Sometimes — a direct FIX API route instead of a bridged platform removes a whole layer, and fill-or-kill orders let you decline fills that arrive late.
Further reading
For what carrier-neutral colocation facilities physically are, see Equinix’s London data centres. For the protocol that carries the order over that distance, see the FIX Trading Community standards.
Latency describes how quickly an order is handled, not whether the trade is profitable. Leveraged FX and metals trading carries a high risk of loss.
Chat with XTRSK
Chat ready
Start a chat and the XTRSK team will be notified immediately.