UNITED STATES OF AMERICA

 COMMODITY FUTURES TRADING COMMISSION

 TECHNOLOGY ADVISORY COMMITTEE MEETING

 

 

 Washington, D.C.

Tuesday, February 23, 2016
 2 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6 

 

7 

 

8 

 

9 

10 

 

11

 

12 

13 

 

14

 

15 

16 

 

17

 

18 

19 

 

20 

21 

 

22

1 

2 

3 

4 

5 

 PARTICIPANTS:

 Opening Statements:

 CHAIRMAN TIMOTHY G. MASSAD

 COMMISSIONER SHARON Y. BOWEN

 COMMISSIONER J. CHRISTOPHER GIANCARLO

Panel I: CFTC Proposed Rule, Regulation Automated

Trading:

 SEBASTIAN PUJOL SCHOTT

 CFTC, Division of Market Oversight

 MARK SCHLEGEL

 CFTC, Division of Market Oversight

 MARILEE DAHLMAN

 CFTC, Division of Market Oversight

Panel II: Swap Data Standardization and

Harmonization

 DAN BUCSA

 CFTC, Division of Market Oversight

 SRINIVAS BANGARBALE

 CFTC, Office of Data and Technology

 RICHARD MO

 CFTC, Division of Market Oversight

 JONATHAN THURSBY

 President, Global Repository Services of CME

 DEREK KLEINBAUER

 Product Manager for Bloomberg Swap Data

 Repository

 MARISOL COLLAZO

 CEO of DTCC
 3 

 1 

 2 

 

 3 

 

 4 

 

 5 

 6 

 

 7 

 

 8 

 9 

 

 10

 

 11 

 12 

 13 

 14 

 15 

 16

 17

 18 

 19

 20

 21

 22

 PARTICIPANTS (CONT'D):

 BRUCE TUPPER:

 Manager, ICE's Global Repository Business

 Panel III: Blockchain and the Potential

 Application of Distributed Ledger Technology to

 the Derivatives Markets

 BRAD LEVY

 Managing Director and CEO, MarkitSERV

 SANDRA RO

 Executive Director, CME Group

 ROBERT SAMS

 CEO, Clearmatics

 JAMES SLAZAS

 CFO, ConsenSys

 Closing Remarks:

 CHAIRMAN TIMOTHY G. MASSAD

 COMMISSIONER SHARON Y. BOWEN

 COMMISSIONER J. CHRISTOPHER GIANCARLO

 * * * * *
 4 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 P R O C E E D I N G S

 (9:45 a.m.)

 MR. GRIFFIN: If everyone could please

 take their seats.

 CHAIRMAN MASSAD: Could you please take

 your seats? We're going to start.

 MR. GRIFFIN: Everyone, if you'd take

 your seats, we're going to get started.

 COMMISSIONER BOWEN: Sit down,

 everybody.

 REPORTER: Because of the way the room

 is wired, you're not going to hear yourself.

 MR. GRIFFIN: Okay.

 REPORTER: Okay, we've got eight

 different zones.

 MR. GRIFFIN: Okay.

 REPORTER: This is one. He won't hear

 it.

 MR. GRIFFIN: All right, all right,

 fine. There you go.

 Good morning. My name is Ward Griffin,

 and as the Designated Federal Officer of the
 5 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Technology Advisory Committee and acting chair for

 this meeting, it is my privilege to call the

 meeting of the Committee to order. Thank you for

 your efforts as we worked to reschedule this

 meeting following last month's blizzard here in

 the D.C. area.

 We have a packed agenda today, and to

 begin I'd like to offer an opportunity for

 Chairman Massad and Commissioners Bowen and

 Giancarlo to make their opening remarks.

 Mr. Chairman.

 CHAIRMAN MASSAD: Well, good morning,

 and thank you all for taking the time to be here,

 particularly those of you who have flown in. We

 really appreciate it. We're glad there wasn't a

 snowstorm. I understand there were some weather

 challenges for some of you, so we're glad you're

 here. I want to welcome all of you to this

 meeting of the CFTC's Technology Advisory

 Committee.

 You know, for more than 15 years, the

 Commission has relied on the TAC for guidance on a
 6 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 wide range of technology issues, and since I took

 office I've made it a priority to focus on

 technological changes taking place in our

 marketplace, and the TAC has provided an excellent

 forum to exchange ideas, discuss issues of

 importance, and engage with market participants.

 And I know Commissioners Bowen and Giancarlo share

 my desire to make sure we are looking at

 technological issues.

 And of course we had a little bit of a

 hiatus in the meetings of this Committee.

 Commissioner Wetjen was the commissioner that was

 kind of responsible for this, so when he left we

 were scrambling and we had more committees than we

 had commissioners. But we were glad that we were

 able to reconvene today, and we'll try to move

 forward with a regular schedule.

 I think today's meeting is particularly

 important, because we're going to address a few

 issues that are at the top of the Commission's

 agenda. I want to also thank the CFTC staff, who

have worked tirelessly to plan this meeting --
 7 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 particularly Ward Griffin, for all the work that's

 gone into that.

 The first thing is we're going to

 discuss the Commission's proposed rule to address

 the increased use of automated trading in our

 markets. And as all of you know, automated

 trading has dramatically expanded in recent years.

 It's brought many benefits to market participants,

 such as more efficient execution, lower spreads,

 and greater transparency, but its extensive use

 also raises important policy and supervisory

 issues.

 We have proposed a rule, as you all

 know, that builds upon the steps that we and the

 exchanges have already taken. It focused on

 principles-based industry best practices to

 mitigate operational risks and minimize the

 potential for disruptions or other problems. And

 it includes requirements for pre-trade risk

 controls and other types of measures, but it does

 not describe the parameters or limits of such

 controls. So, we're going to look at a few issues
 8 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 on that. Obviously, we can't look at all issues

 that are covered by the rule, but we will have a

 good discussion today of some of those issues, and

 of course the comment period remains open for your

 input generally.

 Second, we will discuss our efforts to

 improve the quality of swap data reporting. This

 has been a key feature of the reforms enacted by

 Dodd-Frank, and we have come a long way since 2008

 when we basically had no insight into the

 over-the-counter swaps market. We do have much

 better information today.

 But building out the system to collect

 and analyze all this data is a very significant

 project. We're taking a number of actions to

 enhance the quality of the data, and today we will

 focus on one aspect of our actions, which is our

 efforts to ensure greater consistency in the data.

 Currently, there's a lot of variation in how

 different participants report the same fields to

 swap data repositories and then in turn how the

 SDRs themselves transmit the information to the
 9 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 CFTC. We have made a dedicated effort to focus on

 that issue and to identify a number of priority

 areas where we think standardization or

 clarification is needed, and the staff has

 recently solicited public input on 80 specific

 questions addressing 120 data elements. And so

 from the discussion we'll have today and the other

 feedback we get on this, the staff is hoping to

 develop proposals that specify the form, manner,

 and allowable values that each data element can

 have.

 And finally today we will discuss

 blockchain technology and its potential

 application to the derivatives market. I know

 many of you are thinking about this and looking at

 it. We are quite interested in hearing your

 thoughts about this, and I hope we can have a

 discussion today that gets into some of the

 specifics -- and avoids maybe some of the hype --

 but really looking at the potential for blockchain

 or distributed ledger technology in this industry.

 In what specific areas could there be applications
 10

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 that might bring benefits or improvements? And

 what are the disadvantages and advantages of

 those? What are the limitations of those?

 So, again, thank you all for coming and

 lending your voice and experience. It means a lot 

 to us. And with that I will turn to Commissioner

 Bowen.

 COMMISSIONER BOWEN: Thank you, and good

 morning. It's a pleasure to be here today for a

 meeting of the reconstituted Technology Advisory

 Committee. I want to thank the staff and the

 Committee for the time you've devoted for today's

 topics. The Committee clearly has its work cut

out for it today, so I'll be brief.

 As I've said before, changing technology

 is causing a sea change in how our markets

 operate. That's particularly true of the three

 issues the Committee will be discussing today.

 I've already spoken several times about

 the remarkable changes caused by the rise of

 algorithmic trading and the positive impact that I

believe our proposed regulation automated trading
 11

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 will have on market stability. However, this

 regulation is, to me, only a first cut. I want to

 hear from you if you believe our new rule is

 failing to address aspects of algorithmic trading

 that pose system risk or pose undue risks to

 ordinary investors. I'm absolutely willing to

 take additional steps to craft additional

 appropriate regulations on this nascent

 technology. In that regard, I look forward to the

 Committee's thoughts on our proposal, including

 whether we have overreached or even under-reached.

 The second topic before us today, swap

 data standardization and harmonization, may be

 less heralded than algo trading, but I believe it

 is no less important.

 Our new rules regulating the swap

 markets have substantially increased systemic

 stability and reduced the risk of major market

 events. But our rules cannot work without

 accurate data. And to have workable data requires

 robust, widely-accepted data standards. Our staff

 has made great strides in the last few years
 12

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 towards standardizing the most important aspects

 of data but more work remains. Until all of our

 key data is standardized and easily usable for

 analytics and surveillance, we cannot say that the

 Dodd-Frank regime is complete.

 Finally, what can I say about the

 blockchain that has not already been said? I'm

 fairly confident that the vast majority of the

 press covering today's event have spent

 significant time discussing or reporting some

 aspect of this new innovation, from 

 crypto-currencies' value swings, to legions of

 bitcoin miners, from blockchain cyber security

 developments, to the technology's myriad early

 adapters. This technology, which is even more

 nascent than algo trading, carries with it

 tremendous potential for electronic trading and

 electronic commerce more broadly.

 Yet, before we can use this technology,

 we need to understand it. No one from industry to

 regulators or consumers is served if we run

 head-long toward adopting a new technology that we
 13

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 all do not understand. I therefore hope that

 today's discussion on the blockchain's ledger

 technology, its public data file of all the

 transactions, can be safely distributed to the

 derivatives markets.

 Now, to date myself, I graduated from

 law school before Apple introduced the Mac. So,

 I've been a securities and corporate lawyer in the

 pre-digital world, and while I'm quite familiar

 with online e-commerce and mobile payment systems,

 more recently I've been following current news

 about the blockchain and crypto currencies

 generally.

 Well, like many people in public, I'm

 still learning. So, I not only look forward to

 today's discussion, but I also want to urge

 everyone to try and make sure that we don't skip

 over some baseline facts as we delve into these

 issues. But those of you who are experts who

 perhaps spend hours in the bitcoin sub-forum in

Reddit or elsewhere on the Internet, innovate with

 care and be mindful of the rest of us.
 14

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Thank you.

 COMMISSIONER GIANCARLO: Thank you. The

 electronification of trading over the past 30 to

 40 years -- actually since before Commissioner

 Bowen, the Chairman, and I all graduated from law

school -- and the advent of exponential digital

 technologies have transformed financial

 businesses, markets, and entire industries with

 dramatic implications for capital formation and

risk transfer. We see this change most presently

 in the area of automated trading that now

 constitutes over 70 percent of regulated futures

 markets.

 Automated trading presents new

 challenges to the continuing viability of

 traditional market regulation, and how 21st

 century markets adjust to this evolution from

 human to automated trading is critically

 important. Last November, the Commission voted to

 propose Regulation AT. I questioned then whether

 the merits of the proposal outweigh its additional

 costs and burdens, and I raised special concern
 15

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 about requiring registrants to hold proprietary

 source code in data repositories available for

 inspection by the CFTC or the U.S. Department of

 Justice at any time and for any reason without a

 subpoena.

 Yet, a broader concern is that, in

 essence, Reg. AT is a registration scheme. The

 relatively simple process of registering AT users

 does not begin to address the hard public policy

 considerations that arise from the digital

 revolution in modern markets:

 What do essential legal concepts like

 mens rea, scienter, and "failure to supervise"

 mean in transactions initiated by artificial

 intelligence rather than by direct human action?

 How do we adapt regulatory frameworks

 designed to catch "bad guys" to catch tomorrow's

 "bad algos?"

 And how do we recondition 20th century

 trading markets and their essential institutions

 to benefit from 21st century automated trading

 while maximizing marketplace safety, soundness,
 16

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 efficiency, resiliency, and liquidity?

 These difficult policy issues can only

 be considered with deep technological expertise,

 industry-wide dialog, and thoughtful analysis.

 And that is our purpose today.

 I also look forward to our second panel

 on swap data standardization and harmonization.

 At the heart of the 2008 financial crisis was the

inability of regulators to assess and quantify the

 counterparty credit risk of large banks and swap

 dealers. The legislative solution was the

 establishment of swap data repositories and

 enhanced market data analysis. Yet, 7 and a half

 years after the financial crisis we still do not

 have accurate visibility into global swaps

 counterparty exposure. Of all the many mandates

 to emerge from the financial crisis, swaps market

 transparency was perhaps the most pressing. The

 failure to accomplish it is certainly the most

 disappointing.

 Prior TAC meetings have well documented

 the challenge facing the Commission in optimizing
 17

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 swaps market data. They range from field

 standardization and data validation to analysis

 automation and cross-border data aggregation and

 sharing.

 A key challenge of swaps market analysis

 is the lack of global standardization. Market

 participants vary widely in how they report the

 same data field to SDRs that, in turn, differ in

 how they report to the CFTC. I fear that the CFTC

 and its overseas regulatory counterparts, acting

 by themselves, will continue to struggle to

 achieve the important objective of full visibility

 into swaps counterparty exposures.

 Swaps market analysis is essentially a

 big data problem -- the kind of problem that is

 tackled every day in America's technology

 corridors from Brooklyn to Silicon Valley. What

 is needed in Washington is a concerted and

 cooperative effort by regulators, market

 participants, commercial technology vendors, and

 academia that draws on the emerging fields of big

 data analysis, network science, and financial
 18

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 cartography. It's long past time to broaden this

 important implementation.

 I welcome the TAC's input on this and

 other swaps data reporting challenges.

 Finally, blockchain. In a recent

 podcast I spoke about the potential benefits to

 financial market infrastructure from the

 application of distributed open ledger technology,

 and at risk of increasing the hype, this is indeed

 a development that has enormous implications for

 financial markets in payments, banking, security

 settlement, title recording, cyber security, and

 the process of collateral management and

 settlement. It may make possible new "smart"

 securities and derivatives that could

 revolutionize operational and transactional

 efficiency. It may help reduce some of the

 enormous costs of the increased financial system

 infrastructure required by new laws and

 regulations, including Dodd-Frank.

 We regulators must cultivate and embrace

 new technologies, such as the blockchain, that
 19

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

hold important promise for our financial markets

 and their greater service to our country.

 So, I'm pleased that the TAC will be

 discussing these and other issues, and I look

 forward to a very productive meeting today. Thank

 you all for coming and bringing your expertise and

 thoughts.

 MR. GRIFFIN: Thank you. Before we turn

 to our first panel, it would be helpful if we go

 around the table and ask each of our TAC members

 to introduce themselves and the organizations that

 they represent.

 

 

Paul, would you like to start us off?

MR. CHOU: Thank you, Ward. My name is

 Paul Chou. I'm the CEO and Chairman of Ledger X,

 and Ledger X is a current applicant for

 registration as both a SEF and DCO, and we are

 entirely focused on bitcoin derivatives and so

 very much looking forward to the conversation

 today for perhaps obvious reasons.

 

 

Thank you.

MS. COLLAZO: Hi, I'm Marisol Collazo.
 20

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 I'm a managing director at DTCC. I'm the CEO for

 our U.S. swap data repository, and I look forward

 to the discussion on data standardization.

 MR. DURKIN: Good morning. I'm Bryan

 Durkin, Chief Commercial Officer for CME group and

 delighted to be invited back as a member of this

 Committee.

 

 

 Thank you.

 MR. GORELICK: Good morning. My name is

 Richard Gorelick. I'm the CEO of RGM Advisors, a

 proprietary trading firm in Austin, Texas.

 MR. HEHMEYER: Good morning. I'm Chris

 Hehmeyer. I was chairman of the National Futures

 Association for the last four years. I run a

 prop. trading firm in Chicago, and I was in the

 FCM business for 25 years.

 MR. JOACHIM: Good morning. I'm Steve

 Joachim. I'm the Executive Vice President for

 Transparency Services at FINRA with people that

 bring you TRACE.

 MR. LAMY: Good morning. I'm Pierre

 Lamy, a managing director in the Technology
 21

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 Division of Goldman Sachs.

 MR. LEVY: Hi, Brad Levy, managing

 director at Markit. I run one of our product

 division's processing, and I'm the CEO of

 MarkitSERV and oversee our blockchain initiatives

 within Markit. And I'm pleased to be added to the

 TAC at this point. Thank you very much.

 MR. LEWIS: Cliff Lewis. I'm here

 representing Eris Exchange. I see a lot of old

 friends that I've known for -- we're trying to

 figure out how many decades. But it's fun to have

 seen the industry evolve to the point -- when I

 started there wasn't any need for a technology

 committee.

 

 

 Thank you.

 MR. TABB: Larry Tabb, founder and CEO

 of Tabb Group, and we write financial markets

 research, and I'm happy to be part of the TAC.

 MR. GRIFFIN: Thank you and if -- oh,

 all right. If I could just ask everyone -- I 

 think there are some issues with the sound. If

 you wouldn't mind just leaning in and speaking up.
 22

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Don't be bashful.

 We also have a few of our members who

 were planning on calling in. I want to take the

 opportunity to invite them to introduce themselves

 if they're on the line.

 MR. TRAHAN: Yes, Ward, this Jeff

 Trahan. I'm Vice President of Pensions at Deere &

 Company and formerly the treasurer, where we are a

 pretty extensive user of derivatives.

 MR. GRIFFIN: Thanks, Jeff. Anyone

 else? Great. Turning now to our first panel, I

 would like to welcome Sebastian Pujol Schott,

 Marilee Dahlman, and Mark Schlegel -- all from the

Commission's Division of Market Oversight -- to

 get us started with a discussion of the

 Commission's proposed rule, Regulation Automated

 Trading, or Reg AT.

 MR. SCHOTT: Thank you, Ward, and thank

 you to the members of the Commission and the

 Technology Advisory Committee for taking the time

 today to share your thoughts on our proposed rules

 for automated trading. As a reminder, Regulation
 23

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 AT, or Reg AT, was published in the Federal

 Register on December 17, 2015. It remains open

for public comments through March 16th. The staff

 has already held a number of informative meetings

 with interested parties, and we encourage and look

 forward to comment letters on the proposed rules

 as well as to meeting with anyone who would like

 to talk with us.

 This morning, I'm going to provide a

 very brief overview of Reg. AT, of its purpose and

design, also with a particular focus on the

 elements that we will delve into further in

 today's conversation.

 First, as a threshold matter, it's

 important to note, Reg AT is intended to reduce

 risks and increase transparency in automated

 trading. It identifies points where operational

 risks may be introduced into the trading ecosystem

 and proposed as a series of related measures for

 mitigating and managing such risks. In this

 regard, Reg AT follows recommendations from many

 industry best practices in adopting a multilayered
 24

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 approach to risk control and in addressing the

 role of order originators, FCMs, and exchanges in

 the life cycle of each automated order. This

 multilayered approach to risk controls will be one

 of the topics we discuss this morning.

 Second, in proposing risk controls, Reg

 AT makes an effort to provide flexibility and rely

 on existing industry best practices wherever

 possible. For example, the proposed rules provide

 latitude around the design and calibration of

 required pre-trade risk controls and around the

 design and implementation of self-trade prevention

 tools. In fact, many of the specific pre-trade

 risk controls posed in Reg AT are existing

 elements of best practices in industry.

 At the same time, the proposed rules

 attempt to promote the responsible use of such

 flexibility through, for example, annual reporting

 from each market participant regarding how it has

 chosen to implement and calibrate its own risk

 controls. Both the specific mix of pre-trade risk

 controls and the proposed rules around
 25

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 self-trading will be another topic of discussion

 today.

 Finally, I'd like to emphasize that Reg

 AT is a proposed rule, and it is a proposed rule

 that asks over 160 questions over almost every

 element of the proposal. From a staff

 perspective, readers should hopefully see a

 consistent approach where each proposal is

 balanced by one or more questions around whether

 the Commission has identified the best way to get

 from point A to point B or even whether the goal

 is the appropriate goal.

 With that in mind, I'd like to highlight

 a third aspect of Reg AT and the one with which we

 will begin today's conversation, and that is the

 importance of key defined terms in establishing

 the scope of the proposed rules. These include,

 for example, the proposed definition of the term

 "algorithmic trading" and the proposed definition

 of the term "direct electronic access." These

 terms are fundamental in that they define who's

 in, who's out, and what activities are covered by
 26

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 proposed Reg AT.

 In closing, let me say that Commission

 staff is aware of the time and of the effort

 required to engage substantively with the proposed

 rules. We look forward to your comment letters,

 and we are very appreciative of the time that it

 takes to write a letter, so thank you for all of

 you who produce them.

 Ward, I think if you would like at this

 point we can bring up some slides to guide the

 conversation.

 MR. GRIFFIN: Good. Thanks, Sebastian.

 As Sebastian noted, we're going to begin the

 discussion with an examination of the scope of the

 underlying rule, in particular, as Sebastian

 noted, a couple of key terms, and to begin that is

 the proposed definition of "direct electronic

 access."

 Really, the question has been raised not

 only in the proposal but in a number of the

 meetings that have followed since the proposal was

 published. A question as to whether these
 27

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 definitions are capturing the right population:

 Are they over-capturing? Are they under- 

 capturing? And certainly this notion of direct

 electronic access is foundational to that

 question. So, I'd like to open that up at this

 point.

 

 

 Sebastian.

 MR. SCHOTT: Thank you, Ward. And one

 thing I could add is that, you know, as the

 discussion focuses on this term, it's important to

 know that direct electronic access plays an

 important role in an item that Commissioner

 Giancarlo mentioned, which is: it is a trigger for

 the new registration requirement. So, it's one of

 the prongs that would lead to registration.

 MR. SCHOTT: Richard, would you like to

 kick us off?

 MR. GORELICK: I'd be happy to. Thank

 you, Ward. So, I appreciate the opportunity to

 participate in this important discussion. The

 purpose of this Committee has been to foster

 dialog on the role of technology and automation in
 28

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 today's modern electronic markets, and with Reg AT

 we again return to that topic.

 There is already a substantial public

 record in this regard. This Technology Advisory

 Committee has repeatedly discussed market

 structure issues and risk management practices at

 exchange trading firms and clearing firms. We met

 two years ago to discuss the Commission's concept

 release on automated trading, and this discussion

 and the concept release itself created a useful

 and detailed record of the various control

 safeguards and surveillance procedures that have

 been put in place by the industry over recent

 years.

 I also believe that the empirical

 evidence that's been discussed at the Technology

 Advisory Committee presented over the years has

 shown that increasing automation and competition

 have made markets on balance more efficient, more

 liquid, more transparent, and lower cost for

 investors and hedgers. But I'm not here to defend

 the status quo. We can always do better, and we
 29

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 should always strive to improve the quality and

 resilience of the markets. I've consistently

 supported a regulatory environment that promotes

 their competition, encourages innovation, enhances

 transparency, manages systemic risk, lowers cost

 for investors and hedgers, and gives regulators

 the tools that they need to detect and deter

 market abuse. It's important to note that, in

 general, moves towards open, electronic,

 centrally-cleared markets further these valuable

 objectives.

 Overall, while well intentioned, I find

 that the Reg AT proposal that currently stands is

 somewhat confusing. In some places, it's too

 broad and in others too narrow. While some

 provisions are certainly helpful, others may be

 counterproductive. I don't have time today to go

 into much detail, but I'm concerned that Reg AT

 could amount to a whole lot of work by the

 industry and by the Commission to accomplish

 relatively small gains in market integrity and

 would risk negative unattended consequences. I'll
 30

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 touch on a few concerns today.

 First of all, the source code provisions

 are very concerning. The proposed requirement to

 turn over valuable IP to the government as part of

 a simple document request is simply unprecedented

 and unreasonable. It violates standards of due

 process. The secret formula for Coke Cola and the

 source code for Google Search algorithms are not

 available on demand to regulators without a

 subpoena.

 A trading firm source code is no

 different. Many modern trading firms are very

 much technology businesses. Much of our staff

 writes software, and our source code contains

 valuable IP. The proper protection of

 intellectual property lies at the heart of our

 private enterprise system. Government agencies

 must make a reasonable showing of cause and get a

 subpoena to gain access to private intellectual

 property. Moreover, it would set a dangerous

 precedent with foreign governments, such as China,

 who have sought to impose similar source code
 31

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 requirements on U.S. firms.

 I appreciate that the Commission has

 indicated a willingness to revise these

 provisions, as this part of Reg AT must be fixed.

 Next, much of -- it seems to be cutting

 in and out. Is it? Can everyone hear me okay?

 Okay.

 Next, much of the role is geared toward

preventing the defined term of algorithmic trading

 events, which are defined to include both

 algorithmic trading compliance issues and

 algorithmic trading disruptions. Both

 definitions, in my opinion, are too broad. For

 example, Reg AT would make not following a firm's

 own internal policies an algorithmic trading

 compliance event. The more comprehensive a firm's

internal policies, the more liability they would

 risk. Counterproductively, rational actors would

 be incentivized to have internal policies and

 procedures that only do the bare minimum required

 by law.

 Similarly, Reg AT would penalize firms
 32

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 for disrupting or materially degrading their own

 trading. This makes no sense to me and might

 encourage firms to continue trading in the face of

 potential risk management issues. These

 provisions should be eliminated from their

 respective definitions.

 On the other hand, some provisions are

 too narrow. For example, the requirement for

 firms to have pre-trade risk controls is limited

 to firms that are using algorithms. Firms that

 conduct electronic keyboard trading would have no

 such requirements. In my view, pre-trade risk

 control should be required broadly for all firms

 conducting electronic trading.

 The SEC's market access rules should be

 studied as a possible alternative approach. These

 rules were introduced to require pre-trade risk

 controls for all firms with electronic market

 access and do not hinge on whether a firm uses an

 algorithm or not.

 It should be noted that when the SEC

 studied volatility spikes in the equities markets,
 33

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 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.

 We should also consider that the futures

 exchanges already have robust pre-trade risk

 controls for all users with limits configured and

 managed by FCMs.

 I also continue to question the need for

 a new CFTC registration requirement, given that

 the Commission already has extensive access to

 information in exchange audit trails and

 membership files.

 The cost benefit test is elusive, and it

 is curious how or why proprietary trading firms

 with direct electronic access who use trading

 algorithms but who never set foot on the trading

 floor would fit into the definition of floor

 traders. If the CFTC believes it has a gap in its

ability to supervise some trading firms, I believe

 it should propose that registration requirement

 separately.
 34

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Altogether, the rule seems to impose

 costly burdens on the broad and growing group of

 firms using algorithms to trade in the futures

 market without commensurate benefits. The markets

 are dynamic and constantly changing. Mandated

 risk controls, documentation, training, audits,

 reporting, certifications like those in Reg AT

 that are too prescriptive could quickly become

 obsolete as markets, technology, and training

 strategies evolve.

 Creating checklists and written policies

 might give the appearance of reform but in

 practice don't make markets safer or more

 resilient and could instead create unintended

 incentives to the contrary. I think it's worth

 understanding that the primary new requirements in

 Reg AT, from my read, are to create lots of

 safeguards, lots of laws, lots of policies and

 procedures around things that are already

 prohibited by law.

 Costly new rules will limit the ability

 of smaller firms to compete in these markets and
 35

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 reduce competition and should be expected to

 ultimately harm market quality and raise trading

 costs for investors and hedgers. 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 make the markets safer and more

 efficient, and I look forward to working with the

 Commission and its staff on solutions to help

 achieve the right balance.

 

 

 Thank you.

MR. GRIFFIN: Thank you, Richard.

 Focusing back on just trying to look at the scope

 itself in terms of who will be captured really on

 this first prong of the discussion, the activities

 that would trigger coverage under the rule, with

 respect to direct electronic access, are there any

 thoughts or feedback that Committee members might

 want to give with respect to how that is

 formulated? Is there a breadth issue either,

 again, too inclusive or not inclusive enough that

 you'd like to share?
 36

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. HEHMEYER: Chris Hehmeyer from NFA.

 I have my NFA hat on, and in reading Reg AT and

 the proposed -- which I compliment the Commission

 for putting this out there and casting the net

 broadly to get the conversation started. And so I

 certainly would guess that from your chair that's

 a good way to start to approach this.

 From NFA's perspective, some of the

 language in the preamble conflicts with some of

 the language that's in the proposed regulations.

 In the internal memo that we had, the term was

 used "strikingly broad," and this has come out, I

 know, in some of the legal conferences where

 lawyers have gotten together to try to debate what

 exactly the ramifications are for the way that

 it's currently written.

 NFA is not looking to try to extend its

 footprint over the automated traders. NFA

 certainly stands ready to take on responsibilities

 if the Commission sees that NFA should do that.

 But it's important that if they, for instance,

 were to become -- the automated traders were to
 37

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 become members of NFA, that NFA has got, then,

 enforcement responsibilities if those don't

 conflict with the exchanges. And the exchanges

 have a lot more experience in dealing with the

 proprietary traders and the automated traders, and

 so getting this definition right is very key. And

 I know that there are a lot of people that

 certainly are willing to pitch in and try to help

 get it right between private enterprise and

 government.

 But it's very important -- I have a

 letter from -- I pulled out my TAC file, and I

 have a letter from Commissioner O'Malia thanking

 me for coming to the Committee and imploring us to

 try to get the definition of HFT correct from

 2011. So, we've been at this for a while. And

 it's tricky. It's not a -- I'm not -- in NFA, the

 discussion is not one of throwing up our hands,

 "Oh, my gosh, I can't believe this." It's a

 tricky proposition to try to get this definition

 correct and to try to accommodate the interests of

 trying to have the markets thrive by the prop.
 38

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 traders, the exchanges who have a lot of

 experience with this, and the public that wants

 some sort of oversight, which the Commission and

 the NFA could possibly provide.

 So, I just say all of that in that it's

 important to try to get this right and possibly a

 subcommittee of some people representing those

 different groups would be one that could try to

 knock out this language. And I think a lot of the

 comments will be along those lines of trying to

 make sure this definition is a good one.

 

 

MR. GRIFFIN: Steve.

MR. JOACHIM: Yes. To comment on what

 Richard talked about, I think that from FINRA's

 perspective --

 CHAIRMAN MASSAD: Steve, can you speak

 up?

 MR. JOACHIM: Sure. When we look at Reg

 AT, we see many similarities in actions the SEC

 has taken or FINRA has taken, and we want to

 compliment you on the coordination. We think,

 though, that it is critical, especially as we move
 39

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 forward in these new automated spaces -- not so

 new but in terms of regulatory activities -- that

 we stay very heavily coordinated and we keep our

 actions in synch because so many of the electronic

 environments or automated environments are

 cross-product and cross-markets.

 Being sure that we're staying in synch

 thinking about these markets in the same way,

 thinking about the approaches to the regulation of

 those environments in the same way is important,

 while recognizing that there are differences in

 the markets and there are clearly some traders

 that will operate in only one market rather than

 another. But it is important to get the core

 concepts so that the SEC, the CFTC, and FINRA are

 all working and coordinating our actions in a way

 that will move the market forward and our

 visibility of the markets more insightful and more

 accurate.

 MR. GRIFFIN: Bryan, before you go, if I

 could just ask Committee members: If you'd like

 to make a comment, if you'd just flip that up that
 40

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 would be very helpful. Thank you.

 

 

 Bryan.

 MR. DURKIN: First of all, please allow

 me to compliment you in terms of the work that

 you've done in preparing this. It's been, boy, I

 think a five-year effort in terms of the work that

 we've all collectively done as part of the

 Technology Advisory Committee, and a lot of those

 efforts were reflected in the proposed rulemaking

 and we thank you for that in terms of

 acknowledging the advances that the industry and

 the Commission collectively have done together to

 adopt best practices.

 And, Sebastian, you highlighted that the

 main kind of focus is to preserve and protect the

 integrity of these marketplaces that we all

 represent. We couldn't agree with you more on

 that priority.

 The rulemaking or the proposed

 rulemaking itself is so extensive that there are

 areas of complexity that I think are making the

 ability to define what should be, like, the chief
 41

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 priority for us to be able to move together even

 more difficult to discern. And we would just

 proffer an idea to separate out the registration

 requirements that are proposed here, because there

 are a lot of complexities just associated with how

 those requirements would be applied, and we'll get

 into those in great detail when we submit our

 response.

 But, you know, how would this apply to

 various users in the marketplace? How would ISBs

 be brought into this, or wouldn't they? So,

 there's a lot involved in the application of that

 definition itself. And so we're wondering, might

 it be prudent to separate that from the risk

 controls that we all want to get right for the

 marketplace in terms of, you know, the good

 efforts that have been undertaken by various

 industry constituencies, the DCMs -- the CFTC has

 proffered and has implemented certain requirements

 itself?

 There's a lot of good that's been

achieved there, you know, as a starting point:
 42

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 What's working well with those controls? Where

 should we be taking them a step further? As we

 talk about the order routing food chain itself and

 the application and parameterization of those

 controls, there's a great deal of complexity

 associated with how these would be applied. I'm

 heartened to hear you say today that this was

 developed with a certain mindset of flexibility

 associated with the application of these controls.

 It didn't come out that way in the

 report. Where it says that there may be some

 flexibility, there are also very, I think,

 granular approaches that have been taken in terms

 of how these are to be applied across every aspect

 of the order routing process from, so from the AT

 level to the FCM to the clearing firm to the DCM.

 So, I really feel that we could do well working

 together to kind of delve into that a bit more

 deeply so that we're all very, very much aligned

 and clear in terms of how best those should be

 applied.

 MR. GRIFFIN: Larry.
 43

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. TABB: Thanks, Ward. I want to ask

 a question. I don't want to put too many people

 on the spot but, Rich, you talked about the IP

 issues involved with registering algos and things

 like that, and I guess the question would be to

 Rich and Chris -- you're a proprietary firm -- and

 I guess, Pierre, from a Goldman Sachs perspective.

 You guys, the three of you, have been involved

 with developing algos. What, you know, not

 necessarily from an RGM perspective but more on a

 theoretical basis, what's the impact of having

 this IP, you know, put into a registry? Would

 that impact how you write algos? Or is this just

 more issue that you don't want other people -- you

 know, the risk of people looking at it and they

 jeopardize you? Would that change kind of how you

 think about writing algos? Would that reduce the

 quality of the algos that you put into the market?

 Would it force you to think about do I really want

 to be in the futures market? I don't know, what

 kind of -- you know, and you don't have to

 actually answer for RGM. I (inaudible -- mic
 44

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 noise) for proprietary issues, but theoretically,

 you know, how does that impact? And I guess the

 same would be for Goldman or for Chris from your

 history.

 (Interruption)

 MR. GORELICK: Okay, we'll try this.

 So, from my perspective, I'm not sure that it

 would change the way firms actually write their

 algorithms. I'm not sure that that is an

 important factor. But it certainly may affect

 firms' willingness to participate in the futures

 market but, if it does, cause them to expose their

 IP to turn over to regulators or the government

 agencies without due process.

 I would say that from my perspective,

 the risks that go along with that are pretty

 standard. When we have the IP within our firm,

 it's our responsibility to protect it as we see

 fit, and when that is out of our firm, whether

 it's with a government agency or with anybody, any

 third party, really we lose that control, and that

 intellectual property becomes vulnerable to folks
 45

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 leaving the agency and going into private business

 and working for competitors. That would be a

 concern. Cyber security certainly becomes a big

 concern when you have code or valuable IP from a

 variety of firms at one location that might become

 an appealing target for hacking, and the like.

 So, I think the general issue is we lose the

 ability to protect that IP once it's out of our

 shop.

 MR. HEHMEYER: I agree with Richard.

 The question of due process is above my pay grade.

 I'm not sure about how the law works, but

 instinctively the idea that private enterprise

 trade secrets just have to be made available at

 any time to any government person that feels that

 they should be taking a look at it without a

subpoena without justifying why they believe a

 market's being manipulated, which they certainly

 have the power to do today, is one that certainly

 in our industry is cause for, well, what is it

 that's hoped to be gained by having the trade

 secrets always available as opposed to a subpoena.
 46

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 However, I will point out that it's lost

 on many people that for the members of the

 exchanges that CME certainly has that power today.

 We've got a tag 50 that's sending orders that they

 believe may be manipulating a market and CME shows

 up tomorrow and says, we want to see the code that

 belongs to this trade identifier, that we'd show

 it to them or be out of business. So, a lot of

 that is available in oversight, but it's

 protected. The government issues get much

 broader, as I say, on the legal side of it as

 Richard I think described. But I think there is

 this concern in the industry of trade secrets

 always available to government.

 MR. LAMY: Yes, Pierre Lamy from Goldman

 Sachs. I second what Richard was saying. The

 concern is the risk that -- increased risk that

 this information could be leaked outside through

 cyber security threats and the like and also the

 fact that besides increasing the risk is

 decreasing the right of knowledge that we would

 have, that the information has been linked because
 47

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 information is more broadly available and more

 broadly disseminated.

 MR. GRIFFIN: I know we have a couple

 extra cards up, but -- Mr. Chairman.

 CHAIRMAN MASSAD: Yes. I appreciate the

 comments on the source code issue. We certainly

 heard previous comments to this effect.

 And let me just say, you know, source

 code is not the first and it's not the only form

 of confidential information that this Commission

 has access to or has had access to, and protecting

 confidentiality of information is incredibly

 important to what we do, and to the markets. Our

 job is to preserve the integrity of the markets.

 We can't do that if we can't do our job in a way

 that protects confidential information.

 I'd like to suggest -- I mean, Reg AT is

 a big rule. There are a lot of aspects. We only

 have a limited time today, and I think we tried to

 tee up -- I think Ward and the staff tried to tee

 up -- a couple of specific issues that we might

 talk about, the first being this kind of scope
 48

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 question, the second being whether we've got the

 right package of risk controls, and I think the

 third, I believe, is the self-trading.

 We could have picked other issues, of

 course, and all of you, of course, are invited to

 submit written comments to us. But if we could

 try to focus the discussion on a few issues, I

 think it will be more productive. And maybe as a

 way of doing that, just so I understand the

 comments that Bryan and Richard made earlier in

 terms of separating the registration requirement,

 that's not quite the issue that was teed up. But

 it is related, because, you know, I think Ward, by

 teeing up the definitions, was really trying to

 get at are we capturing the right universe of

 participants, if you will.

 If you separated the registration

 requirement, wouldn't that mean that we're just

 talking about a package of risk controls that

 would essentially apply to the exchanges and the

 FCMs and, I guess, maybe anyone who's otherwise

 registered with us already -- We could say, you're
 49

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 subject to it also.

 But I want to make sure I understand

 what the thrust of that suggestion means.

 MR. DURKIN: May I comment now? So,

 embedded under the risk controls, there are a

 number of controls that today are in place based

 on best practices. There are other ones that are

 suggested or represented in here that, you know,

 we don't feel that the Commission has a full maybe

 appreciation or understanding of how they're

 applied today and how those would be applied

 according to this rule down to the granular level

 of the actual AT person and how these controls

 would be expected to be parameterized and whose

 responsibility would it be.

 There's a lot that appears to be

 incumbent on the DCM itself in terms of its

 understanding, knowledge, or awareness of the

 actual AT user and how they might interface, you

 know, with the platform and having some

 obligations associated with how those controls are

 affixed, where today those would be under the
 50

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 control of the FCM. They'd have the capabilities

 to have far more granular application down to the

 account level or the individual. It doesn't seem

 clear to us in the report that that's what's

 intended today. It looks like you're expecting it

 to put more of that on the part of the DCM as it

 applies to the clearing firm, to the FCM, and to

 the individual AT user.

 So, we may be confused in terms of how

 we're interpreting it, right? And, you know, we

 need more clarity in that regard, and we're fully

 prepared to lay that out in the context of our

 comments, Mr. Chairman. But this is the area

 that, you know, this group has focused on

 immensely over the last several years, and I feel

 that it is -- or we feel it's an area that we're

 all fully aligned, in terms of the intent and

 purpose, and we just -- we would suggest we should

 focus on trying to get that part of it right and

 make sure that we're all clear on what the

 expectations would be and what would be required

 under the federal requirements themselves.
 51

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 CHAIRMAN MASSAD: I'm sorry, just to be

 clear, "that part" being?

 

 

MR. DURKIN: The risk controls, sorry.

CHAIRMAN MASSAD: But, again, then --

 maybe, Sebastian, you can help me out. Who would

 they then apply to?

 MR. SCHOTT: Yes, so I think the

 question, Mr. Chairman, is a very good one. If

 the focus is on getting the controls right --

 

 

CHAIRMAN MASSAD: Right.

MR. SCHOTT: Assuming that there are

 things that need to be amended in the proposal in

 that regard, even if we arrive at a perfect set of

 controls, they would be limited only to the

 existing registrant population, and so the

 question may be, you know, Mr. Chairman, is what

 happens to the unregistered part of the market

 that is a large part of the market, that can have

 a significant part of the market no matter how

 well we get the controls, no matter how perfectly

 we devise a set of controls? If they're not

 applicable to a group of people, then, you know,
 52

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 how much are we moving the ball forward?

MR. DURKIN: May I respond.

 CHAIRMAN MASSAD: Go ahead.

 MR. DURKIN: So, our response to that

 would be no different than it would apply today,

 which is in the context of we require all of our

 firms to apply our risk controls. And they have

 the obligation to ensure that they're effectively

 managing the business that's coming through those

 firms and trading on our markets. And if we find

 any evidence that there's been some violations of

 our requirements or our rules, then we take the

 appropriate action against those participants.

 You know, I would also make a point in

 terms of a registration requirement. I mean,

 today we require large trader reporting, and many

 of those people that are reporting on a day-to-day

 basis are not registered in any capacity, but

 they're required to submit that information, and

 so the CFTC certainly has the authority over those

 folks. And so we would make a very similar, you

 know, analogy in that respect.
 53

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Furthermore, in terms of anybody that is

 accessing our markets today using automated

 systems, we do have a requirement that those be

 acknowledged and represented to us, and we have a

 very specific way of identifying through our

 tagging system who's utilizing those systems, and

 then we go in and we will look at how they're

 utilizing those systems.

 Back to the registration part of it, Mr.

 Chairman, you know, there's a reference in the

 proposal that we're thinking captures a fairly

 limited population of market participants. But,

 again -- and we will explain this in more detail

 in our comments -- some of that definition seems

 to be contradictory at least in our reading of it.

 And so when we look at it, we see this applying to

 a much broader potential swath of market

 participants. And some of that is based on

 interpretation in the context of whether or not

 this brings in users of systems that are provided

 by ISVs. And right now it doesn't seem like it's

 contemplated, or at least specifically called out,
 54

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 I should say, in the proposed rule. But it's not

 specifically stated that it isn't either. And so

 we're a bit confused in that regard and, you know,

 we want to understand what's the responsibility

 and liability for having misinterpreted the

 language, because it needs some greater clarity.

 

 

MR. GRIFFIN: Richard?

MR. GORELICK: Thank you. I would --

 Bryan said a lot of what I was going to say. I

 think the Commission would continue to have both

 direct and indirect ways to enforce these risk

 requirements on firms that are not registered with

 the CFTC both through the exchanges as well as

 sort of with direct authority. And I'll let

 others comment on the legal authority for that,

 but I believe -- and I've been told that there's

 not a requirement that a firm be registered with

 the CFTC to be required to comply with CFTC rules.

 

 

 MR. GRIFFIN: Gary, welcome.

 MR. DeWAAL: I agree with Bryan a

 hundred percent. Large trader reporting, the

 rules around the CFTC's concern about positions
 55

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 and speculative limit positions -- they have used

 that authority to require a whole bunch of

 requirements on nonregistrants, including filing

 form 40s and similar documents.

 The CFTC has clear authority, in my

 view, to capture other participants other than the

 so-called AT persons today. That authority is

 4c(a)(6). 4c(a)(6) is the sister provision of

 4c(a)(5), which is the anti-spoofing provision,

 the anti-market disruption. 4c(a)(6) expressly

 gives the Commission authority to promulgate such

 rules and regulations as in its judgment are

 reasonably necessary to prohibit the training

 practices described in paragraph (5) -- that's the

 anti-spoofing -- and any other trading practice

 that is disruptive of fair and equitable trading.

 So, it actually gives you broader authority than

 just under the prior provision. So, it seems to

 me that under that provision alone, the Commission

 would have authority to capture customers who

 otherwise weren't registered.

 To me, it's an imperative, because right
 56

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 now as I look at a box, a matrix, and the old

 adage, "A picture's worth a thousand words" -- and

 I wish I could draw one -- you've got a big gap in

 the proposed regulatory scheme. You've got a

 principle that says that AT persons, whether their

 access is DEA or non-DEA, could pose sufficient

 disruption to the marketplace that they're

 required to go through the entire panoply of risk

 controls as well as pre-trade testing of

 algorithms.

 You then say that there's a new category

of persons, who are not currently AT persons, who

 possess that danger -- the so-called DEAs. But

 yet you do leave exposed this whole other group,

 and it seems incumbent that risk controls are a

 function of everybody. Anybody who engages in

 algorithmic trading needs to have reasonable risk

 controls to prevent market meltdowns. And, again,

 along the chain there might be different levels of

 controls required. But it seems odd to exclude a

 group when that same group is included simply

 because they're registered. It's not the
 57

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 registration category of the group that makes them

 possible to cause market disruption; it's the

 trading itself.

 

 

 MR. GRIFFIN: Mr. Chairman?

 CHAIRMAN MASSAD: If I understand you

 correctly, then what I think I hear you saying is:

 Don't make all these participants register but

 apply these controls to not just who you thought

 you were going to apply registration to but to

 even a broader group. So, that brings us back to

 at least these definitions of who do the controls

 apply to?

 

 

MR. DeWAAL: Well, I --

CHAIRMAN MASSAD: What you're saying --

 I think you -- at least Gary is saying and I think

 Richard was saying; Bryan I'm not quite sure is

 saying it -- I thought the two of you were saying:

 Yeah, it shouldn't just be: apply the controls to

 the DCMs and the FCMs but to some set of traders.

 Bryan may have been saying: Apply it to the DCM

 and we'll figure out who to apply it to as far as

 participants in our market. But someone somewhere
 58

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

has to decide what traders are going to be

required to comply with risk controls. Either we

have to decide that or the DCM has to decide that

-- I think. And so that requires some

definitions.

 MR. DeWAAL: Sure. Right. If I might

respond. I mean, I -- again, different types of

controls could apply to different types of

persons. You know, again, in comment letters I

think it will be expressed more in greater detail,

although there was a great attempt, I think, not

to be prescriptive in a lot of the requirements.

In fact, they probably are a bit prescriptive in

many areas, and they are likely, I think, better

adjusted.

 But I guess the cardinal principle,

again, is that if you're going to include all AT

persons in that, the 4,000 potential registrants

who were captured by this rule, you're capturing

them whether they are DEA or non-DEA. You're

making a statement that something about being

registered, whether you're a CTA or a CPO,
 59

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 something about that quality of being registered

 exposes the marketplace to their trading. Yet,

 other folks who might engage in the same type or

 more complicated trading don't expose the markets

 the same way, and that just seems to be illogical

 to me. It seems to be illogical. It turns risk

 on a function of a registration, and that may not

 be the case -- and is likely not the case.

 

 

 MR. GRIFFIN: Sebastian.

MR. SCHOTT: Yes, if I could just follow 

 on to what the Chairman was saying, I think -- so,

 assuming for the sake of the conversation that,

 you know, there are points here. I think,

 nonetheless, the question remains: What is the

 activity, and how should it be defined such that a

 population, whether it's DEA or something larger,

 is subject to these rules? How do we define the

 activity that brings you under the scope and just,

 you know, what do people think about that?

 MR. GORELICK: I would say that it

 should be a very broad group, maybe as broad as

 all electronic trading. In my view -- I've worked
 60

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 on best practices with the FIA and with other

 groups, and we've always said that all electronic

trading should have risk controls, pre-trade risk

 controls, et cetera -- and my view would be that

 that is what we should be recognizing here, and

 not all risk controls should be appropriate for

 all market participants. It really depends on the

 nature of a firm's business, and the like, but to

 select out a subset of that group and say we're

 going to only apply these rules to those folks I

 think really would miss the mark and possibly

 leave out some of the most risky and potentially

 disruptive behaviors as we've seen in other

 markets.

 

 

MR. GRIFFIN: Gary, last comment.

MR. DeWAAL: I was going to say that

 personally I think that the definition of

 algorithmic trading is not bad. I mean, a little

 tweak here and a little tweak there, but I agree

 with Richard.

 One thing that I think is important to

 note: It appears -- I'm not a hundred percent
 61

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 sure this is correct, and I think this will emerge

 in comment letters later, but I do think that one

 of the issues is even as the rule is written

 today, is the number really 420 people who the

 CFTC is going to capture? Is it really 320

 theoretically AT persons today and a hundred new

 potential AT persons tomorrow? I suspect that's

 not correct, and the reason being is because today

 my understanding is the definition of automated

 trading systems at the exchanges is more narrow

 than the definition of algorithmic trading as

proposed by the CFTC. So, to the extent that

 staff is utilizing an analysis of tags and things

 like that, they'd be picking up what the exchanges

 consider to be automated trading systems, which is

 likely more narrow. So, immediately, that's

 probably going to increase the group. How? Hard

 to tell, hard to tell. But, you know, it's likely

 one of the analyses.

 But I do think as a bottom line the

 definition should be broad -- I agree with Richard

-- because you're drafting a rule not just for
 62

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 today but for tomorrow, and you don't know what

 kind of systems are going to be developed between

 today and tomorrow, and you want to make sure that

 by -- if you draft it too narrow, you're going to

 exclude something that comes in, you know, a day

 after the rule is finalized, and that you don't

 want to do.

 MR. GRIFFIN: Well, speaking of the

ever-changing nature of not just the market but

 the market practitioners in this area, I think,

 you know, this might be a good point to transition

 away from the scope question, this registration

 question, and maybe dive a little deeper into

 those pre-trade risk controls and what's being

 proposed and really looking at the scope, what's

 captured, and try and make sure that we have a 

 clear sense from the members how well -- you know,

 in terms of breadth, in terms of content -- that

 proposal covers some of those affirmative

 requirements.

 Floor's open. Let's start basic.

 Sebastian, you want to take it?
 63

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. SCHOTT: Yes, just since no one else

 was talking.

 We've heard a couple of things over the

 course of the meetings we've had with industry

 participants and even today. There's a little bit

 of confusion as to how the pre-trade risk controls

 would work, so I thought I'd just put out a couple

 of points that have raised confusion.

 So, we are proposing pre-trade risk

 controls at the AT person level, the clearing FCM

 level, and the DCM level. Those controls are

 similar in the way they are described, but one

 point of confusion has been whether in fact there

 needs to be coordination or similarity in the

 actual design and implementation. So, I just want

 to be clear that that's not the case. Each

 entity, whether DCM, FCM, or AT person under the

 rules can design the controls and calibrate the

 controls as it sees fit for the role that it plays

 in the market. And in fact, we would expect that

 a DCM, an FCM, and an AT person would have maybe

sort of distinct interests or distinct risk
 64

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 tolerances with respect to an order. So, I just

 want to make that clear that it's sort of specific

 to the entity that you are and the risk that you

 perceive as that entity despite the similar

 language in the rule text as to the nature of the

 controls.

 

 

MR. GRIFFIN: No comments.

CHAIRMAN MASSAD: So, I take it we got

 it right.

 (Interruption)

 CHAIRMAN MASSAD: Exactly. We can go

final, like, tomorrow. You're all happy with the

 package of risk controls and how they apply. This

 is great.

 MR. GORELICK: I'd say I think they're

 very -- there's a lot to say, and it's probably

 hard to get it out in a meeting like this, but

 there'll be a lot more detail in the final comment

 letters that come in. That said, I think they're

 not too far off in terms of the specific pre-trade

 risk controls that are delineated.

 I think the important pre-trade risk
 65

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

controls for any electronic trading -- not just

 algorithmic trading, again -- are to make sure

 that before a trade you check the order size to

 make sure that the order is not too big for what,

 you know, a particular firm can bear, what their

 credit limits are, their risk limits, their risk

 tolerances, et cetera.

 And the second thing that's important to

 check pre-trade is frequency, that you have not

 sent too many orders maybe of the same size and

 the same -- of a size and direction within a

 certain period so that you, post-trade, have an

opportunity to enforce lots of limits, more

 sophisticated limits, around your desired trading.

 So, I think, generally speaking, it's

 not too far off. I think my concerns will be not

 in the details of the pre-trade risk controls but

 all of the layers of additional requirements that

 are piled on top of those risk controls to make

 sure that you're actually doing what you're 

 supposed to be doing. And I would leave a little

 bit more discretion to firms to figure out how to
 66

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 make sure that their algorithmic trading or their

 electronic trading doesn't violate laws or rules.

 CHAIRMAN MASSAD: Sorry, Richard, "by

 all those other requirements," let me make sure I

 understand what you mean.

 MR. GORELICK: I think there are a lot

 of details in the testing that may not be suitable

 for all types of trading. I think there are, you

 know, and may not even be able for different types

-- from exchange testing environments, for

 example.

 I think that some of the written

 supervisory procedures and controls may not be

 suitable for every type of business. I think that

 the -- clearly, I think it's appropriate that

 algorithms need to be supervised by an individual,

 a named individual, at a firm. I think that it's

 an important thing that the rules get right, in

 that we don't want this idea where everyone points

 the fingers at the computer and there's no one to

 take responsibility.

 When an algorithm is traded in the
 67

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 market, even if it has artificial intelligence, as

 Commissioner Giancarlo mentioned, there needs to

 be a human person at the trading firm responsible

 for that algorithm, and that person needs to be

 named in advance and understood so that if there

 is a problem the exchanges and the regulators know

 who to talk to.

 But I do get concerned about some of the

 specific training requirements, the testing

 requirements, and in particular, the annual

 certification requirements, where on an annual

 basis a firm would have to go back to the exchange

 with a very extensive document that might list all

 of the risk parameters that they chose to set it

 throughout the course of the preceding year. And

 that's something to me that just seems

 unnecessarily burdensome, especially when most of

 these risk parameters are set with the exchange

 day in and day out, and the exchanges in real time

 have access to the same or very similar

 information. So, it's that type of additional

 requirement built around these pre-trade risk
 68

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 controls that give me some pause.

 

 

 MR. GRIFFIN: Gary.

 MR. DeWAAL: Yes. You know, it's -- I 

 like to see what's going on around the world, not

 just in the United States, and I was struck that

 last week, the Singapore Exchange, which had had

 very, very -- and still has, I might add -- very,

 very prescriptive requirements around its pre- 

 trade risk controls, has proposed a modification

 to its rule 2.1. And the rule basically

 eliminates all the specific requirements and

 simply comes up -- and this is just one provision

-- it says obviously -- it's just a general

 sentence. It says that a clearing member -- this

 only relates to a clearing member, but again this

 is a Singapore Exchange -- in order to clear the

 trades, it has to have pre-trade controls, and it

 says as such: The checks must be appropriately

 set to effectively limit the firm's risk exposure

 to trading members to prevent the taking on of

 excessive risk. One sentence. If you look at the

 rule before, they had many of the types of
 69

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 specific requirements that were listed in 1.80.

 And, again, to Richard's point and to

 some of the points that I think you'll hear over

 and over again, the danger of making this too

 specific is that you're not going to allow for the

 evolution of the marketplaces. You're not going

 to allow for the evolution of what might be best

 practice in a couple of weeks. Keep in mind that

 the way that this rule is constructed because of

 the definition of algorithmic trading compliance

 issue, it's a violation potentially of the rule

 for a firm to violate its own internal policies.

 That doesn't exactly encourage firms to run out

 and adopt the best practices. And the problem of

 coming up with a prescriptive rule -- and, again,

 I do think the effort was not to be prescriptive,

 but when you compare, as I said, the Singapore

 Exchange proposed rule with what's being proposed

by the CFTC, you can see the difference, the

 danger being too specific, and coupled with the

 fact that firms, I think, are going to be

 discouraged from being innovative in adopting best
 70

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 practices going forward, is that you are not going

 to be flexible enough to deal with what is the

 best practice going in the future.

 

 

 MR. GRIFFIN: Paul and then Chris.

 MR. CHOU: Yes. So, I would just

 suggest that understanding the context around a

 lot of the trades and the message throttling in

 particular is going to be very important, because

 many different markets in asset classes have

 extremely different and unintuitive, appropriate

 message profiles for how many should be going per

 second. So, you know, if you take the equity

 options world, if you're a market-maker in S&P 500

 stocks and all the series of options around that,

 and nothing moves for the entire day, then you

 sort of have this profile where you see no

 messages per second and then the second all the

 stocks move up at once, you might see enormous

 amount.

 So, I think understanding the context of

 when that's happening, it's going to be important.

 If the underlying asset moved, obviously that
 71

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 makes sense, and it's unlikely that that's

 manipulation.

 But if you have too little -- if the

 thresholds are too low, essentially what will

 happen is certain people won't be able to update

 fair markets for other securities and the

 execution quality will probably suffer for

 customers, so.

 MR. HEHMEYER: There have been a lot of

 very good things that have been said, and I

 certainly agree with a lot of them. You know, it

 seems to me that this balance that you'll be

 trying to achieve between how broad to set the

 rule and then how many people you have in the net

 that you would require to be registrants or

 members potentially of NFA, and again, I'll say

 that the NFA stands ready to do what the

 Commission deems that NFA should be doing. But

 you've got the -- I think you'll find, in the

 industry, that there's a lot of desire to have it

 clear what's expected of people, because that's

 the best practices now. And so I don't think
 72

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 you're going to get push-back on trying to make

 the market safer and more sound with regard to

 these algorithmic practices by most of the people

 that are engaging in most of the activity.

 So, you're not going to get, I don't

 believe, push-back -- as Richard was saying, well,

 in codifying best practices. The problem would be

 in creating some of the bureaucratic work of

 filing a lot reports by people who really aren't

 the intended targets, if you will. And that's

 going to be a balance, I think, for the Commission

 in trying to get that right.

 MR. GRIFFIN: You know, speaking on the

 multi-layered approach -- and, Bryan, I don't know

 if you would be best for that, or Pierre perhaps

-- I mean, in terms of, you know, who -- or upon

 whom -- the pre-trade risk controls are imposed,

 the rule obviously looks at, again, multiple

 layers throughout the process, whether it's the AT

 person, the clearing FCM, the DCM. In terms of

 that structure, do you feel like that is well

 covered? Is the need for application to clearing
 73

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 FCMs -- is that a necessary obligation, or

 something that perhaps should be discussed

 further?

 MR. DURKIN: First of all, in terms of

 the controls themselves, I mean, many of these are

 ones that we've implemented as an institution,

 right -- and we're firmly behind the intent and

 purpose behind this. No question. So, I just

 want to be very clear on that point.

 Where we find confusion, and even today

 it was very helpful, Sebastian, to hear some

 greater clarity on the intent on flexibility and

 how that would be applied in this multilayered

 approach.

 We need to define that a bit more

 clearly and will opine on that in our comment

 letter in terms of how you might, you know,

 consider approaching that multilevel application.

 But, you know, again, it's a little confusing to

 us. Just on the slide that's referenced here

 today, multilayered approach requires risk

 controls at AT person, clearing member, FCM, and
 74

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 DCM. Then it says, "Each entity has discretion to

 set appropriate design and parameters," which is

 positive. But then it goes on to say, "To ensure

 minimum standards for parameters, entities must

 report settings to the DCMs," and this is to

 establish, I think, some kind of baseline or

 floor, whatever, in terms of making sure everybody

 has some baseline parameters that they're trying

 to work towards.

 But, you know, these are the types of

 things that we just need some clarity on to figure

 out, and what are our obligations as a DCM to make

 sure that this is being carried out in the

 appropriate manner, and what are each one of those

 participants in those order routing chain

 obligations.

 MR. SCHOTT: Sure. So, both in response

 to your comment and maybe Chris -- the pre-trade

 risk controls are intentionally, I think from

 staff perspective, broad in that they say have a

 maximum per-unit time. We don't tell you what the

 maximum is; we don't tell you what the unit time
 75

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 is -- just have a number divided by a number. So,

 the purpose of some of the reporting that has been

 discussed is because the rule in theory lets you

 have a pre-trade risk control of, you know, a

 million orders per second -- to be facetious about

 it -- there's a desire to have some check that in

 fact that flexibility hopefully that is reflected

 in the rules is not going to be abused.

 MR. GRIFFIN: Gary. Oh, sorry.

 Commissioner Bowen.

 COMMISSIONER BOWEN: Yes, thank you. I

 just want to make sure -- thank you so much for

 the comments. What I'm hearing is that we have

 been overly prescriptive, and we have not

 necessarily captured the risks that are posed by

 these types of trading activities. And so

 therefore, by even listing or defining people,

 whether they're DCMs, ATs, or FCMs, we may not be

 capturing the very people who are coming to the

 market and presenting potential risk. Am I

 hearing that right?

 MR. DURKIN: Yes.
 76

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 COMMISSIONER BOWEN: Okay, thank you.

 MR. DeWAAL: One question that I have,

 because it jumps out at me as something that's not

 entirely clear in the proposed rules is when the

 staff refers to "clearing member," FCM, an FCM

 that's a clearing member, are you placing all the

 obligations on the FCM that's carrying the

 customer's account? Are you placing the

 obligations on the FCM -- the clearing member FCM

-- that is sponsoring or granting the access? Or

 both.

 MR. SCHOTT: So, that would be a useful

 thing to have a comment on, because the proposal

 is around the member that is clearing the trade.

 (Interruption)

 MR. SCHOTT: I'll try to shout. So, we

 have received questions as to whether the better

 approach ought to be the executing firm that's

 putting these controls in place. So, I think that

 would be a good point for discussion here. But

 the proposal is the clearing firm, not the

 executing firm.
 77

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. DeWAAL: I mean, from a pure point

 of technicality, both FCMs are a clearing FCM with

 a relevant DCM, because in order to sponsor

 somebody's access or grant access, you have to be

 a clearing member FCM. So, that's where the

 danger -- that's why it's a little unclear in the

 rule, because everybody who grants or sponsors

 access is a clearing member FCM -- unless you're

 self-clearing, by the way. And it's potential

 that somebody could self-clear -- and, by the way,

 they would not fall within this rule necessarily

-- that's another potential exclusion.

 But to me what's relevant, because here

-- this rule is all about avoiding market

 disruption. And therefore the appropriate party,

 to me, is the gatekeeper, who is granting that

 market access. So, in a situation where one

 executing broker on behalf -- one executing FCM on

 behalf of multiple customers grants access, they

 seem to be in a far better position to control

 that access, than the firms that ultimately are

 receiving the trades -- this is not, like, 1.73,
 78

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 which effectively is really a credit control.

 This is really all about disruption. So, I do

 find that -- you know, I agree, I think it's

 something that should be clarified when the final

 rule comes out that, in my view at least, the

 gatekeepers are the more appropriate party.

 MR. GRIFFIN: Being cognizant of time,

 this would be a good point to move on to the last

 topic that we certainly wanted to raise today,

 which was the question of self-trading. And this

 has been an area where it's certainly gotten a

 great deal of focus from a number of parties, and,

 really, there are a couple of questions I think

 that have come up that would be helpful to discuss

 here.

 First, the way that self-trading is

 proposed in the rule: Does it define the

 population of trades appropriately, first of all?

 And, second, is there enough flexibility in terms

 of implementing the self-trade prevention tools at

 the DCM level and how that may go about?

So, Bryan, if you want to jump in.
 79

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. DURKIN: First of all, compliments

 to all of you in terms of the discussion that

 we've had over the last few years on this very

 topic and how it's informed the definition of how

 this would apply. You've recognized that there

 are legitimate situations where there may be

 transactions occurring within the same firm for

 the same proprietary account opposite each other,

 and you laid out, you know, how that would be

 permissible or allowable with a certain level of

 reporting obligations and whatnot. And I think

 that's a big advancement and cannot compliment the

Commission enough for making that recognition.

 Now, assuming that that occurs and, you

 know, we stick to that criteria, when you remove

 those transactions from our calculation and how

 we've reviewed it just having taken a particular

 day in February where this was called out in terms

 of the level of self-matches, it would be down to

 a fraction of one percent, a very small fraction

 of one percent of activity.

 And, you know, we're really happy to
 80

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

share that information with you. I think you'd

find it interesting, and it's just to kind of

frame out, you know, what, in terms of possible

disruptive practices, are we talking about here if

we're acknowledging now that, you know, there is a

reasonable basis for certain types of these

transactions to be occurring with the caveats that

have been outlined, to what end, then, are we

trying to address a problem? Or how big is that

problem? And so we'll articulate that again in

our comment in greater detail and specificity, but

in terms of how the DCMs' protocols are to be

applied, you know, again, we're going to be asking

for some more guidance from the Commission in

terms of what the expectations are under this rule

and ensuring that the protocols that we've put

forth effectively comport with your expectations.

But, again, I think we have to really focus on

what is the problem here that we're trying to

solve, and the universe of what this is being now

applied to is a very, very small fraction of

activity.
 81

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. GRIFFIN: Sebastian, if you'd like

 to maybe speak briefly on the intent behind the

 rule, how it was structured, and some of the

 thinking that went into those points.

 MR. SCHOTT: Sure. Let's see, is my mic

 working now? Yes? Okay, good.

 So, from the staff perspective, the

 approach here was, again, a little bit like our

 pre-trade risk controls, and we thought we were

 being flexible, but we have a mechanism around

 reporting, and the mechanism around reporting is

 designed as a counterbalance.

 So, as you mentioned, Bryan, there's the

 premise that there are certain activities,

 self-trading, that when it has characteristics

 about independent decision-makers and so forth,

 that that's permissible.

 Now, having made sort of that statement

 and proposing to codify it in rules in effect,

 we're also looking to make sure that that latitude

 isn't abused through a measure of transparency

 that says, it's happening, that's good, now let's
 82

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

identify how much of the self-trade, how much of

it is happening? And so I think that's the

primary desire: To acknowledge it, to permission

it, but to be transparent about how much of it is

happening.

 MR. DURKIN: There's one other aspect

that we're going to be seeking some clarity under

the requirement where I believe it makes a

reference to transactions that are under common

control, and this would apply to those types of

transactions, which had us a bit perplexed because

we would look at those types of transactions as

cross orders or crossing of trades, and, you know,

we have facilities for those types of transactions

to be permissible, and so we're going to be

seeking some greater clarity on what the intent

was there. Again, the driver was orders for

accounts under common control but are for

different beneficial account owners. So, I mean,

it's not what we would typically have put under a

definition of self-trading.

 MR. GRIFFIN: Okay, we are about out of
 83

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

time on Panel I. Before we close it, I just want

to check -- Chris?

 MR. HEHMEYER: Thank you. Can I go back

to the bigger issue of the registrants for just a

moment? And that is just a little perspective to

some of those that maybe are newer to the

industry.

 When the NFA was created in the early

'80s, it created the categories of floor broker

and floor trader for purposes of registering the

floor brokers and the floor traders while trying

to avoid duplicative regulations with the

exchanges, because they were already regulated by

the exchanges. And so we went over -- we, floor

brokers and floor traders -- went over and got our

fingerprints at the NFA, and that was all we heard

of it for 30 years. And so it functioned pretty

well, because you had these people in the system

and had data on them and the exchanges regulated

them.

 Then, it was somewhat my fault that this

came back up under the swaps regulation
 84

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

discussion, because those of us in the trading

business kind of thought, you know, if we register

as floor traders and only trade cleared swaps, if

we get registered as floor traders, maybe that

would work and function roughly as the way it used

to work. And it then became a bigger thing, and

so there's this awful application -- I went to the

NFA and said: Could you handle this thing of

floor traders? And they said: Yeah, it'd be a

little difficult because they're individuals and

not companies but we could make it happen; there's

only a limited number of them. And so I said:

Sure, we could do it. And so it ended up that the

Commission came up with this set of rules for the

floor traders, which now needs to be tweaked. So,

there's this really cumbersome term, "floor

trader," for these automated traders. And I'm

somewhat guilty of contributing to that.

 Having said that, the challenge I think

for you all as this goes forward is this

difference between a member of the NFA and a

registrant of the NFA, because a member has much
 85

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

greater responsibilities, has to file an annual

report, has to be there for regular audits. Its

books and records will get audited.

 A registrant doesn't have that

responsibility. And so here you're going to have

the issue of the prop trading firms and the

exchanges' rules again where we don't want to be

duplicative with what the exchanges cover, and

these professionals that have a lot of these

systems and rules and best practices already in

place and certainly could abide by those

Commission rules if they come down -- that they

have to abide by a set of rules that are to go

with new releases of algorithms and things like

that -- software releases -- which is important.

 It's the software releases oftentimes

that, in my opinion, where some of the danger

comes. And so those need to be laid out. The

professional firms I think are certainly willing

to do that and welcome because it's safe and

secure.

 The bigger issue is if it's broad, do
 86

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 you have 4,000 registrants or 5,000 registrants

 out there who might be a farmer that uses an ISV,

 and so that will be the trickier part. All of

 those people being registrants with the NFA may be

 good for the NFA business, but I'm not sure if

 that, from a public policy standpoint, is where

 you want to go. So, that's -- I just offer that

 as possibly part of the challenge of trying to get

 this right. It's somewhat nuanced.

 

 

Thank you.

MR. GRIFFIN: Thank you, Chris. Unless

 any Commissioners have any questions, comments?

 Great. Thank you, Sebastian, Marilee, Mark for

 joining us this morning. We're going to take a

 very short 15-minute break, and by "15," we're

 going to stick to 15 minutes so we can jump right

 into Panel II. Thank you.

 (Recess)

MR. GRIFFIN: Thank you. I now would

 like to welcome our second panel, which will focus

 on swap data standardization and harmonization.

 Joining us on the panel are Dan Bucsa and Richard
 87

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 Mo from the Commission's Division of Market

 Oversight, and Srinivas Bangarbale from the

 Commissioner's Office of Data and Technology. We

 also invited representatives from the four swap

 data repositories to join us: Marisol Collazo

 from DTCC is, of course, with us as a TAC member,

 and joining her as panelists are Derek Kleinbauer

 from Bloomberg, Jonathan Thursby from CME, and

 Bruce Tupper from ICE.

 

 

 Dan?

MR. BUCSA: Thanks, Ward. First off,

 thank you, Chairman and Commissioners, for

 reinvigorating the TAC; members of the TAC for

 participating; and Ward for organizing today's

 activities. As other colleagues probably

 mentioned earlier, any comments that I make today

 are my views and my views only. They don't

 represent the Chairman, Commissioners, or any

 other staff at the Commission.

The second panel is not for staff to

 brief you on the history of reporting or where the

 future might take us. Instead, we wanted to share
 88

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 our thinking and provide some background on the

draft technical specifications in order to help

 frame the questions we asked for the pending

 comment letters. As a reminder, that comment

 period has been extended to March 7th for all of

 you drafting letters. More importantly, staff

 also wishes to take a step back and have industry

 take the lead and advise us by panelists sharing

 their expertise rather than the other way around.

 It is well documented why and how

 entities interpret regulations differently and

 created new reporting templates with distinct data

 fields and formats. The agency has been focused

 on improving data and worked with a lot of you --

 SDRs, reporting counterparties, industry

 organizations -- throughout the evolution of swaps

 data. We appreciate that cooperation and plan to

 continue to rely on that dialogue.

 Swaps data has come a long way since the

 inception of reporting, especially considering

 that there was limited transparency for the market

 and regulators before Dodd- Frank. Today we have
 89

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 a better understanding of what is happening in the

 swaps markets than in the past.

Staff distributed this Request for

 Comment to continue the work of improving the

 data, as well as our other initiatives such as the

 cleared swap reporting rulemaking. This is just

 one step in an iterative process to resolve the

 inconsistencies in how different SDRs and market

 participants report swaps.

 To be clear, the Request for Comment is

 not a Commission action and doesn't change any

 regulations or reporting requirements. It is not

 intended to stimulate discussion on existing or

 future regulations at this time. Instead, the

 goal is to garner technical feedback from a data

 perspective on the prioritized list of data

 elements whether their definitions, formats, and

 allowable values are accurate.

 In particular, we're not attempting to

 limit the different economic terms that could

 constitute a swap. On the contrary, we are simply

 searching for more robust reporting so the same
 90

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 element is being reported consistently and

 transmitted to the CFTC under a common approach.

The Request for Comment aims to better understand

 if the definition is not clear, the format not

 possible, or the allowable values not inclusive

 enough to represent swap transactions.

 At this time, staff chose to focus on

 credit, interest rate, and FX swaps since those

 asset classes are much more standardized than

 others, such as commodity swaps, for example.

There's no one-size-fits-all approach that works

 for reporting. The terms of swap transactions can

 vary greatly based on the risks one wants to gain

 exposure to or limit by hedging. The prioritized

 data elements listed are driven by use cases

 identified by staff across all divisions of the

 Commission in order to help promote our regulatory

 mandates.

 Wherever possible, an existing data

 standard was used. In instances where a data

 element did not exist in another reporting regime

 or the options available did not fit the needs of
 91

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 the use case, a new draft technical specification

 was created.

 Staff conducted its initial review based

 on data actually contained in the SDRs, FpML and

 FIX messaging standards, known SEC reporting

 regulations, and ESMA reporting requirements. We

 also heavily leveraged the international

 harmonization work going on, such as by groups

 like CPMI-IOSCO. The Office of Data and

 Technology is co-leading some of those efforts,

 and my colleague, Srini, will take the lead on

 detailing some of that work.

 MR. BANGARBALE: Thank you, Dan, and

 again my comments are mine only and they do not

 reflect necessarily the views of the Commission,

 the Commissioners, or other staff of the

 Commission.

 I would like to take a couple of minutes

 to talk about the background in the international

 work and how the international work that the CFTC

 has been co-leading corresponds and works with the

 staff work that's being done here.
 92

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 In September 2014, the Financial

 Stability Board published a report on aggregation

 of global swaps data for regulators, and they

 conducted a feasibility study. The CFTC co-led

 that effort. And that study recommended several

 things.

 One was the development of standards for

 data elements, which different regulatory regimes

 had different standards for form and manner.

 The second one was development of key

 identifiers like the LEI, the UPI for products,

 and USI or UTI for transactions. The LEI was well

 formed by then, so not a whole lot of further work

 was necessary, and the Commission has been an

 early adopter of the LEI standard.

 As far as the development of data

 standards for other data elements and USI and UPI

 or UTI and UPI, the Commission has been leading

 the CPMI-IOSCO work on developing these standards.

 The CPMI-IOSCO formed this group in December of

 2014 quickly following the publication of this

 report to handle these data elements.
 93

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 So far, the work has proceeded on all

three fronts.

 On the data elements side, the group has

published the first consultative document, and the

comment period has closed but the group is

considering comments and is working on more data

elements. On UTI, the group has again published a

consultative document, has received comments, and

is expected to issue final guidance by late spring

this year. On UPI, the group has published one 

consultative document and is expected to follow

with one more consultative document by the end of

the year.

 The FSB has again taken charge of

putting together a governance mechanism and an

implementation plan for UTI and UPI. So, based on

these, our document that we published as specs

does not address UPI and UTI, because we intend to

fully leverage all the international work that's

going on in these areas. And since we co-lead

this work, we are very much involved in it, and in

fact two weeks ago we had an industry workshop
 94

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 here. A number of you actually participated in

 that workshop to provide CPMI-IOSCO and the

 workgroup with your views on all the consultative

 documents that have been published by the

 CPMI-IOSCO workgroup.

 On the data element side, the focus of

 the CPMI-IOSCO workgroup is on global data

aggregation for systemic risk purposes. But the

 CFTC's remit goes beyond it.

 As Dan talked about a number of use

 cases, we have a number of regulatory use cases,

 so our list of data elements is, by necessity,

 larger. There will be overlap. We are

 overlapping, and we are leveraging as much of the

 work of the CPMI-IOSCO that we can put into our

 specs. But there will be data elements that we

 will address that will go beyond what CPMI-IOSCO

 will address.

 So, with that in mind, we also, as Dan

 said, looked at the work done by ESMA on EMIR and

 the regs by SEC and other documents available like

 the industry bodies. And we believe that staff
 95

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 has spent a lot of effort and research into many

 of the technical and data standards aspect to come

 up with the draft spec that we have put out for

 comment.

Of course, you know, part of the process

 in the comment is to learn more about anything

 that we might have missed or any other aspects we

 should take into consideration, so the comment

 period is still open, and I would obviously

 encourage everyone to, you know, send in your

 comments with respect to the document we put out.

 Thank you.

 MR. BUCSA: Thanks, Srini. The comments

 that we do hope to receive will inform any

 subsequent decision-making by providing insight on

 how SDRs can transmit the data in a consistent

 manner. We want this to happen regardless of who

 is executing the transaction or which SDR has been

 utilized. We hope to continue to consult with

 industry now and in the future, and we place

 utmost importance on this.

 That's why we think the TAC should
 96

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

contemplate the reestablishment of the Data

 Standardization Subcommittee. It would provide a

 more permanent means for the experts in the space

 to have these conversations, share best practices,

 and collaborate with staff on how to deal with

 this complicated dataset.

 Today, for this panel, we're going to

 talk about four of the themes from the Request for

 Comment: Reporting of events, particularly

 allocations and compressions; order data and

 package transactions; pricing information; and

 notional amounts. Of course, as time allows we'll

 talk about other themes as well.

 Thank you again for your attendance. 

Looking forward to the discussion, and turn it

 back over to Ward to lead the conversation.

 MR. GRIFFIN: Thank you, Dan; Srini. As

 Dan mentioned, today's discussion is going to

 focus on four of the themes from the Request for

 Comment. We have asked TAC members as well as our

 invited SDR panelists to co-lead each of these

 themes, and we're going to address them in order.
 97

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 And then, finally, before we wrap the panel, we

 will discuss briefly the potential for

 reestablishing the Data Standardization

 Subcommittee and solicit the TAC members' views

 with respect to that.

 Why don't we dive right into the first

 theme, reporting of events. Handling -- or, say,

 co-leading -- that discussion will be Jonathan

 Thursby from CME; Marisol Collazo from DTCC; and

 Supurna, who's on the phone, I hope, from

 BlackRock. Supurna, you there?

 MS. VEDBRAT: Yes, I am. Can you hear

 me?

 

 

MR. GRIFFIN: Yes, we can, thank you.

MS. COLLAZO: Okay, so thank you for the

 opportunity to present to this Committee today on

 what I would consider a very important topic as it

 relates to regulatory transparency in the OTC

 derivatives market.

 First I'd like to say I applaud the

 effort of the Commission to tackle this issue and

 to address it from a technical specifications
 98

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 approach and solicit comments. I'm encouraged to

 hear that in taking forward this approach that you

 are looking at CPMI-IOSCO data harmonization work,

 because we think that's very important from a

 global perspective, and I'm looking forward to

 opening up this dialog with my co-panelists here

 representing other SDRs.

 Before I go into the reporting of

 events, I'd like to set some context around data

 quality that I think will drive the four points as

 it relates to events pricing, notional and --

 missing one. What am I missing? This -- yes,

 thank you.

 So, DTCC -- we've been looking closely

 at data quality since commencing our global trade

 repository services back in 2012. Just to set

 some context, we are now covering nine

 jurisdictions globally across U.S., Canada,

 Europe, and Asia. And what this allowed us to do

 is it positioned us quite well to look across the

 datasets and understand where the issues lie both

 from jurisdictional level -- for example, under
 99

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 the CFTC regulations -- as well as compared to

 regulations across the globe.

 In that vein, we have really looked to

 take a very proactive approach on addressing data

 quality issues that we have seen, and we have been

 working closely with market participants, market

 providers, SEFs, clearing houses, as well as

 regulators to identify what is the root cause of

 the poor data quality in certain areas. And, in

 fact, we've been very engaged with Dan Bucsa and

 his team in providing the results of our effort --

 whether it be through heat maps, through root

 cause analysis and recommendations -- and also

 actively participating in the CPMI-IOSCO Data

 Harmonization Working Group.

 So, I just want to show a little bit of

 what we have learned and how we have evolved our

 own thinking around data quality. You know, there

 are a few components. When we first embarked on

 this exercise, we thought about sort of the

 traditional standards that, you know, you can

 Google search and read what does data quality
 100

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 mean, and there are many white papers on this,

 and, you know, right away two key terms that come

 up are "completeness" and "accuracy."

 Well, we looked a little further into

 exactly how do you achieve accuracy in particular,

 and so there are two points that I want to raise

 here. One is around validating the content of the

 data and doing so in a way where you're applying

 business rules to the data that's being provided.

 So, we think that's really important in terms of

 how we look at the technical specifications. What

 are the business rules that are going to lead to a

 reliable piece of information?

 I would note that, based on discussions

 we've had with staff and our own read, we think

 there are some changes that need to happen under

 Part 49 rules that enable the SDRs to apply those

 business rule validations and have the authority

 to either perform inception management or

 potentially reject the trade, and, you know, the

 reporting entity has to try again.

 So, you know, the other -- the second
 101

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

part of this is what I would call data integrity.

When I speak about the data integrity, what I'm

really speaking about is the reliability of the

content being provided. The reliability

increases, we believe at least, when it is tied to

existing processes.

 For example, if a field is reported as

part of an electronic confirmation process and the

value is provided by that confirmation provider,

then it's going to have a high reliability rating.

And we see this play out quite strongly on CDS and

interest rate swaps where it is a market where you

do have a high percentage of trades being

electronically confirmed.

 The same is also true for cleared swaps

as it relates to fields that are being captured

for the purpose of either clearing or confirmation

where these fields are required to be reported in

terms of information that's being asked for that

doesn't exist in existing market conventions or in

practices or whether data needs to be transformed,

values added, or potentially where we have a
 102

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 redundant set of data fields. So, you know, the

 illogical sequence of having two or more fields in

 the same trade record that can contradict each

 other is what I mean there.

 The danger here is that it then starts

 to fall further and further away from existing

 operational process or market structure, and there

is where we're really seeing the data quality

 decline. And so I don't think that the measure of

 data quality is poor across the board. There have

 been improvements. Our analysis has shown cases

 of, you know, 38 percent on data quality up to 85

 percent on certain fields. So, we are seeing

 improvements, but where we're really I think still

 quite struggling is on what I'd call sort of the

 outside the parameters of where the existing

 operational process is.

 So, with that lens I'm going to turn to

 reporting of events, and then I'll open it up as

 well to my co-panelists to add their comments to

 it.

 In thinking about reporting of events, I
 103

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

considered three aspects:

 One is: does a recommendation advance

the data quality, and can the information be

relied upon? So, essentially that data integrity

test.

 Two: are there global implications that

need to be considered? Sounds like Srini has

tackled some of that, so I'd like to explore that

a little bit more.

 And three: is the information readily

available or accessible to make execution of such

proposed standard executable and can we act on

that?

 So, starting with the first, and then

looking at the definition around event type in the

specification, when we look at the data quality

aspect, we think event types in the proposed

specification is over 30 values or 30 values that

are provided there. We think there is a much more

narrow definition. We think that's too broad.

 Traditionally, event types really

reflect price-forming changes as it relates to the
 104

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 opening or closing of a transaction -- for

 example, a new trade, new execution, novation, or

 terminating a trade. These are all price- forming

 events; whereas, when you look at middleware

 providers, what they are really doing is

 performing actions on those events. And so the

 remainder of what we saw in the technical

 specification beyond those three we believe are

 much more applicable to actions. And these are

 really actions that are applied on a new trade, a

 novation, or a termination for the purpose of --

 typically for position calculations, settlement

 activity, or confirmation processing.

 I think this is a very important

 distinction, because the danger here is that we

 are trying to fit into an event-type definition,

 and this includes the compression and allocation

 point, the behaviors, and the actions that occur

 within market providers for other purposes. And

 I'm concerned, in terms of advancing data quality,

 that we're going to -- even in the place of a

 standard, we're not going to get highly reliable
 105

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 data, because it doesn't presently exist in that

 infrastructure. And the result is going to be,

 you know, a lot of, I think, cost here in terms of

 passing that information through, but the

 likelihood of the data quality in our opinion is

 still going to be poor.

You know, the other application is the

 global consideration, and we think that event type

 is an important field for systemic risk and

 certainly for the need for data aggregation, so

 I'm encouraged to hear that that is something that

 is being looked at alongside of the other data

 elements workstream from CPMI-IOSCO. My caution

 here would be that there is full alignment, and

 that is worked through -- because I understand

 that's still work in progress -- and I would be

 very concerned about the Commission moving in

 advance of CPMI-IOSCO having really fed it through

 all of these scenarios and really collecting

 industry feedback on that.

 The last point -- is the information

 readily available? I think, for the reasons I've
 106

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

already stated, we don't think they are, and we

would propose instead that the focus here be on

really narrowing what is the objective, you know?

So, we look at alternatives, because we do

understand that there is a need to have a better

understanding, and we believe that the objective

here is what the Commission is looking to seek --

and happy to be sort of educated on that in terms

of these use cases -- audit trail, being able to

follow a trade from execution through its life.

 There are other alternatives that can be

explored such as linking trades when it relates to

compression between the predecessor and the

successor identifiers -- trade identifiers-- you

know, and that would satisfy the audit

traceability. There are other values as well

reported in that trade record that would identify

that the submitter of that data is a compression

provider. So, that is another data element that

has a high degree of accuracy and would enable the

Commission to understand that it's a compression

trade and one of the linking identifiers to that
 107

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 compression.

 What then remains is the question of the

 reason for the compression. Multi, bilateral, or

 blending are the three examples in the

 specification. As it relates to the reason, I'd

 like to better understand, in terms of use cases,

 what added value the Commission is deriving for

 that. We think that collecting such information

 again would be very difficult, and we're concerned

 about the degree of accuracy that as a swap data

 repository we would see in terms of that field

 being populated.

 So, those are my comments. Thank you

 for giving me the opportunity to present on that,

 and I'd like to turn it over to perhaps Bruce, if

 you want to pick up.

 MR. TUPPER: My name is Bruce Tupper. I

 manage ICE's global repository business.

 Appreciate the opportunity to speak on today's TAC

 panel. Thank you.

 I think before we dive into the very

 specific questions that are posed by the draft
 108

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

specifications, I think it is important to just

kind of take a step back and look at the data

quality in what the Commission receives today.

With the sort of standing up a creation of SDRs,

there was very little coordination on the output

amongst repositories to the Commission, for which

I know there have been public statements in that

regard. So, if we kind of look back to 2012, all

of us were busy working with our individual

customer bases, trying to stand up our own

technology and connect customers to us and make

sure that they could fulfill their reporting

obligation.

 As part of that process, there was very

limited guidance or coordination amongst the

repositories on what the outputs to the Commission

would look like and, more importantly, what are

the methodologies and standardization of these

fields and how do we aggregate those and report

them as a collection? And as Marisol mentioned,

it's more than just saying I have a field.

There's a life cycle event. How do we communicate
 109

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

that to you, and how do we each do that in a

uniform manner?

 I think it's important to look at

efforts that the Commission's made and also

compare that to other reporting jurisdictions.

I've had the unique ability with ICE to also

manage other jurisdictions, and what I can say is

that I think the Commission's done a very good job

with collecting a dataset that's manageable and

one that relates to the swaps markets. In other

jurisdictions, there was a very broad expansion of

data, and what it's led to is these very large

sets of data that are unmanageable -- for example,

dual-sided reporting and the inclusion of orders.

So, I really -- I strongly believe that the

Commission got it right in the early days with

single-sided reporting and also just focusing on

transactions.

With that being said, I think we also

have to look at harmonization and the benefits of

that, and I'm very encouraged to hear that there

is consideration to restart that group or under a
 110

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 new subgroup that Dan had mentioned. I think that

 would be very beneficial. And I think the next

 goal is to work with the data fields we have and

 understand how those are to be standardized or

 validated and also given to the Commission in a

 uniform manner amongst all four SDRs. The end

 result is that the staff will be able to aggregate

the data, process it, and then use it and have

 useful information, and I think that's the big

 challenge today.

 So, those are kind of my high-level

 remarks. I know I was asked to also prepare some

 remarks on price data reporting and no-shows, Dan.

 I don't know if you want to do that now, or if I'm

 changing the agenda. You tell me.

 MR. BUCSA: I think we jumped around a

 bit prematurely, so we can hold off on this.

 

 

 

MR. TUPPER: Fine.

MR. BUCSA: Thank you.

MR. THURSBY: Hello. My name is

 Jonathan Thursby. I'm from CME Group. I manage

 CME's global trade repository business. I'm
 111

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 thankful for the opportunity to sit on this panel

 and talk about data quality and data improvement

 efforts. I won't repeat a lot of the fine

 comments from Marisol and Bruce but would like to

 lend support to a couple of the notions,

 particular the concept of engaging in the

 international standards work that I know this

 Commission has been active in doing. I think

 we're seeing a lot of positive developments,

 particularly in the space of certain data elements

-- UPI, UTI. I would also add in other

 international standard-setting efforts around LEI

 and the hierarchical rollup that are also

 happening, and I think that we're seeing great

 momentum and a lot of coordination around that.

 Srini remarked about the event that

 occurred here -- the workshop that occurred a

 couple of weeks ago, and I think that's evidence

 of the positive inertia that we're seeing. And I

 think that we can be a beneficiary of that, and I

 think following those timelines rather than

 perhaps getting in front of those might be our
 112

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 best course to ensure that the work that does

 occur at both the SDR level as well as the

 reporting participant level is in line with the

 international standards so that the cycles that

 are spent can be hopefully multi-purposed,

 particularly for organizations that have reporting

 obligations in multiple jurisdictions.

I think ultimately when we get to the

 desire to see data transferred across

 jurisdictions and be compiled together to give a

 broader picture, following those international

 standards is going to be our best course there.

 And I also would support the idea that we resume

 the data harmonization efforts that were

 previously led by ODT.

 We had done that initially around credit

 markets. I think that resulted in cleaner data,

 and note that that happened within the SDRs

 without impacting the reporting participants. And

 I think that we had seen nice progress there.

 There was work for a second phase. There was

 engagement -- in fact, the SDRs had come out here
 113

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 to D.C. And had done sessions on that. That work

 did get paused. It wasn't resumed, so I would put

a vote in for resuming that, extending it to the

 other asset classes, and seeing how far we can get

 within the SDR community, particularly taking

 inspiration from the work that's happening by the

 international standard-setters, and let's see what

 that results in prior to turning to the market

 participants and seeking the entirety of the

 marketplace to take action on the data that

 they're reporting in.

 And then finally I would just make a

 remark along with harmonization efforts to just

 see what we've had at times, but I think we can do

more of, which is greater collaboration amongst

 the SDRs and the Commission staff to look at ways

 to improve, particularly with things around

 looking at technical standards and other elements

 that could be potentially imposed on recording

 participants to have that work done in advance in

 collaboration with the SDRs, I think is going to

 give us our best outcome.
 114

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 

 And with that, I guess I will ask the

 question again, Dan, did we want to turn into the

 first theme?

MR. GRIFFIN: Actually, Dan, why don't I

-- since we kind of jumped around just a little

 bit -- Derek, not to put you on the spot, but if

 you want to maybe chime in a bit from kind of that

higher-level perspective from Bloomberg's

 standpoint to kind of set the table a little bit

 for the broader discussion. And then after that,

 Supurna, perhaps if you'd like to jump in and

target in on the discussion of events.

MS. VEDBRAT: That would be great.

MR. KLEINBAUER: So, Derek Kleinbauer,

 product manager for Bloomberg Swap Data

 Repository.

Thank you for the opportunity to join

 today's TAC. I definitely look forward to a very

 healthy discussion.

BSDR supports the efforts by the CFTC to

 harmonize swap data in an effort to resolve

 reporting challenges present in the market. We
 115

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 intend to file a comment letter on the draft

 technical specs for certain data elements. As we

 look to introduce these additional reporting

 fields, and I don't want to hop around again, but

 we are aware that for instances of reporting

 package transactions or compression events, I

 think a common theme that we're going to touch on

 today is the ability to link these transactions.

 Whether we have bifurcated reporting styles of MAT

 legs versus packages being executed on a platform

 or away from a platform, being able to properly

 assess that risk is going to be critical. And in

 order to do that, I think having the linking

 abilities is going to be key.

I would also say, you know, to the

 extent that we can leverage in certain fields here

 information that is already being reported

 upstream, say, by a swap execution facility.

 There are some elements on the order data side

 where the swap execution facilities are reporting

 elements to their trade surveillance. I think we

 could probably do a lot of leveraging there to
 116

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 ensure that the fields are not only consistent to

 Marisol's point and Jonathan and Bruce's points,

 but to make sure the information is going to the

 correct location and what the intent of that

 information is -- whether it's to identify

concentration of risk or trade manipulation, does

 that sit with SDR reporting, or does it sit with

 the SEF reporting? So, I think that's going to be

 critical.

But not go further beyond the agenda. I

 think we can probably leave it there and jump

 right into the reporting of events.

 MS. VEDBRAT: This is Supurna VedBrat

 from BlackRock, and I'm not -- I'm going to try

 not to repeat what people already heard, and I'm

 going to talk about reporting of events looking at

 it from three different angles.

One is, like, the usability just from a

 practitioner's standpoint as we trade. We want to

 make sure that any of you feel that we introduce

 as much as possible. They can systematically be

 provided, you know, whether it's at the SEF level
 117

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

or what have you.

 The second is accessibility of data, and

we need to be able to have access to the data

that's reported either, you know, to help with

analytics that the Commission can build upon in

order to get the complete life cycle of the trade.

 And then the third element of it is on

linkage, because if you look at reporting of

events that are outlined for discussion on

compression and allocation, when a buy side firm

is participating in any of these trade execution

methodologies, it is very possible that the

initial trade (inaudible) indicates of an

allocation, what we would do is block trade it,

and then that block would be allocated. But the

block trade is executed on a SEF, and depending on

what SDR -- what SDR the SEF is using as the

reporting entity, you know, it could be different

from the entity that the CCP is using.

 For example, if you traded a trade on

Tradeweb -- a block trade on Tradeweb -- and then

we allocated it to the CME because it was a CME
 118

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

swap, you won't have the full life cycle of that

trade in one SDR. And for that -- in order to be

able to understand, like, the complete trade,

whether it's, like, from a surveillance

perspective or a market risk perspective, it is

very important that that data is accessible and

the Commission is able to build the analytics on

top of that data and be able to follow the swap

completely.

You know, from a linkage perspective,

one of the suggestions that we would like to make

is perhaps giving the client or the market

participant the ability to select which SDR they

would like their trades to be reported to, because

by providing that type of ability, you could

potentially report the complete life cycle of the

trade to a single SDR, which would make it much

more accessible and easier to be able to do any

type of analysis.

I think in the current proposal there

are certain fields that we can benefit from. I

think we also have to be careful with the number
 119

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

of event types, and in certain situations you may

have multiple events that may apply to a

particular swap or, you know, with a unique swap

identifier.

 And then the other component of it to

consider is there are going to be certain event

types that you do at time of trade. So, for

example, when you're trading a block and you're

allocating, a time of trade you know that you're

going to be allocating those trades, so it's --

and we can define that event type when we're

trading. For a trading strategy such as

compression, which you know, for purposes of risk

management, it's considered to be much more a

post-trade event.

You don't know when the initial trade

was done, if that trade was going to be part of a

compression or not. So, we also have to think

through, as these event types occur in the life

cycle of the swap, at what point do we include

them, and when we include them, is there a method

by which we can translate or transmit that
 120

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 information both downstream and upstream, because

 I think in the current environment today, the data

 is flowing forward, which actually helps the

 integrity of the data. But if you start to

 include additional events that are happening on

 the swap, that type of information may need to be

 transmitted backwards.

 MR. GRIFFIN: Thank you, Supurna. I

 want to open it up to the broader membership if

 anyone would like to chime in. Pierre?

 MR. LAMY: Yes. Pierre Lamy, Goldman

 Sachs. And I would also like to point out that I

 also have been working on the FpML standard for

 many years, and I currently chair the FpML

 Standards Committee.

So, when I look at the proposal for the

 list of events that are being proposed, what

 strikes me, as Marisol pointed out, is those

 events are very, very detailed and go well beyond

 what is currently used on the marketplace. I know

 as part of FpML, we have standardized the way to

 report and to describe events. We do not go to
 121

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 this level of granularity, and even within Goldman

 Sachs, the way we frame events, we also have a

 shorter list of events, because we don't think

 that we need to go beyond that.

 So, I think I would echo what Marisol

 pointed out, which is as part of that (inaudible)

 recommendations, a number of firms would struggle

 to implement this very detailed set of events.

 And that would compound the issue that we're

 currently seeing as part of the quality of that

 reporting.

 And I think when I look at the proposed

 consultation, it strikes me that there are two

 elements. There is trying to normalize a set of

 data which is currently reported and another set 

 of elements is introducing further data elements

 for reporting. And I think I would be -- what I

 would suggest is (inaudible) the information that

 we currently report -- and I will talk later on

 today about validating the data that we would

 currently report -- before going to a further step

 and significantly enlarging the set of data points
 122

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 that we look to collect, because unless those are

 completely indispensable, the risk is you will

 compound the problem of data quality by going

 through such approach.

 MR. LEVY: Thanks. Okay, I'm just going

 to hit on the two specific areas of compression

 and allocations. I agree with a lot of the

 comments already made, and for those that don't

 know, we sit, as the other side of coin, to some

 degree for many of the SDR activities that goes on

 at DTCC, and we're a major provider of the data in

 on behalf of many of the end users.

 You know, there may be rules that are

 already on the books that aren't really being

 looked at or enforced as much. We definitely see

 the data quality issues on trades that are part of

 other processes versus trades that are just put in

 as part of a reporting, and the quality is

 definitely higher. Just to validate what Marisol

was talking about, we see that from our side.

 But there's also maybe an element of

 functionality being out there, or ready in
 123

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 providers like ourselves and others, that is just

 being underutilized and could be. We would agree

 that the granularity of the information that is

 looking to be provided is a bit too much, but we

 do applaud the attempt to get to that detail. But

 we do think it needs to be brought up a level.

The fact that a compression is bilateral

 or multilateral may be interesting. I don't quite

 understand why that would be relevant from a

 reporting perspective as much as it's part of a

 compression, because often compression trades,

 whether they're new or terminations, are not

 economic events. So, at a minimum, it's important

 to identify that trade as different, not

 necessarily to identify how granular you need to

 be in describing that difference, so just saying

 it's part of a compression may be enough there.

The other thing that we have done that

 is used to varying degrees is this idea of a bulk

 processing ID where there is some bulk event,

 credit events, or compression events, particularly

 compression here, where you can say not only is
 124

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 that a compression event at the trade level, but

 it's also part of the bigger event. And again,

 just to validate what Marisol said, the bilaterals

 that get done off of third-party platforms are

 very tough. The data quality is not great, and

 people tend not to provide it even when we can

 take it, and then we therefore can't send it

 downstream; whereas those provided by the

 third-party venues for doing compressions, whether

 they're compression engines specifically or

 clearing houses, tend to result in better data.

So, again, just came off of what Marisol

 was going through.

 On the allocation side, it's somewhat

 similar. You know, we have the ability to call up

 a block, to define a block USI for an asset

 manager trading with a counterparty. We can then

 take an allocation-level USI at the fund level to

 a counterparty. We can maintain those linkages

 and report the block as essentially the former

 real identifier, whereas the allocated trade is

 related to that identifier.
 125

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 So, again, we are not the only ones in

 this market with some of this functionality. Some

 is embedded in other middleware, in other SEFs.

 We do think that there's a range of functionality

 that's available that will make the data better

 just by using some of the kit that's already

 available on the shelf.

 Admittedly, people have not necessarily

 tried to optimize reporting as much as just say

 that they've reported. And I now think we're

 probably into the mode more of optimization; and,

 to Pierre's point, maybe the focus should be more

 on optimizing where we are but at a minimum, walk

 cautiously into adding numerous fields at a

 granular level. That doesn't necessarily add a

 ton of value to the industry until we figure out

 how to create some value from what we already

 have. We do believe that some fields need to be

 added. We just see the pattern of, if four is

 good then maybe twenty is better. Just because

 that granularity may be true; it just may not be

 relevant.
 126

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 MR. GRIFFIN: Commissioner Giancarlo.

 COMMISSIONER GIANCARLO: Thank you.

 Brad, I found that very interesting. You've

 referred to functionality and perhaps -- I don't

 want to use a word you didn't use -- but expertise

 that you have that might be underutilized. Do you

 feel that perhaps we haven't done enough to reach

 out to some of the expertise that's available or

 some of the market granular understanding that's

 available to inform our process?

 MR. LEVY: Yes, I think there's a bit of

 that. We'll talk a bit more about some of the

 work we've done about trying to provide the CFTC

 with information about what is happening up and

 downstream.

 We have a clear view a lot of what

 happens once a trade is done and beyond. Upstream

 is a little more challenging. We'll talk a little

 about order data, maybe being married with that.

 It's not necessarily that we should have that nor

 should it be in the SDR, but somehow it may need

 to be linked. And, again, we're going to pick up
 127

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 on that thread in the next theme. But I don't

 know if it's people knowingly not doing something

 as much as just the usual -- if it's not screaming

 broken right now, it tends not to get the

 attention.

This is definitely something we all want

 to get through and make it better in terms of the

 data being reported in a less costly way and the

 data being usable, more importantly, and we just

 think it's -- really, people coming around to that

 now, given people are able to take a bit of a

 breath and maybe optimize what's already out

 there, which is really where our concern is, where

 we won't do that if we pile a bunch more onto what

 already exists. And some of what is being asked

 to be added could be very relevant and very real.

 But as we all know, priorities and

 resources are stretched, and if there is a bunch

 of new requirements, it's going to be tough to

 optimize what we already have on the table.

COMMISSIONER GIANCARLO: It raises a

 concern I have, and I'd like to see if it
 128

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 resonates with members of the Committee in that, a

 question as to whether we really have the right

 people around the table, whether we're going about

 this in the right way. There's an excellent piece

 in today's Wall Street Journal on the really just

 groundbreaking work that's being done in big data

-- everything from consumer retail but all the way

 over to health care and public policy and social

 networking; and the science is just really

 breathtaking in its scope. And there are centers

 of excellence in this in places like Google and

 Amazon and others, and I just wonder whether we

 are really bringing this to this very important

 task. There's no question that getting this type

 of visibility into our trading markets, especially

 the swaps trading market, in the wake of the

 financial crisis is vitally important. I just

 wonder whether a primarily regulatory-driven

 effort -- and I don't mean to be flippant, but a

 government that's struggled to build websites,

 whether we have the expertise to build a big data

 analysis capability or whether we ought to be
 129

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 looking to commercial centers of excellence and to

 market participants in a broader way to get this

 right.

 MS. VEDBRAT: Commissioner, this is

 Supurna. You know, when I made reference to the

 analytics, it was exactly like the point that

 you're making. We have a decent set of data, and

 if we're able to actually build the right

 analytics on top of that data, which is

 essentially a sense of big data, it may help the

 Commission with some of its end goals, because

 right now the fragmentation of data -- and to

 Brad's point on, like, all the prophesies not

 being, you know, used to the maximum as such is

 causing some data integrity issues -- putting

 those two pieces together -- and I think we have

 the expertise within the TAC members and the

 broader community to be able to help with some of

 those analytics.

 MS. FUHRER: I'd like to make a point on

 this topic as well.

 On the plane on the way here I actually
 130

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 read the same article and was intrigued by it, but

 in my view there really is a difference between

 the science of big data and the type of granular

 detailed information that we're talking about over

 here. And I think both of them play a part, but I

 think we need to be very clear that we understand

 what the different expectations are between the

 work that we're talking about here, which can be

 used in reporting, trade surveillance, et cetera,

 where when we go back, as the speakers were

 talking about, we're looking for data integrity,

 quality, making sure that it's very (inaudible),

and, you know, I can go on and on about the types

 of disciplines we need to have around the data to

 make sure that it's usable and the conclusions

 that you come to are accurate.

The way I view big data -- and I have

 spoken on big data at different conferences in the

 past -- is -- and if you read the article in the

 Wall Street Journal carefully, it's more about

trend analysis, causality, inferences, and so on,

 but not necessarily a cause-and-effect type of
 

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 131

 thing. So, you could say that people who tend to

 buy a certain number of things may also go and see

 these movies or whatever. I'm just using, you

 know, things that are outside our purview on

 purpose. And it's a different type of conclusion,

 an important one but a different type of

 conclusion than I think we're talking about now.

So, to address the question: Should we

 broaden our view on data to include big data

 analysis? I think it's something we should talk

 about, but I would caution the Commission that we

 need to be very, very clear as to what our

 expectation is if we do include big data and big

 data kinds of science and big data analytics.

 MR. GRIFFIN: I believe we had Steve and

 then Pierre. And we've got a few more coming.

MR. JOACHIM: We have -- FINRA has about

 35 years of experience in the equity business of

 gathering, collecting, and analyzing data for

 regulatory purposes; the fixed-income business

 about 14 years. We've gone through many of the

 pains that you're going through today. So, we
 132

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 understand and feel some of the pain and problems

 and difficulties you've got. But let me first

 address the big data issue, and I'll come back to

 that. Because we are actively investing very

 heavily in big data environments.

 There's a process that has to take

 place, and I would applaud you and encourage you

 to think about big data analytics in the long term

 rather than the short term.

I think as Evelyn talked about before,

 some of these analytics are just beginning to

 mature, but getting your data structured in a way

 that you can analyze it effectively to use these

 tools, stored efficiently, as we move to big data

 and storage data, storage environments, we found

 incredibly dramatic improvements in terms of cost

 and analytic speed that you can achieve by using

 some of these new tools, even in their infancy

 today. So, I don't think it's too early to begin

 to look at these issues, study them, understand

 them. And, using external advice as well as

 internal advice is a powerful thing. And I offer
 133

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 this in terms of going forward is, we're always

 happy to offer our good offices to help as you

 think through that in any way we can, with your

 staff, and share our lessons learned.

But I absolutely agree with what Evelyn

 also said, which was that the data collection

 process itself is not really a big data issue.

 It's a kind of roll your sleeves, get in the

 ground, get in the guts of the organizations, and

 work this thing through very carefully. It takes

 many years and takes time to get this data

 accurate, complete, and reliable; and some of the

 issues you're dealing are issues that are

 relatively common as you go through the process.

 But much of the advice that people have talked

 about today -- I don't want to repeat it all -- we

 think are very powerful tools. Keep things simple

 to start with. And settling -- and I do this all

 this time internally because I'm on the data

 ingestion side of the business in the creation of

 the database at FINRA, but our examination and

 rule enforcement people always want more.
 134

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 And getting the right balance is very

 important at the right time, so everybody is ready

 to perform, because you have to get -- what you

 get in, you have to be able to rely on. It has to

 be accurate, complete, and timely. And to do that

 requires, at least in our experience, a real-time

 exercise of cleaning the data, validating it,

 ensuring it -- not just on the sender side but on

 the receiver side -- with an active dialog between

 the parties to ensure that the information is

 being done accurately and completely as close to

 real time as possible, and then a historical

 analysis on top of that to ensure that the data

 looks consistent and is fair. And then you should

 combine that with some kind of an examination

 routine to ensure that everybody's reporting,

 because one thing we found over time: No matter

what the rules say, there's always some people who

 forgot, and we always, even 14 years later on the

 TRACE side, we still periodically find buckets of

 business that should be reported under TRACE rules

 that are not today. So, very important to do
 135

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 that.

The validation process is critical.

 Thinking through the linkages, though, is really

 an art. We have spent many years working and

 refining through the process of linking equity

 orders to each element of the trade execution

process as that's gotten more complex, as the

 business in the equity world has moved from being

 purely exchange driven to being over the counter

 and exchange driven.

 Over-the-counter and exchange executions

 that require mobilization of lots of the data

 across many reporting venues, which is not unlike

 what you're doing with the SDR world, and thinking

 through those linkages and actively working

 through that process is a complex, detail- 

 oriented process that requires a great deal of

 dialogue amongst all the parties but also with the

 regulatory view of what needs to be linked and how

 it has to be done. Some of that can be done by

 machines without human interaction; some of it

 requires coding and analysis up front.
 136

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 What we do in the equity business and

 fixed income business isn't directly a linkage

 here; it's lessons to learn. There are things you

 can extract from our processes that we're more

 than happy to share with you and work with you to

-- and then we've done some of that already, so we

 would offer our good offices to continue to help

 with that process. And we think, quite frankly,

 as you talk through ensuring you have integrity

 across global jurisdictions, in keeping those

 linkages tight as you think about instruments,

 it's important to think across -- especially in

 the package instruments where you're talking about

 the underlying linkages, people shouldn't have to

 report these transactions in multiple venues in

 multiple ways. We should find ways as regulators

 to be able to link across our environments so that

 the data can be reported once and reported once in

one comprehensive way that allows us to link

 across those environments, and that requires a

 tremendous amount of coordination and effort. But

 there probably are ways where we can do that more
 137

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 effectively and efficiently than we do today. So,

 I want to encourage you to continue to do that.

With that, I could probably talk for

 another hour, but I won't do that. But thank you.

MR. GRIFFIN: Pierre, I believe you're

 next and then Bruce and Jonathan.

MR. LAMY: Thank you. I would like to

 echo what Commissioner Giancarlo was asking, which

 is: Does the CFTC sufficiently leverage what

 exists already out in the marketplace or what is

 being developed?

I would like to comment on the specific

 question of data standardization, because I think

 the reason we are discussing these draft technical

 specifications is because -- the reason we have

 all those data quality problems is because there

 is not sufficient data standardization. So, there

 are definitely some topics - reporting of package

 transactions, we have noticed a few times -- on

 which there is a need for further data

 standardization.

But to a large extent, there is already
 138

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 a very significant level of data standardization

 that exists in the marketplace and is not

 sufficiently leveraged as part of these, and what

 I see is, and what I'm being concerned about is,

 the risk in which we will see specific regulators

 developing their own definition and their own way

 in which they want to see the data reported

 despite the fact that there is definitely, under

 CPMI-IOSCO, a trend to try to normalize the data.

We still see those efforts being done,

 and I've been, once again, working for many years

 in developing the FpML data standard among which

 there is a large number of market participants.

 It takes a lot of work to develop those standards.

 And developing yet another way of doing things --

it's not the most productive way. What we should

 rather do is look into leveraging the standards

 and adjusting the governance of the standards if

 need be, because, speaking for FpML, we are very

 keen and we're very open to the idea of adjusting

 the governance of the FpML standard to reflect and

 to adjust as a reality of usage by regulators. It
 139

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 is just -- and we think this is the right way to

 go, because those standards reflect the current

 usage in the marketplace.

 MR. TUPPER: I think in regard to the

 concept of big data, we look at the size of data

 that all the repositories consume, and it's a fair

 amount.

But I don't know if I would quite

 categorize it as a big data issue. What I would

 say is, as a repository, we struggle at times to

 understand what is it the Commission wants to do

 with the data and how can we best provide it.

 That is, we're very, very familiar with all the

 rules, and I understand all the work flows and how

 data should be sent to us. But what is very

 opaque, at least to me, is when I send data to the

 Commission, what is being done with that and how

 can I best help you facilitate your oversight

 duties. And without understanding that, it's very

 difficult, and each of us in the early days -- we

 took these sets of fields, and without guidance we

 created our own standards and validations around
 140

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 it. Not to say who was right or wrong, but we

 were left to do that, and obviously there are

 three different sets.

We were able to harmonize our sets, I

 would say in a field of short order, with CDS,

 which has a high degree of standardization. Fine.

 So, we've proven that we could do this in a small

 set of data, but what we need to understand better

 is: How do you want to consume it, and what are

 you going to do with it? That will drive the --

 we talked a lot about, without getting specific,

 various workflows -- package trades, you know,

 valuation reporting. I don't want to get into

 those details, but understanding that better will

 allow us to build the messages and the collection

 of fields to facilitate that reporting. And I

think, really, that's what's going to help correct

 today's problem.

MR. THURSBY: I am going to attempt to

 maybe tie together a response to a couple of

 themes that were brought up about linking -- maybe

 leveraging better under leveraged standards that
 141

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 are already existing today -- by way of talking

 about the SDR rules amendments for clearer swaps

 reporting. I want to start off by first

 acknowledging and complementing the Commission for

 understanding the two different market structures

 that really exist. The original rule set really

 was a one size fits all and I think there clearly

 are different workflows with different market

 participants engaging in that and what I would say

 though is that I would encourage that the outcome

 of that be in line with the proposals and the

 comments provided by CME both during this

 iteration as well as prior iterations on the

 topic, whereby the mirror act of the submission of

 the swap for clearing solves for the act of

 reporting and in extension to have the DCO perform

 reporting on the alpha side of an

 intended-to-be-cleared swap. The outcome of that

 is that you have all of the relevant data in a

 single data repository. You move from a situation

 of having hundreds or potentially even a thousand

 reporters down to say less than five and that is
 142

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

immediately going to create the standardizations

that exist within clearing organizations. That is

going to create a homogenous data set there, as a

large percentage of each of the driven markets are

already cleared and more is moving in that

direction. That's going to be a big boost towards

data quality that exists and that is going to, I

think, really better the overall goals which is

having data that is standardized that is coming

in, and I think the path to that is readily

available and actionable. So I would encourage a

relook at that direction and that path.

MR. GRIFFIN: Marisol?

MS. COLLAZO: So wow big data. I would

certainly echo that the task we're looking to do

really involves much more I would say

collaboration and one of the comments that came

out today is resurrecting or instituting this subworking group. This is about -- it requires a

high level of discipline and focus around looking

at the data that is already collected. As SDRs we

obviously have a lot of knowledge about the data
 143

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

that we're receiving. In some cases we can look

across and see where there are global

harmonization opportunities utilizing the data

provided already. That has to from our

perspective be the key jumping off point. So

perhaps in parallel the Commission should also

look at big data and start to consider that. But

to solve for the issues today, if we had more

frequent communication with staff, really focus on

perhaps a narrow set of the use cases that were

being explored and see what does the data tell us?

Internally within DTCC, that's how we started.

You have to simplify the problem. If you start to

look at all the possible permutations and take

purely an academic approach, it is going to be too

disconnected, and so the very simple approach we

took is what problem we're trying to solve for and

we had to collect the data and start to look at

that. So my recommendation here is that, with the

people that are both with the Commission as well

as with the people that we can provide from an SDR

perspective, we can solve for this. And as stated
 144

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

by both Bruce and Jonathan, we actually did for

 CDS, for a very narrow set. In many cases we

 actually asked the CFTC to let us do the work and

 present back our proposals based on the analysis

 that we saw and where we could come to a common

 understating so it is absolutely solvable. It

 just requires what I would view as a bit more

 collaboration and more frequency in terms of

 getting together, understanding the use cases and

 really diving into the data.

COMMISSIONER GIANCARLO: Did we accept

 your offer?

 MS. CALLAZO: Again I hope so. I hear

 that that is a proposal in terms of next steps in

creating a subcommittee so not having heard too

 much content about that, I think that would be

 certainly very welcomed -- certainly by ourselves

-- and this is kind of a recipe for what we can do

 going forward.

 MR. MCDONALD: I totally agree with

 that. I think, with all due respect, I don't

 think this is a big data program. I think that it
 145

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 is actually fairly simplistic. I think that, to a

 large extent, most of the analytics today exist to

 be able to look at the data we deal with TRACE and 

 FINRA data and all the rest of that, and this is

 really a data quality problem for me and I

 actually think that around the table or in the

 room there are pretty much all the people needed

 to solve this problem and just to echo Bruce's

 point I think if we understand as a group better

 what it is you're trying to do with the data I

 think the group is going to be better placed to be

 able factor the data in a way that is more usable

 and we are certainly supportive of participating

 in that and helping solve this problem which I

 think at the end of the day is just about data

 quality and just the right people getting in a

 room together.

MR. TERRY: Hey Ward this is Marshall

 Terry on the phone. Sorry I couldn't make it

 today.

Can you hear me?

MR. GRIFFIN: We can hear you.
 146

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. TERRY: So just one thing I think

that is interesting here -- and I agree with

everything that has been said -- but as a small

hedge fund manager up in New York -- I'm the COO

of the firm -- I would caution that the folks you

need in the room are not just the DTCC's and such.

I think you need some of the folks that we connect

through, whether it is the admins or what have

you, because I do know one of the things we

struggle with as a small manager is trying to

figure out how to afford all these initiatives and

I agree this isn't a big data management issue --

this is data management in and of itself. And it

is a very expensive proposition, I think, for

smaller managers and folks in general. So I would

caution -- I applaud the idea of having these

subgroups, but I might suggest if they're not in

the room, that you broaden the offer to some of

the folks that we rely on to interface with the

likes of DTCC and Bloomberg and what have you.

Meaning the fund admins or what have you, because

they struggle mightily to try to connect all these
 147

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 different end solutions. I think they can give

 you some insight on the upstream issues they have

 with folks like myself who are working with more

 limited budgets to try to meet these requirements.

 So it is just an observation from where we sit.

 MR. GRIFFIN: Thank you Marshall.

 Bryan, and after Bryan, I think we may want to --

 I know we're cognizant of time here and we had a

 few themes we wanted to try and get through. I

 know some of the co-leads had put some work in so,

 I wanted to make sure we try to cover some of that

 ground.

MR. DURKIN: Yeah we just want to be on

 record to support the resurrection of the data

 harmonization committee as well. You guys were

 able to tackle a really difficult process getting

 out of the gate by bringing all the SDRs together,

 working with the Commission staff and in this

 committee, they were able to solve a lot of

 complexities very quickly and people were

 extremely excited about the level of engagement

 and collaboration that was going both ways with
 148

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 CFTC staff and the SDR representation to getting

 the problem solved. And so in line with Marisol

 as well as Bruce and Jonathan to get that

 committee resurrected, I think it will help solve

 a lot of these issues.

 MR. HEHMEYER: Just one quick comment by

 way of -- I know it is different -- by way of some

 perspective though, if ICE or CME walks into our

 shop tomorrow and wants all of our data from three

 years ago it better be perfect, or they fine the

 bejesus out of us.

 MR. GRIFFIN: Thanks, Chris. So I know

 we've covered a lot of ground here and we've

 skipped around a little bit, but I would like to

 try and refocus on the 25 or so minutes we have

 left on some of the other themes that we had

 discussed previously -- and Derek and Brad, I

 don't know if you want to take up and discuss

 anything on the order data and packages.

 MR. LEVY: Yes sure and I think some of

 the themes are going to be consistent. These are

 just specific discussions around order data and
 149

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 package transactions so I will kick that off. We

 don't have a place in the order data side of

things as much, given what we do is more at the

 trader or immediately after and then down stream,

 but it is definitely relevant as we've been asked

 to provide certain information about what we see

 based on our flow and then how to marry that with

 what may be happening up stream. One thing at

 least just to separate the two topics on the order

 data side, one element that has been proposed is

 this idea of price discovery mechanism and there

 is a number of fields that have been suggested.

 Again it looks like an example of all of these do

 technically exist potentially in some situations

 or maybe rarely where there are ideas that could

 come about. But when you really think about it,

 what is the purpose of getting 10 or 12 different

 methods of price discovery and differentiating

 between RFQ versus RFS versus a limit order book

 versus a central limit order book. I think there

 is a category called permitted transaction which

 maybe is a catch all for things that don't fall
 150

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

into the other categories. But again it seems like

maybe there is something there where the good

being the enemy of the great -- or the great being

the enemy of the good -- and can we get some level

of information so that it is clear that maybe

things are moving to a more automated, centralized

environment versus a non-automated centralized

environment. There is also the element of voice

trading and again the laws are what they are in

terms of what is permitted. It does seem like

there is some information that the regulators and

the Commission itself is trying to get to, to

understand how is the market evolving which we do

think it is important to understand how that

market is evolving. The question is, is that

really part of the regulatory requirements or just

part of an understanding, trying to get an

understanding of how the market is evolving. So I

think just that idea of order data maybe zeroing

in a bit on the price discovery mechanism and

other views from others here that may have a view

on whether it is too broad, too deep, too soon and
 151

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 maybe what kind of information might be valuable

 for the market as a whole and the regulators 

 within it. So I don't know if anybody around the

 table, it's more people I would imagine that are

 involved in the execution space. I know this is a

 data -- more of an SDR -- discussion, but there is

 definitely a desire that we see, especially based

 on the proposal, to get not just that at trade

 down stream but a lot of the information that

 happened that created that trade or that got to

 the point of doing that trade, which again we

 don't see as a platform but we do understand the

 desire, we're just trying to figure out where is

 it really placed in terms of what is driving it

 from an outcome perspective, from a regulatory

 perspective. I don't know if anybody has any

 specific points on order, information specifically

 or the price discovery mechanisms that have at

 least been suggested in the request for comment.

MR. GRIFFIN: Dan if you want to jump in

 there.

 MR. BUCSA: And, just to be clear to
 152

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 frame the scope of that part of the document, it

 is only for executed transactions done on

 facility, was the limit to that order information,

 just to help guide the conversation going forward.

 MR. LEVY: Yes, I understand. I guess

 our view would be it still seems a bit granular

 for just what is really the goal of the

 regulators. Do they want to understand truly the

 difference between a central limit order book

 order and a limit order book order. I understand

 that the desire may be to move more electronic or

 less, or maybe to have more anonymized trading

 then disclosed trading. The question is how

 granular do you want to go in the reporting

 requirements to get to that level of detail or do

 you want to utilize other mechanisms to understand

 that trend.

 MR. THURSBY: And maybe just a take

 from a slightly higher level, to maybe ask the

 question, is it necessary or appropriate to

 collect that order information within the SDR. Is

 that not something that is already made available
 153

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

through the regulatory oversights of SEF and DCMs,

and is it not already available through a lot of

the audit trail information?

MR. KLEINBAUER: Just looking through

the order data and obviously having a part in

Bloomberg SEF -- to echo Jonathan's point, a lot

of this information is provided today by either

SEFs or DCMs to their trade surveillance. So, it

is not necessarily a matter of that information

not being made available. It is what is the

proper destination for that -- is it the SDR or is

it another form of oversight? So perhaps a

further discussion with multiple SEFs and DCMs

would be a good starting point.

 MR. LEVY: So I think one of the topics

also in this theme that is probably going to get a

bit more attention is the package transactions.

This is something that has been a big discussion

as part of packages. Some products are

technically included in the regulations and some

instruments within a package that may or may not

be included in a regulatory framework do impact
 154

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 the economics of the trade. We have spent a lot

 of time on this ourselves because it is important

 to be able to identify these trades and we'll look

 to do that at times. I would say in general the

 CPMI-IOSCO idea that you really look at that

 individual instrument level to really define a

 part of a transaction, then with the idea that

 there is some ability to indicate that this is

 part of a larger transaction and maybe even having

 an identifier somehow for that larger transaction.

 Again is it important that all of that is

 completely disclosed, clear, and everybody can add

 all of those elements up and get to an ultimate

 price, we're not sure. We think it is a big lift

 and maybe even a bit of an overreach from a

 regulatory perspective. But we think at least the

 most important thing is to say those are two

 apples that you could compare, that's an orange.

 At a minimum you should look at that differently.

 You may not be able to judge the color, the weight

 and everything about that orange but at least you

 know you can't just compare it to those other two
 155

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 outright transactions. This is probably relevant

 for the compression discussion as well as how the

 market understands when it hits the tape, what is

 the value of that instrument? Other markets have

 dealt with this where it is effectively uneconomic

 trades or trades that are off market and somehow

 indicate just to the world that just warning this

 is a bit different and over time we believe that

 that difference can be more understood. Maybe

 that is where big data comes in, where people are

 looking at lots of disparate information and

 trying to understand trends as opposed to it's a

 regulatory requirement. I do think there is a

 place for big data and it is not in swap data

 reporting as much as financial systemic risk and

how swap data reporting fits into that puzzle,

 different discussion. But the idea that packages

 can be defined just at the package level and then

 fully disclosed at every level up to the price or

 down at that instrument level or a bit of both.

 So our view is more at the instrument level with a

 wrapper to at least indicate that these are linked
 156

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 and again we've from a platform perspective, in

 working with the industry, have been developing

 that level of functionality to make it clear at

 least that something is a package. So I'll just

 open it up there. I think others have more views

 on this topic.

 MR. LEWIS: Just a very quick

 substantive point. Obviously the major use

 besides the CFTC is transaction cost analysis for

 all the things we're saying and I would urge the

 Commission -- in prioritizing, improving, in terms

 of the quality of the data and the usability of

 the data -- obviously to focus on pricing, but

 moreover to the extent that other prospective

 deadlines slip -- and I'm thinking particularly of

 package trades -- I would then accelerate the

 importance of addressing the data piece. Because

 I think that, to some extent, the data piece

 solves some of the problems that are trying to be

 addressed by mandating different execution

 systems, the MAT-ing and other things. So to the

 extent, like I say, the package trade requirement
 157

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

may slip, fine. But that would argue I think for

 accelerating even in a unilateral U.S. basis,

 requiring meaningful price discovery by which I

 mean, actually, a usable price so guys can figure

 out if they're getting hosed or not. That would

 solve a lot of the problem.

 

 

 MR. GRIFFIN: Jonathan.

 MR. THURSBY: To answer maybe more

 specifically to the question that was posed, in

 the case of packages around identifying the

 package transaction. So in the case of the

 packages submitted as the component legs, we feel

 that the package or the strategy ID field that is

 proposed by the Commission is sufficient to link

 the components together. For packages that are

 submitted as one economic transaction, we believe

 to expect the product strategy ID field to be left

 blank and then the USI to be utilized. And with

 this, we -- Brad, I think along with your point --

 recommended an ID field -- like a package trade

 indicator field -- be useful to enabling to see

 whether or not it is executed as a package or if
 158

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

it is done as a single economic transaction. With

 respect to pricing, it was unclear to us whether

 the Commission thought that there would be

 interplay between the price field and the package

 trade price field. Should reporting parties be

 filling out one or both? So that was unclear to

 us.

 MR. BUSCA: So to answer your last

 question Jonathan, the way to think about it and

 maybe how people could formulate their comments is

 if we're talking about a package and it's traded

 on a spread where there is some basis to be done,

 what is the right way for the Commission to

 understand either what was the spread that was

 exchanged or what were the strikes of the

 different legs and what is the best way to

 represent that in the data, is probably how you

 want to consider the letter.

 MR. GRIFFIN: Any additional comments?

 Anyone on the phone?

 MR. BUSCA: Just before we move on --

 for real time tape and the public dissemination
 159

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

purposes for all the SDRs, if there is a package

swap that hits the tape, there is no identifier

indicator for people to look at currently that it

is one, correct?

 MR. KLEINBAUER: Right, so we do have

the ability to link transactions but in terms of

being able to flag those in a public

dissemination, I think that is probably where we

get the most questions from market participants is

seeing something hit the tape that looks off

market to Brad's earlier point, that is in fact

part of a larger transaction. So making sure that

we can publically disseminate that not to

introduce noise I think is going to be pretty

critical.

MS. COLLAZO: Yes, so two things, not

having the part 43 rules with me, I do think that

the field -- so part 43 is quite enumerated in

terms of what we can disseminate on the real time

price -- I don't believe that that is a field.

The one area of caution is before we consider

adding it as a field, let's make sure the data
 160

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 that is coming in is of high quality because the

 worst thing we can do is put that out there and it

 doesn't signal the right message. So, agree that

 it does produce a somewhat illogical result

 because it looks like an off market trade and we

 should look at it but we should have a baking-in

 period where we see that field come in, that we

 see the quality that is coming through, and then

 subsequent to that, that becomes a field that gets

 added to the real time tape. I think we have to

 use a lot of caution in terms of what fields we

add to real time and that we're not

 misrepresenting information that could yield some

 other unintended consequences.

 MR. GRIFFIN: Great. Now might be a

 good time to transition to our next theme, which

 is reporting of pricing data. Pierre, would you

 kick us off?

MR. LAMY: I will try to go swiftly

 through this short presentation, so as to leave

 room for discussion. So as part of the proposed

 specification, the Commission staff proposed to
 161

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

normalize price information through four fields,

 which is the four spreads, the price, the price

 type and the price currency. In relation to that

 proposed specification the question I'm being

 asked about, do we need the additional data

 elements, these are derived from knowable values,

 should we have differences across asset classes,

 and also the question of how should we involve the

 case of post-pricing trade swaps. In order to

 comment on that, I would like to start by what is

 the current state of affairs as it relates to

 reporting of data. And if you could move to the

next slide, CFTC Part 43 which was issued in 2012

 actually normalized and specified the way price

 should be reported through the price notation and

 the additional price notation fields. I will not

 go through the full definition. I would just like

 to point out that the as part of those definition

 for price notation, it specified that the format

 in which pricing characteristics is real time

 reported to the public should be the format

 commonly stored by market participants for each
 162

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 particular market or contract. So as we looked

 into complying with Part 43 rule on the market

 participant side, we thought that what we should

 do is look to document and normalize the way the

 market practice would fit into the reporting of

 price notation and additional price notations,

 because our concern was if we would not develop a

 standard approach for reporting and not bring the

price information into those two fields we could

 be a little bit inconsistent across market

 participants. So, under ISDA, what we developed

 at the time, and I was involved as part of that,

 is a very detailed documentation, asset class by

 asset class, as to for each of the type of trades,

 how should we map the value into price notation,

 additional price notation. If you look at the

 next slide, this is just a snippet from a credit

 derivatives product into for each of the

 transaction types -- and this is just the subset

 of the transaction types -- with the comment that

 those transaction types we should report the

 spread in basis points, in this case it's --
 163

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 percent of notional amount, et cetera. So that

 has been very thoroughly documented and at that

 time was shared with, of course, the Commission.

 An example of what developed, et cetera. So if we

 looked into where do we stand now with respect to

 the quality of the data that is being reported and

 DTCC worked with us to just take three months of

 data and see for a very small snippet of

 information on credit derivatives, is to what is

 the quality of the data with respect to that

 standard that was issued at the time and very

 interesting to see it is very uneven. If you look

 at CMBX it is 12 percent consistent with the

 standard when iTRAXX Europe is 90 percent. So if

 we stand back at this point in time the question

 is -- is that the data standard? Because the data

 standard was issued at the time and was worked out

 or is the question of first endorsing the standard

 which goes back to the question of the Commission

 leveraging market participants in the work that is

 being done. And number two, is validating against

 the standard and that is really for me the essence
 164

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 of the recommendation, is on this specific topic

 of price reporting, the issue is not

 standardization because the standard was developed

 at the time and a very specific standard. The

 issue is endorsing the standard, number one, and

 number two is validating against the standard. We

 already have a standard. And I believe very

 interestingly, the standard was not based on

 specifically applying what has been ruled by the

 CFTC at the time. The second point as it relates

 to my other point is swap price, post-execution,

 is one of the questions that has been asked as

 part of this consultation, is we think that the

 reports should be postponed until such time that

 the price is known, because reporting a

 transaction without a price is not meaningful and

 could also expose information about investment

 strategy that is being pursued by the investor and

 by the market participants, so we would be better

 off postponing the reporting of this transaction

 until such time that the price is known.

 MR. GRIFFIN: Gary, if you wouldn't mind
 165

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 advancing to the last slide -- I don't know if

 folks in the audience saw the recommendations.

 Perfect. Paul would you like to chime in?

 MR. CHOU: Thanks. I have some comments

 prepared about price reporting and the nature of

 price reporting and what I hope to show is that

 we're kind of going through this process right

 now. So a lot of the kind of issues for data

 standardization and how to represent complex

 trades, whether packaged or more exotic, are

 directly starting to affect us as we're starting

 to integrate at LedgerX. We're a recent SEF and

 DCO applicant so this issue of price reporting is

 top of mind for us as we're designing all the

 infrastructure, doing the testing and things of

 that nature and seeing the kinds of products that

 we can now list with the kind of data fields that

 we have. So I appreciate the opportunity to kind

 of share some of these stories here. LedgerX's

 goal, to give you context, is to be the platform

 to list, trade, and clear options and derivatives

 of Bitcoin. There are some nuances to that, in
 166

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 that Bitcoin derivatives can look very different

 than traditional derivatives. Some of them can

 look similar but a lot of the unique properties of

 our asset class, as I'll show you, can make the

 design much more important and also therefore the

 reporting that much more important, just to get

 the transparency around a lot of these things.

 I'm not going to go too much into Bitcoin,

 Blockchain and things of that -- there is a whole

 panel after this and we're kind of short on time,

 but there are a lot of unique asset classes that

 have caused us as a SEF and a DCO to have to

 design a lot of things from the ground up. One of

 the lessons we've learned and internalized is that

 even a lot of these minor details have dramatic

 implications for the contracts that we can

feasibly list or even think about designing

 without having to go through a lot of headaches

 and working through a lot of these data fields and

 the various SDRs that we have approached and are

 in the process of integrating with. Setting

 standards for existing instruments with multiyear
 167

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

or multi-decade histories is difficult as it is.

Our space, the instruments are much more different

in nature and that applies to data fields as well.

So one really good example that I use to

illustrate this internally is that even simple

constraints like the precision of the field that

we have to report and how many decibel places it

has to be can have many unintended consequences.

So this is very germane for our asset class

because it is sort of widely know that the total

supply in producible Bitcoin is about 21 million

dollars. What people don't often know is that an

individual Bitcoin can be divided evenly into one

hundred million parts. So you can have one

one-hundred millionth of a Bitcoin. So right off

the bat if we have certain precisions and

decibel-point requirements, we will be so far off,

order magnitude-wise, right from the values that

we're discussing today. So this is of course not

the case in U.S. dollars and kind of a whole lot

of other markets are used to enjoying, but it is

something that we have to think about a lot as it
 168

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

reflects on the Blockchain essentially. One other

 thing to note is that Bitcoin's precision is not

 fixed so the precision can be increased over time

 and I in fact we fully expect it to do so if the

 market cap continues to grow. So now all of a

 sudden we're talking about a moving target that we

 have to hit for a data standard that is very vital

 to our contract. Reporting infrastructure for us

 is interesting as we built our SEF and DCO from

 the ground up because it is not in isolation. It

 is not just a piece of software that talks to our

 SDR. It is a critical part of everything else we

 do, especially as we are a SEF and DCO combined.

 So there are a lot of things that are blocked if

 we cannot comply with the reporting standard. One

 example that our CTO has spent a lot of time 

 looking at is the Embargo Rule. So we are unable

 to broadcast trades and especially the prices and

 the formats associated with them to our clients

 until we have "transmitted" the data to the SDR.

 Now the problem is, transmission and transmittal

 has not been really well defined. So we don't
 169

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 know when we're building software from scratch, so

 we see at a very granular level, does it mean that

 a piece of line of code is before another, or does

 it mean that we create the right data structure

for the SDR, or is it after we make a best efforts

 approach to try to transmit that data over the

 public internet? So there are a lot of questions

 around that. And for our SEF -- this kind of goes 

 to the market structure -- we actually expect the

 vast majority of our volumes to be on the limit

 order book. And in fact, we expect a lot of

 automated traders to be providing liquidity. This

 is sort of the nature of the differences in

 marketplaces. A lot of the players in Bitcoin

 are, by nature, technical. It is a little hard to

 understand, and so they tend to be inclined toward

 that style of trading. So things like the Embargo

 Rule that can introduce hundreds of milliseconds

 that might not be relevant for SEFs that are doing

 transaction volumes in a very different market are

 extremely relevant to us and in fact will make us

 right off the bat very uncompetitive in a lot of
 170

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

ways that our customers have talked to us about.

 So there have been a few issues faced here that

 the asset class for the reporting standards are

 still in total flux and that filters down directly

 to us. My new details of the finalized

 regulations can have really material business

 implications for us as well and I'll add one final

 thing which I think is a subtle point. The

 benefits to kind of getting data standardization

 right are not just improving data usability and

 reducing the cost for SDR but it also impacts SEFs

 and ourselves that want to design very new and

 exotic looking products with very different terms

 because it makes it difficult. So more and more

 what we're finding here at LedgerX as we design a

 whole suite of derivatives that are based on this

 new asset class, is that more and more of our time

 is being spent on the SDR part. Now before

 starting LedgerX two years ago I never would have

 imagined that 30 to 50 percent of our engineering

 time would be involved in SDR integrations and

 trying to figure out how fields should work
 171

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

together. Especially as a DCO there are a lot

 interesting things for us. Our DCO has reporting

 requirements that are very different then our SDR.

 The DCO is not subject to the Embargo Rule so we

 have a little mismatch there. And then just the

 inconsistencies between the integrations with the

 STRs end up having to have what I would call short

 cuts that are not sustainable if the data

 standardization is done because they'll no longer

 be necessary essentially. So I think LedgerX has

 a fairly unique perspective having built our

 exchange infrastructure from scratch and working

 with many SDRs. I'd really like to make it

 cleaner sooner than later because a lot of these

 hacks are very time consuming to build into the

 system and will hopefully just be unnecessary one

 day. So if any SDR has sort of a question as to

 what we've kind of been working on and what we're

 spending time on, I'd love to hear from it as

 well.

MR. GRIFFIN: Thank you. We are cutting

 it awfully close, but Brad, please.
 172

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. LEVY: Yes I'll go really quickly.

 I just want to make a point that we use the word

 standard a lot here which is valid. A standard

 without adoption is not a standard so I actually

 think we should start calling things something

 different when they're actually not adopted

 because it can't be a standard unless it is

 adopted. But I think if you just page back one

 and I'm always trying to get to cause and effect

 in having been a part of a lot of the

 standardization and creation of these products

 myself -- it looks very correlated to where people

 care where there is PNL and where there is people

 physically doing the business. So the iTRAXX CDX

 world has much more option because there is a lot

 more people and there is more business to be done

 there in the last five years. If you look at EM

 it is a little bit off the radar but it kind of

 falls into that, and if you look at CMBX and IOS

 it falls off the cliff because that business has

been really struggling. So again it gets back to

 that point that you won't implement a standard
 173

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

without the implementation of a standard or you

won't get to a standard with the implementation.

And if you don't have the people and the will from

a commercial perspective to move to a new standard

or a standard then to me this data just says to me

there is probably not enough people or money to be

made in that business to put the effort in to get

that up from 12 percent or much higher if you look

at what is going on in say the commercial mortgage

industry. For me I would say the cause of that is

just the fact that people don't care about those

products as opposed to the standards not being

right.

MR. GRIFFIN: Thank you Brad. Let's see

if the Commissioners have any final comments or

questions. I'm afraid we will not get to our

fourth theme -- the reporting of notional amounts

-- but I would like to very much thank our

panelists both from the Commission and from the

SDRs on what has been a very, very robust

conversation here. I would like to request that

everyone please be back by 2:00. We want to make
 174

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10

 11

 12

 13

 14

 15

 16

 17

 18

 19

 20

 21

 22

 

 

 sure that we're able to start the final panel on

 time so that folks can make their planes and

 trains and so on and so forth. For those

 panelists and TAC members that will be joining us

 upstairs, please just congregate outside the front

 door here, thank you.

 (Whereupon, at 1:17 p.m., a

 luncheon recess was taken)
 175

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 

 AFTERNOON SESSION

 (2:02 pm)

MR. GRIFFIN: Thank you. For our final

panel, we will focus our discussion on Blockchain

and the development of distributed ledger

technology, with a particular focus on the

derivatives markets, how such emerging technology

may be applied to the derivatives markets, and

what the ramifications may be to such innovation,

be it to product development, market structure or

regulatory concerns. We are pleased to welcome as

panelists Sandra Ro from CME Group, Brad Levy from

MarkitSERV, Robert Sams from Clearmatics, and

James Slazas from ConsenSys. We have asked each

of the panelists to make a brief presentation

after which we are hoping to engage in a robust

discussion. Sandra, would you like to get us

started?

MS. RO: Hi. Thank you very much, Ward,

and thank you for having us here today. I'm going

to start off and just do a very quick primer, just

in case there are those who are not quite as
 176

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 familiar with what people bound around as

 Blockchain. I think it is one of the most

 overused words these days and I think it is pretty

 much in the press now everyday if not every other

 day. So, Blockchain itself. It is the

 distributed ledger and the supporting protocols

 underneath it, which constitutes the Blockchain.

 I think most people know the Blockchain is part of

 Bitcoin, and it being the public Blockchain. This

 technology I think has really captured people's

 imaginations and also financial services, because

 they hope and the view that it has the ability to

 offer and facilitate significant cost reduction,

 acceleration of processes including payments,

 settlements and clearing. I think there are views

 that this technology in its form could actually

 help to speed up many things that are going on in

 the financial world which are still very manual

 and considered slow. We'll debate that today. But

 in its truest sense -- the Blockchain -- how does

 it work? Let me just walk you through that very

 quickly. There is a block and there is a chain.
 177

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Every completed block is added to the Blockchain

 in a linear, chronological order. With every

 block -- and this is in particular referencing the

 Bitcoin Blockchain -- with a hash that is from the

 previous block. So all of these blocks are in

 order. So imagine it is like bank transactions

 that are cataloged, confirmed and then put into a

 block in order. And since the protocol -- the

 Bitcoin protocol, in particular -- was launched in

 2009, there is a record of every transaction that

 has ever existed. Now imagine that for any other

 asset class we talk about, it is pretty amazing

 actually. So the Blockchain itself is a string of

 these transactions strung together and confirmed

 in a Blockchain. So let's talk about some of the

 benefits. Some of the benefits that people talk

 about is the fact that you've got a distributed

 system, its interoperability, its global payment

 network especially with respect to Bitcoin, it's

 auditable, immutable, it's transparent and for the

 most part, it's open source. I'm not going to go

 through every single one of these columns, but
 178

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 basically what has evolved in the last couple of

 years is it started off with a public Blockchain

 of which Bitcoin is the most famous but there are

 others including Ethereum -- and James will be

 speaking particularly about Ethereum and smart

 contracts on Ethereum -- so I'll let him do that.

 There is also an evolution now that some purists

 disagree with, which is private Blockchains. So

 these are permissioned, trusted private

 Blockchains which take a different form and their

 consensus protocols are different. They may take

 lots of different elements. Often they may not be

 open source so they're proprietary. Financial

 services, I think, if you hear about all the

 consortium that are being formed, I think there is

 still a lot of debate as to whether it should be

 open source, it should be private proprietary, and

this evolution will play out in 2016. There is a

 lot of building going on, there is a lot of

 experimentation going on, and there are still

 question marks around which is the best model.

Today it is not clear. Risks to Blockchain
 179

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 adoption. If we're going to wear the cynical hat,

 I think there's some things we should consider.

 Industry today has spent a lot of money building

 infrastructure that works, is robust, is scalable

-- so I think there is a question to be asked --

 because I actually personally think there is a lot

 of great potential for this technology -- but the

 question is, so what? There are a lot of use

 cases out there that people apply to Blockchain

 and say this is going to change everything and

 this is going to make everything better. Well is

 it really? I think the so what factor is what we

 start asking this year. Not every use case makes

 sense. To me we've got to start parsing down what

 is actually possible with this technology and it's

 going to take a number of years. This is not

 about an overnight determination of which use

cases work or not and it is good that the world is

 looking at experimenting this year. I think 2016,

 2017, we will start figuring out what this is good

 for and what this is not good for. I think that's

 going to be just as critical. Technology issues,
 180

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 non- scalability, use cases not being relevant,

 security concerns, transaction anonymity versus

 privacy -- I think those are all concerns right

 now. Industry standards and harmonization -- that

 is another major issue because part of the beauty

 of this technology is the network effect. It is

 not like typical industry behavior which is I'm

 going to build something proprietary and hope

 everyone comes and buys it. This doesn't work

that way. If you're not in the network and you

 don't get enough people in the network, you won't

 derive the true benefits of this. And then

 obviously regulatory hurdles and making sure that

 the regulations and the legal framework work

 across global jurisdictions.

MR. LEVY: Thanks and I'll give a brief

 presentation as well -- just a couple of pages.

 I'm going to try to move it along quickly to

 ensure that we have other time for both the

 panelists and the discussion. So I'm going to

 start off with a bit about what's important as far

 as we see it -- the key components, implications
 181

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 for derivatives which is obviously why we're here,

 and then a bit on path to adoption, some similar

 points to Sandra but some different. So this is

 generic and the next page I'll try to bring it

 down a little bit to something more specific to

 the industry. We use the word natively here very

 specifically because assets that start out as

 digital are different and can more easily be

 digitized up stream and down stream and can be

 transported. Ultimately on the next page you'll

 see that's not the way our world will necessarily

 work where things will start out as a natively

 digital asset on a chain represented as a block.

 But just the idea that native digital assets could

 exist and that just questions things being issued

 for example initially on the chain and then

 starting from there. Then you get into the idea

 of smart contracts, which the chain exists and the

 smartness really allows actions to be taken on the

 chain and that is something that is a bit newer,

 as part of Ethereum -- again, you'll see some of

 that today -- and is definitely a step up from
 182

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 where the Bitcoin Blockchain network exists. And

 then ultimately getting down to bigger shared

 repositories and this is not centralized data as

 much as data that is accessible by all that need

 to access it at the moment they need it. So it is

 a little complicated to talk about something that

 is shared but not centralized but that is really

 the point. These are the key components that we

 see. We do think that if things are issued on the

 chain it will be easier. If they're not and there

 is this idea that you have to take it from its

 former form into a digitized form, there is just a

 bit of a hurdle there. And then there's also

scenarios as the industry ramps on certain use

 cases that things may be able to start out on the

 block but due to some limitations and

 functionality, et cetera, maybe they need to be

 off ramped depending on where the industry is in

 terms of the evolution. So that's the more

 general view and just to take it down more

 specifically to the industry. So what we're

 trying to figure out is a lot of what we discussed
 183

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 today, which is the why, and then get into the

 what, but we do believe that Blockchain technology

 generally can immediately reduce some operational

 risks and costs, begin then to get into some

 balance sheet and then ultimately maybe even

 market risk and liquidity. But just to take these

 in order -- if you think about digitizing an

 asset, which we spent probably the better part of

 15 or 20 years as an industry doing things like

 that, like putting swaps in a database and

 transporting that information on an API using

 FPML, that has been a long process. But clearly

 the process of doing that has enabled a lot of

 operational efficiency, and then the question is

 can Blockchain take it even up a level further by

 creating less centralized infrastructure that

 everybody has to maintain or integrate with and

 somehow be able to get people the information they

 need at the time they need it. This really

 combines the idea that there's a digital asset

 with the idea of a smart contract that you can

 manage events around it. Then you get into the
 184

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

second area which starts to get into things like

balance sheet and collateral management now.

These may ultimately have the impact of increasing

liquidity, et cetera, but we think that there are

scenarios and value to getting to a point where

things like collateral can be managed more

effectively and balance sheets can be managed more

effectively without necessarily changing what

liquidity looks like but creating a lot of value

beyond operational risk reduction or operational

cost reduction. And then in the long road, we

used the word securitization where these assets,

if they live in this form just like they used to

in paper, and you can wrap them together and

create something where they all exist within it,

there is this idea of bundling these and

ultimately using this as a tool to get to higher

liquidity -- or transparency, liquidity, less

friction in the market -- we believe from a market

perspective that that is possible. We also

believe that there is somewhat of a natural order

to going after these three elements. Operational
 185

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

risk, balance sheet risk and market risk -- and

the word risk here I'm using more liberally, it's

not just necessarily about risks but cost as well

or just efficiency outright. So we do see the

spectrum of operational reduction, balance sheet

reduction and then hopefully that will have the

result in the long run of increasing liquidity in

the markets overall. And we think it's possible,

but again, the right order is critical, but we do

think each step provides some value. But at the

same time to Sandra's point on timing, we can't

rush to the end game. There is no big game

changer ecosystem that's been built overnight on

one technology. The analogy I like to use is,

iPhone would be irrelevant without the internet.

Apple didn't invent the internet but they

certainly have stitched it together and taken

advantage of building out the ecosystem, and we

think Blockchain will evolve in a similar way and

a similar timeframe -- i.e., many years not months

-- but we do think we'll see gains in the short

run. The path to adoption -- and again some of
 186

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 the same points that Sandra made -- network costs

-- just because Blockchain exists doesn't mean it

is better or will be less costly and there is

 always the conundrum of wanting to move to a

 better place or a new place but having to invest

 to get there and we don't think Blockchain is any

 different. It is not a silver bullet. We think

 it is real and valuable, but the questions are how

 do we get there without blowing up the costs or

 knowing that we're eventually going to get to a

 lower cost? One thing that has been talked about

 a bit in the markets and even here with Sandra's

 introduction -- this idea of trust. The Bitcoin

 network is based on the fact that everybody wants

 to remain anonymous forever and never know who

 anybody is other than they performed a function

 that the platform network agrees with. We don't

 think that that's necessarily the model that our

 industry will adopt. Identity will be key. We do

 think that the idea of private networks that are

 gated where you don't necessarily know who

 everybody in it is but they're all validated and
 187

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 should be in that network. There is a big KYC

 element that is part of this discussion as well

that could either be injected into the Blockchain

 workflow or Blockchain can actually aid in KYC

 itself. And then the last area -- regulation and

 compliance -- this is one where we do think that

 the regulators need to be a bit careful not to go

 too far in saying this can solve all of our

 problems but also not throttle the innovation, and

 really look at more objectives as I guess

 prescriptive, and that certainly seems to be the

 mode here for the most part and we think that

 suits Blockchain well. The fact that the TAC is

 having this panel and is considering a broader

 discussion around this over time is great and then

 some of the regulators including the CFTC and in

 Europe are really engaged and really helping lead

 the way as opposed to react or just be a part of

 the industry. At the bottom there's just a few

 things that we cite as areas that we're focused on

 when we say smart derivatives - contracts -- it is

 a bit more focused on credit for us specifically.
 188

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 We're doing some work in the syndicated loan

 space. And then there is a few other things

 there, including what we're thinking about in KYC

 in terms of real use cases. We're still a bit in

 a put it up on the wall and see what sticks.

 We're not doing that in a vacuum -- we're doing

 that in partnership with many in the industry,

 whether it is providers like ourselves, Blockchain

 providers specifically, or the end users as well.

 The one point I'll leave you with on this deck, is

 there is no way to make progress in Blockchain

 without industry collaboration. I think again

 this is a forum that just oozes that. Even if you

 think about the words that are used in this space

-- shared, peer to peer, distributed -- it all

 assumes some level of collaboration. And then we

 actually think open source is going to have a very

 big role in this space, probably more so then any

 other initiative in our industry, maybe ever. And

 there is already some initiatives going on there

 that we're pretty excited about, and we think the

idea of open source plus proprietary -- or open
 189

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 source used more proprietarily -- will be the

 right model, and there's things like the Linux

 Foundation and others that are starting to spin up

 real efforts there. It's not a normal, natural

 state for our industry to get together and think

 about contributing code. If you think about our

 first panel on AT, that was the opposite of that

 discussion for good reason, but this is one where

 we're going to have to take a bit of a leap that

 some of this stuff just needs to exist in the

 public domain, and we all just need to compete

 beyond that. And I'll leave it to Robert now to

 continue.

 MR. SAMS: Thank you Brad. I'd like to

 talk about a few things. One, just to cover some

 issues of terminology, because I think it confuses

 a lot of people because it is new. Then I want to

 skip to just some general observations about the

 technology. And then conclude with some

 discussion about how the technology may be applied

 to the OTC derivatives market and some of the

 policy implications that there could be. About
 190

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 the terminology I mean it is popular today to

 speak of Blockchain technology in the context of

 financial markets and in particular its

 applicability to post-trade. This is often

 qualified as permissioned Blockchain technology,

 to make clear that the consensus model is based on

 authenticated and legally accountable validating

 nodes, and to distinguish it from Blockchains like

 Bitcoin or Ethereum which are based on models of

 permissionless consensus. Today I'll instead use

the phrase distributed ledger technology -- or DLT

-- in place of permissioned Blockchain. It's not

 that there's anything wrong with the phrase

 permissioned Blockchain -- it's just that neither

 the property of collating transactions into

 blocks, nor the property of chaining those blocks

 together via cryptographic hash, are essential to

 creating an immutable and distributed ledger, so

 the terminology is a little bit question begging

 about the implementation details. I also think it

 helps to demystify the technology by making it

 clear that what we're really doing is finding
 191

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 powerful new applications by combining

 technologies that are actually well established

 and well understood -- namely, public key

 signature, cryptographic hash functions,

 virtualization, distributed consensus algorithms,

 and peer to peer networking protocols. Now DLT is

 a network where every node on the network has a

 local copy of the global state of the ledger. And

 a consensus algorithm ensures that each node's

 local copy is the same as every other node's local

 copy, which is why we can refer to the collection

 of separate ledgers as a single shared ledger.

 Today every financial institution maintains its

 own system of ledgers, so in today's financial

system it is also fair to say that ledgers of

 ownership and obligations are already distributed.

 But in today's system, consensus on the global

 state of who owes what or who owes what to whom is

 obtained by many iterations of reconciliation,

 which is usually labor intensive, expensive and

 slow. So distributed ledger technology works

 differently. The way it works is we can think of
 192

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 it in two steps. Each node on the network first

 takes a set of settlement instructions, applies

 them to the current state of the ledger, and

 returns a new ledger state. And then secondly,

 each of the nodes on that ledger follow a

 consensus algorithm and come to an agreement with

 each other on the new state of the ledgers that

 each of them computed independently. Now there

 has been a lot of discussion about how this second

 aspect of distributed ledger technology can

 improve post-trade. If you replace reconciliation

 with a consensus algorithm, you can obtain

 substantial operational efficiencies through

 automation while reducing the time interval

 between trade and settlement, which releases

 capital and reduces counterparty risk. However,

 this narrative -- which has been described many

 times -- this narrative about the benefits of

 replacing reconciliation with consensus algorithm

 is silent on the first aspect of distributed

 ledger technology, which raises an important

 question. At what point in the post- trade life
 193

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 cycle is an instruction generated and passed to

 distributed ledger technology. The post- trade

 life cycle is complicated. It varies from market

 to market and there are many processes in between

 the contractual event represented by a trade

 confirmation and the proprietary event of a

 trade's settlement. If distributed ledger

 technology comes only at the end of the life

 cycle, then some other technology or technologies

 are automating the post-trade process up until

 that point. But given that the legal validity of

 a ledger entry makes reference to every step in

 the life cycle, distributed ledger technology

 could end up turning a distributed industry-wide

 golden record into an intermediated technology

 service even if distributed ledger technology is

 itself a technology commons. This could have the

 rather paradoxical consequence of actually

 concentrating rather than decentralizing

 post-trade intermediation. On the other hand, if

 DLT is introduced at the beginning and encompasses

 the entire post-trade life cycle, then there is a
 194

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 very different implication. Post-trade automation

 can be achieved through what we describe as

 decentralized clearing networks, or DCNs. DCNs

 are light weight consortium entities whose members

 are the nodes on the network and consist of the

 main participants in the market that the DCN

 clears. In principle this model can eliminate

third party intermediation entirely, replacing it

 with a platform model, one that enables third

 party service provision but the platform itself is

 governed by DCN members rather than a third party

 intermediary. The market therefore owns the

 plumbing. Some DLT architectures like those

 derived from the Ethereum code base lend

 themselves to this second scenario because they

 are based on a model where the ledger state

 transition is general purpose computation and are

 therefore capable of expressing the complex

 business logic involved in processing the post- 

 trade life cycle. These architectures I'll

 describe as programmable distributed ledgers, or

 PDLs. Other architectures, like those adapting
 195

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 Bitcoin's UTXO model, are much more likely to fit

 into the first scenario for the simple reason that

 these architectures cannot by themselves implement

 the complexities of post-trade processes in their

 model of limited purpose ledger state transition.

 Moving on to the OTC derivatives market and some

 of the implications of some of these observations

 for that. I think one of the domains for the DCN

 model --

 Decentralized clearing network model --

 is most compelling is in the OTC derivatives

 market where we believe that programmable

 distributed ledgers are not only potentially

 transformative new infrastructure for the

 bilateral uncleared OTC market but also perhaps an

 alternative to central counterparties themselves

 or CCPs. One of the most interesting aspects of

 PDLs is that it challenges our background

 assumptions about what functions can only be

 performed through centralized intermediation.

 Consider the following functions performed by a

 CCP. Performing contract valuation, settling
 196

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 variation margin payments, calculating initial

 margin, custody of initial margin and other loss

 absorbing capital, novation and netting, and

 managing closeout on counterparty default.

 Clearmatics is currently working on proving how

 all of these functions can be performed on a DCN

 that is by a membership governed network instead

 of a CCP. At their core, derivatives contracts

 are legal agreements with fully computable terms.

 They are quite literally algorithms described in

 the legalese of IMAs, CSAs, and contract

 specifications. Ignoring for the moment the role

 that CCPs play in assuming the performance of a

 derivatives contract to both sides of a trade,

 what CCPs in affect do is standardize and automate

 the aforementioned clearing function by

 centralizing the computations in the CCPs

 technology silo. The solution is sensible when

 the alternative is that the counterparts to a

 trade perform the computations independently.

 This is because until recently there has been no

 obvious means of definitively reconciling
 197

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 complicated computations performed independently

 by two or more parties. Valuation disputes in the

 bilateral market are but one example of this

 difficulty. But we now have a model for

 performing computations collectively and come into

 consensus on the correct results. With a

 programmable distributed ledger there is not only

 a golden record of collateral and variation margin

 movements but also a golden record of all the

 computations involved in those movements.

 Everything is available on the ledger with machine

 readable auditability. We believe that one of the

 profound implications of this technology will be

 the transformation and revival of the OTC

 marketplace that are more transparent alternatives

 to markets with centralized post-trade

 intermediation. The function that a CCP performs

 that cannot be replaced by a DCN is that of

 guaranteeing both sides of a trade. It remains an

 unanswered question whether this impressive

 concentration of counter party risk at CCPs

 mitigates or amplifies systemic risks. But now
 198

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 that the technology is providing practical means

 of unbundling the many functions performed by a

 CCP, it is perhaps worth revisiting the question.

 Another potential risk factor that the OTC

 derivatives market is the legal nature of the

 contractual agreements themselves, which are

 agreements that provide legal recourse against the

 defaulting counterpart's balance sheet. This is

 arguably a statutory innovation by the Commodity

 Futures Modernization Act of 2000, which does run

 contrary to a long standing Anglo Saxon common law

 principle that contracts for difference are not

 enforceable in a court of law. Therefore another

 question that we believe is worth exploring is

 whether there should be an alternative legal

 wrapper around DCN's computational contracts where

 it is not based on ISDA documentation at all.

 Instead it could be based on documentation that

 binds the counterparts of the trade to the output

 of the program implanting the derivatives deal on

 the DCN's programmable distributed ledger with

 recourses against defaulting counterpart limited
 199

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 only to the collateral posted. In the long tail

 scenario, where loss absorbent capital is

 exhausted, it amounts to variation margin hair

 cutting. Such a scheme in many ways resembles the

 membership model of a 19th century exchange. We

 at Clearmatics are committed to developing

 programmable distributed ledger solutions that

 decentralize financial intermediation and would

 welcome the opportunity to open a dialogue with

 regulators to explore how this might be

 accomplished and in particular we would very much

 like to explore how Title 7 of Dodd-Frank might

 accommodate a DCN model of clearing, thank you.

 MR. SLAZAS: Hi, thank you and thank you

 to the committee to be able to present a

 Blockchain solution and application. I'm just

 going to go fairly quickly through it and it is

 really basically going from where we had been

 discussing a little bit of Bitcoin to the Ethereum

 Blockchain. There's several different Blockchains

 out there. The Ethereum Blockchain basically

allows that transfer of value that Bitcoin does as
 200

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 well as programming applications within the

 Blockchain. There are a few different parts I 

 just want to highlight. We're going to talk about

 a couple of different core components that can be

 built upon each other and basically construct all

 different types of solutions for financial

 institutions. So some highlights that will come

 out will be having identity, reputation and

 persona; the idea of oracles giving pricing and

 reputation feeds within the Blockchain; an ability

 to be able to have a transparency -- or basically

 an accounting system where you could have triple

 entry accounting; as well as the ability to use

 smart contracts throughout the whole process of

 different applications. So to set up what is on

 the screen, it is basically two counterparties

 have discussed to enter into a transaction. They

 have agreed to all the different terms, collateral

 requirements and things of that nature. So this

 could just be in the form of a bank talking to a

 hedge fund. So the first thing is the trader is

 going to enter in their password into their wallet
 201

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

which is going to hold all of these different

types of public and private keys and different

attributes. What I mean by that is, again,

Bitcoin holds just a value where in a wallet such

as on the Ethereum Blockchain it has different

attributes. So it might be, has the individual or

counterparty been KYC verified, what type of

trading entity are they, and things of that

nature. So as a trader, basically just logging in

the Blockchain is basically as you can see from

the public address that this counterparty is on

the Blockchain, so it is part of that identity

system. Given that it is a bank, it has been KYC

verified, of course. One of the first parts for

looking at the smart contracts would be this

counterparty has been given a designation of SD,

or swap dealer. These are all different parts

where an attribute not just that value, can be put

into smart contracts. So this is a way to help

maybe facilitate some of that data gathering that

you're going through for the swap data

repositories and things like that. The other
 202

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 value that we have here is a little bit more after

 an ecosystem has been built, it is basically a

 reputation value. So it could be looked at as a

 scoring that a bank might use for calculating the

 credit risk and then being able to apply

 collateral requirements for counterparties. So as

 I said this is just the trader entering in the

 swap details. First, the counterparty on the

 phone had given a public address which is what

 I've entered in here, and we're first just seeing

 has this counterparty been verified, as well as

 what type of standing or what kind of entity are

 they. And so as you see here, one, they are in

 the system, so we know that they are a valid

 counter party. FEU's basically stands for

 Financial End User, or the type of counterparty.

 It could have been a swap dealer or hedging

 organization or some other type of counterparty.

 Again we have this reputation score. Now I'm

 going to enter in a couple of quick terms so we're

 going to make it a 10 million dollar total return

 swap, we're just going to make it last for 4
 203

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

minutes, it will be long Microsoft, short gold.

And what we would do here is basically again you

can utilize smart contracts to be able to see if

the trader was able to trade in these types of

assets. This could also be earmarked within the

system given that there is different requirements

for the different types of asset classes and

sensitivity. This again can be incorporated

within the tracking of the system. Down here at

the bottom we have different areas where a smart

contract could be created where the swap

documentation may say it has different types of

terms -- you know, trading days, how it can be

terminated. What we've chosen to highlight is

just an example where if there is a downgrade in

the reputation of the counterparty then there is

going to be additional collateral required. The

one part I do want to highlight here is this 

notion of basically an asset trading account.

We're all familiar with collateral as encumbered

escrow type of collateralized account. Here it is

just a freely traded account and what we're going
 204

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 to do is we're going to utilize that account to be

 pushed and pulled collateral as the market

 changes. That would be based off of the pricing

 of the securities or in this case the reputation

 of the counterparty as well. So all I'm doing is

 just publishing those terms to the Blockchain and

 so we can just see that we have a 10 million

 dollar total return swap. We see that the

 collateral has not been funded yet. We also see

 that each counterparty has a trading account of

two and a half million dollars and three million

 dollars. And what we're going to do is we're just

 going to go through the typical process for

 executing a swap transaction. All of this is

 obviously just a POC so it's not built out to have

 multiple transactions or multiple collaterals, but

 again it is just to be able to show you a little

 bit of what can be done with the Blockchain. So,

 in the first part is that, as the trader, we need

 to fund the account. So we're going to encumber

 basically collateral. So the trading account --

 again, that could be the credit risk allocated to
 205

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 a specific trader, it could be utilized from a

 bank to push or enhance traders to want to trade

 on one end of the curve versus another. Here what

 we've just done is we've funded the collateral

 account. Obviously there is a tremendous amount

 of documentation. I'm not sure if we'll be able

to add this in here. But basically the Blockchain

 is not very efficient in holding large amounts of

 data so when we have standardized type of

 documentation like the ISDA or CSA, what we

 typically do is we'll use something called IPFS,

 or Interplanetary File System. You can look at it

 similar to your Dropbox, except that you can't

 change the name or any of the documentation. And 

 this long string of numbers and letters here is

 basically a hash that is put onto the Blockchain

 so that again there is no way to be able to change

 documentation that is associated with a specific

 transaction. Finally we're going to sign the

 agreement. Again this is all within one interface

-- this could be going to the credit department,

 could be legal reviews it prior -- and this is
 206

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

just again all of this is being put on top of the

Blockchain. So you have this transparency and

immutability. So there isn't a way to be able to

change any of the terms that go in here.

Obviously things can be revised but there's always

going to be a log of being able to see what has

been put on the Blockchain. From a regulatory

standpoint of course this gives a very easy to be

able to create a dashboard that gives complete

transparency of all the different types of

transactions -- swaps -- that are being entered

into, what kinds of collateral is being associated

with it. Different items that need to be

analyzed. So again now for demo purposes this is

just going to the other counter party. They're

going to see the same type of terms and reply

going through the same process -- funding the

account, reviewing the documentation, and then

entering into the transaction. Now that that's

gone through, we have this notion of triple entry

accounting, and basically what this is it's a

confirmation on the Blockchain -- a confirmation
 207

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 goes to each counterparty and then a confirmation

 on the Blockchain that can be referenced

 indefinitely. This can help again from a

 transparency standpoint and from an auditing and

 regulatory standpoint. So what we have here now

 is the transaction is ongoing. Up top you just

 have the prices and here that's what I meant by

 the oracle. You're going to have organizations --

 they may either be centralized similar to the

 Bloombergs and Reuters of the world, or it might

 be a much more decentralized fashion. These are

 just utilized for obviously being able to price

 the assets. If there is a way that you have some

 type of listed or some type of way of being able

to give a pricing on the underlying, then we're

 able to track what is the value of this swap

 transaction. So as you'll notice, every few

 seconds you'll see a black logo that pops up and

that's basically a rebalancing. So every time

 that the prices are moving we're having a pull or

 push from the trading account into the escrowed

 collateral account, both of these standing on the
 208

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 Blockchain. This becomes very powerful.

 Obviously from a tracking in a back office

 scenario, this is automatically happening and if

 you can just imagine having the initial and then

 maintenance level margins, now you can have a

 level that is basically rebalanced in real time.

 There isn't the delay of having someone call and

 say you need to deliver assets because your

 account is down. It also becomes a very -- much

 more -- efficient use of capital. Less capital is

 having to be tied up in a collateral account, as

 well as from a financial institutions risk

 standpoint it also reduces their risk. They're

 able to basically grab collateral as soon as

 needed given market fluctuations. We have here

 one of the smart contracts has been initiated

 where there was a down grade in my counterparty.

 So it went from 79 down to 74, and so immediately

 there was a pull of additional collateral from the

 trading account into that collateralized account,

 shoring up, given a change in a counterparty's

 creditworthiness. Again, given that it is a
 209

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 freely traded account, yes, it could be depleted

 or moved after the trade is initiated and again

 all that means is then we're back to where we are 

 today of people having to be on the phone saying

 you need to deliver collateral. You can easily

 put smart contracts in there to encourage

 counterparties to keep collateral or keep funds in

 there just because you would say well we'll give

 you a reduced rate if you have additional funds in

 your trading account. This is just as quick as I

 could go through of what the transaction is. What

 we've looked at are basically just what is

 identity, how you could use the reputation using

 the Blockchain from the transparency side of

 things, and the ability and really a way for

 regulators and financial institutions to be able

 to track what these transactions are utilizing the

 Blockchain. Thank you.

MR. GRIFFIN: That's great. Thank you.

 Why don't we open it up to the committee if anyone

 has questions they'd like to lob? Thoughts?

 MS. VEDBRAT: This is Sapurna. I have a
 210

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 question on this last section of the collateral

 management piece. What do you think would be the

 main concerns from an industry standpoint of

 moving to a much more efficient way of managing or

 moving collateral?

 MR. SLAZAS: I would say that I think

 the -- probably one of the most important issues

 to be able to address would be the digitization of

 the assets. We are obviously going through an

 inflection point right now where we have this

 legacy world and we have the potential use of the

 Blockchain. So there is definitely going to be a

 need for being able to digitize legacy assets so

 that they can come on and off the Blockchain

 easily. If not there would be some type of

 arbitrage opportunity to be able to -- or a

 limitation of what an asset's value would be if we

 could not have it go back and forth easily. And

 from that standpoint I think that utilizing

 something -- having that kind of functionality

 would enable a tremendous amount of basically cost

 savings and risk reduction by being able to have
 211

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 that movement.

 MS. RO: From a technology standpoint

 that's absolutely correct but I think one of the

 big hurdles that we need to figure out how to

 marry is the fact that if you tokenize collateral,

 what happens in the event of a default or a

 bankruptcy? What regimes would cover these

 tokenized assets and if they're in transit from

 one jurisdiction to another, do these tokenized

 assets become recognized under law? There is a

 lot of, I think, advances happening on the

 technology side which is natural, being way ahead

of legal and regulatory framework. So agree we

 definitely need to be looking at digitization of

 collateral and assets but we need to figure out

 also how we work with regulators and the legal

 framework to make sure that these things are

 recognized.

 MR. LEVY: Yes, just to add a little bit

 on that, that's a really important point and when

 we look at the timeframe for this to really get

 adoption across the board the technical side is a
 212

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 hurdle but it is probably the least meaningful

 hurdle. The legal framework has to be understood

 and then around that the regulations need to

 happen so there are definitely -- I don't think

 they're edge cases but there are cases that you

 have to figure out because a lot of what we talk

 about is solving for those default events, et

 cetera, as opposed to when things are happening in

 the normal course. In the normal course obviously

 these things don't matter as much but everybody is

 going to do that what if analysis. I'll introduce

-- I know we've talked pretty technically at times

 today across the board here, but I think what was

 said is that idea of the digitization of the asset

 is critical as early in the process as you can.

 To the extent that it's not, you make it digital

 or need to off ramp it, that is really important.

 But there is this idea that there are apps that

 are basically written above the Blockchain that

 have the smartness of the contract in it where

events can either be prewired in or can be more

 easily instructed when necessary, and to Supruna's
 213

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 question, there is quite a bit of efficiency from

 the idea of these smart contracts -- not just the

 Blockchain -- but the idea that you can deliver

 these fairly small apps that sit in and around

 those chains to really drive the events. Those

 are things that will take time; we'll probably

 have to go after them bit by bit or several by

 several. That is not unique to how Blockchain

 technology is developing in our space or being

 talked about -- the idea of micro services, API's

 that interact with each other and more modular

 apps that leverage all of this is the way that

 technology is just being delivered and Blockchain

 is just another version of that. Where -- and

 again to the point -- you don't want to overload

 the network with a lot of data that's not

 necessary and have to ship that around all over

 the place because one of the issues with the

 Bitcoin network itself is its scalability and one

 of the things that we have to solve for is making

 sure that things can happen fast and for things to

 happen fast obviously the technology itself needs
 214

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 to carry the load -- it should carry and the core

 Blockchain technology as stated and we understand

 this is not really fit for that. So the question

 is how many events and technology do you weave

 around that versus putting on the chain directly

 and that will be a big part of the technical

 debate as well as the legal regulatory because

 these things have to manifest somewhere to give

 people comfort that it is being done properly in

 any event including defaults.

 MR. GRIFFIN: Cliff and then Steve.

 MR. LEWIS: Just a couple of points. I

 was wondering if this would be a sensible session

 or not because the talk to ticket ratio as they

 said on the floor was very high on Bitcoin and

 distributed ledger stuff and this was very, very

 impressive thinking. But just to come back to a

 couple of points -- and I think it's particularly

 related to what Brad was just talking to and how

 important it is and how heartening that the

 Commission is interested in this. Because the

 impediments to -- I think it is a mistake to start
 215

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

focusing too narrowly on the technology or even on

proof of concepts which you can dummy up pretty

quickly. The question is to sort of go back to

what's within the Commission's gift and begin to

identify and sort of using this as a metaphor --

really, it's the distributive ledger, it's that

concept of a different model than the existing

clearing model which is really what this is about.

And of course because of regulatory changes some

of which you guys have fought the good fight on

and had, as President Carter said, an incomplete

success on, the industry is faced with a huge

challenge in terms of the cost of clearing. And

in particular the cost of clearing that's imposed

on end users -- so the most innocent participants

in the market are the ones that are facing the

biggest challenge. And as you listen to the

description of the Blockchain model, I think it

becomes pretty obvious immediately where there

would be serious cost savings to the extent that

that clearing model has to change to be more of a

direct clearing model. Rather than having
 216

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 intermediaries who because of capital costs are

going to be ill-suited to provide efficient

 services, how do you begin to facilitate an

 alternate model? I think what's been just

 described here as you go back to basically things

that as you can tell the clearinghouses are

 already thinking about, you have some avenues that

 the Commission could be thinking about proactively

-- and I gather you're doing that -- whereby

 relatively small adjustments to some of the

 regulatory requirements, it may be possible to

 facilitate new mechanics for the system -- in

 particular the mechanics of pays and collects, the

 mechanics of the way collateral gets moved -- that

 may make it easier to go to a more direct clearing

 model, which pretty clearly is going to be the

 future because the cost of paying the balance

 sheet charges for, in effect, better credits than

 the banks to access risk management tools, is

 probably unsustainable in the long term. So this

 again I think is a terrific way not only from a

 technology standpoint but really in the classic
 217

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 Christensen sense of a really disruptive

 technology, technology in the sense of business

 solution for the biggest challenge that I think

 the industry is going to have which is how do you

 continue to use things like futures even though it

 is going to get a lot more expensive as all of

 these new changes come on stream.

 MR. JOACHIM: I think some of my

 questions are kind of in line with what Cliff is

 talking about but maybe a little bit more

 practical. I'd be curious to hear from you if you

 thought through the implementation issues of doing

 something like this. It sounds to me like when I

 listen to the description of what you're talking

 about it's a zero sum game. Either everybody's on

 the network or everybody is off the environment.

 What happens if you're in an environment where

 some counterparties are on and some counter

 parties are off -- how do you kept those

 environments in sync? How do you really create an

 orderly transition to a disruptive technology like

 this in a way that the risks of that transition
 218

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 don't overwhelm the benefits that you might

 achieve in the long term, so pay a high rent or a

 high risk for many years while you do that

 transition while 10 years down the road you might

 get some value out of it?

 MR. SLAZAS: I would say not that it's a

 zero sum game -- there's definitely much more

 efficiencies that are gained as the ecosystem gets

 fully built out -- but when we talk about smart

 contracts, and those are part of the Blockchain,

 there is a little bit of an incongruence I think.

 You can just imagine there are efficiencies

 internally that an institution could gain without

 incorporating with other banks at all, and at

 ConsenSys we work with a lot of different

 financial institutions from an internal

 standpoint, a consortium and public viewpoint.

 And so what I would say is it's probably more of a

-- institutions are going through their learning

 phase and their experimental phase right now and

 so they can gain, definitely, abilities within

 their institution. I think by having the dialogue
 219

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 open with several, that we can incorporate a lot

 of different types of efficiencies. I think we

 spoke about KYC for a single institution -- that

 might not garner as much benefits as if there was

 a consortium of different intuitions. In the

 example that I was going over, that could just be

a way for one institution to interact with other

 counter parties of their own -- so, disregard

 maybe that reputation side, because the credit

 department has already gone through that -- but

 could transact with each one of those

 counterparties from an efficiency standpoint.

 They may say, again, it may be run by the dollars

 and said we'll offer out the same swap five, ten

 basis points cheaper because if you're going to

 utilize this system. Or some institutions may say

 you have to do this if you're going to transact

 with me. So I think it's going to be a growing 

 process. I don't think we're going to have a date

 that going to just say we're just turning on

 everything and now we're all a part of the system.

 But it will be, what I envision, a multitude of
 220

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 many different types of Blockchains, private,

 consortium, one to one, and public.

 MR. SAMS: If I could respond to that as

 well, Steve. Yeah, I mean you don't trade with

 yourself you trade with counterparts and that

 naturally means that there is a network effect and

 you're right, the value of a decentralized

 clearing network is proportional to the amount of

 usage. But that's not really any different from a

 clearing house or a CCP. And the level of

 complexity that's involved in setting up something

 like this is pretty similar to the level of

 complexity in setting up a clearinghouse or a CCP

-- you need to have a critical mass of usage for

 it to be worthwhile. Two things I want to say.

 One is that this technology is about -- the

 implementation of it is going to be incremental.

 We're not talking about everybody getting on a

single network. There will be a myriad of

 networks and it will be important that the

 industry encourages interoperability between them

 in order to gain the benefits. But it's quite
 221

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 possible to take some markets that have a

 relatively small number of participants and

 implement this technology live first and gradually

 move to larger and larger markets. But there are

 also quite powerful reasons why the industry would

 want to put the effort into going down a route

 like this. These are largely because of the

 networked nature of post- trade and clearing, if

 you take a particular derivatives contract, for

 example, there is a natural monopoly in clearing

 something like that and the natural monopoly is

 carved along the domains of whatever the netting

 set is and the risk modeling. And obviously if

 you have an intermediary in the middle a natural

 monopoly plus an intermediary is problematic for

 the industry. There are competition concerns and

 to have an alternative of being able to perform

 the functions of a clearinghouse without having to

 concentrate that natural monopoly in a commercial

 entity is a pretty powerful incentive for putting

 in the effort to try to do this.

 MR. GRIFFIN: First we'll go to Marisol,
 222

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 Evelyn and then Larry.

 MS. COLLAZO: Thanks. So there was

 certainly interesting points raised. I just

 mentioned that from the DTCC perspective we're

 certainly looking at this Blockchain technology as

 well and we actually recently issued a white paper

 around what perspective we take on this and

 certainly from a financial transactions

 perspective, what and how Blockchain can be used.

 Very much the discussion around disruptive

 technology, we tend to think it's more of an

 emerging technology around how financial

 transactions can be processed. As I think was

 already mentioned, lots of focus on technology but

 there are common themes here that we need to be

 cautious as we proceed, which is, you still have

 need for standards because of this network effect.

 You need to ensure that -- looking at the demo --

 that the smart contract and the terms of the

 contract are agreed by the community. You also

 need to have governance around those standards and

 around sort of that network effect. There are
 223

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

also other sort of considerations here that at the

heart of it, what is the problem that we're trying

to solve for with the use of the technology and so

in thinking about that, you have to break it down

into its parts -- we think, at least -- in terms

of are we solving for identity information, so

client onboarding, KYC, things of that sort. Our

thinking here is this is pretty sensitive nonpublic information and it is not the right place

to start just yet and there may be an opportunity,

but given this is what we see as the most highly

sensitive and most prone to cyber attacks, not the

best place to start. However there may be other

opportunities, such as master information around

securities as an example. There we do think that

that has an opportunity to look at a decentralized

processing. One of the key things I would caution

as the Commission is thinking about what role

Blockchain may play and certainly what would be

the regulatory lens which you want to apply on

this. It's thinking about where are the

opportunities in terms of what problem are we
 224

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 trying to solve for -- is it about getting closer

 to settlement? So we certainly know we have the

 goals of moving to T plus 2 settlement -- what are

 the enablers to doing those types of things, as

 another example? Collateral -- yes, another

 example. So there are areas where I think the use

 of this technology could serve to solve some

 problems and create some efficiencies, but we need

 to make sure that in thinking about kind of the

 full process and where we're looking to go, that

 we start with the question of what problem are we

solving for -- is it really yielding the

 efficiencies that the market needs; in some cases

 it may have already hit a level of maturity in

 terms of efficiency. Yet another case is the

opportunities may present itself so I do think it

 is much more nuanced in looking at the specifics

 of the problem that we're looking to address.

MS. FUHRER: Thank you. First of all

 I'd like to thank you all for the conversation

 around the Blockchain. I've been thinking about

 these issues for quite a while and was very much
 225

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 looking forward to this conversation and I do have

 a question that I kind of want to throw out to

 everybody for conversation. One of the things I

 can't stop thinking about is, is there any

 confluence between this morning's conversation and

 this conversation. And what I'm thinking about

 besides the use cases -- and I agree with

 everything that Marisol and the others have said

 -- implicit in my mind -- and I'm curious if

 people agree or disagree -- is that in order to

 effectively build distributed ledgers, implicitly

 we have a high degree of standardization in place,

 and not only a high degree of standardization, we

 have a high degree of commonality. Everybody on

 the network is seeing the same information. This

 transparency to all the node members. And when I

 think about -- coming from Promontory -- about the

 regulatory implication is, can we make that

 information available on a real time basis to the

 regulators without having to go through the

 permutations of different kinds of reporting and

 then the regulators could do with the information
 226

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 what they want to do with the information. So I

 have less of a commentary to make --

 I just wanted to share some of the

 things I've been grappling with and I'm curious as

 to what other members of the TAC and the

 Commission think on that.

 MR. LEVY: Yes just one specific point

 on that. We think about the regulators as a node

 as opposed to there are nodes and they're

 overseeing the nodes. They themselves become part

 of the network and have their own permissioning

 based on whatever rights they're supposed to have 

 as a regulator. In the normal market structure

 there is a market, there are participants, and the

 regulators regulate the participants and the

 market. That doesn't change, other than the fact

 that they're in the network this time more

 directly or that is physically possible. With

 encryption and keys and tokenization, you can give

 them access to the information they need when they

 want it, more on demand, and weave that into the

 whole concept of smart contracts and the chain
 227

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 itself. So it is different than the way a lot of

 think about regulators where they are outside of

 the network and looking at it from the top -- we

 think of them as a node, with just -- arguably,

 most of the time, will have super access, and that

 may scare a lot of people, but that is --

 (Interruption) --

 Well, I don't know your trading

 capabilities at the panel, but it's probably read

 only. But yes, you can go very far on that.

 There are even times when maybe regulators need to

 take actions in markets, which I think they've

 done from time to time, and maybe they go from a

 read only node to a I'm buying equities today

 node. Maybe that doesn't happen in this country

 as much, but it happens. So, we think of them

 differently than a typical regulatory framework,

 which is why we think the engagement directly from

 the regulators is different this time because they

 are actually a participant in the network in our

 view more than just a regulator of it.

 MS. FUHRER: Thank you.
 228

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. GRIFFIN: James, do you want to jump

 in?

 MR. SLAZAS: Sure, and yes, again, I

 agree with Brad and I don't want to go too

 technical. There's a fairly unique structure that

 we look at when we're applying these types of

 transactions where we see Blockchains where it

 would be one to one counterparty Blockchains with

 the regulator as a third node. So I know that

 we've only been talking about where it might be

 this multitude of different nodes, and everybody

 is on the system that does give transparency so

 people can all see what your trades are and my

 trades are. That is not as beneficial as

 potentially putting a Blockchain between you and I

 and then regulators have another node, but then

 again there is a consortium where all this

 information is then shared on a consortium

 Blockchain as well.

 

 

 MS. FUHRER: Right.

 MR. SLAZAS: Maybe a more technical

 conversation but absolutely -- the idea is it
 229

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

 feels like having a type of dashboard for

 addressing systemic risks and different types of

 issues that could come up -- it can get very --

 that's part of the infrastructure and the

 ecosystem.

MS. FUHRER: Thank you.

MS. RO: I mean I can attest from a CME

 Group perspective -- the few industry consortiums

 that we are a member of, there is very much the

 inclusion of regulatory bodies to be at least --

 in the very least, an observer status in the

 network or further to that, having additional

 powers inside of the network. But this

 consideration spans globally -- it's not just

 about US regulators but it would include obviously

 UK, Europe and Asia regulators as appropriate.

 

 

 

 MS. FUHRER: Thank you.

 MR. GRIFFIN: Larry?

 MR. TABB: My issues are, you know, how

 do you -- can you -- separate the settlement

 process from the transacting process or from the

 contract process? The issue I seem to have is
 230

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 when you start shortening the settlement cycle to

 such a short period of time, cash really doesn't

 become a significant issue because you have a

 balance of cash generally hanging around. But

 margin and securities -- they are rehypothecated,

 they're lent out, and how do you get them back,

 and how do you make sure you're not short? And

 even with cash, there is a lot of times, there are

 payments going out in the morning and the cash

 coming in in the afternoon, and how do you manage

 that float in between? And if all that stuff

 happens in real time or happens so close together

you wind up with all sorts of other problems, so

 if I'm a long-only --

 Getting into the securities side, not

 where you guys are -- but if I'm a long-only and

 settlement is like in three minutes or real time

 basically and I've lent my securities out, I've

 got to actually get them back before I actually

 trade which means that I've got to call all my

 borrows in and let everybody know who's borrowed

 my stock that I'm going to be selling it. I'm
 231

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 exposing the world to what I'm going to do

 beforehand, which is like not going to ever

 happen. There are some real challenges on the

 collateral side. Rich, I'm sure you understand

 that pretty well.

 MR. SAMS: Can I jump in on that? I

 mean I think you are absolutely right and there

 has been a lot of discussion around, well, the

 Blockchain can radically reduce settlement times.

 Some people say the trade is settlement, that

 trade and settlement become the same thing and

 most of these ideas are ill-considered because the

 difference between trade and settlement serves a

lot of different functions -- one of them is the

 liquidity in settling a trade. A trade is a

 contractual event settlement is when assets

 actually change hands. And one of the ways the

liquidity works in the market is having a buffer

 between the two where there is a netting process

 that takes place between the interval of trade and

 settlement. And if you have this real time gross

 settlement model in every market, you wouldn't
 232

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

have any netting and if you don't have any netting

you're basically in a situation where in order to

buy the asset you need to sell the asset first.

It is ridiculous. So netting serves a very, very

useful function in the market in terms of

liquidity. It serves a useful function in the

market in terms of reducing counterparty risk

because your settlement risk is based on a net

rather than a gross basis. So what I foresee is

that the trade settlement interval will shrink.

How much it shrinks will differ from market to

market. There won't be a standard distinction

between the two and the optimal interval between

trade and settlement for a particular market is

going to be a balancing of two offsetting factors.

The positive factor of reducing counterparty risk

and capital usage by reducing the window on the

one hand, and on the other hand, the reduction in

trade compression that happens when the settlement

window is very narrow and what that optimum is is

going to differ from market to market. So it will

shrink but it is certainly not going to go to
 233

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 zero.

 MR. GORELICK: Thank you and thanks for

your panel discussion. I found it very

 interesting and informative. My question for all

 of the panelists gets back to something that

 Sandra said at the beginning, which is the

 scalability concern. There have been some widely

 publicized scalability issues with the Bitcoin

 Blockchain that were going to be addressed in

 various ways. How do you see the technology

scaling to markets in which there are millions of

 transactions a day and the need to continually

 build that Blockchain indefinitely?

 MR. SLAZAS: Sure, and I can speak, I

 would say mainly to the Ethereum Blockchain as

 well as the consortium Blockchains that are run

 off of Ethereum. One is, the foundation itself

 has been working on the scaling issue where right

 now we have a proof of work similar to the Bitcoin

 Blockchain. There will also be a couple different

 technical sides of things but a proof of stake and

 a sharding of addresses to increase the
 234

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 scalability. The goal is for that to be released

 9 months to 18 months from now. From a consortium

 or private Blockchain, there the scalability issue

 really doesn't come into question. There you can

 have a scalability; we're working from more of a

 credit card processing and commercial banking

 aspect, where it is hundreds of thousands of

 transactions per minute type of thing. So it

 really would be dependent on what is the

 framework, what is the marketplace that we're

 looking at for that scalability issue.

 MR. SAMS: I think it is important to

 draw the distinction between these public

 Blockchains and this so called permissioned or

 governed Blockchains, because the reason why

 scalability is so hard in public Blockchains like

 Bitcoin and Ethereum is because you have to build

 them in such a way to mitigate against the risk of

 what's called a civil attack. Because anybody can

 be part of the validation set -- they're

 anonymous. So you have to raise the cost of

 participating in that network as a way of
 235

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 preventing a single party from taking a

 significant proportion of the consensus process

 over. In a permissioned Blockchain, you don't

 have to mitigate against that simple attack so

 already without some of the innovations that

 Ethereum is working on around sharding and some

 other techniques -- even without those innovations

 we can achieve some fairly high level of

 through-put and scalability with permissioned

 networks already. And it gets down to details

 about which consensus algorithm you use, what

 networking typology do you need, can the nodes be

 collocated in one geographical location or do they

 need to be geographically dispersed? But they are

 all imminently solvable problems in the

permissioned context.

 

 

 MR. GRIFFIN: Mr. Chairman.

 CHAIRMAN MASSAD: Thanks. Well let me

 thank you all for the presentations which have

 been very, very interesting. I want to follow up

 on a couple of comments that have been made --

 Marisol and others -- about what's the problem
 236

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 we're trying to solve, and Sandra I think kicked

 it off by sort of raising the so what question.

 There was an article I read and probably a lot of

 people in this room read a while back in The

Economist that talked about this and talked about

 the potential application of this technology and

 situations like the lack of a centralized land

 registry in a third world country. We're

 obviously in a very different place which is,

 we've got an industry that already has incredibly

 sophisticated technology, lots of digital records,

 and even to the settlement time, I think Larry

 properly pointed out that it may not be a

 technological barrier that's keeping, say,

 securities settlement at least at T+3 -- it may be

 market participant preferences for doing that. So

 Cliff raised the question on, well, maybe this is

 a path to a direct clearing model, which I think

 is an interesting idea and so let me ask you two

 questions. Because I think as a Commission, I

 think all of us -- I think I can speak for my

 fellow Commissioners -- in saying we want to make
 237

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

sure we're at least not standing in the way of new

technological developments and potentially

encouraging technological developments that can be

beneficial. So if we were to have this session

two years from now, what would you be pointing to

as the applications of this technology? What do

you think you would be pointing to as the things

we would then be talking about as the advances?

And maybe they wouldn't even be specifically in

derivatives -- maybe they'd have to do with KYC

issues or AML issues. But more specifically then,

what then -- in thinking about that and thinking

about where you see the development taking place

-- are there particular things we as a Commission

should be thinking about in terms of our own rule

set or in terms of what we do that can at least

ensure we're not standing in the way, and maybe

even we're encouraging things?

MR. SLAZAS: So what do I want in two

years?

CHAIRMAN MASSAD: Five, if you want --

if that's easier.
 238

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 MR. SLAZAS: I think, coming from the

 premise of, I look at a lot of the over the

 counter market as the area to first be addressed.

 And not that I'm glad the CME and everyone else is

 obviously working on this because it does make

 sense. But from the over the counter side of

 things, what I would envision is a dashboard for

 yourselves that you would be able to, if you had

 different parameters, from the earlier panels

 today, being able to have that access and that

 kind of data in any type of real time fashion,

 where not just that trade is the settlement type

 of conversation, but the transparency and the

 immutability of all those transactions I think is

 extremely cornerstone to this. We haven't really

 defined it too much, but even the security that

 the Blockchain does bring to the ecosystem,

obviously we would be talking about a lot of very

 sensitive data. I think that in just a few short

 years that we would be able to provide some type

 of mechanism where you have a window into that

 space and I think it can be done in parallel to
 239

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 what is being done currently off the Blockchain.

 And I think that that might just be another window

 for you to see where that market risk is. From a

 building out standpoint, I know that many of the

 financial institutions are looking at how do I

 address this KYC issue, how do I address my

 collateral and different issues how can I move

 money around either internally or through

 different trade finance situations. But I think

 that the derivative and over the counter landscape

-- definitely we'll have a lot more clarity in

 what our risk exposures are.

 MR. SAMS: Yeah, a couple of -- I 

 outlined in my beginning talk this concept of a

 decentralized clearing network, and what we

 sincerely believe can be accomplished within the

 next couple of years is an alternative way of

 clearing an over the counter market that doesn't

 have a central counterpart. One of the things

 that we would like to be able to explore with the

 CFTC is whether a DCN would be considered a

 designated clearing organization under Dodd-Frank
 240

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 or whether the products that a DCN clears would

 fall into an exempt category from central

 clearing. To have a process or a format whereby

 we could communicate with the regulators in

 considerable detail about what the mechanics of a

 DCN would look like and enumerate a lot of open

questions regarding the regulatory framework and

 be able to get some clarity on that before

 significant capital expenditures put into

 attempting to build something like this. I'd say

lastly the OTC clearing topic is obviously a very

 topical one -- controversial across a number of

 dimensions -- and I think it is encouraging that

 the regulators are looking at the technology

 today. I think it will be very helpful if the

 technology can actually start to help inform some

 of the debates that currently take place

 independently and that don't make reference to the

 technology at all. Because I do think the

 technology has some very enabling properties that

 could be quite decisive in some of the regulatory

 debates that are taking place in the OTC
 241

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 landscape, both over here and in Europe and the

 UK.

 MS. RO: I'd like to take a very

 practical situation that I heard recently where

 CFTC asks our market reg for some data information

 regarding transactions that have occurred. We

 have one half of that so we have to go out to our

 FCMs and ask them for the other parts of the

 information, make the phone calls, takes them a

 week or two to get their various departments

 together, collate all that information, gets back

to our market reg team, and then they have to

 review and obviously send that back to you. Why

 does it take two to three weeks? To me that is

 astonishing. Not because anyone is doing anything

 wrong, but that information is just in different

 places and it is siloed. This technology can

 actually help mitigate that. Whether it needs to

 be real time or not, it doesn't really matter. I

 think the point is two to three weeks to get your

 information is too long. I think that is probably

 an extreme example but there is technology today
 242

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 to actually make it far better and I think if we

 can have that in a couple of years' time, we'll

 have a better marketplace because that visibility

 and transparency will be there.

 MR. LEVY: Just the way we think about

 the timing and just back to my presentation of it

-- one to three years, we'll think they're be real

 ops efficiency and ops risk reduction through

 chains plus event in data management, and that's a

 little bit of the point that I think Sandra just

 made. There are real gains that we can make in

the next three. We think in the two to five year

 timeframe that's where collateral could be

 impacted more so on just the operational side and

 then maybe over time on the actual balance sheet

 side. And then in that five to ten year

 timeframe, that's where we could see some real

 impact on liquidity, but we think that is the

 order and the rough timeframe,e and if you look at

 other big disruptions or big technologies whether

 it is PC, the Internet, mobile -- it all takes

 about 10 to 15 years to make a true impact, front
 243

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 to back. But we think there could be real impact

-- not front to back, but in pieces of the process

 in the next couple of years. But not too much

 before that.

CHAIRMAN MASSAD: And in terms of our

 role in that, again, without having to look out 10

 years, because that is a little long, but in the

 shorter term, in terms of the things that we

 should be considering or at least engaging on, are

 there particular things --

MR. LEVY: I think it's a little bit of

 what are the problems we have today and can

 Blockchain help solve them more quickly then what

 we're doing today. I think that's maybe a bit too

 glib or simple but I do think it is about, let's

 not take a technology in search of a problem --

 let's look at the problem and say can this

 technology help us. I also believe there is

 something real to the crowd sourcing of

 engineering solutions as opposed to looking at a

 few entities to ramp up their scale to Rick's

 point earlier -- I think it is going to be
 244

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

different this time. The exchanges or we or a big

bank is not going to solve the scalability issue

-- it is going to be solved by the industry more

collaboratively -- a big piece of that will be

through the open source engineering efforts.

MR. GRIFFIN: Marisol, then Paul. If I

could just remind everyone we are running short on

time, so if we could keep our comments relatively

brief, thanks.

 MS. COLLAZO: I'll be very brief. I

think one area to look at, Chairman Massad, is

going to be in terms of the technology being put

in place. Often the question is where does the

data reside? Where is the database? A lot of the

regulations tend to focus on that, just generally

speaking, so I think that could be a potential

area, in terms of being an enabler of this type of

technology that that is a limitation as the

technology emerges.

MR. CHOU: So we sort of discussed

Blockchains and smart contracts. I'm sort of

interested in some of the other complimentary
 245

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 

 

services that are needed like oracles, for

example. CME, for example, with the brand name, I

wondered if you guys ever considered leveraging

your brand name to actually start broadcasting

prices as an oracle, as a service? For both your

own chains and any around the world. I think that

would have some interesting regulatory

implications.

 MS. RO: That's a very interesting

point. I think we're looking at a lot of

different areas right now. I have to say, that is

one that is a little bit lower down the food chain

in terms of discussion but I appreciate you saying

that, because actually that makes a lot of sense. 

 MR. LEVY: Yes, we think oracles are

going to be an important element because there is

going to be so many chains, side chains and assets

around those chains. Something needs to organize

that a bit more than certainly what goes on in the

Bitcoin space today.

MR. GRIFFIN: Gary?

MR. DEWAAL: To the Chairman's question,
 246

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

one thing I was just thinking about as I heard

this conversation was not what's here today and

what's here tomorrow -- it's really what happens

in between. So during the time period that

perhaps there's disintermediation of FCMs --

because you don't need them, you can do all these

transactions bilaterally. What happens as the FCM

business is slowly killed? What happens to folks

that actually have to rely on it but there's not

enough scale at the FCMs to actually maintain it.

Interesting, for those guys who remain, to stay in

business. I was just looking for the fun of it at

some of the Commission regulations -- 1.31, 1.35

-- the recordkeeping rules. They probably have to

be adapted. There's a lot of rules that probably

have to be adapted to accommodate this, they don't

fit nicely but frankly, they probably don't fit

all that well today and could use some clean up.

But I do wonder about this period of transition.

How does the business work during the period of

transition?

COMMISSIONER GIANCARLO: I remember
 247

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

something Sharon said at the beginning of the day,

talking about when we got out of law school in the

eighties, and I was remembering a story. I was in

law school at the time in the early eighties, I

was talking to a grad student who was an

engineering student, and I asked him what he was

working on, and he said he was working on a new

technology called asynchronous transfer mode which

I still remember now and I said what is that.

Remember this is the day of just the mainframe

computers and he said it allows one computer to 

talk to another computer. And I thought to

myself, why would anybody need that? And now I

look around the room here it's rainy outside, I

imagine most of you are using the computing power

of one of these to call a series of cabs to be

outside in the rain to take you to the airport. A

whole series of computers talking to one another

35 years later, so sometimes it's just not even

possible to envision what new breaking technology

will lead to, but the critically important thing

is that we allow it to develop and it not be
 248

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 

 strangled at birth. And I think we're at the

 birth now of the Blockchain. I think it is

 vitally important that we as regulators take

 account of what we're hearing here and look at our

 regulations and see to what extent do they favor

 an old model of data recording and ledgering, and

 whether we need to take some affirmative steps to

 loosen that up so that this very important

 technology can develop and lead to whatever it is

 going to lead to. But it will lead to some things

 as technology always does and I for one am excited

 to see how it will develop.

MR. LEVY: Commissioner, if I could just

-- I think by cab, you mean Uber, is that right?

 COMMISSIONER BOWEN: I just want to

 thank the committee for the great work. I learned

 so much today and I have lots of great takeaways

 including the fact that we shouldn't be overly

 prescriptive and should look at sort of trading

 activities to make sure we're capturing the right

 people. The staff has done a great job on the

 swap data harmonization and it is clear we need to
 249

 1 

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17 

 18 

 19 

 20 

 21 

 22 

 

 do more work in that area and I clearly support

 reconstituting the working group that did such

 great work before. Blockchain, as a regulator, I

 just need to be mindful of what it means to be a

 node on the Blockchain.

 MR. GRIFFIN: Any further comments?

 Wonderful.

 CHAIRMAN MASSAD: Thanks, everyone, once

 again.

 MR. GRIFFIN: Sandra, Brad, Robert,

 James -- thank you for helping to lead a very good

 discussion here today. Before we adjourn, I just

 want to thank all of the TAC members, both for

 your contributions and for participating again

 with the last minute rescheduling, courtesy of the

 blizzard and so on and so forth. And we really do

 appreciate your attendance and participation.

 Also a very special thank you to our outstanding

 staff, both for their assistance in organizing

 this meeting as well as all of the behind the

 scenes logistics, everything you don't see, the

 folks who are behind this glass pane back here --
 250

 1 

 2 

 3 

 4 

 5 

 6 

 7 

8 

9 

10

11

12

13

14

15

16

17

18

19

20

21

22

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 they really helped to make this happen, so thank

 you. As well of course, all the contributions of

 our CFTC panelists earlier in the day. With that,

 this meeting is now adjourned. Thank you.

 (Whereupon, at 3:35 p.m., the

 PROCEEDINGS were adjourned.)

 * * * * *
 251

 1

 2 

 3 

 4 

 5 

 6 

 7 

 8 

 9 

 10 

 11 

 12 

 13 

 14 

 15 

 16 

 17

 18

 19 

 20 

 21 

 22 

 

 

 

CERTIFICATE OF NOTARY PUBLIC

DISTRICT OF COLUMBIA

I, Carleton J. Anderson, III, notary

 public in and for the District of Columbia, do

 hereby certify that the forgoing PROCEEDING was

 duly recorded and thereafter reduced to print under

 my direction; that the witnesses were sworn to tell

 the truth under penalty of perjury; that said

 transcript is a true record of the testimony given

 by witnesses; that I am neither counsel for,

 related to, nor employed by any of the parties to

 the action in which this proceeding was called;

 and, furthermore, that I am not a relative or

 employee of any attorney or counsel employed by the

 parties hereto, nor financially or otherwise

 interested in the outcome of this action.

 (Signature and Seal on File)

 -----------------------------------

 Notary Public, in and for the District of Columbia

 My Commission Expires: March 31, 2017