Seeing what the CFTC Sees
      Back to home
      1. Knowledge Base
      2. Repository - CFTC SDR
      3. Seeing what the CFTC Sees

      How are the CFTC reports defined?

      The CFTC’s regulations in part 49 require the SDRs to submit certain reports to the CFTC.[1] The Guidebook provides the instructions for SDRs to submit 5 specific reports to the CFTC in the form of files. Those reports are the Daily Transactions, Daily Open Swaps, Daily Collateral/Margin, Daily Valuations, and Daily Real-Time Disseminations. Beginning on Compliance Date, the SDRs must adhere to the requirements defined in this Guidebook for all files, when transmitting to the CFTC.

      [1] See e.g., 17 CFR 49.9, 49.17(c)(1), and 49.30. See also, 17 CFR 49.31.

      Items to note:

      • Format: Each file must contain a header row as its first row. That row will have the file header name of each field delimited by pipe characters. The data is reported in pipe ‘|’ delimited format using the Data Dictionary fields. Each submitted field can be a maximum length of 500 characters, if not explicitly limited to a shorter field length specified below in section 3.1. However, each SDR must accept and store as much of the value submitted by the participants as technologically possible. Further, all value(s) in the fields should be enclosed in double quotes (" "). The file header names are listed in the Data Dictionary tables in section 3.1. The file extension is .csv.

      • Repeating Values: Fields that require reporting of multiple values in a single field can be reported using a delimiter between the reported values. The example below uses a semi-colon for Clearing swap UTIs [#6] which requires multiple UTIs resulting from clearing. The choice of delimiter is left to the discretion of the SDR but the delimiter usage must be the same in all files. In addition, all values within the field must be encapsulated using double quotes, as referenced in § 2.3.1. Participants submitting swap data must adhere to the implementation procedures established by the SDR to whom it submits. Fields that allow multiple values for submission to CFTC have a standard variable length of 500 characters as the data type regardless of how each SDR is collecting from their participants. For the fields that are from the CFTC Technical Specification (“tech spec”), it is expected the SDRs will validate on the inbound submissions for appropriate data types as specified in the tech spec. 

      • Fields: For every asset class, each field is specified with Mandatory, Conditionally Mandatory, Optional, and Not Required as shown in the table below along with the definitions for each validation code. The fields apply to all SDRs unless otherwise noted with the acronym of the SDR(s) in the definition. Additionally, before the Unique Product Identifier (UPI) is available, the SDRs should provide the values from their equivalent field(s) it receives for the UPI reference data library (RDL) fields listed in the Guidebook. The validations are identical to the published Technical Specification. Generally speaking, the validations included in the Technical Specification for leg-based data elements are meant to apply to the first leg (Leg 1); it should not be presumed the validations apply to the second leg (Leg 2). This is due in large part to the conditionality between leg fields and in light of the fact that SDR-specific fields can alter the application of the published validations in ways not contemplated in the Technical Specification. Given this, SDRs may incorporate other validations for leg-level fields, should they deem it necessary.

      • Short Messages: The SDRs are permitted to accept “short messages” or submission with reduced number of required fields for some action types (meaning there are a minimum number of fields required to be reported). For submissions with action types EROR, TERM, and PRTO, the following fields are the minimum fields required to be reported: Action type, Counterparty 1, Counterparty 2, Counterparty 2 identifier source, Event timestamp, Event type, Reporting timestamp, Submitter identifier, Unique swap identifier, and Unique transaction identifier. Each SDR may choose to augment the required fields beyond what is specified here. However, the layout of the file for short messages should be the same as described in the tables below.

      • The CFTC has required the reporting of a number of fields in the Guidebook which are not present in the CFTC Technical Specifications, where that is the case KOR has been required to add these fields to its Tech Spec.

      Why do the field names in the CFTC reports not match the CFTC Tech Spec or KOR tech Specs?

      • The fields in the Guidebook have "short names" which the CFTC has defined. The mappings can be found here.

      Why are the fields in the report that I don't report to KOR?

      1. Some fields are specific to other SDRs (link)
      2. The CFTC UPI fields don't align with the UPI specifications/KOR UPI fields as they use legs in the field name where the UPI does not so that duplicate products aren't created based solely on legs.