The recent Aquis Exchange PLC, SGX and Amazon Web Services (AWS) project to launch a cloud-based exchange is a great milestone, writes Chris Lees, founder of FixSpec. But could it be a stepping stone, he asks, to a much bigger shift in the way that exchange matching engines are developed and deployed?
An interesting article popped up on my LinkedIn feed recently which described a project by Aquis Exchange, SGX and Amazon AWS to deploy an exchange in the cloud. In case you missed it, here’s the link: Amazon Lifts Stock Exchanges into the Cloud.
It’s a promising milestone and I congratulate the participants on the achievement of course, but I couldn’t help but feel a sense of inevitability about it.
Of course exchanges of the future will be deployed on the cloud infrastructure. Of course, the financial benefits to doing so are compelling (the article suggests a 90% reduction).
There are lots of regulatory and security considerations to iron out of course, but there is nothing unique or special about an exchange matching engine that fundamentally blocks their operators from following the exact same strategy that they are taking with vast swathes of other technology. Migrating to the cloud has the potential to not only unlock significant cost savings but also offers an important opportunity to re-evaluate or improve legacy technology as part of a migration strategy.
As I say… this step was almost inevitable.
And it reminded me of an idea that I floated to a prior employer before I set up FixSpec; the idea of micro-exchanges or “order-book on demand” services.
The core idea is that there is clear demand from firms which are not “traditional” exchanges to offer exchange-like services; think of the alphabet soup of exchange-like trading firms out there — ATS, OTF, SI, MTF, MM… Business models such as these require large (five or six-figure) up-front investments in matching and surveillance technology, reams of regulatory filings and possibly dedicated staff. And it all has to be completed before you match your first trade, making it a risky proposition for lots of firms, especially those which might wish to offer trading in a niche or specialist range of instruments.
The idea that I floated was of a drastically smaller, atomic matching engine responsible for only a single instrument, combined with the ability to spin up and take down matching engines quickly, and a pricing structure to match. Such an approach would allow potential marketplace operators to ‘test the water’ before committing to large investments or allow time-limited marketplaces to be rapidly spun up for specific events.
Modern technology permits all of this already of course. The idea of encapsulating a matching engine logic inside a container and dynamically cloning/adding containers to an orchestrating Kubernetes cluster (for example) is not science fiction, but instead common practise. All of the technology to build a cloud, micro-service-based exchange probably exists today, and I consider it almost inevitable that it will be delivered at some point.
There are two secondary implications on the wider trading ecosystem here, however, which centre on the challenge of rapidly connecting customers to future cloud-based exchanges.
1. For decades, financial services firms have remained stubbornly wedded to expensive telecom lines — point-to-point or datacenter cross-connects — which feel inappropriate for a cloud-based matching engine, where internet-based (and free) alternatives such as stunnel and VPNs are freely-available. This may require not only re-training internal networking teams who are often not very well-practised in internet connectivity but also changes to a bank’s security policy which often strongly discourage internet-based connections; something that they may already be under review as a result of extensive home-working arrangements.
2. There will be a need for faster customer onboarding and conformance (and/or more robust APIs) into these cloud exchanges; customers should be able to connect in hours and not weeks or months. This will require a change to the way that exchanges publish APIs and developers write to them, as well as an overhaul and extensive automation of the client connectivity processes.
So congratulations to the Aquis, SGX and Amazon AWS teams on taking this first step towards a cloud exchange. I look forward to watching the journey with interest!
• • •