[House Hearing, 114 Congress]
[From the U.S. Government Publishing Office]
EXAMINING THE CFTC'S PROPOSED RULE: REGULATION AUTOMATED TRADING
=======================================================================
HEARING
BEFORE THE
COMMITTEE ON AGRICULTURE
HOUSE OF REPRESENTATIVES
ONE HUNDRED FOURTEENTH CONGRESS
SECOND SESSION
__________
JULY 13, 2016
__________
Serial No. 114-56
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
Printed for the use of the Committee on Agriculture
agriculture.house.gov
______
U.S. GOVERNMENT PUBLISHING OFFICE
20-912 PDF WASHINGTON : 2016
-----------------------------------------------------------------------
For sale by the Superintendent of Documents, U.S. Government Publishing
Office Internet: bookstore.gpo.gov Phone: toll free (866) 512-1800;
DC area (202) 512-1800 Fax: (202) 512-2104 Mail: Stop IDCC,
Washington, DC 20402-0001
COMMITTEE ON AGRICULTURE
K. MICHAEL CONAWAY, Texas, Chairman
RANDY NEUGEBAUER, Texas, COLLIN C. PETERSON, Minnesota,
Vice Chairman Ranking Minority Member
BOB GOODLATTE, Virginia DAVID SCOTT, Georgia
FRANK D. LUCAS, Oklahoma JIM COSTA, California
STEVE KING, Iowa TIMOTHY J. WALZ, Minnesota
MIKE ROGERS, Alabama MARCIA L. FUDGE, Ohio
GLENN THOMPSON, Pennsylvania JAMES P. McGOVERN, Massachusetts
BOB GIBBS, Ohio SUZAN K. DelBENE, Washington
AUSTIN SCOTT, Georgia FILEMON VELA, Texas
ERIC A. ``RICK'' CRAWFORD, Arkansas MICHELLE LUJAN GRISHAM, New Mexico
SCOTT DesJARLAIS, Tennessee ANN M. KUSTER, New Hampshire
CHRISTOPHER P. GIBSON, New York RICHARD M. NOLAN, Minnesota
VICKY HARTZLER, Missouri CHERI BUSTOS, Illinois
DAN BENISHEK, Michigan SEAN PATRICK MALONEY, New York
JEFF DENHAM, California ANN KIRKPATRICK, Arizona
DOUG LaMALFA, California PETE AGUILAR, California
RODNEY DAVIS, Illinois STACEY E. PLASKETT, Virgin Islands
TED S. YOHO, Florida ALMA S. ADAMS, North Carolina
JACKIE WALORSKI, Indiana GWEN GRAHAM, Florida
RICK W. ALLEN, Georgia BRAD ASHFORD, Nebraska
MIKE BOST, Illinois
DAVID ROUZER, North Carolina
RALPH LEE ABRAHAM, Louisiana
JOHN R. MOOLENAAR, Michigan
DAN NEWHOUSE, Washington
TRENT KELLY, Mississippi
______
Scott C. Graves, Staff Director
Robert L. Larew, Minority Staff Director
(ii)
C O N T E N T S
----------
Page
Conaway, Hon. K. Michael, a Representative in Congress from
Texas, opening statement....................................... 1
Prepared statement........................................... 3
Peterson, Hon. Collin C., a Representative in Congress from
Minnesota, opening statement................................... 4
Witnesses
Wood, Gregory John, Chairman, Market Access Committee, Futures
Industry Association; Director, Electronic and Algorithmic
Execution, Listed Derivatives, Deutsche Bank Securities Inc.,
Washington, D.C................................................ 4
Prepared statement........................................... 6
Gorelick, J.D., Richard, Chief Executive Officer, RGM Advisors,
LLC, Austin, TX................................................ 11
Prepared statement........................................... 13
Vrabel, J.D., Andrew, Executive Director, Global Head of
Investigations, Market Regulation Department, CME Group, Inc.,
Chicago, IL.................................................... 20
Prepared statement........................................... 22
Ryan, Michael G., Executive Vice President and General Counsel,
Trading Technologies International, Inc., Chicago, IL.......... 25
Prepared statement........................................... 26
Submitted Material
Bergles, Susan, Assistant General Counsel, American Gas
Association, submitted statement............................... 65
EXAMINING THE CFTC'S PROPOSED RULE: REGULATION AUTOMATED TRADING
----------
WEDNESDAY, JULY 13, 2016
House of Representatives,
Committee on Agriculture,
Washington, D.C.
The Committee met, pursuant to call, at 10:00 a.m., in Room
1300 of the Longworth House Office Building, Hon. K. Michael
Conaway [Chairman of the Committee] presiding.
Members present: Representatives Conaway, Neugebauer,
Goodlatte, Lucas, King, Thompson, Gibbs, Austin Scott of
Georgia, Crawford, DesJarlais, Benishek, Denham, LaMalfa,
Davis, Allen, Moolenaar, Newhouse, Kelly, Peterson, David Scott
of Georgia, Walz, Fudge, McGovern, DelBene, Vela, Lujan
Grisham, Kuster, Nolan, Bustos, Kirkpatrick, Aguilar, Plaskett,
Adams, and Graham.
Staff present: Caleb Crosswhite, Darryl Blakey, Haley
Graves, Kevin Webb, Paul Balzano, Scott C. Graves, Stephanie
Addison, Liz Friedlander, Matthew MacKenzie, Nicole Scott, and
Carly Reedholm.
OPENING STATEMENT OF HON. K. MICHAEL CONAWAY, A REPRESENTATIVE
IN CONGRESS FROM TEXAS
The Chairman. Good morning. This hearing of the Committee
on Agriculture entitled, Examining the CFTC's Proposed Rule:
Regulation Automated Trading, will come to order.
I have asked Rick Crawford to open us with a quick prayer.
Rick.
Mr. Crawford. Thank you, Mr. Chairman.
Heavenly Father, we bow humbly before you today, thankful
for every blessing of life. Father, thank that we live in this
nation that you have provided for us. Father, just ask that
everything we say and do here today be pleasing in your sight.
Ask it in Jesus' name. Amen.
The Chairman. Thank you.
Good morning, and welcome again to the hearing on
Regulation Automated Trading. Before we get started, I want to
thank both Chairman and Ranking Member Scotts. I am not sure
how to properly phrase that, David, but you and Austin, and all
the Members of the CEEC Subcommittee for their work over the
past few months examining Title VII, and working through the
ongoing challenges in our derivatives markets. Implementing
Title VII has been a monumental task for regulators. The staff
and Commissioners of the CFTC deserve credit for their work.
Much has been improved over the past 2 years, but clearly,
there remains a significant amount of work to be done,
especially in harmonizing rules across borders and fixing
outstanding issues like the swap dealer de minimis problem.
Over the past 3 decades, our financial markets have been
quietly revolutionized by computers. Sometimes called the
``electronification'' of markets, computer networks have slowly
replaced the traditional trading pits. Electronic markets allow
computers to seamlessly input orders, giving rise to trading
directed and conducted entirely by computer algorithms.
Electronic markets and algorithms offer easier access,
reduced transaction costs, and support sophisticated tools that
even the smallest market participants can use. Today,
algorithmic trading is essential to our futures markets.
However, the transition to computers has not been without its
challenges. Computer algorithms sometimes interact in
unintended ways and markets have suffered disruptions that
remain difficult to explain.
In response to this challenging market structure, CFTC
staff began work several years ago to address the rise of
automated trading across its markets. Since 2012, CFTC staff
has held roundtables, participated in advisory committee
hearings, put forward a concept release, and no doubt held
countless other smaller meetings. Regulation Automated Trading
represents the culmination of all this work hard work.
Reg AT is summarized as a comprehensive approach to
reducing risk and increasing transparency in automated trading.
While I am certainly supportive of reducing risks and
increasing transparency, the approach proposed by the
Commission falls short of those goals.
Reg AT's vague boundaries and prescriptive requirements
conspire to create a rulemaking that is overly complicated, yet
still incomplete. However, the rule does not have to be this
complicated. The most confusing parts of Reg AT; the source
code rules, the registration regime, the reporting
requirements, and the inflexible risk controls, are unnecessary
to achieve the Commission's stated goals. Market participants
already have incentives to police bad algorithms, prevent
disruptions, and plan for recovery. In many cases, there are
already ongoing processes across the industry to impose and
refine risk controls.
A more modest proposal by the Commission might start by
leveraging these inherent incentives and requiring universal
adoption of a flexible framework for best practices.
While I believe the instincts and intentions of the rule
are good, its broad scope and sweeping requirements lead me to
conclude that it cannot be implemented in its current form. I
am heartened that Chairman Massad is open to finalizing the
rule in phases, taking more time to get it right. I look
forward to seeing the Commission's next proposal.
I have additional thoughts in my written statement, but for
now, let me close by thanking today's witnesses, each of whom
have traveled from out-of-town to be here today. We appreciate
your taking the time to prepare the testimony, and your
willingness to share your expertise with us, and I want to
thank you.
[The prepared statement of Mr. Conaway follows:]
Prepared Statement of Hon. K. Michael Conaway, a Representative in
Congress from Texas
Good morning, and welcome to the Committee's hearing on Regulation
Automated Trading.
Over the past 3 decades, our financial markets have been quietly
revolutionized by computers. Sometimes called the ``electronification''
of markets, computer networks have slowly replaced the traditional
trading pits. Electronic markets allow computers to seamlessly input
orders, giving rise to trading directed and conducted entirely by
computer algorithms.
Electronic markets and algorithms offer easier access, reduced
transaction costs, and support sophisticated tools that even the
smallest market participants use. Today, algorithmic trading is
essential to our futures markets. However, the transition to computers
has not been without its challenges. Computer algorithms sometimes
interact in unintended ways and markets have suffered disruptions that
remain difficult to explain.
In response to this changing market structure, CFTC staff began
work several years ago to address the rise of automated trading across
its markets. Since 2012, CFTC staff has held roundtables, participated
in advisory committee hearings, put forward a concept release, and no
doubt held countless other smaller meetings. Regulation Automated
Trading represents the culmination of all this work hard work.
Reg AT is summarized as ``a comprehensive approach to reducing risk
and increasing transparency in automated trading.'' While I am
certainly supportive of reducing risks and increasing transparency, the
approach proposed by the Commission falls short of those goals.
Requiring firms to provide the CFTC and the Department of Justice
with on-demand access to sensitive intellectual property is fraught
with danger. There is a legitimate fear among market participants that
allowing more people, even regulators, to view and store their
intellectual property increases their cybersecurity risks.
While the rule is unclear about the CFTC's intentions, at least one
interest group interpreted the rules to suggest that the CFTC will use
its newly self-granted authority to ``involve itself in the workings of
[automated trading systems] to anticipate problems . . .'' Such an
interpretation of the rule would require CFTC staff to oversee hundreds
of algorithmic trading companies, each running dozens of interdependent
algorithms, each written with tens of thousands of lines of code. It
isn't a stretch to say that using source code to ``anticipate
problems'' in the marketplace would require CFTC analysts to interpret
hundreds of millions of lines of code.
The CFTC cannot perform even a fraction of that work in any
meaningful way. Yet, absent such a proactive effort to monitor
algorithms, it is unclear why else the Commission would require source
code be produced without a subpoena.
Reg AT creates a definition, the AT Person, to identify the
entities covered by the rule which must comply with all of the
registration, reporting, testing, compliance, control, and source code
repository requirements. Included in that definition are any entities
already registered by the CFTC and ``engaged in algorithmic trading,''
as well as those registered as floor traders.
Twenty-five years ago, this Committee sought to prevent individuals
with felonies from trading in the pits by requiring the individuals
trading for their own account in futures pits to register as floor
traders, be fingerprinted, and undergo background checks.
Under Reg AT, this concept is being re-purposed to try and expand
the categories of registered market participants, despite no
Congressional change to the current registration requirements.
Beyond the obvious legal question, there is a practical problem to
using the floor trader definition in this way: the new definition of
floor trader could wind up unintentionally capturing thousands of end-
users as AT Persons.
Reg AT's vague boundaries and prescriptive requirements conspire to
create a rulemaking that is overly complicated, yet still incomplete.
However, the rule does not have to be this complicated. The most
confusing parts of Reg AT--the source code rules, the registration
regime, the reporting requirements, and the inflexible risk controls--
are unnecessary to achieve the Commission's stated goals. Market
participants already have incentives to police bad algorithms, prevent
disruptions, and plan for recovery. In many cases, there are already
ongoing processes across the industry to impose and refine risk
controls. A more modest proposal by the Commission might start by
leveraging these inherent incentives and requiring universal adoption
of a flexible framework for best practices.
While I believe the instincts and intentions of the rule are good,
its broad scope and sweeping requirements lead me to conclude that it
cannot be implemented in its current form. I am heartened that Chairman
Massad is open to finalizing the rule in phases and taking more time to
get it right. I look forward to seeing the Commission's next proposal.
I'll close by thanking today's witnesses, each of whom traveled
from out of town to be here today. We appreciate you for taking the
time to prepare testimony and your willingness to share your expertise
with us. Thank you.
With that, I'll turn to the Ranking Member for his remarks.
The Chairman. With that, I will turn to the Ranking Member
for his remarks. Collin.
OPENING STATEMENT OF HON. COLLIN C. PETERSON, A REPRESENTATIVE
IN CONGRESS FROM MINNESOTA
Mr. Peterson. Thank you, Mr. Chairman, and I thank the
witnesses for being here.
A little more than 6 years ago, broad-based stock indexes
collapsed and then rebounded over a course of about \1/2\ an
hour. The Dow dropped by 998 points in a few minutes, and this
was the largest infra-day point decline in its history.
Subsequent research by the CFTC and the SEC determined
three factors combined to cause this flash crash: algorithmic
trading activity, obscure order submission methods, and an
automated trade execution program to sell 75,000 stock index
futures.
Since the flash crash, there have been between 15 and 30
similar disruptions every single year in markets ranging from
treasuries to crude oil to agriculture futures. With Regulation
Automated Trading, the CFTC has proposed some rules to try to
prevent future market disruptions caused or made worse by
algorithmic trading. This rulemaking is still open, and the
CFTC is continuing to work on this, hopefully to get it right.
So I hope that this hearing adds to our understanding of
this complex issue, and assists the CFTC in its rulemaking.
I look forward to today's testimony, and I yield back.
The Chairman. Well, I thank the Ranking Member for his
comments.
The chair would request that other Members submit their
opening statements for the record so our witnesses may begin
their testimony, and to ensure that there is ample time for
questions.
We have asked witnesses today who actually have to live
with and/or are living with this rule, to give us as close to
an insider look at the impact the rules will have as we can.
We have Mr. Greg Wood, Chair, FIA Market Access Committee,
Washington, D.C. We have Richard Gorelick, CEO of RGM Advisors,
LLC, in Austin, Texas. Andrew Vrabel, Executive Director,
Global Investigations, the CME Group, Chicago, Illinois. And
Mr. Michael Ryan, the Executive Vice President and General
Counsel, Trading Technologies International, in Chicago as
well.
Mr. Wood, the floor is yours for 5 minutes.
STATEMENT OF GREGORY JOHN WOOD, CHAIRMAN, MARKET ACCESS
COMMITTEE, FUTURES INDUSTRY ASSOCIATION;
DIRECTOR, ELECTRONIC AND ALGORITHMIC EXECUTION, LISTED
DERIVATIVES, DEUTSCHE BANK SECURITIES INC., WASHINGTON, D.C.
Mr. Wood. Chairman Conaway, Ranking Member Peterson, and
Members of the Committee, thank you for holding this very
timely hearing on the Commodity Futures Trading Commission's
proposed Regulation Automated Trading.
My name is Greg Wood, and I am here today representing the
Futures Industry Association. I currently serve as the chair of
the FIA Market Access Committee, the co-chair of the FIA Market
Technology Division's Automated Trading Committee, and I
previously served as President of the FIA Market Technology
Division itself.
FIA has been working with the industry since well before
the 2010 flash crash to establish safeguards for electronic
trading. We have published five documents that include best
practices, recommendations for risk controls, as well as the
development, testing, and monitoring of trading software.
FIA employed ten working groups devoted to analyzing the
feasibility of the CFTC's proposed Reg AT, and provided
recommendations for improving the regulation prior to
finalization. Our efforts have involved the market
participants, the exchanges, the futures commission merchants
who act as facilitators for clients seeking to access the
cleared derivatives markets, as well as other industry
associations that represent various market constituents.
Our efforts have been comprehensive, and are outlined fully
within my written testimony, which also includes points that
will be discussed further by my fellow witnesses, such as
concerns regarding the source code provisions of the proposed
rule, as well as the complications that arise from the use of
third-party-provided software.
For the sake of time today, I will focus my comments on
FCMs and their views, particularly with regards to pre-trade
risk controls.
U.S. futures markets have evolved into highly sophisticated
electronic markets, and all market participants have a
responsibility appropriate to their participation in the life
of an order to help minimize the likelihood of a market
disruption. For that reason, pre-trade risk controls are the
responsibility of all market participants, and when implemented
properly and appropriate to the nature of the activity, have
been proven to be the most effective safeguard for the markets,
and should be applied comprehensively to all electronic orders,
not just those of AT persons.
Rather than defining what constitutes an AT person, and
using an artificially constructed trigger to require
registration of those participants, we believe that the most
important tool for achieving the goal of protecting market
integrity is requiring the application of pre-trade risk
controls to all electronic orders, regardless of the
participant's registration status. Rules should not focus on
any one specific type of market access, but rather should
recognize the appropriate application of pre-trade risk
controls to protect market integrity. Regulations should build
on and leverage the very successful risk controls and
safeguards currently in place, instead of proposing new and
untested systems or procedures that would require significant
investment by the industry. Requirements should not be one-
size-fits-all. Distinctions should be based on the business
structure, business model, operational size, and technical
sophistication of market participants, and the specific
implementation and location of particular risk controls should
not be mandated by the CFTC. Instead, the types of controls
required should be principles-based to provide for flexibility,
as well as to permit innovation and technological advances that
could improve future controls.
While we believe the CFTC can accomplish its objectives in
Reg AT without new registration requirements by applying risk
controls to all electronic trading, as previously discussed, we
understand that the CFTC is concerned that it may be unable to
enforce rules regarding automated trading against non-
registrants. Thus, in an effort to be responsive to the CFTC's
concerns, FIA has joined with other trade associations to
propose a requirement that all electronic trading must pass
through the pre-trade controls of a CFTC registrant. These
controls are typically in addition to the risk controls
provided at the DCM level. The responsibility for implementing
the appropriate pre-trade risk controls lies either with the
FCM registrant that is facilitating electronic access to the
DCM, or in the case of a market participant that is not trading
through the risk controls of an FCM, with that participant, who
is also a registrant. In both cases, these pre-trade risk
controls must be supplemented by DCM-provided risk controls
configured by the clearing member that grants access to the
DCM.
Required controls must meet the core principles of being
designed to reasonably mitigate the potential for sending
orders for too large a size to the DCM, sending orders for a
clearly erroneous price to the DCM, and sending too many
messages to the DCM.
We believe that the recommended approach I have outlined
reflects a thoughtful effort designed to most effectively
mitigate disruptions in the ever-evolving markets regulated by
the CFTC.
Again, I would like to thank you for holding this important
hearing. Oversight of the CFTC is such an important function of
this Committee, and we commend you for the time devoted to
these matters. I will be happy to answer any questions,
following my fellow panelists' testimony.
[The prepared statement of Mr. Wood follows:]
Prepared Statement of Gregory John Wood, Chairman, Market Access
Committee, Futures Industry Association; Director, Electronic and
Algorithmic Execution, Listed Derivatives, Deutsche Bank Securities
Inc., Washington, D.C.
Chairman Conaway and Ranking Member Peterson thank you for holding
this very timely hearing on the Commodity Futures Trading Commission's
(CFTC) Proposed Regulation Automated Trading (Reg AT). My name is Greg
Wood and I am here today representing the Futures Industry Association
(FIA). FIA's members have been extremely engaged in providing input to
the CFTC as it seeks to finalize Reg AT. I currently serve as the Co-
Chair of the FIA Market Technology Division Automated Trading
Committee, the Chair of the FIA Market Access Committee, and I
previously served as President of the FIA Market Technology Division.
FIA has been working with the industry since well before the 2010
Flash Crash to establish safeguards for electronic trading. We have
published five documents that include best practice recommendations for
risk controls, developing, testing and monitoring software, and other
protections.
FIA employed ten working groups devoted to analyzing the
feasibility of the CFTC's proposed Reg AT and providing recommendations
for improving the regulation prior to finalization. Our efforts have
involved the trading community, the exchanges, market participants and
the futures commission merchants (FCM), who act as facilitators for
clients seeking to access the cleared derivatives markets. In March of
2016, FIA filed a comprehensive comment letter to address the various
components of the proposal. Subsequently, and in response to a recent
CFTC Staff Roundtable, FIA has also worked with the Managed Funds
Association, SIFMA Asset Management Group, and the International Swaps
& Derivatives Association (together ``the Group'') to present a view
that has broad agreement across the industry. Further details can be
seen within the Group's comment letter submitted on June 24th.
Today, I will focus my comments on FCMs and their views,
particularly with regards to pre-trade risk controls.
During the course of a recent CFTC Staff Roundtable, Staff sought
to elicit suggestions on how to better define Direct Electronic Access
(DEA) as well as proposals for quantitative measures to reduce the
current population of AT Persons to which Reg AT would apply. In
addition, the Staff questioned whether requiring and monitoring
compliance by AT Persons could be imposed upon FCMs or designated
contract markets (DCMs). Roundtable participants soundly rejected these
proposals, as they did not address the real issues and concerns on
which the Commission and Reg AT should be focused.
Broadly, across all components of proposed Reg AT, the Group
believes that:
1. Pre-trade risk controls are the responsibility of all market
participants, and when implemented properly and appropriate
to the nature of the activity, have been proven to be the
most effective safeguard for the markets, and should be
applied comprehensively to all electronic orders, not just
those of AT Persons.
2. Rules should not focus on any one specific type of market access,
but, rather, should recognize the appropriate application
of pre-trade risk controls to protect market integrity.
3. Regulation should build on and leverage the very successful risk
controls and safeguards currently in place instead of
proposing new and untested systems or procedures that would
require significant investment by the industry.
4. Requirements should not be one-size-fits-all. Distinctions should
be based on the business structure, business model,
operational size, and technical sophistication of market
participants.
5. Rules should not be prescriptive.
I would like to highlight the following Three key points that FIA
feels should be considered in formulating a regulation that is both
scalable and effective:
First, Risk Controls. U.S. Futures markets have evolved into highly
sophisticated, electronic markets, and all market participants have a
responsibility appropriate to their participation in the life of an
order to help minimize the likelihood of a market disruption, and,
accordingly, all electronic trading should be subject to appropriate
pre-trade risk controls.\1\
---------------------------------------------------------------------------
\1\ Such pre-trade risk controls can be implemented directly by the
market participant or may be administered by the FCM facilitating
electronic access to the market--including those implemented within
third-party vendor systems or exchange provided graphical user
interfaces that the FCM has administrative control over.
---------------------------------------------------------------------------
Rather than defining what constitutes an AT Person, and using an
artificially constructed trigger to require registration of those
participants, we believe that the most important tool for achieving the
goal of protecting market integrity is requiring the application of
pre-trade risk controls to all electronic orders, regardless of the
participant's registration status. To be clear, we are not opposed to a
regulation category subject to appropriate requirements for that group
of registrants; however, we believe defining a particular group of
people and applying risk controls only to registrants does not
safeguard markets to the full extent the industry believes is needed.
To that effect, the Group believes:
Each market participant's orders should be subject to pre-
trade risk controls, depending on how the market participant
accesses a DCM. Access can be via self-developed software, a
third party provided system or FCM-administered \2\ software
and/or services. Orders from market participants leveraging
FCM-administered systems, including those provided by third
parties, may utilize pre-trade controls administered by the
FCM.
---------------------------------------------------------------------------
\2\ It is important to note that a customer may use the same FCM to
provide both execution and clearing services (``full-service FCM'') or
may use one FCM for execution (``executing FCM'') and choose to clear
their trades through another FCM (``clearing FCM'') by arranging for
the trades to be given up to the clearing FCM by the executing FCM. In
this instance, the executing FCM acts as the ``gatekeeper'' to the DCM
matching engine, and, as such, is the only FCM that can administer risk
controls at a pre-trade level. Any other FCM(s) that may subsequently
clear trades for the customer can only provide risk controls on a post-
trade basis once the trades have been given in from the executing FCM.
It is important to note that the Group believes that market
participants not using software that includes FCM-administered
risk controls should be responsible for applying risk controls
---------------------------------------------------------------------------
to their own orders.
FCMs facilitating electronic access to a DCM should be
responsible for implementing appropriate pre-trade risk
controls for all electronic trading that passes through those
controls that it administers. This can be accomplished by pre-
trade risk controls provided by the FCM itself, or those
provided by software that the FCM has administrative control
over.\3\ Where a market participant is responsible for the
administration of risk controls pursuant to Reg AT, the FCM may
satisfy this responsibility by administering DCM hosted risk
controls.
---------------------------------------------------------------------------
\3\ Note that administration of such controls may be delegated by
the FCM to another party, such as an introducing broker.
The risk controls proposed in the proposal are too
prescriptive. The specific implementation and location of
particular risk controls should not be mandated by the CFTC.
Instead, the types of controls required should be principles-
based to provide for flexibility as well as to permit
innovation and technological advances that could improve future
---------------------------------------------------------------------------
controls.
Identical pre-trade risk controls need not be applied at all
points in the order flow. Pre-trade risk controls should not be
duplicated in precisely the same manner across the order flow
between market participants and DCMs. Pre-trade risk control
requirements should permit flexibility such that the controls
will be appropriate for their location and the type of
electronic access being provided, with varying degrees of
sophistication and granularity depending on who is setting the
controls.
The standard used to measure compliance should be that pre-
trade risk controls mitigate the risks associated with
electronic trading--rather than attempt to completely prevent
them.
Based on these points, the Group proposes a requirement that all
electronic trading must pass through the pre-trade risk controls of a
CFTC registrant--either the market participant itself, or the FCM that
facilitates electronic access to the DCM. These controls are typically
in addition to the risk controls provided at the DCM level. The details
of this proposal are as follows:
Scope of Proposal: All electronic trading must be subject to
pre-trade and other risk controls administered by a CFTC
registrant that are appropriate to the nature of the activity.
The responsibility for implementing the appropriate pre-trade
risk controls lies either:
(a) with the FCM registrant that is facilitating electronic access
to the DCM,
or
(b) in the case of a market participant that is not trading
through the risk con-
trols of an FCM, with that participant, who is also a
registrant.
In both cases, these pre-trade risk controls must be supplemented
by DCM-provided risk controls configured by the member of the
DCO that grants access to the DCM.
Required Pre-Trade Risk Controls: Required controls must
meet the core principles of being designed to reasonably
mitigate the potential for:
1. Sending orders for too large a size to the DCM;
2. Sending orders for a clearly erroneous price to the DCM; and
3. Sending too many messages to the DCM.
Identification of Covered Trades/Participants: Market
participants trading electronically, without passing through
FCM-administered risk controls, either self-identify to
applicable DCMs prior to trading, or may be identified via tags
on order messages.
Due Diligence Requirement: An FCM must perform due diligence
on any customer to which it grants electronic access to the DCM
without going through risk controls administered by the FCM.
Such due diligence may include--for example--a self-
certification by the market participant that their orders are
subject to appropriate pre-trade and post-trade risk controls.
For the avoidance of doubt, such due diligence requirements do
not make the FCM responsible for ensuring their customers'
compliance with their own regulatory obligations.
Second, Annual Reports. Reg AT's proposed requirement of annual
reports to be prepared by market participants and clearing member FCMs
is ineffective, unnecessary, and redundant with other requirements to
which registrants are subject. Additionally, the proposed reports will
inundate DCMs with voluminous policies and procedures related to the
development and compliance of algorithmic trading systems, as well as
mountainous snapshots of stale quantitative risk parameter settings
particularized to a given market participant that will be virtually
impossible for a DCM to meaningfully assess. Accordingly, the Group
believes that the objectives of the proposed rule can be met less
onerously and more practically by requiring affected parties solely to
certify that they materially comply with relevant aspects of the rule
and to make such certifications available to a DCM or the CFTC upon
request.
Third, Source Code. The Source Code requirement for unfettered
access to any firm's intellectual property as proposed is unprecedented
among regulators and threatens commercially valuable intellectual
property and proprietary trading strategies. The Source Code
requirement in the proposed rule puts highly proprietary information at
risk without measurable benefits. Required production of Source Code
should only be available through a legal process where an owner of
Source Code has the right to petition a court for appropriate
protection. There is no sufficient set of access conditions (e.g.,
onsite review, tracking who reviews Source Code, etc.) that would
adequately offset the dire potential commercial consequences of
requiring production of Source Code absent the protection of legal
process.
Again, I would like to thank you for holding this important
hearing. Oversight of the CFTC is such an important function of this
Committee and we commend you for the time devoted to these matters. I
will be happy to answer any questions following my fellow panelists'
testimony.
Appendix
How Customers of FCMs Access Markets
A market participant may choose to access a DCM via several
channels (please refer to Diagram 1 for examples). Many market
participants may use a combination of channels to facilitate different
types of trading, using tools that are appropriate to the type of
activity that they engage in. With very few exceptions, an executing
FCM facilitates electronic access for the customer, and administers
pre-trade risk controls appropriate to the type of access.
1. In the context of electronic trading, an Application Programming
Interface (API) is an interface for electronic access
provided by one party for another party to connect directly
without using a manual means of placing orders and
receiving executions (see Graphical User Interface).
Examples of APIs include the following--
An API provided by a DCM for market participants to
connect directly to the matching engine. Such APIs are
usually proprietary to the DCM, and will offer
functionality such as types of messages, order types,
etc., that is specific to the DCM. Connection to the
API is overseen by the DCM through a certification
process. Subsequent to CFTC 1.73, the DCM provides pre-
trade risk controls to the FCM that facilitates
electronic access (see J on attached diagram).
The FCM administers pre-trade risk controls provided
to them by the DCM, but greater responsibility lies
with the market participant to implement their own pre-
trade risk controls to mitigate the possibility of
inadvertent market disruption.
(a) An API provided by an FCM for market participants to connect
via the FCM infrastructure, with orders subsequently
routed via the
FCM's Automated Order Routing System (AORS) through to
the DCM's
API. Such APIs are usually based on the FIX Protocol, a
global standard
for the exchange of financial information across asset
classes. An FCM's
API may be used for routing orders directly from a
customer's trading
system or from a third-party trading system without
using a manual
means of placing orders and receiving executions (see
Graphical User
Interface).
Pre-trade risk management for orders routed
through an FCM's API is provided by the FCM
before the order is subsequently routed to the
DCM (see K M on attached diagram).
(b) An API provided by a third-party software provider for
market
participants to connect via their infrastructure, with
orders subse-
quently routed via the software provider's Automated
Order Routing Sys-
tem (AORS) through to the DCM's API. Such APIs are
usually based on
the FIX Protocol, a global standard for the exchange of
financial informa-
tion across asset classes. A software provider API is
used for routing or-
ders directly from a customers' trading system or from
a third-party trad-
ing system without using a manual means of placing
orders and receiving
executions (see Graphical User Interface).
Pre-trade risk management for orders routed
through a software provider's API is provided
in their system before the order is
subsequently routed to the DCM (see L on
attached diagram). Such risk controls are
typically administered by the FCM facilitating
access to the DCM via the software provider.\4\
---------------------------------------------------------------------------
\4\ Note that where a non-FCM clearing member of a DCM uses a
software provider to access the market, via either API or GUI, there is
no second line of pre-trade risk control administered by an FCM. In
such a situation where the non-FCM clearing member sets their own pre-
trade risk controls, additional responsibility may be required on the
market participant to ensure that all appropriate steps are taken to
mitigate the possibility of inadvertent market disruption.
2. In the context of electronic trading, a Graphical User Interface
(GUI) is an interface for access provided by one party for
another party to manually place orders and visually receive
---------------------------------------------------------------------------
executions.
Examples of GUIs include the following--
(a) A GUI provided by a DCM for market participants to place
orders
directly on the DCM. Such GUIs are usually provided for
functionality
that is unique to the DCM and/or may not be readily
available via the
DCM API. In this situation, the DCM is acting as a
software provider,
and pre-trade risk management for orders entered though
such a GUI is
administered by the FCM facilitating access.
(b) A GUI provided by an FCM for market participants to place
or-
ders directly with the FCM, with orders subsequently
routed via the
FCM's Automated Order Routing System (AORS) through to
the DCM's
API. Pre-trade risk management for orders routed
through such a GUI
is provided and administered by the FCM before the
order is subse-
quently routed to the DCM (see K M on attached
diagram).
(c) A GUI provided by a software provider for market
participants to
place orders directly via their infrastructure, with
orders subse-
quently routed via the vendor's Automated Order Routing
System (AORS)
through to the DCM's API. Pre-trade risk management for
orders routed
through such a GUI is provided by the software provider
before the order
is subsequently routed to the DCM (see L on attached
diagram). Such
risk controls are typically administered by the FCM
facilitating access to
the DCM.
3. An Automated Order Routing System (AORS) is software designed to
electronically route orders to a DCM, without any
subsequent discretion in how to work the order. Any
discretion regarding how to work an order based on
parameters provided by a trader or customer--for example
using algorithmic execution functionality--should be
considered ``algorithmic trading'' and considered
differently from an AORS.
AORSs are utilized by many types of market
participants, and typically offer pre-trade risk
management functionality. It is important to understand
who administers the pre-trade risk controls.
Types of AORS include the following:
(a) An AORS provided by an FCM where orders may be entered via
an API or GUI and subsequently routed to the DCM's API
(see K
M on attached diagram) using the FCM's membership on
the DCM. Such
a system may be developed in-house at the FCM or
licensed from a third-
party provider, but in either situation, the AORS is
considered part of the
FCM's infrastructure. Pre-trade risk controls are
provided and adminis-
tered by the FCM on a customer-by-customer basis. The
FCM in this sce-
nario is always the executing FCM, though they may also
be the clearing
FCM based on their customer relationship.
(b) An AORS provided by a software provider where orders may be
entered via an API or GUI and subsequently routed to
the DCM's
API (see L on attached diagram) using an FCM's
membership on the
DCM. The software provider gives FCMs the ability to
permission the
customer to trade and set the appropriate risk limits.
Although such a
system is not fully under the control of an FCM,
especially where the
AORS provides access to multiple FCMs, it can still be
considered an ex-
tension of the FCM's infrastructure because a customer
may not trade
until the FCM sets appropriate pre-trade risk controls.
As such, pre-trade
risk controls are administered by the FCM on a
customer-by-customer
basis. The FCM in this scenario is always the executing
FCM, though
they may also be the clearing FCM based on their
customer relationship.
An AORS utilized by a market participant where orders may be
entered via an API or GUI and subsequently routed to the DCM's API (see
J on attached diagram). Such a system may be developed in-house by the
market participant or licensed from a software provider, but in either
case is considered part of the participant's infrastructure. Pre-trade
risk controls are administered directly by the participant, and not by
an FCM. The AORS is certified by the DCM to connect directly to its
API, and access is facilitated by an FCM via its membership on the DCM.
The FCM in this scenario is always the executing FCM, though they may
also be the clearing FCM based on their customer relationship.
Sample Pre-Trade Risk Control Locations
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
The Chairman. Thank you.
Richard, 5 minutes.
STATEMENT OF RICHARD GORELICK, J.D., CHIEF EXECUTIVE OFFICER,
RGM ADVISORS, LLC, AUSTIN, TX
Mr. Gorelick. Thank you, Chairman Conaway, Ranking Member
Peterson, and Members of the Committee. Thank you for the
opportunity to discuss the CFTC's proposed Reg AT. I will
briefly summarize my written statement now, which I ask be
included in the record.
I am the CEO of RGM Advisors, a proprietary trading firm
that I co-founded in 2001, that trades electronically in a
variety of markets. We are based in Austin, Texas, where we
employ about 100 people. I serve on the CFTC's Technology
Advisory Committee, and I am involved in industry efforts to
enhance trading risk management and public policy. I have
advocated for a regulatory environment that promotes fair
competition, encourages innovation, improves transparency,
manages systemic risk, lowers cost for investors and end-users,
and gives regulators the tools that they need to detect and
deter abuses.
Mr. Chairman, I support the Commission's stated aims in Reg
AT, however, I am concerned that the proposal falls short of
achieving them. The rule could amount to a lot of work by the
industry and by the Commission, and at best, accomplish only
small gains in market integrity. We are fortunate that the
industry has already put in place multiple layers of risk
controls. New rules should be principles-based and they should
be flexible, because technology changes quickly. And since pre-
trade risk controls are the most effective safeguard for market
integrity, all electronic orders should be subject to them,
regardless of the type of market participant or their
registration status.
Reg AT tries to accomplish too much in a single regulation.
I support the recommendation of commenters to simplify the
rulemaking by dividing it into separate parts, focusing first
on pre-trade risk management.
One part that should be considered separately is the
Commission's proposal to create a new requirement for certain
market participants to register with the Commission. Setting
aside the curious decision to register these automated traders,
many of whom never set foot on a trading floor, as floor
traders, this requirement is unnecessary to accomplish the
Commission's risk management objectives. My written testimony
discusses the principles that should guide any automated
trading regulation, and includes discussion of several other
provisions in Reg AT.
I would like to turn to my concern with the rule's
treatment of source code. Source code is an automated trading
firm's secret sauce. It comprises very specific and detailed
computer instructions that embody the firm's unique trading
strategies. Source code often includes valuable trade secrets,
developed at significant expense, that directly impact business
competitiveness. The requirement to turn over valuable
intellectual property to the government on demand would be
unprecedented and unreasonable. The proper treatment of IP is
central to our private enterprise system. The secret formula
for Coca-Cola is not available to the FDA simply upon request.
The source code for Google's search algorithms is not available
to the government without due process. Government agencies must
make a reasonable showing of cause and use a subpoena to get
access to private proprietary information. A trading firm's
source code should be no different.
For most purposes, source code reviews would be incredibly
costly for the CFTC. Trading firms have large and complicated
code bases that change regularly. As an example, my relatively
small firm has over one million lines of source code associated
with our current trading system. We make changes almost daily.
To review source code of multiple firms at any scale would
require an army of computer programmer regulators. The benefits
to the CFTC of reviewing source code would, in most cases, be
very limited. It is implausible that reviewing source code as
part of an audit or surveillance program would help the CFTC
prevent market disruptions, or provide meaningful insight into
how a trading system would operate when interacting in a real
market. In most cases, surveillance of electronic audit trails
presents a much more valuable and cost-effective way to
understand trading activity.
I can imagine circumstances in which a regulator would have
a legitimate interest in reviewing parts of a firm's source
code. However, under those limited circumstances, the regulator
should be required to use a subpoena and put in place
appropriate safeguards. As we all know, any agency taking
possession of source code could raise significant cybersecurity
concerns.
Finally, allowing easy government access to source code
would set a dangerous precedent with foreign governments, such
as China, who seek to impose similar requirements on U.S.
firms. We are hopeful that this provision will be revised.
Thank you for the opportunity to testify, and I welcome the
Committee's interest in this rulemaking.
[The prepared statement of Mr. Gorelick follows:]
Prepared Statement of Richard Gorelick, J.D., Chief Executive Officer,
RGM Advisors, LLC, Austin, TX
I. Introduction
Chairman Conaway, Ranking Member Peterson, and Members of the
Committee, thank you for the opportunity to join you today to discuss
the Commodity Futures Trading Commission's (CFTC's or the Commission's)
proposed regulation on automated trading, or ``Reg AT'' as it is
commonly known.\1\ I am pleased to be with you today to discuss this
significant regulatory proposal.
---------------------------------------------------------------------------
\1\ Proposed Regulation Automated Trading, 80 FR 78824 (Dec. 17,
2015).
---------------------------------------------------------------------------
I am the CEO of RGM Advisors, a trading firm located in Austin, TX,
that I co-founded in 2001. RGM Advisors is a technology-focused,
quantitative trading firm that trades in a variety of equities and
futures markets. We use computers to analyze tremendous amounts of
market data, to determine what trades we want to make, to conduct those
trades, and to manage risk. We have about 100 employees and most of our
staff are software developers, information technologists, and
quantitative researchers. Most of our software systems have been
developed in-house. Our firm, like many in our sector, trades on a
proprietary basis, using our own capital to take short-term positions
in thousands of instruments.
I serve on the CFTC's Technical Advisory Committee (TAC) and I am a
member of the FIA Principal Traders Group (FIA PTG) executive
committee. My written testimony today expands on public comments I have
shared with the CFTC TAC \2\ and it reflects many of the views that FIA
PTG has expressed to the Commission.\3\
---------------------------------------------------------------------------
\2\ See http://www.cftc.gov/idc/groups/public/@newsroom/documents/
file/tac_022316_tran
script.pdf, page 29
\3\ See https://fia.org/sites/default/files/content_attachments/
2016-03-16_Regulation_AT_
Comment_Letter.pdf and https://fia.org/sites/default/files/2016-06-
24_RegAT_Roundtable_
Group_Comment.pdf.
---------------------------------------------------------------------------
I have been involved in industry-led efforts to develop best
practices and guidelines on identifying and mitigating the risks of
automated and electronic trading. Since 2010, FIA has published six
papers related to these important topics. As a member of the TAC, I
have reviewed and commented on CFTC's proposed regulation of automated
trading since before the Commission first began considering its initial
concept release.
The progression of automated trading has provided substantial
benefits to our markets. Increasing automation and competition have
helped to improve market quality, increase transparency, and lower
costs for investors, hedgers and end-users of all sizes. As we
recognize and work to enhance the many benefits of automated trading,
we must also ensure that rules and regulations keep pace with
technological innovation. I have long been a strong advocate for a
regulatory environment that promotes fair competition, encourages
innovation, enhances transparency, manages systemic risk, lowers costs
for investors and hedgers, and gives regulators the tools they need to
detect and deter abuses.
I am supportive of the Commission's stated aims in developing Reg
AT, which are to mitigate the risks arising from algorithmic trading
activity, to increase transparency with respect to exchange programs
and activities, and to update Commission rules in response to the
evolution from pit trading to electronic trading. I appreciate the
substantial effort put forth by the Commission staff in drafting this
proposal.
While these goals are laudable, the proposed rule, as it currently
stands, falls short of achieving these goals, and is overly
complicated, costly, and confusing. Some aspects of the proposed rule
are too broad, while others are too narrow to adequately address risks.
I am concerned that the rule could amount to quite a lot of work by the
industry and by the Commission to accomplish disproportionately small
gains in market integrity, while introducing significant potential
negative unintended consequences.
In my testimony, I will first set out generally accepted principles
for the regulation of automated trading and then share substantive
concerns with proposed Reg AT.
II. Principles for Regulation of Automated Trading
There is broad industry consensus on the principles that should
guide any regulation of automated trading.
First, it is critical to recognize and leverage the substantial
risk controls and safeguards that have already been put in place by the
industry. The CFTC's TAC has provided a forum to explore current
industry practices with respect to electronic trading. In addition to
detailed discussions of industry best practices for risk management,
exchanges (CME and ICE, in particular) have presented thoughtful risk
controls and extensive surveillance capabilities in great detail. New
regulation should build on the existing framework that has proven
successful, and should not try to reinvent that framework.
Second, to be effective and relevant to dynamic market conditions
and practices, regulations cannot and should not be overly
prescriptive. Instead, as has been the CFTC's historical practice,
regulators should adopt principles-based rules that allow for
flexibility to distinguish between different activities, business
structures, and technologies of market participants, as well as
changing market conditions, among other factors. Technology changes
quickly, so it is important that the rules are able to stand the test
of time.
Third, and most critical, pre-trade risk controls are the most
effective safeguard for market integrity. Therefore, they should be
applied comprehensively to all electronic orders, not just certain
orders submitted by certain types of businesses or submitted through
certain types of market access. Simply put, all electronic orders
should be subject to risk controls, not just those from certain types
of market participants. To do otherwise would create loopholes and
blind spots.
To be clear, the application of risk controls to every order does
not require every market participant to implement its own risk
controls. The policy should be to ensure that all orders are subject to
appropriate risk controls that can be provided in various ways by
market participants, clearing firms, or exchanges.
III. Specific Concerns with Proposed Reg AT
With respect for the CFTC's significant work on this rule, I
believe Reg AT tries to accomplish far too much in a single regulation,
making it unwieldy and impractical. To address this, I support the idea
of simplifying the rulemaking by breaking it up into separate
components, in order of importance: (1) pre-trade and other risk
controls, (2) policies and procedures for the development, testing,
deployment and monitoring of algorithmic trading (including third-party
software), and (3) if necessary, registration of certain market
participants.
Considering these components separately would allow the Commission
to focus first on the parts of Reg AT that are most important to market
integrity and widely supported by industry participants: pre-trade and
other risk controls. Separating the rulemaking would also allow the
CFTC to determine the proper scope for each area of regulation.
My specific concerns with Reg AT fall into the following
categories: the scope of the proposal, unnecessary registration
requirements, and access to intellectual property, including source
code, without due process.
A. The Scope of Reg AT Is Too Broad in Some Parts and Too Narrow in
Others
One of the stated goals of the proposed rule is to reduce the risks
of automated trading. To accomplish this, it introduces a myriad of
requirements, both technical and operational in nature, for newly
defined ``AT Persons.''
Rather than starting from the principle that all electronic orders
must be governed by certain risk controls, the rule proposal attempts
to cover a limited class of market participants within the definition
of an AT Person. Consequently, the rule would establish a class of
market participant that would not be required to have risk controls in
place despite having a similar ability to impact market integrity. As a
result, the rule may fail in its primary goal of protecting the market.
In other areas, the Commission's proposal is too broad. In
particular, the rule would impose a wide range of very specific
requirements pertaining to how AT Persons manage their automated
trading operations. These requirements include detailed rules for
development, testing, documentation, monitoring, training, compliance
and reporting across several dimensions of a firm's operations. While
some of these requirements roughly track industry best practices,
others do not, and most of these requirements are burdensome and do not
clearly contribute to market integrity.
As just one example, the proposal includes a provision that would
require AT Persons to produce an annual report detailing all changes to
their risk settings during the course of a year and to deliver that
annual report to the exchanges on which they traded. It is not unusual
for firms trading hundreds of products to change their risk limits
multiple times per day. These changes are often made in an exchange-
based interface managed by a clearing firm, and as a result, the
clearing firm and the exchange know about the risk limit changes in
real time. While it would amount to a lot of work for AT Persons to
produce these annual reports and for exchanges to review them, it is
hard to see what additional information would be communicated in the
process, or how risk management would be improved. Such onerous
requirements would both inhibit an AT Person's ability to innovate
compared to non-AT Persons with similar businesses, and also
dramatically increase the cost of maintaining algorithmic trading
operations. These costs would certainly be passed on to market end-
users in the form of higher transaction costs and less liquid markets.
Moreover, some of the proposed definitions are, in my opinion, too
broad and, as a result, may be counterproductive. Much of the proposed
rule is geared toward preventing ``Algorithmic Trading Events'' which
are defined to include both ``Algorithmic Trading Compliance Issues''
and ``Algorithmic Trading Disruptions.'' As a result of these
definitions, the more comprehensive a firm's policies, the more
liability it would risk if any practice were found to have varied from
its written policy. Rational actors would be incented to have fewer
internal controls, rather than more. Similarly, the rule would prohibit
firms from ``disrupting or materially degrading'' their own trading.
This requirement might encourage firms to continue trading in the face
of potential risk management issues. In my opinion, those provisions
should be eliminated from their respective definitions.
B. The Registration Requirements Are Unnecessary
The CFTC is proposing to create a new requirement for certain
market participants trading solely for their own account and using
automation to register with the Commission as floor traders. Setting
aside the curious decision to register these automated traders, many of
whom never set foot on a trading floor, as ``floor traders,'' this
requirement is unnecessary. Exchange rules and industry best practices
already require some types of pre-trade risk management for all market
participants regardless of registration category. The trading activity
by the market participants that would be covered by this requirement is
already managed through exchanges and there is no gap in risk controls.
The CFTC has the legal authority and should apply appropriate risk
management requirements broadly to all market participants whether or
not they are registered with the Commission.\4\
---------------------------------------------------------------------------
\4\ The Commission already has ample legal authority to impose
requirements on non-registrants that trade on U.S. futures markets in
order to prevent disruptive practices expressly described in Section
4c(a)(5) of the Commodity Exchange Act (``CEA''), as well as ``any
other trading practice that is disruptive of fair and equitable
trading.'' Using this authority, the CFTC has a statutory basis to
enact rules to require all traders (whether registered as AT Persons or
not) to comply with requirements meant to avoid prohibited conduct.
---------------------------------------------------------------------------
I support comments by FIA, FIA PTG, and other industry associations
explaining that registration requirements are unnecessary. I reiterate
that any market participant, regardless of registration status or type
of trader, has the potential to disrupt markets. It should be noted
that when the SEC studied market disruptions (or so-called mini-flash-
crashes) they noted that the majority of such events were caused by
human mistakes, such as fat-finger errors, rather than algorithmic
trading bugs. In addition, if the Commission would start from the basic
principle that all electronic orders should be subject to risk
controls, and that these requirements should not hinge on registration
status, the entire rule would become much less complex to design and
implement.
Should the CFTC be determined to implement a new registration
requirement, then such registration should be considered separately and
apart from the proposed pre-trade risk controls in proposed Reg AT, so
its potential effects can be given full and careful consideration. Any
registration requirement should be based upon a new and more suitable
registration category rather than over-loading the existing ``floor
trader'' category created for individual market participants standing
on a trading floor.\5\ At a minimum, the Commission should delay
adoption of any registration requirement until after it has implemented
other components of Reg AT to evaluate the necessity of registration,
which would be costly for new registrants and the Commission, and would
be a burdensome distraction for the National Futures Association (NFA).
---------------------------------------------------------------------------
\5\ See http://comments.cftc.gov/PublicComments/
ViewComment.aspx?id=60765 (``Even if the Commission disagrees and
decides that registration is necessary to ensure compliance with the
Proposal, CME Group questions whether the Commission has sufficient
legal authority under the CEA to require registration as a `floor
trader' of a new type of distinctly non-floor trader. Historically, the
scope of CFTC registrants has only been expanded when Congress provides
the Commission with new statutory authority. [. . .] In the absence of
such new authority from Congress, the Commission proposes to introduce
otherwise unregistered algorithmic traders who access an exchange
through DEA into an existing statutory registration category. CME Group
is not persuaded by the Commission's argument that Congress could have
intended for the definition of `floor trader' to include only this
subset of algorithmic traders.'')
---------------------------------------------------------------------------
C. Source Code Should Only be Available to the Government with Due
Process
The final concern I would like to raise today is the CFTC's
proposed access to source code. The proposed requirement to turn over
valuable intellectual property (IP) to the government on demand is
simply unprecedented and unreasonable. The proper treatment of IP lies
at the heart of our private enterprise system. As noted by CFTC
Commissioner Giancarlo in connection with the issuing release for Reg
AT,\6\ the secret formula for Coca Cola is not available to the FDA,
certainly not on demand. The source code for Google's search algorithms
is not available to the government without due process. Government
agencies must make a reasonable showing of cause and get a proper court
order, such as a subpoena, to gain access to intellectual property.
---------------------------------------------------------------------------
\6\ See http://www.cftc.gov/idc/groups/public/@newsroom/documents/
file/transcript
112415.pdf, page 39.
---------------------------------------------------------------------------
A trading firm's source code should be no different. Most modern
trading firms are very much technology businesses. Many of our staff
write software, and our source code constitutes important trade secrets
and valuable IP about our future business plans. Modern trading firms
invest significant time, effort and money in technological innovation,
much of which is embodied in source code, and they go to great lengths
to protect its confidentiality and their competitive edge. Not only
would this proposed provision set a troubling precedent for government
access to private information, but it would do so without any
demonstrable regulatory benefits to offset the significant risk
associated with the misappropriation of that intellectual property.
Proposed Reg AT would accomplish this unprecedented access by
classifying source code as ``books and records'' which would make them
available to the Commission and the Department of Justice upon request.
Source code, however, is unlike other books and records such as trade
blotters and similar records, which can be reasonably protected with
standard confidentiality. Source code often is comprised of valuable
trade secrets that represent substantial investment and innovation and
can directly impact the competitiveness of a business.
It should be recognized that for most purposes, source code reviews
would be incredibly costly for the CFTC. Trading firms have very large
and complicated code bases that change very often. As an example, my
firm is a relatively small trading firm. We have over a million lines
of source code associated with our current trading systems. This code
has been written over 15 years in about ten different programming
languages. We make changes of one kind or another almost daily. To
review source code of multiple firms at any scale would require an army
of computer programmer regulators.
The benefits to the CFTC of reviewing source code would, in most
cases, be very limited. It is not plausible that reviewing source code
as part of an audit or surveillance program would somehow help the CFTC
prevent future market disruptions or provide any meaningful insight
into how a trading system would operate in a real market when
interacting with other traders in different market conditions. In most
cases, surveillance and analysis of electronic audit trails (such as
orders, fills, and cancellations) would present a much more valuable
and cost effective way to understand trading activity.
I can imagine circumstances in which a government agency, such as
the CFTC, would have a legitimate interest in reviewing parts of a
firm's source code. For example, in an enforcement action for market
abuse, reviewing portions of source code might provide some insight
into the intent behind the placement of certain orders. However, under
those limited circumstances, the Commission should be required to get a
subpoena, and put in place appropriate safeguards. To the extent that
the CFTC takes possession of any source code, this would raise
significant information security concerns.
Moreover, allowing easy government access to source code would set
a dangerous global precedent with foreign governments, such as China,
who are seeking to impose similar source code requirements on U.S.
firms. In fact, the Federal Government recently emphasized the
importance of intellectual property by signing the Defend Trade Secrets
Act into law in order to enhance protections against the
misappropriation of intellectual property. This development has not
gone unnoticed. In fact, a number of technology and business-focused
industry organizations have raised this exact point in formal comments
to the CFTC.\7\
---------------------------------------------------------------------------
\7\ See http://comments.cftc.gov/PublicComments/
ViewComment.aspx?id=60890&.
---------------------------------------------------------------------------
We are hopeful that this provision will be revised. CFTC Chairman
Massad has indicated that the Commission ``take[s] very seriously the
fact that [the information] is proprietary, it is significant of value
to firms, and . . . [we] would certainly . . . do everything [the CFTC]
can to protect confidentiality.'' \8\ As such, the current practice--
which enables the CFTC or Department of Justice to seek a voluntary
production of source code subject to agreed restrictions, or to request
such source code via a validly issued subpoena in connection with a
formal investigation--is sufficient and should be continued.
---------------------------------------------------------------------------
\8\ See http://www.cftc.gov/idc/groups/public/@newsroom/documents/
file/transcript0610
16.pdf, pages 295-296.
---------------------------------------------------------------------------
I understand that some regulators have worried that trading firms
might not adequately retain their source code in such a way that they
could make it available for inspection. While good software development
practices already lead firms to retain their source code in software
control systems, I believe it would be helpful for the Commission to
work with industry groups to establish a principles-based retention
policy for source code based on current practices that would ensure
regulators have access to source code information when needed.\9\ This
would allow businesses to maintain control over their sensitive
intellectual property while ensuring regulators can access information
that they desire, after following appropriate processes.
---------------------------------------------------------------------------
\9\ See https://fia.org/sites/default/files/2016-06-
24_RegAT_Roundtable_Group_Comment.pdf, page 9-10.
---------------------------------------------------------------------------
IV. Conclusion
Altogether, proposed Reg AT would impose costly burdens on market
participants, without commensurate benefits. Our markets are dynamic
and constantly changing. Mandated risk controls, like those in Reg AT,
which are overly specific, could quickly become obsolete as markets,
technology, and trading strategies evolve. Creating checklists and
written policies might give the appearance of reform, but in practice,
do not make markets safer or more resilient--and could instead create
unintended incentives to the contrary.
The trading community has a direct interest in well-functioning and
resilient markets. We want to comply with the rules of the road. We
welcome improvements that actually make the markets safer and more
efficient. However, when rules serve to impede those goals, we need to
reconsider them. I am concerned that proposed Reg AT, as designed,
would not accomplish its stated objective of protecting market
integrity, because it would leave many electronic orders outside of its
scope. Moreover, this proposed regulation, as currently written, would
be costly for market participants and the Commission. These costs would
ultimately be borne by market end-users in the form of higher
transaction costs and less liquidity. Finally, the source code access
provisions put valuable American intellectual property in jeopardy, are
without precedent, and would have a chilling effect on technology both
inside and outside of the derivatives world.
I appreciate the opportunity to testify before you today and I
welcome the Committee's interest in consideration of this rulemaking. I
look forward to answering any questions you may have.
Thank you.
[Attachment]
June 24, 2016
Via CFTC Website: http://comments.cftc.gov
Christopher Kirkpatrick,
Secretary of the Commission,
Commodity Futures Trading Commission,
Washington, D.C.
RE: RIN 3038-AD52--Joint coalition comments in response to CFTC
Proposed Regulation AT source code provisions
Dear Mr. Kirkpatrick:
The U.S. Chamber of Commerce (the ``Chamber''), the Information
Technology Industry Council (``ITI''), the Business Software Alliance,
the International Swaps and Derivatives Association, the Futures
Industry Association (``FIA''), the FIA Principal Traders Group, Modern
Markets Initiative, and the Software & Information Industry Association
write to you in strong opposition to the source code disclosure and
retention requirements contained in the Commodity Futures Trading
Commission's (the ``CFTC'') notice of proposed rulemaking on Regulation
Automated Trading (``Regulation AT'') \1\ and urge you to entirely
eliminate these requirements from the final version of the rule.
---------------------------------------------------------------------------
\1\ Commodity Futures Trading Commission, 80 Fed. Reg. 242
(proposed Dec. 17, 2015) (to be codified at 17 CFR Parts 1, 28, 40, et
al.).
---------------------------------------------------------------------------
In short, if not significantly amended, the proprietary source code
provisions of Regulation AT will:
(1) compromise the established and expected due process rights of
our members;
(2) increase the threat of ``copycat'' measures from other countries
and contradict established U.S. policy on intellectual
property disclosure;
(3) heighten the possibility of cyberattacks against government-
mandated data repositories; and
(4) do little to assist the CFTC in its market surveillance
activities.
While this letter is not an exhaustive listing of all of the issues
of our associations may have with Regulation AT, we believe that it is
important that the CFTC appreciate the broad-based opposition we have
to Regulation AT's proprietary source code provisions.\2\ We elaborate
in additional detail below.
---------------------------------------------------------------------------
\2\ For additional detail, please see letter of March 16, 2016 to
CFTC on Proposed Regulation AT source code provisions, available at the
following link (https://www.itic.org/dotAsset/469665b9-7552-4763-9569-
b835eb81a585.pdf).
---------------------------------------------------------------------------
Mandating On-Demand Access to Proprietary Source Code Tramples
Fundamental Due Process Rights and Attracts Similar Global
Responses
Our chief concern with Regulation AT relates to the unprecedented,
on-demand access that the CFTC would have to the proprietary source
code of market participants engaged in algorithmic trading. Simply put,
the proposed requirements force the disclosure of valuable intellectual
property to the government based only on a showing that is akin to a
document request. That type of requested access contradicts widely held
expectations of due process associated with highly sensitive
intellectual property--and, indeed, the legal protections that apply to
any intellectual property in the U.S.
While the CFTC has recently acknowledged these concerns at a staff
roundtable, there is no clear explanation as to why the CFTC could not
use well-established U.S. judicial process to obtain access to
proprietary source code data when needed. The CFTC and the DOJ have
long used subpoenas to obtain access to non-public information and can
continue to do so here. However, Regulation AT would provide an end-run
around these important protections, eroding the important due process
rights of these market participants.
Even more concerning is the precedent that the Regulation AT source
code provisions would set, which may invite similar requirements in
other countries. As recently as last year, the United States pushed
back against a comparable proposal issued by the China Banking
Regulatory Commission, which would have required American companies
selling computer equipment to Chinese banks to turn over intellectual
property and submit source code.\3\ This action is also consistent with
the U.S. Government's policy against source code disclosure
requirements in other contexts, as evidenced by previous opposition to
proposed regulations issued by India's Department of Telecommunications
relating to 2009-2010 Telecom Network Equipment Certification
requirements, and by Korea's National Intelligence Service in 2005
relating to sales of information security software to Korean Government
agencies. Moreover, the signatories to the Trans-Pacific Partnership
have also agreed not to require the transfer of, or access to, source
code of software owned by a person of another party as a condition for
the import, distribution, sale, or use of such software.\4\
---------------------------------------------------------------------------
\3\ Paul Mozur and Jane Perlez, China Halts New Policy on Tech for
Banks, N.Y. Times, Apr. 16, 2015, available at http://www.nytimes.com/
2015/04/17/business/international/china-suspends-rules-on-tech-
companies-serving-banks.html?_r=0.
\4\ See Article 14.17: Source Code, Trans-Pacific Partnership (ICT
Annex), available at
https://ustr.gov/sites/default/files/TPP-Final-Text-Electronic-
Commerce.pdf.
---------------------------------------------------------------------------
These policy decisions from other parts of the U.S. Government
demonstrate a strong expression of U.S. Administration policy to defend
the rights of intellectual property holders from unnecessary disclosure
to third parties, including government entities. It also signals the
extent to which the CFTC is a relative outlier compared to other
financial services and capital markets regulators, and certainly with
respect to other instrumentalities of the U.S. Government. We believe
that the CFTC should follow these decisions when finalizing Regulation
AT, recognize the important of intellectual property to these firms,
and respect the due process rights of its regulated entities.
Mandating On Demand Access to Proprietary Source Code Is Inefficient
and Will Not Assist the CFTC
Proprietary source code data is extremely difficult to understand
without its developer, and simply viewing the source code on demand
would not assist the CFTC in determining if automated trading
contributed to a market-wide event. Participants at the CFTC's
roundtable on June 10 noted that source code differs substantially from
``books and records'' requirements, in that proprietary source code
does not solely provide information on instructions. Instead, it tells
the story behind ``why'' and ``how'' a decision is made--much of which
is impossible to understand without recreating a scenario event with
the assistance of a developer.
Consequently, we fail to see how the CFTC's on demand access
requirements will actually assist the agency in its market surveillance
and investigative activities. In addition, the CFTC has not provided an
estimate of the costs for hiring qualified developers that could
actually analyze the proprietary source code, meaning that the CFTC
currently does not know how much it would even cost to review
information within its possession. We question the value of requesting
on demand access to proprietary source code when the CFTC may not even
have the resources to analyze it.
Regulation AT Increases the Potential for Cyberattacks and Threatens
the Security of Proprietary Source Code
As proposed, Regulation AT requires automated trading firms to
maintain source code repositories to manage source code access,
maintain copies of production code (as well as logs of changes to
production code), and include an audit trail to determine who made
changes to source code, under what circumstances, and why.\5\ Such
repositories must be available for inspection by the CFTC, the DOJ, and
potentially third parties.
---------------------------------------------------------------------------
\5\ See supra note 1 at p. 78824.
---------------------------------------------------------------------------
We strongly object to mandating automated trading firms to create
source code repositories under the terms established by Regulation AT,
especially when many companies already maintain such information.
Moreover, establishing the same across-the-board requirement
unintentionally makes those repositories ``cyber targets,'' giving
hackers and others a precise location for obtaining an automated
trading firm's most valuable intellectual property.
Moreover, there is substantial reason to believe that proprietary
source code data would not be safe in a government-mandated repository
or in the hands of the Federal Government. In the past year, we have
seen cyberattacks against the Internal Revenue Service,\6\ the Office
of Personnel Management,\7\ the Federal Deposit Insurance Company,\8\
and the Board of Governors of the Federal Reserve.\9\ Even the CFTC
suffered its own data breach in June of 2012, risking the security of
its employees' [S]ocial [S]ecurity [N]umbers.\10\ Given how incredibly
valuable proprietary source code data would potentially be in the hands
of a hacker, we believe that these data breaches are enough reason for
the CFTC to eliminate this element of Regulation AT.
---------------------------------------------------------------------------
\6\ Stephen Dinan, IRS hit by cyberattack, thousands of taxpayers'
information stolen, The Washington Times, May 26, 2015, available at
http://www.washingtontimes.com/news/2015/may/26/irs-hit-cyberattack-
thousands-taxpayers-informatio/.
\7\ Julianne Pepitone, Federal Data Breach: Can the Government
Protect Itself From Hackers?, NBC News, Jun. 5, 2015, available at
http://www.nbcnews.com/tech/security/federal-data-breach-can-
government-protect-itself-hackers-n370556.
\8\ Joe Davidson, FDIC cyberattacks included hit on former
chairwoman's computer, The Washington Post, May 11, 2016, available at
https://www.washingtonpost.com/news/powerpost/wp/2016/05/11/fdic-
cyberattacks-included-hit-on-former-chairmans-computer/.
\9\ David Murphy, House Committee Investigates Federal Reserve
Cyber-Attacks, PC Mag, Jun. 4, 2016, available at http://www.pcmag.com/
news/344991/house-committee-investigates-federal-reserve-cyber-attacks.
\10\ Silla Brush, CFTC Data Breach Risks Employees' Social Security
Numbers, Bloomberg News, June 25, 2015, available at http://
www.bloomberg.com/news/articles/2012-06-25/cftc-data-breach-risks-
employees-social-security-numbers.
---------------------------------------------------------------------------
Conclusion
While we appreciate the CFTC's need for timely access to data in
order to fulfill its market surveillance mission, the proprietary
source code requirements of Regulation AT are a bridge too far. By
mandating on demand access to proprietary source code and the
development of source code repositories, the CFTC not only compromises
established due process rights--it also adopts policy in direct
contradiction to other agencies of the U.S. Government and increases
the risk of cyberattack, all while not providing any tangible benefit
to the CFTC. Consequently, we believe that the proprietary source code
provisions of Regulation AT should be eliminated in their entirety.
Sincerely,
BSADThe Software Alliance;
Information Technology Industry Council;
International Swaps and Derivatives Association;
Futures Industry Association;
FIA Principal Traders Group;
Modern Markets Initiative;
Software & Information Industry Association;
U.S. Chamber of Commerce.
The Chairman. Thanks, Richard.
Mr. Vrabel, 5 minutes.
STATEMENT OF ANDREW VRABEL, J.D., EXECUTIVE
DIRECTOR, GLOBAL HEAD OF INVESTIGATIONS,
MARKET REGULATION DEPARTMENT, CME GROUP, INC.,
CHICAGO, IL
Mr. Vrabel. Thank you, Chairman Conaway, Ranking Member
Peterson, and Members of the Committee. My name is Andrew
Vrabel, I am the Global Head of Investigations at CME Group
where my teams are responsible in part for monitoring CME's
markets for aberrant market activity, including activity that
may be the result of automated trading strategies.
I am pleased to be here today to discuss the CFTC's
proposed rule on automated trading, referred to as Reg AT. As
many of you may be aware, automated trading strategies, or
algorithmic trading, is a source of considerable liquidity in
today's markets. These are strategies that are used by all
types of participants, from commercial end-users to market
makers, for price discovery and efficient risk management. But
like any automated process, there are inherent risks associated
with automated trading, and it is because of this, and CME
Group's vested interest in preserving the integrity of our
markets, that we have pioneered innovative market controls, and
have devoted substantial resources to protect the market from
potential aberrations and disruptions.
On top of these measures, which have proven highly
effective over time, Reg AT aims to mandate additional tools
and controls which we, unfortunately, think are broad,
unworkable, and could be counterproductive.
One particular area of Reg AT that we have concerns with is
a requirement that the exchanges implement tools and controls
that would prevent algorithmic traders from committing a
disruption in the marketplace. Unfortunately, this is an
unachievable standard. The most robust tools imaginable cannot
prevent all algorithmic trading disruptions, or all disruptions
in the markets, for that matter. Instead, we have proffered to
the CFTC, and we believe that the exchanges, if required to do
anything, should be to create tools and controls that would
mitigate rather than prevent the potential for an algorithmic
trading disruption in the markets.
Relatedly, Reg AT would also require the exchanges to
implement tools that would prevent traders from committing
compliance violations, most of which is already prohibited by
the Commodity Exchange Act, carrying criminal penalties, and is
also prohibited by CFTC's regs and exchange rules. The
exchanges have never been asked to mandate or create a control
that would guarantee universal compliance. In my experience,
people intent on violating the law will find a way to do so,
whether there is a control in place or not. It is for this
reason we have asked the CFTC to abandon this portion of Reg AT
in its entirety.
Reg AT also proposes that the exchanges review extensive
compliance reports to identify and remediate deficiencies with
risk controls, development, and testing standards. The weakness
with this particular approach is that the information contained
in those compliance reports is backward-looking. It will,
therefore, be stale the moment the exchanges have an
opportunity to review it. Beyond that, even if the exchanges
are asked to review these extensive compliance reports, in
order to do a substantive review of this type of information,
it will require highly specialized skills and knowledge that,
in our experience, is only possessed by the traders and firms
that created the algorithms themselves. The exchanges are not
suited, nor should they be, to perform this type of review on a
regular basis. Instead, we believe that the clearing member
firms that grant that particular participant access to the
market is in a strong position to receive from that trader or
trading firm a certification or a verification that they are in
compliance with the requirements of Reg AT. Then, if necessary,
the exchanges can ascertain the veracity of those
certifications and verifications.
One notable void in Reg AT with respect to market risk
controls is that Reg AT would mandate them for only a certain
subset of algorithmic traders; the so-called AT persons. The
reason for this void we believe is that the CFTC is primarily
intent on capturing a set number of new registrants. We believe
that registration is a secondary concern that, if at all,
should be addressed in a separate rulemaking. Instead, we think
that the goal of Reg AT should be on the creation of flexible,
not-mandated, market-wide risk controls that apply to every
algorithmic trader order that is submitted to the exchange.
We, therefore, submitted to the CFTC a proposal or an idea
of a two-tiered system of market risk controls. One tier of
risk controls could be administered by the algorithmic trader
themselves or the clearing firm that provides them access to
the marketplace, and another level of risk controls would be
administered by the exchange on a market-wide basis. These two
levels of control would provide the marketplace adequate,
necessary, and maximum protections from the potential of an
algorithmic trading disruption.
Last, you have heard from others and you will hear more on
source code. I will keep our comment here specific and limited.
The Commission has administrative subpoena authority under the
Commodity Exchange Act, and this affords participants due
process and a mechanism to preserve the confidentiality of that
information. Given the sensitivity of source code, we see no
reason why this approach shouldn't be adequate to the CFTC on a
going forward basis.
While the concerns we raise with Reg AT are significant, we
are hopeful that the CFTC continues to work with the
marketplace as they have to create a better and stronger rule.
On behalf of CME Group, I truly appreciate the opportunity
to be here, and I look forward to answering any questions that
you may have.
[The prepared statement of Mr. Vrabel follows:]
Prepared Statement of Andrew Vrabel, J.D., Executive Director, Global
Head of Investigations, Market Regulation Department, CME Group, Inc.,
Chicago, IL
Thank you, Chairman Conaway, Ranking Member Peterson and Members of
the Committee.
My name is Andrew Vrabel. I am the Executive Director of Global
Investigations at CME Group, which is part of our Market Regulation
division. I am pleased to present CME Group's views on the CFTC's
proposed rules to enhance regulation of algorithmic trading, known as
``Regulation AT.'' \1\
---------------------------------------------------------------------------
\1\ See Regulation Automated Trading, 80 Fed. Reg. 78824 (December
17, 2015); see also Public Staff Roundtable on Elements of Regulation
Automated Trading; Reopening of Comment Period, 81 Fed. Reg. 36484
(June 7, 2016).
---------------------------------------------------------------------------
Algorithmic trading, a type of automated trading, is a source of
considerable market liquidity today, facilitating price discovery and
efficient risk management. Yet, as with any automated process, there
are risks associated with algorithmic trading. To preserve and protect
the integrity of our markets from these risks, CME Group has pioneered
innovative risk controls and system safeguards, and continually employs
substantial human resources and technological capabilities for the
development, implementation and enhancement of these controls. In my
role, I see first-hand every day the sophisticated tools our exchanges
have developed and use to mitigate risks and protect our markets.
Regulation AT aims to mandate additional standards for protections
on top of the strong self-regulatory measures that our exchanges
already apply. We are concerned that much of Regulation AT's framework
is overly broad in scope, unworkable and could be counterproductive.
Our comment letters urge the CFTC to re-focus its proposal on the
essential area of flexible, not mandated, market risk controls that can
be tailored to the different business operations and roles of traders,
intermediaries and exchanges to best protect market integrity.\2\
Getting Regulation AT right is critically important to all who use our
markets.
---------------------------------------------------------------------------
\2\ See Letter from CME Group to CFTC, re: Notice of Proposed
Rulemaking on Regulation Automated Trading (RIN 3038-AD52), dated March
16, 2016. See Letter from CME to CFTC re: Reopening of Comment Period
re: Regulation Automated Trading (RIN 3038-AD52), dated June 24, 2016.
---------------------------------------------------------------------------
We identify the following key areas where the proposed rulemaking
needs to be substantially refined:
Regulation AT Should Not Require a Designated Contract Market (``DCM''
or ``Exchange'') To Prevent Algorithmic Trading Disruptions or
Algorithmic Trading Compliance Issues
Our primary concern is that Regulation AT appears to require
exchanges to prevent Algorithmic Trading Disruptions (``algorithmic
trading disruptions'').\3\ As CFTC Chairman Massad, observed when
approving the Proposal, no control--like no rule--can always prevent
disruptions and other operational problems that may arise from
algorithmic trading.\4\ We agree. As a result, we believe the
``prevent'' standard is unachievable. Instead, we urge the CFTC to
adopt a standard that requires exchanges to implement tools to mitigate
the effects of an algorithmic trading disruption. Any final rule text
and accompanying preamble should consistently articulate this
achievable objective for exchanges.
---------------------------------------------------------------------------
\3\ As used herein, ``Algorithmic Trading Disruption'' has the
meaning contained in the Proposal.
\4\ See Chairman Massad's Statement on November 24, 2015 (http://
www.cftc.gov/PressRoom/SpeechesTestimony/massadstatement112415).
---------------------------------------------------------------------------
Regulation AT also appears to require exchanges to prevent
Algorithmic Trading Compliance Issues (``algorithmic trading compliance
issues'').\5\ The Proposal would require exchanges to prevent an event
that causes a certain trader to operate in a manner that does not
comply with the Commodity Exchange Act or its rules and regulations,
rules of any exchange to which such algorithmic trader submits orders
through algorithmic trading, the National Futures Association rules,
the algorithmic traders own internal requirements, or the requirements
of the trader's clearing firm. We oppose this requirement for two
reasons. First, as discussed below, we believe Regulation AT generally
should not attempt to address compliance issues, but should instead
focus on deterring algorithmic trading disruptions. Second, imposing
this type of universal compliance obligation on DCMs is a major
departure from DCMs' traditional self-regulatory role Congress
envisioned, as reflected in the Core Principles.\6\
---------------------------------------------------------------------------
\5\ As used herein, ``Algorithmic Trading Compliance Issues'' has
the meaning contained in the Proposal.
\6\ See Section 5(d) of the Commodity Exchange Act.
---------------------------------------------------------------------------
Exchanges have never been asked to guarantee, or provide tools to
guarantee, the universal compliance by certain market participants
because such a requirement would be unrealistic and unreasonable.
People who intend on violating the law, Federal regulation, or rule of
a self-regulatory organization will find a way. Further, requiring an
exchange to guarantee compliance and prevent algorithmic trading
compliance issues could inadvertently create a safe-harbor in an
enforcement action. If a trader or firm subsequently is accused of
violating an exchange rule, CFTC regulation, or provision of the
Commodity Exchange Act, they could cite to an exchange's prior action
(or inaction) in defense of the allegations. This could significantly
undermine the effectiveness of an enforcement program and disciplinary
action.
What has proven effective is when exchanges operate in the self-
regulatory role Congress envisioned, which includes adopting and
enforcing rules of conduct related to trading. This serves to not only
penalize wrongdoers where warranted but also to deter other would-be
violators, whether they deploy algorithmic trading strategies or are
manual, point-and-click traders.
Requiring Exchanges To Review and Evaluate Annual Compliance Reports,
Policies, and Procedures and Enforce Compliance With Regulation
AT Is Unworkable and Beyond the Scope of an Exchange's Role
CME Group believes the Commission's proposed requirement that
certain algorithmic traders prepare and submit extensive annual
compliance reports to exchanges creates an unnecessary administrative
burden and substantial costs on all parties involved without providing
significant benefit to market integrity. There are many reasons that
support removing this aspect of the Proposal. First, the information
contained in the proposed compliance reports would be stale and not
representative of how a firm is currently addressing risks by the time
the reviews are submitted to an exchange. This renders the exchange
review substantially ineffective at preventing or mitigating a future
algorithmic trading event.
Second, exchanges are not practically in a position to assess an
algorithmic trader's compliance with Regulation AT or issue remediation
instructions. Assessing pre-trade risk controls designed to prevent or
even mitigate an algorithmic trading event will be dependent on
granular aspects of each algorithmic strategy, including inputs,
variables, and calculations that inform the strategy; system
architecture; operational infrastructure; and the skills and experience
of each trader, programmer, and developer. Not only is this information
highly sensitive and proprietary, but assessing these aspects will
require highly specialized skills and knowledge possessed only by the
traders or firms themselves.
Finally, under the Proposal, a DCM's review of a compliance report
and remediation instructions, if any, would seemingly endorse the
policies, procedures, and risk control parameters. This imposes
significant liability on the exchanges, and again, it potentially
creates a safe-harbor if an issue subsequently arises.
As the Commission is well aware, the CME Group exchanges rigorously
scrutinize the trading on our markets each day pursuant to our
commitment to protecting the integrity of our markets and complying
with existing DCM core principle requirements. We routinely monitor the
market and conduct exhaustive reviews of market events and other
conduct that might be considered disruptive. As a matter of practice,
if an algorithm malfunctions and causes a disruption in the market, we
conduct an in depth review of the participant's risk controls,
development and testing procedures, and compliance policies. We submit
that this is the proper role of an exchange and that the Commission
should not force exchanges to change these well-functioning mechanisms
as a result of Regulation AT.
To the extent verification of an algorithmic trader's compliance is
needed, we believe the clearing member that granted the trader access
to the exchange would be better positioned to accept a certification of
compliance as a condition precedent to granting that trader access to
the market.
We believe that a refined focus on the risk of market disruptions,
e.g., algorithmic trading disruptions, would enable the Commission to
establish a coherent and meaningful framework to address the risks
presented by algorithmic trading.
Pre-Trade Market Risk Controls Applied to all Algorithmic Traders
CME Group proposes that two layers of pre-trade risk controls would
apply to all algorithmic trading orders. The first layer would be
administered by either the algorithmic trader itself or its clearing
member that granted access to the exchange. The second layer would be
developed and administered by the exchange. Both layers of market risk
controls must be reasonably designed to mitigate the effects of
algorithmic trading disruptions, and set at a level of granularity
appropriately tailored to the underlying nature of the algorithmic
trading activity such that the risk mitigation standard is met.
CME Group believes that all algorithmic traders should be subject
to market risk controls. Proposed Regulation AT leaves a control void
for some algorithmic traders by only requiring market risk controls
for, the so-called ``AT Persons.'' \7\ The reason for this gap is that
the CFTC has focused primarily on attempting to capture a set number of
new registrants. We believe registration is a secondary concern--the
first aim of any rule in this area should be establishing a blanket of
market risk controls that applies to all algorithmic trading in a
consistent manner.
---------------------------------------------------------------------------
\7\ As used herein, the term ``AT Person'' has the meaning
contained in the Proposal.
---------------------------------------------------------------------------
We also believe the long-term effectiveness of any market risk
control framework is dependent upon market participants being afforded
flexibility to innovate as trading technology evolves. Accordingly, CME
Group's alternative framework would not mandate the use of any specific
market risk control measures. Rather, the rules would establish
acceptable practices that market participants can follow in order to
meet the applicable risk mitigation standard, consistent with the
Commission's history of establishing acceptable practices in other
areas of DCM core principle compliance.
The Source Code Open Access Requirement Raises Serious Confidentiality
Concerns
Other industry representatives will testify about the source code
issue. We agree with those who want to avoid undue, routine disclosure
of their intellectual property to government officials. This provision
raises serious concerns regarding the confidentiality of proprietary
information. Currently, if the Commission has reason to believe that it
needs access to a market participant's source code, it can obtain the
code subject to adequate confidentiality protections via the subpoena
process. We know of no reason why this approach should not be
satisfactory to the CFTC given the sensitivity of the information at
issue.
* * * * *
CME Group appreciates the opportunity to share our views on this
important rule proposal. We remain hopeful that the CFTC will continue
to work with all stakeholders to build a stronger and better rule.
I look forward to answering any questions you might have.
The Chairman. Thank you.
Mr. Ryan, 5 minutes.
STATEMENT OF MICHAEL G. RYAN, EXECUTIVE VICE
PRESIDENT AND GENERAL COUNSEL, TRADING
TECHNOLOGIES INTERNATIONAL, INC., CHICAGO, IL
Mr. Ryan. Good morning, Chairman Conaway, Ranking Member
Peterson, and Members of the Committee. My name is Mike Ryan,
and I am Executive Vice President and General Counsel of
Trading Technologies International. We are commonly known as TT
in the industry.
TT is an independent software vendor, or ISV, of
approximately 400 employees. Our headquarters are in Chicago,
and we have offices in most of the major financial centers
around the world.
TT licenses electronic trading systems that enable its
customers to trade on the 45 major electronic exchanges and
liquidity platforms globally. TT's products, which are housed
at our customers' facilities or hosted by TT in co-location
facilities, enable customers to trade using several automated
tools, pointing and clicking on a market, or by inputting and
utilizing their own proprietary algorithms to trade on
electronic exchanges.
As an ISV, I believe that TT provides a perspective on some
of the issues related to the proposed Reg AT that is different
than many of the other market participants represented here
today. In that regard, I appreciate the opportunity to testify
about some practical aspects of the regulation, and how it
might be implemented using technology in place today.
I will testify on the following three aspects of Reg AT:
definition of direct electronic access, or DEA; the need for
and propriety of a source code repository; and the testing
requirements related to electronic trading applications. These
are also addressed in my written testimony, which I ask to be
included in the record.
TT believes that the definition of DEA in Reg AT should be
clarified to indicate that there is no direct electronic access
where the orders are routed to an exchange through a
clearinghouse member's trading system, where pre-trade and
other risk controls can be controlled by such a member, even
where a trading firm or a third party maintains the physical
location of the systems. Without clarifying the language, the
definition of DEA will likely cause many single traders, small
trading groups, and even larger commercial companies like
energy firms and agricultural co-ops and merchants who hedge on
futures exchanges, all of whom trade through DCO members, and
are often substantial liquidity providers, to have to register
as floor traders. This will add layers of administrative
complexity to their businesses, without advancing the risk
oversight, because a DCO member's oversight is already fully
integrated into the available trading systems.
Proposed Reg AT also requires AT persons to maintain a
source code repository. Source code in a repository could be
subject to the inspection by both the CFTC and the DOJ, without
subpoena or any formal opportunity by a source code owner to
object to endeavor to restrict the manner or access or use of
the source code. TT believes these requirements in the CFTC and
DOJ's inspection authority are unnecessarily and
extraordinarily broad, not likely to provide helpful
information, likely amount to an unconstitutional taking of
individuals' property, and are generally unnecessary to achieve
the goal of the proposed regulations.
Source code of any trading firm or technology firm goes to
the essence of the value of such companies. It is highly
proprietary, trade-secret information that could expose the
fundamental aspects of a business that provide economic
advantage over competitors. Making such valuable intellectual
property readily available to the Commission is unnecessary to
fulfill the intent of the regulations.
Source code is also complicated, and the breadth of the
relevant code might be so expansive that it is hard to fathom
how it would be compiled, stored, or used effectively by the
Commission. A useful example of the underlying complexity of
seemingly simple commands appears in our first comment letter
to the Commission. Similarly, without the exact same market
data flowing through it, the myriad software applications
interacting together may not work the same. Replicating the
market data is likely a bigger problem than it seems because
trading programs often coalesce data in various ways, depending
on many factors.
Even in the unlikely scenario where the code of an
algorithm might be helpful, the subpoena power of the
Commission would be more than adequate to ensure that the code
is reviewed when truly necessary.
The last issue that I want to address is the testing
requirement set forth in Reg AT. TT believes that such testing
should focus on the output of an algorithmic trading system,
rather than the source code underlying such systems. As
proposed, source code underlying an algorithmic trading system
would be subject to substantial, highly prescriptive testing in
advance of a system's rollout, and continually thereafter. TT's
customers test algorithms every day, but the proposed language
of Reg AT seems to require a registered entity to test software
code as opposed to the finished product that the entity
developed or licensed. To the extent the entity licensed the
product from a third party, the source code is never available
for testing, and TT sees no reason why the code should be
required for testing. The reason why customers purchase turnkey
software is to utilize the product as a whole. Testing of
components of the source code is not consistent with that
motivation, and doesn't make achieving the goals of the CFTC
any more likely.
Thank you very much for the opportunity to testify before
you today. I am happy to address any questions you may have.
[The prepared statement of Mr. Ryan follows:]
Prepared Statement of Michael G. Ryan, Executive Vice President and
General Counsel, Trading Technologies International, Inc., Chicago, IL
Good morning Chairman Conaway, Ranking Member Peterson, and Members
of the Committee. My name is Mike Ryan and I am Executive Vice
President and General Counsel at Trading Technologies International,
Inc. (``TT''). TT is an independent software vendor (``ISV'') of
approximately 400 employees, we are headquartered in Chicago and have
offices in most major financial centers throughout the world. TT
licenses software trading solutions enabling its customers that include
the largest banks, commercial firms, hedge funds, proprietary trading
firms and other professional traders to trade on 45 of the world's
major electronic exchanges and liquidity platforms. TT's electronic
trading solutions, which are either housed at our customers' facilities
or hosted by TT in co-location facilities, enable TT customers to trade
using several automated trading tools, pointing and clicking on a
market, or by inputting and utilizing their own proprietary algorithms
to trade on electronic exchanges.
Most exchange-traded derivatives are now traded electronically, and
electronic systems that connect to exchanges, as well as algorithmic
trading, have introduced new risks to markets that were not present in
open-outcry environments. The daily increasing enhancements in
processing and connection technologies including housing trading
strategies on servers that are co-located with exchange matching
engines constantly accelerates the speed of trading to new levels and
amplifies these risks.
I am proud that TT has historically been in the forefront of
helping the exchange-traded derivatives industry manage risks
associated with electronic trading, by offering trading systems that
include comprehensive risk-management features that can be administered
by customers, but ultimately controlled by their futures commission
merchants--who provide the gateway to derivatives exchanges.
As an ISV, I believe that TT provides a perspective on some of the
issues relating to the proposed Regulation Automated Trading
(``Regulation AT'') that is different than many of the other market
participants represented here today. In that regard, I appreciate the
opportunity to testify before you and I hope that my testimony will
help the Committee understand some practical aspects of the regulation
and how it might be implemented using technology in place today.
We have raised some concerns about Regulation AT in other formats,
including through public comment letters \1\ and today I would like to
testify on the following three aspects of Regulation AT:
---------------------------------------------------------------------------
\1\ See attached Comment letters dated March 15, 2016 and June 24,
2016.
---------------------------------------------------------------------------
(1) The definition of ``Direct Electronic Access'' (``DEA'');
(2) The need for and propriety of a source code repository; and
(3) The testing requirements relating to algorithmic trading
applications.
(1) Definition of ``Direct Electronic Access''
TT believes that the definition of DEA in Regulation AT should be
clarified to indicate that there is no DEA where the orders are routed
to a Designated Contract Market through the trading/order routing
system of a member of a derivatives clearing organization (``clearing
house'' or ``DCO'') where the pre-trade and other risk controls are
able ultimately to be controlled by such member, including when a third
party maintains the physical location of the systems.
As drafted, Regulation AT defines DEA as an arrangement where a
person electronically transmits an order to an exchange without the
order first being ``routed through a separate person'' who is a member
of a clearinghouse to which the exchange submits transactions for
clearing. As proposed, any non-CFTC registered person engaging in the
trading of futures or swaps through DEA would be required to register
with the CFTC as a ``Floor Trader'' and be subject to a host of
prescriptive requirements--as would all persons designated as ``AT
Persons'' under the contemplated CFTC rules.
However the proposed definition of DEA is unclear as it does not
provide sufficient guidance as to what ``being routed through a
separate person'' means. The definition of DEA, as drafted, may suggest
that the order would also have to be routed through a system physically
controlled by the DCO member, but such physical control really has
nothing to do with actual control of risk management or the goal of
enhancing risk management of such orders. The ultimate ability to
exclusively control risk parameters is the relevant issue and that is
typically achieved remotely using software applications. For example,
using TT systems, a risk administrator is able to sit at his or her
desk in Chicago and set risk parameters for traders who may be
physically located anywhere in the world.
One suggestion for modifying the definition would be to add
``(including through a system physically managed by a third party
retained by such member to act on its behalf)'' after the phrase ``who
is a member of a derivatives clearing organization.'' Such
clarification would not diminish any DCO member's ability to control
risk, would reflect the manner by which such risk is often administered
today and the legitimate goal of the new regulation would still be
achieved.
Without clarifying the language, the definition of DEA will likely
capture within the definition of ``Floor Trader'' many single traders,
small trading groups and even larger companies like energy firms and
agricultural Co-ops and merchants who hedge on futures exchanges, all
of whom trade through DCO members and are often substantial liquidity
providers. The prescriptive requirements imposed on Floor Traders will
add layers of administrative complexity to their businesses and require
them to hire expensive compliance experts to their staffs. Yet, no
further risk oversight would be achieved because a DCO member's
oversight is already fully integrated into the available trading
systems.
(2) Source Code Repository and CFTC/Department of Justice Inspection
Authority
Proposed CFTC Regulation AT also requires AT Persons to ``maintain
a source code repository to manage source code access, persistence,
copies of all code used in the production environment, and changes to
such code.'' Source code in a repository would be subject to the
inspection by both the CFTC and the Department of Justice (``DOJ'')
without subpoena or any formal opportunity by a source code owner to
object or endeavor to restrict the manner of access or use of the
source code.
Like many in the industry and at least one CFTC Commissioner, TT
believes these requirements and the CFTC and DOJ's inspection authority
are unnecessarily and extraordinarily broad, not likely to provide
helpful information, likely constitutes an unconstitutional taking of
individuals' property and is generally unnecessary to achieve the goal
of the proposed regulations. TT recognizes that subsequent to the
publishing of Regulation AT, the CFTC indicated publicly that it did
not intend for the source code ``repository'' to be held by the
Commission, but TT's concerns remain.
a. Source Code Is Highly Proprietary and Typically Not Made Available
to Third-Parties
Except with respect to open source licensing arrangements, to my
knowledge source code is never licensed under any software license
agreement offered by any software provider including any ISV in the
futures or securities industries or any software firm such as Microsoft
or Google. The source code of any trading firm or technology firm goes
to the essence of the value of such companies. It is highly
proprietary, trade secret information that could expose the fundamental
aspects of a business that provide economic advantage over competitors.
Making such valuable intellectual property readily available to the
Commission is unnecessary to fulfill the intent of the regulations. The
CFTC is no less prone to potential cybersecurity attacks than other
government agencies and private companies, and two recently well-
publicized instances provide real life examples of why firms would be
gravely reluctant to turn over their proprietary source code to the
CFTC or any government agency except under the highest level of
protections. In each of these cases ex-government regulators--one from
the New York Federal Reserve Bank and the other from the Food and Drug
Administration-obtained and shared confidential information from their
ex-government employers with their then current private employers.
b. Source Code Is Complicated and the Potentially Relevant Amount of
Source Code Is Enormous
Frankly, it is doubtful that source code would readily be useful to
the Commission. One engineer's source code is rarely drafted in the
same manner as another engineer's and without proper documentation to
help decipher the code it is often meaningless. Even with proper
documentation it would often take insight from multiple engineers to
decipher the intent of the code and documentation.
The breadth of the relevant code might also be so expansive that it
is hard to fathom how it would be compiled, stored or used effectively.
Each layer of code is very relevant to how an algorithm might function.
Additionally, any number of different coding languages might be used in
each application and at each layer of software. TT, alone, uses over 30
different coding languages.
A useful example of the underlying complexity of seemingly simple
commands appears in TT's first comment letter to the Commission.
i. Market Data Adds Another Level of Complexity
Similarly, without the exact same market data flowing through it,
the myriad software applications interacting together may not work the
same. Replicating the market data is likely a bigger problem than it
seems because trading programs often coalesce data. Moreover, how and
when coalescing occurs may vary from moment to moment depending on many
factors such as network routers, firewalls, switches, server hardware,
operating systems and vendor software.
Multiplying the complexity exponentially, the Commission would
likely have to replicate market data at a particular moment from
multiple markets, because trading algorithms will typically use and
analyze data from many related markets, for example, equities and/or
stock options if trading stock index futures. So, even if the
Commission could recreate the prices in a market precisely as they were
disseminated by the exchanges or other relevant markets, the software
would likely act differently on different occasions despite using the
same market data.
c. Making Source Code Readily Available to Regulators Would Not Reduce
the Risks
Even assuming, for the sake of argument, that the Commission could
decipher the morass of relevant source code and the complexities of
dealing with market data, there is no compelling need to gain access to
the code because it adds very little to reduce the risks of algorithmic
trading.
The outcome of the trades are indisputable evidence of the actual
outcome of an algorithm and are already available in the form of the
trade data (orders, fills, quotes sent to and matched at each
exchange). Unusual results and/or repeated outcomes demonstrate the
intent of traders and usually no more is necessary to establish intent.
The published guidance from exchanges and the CFTC regarding market
manipulation cases recognizes that the culpability of a trader depends
upon the conduct of the trader over time. Single trades rarely, if
ever, give rise to the sort of culpability that would trigger a market
manipulation case. Rather it is a series of events and a pattern of
activity that might indicate a trader's intent or whatever the level of
culpability is required to prosecute a case. Similarly, the code of an
algorithm rarely if ever would prove the sort of culpability necessary
to prove a market manipulation case. Many perfectly legitimate
algorithms that are typically used to advance innocent trading
strategies might also be used nefariously by bad actors. For example,
TT and, I believe, all ISVs in the futures industry have functionality
in their trading systems that would stop a trader from executing a
trade with himself. TT's unimaginative name for this feature is ``avoid
orders that cross.'' Trading with oneself is prohibited on most
exchanges, so this sort of functionality is mandatory for most of TT's
customers. However, I understand that some alleged bad actors may have
utilized this functionality to manipulate markets. The alleged facts in
these cases are that a large order is entered on one side of the market
and then another entered to cross the first order. The first order
would be pulled from the market and the second order would be entered.
In this scenario, the alleged bad actor would have used an otherwise
perfectly legitimate trading tool to move the market toward the first
order, which was never intended to be filled. The functionality (i.e.,
algorithm) would not be helpful to prove manipulation in this case
because, as mentioned above, there is a perfectly legitimate use for
the functionality. Rather, only the alleged bad actor's behavior over
time could establish culpability.
Even in the unlikely scenario where the code of an algorithm might
be helpful, the subpoena power of the Commission would be more than
adequate to insure that the code is reviewed when truly necessary,
although we continue to question when that would ever be the case. In
fact, subpoenaing a written description of the intent of a trade or the
basic algorithm that describes the strategy should be sufficient for
most regulatory purposes. For example, a basic algorithm might be
described as simply as ``if market price = X then enter buy order at
Y.'' Such a simple description indicates the purpose of the algorithm
much more clearly and easily than the vast expanse of source code that
might otherwise be required under Regulation AT.
It is worth noting that over the 17 years that I have worked at TT
we have been contacted regularly by exchanges and governmental agencies
like the CFTC and DOJ who are investigating trading manipulation and
other cases. We are fortunate enough to have a large customer base that
depends upon TT software every day for their livelihood. Unfortunately
sometimes our customers are accused of violating regulations or rules
while trading with TT software. As a result, we are asked to help the
exchanges and government agencies understand how TT software works so
that they can better understand what a trader may have been doing. We
always cooperate to the extent possible by providing verbal
descriptions, written documentation and tutorials where appropriate. We
also receive subpoenas relating to these cases and, of course, comply
by producing information as required. Interestingly, despite such
regular interaction, we have never once been required to produce the
source code of any of our products. I believe this is the case because
source code is not a necessary or desirable piece of evidence that
might be used to avoid market disruption or prove or disprove bad acts
in the marketplace.
(3) Section 1.81 Testing Requirements Should Be Limited to Testing
Finished Products
The last issue that I want to address is the testing requirements
set forth in Regulation AT. TT believes that such testing should focus
on the output of an Algorithmic Trading system or software rather than
the source code underlying such systems or software, which would yield
no material benefit.
As proposed, source code underlying an Algorithmic Trading system
would be subject to substantial, highly prescriptive testing in advance
of a system's roll-out and continually afterwards.
a. Only Testing of the Finished Product Is Relevant to Regulation AT
Any software product provided by TT to any customer is always
tested internally by TT and is also available for the customer's
testing. TT expects that each customer performs appropriate testing
prior to utilizing the software in production environments, especially
when the product is an algorithm that might be used for trading. In
fact, TT offers testing environments that simulate market conditions to
facilitate such testing. Such functional testing of a product is
conducted to determine whether the output is consistent with the
intended purpose of the product. The intended purpose is typically
described in documentation provided by TT or any other developer of the
product.
An important distinction between the sort of testing that clients
perform every day on their software products and the proposed language
of Regulation AT seems to be that the proposed rules require a
registered entity to test software code (see, 1.81(a)(ii)) as opposed
to the finished product that the entity developed or licensed. To the
extent the entity licensed the product from a third party, the source
code is never available for testing and TT sees no reason why the code
should ever be required for testing. The reason why customers purchase
turnkey software is to utilize the product as a whole; testing of
components of the source code is not consistent with that motivation
and doesn't make achieving the goals of the CFTC any more likely.
If TT products do not work as expected, TT's customers demand
changes to the products and if TT fails to address their concerns, TT
risks losing the customer. In that way companies like TT are
effectively ``regulated'' by the market for software and systems.
We cannot envision any type of testing that would be appropriate
with respect to the code itself. If a line by line test of the code to
determine whether there are flaws in the way it was written is intended
by Regulation AT, it is unclear how any such review would provide any
more or better insight than a test of the product itself to see what
the outputs are.
Moreover, taking the extraordinary step of mandating testing or
review of source code is potentially very damaging to the source code
owner as indicated previously.
To the extent third party code is at issue, third party code simply
will not be made available to licensees. Neither TT nor any other
commercial software vendor that facilitates algorithmic trading
licenses source code to its customers and will not willingly do so. We
believe, respectfully, that any attempt to mandate third party vendors
to produce such code outside of existing legal procedures, such as
issuing subpoenas, would be an unprecedented overreach of governmental
power without any merit.
Thank you very much for the opportunity to testify before you
today. I am happy to address any questions you may have.
Attachment 1
March 15, 2016
Via Electronic Submission
Mr. Christopher J. Kirkpatrick,
Secretary of the Commission,
Commodity Futures Trading Commission,
Washington, D.C.
Re: Proposed Rulemaking on Regulation Automated Trading (Regulation AT)
Dear Mr. Kirkpatrick:
On behalf of Trading Technologies International, Inc. (``TT''), I
am submitting this letter to comment on the Proposed Rulemaking on
Regulating Automated (Regulation AT), specifically with respect to the
proposed definition of Direct Electronic Access and a requirement that
AT Persons be required to maintain a source code repository.
I. Background of TT
TT is an independent software vendor with approximately 400
employees located in its Chicago headquarters as well as offices in
most major financial centers throughout the world. TT licenses software
trading solutions enabling TT's customers to trade on 45 of the world's
major electronic exchanges and liquidity platforms. TT's customer base
includes the largest banks, commercial firms, hedge funds, proprietary
trading firms and other professional traders. TT offers many
sophisticated software applications for its customers' use such as its
new software as a service ``TT'' platform, as well as its legacy
applications such as X_Trader' and X_Trader' Pro,
X_Risk', ADL', AutotraderTM,
Autospreader' and exchange gateways. TT also hosts its
customer's infrastructure at facilities co-located or closely situated
with exchange matching engine technology.
II. Comments on the Proposed Rules
A. New Defined Term: ``Direct Electronic Access''
TT believes that the definition of ``Direct Electronic Access''
(``DEA'') should be clarified to indicate that there is no DEA where
the orders are routed to a Designated Contract Market through the
trading/order routing system of a member of a derivatives clearing
organization (``DCO'') where the pre trade and other risk controls are
controlled by such member, including when a third party maintains the
physical location of the systems.
As drafted, the proposed definition is unclear and does not provide
sufficient guidance as to what ``being routed through a separate
person'' that is a member of a DCO means. The definition of DEA, as
drafted, may suggest that the order would also have to be routed
through a system physically controlled by the DCO member, but such
physical control has nothing to do with the goal of enhancing risk
management of such orders. Control of the risk parameters is the
relevant issue and the definition of DEA should be altered to make
clear that where such control exists, there is no DEA.
The manner by which TT offers access to its trading system is
typical of independent software vendors in the futures industry and
although the methods of software distribution are diverse, a futures
commission merchant (``FCM'') has the ability to fully control the risk
management settings in every case.\1\ Currently TT offers its software
and services in four distinct ways:
---------------------------------------------------------------------------
\1\ Some FCMs choose not to utilize TT's risk controls and instead
rely on exchange provided risk tools, but the FCM may always control
risk through the TT system if it chooses to do so.
---------------------------------------------------------------------------
(1) traditional on-site licensing;
(2) hosted servers;
(3) shared hosted servers; and
(4) software as a service (``SaaS'').
On-site licensing involves licensing software that the customer
installs at its location. In this case the exchange gateway software
that connects the software with the exchanges is installed on servers
in a server closet at the customer's location and the client side
software, that generates the trading screen, would be installed on the
traders' workstations.
The last three methods of distribution help many FCMs achieve
significant cost savings by outsourcing order routing technology to
third parties without compromising on their control of risk parameters.
Where TT hosts the servers, TT effectively moves its customers'
server closets into a TT managed location. In this case TT oversees the
installation of all server software and maintenance of the applicable
data lines and network.
The shared hosted environment is similar in that TT hosts the
server software, but here end-users can easily clear trades through
multiple brokers because the physical infrastructure is shared and the
software enables such relationships.
The last method is as a fully hosted software as a service
offering. Here the software is installed on hosted equipment and the
trader interface is Internet based so there is no software installation
on the workstation other than minimal code used in the browser.
In each of the last three examples (hosted, shared and SaaS) the
servers on which the gateway software connects a trader to an exchange
sit at a TT managed location--not at a location managed by an FCM. TT
manages the technical aspects of the hardware, software and
telecommunication connections while the FCM's retain complete control
over user set-up and risk management tools that are provided as part of
the TT order entry systems.
The current definition of DEA doesn't appear to fully recognize the
relationship with such third party providers and should be clarified to
allow for these common situations. One suggestion for modifying the
definition would be to add ``(including through a system physically
managed by a third party retained by such member to act on its
behalf)'' after the phrase ``who is a member of a derivatives clearing
organization.'' Such clarification would not diminish any FCMs ability
to control risk and therefore the legitimate goal of the new regulation
would still be achieved.
As drafted, the definition of DEA will likely capture within the
definition of ``Floor Trader'' many single traders, small trading
groups and even larger companies like energy firms who hedge on futures
exchanges, all of whom trade through FCMs and are often substantial
liquidity providers. This will add layers of administrative complexity
to their businesses and require them to hire expensive compliance
experts to their staffs. Yet, no further risk oversight would be
achieved because an FCM's oversight is already fully integrated into
the available trading systems. The goals of the Commission will not be
achieved and the cost of compliance for these individuals and small
groups will often price them out of the market.
B. Source Code Repository
TT is concerned that the requirement under section 1.81(a), that
AT Persons ``maintain a source code repository to manage source code
access, persistence, copies of all code used in the production
environment, and changes to such code'' is unnecessarily and
extraordinarily broad, not likely to provide helpful information,
likely constitutes an unconstitutional taking of individuals' property
and is generally unnecessary to achieve the goal of the proposed
regulations. To be clear, TT strongly urges the Commission to remove
this requirement from the proposed regulation.
1. Source Code Is Highly Proprietary and Typically Not Made Available
to Third-Parties
Although it is unclear exactly what is meant by the term ``source
code'' in the proposed regulations,\2\ TT assumes that the term source
code generally means software expressed in a high-level language
intended to be intelligible by humans. Except with respect to open
source licensing arrangements, to our knowledge, source code is never
licensed under any software license agreement offered by any software
provider including any independent software vendor in the futures or
securities industries or any software firm such as Microsoft or Google.
The source code of any trading firm or technology firm goes to the
essence of the value of such companies. It is highly proprietary, trade
secret information that could expose the fundamental aspects of a
business that provide economic advantage over competitors. Making such
valuable intellectual property readily available to the Commission is
unnecessary to fulfill the intent of the regulations.
---------------------------------------------------------------------------
\2\ TT believes this term needs to be clarified if the Commission
insists on keeping this requirement. The Commission should also clarify
which source code is relevant. As written, it seems the Commission is
looking for a wide array of code that would touch all aspects of a
trading system.
---------------------------------------------------------------------------
TT is very concerned that despite numerous protections for
confidential information submitted to the CFTC, there are gaps in such
protections as well as too many possibilities to escape the CFTC's
control through unintentional means such as third-party
cyberattacks.\3\ If trade secrets \4\ are compromised, the trade secret
status would likely be lost along with a firm's economic advantage over
its competitors. Such an action would likely amount to an unlawful
``taking.'' \5\
---------------------------------------------------------------------------
\3\ Although TT appreciates that a party submitting information to
the CFTC may request that the information be treated confidentially
pursuant to the provisions of CFTC Rule 145.9, the Assistant Secretary
has discretion to grant or deny requests from requestors of non-public
information. Moreover, it is TT's understanding that Congress, and
other governmental authorities--both U.S. and non-U.S.--may also
request non-public information, and a submitter of non-public
information may not be advised of this request or outcome. Finally,
despite the best protections by the CFTC, cyberattacks and other
unauthorized intrusions, as well as the illegitimate actions of staff
acting contrary to their legal requirements, could compromise the
sanctity of non-public information submitted to the CFTC.
\4\ The Uniform Trade Secrets Act (``UTSA'') defines a trade secret
as:
information, including a formula, pattern, compilation,
program, device, method, tech-
nique, or process,
that derives independent economic value, actual or
potential, from not being generally
known to or readily ascertainable through appropriate means by
other persons who might
obtain economic value from its disclosure or use; and
is the subject of efforts that are reasonable under the
circumstances to maintain its se
crecy.
\5\ See, Ruckelshaus v. Monsanto Co., 467 U.S. 986 (1984).
---------------------------------------------------------------------------
It is also worth noting that much of the relevant source code
potentially used by AT Persons comes from third party software
providers like TT and others such as Microsoft. TT offers multiple
applications through which a trader could implement an algorithmic
trading strategy. Yet, TT never licenses its source code and would not
provide it to its customers in any circumstances. TT is not alone in
this position. For example, many traders utilize commonly available
tools such as Microsoft Excel' to implement their trading
algorithms. They might develop the algorithm in Excel and connect Excel
to a commercial trading application like TT. Based on the movement of
the market and the algorithm, orders might be triggered as a result of
actions implemented in Excel. TT has not contacted Microsoft, but we
suspect that software companies like Microsoft would not be willing to
divulge their source code either.
2. Source Code Is Complicated and the Potentially Relevant Amount of
Source Code Is Enormous
Even if the Commission was able to overcome the legal impediments
relating to forcing disclosure of trade secrets, it is doubtful that
such information would readily be useful to the Commission. One
engineer's source code is rarely drafted in the same manner as another
engineer's and without proper documentation to help decipher the code
it is often meaningless. Even with proper documentation it would often
take insight from multiple engineers to decipher the intent of the code
and documentation.
The breadth of the relevant code might also be so expansive that it
is hard to fathom how it would be compiled, stored or used effectively.
Each layer of code is very relevant to how an algorithm might function.
Additionally, any number of different coding languages might be used in
each application and at each layer of software. TT, alone, uses over 30
different coding languages.
In the Excel example above, Excel interacts with TT software, which
includes and interacts with multiple layers of applications and
libraries, which interact with other layers of messaging software and
other systems on down the line until the operating system is utilized.
In order to recreate the intent of the algorithm through the source
code, the Commission would need to compile the code in the same
environment where it was set up, including the same version of each
layer of code and the same version of the exchange's software. Short of
that, it would likely not work the same as it was intended or as it
might have worked at a moment in time. The code behind each layer of
production software changes often. New releases occur regularly (often
monthly) plus smaller code patches are released in between. Assuming
there will always be a time lag between trading activity and when an
investigation is started, the Commission would need to be able to
recreate the exact version of code including revisions and interim
patches of each layer of code that was in use at the point in time of
the trade. Each layer of code interacts and depends on the other layers
to work as planned. A single version of a single layer of such code
could be millions of lines; a repository of all possible code versions
going back in time for years would be much, much larger and impose an
immeasurable burden on the industry.
As an example, consider the following simple algorithm that is
depicted in TT's ``Algo Design Lab'' application:
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
The logic of this simple algorithm is as follows: (1) submit
a limit order for the given instrument and quantity at a price
equal to the bid; (2) when the bid price changes, re-price the
order to be the same as the bid.
The simple image above belies the complexity and enormous amount of
source code that generates this image and effects the strategy. One can
imagine the image above as a depiction of the highest level of code
used to effect the strategy. The strategy itself would run on a server
application in the TT environment but it would also touch and be
dependent upon almost every part of the TT trading system. The way that
the algorithm subscribes for prices, downloads contract information,
and routes orders is specific to the way that the underlying components
have implemented and exposed this functionality. So technically, one
would need all of the TT system software in order to attempt to
reproduce its behavior. Hundreds of applications and libraries within
the TT system itself are essential components and the source code would
likely add up to millions of lines of code for the TT applications
only. If the trader used Excel for the algorithm, the Microsoft code
would also add millions of lines of code most likely. Add to that the
many other third party applications involved in the process for price
feeds, analysis, messaging, the operating systems of the workstation
and the servers among other layers of code and there would be an
immeasurable morass of code that, in theory, would need to be stored
and made available to the Commission.
This is a very simple example. The complexity of this simple
example is magnified dramatically in a more complex and realistic
example, not to mention situations where multiple algorithms are in
question.
3. Market Data Adds Another Level of Complexity
Similarly, without the exact same market data flowing through it,
the myriad software applications interacting together may not work the
same. Replicating the market data is likely a bigger problem than it
seems because trading programs often coalesce data and how and when
coalescing happens may vary from moment to moment depending on many
factors such as network routers, firewalls, switches, server hardware,
operating system, vendor software, coalescing and conflation factors.
Multiplying the complexity exponentially, the Commission would likely
have to replicate market data at a particular moment from multiple
markets, because trading algorithms will typically use and analyze data
from multiple related markets, for example, equities and/or stock
options if trading stock index futures. So, even if the Commission
could recreate the prices in a market precisely as they were
disseminated by the exchanges or other relevant markets, the software
would likely act differently on different occasions despite using the
same market data.
Consuming market data is like drinking from a fire hose. The basic
process by which TT delivers market data to clients is as follows:
1. TT receives a market data update from an exchange (e.g., bid
price = 100).
2. TT broadcasts the update to other servers in TT's trading
network.
3. The TT system notifies the client application.
4. TT receives another market data update (e.g., bid price = 101).
If the client has finished processing the last update, the
TT system notifies the client of the update. If not, the
system waits--and then delivers it when they are ready.
(i) While waiting, the TT system might receive thousands more
updates. TT
conflates this data, meaning it overwrites the values
that will be delivered
to them when appropriate. This is done because no one
wants to receive
``old'' market data updates.
(ii) The time it takes a client to process an update depends on a
variety of fac-
tors, including system load, network load and operating
system scheduling.
This makes it extremely difficult to determine the exact
price update that
the client might process to re-price the order. So even
with access to iden-
tical system software, intermediate network and server
infrastructure and
the algorithm, one would likely be unable to reproduce
the exact behavior
of an algorithm for most liquid markets.
Even assuming, for the sake of argument, that the Commission could
make heads or tails of the morass of relevant source code and the
complexities of dealing with market data, there is no compelling need
to gain access to the code because it adds very little to reduce the
risks of algorithmic trading. The outcome of the trades are
indisputable evidence of the actual outcome of an algorithm and are
already available to every exchange and the Commission in the form of
the trade data (orders, fills, quotes sent to and matched at each
exchange). Unusual results and/or repeated outcomes demonstrate the
intent of traders and usually no more is necessary to establish intent.
Even where more is necessary, the subpoena power of the Commission
would be more than adequate to insure that the code is reviewed when
truly necessary, although we continue to question when that would ever
truly be necessary. In fact, subpoenaing a written description of the
intent of a trade or the basic algorithm that describes the strategy
should be enough without even delving into source code. This would
amount to a document detailing the logic of the algorithm that would
direct the trade (e.g., ``if market price = X then enter buy order at
Y.'')
The extraordinary burdens described above, the potentially illegal
or overly damaging intrusion into proprietary source code incurred by
trading firms and their software suppliers and the questionable benefit
of obtaining any further code far outweigh any benefit from acquiring
the code.
* * * * *
TT is very concerned that, as drafted, Regulation AT will not
positively enhance the existing regulatory regime for automated
trading. We addressed two aspects of the proposal about which
independent software vendors like TT seem to have good insight. We are
more than willing to provide additional input about these matters or
others matters within our expertise.
Please contact me at (312) 476-1081 if you have any questions or
seek additional information.
Respectfully submitted,
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
Michael G. Ryan,
Executive Vice President and General Counsel.
Attachment 2
June 26, 2016
Via Electronic Submission
Mr. Christopher J. Kirkpatrick,
Secretary of the Commission,
Commodity Futures Trading Commission,
Washington, D.C.
Re: Proposed Rulemaking on Regulation Automated Trading (Regulation AT)
Dear Mr. Kirkpatrick:
I am submitting this letter on behalf of Trading Technologies
International, Inc. (``TT''), to respond to certain issues raised
during the June 10, 2016 public roundtable discussion regarding
Regulation AT. Specifically, TT would like to address proposed testing
requirements for Algorithmic Trading (as defined in Regulation AT)
systems and software.
Section 1.81 Testing Requirements Should Be Limited to Testing Finished
Products
TT applauds all reasonable regulatory initiatives to ensure that
market integrity is enhanced through testing of Algorithmic Trading
systems and software. TT believes that Section 1.81(a) of Regulation
AT, which would impose certain development and testing requirements for
Algorithmic Trading systems, should be clarified so that it can be
implemented in the most practical and useful manner. TT believes that
such testing should focus on the output of an Algorithmic Trading
system or software rather than the source code underlying such systems
or software, which would yield no material benefit.
TT Performs Regular Tests on the Software It Licenses
As a third party software vendor, TT's view of the proposed rules
may be different than entities that are directly regulated by the
Commodity Futures Trading Commission (``CFTC''). TT practices commonly
accepted development and testing practices and only licenses systems
and software that have been subject to a rigorous testing protocol.
This protocol includes:
testing in a development environment separate from a
production environment;
back testing and stress testing;
documenting the specifications and requirements of source
code; and
retaining of source code in an environment where changes are
recorded.
TT's practices are consistent with the requirements the CFTC
proposes to be adopted by AT Persons. In fact, other independent
software vendors in the futures world, and most likely all companies
that license software and systems, such as Microsoft, Adobe, Google,
etc., already follow those practices every day in an effort to produce
software and systems that perform as intended.
Only Testing of the Finished Product Is Relevant to Regulation AT
As TT indicated in its previous comment letter and during the
roundtable discussion on Regulation AT, in no event does TT or any
software vendor in any industry provide access to source code as part
of its license grant to its customers.\1\ But, any software product
provided by TT to any customer is always available for the customer's
testing and TT expects that each customer performs appropriate testing
prior to utilizing the software in production environments. In fact, TT
offers testing environments that simulate market conditions to
facilitate such testing. Such functional testing of a product is
conducted to determine whether the output is consistent with the
intended purpose of the product. The intended purpose is typically
described in documentation provided by the developer of the product.
---------------------------------------------------------------------------
\1\ The exception to this statement would be vendors who license
open source software.
---------------------------------------------------------------------------
If TT products do not work as expected, TT's customers demand
changes to the products and if TT fails to address their concerns, TT
risks losing the customer. In that way, companies like TT are
``regulated'' by the market for software and systems.
An important distinction between the sort of testing that clients
perform every day on their third party software products and the
proposed language of Regulation AT seems to be that the proposed rules
require a registered entity to test software code (see, 1.81(a)(ii)) as
opposed to the finished product that the entity licensed. To the extent
the entity licensed the product from a third party, the code is never
available for testing and TT sees no reason why the code should ever be
required for testing. The reason why customers purchase turnkey
software is to utilize the product as a whole; testing of components of
the source code is not consistent with that motivation and doesn't make
achieving the goals of the CFTC any more likely.
We cannot envision any type of testing that would be appropriate
with respect to the code itself. If a line by line test of the code to
determine whether there are flaws in the way it was written is intended
by Regulation AT, it is unclear how any such review would provide any
more or better insight than a test of the product itself to see what
the outputs are.
Moreover, taking the extraordinary step of mandating testing or
review of source code is potentially very damaging to the source code
owner as indicated in TT's prior comment letter, several other comment
letters and verbal comments to the CFTC.
To the extent third party code is at issue, third party code simply
will not be made available to licensees. Neither TT nor any other
commercial software vendor that facilitates algorithmic trading, such
as Microsoft through its products like Excel',\2\ licenses
source code to its customers and will not willingly do so.\3\ We
believe, respectfully, that any attempt to mandate third party vendors
to produce such code outside of existing legal procedures, such as
issuing subpoenas, would be an unprecedented overreach of governmental
power without any merit.
---------------------------------------------------------------------------
\2\ Excel is a registered trademark of Microsoft Corporation.
\3\ As indicated in TT's original comment letter, TT has not been
in contact with Microsoft, but we would suspect that commercial
software companies like Microsoft would not be willing to divulge their
source code.
---------------------------------------------------------------------------
Whether a Product Is Licensed from a Third-Party Does Not Change the
Appropriate Testing Procedures
Some have argued that, absent a requirement by the CFTC, an FCM or
other regulated entity would have no control over how third party code
might be tested, monitored or altered to address issues that may arise
in an algorithmic trading environments. When looked at from a practical
perspective, such an objection has no merit.
If an FCM was to test an algorithmic trading system it would run
the algorithm in a simulated environment to determine what the outputs
of the system would be under various market scenarios. If a problem was
detected by a tester or compliance specialist, that person would turn
off the algorithm,\4\ contact the developer of the algorithm, point out
the problem and ask the developer to fix the problem. The developer
would then review the code that implemented the algorithm and make any
appropriate adjustments. Then the algorithm would be retested in the
simulation environment and the process might repeat itself until the
algorithm was determined to be running as planned. The process would be
the same if the problem was discovered in a production environment--the
algorithm would be turned off and it would be fixed by the developer
and then tested in a simulation environment before being used again in
a production environment. If the algorithm had been developed in-house
at an FCM that developer might sit down the hall from the tester or the
compliance specialist. If the algorithm was developed by a third party,
the developer would be a phone call away. The testing would be the same
and the resolution of any issues would be the same.
---------------------------------------------------------------------------
\4\ Mandating such a kill switch seems prudent.
---------------------------------------------------------------------------
* * * * *
TT, respectfully, remains very concerned that, as drafted,
Regulation AT will not positively enhance the existing regulatory
regime for automated trading. We appreciate the opportunities afforded
to us to comment on Regulation AT and are more than willing to provide
additional input about these matters or others matters within our
expertise.
Please contact me at (312) 476-1081 if you have any questions or
seek additional information.
Respectfully submitted,
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
Michael G. Ryan,
Executive Vice President and General Counsel.
The Chairman. I want to thank our witnesses.
The chair would remind Members they will be recognized for
questioning in order of seniority for the Members who were here
at the start of the hearing. After that, Members will be
recognized in order of arrival. I appreciate Members'
understanding.
And with that, I will recognize myself for 5 minutes.
Mr. Wood, under the broad definitions provided in Reg AT,
and the ubiquitous use of automated trading in the market, what
percent of market participants do you think would qualify as AT
persons?
Mr. Wood. Thank you for the question, Mr. Chairman. We have
seen an adoption of automated trading in the futures markets
that has become prevalent in many ways. Reg AT has tended to
focus on a particular type of participant. The argument that
FIA has made is automated trading is used by a lot of different
types of market participants in one form or another. There are
people who use highly sophisticated systems that they develop
themselves, but there are people who also increasingly use
systems that are provided by software vendors or by the FCM
community for them to execute more efficiently within the
futures markets.
So trying to quantify how much of the market is truly
algorithmic in nature, it is going to actually be a very high
percentage. And I would actually defer to Andrew Vrabel here,
because they use metrics on their orders going into the CME
Globex platform that actually highlights whether an order is
manually generated or automated.
The Chairman. Mr. Vrabel, do you have that number off the
top of your head?
Mr. Vrabel. The number off the top of my head is that, in
our agricultural markets, roughly 50 to 53 percent of total
volume comes from automated strategies. And as I had mentioned
before, every type of market participant, not every participant
but every type of participant uses some form of automated
trading strategy or another, whether it be, as Greg said, a
highly complicated algorithm or a simple auto spreader
available through any ISV or software contractor.
The Chairman. Mr. Gorelick, some would argue that the CFTC
should use Reg AT to involve itself in the inner workings of
algorithmic trading systems to anticipate problems. Is it
remotely possible that the CFTC would be able to anticipate
problems in the market by studying source code?
Mr. Gorelick. I would say it is highly implausible. I was
trying to think of an analogy that would help to sort of
explain what this test would be, and it is tricky for a variety
of reasons but, the best I can come up with, it is sort of like
taking a car apart, and taking all the pieces and studying them
in excruciating detail to try and predict traffic patterns. It
is sort of relevant, if you want to figure out how to build a
car it is very useful, but it is not the best way to measure
traffic patterns. What you really need to do is go out there
and measure. And that is what we are trying to do. By looking
at source code, with millions of lines, with lots of
interactions that are very dependent on the specific market
data that is coming in at a particular time, that is very
dependent on the hardware that it is running on, the network
characteristics, it would be very difficult to determine future
market events by studying source code.
The Chairman. Let me ask you, some of you mentioned this
two-tiered level of pre-trade risk controls. Are there barriers
to those being implemented now on a voluntary basis? Mr.
Vrabel, is that scheme already in place, the two-tier that you
talked about?
Mr. Vrabel. Yes, the scheme is largely already in place.
The exchanges have comprehensive market integrity controls that
have been in place for years. By and large, every market
participant has some degree of risk controls.
The real question under Reg AT is whether those risk
controls are adequate, given the scope and scale of that
particular algorithmic trader. But yes, in our experience, I
have not encountered a firm that has zero risk controls in
place.
The Chairman. Well, I am talking about that two-tiered
system that you have mentioned where, obviously, the trader
should have controls in place, the FCM should have controls in
place, the DCM should have controls, is there something
preventing the SROs from actually requiring that to be in place
already?
Mr. Vrabel. There is not, and the two-tiered model is what
we have offered instead of a more complicated structure, for
example, portions of Reg AT lead one to believe that there
could be as many as three tiers. The exchange has to have an
appropriate level, the clearing firm has to have a level of
protection, and the algorithmic trader has to have a level of
protection. And, redundant measures like that we not believe
are----
The Chairman. Okay. The Ranking Member mentioned 15 to 30
issues a year in which that happened. Are those numbers going
up or down as a result of the array of controls that self-
imposed has had? Is that getting better or worse?
Mr. Vrabel. My understanding of that 15 to 30, or 15 to 20
number, wasn't an analysis of the number of malfunctions that
have caused a market disruption. Instead, it was based on a
calculation of markets that have had price swings of a certain
degree over a period of time. One important thing to note is
that the preamble to Reg AT notes significant market events
resulting from algorithmic trading, and the only one in CFTC-
regulated markets is the May 6, 2010, flash crash that the CFTC
addresses there. And since that point in time, there have been
12 billion trades on CME's markets.
Now, obviously, we have had other small events, but the
risk protections that are in place we believe are adequate, and
have been adequate to address those.
The Chairman. Yes. Thank you.
The Ranking Member, 5 minutes.
Mr. Peterson. Thank you, Mr. Chairman.
Does the Division of Market Oversight have subpoena
authority? Does anybody know?
Mr. Wood. I believe the Division of Enforcement at the CFTC
does.
Mr. Peterson. The Enforcement Division has subpoena power?
Mr. Wood. Yes.
Mr. Peterson. Is there a Division of Market Oversight?
Mr. Wood. I believe in this circumstance, the various
divisions at the CFTC would work together if they needed to
take this course of action.
Mr. Peterson. I guess, as with a lot of the stuff that we
found out as we went through all of this that until you get
into enforcement, sometimes you can't find out anything about
what is going on with these things, unless you get into an
enforcement situation. Is that right?
Mr. Wood. I believe so, yes.
Mr. Gorelick. Ranking Member Peterson, that is a good
question. What I have suggested is that the best way to figure
out what is going on with an algorithm or with a particular
trading strategy is to really look at the data, at the orders
and the fills and the cancellations, and all of the audit trail
information that is readily available to the exchanges and to
the CFTC. That is going to give you a much better idea of what
is going on with the trading strategy than sort of a
preemptive, extraordinary code review.
Mr. Peterson. Well, can they get that information?
Mr. Gorelick. Absolutely. I think that is where ongoing
investment is warranted. Right now, one of the great advantages
of electronic trading and of the electronification of our
markets has been that there is now a complete audit trail
available of every message that is sent back and forth from the
exchange by traders and everywhere else. And that allows sort
of an unprecedented level of transparency into what is going on
in the markets. Regulators need to continue to develop their
skills and their technologies and their toolsets to conduct
that analysis, but right now the exchanges already have
terrific surveillance capability built on these audit trails,
and the CFTC has an opportunity to piggyback on that as well.
Mr. Peterson. Yes. So they don't have enough resources to
do as much of this as they should, is that----
Mr. Gorelick. Yes, I am not sure, this is something that
has come up at the Technology Advisory Committee over the
years. I think that is really more of an issue for Congress and
for the CFTC to talk about resource-wise. I certainly think
that it is an area of focus to make sure that they are
investing appropriately in both their technology and in their
analytical capabilities. I think that is going to be a much
better, more efficient investment than in source code review
capabilities.
Mr. Peterson. Are they doing that?
Mr. Gorelick. I believe they are, yes. Whether it is
enough, whether it is sufficient, whether they could do it
better I am not positive about.
Mr. Peterson. Yes, with a lot of these different issues, it
seems like people get more tied up in all the enforcement stuff
and they miss the trees for the forest. When I was on the
Intelligence Committee, I had a similar issue with the FBI, who
were not doing what they should be doing, because they were
more worried about enforcement than they were trying to figure
out what was going on. Do you think that the CFTC has figured
this out and is moving in the right direction?
Mr. Gorelick. I would say that they are moving in the right
direction. This has clearly been an area of focus and a lot of
discussion at the Technology Advisory Committee. I do think
though that this is an area that probably needs more focus. It
would be a more fruitful avenue to pursue than the source code
provisions in Reg AT.
Mr. Peterson. Yes, sir.
Mr. Ryan. If I may add something. One thing that I want to
note is that I have been at TT for about 17 years, and we often
get contacted by the CFTC, sometimes the Department of Justice
in an enforcement action and the like, and asked questions
about our technology. The questions are how does it work, can
you give us some documentation to explain how it works in this
scenario or that scenario. And we are always there to answer
those questions. We are always happy to do that. But never once
in my 17 years at TT have we ever been required to provide
source code.
So it just seems to me, the source code avenue is an avenue
that is not likely to help in this analysis.
Mr. Peterson. Well, Mr. Chairman, maybe the Committee
should look into that and find out more about it.
The Chairman. Well, I do think the proprietary source code,
the property-taking under the Constitution, they are troubling
that they can simply request that. It is apparently on
everybody's mind.
Do you yield back?
Mr. Peterson. Yes.
The Chairman. The gentleman yields back.
Mr. Goodlatte, 5 minutes.
Mr. Goodlatte. Mr. Chairman, thank you for holding this
important hearing. And thank you to the panel for being with us
today.
While there may be a number of significant concerns with
this rule, I would like to zero-in on one particular aspect
that has been mentioned several times already today in this
issue of source code repository.
It seems that through this rule, the CFTC has decided to
use its legitimate authority to access books and records as a
means to illegitimately force trading companies to turn over
valuable intellectual property without first obtaining a
subpoena. And I am disturbed by this decision and, therefore, I
have a few questions for the panel.
First, how difficult is it currently for the CFTC to obtain
a subpoena for a source code, and who at the CFTC can authorize
that type of action? Anybody answer that? None of you know?
Mr. Vrabel.
Mr. Vrabel. I am by no means an expert on the
administrative procedures, but my understanding is that an
administrative subpoena has to be approved by all
Commissioners.
Mr. Goodlatte. All the Commissioners, right. But
nonetheless, if they have a desire to subpoena documents from
any of the companies that are affected by this, they have the
ability to do that.
Second, how will this type of unfettered access to source
code be beneficial to the CFTC? Would this reduce risk to the
system, or does CFTC currently retain staff able to easily
understand and interpret the code? Mr. Gorelick, you have
commented on this a bit already. Could you elaborate on that?
Mr. Gorelick. I did. No, I don't think the CFTC has the
capability to routinely evaluate large amounts of source code.
The software programs are written in lots of different
programming languages, they are very extensive, they are
often--really the best way to understand exactly the inner
workings is to talk to the software developers involved in
writing that code.
As I referenced, I think it would take an army of software
developer regulators, and I am pretty sure that the CFTC does
not presently have that capability.
On a one-off basis in connection with an enforcement action
with a very narrow set of actions, it may be useful. And I am
not aware of any circumstances in which the CFTC thought they
needed source code for that purpose and were unable to get a
subpoena. What we are really talking about is a due process
concern. The times in which the CFTC would need to access
source code, they can get a subpoena, they can use the subpoena
process, and there will be adequate protections built in.
Mr. Goodlatte. We are also talking about a security concern
here, aren't we? I mean isn't this something similar to the
Apple-FBI dispute where the FBI wanted to compel Apple to
unlock something? Here, they are asking for the authority to
have automatic access to it, and once they have automatic
access to your source code, what are the risks involved that it
will fall into the wrong hands; either a competitor or a
criminal, or even a foreign government that might use it to
manipulate the market?
Mr. Gorelick. Firms like ours, firms that use automation in
the markets, generally hold their source code to be very
important to their business. They take their own precautions to
protect their source code. They store it in secure ways, they
secure their network, they have the cybersecurity defenses,
they have authority about who is allowed to access it and under
what circumstances. Once it is out of a particular firm and in
the hands of sort of any third party, the firm loses the
ability to manage those controls. And as we have seen, there is
risk that if the information is attacked by third parties in
some type of a cybersecurity attack, or simply that information
gets out there. People change jobs, it moves from one place to
another, and it could really have a negative impact from a
competitive standpoint. So generally, the issue is who is able
to have the types of controls that are required.
Mr. Goodlatte. Right, and it exponentially could increase
the vulnerability of that source code to discovery by
individuals who shouldn't have access to it. You have to worry
about yourself. Businesses are hacked all the time.
Mr. Gorelick. Right.
Mr. Goodlatte. Government agencies, retailers, credit card
companies, the list goes on and on of people who have had
important information hacked, including, in some instances,
their very source codes. So if this is in the hands of a
government agency, that wouldn't inspire your confidence that
your vital piece of how your business operates will be better
protected. It will be more vulnerable, will it not?
Mr. Gorelick. I think that is the case whenever it is
outside of our hands. A government agency would just be like
any other third party from that regard that we don't control
who is able to look at this information, how they are able to
get it, what security they have put in place. We only like to
have a very small group of people inside our firm who are
responsible for those controls, and not more broadly open
access.
Mr. Goodlatte. Thank you very much.
Thank you, Mr. Chairman.
The Chairman. The gentleman yields back.
Mr. Scott, 5 minutes.
Mr. David Scott of Georgia. Thank you, Mr. Chairman.
I certainly applaud the CFTC's overarching efforts to bring
the futures markets' regulatory regime into the 21st century.
And as a matter of fact, it was almost a year ago to the day,
in July 2015, that the Chicago Mercantile Exchange, CME,
shuttered the last of its trading pits after 167 years of
operation. So it makes a great deal of sense that the CFTC move
on these rules now that trading pits are officially a thing of
the past. However, when I heard that the CFTC would require
people affected by this rule to not only retain all copies of
their source code, but also make it available to the CFTC at
their demand, without a subpoena. It caused me great alarm.
So I wanted to first ask the panelists if each of you drew
the same conclusion that I have, in that the Reg AT being
unprecedented, and that it could demand source code without a
subpoena. Everybody agree?
Mr. Ryan. Yes, I will address that first, if I may,
Congressman.
From our perspective, TT and the others in the industry are
always willing and able to help with useful information, when
that useful information is available. The biggest concern, in
addition to the security aspect of handing over the source
code, is that it is unlikely that in any scenario it is
actually going to be useful. I gave an example on one of the
comment letters that I issued to the CFTC that had an image of
a very simple algorithm. It was just an image where you entered
an order at the best bid on the market, and if it moved, you
went with it. It is an image that is maybe about this big.
Mr. David Scott of Georgia. Yes.
Mr. Ryan. Okay. The amount of code that goes into
generating that image and then executing the order that that
image tries to put into place is incredibly expansive. I mean
we are talking like millions of lines of code, ultimately, to
effect that simple of a process.
Mr. David Scott of Georgia. And let me get rather specific
here for a moment. And, Mr. Vrabel and Mr. Gorelick, you
touched on some of this, but do you think that the CFTC should
have a definition of automated trading that separates out
automated execution from algorithmic strategies that drive
trading decisions? My worry stems from the CFTC forcing
automated traders to share their algorithmic strategies or
secret recipes with the CFTC, whenever the CFTC wants it. Now,
couldn't a better solution to this problem be that if the CFTC
separated out those two definitions, we could better protect
these secret recipes?
Mr. Vrabel. Respectfully, Congressman, I don't know if that
will adequately address the issues. In my experience when our
teams have reviewed and monitored disruptions in the markets
resulting from automated trading, algorithmic trading, or
simple devices like order routers, we see as many malfunctions
that cause disruptions in the markets from very simple devices
as we do from highly complex ones.
Mr. David Scott of Georgia. Yes.
Mr. Vrabel. So from my perspective, if there is going to be
risk controls that are addressing automated trading, it would
need to include the algorithmic, highly complex, and the very
simple order routing automated strategies.
Mr. David Scott of Georgia. All right, and determining the
boundaries of a particular group of market participants is
always a problem when trying to define the scope of regulation.
I serve on the Financial Services Committee, and we have that
problem all the time. But oftentimes we deal with this problem
by regulating the activity that is being done, as opposed to
regulating the entity that does it.
I wonder if we are encountering a similar type of problem
here with the definition of the AT person. Is the scope of this
regulation exhaustive, are the lines we are drawing with this
AT person definition too big, is it too small, and could a
better way be to regulate the activity that the AT person is
doing as opposed to regulating the entity?
Mr. Wood. Congressman, if I can take that one. FIA has
certainly always advocated that there shouldn't be a very
strict definition of who is an AT person, because the lines
have increasingly become blurred between automated and
algorithmic trading to the point that it becomes meaningless in
the sense of the interaction with the marketplace. And to your
point, we have stressed to the Commission that they should be
looking more at the what, the actual activity, the automated
nature of the activity in the U.S. futures markets, as opposed
to trying to look at the who, and trying to create some sort of
arbitrary categorization where people either fit into that
category or outside of that category, which really doesn't do
anything to protect the overall integrity of the marketplace.
Mr. David Scott of Georgia. Okay. Thank you, sir.
Thank you, Mr. Chairman.
The Chairman. The gentleman yields back.
Mr. Lucas, 5 minutes.
Mr. Lucas. Thank you, Mr. Chairman. And thank you to the
panel for being here today.
A big part of what we do is establish a base of information
and knowledge, in these Committee hearings. So just go back to
the fundamentals for just a moment, and I would say, Mr. Woods
or Mr. Gorelick, or whoever would like to answer this question,
explain to us for just a moment what the benefits of automated
trading provide to the participants, that fundamental question
about why this matters. Surely it benefits someone or we
wouldn't be doing it, right?
Mr. Gorelick. Absolutely. If you look back at the
development of the markets over the last 15, 20 years, as
markets have become more electronic, market participants have
started to automate a lot of the functions that they did
previously. So in terms of evaluating market data and what is
going on, in terms of placing orders, in terms of adjusting
orders, in terms of managing risk, all of those functions are,
in many ways, better handled by a computer much more
efficiently than they were able to be handled previously. And
the result of all of that is that costs for end-users in the
markets have come down. And if you look at the data, sort of
end-user costs in a variety of markets that have become
increasingly electronic, increasingly automated, and in turn,
increasingly competitive, the result is that the costs to the
end-user are much lower. And that is the primary benefit of
automation.
Mr. Lucas. Increased efficiency of the process. Absolutely.
Mr. Ryan, in Reg AT it doesn't appear to provide a real
definition of what source code is. Is there some universal
definition that CFTC and other entities like to use?
Mr. Ryan. Yes.
Mr. Lucas. Because we have come a long ways in my 40 years
from playing with COBOL and FORTRAN in those freshman classes
back in the 1970s.
Mr. Ryan. Sure. I don't think that the general definition
of source code, first, I don't think it is really defined in
the proposed regulation, but I don't think that is too
controversial a concept. Basically, it is a high-level software
language that is supposed to be written in a way that is
intelligible to humans. So it is not the machine language, it
is not binary code. The part that is more concerning is the
breadth of the source code that is being requested under the
regulations.
Mr. Lucas. One last question. Mention was made about not
just proprietary code developed by a firm, but vendors being
available to purchase this from. For curiosity's sake, how much
of an industry is this, do we have dozens or hundreds of
vendors who have these products for sale, retail?
Mr. Ryan. Well, we have----
Mr. Lucas. And I address that to anyone who would care to
respond.
Mr. Ryan. Sure. I mean, actually, others might know it
better than I do, but we have many. I mean I would say in the
futures worlds, maybe a dozen or more, or dozens, I guess,
vendors that are available.
Mr. Wood. Yes, I would add from an FCM perspective where we
provide access to our customers, we see many firms who either
write their own code or are using third parties, or they are
even using algorithmic trading software provided by ourselves.
And in terms of numbers, there are, yes, certainly many
different types of firms that provide different levels of type
of automation.
Mr. Lucas. And with the resources involved and the
sophistication of the users, I would assume this is an
incredibly competitive process developing this software for
sale, and I can just imagine how competitive.
With that, Mr. Chairman, I yield back.
The Chairman. The gentleman yields back.
Ms. DelBene, 5 minutes.
Ms. DelBene. Thank you, Mr. Chairman. And thanks to all of
you for spending time with us this morning.
Everyone has brought up the issue of source code and
concerns about unfettered access to source code, and not
maintaining a subpoena standard. Mr. Ryan, brought up the issue
of kind of the access of code with actual data flows coming in.
And when you are doing testing and there are obviously the
requirements on testing within the regulation, can you talk
about how you develop code and how you test it, test your
source with data so that you can understand how it is working?
Mr. Ryan. To a degree, I can talk about that. I am the
lawyer, I am not the technologist.
But yes, throughout the development cycle we test the data
to look at things like how it is working functionally, whether
there are security issues involved with it, whether the code is
written appropriately, how it works in relation to the market
itself. An issue that I have raised on this is that I question
whether that review of code is really the relevant test, as
opposed to the review of the output of the product because it
is that output that is really what is relevant to an analysis
of whether there is a problem, at the end of the day.
Ms. DelBene. Do others have feedback on how you test and
how you combine those two together to one, see if you are
getting the results that you want in terms of creating the
product that you thought you were creating?
Mr. Gorelick. Well, that is a very important point that the
software in and of itself won't tell you very much about what
is going to happen in the market. It is really an issue of
seeing how the software runs in a live market.
Now, what we do internally is lots of different kinds of
testing. We do component-level testing where we look at a
particular piece of code and develop test cases around that to
make sure it is functionally the way we intend. We do system-
level testing where we actually dummy-up information sources so
that the information comes, in a way that is as close to what
we expect to see in the real market as we can. And then we do
live-market testing where we actually trade these markets,
after they have passed all of our other tests, at small scale
in the market to make sure that they do what we expect them to
do, based on all of our testing.
There is extensive testing that goes on. The real core of
the issue is though, from a software standpoint, is looking at
the software close to enough to let you know how it is going to
operate in the real live market, and when you are not taking
into account all the data, the timing issues, the hardware
issues, the network issues, it is hard to get comfortable that
there will be a lot of insight gained from that.
Ms. DelBene. Yes.
Mr. Wood. And if I can just add to that. Source code is the
basis for when something is actually running in production.
There are a lot of runtime parameters; i.e., real-time inputs,
that come not just from the people who are using the software,
but also from the market itself. And these are factors that,
obviously, influence how the software then interacts with the
market. Generally, across the industry, we have been trying to
say the only way that you can try and control this is to ensure
there are appropriate pre-trade risk controls in place to
mitigate the possibility that something may go wrong, or
something may occur that could disrupt trading in the
marketplace.
Ms. DelBene. All of you are saying if you aren't really
studying the overall environment, just looking at code and
looking at the lines of code, you are not necessarily going to
have the insight you would have unless you saw the entire
environment, which is the data flowing through the system and
the output of the system, which I guess speaks to the point
that you made, Mr. Gorelick, earlier about the resources that
would be required there.
Secondarily, then there is the protection, the protection
of source code and trade secrets and IP, and does anyone have
any problems with the way things have worked to date in terms
of having the subpoena standard that has been in place?
Mr. Wood. One thing I would just say to that is it usually
takes several steps before it gets to a subpoena level. Working
for an FCM, we often get inquiries from both the SROs and from
the CFTC for a section 4g inquiry where they are asking for
information. And, of course, we will try our best to provide
that information. We will talk to our customers if it involves
their customers, if they are direct members of the SRO,
obviously, they would be directly approached. So we would go
through all appropriate steps to provide as much information
and background before we got to the subpoena process.
Ms. DelBene. Thank you so much.
My time has expired. I yield back, Mr. Chairman.
The Chairman. The gentlelady yields back.
Mr. King, 5 minutes.
Mr. King. Thank you, Mr. Chairman. And I thank the
witnesses for your testimony.
I turn first to Mr. Gorelick, and I pose a question this
way. All the things we are talking about here with algorithmic
trading, could you paint for us, since you have been really
good metaphorically so far, worst case scenario, if we did
nothing and let this thing just race where would it go, what
would be the worst case scenario?
Mr. Gorelick. Markets certainly have experienced
disruption, and there has been manipulation. There has really
never been a market in the history that has not had some kind
of problems with it, and some of those problems have come
forward as the markets have been electronified and automated.
My sense is that there are a lot of safeguards that the
industry has already put in place to really mitigate the risk
of the worst case scenarios that we are talking about; markets
spinning out of control in some way, that there are multiple
layers of risk controls, there are best practices that have
been discussed widely, there are audit functions from the
exchanges, there are lots of things that have gone on over the
years to help create and innovate multiple layers of risk
controls to help keep the market in line, and by and large,
they work extremely well. Our job here today is to think about
those worst case scenarios, and think about the events in which
in which things have gone wrong, but it is important to note
that almost all day, every day, markets trade and function
extremely well.
So my sense is that, generally speaking, the worst case
scenarios are largely mitigated, but we need to keep after it.
We need to improve our data analysis skills from the regulatory
standpoint, we need to continue to invest in technology, and we
need to continue to develop best practices in a flexible
regulatory environment.
Mr. King. I tend to agree with you about the corrections
that would take place along the way, but what about worst case?
Mr. Gorelick. Right. I think the worst case----
Mr. King. How would that come about?
Mr. Gorelick. Yes, sure. What we are all worried about is
market disruption such as the flash crash where the market went
down very quickly and then recovered very quickly, without a
lot seeming to happen to explain that quick turnaround.
Mr. King. Okay, let me dial this back to the 2007 or 2008,
the broader financial market near-collapse that we had, and the
invention of the concept of too big to be allowed to fail. And
if I recall, the insurance component of that was AIG, who went
clear to the bottom. But there were people buying that on the
way down, or there wouldn't have been a market, and those folks
that bought it all the way to the bottom made a lot of money
coming back the other way. So I might paint that as a worst
case scenario with regard to those markets. Is there a similar
scenario that you could paint with regard to the algorithmic
trading?
Mr. Gorelick. Yes, that would be the concern, again, that
market prices don't reflect real market realities. And
typically speaking, there are so many firms looking at these
markets and trading for those opportunities that, if things are
working well, it pushes everything back in line. But if you
have markets that are trading away from fair value for extended
periods of time, that is a market malfunction, and for most
people it is probably an opportunity for others. And that is an
important way to think about it.
Mr. King. And would you say that the more experience and
history we have with these market fluctuations, the fewer
fluctuations we have, because you would have more traders that
would identify it earlier, and those corrections would come
into place naturally and more quickly?
Mr. Gorelick. Absolutely. And one of the good things about
the market changes that we have seen in this automated market
is we are no longer just relying on several dozens of traders
in a trading pit to be able to provide all that liquidity. We
have the opportunity for people from all around the country and
all around the world to look at this data on a level playing
field, and try and push the markets back in place. I think that
has resulted in fairer markets with better pricing and more
liquidity.
Mr. King. All in real-time, which they don't conceive of
that in those Marxist countries.
I turn to Mr. Vrabel, and would you agree there is natural
market corrections?
Mr. Vrabel. I do, and I see it. Part of my team structure
is to review market events. We have reviewed every event from
the flash crash through the recent market turmoil with Brexit,
and we see corrective activity from participants. An example is
if we look at August 24, 2015, when the Chinese equity market
crashed, which led to a precipitous decline in our markets, we
saw vastly different market activity than we did during the
Brexit days. And a lot of this, I believe, based on having
talked to firms, is that they learned from the market event of
August 24, they learned from the Treasury flash crash of
October 15 how to adjust to the market.
Mr. King. And quickly, I ask you, do you believe that our
traders are adequately collateralized?
Mr. Vrabel. That the traders are adequately capitalized?
Mr. King. Collateralized.
Mr. Vrabel. Collateralized.
Mr. King. Yes. Do they have their collateral underneath
their trades adequately?
Mr. Vrabel. Yes. And we have controls in place from our
clearinghouse structure, we have tools in place that allow
firms to set capital limitations or risk limitations. So yes, I
do believe so.
Mr. King. Thank you very much. I thank all the witnesses.
I yield back the balance of my time.
The Chairman. The gentleman's time has expired.
Ms. Adams, 5 minutes.
Ms. Adams. Thank you, Mr. Chairman, Ranking Member
Peterson. And thank you, gentlemen.
High-frequency trading has certainly taken off quite a bit,
and it is taking the trading industry by storm, with mixed
results. While it is clear that the technology used in our
financial markets is constantly evolving, we must be cautious
and make sure that there are standards in place to regulate
these new technologies. Obviously, Reg AT seeks to provide a
regulatory regime for market participants that engage in high-
frequency trading, but what about the companies that only write
trading algorithms and sell them to market participants? They
are not market participants, but service providers to market
participants, and yet you can imagine that if one of the
algorithms they provided is faulty in some way, this could
cause or contribute to a market disruption.
Mr. Ryan, what would be the best way to monitor or regulate
third-parties who provide the technology, but do not trade?
Mr. Ryan. Well, thank you for the question, Congresswoman.
It is an interesting one.
TT is generally not the type of entity that you are talking
about. Although we offer some algorithmic trading tools, for
the most part, we enable our customers to utilize their own
algorithms onto our systems, or using our systems.
Having said that, I believe that the answer to your
question is that the algorithms that are provided by third
parties can be tested by the traders and by the registered
entities as products to see how they work in the market, and to
see whether the intended effect actually happens. That is
something that can be done today, and that is the appropriate
way to test those types of tools.
Mr. Wood. If I may just add to that.
Ms. Adams. Yes.
Mr. Wood. The FMCs have a responsibility in providing
access to the U.S. futures markets. We talk to customers who
are using different types of software, and obviously, everyone
has a responsibility to ensure what they are using to interact
with the market is appropriate and has been tested. And
obviously, a software provider has a similar responsibility to
ensure that their software has been adequately tested. However,
when it comes to being used in the marketplace, it comes,
again, back to these real-time parameters that are used around
the software. And we in the FCM community will have many
conversations with our clients about the types of software they
use, the types of market access they want to use, and the types
of risk controls that should be put in place appropriately. And
to the previous question around collateralization of clients,
the types of risk controls that we agree to put in place with
our clients are based on a risk assessment of the client, and
they will then act as a speed bump in situations where there
may be overtrading. Now, overtrading may be deliberate or it
may be accidental through the way an algorithmic trading system
or automated trading system is using, but again, it comes back
to the fact that we have to have risk controls in place to
minimize any possibility that something may go wrong.
Ms. Adams. Thank you. Several comments submitted during the
comment period for Reg AT suggest that a lot of the definitions
included in the proposed regulation are overly broad,
particularly with regard to the definitions of an AT person,
algorithmic trading, and floor trader. So what do you believe,
and anybody can answer this, is the best way to set those
definitions, and what are some of the challenges in drawing
those lines, and should it be based on speed or on the way a
market participant enters orders?
Mr. Gorelick. There are a lot of concerns with the
definitions that have been expressed and kicked around. One of
the opportunities that we have, if the goal is to improve
market integrity and sort of relatively quickly, is to not
worry about defining classes of participants with great detail
because everyone will have different opinions on what the right
definition is and who should be covered by what, but rather
focus on making sure that there are risk controls on every
order that goes into the market.
So if we do that, we don't need to focus on some of these
boundary questions, and instead just worry about appropriate
risk controls at every level of the process for all electronic
orders.
Mr. Wood. And if I can just add to that. One of the
challenges with trying to create some sort of arbitrary
boundary, as Richard said, and we have seen this in Europe as
well where people have tried to create definitions of high-
frequency trading, I was part of the CFTC Technology Advisory
Committee, along with Richard, where we were trying to come up
with a definition of high-frequency trading, and we decided we
would not come up with a definition because, first, it would be
very broad, and it is a mechanism, not necessarily a style of
trading, but also it creates a situation where you can almost
arbitrage the situation by saying if I don't meet the metrics
that have been set as the boundary, therefore, I do not have to
comply with this categorization.
Ms. Adams. Thank you. I am out of time. Mr. Chairman, thank
you, I yield back.
The Chairman. The gentlelady's time has expired.
Mr. Crawford, 5 minutes.
Mr. Crawford. Thank you, Mr. Chairman. I thank the
gentlemen for being here today.
Mr. Gorelick, in 1992, Congress required the registration
of floor traders to prevent felons from participating in the
commodities markets. Today, the CFTC is attempting to use that
same floor trader registration requirement to regulate the
activities of proprietary trading firms, most of whom would
qualify as floor traders under Reg AT. Is there any harm in
stretching the definition of floor trader to encompass those
market participants?
Mr. Gorelick. I am thinking about it from is there any
benefit in doing that. I am sort of taking the flipside of that
question because I don't think it is necessary to create a new
registration category in order to accomplish the Commission's
risk management objectives. So I would start off by sort of
questioning the benefit that is sought to be achieved with that
new categorization. I would also say there are some obvious
awkwardness around trying to shoehorn a group of market
participants into an old definition. The old definition, for
example, was geared towards individuals standing on a trading
floor, as opposed to a firm.
Mr. Crawford. Yes.
Mr. Gorelick. And there would be a lot of things that need
to be smoothed out. What I have suggested is that it would make
more sense to consider the registration requirements separately
from the risk management components here, so that the
Commission could figure out what the right categorizations
might be, who they are trying to capture. More importantly,
what are the benefits that they seek to achieve through that
registration.
Mr. Crawford. What is your primary objection to the
agency's definition of direct electronic access?
Mr. Gorelick. Yes, I have not questioned the details of the
definition as much as the need for that definition, again. If
we are putting risk controls on all electronic orders, the
question of exactly the mode in which someone connects to the
market becomes irrelevant and unimportant. We can just make
sure then that we have the appropriate levels and layers of
risk controls, regardless of the method of access.
Mr. Crawford. And, Mr. Ryan, the same question to you.
Mr. Ryan. Yes, I mean I agree with what Mr. Gorelick just
indicated. However, I will also add that we have raised
concerns because we definitely have individual end-users who,
for example, trade on their own account. And I actually had a
conversation with a guy a couple of months ago about this. He
told me about the way that he trades. He trades on his own
account, he happens to share space with a bunch of other people
who do the same thing. They share algorithms that they wrote in
Excel, and they will use those algorithms throughout the day.
They trade through an FCM whose infrastructure is hosted at one
of TT's facilities. The way that DEA is currently defined, that
individual would have to register as a floor trader, arguably,
because he is accessing the market through a system that isn't
physically hosted by the registered agent or the registered
FCM. And so I think that is problematic.
Mr. Crawford. Okay. Mr. Gorelick, back to you. If an entity
is required to be registered as a floor trader, what CFTC
regulatory requirements would be imposed on them beyond those
specified in Reg AT?
Mr. Gorelick. Actually, I am not sure about that. I would
be happy to look that up. I focus more on what are the
requirements within Reg AT.
Mr. Crawford. Yes.
Mr. Gorelick. I am not familiar with the floor trader
requirements in any great detail.
Mr. Crawford. Okay. Mr. Wood, do you have anything that you
could add?
Mr. Wood. With regards to the responsibilities of being a
floor trader, I apologize, not really. The one thing I would
say on DEA, what we have questioned, again, because it brings
into scope a lot more participants than was originally intended
in Reg AT, we have generally questioned its need because it
becomes almost like an arbitrary trigger again in terms of
creating a requirement around someone who has a particular type
of market access, which then they don't have to do if they then
use a different type of market access by going through pipes
provided by an FCM. And we think that it comes back to we
should be looking more at what is the type of activity, as
opposed to the mode of access to the market.
Mr. Crawford. Okay. Mr. Ryan, did you have anything you
want to add on that?
Mr. Ryan. Well, I guess just to add to what I was saying
before, the significance of having that individual that I was
talking about trade through an FCM is that the FCM controls his
risk already, and that is the key, it seems to me, not
necessarily where the physical trade is entered or how it is
entered.
Mr. Crawford. Okay. Mr. Vrabel, in the last 13 seconds, any
comments?
Mr. Vrabel. No, I can agree with what was said. The key
issue for us is where the risk controls are being administered,
either by the clearing member firm that has the ability to
administer those controls, or if it is by the trading firm
themselves that have created their own tools, and that is
really where the line comes when looking at whether those
controls are adequate and who is responsible for them.
Mr. Crawford. Thank you. I yield back.
The Chairman. The gentleman's time has expired.
Mr. Walz, 5 minutes. No questions?
Austin Scott, 5 minutes.
Mr. Austin Scott of Georgia. Thank you, Mr. Chairman.
Mr. Gorelick and Mr. Wood, when Chairman Massad appeared
before the Committee in February, I questioned him regarding
the source code provisions in Reg AT, and his testimony was
that the CFTC would only access source code using proper
procedures. And why isn't a subpoena the proper procedure to
get highly sensitive information like source code?
Mr. Wood. We would all argue that the subpoena is the
appropriate legal procedure for accessing intellectual
property. As I said previously, it is an extreme situation
though. There are other methods to find out more information if
there is a particular inquiry without going to the subpoena
level.
Mr. Gorelick. I was reassured by Chairman Massad's comments
in that regard that they would be open to looking at what the
appropriate safeguards are, and I would suggest that the
subpoena process, as it has currently been in place, is
probably the best place to start.
Mr. Austin Scott of Georgia. Well, let me ask you this
then, with the breaches and other things that we have had, and
the government pledge to look after your source codes, how much
comfort does that give you that the government would be in
possession of it and looking after it?
Mr. Gorelick. The assurances, at the end of the day, would
need to go beyond just merely we are going to take care of you,
don't worry about it. I think that there are lots of different
types of safeguards that can go in place around sensitive
information, about who is able to look at the information and
in what form they are able to access the information, what are
the various levels of access printed copies versus connected to
the Internet, et cetera, et cetera, that would need to be
thought through and put in place to give comfort in that
regard.
Mr. Austin Scott of Georgia. Mr. Ryan, could you speak to
the definition of source code and whether or not there is a
universal definition, and specifically to Reg AT, if they have
been clear about what the definition of source code is?
Mr. Ryan. Sure. I mean as I indicated before, I don't think
that the general definition of source code is too
controversial. Very generally, as I said, it is a high-level
software language that is intended to be intelligible to
humans.
Mr. Austin Scott of Georgia. Is it all written in the same
computer language?
Mr. Ryan. No. No. There are many, many different languages.
In fact, TT uses in excess of 30 different languages.
Mr. Austin Scott of Georgia. Is it easy to interpret? I
would assume that it is not if you use that many different
languages.
Mr. Ryan. Absolutely. No, it is not. It is not. It is not
even easy to interpret when you are talking to different
software engineers who are working with the same sort of
language. One software engineer's source code might not be very
obvious to another software engineer's source code. In fact,
that is typical.
Mr. Austin Scott of Georgia. So then how would an agency
maintain a staff that could actually use the information and
derive anything that they may need out of the information?
Mr. Ryan. I appreciate your question, and I think that
would be very difficult for them to do. And again, I think that
the participants in the marketplace are willing and able to
give as much useful information as we can, but there is
definitely a question as to whether this sort of information is
useful.
Mr. Austin Scott of Georgia. Well, I don't have any further
questions, Mr. Chairman, most of the ones that I had have
already been asked, but thank you for having this hearing. And,
gentlemen, thank you for being here.
And with that, I yield the remainder of my time.
The Chairman. The gentleman yields back. I also thank him
for his chairmanship of the Subcommittee that has direct
oversight on this.
Mr. Thompson, 5 minutes.
Mr. Thompson. Thank you, Mr. Chairman. Thanks to the
members of the panel.
Mr. Ryan, my first question is for you. Can you share some
additional detail about how commercial market participants
utilize the tools that your platform provides?
Mr. Ryan. Sure. We have many different trading tools that
people can use, specifically with respect to algorithmic
trading, to input their algorithms. For example, we have a tool
called ADL, or Algo Design Lab, which enables an individual to
basically drag and drop icons onto a user interface to create
kind of a logic tree that ultimately creates an algorithmic
trading strategy.
We also have other tools that enable people to input
algorithms or equations into the different cells on a user
interface that, again, would enable them to use the algorithmic
trading. It also integrates with things like Excel. Lots of our
traders use Excel and integrate it into our software, Microsoft
Excel. And otherwise through APIs, they can integrate their
algorithmic trading strategies through our software.
Mr. Thompson. Sounds like many of your strategies and tools
are pretty consumer-friendly in terms of, I don't want to say
algorithms for dummies, but maybe a kind of thing I could
actually handle. I am not sure when you are talking about
dropping icons.
Mr. Ryan. ADL is one that we are particularly proud of, and
the idea of it is that it enables regular traders, so to say,
to be able to input algorithms without having to hire a
software engineer to do it for them.
Mr. Thompson. Yes. Market access. What would be the
ramifications for your clients if they were subject to the Reg
AT simply because they used your platform to execute their
trades?
Mr. Ryan. Well, I mean we have touched on some of the
bigger concerns such as the source code repository. An example
is that end-user that I was talking about before. When I was
talking to him, he had told me that when he trades throughout
the day, he will have a list of maybe ten different algorithms
that he and his trading partners might use. They will be
tweaking them throughout the day too, depending on market
conditions.
As written, that individual trader would have to keep track
of all of those changes, all of the source code related to
those changes, indicate how and when that was done, and have
that available for review by the CFTC, again, without subpoena
power, which is a tough task.
Mr. Thompson. Well, thank you.
For the rest of the panel, why would imposing risk controls
on market participants, instead of registration requirements,
be a better means by which to regulate automated trading?
Mr. Vrabel. I will address it in part with some of my
earlier comments that some of the disruptive activity we have
seen in our markets have come from fairly simply automated
strategies that would not necessarily be caught in how Reg AT
is currently written. By participants that do not have direct
electronic access, who are nevertheless operating a simple
automated strategy in the markets. And they pose similar risks
to the marketplace like some of the more sophisticated firms.
Obviously, I think that everyone up here shares the same
perspective that we need to protect the entire market, not just
a particular subset of traders that would be burdened with
these requirements.
Mr. Wood. And if I may add to that. So when FCMs provide
access to their customers, to the marketplace, we have
discussions with the clients about what sort of systems they
are using, what types of controls they have in place. And if
they choose to bypass the systems that we provide for market
access, where we have risk controls that we administer, and
they choose to use either a third-party software which may or
may not give the FCM the ability to set those risk controls,
then if they are going direct to market without something the
FCM can provide, then they have a responsibility to ensure that
there are appropriate risk controls in place.
The industry has generally taken that approach that there
is this responsibility. The Commission feels that they have to
go one step further with regards to then saying, ``Okay, if you
are not going through an existing registrant, you should become
registered, and in this case it would be as a floor trader,
because of the type of access you have.''
We have generally argued within the industry that is
probably going a little bit too far, though we have conceded
that if someone chooses not to go through the risk controls
provided by an existing registrant, such as an FCM, then, okay,
they will become registered in themselves.
Mr. Thompson. Yes. Thank you, gentleman.
Thank you, Mr. Chairman.
The Chairman. The gentleman's time has expired.
Mr. Allen, 5 minutes. Rick.
Mr. Allen. Yes, sir. Thank you, Mr. Chairman. And we have
covered a lot of ground here this morning. Thank you so much
for coming and at least educating me on this process.
I just had a couple of general questions about the
industry. Mr. Gorelick, you are in the business, and I just
have a general question, what keeps you up at night?
Mr. Gorelick. Well, there is a lot, obviously, we are in
business, the competitive concerns are something that we spend
a lot of time thinking about, making sure that we are keeping
up with changes in the market, and competitive changes and
competitive dynamics, and that is where I spend a lot of my
time thinking.
In terms of sort of risks to the market, I really worry
about new regulation coming in, in ways that distorts how
things are working pretty well right now.
Mr. Allen. Yes.
Mr. Gorelick. Things can always get better, and we should
always be working to improve. I don't want to defend the status
quo, however, some of the rules that are being proposed here
and in other contexts definitely run the risk of unintended
consequences that could make it a lot harder to manage risk,
and that could take a lot of time and energy away from sort of
our core functions of risk management, and keeping up with
competitive developments in the market.
Mr. Allen. Yes. I am on another committee, Education and
the Workforce. We have had a number of hearings on the
fiduciary rule. Does that in any way affect your business, or
are you familiar with that?
Mr. Gorelick. I am not.
Mr. Allen. You are not, okay.
As far as your customer base, and again, this is just to
satisfy my curiosity, your customer base, are they pretty much
investors that know this industry, know this business, or are
they folks that just kind of come and go in the market, and
what incentives do people have to invest in these trades?
Mr. Gorelick. Sure. So we are a proprietary trading firm.
So we manage----
Mr. Allen. Okay.
Mr. Gorelick. We trade our own capital. We put our own
money at risk in all the trades that we conduct. So we don't
have direct customers in the traditional sense.
Mr. Allen. I see. Okay. So from your standpoint then, as
far as these regulations, if you are dealing with your own
money what then would be the issues as far as the government is
concerned?
Mr. Gorelick. Well, as proprietary traders, we clearly have
incentives to make sure that we are managing our own risk. It
is our own capital at risk, and so we are largely aligned with
the goals of risk management throughout the market.
Mr. Allen. I see. Okay.
Mr. Gorelick. So I would think that that is the case.
The interest of the government here is sort of protecting
market integrity, and we very much share that concern. We want
to make sure that we are participating in markets that are
transparent, that are well-regulated, and that the public
rightfully has confidence in.
Mr. Allen. And that is one of the things that I have seen
as far as my short time here, is that we have this tremendous
disconnect between the regulatory part of this body versus
actually the business community out there. And it sound like
you all have put in a lot of your own regulatory environment to
protect the industry, and I commend you on that.
As far as what we can do as a Committee, and I will leave
this, I have about a minute and a half left, what is the
biggest thing we can do here as this body to protect the
integrity of this industry, and certainly as far as our role in
agriculture?
Mr. Gorelick. The continued oversight responsibility of the
Commission is very helpful. Holding hearings like this where
you surface issues, and help to urge the Commission to continue
to take into account the views of industry, and to identify
where there are opportunities to improve the current regulatory
framework.
Mr. Allen. Mr. Wood, do you have any comment?
Mr. Wood. I would absolutely echo what Mr. Gorelick said
there. From the FCM perspective, obviously, we have put a lot
of investment into ensuring that we have the controls in place
to obviously aid us in how we do our business in providing
access to market participants, who are our customers. We would
like to see a fair and evenhanded continued regulation of the
U.S. futures markets that is not too prescriptive or onerous or
burdensome on the market participants.
Mr. Allen. Yes. And I assume you will holler at us if it
gets a little too restrictive? Good.
Well, I am out of time. I will yield back.
The Chairman. The gentleman's time has expired.
Mr. Benishek, 5 minutes.
Mr. Benishek. Thank you, Mr. Chairman. Thanks, gentlemen.
I missed your initial testimony, but I have a couple of
questions, I am not as sophisticated as far as this market
stuff as some of these people here. What are some of the
disruptions to the marketplace that, I think it was Mr. Vrabel
described, like 20 or 30 incidents of market disruptions that
have resulted from, I don't know, programmatic trading
policies, or something? Can you explain that to me a little bit
more, what happened, and like pick a couple of examples, and
then how did you fix it or what happened there, tell me about
that?
Mr. Vrabel. Sure. And just for clarity, the 15 to 30, or 15
to 20 disruptions in the market based on my understanding of
that study, it was not disruptions that were the result of
algorithmic trading malfunctions, which is important to
recognize.
What we do though on a regular basis is monitor our markets
for aberrations. And it could be as simple as we see a firm
sending in a significant number of order messages over a given
period of time, which may be indicative that their systems are
malfunctioning. So this could have no impact on the marketplace
at all, but we see conduct from that firm that seems like an
aberration. And our ordinary course of practice is to reach out
to that firm to try to identify the cause of that. And by and
large, this causes the firm to say, ``Yes, we realize the
issue, we have implemented these new controls to prevent this
from happening in the future.'' That is how we monitor the
markets and mitigate the potential of an algorithmic trading
disruption. And that is really what is important that, in order
to protect the market, you have to spend a lot of time working
with the participants, rather than imposing very----
Mr. Benishek. Does this happen very fast though? I mean it
seems to me that these kind of algorithmic trading--that stuff
happens really fast. I mean is there an opportunity to get in
there and question them how this is working?
Mr. Vrabel. It is. CME Group has a number of controls that
are in place. One of them is a messaging throttle control. And
what it does is, it imposes a threshold where if a firm
breaches that threshold over a given period of time, we start
to reject new orders that that firm is submitting. And if it
gets egregious enough, we actually shut down their access to
the exchange. So we have controls that can act much faster than
I can look at my computer screen and see what is happening.
Mr. Benishek. Right. Right. So how often does that happen?
Mr. Vrabel. I don't have numbers at-hand. I would say that
it is not infrequent that firms have activity that causes us to
prevent those orders. I would also say it is not always a
malfunction.
Mr. Benishek. Right.
Mr. Vrabel. Sometimes it could be intended activity based
on the market moving.
Mr. Benishek. Let me kind of go a different direction a
little bit. Apparently, this Reg AT, if the participant
violates an algorithmic trading policy, that is considered
grounds for the CFTC to enforce, which seems kind of weird to
me that your own rules, if you violate them. So what is to
prevent you from writing very lax rules and then not reporting
to the CFTC? I am just kind of curious about that.
Mr. Gorelick. That is one of the concerns that we have
raised with the CFTC, that it sort of provides a disincentive
for people to have particularly restrictive internal policies
and procedures, and that the incentive that would come from
that would be to have the bare minimum that are required by law
to make sure that you are not inadvertently bringing on
additional liability to your firm. So that is one of the
definitional issues that we have suggested need to be fixed.
Mr. Benishek. All right. Thank you.
Thanks, Mr. Chairman. I will yield back.
The Chairman. The gentleman yields back.
Mr. LaMalfa, 5 minutes.
Mr. LaMalfa. Thank you again, Mr. Chairman. Please forgive
me for having been in a different committee, if anything I ask
may be a little redundant, having missed some of your previous
testimony.
But, coming back to the requirement that firms make their
source codes available without a subpoena at CFTC is very
concerning to everybody here today. It would seem to me that
this change is really an important issue of privacy and
protection of intellectual property. So do any of you on the
panel have any additional thoughts about how this agency could
modify the code repository requirements in order to maintain
that intellectual property? Anything you want to sum up with
here?
Mr. Gorelick. So one of the things that I suggested in my
written testimony is that there is an opportunity for a sort of
principles-based retention policy for source code that, working
with the industry, could be defined in a way that is consistent
with current practices, to ensure that when the CFTC needs
access and gets a subpoena, and follows proper due process,
that they can be comfortable that the source code still exists
within the firm in a reasonable way.
Mr. LaMalfa. With a subpoena.
Mr. Gorelick. With a subpoena, absolutely.
Mr. LaMalfa. Which isn't the pattern and doesn't seem to be
the policy coming forward?
Mr. Gorelick. Correct. So this is a change that we are
suggesting, an alternative that we are suggesting would be that
a thoughtful principles-based retention policy should address
the concern that the source code just doesn't exist, but in
order to access that, the CFTC would have to follow existing
practices of using a subpoena and following the due process,
and putting in place appropriate safeguards.
Mr. LaMalfa. Gentlemen, do you wish to address that? Mr.
Vrabel? Okay. All right, thank you.
The cost-benefit analysis, do you think there are really
any benefits with the applications as to the end-users, the
commercial end-users? Are they going to see anything they can
put their finger on as a benefit? Gentlemen? Anybody? Don't
want to touch that one?
Mr. Gorelick. Yes, I don't think it will be very
measurable.
Mr. LaMalfa. Not very measurable, okay. Okay.
There is a questionable interpretation of a long-time
definition of floor trader that is my understanding. Do you
think it takes into account the costs of floor registration
with this new definition, and ongoing cost of compliance?
Mr. Gorelick. I would say in general, if the rule were to
be approved in its current form, or close to it, it would
impose significant costs on both the industry participants and
on the Commission in trying to enforce it and keep up with it,
and those need to be factored into account. Ultimately, those
costs are not just borne by the professionals in the market,
they do get passed onto the end-users in the form of----
Mr. LaMalfa. Certainly. Everything does.
Mr. Gorelick.--higher transaction costs, less liquidity. I
think that is something that we do need to be concerned about.
Mr. LaMalfa. So you don't think these costs are being taken
into account by CFTC? This is being imposed. They are not
really looking at that.
Mr. Gorelick. It did not seem to me from the cost-benefit
analysis that they were looking at the broader impacts, that
they were really looking at sort of more specific narrow cost
concerns.
Mr. Wood. I would echo that, yes, there is a wider concern
that the cost-benefit analysis in the proposed rulemaking
didn't take into account what the potential impact on the
marketplace would be from the burden of compliance with Reg AT.
Mr. LaMalfa. It is kind of important to have that impact
taken into account, isn't it? Yes, okay.
Thank you. I appreciate the panelists here today. Thank
you, Mr. Chairman, for your graciousness.
The Chairman. The gentleman yields back.
Mr. Davis, 5 minutes.
Mr. Davis. Thank you, Mr. Chairman. I appreciate all the
panelists.
Something like this seems that in this case we have market
participants, and if you were given an opportunity to make
comments, it seems like your comments weren't heard before the
rule was implemented, otherwise we wouldn't be having this
hearing today. So it is interesting, sitting on this side, to
see that. And that is a concern to us.
And I do want to start a question with Mr. Vrabel. And I
want to know what will the CME do with all of the data that AT
persons and FCMs are required to report under Reg AT?
Mr. Vrabel. Under the requirements of Reg AT as it is
currently drafted, not much. And here is the reason why. For
example, the compliance reports that every AT person in a
clearing firm would have to submit to the exchanges on an
annual basis, the requirements in the draft would only require
us to review those every 4 years. So we impose this burden on
every firm to submit annual reports that the exchanges aren't
obligated to review. So it leaves huge gaps where participants
are submitting these reports, thinking that the exchanges are
endorsing them because they have submitted them, when, in fact,
they may have risk controls that are inadequate.
Mr. Davis. Well, will this information help you reduce the
risk of an algorithmic trading disruption?
Mr. Vrabel. From our perspective, no. As has been discussed
earlier, the algorithmic trading disruptions and the
malfunctions that are caused from algorithmic trading, in order
to ascertain the root cause of those requires highly
complicated analysis; the type of analysis that won't be gained
from routine annual compliance reports that are submitted to
the exchanges.
Mr. Davis. And I apologize if you may have addressed this
in your opening testimony, but were these concerns raised
during the comment period?
Mr. Vrabel. They were.
Mr. Davis. And the result?
Mr. Vrabel. There was no result.
Mr. Davis. Yet.
Mr. Vrabel. CME asked the Commission to extend the initial
deadline so that we and others could come forward with more
robust proposals, and that request was declined.
Mr. Davis. It was declined?
Mr. Vrabel. It was declined. We are thankful that the
Commission reopened the comment period. Unfortunately, it was
on a very small subset of the total proposed rule.
Mr. Davis. Well, I would hope that they would take comments
into consideration more seriously that we are hearing from many
of you as the market users.
Mr. Gorelick, or actually, the whole panel if you would
like to answer this, do you believe that Reg AT's cost-benefit
analysis fully appreciates the ramification of Reg AT on market
participants in terms of initial and ongoing cost of the
compliance? Whoever wants to start.
Mr. Wood. Generally as a panel, we feel that the cost-
benefit analysis focused on certain aspects, but not on wider
aspects. In terms of compliance with what is proposed in the
full scope of Regulation AT, it has a very large burden on
pretty much all market participants, from those who would be
classified as a floor trader, those who are already registered
with the CFTC, perhaps as a commodity trading advisor or
commodity pool operator, who would find themselves in the
category of an AT person. It imposes a burden on the FCMs in
terms of what we have to do providing access to an AT person,
and the reporting responsibilities, and it poses a burden on
the DCMs, in terms of what they have to do in providing
additional controls, and the reports that have to be filed with
everyone. That cost of compliance, unfortunately, will get
passed on to the wider marketplace, so every type of market
participant, whether they are commercial end-users, pension
funds, asset managers, et cetera, in the that sense our main
concern about Regulation AT is that this has a potentially
large impact on how liquidity is provided in the U.S. futures
markets that will ultimately be to the detriment of the end-
user.
Mr. Davis. All right, thank you.
Mr. Gorelick, I don't have much time left so I want to ask
you a specific question on this. Do you believe that the cost-
benefit analysis fully appreciates the potential costs of an
inadvertent release of your intellectual property?
Mr. Gorelick. No, that was not an area that was explored in
the cost-benefit process, to my recollection.
Mr. Davis. Okay. And any other comment you would like to
make on this follow up.
Mr. Gorelick. Sure. I would say one thing that often gets
lost in these cost-benefit analyses is the competitive impacts
of this regulation. When you have burdensome regulations like
this, the result is the biggest firms can keep up with it, they
can hire a few more compliance people, they can deal with the
reporting requirements, they can handle it, but it is the
smallest firms that sort of drop out of the market because they
can't compete. And that has a negative impact in the
competitiveness of the market in the short, medium, and long-
terms.
Mr. Davis. Thank you very much.
My time has expired.
The Chairman. The gentleman's time has expired.
Mr. Neugebauer, 5 minutes.
Mr. Neugebauer. Thank you, Mr. Chairman.
Mr. Gorelick, in your testimony, you stated that foreign
governments such as China are seeking to impose similar source
code requirements on U.S. firms. Could you describe some of
those efforts?
Mr. Gorelick. Sure. I would actually refer the Committee to
a comment letter that was put in by a variety of technology
trade associations and industry associations that deals
extensively with the source code issue. They raise a number of
actions in which the Chinese Government sought to impose a
source code requirement on U.S. companies who were selling
technology into China in certain sectors, and ultimately, they
were persuaded that this was unprecedented, not usual in the
marketplace, and backed down from that requirement. The concern
would be that this type of precedent that we would set would
give excuses across the board in lots of different industries
to impose similar requirements, which would be very detrimental
to American IP protection globally.
Mr. Neugebauer. Yes, with a country we already have a
problem in that area, quite honestly.
Mr. Gorelick, Mr. Vrabel, or Mr. Wood, what risk controls
would Reg AT impose on market participants that are not
currently being implemented? Are there new risk controls that
will be required in implementing this?
Mr. Wood. With the way Regulation AT is currently proposed,
it comes across as a very prescriptive list of risk controls
that an AT person and an FCM and a DCM should have in place.
And several of those controls are already in use on a wide
basis, but several of those controls are not. And as a more
general concern, it is too prescriptive in how those controls
should be applied in various places. And the view of the
industry is generally the controls that are used should be
appropriate to the type of activity, and to the market
participant in terms of how they manage their risk, how the FCM
manages the risk of providing access to the customers, and how
the DCM manages the risk to how it protects the marketplace, as
opposed to being as prescriptive in the way Reg AT is currently
proposed.
Mr. Neugebauer. Yesterday, I chaired a committee a hearing
on Fintech, and Fintech is a big world. And one of the things
that keeps coming up is that people are coming up with
innovative ways to make money and new business models, is that
the regulatory community in many cases don't understand the
technology, and in many cases maybe don't always understand the
particular business model being imposed there. And so my
concern is, and I wanted to hear your thoughts, my concern is,
we see this innovation in the marketplace, and hopefully it
makes markets more open, more efficient, and brings more
liquidity to those markets. Do you sense that the regulatory
community is kind of behind the curve and trying to play
catchup, and trying to then fold some of this new technology
and these methods into old regulatory framework?
Mr. Gorelick. I think that is a challenge in any regulatory
environment, to keep up with technology, and I think that is
something that we are seeing right here. And because there are
new things going on in the market with new technologies that
are constantly changing, we see the CFTC in one action try and
catch up with every possible outcome of some of the changes
that have occurred in the market in one rulemaking, and that is
complicating the process a little bit. There is a consensus
across the industry that the place to start is with risk
controls, with pre-trade risk controls, and that there is an
opportunity to really catch up a lot by focusing there, and
then we can move elsewhere.
I would say another area where the regulators can sort of
improve their capabilities is their data analytics ability.
When there are lots of people out there who look at market
events and say, ``Wow, this looks strange,'' and they come up
with their theories about what happened. The regulators are the
expert agency who is well-placed to actually look at what
occurred, and tell the public that this is what happened, and
be reassuring where there is a need to be reassuring, and
actually go and start enforcement or other compliance actions
where there is a need to do that. Data analytics is another
area that would help the Commission catch up very quickly.
Mr. Wood. If I might just add there. We have seen the U.S.
futures markets evolve in the space of 15 years from being 100
percent floor-driven, to screen-driven, to now, as we were
talking earlier about the high prevalence of some form of
automated trading. We believe that regulations should be
principle-based to allow for continued evolution, especially in
markets that are very technology-driven, and obviously where
innovation is constantly occurring. And to that point, what is
proposed in Reg AT is too prescriptive and anchors you in a
period of time that doesn't necessarily allow for innovation
and continued evolution.
Mr. Neugebauer. I thank the Chairman.
The Chairman. Thank you. The gentleman's time has expired.
I want to thank our witnesses.
Let me follow up, Mr. Vrabel, you mentioned that the
algorithmic trading users would, under your scheme, certify
something, certify that they have tested. What were you asking
to be certified, and who would set those standards, and would
there be an outside, I am a CPA by profession, and that word
certify is a bit protected, but what would that look like, what
would that certification look like?
Mr. Vrabel. Sure. A certification could look like a firm,
an automated trading firm verifying that they are in compliance
with a principle-based Reg AT regime. I can tell you that
today, we require firms to submit those types of certifications
on their maintenance of Audit Trailer, their 5 year retention
requirements. And I can tell you with 100 percent certainty
that if a firm does not believe it is in compliance, it will
not certify that they complied with our rules. That causes us
to then go interrogate the data and find out the reason why.
And we have no reason to believe why that type of model that is
currently enforced in FINRA, in a much more complicated
securities world, wouldn't work in our environment.
The Chairman. All right.
Well, I want to again thank you. I am hard-pressed to
envision a circumstance where the CFTC could have on-staff a
cadre of people who would pick out one of these firms at
random, and go in and drag through their source code in enough
detail to find that glitch that had been missed, and looking to
prevent some disruption in the market. If I had a client who
was cooking the books, I didn't argue as to whether or not
their automated general ledger system worked properly or not, I
regulated what came out of it and go about that direction. So
this whole issue around source code and those things, to me,
seems to be wrong-headed, and I don't know that it gets us
much.
On an after-the-fact, if someone has actually caused a
disruption in the market, the violation is not going to be that
they screwed up the code, the violation is going to be that
they manipulated or hammered the market. And we don't really
care how it happened if we can prove what they did. And it is a
real head-scratcher for me to understand the agency's fixation
on getting source code, having it in their own control, because
I don't know what they would do with it. They get a lot of data
today that I don't think they necessarily do everything that
they should be doing with it, and this would just add more to
that as well.
I did not hear from any of you that you don't want this
arena regulated, that the conduct should just be free-flowing
and laissez-faire, not one of you mentioned anything that
remotely said this does not need to be regulated, but you did
say that it ought to make sense and ought to be principles-
based, as Mr. Wood just mentioned. And I am hopeful that this
hearing and I see some representatives from the agency and
others here, that the CFTC will respond to the comments made
today, as well as the attention we have placed on this. But,
the testing that I know Richard does on his team, as a market
participant, if you had an algorithm you put in place and it
did something you didn't want it to do, and it didn't disrupt
the market but it caused you to be on the wrong side of all
those trades, you have a vested interest, a proprietary
interest, in not having a system that does something you don't
want it to do. And that is that first layer, and then all the
various things we could put in place on top of that that gets
to the system. And this proposed rule has a lot of fine-tuning
that needs to be done. I was particularly disappointed to hear
that the cost-benefit analysis was not maybe as fulsome as it
should have been. Chairman Massad and I have a running argument
as to the way the CFTC does their cost-benefit analysis. I
don't believe CFTC takes into consideration the costs to market
participants broadly, and I don't think it takes into
consideration the costs to the agency itself. If I want to
build a fiefdom then I could build all kinds of regulatory
schemes, it causes me to have to beef-up my staff, to put in
place that cadre of 50 or 60 different expert software
engineers to put on my team so that I can wade into your
software. Well, that makes no sense if, at the end of the day,
it doesn't really prevent manipulation of the market.
The other thing that earlier on was said somehow that this
regulatory scheme is going to be perfect, and that nobody will
be able to violate it. Well, if that is the case, then perhaps
the CFTC has discovered a technique that we could use perhaps
in the real criminal area, and maybe write rules that nobody
gets murdered today, and all those kind of good things. There
is a lot of work to be done in this.
Again, thank you very much for you very clear testimony. It
was great having you with us today.
Under the rules of the Committee, the record of today's
hearing will remain open for 10 calendar days to receive
additional material and supplementary written responses from
the witnesses to any question posed by a Member.
This hearing of the Committee on Agriculture is adjourned.
Thank you.
[Whereupon, at 11:54 a.m., the Committee was adjourned.]
[Material submitted for inclusion in the record follows:]
Submitted Statement by Susan Bergles, Assistant General Counsel,
American Gas Association
The American Gas Association (``AGA'') \1\ appreciates the
opportunity to submit this statement for the record relating to the
Commodity Future Trading Commission's (``CFTC'') proposed rule on
Regulation Automated Trading (``Regulation AT'').\2\ AGA filed comments
to the CFTC in this proceeding on March 16, 2016.
---------------------------------------------------------------------------
\1\ The AGA, founded in 1918, represents more than 200 local energy
companies that deliver clean natural gas throughout the United States.
There are more than 72 million residential, commercial and industrial
natural gas customers in the U.S., of which 95 percent--just under 69
million customers--receive their gas from AGA members. For more
information, please visit www.aga.org. AGA member companies provide
natural gas service to consumers and businesses under rates, terms and
conditions that are regulated at the local level by a state commission
or other regulatory authority with jurisdiction. They use financial
tools to hedge the commercial risks arising from the regulatory
obligation to provide affordable, reliable natural gas service to
customers--risks that include commodity price volatility. These tools
may include futures contracts traded on CFTC-regulated exchanges, and
over-the-counter energy derivatives.
\2\ Regulation Automated Trading, 80 Fed. Reg. 78824 (Dec. 17,
2015) (``Proposed Rule'').
---------------------------------------------------------------------------
The potential impact of proposed Regulation AT on AGA's members is
not insignificant. Absent an appropriately tailored and modified
definition of ``Algorithmic Trading,'' AGA believes there would be a
strong disincentive for AGA members and other commercial end-users to
use Direct Electronic Access (``DEA'') for futures trading activity on
or subject to the rules of a Designated Contract Market (``DCM'').
AGA's comments also expressed concern about the requirement that, for
the first time, commercial end-users might be deemed ``floor traders''
and have to register with the CFTC based solely on the manner in which
they trade--and the potential for Regulation AT, if applicable, to
unwind or render inapplicable many of the provisions in other rules put
in place to limit the burden and costs for commercial end-users, such
as AGA members.
As users of the futures markets, AGA members support and appreciate
the CFTC's efforts to bolster safeguards and risk controls in order to
protect against the risk of malfunctioning algorithmic trading systems,
and to increase transparency. However, AGA submits that it is vitally
important that any new rules promulgated as part of Regulation AT
preserve, and do not negatively impact, the ability of commercial end-
users to access the futures markets and use futures as part of their
risk management tools. Specifically, AGA is concerned that proposed
Regulation AT sweeps too broadly in its reach, and as such, may: (1)
have the unintended consequence of hindering the ability of commercial
end-users to efficiently and cost-effectively access the futures
markets; and (2) create inconsistency and regulatory uncertainty
regarding issues that commercial end-users and the CFTC just recently
addressed in other rules, such as margin requirements for uncleared
swaps (the ``Margin Rules''), and record-keeping requirements.\3\ AGA
believes that the CFTC need not, and should not, deem end-users to be
floor traders solely because they utilize DEA for ``Algorithmic
Trading.''
---------------------------------------------------------------------------
\3\ See Margin Requirements for Uncleared Swaps for Swap Dealers
and Major Swap Participants, Final Rule and Interim Final Rule, 81 Fed.
Reg. 636 (January 6, 2016), and Records of Commodity Interest and
Related Cash or Forward Transactions, Final Rule, 80 Fed. Reg. 80247
(December 24, 2015).
---------------------------------------------------------------------------
Simply put, AGA's concern regards the impact of proposed Regulation
AT on its commercial end-user members that may transact in futures
contracts via DEA to a DCM for ``Algorithmic Trading.'' As proposed,
the definitions, including ``Algorithmic Trading,'' ``DEA,'' and
``floor trader,'' are so broad and far reaching in scope that they may
have the unintended consequence of actually discouraging companies
looking to hedge their commercial risks from trading futures. In
particular, commercial end-users could--with just one DEA futures
transaction--fall within the definition of a ``floor trader'' which
requires registration with the CFTC, and concurrently fall within the
definition of an ``AT Person'' subject to all the requirements of
Regulation AT.
Additionally, AGA is concerned that proposed Regulation AT
potentially would impact the commercial end-user's status under other
rules that the CFTC has recently adopted or amended that address
concerns raised by end-users. Becoming a ``floor trader'' by virtue of
Regulation AT may inadvertently result in commercial end-users becoming
``registered members'' for purposes of the CFTC's general record-
keeping rules, specifically Rule 1.35(a). AGA submits that this would
be an unfortunate step in the wrong direction, given this rule was
recently amended to provide that commercial end-users as ``Unregistered
Members'' do not have to retain pre-swap-trade communications or text
messages or link all relevant data to a particular swap. Additionally,
AGA is concerned that because ``floor traders'' fall within the defined
term ``financial end-users'' for purposes of the CFTC's recently-
adopted Margin Rules, commercial end-users that are ``floor traders,''
solely because of their automated trading in futures, would be subject
to margin requirements in their swap trading. Thus, the potential
impact on commercial end-users of the definitions in proposed
Regulation AT would not be insignificant.
Further, the proposed definition of DEA appears so broad as to
include tools that DCMs are marketing, and make available for use by
commercial end-users, including AGA members. The definition of DEA
could be interpreted to include these common order management tools
even if they include DCM-administered risk controls and, notably, even
if the market participant is accessing the DCM via a Futures Commission
Merchant (``FCM'') with additional risk controls. As such, end-users
may not be able to use these DCM-administered tools going forward--
notwithstanding that the use of these tools may result in decreased
fees--due to the high cost and burden that would be associated with the
Regulation AT rules. AGA submits this result is not in line with the
CFTC's commitment to minimizing the burdens and costs of its
regulations on commercial end-users.
AGA believes that subjecting all commercial end-users that use DEA
to access the futures markets to the comprehensive and substantial
requirements in proposed Regulation AT--including the requirement to
register with the CFTC--would run counter to the CFTC's laudable recent
efforts to fine-tune its regulations to make sure that commercial
businesses can continue to use the futures markets effectively. AGA
appreciates that it has been a priority of the CFTC to make sure the
overall regulatory scheme it puts in place recognizes the needs and
concerns of commercial end-users, and that the overall framework is
designed to minimize burdens on commercial end-users who depend on the
markets to hedge normal business risks.\4\
---------------------------------------------------------------------------
\4\ Opening Statement, Chairman Timothy G. Massad, Open Meeting on
Proposed Rule on Margin Requirements for Uncleared Swaps and Final Rule
on Utility Special Entities (September 17, 2014).
---------------------------------------------------------------------------
The American Gas Association appreciates the House Agriculture
Committee's careful review of the CFTC's proposed Regulation AT. The
impact of this rule on end-users, notably gas utilities, may indeed be
substantial, burdensome and costly. We look forward to working with the
Committee, the CFTC and all other impacted parties to see that this
matter is settled appropriately
Respectfully Submitted,
[GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]
Susan Bergles,
Assistant General Counsel,
American Gas Association.
[all]