The CFTC (Still) Wants Your Intellectual Property
George E.P. Box, the internationally renowned mathematician and statistician, once said, “Essentially, all models are wrong, but some are useful.”1 So where mathematical models replace human thought and judgment, as they are doing on an ever larger scale in today’s financial markets with the advent of electronic trading and digital technologies, it is inevitable that market disruptions will follow on. Automated trading presents a number of challenges, especially for market regulators, who must ensure a level playing field and durable markets, while at the same time take care not to stifle innovation.
While we at Crow & Cushing are only lawyers, not mathematicians or traders, something strikes us as unwise about one aspect of the effort by the United States Commodities Futures Trading Commission (“CFTC”) to regulate automated trading, known as Regulation Automated Trading, or Regulation AT, a proposal almost 500 pages long, first published in December 2015.2 The regulatory history of this provision of Regulation AT bears telling.
The Initial Proposal
Under Rule 1.81 of Regulation AT, as originally proposed by the CFTC, those engaged in algorithmic trading would have been required to maintain their source code in a repository (a structure that stores the code) and make it available to the CFTC and the Department of Justice without a subpoena. Rule 1.81 would also have required that algorithmic traders maintain the source code repository to manage source code, and provide access to copies of all code and any changes to the code. The regulation would have permitted monitoring by the CFTC in real time and required automated alerts when the trading system approached boundaries within which it was designed to operate or upon loss of network connectivity, among other monitoring requirements.
The CFTC viewed the provision as simply a matter of recordkeeping, although it acknowledged the unique characteristics of source code. Perhaps the most articulate and sustained defense of the CFTC proposal came from Better Markets, a not-for-profit dedicated to market reform founded in the wake of the 2008 financial crisis. Better Markets believes that access to source code is a key to detecting and rooting out many types of manipulative and predatory behavior which are otherwise unidentifiable through the use of conventional market data. Source code, Better Markets asserts, needs to be available in real time, not in the aftermath of potentially devastating events.
While not challenging the legality of the CFTC’s original proposal, most critics, and there were many, described source code, accurately we think, as a firm’s intellectual property which contains its confidential current and future trading strategies. Source code reveals not positions held in the past, which can be gleaned from other records already available to regulators, but what a trader intends to buy and sell and the basis for those decisions.
Given today’s level of competition, market participants view source code as the key to their success. They typically employ numerous safeguards to protect against disclosure of their code, including restricting certain classes of their own employees from viewing it. The critics objected strongly to a requirement that they provide unfettered access to regulators in real time and questioned whether the CFTC needed, or was even equipped, to monitor ongoing trading, especially in cases where there is no reason to believe there is an intent to disrupt markets.
A New Proposal Emerges
In the face of widespread industry criticism, and the vehement objections of one of its own Commissioners, the CFTC has now largely scrapped proposed Rule 1.81 and replaced it with Rule 1.84.3 The new proposal would require that covered traders maintain for a period of five years source code they use, material changes to the code and logs recording the activities of their algorithmic trading systems.
In its revised proposal, the CFTC pulled back from the requirement that traders provide real time unfettered access to the code to CFTC staff. In place of those provisions, the CFTC, in Rule 1.84, now proposes that traders covered by the rule make available the documents listed in the rule, including source code, to the CFTC upon a “special call” by the CFTC itself. In other words, the CFTC has added a layer of protection by inserting itself into the process and not leaving the judgment as to whether source code must be produced solely to staff.
Not surprisingly, the new proposal has done little to quell the anxiety of the critics of the original rule. They remain concerned as to how the CFTC will implement its source code review and what will happen to the code once the CFTC completes that review. In their view, the CFTC still fails to offer a valid reason why a subpoena does not provide sufficient access.
A Balance of Interests is Needed
There is to our knowledge no other federal regulation in existence which provides the government with access to the business plan of an enterprise without a subpoena. The SEC, for one, does not require that registrants provide access to their source code.
A balancing of these interests is in order. It seems to us that a less intrusive rule which simply requires that traders preserve all versions of source code and track material changes would not compromise a firm’s intellectual property, but still enhance regulatory oversight. The CFTC would be free at any time, as it is now, to obtain the code through a subpoena based on a showing to a third party that the demand is within its authority and relevant and material to an investigation.
While some of the reactions in opposition to the rule seem at times a bit overwrought–after all, governmental agencies already have ready access to other essential information–those opponents, we think, still have the better of the argument. Furthermore, the fact that the mere proposal of access to source code without a subpoena has proved so unsettling to market participants should itself give the CFTC pause.
Endnotes
1 Box and Draper, Empirical Model-Building and Response Surfaces, 414 (2007).
2 8 Fed. Reg. 78824 (Dec. 17, 2015).
3 81 Fed. Reg. 85393 (Nov. 26, 2016).