CFTC Rules Rewrite - FAQ

General

Q. What is the deadline for compliance (“Compliance Date”) with the amended swap data reporting rules (Parts 43, 45, 46 and 49)?
A. Dec 5, 2022 for all amended rules except §§ 43.4(h) and 43.6. The compliance date for §§ 43.4(h) and 43.6, which govern block thresholds and cap sizes, is Dec 4, 2023.

Q. How can I add other key contacts for CME SDR to send updates and notices to?
A. CME SDR is requesting all pertinent business, operations and legal/compliance contacts to be provided so as to be included for all updates and notices. If you are aware of or suspect that a person is not on our contact list for your firm, then please supply that information to repositorysupport@cmegroup.com.

Q. Who should I contact for inquiries? 
A. Please contact repositorysupport@cmegroup.com for any initial inquiry. If you have a regular relationship manager, you may also copy that person in the email. 



Reporting to the SDR

Q. What are the Part 43 reporting deadlines?
A. The deadline for Part 43 reporting remains unchanged and must be reported ASATP (As Soon As Technologically Practicable) after execution. (see §43.3)

Q. What are the Part 45 reporting deadlines?
A. The CFTC has extended the Part 45 reporting for SEFs, DCMs, SDs, MSPs, and DCOs to the end of the next business day following the execution date instead of immediately after execution with certain backstops. CFTC also extended the deadline for all other counterparties to the end of the second business day following the execution date. (see §45.3(a) and (b))

Q. What are my obligations to report Valuations?
A. The amendments to part 45 retain the obligation for SDs/MSPs/DCOs to submit valuations daily but clarifies it is “each business day” as that term is defined in § 45.1. For all other counterparties that currently report valuation data quarterly, the requirement to report valuations has been removed. (see § 45.4(c)(2))

Q. What are my obligations to report Margin/Collateral?
A. The CFTC, under the new rules requires SDs/MSPs to report margin and collateral data "each business day" with a view that the Commission's ability to monitor for systemic risk will be significantly improved. (see § 45.4(c)(2))  

Q. What is the Unique Trade Identifier on a transaction ?
A. UTI and USI are two fields that are available to populate the unique trade identifier.
A USI will no longer be permissible for swaps executed on or after the compliance date of Dec 5, 2022. The regulation prohibits SDRs from accepting USIs for all new transactions (e.g., <Action> = 'NEWT'). However, any transaction reported to CME SDR prior to the Compliance Date using a USI, can continue to be amended using the USI.  Previously, the USI comprised of a separate USI Namespace and USI field(s). Going forward, the USI Namespace and USI will be combined into a single field called <USI> of 42 characters long.
All new transactions reported after the Compliance Date must utilize the UTI field.
Note: Uniqueness on a transaction is across the UTI, USI, and all asset classes. For example, a value populated in USI for a given asset class must not have been previously used in the USI or UTI fields for any other asset class.



Submission Process

Q. Which methods are available to submit data to the SDR?
A. Web Services (Rest API), User Interface, and Secure FTP continue to be offered as the the submission methods to the SDR. Between the three available methods, the Web Services and User Interface submission methods will have an improved user experience and few technical changes in the way data is submitted and responses retrieved. For more information, please contact repositorysupport@cmegroup.com.

Q. What are the technical changes in the submission process to the SDR?
A. Submissions via the Web Services and User Interface will see user experience changes.  The submissions will move to a "asynchronous" model, which means the user will receive a request ID in response when the file has been received by the CME SDR. This allows the user to return to the browser (if using the User Interface upload feature) or terminal (if using the Web Services API) to continue to work as normal while their request is being handled in the background. To look up the status of the submission, the user can navigate to Submission Tracker screen on the User Interface or initiate another Web Service call and pass the previously generated request ID as a parameter to receive the status or final ACK or NACK on the submission.

Q. In which format is data reported to the SDR?
A. CSV (Comma Separated Flat File) will be the only supported format.

Q. Is there a file naming convention to follow?
A. The following file naming convention will apply across all submission methods. No spaces or special characters apart from underscore ( _ ) or hyphen ( - ) are allowed.
Interest Rates: SDRIRS_*
Credit: SDRCDS_*
FX: SDRFX_*
Commodity: SDRCMDT_*
Equity: SDREQUITY_*
Collateral: SDRCOLL_*

Q. Is any structured XML (such as FIXML, FpML, ISO 20022...etc) supported?
A. Since the Commission has not mandated any such reporting format for the Dec 5, 2022 go-live date, FIXML, FpML, or ISO 20022 XML are not supported by the CME SDR. However, if there is a need we are happy to introduce you to our channel partners that are equipped to perform the translation to the CME SDR CSV format.

Q. How is Part 43 and Part 45 transaction data reported?
A. As per the new reporting requirements, Part 43 and Part 45 transaction data must be reported separately and cannot be combined into a single submission record as previously allowed. While they may be reported on the same file, Part 43 and Part 45 must exist in separate records with all respective fields populated. Note: The Part 43 and Part 45 records must each be reported with <Action> = 'NEWT' for the first submission to the CME SDR and the appropriate <Action> for continuation events as applicable.

Q. How is Part 45 Valuation data reported?
A. The Part 45 Valuation (for <Action> = 'VALU') may be reported on the same file as the transaction data in a separate row but must exist only after the Part 45 record if submitted on the same file. Only the Valuation relevant fields may be populated and all other Transaction fields can be left blank.

Q. How is Collateral & Margin data reported?
A. The Collateral data (for <Action> = 'MARU') must be reported on a separate file from the transaction data and must only contain the 29 relevant fields as the header, if applicable.

Q. Where can I access the new Technical Specification?
A. The CME SDR CSV Technical Specification is available via this link

Q. Will there be any sample templates provided ?
A. The sample submission template will be available as a separate tab within the CME SDR CSV Technical Specification available via this link.

Q. What are the standard list of errors that can be expected as a response to a failed submission ?
A. A list of possible errors for each field is available as a separate tab within the CME SDR CSV Technical Specification available via this link.

Q. Is there a column ordering constraint on the CSV file?
A. There is no ordering constraint. Although the column headers must match exactly to the field names in the CME SDR CSV Technical Specification. The submission template can be the same across all asset classes but only the relevant fields for that asset class must be populated.



Data Access and Verification 

Q. What obligations do I have as a counterparty to verify data submitted to the CME SDR?
A. Each reporting counterparty shall verify that there are no errors in the swap data for all open swaps that the reporting counterparty reported, or was required to report, to CME SDR. Such verification shall be conducted by utilizing the “mechanism” provided by CME SDR to compare all swap data for each open swap for which it serves as the reporting counterparty with all swap data contained in its internal books and records for each swap, to verify that there are no errors in the swap data maintained by CME SDR. (see § 45.14 for further details).

Q. What "mechanism" is CME SDR providing counterparties to verify data?
A. The CME SDR intends to make available a report via a self-service User Interface that allows each user to access all swap data maintained by the CME SDR. This mechanism shall allow sufficient access, provide sufficient information, and be in a form and manner to enable every user to perform swap data verification as required under § 45.14.  A Client Advisory will be sent when this report is available in our testing environment.

Q. Will I be able to continue to access my previously reported swap data after the implementation of new rules?
A. Yes. 



Testing and Connections

Q. When will the UAT environment be available? 
A. The UAT environment for Submissions will be available effective Jul 21, 2022. More UAT dates for outbound reporting from SDR will soon follow.

Q. How do I connect to UAT environment to begin testing? 
A. User must follow the instructions below to connect to UAT.
Note: PROD connections are also provided below but users must note that the PROD URL's will not be activated until Dec 5th and must not be used for any sort of testing.

SFTP: Once connected to the below environment using the same credentials user currently possesses, place files using the file naming convention specified earlier into the /Incoming folder. Response from the CME SDR will be generated and can be picked up from the /Outgoing folder.
UAT: sftpcert.cmegroup.com (port 22)
PROD: sftpng.cmegroup.com (port 22)

User Interface:
UAT: https://sdrcftcuinr.cmegroup.com/swapdatarepositoryui/
PROD: https://sdrui.cmegroup.com/sso/navmenu.action

Web Services:



Handling of Historical Data

Q. What is the meaning of the term “Historical Data” as it relates to the amended CFTC swap data reporting rules?
A. While not defined in the regulation, for these purposes, the term “Historical Data” shall mean any swaps/position which was submitted prior to Dec 5, 2022 (the “go-live” date).

Q. What are a reporting counterparty’s obligations for Historical Data that remain open?
A. In order to ensure CME SDR is able to meet its regulatory obligations pursuant to § 49.9, §49.17(c)(1) and § 49.30 reporting counterparties will need to bring all open Historical Data into compliance with CME SDR’s new Technical Specification (i.e., “upgrade”). 

Q. Is an upgrade to historical open swaps required?
A. All submissions to the SDR must be in the then current specifications. All open swaps submitted prior to Dec 5th need to be upgraded to be able to report life cycle events.

Q. How can I get a complete list of my Historical Data that remains open at CME SDR?
A. CME SDR provides users with an Outstanding swap report via the Reports tab of its User Interface. To see what open swaps have not yet been upgraded to the new specification, run an ‘Outstanding’ report for a given asset class from the “Reports – Before 05 December” section. Be sure to choose a recent As-Of Date when running the query because historical Outstanding Report data is only retained for a rolling 90 days. For example, if today's date is June 12, 2023, to determine if you have open swaps that have not yet been upgraded, select an As-of-Date on or between March 14, 2023 and June 11, 2023, due to the rolling 90-days.

Separate from non-upgraded data, CME SDR now provides an additional Outstanding report (in the “Reports- On or After 05 December” section), with a new format, showing any open swaps submitted on or after the 5 December 2022 compliance date. This new-formatted Outstanding report shows swaps (separated by asset class) that remain open as-of 11:59:59 pm UTC on a given completed prior business day. Be sure to choose a recent As-Of Date when running the query, because historical Outstanding Report data is only retained for a rolling 90 days.  Clients can log on to the User Interface to run it on an ad hoc basis, or schedule the report to run for the prior business day at a predetermined frequency (i.e., daily, weekly, monthly, etc.). If you need help scheduling the automated report, contact Client Services for assistance at repositorysupport@cmegroup.com This report can be used by clients to meet their verification obligation set forth in § 45.14(b).

Q. Is there a special way for me to identify the data as being amended in connection with my obligation to “upgrade” open Historical Data?
A. When submitting an upgrade to your historical data to conform with CME SDR’s new Technical Specifications, populate the <Action> field with ‘MODI’ and the <Event> field with ‘UPDT’. 

Q. What is the deadline for “upgrading” my Historical Data?
A. Historical Data must be “upgraded” by June 5, 2023.  However we would strongly encourage you to upgrade your Historical Data as soon as possible for the following reasons:

  • If everyone waits until the last minute the load on the system could result in slow-downs in processing which could cause you to miss the deadline.

  • If there are any issues in “upgrading” the data you may not have time to resolve them prior to the deadline.

  • CFTC Regulation 14(b) requires reporting counterparties to “…..verify that there are no errors in the swap data for all open swaps that the reporting counterparty reported, or was required to report….”.  Moreover each reporting counterparty must “…compare all swap data for each open swap for which it serves as the reporting counterparty maintained by the relevant swap data repository or repositories with all swap data contained in the reporting counterparty's internal books and records for each swap….”.  As noted above there will be two different Open Swaps reports (i.e., pre- and post- go-live) with different formats, enums, etc. which will make completion of the verification more difficult.  That issue disappears once your data has been upgraded since you will only have one report with the same format.

Q: What should I do if some or all of my open Historical Data cannot be “upgraded” to comply with CME SDRs then current Technical Specifications?
A: You will need to reach out to the Division of Data at the CFTC to inquire as to how you should handle the matter. 



Porting to/from another SDR

Q. Is porting from one SDR to another allowed? 
A. A reporting counterparty may change the swap data repository to which swap transaction and pricing data is reported as set forth under §45.10 (d)

Q. What is the process to port transactions from one SDR to another?
A. At least five business days prior to changing the SDR to which the reporting counterparty reports swap and pricing data for a swap, the reporting counterparty shall provide notice of such change to the other counterparty to the swap, the SDR to which swap and pricing data is currently reported, and the SDR to which swap and pricing data will be reported going forward. Such notification shall include the UTI of the swap(s) and the date on which the reporting counterparty will begin reporting such swap and pricing data to a different SDR.

Next, the reporting counterparty shall report the change of SDR to the SDR to which the reporting counterparty is currently reporting swap and pricing data as a life cycle event for such swap pursuant to § 45.4 using <Action> = "PRTO" and <Event> = "PTNG".

On the same day that the reporting counterparty reports required swap continuation data as stated above, the reporting counterparty shall also report the change to the new SDR as a life cycle event for such swap pursuant to § 45.4 using <Action> = "NEWT" and <Event> = "PTNG". The required swap continuation data report shall identify the swap using the same UTI used to identify the swap at the previous SDR.

Thereafter, all swap and pricing data, required swap creation data, and required swap continuation data for the swap shall be reported to the same SDR.

Q. What data can be ported to the new SDR?
A. Historical data will not be required to be transferred to a new SDR. Only open trades/positions must be reported by the reporting counterparty (or its delegated reporting service provider) to the new SDR.

Q. Do my open trades need to be updated to the new SDRs current reporting specifications to be ported?
A. Yes, reporting counterparties (or delegated reporting service providers) must ensure that all outstanding trades to be transferred meet the new SDR's latest technical specifications. Data not meeting these requirements for a given entity will limit the ability to port for the entirety of that entity until resolved.  

Q. How can CME SDR help me with porting in?
A. It is the responsibility of the reporting counterparties (or delegated reporting service providers) to ensure that all submissions to the CME SDR meet its latest technical specifications. While CME operations can help with the initial mapping of data to the CME SDR's Technical Specifications, the CME SDR also has partner service providers that can provide additional guidance and required technology to support the reporting of data to CME SDR. Please contact repositorysupport@cmegroup.com for any introductions to the service providers.










How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.