Canadian Trade Repository

This topic provides an overview of CME's Canadian Trade Repository (CTR). It details supporting functions, workflows, message flows, and interfaces to allow registered users to submit and retrieve swap data in the CTR. CTR leverages existing CME repository and clearing services connectivity, functionality, and processes in order to accept, store, and report swap data.

Revision History

Prerequisites

This topic assumes the user has basic trade repository flow knowledge. For more information, please refer to the relevant Canadian provincial derivatives regulations or contact our team:

Contact Information

CTR Business Team: repository@cmegroup.com 

CTR Support Team: repositorysupport@cmegroup.com 

CTR Support Team Phone number:

• Chicago +1 (312) 580 5352

• London +44 (0) 203 379 3180

• Singapore +65 6593 5592

Additional Information

www.cmegroup.com/ctr

Access to the CME CTR

Registering for CTR Test Environment Access

To assist clients with preparation for various Canadian provincial reporting regulations, CME CTR provides a test environment. Access to the test environment can be granted prior to execution of the CME CTR User Agreement by completing an informational form. Production environment access may only be granted to users and service providers with completed registrations and legal agreements. A full CTR user registration also includes access to the test environment. Service providers do not have a test environment only option, and must complete the full Service Provider Agreement, which includes test environment access.

Steps to request access to the CME ETR test environment: 

1. Complete the User Agreement or Test Environment form (single form to gain access to any of CME's Global Trade Repositories) from www.cmegroup.com/ctr. 

2. Use the form's submit button; your system's default email program prepares an email to the CTR Registration Team. If you prefer a different email program, copy the email attachment and email address to your preferred program.

3. Once the form is received, CME processes the request. Upon completion, CME CTR sends an email to the administrator contact confirming the registration and provides information on how to get started. 
   
   

For assistance during or following the registration process; please send an email to CME Global Repository Client Services repositorysupport@cmegroup.com.

Registering for CTR Production Environment Access

Access to the production environment is granted only to fully registered users and authorized service providers. The following steps outline the registration process to submit and access derivative data in the CME CTR for Canadian reporting compliance.

1. Obtain a Legal Entity Identifier (LEI).
   
   An LEI is strictly required at the time of full registration. An LEI is required for each separate legal entity for whom data will be submitted or retrieved in the CME CTR. Users may acquire a LEI through one of the authorized LEI issuers listed in http://www.leiroc.org.  An LEI obtained previously for a legal entity to satisfy other business purposes (including trade reporting in a different global jurisdiction) may be used in the CME CTR registration if the issuer is recognized on the LEI ROC website.
   
   CME Central Counterparty (CCP) LEI's provided for reference:

   • CME ChicagoMercantileExchangeInc.(USClearingHouse) 
     
     

     • CME Inc. LEI: SNZ2OJLFK8MNNCLQOF39
       
       

     • CME Inc. UTI Namespace: 1010000023

2. Execute the agreement (User Agreement or Service Provider Agreement).
   
   User Agreement:  Entered into by a party to a derivatives transaction; the agreement enables the registered user to (1) submit, (2) analyse/filter, (3) extract, and (4) authorize their counterparty or service provider (not a party to the transaction) to view its derivative data stored in CME CTR. In order to execute the CME CTR User Agreement:

   • Download the agreement from the CME CTR website www.cmegroup.com/ctr. Complete the user agreement and click the send button to electronically submit the agreement to the CME CTR Registration team.

   • The user agreement is received and processed by the CME CTR Registration team. Notification of receipt of the submission is provided, and a subsequent notification is sent when the registration is completed. In the registration complete email, instructions are provided to contact the CME registration team to receive the login information over the phone (for security reasons).

   • Schedule A (CME CTR registration entity details): A required form as part of CME CTR registration. Firms are required to specify at least one Verification Officer upon registration. The Verification Officer acts as the account administrator--approving any new requests, access modifications, etc. In addition to a Verification Officer, regular users are also requested. Verification Officers have a choice of admin roles or view only roles. Admin roles allow users to upload, amend, and view; whereas a View Only role allows for read only access to the CTR.

   • Schedule C: bulk registration for investment advisors or multiple entities under the same corporate structure. Schedule C is available from www.cmegroup.com/ctr.
     
     

Additional User Access Requests

Once registered, accounts may authorise additional users to access the data (i.e. internal staff, fund administrators, other intra-group entities, etc.). Please follow the instructions on the additional user access request form from www.cmegroup.com/ctr.

Access Levels

CMECTRAdministrator:

• Rights to create, modify, and remove user accounts

• Rights to view data for all accounts

• Rights to upload data for all accounts

• Rights to run all reports and download the results for all accounts

CMECTRFullAccess:

• Rights to view data for accounts

• Rights to upload data for accounts

• Rights to run all reports and download the results for accounts

CMECTRViewOnlyAccess:

• Rights to view data for accounts

CMECTRViewOnlyAccess:

• Queries regarding permissioning for Regulatory Authorities should be emailed to repositorysupport@cmegroup.com.

Trade Submissions to CME CTR

Swaps are submitted to CME CTR via the following methods:

Transport Overview

MQ

FiXML API submission via MQ is a full service option for submitting, cancelling, or amending derivative data to CME CTR. 

MQ is an IBM product that facilitates software messaging between two computer systems. In order to use MQ based messaging system, firms require installation of IBM MQ client software. Please note that IBM is an independent company from CME, and therefore, firms will need to appropriately license the software.

A prerequisite to facilitate MQ connectivity is establishing connectivity into the CME network. This is accomplished via either a Virtual Private Network (VPN) or a leased line connection to CME. Existing direct connectivity to the CME network maintained by the User/Service Provider for access to other CME systems may be leveraged for using CME CTR services. 

For more information on establishing an MQ connection or leveraging an existing MQ connection with CME, please send an email to repositorysupport@cmegroup.com.

Web Services

CME CTR allows programmatic submissions, cancellations, and amendments via secure http web services. This web service submission facilitates connection to the CME CTR via the internet, removing the need for any other type of connectivity infrastructure (such as MQ). Either FiXML or CSV formatted data may be passed via this transport method. Full technical details are available below:

Web User Interface Upload

Users or service providers may use the CME CTR secure web User Interface (UI) to upload CSV formatted files. On-screen confirmations are provided on acceptance or identify required corrective actions.
Full documentation on this option (including the asset class specific CSV templates and samples) are available here.

SFTP

About SFTP                                                                                     

Secure File Transfer Protocol (SFTP), is a method of transferring data between to end points using strong encryption and authentication.  We utilize this to allow confidential and easy transfer of files between our clients and our CME Repositories. 

Getting Access to SFTP

 Fig.1 Taken from CTR User Agreement

Technical Set-Up Information

CME supports file transfer through Secure FTP available via Wide Area Network connection as well as via the Internet. Please have your IT Staff facilitate the below connectivity and provide access through your firewall for our IPs as required.

CME Public Key Installation

CME allows the use of public/private key authentication. (SSH Public Key File format RFC4716).  Firms who require the use of public keys are responsible for the installation themselves.

Please note:  Public key may not be required as it is dependant of the connection method you use

CME uses SSH Public Key File Format (RFC4716)

The location of your public key should be installed to: 
“YOUR_CME_SFTPNG_HOMEDIR”/.ssh/”USERNAME”

Example, where username is “USERNAME”:
sftp> ls .ssh
.ssh/USERNAME

If you already have an RFC4716 Public Key file yet installed at CME
Here’s the steps, you’ll need to update the Public Key named “USERNAME” at CME:

1. Sftp to the site
2. Run the command, sftp> get .ssh/”USERNAME” where “USERNAME” is your login name.
3. Append new key(s) to the Public key file.
4. Put the key file up, sftp> put .ssh/”USERNAME” where “USERNAME” is your login name.

If you don’t have an RFC4716 Public Key file yet installed at CME
Here are the steps, you’ll need to have the Public Key file named “USERNAME” which contains the keys in the local directory on your source host in order for these steps to work:

1. ssh-keygen –t rsa –b 2048 –f id_rsa –N ‘’ && ssh-keygen –e –f id_rsa > USERNAME
2. sftp to the site
3. Put the key file up, sftp> put .ssh/”USERNAME” where “USERNAME” is your login name.
    NIST expects that a 2048 key size will be secure until 2030
    (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf). You can opt for 4096, but it is not required.
    More about RFC 4716 https://tools.ietf.org/html/rfc4716

CME SFTP Directory and Path Structure

Regardless how firms connect to their CME sftp account, there are 3 default directories that each firm is provided when their sftp account is added. Each folder is utilized for a specific purpose as outlined below including the directory path, note that 123 represents the firm’s sftp account ID:

cme/ftp/123/Incoming (with upper case I)
cme/ftp/123/Outgoing (with upper case O)
cme/ftp/123/PUB (all upper case)

When a user logs into their sftp account, the default maps to the user account root directory where the above 3 folders securely accessed by the account. Firms then can navigate between the folders and sub-folders based on their data upload or download requests.

Incoming: Used for confidential data files submitted by firms to CME. Firms will upload the required files to the Incoming directory as required by CME.
Outgoing: Used for confidential files that CME makes available for firms. Firms will be able to download files when they are ready to be retrieved.
PUB: Used for shared files that CME makes available for firms into specific sub-directories. Firms will be able to download files when they are ready to be retrieved from the sub-directories.

Submitting Files to SFTP

The folder will have two sections: Incoming and Outgoing. Files must be dropped for upload into the incoming section, and reports can be pulled from the outgoing section. There will be a response file in the outgoing file which is prefixed with ‘res_’ to the data file.  There is an acknowledgment for each file; if the data is successful the response file will simply contain ‘success’.  If there are errors the response file will be larger and will contain ‘error’ and give a detailed message explaining the failure.  Duplicate submitted records are rejected with an appropriate error message and for every 1 file submitted into incoming there will be 2 files in outgoing (the original file submitted and the results file).  Files dropped in the incoming folder to upload in the TR should be asset class specific.

• All submitted files must be in .csv format.

• All response files will be in .txt format.

CTR Messages Flows

This section illustrates select high level message flows between CME CTR and users.

CME Cleared Trade Submissions to CME TR

The following diagrams depict the flow when a trade is transacted on a platform, and is subsequently submitted to a clearing agency. It is assumed that initial bilateral trade is submitted to CME CTR and that the cleared novated trades are also submitted to CME CTR. The figures below depict submissions for two scenarios: i) Creation and Lifecycle data are submitted to CME CTR on separate messages, and ii) Creation and Lifecycle data are submitted to CME CTR on the same message.

Agency Clearing Model

Scenario 1

Two Canadian counterparties execute a bilateral (aka ‘alpha’) transaction intended for clearing and submitted to a Clearing Agency, such as CME Clearing for acceptance. Simultaneously the designated counterparty must report the original bilateral/alpha transaction to a Trade Repository, unless the responsibility has been delegated to a Service Provider.  Once the bilateral/alpha trade is accepted for clearing, the transaction is terminated and replaced with two new equal and opposite resulting cleared trades, beta and gamma. Beta and gamma are reported by the Clearing Agency to CME CTR.

Scenario 2

A Candian counterparty and a non-Canadian counterparty execute a bilateral (aka 'alpha') transaction intended for clearing and submitted to a clearing agency such as CME clearing for acceptance. Simultaneously, the canadian counterparty must report the original bilateral/alpha transaction to a trade repository, unless the responsibility has been delegated to a Service Provider. Once the bilateral/alpha trade is accepted for clearing, the transaction is terminated and replaced with two new equal and opposite resulting cleared trades, beta and gamma. The gamma trade that pertains to the Canadian counterparty is reported by the Clearing Agency to CME CTR and the beta transaction that relates to a non-Canadian entity is not required to be reported under any in force Canadian trade reporting rules.

Principal Clearing Model

Scenario 3

Two Canadian counterparties s execute a bilateral (aka 'alpha') transaction intended for clearing and submitted to a clearing agency such as CME clearing for acceptance. Simultaneously, the designated canadian counterparty must report the original bilateral/Alpha transaction to a trade repository, unless the responsibility has been delegated to a Service Provider. Once the bilateral/alpha trade is accepted for clearing, the transaction is terminated and replaced with two new equal and opposite resulting cleared trades, beta and gamma. The clearing agency will report the beta and gamma transactions to CME CTR and will include on the trades reported that CB1 and CB2 are the Principals on the trade. 

Scenario 4

A Canadian counterparty and an non-Canadian counterparty execute a bilateral (aka 'alpha') transaction intended for clearing and submitted to a clearing agency such as CME clearing for acceptance. Simultaneously, the canadian counterparty must report the original bilateral/Alpha transaction to a trade repository, unless the responsibility has been delegated to a Service Provider. Once the bilateral/alpha trade is accepted for clearing, the transaction is terminated and replaced with two new equal and opposite resulting cleared trades, beta and gamma. The clearing agency will report the beta and gamma transactions to CME CTR and will include on the trades reported that CB1 and CB2 are the Principals on the trade.

CME Bilateral (Non-Cleared) Trade Submissions to CME CTR

The following diagrams depict the flow in which a bilateral trade is transacted on a platform, and is subsequently reported to the CTR.

Life-Cycle (Continuation) Data Reporting

Life-cycle event data reporting can be reported either using the life-cycle approach, or using a snapshot approach. The life-cycle approach involves reporting all life-cycle events affecting the terms of a swap. The snapshot approach requires reporting of a daily snapshot of all primary economic terms of a swap including any changes to such terms occurring since the previous snapshot. The life-cycle event data reporting also includes valuation data.

Reporting Continuation Data for all other Trades (Bilateral and Cleared at other Clearing Agencies)

Generate Authentication Token

1. Login to https://ctrui.cmegroup.com with your CME Group Login ID and password
2. Navigate to Submit>Generate Token menu as shown in screen shot below:

Open

3. Enter your username and password and click “Generate Token”. It should give you your authentication code for using web service in Token text field. You will have to use valid username and password which is authorized by CME Repository Support Group during Registration. (Make sure you have already changed the temporary password provided during registration. You can use https://ctruinr.cmegroup.com/ctrui/ to change your temporary password. It will prompt you to change the password when you login first time)

Open

4. You are ready to use this token for your web service client code to submit FIXML or CSV messages to CME TR. This token will be used as a value for http header name “Authorization” (Please refer to DataCaptureWSClient.java code ).

Importing Certificate in Local Java Store

1. Open https://ctrws.cmegroup.com/datacapture-ws/ctr/submitCSV/CMDTY URL in IE.
2. Click on Lock image and click on View Certificate. You will see following dialog box

3. Open Certificate Path Tab and select VeriSign as shown in image below.

4. Select Details tab and click “Copy to File” and Click Next


5. Select first format option of “DER encoded binary X.509 (.CER) on “Certificate Export Wizard” dialog and click Next as shown in below screen shot

6. Specify file name and local path to store the certificate on your local machine (e.g C:/etrwsnr.cer)
7. Click Next and Finish. It will save the certificate locally on your machine in C:/etrwsnr.cer file which we will import to your local java keystore.
8. Open DOS command window
9. Type following command at DOS prompt to create and import the certificate in local keystore.

10. It will prompt you for password for your keystore. Enter any password which you will be passing later to your Web Service client along with path to the keystore you will be creating (e.g password “trwsnrclient”). Hit enter key. Retype same password and hit enter key again. 
11. Type “yes” for Trust this certificate? [no]. Hit enter key. You should see last line as “Certificate was added to keystore” as shown in following screen shot.