Implementing global standards in digital exchange infrastructure

Forkast.News: How does LSEG Technology’s matching engine ensure orders are closed with as little latency as possible? How does this prevent the phenomenon of negative convexity, where the market moves away from the position staked out by the trader?

Lorne Chambers: The architecture of LSEG Technology’s matching engine is highly modular and multi-threaded, which allows for the best possible performance from the hardware it is deployed on.

Based on our multiple deployments across markets, we have not seen much of an impact related to convexity, given that our interface APIs are architected so that all investors have a “first in, first out” (FIFO) allocation based on when their order is submitted.

Some markets may also use speed bump methods to ensure fairness across different types of investors and to even the playing field. 

FN: Can you describe some of the redundancies LSEG Technology’s matching engine has in place?

LC: All critical software and hardware components are deployed with redundancies to eliminate single points of hardware/software failures, thus ensuring the availability and recoverability of the system. Recovery is seamless in most cases, with no impact on system functionality.

All application processes in LSEG Technology’s solutions have at least two instances running at any given time: a primary instance and a mirror instance. An instance is a copy of the binary running in the memory. These multiple instances allow the system to “failover” and achieve continuous availability.

The recovery mechanism is implemented at the application level without any dependency on underlying hardware-level redundancy. Therefore, the system can provide an extremely high level of reliability, even when deployed on commodity hardware.

In addition, the system also employs multiple methods of maintaining secondary backup sites based on an individual client’s needs.

FN: At a high level, what sort of customization did LSEG Technology need in order to deploy the engine to AAX? At its core, AAX is a market similar to many of LSEG Technology’s other clients, but digital assets/crypto are also quite unique. What sort of adjustments to your software stack did this require?

LC:

As the matching engine was built to cater to a multi-asset, multi-market structure, there were hardly any functional customizations required. The existing asset class build, features and configurations were deployed off-the-shelf. Our focus was primarily ensuring that the matching engine, which normally operates in daily trading cycles at traditional exchanges, could run 24/7 without the need for daily or even regular monthly maintenance windows.

As this was our first crypto deployment, we implemented an ultra-low latency API, which allowed us to integrate with AAX’s position management system to check each and every order on a cash and position basis prior to trade execution.

It was also our first cloud deployment, which only required configuration changes in the system to fine-tune the application from a technology operations point of view.

FN: How does LSEG Technology’s matching engine ensure trade transparency in the digital asset market while allowing for regulatory compliance in as far as the regulations exist?

LC:

LSEG Technology’s matching engine can be configured with various market structures, such as allowing for a fully transparent central limit order book (CLOB), continuous trading and auctions, dark pools, request for quote (RFQ) functionality, bulletin boards, and many other execution methods. The matching engine provides pre-trade checks and is also MiFID II compliant, allowing customers to adhere to the necessary regulatory requirements. 

Furthermore, the Millennium Exchange provides a variety of industry-standard APIs and messaging protocols for market supervision or regulatory authorities to actively and efficiently monitor the market, which was one of the key considerations for AAX when selecting LSEG Technology.