By Lev Lesokhin, EVP, Strategy and Market Development, CAST
“Kill Switches” are being hailed as the solution to the algorithmic or High-Frequency Trading (HFT) problems witnessed this year at NASDAQ, BATS and Knight Capital.However, wise financial professionalswould be misguided to put all their hope into these switches – they can only be as effective as the software operating underneath them.
Circuit Breakers and ‘Kill Switches’ have been around for a while. For example, the regulators installed circuit breakers after the “Flash Crash” in 2010. Kill Switches are intended to be deployed by exchanges and are designed to halt trading when the value of the market goes down more than a set percentage within a specific period of time.
There is still a live debate whether either mechanism should be set as a ‘business rule’ or triggered by a human monitoring how firms are trading on that exchange. These measures exist because of the speed and volatility financial markets have witnessed in recent years.
Currently there is renewed focus on Kill Switches because of the slew of recent trading glitches, leading to serious problems and capital losses. These mechanisms attempt to increase the safety of the markets and reassure investors’ confidence.
But there is a flaw in the plan. Kill Switches supposedly ensure an exchange can shut its trading off instantaneously and, in many cases, even roll back some of those trades should a trading firm or market maker exhibit erratic trading behaviour. This puts pre-emptive control in the hands of the exchanges to help their clients prevent trading disasters, such as Knight Capital. But can experts at the exchanges detect unusual behaviour quickly and prevent it from causing a disaster?
These safeguards are specifically targeted at Algorithm driven, High-Frequency Trading operations.However, technical glitches in trading systems can be exacerbated by fast algorithm-based trading and quickly spin out of control killing an entire platform, freezing out a market, so both the guilty and innocent are punished. This can lead to legal cases for both losses and lost profits. Arguably, everyone loses.
The issue is that kill switches absolutely do not address the fundamental problem in the markets today – which is the technology underpinning all the exchanges and trading systems. This trading technology is being pushed very fast, in rapid iterations. All of us in software engineering know, all else being equal, the more quickly and frequently you release complex systems the more risky they are in production. As new software gets rolled out on top of the old, all sorts of unpredictable things start to happen. This is true in every software-intensive industry, but has a very high impact in trading systems.
Trading software development houses, and the exchanges themselves, all suffer from lack ofoversight over their software structure. All these organizations rely on testing to ensure quality. Testing is not enough – you can ask the COO of BATS, who actually did test their systems pretty sufficiently. Scarily, most institutional finance organisations don’t even do that.
Despite thisKill Switches are important, useful mechanisms for the market operators to have at their disposal. The recent events involving technical glitches pushed this discussion to the fore – and that’s not inherently a bad thing. It’s an advance in the markets that we have more ways to control trading flow and volatility, and to prevent irregularities.
Kill switches may help the regulators and the exchanges ensure the damage done by software glitches and errant systems is not as cataclysmic as Knight Capital became. However,Kill Switches are just a control measure built to defend against what has been occurring, and will continue to occur even more frequently. While they might pick up some glitches, limiting losses to only millions, instead of hundreds of millions, they do not address the issue at the cause. More importantly their intended aim of reinstating confidence in the markets is not going to be achieved.
The technical glitches recently roiling the markets are in the main the basic coding problems we see over and over again in many industries. With BATS, there was a single line of code that tripped up the entire exchange. With NASDAQ there was a concurrency problem that put the system into an infinite loop. With Knight, we had an issue of “dormant” code that suddenly got reactivated. These are problems we see everywhere in industry, and many industries are starting to get structural software quality under control. Institutional trading is not among the fastest to do so unfortunately and the current debate is missing the point.
At some point, the exchange operators, banking institutions and the regulators have to agree to measure and control the structural quality of their business. It’s easy to forget that the markets are completely riding on software, which is getting more and more complex, and growing more and more rapidly every day. While the industry is well adept at hiring and paying for the top of the programming industry’s bell curve, these systems are reaching a point of complexity well beyond the capabilities of these programmers. Our best super-programmers can no longer handle the structural complexity of the systems they’re grappling with and they need guidance and oversight to secure the integrity of our financial markets.