The pursuit of lower latency in electronic trading hasn’t disappeared, but the engineering decisions behind it are becoming more selective. Rather than trying to make every component of the trading stack as fast as possible, firms need to determine where microseconds genuinely affect trading outcomes, where predictable performance matters more than absolute speed, and where proprietary development creates enough differentiation to justify the investment.
Those questions shaped the panel Low latency: buying hardware and building performance at the edge at A-Team Group’s recent Buy and Build: The Future of Capital Markets Technology event in London. Conducted under the Chatham House Rule, the discussion followed the trading path from network and feed processing through software, hardware acceleration and execution, examining where firms should build, where they should buy and how performance should be measured across the stack.
Build Where the Differentiation Is
The build-versus-buy calculation starts with defining what low latency actually means for the trading strategy. Requirements can range from milliseconds to microseconds and, at the extreme end, nanoseconds, with very different technology choices and economics at each level.
When building latency-sensitive strategies, two clocks are running simultaneously: the time required to build the infrastructure and the rate at which the strategy’s alpha decays. The proprietary value may lie in the trading logic rather than the underlying feed handler, gateway or communications infrastructure, particularly where mature commercial products already incorporate years of work dealing with exchange-specific edge cases.Building nevertheless offers control. Commercial platforms inevitably contain generic layers needed to support multiple customers, while internal development can be optimised around a firm’s specific requirements. Vendor dependency, pricing and the speed at which new markets become available also enter the equation.
The cost comparison becomes distorted if it ends at initial deployment. Maintaining internally developed infrastructure requires specialist engineers, ongoing testing and support for exchange and protocol changes. Conversely, getting into production earlier using existing technology provides an opportunity to understand how a strategy behaves under actual market conditions rather than spending those months building the infrastructure beneath it.
Predictability Becomes the Performance Metric
The performance problem is also changing. An audience poll at the event identified unpredictable latency spikes and jitter within software execution paths as the biggest low-latency bottleneck, putting the focus on consistency rather than simply the lowest headline number.
That echoes a theme explored in a recent TradingTech Insight article ‘Is Speed Still the Point of a Low Latency Stack?’. Latency-sensitive infrastructure increasingly needs to deliver performance that is deterministic and repeatable under real market load, rather than merely fast under ideal conditions.
At the most latency-sensitive end, FPGA-based processing can remove much of the variability associated with software by operating at line rate without buffering. Software architectures offer greater flexibility, but their performance can be affected by the operating system, memory access and machine configuration. Large multi-CPU servers, for example, can introduce additional latency when processing crosses NUMA nodes and memory boundaries, with an even greater effect on tail latency.
The distinction becomes particularly important during volume spikes. Infrastructure has to sustain its performance when markets are busiest, not simply produce an impressive average during normal conditions.
Measuring the Whole Trading Path
That places greater emphasis on knowing where latency is being introduced. Measuring individual components in isolation provides limited information if firms cannot correlate those measurements across the complete trading flow.
Accurate timestamping requires tightly synchronised clocks, while measurement at multiple network hops can expose where queues, bursts and processing delays develop. Average latency can also conceal the events that matter most. Tail behaviour around market opens, periods of volatility and sudden volume increases provides a better indication of whether an architecture will remain stable when placed under pressure.
Previous TradingTech Insight analysis has highlighted the same need to connect infrastructure telemetry with application and business-level data, allowing firms to understand not only that latency increased but how a particular network or processing event affected an order.
The measurement boundary extends beyond infrastructure controlled by the trading firm. Exchange matching-engine response times can themselves vary, making venue latency another input into decisions that depend on precise timing.
Accelerate the Bottleneck, Not Everything
Hardware acceleration remains firmly on the investment agenda. A second audience poll identified FPGA and bare-metal acceleration, alongside greater use of managed hardware providers, among priorities for the next 12–18 months. But accelerating one component can simply move the constraint elsewhere if the downstream software cannot process the resulting flow quickly enough.
The same principle applies as machine learning moves closer to trading. Latency-sensitive inference can potentially sit close to the exchange and execution infrastructure, while computationally intensive model training remains elsewhere. Different trading strategies can similarly share a highly optimised connectivity and execution core without requiring every part of the surrounding architecture to operate at the same latency.
Physical infrastructure is adding another constraint. Higher-density servers are increasing power requirements in colocation facilities, while memory and other high-performance components face their own supply pressures. More processing at the edge therefore makes decisions about what genuinely needs to occupy scarce colocation capacity increasingly important.
Low-latency architecture is becoming as much an exercise in allocation as acceleration. Engineering talent, hardware capacity, rack power and development time are finite resources. Concentrating them on the parts of the trading path where latency affects the economics of the strategy leaves mature infrastructure to be bought where appropriate, flexible functions in software and deterministic workloads in specialised hardware.
The fastest trading stack may increasingly be the one that knows where it doesn’t need to be fast.
Subscribe to our newsletter
