HANDBOOK FOR TRADE REPOSITORY REPORTING NASDAQ CLEARING

Transcription

1 HANDBOOK FOR TRADE REPOSITORY REPORTING NASDAQ CLEARING DATE: DOCUMENT VERSION: 2.2

2 LEGAL DISCLAIMER The content of this document is subject to change without notice. Nasdaq makes no representations or warranties with respect to the information and disclaims all liability for any use made of the contents of this document. Nasdaq assumes no responsibility for any errors or omissions. Nasdaq does not provide legal advice. This document is provided for information purposes only, does not constitute legal advice and should not be relied upon for that purpose. For a more detailed explanation of the issues highlighted in this document, please contact your legal counsel. Professional legal advice should be obtained before taking or refraining from taking any action as a result of the contents of this document. Nasdaq cannot provide legal advice to clients and this summary is not a complete overview of how to prepare for derivative regulation under EMIR or any other regulations. For information regarding the impact of the areas discussed herein and steps that a counterparty must take in preparation of the pending compliance dates, counterparties are advised to contact their legal counsel. You and your legal counsel are encouraged to actively review and monitor regulations applicable to you.

3 TABLE OF CONTENTS SUMMARY OF CHANGES READING INSTRUCTIONS REPORTING OBLIGATION REPORTING OF EXCHANGE TRADED DERIVATIVES (ETD) REPORTING OF OTC CLEARED DERIVATIVES REPORTING OF NASDAQ OMX CLEARING AS A CCP IDENTIFIERS OF NASDAQ OMX CCP IDENTIFIERS TRADING VENUE IDENTIFIERS UTIS FOR TRADES AND POSITIONS BASIC CONCEPTS TRADE UTI POSITION UTI CONSTRUCTION OF UTI TRADE UTI POSITION UTI UTI FIELD DETAILS REPORTING OF REGULAR TRADES REPORTING OF UPDATES TO REGULAR BACKLOADED TRADES REPORTING OF OTC RATES TRADES REPORTING OF POSITIONS LIFECYCLE EVENTS ACCOUNT TRANSFER RECTIFY TRADE DEAL CANCELLATION NETTING AVERAGE PRICE TRADE CASCADING EXERCISE AND ASSIGNMENT TERMINATION EXPIRATION CORPORATE ACTION / ISSUE COUNTERPARTY DATA REPORTING COUNTERPARTIES COUNTERPARTY ID (FIELD 2) ID OF THE OTHER COUNTERPARTY (FIELD 3) NAME OF THE COUNTERPARTY (FIELD 4) DOMICILE OF THE COUNTERPARTY (FIELD 5) CORPORATE SECTOR OF THE COUNTERPARTY (FIELD 6) FINANCIAL OR NON-FINANCIAL NATURE OF THE COUNTERPARTY (FIELD 7) BROKER ID (FIELD 8) REPORTING ENTITY ID (FIELD 9) CLEARING MEMBER ID (FIELD 10) BENEFICIARY ID (FIELD 11) TRADING CAPACITY (FIELD 12) COUNTERPARTY SIDE (FIELD 13) CONTRACT WITH NON-EEA COUNTERPARTY (FIELD 14) DIRECTLY LINKED TO COMMERCIAL ACTIVITY OR TREASURY FINANCING (FIELD 15) CLEARING THRESHOLD (FIELD 16) MARK TO MARKET (FIELDS 17-21) MARK TO MARKET VALUE OF CONTRACT (FIELD 17) CURRENCY OF MARK TO MARKET VALUE OF THE CONTRACT (FIELD 18) VALUATION DATE (FIELD 19) VALUATION TIME (FIELD 20)... 23

4 5.2.5 VALUATION TYPE (FIELD 21) COLLATERAL (FIELDS 22-25) COLLATERALISATION (FIELD 22) COLLATERAL PORTFOLIO (FIELD 23) COLLATERAL PORTFOLIO CODE (FIELD 24) VALUE OF THE COLLATERAL (25) COMMON DATA REPORTING PRODUCT DETAILS EMIR COMMON DATA FIELDS ISIN CODES CFI UNDERLYING (FIELD 4) NOTIONAL CURRENCY (FIELD 5-6) DELIVERABLE CURRENCY (FIELD 7) TRANSACTION DETAILS TRADE ID (FIELD 8) TRANSACTION REFERENCE NUMBER (FIELD 9) VENUE OF EXECUTION (FIELD 10) COMPRESSION (FIELD 11) PRICE/RATE (FIELD 12) PRICE NOTATION (FIELD 13) NOTIONAL AMOUNT (FIELD 14) PRICE MULTIPLIER (FIELD 15) QUANTITY (FIELD 16) UPFRONT (FIELD 17) DELIVERY TYPE (FIELD 18) EXECUTION TIMESTAMP (FIELD 19) EFFECTIVE DATE (FIELD 20) MATURITY DATE (FIELD 21) TERMINATION DATE (FIELD 22) DATE OF SETTLEMENT (FIELD 23) MASTER AGREEMENT TYPE (FIELD 24) MASTER AGREEMENT VERSION (FIELD 25) RISK MITIGATION / REPORTING (FIELD 26-27) CLEARING CLEARING OBLIGATION (FIELD 28) CLEARING TIMESTAMP (FIELD 29) CLEARING TIMESTAMP (FIELD 30) CCP (FIELD 31) INTRAGROUP (FIELD 32) INTEREST RATES (FIELD 33-40) FOREIGN EXCHANGE (FIELD 41-44) COMMODITIES (FIELD 45-46) ENERGY DELIVERY POINT OR ZONE (FIELD 47) INTERCONNECTION POINT (FIELD 48) LOAD TYPE (FIELD 49) DELIVERY START DATE AND TIME (FIELD 50) DELIVERY STOP DATE AND TIME (FIELD 51) CONTRACT CAPACITY AND QUANTITY UNIT (FIELD 52-53) PRICE/TIME INTERVAL QUANTITIES (FIELD 54) OPTIONS OPTION TYPE (FIELD 55) OPTION STYLE (EXERCISE) (FIELD 56) STRIKE PRICE (CAP/FLOOR RATE) (FIELD 57) MODIFICATIONS TO THE REPORT REPORTS EMIR DATA REPORT... 35

5 UPDATES TO EXISTING REPORTS APPENDIX A NOTIONAL AMOUNT EXAMPLES EQUITY AND INDEX DERIVATIVES EXAMPLES FIXED INCOME DERIVATIVES EXAMPLES COMMODITY DERIVATIVES APPENDIX B EMIR DATA REPORT... 40

6 BACKGROUND AND PURPOSE One of the main obligations under the European Market Infrastructure Regulation (the Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories) (EMIR) is the reporting of all derivatives trades to trade repositories 1. According to EMIR, counterparties and CCPs (clearing houses) shall ensure that all details of any derivative contract they have concluded are reported to a trade repository. The details shall be reported no later than the working day following the conclusion of the contract. Modifications and cancellations of the contract shall also be reported. As of 12 February 2014, all derivative contracts, in all asset classes, must be reported to a trade repository in accordance with above. The reporting obligation covers both exchange traded derivatives (ETD) as well as OTC derivatives. According to EMIR, both counterparties to a derivative contract are responsible for their own reporting (the reporting can be outsourced to a third party). From the point of view of Nasdaq Clearing, this means that Nasdaq Clearing will submit a report for a derivative contract that has been cleared by the clearing house and the counterparty to that contract (typically a clearing member) is expected to submit a matching report. Certain parts of the report Common Data - must contain the exact same data, in the same format, so that the trade repository can match the two sides. The purpose of this handbook is to describe how Nasdaq Clearing will populate the various parts of the trade report, which formats will be used and where counterparties can find the equivalent data in order to populate their side of the report, so that it can be matched by the trade repository. The contents and formats of the data fields described in this handbook are based on EMIR Technical Standards, Q&As publicized by ESMA as well as agreements on industry standards reached among the European clearing houses within the EACH (European Association of Clearing Houses) TR working group. It is possible that updates will occur to this handbook, as a result of new guidance from ESMA in upcoming Q&A(s) 2. AUDIENCE The intended audience of this document is: Project managers Technical project managers Developers 1 EMIR, Article 9 2 ESMA Q&As can be found on the following website: Regulation-EMIR

7 SUMMARY OF CHANGES + VERSION (CHANGES IMPLEMENTED NOVEMBER, 2014) IDP customers are reported as direct counterparties to the Clearing House The underlying field is left blank for commodities (6.1.4) Price is reported as the fixed rate for OTC rates (6.2.5) Transaction reference number is reported as NA for OTC rates instruments (6.2.2) Introducing reporting adaptations for Coal (6.7) Counterparty sector will be reported as X as the CCP is not included in the corporate sector taxonomy but the field is mandatory (5.1.5) Clarified that Field 7 (Financial or non-financial nature of the counterparty) is not applicable for CCPs (5.1.6) Effective is now reported for all trades (6.2.13) Risk mitigation / Reporting (fields 26 and 27) are now reported (6.3) Intragroup is now reported for OTC trades (6.4.5) Clearing obligation (field 28) is now reported (6.4.1) + VERSION (CHANGES IMPLEMENTED JUNE, 2014) Introducing mark-to-market value reporting for all contracts Introducing position reporting of all trades except non-standard OTC contracts Trades are only reported in their end-of-day state New reporting flow for instruments with position reporting Two-digit expiration year indicator (YY) added to the Position UTI definition Underlying will be identified as NA for commodities Notional amount for commodities will be calculated as a monetary value Removed reference to venue Identifier XOFF for commodities products as all ETD trade reports are considered to be on-exchange since April 7 th 2014 Removed description of backloading, which took place in February 2014 Version : o Netted OTC trades are reported as Compressed (Z) instead of Other/Netted (O) + VERSION Removed the following products from the handbook as they are not subject to trade reporting requirements (0) + (6.8.6) + (Appendix A Notional amount) o Certified Emission Reductions o Electricity Certificates o European Union Allowances o European Union Aviation Allowances Clarification on how to report price notation (6.2.6) + VERSION 1.1, Clarification on how to report updates to trades entered prior to February 12 th 2014 (4.3.2)

8 Clarification on how to report notional amount for different asset classes (6.2.7) Clarification that effective date and termination date (Common Data fields 20 and 22) are only applicable to OTC rates trades ( ) Clarification that netting events will currently not be reported (4.4.4) Corrected the reporting format for Common data fields 52, 53 and 54 New report Position non-propagated has been added (7.1.2) Updated definition for the Transaction Reference Number (Common Data field 9) (6.2.2) + VERSION 1.0, Initial version published

9 1. READING INSTRUCTIONS The first sections of this handbook contain descriptions of the logic behind some of the more complex data fields in the trade report. This includes descriptions of: Who should report the reporting obligation The role of Nasdaq Clearing and the various entities within Nasdaq and their venue identifiers UTI (Unique Trade Identifier) Life cycle events The second part of the handbook contains details of the data fields in the Counterparty Data section and Common Data section of the trade report. Each field is listed and the contents is described. The final parts of the handbook describe some areas where discussions are still ongoing regarding how to handle the reporting. This includes position reporting and backloading. In addition, there is a description of the reports available from Nasdaq Clearing, in order to assist counterparties in retrieving the necessary data for reporting. Appendix A contains examples of how to determine Notional Amounts. Appendix B contains a detailed description of the special EMIR Data Report provided by Nasdaq Clearing.

10 2. REPORTING OBLIGATION EMIR states that counterparties and CCPs shall report derivatives contracts to a Trade Repository 3. ESMA has issued Q&As to further clarify which entities are obliged to submit trade reports in different scenarios. Such scenarios have been further discussed within the industry and certain assumptions have been made regarding the reporting obligation. The descriptions below show the interpretation of NASDAQ OMX Clearing and how the CCP views its counterparties and their reporting obligation. This may change following further clarifications by ESMA. When using the term counterparty or member below, this may refer to a Clearing Member, Direct Pledge Customer (DP), Indirect Pledge Customer (IDP) or Clearing Client (CC). 2.1 REPORTING OF EXCHANGE TRADED DERIVATIVES (ETD) When orders are matched on a Nasdaq exchange venue, the orders are immediately sent to Nasdaq Clearing and novated by the CCP. This means that the original trade, between A and B in Figure 1 below, should not be reported. A Figure 1 Matching B Instead, the trades and positions that result from the clearing should be reported, as in Figure 2 below. Nasdaq Clearing generally views the clearing members as its counterparties. Figure 2 below illustrates a scenario where the CCP has cleared a trade. The clearing member CM-A reports the trade against the CCP (the CCP reports the other side of the trade). CM-A also reports the trade against its client A (and client A is responsible for reporting the other side of this trade, provided the client falls under the reporting obligation). Nasdaq Clearing will generate Unique Trade Identifiers on the trades with the clearing members. Please note that Nasdaq Clearing will report ETD trades only in their end-of-day state (please see chapter 4 for more info). Figure 2 - All counterparties have a reporting obligation, but reporting can be delegated or outsourced to a third party 3 EMIR, Article

11 2.2 REPORTING OF OTC CLEARED DERIVATIVES Where a trade has been concluded OTC, the original trade between A and B should be reported, by both counterparties (Figure 3 below). Nasdaq Clearing will not report the original trade in this scenario. Reporting of original trade A B Figure 3 If the trade is cleared by Nasdaq Clearing, the original trade is replaced by the novation. It is therefore reported as terminated with a cancel message (Figure 4 below). Nasdaq Clearing will not report the modification of the original trade. Modification of the original trade A Figure 4 Cleared B Figure 5 illustrates a scenario where counterparty A uses a clearing member CM-A to clear the trade. In this scenario, CM-A reports the trade with the CCP, as well as the trade with counterparty A (the CCP and counterparty A reports the other sides of the respective trades). Nasdaq Clearing will assign new Unique Trade Identifiers to the trades with the clearing members. Figure

12 3. REPORTING OF NASDAQ CLEARING AS A CCP Nasdaq Clearing is responsible for reporting all derivative contracts that the CCP has cleared. In most cases, the clearing member will be the counterparty of Nasdaq Clearing and will be responsible for reporting the other side of the contract. Any counterparty can choose to delegate the actual reporting to a third party. Nasdaq Clearing is delegating its reporting to a company within the Nasdaq Group, Nasdaq Broker Services. Nasdaq Broker Services also offers this service to the counterparties of Nasdaq Clearing. Further information about this service can be obtained by sending an to [email protected]. Nasdaq Clearing reports to the trade repository of REGIS-TR. 3.1 IDENTIFIERS OF NASDAQ CCP IDENTIFIERS For reporting against Nasdaq Clearing as a CCP use the Pre-LEI issued CICI code of NASDAQ OMX Clearing Aktiebolag: A8LR1AAUCU78. This should be entered in field "Counterparty ID" (Counterparty Data Field 2). When identifying the CCP with a MIC code, please use CSTO TRADING VENUE IDENTIFIERS Contract type ETD or OTC contract 4 Deal source Venue identifier Equities and fixed income ETD Any XSTO Equities and fixed income OTC Trade report XXXX Commodities ETD Orderbook trade NORX Commodities ETD Trade report NORX Commodities ETD Fishpool trades FISH Commodities OTC Trade report XXXX When reporting ETD, the venue of execution should be identified with a MIC code. The NasdaqDerivatives Markets, including equity and fixed income derivatives, should be identified with the MIC code XSTO. Nasdaq Commodities should be identified with NORX. Exchange MIC codes will also be retrievable via the OMnet API using query DQ7, field mic_code_s. 4 For specification on what products Nasdaq Clearing determine as ETD or OTC, please see the list of products and product codes on the TR-web 12

13 13

14 4. UTIS FOR TRADES AND POSITIONS This is a guide for how to replicate Unique Trade Identifiers (UTIs) produced in Genium INET Clearing using the OMnet API and FIX protocol. 4.1 BASIC CONCEPTS TRADE UTI Trades executed during the day will be assigned UTIs by Nasdaq Clearing based on their end of day state. This means for example that trades on transitory accounts which are later allocated to a position account or trades that are given up the same day will never be assigned a UTI. For ETDs and standardized OTC traded derivatives, the trade will only be reported once and the trade will then marked as having reached its end-of-life state via an additional report with action type=58. After this any additional events on the trade will be reported on position level. Figure 6 For non-standardized OTC contracts (including interest rate swaps and TM FRAs) a reference to the original Trade UTI will be kept throughout the lifecycle of the contract and any events will be reported as modifications or cancellations of the original Trade UTI. Figure POSITION UTI Trades in ETDs and standardized OTC traded derivatives are netted into a position by the clearing house at end of day and any future events will be handled on a position level. A position UTI is kept for the whole lifecycle of the contract even if the position is netted to zero. Only the net position is reported. 14

15 4.2 CONSTRUCTION OF UTI The UTIs in Genium INET are constructed as follows: TRADE UTI characters 2. MIC code of the clearing house, 4 characters ( CSTO ) characters 4. Instrument type 4-8 characters, filled with zeros up to 8 characters at the end (e.g. Swedish Index Future = SEIU0000 ) 5. Trade number, converted to decimal representation and filled out to 20 characters with leading zeros (trade_number_i/orig_trade_number_i/trade_number_q= ) Full example of trade UTI: 000CSTO000SEIUO POSITION UTI characters 2. MIC code, 4 characters ( CSTO ) characters 4. Member exchange code, 2 characters ( SE, NC ) 5. Member prefix + zero filler up to 5 characters ( ABC00 ) 6. Account ID + x filler up to 10 characters ( HOUSExxxxx ) 7. Symbol (also called instrument ID or series name) + x filler up to 23 characters ( OMXS304Exxxxxxxxxxxxxxx ) 8. Two digit expiration year YY ( 14 ) Full example of position UTI: 000CSTO000SEABC00HOUSExxxxxOMXS303Hxxxxxxxxxxxxxxx UTI FIELD DETAILS REPORTING OF REGULAR TRADES Trade information is distributed in the OMnet API via BD6/CQ10/CQ11 and via FIX trade capture report (35=AE). Note that trades will only be reported in their end-of-day state. The instrument type information included in position 4 of the Trade UTI can be retrieved via field int_id_s in OMnet API queries DQ3/DQ22 /DQ131. Trades entered during the day will be reported to the repository as New. The trade that will be assigned a UTI is determined by the trade type and quantity left, according to the table below. For FIX either the second part of the TradeID or OrigTradeID should be used. OMnet API trade type FIX TrdSubType (829) Description State Deal Source Qty left Open/ Close Action Type if not an intraday Action Type if intraday operation 15

16 (trade_type_c operation Standard New New Standard Interm APT Not reported Not reported Standard 0 Not reported Not reported Standard Transferred Not reported Not reported Transitory Not reported Not reported Overtaking New New Overtaking 0 Not reported Not reported Overtaking Transferred Not reported Not reported Reversing New Not reported Transfer (Transitory) Not reported Not reported Transfer (Position) Transfer (Partial Position) Close New Not reported Close New Not reported Transfer (Position) New New Transfer (APT) Interm APT New Not reported Exercise New New Assign New New Closing New New Issue Not in use New_contract New New New_contract 0 Not reported Not reported New_contract Transferred Not reported Not reported 16

17 OMnet API trade type (trade_type_c FIX TrdSubType (829) Description State Deal Source Qty left Open/ Close Action Type if not an intraday operation Action Type if intraday operation Offsetting New Not reported Superseding New New Superseding 0 Not reported Not reported Superseding Transferred Not reported Not reported Give_up New Not reported Give_up (Partial) New Not reported Take_up New New Take_up 0 Not reported Not reported Take_up Transferred Not reported Not reported REPORTING OF UPDATES TO REGULAR BACKLOADED TRADES Updates to trades where the original clearing date is prior to February 12 th 2014 should always be reported with Action type (field 58) set to New and Counterparty side (field 13) set according to OMnet API BD6/CQ10/CQ11 bought_or_sold_c or FIX TradeCaptureReport, Side (54). The original clearing date can be found in OMnet API BD6/CQ10/CQ11 field orig_clearing_date_s or FIX field OrigClearingBusinessDate (21020) REPORTING OF OTC RATES TRADES Only trades that have been accepted for clearing by the clearing house will be reported to the TR. The reporting of these trades should be done according to the table below. OTC rates trade reports are retrieved via OMnet API messages CB3/CQ80/CQ81 (note that these messages will be replaced in a future release by KB1/KQ1/KQ2). OMnet API OTC trade report state (trade_report_state_c) Trade report state description OMnet API OTC trade report sub state (trade_report_sub_s tate_c) OTC trade report sub state description TR report field 58 (field 59) 17

18 OMnet API OTC trade report state (trade_report_state_c) Trade report state description OMnet API OTC trade report sub state (trade_report_sub_s tate_c) OTC trade report sub state description TR report field 58 (field 59) 0 None Any sub state Not applicable Not reported 1 Unmatched Any sub state Not applicable Not reported 3 Matched Any sub state Not applicable Not reported 4 Cancelled Any sub state Not applicable Reported as Cancel if previously novated report exists 5 Rejected by Clearinghouse Any sub state Not applicable Not reported 6 Novated Any sub state Not applicable New 7 Terminated Any sub state Not applicable Cancel 7 Terminated 6 Netted to Zero Compressed 8 Deleted Any sub state Not applicable Cancel REPORTING OF POSITIONS The instrument name can be found in field ins_id_s in any of the OMnet API queries DQ2/DQ9/DQ124/DQ125. The position is retrieved via OMnet API query CQ3. Only the net position should be reported. Net Long Report Buy trade with quantity nbr_held_q-nbr_written_q Net Short Report Sell trade with quantity nbr_written_q-nbr_held_q Net zero Report Buy trade with quantity LIFECYCLE EVENTS New trades in ETDs and standardized OTC contracts will only be reported in their end-of-day state which includes any lifecycle events such as transfers, give-ups or amendments. Subsequent changes (T+1 and later) are considered to be on position level and will be reported as new trades that update the previous position. All lifecycle events on non-standardized OTC instruments (including interest rate swaps and TM FRAs) are reported as modifications of the existing trade. The remainder of this chapter describes the different lifecycle events and how they will be reported by Nasdaq Clearing. 18

19 4.4.1 ACCOUNT TRANSFER TRADE TRANSFER A trade transfer is a transfer of a whole or part of a trade from one clearing account to another. For ETDs and standardized OTC, a transfer of a trade will not be reported if it occurs on the same day that the trade was created, since trades are only reported in their end-of-day state. For trade transfers that occur on T+1 or later, this will be reported as a new trade which modifies the existing position. Trade transfers for non-standardized OTC instruments are always reported as a cancellation of the original trade and a new trade on the receiving account. The behavior is summarized in the table below Derivative type T T+1 or later ETD and standardized OTC Non-standardized OTC POSITION TRANSFER Not reported (the trade is only reported in its end-of-day state) Not reported (the trade is only reported in its end-of-day state) New trade on original account New trade on receiving account Cancel of existing trade and New trade on receiving account A transfer of a whole or part of a position to another account will result in a new trade on the receiving account opening the position and a new trade on the original account closing the position GIVE UP A give up will be reported in the same way as a trade transfer. Please see the table above for details RECTIFY TRADE For ETDs and standardized OTC, a rectification (T+1 or later) of an existing trade will be reported as a new trade and a subsequent position update. For non-standardized OTC, the rectification will be reported as cancellation of the original trade and a new trade DEAL CANCELLATION Deal cancellations only occur on T and will not be reported NETTING Netting events will not be reported. Accounts with automatic netting may however result in a single trade being split up into two partial trades. If the trades remain on the account until end-of-day, both such trades will be reported as New trades AVERAGE PRICE TRADE An average price trade is a set of ETD trades that are combined into a single trade at an average price. Only the end of day state of such an operation will be reported, i.e. the single resulting average priced trade. 19

20 4.4.6 CASCADING A cascading event is used on the commodities market where a year or season contract is divided into quarters and quarters are divided into months. For forward contracts and contracts with immediate cascading, this will be reported as a cancellation of the original trade and new trades for each of the new periods. For futures this will be reported as one trade cancelling the original position and a new trade for each new contract. After this a cancellation of the original position and a new position for each of the new contracts will be reported EXERCISE AND ASSIGNMENT Exercise and assignment events will be reported as new trades. The trades will always close part of the existing position on the member account TERMINATION Some OTC contracts can be fully or partially terminated by the parties of the original trade. When the termination has been authorized by the CCP, the trade will be reported as cancelled EXPIRATION Normal expiration is considered to be part of the contract specification / Product Identifier and will not be reported CORPORATE ACTION / ISSUE Any update to an instrument series as part of a corporate action will be reported as a new trade that modifies or closes the existing position and one or more new trades with the issued series, depending on corporate action type. Corporate action events on equity derivatives may cause a change in the symbol name of the instrument series, for example an X added to the end of series name. Since the series name is part of the position UTI this will cause a cancellation of the original position UTI and a new position report with the new position UTI. 20

21 5. COUNTERPARTY DATA REPORTING This chapter describes how Nasdaq Clearing will populate the EMIR Counterparty Data section. As mentioned in section 2, when using the term counterparty or member, this may refer to a Clearing Member, Direct Pledge Customer (DP), Indirect Pledge Customer (IDP) or Clearing Client (CC). Please see section 2 for further details of how Nasdaq Clearing interprets the reporting rules with regard to its counterparties. 5.1 COUNTERPARTIES The counterparties in the report will always be Nasdaq Clearing and the clearing member/counterparty. However, since Nasdaq also operates as an exchange and therefore has extended information on the trade, it will also report the Broker ID when this exists COUNTERPARTY ID (FIELD 2) The field should identify the reporting counterparty. Nasdaq Clearing will fill in the LEI of the CCP in this field. See Chapter for more information ID OF THE OTHER COUNTERPARTY (FIELD 3) This field should identify the other counterparty. Nasdaq Clearing will report the LEI of the counterparty (clearing member, DP customer, IDP customer or Clearing Client) in this field NAME OF THE COUNTERPARTY (FIELD 4) Nasdaq Clearing will report the full name of the CCP, NASDAQ OMX Clearing Aktiebolag DOMICILE OF THE COUNTERPARTY (FIELD 5) Each counterparty should specify the address of its registered office, consisting of full address, city and country of the reporting counterparty CORPORATE SECTOR OF THE COUNTERPARTY (FIELD 6) Field 6 will be reported as X as the CCP is not included in the corporate sector taxonomy FINANCIAL OR NON-FINANCIAL NATURE OF THE COUNTERPARTY (FIELD 7) Each counterparty should specify whether it is a financial F or non-financial N counterparty. Nasdaq Clearing will report this field as X BROKER ID (FIELD 8) This field will contain the LEI of the broker in case this exists. Note that in case a trade is executed by a broker on its own account and then given up to the clearing member, this field will be left blank. 21

22 5.1.8 REPORTING ENTITY ID (FIELD 9) Should be populated with the LEI of the reporting entity CLEARING MEMBER ID (FIELD 10) This field will be filled with the LEI of the clearing member, same as field BENEFICIARY ID (FIELD 11) Nasdaq Clearing will report beneficiary ID as the LEI of the CCP TRADING CAPACITY (FIELD 12) Nasdaq Clearing will always report P as European CCPs act as principal COUNTERPARTY SIDE (FIELD 13) Nasdaq Clearing will report EMIR Counterparty Data field 13 from the perspective of the CCP. B on trades where the CCP is buyer and on positions where the CCP is long, S on trades where the CCP is seller and on positions where the CCP is short. For standard ETD and OTC trades, this information is available for the member via OMnet API BD6/CQ10/CQ11, field bought_or_sold_c, or via FIX TradeCaptureReport, Side (54). For OTC rates instruments, the payer of the fixed leg (leg 1) is considered to be the buyer. This information can be found via OMnet API CB3/KB1/KQ1, field bought_or_sold_c CONTRACT WITH NON-EEA COUNTERPARTY (FIELD 14) Nasdaq Clearing will report this field based on the domicile of the counterparty. When the counterparty is domiciled in EEA Nasdaq Clearing will report N. Where the counterparty is domiciled outside EEA, Nasdaq Clearing will report Y DIRECTLY LINKED TO COMMERCIAL ACTIVITY OR TREASURY FINANCING (FIELD 15) This field will always be reported as blank since this is not applicable to CCPs CLEARING THRESHOLD (FIELD 16) This field will always be reported as blank since this is not applicable to CCPs. 5.2 MARK TO MARKET (FIELDS 17-21) Most contract types are reported on position level, with the exception of non-standard OTC contracts which are reported with a separate mark to market value for each trade MARK TO MARKET VALUE OF CONTRACT (FIELD 17) For ETDs and standardized OTCs, this will be reported as either the total mark to market value per position (daily cash settled futures), or as the market value of the position (forwards and options). 22

23 For non-standard OTC contracts this will be reported as the market value per trade. The mark to market values will be included in the EMIR Trade report as well as in daily clearing reports. Below is a list of where the information can be found. Product Mark to market value Corresponding clearing report Report Field Daily cash settled futures Daily mark to market Future Mark To Market MtM (sum of all mark to market values for the date, position account and instrument series) EMIR Trades CPD17 Market Value Forwards and options (ETD and standardized OTC) Market value Positions Non-Propagated / Positions (depending on account configuration) EMIR Trades Market Value CPD17 Market Value Non-standardized OTC Market value Trade Detail OTC MV Current Date EMIR Trades CPD17 Market Value The values are also available via OMnet API. Please contact [email protected] or refer to the OMnet API Message Reference for further information CURRENCY OF MARK TO MARKET VALUE OF THE CONTRACT (FIELD 18) For futures, interest rate swaps and TM FRA this will be equal to the instrument currency. For forwards and options, this is normally the instrument currency but it can be overridden in case the member has selected a different risk currency, in which case the valuation is done in this currency instead VALUATION DATE (FIELD 19) This will be reported as the date of the valuation, e.g. the same as the trading date (ISO 8601 date format) VALUATION TIME (FIELD 20) This will be set to 23:59:00 (UTC time format) for mark to market and collateral valuations updates VALUATION TYPE (FIELD 21) Will be set to M (=Mark to Market). 5.3 COLLATERAL (FIELDS 22-26) Nasdaq Clearing includes a reference to the collateral portfolio in each trade/positions report. In addition, a separate report is generated daily with the valuation of each collateral portfolio COLLATERALISATION (FIELD 22) Will always be "OC" = one way collateralised. 23

24 5.3.2 COLLATERAL PORTFOLIO (FIELD 23) Will always be "Y" as collateralisation is performed on a portfolio basis at CCPs COLLATERAL PORTFOLIO CODE (FIELD 24) This value will be equal to the custody account reference for the applicable collateral portfolio, for example VALUE OF THE COLLATERAL (25) This value will be reported as the sum of all collateral values per instrument after haircut and concentration limit, converted to the base currency of the margin requirement account. The value is available in the EMIR Trades report CURRENCY OF THE COLLATERAL VALUE (26) This value will be the base currency of the margin requirement account corresponding with the collateral portfolio. 24

25 6. COMMON DATA REPORTING This chapter describes how Nasdaq Clearing will report the EMIR Common Data section and how to retrieve this information via OMnet API and other interfaces. 6.1 PRODUCT DETAILS For ETDs and standard OTC contracts ISIN + CFI will be used (taxonomy I) and fornon-standard OTC contracts Interim taxonomy (taxonomy E) EMIR COMMON DATA FIELDS 1-3 Product type Standardized ETD and OTC contracts Non-standard OTC contracts ISIN CODES Taxonomy used (EMIR Common Data field 1) Product ID 1 (EMIR Common Data field 2) I ISIN code CFI Product ID 2 (EMIR Common Data field 3) E IR IRS= SW OIS= SW Basis swap= SW TM FRA= FR ISIN codes are assigned to all instruments except OTC rates and can be found in Reports (Daily Series report or EMIR trade details report in Clearing Workstation 1 or 2) CFI OMnet API DQ2/DQ9/DQ124/DQ125 A list of CFIs for all instrument types that need to be reported under EMIR is available on the following website UNDERLYING (FIELD 4) Nasdaq Clearing will report the ISIN code of the underlying instrument in EMIR Common Data field 4, when such exists. For instruments where the underlying does not have an ISIN code, such as Commodities, the field will be left blank. Underlying ISIN can be found in the OMnet API via queries DQ4/DQ19/DQ120/DQ NOTIONAL CURRENCY (FIELD 5-6) Nasdaq Clearing will report the currency of the contract specification as Notional currency 1 (field 5). Notional currency 2 (field 6) will be left blank for all contracts. The contract currency is found in field base_cur_s in OMnet API instrument class queries DQ10/DQ20/DQ122/DQ123. The underlying currency is found in field in base_cur_s in OMnet API underlying queries DQ4/DQ19/DQ120/DQ

26 6.1.6 DELIVERABLE CURRENCY (FIELD 7) The deliverable (or settlement) currency can be found in field settl_cur_id_s in OMnet API instrument class queries DQ20/DQ TRANSACTION DETAILS TRADE ID (FIELD 8) The Unique Trade Identifier (UTI). See Chapter TRANSACTION REFERENCE NUMBER (FIELD 9) For ETD and standardized OTC contracts this field is populated with the Genium INET Match ID. The information is converted from binary to printable format using base 64 encoding. For OTC rates, this will be reported as NA VENUE OF EXECUTION (FIELD 10) Please see Chapter for a description of this field COMPRESSION (FIELD 11) Compression is used to indicate contracts resulting from a compression exercise only, not as a result of netting or any other type of aggregation. Nasdaq Clearing currently does not have any contract that is subject to compression so this field will always be reported as N PRICE/RATE (FIELD 12) The trade price or rate is found in the OMnet API BD6 field deal_price_c, in field LastPx(31) in FIX TradeCaptureReport (35=AE). For OTC rates instruments this will be the fixed rate (member_pay/counterparty_pay fixed_interest_rate_i). For basis swaps this value will be reported as zero (0) PRICE NOTATION (FIELD 13) Price notation is reported according to the traded price unit. Nasdaq Clearing will report the ISO 4217 currency code for products where price is expressed in currency and 100 where the price is expressed as a percentage. The traded price unit can be retrieved via OMnet API using the field price_unit_premium_c in DQ10/DQ20/DQ122/DQ NOTIONAL AMOUNT (FIELD 14) Nasdaq Clearing will report the notional amount in line with ESMA Q&A Question 9: notional can also be defined as the value of a derivative s underlying assets at the applicable price at the transaction s start. For financial and commodities forwards and futures, this is quantity (field 16) price multiplier (field 15) price / rate (field 12). 26

27 For financial and commodities options, this is quantity (field 16) price multiplier (field 15) strike price (field 57). For standardized fixed income derivatives, the notional amount will be reported as the nominal value of the underlying e.g SEK (OMnet API DQ120/DQ121NS_FIXED_INCOMEnominal_value_q). For OTC rates such as interest rate swaps and TM FRA contracts, the notional amount is included directly in the trade report (IR_SWAP/FRAnotional_amount_q). See Appendix A Notional amount for examples on how to calculate the notional value PRICE MULTIPLIER (FIELD 15) The price multiplier is found in OMnet API instrument series queries, DQ2/DQ9/DQ124/DQ125 field price_quot_factor_i QUANTITY (FIELD 16) The quantity should be reported as the number of contracts in the trade, for trade reporting, or as the net long or short position for position reporting. For OTC rates trades, quantity will always be reported as 1. Trade reporting Position reporting Quantity (ETD and standardized Number of contracts in the trade Long or short position OTC) OTC rates 1 Not applicable The quantity is available via OMnet API, FIX or clearing reports for trades and via OMnet API or reports for positions. See the table below for details: Source Quantity (trade) Quantity (position) OMnet API BD6/CQ10/CQ11, field trade_quantity_i for trades with Action Type set to New or Cancel. BD39/CQ39, field rem_quantity_i for trades with Action Type set to Modify. FIX Trade Capture Report (35=AE), field LastQty (32) Clearing reports Trades UPFRONT (FIELD 17) Trade exception Interest rate trades CQ3, fields nbr_held_i, nbr_written_i reported as: Net long: nbr_held_inbr_written_i Net short: nbr_written_inbr_held_i Not available Position non-propagated For OTC rates, the upfront amount will be reported in the field. For all other products this field will be blank. This value will always be reported as a positive amount. The buy/sell indicator should be used to determine direction. In OMnet API this value is found in CB3: IR_SWAP_TRADE_REPORTIR_SWAPUPFRONTamount_q DELIVERY TYPE (FIELD 18) Delivery type indicates whether the contract is settled physically or in cash. This information will be available via the OMnet API instrument type queries DQ3/DQ22/DQ131, field settlement_type_c 27

28 EXECUTION TIMESTAMP (FIELD 19) The execution timestamp is reported as the time when the CCP enters into the trade. For lifecycle events this will be the time of the lifecycle event as defined by the CCP rather than the original time of execution. All timestamps are in CET and will be reported in UTC format YYYY-MM-DDTHH:MM:SS±HH:MM. See table below for details on how to retrieve the information: Source ETD OTC Cleared OMnet API BD6/CQ10/CQ11, fields created_date_s + created_time_s FIX SendingTime (52)/ OrigSendingTime (122) of TradeCaptureReport Clearing reports Trades Trade exception Interest rate trades EFFECTIVE DATE (FIELD 20) The effective date indicates the date when obligations under the contract come into effect. CB3/KB1fields timestamp_date_s + timestamp_time_s SendingTime (52)/ OrigSendingTime (122) of TradeCaptureReport Trades Trade exception Interest rate trades Trade details OTC Instrument Interest Rate Swap Overnight Index Swap Basis Swap TM FRA All other instruments, including ETD and standard OTC Effective date in OMnet API CB3IR_SWAP_TRADE_REPORTIR_SWAPsettlement_date_s CB3 IR_SWAP_TRADE_REPORTIR_SWAPsettlement_date_s CB3 IR_SWAP_TRADE_REPORTIR_SWAPsettlement_date_s CB3FRA_TRADE_REPORTFRAsettlement_date_s This will be the same as the clearing date, BD6/CQ10/CQ11 field orig_clearing_date_s MATURITY DATE (FIELD 21) The maturity date will be reported as the original expiry date of the contract. Early termination will not be reported in this field, however a change to the effective expiration of the contract, for example due to incorrect initial setup, will be reported. The table below shows how to retrieve the expiration date: Instrument ETD and standard OTC Interest Rate Swap Overnight Index Swap Basis Swap TM FRA Expiration date in OMnet API DQ2/DQ9/DQ124/DQ125 field effective_exp_date_s. If blank, use seriesexpiration_date_n in the same query CB3IR_SWAP_TRADE_REPORTIR_SWAPtermination_date_s CB3IR_SWAP_TRADE_REPORTIR_SWAPtermination_date_s CB3IR_SWAP_TRADE_REPORTIR_SWAPtermination_date_s CB3 FRA_TRADE_REPORTFRAtermination_date_s 28

29 TERMINATION DATE (FIELD 22) This field is only reported in case of early termination of OTC rates contracts. Will be reported with the OMnet API termination_date_s field but only when CB3 field trade_report_state_s=7 (terminated). For ETD this field will always be blank DATE OF SETTLEMENT (FIELD 23) ETD and standard OTC contracts will be reported as field effective_exp_date_s where such exists, or otherwise as expiration_date_n in OMnet API instrument series queries DQ2/DQ9/DQ124/DQ125. For Non-standard OTC contracts, this will be the same as maturity date (see ). Where an American option is exercised prior to expiry, this will be reported as a position Lifecycle Event MASTER AGREEMENT TYPE (FIELD 24) To be left blank as this is not applicable to cleared trades MASTER AGREEMENT VERSION (FIELD 25) To be left blank as this is not applicable to cleared trades. 6.3 RISK MITIGATION / REPORTING (FIELD 26-27) EMIR Technical Standards (Commission Delegated Regulation (EU) No 149/2013) states that confirmation means the documentation of the agreement of the counterparties to all the terms of an over the counter (OTC) derivative contract. Therefore, the field 26 will be reported as T00:00:00Z and field 27 will be left blank for ETDs and XOFF CONFIRMATION TIMESTAMP (FIELD 26) For ETD and XOFF this field will be reported as T00:00:00Z in order to comply EMIR validation table ESMA/2014/1301. For OTC contracts this will be the same as the execution timestamp (field 19). Please see for further details CONFIRMATION MEANS (FIELD 27) For ETD and XOFF this field will be left blank. For OTC this will be reported as E. 6.4 CLEARING CLEARING OBLIGATION (FIELD 28) The field will reported as N for all products CLEARING TIMESTAMP (FIELD 29) Will be Y in all cases for cleared trades. 29

30 6.4.3 CLEARING TIMESTAMP (FIELD 30) This field will be the same as the execution timestamp for all Nasdaq trades. See Chapter for details CCP (FIELD 31) Nasdaq Clearing will report the LEI of the CCP. See Chapter INTRAGROUP (FIELD 32) This is not applicable to cleared trades, as per definition in Article 3 of EMIR (Regulation (EU) 648/2012). However this field is mandatory for OTC trades according to EMIR validation table ESMA/2014/1301 and it will therefore be reported as N. For ETD and XOFF this field will be left blank. 6.5 INTEREST RATES (FIELD 33-40) The fields in this section are only applicable to OTC rates instruments, e.g. interest rate swaps, overnight index swaps, basis swaps and TM FRA contracts. Nasdaq Clearing will always report the fixed leg as Leg 1 in a swap or FRA contract. In case of float vs. float the shorter dated is considered to be Leg1. The payer of Leg 1 will always be reported as the buyer. The table below describes how the data is retrieved and how the instruments should be reported. Field no Name Interest rate swap / Overnight index swap 33 Fixed rate leg 1 34 Fixed rate leg 2 35 Fixed rate day count member_pay/counterparty_ pay fixed_interest_rate_i (4 implicit decimals) counterparty_pay/member_ pay spread_i (4 implicit decimals) member_pay/counterparty_ pay day_count_conv_c Basis swaps member_pay/counterparty_ pay spread_i (4 implicit decimals) counterparty_pay/member_ pay spread_i (4 implicit decimals) Blank TM FRA FRAfixed_interest_rate_i (4 implicit decimals) Blank FRAday_count_conv_c 36 Fixed leg payment frequency 37 Floating rate payment frequency 38 Floating rate reset frequency 39 Floating rate of leg 1 member_pay/counterparty_ pay rollover_period_c, expressed as 10D, 3M etc. counterparty_pay/member_ pay rollover_period_c, expressed as 10D, 3M etc. Same as above counterparty_pay/member_ pay rollover_period_c Blank Blank member_pay/counterparty_ pay rollover_period_c, For the shorter dated rate. expressed as 10D, 3M etc. Same as above counterparty_pay/member_ pay rollover_period_c member_pay/counterparty_ pay float_rate_index (series struct) The name of the float rate index can be found in field ins_id_s in instrument series The period between FRABASE_TRADE_REPORTs ettlement_date_s and FRAtermination_date_s, expressed as 10D, 3M etc. Same as above Same as above Blank 30

31 Field no Name Interest rate swap / Overnight index swap 40 Floating rate of leg 2 counterparty_pay /member_pay float_rate_index (series struct) The name of the float rate index can be found in field ins_id_s in instrument series queries (DQ9/DQ125) Basis swaps queries (DQ9/DQ125) counterparty_pay/member_ pay float_rate_index (series struct) The name of the float rate index can be found in field ins_id_s in instrument series queries (DQ9/DQ125) TM FRA FRA float_rate_index (series struct) The name of the float rate index can be found in field ins_id_s in instrument series queries (DQ9/DQ125) 6.6 FOREIGN EXCHANGE (FIELD 41-44) These fields only apply to foreign exchange products which are currently not offered by Nasdaq Clearing. These fields should therefore be left blank for the time being. 31

32 6.7 COMMODITIES (FIELD 45-46) The EMIR Common Data fields will be reported as follows: Product Commodity base (field 45) Commodity details (field 46) Power EN EL UK Natural Gas EN NG Coal EN CO Freight FR Blank Seafood AG SO Iron ore ME NP 6.8 ENERGY The EMIR Common Data fields will be reported for power contracts listed on Nasdaq Commodities DELIVERY POINT OR ZONE (FIELD 47) Energy Identification Codes (EIC) are not applicable for Nasdaq Commodities derivatives contracts. This field will therefore be left blank INTERCONNECTION POINT (FIELD 48) This field will be left blank LOAD TYPE (FIELD 49) This field is used to report the load type, (e.g. base load (BL), peak load (PL)). This information is not available directly in the OMnet API but can be derived in two ways: BASED ON INSTRUMENT SERIES NAME The instrument series name is found in OMnet API DQ2/DQ9/DQ124/DQ125 field ins_id s or in FIX Trade Capture Report field Symbol (55). For most base load contracts, the text BL will be included in the series name For all peak load contracts, the text PL is included in the series name BASED ON PRICE MULTIPLIER AND DELIVERY PERIOD Whether the contract should be reported as base load or peak load can be derived from the delivery hours. A base load contract is delivered 00:00-24:00 Monday to Sunday and a peak load contract is delivered 08:00-20:00 Monday to Friday. Note that the delivery hours may be adjusted for leap years and daylight savings time. Example: EDEPLMOCT-14 Price multiplier (Common Data field 15): 276 Delivery start (Common Data field 50): Delivery stop (Common Data field 51): Delivery days (if base load):

33 Delivery hours (if base load): (due to daylight savings adjustment)=745 Delivery days (if peak load): 23 Delivery hours (if peak load): 23 12=276 Result: EDEPLMOCT-14 is reported as a peak load contract since the price multiplier corresponds with the delivery hours for the peak load contract DELIVERY START DATE AND TIME (FIELD 50) The delivery start date to be reported in field 50 can be found in the OMnet API series query DQ2/DQ9/DQ124/DQ125 field date_delivery_start_s. For base load contracts, the delivery start time will be reported as 00:00 (CET), and for peak load contracts, the delivery start time will be reported as 08:00 CET. For option contracts, this field will be reported as the delivery start date and time of the underlying contract, which can be derived from the UPPER_LEVEL_SERIES struct in the OMnet API series query DQ2/DQ9/DQ124/DQ DELIVERY STOP DATE AND TIME (FIELD 51) The delivery stop date can be found in the OMnet API series query DQ2/DQ9/DQ124/DQ125 field date_delivery_stop_s. For base load contracts, the delivery stop time will be reported as 23:59:59 (CET), and for peak load contracts, the delivery stop time will be reported as 20:00 CET. For option contracts, this field will be reported as the delivery stop date and time of the underlying contract, which can be derived from the UPPER_LEVEL_SERIES struct in the OMnet API series query DQ2/DQ9/DQ124/DQ CONTRACT CAPACITY AND QUANTITY UNIT (FIELD 52-53) These fields will be reported according to the table below. The information can be mapped to OMnet API field ins_id_s or FIX Symbol (55) via Product code. Asterisk (*) indicates wildcard. Product Product code Contract capacity Quantity unit Power ENO*, EDE*, ENL*, MWh 1 SY*, EUK*, UK Natural Gas NGUK* Therms PRICE/TIME INTERVAL QUANTITIES (FIELD 54) This field will be reported as Price/Quantity unit (Common Data field 12/Common data field 53). 6.9 OPTIONS OPTION TYPE (FIELD 55) Option type (Put or Call) can be retrieved from OMnet API via the instrument group query DQ8, field option_type_c. 33

34 6.9.2 OPTION STYLE (EXERCISE) (FIELD 56) Nasdaq Clearing supports American ( A ), Asian ( S ) and European ( E ) option contracts. The option type can be retrieved from OMnet API via the instrument group query DQ8, field option_style_c STRIKE PRICE (CAP/FLOOR RATE) (FIELD 57) The strike price is found in the SERIES struct in OMnet API trade capture report BD6/CQ10/CQ11 or via instrument series queries DQ2/DQ9/DQ124/DQ125, field strike_price_i MODIFICATIONS TO THE REPORT Details on how the EMIR Common Data fields 58 and 59 will be reported are described in Chapter

35 7. REPORTS EMIR DATA REPORT A new EMIR data report in comma-separated format (CSV) will be created daily per member and made available in the Clearing Workstation and via OMnet API. The report will contain all required EMIR reporting fields that are available via the Genium INET Clearing system as well as additional CCP specific fields for identifying the trades. Both ETD and OTC will be included in the report. Please note that the report will not contain the full data required for reporting purposes. The report will be produced from the perspective of the member with the CCP as counterparty UPDATES TO EXISTING REPORTS A number of clearing reports will be updated with new columns to include UTIs and Action type. Only reports in Excel and CSV format will be updated. Report Format Columns Trades XLS, CSV UTI, Action type Trade exceptions XLS, CSV UTI, Action type Interest rate trades XLS, CSV UTI, Action type Trade details OTC CSV UTI, Action type Position non-propagated XLS, CSV UTI, Action type 35

36 36

37 APPENDIX A NOTIONAL AMOUNT EXAMPLES EQUITY AND INDEX DERIVATIVES INDEX OPTIONS 20 contracts of June 2014 OMXS30 call strike 1320 traded at 32,00 index points - Quantity = 20 - Price multiplier = 100 SEK per index point - Notional = ,00 = SEK INDEX FUTURE Equity index future example: 50 contracts of June 2014 OMXS30 future traded at 1270,00 index points - Quantity = 50 - Price multiplier = 100 SEK per index point - Notional = = SEK SINGLE STOCK OPTIONS Single Stock option example: 10 contracts of June 2014 of ERIC B put option strike 80,00 traded at 6,00 SEK - Quantity: 10 contracts - Contract size = Notional = ,00 = SEK SINGLE STOCK FUTURE OR FORWARD Single stock future or forward example: 200 contracts of June 2014 ERIC B forward traded at 79,00 SEK - Quantity: 200 contracts - Contract size: Notional = = SEK 37

38 EXAMPLES FIXED INCOME DERIVATIVES R10XX - Quantity: 50 contracts - Nominal value of underlying R10X = SEK - Notional = = SEK TM FRA On a Generic STIBOR-FRA contract with notional amount of SEK 100 million is bought at percent. Fixing date for the trade is and 3-month STIBOR fixes at 1.550% on that date. - Notional amount = SEK EXAMPLES COMMODITY DERIVATIVES ELECTRICITY Electricity example: 5 lots of Year 2015 Nordic Electricity Base DS Futures traded at EUR Quantity = 5 (# contracts traded) - Price multiplier = 8,760 hours (# hours in each base Year contract) - Price / rate = EUR 35 (price per contract) - Notional = quantity price multiplier price = 1,533,000 EUR FREIGHT DRY Freight Dry example: 180 lots of Year 2015 Capesize Timecharter Futures trade at USD 18, Quantity = 180 (# contracts traded) - Price multiplier = 1 day (# days in each contract) - Price / rate = USD 18,000 (price per contract) - Notional = quantity price multiplier price = 3,240,000 USD FREIGHT TANKER Freight Tanker example: 10 lots of Year 2015 TC2 Futures trade at USD Quantity = 10 (# contracts traded) - Price multiplier = 12,000 metric tonnes (# metric tons in each Year contract) - Price / rate = USD 18 (price per contract) 38

39 - Notional = quantity price multiplier price = 2,160,000 USD SALMON Salmon example: 10 lots of Year 2015 Salmon Futures trade at NOK Quantity = 10 (# contracts traded) - Price multiplier = 12,000 kg (# kilo grams in each Year contract) - Price / rate = NOK 35 (price per contract) - Notional = quantity price multiplier price = 4,200,000 NOK 39

40 APPENDIX B EMIR DATA REPORT The report will be divided in three segments: 1. CCP specific field (CCP1-CCP16), not required by EMIR but used to identify the trade in the clearing system 2. EMIR Counterparty Data fields (CPD1-CPD26) 3. EMIR Common Data fields (CD1-CD59) Column number Heading/label 1 CCP1 Market 2 CCP2 Account 3 CCP3 Series 4 CCP4 Trade number 5 CCP5 Trade type 6 CCP6 Trade report type 7 CCP7 State 8 CCP8 Substate 9 CCP9 Date created 10 CCP10 Free text 1 11 CCP11 Free text 2 12 CCP12 Counterparty ID 13 CCP13 ID of the other counterparty 14 CCP14 Instrument type 15 CCP15 MatchID 16 CCP16 OrderID 17 CCP17 Prior UTI 18 CPD1 Reporting timestamp 19 CPD2 Counterparty ID 20 CPD3 ID of the other counterparty 21 CPD4 Name of the counterparty 22 CPD5 Domicile of the counterparty 23 CPD6 Corporate sector of the counterparty 24 CPD7 Financial or non-financial nature of the counterparty 25 CPD8 Broker ID 26 CPD9 Reporting entity ID 27 CPD10 Clearing member ID 28 CPD11 Beneficiary ID 29 CPD12 Trading capacity 30 CPD13 Counterparty side 31 CPD14 Contract with non-eea counterparty 40

41 32 CPD15 Directly linked to commercial activity or treasury financing 33 CPD16 Clearing threshold 34 CPD17 Mark to market value of contract 35 CPD18 Currency of mark to market value of the contract 36 CPD19 Valuation date 37 CPD20 Valuation time 38 CPD21 Valuation type 39 CPD22 Collateralisation 40 CPD23 Collateral portfolio 41 CPD24 Collateral portfolio code 42 CPD25 Value of the collateral 43 CPD26 Currency of the collateral value 44 CD1 Taxonomy used 45 CD2 Product ID 1 46 CD3 Product ID 2 47 CD4 Underlying 48 CD5 Notional currency 1 49 CD6 Notional currency 2 50 CD7 Deliverable currency 51 CD8 Trade ID 52 CD9 Transaction reference number 53 CD10 Venue of execution 54 CD11 Compression 55 CD12 Price/rate 56 CD13 Price notation 57 CD14 Notional amount 58 CD15 Price multiplier 59 CD16 Quantity 60 CD17 Up-front payment 61 CD18 Delivery type 62 CD19 Execution timestamp 63 CD20 Effective date 64 CD21 Maturity date 65 CD22 Termination date 66 CD23 Date of Settlement 67 CD24 Master Agreement type 68 CD25 Master Agreement version 69 CD26 Confirmation timestamp 70 CD27 Confirmation means 71 CD28 Clearing obligation 72 CD29 Cleared 41

42 73 CD30 Clearing timestamp 74 CD31 CCP 75 CD32 Intragroup 76 CD33 Fixed rate of leg 1 77 CD34 Fixed rate of leg 2 78 CD35 Fixed rate day count 79 CD36 Fixed leg payment frequency 80 CD37 Floating rate payment frequency 81 CD38 Floating rate reset frequency 82 CD39 Floating rate of leg 1 83 CD40 Floating rate of leg 2 84 CD41 Currency 2 85 CD42 Exchange rate 1 86 CD43 Forward exchange rate 87 CD44 Exchange rate basis 88 CD45 Commodity base 89 CD46 Commodity details 90 CD47 Delivery point or zone 91 CD48 Interconnection Point 92 CD49 Load type 93 CD50 Delivery start date and time 94 CD51 Delivery end date and time 95 CD52 Contract capacity 96 CD53 Quantity Unit 97 CD54 Price/time interval quantities 98 CD55 Option type 99 CD56 Option style (exercise) 100 CD57 Strike price (cap/floor rate) 101 CD58 Action type 102 CD59 Details of action type 42