UPI Implementation - FAQ

Reporting UPI to CME SDR

Q. What date do I need to begin submitting Unique Product Identifier (UPI) data to remain in compliance with the amended swap data reporting rules?
A. On January 29, 2024 all reportable swaps in the CR, IR, FX, EQ asset classes must be submitted with the UPI field. CME SDR’s New Release environment is available for testing as of November 9, 2023.

Q. Where can I obtain the UPI data that I will send to the CME SDR to fulfill my reporting obligations?
A. The Derivatives Service Bureau (ANNA DSB) creates and maintains all UPI codes. Please reference the ANNA DSB website to determine the connection type your firm will need.

Q. How can I check the data associated with UPI prior to submission? Also, how can I check the subsequent outstanding report? 
A. ANNA DSB maintains the UPI database and is the central source of reference. CME will use the UPI provided on the submission, and retrieve the data from ANNA DSB tied to that UPI, and then use this data to validate. These UPI elements are reflected in the tech spec as UPI.[Element]. 

Q. How frequently does CME SDR check ANNA DSB for new or updated UPIs?
A. CME SDR will process any newly created UPIs from ANNA DSB once a day. This update will occur at the close of business. If a UPI is submitted that the SDR doesn’t recognize, we will search the ANNA DSB database real-time and, if it exists there, will update our system accordingly.

Q. What UPI related validation does CME SDR perform on my trade submission?
A. As per CFTC technical specification V.3.2, all trade and valuation records being submitted to an SDR for CR, IR, FX, EQ asset class must contain a valid UPI value. The validity of UPI provided is determined based on following checks:

• Format Check - The UPI code value must align with the format provided by DSB UPI guidance. Refer to the specification for more details.

• ** Existence check - UPI value provided on the submission record must exist in DSB UPI records.

• Asset Class Check - The asset class associated with the UPI as per DSB records must be the same as the asset class provided in 'AssetClass' field as part of the submission. Only exception is for the DSB Asset Class as 'Other' which can be submitted under any asset class.

Q. Do SDRs use the UPI provided on the submission to drive any field level validations? 
A. Yes, SDR will use some of the key UPI attributes for validating conditionally required fields. All cases where the validation refers to a field as UPI.[] implies that the value of that field would be sourced from UPI details.

Example: A Rates trade record is submitted with a UPI that describes a product with a Notional Schedule that is Amortizing. SDR will validate whether fields that are mandatory for an Amortizing trade, such as ‘Leg1EffectiveNotionalAmount’ are populated, and the submission will be rejected if not, with error “CRMI:Conditionally Required but missing -Leg1EffectiveNotionalAmount is a required field when UPI.NotionalSchedule is not equal to Constant and is not blank”.

Q. What happens if I report an interest rate swap to the SDR but the UPI submitted on the swap is for an FX product? 
A. CME SDR will compare the UPI field with the Field Header “AssetClass” submitted on each trade. This must match the asset class tied to the UPI as defined by ANNA DSB, the source of UPI data. If the AssetClass field is populated with an attribute that doesn’t match the derived asset class of the UPI then this trade will not pass validation. It is the Reporting Counterparty’s responsibility to ensure that the correct UPI is being referenced on the record being submitted.

Q. Will SDR enforce a condition that UPI provided on a given trade cannot change? 
A. No, SDR will not be enforcing any such constraints currently.

Q. Will SDR enforce a condition that UPI provided for a given UTI must be the same across all forms of submissions i.e. consistency between Part 43, Part 45 and Valuation submissions? 
A. No, SDR will not do any cross validations for UPI between different submission types for the same UTI/USI. Essentially it is possible that the Part 43 and 45 records of the same trade are submitted with differing UPIs. As noted earlier it is RCPs responsibility to ensure that correct UPI is being referenced on the record being submitted.

Updating 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 Jan 29, 2024 (the “go-live” date).

Q. Do the swaps that I have already reported (known as Historical Data) need to be upgraded with a UPI?
A. Yes, January 29, 2024 is the compliance date for Historical Data as well. CME SDR will make the Production environment available on Sunday January 28, 2024 at 5:00 am Central Time for those looking to upgrade their existing swaps over the weekend. This is required for all open Part 45 submissions. It is not required to update swaps that, as of Jan 29, 2024, are no longer in an open status. To be clear, trades that are closed (terminated, matured, expired etc.) as of the Jan 29, 2024 date do not need to be upgraded.

Q. Do Part 43 submissions require upgrading?
A. No. Part 43 is designed to capture price-forming events. Upgrading data to accommodate UPI does not cause a price-forming event, and therefore Part 43 submissions are not required to be upgraded JUST for UPI. Any price-forming event in the future will need to be submitted, and will need to match the new specifications.

Q. How do I upgrade my 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. How can I get a complete list of my Historical Data where UPI will need to be added to each open swap?
A. CME SDR provides users with an Outstanding swap report via the Reports tab of its User Interface. To see the open swaps that have not yet been updated with UPI, run an ‘Outstanding’ report for a given asset class from the “Reports – On or After 05 December” section. Choose an As Of Date at least one day in the past and click the ‘Execute’ button. Please note that if you enter an as of date for the current day the report will return 0 results.  

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. 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. What should I do if some or all of my open Historical Data cannot be “upgraded” to comply with CME SDRs 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.

Technical Specification Document

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

Q. Will there be any sample templates provided?
A. The sample submission templates are available in separate tabs within the Technical Specification document available via this link.

Q. Are there any other fields that are being deprecated?
A. Yes, there are several other fields that are being deprecated based on updated guidance from CFTC. The list of impacted fields can be found by filtering on <<details>>.

Q. Does deprecation imply that such fields, if included in the submission, will be rejected by the SDR?
A. No, given the UPI mandate is only applicable for 4 of the 5 asset classes, CME SDR will continue to accept deprecated fields as ‘valid headers’, given they continue to be relevant for CO submissions (where applicable). Please note, though SDR will not reject a file if it includes such headers in the csv, all such fields will be excluded from processing and will not be persisted.

For example, if a submission is made of AssetClass as ‘IR’ and the field ‘InstrumentType’ (one of the fields being deprecated due to UPI) has a value of ‘Swap’, the file will be processed but the value of ‘InstrumentType’ would be null in SDRs records.

Q. What does “UPI & Deprecated” mean on the Technical Specifications tab under the Header ‘Jan 2024 Impact’ (Column C)?
A. Reportable attributes that previously were mandatory or conditionally mandatory that now show as UPI & Deprecated means that they are no longer required to be submitted in order to pass validation at the CME SDR. This data will now be derived from UPI.

Q. How to identify existing CME SDR specification fields that were initially introduced in lieu of UPI and are now being deprecated?
A. All fields that have the ‘Source’ of “CME - UPI” were introduced in lieu of UPI and are being deprecated for CR, IR, FX, EQ asset class. 

The only exception to this is the ‘AssetClass’ field which will continue to be a mandatory field and will be used as the primary asset class in cases where the asset class associated with the provided UPI is classified as ‘Other’. [More details on treatment of ‘Other’ asset class is detailed below under “How does SDR treat UPIs where UPI asset class is specified as ‘Other’?”

Q. How does SDR treat UPIs where the UPI asset class is specified as ‘Other’?
A. Other’ Asset Class is not a natively supported concept. SDRs only recognize the 5 primary asset classes. All of the field level validations as well as reporting is based on one of the 5 primary asset classes. When submitting trades associated with a UPI with asset class as ‘Other’ clients need to make a determination of what the Primary asset class would be and make their submissions under the same.

Primary asset class will drive the field applicability, validations, regulatory reporting as well as any post trade processing CME SDR undertakes in support of the Part 43 real time reporting requirements.

End of Day Reporting

Q. What will change in reporting as a result of the UPI changes?
A. UPI has been added to the Trade, Outstanding, Collateral, and Valuation reports (a full list of impacted reports is below). This new field will be populated by the UPI value that was on the submission. The UPI field will be used to retrieve the associated data elements, which will be populated on the Outstanding report.

List of Impacted Reports:

• Outstanding Trade Report - CR

• Outstanding Trade Report - EQ

• Outstanding Trade Report - FX

• Outstanding Trade Report - IR

• All Trade Report - CR

• All Trade Report - EQ

• All Trade Report - FX

• All Trade Report - IR

• Part 43 Trade Report - CR

• Part 43 Trade Report - EQ

• Part 43 Trade Report - FX

• Part 43 Trade Report - IR

• Part 45 Trade Report - CR

• Part 45 Trade Report - EQ

• Part 45 Trade Report - FX

• Part 45 Trade Report - IR

• Valuation Report - CR

• Valuation Report - EQ

• Valuation Report - FX

• Valuation Report - IR

Q. How will scheduled reports accommodate the changes?
A. If a report was initially scheduled before UPI changes went live in Production, then the query populating the report will be the same that it was at the time of schedule. Cancelling this schedule, and re-scheduling it moving forward, will regenerate the query and populate the added data fields.

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.

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 Jan 29, 2024 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. Is there a column ordering constraint on the .CSV file?
A. Required column headers must match exactly to the field names in the Technical Specification document. The order of required columns, however, does not matter. 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).

Testing and Connections

Q. When will the UAT environment be available? 
A. The UAT environment for Submissions is available effective Nov 9, 2023.

Q. How do I connect to CME SDR’s UAT environment to begin testing? 
A. Please follow the instructions below to connect to UAT.

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 To Be In Contact

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.