8/22/2013

Phase 1 v1

External 1

1

2

3

4

5

6

7

8

9

Fields should be used for only one purpose.

Harmonization: Document Introduction

As part of a larger SDR Data Harmonization effort, CFTC is incrementally developing and publishing SDR data 

standards. The data elements identified in this document represent the first set of SDR swap data elements for 

harmonization. This is an iterative process where additional fields will be added in subsequent phases/publications of 

this document. Each data element is numbered where the first number represents the Phase (in this case the numbers 

start with one as the associated data elements were identified in the first phase of the effort), followed by a dash, and 

a sequential number. As additional fields are included in subsequent phases of the data 

standardization/harmonization effort, each new data element will receive a number that identifies the phase in which 

the field was identified for harmonization. For example, currently the 'Submitter Name' data element is numbered as 

1-2 where the number '1' indicates the standardization was requested in phase 1 of the effort and the number two 

indicates the data element was second on the phase 1 list of data elements. Phase two data elements will start with 

the number '2' and so on.

The objectives for issuing data standards documentation are to provide guidance to all SDRs to ensure key data 

elements are uniformly populated, formatted, named and enumerated. Uniform data elements support CFTC 

requirements to report across the OTC derivatives market and across all SDRs.

Guiding Harmonization Principles

When reporting the data elements identified in this document name them as defined in the Data Element 

column of the worksheet entitled Phase 1-Harmonization Data Elements. The focus for this phase of 

harmonization is on fields as contained in portal data downloads.

Data requirements are dynamic in that they change over time. As such, the requirements identified in this 

document and in subsequent harmonization phases may be revisited over time and as necessary to support new 

and/or changing Commission requirements.

Names as associated with Legal Entity Identifiers (LEI) should match the CICI registration legal name at the time 

the swap was reported.

Swaps clearly flagged as historical and/or voluntarily submitted are not currently the focus of this phase of 

harmonization. 

Boolean data elements should always be represented as ‘Y’ or ‘N’.

Fields should represent and describe a single data element. For example, the ISDA CDS Product taxonomy string 

of Credit:Index:iTraxx:iTraxxEurope represents four separate data elements in a single field delimited with colons 

as follows: asset class, base product, sub product, transaction type. Each data element should be individually 

represented in its own field.

Every effort should be made to harmonize across asset classes where a data element exists in more than one 

asset class. On encountering challenges implementing harmonization guidance across asset classes, the issue(s) 

should be raised and discussed. With that said, issues in non-CDS asset classes should not hinder CDS asset class 

harmonization efforts. CDS harmonization will be discussed at the September TAC so this effort cannot be 

delayed as a result of harmonization in other asset classes. 

Harmonization data elements 

• Should be ‘baselined’ at the start of each harmonization phase. 

• Should each have custom measures that allow the SDR and CFTC to measure data quality improvement (inter 

and intra SDR) when compared against the original baseline. Measures should be reportable. Measures should 

be the same across SDRs where possible.

• Should have supporting reports and status updates created and maintained by the SDR illustrating progress. 
8/22/2013

Phase 1 v1

External 2

Guiding Harmonization Principles

10

11

12

13

14

15

16

To ensure consistency of data, name fields should be populated by looking up reference data based on the 

associated reference identifiers.

Meaning should not be inferred through the use of column titles but explicitly expressed in data values.

Data elements identified as required must be populated in all instances. Data elements identified as 

conditionally required must be populated in the instances noted. 

To ensure data integrity, edits should be applied to related fields. For example, if a swap is cleared, one of the 

counterparty names and LEI IDs should be a DCO or if the swap allocated flag is set the execution agent 

information should be populated.

Data element harmonization should be applied across all data entities (open swaps, events, etc.) except as noted 

otherwise.

While the Commission has tried to be fully inclusive when identifying values for enumerated fields, the relative 

'newness' of SDR swaps reporting makes that difficult. When an SDR identifies situations that require additional 

enumerations where the current list does not adequately or appropriately describe the situation, the SDR should 

notify the Commission. The Commission and the SDRs will work together to add the enumerated value and to 

update the harmonization documentation accordingly. Additionally, the SDR should develop processes by which 

to accept these submissions but to flag them so that they can be tracked and corrected once the new 

enumerated value is added.

When standardizing data elements across the SDRs, consider the guidance below: 

• When satisfying data element harmonization requirements, the SDRs may calculate a harmonization data 

element from data already submitted by participants. 

• String data elements should not contain leading or trailing spaces. Words should be separated by only one 

space.

• Where appropriate, data elements should have common enumerated values across SDRs. Where an industry 

standard(s) exists, the standard(s) should be reviewed across SDRs. If the standard is reasonable it should be 

applied across SDRs. Where no standard exists, the SDRs, in coordination with the Commission, should develop 

a common list of enumerations. 
9/10/2013

Phase & Nbr Data Element Asset Classes

1-1 Submitter

ID

All

1-2 Submitter

Name

All

1-3 Submitter ID Source All

1-4 Third Party Rpted Indicator All

1-5 Trade Party 1 ID All

1-6 Trade Party 1 Name All

1-7 Trade Party 1 ID Source All

1-8 Trade Party 1 Status All

1-9 Trade Party 1 US Person Indicator All

1-10 Trade Party 1 Financial Entity

Indicator

All

1-11 Party 1 Execution Agent ID All

1-12 Party 1 Execution Agent Name All

1-13 Party 1 Execution Agent ID Source All

1-14 Execution Timestamp All

1-15 Reference Entity ID CDS

1-16 Reference Entity ID Source CDS

1-17 Reference Entity ID Description CDS

1-18 Version CDS

1-19 Series CDS

1-20 Asset Class CDS

1-21 Base Product CDS

1-22 Sub Product CDS

1-23 Transaction Type CDS

1-24 Notional Currency CDS

1-25 Scheduled Termination Date CDS

1-26 Clearing Organization Name All

1-27 Clearing Organization ID All

1-28 Clearing Organization ID Source All

1-29 Clearing Indicator All

1-30 Intent to Clear Indicator CDS

1-31 Reporting Party ID All

1-32 Non-reporting Party ID All

1-33 Voluntarily Submitted ID All

Data elements numbered 1-5 through 1-13 below may repeat N times 

depending on the number of counter parties associated with the swap.

Data elements numbered 1-15 through 1-23 below may repeat N times 

depending on the asset class and type of swap reported.

DATA ELEMENTS TO HARMONIZE

Data elements may include PET data fields from Part 45 or

Part 43, as well as SDR information as defined in Part 49