JOINT STUDY ON THE 

FEASIBILITY OF MANDATING 

ALGORITHMIC DESCRIPTIONS 

FOR DERIVATIVES

A STUDY BY THE STAFF OF THE SECURITIES AND EXCHANGE 

COMMISSION AND THE COMMODITY FUTURES TRADING 

COMMISSION AS REQUIRED BY SECTION 719(b) OF THE DODD-FRANK 

WALL STREET REFORM AND CONSUMER PROTECTION ACT

APRIL 7, 2011

[DISCLAIMER]

This is a study by the staff of the U.S. Securities and Exchange Commission and the

staff of the U.S. Commodity Futures Trading Commission. The Commissions have 

expressed no view regarding the analysis, findings or conclusions contained herein.
719(b) Feasibility Study

iii

Contents 

EXECUTIVE SUMMARY...............................................................................................................1

I. CONGRESSIONAL STUDY MANDATE ..................................................................................3

I.1. STATUTORY LANGUAGE ..............................................................................................3

I.2. KEY TERMS ......................................................................................................................3

I.3. PROCESS AND APPROACH ...........................................................................................5

II. BACKGROUND ON OTC DERIVATIVES MARKETS ..........................................................6

II.1. TYPES OF DERIVATIVES, COUNTERPARTIES, AND EXECUTION ...................6

II.1.a. TYPES OF DERIVATIVES ...............................................................................6

II.1.b. COUNTERPARTIES TO A SWAP AGREEMENT.........................................7

II.1.c. EXECUTION OF A SWAP AGREEMENT......................................................7

II.2. SWAP DOCUMENTATION ...........................................................................................8

II.2.a. MASTER AGREEMENTS AND CREDIT SUPPORT DOCUMENTS .........8

II.2.b. CONFIRMATIONS ...........................................................................................9

II.2.c. MASTER CONFIRMATION AGREEMENTS ................................................9

II.3. STANDARDIZED MACHINE-READABLE DATA THAT IS 

CURRENTLY AVAILABLE ..........................................................................................10

II.4. ELECTRONIC REPRESENTATION OF MASTER AND CREDIT 

SUPPORT AGREEMENTS ...........................................................................................12

II.5. CREATING MACHINE READABLE, LEGALLY-BINDING DOCUMENTS ........13

III. DATA THAT MAY BECOME AVAILABLE THROUGH ONGOING 

RULEMAKING UNDER THE DODD-FRANK ACT..........................................................15

III.1. SDR ENHANCEMENT TO MARKET ANALYSIS.....................................................15

III.1.a. REGULATORS WILL HAVE DIRECT, CENTRALIZED

ACCESS TO DATA ......................................................................................... 15

III.1.b. DATA CAN BE USED TO ANALYZE THE MARKET .............................. 16

III.2. SDR LIMITATIONS RELATING TO MARKET ANALYSIS...................................16

III.2.a. UNIVERSAL, UNIQUE IDENTIFIERS ...................................................... 17

III.2.b. GENERAL CONTRACTUAL OBLIGATIONS ........................................... 17

III.2.c. CONSISTENCY ACROSS ALL REPOSITORIES ........................................ 18
719(b) Feasibility Study

iv

IV. SIGNIFICANT ISSUES AND CHALLENGES .....................................................................19

IV.1. THE ABSENCE OF UNIVERSAL ENTITY AND 

PRODUCT IDENTIFIERS..........................................................................................19

IV.2. DESCRIBING CONTRACTUAL TERMS IN A MACHINE-READABLE FORMAT

20

IV.3. LACK OF COMMON INDUSTRY-WIDE REPRESENTATION OF REFERENCE 

DATA.............................................................................................................................22

V. CONCLUSIONS .......................................................................................................................23

V.1. STANDARDIZING ENTITY AND PRODUCT IDENTIFIERS ...............................24

V.2. POSSIBLE FURTHER USE OF COMPUTER READABLE 

REPRESENTATIONS FOR LEGAL DOCUMENTS .................................................25

V.3. REPRESENTATION OF REFERENCE DATA .........................................................25
719(b) Feasibility Study

1

EXECUTIVE SUMMARY

On July 21, 2010, President Obama signed into law the Dodd-Frank Wall Street Reform and 

Consumer Protection Act (“Dodd-Frank Act”). Title VII of the Dodd-Frank Act provides the

Commodity Futures Trading Commission (“CFTC”) and the Securities and Exchange 

Commission (“SEC”) with the authority to regulate over-the-counter (“OTC”) derivatives in

light of the recent financial crisis, which demonstrated the need for enhanced regulation of the 

OTC derivatives market. The Dodd-Frank Act provides that the CFTC will regulate “swaps” 

and the SEC will regulate “security-based swaps.”

Section 719(b) of the Dodd-Frank Act requires the SEC and the CFTC (collectively the 

“Commissions”) jointly to study (the “Study”) the “the feasibility of requiring the derivatives 

industry to adopt standardized computer-readable algorithmic descriptions which may be used 

to describe complex and standardized financial derivatives,” and the extent to which such 

algorithmic descriptions, together with standardized legal definitions, “may serve as the binding 

legal definition of derivative contracts.”1 The statute also requires us to examine the “logistics of 

possible implementations of standardized algorithmic descriptions for derivatives contracts.”

Thus, the Study presents two key questions. First, is computer technology capable of 

representing derivatives with sufficient precision and detail to facilitate collection, reporting, and 

analysis of risk exposures, including calculation of net exposures, as well as to function as part or 

all of a binding legal contract? Second, if the technological capability exists, in consideration of 

the logistics of possible implementation, should these standardized, computer-readable 

descriptions be required for all derivatives?

The Study fits within the broader context of the Commissions’ work toward bringing greater 

transparency to the derivatives markets by requiring market participants to collect, report, and 

manage their risk exposures. In essence, the Study explores whether the collection, reporting, 

and management of risk exposures can be aided by the computer-readable descriptions - a 

common dictionary with standardized, electronic “spelling” for each aspect of a derivative.

To answer these questions, a cross-agency staff task force (the “staff”) was established.

2 The 

Commissions also solicited comments and data and published a Notice of Request for Comment 

in the Federal Register. The staff conducted an extensive outreach effort, meeting with market 

participants, industry groups, data vendors, and academics, and communicated with international 

regulators, notably the members of the International Organization of Securities Commissions' 

(“IOSCO”) Task Force on OTC Derivatives Regulation. The staff also participated in 

collaborative discussions facilitated by the U.S. Treasury Department’s Office of Financial 

Research and other financial regulators.

In addition, the staff have considered the types of data that will become available to regulators 

and market participants in the future as a result of the Dodd-Frank Act.

Based on the public input and its own analysis, the staff conclude, with respect to the first 

question, that current technology is capable of representing derivatives using a common set of 

computer-readable descriptions. These descriptions are precise enough to use both for the 

calculation of net exposures and to serve as part or all of a binding legal contract.

 1 Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010, Pub. L. No. 111-203, § 719(b)(2), 123 

Stat. 1376, 1655 (2010). A copy of the relevant text appears in Appendix A.

2 Professional staff were designated to undertake the Study, including staff with expertise in financial economics, 

law, computer technology, and the derivatives industry. 
719(b) Feasibility Study

2

As to question two, the staff conclude that before mandating the use of standardized 

descriptions for all derivatives, the following are needed: a universal entity identifier and product 

or instrument identifiers, a further analysis of the costs and benefits of having all aspects of legal 

documents related to derivatives represented electronically, and a uniform way to represent 

financial terms not covered by existing definitions.

To that end, the staff view standardized computer-readable descriptions for at least a broad 

cross-section of derivatives as feasible, leaving, for now, the industry to develop solutions that 

would achieve that this. The staff contemplates that other financial regulators and the Office of 

Financial Research, along with the Commissions’ staff, may engage in a series of public-private 

initiatives to foster collaboration between the regulators and the derivatives industry to work 

toward representation of a broader cross-section of derivatives in computer-readable form. 

The OTC derivatives markets are in transition. It is unclear what portion of transactions will 

become subject to mandatory central clearing through derivative clearing organizations or 

clearing agencies. For those contracts that remain un-standardized and continue to trade OTC, 

additional challenges remain for automating calculations of net exposures. Standardizing and 

automating legal definitions and terms across dealers in some asset classes, while maintaining 

flexibility for new types of products, would appear to benefit risk management. Although the 

comments to the Commissions regarding the Study differ on the merits of various approaches, 

there was general agreement on the benefit of having readily available data to calculate net 

exposures in the OTC derivatives market.

* * *

The Study consists of five sections. Section I describes the congressional mandate for the Study. 

Section II describes the relevant aspects of the current OTC derivatives market. Section III

describes the data that will become available to regulators and market participants under DoddFrank regulations promulgated by the Commissions. Section IV describes the three main 

challenges to mandating that the derivatives industry adopt standardized computer-readable 

algorithmic descriptions to describe complex and standardized financial derivatives. Section V 

provides the Study conclusion. 
719(b) Feasibility Study

3

I. CONGRESSIONAL STUDY MANDATE

I.1. STATUTORY LANGUAGE

Section 719(b) of the Dodd-Frank Act requires that the Commissions “conduct a joint study of 

the feasibility of requiring the derivatives industry to adopt standardized computer-readable3

algorithmic descriptions which may be used to describe complex and standardized financial 

derivatives.”4 The Dodd-Frank Act states that the goal of using these algorithmic descriptions is 

to “facilitate computerized analysis of individual derivatives contracts and to calculate net 

exposures to complex derivatives.”5

The Dodd-Frank Act specifies that algorithmic descriptions be “optimized for simultaneous use 

by (A) commercial users and traders of derivatives; (B) derivatives clearing houses, exchanges 

and electronic trading platforms; (C) trade repositories and regulator investigations of market 

activities; and (D) systemic risk regulators.”6

The Dodd-Frank Act also requires that the Study determine whether an electronic 

representation of a derivatives contract, together with standardized legal definitions, can be 

legally binding.7 Finally, to the extent appropriate and practical, the Commissions must 

coordinate with international financial institutions and regulators.8

I.2. KEY TERMS

Section 719(b) of the Dodd-Frank Act requires that the Commissions consider “algorithmic 

descriptions” of derivatives for the purposes of calculating “net exposures.”9 An algorithm is a 

step-by-step procedure for solving a problem, especially by a computer, which frequently 

involves repetition of an operation.10 Algorithmic descriptions, therefore, would refer to a 

computer representation of derivatives contracts that is precise and standardized, allowing for 

calculations of net exposures. While it is conceivable to represent derivatives as algorithms – by 

reflecting the steps necessary to calculate net exposures and other analysis as computer code –

such an approach would be very difficult given the divergence of assumptions and complex 

modeling needed to calculate net exposures. Accordingly, the staff have interpreted “algorithmic 

descriptions” to mean the representation of the material terms of derivatives in a computer 

language that is capable of being interpreted by a computer program.

While many forms of derivatives themselves could be described as algorithms and some aspects 

of derivatives could be described as procedures, calculations of net exposures often require 

additional computer modeling, not just understanding the basic agreement between two parties. 

To accomplish this modeling, economic and legal terms need to be made machine-readable.

 3 The terms “computer-readable” and “machine readable” are used interchangeably throughout.

4 Dodd-Frank Act Section 719(b)(1).

5 Id. at § 719(b)(2). Although we recognize that gross exposures play a significant part in evaluating systemic risk, an 

assessment of whether algorithmic descriptions can facilitate the calculation of gross exposures to complex 

derivatives is outside of the scope of the Study.

6 Id.

7 Id.

8 Id. at § 719(b)(3).

9 Id. at § 719(b)(2).

10 MERRIAM-WEBSTER ONLINE DICTIONARY, http://www.merriam-webster.com/ (last visited Feb. 25, 2011).
719(b) Feasibility Study

4

The net exposure of market participants to derivatives can be viewed narrowly or broadly. A 

narrow interpretation might be the market value of an outstanding derivatives position, for a 

particular firm.11 Using this method, a static view of net exposure for a given firm can be viewed 

as the sum of all of its marked-to-market positions, both positive and negative, less any hedging 

positions.

However, such a narrow definition may not adequately capture the full financial risk of the OTC 

derivatives positions for the firm or for the market as a whole. The risk associated with a 

derivatives instrument whose value likely will vary over time is a dynamic risk, depending on 

changes in market conditions and lifecycle events that affect the value of a contract, such that a 

single “snapshot” view of the instrument will not capture all risk exposure associated with 

potential future losses or counterparty credit exposure.12

In some cases, calculations of net exposure need to incorporate an analysis of obligations to pay 

or receive collateral, as well as counterparty credit risk and legal risk associated with 

collateralized obligations.13 These details are frequently spelled out legal documents called credit 

support agreements,

14 and can substantially reduce the net exposure associated with a derivatives 

contract over its lifecycle.15

An “algorithmic description” of derivatives that allows for calculations of “net exposures” must 

be able to serve different users, each of which relies on different assumptions and modeling 

techniques, and thus an “algorithmic description” defined as a representation of a derivative as a 

step-by-step procedure may not fully describe a given contract. However, as discussed below, it 

may be feasible to describe the terms of these contracts in a sufficiently precise and standardized 

way as to facilitate the modeling necessary to calculate net exposure for different members of 

industry and for regulators.

 11 Letter from International Swaps and Derivatives Association (“ISDA”) and Securities Industry and Financial 

Markets Association (“SIFMA”) at 2, Dec. 31, 2010, available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26827&SearchText=; Letter from Investance 

at 1, Dec. 23, 2010, available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26796&SearchText= (“Most of our clients 

define complex derivatives as those derivatives that are not exchange traded, allowing for a wide variety of deal 

specific attributes that do not allow for generic nomenclature that is sufficiently descriptive. These derivatives often

. . . cannot be priced using a closed form solution, i.e., a formula and must be priced using mathematical techniques 

that estimates the price using a non formula methodology (e.g., Monte Carlo simulation).”).

12 Letter from ISDA and SIFMA, supra note 11 at 2-3.

13 Id. at 3.

14 See COMMODITY FUTURES TRADING COMMISSION, PUBLIC ROUNDTABLE TO DISCUSS SWAP DATA 

RECORDKEEPING AND REPORTING REQUIREMENTS 269-71 (Jan. 28, 2011), available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=27489&SearchText= (hereafter “CFTC Staff

Roundtable”).

15 Meeting with Michael Will, docGenix, Conf. Call (Jan. 20, 2010). The calculations can be complex. As ISDA and 

SIFMA observed, “even though a party may have negative exposure to its counterparty (such that the counterparty 

is in the money), that party may have credit exposure to such counterparty as a result of the party having over 

collateralized its counterparty.” Letter from ISDA and SIFMA, supra note 11 at 3.
719(b) Feasibility Study

5

I.3. PROCESS AND APPROACH

The Commissions established a cross-agency staff task force composed of economists, 

technology experts, professionals with recent derivatives industry experience, and attorneys. The 

Commissions gathered public input by publishing a Notice of Request for Comment in the 

Federal Register and by posting this notice and these questions on their websites, which also 

were distributed to various market participants and organizations, and provided to the IOSCO 

Task Force on OTC Derivatives. The staff conducted research on the state of technology and 

industry practices regarding derivatives data management and analysis that included meetings 

with market participants, literature reviews, and examination of current industry practices and 

initiatives.

In all, the Commissions received 17 responses from a broad cross section of the public, 

including major participants, dealers in the derivatives markets, vendors, and others. The Federal 

Register notice and questions appear in Appendix B. Copies of responses appear on the CFTC’s 

website.

16 A list of meetings with interested parties appears in Appendix C. We thank all of the 

individuals and organizations that provided information, insight, and recommendations to the 

Commissions.

 16 Comment letters are available at http://comments.cftc.gov/PublicComments/CommentList.aspx?id=915.
719(b) Feasibility Study

6

II. BACKGROUND ON OTC DERIVATIVES MARKETS

This section focuses on derivatives products, market participants, and trade execution processes.

It also discusses the documentation that establishes the rights and responsibilities of the parties 

who enter into OTC derivatives contracts, the machine-readable descriptions of transaction data 

and contracts that are currently available for OTC derivatives transactions, and the extent to 

which electronically rendered versions of these documents are legally binding.

II.1. TYPES OF DERIVATIVES, COUNTERPARTIES, AND EXECUTION

II.1.a. TYPES OF DERIVATIVES

A derivative is a contract whose value is derived from the value of an underlying asset (such as a 

commodity, equity, bond, or loan), an index, or a reference rate (such as an interest or exchange 

rate). Derivative contracts include futures, forwards, options, and swaps.17 The contract could 

include a combination of futures, forwards, options, or swaps, which themselves may be a series 

of cash forward contracts.

Derivatives may be traded on exchanges or over-the-counter. The Study focuses on OTC 

derivatives such as swaps18 because exchange-traded derivatives such as futures and options are 

standardized already and described in computer-readable languages, so that valuing them and 

understanding net exposure is not an issue. By contrast, the OTC derivatives market permits 

greater customization of agreement terms, which presents a challenge to the development of 

standardized forms for these agreements. Further, OTC derivatives often are not centrally 

cleared, and may be based on underlying assets that are more complex or more difficult to value 

than exchange-traded derivatives.

A swap is a bilateral agreement to exchange payments based on some agreed formula and 

according to a schedule of dates.19 Swaps can be grouped into several asset classes. Swaps may 

include contracts for the exchange of a fixed interest rate for a floating one (interest rate swaps), 

protection against default (credit default swaps), hedging against an equity index, basket of 

equities or structured equity product (equity swaps), protection against fluctuating currency 

exchange rates (foreign exchange swaps), and other less common contracts, such as protection 

against weather conditions.20 An example of a “plain vanilla” interest rate swap would be a 

contract composed, in economic terms, of a series of cash forward contracts, where one party 

makes periodic payments based on a fixed rate of interest while the other makes payments based 

on a floating interest rate.21

 17 E.g., John C. Hull, Options, Futures, and Other Derivatives 1 (4th ed. 2000).

18 The Dodd-Frank Act provides definitions of the terms “swap” and “security-based swap.” See Dodd-Frank Act 

Sections 721(a) (amending 7 U.S.C. § 1(a)(47)) and 761(a) (amending 15 U.S.C. § 78(c)(a)(68)). For purposes of the 

Study, the term “swap” is used generally to identify, in economic terms, contracts that would be swaps or securitybased swaps under the Dodd-Frank Act definitions, as they exist currently in the OTC derivatives market. DoddFrank Act Section 721(a)(21) (swaps encompass master agreements and supplements).

19 Don M. Chance, Essays in Derivatives 13 (1998).

20 See id. at 14-15.

21 Id. at 14.
719(b) Feasibility Study

7

II.1.b. COUNTERPARTIES TO A SWAP AGREEMENT

Swaps are created in a number of ways. Some swaps are facilitated by dealers in the course of 

their market-making businesses.22 Other swaps are entered into between two dealers acting on 

behalf of themselves, or between a dealer and an end-user or client. In fact, any two 

counterparties, including two end-users, may enter into a swap agreement.23

II.1.c. EXECUTION OF A SWAP AGREEMENT

Before entering into a swap agreement, both counterparties to the swap will typically first 

negotiate and sign a master agreement and other agreements that govern all swap transactions 

subsequently entered into between the two parties. The terms of these agreements are 

documented using master agreements, credit support annexes, and other documents, generally 

using standardized forms created by ISDA or one of a few other standard formats. These 

documents will be discussed in detail below.

Once these agreements are executed, the counterparties may enter into specific swap 

transactions. At present, these transactions may be executed through multiple venues, including 

over the telephone, through central order systems, and through single-dealer platforms, 

depending on the degree of standardization of the swap.

24

After a swap transaction is executed, the parties to the swap “confirm” the transaction, or verify 

the economic terms of the trade with one another.25 The economic terms of a trade include the 

trade date, notional amount, and payment terms. Generally, to verify the economic terms, one 

counterparty sends a trade acknowledgement to the other counterparty for review and 

verification. The acknowledgment may be sent directly or through a third-party service that 

displays the acknowledgment for the recipients to review.26 Some third-party firms also provide a 

matching service that receives trade acknowledgments from each counterparty and compares the 

documents.

27 Electronic processes for trade confirmations are discussed further in Section II.2.b.

For some types of swaps, a clearinghouse may be willing to accept the swap contract for central 

clearing, thereby assuming the risk of counterparty default. In this case each counterparty 

novates (or assigns) its rights and obligations under the contract to a clearinghouse.

Clearinghouses are capitalized by clearing members and use this capital in the event that a 

 22 Further Definition of “Swap Dealer,” “Security-Based Swap Dealer,” “Major Swap Participant,” “Major SecurityBased Swap Participant,” and “Eligible Contract Participant,” 75 Fed. Reg. 80,174, 80,175-76 (proposed Dec. 21, 

2010).

23 Lawrence C. Tondel & Jonathan D. Gupta, Introduction to Derivatives, in DERIVATIVES: LEGAL PRACTICES 

AND STRATEGIES, 1.14 (Robert D. Aicher ed., Aspen Publishers 2010). 

24 See Registration and Regulation of Security-Based Swap Execution Facilities, 76 Fed. Reg. 10,948, 10,951 

(proposed Feb. 28, 2011), and Core Principles and Other Requirements for Swap Execution Facilities, 76 Fed. Reg. 

1,214 (proposed Jan. 7, 2011).

25 Trade Acknowledgment and Verification of Securities-Based Swap Transactions, 76 Fed. Reg. 3,859, 3,860 

(proposed Jan. 21, 2011).

26 This process is referred to as affirmation. See MarkitSERV for Confirmations, MARKITSERV, 

http://www.markitserv.com/ms-en/solutions/by-service/confirm.page (last visited Feb. 21, 2011).

27 Id. For credit default swaps, these transactions can be confirmed by sending an electronic copy to a matching 

service like Markit/SERV, using Financial Products Markup Language. DTCC Trade Information Warehouse, 

DTCC, http://www.dtcc.com/products/derivserv/suite/trade_reporting_repository.php (last visited Feb. 21, 

2011).
719(b) Feasibility Study

8

clearing member defaults.28 Some clearinghouses have specialized in clearing interest rate swaps 

between large banks,29 and these swaps generally are highly standardized. Historically, most 

cleared swaps have been inter-dealer transactions. Most swaps between dealers and end-users are 

not currently cleared by a central clearinghouse, although a large percentage of both cleared and 

uncleared transactions have some level of electronic processing for trade confirmations. Highly 

customized swaps are typically processed manually due to the lack of standardized terms.30

II.2. SWAP DOCUMENTATION

Participants in the OTC derivatives market typically document swap trading relationships by 

using industry standard legal documentation, including master netting agreements, definitions, 

schedules, and confirmations.31 Industry standard documentation includes the ISDA Master 

Agreement and related definitions, schedules, and confirmations specific to particular asset 

classes, and offers a framework for documenting transactions between counterparties for OTC 

derivatives products.32 The standard documentation details the legal, trading, and credit 

relationship between the parties. This facilitates cross-product netting of transactions, including 

netting in the event that parties have to close-out their positions with one another. Although the 

documentation uses standard clauses, the staff understands that the parties routinely negotiate 

terms that modify the standard clauses. A description of these standardized agreements follows. 

II.2.a. MASTER AGREEMENTS AND CREDIT SUPPORT DOCUMENTS

Master agreements provide the central documentation for swap counterparties’ trading 

relationships and memorialize the parties’ allocation of credit, legal, and operational risks. Master 

agreements also serve as master netting agreements and provide for close-out netting for all 

transactions,33 which, along with collateral arrangements,34 provide an important method of 

 28 See Order Granting Temporary Exemptions, 74 Fed. Reg. 10,647, 10,648-49 (Dep’t of Treasury, Mar. 11, 2009).

29 Matthew Leising and Mary Childs, LCH.Clearnet Sees U.S. as ‘Battleground’ for Clearing Interest-Rate Swaps, 

BLOOMBERG, Jul. 21, 2011, available at http://www.bloomberg.com/news/2010-07-21/lch-clearnet-seeks-u-sdominance-in-rate-swap-clearing-amid-rule-changes.html.

30 In this context, “standardized terms” means terms relating to highly traded swaps. The Study references 

“complex” derivatives, and market participants commonly refer to “bespoke” (or one-off) swaps. Because we are 

focused on the line between those swaps currently represented electronically and those that are not, we are not 

using these terms but are, instead, referring to “standardized” swaps, and those that are not. Some commenters 

have indicated that in the commodities space and to a lesser degree in the FX space, a number of end-user to enduser swaps are executed manually without electronic intervention. 

31 “Master netting agreements” are defined in the bankruptcy code as “an agreement providing for the exercise of 

rights, including rights of netting, setoff, liquidation, termination, acceleration, or close out under or in connection 

with one or more contracts,” which include swap agreements. 11 U.S.C. § 101(38A) (2010).

32 Copies of these documents can be obtained through the ISDA Bookstore, available at

http://www.isda.org/publications/pubguide.aspx (last visited Mar. 7, 2011).

33 “Close-out netting” has been defined as “a process involving termination of obligations under a contract with a 

defaulting party and subsequent combining of positive and negative replacement values into a single net payable or 

receivable.” David Mengle, ISDA Research Notes at 2, ISDA (2010), available at

http://www.isda.org/researchnotes/pdf/Netting-ISDAResearchNotes-1-2010.pdf. Enforceable bilateral netting 

arrangements are a common commercial practice and are an important part of risk management and minimization 

of capital costs. HOUSE OF REPRESENTATIVES COMMITTEE ON THE JUDICIARY, REPORT ON BANKRUPTCY ABUSE 

PREVENTION AND CONSUMER PROTECTION ACT OF 2005 125 (Apr. 8, 2005), available at 

http://www.law.ttu.edu/lawlibrary/library/research/bapcpa_library/house-report-109-31-121-130.htm#p125.
719(b) Feasibility Study

9

addressing counterparty credit risk arising from OTC derivatives transactions. Following a 

default, swap transactions between the two parties are terminated, and the value of each swap 

transaction is calculated and netted to determine a single net amount due from one party to the 

other.

Information contained in master agreements and similar documents such as credit support 

agreements may also be used by regulators for the analysis of systemic risk. Important 

information for this analysis includes, but is not limited to, the following: events of default; 

terms which establish the collateral relationship between two parties; variables contained in 

collateral systems that are required for calculating margin calls; netting provisions; a wide range 

of product-specific definitions and individual trade confirmations; termination events; 

rehypothecation provisions35; and lifecycle events that would result in a new swap or a change in 

the terms of an existing swap.

II.2.b. CONFIRMATIONS

In addition to standardized master agreements, ISDA has created standardized documents for 

confirmation of many types of swap agreements. These documents contain the economic terms 

of a trade, and counterparties verify these documents with one another. Confirmation 

documents generally are subject to the master agreement and any amendments to it, but parties 

may modify the terms of the master agreement that relate to a specific confirmation or 

confirmations. Section II.1.c., above, describes methods counterparties may use to verify these 

confirmation documents.

II.2.c. MASTER CONFIRMATION AGREEMENTS

The derivatives industry has developed master confirmation agreements as a bridge between 

master agreements and confirmations.36 While the content of master confirmation agreements 

could be incorporated into the parties’ master agreements, parties sometimes negotiate master 

confirmation agreements as stand-alone documents because they are often negotiated by 

product specialists on an asset class by asset class basis. A master confirmation agreement allows 

the parties to agree on most standard terms for a complex trade, and then enter into individual 

transactions by agreeing on a small subset of economic terms in a confirmation in the form of a 

transaction supplement. With respect to confirmations, after coming to an agreement on the 

terms of a transaction, parties document the transaction in a complete and definitive written 

master confirmation agreement.37

 34 Obligations in swap trades are often secured according to the terms of a credit support agreement, but parties 

may use other methods to secure their obligations, such as guarantees from third parties.

35 Rehypothecation takes place when an entity that is the recipient of a collateral pledge uses that same collateral to 

secure its own borrowing. Manmohan Singh and James Aitken, Deleveraging after Lehman – Evidence from 

Reduced Rehypothecation 3 (IMF, Working Paper, Mar. 2009), available at

http://www.imf.org/external/pubs/ft/wp/2009/wp0942.pdf.

36 Examples of Standard Master Confirmation Agreements that have been published are available at 

http://www.isda.org/publications/isdacredit-deri-def-sup-comm.aspx. They include: 2004 Sovereign Master Credit 

Derivatives Confirmation Agreement, the 2003 Master Credit Derivatives Confirmation Agreement (Asia-Pacific), 

the 2004 Americas Interdealer Master Equity Derivatives Confirmation Agreement, and others.

37 If converted to an electronic format, parties can further agree that the electronic record is legally binding. See 

Keeping ‘gold’ trade records ‘gold,’ DTCC DERIV/SERV (Oct. 9, 2006), 

http://www.dtcc.com/products/documentation/derivserv/DerivSERV%20-%20Gold.pdf (last visited Mar. 10, 

2011).
719(b) Feasibility Study

10

II.3. STANDARDIZED MACHINE-READABLE DATA THAT IS CURRENTLY 

AVAILABLE 

Currently, some economic data for exchange-traded derivatives, and certain standardized OTC 

swaps, can be represented in standardized computer-readable messages for confirmation and 

clearing purposes. But legal documentation and data relating to non-standardized transactions 

generally is not represented in a machine-readable format, or if it is, it typically relies on 

proprietary systems that are not publicly available.38 To the extent that non-standardized 

derivatives transactions are computer-readable, the derivative transaction and contract 

information is available only in internal, proprietary systems developed and used by dealers, 

clearinghouses, trade repositories, and large money managers.39 Such systems have been 

customized to meet the institutions’ needs, making extensive modifications to current and past 

industry standard electronic definitions. In response to the Commissions’ request for comments, 

several commenters said that they have implemented new frameworks or standards for 

organizing and sending data.40Because these customized solutions do not rely on standardized 

computer languages and reference data, it may be difficult for counterparties and others to 

exchange and use the data.41

Standardization across firms currently exists to some degree, however. Specifically, to foster 

electronic communication of trades of certain derivatives, the financial industry has moved 

toward standardized methods of formatting data for messaging confirmations and clearing. The 

most commonly used standards are the Financial product Markup Language (“FpML”) and the 

Financial Information eXchange (“FIX”) Protocol.42 Both standards are focused on messaging 

certain economic terms of standard exchange-traded or OTC derivatives. Each provides some of 

the data needed to perform net exposure calculations for the instruments they cover.43

 38 Letter from Michael Atkin, EDM Council at 2, Dec. 22, 2010, available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26952&SearchText=.

39 Meeting with Pierre Lamy, Goldman Sachs, Conf. Call (Nov. 18, 2010); Meeting with Jennifer Han, Associate 

General Counsel, Managed Funds Association, Conf. Call (Jan. 13, 2011); FpML Information, FPML, 

http://www.fpml.org/about/factsheet.html (last visited Feb. 21, 2011).

40 David M. Inggs, Goldman Sachs at 2 (Dec. 29, 2010), available at

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26814&SearchText=; letter from David N. 

Gertler, letter from SuperDerivatives at 9 (Dec. 31, 2010), available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26965&SearchText=; letter from BM&F 

Bovespa at 6 (Dec. 31, 2010), available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26950&SearchText=; letter from CETIP at 6 

(Dec. 31, 2010), available at

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26951&SearchText=.

41 FpML Information, FPML, http://www.fpml.org/about/factsheet.html (last visited Feb. 21, 2011).

42 The FIX Protocol Organization, FIX PROTOCOL, http://www.fixprotocol.org/adopters/21 (last visited Feb. 21, 

2011).

43 Neither expresses the formulas by which the cash flows relevant to those net exposure calculations are calculated, 

but they could serve as wrappers, or vessels, for carrying certain algorithmic information. This is not a new idea.

The SEC’s Asset Backed Securities rule proposed last April called for issuers to file the source code of a computer 

program into which interested persons could plug the tagged data terms from the XML-tagged “asset data file” to 

calculate potential cash flows. Asset Backed Securities, 75 Fed. Reg. 23,328, 23,378 (proposed Apr. 7, 2010). Data 

tagged using FpML or FIX Protocol could serve as inputs into a computer program like the waterfall computer 

program to determine cash flows.
719(b) Feasibility Study

11

FpML is widely used in the OTC derivatives market to electronically message and confirm 

standard credit default swaps.44 It is built from Extensible Markup Language (“XML”), which is 

a flexible text-based markup language45 that has gained wide use in electronic communication.46

FpML provides a common yet customizable language. ISDA oversees the FpML standard.

The FIX Protocol is widely used for electronic trading in exchange-traded securities,

47 and has 

significant industry support in clearing applications.48 Compared to FpML, FIX offers a smaller 

data file for common products such as equities, futures and foreign exchange. FIXML is an 

XML representation of FIX (FIXML is the Financial Information eXchange Markup Language),

and some firms already experienced in using FIX are now using FIXML for OTC derivatives.49

FIX Protocol Limited (“FPL”) oversees the FIX standard.50

FpML and FIX each have different strengths that reflect their intended purposes. The two major 

considerations in representing financial data that are often at odds are the speed of transmission 

(determined in part by the size of the data file), and the ability to capture complex or 

customizable information about products. FIX is most widely used as a messaging language to 

relay trade information quickly and concisely. Because it focuses on speed, FIX is not suitable 

for large files containing volumes of data (often referred to as “verbose” files). FIXML is being 

developed to accommodate larger message sizes.51

FpML is designed for the OTC derivatives market and supports large data files. While FpML

can capture the complexity of products, the speed of transmission is secondary. By being very 

expandable, FpML allows for the electronic representation of customized or novel products.

Despite the industry’s move toward standardization, some derivatives products are still incompletely

represented in standardized machine-readable format, and the development of standardized tags 

typically follows behind the development of new instruments. As one commenter explained: 

“FpML relies on an existing body of contract type definitions, defined at too high a level of 

abstraction and thus it lags transaction innovation. This lag is often managed internally by the 

use of proprietary extensions to FpML, which further introduces inconsistencies between parties 

and sometimes incomplete representations of the full economic terms and contractual obligations

of a contract.”52Thus, to be truly useful, the staff believes that accelerated development of 

markup language tags may be needed for new and non-standard swaps.

 44 In 2001, ISDA “integrat[ed] the development process of the FpML standard into [its] organizational structure.”

History of FpML, FPML, http://www.fpml.org/about/history.html (last visited Mar. 8, 2011). 

45 A markup language is defined as “a modern system for annotating a text in a way that is syntactically 

distinguishable from that text” and often includes instructions that are not visible to the end user of the text.

Markup Language, WIKIPEDIA, http://en.wikipedia.org/wiki/Markup_languages (last visited Feb. 25, 2011).

46 E.g., Extensible Markup Language (XML), W3C, http://www.w3.org/XML/ (last visited Feb. 25, 2011).

47 D. Craig Nordlund, Electronic Dissemination of Disclosure Documents, 1093 PLI CORPORATE LAW AND 

PRACTICE COURSE HANDBOOK 39, 113 (Jan.-Feb. 1999).

48 Meeting with Pierre Lamy, Goldman Sachs, Conf. Call (Nov. 18, 2011).

49 Id. For example, CME Group uses FIX in credit default swap clearing.

50 Mary Ann Burns, FIXML Moves Ahead as Global Messaging Standard, FUTURES INDUSTRY, Jan. 2010 at 43, 

available at http://www.futuresindustry-digital.com/futuresindustry/201001?pg=43#pg43.

51 Id. Files representing terms of OTC swaps are, by nature, more verbose than data files reflecting exchange traded 

derivatives, often because they contain less standard terms or more variables.

52 Letter from Olu Oni at 3 (Dec. 31, 2010), available at

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26828&SearchText=.
719(b) Feasibility Study

12

In summary, FpML, FIX and FIXML are messaging languages commonly used to facilitate 

storage and analysis of derivatives contracts, but do not represent all aspects of the contracts 

that they are used to describe, and do not cover all types of derivatives. Much remains in the 

form of written contracts or proprietary data formats and would be expensive for firms to 

convert to machine-readable data, to store the data, and to use the data in analysis.53

II.4. ELECTRONIC REPRESENTATION OF MASTER AND CREDIT 

SUPPORT AGREEMENTS

As noted in Section II.3, at present, derivatives industry participants have established data 

standards for messaging the terms in a confirmation. However, there is no standardized 

electronic language that represents legal agreements. As many commentators have noted, master 

agreements establish the contractual basis for the relationship between counterparties, and are 

crucial tools for valuation and risk management. Because they contain critical information, some 

large financial institutions store data from master and credit support agreements in electronic 

form in their risk management systems.54

As early as 2001, the FpML Institute at ISDA began considering whether and how to represent 

the terms of the master agreement in a shared repository or standard format. Since then, working

groups coordinated by the FpML Institute have also been considering whether and how to 

represent terms of these legal documents electronically, and at least one private company has 

created a proprietary XML-based representation of master and credit support agreements that 

helps clients assess counterparty exposure in their risk management systems.55 But no standardized

language for representing the terms of these agreements has yet emerged from these efforts.

The concepts of a master agreement “library” and portfolio data warehouse were raised at a 

recent CFTC roundtable titled “Public Roundtable to Discuss Swap Data Recordkeeping and 

Reporting Requirements.”56 The focus of the discussion was whether a separate data collection 

infrastructure should be created to collect information from master and credit support agreements

and store them in a portfolio data warehouse. The master agreements include the legal and credit 

terms, and credit support agreements contain the margin terms. Collecting this information

would allow regulators to compare the value of a portfolio with the value of the collateral. Big 

disparities would alert regulators to potential red flags that require further investigation.

However, a significant amount of interpretation is needed when sorting through master and 

credit support agreements. The task of interpreting agreements and systematically representing 

them in a central repository is likely to be expensive. A built-in netting arrangement that deals 

 53 At the CFTC Staff Roundtable on Dodd-Frank data requirements, a representative from JP Morgan stated that it 

has “spent tens of millions of dollars to build systems to take the data . . . in our master agreements and in our 

transaction and data repositories to look at our exposures in different ways” and perform other analysis. CFTC Staff

Roundtable, supra note 14, at 279.

54 Id.

55 One such company is docGenix. DOCGENIX, http://www.docgenix.com/Pages/Home.htm (last visited Mar. 8, 

2011).

56 CFTC Staff Roundtable, supra note 14. The discussion of a master agreement library, or a repository for machine 

readable files containing master agreement contracts, starts on page 326. The discussion of the portfolio data 

warehouse, or a centralized repository for data relating to exposure-related information, starts on 261.
719(b) Feasibility Study

13

with this interpretation issue is currently used in the Basel process.57 Under a process established 

by the Basel Committee on Banking Supervision, regulators rely on the regulated banks to 

analyze the legal documentation, subject to the regulators’ oversight.58 A similar process of 

incorporating the terms of master agreements and credit support agreements into the portfolio 

exposure and then reporting this portfolio data to a portfolio data warehouse may assist in 

facilitating greater market transparency in OTC swaps.

II.5. CREATING MACHINE READABLE, LEGALLY-BINDING 

DOCUMENTS

Currently, parties to OTC derivatives contracts document their legal relationship in written and 

signed documents.59 These documents are often converted to PDF files after signing, but even 

when they are rendered in this format they are not necessarily machine-readable.

After the legal relationship is negotiated and memorialized in master agreements and credit 

support agreements and annexes, for confirmations of individual swap transactions there are 

currently ways to create machine-readable files that become legally binding. Currently, certain 

trades “matched” through a third-party service usually are machine-readable. These matched 

confirmations become legally binding by virtue of agreements with the repository that does the 

matching. For example, counterparties to a credit default swap submit trade acknowledgments to 

a matching service such as MarkitSERV or ICE Link, which sends all matched confirmations to 

the DTCC Trade Information Warehouse, an industry repository for credit default swaps that 

stores the confirmations. Counterparties that use this service have written agreements that a 

trade confirmed by the service and subsequently stored in the warehouse is the primary record 

of the trade over and above any records held by the parties and is legally binding.60 This is 

possible because the economic terms of these transactions are standardized and in machinereadable format (FpML), and the parties have negotiated and signed written master agreements 

with each other, and confirmation agreements with DTCC.61

 57 See, e.g., Basel Committee on Banking Supervision, International Convergence of Capital Measurement and 

Capital Standards Paragraphs 176-77, June 2004, available at http://www.bis.org/publ/bcbs107.pdf (stating a 

calculation for net exposure).

58 CFTC Staff Roundtable, supra note 14, at 296 (stating that banks perform exposure calculations and prudential 

regulators evaluate the data and models used in those calculations).

59 Even when one of the parties or a third party service renders a master agreement in a structured data format, this 

file cannot be legally binding because it has not been agreed to by both parties. See Trade Acknowledgement and 

Verification of Security-Based Swap Transactions, 76 Fed. Reg. 3,859, 3,860 (proposed Jan. 21, 2011) (stating that 

counterparty must sign the document “manually, electronically, or by some other legally equivalent means”).

60 Meeting with Marisol Collazo, Vice President DTCC DerivSERV, Dec. 20, 2010; see also Keeping ‘gold’ trade 

records ‘gold’, DTCC DERIV/SERV (Oct. 9, 2006), available at 

http://www.dtcc.com/products/documentation/derivserv/DerivSERV%20-%20Gold.pdf. 

61 Letter from Stuart J. Kaswell, Managed Funds Association at 4-5 (Dec. 31, 2010), available at 

http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=26825&SearchText=.
719(b) Feasibility Study

14

Under the proposed Trade Acknowledgement and Verification of Security-Based Swap 

Agreements rule that would formalize current practice and seek to improve it, the SEC has 

proposed a regime that would, together with the proposed rules regarding reporting obligations 

to a swap data repository, encourage derivatives market participants to establish electronic 

platforms to capture and transmit for more trades the information necessary to engage in the 

confirmation process in an electronic format.62 The CFTC has proposed a similar regime.63

 62 See Trade Acknowledgement and Verification of Security-Based Swap Transactions, 76 Fed. Reg. 3,859, 3,860 

(proposed Jan. 21, 2011).

63 See Confirmation, Portfolio Reconciliation, and Portfolio Compression Requirements for Swap Dealers and 

Major Swap Participants, 75 Fed. Reg. 81,519 (proposed Dec. 28, 2010), Swap Data Recordkeeping and Reporting 

Requirements, 75 Fed. Reg. 76,574 (proposed Dec. 8, 2010), and Reporting, Recordkeeping, and Daily Trading 

Records Requirements for Swap Dealers and Major Swap Participants, 75 Fed. Reg. 76,666, 76,675 (proposed Dec. 

9, 2010)).
719(b) Feasibility Study

15

III. DATA THAT MAY BECOME AVAILABLE THROUGH ONGOING 

RULEMAKING UNDER THE DODD-FRANK ACT

This section describes the data on swap agreements that may become available to regulators and 

market participants under proposed Dodd-Frank Act regulations promulgated by the 

Commissions. In addition to mandating the Study, the Dodd-Frank Act established new 

requirements for executing, confirming, and reporting data relating to derivatives transactions, 

and defined entities that will be involved in these activities.

64 The Commissions are currently 

considering rules that would increase the data available for computerized analysis of derivatives 

contracts, including calculations of net exposure. For purposes of the Study, regulations relating 

to the storage, distribution, and use of derivatives data facilitated by swap data repositories and 

security-based swap data repositories (collectively referred to as “SDRs”)

65 are of particular 

interest.

III.1. SDR ENHANCEMENT TO MARKET ANALYSIS

SDRs are defined as “centralized recordkeeping facilit[ies] for swaps.”66 The Dodd-Frank Act 

requires that all swap transactions be reported to an SDR, whether they are cleared or 

uncleared.

67 The SDRs, in turn, will disseminate real-time68 information on swaps transactions to 

facilitate price discovery and also will provide other information about swaps transactions to 

regulators.69 The Dodd-Frank Act also requires that SDRs take steps to ensure that the data they 

receive is accurate.

70 The Commissions are proposing regulations to implement the SDR 

provisions of the Dodd-Frank Act.71

III.1.a. REGULATORS WILL HAVE DIRECT, CENTRALIZED ACCESS TO 

DATA

Currently, to obtain information about swap transactions, regulators must request data from 

repositories established by the private sector or from counterparties directly. The Dodd-Frank 

Act significantly changes this regulatory environment by requiring that SDRs register with one 

or both Commissions, depending on the type of instrument, and provide the Commissions with 

“direct electronic access” to data contained in these repositories.72 The Commissions have 

discretion to define “direct electronic access.” The SEC has proposed to interpret this access to 

 64 E.g., Dodd-Frank Act § 721 (adding 7 U.S.C. § 1(a)(50) defining swap execution facilities), § 761 (adding 15 

U.S.C. § 78(c)(a)(75) defining security-based swap data repositories), and (defining security-based swap dealers, 

(a)(71) and major security-based swap participants (a)(67)).

65 For purposes of the Study, SDRs include both swap and security-based swap data repositories.

66 7 U.S.C. § 1(a)(48) (2011), 15 U.S.C. § 78(c)(a)(75) (2011).

67 Dodd-Frank Act § 723(a) (adding 7 U.S.C. § 2(h)), and § 763(a) (adding 15 U.S.C. § 78(c)-(1)(e)).

68 Proposed real-time reporting rules vary between the Commissions.

69 Regulation SBSR – Reporting and Dissemination of Security-Based Swap Information, 75 Fed. Reg. 75,208, 

75,217 (proposed Dec. 2, 2010). See Real-Time Public Reporting of Swap Transaction Data, 75 Fed. Reg. 76,139, 

76,150 (proposed Dec. 7, 2010). 

70 Dodd-Frank Act § 728 (adding 7 U.S.C. § 21) and § 763 (adding 15 U.S.C. § 78(m)(n)(5)(B)) require SDRs to 

“confirm with both counterparties . . . the accuracy of the data that was submitted.”

71 See Security-Based Swap Data Repository Registration, Duties, and Core Principles, 75 Fed. Reg. 77,306, 77,318 

(proposed Dec. 10, 2010); Swap Data Repositories, 75 Fed. Reg. 80,898, 80,80,899 (proposed Dec. 23, 2010).

72 See Dodd-Frank Act § 728 (adding 7 U.S.C. § 21(c)(4)(A)) and § 763(a) (adding 15 U.S.C. § 78(m)(n)(5)(D)).
719(b) Feasibility Study

16

mean, in part, “the ability to query or analyze the data in the same manner that the SDR can 

query or analyze the data.”73 The CFTC’s rule proposal interprets it to mean an “an electronic 

system, platform or framework that provides Internet or web-based access.”74

III.1.b. DATA CAN BE USED TO ANALYZE THE MARKET

The Dodd-Frank Act anticipates that regulators and market participants will use data provided 

by SDRs to analyze the swaps market. Certain swap transaction and pricing data would be 

publicly disseminated in real-time to enhance price discovery. These data would include asset 

class, date and time of execution, notional size and price.75 Other information proposed to be 

required to be submitted to SDRs would help regulators monitor the market for systemic risk, 

but would not be made public.76 This information would include unique legal entity identifiers77

and “data elements necessary to calculate the market value of a transaction.”78

III.2. SDR LIMITATIONS RELATING TO MARKET ANALYSIS

While SDR regulations, if adopted, could result in more machine-readable data becoming 

available than is available at present,79 gaps would likely remain. Three such gaps are discussed 

below, and in Section IV.

 73 See Security-Based Swap Data Repository, 75 Fed. Reg. at 77,318.

74 See Swap Data Repositories, 75 Fed. Reg. 80,898, 80,906 (proposed Dec. 23, 2010).

75 Regulation SBSR – Reporting and Dissemination of Security-Based Swap Information, 75 Fed. Reg. 75,208, 

75,212 (proposed Nov. 19, 2010). The SEC has established a baseline of elements that must be reported in realtime, which includes asset class, date and time of execution, price, and the notional amount of the SBS. The SDR 

must set up policies and procedures that “specify the data elements of a SBS . . . that a reporting party would be 

required to report” and to make these publicly available. Id. Similarly, the CFTC has proposed suggested data 

elements that must be reported in real-time for swaps. Real-Time Public Reporting of Swap Transaction Data, 75 

Fed. Reg. 76,140, 76,176 (proposed Dec. 7, 2010).

76 The SEC’s SBSR release states that this data will “facilitate regulatory oversight and monitoring of the SBS market 

by providing comprehensive information regarding SBS transactions and trading activity.” Regulation SBSR --

Reporting and Dissemination of Security-Based Swap Information, 75 Fed. Reg. at 75,217.

77 Id. Identifiers include counterparties to the transaction and its brokers. The SDR would be required to create a 

unique transaction identifier for every derivatives contract reported to it. Id. at 75,220. Counterparties would be

required to submit information necessary to delineate a participant’s parent and affiliate relationships. Id. at 75,222.

78 Id. at 75,218. The rules proposed by the SEC contemplate that the SDR would determine what data elements are 

necessary for reporting a life cycle event. Id. at 75,220. The CFTC rule contemplates that the CTFC would

determine what data elements are necessary. For this purpose, the CFTC’s proposed rule includes tables of 

minimum required data elements, and also specifies reporting of terms verified or matched by the counterparties, 

and of the terms of confirmation done by the counterparties. Swap Data Recordkeeping and Reporting 

Requirements, 75 Fed. Reg. 76,574, 76,581 (proposed Dec. 8, 2010).

79 At present there appear to be three industry sanctioned repositories for swap trade data, and these are operated by 

the following entities: TriOptima (interest rates), Rates Repository, and TRIOPTIMA.

http://www.trioptima.com/repository.html (last visited Mar. 3, 2011), DTCC (equity), DTCC Launches Equity 

Derivatives Reporting Repository, DTCC,

http://www.dtcc.com/news/press/releases/2010/dtcc_launches_equity.php (last visited Mar. 3, 2011), and DTCC 

(credit), Products and Services, DTCC, 

http://www.dtcc.com/products/derivserv/suite/trade_reporting_repository.php (last visited Mar. 3, 2011).
719(b) Feasibility Study

17

III.2.a. UNIVERSAL, UNIQUE IDENTIFIERS

The Commissions have proposed rules for the use of standard entity identifiers that could be 

applied across all repositories and by all market participants under the Commissions’ 

jurisdictions.80 These identifiers do not currently exist.

Entity identifiers could provide a consistent reference for the counterparties, products, and 

reference entities. As stated in a recent paper on the subject, “[t]he financial crisis . . . 

demonstrated the . . . ‘complexity of interrelationships’ and dependencies that exist between . . . 

counterparties, issuers, guarantors, and the domino effect that can result should one or more of 

[these entities] come under pressure.”81 An identifier consistently applied to a counterparty 

across all of its transactions recorded in an SDR would allow regulators to, among other things, 

“aggregat[e] and monitor[ ] . . . the positions of [swap] counterparties, which could be of 

significant benefit for systemic risk management.”82 The same benefit would appear to also apply 

to product and instrument identification, particularly for more standard products. Universal data 

standards also would avoid the translation and data mapping that would be needed if different 

data standards emerged.

III.2.b. GENERAL CONTRACTUAL OBLIGATIONS 

Rules proposed by the Commissions would require the reporting of the economic terms of a 

transaction such as the counterparties, notional amount, and reference entity, but would not 

require the reporting of all of the terms of the governing documents.

83 Credit support, 

termination and default, and other provisions from master agreements that affect multiple trades 

are not proposed to be reported. As a result, regulators would not have direct access to 

information contained in those provisions in a central location. Having these documents in a 

machine-readable format could, among other things, facilitate analysis of how market events that 

trigger conditions in these legal documents would change the value of a derivative, and also a 

counterparty’s leverage and net exposure.84

 80 Regulation SBSR - Reporting and Dissemination of Security-Based Swap Information, 75 Fed. Reg. 75,208, 

75,218 (proposed Dec. 2, 2010) (stating that SDRs must assign each entity a “unique identification code” provided 

by an “internationally recognized standards-setting body” if such a code exists). Swap Data Recordkeeping and 

Reporting Requirements, 75 Fed. Reg. at 76,602. 

81 See John Bottega & Linda Powell, Creating a Linchpin for Financial Data: The Need for a Legal Entity 

Identifier, at 3 (Dec. 10, 2010) (unpublished manuscript), available at http://ssrn.com/abstract=1723298.

82 Regulation SBSR, 75 Fed. Reg. at 75,217. 

83 E.g., Swap Data Recordkeeping and Reporting Requirements, 75 Fed. Reg. at 76,605. This proposed rulemaking 

requests comment on whether a “collateral warehouse system” or a “master agreement library” should be created.

Id. at 76,586. Trade Acknowledgment and Verification of Securities-Based Swap Transactions, 76 Fed. Reg. 3,859, 

3,864 (proposed Jan. 21, 2011). 

84 One response to the Study’s request for comment stated the following:

Typically derivatives transactions exist within a framework of agreements between the firms. A single transaction 

may be a represented as a transaction supplement within a master confirmation which contains standard terms for 

that type of transaction, and that operates within a master agreement that covers various contingencies such as 

credit issues and extraordinary events. This transaction supplement is legally binding but references other materials. 

To provide a complete standalone economic description of the transaction would require a “long form” 

representation of the transaction, which includes both the standard economic terms (found in the master 

confirmation) and the variable terms for the individual transactions (found in the transaction supplement). 

Letter from ISDA and SIFMA, supra note 11, at 12-13.
719(b) Feasibility Study

18

III.2.c. CONSISTENCY ACROSS ALL REPOSITORIES

As this Study has noted, there exists no single standard for describing in machine-readable 

format all aspects of all derivatives transactions and, as a result, it may not be possible to achieve 

consistency of data standards across all SDRs. The SEC’s proposed rules allow for, but would 

not mandate, the use of a single standard across multiple repositories for reporting derivatives 

information.

85 The proposed CFTC regulations would require an SDR to maintain all swap data 

reported to it, and to report such data to the CFTC, in a format acceptable by the CFTC. The 

proposed CFTC regulations would require reporting entities and counterparties to use the 

facilities, methods, or data standards provided or required by an SDR to which they report data, 

but also would allow an SDR to permit reporting via various facilities, methods, or data 

standards, provided that its requirements in this regard enable it to maintain swap data and 

transmit it to the CFTC as the CFTC requires.86

 85 E.g., Regulation SBSR - Reporting and Dissemination of Security-Based Swap Information, 75 Fed. Reg. 75,208, 

75,222-23 (proposed Dec. 2, 2010). Proposed Regulation SBSR would require each data repository to specify one or 

more data formats (each of which must be an open-source structured data format that is widely used by 

participants), connectivity requirements, and other protocols for sharing information. The format or formats 

selected by one SDR need not be shared by other SDRs. The SEC preliminarily determined not to dictate a uniform 

data standard for use across all SDRs, recognizing that technology and industry conventions may evolve over time 

to produce improved data standards. The SEC did note that it believed that FpML would be an appropriate format 

for data reporting.

86 Swap Data Recordkeeping and Reporting Requirements, 75 Fed. Reg. at 76,594.
719(b) Feasibility Study

19

IV. SIGNIFICANT ISSUES AND CHALLENGES

Based on this Study, the staff believes that it is too soon to require using a standardized, agreedupon description for all derivatives. Before such a requirement could be imposed, three issues 

should be resolved: the absence of a universal entity and product identifiers, the need for further 

analysis of the costs and benefits of electronic representation of all aspects of legal documents, 

and the lack of standard reference data for financial terms not covered by existing definitions.

IV.1. THE ABSENCE OF UNIVERSAL ENTITY AND PRODUCT

IDENTIFIERS

Many in the financial sector have come to recognize the need for universal, accurate, and trusted 

methods of identifying particular financial transactions, the legal entities that are parties to 

financial transactions, the underlying corporate entity referenced in a particular financial 

transaction, and the product type involved in particular financial transactions.87 Legal entity 

identifiers (“LEI”), unique counterparty identifiers (“UCI”), and product identifiers could be 

crucial tools for financial regulators tasked with measuring and monitoring systemic risk, 

preventing fraud and market manipulation, conducting market and trade practice surveillance, 

enforcing position limits, and exercising resolution authority.88 Such identifiers also could have 

great benefits for financial transaction processing, internal recordkeeping, compliance, due 

diligence, and risk management by financial entities. Consequently, technology to represent 

derivatives may need to incorporate a unique counterparty identifier and corporate hierarchy

information (such as immediate or ultimate parent). As a member of the Board of Governors of 

the Federal Reserve System said recently:

Clearly, the [recent financial] crisis exposed the need for a regulatory mechanism that will 

provide real time analysis across multiple financial markets to identify systemic risk and 

stresses in market conditions before they occur. A unique entity identifier for data sharing 

and use in data collections between the federal financial regulatory agencies is the critical 

missing component for this analysis.89

Information concerning a counterparty’s affiliations and corporate hierarchies must be available 

in conjunction with LEI/UCIs. This could enhance regulators’ abilities to aggregate data across 

entities and markets and also facilitate monitoring systemic risk. To better help them assess 

systemic risk, regulators need to be able to identify all swap positions within the same ownership 

group. Thus, “corporate affiliations” would mean the identity of all legal entities that own or are 

owned by the counterparty, or that are under common ownership with the counterparty. 

A consistent way to identify products across SDRs, asset classes, and jurisdictions also is needed.

There are a number of vendor-supplied identifiers90 currently available to regulators and market 

 87 See CFTC Staff Roundtable, supra note 14, at 1-261.

88 Bottega and Powell, supra note 81.

89 Swap Data Recordkeeping and Reporting Requirements, 75 Fed. Reg. at 76,589 (quoting Daniel K. Tarullo, 

Member, Board of Governors of the Federal Reserve System, Equipping Financial Regulators With the Tools 

Necessary to Monitor Systemic Risk, before the Subcommittee on Security and International Trade and Finance, 

Committee on Banking, Housing, and Urban Affairs, U.S. Senate, Washington, DC, Feb. 12, 2010).

90 For example, Markit has created a regime of reference entity identifiers, called the RED code, and Standard &

Poors operates the CUSIP system. Market participants can use these identifiers in credit default swaps. Meeting with 

Brian Okupski, Markit, Feb. 23, 2011.
719(b) Feasibility Study

20

participants at a cost. These identifiers can be reliable and critical to well functioning markets

and would be more useful if they were available without limitation to regulators and market 

participants needing to follow transactions and associate instruments and products to entities.

Regulations proposed by the SEC contemplate the possibility that universal identifiers may 

become available in the future. If and when they are, SDRs may require reporting parties to use 

these identifiers in their reports. Similar regulations proposed by the CFTC would impose the 

requirement to use UCIs if they are available sufficiently prior to the implementation date for the 

CFTC’s final swap data reporting regulations.91 We discuss the current state of market 

development of LEI/UCIs in our conclusion below.

IV.2. DESCRIBING CONTRACTUAL TERMS IN A MACHINE-READABLE

FORMAT

As noted above, market participants have suggested that there may be benefits to representing 

already standard legal documents in an electronic format. However, currently there appears to be

a lack of industry consensus on whether the benefits would outweigh the costs. As one 

commenter opined: “there are benefits because using computer readable descriptions creates an 

environment that is less susceptible to operational errors, decreases the total cost of ownership 

and helps to bring transparency and efficiency to the system.”92

Indeed, many firms are already representing parts of their contractual agreements in machinereadable format to help them understand counterparty risk and calculate net exposure, but they 

use proprietary representations that vary from the standards used by other firms. This may speed 

analysis in termination event situations, but it continues a “Tower of Babel” problem where risk 

systems cannot communicate without “manual reconciliation and transformation processing.”93

ISDA has been exploring using FpML to represent its master and credit support agreements, 

and at least one company has developed a proprietary technology that electronically represents 

master and credit support agreements.94

As stated above, essential information needed to calculate net exposures is found in master 

agreements and other legal documents, including when collateral must be transferred or 

increased; what constitutes a default or credit event; and what otherwise triggers changes in the 

relationship between the parties. Even something as simple as having the names of all parties 

and referenced entities identified in an agreement is useful for understanding the net exposure of 

trades or risks to markets. Yet detailed analysis of lengthy legal agreements in paper format, and 

how they interact with individual transactions, is time consuming and potentially inefficient.

95

Some participants in the OTC derivatives markets have indicated that they are working to 

improve their internal risk management systems, including analysis of their net derivatives 

 91 Swap Data Recordkeeping and Reporting Requirements, 75 Fed. Reg. at 76,591.

92 Letter from BM&F Bovespa, supra note 40, at 7. 

93 Letter from Michael Atkin, supra note 38, at 2. 

94 DocGenix, for one, is developing an XML language for describing all terms of swap contract, master agreements 

and trades. Meeting with Michael Will, docGenix, Conf. Call (Jan. 20, 2010).

95 As a Deutsche Bank Research report observed, when AIG, a major dealer in Credit Default Swaps failed, “market 

reactions were heavy, owing to the fuzziness of information on actual credit exposures in a market where trading 

takes place over-the-counter.” Deutsche Bank Research, Credit Default Swaps: Heading towards a more stable 

system, at 3 (Dec. 21, 2009), available at http://www.dbresearch.com/PROD/DBR_INTERNET_ENPROD/PROD0000000000252032.pdf.
719(b) Feasibility Study

21

exposures. As part of these efforts, proprietary and commercial systems are being developed that 

would render the key legal documents, such as the ISDA master agreement and credit support 

agreement, in machine-readable format.96

However, one commenter observed that the desirability of making computer-readable 

descriptions legally binding hinges on the accuracy of the legal description and the degree of 

confidence that market participants have in them.97 Another commenter expressed skepticism 

about whether legal aspects of all OTC trades could be represented through legally-binding 

computer readable descriptions.98 This commenter reasoned that paper confirmations are 

needed for complex transactions because “electronic platforms and their common terms and 

algorithms cannot account for bespoke terms. Critical terms to a customized trade [include] 

tailored additional termination events, embedded optionality, or allocation of legal rights in 

respect of a referenced security. These bespoke terms necessarily must be memorialized in a 

paper confirmation.”99

At the CFTC’s recent roundtable, discussed above, participants supported the establishment of 

an SDR for exposure and credit support information,100 but said that an SDR for master 

agreements may be unworkable due to variation and cost. Participants at this roundtable 

generally agreed that regulators need access to more swap agreement data than what is provided 

by trade reporting.101 However, at least one commenter expressed concern that building the 

systems needed to store and analyze the data may take more time and money than regulators 

anticipate.102

 96 As stated above in footnote 91, docGenix, is marketing a service to render master agreements, credit support 

agreements, and other documents in an XML format. Meeting with Michael Will, docGenix, Conf. Call (Jan. 20, 

2010), docGenix Overview, DOCGENIX, http://www.docgenix.com/Pages/Topic_docGenixOverview.htm (last 

visited Mar. 8, 2011). JP Morgan has its own proprietary systems in place for storing and analyzing such data. CFTC 

Staff Roundtable, supra note 14 at 264.

97 Letter from CETIP, supra note 40, at 7.

98 Letter from Stuart J. Kaswell, supra note 61, at 4.

99 Id. at 5.

100 E.g., CFTC Staff Roundtable, supra note 14, at 264. A TriOptima representative stated that their repository 

provides an “exposure management service” for facilitating the “move[ment] and settle[ment of] the collateral.” 

101 Id. at 267-279. But some may not agree on whether regulators should have direct access without request. Id. at 

273 (an ISDA representative stated that prudential regulators should require the keeping of master agreement-level

data but not reporting of such data until its need is determined).

102 Id. at 279-80. According to a JP Morgan representative, it has “taken [JP Morgan] years to build the 

infrastructure . . . to manipulate this data and use it effectively in [its] risk management regime.”
719(b) Feasibility Study

22

These comments suggest to the staff that there is continued disagreement about whether 

regulators should mandate that legal documents underpinning derivatives transactions be 

represented in a computer-readable format, and if so, the pace at which this change should 

occur.103

IV.3. LACK OF COMMON INDUSTRY-WIDE REPRESENTATION OF 

REFERENCE DATA

“[F]acilitat[ing] computerized analysis of individual derivative contracts” and “calculat[ing] net 

exposures to complex derivatives”104 across all markets and counterparties, requires, in the staff’s 

view, consistent and comparable reference data for all derivatives, not just the standardized 

contracts currently represented in machine-readable format. This includes data that describes the 

attributes and cash flows of derivative contracts, regardless of whether the instrument is 

standardized, and whether key terms are detailed in a lengthy legal document.105 While some 

firms already have data standards and semantic representations for non-standard derivative 

contracts, not all do, and there is no universally accepted set of standards that would enable 

regulators or others to calculate net exposures on a system-wide basis.

Due to the lack of industry standards for reference data and instrument descriptions, when 

capturing and storing derivatives position information internally, many firms rely on proprietary 

data models and databases.106 This approach, which was born of necessity, is less of a problem 

for individual firms than it may be for regulators that need to analyze cross-market or system-wide 

risks.

Industry consensus or regulatory mandate could respond to this problem by shaping new 

standards for reporting data to SDRs, including non-standard agreements, contractual terms and 

conditions, entity and instrument identification, and hierarchies. Such standards could be a 

critical component of the data infrastructure that regulators need to quickly and accurately 

analyze systemic risk and conduct market surveillance. The unique identification of market 

participants, and the comparability of position data from the various repositories, are essential to 

prudential risk management and market oversight.

 103 Creating documents containing computerized descriptions of master agreements and other provisions of swap 

transactions may be more challenging than making these documents in electronic format legally binding. As stated 

above, in order for a document containing contract terms to be legally binding, it must be agreed to by both parties.

The current practice for matching the terms of credit default swap trade acknowledgments shows that the process 

for obtaining an agreed upon document can be automated. Where a data standard exists for making documents 

machine readable, such as FpML for credit default swap trade confirmations, matching services are able to compare 

versions submitted by counterparties and the matched copy can become legally binding. If similar data standards 

were created for master agreements and other documents, then these should be able to be confirmed in a similar 

manner.

104 Section 719(b) of the Dodd-Frank Act.

105 See letter from Michael Atkin, supra note 38, at 1-2. 

106 Id. at 2. European financial firms are burdened by the same problem. See Francis Gross, Directorate General 

Statistics, European Central Bank, Paper Presented to the IFC Conference on Initiatives to Address Gaps Revealed 

by the Financial Crisis, Microdata As Necessary Infrastructure at 3 (Aug. 24, 2010), available at

http://www.bis.org/ifc/events/5ifcconf/gross.pdf. (stating that European regulators attempt to create a 

“Centralised Securities Database” has been hindered by “diversity in data formats, taxonomies and definitions”).
719(b) Feasibility Study

23

V. CONCLUSIONS

The representation of all aspects of all financial derivatives in a computer-readable language is 

technically feasible, although it may be difficult to do so for non-standard derivatives products as 

a practical matter. Regardless of whether terms are standardized, technology exists to make the 

terms machine-readable, and thus it is feasible, in a technological sense, to algorithmically 

describe derivatives.

Furthermore, not only is it feasible to represent these instruments in machine-readable format, 

many already are represented this way. The economic terms of significant portions of the 

derivatives marketplace are messaged electronically in FpML or FIX. In those cases where 

derivatives are currently described electronically, these electronic messages, together with certain 

written documents, form the basis of legally-binding agreements. Moreover, market participants 

often are able to take the data from these messages and use it in computer-modeling programs 

that analyze net exposure calculations.

Despite the fact that it is technically feasible to represent derivatives contracts in machinereadable format, before requiring standardized, agreed-upon computer descriptions for all 

derivatives, three issues need to be resolved: (i) the absence of a universal entity identifier and 

product identifiers; (ii) the need for further analysis of the costs and benefits of electronic 

representation of all aspects of legal documents; and (iii) the lack of standard reference data for 

financial terms not covered by existing definitions.

With regard to the question of whether it is feasible to mandate electronic representations of 

derivatives in order to make them legally binding, the Study concludes that this would be 

possible if all material aspects of derivatives contracts were represented in machine-readable 

format. Specifically, an agreement rendered in a structured data file could be legally binding 

upon the parties provided they both agreed to it.107 Whether this would benefit participants in 

the swaps market is a separate question that, together with the question of the costs imposed by 

such a regime, necessitates further analysis, including input from those participating in these 

markets. As regulators, we can see benefits to participants such as ensuring the quality of the 

data, but it is less clear that others would see a benefit.

To resolve the above-identified three issues, the staff believe that collaborative public-private 

initiatives with other financial regulators and the derivatives industry would be useful. In essence, 

rather than mandating the adoption of a particular solution, the staff would identify broad 

requirements for implementation, and the industry would agree on solutions that meet these 

requirements. 

 107 Legal questions around the need for an actual paper copy of the agreement or a signature on some document, as 

occurs currently with respect to master agreements and confirmation agreements with the DTCC Trade 

Information Warehouse, would require further analysis.
719(b) Feasibility Study

24

V.1. STANDARDIZING ENTITY AND PRODUCT IDENTIFIERS

Work on developing standard entity identifiers is already underway. In the Fall of 2010, the 

Commissions proposed rules that would regulate SDRs as well as reporting to SDRs and require 

those repositories to use a standard entity identifier (described as a unique counterparty identifier 

in CFTC rulemaking),108 developed by a voluntary standard-setting body, if one is available.109

These rules were published around the same time that the U.S. Treasury’s Office of Financial 

Research published a policy statement calling on industry to work together with regulators to 

develop standard entity identifiers.

110 And in December of 2010, staff members from U.S. 

financial regulatory agencies published “Creating a Linchpin for Financial Data: The Need for a 

Legal Entity Identifier,” (“the Linchpin paper”) which called for an international standard setting 

process to develop a reliable universal entity identifier.111

It is too early to tell whether this process will develop an LEI/UCI that satisfies the needs of 

industry and domestic and foreign regulators. Staff representing U.S. regulators involved in the 

development of the Linchpin paper continue to engage industry members on this topic, and the 

financial industry is developing a process that may reasonably soon produce a single identifier 

for each participant in our markets.112

If successful, the LEI/UCI would include freely and publicly available attribute information –

reference data about the LEI/UCI that provides context and meaning. Included as an attribute –

or in some other dataset that uses the LEI/UCI to connect entities to one another – would be 

hierarchical information. At a minimum, the marketplace would be served by current 

information identifying each entity, their immediate parent, and their ultimate parent.

Additionally, market participants and regulators should be able to link this information to 

instrument or product identification information.

With respect to creating a reliable and universal way to identify products and instruments across 

different datasets, firms, and markets, a public-private partnership like that unfolding for the 

LEI/UCI may be appropriate. As the authors of the Linchpin paper noted, while the 

development of an LEI/UCI is an appropriate first step, the development of product and 

instrument identifiers also is critical to understanding markets.113 As with an LEI/UCI, the 

product or instrument identification would need to be universal across international markets, 

reliable (persistent, unique and current), and freely available to regulators and investors. In the 

coming months, the staff of the Commissions will continue to monitor developments in the 

industry development of an LEI/UCI, and will evaluate, with input from other regulators and 

industry, approaches to establishing universal product or instrument identifiers.

 108 Swap Data Recordkeeping and Reporting Requirements, 75 Fed. Reg. 76,574, 76,589 (Dec. 8, 2010).

109 Id. at 76,590. See also Regulation SBSR – Reporting and Dissemination of Security-Based Swap Information, 75 

Fed. Reg. 75,208, 75,217-18 (proposed Dec. 2, 2011).

110 OFFICE OF FINANCIAL RESEARCH; STATEMENT ON LEGAL ENTITY IDENTIFICATION FOR FINANCIAL 

CONTRACTS (Nov. 30, 2010), available at http://www.federalregister.gov/articles/2010/11/30/2010-

30018/office-of-financial-research-statement-on-legal-entity-identification-for-financial-contracts. 

111 Bottega and Powell, supra note 81.

112 CFTC Staff Roundtable, supra note 14. Panels 1-5 discussed identifier issues. At this event, representatives from 

industry groups, vendors, data managers, and entity and instrument registration authorities unanimously agreed that 

a single identifier is critical. They appear to be working toward a consensus process for the development and 

maintenance of a universal entity identifier.

113 Bottega and Powell, supra note 81.
719(b) Feasibility Study

25

V.2. POSSIBLE FURTHER USE OF COMPUTER READABLE 

REPRESENTATIONS FOR LEGAL DOCUMENTS

Master agreement documents might benefit from electronic representation in at least two areas.

First, a standardized electronic representation of key quantitative terms embedded in these 

agreements would aid in tasks such as calculating exposures to various events. For example, if a 

credit support agreement required the addition of collateral in the event of a credit downgrade to 

a specified level, an electronic representation of this term could be included in a model that 

would provide for risk analysis or event notification. Thus, electronic representation of collateral 

terms in credit support agreements could be helpful. Credit support terms are routinely 

contained in a credit support agreement between market participants. Terms that would appear 

to benefit from electronic representation include: calculation methodology for initial margin; 

amount of any credit threshold; amount of any minimum transfer amount; rounding convention; 

forms of eligible collateral; collateral valuation haircuts; timing of collateral demand; timing of 

collateral delivery; and amount of collateral already held. This could assist counterparties, and 

could also, in certain circumstances, serve regulators seeking to understand the effects of such 

events as deterioration of ratings of systemically important institutions.

Second, even block tagging114 written provisions of these agreements could help managers, 

auditors, lawyers, and regulators more quickly understand the implications of various market 

events, particularly in a crisis. Thus, an electronic representation of master agreement provisions 

could provide attorneys seeking to unwind relationships with failing institutions with important 

tools such as the ability to quickly extract important clauses from different agreements with the 

same counterparty.

Given the work to date in representing these legal documents in standard computer-readable 

languages, it may be possible, without great burden and with significant benefit, to tag 

appropriate sections of these agreements in the near term. Published standard legal clauses are 

available for tagging, and industry and vendor efforts can continue to develop an electronic 

representation of those clauses most useful for determining net exposures.

The staff intend to monitor the progress of this work and participate as appropriate, 

coordinating our efforts with other financial regulatory agencies. We anticipate that the Office of 

Financial Research will be actively involved in working with industry to evaluate the benefits and 

costs of representing and collecting this data relating to exposures and risks given its 

responsibilities to develop certain data repositories. We encourage market participants to help 

our efforts by actively engaging efforts to analyze the propriety of tagging legal documents, and 

we welcome their input.115

V.3. REPRESENTATION OF REFERENCE DATA

The final, and perhaps most difficult, area to resolve is the creation and maintenance of standard 

definitions for financial data and contractual terms, along with a standardized language for 

 114 “Block tagging” is defined as tagging an “entire footnote, or other discrete item” of text as one individual 

element. Interactive Data to Improve Financial Reporting, 74 Fed. Reg. 6,776, 6,786 n. 134 (Feb. 10, 2009). 

115 As more aspects of derivatives contracts become machine readable, regulators and market participants should 

explore whether documents containing machine-readable terms can become legally binding. As stated previously, 

the technology required to accomplish this may be costly and it may not be feasible to do this for some time. Credit 

support agreements may be a next step for expanding the scope of machine readable, legally binding derivatives 

contracts. If information in these agreements can be rendered in a format for analysis, then it may be possible to 

implement standards for matching these agreements.
719(b) Feasibility Study

26

composing these terms, so that any new contract could be described electronically. One 

commenter described working with others to build a “semantic repository” that could house

those standard definitions and relationships among them.116 This semantic repository does not 

use a language like FpML that defines the detailed syntax of specific documents and messages; 

instead, it uses Web Ontology Language that has multiple layers of definitions, potentially 

supporting a greater variety of applications. Another market participant proposed a way to break 

all financial contracts down into their most basic form, develop a programming language (or use 

an existing one) that represents these basic clauses and terms, and then build even the most 

complicated contract according to this language.117 Other efforts in this area also are underway.118

As consideration is given to some sort of reference data standard or universal data utility, a key 

challenge will be establishing a governance structure for the maintenance of the standard or for 

the utility that is fair and efficient and that does not stifle innovation. Such a structure should 

also reflect an acceptable business model that is sustainable and not unduly burdensome. 

We recognize that change is not without cost. Thus, the staff have determined that, while 

feasible, further consideration is needed to determine whether to require use of technology that 

fully represents all aspects of all derivatives transactions. While one Study commenter expressed 

optimism and explained that technological change requires a transition period, during which 

companies have to run both “new” and “old” systems,119 another commenter was pessimistic on 

the prospect of immediate progress, and cautioned against prescribing a specific technology for 

the financial derivatives market.120 In this commenter’s view, “[c]omplex derivatives and 

customized derivatives do not currently lend themselves to the use of algorithms or standardized 

computer readable descriptions.”121 The commenter reasoned that OTC derivative participants 

can “use more sophisticated proprietary algorithmic valuation models to value complex 

derivatives that have multiple factors driving their value” and that “[i]n general, the more 

complex a derivative might be, the more difficult it is to arrive at a market standard algorithmic 

valuation model that can be used by counterparties to reach a common valuation.”122

We recognize that, as one commenter stated, to “encourage standardization in markets without 

hindering market efficiency,” a key role for regulators “is that of a facilitator.”123 At a minimum, 

an ongoing dialogue about how best to move the markets in the proper direction is essential,

which is why a public-private initiative would go far in further answering the questions that gave 

rise to the Study.

 116 Letter from Michael Atkin, supra note 36, at 3.

117 Meeting with Harvey Stein and Adam Litke, Bloomberg, Conf. Call (Dec. 13, 2010. See also How to Write a 

Financial Contract, Peyton Jones, S.L. and Eber, J-M. (unpublished paper, 2001), 

http://research.microsoft.com/en-us/um/people/simonpj/papers/financial-contracts/pj.eber.ps (last visited 

March 14, 2011).

118 Francis Gross, Microdata As Necessary Infrastructure at 9, supra note 106.

119 Letters from David N. Gertler, supra note 39, at 9; and BM&F Bovespa, supra note 40, at 6.

120 “[T]he ultimate manner in which uniform computer readable description standards are adopted and the timing of 

such adoption should be left to the market.” Letter from Stuart J. Kaswell, supra note 61, at 4. 

121 Id. at 2.

122 Id.

123 Id.