Scope, Terms and Conditions of KDPW_CCP Reporting of ETD Transactions to the Trade Repository Operated by KDPW Document history

Transcription

1 Scope, Terms and Conditions of KDPW_CCP Reporting of ETD Transactions to the Trade Repository Operated by KDPW Document history No. Date Section Reason Modification TRN example on page 7 Incorrect value of Counterparty side of Clearing Member From: TRN: 000KDPW000E PL0GF S to: TRN: 000KDPW000ES PL0GF Pages 4-5 Additional TRN details Addition of TRN generating algorithms for position transfers, transaction transfers and backloading Pages 4, 10 Modification of requirements for NKK and clearing accounts Additional details on client identification in the absence of an LEI. Requirement to specify the country of the reporting entity Page 11 Additional KDPW_TR service KDPW_TR automatically terminates contracts on maturity Page 5 Market transaction identifier not unique Page 9 Additional details for field (Corporate sector) Additional details on TRN field technical ISIN code used by WSE will be used here for block trades Field need not be filled for non-financial counterparty (field 2.9.4) Page 8 Modified approach on the Additional identifiers acceptable to reset the flag. requirement to provide an LEI in reports accepted by TR Page 8 TR requirement Validation of the length of LEIs Page 2 Publication of the new Q&A Indication of a new link for the website, where were published the new O&A ESMA Page 5 Define the length of the field MktRef From: 8 To: max Page 7 Indication of the counterparty side of reports and UTI codes for scenario 3 For scenario 3 (reports 11 and 12) counterparty side to the transaction are client and CCP. UTI code has an extension Pages 6 UTI for transfers Presentation of the mode of reporting transfers and assigning UTI (extension 006) Page 10 Change of date Modification of the reporting start date for collateral and valuation details from 12 August 2014 to 11 August Page 11 Termination by TR TR terminates ISIN on t Page 10 Change of date Modification of the date of publication of the structure of the message used to notify KDPW_CCP of details of collateral posted with a clearing member by its client from June 2014 to 19 May Page 10 Reporting clients collateral Description of the process of providing KDPW_CCP with information on clients collateral deposited with Clearing Members Page 10 Reporting clients collateral The reported value is the value of clients collateral and not the difference between the value of assets deposited with a Member and the value of assets deposited with KDPW_CCP Page 11 Reporting historical transactions Detailed information on backloading for outstanding and expired transactions on 12 February Page 11 Modification of status names Modification of the status name from PEND to PACK, and the status name from PACK to COMP Page 11 Modification of the date of accepting client collateral reports All client collateral reports for day T sent to kdpw_stream no later than 07:30 on day T+1 are forwarded to the trade repository KDPW_TR on that day Page 4-5 Adjustment to level 2 of validation Adjusting TRN and UTI algorithm construction to VL2. Indication new link for the website, where a new Q&A ESMA have been published Page 5 6 Editorial error TRN and UTI examples Zeroes in TRN and UTI examples have been erased Page 2, 10 and 11 Change in RTS of European Commission The ultimate reporting date for the trades executed before August 16 th 2012 and still outstanding on August 16 th 2012 as well as contracts concluded on or after August 16 th 2012 has been shifted from 3 to 5 years since the Reporting Start Day. 1

2 Reporting Obligation General The Regulation of the European Parliament and of the Council (EU) No 648/2012 on OTC derivatives, central counterparties and trade repositories (EMIR) imposes specific reporting obligations on CCP clearing houses and counterparties to derivatives contracts including both exchange-traded derivatives (ETD) and OTC contracts. a. Reporting Start Date The start date of the obligation of reporting derivative transactions to trade repositories is 12 February 2014 (Reporting Start Date, RSD). Entities subject to the reporting obligation are also required to backload transactions that are outstanding at the reporting start date as at the end of day of 11 February 2014, which means that it was possible to backload positions as at the end of that day. The obligation of reporting details of transactions that were outstanding on 16 August 2012 and are outstanding on 12 February 2014 required that they are reported to a trade repository within 90 days. Derivative transactions that were outstanding on 16 August 2012 but are no longer outstanding on 12 February 2014 must be reported to a trade repository within 5 years. KDPW_CCP will provide Clearing Members and, through them, other reporting entities with an additional backloading service. The start date of the obligation of reporting valuation and collateral details of derivatives to a trade repository had been extended by 180 days (start date: 11 August 2014). b. Reporting Documentation The applicable technical standards and time limits referred to above are available online: The European Securities and Markets Authority (ESMA) regularly publishes Questions and Answers, Implementation of the Regulation (EU) No 648/2012 on OTC derivatives, central counterparties and trade repositories (EMIR) (Q&A). The Q&A were last updated on the 1 October 2015 (ESMA/2015/1485) and are available online: The European Commission published EMIR: Frequently Asked Questions on 18 December The FAQ are also available online: 1. Reporting Transactions by KDPW_CCP According to the obligation imposed under EMIR, KDPW_CCP reports all derivative transactions to which it is a counterparty to the trade repository operated by KDPW. According to the ESMA Q&A, a Clearing Member is a counterparty to every transaction reported by KDPW_CCP. Irrespective of the applicable reporting chain, KDPW_CCP always provides Report 2 to the trade repository in compliance with the reporting obligation (see Fig. 1) 2

3 Report Who has the reporting obligation(15)? UTI TRN Counterparty (2) Counterparty ID Broker ID (8) CM ID (10) Beneficiary ID(11) Trading capacity (12) Counterparty side(13) Venue of execution1 CCP ID KDPW_CCP Reporting Schema (Fig. 1) 1 CM UTI001 TRN CM CCP CM CM P B MIC WSE 2 CCP UTI001 TRN CCP CM CCP CCP P S MIC WSE KDPW_CCP KDPW_CCP 1 For portfolio transfers derivatives code MIC, will be XOFF 3

4 a. LEI In derivative transaction reports, KDPW_CCP as a reporting counterparty is identified by an LEI. The LEI issued by KDPW to KDPW_CCP is: K576D5CQXI987. Considering that a Clearing Member is a counterparty of KDPW_CCP in every derivative transaction reported to the trade repository, all Clearing Members active on the derivatives market must have an LEI. A Clearing Member notifies KDPW_CCP of its LEI once in a declaration presented according to the requirements of participation. More information on LEIs issued by KDPW is available online: In the interim period, whose duration will be established depending on the regulatory requirements, it will be possible to delegate to KDPW_CCP the reporting obligation of your clients who have no LEI (using only the Client Classification Number (NKK)). b. Transaction Identifiers Every transaction reported to a trade repository has a unique identifier: the Transaction Reference Number (TRN). KDPW_CCP generate a TRN based on the transaction identifier provided by WSE (MktRef). The identifier is unique only for the transaction date and the instrument ISIN code. According to the requirements, a TRN has up to 40 characters. A TRN is unique to every novated transaction. Consequently, KDPW_CCP generate a TRN according to the following algorithm: TRN Generating Algorithm - New Transaction (Fig. 2a) Field no. Length Description Value E01MIC KDPW_CCP000 E01KDPW Market code E 12 1 Counterparty side of Clearing Member (before novation) Transaction date YYYYMMDD B/S Instrument ISIN 3 ISIN 33(32+N,max.8) N(max.8) WSE transaction identifier MktRef TRN example: for a transaction with the following parameters: 2 The same value is used for all reports in the chain for a novated transaction: B (Buy) or S (Sell) from the perspective of the Clearing Member. This means that a TRN is based on value S for all transactions reported in a chain where KDPW_CCP is the Buyer and Clearing Member is the Seller in the novated transaction, and value B for all transactions reported in a chain where KDPW_CCP is the Seller and Clearing Member is the Buyer in the novated transaction. 3 Technical ISIN code used by WSE is used here for block trades. 4

5 Counterparty side: S (in the novated transaction, Clearing Member is the Seller, KDPW_CCP is the Buyer) Transaction date: ISIN: PL0GF MktRef: 256 TRN: E01KDPW000ES PL0GF TRN Generating Algorithm Transaction and Position Transfer (Fig. 2b) Field no. Length Description Value E01MIC KDPW_CCP000 E01KDPW Market code T 12 1 Position side B/S Instrument ISIN ISIN 25-(24+N) N KDPW_CCP identifier KDPW_CCP identifier TRN example: for a transfer of position with the following parameters: Position side: S ISIN: PL0GF KDPW_CCP identifier: TRN: E01KDPW000TSPL0GF TRN Generating Algorithm Backloading (Fig. 2c) Field no. Length Description Value E01MIC KDPW_CCP000 E01KDPW Market code B 12 1 Position side B/S 13- (12+N, max. 28) N 16) (max. Reported position number Ordinal number TRN example: for a position: Position side: S Ordinal number: 228 TRN: E01KDPW000BS228 5

6 c. Report Identifiers The identifier of a pair of reports / report (UTI) is generated based on a TRN plus an identifier of each pair of transaction reports sent to the trade repository (UTI extension). A UTI is generated by adding 00N to a TRN (TRN00N) as per the rules presented in the Table for Fig. 4b taking into account the reporting chains defined in Fig. 4a. It should be noted that netting (KDPW_TR building of a position reflecting KDPW_CCP clearing account balances) requires that every new transaction has a UTI based on the version number added to the UTI extension. A description of netting is presented below. The report version number has the format V_X where X is the sequential numeral (UTI Generating Algorithm (Fig. 3)). According to the requirements, a UTI has up to 52 characters. Consequently, KDPW_CCP generate a UTI in reports provided under the reporting obligation according to the following algorithm: UTI Generating Algorithm (Fig. 3) Field no. Length Description Value Trade identifier TRN Max 12 UTI extension 00X or 00XV_X UTI example: for a pair of transaction reports with the following parameters: TRN: E01KDPW000ES PL0GF UTI extension for the pair of reports: 001 UTI: E01KDPW000ES PL0GF UTI example: for a report after netting version 1 (first netting of the position by KDPW_CCP): TRN: E01KDPW000ES PL0GF UTI extension for the report after netting version 1: 001V_1 UTI: E01KDPW000ES PL0GF V_1 Reports under Q&A Scenarios (Fig. 4a) Scenario 1: Reporting chain where the broker has the reporting obligation and every entity has a different role (UR= Clearing Member, klient=client, Broker=Investment Firm, Scenario 1, Question ETD2, Q&A) 6

7 Scenario 2: Reporting chain where the broker has no reporting obligation or an entity is a Broker and a Clearing Member (UR= Clearing Member, klient=client, Broker=Investment Firm, Scenario 2, Question ETD2, Q&A) Scenario 3: Reporting chain where the Clearing Member is a Client (UR= Clearing Member, klient=client, Question ETD2, Q&A) Scenario for reporting transfers (klient=client): UTI in Reports under Q&A Scenarios (Fig. 4b) Report Who has the reporting obligation? Counterparty UTI TRN 1 CM CCP TRN001 TRN 2 CCP CM TRN001 TRN 3 Broker CM TRN002 TRN 4 CM Broker TRN002 TRN 5 Client Broker TRN003 TRN 6 Broker Client TRN003 TRN 7 CM CCP TRN001 TRN 8 CCP CM TRN001 TRN 9 Client CM TRN004 TRN 10 CM Client TRN004 TRN 7

8 11 Client CCP TRN005 TRN 12 CCP Client TRN005 TRN 13 Client Client TRN006 TRN 2. Delegating the Reporting Obligation a. General KDPW_CCP provides the service of reporting details of derivative transactions to the Trade Repository operated by KDPW on request of a Clearing Member. Reporting can be delegated by Clearing Members and, through them, by their Clients and entities entering into derivative transactions on request of Clients (Brokers). Reporting is delegated by KDPW_CCP as follows: 1. written declaration submitted by a Clearing Member delegating the obligation of the Clearing Member and Brokers entering into transactions on request of Clients (declaration template available on the KDPW_CCP website). In a declaration submitted to KDPW_CCP, a Clearing Member specifies the LEI and other details necessary to ensure correct transaction reporting. Where the reporting obligation is delegated to KDPW_CCP, a Clearing Member should eventually additionally specify the LEI for the NKK of those of its Clients that are subject to the reporting obligation for derivatives. 4 Where a Clearing Member clears transactions entered into by Brokers on request of Clients, the Clearing Member s declaration must include the information listed above also for those Brokers that have the reporting obligation under EMIR (i.e., they are an Investment Firm in Scenario 1, Question ETD2, Q&A). 2. XML messages dedicated to delegating the obligation for clearing accounts (including Clients accounts, Clearing Member s own position accounts, Brokers own position accounts): a. Clearing account reporting flag (where reporting is delegated message acmt.rqa Clearing account instruction); b. Additional information for NKK (acmt.rqc NKK instruction). b. Clearing Account Reporting Flag (acmt.rqa ) In the message acmt.rqa , for the purpose of reporting, the following field has been added: RprtAu Reporting authorisation for KDPW_CCP - Y or N The field indicates whether or not the member has delegated the reporting of derivative contracts registered in the clearing account to KDPW_CCP; if so, the reporting flag should be set to Y. A flag may be reset irrespective of the enrichment of NKK data as described in item (c). c. Additional information for NKK (acmt.rqc ) 4 KDPW_CCP will report transactions always according to data attributed to a client NKK, e.g., in the absence of a LEI, for a Clearing Member s counterparty identified as an entity other than an individual not subject to the reporting obligation, KDPW_CCP will populate Field 3 Other counterparty identifier with the NKK. In the interim period, whose duration will be established depending on the regulatory requirements, it will be possible to delegate to use the NKK as the identifier of the reporting entity (client). 8

9 For KDPW_CCP to fulfil the reporting obligation on behalf of clients, the following additional information must be provided to the KDPW_CCP system in message acmt.rqc (as a minimum): 1) where the client has an LEI: LegalSts Institutional / Individual client (indicates whether the other counterparty has the reporting obligation or is an individual not subject to reporting. According to the definition of undertaking in the European Commission document, 5 individuals carrying out an economic activity have the reporting obligation) LEI legal entity identifier (populated with at least 20 characters. KDPW_CCP checks the number of characters), Ctry Country FinNonFinInd - Financial/Non-financial indicator (F-Financial, N-Non-financial) CmmrclActvty - Directly linked to commercial activity or treasury financing (Y Yes, N - No) ClrTrshld - Clearing threshold for the OTC CCP clearing obligation (only for nonfinancial counterparties; Y-Above, N-Below) If the field Country is not populated, KDPW_CCP will populate the Trade Repository report with the default value PL. 2) where the client has no LEI: LegalSts Institutional client / Natural person (Indicates whether the other counterparty is a client with a reporting obligation or a natural person with no reporting obligation. According to the definition of undertaking in the European Commission document, 6 natural persons who carry out an economic activity have the reporting obligation) CtrPtyAdrAndSctr Counterparty address and sector Nm - Name Dmcl - Domicile Ctry - Country PstCd - Post code TwnNm - Town name StrtNm Street name CorpSctr Corporate sector 7 of the client (need not be populated for a non-financial counterparty field 2.9.4) 5 EMIR: Frequently Asked Questions published by the European Commission on 18 December 2013, available online: 6 EMIR: Frequently Asked Questions published by the European Commission on 18 December 2013, available online: 7 According to the classification for Field 6 in Table 1 of Commission Delegated Regulation (EU) No 1247/

10 In every case, the following need to be populated: FinNonFinInd - Financial/Non-financial indicator (F Financial, N Non-financial) CmmrclActvty - Directly linked to commercial activity or treasury financing (Y Yes, N - No) ClrTrshld - ClrTrshld Clearing threshold for the OTC CCP clearing obligation (only for non-financial counterparties; Y-Above, N-Below) Information on XML messages is available online: KDPW_CCP sends transaction reports to the trade repository on the business day following the transaction clearing date. KDPW_CCP sends reports according to the delegation of the reporting obligation provided that declarations / XML messages are effectively submitted one day before the date of the transaction to be reported by KDPW_CCP. Access to data reported by KDPW_CCP as part of the reporting intermediation service is available in the KDPW_TR system accessible only to Trade Repository Participants. Information on the terms and conditions of participation in the trade repository operated by KDPW is available online: On written request of a Clearing Member, KDPW_CCP provides a declaration of fulfilment of the obligation of reporting transactions to a trade repository according to applicable legislation for transactions covered by the delegation of reporting. At the same time, KDPW_CCP provide Clearing Members with reports sent by the trade repository for trades reported under the delegated reporting obligation. d. Reporting Valuation and Collateral The reporting obligation applies both to details of derivative transactions and to valuation of derivatives and collateral posted with KDPW_CCP, Clearing Members and, if applicable, entities entering into derivative transactions on request of Clearing Members Clients. KDPW_CCP report collateral posted by a Clearing Member in KDPW_CCP accounts by reporting the aggregate value of collateral in all collateral accounts. KDPW_CCP report such details to KDPW_TR as of RSD. KDPW_CCP started to report collateral 180 days after RSD, i.e., as of 11 August KDPW_CCP will report details of collateral posted with Clearing Members and entities entering into derivative transactions on request of Clearing Members Clients based on XML messages sent to KDPW_CCP; message format and structure were to be published on the KDPW_CCP website by 19 May The collateral account used in reports is built by adding the Clearing Member s code and NKK. KDPW_CCP reports valuation by class of instrument listed on WSE based on data provided in UTP files. KDPW_CCP report such details to KDPW_TR as of RSD. The process of reporting collateral posted with Clients by Clearing Members (CM) is as follows: 1. CM sends to KDPW_CCP a message colr.ins whose structure is available on the website: 10

11 A message with the value of clients collateral is sent to TR on the next day (t+1), but all client collateral reports for day T sent to kdpw_stream no later than 07:30 on day T+1 are forwarded to the trade repository KDPW_TR on that day. 2. KDPW_CCP only checks whether the sent message conforms to the schema. In case of nonconformity of a message with the schema, the message status is set to error (admi.err ) and the location of the error is specified. 3. For a conforming message, the message status is set to pending processing in KDPW_CCP (PACK). In reply, KDPW_CCP sends a status message to CM (colr.sts ). 4. Next, on receipt of feedback from TR, KDPW_CCP sends to CM a status message (colr.sts ) according to the feedback from TR (COMP or REJT). Status COMP means that the message has been accepted and successfully processed by TR; status REJT means that the message has been rejected by TR and specifies the error code and the reason of rejection by TR. e. Backloading KDPW_CCP had done first backloading data to KDPW_TR for entities that delegate the reporting obligation to KDPW_CCP by reporting the current net position in derivative contracts to the trade repository at the end of the last clearing day before RSD, i.e., at 11 February This fulfilled the obligation of reporting transactions outstanding on 12 February There will be no additional reporting of such transactions individually. In order to fulfil the requirement of reporting details of transactions which were expired on 12 February 2014, KDPW_CCP will offer to Clearing Members and through them to other entities which have the reporting obligation an additional service of reporting historical transactions at a later date. Firstly it was regulated that abovementioned transactions should be reported within 3 years since RSD, however it has been prolonged to 5 years. It means that the ultimate date is February f. Position Netting in the Trade Repository Where a position arising from transactions in a clearing account, for an ISIN code, in particular as a result of registration of opposite transactions, at a given clearing day is equal to 0, KDPW_CCP will net the position in the Trade Repository by sending a message with action type C for all transactions in the position. In addition, positions are netted up to a balance other than 0: partial netting of positions is apply to all opposite transactions, which may result in partial termination of a single transaction. In that case, the trade repository will register a new version of a report with the same data other than the following fields: Quantity of instruments - equal to the quantity of derivative instruments after partial position netting; Compression flag - the new transaction is flagged for compression ( Y ); Field Id (section TradId) - new value for the new transaction version: UTI: TRN + 00NV_X. g. Terminating Derivatives on Expiry On the day following the expiry date of futures and options, the KDPW_TR trade repository automatically terminates all transactions in expired contracts. For exercise of index participation units or American options before expiry, KDPW_CCP will instruct the trade repository to perform partial position netting. 11