Faster hardware, co-location and better network routes are easy to buy and hard to justify. A latency budget shows where the time actually goes, separates the delays that matter from the ones that just look impressive, and turns "we need to be faster" into a decision you can defend.
What a latency budget is
A latency budget is an itemised account of the time between a market event and your order reaching the venue, and back. It breaks the path into hops and gives each one a measured value and a target:
- Market-data arrival and feed handling
- Normalisation and book building
- Strategy decision
- Pre-trade risk checks
- Order gateway or FIX engine
- Network to the venue, and the venue's own gateway
- Acknowledgement and fill back to your systems
The point is not the total. It is knowing which hop dominates, and how much it varies.
Measure before you optimise
You cannot attribute latency across machines without trustworthy clocks. In the EU, RTS 25 requires members using high-frequency algorithmic trading techniques to stay within 100 microseconds of UTC, with timestamps at 1 microsecond granularity or better. It also requires firms to demonstrate traceability to UTC and to review it at least once a year, as the National Physical Laboratory's guide sets out. The same discipline makes latency measurement credible.
Practical rules:
- Timestamp at consistent points on every hop, ideally with network capture as well as application logs.
- Look at the distribution, not the average. Median, high percentiles and the worst cases tell different stories. The tail is usually where money is lost.
- Measure in the conditions that matter: the market open, data bursts and news events, not quiet periods.
Build the budget
- Start from the strategy. How quickly does the opportunity decay? A strategy that holds positions for minutes has a very different budget from one that competes at the top of the queue.
- Allocate a target to each hop, based on what the measurements show is achievable.
- Keep the controls in the budget. Pre-trade checks are not optional. RTS 6 expects price collars, maximum order values and volumes, and message limits before orders reach the venue. Design them to be fast, not absent.
- Price each improvement against the hop it fixes. Co-location, kernel bypass, FPGA feed handling or a new route: buy only where the budget shows the delay, and estimate the commercial benefit before you commit.
- Re-measure after every change, under load, and keep the budget as a living document.
Common traps
- Optimising the average while the tail gets worse.
- Relying on vendor benchmarks measured in ideal conditions.
- Logging or persistence on the critical path.
- Clock drift that makes one hop look faster than it is.
- Generating test orders in production just to measure latency. Do not create artificial trading activity for measurement; agree safe alternatives with your broker or venue.
Where QTC helps
Our Technical Expertise pillar can build the measurement, run the analysis and design the infrastructure changes, or independently review a vendor's proposal against your budget. Read more about our low-latency infrastructure and co-location work.
This article is general information, not legal, regulatory or investment advice. Regulatory, compliance and tax matters should be confirmed with qualified advisers; QTC coordinates these workstreams with specialist partners.