The financial technology industry has developed something of a fetish for latency figures.

Microsecond benchmarks dominate vendor conversations, procurement scorecards and conference presentations. They are clean, quotable and easy to compare. They are also, in isolation, a poor proxy for what actually determines the quality of a trading environment.

The metric that matters, and the one that is far harder to engineer, is jitter.

A matching engine that processes transactions in ten microseconds on average sounds impressive. But averages are statistical conveniences, not operational realities. A system with a mean of ten microseconds and a long tail that occasionally stretches to two hundred microseconds is a fundamentally different proposition from one that delivers ten microseconds with a maximum of eleven microseconds.

For market participants building systematic strategies, it is the distribution that governs execution quality, not the headline. Execution algorithms are designed around assumptions about how infrastructure will behave. When those assumptions break down, when latency spikes unpredictably under load, the consequences ripple through fill rates, spread capture and risk exposure in ways that are difficult to model and harder to recover from.

Jitter is not an academic concern. It is where latency promises meet operational reality.

Jitter quantifies variation in processing time across a population of transactions. It tells you how deterministic a system is. It shows how confidently you can predict how the infrastructure will behave at any given moment.

Low jitter means that performance under normal conditions and performance under stress are recognisably similar. High jitter means the system has hidden dependencies, on workload levels, memory state, operating system scheduling, hardware contention, that surface unpredictably as conditions change.

For a matching engine, this matters in a specific and consequential way. The engine is not a batch processor. It handles incoming order flow in real time, applies complex market rules, and must produce deterministic outcomes across tens and even hundreds of thousands of transactions per second. The moment that processing time becomes variable, when the ninety-ninth percentile diverges sharply from the fiftieth, the trading environment becomes unpredictable in ways that no amount of average-latency improvement can compensate for.

It’s important to remember that not all latency and jitter measurements are equal. While Aquis measures the entire software stack, many others quote a latency or jitter number which looks only at one part of the critical hot path for an order, usually the sequencer or matcher itself. However this ignores the fact that the sequencer, while critically important, also relies on other components such as an order gateway, market data out application, pre-trade risk components and other things which can significantly change the overall latency profile of an exchange matching engine system. Keep that in mind if you see numbers that look unbelievable.

Jitter cannot be solved by optimising a single component. Amdahl’s Law highlights that overall system performance is constrained by the parts of the system that remain unoptimised. The same principle applies to jitter. Variability in any part of the technology stack can affect overall determinism. It is a systemic characteristic that emerges from the interaction of hardware, operating system, memory management, software architecture and processing logic. Addressing it requires understanding the full stack and making correct decisions at every layer.

That means thinking carefully about memory allocation patterns that introduce garbage collection pauses for systems written in for example Java. About CPU affinity and the way operating system scheduling decisions can introduce microsecond-level variation. About how lock contention under high concurrency creates tail latency that average figures will never capture. About the way network connected applications change behaviour as throughput approaches capacity.

These are hard problems. They do not yield to isolated optimisation. Solving the twin problems of latency and jitter requires architectural discipline applied consistently across the entire platform.

A matching engine's most important performance characteristic is not how it behaves at typical load. It is how it behaves when the market moves.

Volatility events, news releases and end-of-day auctions create exactly the conditions under which jitter tends to manifest. Order flow compresses. Message rates spike. The system approaches capacity. These are the moments when the gap between a well-engineered platform and one optimised for benchmarks becomes visible.

The question is not whether a platform can achieve impressive latency under laboratory-style controlled conditions. The question is whether it can maintain consistent, predictable performance when huge numbers of orders arrive within a very short window — and whether the tail of its latency distribution remains acceptable when the market demands most from it.

This is why performance assessment should extend well beyond median and average figures. The ninety-fifth percentile matters. The ninety-ninth percentile matters more. Worst-case behaviour under sustained peak load is the truest indicator of engineering capability.

Technology performance is often reduced to a handful of headline figures: latency, throughput and capacity. These metrics are important, but they should not be considered in isolation.

Market structure is evolving in ways that will amplify the importance of low-jitter infrastructure.

Extended trading hours, the continued growth of algorithmic participation, and the emerging conversation around continuous and 24/7 trading all point toward environments in which infrastructure will be expected to deliver consistent performance across a wider range of conditions and for longer periods of time.

In this context, the ability to maintain a tight latency distribution, not just at launch or under favourable conditions, but sustainably, across varying market regimes, becomes a core infrastructure requirement rather than a differentiator.

Aquis Equinox has been designed with jitter as a first-order engineering concern, not a metric to be optimised after the fact.

The architecture reflects a deliberate set of choices, about how the engine handles memory, manages concurrency and processes order flow that are oriented toward determinism under pressure. The objective is not peak performance in isolation, but consistent performance across the distribution: a system that behaves predictably when it matters most.

Because the measure of market infrastructure is not what it achieves when conditions are easy. It is what it maintains when they are not.