Draft Technical Specifications for Certain 

Swap Data Elements

A REQUEST FOR COMMENT BY STAFF 

OF THE U.S. COMMODITY FUTURES TRADING COMMISSION 

December 22, 2015 

DISCLAIMER

This is a request for comment by staff of the U.S. Commodity Futures Trading 

Commission. Any views expressed in this request for comment are only the views of 

staff, and do not necessarily represent the positions or views of any Commissioner or 

the Commission.
i 

TABLE OF CONTENTS

I. Summary ............................................................................................................................... 1

II. Introduction .......................................................................................................................... 1

III. Request for Comment .......................................................................................................... 7

IV. Issues and Questions ........................................................................................................... 10

A. Counterparty-Related Data Elements ........................................................................ 10

B. Product ....................................................................................................................... 14

C. Price ........................................................................................................................... 17

D. Notional Amount ....................................................................................................... 19

E. Additional Fixed Payments ....................................................................................... 20

F. Options ...................................................................................................................... 21

G. Orders ........................................................................................................................ 23

H. Package Transactions ................................................................................................ 26

I. Clearing ..................................................................................................................... 27

J. Periodic Reporting ..................................................................................................... 30

K. Events ........................................................................................................................ 36

L. Rates .......................................................................................................................... 45

M. Foreign Exchange ...................................................................................................... 47

N. Other Data Elements ................................................................................................. 48

O. General Questions ..................................................................................................... 50

Appendix—Draft Technical Specifications for Certain Swap Data Elements .................... A-1
1 

I. Summary

Commission staff (“Staff”) today requests comment on draft technical specifications – 

including descriptions, allowable values and formats – for certain swap data elements that are 

reportable under part 45 and related provisions of the Commodity Futures Trading Commission’s 

(“Commission” or “CFTC”) regulations. Staff is also requesting comment on draft technical 

specifications for certain swap data elements that are not currently reportable under the 

Commission’s regulations, but which have been identified by Staff as data elements that – when 

reported in a consistent and clear manner – may assist the Commission in fulfilling its regulatory 

mandates, including systemic risk mitigation, market monitoring and market abuse prevention. 

Staff notes that the inclusion or exclusion in this request for comment (“Request for Comment”) 

of technical specifications for any particular data element, in no way modifies or affects existing 

reporting and recordkeeping obligations under the swap data reporting rules. 

II. Introduction

Title VII of the Dodd-Frank Wall Street Reform and Consumer Protection Act (the 

“Dodd-Frank Act”)1 amended the Commodity Exchange Act (“CEA”) to establish a 

comprehensive new regulatory framework for swaps. As relevant here, amendments to the CEA 

included the addition of provisions requiring the retention and reporting of data regarding swap 

transactions, including provisions designed to enhance transparency, promote standardization, 

and reduce systemic risk. Section 727 of the Dodd-Frank Act added to the CEA new section 

2(a)(13), which establishes requirements for the real-time reporting and public availability of 

swap transaction data, and requires all swaps, whether cleared or uncleared, to be reported to 

registered swap data repositories (“SDRs”). Sections 723 and 729 of the Dodd-Frank Act added 

 

1 Pub. L. 111-203, 124 Stat. 1376 (2010).
2 

to the CEA, respectively, sections 2(h)(5) and 4r, which, among other things, establish reporting 

requirements for swaps in effect as of the enactment of the Dodd-Frank Act, as well as swaps 

entered into after such enactment but prior to the effective date for compliance with final swap 

data recordkeeping and reporting rules prescribed by the Commission. 

Section 728 of the Dodd-Frank Act added to the CEA new section 21, which established 

SDRs as a new category of registered entity to collect and maintain swap data as prescribed by 

the Commission, and, as prescribed by the statute, to facilitate access to such data by regulators.2

In addition, CEA section 21(b) directs the Commission to prescribe standards for swap data 

recordkeeping and reporting.3 These standards are to apply to both registered entities and certain 

swap counterparties.4 CEA section 21(b) further directs the Commission to prescribe data 

standards for SDRs5

 and mandates that such standards be comparable to those for derivatives 

clearing organizations.6 CEA section 21(c)(3) provides that, once the data elements prescribed 

by the Commission are reported to an SDR, the SDR shall “maintain the data [prescribed by the 

Commission for each swap] in such form, in such manner, and for such period as may be 

required by the Commission.”7

 

2 Regulations governing core principles and registration requirements for, and the duties of, SDRs are set forth in 

part 49 of the Commission’s regulations (“SDR Rules”). See also Swap Data Repositories: Registration Standards, 

Duties and Core Principles, 76 FR 54538, Sept. 1, 2011.

3 CEA section 21(b)(1)(A), 7 U.S.C. 24a(b)(1)(A), provides that “the Commission shall prescribe standards that 

specify the data elements for each swap that shall be collected and maintained by each registered swap data 

repository.”

4 CEA section 21(b)(1)(B), 7 U.S.C. 24a(b)(1)(B), provides that “in carrying out [the duty to prescribe data element 

standards], the Commission shall prescribe consistent data element standards applicable to registered entities and 

reporting counterparties.”

5 CEA section 21(b)(2), 7 U.S.C. 24a(b)(2), provides that “the Commission shall prescribe data collection and data 

maintenance standards for swap data repositories.”

6 CEA section 21(b)(3), 7 U.S.C. 24a(b)(3), provides that “the [data] standards prescribed by the Commission under 

this subsection shall be comparable to the data standards imposed by the Commission on derivatives clearing 

organizations in connection with their clearing of swaps.”

7 7 U.S.C. 24(a)(c)(3).
3

After extensive consultation, opportunity for public comment, consideration of comments 

received and coordination with foreign and domestic regulators, the Commission adopted several 

new regulations addressing swap data reporting and recordkeeping. Part 438 sets forth rules for 

the real-time public reporting of swap transaction data. Part 459 establishes swap data 

recordkeeping rules, as well as rules for the reporting of swap transaction data to a registered 

SDR. Part 4610 sets forth swap data recordkeeping and reporting rules for pre-enactment swaps11

and transition swaps12 (collectively, “historical swaps”).13 Part 49 enumerates rules applicable to 

SDRs as such (the “SDR Rules”).14 Collectively, these provisions provide the public and market 

participants with an unprecedented level of transparency into swaps markets, create rigorous 

recordkeeping and data reporting regimes with respect to swaps, and enable Commission 

oversight of swap markets and market participants.

Swap counterparties, including those that are required to be registered with the 

Commission as swap dealers (“SD”) or as major swap participants (“MSP”), have swap data 

reporting obligations under parts 43, 45 and 46 (collectively, the “swap data reporting rules”). 

The swap data reporting rules also place reporting obligations on derivatives clearing 

 8 Real-Time Public Reporting of Swap Transaction Data, 77 FR 1182, Jan. 9, 2012 (“RTR Adopting Release”).

9 Swap Data Recordkeeping and Reporting Requirements, 77 FR 2136, Jan. 13, 2012.

10 Swap Data Recordkeeping and Reporting Requirements: Pre-Enactment and Transition Swaps, 77 FR 35200 

(June 12, 2012) (“Historical Swap Reporting Rule”).

11 A “pre-enactment swap” is a swap entered into prior to the enactment of the Dodd-Frank Act (July 21, 2010), the 

terms of which have not expired as of the date of enactment of the Dodd-Frank Act. See Historical Swap Reporting 

Rule at 35226.

12 A “transition swap” is a swap entered into on or after the enactment of the Dodd-Frank Act (July 21, 2010), and 

prior to the applicable compliance date for reporting historical swaps data pursuant to part 46 of the Commission’s 

regulations. See Historical Swap Reporting Rule at 35227.

13 See also part 44 of the Commission’s regulations (Interim Final Rule for Reporting Pre-Enactment Swap 

Transactions, 75 FR 63080, Oct. 14, 2010; and Reporting Certain Post-Enactment Swap Transactions, 75 FR 78892, 

Dec. 17, 2010), which established certain record retention requirements for historical swaps, pending the adoption of 

the Commission’s final rules, set forth at part 46, regarding recordkeeping and reporting with respect to historical 

swaps.

14 See SDR Rules, supra note 2.
4

organizations (“DCOs”) that clear swaps; designated contract markets (“DCMs”) that list swaps 

for trading; and swap execution facilities (“SEFs”). At present there are over 150 potential 

Reporting Entities registered15 with the Commission, each of which has its own business and 

data standards for listing, executing or clearing swaps in one or more of the five asset classes 

recognized for the purposes of the swap data reporting rules—interest rates, credit, equity, 

foreign exchange, and other commodity. In addition, swaps data may currently be reported to 

any registered SDR, each of which also has its own data standards, which has resulted in 

variation in how each SDR reports swap data to the Commission. The different interpretations 

and practices by SDRs and Reporting Entities have resulted in varying business and data 

standards and for reporting and created inconsistencies in swaps data transmitted to the 

Commission.

On January 21, 2014, the Commission announced the formation of an interdivisional staff 

working group (“Working Group”)16 to review the Commission’s part 45 swap data reporting 

rules, and related provisions of the Commission’s regulations.17 Among other objectives, the 

Working Group was asked by the Commission to identify and make recommendations to resolve 

 15 For purposes of this Request for Comment, the Staff uses the term “Reporting Entity” to refer to any person, 

registrant or non-registrant that has an obligation to report swap data pursuant to part 45 of the Commission’s 

regulations, including SDs, MSPs, unregistered swap counterparties, SEFs, DCMs, and DCOs. The Staff is also 

interested in receiving responses from persons that are complying with part 45 reporting requirements pursuant 

to the terms and conditions set forth in staff no-action relief. Staff no-action letters are available at 

http://www.cftc.gov/LawRegulation/DoddFrankAct/CurrentlyEffectiveStaffLetters/index.htm.

The list of entities with reporting obligations includes Reporting Entities fully registered with the Commission 

and entities that have received provisional registration and/or temporary registration. Specifically, as of December 7, 

2015, it includes 104 SDs; 22 SEFs; 15 DCMs; 15 DCOs; and two MSPs. Not all entities that are potential 

Reporting Entities currently execute or clear swaps. For example, 10 of the 15 registered DCOs currently clear 

swaps.

16 The Working Group includes staff from the Division of Market Oversight, the Division of Clearing and Risk, the 

Division of Swap Dealer and Intermediary Oversight, the Division of Enforcement, the Office of the Chief 

Economist, the Office of Data and Technology, and the Office of General Counsel.

17 Press Release, CFTC to Form an Interdivisional Working Group to Review Regulatory Reporting (Jan. 21, 2014), 

available at http://www.cftc.gov/PressRoom/PressReleases/pr6837-14.
5

reporting challenges, and to consider data standardization and consistency in reporting by market 

participants. Consistent with those objectives, and informed by the Working Group’s analysis, on 

March 26, 2014, the Commission published in the Federal Register a request for public comment 

(the “2014 Request for Comment”) on specific swap data reporting and recordkeeping rules to 

help determine how such rules are being applied and whether or what clarifications, 

enhancements or guidance might be appropriate.18 The comment period closed on May 27, 2014, 

and the Commission received 37 comments, several of which indicated support for 

standardization of SDR data reporting.19 The Working Group’s efforts have also thus far resulted 

in proposed amendments to swap data recordkeeping and reporting requirements for cleared 

swaps.20

After considering the comments the Commission received in response to the 2014 

Request for Comment, Staff is considering whether further standardization of data elements that 

are reportable under the swap data reporting rules, and in certain instances the augmentation of 

such data elements, would promote the efficient and effective analysis of swap data by Staff. In 

connection with its review, Staff is requesting comment on draft technical specifications –

including descriptions, allowable values and formats – for certain of the swap data elements that 

are reportable under parts 43 and 45 of the Commission’s regulations. These reportable data 

elements have been identified by Staff for preliminary focus, based on its review of responses to 

the 2014 Request for Comment and its experience utilizing the swap data that has, to date, been 

reported under the swap data reporting rules, and taking into consideration advancements in data 

 18 Review of Swap Data Recordkeeping and Reporting Requirements, 79 FR 16689, March 26, 2014.

19 The list of comments received in response to the request for public comment is available at 

http://comments.cftc.gov/PublicComments/CommentList.aspx?id=1484. 

20 See Amendments to Swap Data Recordkeeping and Reporting Requirements for Cleared Swaps, 80 FR 52544, 

August 31, 2015 (“Proposed Part 45 Amendments”).
6

schema, best practices within the industry, swap data reporting rules and data standards recently 

adopted by other regulators, including the European Securities Markets Authority and Securities

Exchange Commission, and international work streams focusing on the global harmonization of 

swap data, such as the Committee on Payments and Market Infrastructures (“CPMI”) –

International Organization of Securities Commissions (“IOSCO”) Over-the-Counter Derivatives 

Harmonization effort.21

Staff expects the development of any technical specifications for reportable swap data 

elements to be an iterative process. Future technical specifications on swap data reporting are 

likely to specify the form and manner with which SDRs will be required to make swap data 

available to the Commission according to schema(s) that will reference international industry 

standards. In addition, any future technical specifications that are developed, taking into 

consideration the information gathered from this request for comment process, are likely to also 

include further details, such as whether a particular swap data element is always or conditionally 

required to be included in a swap data report, and what validation procedures should be applied 

to reported swaps data messages. Moreover, the reportable data elements for which draft 

technical specifications have been presented herein for comment, represent only a subset of all 

data elements that are reportable under the swap data reporting rules, and focus primarily on the 

interest rate, credit and foreign exchange swap asset classes—although several of the data 

elements are not asset class specific, such that any standardization of their format and content 

 21 The Financial Stability Board (“FSB”) constituted the Aggregation Feasibility Study Group (“AFSG”), co-chaired 

by the CFTC and the European Central Bank, tasking it to study the various options for the global aggregation of 

over-the-counter-derivatives trade repository data (“OTCD TR data”). On September 19, 2014, the FSB published 

the final AFSG report, endorsing certain recommendations to take forward the work relating to the potential 

aggregation of OTCD TR data, including: 1. Further develop and implement a uniform global Unique Transaction 

Identifier (“UTI”) and Unique Product Identifier (“UPI”); and 2. Develop global guidance on harmonization of data 

elements that are reported to trade repositories and are important to aggregation by authorities. The CPMI and 

IOSCO are leading the effort to act upon the foregoing recommendations in order to harmonize key data elements, 

and eventually facilitating the aggregation of OTCD TR data on a global scale to understand systemic risk.
7

may enhance clarity and utility across all asset classes. By contrast, certain of the reportable data 

elements presented herein are not applicable to all swaps, even within a particular asset class, 

and would not be germane to the reporting of certain transactions or events. The inclusion or 

exclusion in this Request for Comment of technical specifications for any particular data 

element, in no way modifies or affects existing reporting and recordkeeping obligations under 

the swap data reporting rules.

Staff is also requesting comment on draft technical specifications for swap data elements 

that are not currently reportable under the swap data reporting rules, but which have been 

identified by Staff as data elements which—when reported in a clear and consistent manner—

may assist the Commission in fulfilling its regulatory mandates, including systemic risk 

mitigation, registrant compliance oversight, market monitoring and market abuse prevention. 

Staff seeks to assess, via this comment request, whether any clarifications, modifications and 

enhancements may be necessary for swap data repositories (“SDRs”) to appropriately transmit 

this subset of swaps data elements to the Commission. This Request for Comment has been 

guided in part by Staff’s views regarding the potential regulatory utility of these additional data 

elements, and includes, among the specific questions presented for comment, certain questions 

which address the efficacy and utility of reporting such data elements.

III. Request for Comment

Staff is soliciting comment from all interested parties regarding the draft technical 

specifications for certain swap data elements, and associated questions, presented herein. The 

specifications and questions are organized into sections by topic, with each section including a 

brief explanatory paragraph intended to provide context for the specifications and questions 

presented. Relevant topics include, among other things, counterparty-related elements, price, 
8

clearing, product, periodic reporting, orders, package transactions, options, additional fixed 

payments, notional amount, events, rates and foreign exchange. These topics have been grouped 

together based on their application to transaction, event and asset class specific information. 

Each topic includes draft technical specifications containing a set of data elements that are 

related to that topic. A topic for other data elements for which an explanatory paragraph was not 

necessary includes only draft technical specifications. This Request for Comment purposely does 

not differentiate between parts 43 or 45 or between requirements, under part 45, for reporting 

creation (primary economic terms (“PET”) and confirmation data) or continuation data reporting 

because Staff’s primary aim is to solicit feedback regarding the technical specifications for 

certain data elements, rather than the requirements of the swap data reporting rules more 

generally. Furthermore, this Request for Comment deliberately does not focus on technical 

aspects of the LEI (Legal Entity Identifier), UPI (Unique Product Identifier) or USI (Unique 

Swap Identifier), in light of ongoing, coordinated initiatives at the international level to develop 

global standards for these broadly utilized identifiers. Unless otherwise indicated, section 

references below are to Commission regulations in Chapter I of Title 17 of the Code of Federal 

Regulations (“CFR”).

Commenters’ responses should identify the specific question that they are addressing. 

Responses should consider the oversight functions performed by the Commission, including, but 

not limited to, financial surveillance, market surveillance, risk monitoring, and trade practice 

surveillance. Staff welcomes responses that identify swap data elements that are not included in 

this Request for Comment and suggestions on substitute elements that would better help the 

Commission perform the above mentioned functions. In addition to responding directly to 

enumerated questions, Staff requests that respondents thoroughly review all of the details 
9

presented in the draft technical specifications for certain swap data elements, including Data 

Element which provides a name by which to reference the information being reported, 

Description which provides an overview of the function of the information being reported, 

Allowable Values which provides instructions on the expected content for the information being 

reported including applicable enumerated values and/or codelists, and Format which provides 

technical detail on how the content for the information being reported should be expressed 

including applicable data standards, and comment upon any aspects thereof.

Comments on this Request for Comment must be received on or before March 7, 2016. 

You may submit comments, identified by “Comments on Draft Technical Specifications for 

Certain Swap Data Elements,” by any of the following methods:

• Agency Web Site: http://www.cftc.gov.

• Mail: Secretary of the Commission, Commodity Futures Trading Commission, Three 

Lafayette Centre, 1155 21st Street NW, Washington, DC 20581. 

• Hand Delivery/Courier: Same as mail above. 

Please submit your comments using only one method. All comments must be submitted 

in English or accompanied by an English translation. Comments will be posted as received to 

www.cftc.gov. You should submit only information that you wish to make available publicly. If 

you would like to submit information that is exempt from disclosure under the Freedom of 

Information Act, a petition for confidential treatment of the exempt information may be 

submitted according to the procedure established in Regulation 145.9.

The CFTC reserves the right, but shall have no obligation, to review, pre-screen, filter, 

redact, refuse, or remove any or all of your submission from www.cftc.gov that it may deem to 

be inappropriate for publication, such as obscene language. All submissions that have been 
10

redacted or removed that contain comments on the merits of this Request for Comment will be 

retained in the public comment file and will be considered as required under the Administrative 

Procedure Act and other applicable laws, and may be accessible under the Freedom of 

Information Act.

This Request for Comment was prepared by staff from the Division of Market Oversight

and the Office of Data and Technology. For further information contact: Daniel Bucsa, 

Deputy Director, 202-418-5435, dbucsa@cftc.gov; Ben DeMaria, Special Counsel, 202-418-

5988, bdemaria@cftc.gov; David Aron, Special Counsel, 202-418-6621, daron@cftc.gov; 

Richard Mo, Attorney Advisor, 202-418-7637, rmo@cftc.gov; Tom Guerin, Attorney Advisor, 

202-734-4194, tguerin@cftc.gov, Division of Market Oversight; Srinivas Bangarbale, Deputy 

Director, 202-418-5315, sbangarbale@cftc.gov, Office of Data and Technology, Commodity 

Futures Trading Commission, Three Lafayette Centre, 1155 21st Street, NW, Washington, DC 

20581.

IV. Issues and Questions

A. Counterparty-Related Data Elements

Identifying entities involved in or impacted by a swap transaction, and their roles with 

respect to the transaction, would help Staff surveil and otherwise monitor, among other things, 

the concentration of risk in the swap markets. However, Staff has encountered difficulties 

aggregating swap data based on current data elements.

Data elements related to Ultimate Parent and Ultimate Guarantor only, not the entire 

hierarchy of relationships, have been included to address Staff’s need to identify entities related 

to a swap transaction. Identifying the Ultimate Parent and Ultimate Guarantor of each swap 

counterparty may assist Staff, among other things, in evaluating the overall risk undertaken by 
11 

each of these entities, identifying inter-affiliate swaps, and properly aggregating volume 

measures across counterparties.

1. Are there challenges associated with identifying the Ultimate Parent and/or Ultimate 

Guarantor of a swap counterparty? If so, how might those challenges be addressed? 

2. Are there any additional counterparty-related data elements that should be included 

to evaluate the risk undertaken by the Ultimate Parent and Ultimate Guarantor? 

3. When a swap counterparty has more than one Ultimate Parent, including, but not 

limited to, situations in which an entity is a joint venture, how might this be reflected 

in a single data element? 

4. Are there situations in which a natural person is the Ultimate Parent of a swap 

counterparty? If so, is it clear who should and should not be reported? 

5. Should the allowable values for Counterparty ID be modified for counterparties that 

are natural persons? If so, how? 

Staff also needs the ability to accurately monitor the swaps market for participants who 

should be registered as SDs or MSPs. Staff cannot effectively perform this monitoring due to the 

challenges presented by the current data available to it provided by the SDRs. Currently, it is 

challenging to count the notional amount of particular swaps to determine whether the 

counterparty has exceeded the SD de minimis threshold.22 By facilitating the tracking of whether 

a counterparty is acting as a dealer for a swap and whether specific SD de minimis exception 

exclusions apply, a Counterparty Dealing Activity Exclusion Type data element may assist Staff

in determining whether a swap counterparty exceeds the SD de minimis threshold. 

 

22 See “Swap Dealer De Minimis Exception Preliminary Report” (Nov. 18, 2015) (“Swap De Minimis Report”), 

available at http://www.cftc.gov/idc/groups/public/@swaps/documents/file/dfreport_sddeminis_1115.pdf. 
12 

Similarly, Special Entity (SE) and Utility Special Entities (USE) indicator data elements 

may assist Staff in determining whether participants trading with SEs should be registered as 

SDs. SE/USE indicator data elements would allow Staff to analyze currently registered and 

potential SDs who enter into trades exceeding the de minimis threshold for swaps with an SE, 

which is lower than the general de minimis threshold at $25 million for SEs. 

Staff also needs data which accurately represents the various workflows that occur as part 

of a swap involving a Prime Broker. A Prime Brokerage indicator may assist Staff in calculating 

swap transaction volumes without potentially double counting trades where a Prime Broker steps 

into an existing trade between the executing SD and the client.

6. Should the Commission propose a definition of a prime broker for this purpose? If so, 

is the following definition sufficient to describe all forms of prime brokerage in the 

swap markets? 

A prime broker is a party that acts as the credit intermediary for swaps whose 

terms and conditions are agreed to by (1) a customer of the party providing the 

credit intermediation and (2) an executing swap dealer, provided that the terms 

and conditions of the swap fall within the customer-specific limits previously 

specified by the party providing the credit intermediation?

Is there an alternative definition that would more appropriately capture all forms of 

prime brokerage relationships and transactions in the swap markets? 

7. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below.

Data Element Description Allowable Values Format/Standard

Counterparty ID Unique code identifying the counterparty. Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Special entity/utility 

special entity 

Indicator

The terms “special entity” and “utility 

special entity” are defined at 23.401(c) and 

1.3 (ggg)(4)(i)(B)(2), respectively. Note that 

“utility special entity” is a subset of “special 

entity.”

SE 

USE

N 

Varchar
13 

Data Element Description Allowable Values Format/Standard

SE = Special entity - Special Entities that 

are not Utility Special Entities should select 

SE as their entry. 

 

USE = Utility special entity - Utility special 

entities should select USE as their entry.

N = Counterparty is not a special entity or 

utility special entity

Third Party Reporter 

ID

The ID of the Third Party Reporter or SEF. Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Submitter ID An entity submitting the data on behalf of a 

registered entity23 or swap counterparty to 

the SDR as allowed by § 45.9.

The submitter ID will be the same as the 

reporting party ID or Third Party Reporter 

ID, unless either uses another service 

provider to submit the data to SDR.

Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Ultimate Parent The term “Ultimate Parent” is defined at § 

45.6(a).24 

Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Ultimate Guarantor Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Counterparty 

Dealing Activity 

Exclusion Type

Identifies the exclusion on which 

counterparty relies to exclude the swap 

from dealing activity. 

NE = No Exclusion; swap is a dealing swap 

for the CP: 

If NE applicable, only NE may be reported, 

else multiple entries may be reported for the 

same swap

Swaps not considered in determining 

whether the counterparty is a swap dealer:

IDI = §1.3(ggg)(5): Insured depository 

institution swaps in connection with 

originating loans to customers 

NE 

IDI 

IA

COOP 

PHYS

FLR 

NonUS

CMPRS 

IFI

FX

CTO

Varchar

 

23 The term “registered entity” includes SEFs and DCMs. See CEA sections 1a(40)(A), (C) and (D), 7 U.S.C. 1a(40) 

(A), (C) and (D). The Commission stated in the RTR Adopting Release that SEFS and DCMs may enter into a 

contractual relationship with a third party service provider to transmit swap transaction and pricing data to an SDR; 

however, the SF or DCM will remain responsible for such reporting requirement pursuant to part 43. RTR Adopting 

Release at 1201.

24 Regulation 45.6(a) defines ultimate parent for the purposes of §45.6 as “a legal person that controls a counterparty 

to a swap required to be reported pursuant to this section, or that controls a legal entity identified or to be identified 

by a legal entity identifier provided by the legal identifier system designated by the Commission pursuant to this 

section, and that itself has no parent.”
14 

Data Element Description Allowable Values Format/Standard

IA = §1.3(ggg)(6)(i): Inter-affiliate 

activities 

COOP = §1.3(ggg)(6)(ii): Activities of a 

cooperative 

PHYS = §1.3(ggg)(6)(iii): Swaps entered 

into for the purpose of hedging physical 

positions 

FLR = §1.3(ggg)(6)(iv): Swaps entered into 

by floor traders 

NonUS = Non-US Person 

CMPRS = CFTC Staff Letter No. 12-62 

(Dec. 21, 2012): Compression exercise 

swaps 

IFI = 77 FR at 30693: International 

Financial Institutions 

FX = Treasury Determination, 77 FR at 

69705: FX swap exclusion 

CTO = Regulation 32.3; 77 FR 25320, 

25326, note 39, Apr. 27, 2012; see generally 

77 FR 25320 at 25325-29: (Commodity 

Trade Options) 

US Person Indicator 

for Ultimate 

Guarantor

Y

N 

Char(1)

US Person Indicator 

for Ultimate Parent

Y

N

Char(1)

Counterparty US 

Person Indicator

Y

N

Char(1)

Reporting 

Counterparty ID

The Reporting Counterparty as determined 

in accordance with 45.8.

Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Counterparty 

Financial Entity 

Indicator

An indication of whether the counterparty is 

a financial entity as defined in CEA § 

2(h)(7)(C).

Y

N 

Char(1)

Prime Brokerage 

Indicator

Indicator of if a counterparty is acting as a 

prime broker for the other counterparty for 

the reported swap.

Y

N 

Char(1)

B. Product 

Staff needs to aggregate swap data to determine positions and exposures, and to perform 

their regulatory duties. To properly aggregate swap data, Staff needs to first identify the underlier 
15 

of each swap and know its source. However, many underliers, such as rate indices for instance, 

are not uniformly identified in SDR data. While data standards, such as ISDA Floating Rate 

Option definitions (e.g., the 2006 ISDA Definitions), have been published for interest rate 

indices underlying interest rate swaps, many reporting counterparties and submitters use their 

own descriptions for such indices rather than standard representations. Such variation and 

optionality in reporting decreases both the quality and usability of SDR swap data. Indices that 

do not have an ISDA Floating Rate Option, such as the DTCC GCF Repo index as one example, 

are similarly not represented consistently across submitters. A standardized representation of the 

Floating Rate Index data element would allow Staff to properly aggregate interest rate swaps 

according to the underlier of those swaps. 

Similarly, for currency-related swaps and offshore currencies,25 such as the offshore 

Renminbi (RMB), are not uniformly identified in currency-related swap data. This lack of 

uniformity hinders Staff’s ability to properly aggregate currency-related swap data. Therefore, 

Staff requests comment on how best to identify offshore currencies. 

For credit index products in particular, Staff has been notified that certain parties’ 

potential assertion of their intellectual property rights in their proprietary credit indices might be 

preventing SDRs from transmitting all of the data identifying the index underlying swaps. 

Without taking a view on the validity of such assertions, mandating the use of existing identifiers 

would greatly improve Staff’s ability to aggregate transactions to determine positions and 

exposures to perform their regulatory duties, and could—if Staff mandated the use of the 

identifiers of a single, or a limited number of, index providers—promote more efficient use of 

Staff’s resources. To the contrary, Staff is concerned that mandating the use of specific 

 

25 In this context, in the case of a country that otherwise controls the exchange rate for its currency, an offshore 

currency market means a market that trades separately from a market controlled by the issuing country, and outside 

the control of that country. 
16 

proprietary identifiers could interfere with innovation and competition in the creation of new 

products for these markets. Therefore, Staff is requesting comment on how to best resolve this 

issue.

Changes to index identifiers present another challenge to proper aggregation of swaps 

involving the same underlying index. Changes may result from a name change or a new 

organization governing the index, such as when the Public Securities Association/Bond Market 

Association Municipal Swap Index became the SIFMA Municipal Swap Index, or a new quote 

provider being referenced in the index identifier, such as replacing Telerate 3750 with Reuters 

LIBOR01. 

8. What are the challenges to reporting industry accepted uniform identifiers? How can 

those challenges be addressed? 

9. If there is not an industry accepted uniform identifier for a particular index, how 

should the index be represented in swaps data? 

10. What are the challenges to using proprietary identifiers? Do you have 

recommendations for addressing these challenges? 

11. What are the challenges presented when an identifier for an index is changed? Do 

you have recommendations for addressing these challenges? 

12. Do the benefits of mandating a publically available standard reference 

representations and possibly a central maintenance authority outweigh the potential 

effect on innovation and competition in the creation of new indices or index 

identifiers?
17 

13. Would using a single source for each index identifier and/or asset class be preferable 

to using multiple index providers? If so, why, and which providers would you 

recommend and why? 

14. How should currencies that do not have ISO 4217 codes be represented? 

15. Is there any uncertainty regarding how Reporting Counterparties should determine 

and report the Asset Class treated as the primary asset class involved in a multi-asset 

swap? 

16. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Asset Class This data element identifies the asset class 

for the swap. 

Credit

Rates

ForeignExchange

Commodity

Equity

Varchar

C. Price

Staff needs information on the price of swap transactions. In this context, Staff is using 

price to mean the value exchanged between parties for a swap, which could be all up front (such 

as an option premium) or over the course of the contract (such as the fixed rate on an interest rate 

swap). Price information is useful for a wide range of swaps data analysis, including but not 

limited to, tracking intraday price movement, measuring volatility, and comparing prices 

reported for similar swaps within the same timeframe. Price may be expressed differently across 

different swap asset classes or across different products within an asset class. In certain 

circumstances, price may not be the most appropriate term for describing the value exchanged 

between the counterparties to a swap transaction.
18 

17. Are there alternative terms for representing the value exchanged between parties for 

different asset classes and different types of contracts within each asset class? 

18. Price is currently reported in several ways, including Price, Spread, Percentage, and 

Upfront Points. Is this list sufficient or should other Allowable Values be added? 

19. Should each asset class have a specific list of allowable Price types? If so, please 

suggest allowable price types. 

20. What additional data elements related to Price should be provided for each asset 

class or product type to fully reflect the value exchange by counterparties of the 

swap? 

21. Where a swap uses “post pricing” (e.g., the pricing is determined by an average 

price over time, volumetric weighted average price, closing price, opening price), 

how should the Price data element be expressed before the numerical price value is 

determined for each type of post-priced swap? 

22. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Par Spread The spread used to quote CDS 

indices.

Number of Basis Points Format: 5 digit 

decimal precision

Example:

1 basis point will be 

represented as 

0.00010 

Price The price per swap excluding, 

where applicable, commission and 

accrued interest.

Numeric value of zero or 

greater

5 digit decimal 

precision

Price Type The type of pricing that is reported 

in the “Price” data element. 

Price

Spread

Percentage

Upfront Points

Varchar

Price Currency An indication of the currency of the 

price if the price type is a price.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code
19 

D. Notional Amount 

Commission regulations frequently reference the term notional amount. Staff needs to 

ensure that reported notional amounts accurately reflect market activity. To date, Staff has 

encountered difficulties analyzing notional amounts due to inconsistent representation in swaps 

data.26 The Notional Amount data elements listed below allow for an explicit representation of 

the notional amount for each leg or cash flow stream, rather than requiring Staff to infer the 

notional amount for a leg/stream based upon the absence of reported multiple notional 

amounts.27

23. What challenges exist for reporting of static and/or varying notional amounts, such 

as a schedule for accreting or amortizing swaps? Do you have recommendations for 

addressing these challenges? 

24. How should the reported notional amount reflect embedded leverage that may alter 

the “effective” notional amount of the swap? 

25. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Notional 

Amount

The notional amount reflects the 

reference amount from which the 

contractual payments are 

determined.

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Notional 

Currency

The currency associated with the 

notional amount

Valid ISO 4217 currency code 3-character 

alphabetical 

Standard: ISO 4217 

currency code

 

26 See e.g., Swap De Minimis Report, supra note 22. 

27 Leg is a cash flow present within swaps and in this draft technical specifications for certain swap data elements, 

we also refer to it as a stream to incorporate the concept of fees.
20 

E. Additional Fixed Payments

Staff needs information regarding any Additional Fixed Payments (e.g., upfront fees, 

brokerage fees, novation fees) associated with the swap transaction. These Additional Fixed 

Payments could potentially impact the economic terms of the transaction. An additional fixed 

payment can be represented in a manner similar to a leg. In case of multiple Additional Fixed 

Payments, there will be an equivalent number of legs. Since the Payer or the Receiver of the 

Additional Fixed Payment might not be a counterparty to the swap, the leg/stream structure will 

include the ‘Payer/Receiver’ of the Additional Fixed Payment. Additional Fixed Payments can 

arise for a wide variety of reasons, leading to multiple Allowable Values for the Additional Fixed 

Payments Type.

26. What challenges may exist for reporting Additional Fixed Payments? If so, what 

alternative approaches are available? 

27. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Additional Fixed 

Payment Amount

Numeric amount of Additional 

Fixed Payment

Numeric value of zero or 

greater

5 digit decimal 

precision 

Additional Fixed 

Payment Currency 

Currency code for Additional 

Fixed Payment

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Additional Fixed 

Payment Date

Date of Additional Fixed 

Payment (paid / received)

Valid date Format: YYYY-MMDD

Standard: ISO 8601 

UTC

Additional Fixed 

Payment Payer ID

LEI of Payer of Additional 

Fixed Payment 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Additional Fixed 

Payment Type

Enumerated list of types of 

fixed payments

Initial Exchange 

Interim Exchange

Final Exchange 

Credit: Interest Shortfall 

Reimbursement 

Varchar
21 

Data Element Description Allowable Values Format/Standard

Credit: Principal Shortfall 

Reimbursement 

Credit: Write Down 

Reimbursement

 

Brokerage

Unwind

Correction

Cancellation

Amendment

Novation

Currency: Premium Exchange

Compression

Partial Termination

Full Termination

Other

Initial Payment Amount

Additional Fixed 

Payment Receiver ID

LEI of Receiver of Additional 

Fixed Payment 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

F. Options 

Staff believes that additional options-related information is necessary to provide a more 

complete picture of risk exposures resulting from option transactions. In particular, Staff

determined that the swap data currently reported to SDRs does not sufficiently identify option 

buyers and sellers or the resulting obligations and cash flows associated with option exercises. 

Option Type and other data elements reported both at the overall swap reporting level and the 

leg/stream reporting level would better detail the obligations and cash flows resulting from 

option exercises.
22 

28. Do the allowable values for Option Type clearly and properly reflect the possible 

outcomes resulting from an option exercise as they relate to the underlying contract? 

29. Do the allowable values for Option Strike Type properly reflect the range of appropriate 

entries for this data element?

30. Does the definition of Option Strike adequately describe the range of entries for this data 

element?

31. Do the allowable values for Option Premium Amount Type properly reflect the range 

of appropriate entries for this data element? 

32. How should the Embedded Option Indicator data element be defined? Should optional 

termination rights at the market price of the swap, “tear up” swaps and/or “First 

Method” style termination rights be considered embedded options? 

33. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Option Buyer ID Identity of the buyer of an option Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Option Seller ID Identity of the seller of an option Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Option Strike The level or price at which an 

option may be exercised.

Numeric value zero or 

greater

Format: 5 digit 

decimal precision

Note: If a percentage, 

floating point decimal 

representation of 

percentage

Example:

1% should be 

represented as 0.01000

Option Strike 

Type

Identifies the type of the option 

strike price.

Price

Spread

FX Rate

Percentage

Upfront Points

Interest Rate

Varchar

Option Strike 

Currency

The currency of the option strike 

price if the option strike price type 

is a price.

Valid ISO 4217 currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 4217 
23 

Data Element Description Allowable Values Format/Standard

currency code

Option Premium 

Amount

The amount a buyer pays for an 

option

Numeric value 5 digit decimal 

precision

Option Premium 

Amount Type

Describes how the option premium 

amount is being represented.

Price

Spread

Varchar

Option Premium 

Currency

An indication of the currency of 

the option premium amount if the 

amount type is a price.

Valid ISO 4217 currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Option Type A description of the right to which 

the reporting party is entitled. 

Right to Pay and Right to Receive 

are applicable for interest rate 

swaptions only. Right to Buy 

protection and Right to Sell 

protection are applicable to credit 

index swaptions only.

Right to Pay

Right to Receive

Right to Buy Protection 

Right to Sell Protection

Call

Put

Chooser

Varchar

Earliest Exercise 

Datetime

Earliest time that an option may be 

exercised.

Valid date-timestamp greater 

than the date and time for 

execution and less than the 

date and time Scheduled 

Termination Date

Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Final Exercise 

Datetime

An indication of the date after 

which the option is no longer 

available for exercise.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC 

Option Style An indication of the exercise style 

of the option transaction.

American

Bermudan

European

Varchar

Embedded Option 

Indicator

An indication of whether or not the 

option data elements are for an 

embedded option 

Y

N

Char(1)

G. Orders

To sufficiently perform its oversight duties, Staff needs information on the order details 

underlying each executed swap on or subject to the rules of a SEF or DCM. Examples of 

applicable order information include price discovery mechanism (e.g., RFQ or CLOB), order 

type (e.g., limit or market), time in force (e.g., GTC or FOK), quantity type (e.g., AON or 

Iceberg), customer type (e.g., customer or proprietary accounts), and timestamps for both order 

placement and matching. These data elements would allow Staff to better understand the type of 

swap trading activity that occurs on facilities and more accurately assess how the implementation 

of the trade execution mandate is impacting markets and participants.
24 

34. Is a single Order ID sufficient to access historical order information? If not, what other 

identifier(s) would be sufficient to access historical order information? 

35. What challenges exist for reporting this type of order information for a particular swap 

traded on or subject to the rules of a SEF or DCM? Do you have recommendations for 

addressing these challenges? 

36. Please provide feedback on any aspect of the draft technical specifications for the data 

elements presented below.

Data Element Description Allowable Values Format/Standard

Order ID Order ID refers to a numeric ID 

assigned by the SEF or DCM, for 

each counterparty, that refers to the 

order to trade the swap that led to 

the transaction. Order ID should be 

unique by execution venue and 

date.

Unique code generated by the 

SEF or DCM

 

Varchar

Order 

DateTimestamp

Time the order was received by the 

SEF or DCM

Valid date time Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Match 

DateTimestamp

Time the order was matched by the 

SEF or DCM

Valid date time Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Price Discovery RFQ = Request for Quote

AUC = Auction

WKP = Workup 

CLOB = Central Limit Order Book

AIM = Actionable Indicative 

Message

RFC = Request for Cross

ORD = Orderbook

PME = Permitted Method of 

Execution

VRFQ = Voice Request for Quote

RFQ

AUC

WKP

CLOB

AIM

RFC

ORD

PME

VRFQ

Varchar

Price Order Price specific order designation.

Market = Market order – An order 

to buy (or sell) a product at the 

bid/offer price currently available 

in the marketplace.

MIT = Market if Touched – An 

order to buy (or sell) below (or 

above) the market. When trigger 

price is touched, the order is 

submitted as a market order.

STOP = Stop Order – Stop order 

Market 

MIT 

STOP

LIMIT

STOP LIMIT

LIT 

TOP 

Varchar
25 

Data Element Description Allowable Values Format/Standard

becomes a market order at the 

specified stop price.

LIMIT = Limit order – An order to 

buy (or sell) at a specified price or 

better.

STOP LIMIT – Stop limit – Stop 

limit order becomes limit order at 

specified price.

LIT = Limit if touched - An order 

to buy (or sell) below (or above) 

the market at the limit price or 

better. When trigger price is 

touched, the order becomes a limit 

order.

TOP = Order set to either the best 

bid or offer price. Order will be 

cancelled if no longer best bid or 

offer.

Customer type Distinguishes from whom and on 

what type of account the trades are 

being placed.

EBOA = For orders placed by an 

executing broker for his own 

account.

EBFP = For orders placed by an 

executing broker for a firm 

propriety account.

EBAB = For orders placed by an 

executing broker who also has 

access to the system.

EBFC = For orders placed by an 

executing broker on behalf of the 

customer.

EBOA

EBFP

EBAB

EBFC

Varchar

Execution Type Identifies instruments as required 

or permitted transactions on a SEF. 

REQ = Required

PERM = Permitted

REQ

PERM

Varchar

Order Source The source of where the order 

came from.

EXCH = Exchange activity

BLOCK = Off exchange block 

trade

EDRP = Exchange derivatives for 

related positions

XFER = Transfers

CUST = Portfolio Compression 

transactions

GIV = Giveup

VOICE = Voice trade

BUST = SEF busted trade

EXCH 

BLOCK 

EDRP 

XFER 

CUST

GIV

VOICE

BUST

Varchar

Block Trade 

Election Indicator

This data element indicates that an 

election has been made to report 

the swap as a block or large 

Y

N 

Char(1)
26 

Data Element Description Allowable Values Format/Standard

notional off-facility swap either by 

the reporting party or as calculated 

by the SDR acting as a third party 

for the Reporting Entity.

H. Package Transactions

Package transactions have been described generally as “transactions involving at least 

one swap subject to the trade execution requirement [of CEA section 2(h)(8), 7 U.S.C. 2(h)(8)]; 

and at least one or more additional swaps or financial instruments (often referred to as 

“component legs”).”28

In some cases, one or more of the component legs of a package transaction can involve a 

financial instrument not subject to the Commission’s exclusive jurisdiction, such as a component 

leg involving the purchase or sale of a Treasury security or a credit default swap on a single 

name. In other package transactions, both component legs are subject to the Commission’s 

exclusive jurisdiction, such as package transactions in which both component legs are swaps or 

packages in which one component leg is a futures transaction and the other is a swap. 

Given that a significant portion of swaps in certain asset classes are traded as component 

legs of package transactions, identifying which swaps are parts of package transactions improves 

Staff’s oversight of swap markets. Further clarity on package transactions will improve Staff’s 

understanding of concentrations of risk within the market and their regulatory oversight. 

37. Are the proposed data elements appropriate in identifying which swaps are executed 

as component legs of a package transaction? 

38. Are there any unique characteristics to certain types of package transactions that 

Staff should account for in devising data elements? 

 

28 CFTC No-Action Letter No. 14-12 (Feb. 10, 2014) at 2, available at

http://www.cftc.gov/idc/groups/public/@newsroom/documents/letter/14-12.pdf. 
27 

39. Should the data elements provide pricing for each component of a package 

transaction, or is it sufficient to only provide (1) pricing for the swap components 

only; or (2) price for the entire package? 

40. Should the data elements specifically identify the types of non-swap instrument 

component legs in the package transaction? 

41. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Package Trade 

Price

A package transaction is a transaction 

involving two or more instruments: (1) 

that is executed between two or more 

counterparties; (2) that is priced or 

quoted as one economic transaction, 

collection of swaps, securities, loans or 

other products that are traded as a single 

unit (one economic transaction). The 

data element will capture the traded 

price of the entire package or strategy in 

which the reported swap is a component.

Numeric value of zero or 

greater.

5 digit decimal 

precision

Package/Strategy 

ID

A package transaction is a transaction 

involving two or more instruments: (1) 

that is executed between two or more 

counterparties; (2) that is priced or 

quoted as one economic transaction. A 

package trade is a collection of swaps, 

securities, loans or other products that 

are traded as a single unit (one economic 

transaction). The data element will 

capture the ID of the entire package or 

strategy in which the reported swap is a 

component.

Must be a value that will 

uniquely identify the 

package or strategy that 

includes the executed 

swap.

Varchar

Package Contains 

Non-CFTC Swap 

Components

The data element will indicate if the 

given package transaction contains 

elements that are not CFTC-regulated 

swaps and therefore not reported to 

SDRs, such as securities or futures.

Y

N 

Char(1)

Package Trade 

Price Type

The data element will indicate the type 

of price found in “Package Trade Price” 

data element.

Price

Spread

Percentage

Upfront Points

Varchar

Package Trade 

Price Currency

An indication of the currency of the 

package trade price if the package trade 

price type is a price.

Valid ISO 4217 currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 

4217 currency code

I. Clearing

Staff needs to accurately identify and analyze related swaps throughout the lifecycle of a 

cleared swap transaction in order to perform its oversight duties. Ensuring consistent and 
28 

complete reporting for original swaps and clearing swaps29 would promote Staff’s understanding 

of swap activity and promote a more accurate representation of whether a swap has been cleared, 

and therefore terminated, or is still active. In particular, the true ultimate notional amounts of 

various related swaps would be more apparent, thus avoiding triple counting of original swaps 

and the clearing swaps that replace them. Further, knowing which swaps have been cleared will 

allow Staff to reconcile part 45 transaction reporting with part 39 position reporting. 

To help achieve these and other goals, the Commission recently proposed amendments to 

part 45.30 The Proposed Part 45 Amendments sought to clarify part 45 cleared swaps reporting 

rules and how part 45 interacts with part 39 of Commission regulations. In addition to being able 

to distinguish between original and clearing swaps, Staff needs to be able to identify the 

relationship between original and clearing swap types in order to, among other things, properly 

determine that swaps that fall under the clearing mandate have in fact been cleared. 

To further improve its understanding of cleared swaps data, a Mandatory Clearing 

Indicator data element has been added to explicitly identify whether a swap is subject to 

mandatory clearing. Clearing requirements for swaps are detailed in section 2(h) of the CEA,31

as added by section 723 of the Dodd-Frank Act. Rules regarding swaps subject to a clearing 

requirement can be found in part 50 of the Commission’s regulations. 

Staff also believes it would be useful to explicitly identify the type of clearing exemption 

claimed by a counterparty. Possible types may include: the non-financial end-user exception set 

 

29 The Commission has proposed to add to regulation 45.1 the term “original swap,” which would be defined as “a 

swap that has been accepted for clearing by a derivatives clearing organization.” See Proposed Part 45 Amendments. 

The Commission also has proposed to define the term “clearing swap” as “a swap created pursuant to the rules of a 

derivatives clearing organization that has a derivatives clearing organization as a counterparty, including any swap 

that replaces an original swap that was extinguished upon acceptance of such original swap by the derivatives 

clearing organization for clearing.” Id. The terms “original swap” and “clearing swap” as used herein have the 

meanings set forth in the Proposed Part 45 Amendments.

30 Id.

31 7 U.S.C. 2(h).
29 

forth in regulation 50.50(a); the small bank end-user exception set forth in regulation 50.50(d); 

the financial cooperative exemption set forth in regulation 50.51); the inter-affiliate exemption 

set forth in regulation 50.52; and Staff relief from clearing set forth in various Staff no-action 

letters (e.g., Staff no-action letter 14-144). 

42. Are the sources cited above, and the associated Allowable Values, sufficiently clear to 

avoid any ambiguity regarding clearing requirements and allowable exemptions? If 

not, what ambiguity exists that Staff might address? 

43. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Clearing 

Exemption Type

The type of clearing exemption(s) that is/are 

claimed by the counterparty.

Exceptions and exemptions to the swap 

clearing requirement. All applicable clearing 

exceptions must be selected:

NF-50.50 [non-financial end-user exception]

SB-50.50(d) [small bank end-user exception]

FC-50.51 [financial cooperative exemption]

IA-50.52 [inter-affiliate exemption]

NAL “Free Text”- The term entity entering 

the data for this data element must enter No 

Action letter and Free text with the letter 

number (e.g. “NAL 14-144).

NF-50.50

SB-50.50(d) 

FC-50.51 

IA-50.52

NAL “Free Text”

Varchar

Clearing 

Organization ID

Clearing Organization ID should be 

populated with the valid Legal Entity 

Identifiers (“LEIs”) of the clearing 

organization that has cleared the swap. 

Only current and 

valid Legal Entity 

Identifiers (“LEIs”) 

ISO 17442

Intent to Clear 

Indicator

Indication of whether the swap is expected to 

be cleared. For swaps that have resulted from 

the clearing of a previous swap that has been 

since terminated, this data element should be 

populated with a value of “N”.

Y

N

Char(1)

Mandatory 

Clearing Indicator

Indication of whether the characteristics of 

the swap meet the requirements for 

mandatory clearing. 

Y

N

Char(1)

Cleared Date 

Time Stamp 

The date time stamp of when the trade was 

accepted for clearing. Reported by 

derivatives clearing organization. 

A valid date time 

stamp

Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 
30 

Data Element Description Allowable Values Format/Standard

If the time portion is unknown, it should be 

designated as midnight UTC (00:00:00Z) on 

the date accepted for clearing.

UTC

Counterparty ID 

Claiming Clearing 

Exemption

The ID of the Counterparty claiming the 

clearing exemption(s)

Only current and 

valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

J. Periodic Reporting 

Staff needs to accurately identify and analyze data throughout the lifecycle of the swaps 

in order to perform their regulatory duties. Registered entities and swap counterparties provide 

the continuation data that Staff uses to fulfill these regulatory duties. Other data elements exist 

that can improve the utility of this reporting in areas including collateral and margin, next reset 

date, reconciliation, and valuation. 

(a) Reconciliation

Staff believes that data elements related to reconciliation would improve the reporting 

counterparties’ and the SDRs’ ability to confirm data accuracy, which could subsequently 

improve the accuracy of swaps data transmitted to the Commission and assist Staff with fulfilling 

their regulatory duties. 

44. To represent that the reporting counterparties and the SDRs have confirmed data 

accuracy, is there a methodology better than reporting the Data Accuracy 

Confirmation by Counterparty data element? 

45. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Part 43/45/46 Indicates if the record is being submitted 

pursuant to part 43, part 45, or part 46, or 

both part 43 and part 45. 

43

45

46

43,45

Varchar

Data Accuracy 

Confirmation by 

Counterparty

Indication of whether or not each 

counterparty to a trade has actively 

affirmed, actively disputed, or failed to 

affirm that the SDR’s record of its trade is 

Affirm 

Dispute

FailedToRespond 

Varchar
31 

Data Element Description Allowable Values Format/Standard

correct. 

The value FailedToRespond means no 

active affirmation or dispute has been 

received within 48 hours of trade. 

Date and time of 

last open swaps 

reconciliation with 

CP

Date and time of the most recent 

reconciliation of material terms for 

outstanding open swaps by SDs/MSPs. This 

reconciliation is done between 

counterparties of open swaps. 

A valid datetimestampFormat: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Date and time of 

last open swaps 

reconciliation with 

SDR

Date and time of the most recent 

verification of primary economic terms for 

outstanding open swaps. This reconciliation 

is done between swap data repositories and 

counterparties of open swaps.

A valid datetimestampFormat: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Dissemination ID Links the ID of the publicly disseminated 

swap, as it appears on the part 43 real-time 

ticker, to the part 43 message as received by 

the SDR and viewable in the SDR portal.

Varchar

(b) Next Reset Date

Periodically reporting the updated next reset date, in addition to a reset date schedule 

reported at the inception of the swap transaction, would assist Staff in monitoring for important 

fixing dates in the market.

46. Are there any challenges for reporting the updated next reset date as the floating leg 

resets over time?

47. Is there a different methodology for Staff to know the updated next reset date that is 

more efficient than the reporting of the Next Reset Date data element? 

Data Element Description Allowable Values Format/Standard

Next Reset Date The next date on which a floating 

reference becomes known for a swap.

A valid date Format: YYYY-MMDD

Standard: ISO 8601/ 

UTC

(c) Valuation

Staff needs accurate swap valuation data elements in order to fulfill their regulatory 

responsibilities. To better fulfill these responsibilities, Staff has identified utility in the Valuation 
32 

Datetime, Valuation Amount, Valuation Currency, Valuation Type, and Leg Net Present Value 

(NPV) data elements.

48. Is there a better methodology or should Staff provide more guidance on reporting the 

Valuation Amount? 

49. Are there any conditions under which the NPV of a given leg/stream cannot be 

adequately determined? If so, how should the inability to determine the NPV be 

reported? 

50. What are the challenges to reporting Leg NPV for a trade with changing notionals 

and fixed rates that cannot be accurately represented by simple aggregation 

measures? Do you have recommendations for overcoming these challenges? 

51. Are there any additional data elements related to valuation that would improve 

Staff’s ability to use valuation data and/or to fulfill their regulatory responsibilities? 

52. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Leg NPV The net present value of a cash-flow 

stream as calculated by the 

counterparties from the perspective of 

the reporting counterparty.

Numeric value. May be 

negative.

5 digit decimal 

precision 

Leg NPV Currency The currency the Leg NPV is reported 

in.

Valid ISO 4217 

Currency code

Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Valuation Datetime Datetime of the last valuation. A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Valuation Amount Numeric portion of the value of a 

contract from the perspective of the 

reporting counterparty.

Numeric value. May be 

negative 

5 digit decimal 

precision

Valuation Currency Currency associated with the valuation 

amount.

Valid ISO 4217 

currency code

3-character 

alphabetical 

Standard: ISO 4217 

currency code

Valuation Type Indication of whether valuation is mark 

to market or mark to model.

M

O 

Char(1)
33 

Data Element Description Allowable Values Format/Standard

M = Mark to Market

O = Mark to Model

(d) Collateral/Margin

Staff has identified the need to obtain information regarding swap portfolios, labeled 

Netting Set throughout the draft technical specifications for certain swap data elements. Staff

understands that market participants typically group transactions into Netting Sets based on two 

criteria: (1) ongoing cash flows in the same currency on the same payment dates (Payment 

Netting) and (2) net payments due upon an Event of Default or Termination Event (Closeout 

Netting). The Collateral/Margin data elements would allow Staff to appropriately aggregate 

swaps data based on Netting Sets to better evaluate swap market risks.

Staff is aware that collateralization is generally determined using a portfolio of 

transactions between two counterparties. To better evaluate risk undertaken by counterparties, 

Staff needs access to collateral and margin information. While these calculations are performed 

at the Netting Set level, the draft technical specifications for certain swap data elements is based 

on transaction level reporting and envisions the same data being reported for each swap 

transaction that is part of a Netting Set as a pragmatic resolution.

53. What are the challenges to reporting the following collateral information: 

(a) eligible currencies, securities and haircuts; 

(b) other types of eligible collateral and valuation; 

(c) rehypothecation election; and 

(d) segregation of posted collateral in a triparty custodial account? 

Do you have recommendations for addressing these challenges? 

54. What are the challenges to reporting Independent Amount/Initial Margin and 

Variation Margin amounts separately? Do you have recommendations for addressing 

these challenges?
34 

55. What are the challenges to reporting if a transaction is guaranteed by multiple 

entities at varying levels of subordination? 

56. Should Netting Set valuation, collateral and margin information be reported at the 

transaction level or only at the aggregated portfolio level? 

57. Are the data described in the data element Close Out Netting Set Portfolio and 

Collateral Valuation Currency all denominated in the same currency? If not, should 

there be additional data elements to capture the currencies?

58. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

59. Are there any other event types that are important to define and track? 

Data Element Description Allowable Values Format/Standard

Close Out Netting 

Set Portfolio and 

Collateral 

Valuation Currency

Currency associated with:

 - Close Out Netting Set Portfolio Net 

Mark To Market Valuation

 - Close Out Netting Set Independent 

Amount/Initial Margin requirement

 - Close Out Netting Set Variation 

margin requirement

 - Close Out Netting Set Collateral 

Posted Valuation

Valid ISO 4217 currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Close Out Netting 

Set Independent 

Amount/Initial 

Margin 

requirement

Sum of all independent amount and/or 

initial margin requirements to be 

posted by each CP in the close out 

netting set.32 Value reported here is 

not the actual value of Independent 

Amounts (IA) and/or Initial Margin 

(IM) posted; instead this is the sum 

contractual IA/IM requirements from 

each counterparty (CP) for the close 

out netting set. 

Numeric value of zero or 

greater. 

5 digit decimal 

precision

Close Out Netting 

Set Variation 

margin requirement

Variation margin requirement. 

Value reported here is not the actual 

value of variation margin posted; 

instead this is the contractual VM 

requirement from each CP for the 

close out netting set.33

Numeric value of zero or 

greater. 

5 digit decimal 

precision 

 

32 Independent Amount is defined in the ISDA 2013 or 2014 Standard Credit Support Annex.

Exposure and Delivery Amount are defined at ISDA 2013 or 2014 Standard Credit Support Annex. 
35 

Data Element Description Allowable Values Format/Standard

Close Out Netting 

Set ID (unique)

Unique ID agreed to by both 

counterparties identifying a portfolio 

of transactions that are netted for 

close out/early termination 

purposes.

34 

Unique internal ID code 

generated by each 

counterparty to represent a 

distinct netting set. 

Varchar(50)

Close Out Netting 

Set Collateral 

Posted Valuation

The total value of all collateral posted 

by either CP to the other (collateral 

posted by each CP reported 

separately) in a single valuation 

currency after the effects of applying 

any Valuation Percentage or haircut 

to the collateral.35

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Close Out Netting 

Set Portfolio Net 

Mark To Market 

Valuation

Close out netting set/portfolio level 

(not trade by trade) fair values 

reported from the Reporting 

Counterparty’s point of view. Positive 

value = Reporting Counterparty asset 

= other counterparty liability. 

Negative value = Reporting 

Counterparty liability = other 

counterparty asset.

Portfolio values should be reported 

using the relevant “fair value” 

accounting standard applicable to the 

reporting party.

Numeric value. Can be 

negative.

5 digit decimal 

precision 

Close Out Netting 

Set Collateral 

Weighted Average 

Valuation 

Percentage

Weighted average Valuation 

Percentage derived from the actual 

collateral posted. 36

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Close Out Netting 

Set Collateral 

Posted Valuation 

Date/Time

For each CP, date and time when the 

collateral posted into a close out 

netting set is valued.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Close Out Netting 

Set Portfolio Net 

Mark To Market 

Valuation 

Date/Time

Date and time when a close out 

netting set portfolio is valued.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

 

34 See 1992/2002 ISDA Master section 6.

35 See ISDA 2013 or 2014 Standard Credit Support Annex, or 1994 ISDA Credit Support Annex for definitions for 

Independent Amount, Exposure and Delivery Amount for guidance.

36 See ISDA 2013 or 2014 Standard Credit Support Annex, or 1994 ISDA Credit Support Annex for definitions for 

Valuation Percentage
36 

K. Events 

Staff needs to be able to track the history of material events and amendments for swaps to 

perform a number of regulatory duties. These duties include, among others, market surveillance, 

risk monitoring, analyzing the appropriate de minimis level for swap dealer registration purposes 

and determining the appropriate minimum block size for block trade reporting. Staff requires a 

clear understanding of the multitude of events that could potentially impact swap transactions 

over the life of a swap. The frequency and volume of unlinked message traffic representing 

changes to reportable swaps transactions does not adequately capture these events. As a result, 

Staff cannot readily analyze the activity occurring in jurisdictional swap markets by tracking the 

audit trail of what occurred and capturing the most up to date representation of the swap. Some 

of these representative challenges include: tracking the various linkages between swaps and the 

lifecycle events that impact them via unique swap identifiers (USIs) and ambiguity associated 

with identifying swap terminations. Inconsistent reporting of price forming swaps currently 

challenges Staff as they attempt to identify compression, novation, or other similar events. 

Variations in how reporting counterparties interpret swap events and reporting practices by SDRs 

further impairs Staff’s ability to perform their regulatory duties. The data elements listed below 

in the draft technical specifications for certain swap data elements provide greater flexibility for 

the accurate reporting of the multitude of events that could potentially impact swap transactions 

over the life of a swap.

The “Prior USI” data element is not adequate for associating swaps that are affected by, 

or resulting from, specific events. The data elements listed below in the draft technical 

specifications for certain swap data elements include an Event Type to delineate more of the 

reportable potential actions affecting a swap. The envisioned event identifier would track USIs 

affected by an event. An event may impact numerous swaps and counterparties. Staff believes 
37 

new data elements should be contemplated to effectively identify swaps associated with the 

event. Event_ID and Event_Type would assist Staff in better performing their regulatory 

obligations. The Event_Type data element is consistent with international Unique Transaction 

Identifier principles.

The data elements listed below in the draft technical specifications for certain swap data 

elements also include an Event_USI_Version, which is an integer that incrementally increases 

with each message received for a particular event for a particular USI. Event_USI_Version 

assists Staff in generating an up to date and correct representation of the current state of the 

swap.

Staff also has encountered difficulties tracking the sequence of events impacting specific 

USIs due to current swap data reporting methods and associated data elements. The data element 

USI_Version would allow Staff to address that problem and track that sequence. For instance, 

USI_Version would assist Staff with calculating the current state of swap transactions.

The data element Event_USI_Impact would allow Staff to identify how an event affects a 

specific USI. Event_USI_Impact would identify if a USI is created, retired, or if the associated 

event had no impact on the USI. 

The inconsistent reporting, either as a static or constantly changing swap data element, of 

Execution Timestamp has caused confusion for both Staff and market participants, both in 

identifying the original creation time and the time when a swap modification occurs. Staff

believes that using Event_Timestamp, in lieu of Execution Timestamp, would, when combined 

with Event_ID, Event_Type, USI_Impact, and USI_Version, resolve this challenge. 
38 

Compression

Swap 

(USI 51) 

Swap 

(USI 52) 

Swap 

(USI 53) 

Swap 

(USI 54) 

Swap 

(USI 55) 

Swap 

(USI 60) 

Swap 

(USI 61)

Swap 

(USI 62) 

For representative purposes, the above example represents a set of trade events that 

occurred before a compression event. The events with Event Type= “Trade” related to Event IDs 

21,22, 23, 24 and 25 resulted in the creation of swaps (Event USI Impact = “Create”) with USIs 

51, 52,53, 54 and 55. For illustration purposes, two digit IDs are used to represent the USIs. 

Message ID Event Version Event ID USI USI Version Event Type Event USI Impact

ABC405 1 21 51 1 TRADE CREATE

ABC406 1 22 52 1 TRADE CREATE

ABC407 1 23 53 1 TRADE CREATE

ABC408 1 24 54 1 TRADE CREATE

ABC409 1 25 55 1 TRADE CREATE

A compression event with Event Type = “COMPRESSION| MULTI_NETTING” 

identified by Event ID 30 follows the swap creation event resulting in the termination (Event 

USI Impact = “Retire”) of swaps with USIs 51, 52, 53, 54 and 55 and creation (Event USI 

Impact = “Create”) of three new swaps with USIs 60, 61 and 62. 

Message ID Event Version Event ID USI USI Version Event Type Event USI Impact

ABC411 1 30 51 2 COMPRESSION|

MULTI_NETTING

RETIRE

ABC412 1 30 52 2 COMPRESSION|

MULTI_NETTING

RETIRE
39 

Message ID Event Version Event ID USI USI Version Event Type Event USI Impact

ABC413 1 30 53 2 COMPRESSION|

MULTI_NETTING

RETIRE

ABC414 1 30 54 2 COMPRESSION|

MULTI_NETTING

RETIRE

ABC415 1 30 55 2 COMPRESSION|

MULTI_NETTING

RETIRE

ABC416 1 30 60 1 COMPRESSION|

MULTI_NETTING

CREATE

ABC417 1 30 61 1 COMPRESSION|

MULTI_NETTING

CREATE

ABC418 1 30 62 1 COMPRESSION|

MULTI_NETTING

CREATE

As an addendum to the Events reporting concept, the Event Type and Description table 

below further details the representation of key events and explains the relationship between 

messages, events, and associated Allowable Values.

Event Type Description

TRADE An event that results in a new swap being created. This event 

occurs in isolation and it is not a result of other events or tied to 

other existing swaps. 

TRADE|FORCE An event that results in a new swap being created. This event 

occurs in isolation and it is not a result of other events or tied to 

other existing swaps. A specific type of trade event where the 

match is forced by the pricing authority to maintain reliability of 

quotes.

NOVATION|3_WAY An event that has the effect of legally moving the risk 

represented in one swap to another counterparty that was not a 

counterparty in the existing swap. There is a transferor and a 

transferee.

NOVATION|4_WAY An event that has the effect of legally moving the risk 

represented in one swap to two counterparties who weren’t part 

of the existing swap. There are two transferors and two 

transferees.

NOVATION|STEP_IN An event that has the effect of legally moving equal and 

offsetting risk from two transferors to the same transferee.

NOVATION|STEP_OUT An event that has the effect of legally moving the risk from one 

transferor so that the two transferees become direct 

counterparties.

NOVATION|ALLOCATION The process by which a trade is allocated among various entities. 

COMPRESSION|BILAT_NETTING An event that results in the termination or reduction of the 

notional of existing swaps and possibly creating new swaps but 

results in largely the same net risk profile that existed prior to the 

event for a counterparty. There are two counterparties involved 

and the swaps have identical economic terms except notional.

COMPRESSION|MULTI_NETTING An event that results in the termination or reduction of notional 

of existing swaps and possibly creating new swaps but results in 

largely the same net risk profile that existed prior to the event for 

a counterparty. There are more than two counterparties 

participating in the same compression and the swaps have 

identical economic terms except notional.
40 

Event Type Description

COMPRESSION|BILAT_BLENDING An event that results in the termination or reduction of notional 

of existing swaps and possibly creating new swaps but results in 

largely the same net risk profile that existed prior to the event on 

a gross basis for a counterparty. There are two counterparties 

who reduce the number of swaps by blending certain 

characteristics like coupon.

COMPRESSION|MULTI_BLENDING An event that results in the termination or reduction of notional 

of existing swaps and possibly creating new swaps but results in 

largely the same net risk profile that existed prior to the event on 

a gross basis for a counterparty. There are more than two 

counterparties who reduce the number of swaps by blending 

certain characteristics like coupon.

COMPRESSION|BILAT An event that results in the termination or reduction of notional 

of existing swaps and possibly creating new swaps but results in 

largely the same net risk profile that existed prior to the event on 

a gross basis for a counterparty. There are two counterparties 

who reduce the number of swaps.

COMPRESSION|MULTI An event that results in the termination or reduction of notional 

of existing swaps and possibly creating new swaps but results in 

largely the same net risk profile that existed prior to the event on 

a gross basis for a counterparty. There are more than two 

counterparties who reduce the number of swaps.

TERMINATION An event that results in the full or partial termination of an 

existing swap.

TERMINATION|VOID An event that results in the full or partial termination of an 

existing swap. The termination of the contract that results from a 

legal decision that expunges the contract. 

CLEARING|AGENCY Central clearing is a process where a CCP interposes itself 

between counterparties to contracts, becoming the buyer to every 

seller and the seller to every buyer and thereby ensuring the 

performance of open contracts. A result of clearing (agency 

model), there are two new transactions between each original 

counterparty and the CCP.

CLEARING|PRINCIPAL Central clearing is a process where a CCP interposes itself 

between counterparties to contracts, becoming the buyer to every 

seller and the seller to every buyer and thereby ensuring the 

performance of open contracts. A result of clearing (principal 

model), there are up to four new transactions: between each 

counterparty and its respective clearing member and mirror 

transactions between each clearing member and the CCP. 

OPTION|EXERCISE Events associated with options. Event resulting in one party 

exercising the option.

OPTION|ASSIGNMENT Events associated with options. Where an intermediary assigns a 

part of the option exercise to counterparty.

TRANSFORMATION|FRAGMENT Events that change how swaps entered into the event are 

represented in the data but do not change the risks of the 

counterparties. The swap is broken into individual components.

TRANSFORMATION|COMBINE Events that change how swaps entered into the event are 

represented in the data but do not change the risks of the 

counterparties. The swap is created from individual components.

END_OF_LIFE|MATURITY An event that results in the termination of a swap that was 

predetermined by the contract, but required no action by the 

parties. The obligations no longer accrue and the final payment 

occurs due to the maturity of the swap. 
41 

Event Type Description

END_OF_LIFE|OPTION_EXPIRATION An event that results in the termination of a swap that was 

predetermined by the contract, but required no action by the 

parties due to the expiration of the option.

MODIFICATION|INCREASE Events that change terms in the swap without changing the USI. 

This is the result of an increase in exposure between 

counterparties.

MODIFICATION|BASKET_CHANGE Events that change terms in the swap without changing the USI. 

This is the result in the change in the members of the reference 

basket.

MODIFICATION|REFERENCE_CHANGE Events that change terms in the swap without changing the USI. 

This is the result of the change in reference.

MODIFICATION|AMENDMENT_OTHER Events that change terms in the swap without changing the USI. 

If the modification doesn’t fall in any of the above three types.

ERROR|CORRECTION_EVENT Events that occurred as the result of erroneous reporting that are 

not able to be corrected in serial message traffic. This event 

corrects a prior swap version.

ERROR|CANCEL_EVENT Events that occurred as the result of erroneous reporting that are 

not able to be canceled in serial message traffic. This event 

cancels a prior swap version.

CREDIT|SUCCESSION This credit specific asset class event is the result of succession. 

CREDIT|SPIN_OFF This credit specific asset class event is the result of spin off. 

CREDIT|AUCTION This credit specific asset class event is the result of auction. 

CREDIT|CASH_SETTLEMENT This credit specific asset class event is the result of cash 

settlement. 

60. Are there other ways to resolve the challenges encountered by Staff in understanding 

swap events? If so, please provide details regarding how these potential solutions 

illustrate both: (i) all of the events impacting a swap and (ii) the current status of a 

transaction? 

61. What are some of the challenges with the Event Types listed below? If so, please 

provide suggestions to address them. 

62. Is there any uncertainty regarding how Reporting Counterparties should determine 

whether an event is price-forming or not? 

63. What factors should Reporting Counterparties consider in determining whether an 

event is price-forming or not? 

64. Do the descriptions suggested for Event Types clearly convey when an event is price 

forming in nature or not? 
42 

65. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Event ID This is an ID for an 

event that takes place 

between the parties that 

changes the terms of the 

contract. 

Must be a value that will uniquely identify 

the event

Varchar

Event Type Type of event resulting 

in the creation, 

termination, or 

combination of the two, 

of one or more USIs.

TRADE

TRADE|FORCE

NOVATION|3_WAY

NOVATION|4_WAY

NOVATION|STEP_IN

NOVATION|STEP_OUT

NOVATION|ALLOCATION

COMPRESSION|BILAT_NETTING

COMPRESSION|MULTI_NETTING

COMPRESSION|BILAT_BLENDING

COMPRESSION|MULTI_BLENDING

TERMINATION

TERMINATION|VOID

CLEARING|AGENCY

CLEARING|PRINCIPAL

OPTION|EXERCISE

OPTION|ASSIGNMENT

TRANSFORMATION|FRAGMENT

TRANSFORMATION|COMBINE

END_OF_LIFE|MATURITY

END_OF_LIFE|OPTION_EXPIRATION

MODIFICATION|INCREASE

MODIFICATION|BASKET_CHANGE

MODIFICATION|REFERENCE_CHANGE

MODIFICATION|AMENDMENT_OTHER

ERROR|CORRECTION_EVENT

ERROR|CANCEL_EVENT

CREDIT|SUCCESSION

CREDIT|SPIN_OFF

CREDIT|AUCTION

CREDIT|CASH_SETTLEMENT

Varchar

Event 

DateTimestamp

The time stamp of the 

beginning of the event 

determined by the 

parties.

A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Event USI 

Version

This is the serial tracker 

for record keeping of a 

unique event-USI pair. 

The version should only 

increment up for the 

modification that 

affects an event USI 

pair. It will help 

maintain the correct 

order.

Integer greater than zero Integer
43 

Data Element Description Allowable Values Format/Standard

Message Type This describes how the 

message affects the data 

relating to the 

event/USI pair.

NEW = The first 

message relating to an 

event/USI pair. Any 

message that contains 

NEW on an existing 

event/USI pair should 

fail validation.

UPDATE = Provides 

additional values that 

have not been provided 

in prior message traffic. 

These are values that 

may not have been 

needed at the initiation 

of the event but become 

known as the event 

matures. One example 

would be the price of a 

transaction that was 

executed at a yet to be 

determined VWAP.

MODIFY = Changes 

values provided in prior 

message traffic due to 

negotiation. May also 

provide values not 

included in prior 

messages. Cannot be 

combined with a 

CORRECT message.

CORRECT =Change 

values provided in prior 

message traffic due to 

error. May also provide 

values not included in 

prior messages. Cannot 

be combined with a 

MODIFY message.

CANCEL = Cancels the 

event/USI pair. This 

would be assumed to 

nullify the effect of all 

prior message versions 

relating to the 

event/USI pair. 

NEW 

UPDATE 

MODIFY 

CORRECT 

CANCEL 

SNAPSHOT

 

Varchar
44 

Data Element Description Allowable Values Format/Standard

SNAPSHOT = 

Provides message of 

positions currently 

known by a reporting 

party but not relating to 

a specific event. This 

message type would 

include the data 

elements for 

Reconciliation, 

Valuation, and 

Collateral/Exposure. 

Price forming 

Event

As reported by the 

counterparties whether 

the event has any price 

discovery significance. 

Y

N

Char(1)

Transferee The counterparty 

stepping into the swap

Only current and valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

Transferor The counterparty 

stepping out of the 

swap

Only current and valid Legal Entity 

Identifiers (“LEIs”)

ISO 17442

USI Impact This data element 

describes the effect an 

Event has on the USI.

Create

Retire

None

USI Version Counter that identifies 

the number of events 

that has impacted a 

USI. This version will 

increment for each 

event related to the 

USI. Its primary 

purpose will be for 

validation and 

reconciliation.

Integer greater than zero Integer

USI Namespace Refer to:

http://www.cftc.gov/La

wRegulation/DoddFran

kAct/Rulemakings/DF_

17_Recordkeeping/usid

atastandards100112

Refer to:

http://www.cftc.gov/LawRegulation/DoddFr

ankAct/Rulemakings/DF_17_Recordkeeping

/usidatastandards100112

Refer to:

http://www.cftc.gov/

LawRegulation/Dodd

FrankAct/Rulemakin

gs/DF_17_Recordkee

ping/usidatastandards

100112

USI 

Transaction ID 

Refer to:

http://www.cftc.gov/La

wRegulation/DoddFran

kAct/Rulemakings/DF_

17_Recordkeeping/usid

atastandards100112

Refer to:

http://www.cftc.gov/LawRegulation/DoddFr

ankAct/Rulemakings/DF_17_Recordkeeping

/usidatastandards100112

Refer to:

http://www.cftc.gov/

LawRegulation/Dodd

FrankAct/Rulemakin

gs/DF_17_Recordkee

ping/usidatastandards

100112
45 

L. Rates

Staff is interested in gaining a greater understanding of the components associated with 

interest rate swaps. In particular, consistent representation of the underlying indices/benchmarks 

and clear identification of fixed and floating legs of interest rate swaps is warranted.

66. How should swap data reporting adapt to changing indices/benchmarks and/or 

bespoke indices/benchmarks used for the floating leg(s) of a swap? 

Interest rate swap transactions may have leverage embedded in the cash flows 

associated with a particular leg. For example, instead of a $1 million notional swap, parties 

may elect to enter into a $1 notional swap and apply 1 million multipliers to each leg. The 

data elements reported for the swap could imply a $1 notional swap, but actually contain the 

cash flows and risk of a $1 million notional swap. Staff needs to clearly understand whether 

the notional reported is the effective notional amount of the swap or the stated notional 

amount of the swap. 

67. Should swap data reporting select the multiplier approach or the effective notional 

approach? Please provide reasons for your selection. 

68. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 

Data Element Description Allowable Values Format/Standard

Fixed Rate Fixed interest rate value. Numeric value 5 digit decimal 

precision 

Value can be 

positive or negative

1% = 0.01000

Floating Rate 

Index 

Alphanumeric name of the reference 

index for the floating interest leg of a 

contract.

Valid index identifier Should 

be defined in ISDA 2006 

Definitions section 7.1 or be the 

identifier used by the 

administrator for that index

Varchar

Floating Rate 

Reset Frequency 

Period 

A time period (e.g., a day, week, or 

month) that together with the Floating 

Rate Reset Frequency Period 

D 

W 

M 

Char(1)
46 

Data Element Description Allowable Values Format/Standard

Multiplier define the frequency of 

floating rate leg resets

D = Day

W = Week

M = Month

Y = Year

T = Term 

Y 

T 

Payment 

Frequency 

Period

A time period (e.g., a day, week, or 

month) that together with the Payment 

Period Frequency Multiplier define 

the frequency of payments per leg.

D = day

W = week

M = month

Y = year

T = term

D 

W 

M 

Y 

T 

Varchar

Leg Spread Generally only applicable to floating 

legs, as fixed rate plus spread should 

be reported as the sum of the fixed 

rate and the spread (e.g., the reporting 

counterparty would not report 5% + 

30 bps in two data elements; it would 

report 5.30% in the fixed rate data 

element). The leg spread should be 

filled in for leg level option trades as 

well.

Numeric value, may be 

negative

Format: 5 digit 

decimal precision

Note: Floating 

point decimal 

representation of 

percentage

Example:

1 basis point will 

be represented as 

0.00010 

Leg 

Multiplier/Lever

age Factor

Multiplier or leverage factor that is 

applied to a leg’s cash flows after all 

other relevant calculations are 

performed. This is the last step before 

the final leg cash flow is determined.

Numeric value greater than 

zero

For trades with no embedded 

cash flow leverage, the reported 

entry will be 1 

Format: 5 digit 

decimal precision

Payment 

Frequency 

Period Multiplier

An integer multiplier of a time period 

describing how often the parties to the 

publicly reportable swap transaction 

exchange payments associated with 

each party’s obligation under the 

publicly reportable swap transaction. 

Such payment frequency may be 

described as one letter preceded by an 

integer.37

An integer greater than zero. Integer

Floating Rate 

Reset Frequency 

Period Multiplier

An integer multiplier of a time period 

describing how often the frequency of 

floating rate leg resets based on the 

rate of its index.

An integer greater than zero. Integer

Floating Rate 

Index Tenor 

Period

A time period (e.g., a day, week, or 

month) for the designated maturity of 

the index.

D = Day

D 

W 

M 

Y 

T 

Char(1)

 

37 See part 43, Table A1, “Description” of “Payment frequency 1” data element.
47 

Data Element Description Allowable Values Format/Standard

W = Week

M = Month

Y = Year

T = Term

Floating Rate 

Index Tenor 

Period Multiplier

An integer multiplier of a time period. An integer greater than zero. Integer

Day Count 

Convention

The day count convention is a 

description of how interest accrues 

over time and is a material term that is 

necessary for pricing certain swaps. 

Common day count convention 

methods include the 30/360 method 

and the Actual method.

1/1

30/360

30E/360

30E+/360

30E/360.ISDA

ACT/360

ACT/365.FIXED

ACT/365L

ACT/ACT.AFB

ACT/ACT.ICMA

ACT/ACT.ISDA

ACT/ACT.ISMA

BUS/252

Varchar

M. Foreign Exchange

Staff needs accurate information about reportable swap transactions in the foreign 

exchange asset class in order to perform Staff’s regulatory functions with respect to those swaps. 

Under present swap data reporting standards, the connectivity of the associated spot and forward 

transactions of a foreign exchange swap can be difficult to identify. 

69. How should the spot component of a jurisdictional foreign exchange swap 

transaction be represented? 

70. What are the swap data elements best suited to link the spot and forward components 

of a foreign exchange swap? 

71. Are there additional data elements that are needed for regulatory reporting of 

transactions in the foreign exchange asset class, including data elements that may be 

specific to particular types of foreign exchange transactions? 

72. Please provide feedback on any aspect of the draft technical specifications for the 

data elements presented below. 
48 

Data Element Description Allowable Values Format/Standard

Exchange Rate The currency exchange rate that 

corresponds to the ‘Exchange Rate 

Basis’ data element. Specifically, the 

number of currency units of the 

denominator currency that is equivalent 

to 1 unit of the numerator currency. 

Numeric value greater than 

zero.

5 digit decimal 

precision

Exchange Rate 

Basis

The currency exchange rate basis that 

comports with the ‘Exchange Rate’ data 

element. It is shown in the format 

“xxx/yyy” where “xxx” is the numerator 

currency and “yyy” is the denominator 

currency.

Valid ISO 4217 currency 

code

Format: Two 3-

character 

alphabetical 

separated by “/”

Note: “xxx/yyy” 

where “xxx” is the 

numerator currency 

and “yyy” is the 

denominator 

currency.

Standard: ISO 

4217 currency code

Fixing Date The date the rate used to calculate the 

settlement amount is determined.

Valid date Format: YYYYMM-DD

Standard: ISO 

8601/ UTC

Settlement 

Currency

The currency, if any, specified as such in 

the related Confirmation, and, if no 

currency is specified: (i) if the 

Underlying Transaction or the 

Transaction, as appropriate, involves one 

currency, that currency; or (ii) if the 

Underlying Transaction or the 

Transaction, as appropriate, involves 

more than one currency, the Termination 

Currency, if any, referred to in the 

related Confirmation and otherwise the 

currency in which Fixed Amount(s) 

under the Underlying Transaction or the 

Transaction, as appropriate, are payable.

Valid ISO 4217 currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 

4217 currency code

Date of 

Settlement

The periodic or final payment dates 

when pre-determined amounts in the 

Settlement Currency are paid or received 

so as to settle the outstanding payment. 

Valid date Format: YYYYMM-DD

Standard: ISO 

8601/ UTC

Delivery Type How the swap is settled

C = cash (use for non-FX related swaps)

P = physical

E = elect at settlement

A = auction

N = non-deliverable (use for FX related 

swaps)

C 

P 

E 

A 

N 

N. Other Data Elements

Data Element Description Allowable Values Format/Standard

Execution Venue 

ID

Unique code identifier of a Swap 

Execution Facility (SEF) or a 

Designated Contract Market (DCM) of 

Only current and valid 

Legal Entity Identifiers 

(“LEIs”)

ISO 17442
49 

Data Element Description Allowable Values Format/Standard

which the swap was executed. 

Trade Execution 

Requirement 

Indicator

The data element will indicate if the 

swap is subject to the trade execution 

requirement under CEA section 2(h)(8). 

If the swap is part of a package, then this 

element will capture each component.

Y

N 

Char(1)

Leg Receiver Unique LEI to define who will receive 

the type as specified in ‘Leg Type’.

Only current and valid 

Legal Entity Identifiers 

(“LEIs”)

ISO 17442

Leg Type The data element for Leg Type will 

specify what type of payment for the 

given stream is being traded and what 

each ID receives. 

Fixed

Float 

Option - Put 

Option - Call

Additional Fixed Payment

Other

CDS Protection Buyer

CDS Protection Seller

Initial Payment Amount

Varchar

Leg Payer Unique LEI to define who will pay the 

type as specified in ‘Leg Type’. 

Only current and valid 

Legal Entity Identifiers 

(“LEIs”)

ISO 17442

Effective Date The date that the transaction becomes 

effective. This should be the same as the 

“Effective or Start date data element in 

Table A1 of appendix A to part 43 

(“[t]he date that the publicly reportable 

swap transaction becomes effective or 

starts[]”) and the “Start Date” data 

category and data element in Exhibit A 

to appendix 1 to part 45 (“[t]he date on 

which the swap starts or goes into 

effect[.]”

A valid date Format: YYYYMM-DD

Standard: ISO 

8601 UTC

Scheduled 

Termination 

Date

The final contractual scheduled 

termination date of the swap. This 

should be the same as what part 45 

describes as “Maturity, termination or 

end date: The date on which the swap 

expires”. Interest rate swaps use the term 

Termination Date and credit default 

swaps use Scheduled Termination Date. 

It was determined that the term 

“Scheduled Termination Date” best 

clarified that it is the contractual 

termination date, and not the actual 

termination date which could occur due 

to an early optional termination.

A valid date Format: YYYYMM-DD

Standard: ISO 

8601 UTC

Business day 

convention

“Business Day Convention” means the 

convention for adjusting any relevant 

date if it would otherwise fall on a day 

that is not a Business Day. The 

following terms, when used in 

conjunction with the term “Business Day 

Convention” and a date, shall mean that 

an adjustment will be made if that date 

FOLLOWING

FRN 

MODFOLLOWING 

PRECEDING 

MODPRECEDING 

NEAREST

NONE

Varchar
50 

Data Element Description Allowable Values Format/Standard

would otherwise fall on a day that is not 

a Business Day so that: (i) if 

“Following” is specified, that date will 

be the first following day that is a 

Business Day; (ii) if “Modified 

Following” or “Modified” is specified, 

that date will be the first following day 

that is a Business Day unless that day 

falls in the next calendar month, in 

which case that date will be the first 

preceding day that is a Business Day; 

and (iii) if “Preceding” is specified, that 

date will be the first preceding day that 

is a Business Day.

Holiday calendar Calendar of holidays and official daysoff observed by the financial center 

specified. 

4 letter value from the 

FpML 

businessCenterScheme 

codelist.

Char(4)

Fixed Recovery 

CDS Final Price

As per ISDA Credit Derivatives 

definitions, if “Cash Settlement” is 

specified as the Settlement Method of 

the CDS then the “Cash Settlement 

Amount” upon a Credit Event will be the 

notional amount multiplied by the 

Reference Price minus the Final Price. 

Furthermore, based upon the “Additional 

Provisions for Fixed Recovery CDS 

Transactions” in the case of Fixed 

Recovery CDS’, the “Final Price” shall 

mean the percentage specified in the 

Confirmation. Therefore we are 

capturing this fixed percentage in this 

data element.

Numeric value greater than 

zero

5 digit decimal 

precision 1% = 

0.01000

Reference price As per ISDA Credit Derivatives 

definitions, the initial reference price 

established at the time of trade to be 

used in the case of a realized credit 

event. The percentage specified as such 

in the related Confirmation (100% if set 

at par. or, If no such percentage is 

specified, one hundred per cent is 

assumed).

Percentage value Format: 5 digit 

decimal precision

Note: Floating 

point decimal 

representation of 

percentage

Example:

1% should be 

represented as 

0.01000

O. General Questions

73. Are any of the Data Elements listed herein unclear? Do any Data elements require 

greater standardization? 
51 

74. Are any of the Descriptions inconsistent with common industry usage or your 

utilization of the data element?

75. Are there any additional Allowable Values that are required to properly represent the 

reporting of swap transactions? 

76. Is there a better electronic representation of the Data Elements that can be 

prescribed in the Format data element? 

77. Should “date” related Data Elements be adjusted or unadjusted? 

78. Is the Day Count Convention list of allowable values sufficient?

79. Are there any other data elements that reporting counterparties require in order to 

accurately reflect all of the economic terms of a swap transaction or adhere to 

existing reporting regulations? 

80. Are there other data elements not included in this draft technical specifications for 

certain swap data elements that you think should be prioritized for standardization? 

Please explain why and provide relevant information as per the draft technical 

specifications for certain swap data elements included in the Appendix, such as 

Description, Allowable Values, and Format.
A-1 

Appendix—Draft Technical Specifications For Certain Swap Data Elements

Data Element Description Allowable Values Format/Standard

Counterparty ID Unique code identifying the 

counterparty.

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Special 

entity/utility 

special entity 

Indicator

The terms “special entity” and “utility 

special entity” are defined at 23.401(c) 

and 

1.3 (ggg)(4)(i)(B)(2), respectively. Note 

that “utility special entity” is a subset of 

“special entity.”

SE = Special entity - Special Entities 

that are not Utility Special Entities 

should select SE as their entry. 

 

USE = Utility special entity - Utility 

special entities should select USE as 

their entry.

N = Counterparty is not a special entity 

or utility special entity

SE 

USE

N 

Varchar

Third Party 

Reporter ID

The ID of the Third Party Reporter or 

SEF.

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Submitter ID An entity submitting the data on behalf 

of a registered entity or swap 

counterparty to the SDR as allowed by § 

45.9.

The submitter ID will be the same as the 

reporting party ID or Third Party 

Reporter ID, unless either uses another 

service provider to submit the data to 

SDR.

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Ultimate Parent The term “Ultimate Parent” is defined at 

§ 45.6(a). 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Ultimate 

Guarantor 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Counterparty 

Dealing Activity 

Exclusion Type

Identifies the exclusion on which 

counterparty relies to exclude the swap 

from dealing activity. 

NE = No Exclusion; swap is a dealing 

swap for the CP: 

If NE applicable, only NE may be 

reported, else multiple entries may be 

reported for the same swap

Swaps not considered in determining 

whether the counterparty is a swap 

dealer:

IDI = §1.3(ggg)(5): Insured depository 

institution swaps in connection with 

originating loans to customers 

NE 

IDI 

IA

COOP 

PHYS

FLR 

NonUS

CMPRS

IFI

FX

CTO

Varchar
A-2 

Data Element Description Allowable Values Format/Standard

IA = §1.3(ggg)(6)(i): Inter-affiliate 

activities 

COOP = §1.3(ggg)(6)(ii): Activities of a 

cooperative 

PHYS = §1.3(ggg)(6)(iii): Swaps 

entered into for the purpose of hedging 

physical positions 

FLR = §1.3(ggg)(6)(iv): Swaps entered 

into by floor traders 

NonUS = Non-US Person 

CMPRS = CFTC Staff Letter No. 12-62 

(Dec. 21, 2012): Compression exercise 

swaps 

IFI = 77 FR at 30693: International 

Financial Institutions 

FX = Treasury Determination, 77 FR at 

69705: FX swap exclusion 

CTO = Regulation 32.3; 77 FR 25320, 

25326, note 39, Apr. 27, 2012; see 

generally 77 FR 25320 at 25325-29: 

(Commodity Trade Options) 

US Person 

Indicator for 

Ultimate 

Guarantor

Y

N

Char(1)

US Person 

Indicator for 

Ultimate Parent

Y

N

Char(1)

Counterparty US

Person Indicator

Y

N

Char(1)

Reporting 

Counterparty ID

The Reporting Counterparty as 

determined in accordance with 45.8.

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Counterparty 

Financial Entity 

Indicator

An indication of whether the 

counterparty is a financial entity as 

defined in CEA § 2(h)(7)(C).

Y

N

Char(1)

Prime Brokerage 

Indicator

Indicator of if a counterparty is acting as 

a prime broker for the other counterparty 

for the reported swap.

Y

N 

Char(1)

Asset Class This data element identifies the asset 

class for the swap. 

Credit

Rates

ForeignExchange

Commodity

Equity

Varchar

Par Spread The spread used to quote CDS indices. Number of Basis Points Format: 5 digit 

decimal precision
A-3 

Data Element Description Allowable Values Format/Standard

Example:

1 basis point will be 

represented as 

0.00010 

Price The price per swap excluding, where 

applicable, commission and accrued 

interest.

Numeric value of zero or 

greater

5 digit decimal 

precision

Price Type The type of pricing that is reported in the 

“Price” data element. 

Price

Spread 

Percentage

Upfront Points

Varchar

Price Currency An indication of the currency of the 

price if the price type is a price.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Notional 

Amount

The notional amount reflects the 

reference amount from which the 

contractual payments are determined. 

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Notional 

Currency

The currency associated with the 

notional amount

Valid ISO 4217 currency code 3-character

alphabetical 

Standard: ISO 4217 

currency code

Additional Fixed 

Payment 

Amount 

Numeric amount of Additional Fixed 

Payment

Numeric value of zero or 

greater

5 digit decimal 

precision 

Additional Fixed 

Payment 

Currency 

Currency code for Additional Fixed 

Payment

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Additional Fixed 

Payment Date

Date of Additional Fixed Payment (paid 

/ received)

Valid date Format: YYYY-MMDD

Standard: ISO 8601 

UTC

Additional Fixed 

Payment Payer 

ID

LEI of Payer of Additional Fixed 

Payment 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Additional Fixed 

Payment Type

Enumerated list of types of fixed 

payments

Initial Exchange 

Interim Exchange

Final Exchange 

Credit: Interest Shortfall 

Reimbursement 

Credit: Principal Shortfall 

Reimbursement 

Credit: Write Down 

Reimbursement

 

Brokerage

Varchar
A-4 

Data Element Description Allowable Values Format/Standard

Unwind

Correction

Cancellation

Amendment

Novation

Currency: Premium Exchange

Compression

Partial Termination 

Full Termination

Other

Initial Payment Amount

Additional Fixed 

Payment 

Receiver ID

LEI of Receiver of Additional Fixed 

Payment 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Option Buyer ID Identity of the buyer of an option Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Option Seller ID Identity of the seller of an option Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Option Strike The level or price at which an option 

may be exercised.

Numeric value zero or greater Format: 5 digit 

decimal precision

Note: If a percentage, 

floating point 

decimal 

representation of 

percentage

Example:

1% should be 

represented as 

0.01000

Option Strike 

Type

Identifies the type of the option strike 

price.

Price

Spread

FX Rate

Percentage

Upfront Points

Interest Rate

Varchar

Option Strike 

Currency

The currency of the option strike price if 

the option strike price type is a price.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Option Premium 

Amount

The amount a buyer pays for an option Numeric value 5 digit decimal 

precision

Option Premium 

Amount Type

Describes how the option premium 

amount is being represented.

Price

Spread

Varchar
A-5 

Data Element Description Allowable Values Format/Standard

Option Premium 

Currency

An indication of the currency of the 

option premium amount if the amount 

type is a price.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Option Type A description of the right to which the 

reporting party is entitled. Right to Pay 

and Right to Receive are applicable for 

interest rate swaptions only. Right to 

Buy protection and Right to Sell 

protection are applicable to credit index 

swaptions only.

Right to Pay

Right to Receive

Right to Buy Protection 

Right to Sell Protection

Call

Put

Chooser

Varchar

Earliest Exercise 

Datetime

Earliest time that an option may be 

exercised.

Valid date-timestamp greater 

than the date and time for 

execution and less than the 

date and time Scheduled 

Termination Date

Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Final Exercise 

Datetime

An indication of the date after which the 

option is no longer available for 

exercise.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC 

Option Style An indication of the exercise style of the 

option transaction.

American

Bermudan

European

Varchar

Embedded 

Option Indicator

An indication of whether or not the 

option data elements are for an 

embedded option 

Y

N 

Char(1)

Order ID Order ID refers to a numeric ID assigned 

by the SEF or DCM, for each 

counterparty, that refers to the order to 

trade the swap that led to the transaction. 

Order ID should be unique by execution 

venue and date.

Unique code generated by the 

SEF or DCM

 

Varchar

Order 

DateTimestamp

Time the order was received by the SEF 

or DCM

Valid date time Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Match 

DateTimestamp

Time the order was matched by the SEF 

or DCM

Valid date time Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Price Discovery RFQ = Request for Quote

AUC = Auction

WKP = Workup

CLOB = Central Limit Order Book

AIM = Actionable Indicative Message

RFC = Request for Cross

ORD = Orderbook

PME = Permitted Method of Execution

VRFQ = Voice Request for Quote

RFQ

AUC

WKP

CLOB

AIM

RFC

ORD

PME

VRFQ

Varchar

Price Order Price specific order designation.

Market = Market order – An order to 

buy (or sell) a product at the bid/offer 

Market 

MIT 

STOP

LIMIT

Varchar
A-6 

Data Element Description Allowable Values Format/Standard

price currently available in the 

marketplace.

MIT = Market if Touched – An order to 

buy (or sell) below (or above) the 

market. When trigger price is touched, 

the order is submitted as a market order.

STOP = Stop Order – Stop order 

becomes a market order at the specified 

stop price.

LIMIT = Limit order – An order to buy 

(or sell) at a specified price or better.

STOP LIMIT – Stop limit – Stop limit 

order becomes limit order at specified 

price.

LIT = Limit if touched - An order to buy 

(or sell) below (or above) the market at 

the limit price or better. When trigger 

price is touched, the order becomes a 

limit order.

TOP = Order set to either the best bid or 

offer price. Order will be cancelled if no 

longer best bid or offer.

STOP LIMIT

LIT 

TOP 

Customer type Distinguishes from whom and on what 

type of account the trades are being 

placed.

EBOA = For orders placed by an 

executing broker for his own account.

EBFP = For orders placed by an 

executing broker for a firm propriety 

account.

EBAB = For orders placed by an 

executing broker who also has access to 

the system.

EBFC = For orders placed by an 

executing broker on behalf of the 

customer.

EBOA

EBFP

EBAB

EBFC

Varchar

Execution Type Identifies instruments as required or 

permitted transactions on a SEF. 

REQ = Required

PERM = Permitted

REQ

PERM

Varchar

Order Source The source of where the order came 

from.

EXCH = Exchange activity

BLOCK = Off exchange block trade

EDRP = Exchange derivatives for 

related positions

XFER = Transfers

CUST = Portfolio Compression 

transactions

GIV = Giveup

VOICE = Voice trade

BUST = SEF busted trade

EXCH 

BLOCK 

EDRP 

XFER 

CUST

GIV

VOICE

BUST

Varchar

Block Trade This data element indicates that an Y Char(1)
A-7 

Data Element Description Allowable Values Format/Standard

Election 

Indicator

election has been made to report the 

swap as a block or large notional offfacility swap either by the reporting 

party or as calculated by the SDR acting 

as a third party for the Reporting Entity.

N

Package Trade 

Price

A package transaction is a transaction 

involving two or more instruments: (1) 

that is executed between two or more 

counterparties; (2) that is priced or 

quoted as one economic transaction, 

collection of swaps, securities, loans or 

other products that are traded as a single 

unit (one economic transaction). The 

data element will capture the traded 

price of the entire package or strategy in 

which the reported swap is a component.

Numeric value of zero or 

greater.

5 digit decimal 

precision

Package/Strategy 

ID

A package transaction is a transaction 

involving two or more instruments: (1) 

that is executed between two or more 

counterparties; (2) that is priced or 

quoted as one economic transaction. A 

package trade is a collection of swaps, 

securities, loans or other products that 

are traded as a single unit (one economic 

transaction). The data element will 

capture the ID of the entire package or 

strategy in which the reported swap is a 

component.

Must be a value that will 

uniquely identify the package 

or strategy that includes the 

executed swap.

Varchar

Package 

Contains NonCFTC Swap 

Components

The data element will indicate if the 

given package transaction contains 

elements that are not CFTC-regulated 

swaps and therefore not reported to 

SDRs, such as securities or futures.

Y

N 

Char(1)

Package Trade 

Price Type

The data element will indicate the type 

of price found in “Package Trade Price” 

data element.

Price

Spread

Percentage

Upfront Points

Varchar

Package Trade 

Price Currency

An indication of the currency of the 

package trade price if the package trade 

price type is a price.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217

currency code

Clearing 

Exemption Type

The type of clearing exemption(s) that 

is/are claimed by the counterparty.

Exceptions and exemptions to the swap 

clearing requirement. All applicable 

clearing exceptions must be selected:

NF-50.50 [non-financial end-user 

exception]

SB-50.50(d) [small bank end-user 

exception]

FC-50.51 [financial cooperative 

NF-50.50

SB-50.50(d) 

FC-50.51 

IA-50.52

NAL “Free Text”

Varchar
A-8 

Data Element Description Allowable Values Format/Standard

exemption]

IA-50.52 [inter-affiliate exemption]

NAL “Free Text”- The term entity 

entering the data for this data element 

must enter No Action letter and Free text 

with the letter number (e.g. “NAL 14-

144).

Clearing 

Organization ID

Clearing Organization ID should be 

populated with the valid Legal Entity 

Identifiers (“LEIs”) of the clearing 

organization that has cleared the swap. 

Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Intent to Clear 

Indicator

Indication of whether the swap is 

expected to be cleared. For swaps that 

have resulted from the clearing of a 

previous swap that has been since 

terminated, this data element should be 

populated with a value of “N”.

Y

N 

Char(1)

Mandatory 

Clearing 

Indicator

Indication of whether the characteristics 

of the swap meet the requirements for 

mandatory clearing. 

Y

N 

Char(1)

Cleared Date 

Time Stamp

The date time stamp of when the trade 

was accepted for clearing. Reported by 

derivatives clearing organization. 

If the time portion is unknown, it should 

be designated as midnight UTC 

(00:00:00Z) on the date accepted for 

clearing.

A valid date time stamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Counterparty ID 

Claiming 

Clearing 

Exemption 

The ID of the Counterparty claiming the 

clearing exemption(s)

Only current and valid Legal 

Entity Identifiers (“LEIs”) 

ISO 17442

Part 43/45/46 Indicates if the record is being submitted 

pursuant to part 43, part 45, or part 46, 

or both part 43 and part 45. 

43

45

46

43,45

Varchar

Data Accuracy 

Confirmation by 

Counterparty

Indication of whether or not each 

counterparty to a trade has actively 

affirmed, actively disputed, or failed to 

affirm that the SDR’s record of its trade 

is correct. 

The value FailedToRespond means no 

active affirmation or dispute has been 

received within 48 hours of trade. 

Affirm 

Dispute

FailedToRespond 

Varchar

Date and time of 

last open swaps 

reconciliation 

with CP

Date and time of the most recent 

reconciliation of material terms for 

outstanding open swaps by SDs/MSPs. 

This reconciliation is done between 

counterparties of open swaps. 

A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Date and time of 

last open swaps 

Date and time of the most recent 

verification of primary economic terms 

A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ
A-9 

Data Element Description Allowable Values Format/Standard

reconciliation 

with SDR

for outstanding open swaps. This 

reconciliation is done between swap data 

repositories and counterparties of open 

swaps.

Standard: ISO 8601/ 

UTC

Dissemination 

ID

Links the ID of the publicly 

disseminated swap, as it appears on the 

part 43 real-time ticker, to the part 43 

message as received by the SDR and 

viewable in the SDR portal.

Varchar

Next Reset Date The next date on which a floating 

reference becomes known for a swap.

A valid date Format: YYYY-MMDD

Standard: ISO 8601/ 

UTC

Leg NPV The net present value of a cash-flow 

stream as calculated by the 

counterparties from the perspective of 

the reporting counterparty.

Numeric value. May be 

negative.

5 digit decimal 

precision 

Leg NPV 

Currency

The currency the Leg NPV is reported 

in.

Valid ISO 4217 Currency 

code

Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Valuation 

Datetime

Datetime of the last valuation. A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Valuation 

Amount

Numeric portion of the value of a 

contract from the perspective of the 

reporting counterparty.

Numeric value. May be 

negative 

5 digit decimal 

precision

Valuation 

Currency

Currency associated with the valuation 

amount.

Valid ISO 4217 currency code 3-character 

alphabetical 

Standard: ISO 4217

currency code

Valuation Type Indication of whether valuation is mark 

to market or mark to model.

M = Mark to Market

O = Mark to Model

M

O 

Char(1)

Close Out 

Netting Set 

Portfolio and 

Collateral 

Valuation 

Currency

Currency associated with:

 - Close Out Netting Set Portfolio Net 

Mark To Market Valuation

 - Close Out Netting Set Independent 

Amount/Initial Margin requirement

 - Close Out Netting Set Variation 

margin requirement

 - Close Out Netting Set Collateral 

Posted Valuation

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Close Out 

Netting Set 

Independent 

Amount/Initial 

Margin 

requirement

Sum of all independent amount and/or 

initial margin requirements to be posted 

by each CP in the close out netting set. 

Value reported here is not the actual 

value of Independent Amounts (IA) 

and/or Initial Margin (IM) posted; 

instead this is the sum contractual IA/IM 

Numeric value of zero or

greater. 

5 digit decimal 

precision
A-10 

Data Element Description Allowable Values Format/Standard

requirements from each counterparty 

(CP) for the close out netting set. 

Close Out 

Netting Set 

Variation margin 

requirement

Variation margin requirement. 

Value reported here is not the actual 

value of variation margin posted; instead 

this is the contractual VM requirement 

from each CP for the close out netting 

set.

Numeric value of zero or 

greater. 

5 digit decimal 

precision 

Close Out 

Netting Set ID 

(unique)

Unique ID agreed to by both 

counterparties identifying a portfolio of 

transactions that are netted for close 

out/early termination purposes. 

Unique internal ID code 

generated by each 

counterparty to represent a 

distinct netting set. 

Varchar(50)

Close Out 

Netting Set 

Collateral Posted 

Valuation

The total value of all collateral posted by 

either CP to the other (collateral posted 

by each CP reported separately) in a 

single valuation currency after the 

effects of applying any Valuation 

Percentage or haircut to the collateral.

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Close Out 

Netting Set 

Portfolio Net 

Mark To Market 

Valuation

Close out netting set/portfolio level (not 

trade by trade) fair values reported from 

the Reporting Counterparty’s point of 

view. Positive value = Reporting 

Counterparty asset = other counterparty 

liability. Negative value = Reporting 

Counterparty liability = other 

counterparty asset.

Portfolio values should be reported using 

the relevant “fair value” accounting 

standard applicable to the reporting 

party.

Numeric value. Can be 

negative.

5 digit decimal 

precision 

Close Out 

Netting Set 

Collateral 

Weighted 

Average 

Valuation 

Percentage

Weighted average Valuation Percentage 

derived from the actual collateral posted. 

Numeric value of zero or 

greater.

5 digit decimal 

precision 

Close Out 

Netting Set 

Collateral Posted 

Valuation 

Date/Time

For each CP, date and time when the 

collateral posted into a close out netting 

set is valued.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Close Out 

Netting Set 

Portfolio Net 

Mark To Market 

Valuation 

Date/Time

Date and time when a close out netting 

set portfolio is valued.

Valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Event ID This is an ID for an event that takes 

place between the parties that changes 

the terms of the contract. 

Must be a value that will 

uniquely identify the event

Varchar

Event Type Type of event resulting in the creation, 

termination, or combination of the two, 

TRADE

TRADE|FORCE

Varchar
A-11 

Data Element Description Allowable Values Format/Standard

of one or more USIs. NOVATION|3_WAY

NOVATION|4_WAY

NOVATION|STEP_IN

NOVATION|STEP_OUT

NOVATION|ALLOCATION

COMPRESSION|BILAT_NE

TTING

COMPRESSION|MULTI_NE

TTING

COMPRESSION|BILAT_BL

ENDING

COMPRESSION|MULTI_BL

ENDING

TERMINATION

TERMINATION|VOID

CLEARING|AGENCY

CLEARING|PRINCIPAL

OPTION|EXERCISE

OPTION|ASSIGNMENT

TRANSFORMATION|FRAG

MENT

TRANSFORMATION|COMB

INE

END_OF_LIFE|MATURITY

END_OF_LIFE|OPTION_EX

PIRATION

MODIFICATION|INCREAS

E 

MODIFICATION|BASKET_

CHANGE

MODIFICATION|REFEREN

CE_CHANGE

MODIFICATION|AMENDM

ENT_OTHER

ERROR|CORRECTION_EVE

NT

ERROR|CANCEL_EVENT

CREDIT|SUCCESSION

CREDIT|SPIN_OFF

CREDIT|AUCTION

CREDIT|CASH_SETTLEME

NT

Event 

DateTimestamp

The time stamp of the beginning of the 

event determined by the parties.

A valid date-timestamp Format: YYYY-MMDDThh:mm:ssZ

Standard: ISO 8601/ 

UTC

Event USI 

Version

This is the serial tracker for record

keeping of a unique event-USI pair. The 

version should only increment up for the 

modification that affects an event USI 

pair. It will help maintain the correct 

order.

Integer greater than zero Integer

Message Type This describes how the message affects 

the data relating to the event/USI pair.

NEW 

UPDATE 

MODIFY 

Varchar
A-12 

Data Element Description Allowable Values Format/Standard

NEW = The first message relating to an 

event/USI pair. Any message that 

contains NEW on an existing event/USI 

pair should fail validation.

UPDATE = Provides additional values 

that have not been provided in prior 

message traffic. These are values that 

may not have been needed at the 

initiation of the event but become known 

as the event matures. One example 

would be the price of a transaction that 

was executed at a yet to be determined 

VWAP.

MODIFY = Changes values provided in 

prior message traffic due to negotiation. 

May also provide values not included in 

prior messages. Cannot be combined 

with a CORRECT message.

CORRECT =Change values provided in 

prior message traffic due to error. May 

also provide values not included in prior 

messages. Cannot be combined with a 

MODIFY message.

CANCEL = Cancels the event/USI pair. 

This would be assumed to nullify the 

effect of all prior message versions 

relating to the event/USI pair. 

SNAPSHOT = Provides message of 

positions currently known by a reporting 

party but not relating to a specific event. 

This message type would include the 

data elements for Reconciliation, 

Valuation, and Collateral/Exposure. 

CORRECT 

CANCEL 

SNAPSHOT

 

Price forming 

Event

As reported by the counterparties 

whether the event has any price 

discovery significance. 

Y

N 

Char(1)

Transferee The counterparty stepping into the swap Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Transferor The counterparty stepping out of the 

swap

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

USI Impact This data element describes the effect an 

Event has on the USI.

Create

Retire

None

USI Version Counter that identifies the number of 

events that has impacted a USI. This 

version will increment for each event 

related to the USI. Its primary purpose 

will be for validation and reconciliation.

Integer greater than zero Integer

USI Namespace Refer to: Refer to: Refer to:
A-13 

Data Element Description Allowable Values Format/Standard

http://www.cftc.gov/LawRegulation/Do

ddFrankAct/Rulemakings/DF_17_Recor

dkeeping/usidatastandards100112

http://www.cftc.gov/LawRegu

lation/DoddFrankAct/Rulema

kings/DF_17_Recordkeeping/

usidatastandards100112

http://www.cftc.gov/

LawRegulation/Dodd

FrankAct/Rulemakin

gs/DF_17_Recordkee

ping/usidatastandards

100112

USI Transaction 

ID 

Refer to:

http://www.cftc.gov/LawRegulation/Do

ddFrankAct/Rulemakings/DF_17_Recor

dkeeping/usidatastandards100112

Refer to:

http://www.cftc.gov/LawRegu

lation/DoddFrankAct/Rulema

kings/DF_17_Recordkeeping/

usidatastandards100112

Refer to:

http://www.cftc.gov/

LawRegulation/Dodd

FrankAct/Rulemakin

gs/DF_17_Recordkee

ping/usidatastandards

100112

Fixed Rate Fixed interest rate value. Numeric value 5 digit decimal 

precision 

Value can be positive 

or negative

1% = 0.01000

Floating Rate 

Index 

Alphanumeric name of the reference 

index for the floating interest leg of a 

contract.

Valid index identifier Should 

be defined in ISDA 2006 

Definitions section 7.1 or be 

the identifier used by the 

administrator for that index

Varchar

Floating Rate 

Reset Frequency 

Period 

A time period (e.g., a day, week, or 

month) that together with the Floating 

Rate Reset Frequency Period Multiplier 

define the frequency of floating rate leg 

resets

D = Day

W = Week

M = Month

Y = Year

T = Term 

D 

W 

M 

Y 

T 

Char(1)

Payment 

Frequency 

Period

A time period (e.g., a day, week, or 

month) that together with the Payment 

Period Frequency Multiplier define the 

frequency of payments per leg.

D = day

W = week

M = month

Y = year

T = term

D 

W 

M 

Y 

T 

Varchar

Leg Spread Generally only applicable to floating 

legs, as fixed rate plus spread should be 

reported as the sum of the fixed rate and

the spread (e.g., the reporting 

counterparty would not report 5% + 30 

bps in two data elements; it would report 

5.30% in the fixed rate data element). 

The leg spread should be filled in for leg 

level option trades as well.

Numeric value, may be 

negative

Format: 5 digit 

decimal precision

Note: Floating point 

decimal 

representation of 

percentage

Example:

1 basis point will be 

represented as 
A-14 

Data Element Description Allowable Values Format/Standard

0.00010 

Leg 

Multiplier/Lever

age Factor

Multiplier or leverage factor that is 

applied to a leg’s cash flows after all 

other relevant calculations are 

performed. This is the last step before 

the final leg cash flow is determined.

Numeric value greater than 

zero

For trades with no embedded 

cash flow leverage, the 

reported entry will be 1 

Format: 5 digit 

decimal precision

Payment 

Frequency 

Period Multiplier

An integer multiplier of a time period 

describing how often the parties to the 

publicly reportable swap transaction 

exchange payments associated with each 

party’s obligation under the publicly 

reportable swap transaction. Such 

payment frequency may be described as 

one letter preceded by an integer.

An integer greater than zero. Integer

Floating Rate 

Reset Frequency 

Period Multiplier

An integer multiplier of a time period 

describing how often the frequency of 

floating rate leg resets based on the rate 

of its index.

An integer greater than zero. Integer

Floating Rate 

Index Tenor 

Period

A time period (e.g., a day, week, or 

month) for the designated maturity of 

the index.

D = Day

W = Week

M = Month

Y = Year

T = Term

D 

W 

M 

Y 

T 

Char(1)

Floating Rate 

Index Tenor 

Period Multiplier

An integer multiplier of a time period. An integer greater than zero. Integer

Day Count 

Convention

The day count convention is a 

description of how interest accrues over 

time and is a material term that is 

necessary for pricing certain swaps. 

Common day count convention methods 

include the 30/360 method and the 

Actual method.

1/1

30/360

30E/360

30E+/360 

30E/360.ISDA

ACT/360

ACT/365.FIXED

ACT/365L

ACT/ACT.AFB

ACT/ACT.ICMA

ACT/ACT.ISDA

ACT/ACT.ISMA

BUS/252

Varchar

Exchange Rate The currency exchange rate that 

corresponds to the ‘Exchange Rate 

Basis’ data element. Specifically, the 

number of currency units of the 

denominator currency that is equivalent 

to 1 unit of the numerator currency. 

Numeric value greater than 

zero.

5 digit decimal 

precision

Exchange Rate 

Basis

The currency exchange rate basis that 

comports with the ‘Exchange Rate’ data 

element. It is shown in the format 

“xxx/yyy” where “xxx” is the numerator 

Valid ISO 4217 currency code Format: Two 3-

character alphabetical 

separated by “/”

Note: “xxx/yyy” 
A-15 

Data Element Description Allowable Values Format/Standard

currency and “yyy” is the denominator 

currency.

where “xxx” is the 

numerator currency 

and “yyy” is the 

denominator 

currency.

Standard: ISO 4217 

currency code

Fixing Date The date the rate used to calculate the 

settlement amount is determined.

Valid date Format: YYYY-MMDD

Standard: ISO 8601/ 

UTC

Settlement 

Currency

The currency, if any, specified as such in 

the related Confirmation, and, if no 

currency is specified: (i) if the 

Underlying Transaction or the 

Transaction, as appropriate, involves one 

currency, that currency; or (ii) if the 

Underlying Transaction or the 

Transaction, as appropriate, involves 

more than one currency, the Termination 

Currency, if any, referred to in the 

related Confirmation and otherwise the 

currency in which Fixed Amount(s) 

under the Underlying Transaction or the 

Transaction, as appropriate, are payable.

Valid ISO 4217 currency code Format: 3-character 

alphabetical 

Standard: ISO 4217 

currency code

Date of 

Settlement

The periodic or final payment dates 

when pre-determined amounts in the 

Settlement Currency are paid or received 

so as to settle the outstanding payment. 

Valid date Format: YYYY-MMDD

Standard: ISO 8601/ 

UTC

Delivery Type How the swap is settled

C = cash (use for non-FX related swaps)

P = physical

E = elect at settlement

A = auction

N = non-deliverable (use for FX related 

swaps)

C 

P 

E 

A 

N 

Execution Venue 

ID

Unique code identifier of a Swap 

Execution Facility (SEF) or a 

Designated Contract Market (DCM) of 

which the swap was executed. 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Trade Execution 

Requirement 

Indicator

The data element will indicate if the 

swap is subject to the trade execution 

requirement under CEA section 2(h)(8). 

If the swap is part of a package, then this 

element will capture each component.

Y

N 

Char(1)

Leg Receiver Unique LEI to define who will receive 

the type as specified in ‘Leg Type’.

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Leg Type The data element for Leg Type will 

specify what type of payment for the 

given stream is being traded and what 

each ID receives. 

Fixed

Float 

Option - Put 

Option - Call

Additional Fixed Payment

Other

CDS Protection Buyer

Varchar
A-16 

Data Element Description Allowable Values Format/Standard

CDS Protection Seller

Initial Payment Amount

Leg Payer Unique LEI to define who will pay the 

type as specified in ‘Leg Type’. 

Only current and valid Legal 

Entity Identifiers (“LEIs”)

ISO 17442

Effective Date The date that the transaction becomes 

effective. This should be the same as the 

“Effective or Start date data element in 

Table A1 of appendix A to part 43 

(“[t]he date that the publicly reportable 

swap transaction becomes effective or 

starts[]”) and the “Start Date” data 

category and data element in Exhibit A 

to appendix 1 to part 45 (“[t]he date on 

which the swap starts or goes into 

effect[.]”

A valid date Format: YYYY-MMDD

Standard: ISO 8601 

UTC

Scheduled

Termination 

Date

The final contractual scheduled 

termination date of the swap. This 

should be the same as what part 45 

describes as “Maturity, termination or 

end date: The date on which the swap 

expires”. Interest rate swaps use the term 

Termination Date and credit default 

swaps use Scheduled Termination Date. 

It was determined that the term 

“Scheduled Termination Date” best 

clarified that it is the contractual 

termination date, and not the actual 

termination date which could occur due 

to an early optional termination.

A valid date Format: YYYY-MMDD

Standard: ISO 8601 

UTC

Business day 

convention

“Business Day Convention” means the 

convention for adjusting any relevant 

date if it would otherwise fall on a day 

that is not a Business Day. The 

following terms, when used in 

conjunction with the term “Business Day 

Convention” and a date, shall mean that 

an adjustment will be made if that date 

would otherwise fall on a day that is not 

a Business Day so that: (i) if 

“Following” is specified, that date will 

be the first following day that is a 

Business Day; (ii) if “Modified 

Following” or “Modified” is specified, 

that date will be the first following day 

that is a Business Day unless that day 

falls in the next calendar month, in 

which case that date will be the first 

preceding day that is a Business Day; 

and (iii) if “Preceding” is specified, that 

date will be the first preceding day that 

is a Business Day.

FOLLOWING

FRN 

MODFOLLOWING 

PRECEDING 

MODPRECEDING 

NEAREST

NONE

Varchar

Holiday calendar Calendar of holidays and official daysoff observed by the financial center 

specified. 

4 letter value from the FpML 

businessCenterScheme 

codelist.

Char(4)
A-17 

Data Element Description Allowable Values Format/Standard

Fixed Recovery 

CDS Final Price

As per ISDA Credit Derivatives 

definitions, if “Cash Settlement” is 

specified as the Settlement Method of 

the CDS then the “Cash Settlement 

Amount” upon a Credit Event will be the 

notional amount multiplied by the 

Reference Price minus the Final Price. 

Furthermore, based upon the “Additional 

Provisions for Fixed Recovery CDS 

Transactions” in the case of Fixed 

Recovery CDS’, the “Final Price” shall 

mean the percentage specified in the 

Confirmation. Therefore we are 

capturing this fixed percentage in this 

data element.

Numeric value greater than 

zero

5 digit decimal 

precision 1% = 

0.01000

Reference price As per ISDA Credit Derivatives 

definitions, the initial reference price 

established at the time of trade to be 

used in the case of a realized credit 

event. The percentage specified as such 

in the related Confirmation (100% if set

at par. or, If no such percentage is 

specified, one hundred per cent is 

assumed).

Percentage value Format: 5 digit 

decimal precision

Note: Floating point 

decimal 

representation of 

percentage

Example:

1% should be 

represented as 

0.01000