
As US equities and other markets move toward continuous, around-the-clock trading, firms face a set of infrastructure questions the traditional trading day never forced them to answer.
A panel at A-Team Group’s recent TradingTech Summit New York was convened to work through them: how to build a resilient foundation without adding operational risk; how to harden security and upgrade software with no out-of-hours window; how price discovery and risk change when there is no definitive close; how firms fund a continuous model; and how automation keeps pace with the build-out. Underneath each sits the same shift: continuous trading removes the overnight maintenance window and the end-of-day close, and a great deal of existing infrastructure was built to depend on both.On timing, an audience poll asked when continuous trading becomes a practical reality for US equities. The most likely timeframe was identified as within the next 12 months, on the grounds that the competition is already running – not only among primary venues but among secondary ones racing to offer 24×7 liquidity. The industry has discussed this for the better part of a decade as a distant prospect, one panellist noted, but for the US market it is now around the corner.
Keep the system running, because you can no longer turn it off
Today, an upgrade means a restart. The venue takes the system down out of hours, changes the software and configuration, clears out the old data, and brings it back up. Remove that window and each of those acts has to happen live, which raises a number of challenges.
Three came up as the hardest. The first is reference data. Adding new instruments or users to a running system is manageable; changing existing ones mid-session is harder, and a continuous market has to support it. The second is software upgrades. With no window to take everything down at once, the system is upgraded one process at a time, in a set order – and the order matters, because if a new release changes the format of the messages passing between processes, upgrading them out of sequence breaks the conversation between them. The third is housekeeping. A system that never restarts keeps writing logs and message stores, and without a restart to clear them it eventually fills its disk. The approach described was to close each log and store at regular intervals, perhaps hourly, and start a fresh one, leaving background scripts to clear away the files no longer in use.
None of this is new, the panel said. What has changed is that work which used to happen safely out of hours now has to happen on a live market.
Zero downtime is an availability problem before it is a maintenance one
Losing the window also changes what resilience has to mean. With trading running everywhere at once, an outage anywhere affects everything – there is no quiet region and no end-of-day handover to absorb it. Service has to hold up in every location regardless of where the load lands, which is a staffing and operational problem as much as a technical one, and a regulatory one on top.
The architecture described to meet this retires the old setup of one production environment and one disaster-recovery backup. In its place run several production environments and several DR environments in parallel. That costs more, mainly in the capacity itself, and it changes how a system handles client connections. If any client can be routed to any instance, no instance can hold a client’s session on its own; the system has to be loosely coupled enough that a client can land on any instance and still have its activity reconciled. One panellist looked ahead to detecting trouble early, failing over automatically, and rerouting flow between instances at the client’s discretion rather than the venue’s.
Real-time risk, and synthetic benchmarks for a market with no close
A large share of daily volume has always executed into the close. So what happens to that liquidity when there is no close? The panel treated this as a question about market structure, not technology, and the view was that the change is already happening, pushed along by emerging markets and by clients trading at every hour. The old shape does not disappear entirely – a spike around the former open and close is still expected. But firms can no longer count on an end of day, an auction, or a single moment of settlement, and the work those moments used to do moves into real time: risk, reconciliation, and the rebalancing that once waited for an auction now triggered through the day. One panellist tied this to the shortening settlement cycle, from T+3 toward T+1 and, for some asset classes, toward same-day, and expected it to be regulated in time, with venues competing on their ability to keep up.
Two consequences follow. Risk stops being a calculation run at the end of the day and becomes a position updated with every trade, which makes pre-trade checks the main line of defence, since there is no end-of-day reckoning left to catch a problem afterwards. And firms that once used the close to mark and price their books will need a substitute: the panel expected a rise in synthetic benchmarks built to price a market that no longer prints a closing level. Throughout, a client in APAC, London or New York has to be treated the same way, and delivering that consistency everywhere, all the time, was described as the real point of difference between firms.
FPGAs, and the latency cost of always-on risk
Asked whether continuous trading is pushing firms toward FPGA-based architectures for sub-microsecond speed, the panel said yes, for two reasons. One is physical: data-centre space, power and hardware are all in short supply, and FPGAs use that space efficiently. The other follows from the loss of end-of-day. Moving risk into the live flow means putting a risk check directly in front of every order, and that check adds latency – the kind of overhead FPGAs are well suited to absorbing. One panellist also made the point that they are harder to attack than a conventional software stack, which makes the speed a security feature as well as a performance one.
Not every firm can afford to be in this market
Continuous trading is going to be expensive, the panel said, and not every firm can afford to run several parallel trading platforms and build in the resilience it demands. Some will pay for it. Others will hand their flow to a provider who already has. That points to consolidation – a smaller number of firms able to operate at the necessary scale, and a long tail of smaller ones for whom outsourcing execution is simply the sensible choice.
The panel split on what that hand-off looks like. One view is that it is already here: white-labelled products, flow sold on to be executed elsewhere, the biggest players running as technology firms with the engineering headcount to match. The other was warier of selling a fully managed, end-to-end platform to large institutions, which face a long approval cycle to take one on and may end up competing with it internally. On that reading, the more durable offer is a framework or self-hosted platform a bank can build on, with the provider acting as a resource rather than a finished product. Both accept the consolidation; they disagree on whether what sells is a service or a foundation to build on. The wider technology sector points the same way, the panel suggested, with the hyperscalers as the model for operating at scale – the standardisation and automation they have run for years still something capital markets is catching up on.
A closing audience question asked whether shared standards – common identifiers and symbologies across venues – could make continuous trading more consistent across jurisdictions. The panel’s answer was that regulators are already moving in that direction, on the understanding that a market that wants to compete has to stay broadly compatible with the rules around it. The maintenance window and the close worked because the trading day had edges. A market without edges has to agree all over again on when things settle, how risk is measured and where the line of fair treatment runs – and on the panel’s account, that rebuilding is already under way, ahead of the rules that will eventually require it.
Subscribe to our newsletter


