A panel at the A-Team Group’s recent ExchangeTech Summit London, titled Setting the matching engine at the heart of the exchange tech ecosystem – Next gen architecture, microservices and cloud migration strategies, positioned the matching engine as the centre of gravity in modern venue architecture. The discussion that followed steadily pulled that centre of gravity elsewhere, towards liquidity formation, ecosystem design, and the question of what an exchange operator should build at all.
Moderated by Andrew Delaney, President and Chief Content Officer at A-Team Group, the session brought together Ian Salmon, Head of Product Marketing at Adaptive; Magnus Almqvist, CEO of Exberry; Steve Grob, Founder of Vision57; Adrian Ip, Chief Strategy Officer at Aquis Exchange; and Indika Ranamuggedara, Head of Market Infrastructure Commercial Development at LSEG.
If there’s nothing on the shelves
The pivot came early. One panellist, pushing back on the panel’s own framing, argued that an exchange is fundamentally about providing liquidity rather than about matching trades. “You can have the best matching engine on planet Earth,” he put it, “but if there’s no cans on the shelves of the shop, people aren’t going to go there.” On that view, the architectural question is not how to optimise the matching engine but how to design an ecosystem that attracts price-making in the first place.A second panellist picked up the thread later in the session, dismissing the proposition that the matching engine is by definition the exchange. The matching engine and the distribution of market data, on this account, are tightly coupled components of a core; everything else – surveillance, FIX engines, connectivity – is peripheral, and increasingly subject to deliberate build-versus-buy decisions rather than being assumed in-house.
That reframing matters because it changes the question. If the matching engine is the heart, modernisation is a problem of engineering optimisation. If liquidity formation and ecosystem design are the heart, modernisation is a problem of where to draw the boundary between what an exchange operator builds and what it consumes as a service.
What stays in-house, what gets bought
On that boundary question, the panel converged on a recognisably modular answer, with one important dissent. Surveillance came up as a worked example. Best-of-breed surveillance vendors exist; market members want choice in how they access and what they buy; the case for an exchange building its own surveillance from scratch is weak. The same logic, several panellists argued, increasingly applies to other components in the wider stack.
The architectural vehicle for that modularity is microservices. The case made by panellists for microservices-based design ran along familiar lines: flexibility, scalability, the ability to start small and grow, fitness for cloud deployment. One speaker pointed to a hardware refresh cycle now costing three to four times what had originally been planned, and presented microservices architectures as a more flexible response than traditional monolithic designs.The dissent came from a panellist who pressed on whether microservices, taken too far, introduce fragility into a system that ultimately needs to be deterministic. It is a real question. Exchanges sell determinism. The reply was that modern architectures can be engineered to deliver it – with the important rider that the metric exchanges should be focused on is not headline latency but consistency. “Latency is almost irrelevant,” as one panellist put it. What matters is jitter and predictable execution: whether participants entering a liquidity pool can know with confidence where they land in the queue, rather than racing to cross the next threshold. Another panellist made the same point from a market infrastructure perspective, arguing that low jitter and predictable distribution in a liquidity pool is the KPI worth defending, with peak throughput a variable that shapes the design rather than a target in itself.
From building tech to buying capability
If the matching engine is no longer the architectural centre, and if the components around it are increasingly bought rather than built, the logical extension is for the matching engine itself to become something an exchange consumes as a service rather than operates. Several panellists made versions of this argument.
The case rests on workforce specialisation as much as on technology. An exchange operator’s job, on this view, is to run a liquid, fair, transparent market and to launch new products. Investing senior management resource in recruiting, supporting and retaining the technology staff who run and operate the matching infrastructure is, increasingly, a misallocation of attention. Better to buy mission-critical technology as a service from specialists whose entire business is running that infrastructure.
The concrete anchor for this argument sits in plain sight. SIX announced in October 2025 that Aquis Technologies had been selected to provide a harmonised trading platform – the Aquis Equinox matching engine – across SIX Swiss Exchange, BME Exchange and Aquis itself, replacing the existing technology stacks operating in Switzerland and Spain.
This is the same logic that has driven the consolidation of equities, fixed income and listed derivatives platforms at exchange groups around the world. What the panel surfaced is that the same logic is now being applied one layer deeper, to the matching engine itself.
A stress test: 24/7
A substantial portion of the discussion turned on 24/7 trading, and what emerged followed directly from the build-versus-buy and architectural-optionality threads.
The panel’s consensus on the engineering was straightforward. The matching engines can run continuously; the regulated environments are already over-specified for resilience; clients exist who operate 24/7 platforms today. What is not solved – and what the discussion kept returning to – is everything else.
Brokers and market makers are not built to operate continuously. In existing 24/7 implementations, participants typically disconnect once a day to run end-of-day processes and reconnect when ready. Operations teams, surveillance functions and infrastructure support are fixed costs that scale with hours of coverage rather than with volume. The close itself performs structural functions in equity markets – TCA, best-execution algorithms, end-of-day reference pricing – that do not have obvious replacements in a continuously open market.
The audience pushed back on demand. One audience member referenced a recent industry poll in which 78% of respondents were not in favour of 24/7 markets, asking who was actually driving the requirement. A panellist replied that retail demand has, in practice, already been absorbed by intermediaries: brokers and ATSs that offer 24/7 access to underlying markets through their own user interfaces, without requiring the underlying exchange to operate continuously. On that reading, the architectural question is not whether exchanges should solve for 24/7 trading, but whether they need to.
What emerged was a clear statement of where the panel landed: none of the exchanges any of the panellists were in contact with actually wanted to run 24/7 today. But all of them wanted the capability to do so in the future. That distinction – between current operation and architectural optionality – is itself a statement about how exchange technology is now being procured. Buyers are no longer buying a matching engine for today’s market. They are buying optionality on tomorrow’s.
Cloud: a spectrum, not a destination
The cloud discussion, compressed into the final minutes of the panel, made a related point. The headline narrative on cloud migration has matured to the point that it now needs unpacking rather than restating.
The reference example offered was the CME–Google Cloud partnership, signed in 2021 with a $1bn equity investment from Google. The substantive observation made on the panel was not that CME had moved its exchange to the cloud, but that Google had had to move its cloud to CME’s exchange – building cloud and colocation facilities adjacent to CME’s Aurora, Illinois data centre. The matching engine moves to the cloud only in the sense that the cloud comes to the matching engine.
As one panellist put it, “cloud” covers everything from a credit-card-funded blog account to bespoke racks of specialist hardware in a dedicated data centre. Different segments of an exchange operator’s stack will sit at different points on that spectrum.
The panel’s consensus on where the boundary currently runs was reasonably clear. Regulated cash-equities markets – where latency is measured in microseconds and physical proximity to participants is the determining factor – continue to require on-premises infrastructure in shared colocation venues. Startup markets, retail-facing venues and prediction-market infrastructure are generally cloud-native. National exchanges with data sovereignty obligations, and incumbent participants paying for colocation, are not. Regulators have softened their stance on permitting mission-critical systems in public clouds; exchanges have softened their initial resistance to relying on them. The boundary has shifted in the last three years. It has not dissolved.
What is an exchange, when it is not its matching engine?
The panel was framed around the matching engine as the heart of the exchange. What it described, taken together, is something more nuanced: a matching engine that is increasingly commoditised, a surrounding stack that is increasingly modular and increasingly bought rather than built, a 24/7 question that is really a question about where in the architecture the fixed costs sit, and a cloud boundary that has shifted but not disappeared.
The competitive implications are worth dwelling on. If matching is a service, surveillance is a vendor decision, and post-trade and clearing are handed off to external CCPs and CSDs, what is left of the exchange? On the evidence of this discussion, two things: the liquidity it formats and the market structure it designs. That is a narrower definition of an exchange than the traditional one, and a more demanding one. It places competitive weight on capabilities – ecosystem design, member acquisition, product innovation, market quality – that do not benefit from the procurement logic now reshaping the technology stack underneath them.
So perhaps the most consequential architectural decision an exchange operator now makes is not how to build its matching engine, but what it chooses not to build at all?
Subscribe to our newsletter
