Reg AT Grabs Spotlight at North American BST Summit 2016

A controversial regulation was the talk of this year's event.

regulation-torn

Plenty of topics were discussed at the North American Buy-Side Technology Summit in New York last Thursday, but Regulation Automated Trading (Reg AT), and specifically its source code proposal, drew plenty of attention.

It's easy to identify the biggest concerns or interests of those in the industry with the passing of each conference. Cloud, cybersecurity, machine learning and blockchain have all been front and center as the hottest topics at WatersTechnology events over the years.

However, there is one constant theme at all events. The endless stream of regulations is always a topic that gets plenty of play. At this year's North American Buy-Side Technology Summit 2016, the substance of one rule grabbed center stage.

Reg AT

Regulation Automated Trading (Reg AT), proposed almost a year ago by the Commodity Futures Trading Commission (CFTC), has drawn the ire of many due to a request for firms' source code that the regulator plans to store in a depository.

Anthony Malakian, WatersTechnology US editor, did a great deep dive on Reg AT, specifically the source code portion of the rule. At the conclusion of his piece, which ran in the April issue of Waters, he said the industry sentiment was that the source code portion of Reg AT would likely be cut out before final approval.

So here we are, six months later, and the source code portion of Reg AT still hasn't been amended. Granted, Petal Walker, chief counsel for the office of CFTC commissioner Sharon Bowen, did say at the event that the regulator has a better understanding of how important the information is to firms. However, she also held firm to the belief that regulators need access to this type of information, and having to get a subpoena to get it is more of a short-term bandage than a long-term solution.

Meanwhile, on the other end of the spectrum, Bill Harts, CEO of high-frequency trading (HFT) advocacy group Modern Markets Initiative, said at the event that forcing regulators to get a subpoena keeps the standard high for what a regulator is going to do with the data. He said he's not opposed to handing over the information; he just wants to make sure there is a good reason for it.

Equal Points

I see both sides of the argument, which makes this such an interesting debate. On one hand, you can't blame regulators for wanting access to the algorithms. It's not good for the CFTC when something wonky happens in the markets due to a rogue algorithm, and the regulator doesn't even have the necessary information to start investigating.

But, we're not talking about basic data. A firm's source code is literally its life blood. To turn that over to the regulators sight unseen is a leap of faith. Just because it's the government doesn't mean it's any less likely to be compromised. Imagine how many bad actors would try and access a repository that includes the special sauce of so many financial firms.

I'm not trying to sit on a fence here (OK, maybe I am), but I really could see how you could make a strong case for both sides.

I wrote last week that I feel the industry's hasty reactions to things like the British pound crash aren't good. Part of this is due to the fact that it takes regulators so long to come up with reasons for these events, which could partially be blamed on a lack of data that's readily made available to them. If obtaining source code can help them do their job faster, allowing the industry to better understand these events sooner, there is something to be said for that.

Still, I'm not sure that's worth putting so many firms at risk. It might seem like hyperbole, but a firm's source code getting leaked is a death blow. Is the CFTC willing to guarantee that won't happen? And do they have people and systems in place that will be able to effectively analyze the code when something does occur? 

Both sides seem entrenched in their positions, so it will be interesting to see how this pans out over the next few months.

  • LinkedIn  
  • Save this article
  • Print this page