Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
(This piece originally appeared on TabbForum - linked here)
The furore over high frequency trading and rogue algorithms is turning these important trading tools into fodder for the mainstream media. As part of the Commodity Futures Trading Commission's Technology Advisory Committee (TAC), I had high hopes that my colleagues and I would be an instrumental part of solving some of these issues that very publically dog our markets, including mechanisms for detecting or even preventing another flashcrash, stopping algorithms going out of control and curbing rogue traders. I believe the vanguard of such market improvements is not draconian restrictions on trading algorithms but rather regulator-led best practices and market policing. If the right measures are implemented and suitably publicized, it would address the market’s nervousness and have algorithms smelling fragrant once more.
I was thus a little disheartened by the second TAC meeting last week (Technology: Achieving the Statutory Goals and Regulatory Objectives of the Dodd-Frank Act). Given the public fear that algorithms and high frequency trading are evil, I was concerned when one commissioner even went so far as to ask the question in his opening remarks as to whether algorithms should be banned completely. If this ever did happen in the US, heaven help our economy. I would equate such an action to the Luddites – a group in 19th Century Britain that broke machines to protest against the industrial revolution. Algorithms are not evil; there are many positive aspects of algorithms and HFT. They minimize the market impact of large trades, lower the cost of execution, make more open and efficient markets, allow trading venues to evolve faster, encourage entrepreneurship and increase trader productivity, among many other things. Banning what is essentially the new industrial revolution, and now an integral part of electronic trading, could take us beyond a double dip recession and back into the dark ages.
A few key points came out in the flash crash report that really need to be emphasized. A key one is that there is a difference between algorithmic execution strategies and high frequency trading strategies. The former are manually set up and are designed to break up a large trade, typically executed in a broker on behalf of a buy-side customer. The latter are much more automated and continuously look for trading opportunities to act on, typically operated by a prop shop or hedge fund. The latter sounds scarier – but it was actually the former – or one particularly extreme instance of the former - that got the lion’s share of the blame in the joint SEC-CFTC report. HFT was pretty much exonerated. It was really human error in the way the execution algo that traded the E-mini was set up that was at fault. In fact one of the TAC participants actually made the point that many of the HFT algos had smarter monitoring built in – which made them pull back from the market when it started to go haywire. Yes that withdrew liquidity – but the HFT algos behaved sensibly given the circumstances.
Commissioner Scott O’Malia asked the question whether a rogue algorithm is the same as a rogue trader. Great question! An algorithm does not “decide” to go rogue, unlike a human rogue trader who is more deliberate. Usually a rogue algo is a mistake – such as Infinium’s algo that went wrong and fired thousands of orders into the market in February (http://www.reuters.com/article/idUSTRE67O2QQ20100825) or CME’s test algo that fired phantom orders into the market in September (http://www.ft.com/cms/s/0/706c45dc-c00a-11df-9628-00144feab49a.html). But rogue algos can threaten the well-being of a marketplace just as a rogue trader can. Rather than banning or restricting HFT and algos it would be much more productive to look at how they and the market can benefit from effective controls.
Some suggestions that I made on the TAC as to how we might provide more confidence around algo trading are as follows:
Firstly, market participants should be mandated to do better back-testing and algo monitoring to help prevent rogue algorithms and scoundrel traders from entering the market. Testing the execution algo that went wrong on May 6th under realistic market conditions might have prevented it going live. More intelligent monitoring might have made it pull out of the market before it did deep damage. Real-time monitoring can detect and respond immediately to dangerous market conditions, “fat finger” or algo errors and trading risk exposures being exceeded. As illustrated by the HFT algos that stepped out of the market on May 6th – some firms have better monitoring technology than others! The CFTC and SEC could provide best practices guidance and maybe even recommend data sets, simulators and pre-production processes to help with this.
Secondly, Exchanges should continue to enhance their monitoring and surveillance systems. Clearly we’ve not perfected it yet given that a rogue algo within the CME managed to fire in phantom orders as recently as September. Also, to ensure consistent response to market crises, all trading venues in a particular asset class should have consistent circuit breakers, which operate under the same circumstances. This would avoid some of the problems discussed in the flash crash report.
And the CFTC (as well as the SEC) needs to be "mission control" to monitor across all markets and provide an early warning system. If firms believe they can be watched in real time they will be much more careful. Unfortunately, the CFTC’s Chairman suggests that there is no budget for such technology and that they will have to rely solely on controls by the exchanges and trading venues. This is unacceptable. The importance of trading to our economy means that ensuring confidence in our markets combined with allowing the world’s most advanced forms of algo trading - with the necessary safety measures to prevent meltdowns - is a matter of national security! The regulators are the US Marshalls to HFT's Wild West. The CFTC should go to Congress and make the case for a bigger budget. And they should strike while the iron is hot.
The flash crash may have been a mixed blessing, having pointed out many market structure issues that the regulators should be striving to correct or control. Until that day American stock markets were the envy of the world, the model for modern trading -- fast, stable, efficient and for the most part transparent (http://tinyurl.com/29bpr4r). That perception has changed and the rest of the world is aiming to avoid, not mimic, our model. It is critical that the US take the necessary steps to remain the shining example of capital markets. The technology is there, it simply needs to be used. Most importantly we must not allow negative publicity to lead us into Luddite-style regulation and break the machines that are fuelling this new industrial revolution.
View all posts from The Progress Guys on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.