PDF Version: Download
by Feroz Cader, VP, Head of Trading Systems, MillenniumIT, LSEG Technology
The matching engine is the core of any trading venue. In its simplest form, it facilitates the electronic matching of orders from buyers and sellers, in a fair and orderly manner, within a regulated framework. This simple function however, sits at the centre of an increasingly complex and competitive global financial system. It brings about many interesting challenges; whether you are setting up a brand new exchange in an extremely competitive developed market, upgrading the legacy systems of an existing exchange in a developed market, or introducing electronic trading for the first time in a frontier market. Building the matching engine requires skill as much as it requires experience and
capacity to deliver. It is a highly specialised niche requiring significant engineering expertise in software design, operability, latency management and connectivity, combined with a deep understanding of trading across multiple asset classes and risk management capabilities.
Availability and quality at source
The matching engine is mission-critical software that global financial markets depend on to provide participants with the confidence to execute their strategies. It must remain glitch-free and provide as close to 100% uptime as possible in a competitive environment while at the same time being flexible enough to respond to regulatory change in near real-time. Managing that change is much akin to replacing the wheels of a moving truck while keeping the truck on the road.
The ability to deliver such quality and availability starts at software design. Quality-at-source and fault-tolerant architecture are critically important to keep the cost-of-ownership low and to minimise opportunity costs from a time-to-market perspective.
Even a defect-free system is prone to operator error. A typical reactive solution is automation. However, there is no such thing as 100% automation and the operations cycle is not limited to the start and end of trading. It begins at the point of release deployment into production. Operability should be a key architectural building block and not an afterthought. A single permissions-controlled dashboard that provides a view and control into the system for reference data, client connectivity, matching and market-data across multiple markets and asset classes should be a standard operability feature along with automated release deployment and rollback capability.
Multi asset and multi-micro market
A matching engine should be capable of trading multiple asset classes in different market structures on the same platform. This design feature allows for harmonisation across platforms and other systems from pre- to post-trade. Even if a trading venue operates multiple segregated instances for different asset classes, a matching engine's capability should allow a common code path to be deployed across these systems. This can significantly reduce maintenance costs compared to maintaining separate systems for multiple asset classes.
This is equally true for frontier or emerging market exchanges where running separate matching engines across multiple asset classes has proven to be prohibitively expensive, especially when such markets are in the early stages of launching asset classes beyond cash equities, and as such, trade very low volumes.
"A matching engine should be capable of trading multiple asset classes on the same platform."
Increasingly, new regulations are demanding greater transparency for asset classes that are traded over the counter (e.g. FX, IRS etc.). Having the capability to on-board new asset classes with different trading models (micro-structures) on the same system will bring cost savings to the organisations leveraging this opportunity.
The arms race to be the fastest may arguably be over. It is no longer a significant differentiator given that most systems are capable of microsecond levels of latency. However, to a tier-1 market, consistency in latency is an important factor and in most cases still a challenge due to latency peaks or outliers. Reducing outliers will limit the uncertainty faced by trading algorithms and in turn minimise the risk of algorithms misbehaving. Improving latency can help trading venues do more with less in terms of the hardware footprint and risk management, even if single digit microsecond level latency is not important.
A key aim of emerging and frontier capital markets is increasing liquidity, but barriers to entry for global investors tend to be high. It is important during a market's evolution, to ensure technology facilitates rather than prevents increased investment inflows. Industry standard connectivity both at order entry and market data level is critical to ensuring the matching engine allows low cost and easy access to the trading venue when hurdles to foreign ownership are relaxed.
The fight for liquidity is not limited to emerging and frontier markets. In mature markets, very few trading venues operate in a single market environment. Price formation is decentralised and as such, market participants need the ability to connect to multiple exchanges to provide best execution. They can do that by maintaining individual connections to each trading venue but this can prove costly given the rate of change in each market. Trading venues should instead look to provide a single standard interface and shield its participants from the need to maintain multiple order and market data interfaces. To do this, the gateway framework of a matching engine needs to be multi-venue capable while maintaining consistent microsecond-level latency without compromising functionality of any connecting venue. Further, the ability to normalise connectivity across venues will be a differentiator with developed as well as emerging markets given an increasing trend to create regional cross-border trading partnerships between venues.
A matching engine's ability to provide risk management should be a key consideration in the current environment of risk regulation being imposed on trading venues. There are two types of risks that can be managed by matching engine software, namely price/size errors (also known as fat finger errors) and exposure-related risks.
A price- or size-based error could negatively impact a fair and orderly market. A trade with an erroneous price or size could cause market-wide panic and adversely affect trading algorithms and valuations. At a minimum, matching engines should be able to manage this risk through price bands and order size checks.
"A trade with an erroneous price or size could cause market-wide panic and adversely affect trading algorithms and valuations."
Exposure risk is the risk of a default. Regulation and the complexity of unwinding a trade, post-execution, is shifting the need to perform risk management upfront, while latency improvements are making this possible. A matching engine should have the ability to be 'participant risk aware' by integrating with a risk management system to maintain real-time risk thresholds per participant without compromising on its matching performance.
Experience is key
Competition among exchanges for market share and new regulations are driving change at trading venues at exceptional speed. Deploying a matching engine is labour intensive. It is vital that a matching engine provider has both scale and a proven product, along with experience and process efficiency to support a trading venue's evolving requirements. As more venues turn to specialist providers they can benefit from sharing the cost of development across multiple organisations at a fraction of the cost, while accessing innovative ideas from multiple sources and simplifying member connectivity by leveraging standard protocols.