"Our market continues to be extremely fragmented, poised for an increasing number of micro flash crashes either in one name, or multiple, and with the SEC continuing to dither and take no action..." "[E]veryone will know that just like in this isolated case, it will be the HFTs which have completely destroyed the credibility of an efficient market."
Maybe these need to be framed as a cyberattack on critical infrastructure, handled within the current cyber security framework which is getting so much attention for re-vamping.
Not that framing the problem differently would fix it, but maybe it would lead to a different mindset of urgency and necessity. Who is to say that intentional HFT attacks (which certainly falls within the cyber security umbrella) won't happen.
With the SEC taking no action, re-framing it this way would at least open the door to other regulators lighting a fire under their ass, in effect saying if you (SEC) don't act, we will, and our jurisdiction is all information technology systems, especially critical infrastructure (which I'd think this qualifies for). Also possible the SEC just isn't qualified to address/solve the issue, but they don't want to admit it, and they'd secretly welcome the intervention.
One fundamental problem I see is that on the "attack" side you have bazillions of HFT developers and their unique solutions, and on the "defend" side you have little to nothing (I'm assuming here). Compare that to, say, the regulatory requirements placed on medical device manufacturers, who must demonstrate they have done fault analysis of their systems and proprietary algorithms, and have developed protective measures, before their product is even allowed in the marketplace.
There needs to be significant effort in developing HFT-gone-wild detector algorithms, especially algorithms able to detect before the damage is done--not an easy task.
There's no motivation for HFT developers (or those funding them) to spend time "hardening" their algorithms from going wild, via "blowout preventers" ;o). That (self-designed safety measures) would be the most effective approach, since the HFT designers know what their algorithm does so are best situated to protect from going awry (as opposed to a 3rd party team of defender-developers trying to guess what every HFT algorithm does through pattern detection, and shut it down ASAP, but also not prone to false detection).
Self-develped protection requirements could protect unintentional HFT attacks, but there still need to be some anticipatory effort into detecting/preventing intentional attacks, I would think. |
