Canadian Trade Repository - FAQ

Contents

General

Q. What is the deadline for compliance (“Compliance Date”) with the amended swap data reporting rules?
A. While the official deadline from the CSA is July 25, 2025 (CSA announcement), for all amended rules, CME CTR will deploy changes to our production systems on July 20, 2025. To allow enough time to implement the necessary changes we will be closing at 5 pm CT (10 pm UTC) on Friday July 18, 2025. This means that all transactions submitted after 5:00 pm CT (10:00 pm UTC) on Friday July 18, 2025 must be submitted in conformity with CME CTR's new Technical Specification. CME CTR will reject any submissions that do not conform with the new Technical Specifications after 5:00 pm CT (10:00 pm CT) on Friday, July 18th. 

Q. How can I add other key contacts for CME Group CTR to whom updates and notices will be sent?
A. CME CTR 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 in our contact list for your firm, please supply that information to repository@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. 

Q. Is there a Working Group to which I can be added?
A. We have a virtual Working Group session on the final Wednesday of every month at 9:00 am CT. Please contact repository@cmegroup.com if you wish to attend these sessions.

Reporting to the CTR

Q. What are the Creation and Lifecycle Event Data (CLED) reporting deadlines? 
A. The amended Trade Reporting Rules establish a bi-furcated reporting deadline, which is determined based on whether the reporting entity is a “qualified reporting counterparty” or not.

Creation Data

• Qualified reporting counterparty - Creation Data must be reported in “real time” . If data cannot be reported in real time then it must be reported ASATP (As Soon As Technologically Practicable) after execution but in no event later than the end of the following business day.

• Non-qualified reporting counterparty - Must report creation data no later than the end of the second business day following execution.

See Supplement to the OSC Bulletin: Annex D, Subsection 2--Page 97.

Lifecycle Event Data

• Qualified reporting counterparty - Lifecycle Event Data must be reported to a designated trade repository by the end of the business day on which the lifecycle event occurs. However, if it is not “technologically practicable” to report lifecycle event data in this timeframe, no later than the end of the business day following the day on which the lifecycle event occurs.

• Non-qualified reporting counterparty - Non-qualified reporting counterparties will have until the end of the second business day following the day on which the lifecycle event occurs to report all lifecycle event data.

See Supplement to the OSC Bulletin: Annex C, Section 33--Page 62.

Q. What is the reporting deadline for Transaction Level Data required to be made publicly available or what is referred to in our Technical Specifications as Publicly Available Transaction Data (PATD)?
A. The regulation is silent on when the reporting counterparty must submit Publicly Available Transaction Data. However, the regulation does require a TR to make the information available to the public 48-hours after execution. Thus, the transaction should be submitted sufficiently in advance to meet this deadline.

Q. What are my obligations to report Valuation Data?
A. A reporting counterparty that is a derivatives dealer or a recognized or exempt clearing agency must report valuation data to a designated trade repository each business day until the derivative is terminated or expires. A reporting counterparty that is not a derivatives dealer or recognized or exempt clearing agency is not required to report valuation data.

Q. What are my obligations to report Collateral and Margin Data?
A. A reporting counterparty that is a derivatives dealer or a recognized or exempt clearing agency must report collateral and margin data to a designated trade repository each business day until the derivative is terminated or expires. A reporting counterparty that is not a derivatives dealer or recognized or exempt clearing agency is not required to report Margin/Collateral data.

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. However, as of implementation date of the Trade Reporting Rules and the Technical Manual, a USI may no longer be submitted on any new swaps. The regulation prohibits CTRs from accepting USIs for all new transactions (e.g., <Action> = 'NEWT') after the implementation date. However, any transaction reported to CME CTR prior to the implementation date using a USI can continue to be amended using the USI. Currently, a USI is reported using a separate USI Namespace and USI field(s). After implementation of the Trade Reporting Rules, the USI Namespace and USI will be combined into a single field called <USI>.

All new transactions reported after the Compliance Date must utilize the UTI field.

Reporting UPI to CME CTR

Q. What is UPI?
A. UPI stands for Unique Product Identifier and is a code that uniquely identifies a type of derivative and is assigned by the Derivatives Service Bureau. The purpose of UPI is to standardize OTC derivative reporting to regulators globally by assigning a unique code to each derivative product rather than relying on certain reportable trade attributes from each submitter. 

Q. Are UTI and UPI related?
A. Think of these separately. UTI (Unique Trade Identifier) identifies an individual derivative. UPI (Unique Product Identifier) defines the product attributes of a derivative. 

Q. Do I need to be prepared to submit UPI on all trades beginning July 25, 2025?
A. The CSA has mandated that UPI must be submitted on 4 of the 5 asset classes on and after this date. All reportable swaps in the Credit, Interest Rate Swap, FX, and Equities asset classes must be submitted with the UPI field. UPI for Commodities has been descoped from the July 25 implementation and will be applied at an as of now unknown date.

Q. Where can I obtain the UPI data that I will send to the CME CTR 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 needs.

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, 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 CTR check ANNA DSB for new or updated UPIs?
A. CME CTR processes any newly created UPIs from ANNA DSB once a day. This update occurs at the close of business. If a UPI is submitted that the CTR doesn’t recognize, we search the ANNA DSB database real-time and, if it exists there, will update our system accordingly.

Q. What UPI related validation does CME CTR perform on my trade submission?
A. 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. The only exception is for the DSB Asset Class as 'Other,’ which can be submitted under any asset class.

** Existence check for UPI in CTR New Release environment will be done against a cumulative set of UPIs existing in DSB 'UAT' and DSB 'PROD' environment. CME CTR supports UPI data generated from DSB UAT (uat.anna-dsb) and DSB PROD (prod.anna-dsb) only.

Q. Does CTR use the UPI provided on the submission to drive any field level validations? 
A. Yes, CTR uses 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. CTR validates whether fields that are mandatory for an Amortizing trade, such as ‘Leg1EffectiveNotionalAmount,' are populated, and the submission is 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 CTR but the UPI submitted on the swap is for an FX product? 
A. CME CTR compares 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 referenced on the record being submitted.

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

Q. Will CTR enforce a condition that UPI provided for a given UTI must be the same across all forms of submissions, i.e., consistency between creation data, publicly available data, and Valuation submissions? 
A. No, CTR will not do any cross validations for UPI between different submission types for the same UTI/USI. Essentially it is possible that the CLED (creation and lifecycle event data) and PATD (publicly available transaction data) records of the same trade are submitted with differing UPIs. As noted earlier, it is the Reporting Counterparty’s responsibility to ensure that correct UPI is referenced on the submitted record.

Submission Process

Q. Which methods are available to submit data to the CTR?
A. Web Services (Rest API), User Interface, and Secure FTP continue to be offered as the submission methods to the CTR. 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 CTR?
A. Submissions via the Web Services and User Interface will see user experience changes. The submissions will move to an "asynchronous" model, which means the user will receive a request ID in response when the file has been received by the CME CTR. 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 the 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 CTR?
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 applies across all submission methods. No spaces or special characters apart from underscore (_) or hyphen (-) are allowed.
Interest Rates: CTRIRS_*
Credit: CTRCDS_*
FX: CTRFX_*
Commodity: CTRCMDT_*
Equity: CTREQUITY_*
Collateral: CTRCOLL_*

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 July 25, 2025, go-live date, FIXML, FpML, or ISO 20022 XML are not supported by the CME CTR. 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 CTR CSV format.

Q. How are Creation and Lifecycle Event Data (CLED) and Publicly Available Transaction Data (PATD) reported?
A. As per the new reporting requirements, CLED and PATD 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, CLED and PATD must exist in separate records with all respective fields populated.

Q. How is Valuation data reported?
A. The Valuation (for <Action> = 'VALU') data may be reported on the same file as the transaction data in a separate row but must exist only after the CLED 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 relevant fields as the header, if applicable. A sample file will be made available on the CME CTR CSV Technical Specification document once ready.

Q. Where can I access the new Technical Specification?
A. The CME CTR CSV Technical Specification is available at Trade Repository Technical Documentation - CME Group under the Canadian Trade Repository CSV Templates section. The document at this link will always have the most updated specification under the name “CME Canadian Trade Reporting Rewrite Specs - Effective 7/25/2025.”

Q. Will there be any sample templates provided?
A.  Sample submission templates are available as separate tabs within the CME CTR CSV Technical Specification. Please note that, currently, these samples are for trade submissions only. We will add Valuation and Margin/Collateral samples to the Technical Specification soon.

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 CTR 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 CTR?
A. All reporting counterparties, including those that are not derivatives dealers, recognized or exempt or reporting clearing agencies, or notional amount threshold derivatives dealers are required to report derivatives data as provided in the TR Reporting Rules and ensure that this data does not contain any errors or omissions. Reporting counterparties that are not derivatives dealers, recognized or exempt or reporting clearing agencies or notional amount threshold derivatives dealers are not subject to the ongoing verification requirementsSee Supplement to the OSC Bulletin: Section 26.1--Page 144.

Q. What "mechanism" is CME CTR providing counterparties to verify data?
A. The CME CTR 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 CTR. 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. 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 the TR Reporting Rules?
A. Yes. 

Testing and Connections

Q. When will the UAT environment be available?
A. The UAT environment for Submissions is targeted to be available in mid April. A Client Advisory will be sent once the date is known. Please note that this UAT date is for trade submissions only. A separate Client Advisory will be sent once outbound reporting from the CTR is available. We will also update the response on this FAQ once a date for outbound reporting is known.

Handling of Historical Data

Q. What is the meaning of the term “Historical Data” as it relates to the amended TR Reporting Rules?
A. While not defined in the regulation, for these purposes, the term “Historical Data” shall mean any derivatives/position that was submitted prior to implementation date.

Q. What are a reporting counterparty’s obligations for Historical Data that remain open?
A. Reporting counterparties will need to bring all open Historical Data into compliance with CME CTR’s new Technical Specification (i.e., “upgrade”) 6 months from the implementation date. 

Q. Is an upgrade to Historical Data required?
A. In order for counterparties to report lifecycle events after the implementation date, all open derivatives submitted prior to that date will need to be upgraded. Lifecycle event submissions using the pre-implementation date template will be rejected.

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 CTR’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” 6 months from the implementation date. However we 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.

• Until your Historical Data is upgraded, there will be two different Open Swaps reports (i.e., pre- and post- go-live) with different formats, enums, etc., which will make verification more difficult. This issue will disappear once your data has been upgraded since you will only have one report with the same format.