Sergei Samushin, Head of Exchange Solutions, Devexperts.
Financial markets are increasingly moving to incorporate longer trading hours. Whether it be pre-and post-market availability extending the traditional trading day, or 24/5 overnight trading in stocks, futures, and ETFs, the trend is clear.
The progressive shortening of settlement cycles across jurisdictions is further evidence of this. There’s a broader recognition that today’s investors are an interconnected global community that demands markets keep pace with technological advancements.
The 24/5 nature of international FX markets, and more recently the 24/7 availability of spot crypto and crypto perpetual futures, have been bellwethers of a coming evolution in the way that securities are traded.
The question now is what changes need to be made in the systems of financial firms to enable seamless trading around the clock without increasing risks. Can existing infrastructure handle these demands, and how do firms go about updating their systems?
Duplication as a resilience strategy
Modern trading infrastructures require close to 100% uptime. This means that there’s almost no room for error in any system components. Running duplicate systems in parallel goes some way to ensuring that uptime can be preserved even when experiencing technical difficulties.By running multiple instances of all relevant applications and system components, business functions may be preserved. In this way, if one piece should run into difficulty, whether this be an application or a server, there’s another instance available to cover this function.
Of course, the running of redundant fail-safes introduces complexities relating to how consistency is maintained between these parallel systems. This is an area that has received a great deal of attention in distributed computing and there are competent consensus algorithms available to address the problem. This ensures that there’s one canonical version of the “truth” adhered to by all duplicates.
Rolling restarts for updates without shutdowns
From a technical standpoint, the requirement of increased system uptime, whether this be 24/5 or 24/7, assumes that maintenance has to be conducted on the fly, or at best within a much-reduced window.
Applications require updates as new features are introduced and in the case of major releases. Financial businesses are also constantly adding new assets, functions, order types, and risk controls. So, how are these changes to be made without causing disruptions?
It’s becoming clear that the old model of shutting down entire trading infrastructures in order to update them is no longer feasible. Financial systems should support rolling restarts where applications can be updated one at a time without disrupting normal service. This is a technical feat akin to changing the tires of a vehicle in motion, but it is possible with some thoughtful engineering.
To enable this, all new versions of existing components should be backwardly compatible with previous versions, allowing for old business functions to be maintained and new ones to come into effect as the full rolling restart draws to completion.
This can be a difficult puzzle to solve as it’s not just a technical problem but a business one, too. New functions may directly conflict with old ones, which requires additional switching capabilities between versions, allowing new functions to be brought online and for old ones to be rendered obsolete.
Separating technical requirements from business logic
An important part of the update process is the ability for business management to take place without requiring any technical operations. For example, when listing or removing symbols and asset classes, or adjusting risk controls.
These changes should be able to be conducted on the fly through an administrative application by the relevant members of staff, without requiring any technical expertise. In our experience, some exchanges struggle with this, which means that the listing of new instruments requires restarts and the changing of configuration files.
Since these types of updates are by far the most common, it’s crucial that the ability to make these changes on the fly be built into the system, so that technical staff are not required to take the helm whenever a minor change needs to be made.
100% uptime is possible
At Devexperts, one of our recent test cases involved helping a crypto exchange maintain 100% uptime for 365 consecutive days. Those familiar with the asset class will recognize how regularly updates are required in such a fast-moving and constantly evolving market.
This was achieved through a combination of the above suggestions. To be able to manage the changing demands of a fast-moving 24/7 asset class like crypto, without end users experiencing any disruptions, is a model for how other markets will be required to operate in the future.
Asset specific obstacles, opportunities, and final thoughts
Even in a situation where the above recommendations are implemented, it’s important to note that traditional markets rely on external post-trade processing services that must also be able to transition to 24-hour trading. These hurdles have to do with their own internal operating procedures, regulatory requirements, and other dependencies such as the time delay involved in cross border transactions.
When weighing in on the move from T+2 to T+1, Swift (the Society for Worldwide Interbank Financial Telecommunication), commented that the move wouldn’t just cut available post-trade processing time in half, but that banks and brokers would actually have 80% less time to conduct cross-border settlements in such a scenario.
Crypto exchanges don’t experience the same issues. Owing to the technological particularities of the asset class, they’re able to perform exchange, brokerage, clearing, and settlement in house with few outside dependencies.
The broader financial industry may, at some point, opt to utilize the DLT (distributed ledger technology) that underpins crypto assets as a way to speed up cross-border currency transactions through the use of stable coins or CBDCs (central bank digital currencies), or even to completely digitize securities in order to shorten settlement times and reduce counterparty risk.
As things currently stand, wholesale changes such as these remain theoretical, with it falling on individual firms to do everything in their power to make their own systems as resilient and future proof as possible within the current framework.
Subscribe to our newsletter
