1.0 INTRODUCTION PREREQUISITES CONTACT INFORMATION 2

Transcription

1 Version 1.0

2 Contents 1.0 INTRODUCTION PREREQUISITES CONTACT INFORMATION ACCESS TO CME Registering for the Test Environment Registering for the Production Environment Additional User Access Requests Regulatory Authority Access Access Levels TRADE SUBMISSIONS MQ Web Services UI Upload FTP MESSAGE FLOWS CME CLEARED TRADE SUBMISSIONS TO CME UTI flow for Agency Style cleared submissions UTI flow for Principal Style cleared submission CME BILATERAL (NON-CLEARED) TRADE SUBMISSIONS TO CONTINUATION DATA REPORTING CME Clearing continuation data reporting Non-CME Clearing continuation data reporting ADDITIONAL INFORMATION 14

3 1.0 Introduction This document provides an overview of CME's Canadian Trade Repository () serving the Manitoba, Ontario, Quebec provinces. It details supporting functions, workflows, message flows, and interfaces to allow registered Users to submit and retrieve swap data to with the. leverage existing CME repository and clearing services connectivity, functionality and processes in order to accept, store and report swap data. 1.1 Prerequisites This document assumes that 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 Business Team: Support Team: Support Team Phone number: Chicago +1 (312) London +44 (0) Singapore Access to the CME 2.1 Registering for Test Environment Access In order to assist clients with their preparation for the various Canadian provincial reporting regulations, CME has created a Test Environment. Access to the Test Environment can be granted prior to execution of the CME User Agreement by the completion of an informational form. Production Environment access may only be granted to Users and Service Providers with completed registrations and Legal Agreements. A full User registration also includes access to Test Environment. Service Providers do not have a Test Environment only option, and must the full Service Provider Agreement (which includes test environment access) Steps for CME ETR Test Environment access include: 1. Complete the User Agreement or Test Environment form (single form to gain access to any of CME s Global Trade Repositories) at Fill out the registration form electronically (do not print and complete). 2. Upon completing the registration; use the forms submit button and your system s default program will prepare an to the Registration Team. If you prefer a different program to send in the form, you may copy the attachment and address into that preferred program. 3. Once the form has been received, CME will process the request. Upon completion, CME will send an to the administrator contact confirming the registration and provide information on how to get started. NOTE: The URL ( for the test environment is different to the production environment. For assistance during or following the registration process; please contact CME Global Repository Client Services at repositorysupport@cmegroup.com. CME User Guide Page 2

4 2.2 Registering for Production Environment Access Production Environment access is only granted to fully registered Users and Authorized Service Providers. The following steps outline the registration process required to submit and to access derivative data to CME for Canadian reporting compliance. A. Obtain a Legal Entity Identifier (LEI) A LEI is strictly required at the time of full registration. A LEI is required for each separate legal entity for who data will be submitted or retrieved for from the CME.. Users may acquire a LEI through one of the authorized LEI issuers listed at A 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 registration so long as the issuer is recognized on the LEI ROC website. CME Central Counterparty (CCP) LEI s provided for reference: Chicago Mercantile Exchange Inc. (US Clearing House) CME Inc. LEI: SNZ2OJLFK8MNNCLQOF39 CME Inc. UTI Namespace: CME Clearing Europe CMECE LEI: 6SI7IOVECKBHVYBTB459 CMECE UTI Namespace: 000CMEC000 B. 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.. In order to execute the CME User Agreement: Download the agreement from the CME website Complete the user agreement and click the send button to electronically submit the agreement to the CME Registration team. The User Agreement will be received and processed by the CME Registration Team. A notification of receipt of the submission is provided and a subsequent notification is sent when the registration has been completed. In the registration complete , instructions are provided on how to contact the CME registration team to receive the login information over the phone (for security reasons). Schedule A -(CME registration entity details). A required form as part of CME registration. Firms are required to specify at least one Verification Officer upon registration. The Verification Officer will act as the account administrator, approving any new requests or access modifications, etc. In addition to a Verification Officer regular Users can also be requested. Verification Officers have a choice of admin roles or view only roles. Admin roles allow users to upload, amend and view while a View Only role allows for read only access to the. Schedule C bulk registration for investment advisors or multiple entities under the same corporate structure. Schedule C may be found at CME User Guide Page 3

5 Service Provider Agreement Applies to entities which are not party to the trade and are providing services to facilitate the trade report in some capacity on behalf of one or both of the obligated counterparties to the reportable derivatives trade. Parties interested in a Service Provider registration should contact CME at repository@cmegroup.com. 2.3 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 located at Regulatory Authority Access A Regulatory Authority wishing to gain access to CME is required to contact Kim Nordhoff or Igor Kaplun: kimberly.nordhoff@cmegroup or igor.kaplun@cmegroup.com or Access Levels CME Administrator: 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 CME Full Access: Rights to view data for accounts Rights to upload data for accounts Rights to run all reports and download the results for accounts CME View Only Access: Rights to view data for accounts CME View Only Access: Queries regarding permissioning for Regulatory Authorities should be directed to repositorysupport@cmegroup.com. CME User Guide Page 4

6 3.0 Trade Submissions to CME Swaps may be submitted to CME via the following methods: Format FIX API FIX File CSV File CSV File CSV File Transport MQ HTTPS web services Website upload HTTPS web services sftp Transport Overview 3.1 MQ FiXML API submission via MQ is a full service option for submitting, cancelling, or amending derivative data to CME. MQ is an IBM product that facilitates software messaging between two computer systems. In order to use MQ based messaging system, firms would require the 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 facilitating MQ connectivity is to establish connectivity into the CME network. This can be accomplished via either a Virtual Private Network (VPN) or a leased line connection into CME. Existing direct connectivity into the CME network maintained by the User/Service Provider for access to other CME systems may be leveraged for use of CME services. For more information on establishing a MQ connection or leveraging an existing MQ connection (with CME), please contact repositorysupport@cmegroup.com. 3.2 Web Services CME allows for programmatic submissions, cancellations, and amendments via secure http web services. This web service submission facilitates connection to the CME 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 documentation on this option is available at CME User Guide Page 5

7 3.3 Web User Interface Upload Users or Service Providers may use the CME secure web User Interface (UI) to upload CSV formatted files. On screen confirmations are provided on acceptance and/or to identified corrective actions required. Full documentation on this option, including the asset class specific CSV templates and samples are available online FTP CSV files may be submitted to CME via secure FTP. Status of such FTP based submissions will be viewable via the CME web User Interface. To obtain an FTP account, customers will need to provide CME Repository Client Services the global LEI number and the name of the entity. Once that information is provided, customers will be provided by Client Services with folder name and password information to access their FTP folder. The folder will have four sections : Incoming,Outgoing, TestIncoming & TestOutgoing. Production files have to be dropped for upload into CME under the Incoming section, and reports can be pulled from the Outgoing section. The test files have to be dropped for upload into CME under the TestIncoming section, and reports can be pulled from the TestOutgoing 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 contain success. If there are errors the response file will contain error and give a detailed message explaining the failure. Duplicate records submitted will be rejected with an appropriate error message. Files dropped in the Incoming/TestIncoming folder to upload in the TR should be asset class specific and the name of the file which can have any additional information should be prefixed with the asset class name (CMDTY, FX, CDS, IRS). The files and the records in the folders will be processed in First in First out (FIFO) order. The time of submission will determine file order written to CME server. Existing FTP accounts with CME cannot be used for TR purposes, a new FTP account needs to be opened for trade reporting. Network details Production: XXXXXXXXXXX (tcp ports 20/21/22) Disaster Recovery: XXXXXXXXXXX(tcp port 20/21/22) For Internet connectivity, no network permissions are needed on the CME side, but firm User IDs are only available upon request from TR support. PROD/DR SFTP sftpng.cmegroup.com XXXXXXXXXXX and XXXXXXXXXX (tcp port 22) CME User Guide Page 6

8 When using SFTP, ssh encrypted software is required for connections. CME allows the use of ssh public/private key authentication. If this is something that is needed, the firm can provide their public key to the CME. This approach does not require a password when logging on and can aid in automation on the firm s side. Public Key Installation Documentation Please be advised the CME uses Open SSH format. If you already have an authorised_key file installed at CME the following steps should be used to update the authorised_keys file at CME: Sftp to the site Run the command, sftp> get.ssh/authorised_keys Modify the file by appending a new key(s) and then overwrite the key installed at CME Run the command, sftp> cd.ssh If you don t have an authorised_key file yet installed at CME the following steps should be used to update the authorised_keys file with the keys in the local directory on your source host in order for these steps to work: Sftp to the site Run the command, sftp> mkdir.ssh Run the command, sftp> chmod 700.ssh Run the command, sftp> cd.ssh Put the key file up, sftp> put authorised_keys Run the command, sftp> chmod 600 authorised_keys Put the key file up, sftp> put authorised_keys CME User Guide Page 7

9 4.0 Message Flows This section illustrates select high level message flows between CME and Users. 4.1 CME Cleared Trade Submissions to CME TR The following diagrams depict the flow in which a trade is transacted on a middleware platform, and is subsequently cleared at CME Clearing and submitted for TR reporting to CME Repository Service. It is assumed that initial bilateral trade is submitted to CME Repository Service and that the post cleared trades are also submitted to CME Repository Service. The figures below depict submissions for two scenarios: i) Creation and Lifecycle data are submitted to CME on separate messages, and ii) Creation and Lifecycle data are submitted to CME on the same message Agency Clearing Model Scenario 1 Two Quebec Derivatives Dealers execute a bilateral transaction intended for clearing and submit it to CME Inc. to be cleared. Once the trade is entered into CME Clearport (for Clearing); the bilateral/alpha transaction is terminated and replaced with two new equal and opposite resulting trades, beta and gamma. Alpha, beta and gamma are all reported by CME Clearing to CME. No action is required on behalf of the original counterparties to the bilateral transaction. The act of submitting for clearing satisfies reporting obligations. Canada Dealer vs. Canada Dealer Trade Cleared CME - (Agency Model) Alpha trade reporting by CME to Canada Cpty1 Dealer (AMF Reporting) Canada Cpty2 Dealer (AMF nonreporting) Trade Execution CMF1 Trade Cleared CME CMF2 CME User Guide Page 8

10 Scenario 2 A Quebec Derivatives Dealer and a Non-Derivatives Dealer, local counterparty, execute a transaction intended for clearing. The transaction is submitted to CME Inc. for clearing. Once the trade is entered into CME Clearport, the alpha transaction is terminated and replaced with two new equal and opposite resulting transactions, beta and gamma. Alpha, beta and gamma are all reported by CME Clearing to CME. No action is required on behalf of the original counterparties to the bilateral transaction. The act of submitting for clearing satisfies reporting obligations. Canada Dealer vs. Canada Local Trade Cleared CME - (Agency Model) Alpha trade reporting by CME to Canada Cpty1 Dealer (AMF Reporting) Canada Cpty2 Local Counterparty (AMF non-reporting) Trade Execution CMF1 Trade Cleared CME CMF2 Scenario 3 Two Non-Derivatives Dealer, Local Counterparties execute a trade that is intended for clearing and submit it to CME Inc. Once the trade is entered into CME Clearport, the alpha transaction is terminated and replaced with two new equal and opposite resulting transactions, beta and gamma. Alpha, beta and gamma are all reported by CME Clearing to CME. No action is required on behalf of the original counterparties to the bilateral transaction. The act of submitting for clearing satisfies reporting obligations Canada Local vs. Canada Local Trade Cleared CME - (Agency Model) Alpha trade reporting by CME to Canada Cpty1 Local Counterparty (AMF Reporting) Canada Cpty2 Local Counterparty (AMF non-reporting) Trade Execution CMF1 Trade Cleared CME CMF2 CME User Guide Page 9

11 Scenario 4 A Quebec Derivatives Dealer and a U.S. Swap Dealer execute a transaction with the intent to clear. The transaction is submitted to CME Inc. for clearing. Once the transaction is entered into CME Clearport, the alpha transaction is terminated and replaced with two new equal and opposite resulting transactions, beta and gamma. Only the alpha and gamma transactions are reported by CME Clearing to CME because the beta transaction relates to a non-canadian entity and therefore is not required to be reported under any in force Canadian trade reporting rules. US SD vs. Canada Dealer Trade Cleared CME - (Agency Model) Alpha trade reporting by CME to US Cpty1 Swap Dealer (Reporting) Canada Cpty2 Dealer Trade Execution CMF1 Trade Cleared CME CMF2 Scenario 5 A U.S. Swap Dealer and a non-derivatives Dealer, local counterparty execute a transaction with the intent to clear. It is submitted it to CME Inc. Once the trade is entered into CME Clearport, the alpha transaction is terminated and replaced with two new equal and opposite resulting transactions, beta and gamma. Only the alpha transaction and gamma transaction are reported by CME Clearing to CME because the beta transaction relates to a non-canadian entity and is therefore not required to be reported under an in force Canadian trade reporting rules. US SD vs. Canada Local Trade Cleared CME - (Agency Model) Alpha trade reporting by CME to US Cpty1 Swap Dealer Cpty 2 Canada Local Cpty Trade Execution CMF1 Trade Cleared CME CMF2 CME User Guide Page 10

12 4.1.2 Principal Clearing Model Scenario 1 Two Ontario Derivatives Dealers execute a transaction with the intent to clear. It is submitted to CMECE for clearing. Once the trade is entered into CME Clearport, the alpha transaction is terminated and replaced with two new resulting equal and opposite transactions, beta and gamma. CME CE will also include on the trade report that CB1 and CB2 are the Principals on the trade. Canada Dealer vs. Canada Dealer Trade Cleared CMECE (Principal Model) Full chain reporting by CME CE to Canada Cpty1 Dealer Canada Cpty 2 Dealer δ Trade Execution ε Clearing Broker CB1 Trade Cleared CMECE Clearing Broker CB2 Scenario 2 An Ontario Derivatives Dealer and an EU Dealer execute a transaction with the intent to clear. The transaction is submitted to CMECE for clearing. Once the trade is entered into CME Clearport, the alpha transaction is terminated and replaced with 2 new resulting equal and opposite transactions, beta and gamma. All three trades are then reported to CME. CME CE will also include on the trade report that CB1 and CB2 are the Principals on the trade. EU Dealer vs Canada Local Trade Cleared CMECE (Principal Model) Full chain reporting by CME CE to EU Cpty1 Dealer Canada Cpty 2 Local δ Trade Execution ε Clearing Broker CB1 Trade Cleared CMECE Clearing Broker CB2 CME User Guide Page 11

13 4.2 CME Bilateral (Non-Cleared) Trade Submissions to CME The following diagrams depict the flow in which a bilateral trade is transacted on a middleware platform, and is subsequently reported to the. Note that the trade in this scenario is non-cleared, and thus bypasses CME Clearing upon submission. Non-Reporting Counterparty (CP1) 1 Reporting Counterparty (CP2) 3 2 Platform/ Execution Venue 4 5 Scenario 1 1. Bilateral trade between CP1 and CP2 2. CP2 enters trade economics 3. CP1 affirms trade 4. Platform (or CP1 or CP2) may assign UTI to bilateral trade, and sends the trade to CME 5. CME echoes the UTI back to the platform. 5.0 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. CME User Guide Page 12

14 5.1 Reporting life-cycle event (continuation) data for trades cleared at CME CME User Guide Page 13

15 5.2 Reporting continuation data for all other trades (bilateral and cleared at other Clearing Agencies) 6.0 Links to additional information CME User Guide Page 14