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
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build, protect and deploy apps across any platform and mobile device
Automate decision processes with a no-code business rules engine
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
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
There have been some heated public debates recently about the kind of liquidity that is being provided by high frequency trading. In an earlier post on Tabb Forum Candyce Edelen from Propel Growth asks if HFTs provide liquidity or do they just provide volume?
Liquidity is bread and butter for firms associated with financial markets; it provides an easy way to get in and out of markets while - hopefully - making money. It is essential to investors who want to know that they can get in or out of a market when they choose. Therefore liquidity is good. (The icing on the cake would be over the counter derivatives markets where firms can use opacity to their profitable advantage.)
Liquidity, from the word liquid, depicts a flow of activity that is smooth and constant. Investopedia says that liquidity is characterized by a high level of trading activity.
It is clear is that HFT provides that high level of trading activity. What is less clear is: is it really liquidity? High quote-to-cancel rates, with pre-programmed cancellations sometimes happening in 2 to 5 milliseconds, lead to perceived rather than actual volume. Liquidity only occurs when buyer and seller can get together and deal. If a sell quote disappears before the buyer is even aware of it, what advantage does that offer the buyer?
I applaud Edelen for asking outright whether HFTs increase liquidity or just volume. The “just volume” replies were no surprise, but some thoughtful counter-arguments appeared in the comments to support the liquidity argument as well. Interesting, but no consensus. So how we expect regulators to figure it out is anybody’s guess.
There is also a lack of clarity as to whether HFTs should be market makers, thereby ensuring liquidity even in volatile markets. Edelen asks if we need new obligations for the new breed of market makers. The May 6th flash crash demonstrated what happens when uncertainty and extreme price movements occurred - the market makers fled. Computerized trading algorithms quit the marketplace even when their owners were designated as market makers, thus steepening the fall. But, since traditional market makers have all but disappeared, HFT market makers are what we have left. If you take them away, what remains?
In the flurry of comments to Edelen's article, it seems that on this at least the pundits seem stumped. They remarked on what the obligations and incentives are or are not, but could not seem to find an answer to what they should be. Instead they go away from market makers to seemingly trying to redefine what the market itself ought to be instead – with little success. This may give us a clue as to why regulators and legislators can’t figure it out either.
And do we need a level playing field as some are calling for? If everyone gets the same data at the same time and can only trade at the same speed, will that solve the problems? Intuitively people seem to feel the answer is “yes” but the commentators could not even agree what the playing field or fields would look like. Most seemed to shy away from trying to put the genie back in the bottle and going back to the way things were. Dark pools are another sore subject, with some claiming that the growing level of volume traded in dark pools (possibly 30% of volume) is due to the fear that HFTs are creating in the lit markets.
High frequency trading is here to stay, and debate over its role and future is healthy. But are all HFTs the same, asks Edelen? Here finally we seem to have some consensus from the pundits, who appear to have argued themselves into this position: There is Good HFT and there is Bad HFT. We can’t define it, but we think we know it when we see it. This is the same as with any tool or technology or trading model – there are beneficial and irresponsible or harmful uses; the line between them is blurry, and the distinction springs from the user of the tool, not the tool itself.
So what are we to do with the “Bad HFT?” This seems to be the real question. So far we’ve heard:
What we are left with is the capitalist mantra of “buyer beware.” But there are ways that the buyer can equip himself to join the 21st Century and - at the same time - protect himself from high frequency errors, fraud or predators.
As we’ve often said, high speed trading needs high speed controls. Like a car racing down the highway, some controls will come from the lurking cop (the regulator). But the driver needs to make sure the brakes work as well as the gas pedal in order to avoid an accident. Of course, the speed itself begs the question of whether HFT needs to have a speed limit in order to stay under control. We don't think a speed limit is necessary.
Instead, the issue is detecting abuse and mistakes, regardless of speed or source. If you have the market surveillance and monitoring tools that can alert you to problems occurring at high speed - if you can monitor your own car, and the cars on the road around you and see a problem coming - an accident can be avoided. And if there is no accident, despite how fast the car is going, then the cops won't have to be called out.
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 © 2017 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.