> For the complete documentation index, see [llms.txt](https://www.mica.wtf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.mica.wtf/eu-level/q-and-a/esma-qa-70-1861941480-56-mifir-data-reporting.md). # ESMA70-1861941480-56 — Q\&A on MiFIR data reporting | | | | --------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Authority** | ESMA | | **Reference** | ESMA70-1861941480-56 | | **Legal basis** | MiFIR (data reporting) | | **Status** | In force | | **Published** | 31 March 2023 | | **Source** | [ESMA landing page](https://www.esma.europa.eu/publications-and-data/questions-answers) | | **Documents** | [Guideline PDF](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf) | ## Questions and Answers On MiFIR data reporting Please note that this document is not updated after 31 December 2023. For Q\&As issued from 1 January 2024, please search in the ESMA Q\&A IT-tool. ESMA · 201-203 rue de Bercy · CS 80910 · 75589 Paris Cedex 12 · France · Tel. +33 (0) 1 58 36 43 21 · [www.esma.europa.eu](http://www.esma.europa.eu) 2 ESMA70-1861941480-56 ## Table of Contents | Table of questions................................................................................................................. | Table of questions................................................................................................................. | | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ## Acronyms and definitions used | LEI | ISO 17 442 Legal Entity Identifier | | --- | ---------------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ## Table of questions | | | Topic of the Question | Level issue | 1/Level | Last Updated | | ------------------------------------------------------- | - | ---------------------------------------------------------------------------- | -------------- | -------------- | ------------ | | LEI of the issuer | 1 | LEI of the issuer | MiFIR RTS 23 1 | MiFIR RTS 23 1 | 20/12/2016 | | LEI of the issuer | 2 | LEI of an operator of a trading venue or a systematic analyser | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | LEI of the issuer | 3 | Issuer LEI vs Ultimate Parent LEI | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | LEI of the issuer | 4 | LEI annual maintenance | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | LEI of the issuer | 5 | LEI of the branch | MiFIR RTS 23 | MiFIR RTS 23 | 04/02/2019 | | LEI of the issuer | 6 | LEI of funds | MiFIR RTS 23 | MiFIR RTS 23 | 19/07/2021 | | LEI of the issuer | 7 | Issuer of depositary receipts | MiFIR RTS 23 | MiFIR RTS 23 | 25/03/2022 | | LEI of the issuer | 8 | \*new LEI of sovereign issuer | MiFIR RTS 23 | MiFIR RTS 23 | 31/03/2023 | | Date and time of the request of admission and admission | 1 | Date and time of the request and of the admission of instruments in the past | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | Date and time of the request of admission and admission | 2 | Unknown time of the request and of the admission | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | Date and time of the request of admission and admission | 3 | Coinciding date and time of the request and of the admission | MiFIR RTS 23 | MiFIR RTS 23 | 20/12/2016 | | Date and time of the request of admission and admission | 4 | Date of request for admission to trading | MiFIR RTS 23 | MiFIR RTS 23 | 02/02/2017 | | Date and time of the request of admission and admission | 5 | Date of admission to trading or date of first trade | MiFIR RTS 23 | MiFIR RTS 23 | 02/02/2017 | | Date and time of the request of admission and admission | 6 | Unknown date of admission | MiFIR RTS 23 | MiFIR RTS 23 | 14/12/2017 | | Instrument identification code and Underlying | 1 | ISIN, CFI and FISN | MiFIR RTS 23 | MiFIR RTS 23 | 02/02/2017 | | instrument code | 2 | Timeline to obtain ISINs | MiFIR RTS 23 | MiFIR RTS 23 | 25/03/2022 | ### Table | Column 1 | 3 | Underlying Instrument Code for future contracts on sovereign bonds | MiFIR RTS 23 | 02/02/2017 | | -------- | - | ------------------------------------------------------------------ | ------------ | ---------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). | FX Swaps reporting | 1 | Reference data and transaction reporting scenarios | MiFIR RTS 23 and 22 | 26/09/2018 | | ------------------------------------------------------------ | - | ------------------------------------------------------------------------------------------------------------------------ | ------------------- | ---------- | | Interest Rate Swaps reporting | 1 | Field 41 | MiFIR RTS 23 | 26/09/2018 | | Interest Rate Swaps reporting | 2 | Reference data and transaction reporting scenarios | MiFIR RTS 23 and 22 | 26/09/2018 | | FX Forward reporting | 1 | Reference data and transaction reporting scenarios | MiFIR RTS 23 and 22 | 07/10/2019 | | Reporting of reference rates not included in RTS 23 and 22 | 1 | Reference data and transaction reporting scenarios | MiFIR RTS 23 and 22 | 21/05/2021 | | Reporting of Emission Allowances | 1 | Reference data and order record keeping | MiFIR RTS 23 and 24 | 11/07/2022 | | Complex trades | 1 | Complex trades and reporting of instrument reference data for instruments where the execution results in a complex trade | MiFIR RTS 23 and 22 | 04/02/2019 | | FIRDS fields 8 to 11 | 1 | Population of field 8 to field 11 | MiFIR RTS 23 | 26/09/2018 | | Reporting of Nominal value per unit and minimum traded value | 1 | Population of field 17 | MiFIR RTS 23 | 25/03/2022 | | Defined List of Instruments | 1 | Reference data reporting | MiFIR RTS 23 | 08/04/2019 | | | 1 | Price not available at the time of execution | MiFIR RTS 22 | 03/04/2017 | | | 2 | National client identifiers for natural persons | MiFIR RTS 22 | 28/09/2020 | | | 3 | Circumstances where the buyer and seller in a transaction under Art. 26 of MiFIR are the same | MiFIR RTS 22 | 07/07/2017 | ### Table | Column 1 | 4 | Population of Field 30 - Quantity | MiFIR RTS 22 | 07/07/2017 | | -------- | - | --------------------------------- | ------------ | ---------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ## 1 Introduction ## Background The final legislative texts of Directive 2014/65/EU[^1] (MiFID II) and Regulation (EU) No 600/2014[^2] (MiFIR) were approved by the European Parliament on 15 April 20[^3] and by the European Council on 13 May 20. The two texts were published in the Official Journal on 12 June 20[^3] and entered into force on the twentieth day following this publication - i.e. 2 July 20. Many of the obligations under MiFID II and MiFIR were further specified in the Commission Delegated Directive[^4] and two Commission Delegated Regulations 5 6 , as well as regulatory and implementing technical standards developed by the European Securities and Markets Authority (ESMA). MiFID II and MiFIR, together with the Commission delegated acts as well as regulatory and implementing technical standards will be applicable from 3 January 2018. ## Purpose The purpose of this document is to promote common supervisory approaches and practices in the application of MiFID II and MiFIR in relation to regulatory data reporting topics. It provides responses to questions posed by the general public, market participants and competent authorities in relation to the practical application of MiFID II and MiFIR. The content of this document is aimed at competent authorities and firms by providing clarity on the application of the MiFID II and MiFIR requirements. The content of this document is not exhaustive and it does not constitute new policy. ## Status 5 Commission Delegated Regulation of 25.4.2016 supplementing Directive 2014/65/EU of the European Parliament and of the Council as regards organisational requirements and operating conditions for investment firms and defined terms for the purposes of that Directive. The Commission Delegated Regulation was published on 25 April 201[^5] and no objection has been expressed by the European Parliament or the Council on the MiFID II Delegate Directive and Delegated Regulation within the period set in Article 89 of MiFID II. The question and answer (Q\&A) mechanism is a practical convergence tool used to promote common supervisory approaches and practices under Article 29(2) of the ESMA Regulation. Due to the nature of Q\&As, formal consultation on the draft answers is considered unnecessary. However, even if Q\&As are not formally consulted on, ESMA may check them with representatives of ESMA's Securities and Markets Stakeholder Group, the relevant Standing Committees' Consultative Working Group or, where specific expertise is needed, with other external parties. ESMA will periodically review these Q\&As on a regular basis to update them where required and to identify if, in a certain area, there is a need to convert some of the material into ESMA Guidelines and recommendations. In such cases, the procedures foreseen under Article 16 of the ESMA Regulation will be followed. ## Questions and answers This document is intended to be continually edited and updated as and when new questions are received. The date on which each section was last amended is included for ease of reference. ## 2 LEI of the issuer \[Last update: 31/03/2023] ## Question 1 \[Last update: 20/12/2016] Q\&A 1669 What action should be taken by the operator of the trading venue or the systematic internaliser in the cases where the LEI of the issuer cannot be obtained? ## Answer 1 Operators of trading venues and systematic internalisers are advised to inform the issuers pertaining to the financial instruments concerned of their obligation to obtain the LEI of the issuer of every financial instrument in order to comply with the requirements under Article 3(2) of the MiFIR RTS, Article 1 of the MAR RTS[^6] and Article 2 of the MAR ITS. Trading venues and systematic internalisers are advised that the GLEIF has introduced the concept of 'Registration Agent'. This facility will enable trading venues and systematic internalisers to assist the issuer applying for the LEI to access the network of LEI issuing organisations. For more information on the 'Registration Agent' arrangements please refer to the following link . ## Question 2 \[Last update: 20/12/2016] Q\&A 1670 When can an operator of trading venue(s) and systematic internaliser(s) populate field 5 of Table 3 of the Annex to RTS 23[^7] and related MAR RTS and ITS 12 with its own LEI? ## Answer 2 Operators of trading venues and systematic internalisers can populate field 5 of Table 3 of the Annex to RTS 23 with their own LEI only where they create or issue themselves the financial instrument to be reported under the MiFIR and MAR obligations to supply reference data. 12 See footnote 8 and 9 respectively. ## Question 3 \[Last update: 20/12/2016] Q\&A 1671 In case the Issuer LEI code is missing but the Ultimate Parent Code LEI is available, can the latter one be used at least for a to-be-specified grace period? ## Answer 3 No, it cannot. The information about the LEI of the issuer of the financial instrument is essential to determine the relevant competent authority pursuant to Article 16 of RTS 22. For this reason, it is essential that the LEI pertaining to the issuer of the financial instrument and not that of the ultimate parent of the issuer is provided. In general, issuers should be aware of a number of existing EU obligations that already require the LEI of the issuers to be provided (e.g. MAR, EMIR and Transparency Directive 14 ). Under MAR, the LEI of the issuer, in addition to being used in the context of providing reference data, is part of the mandatory information to be included in the notifications by persons discharging managerial responsibilities and by all persons closely associated with them 15 . Under EMIR, the LEI is mandatory for the identification of all legal entities involved in the derivative contract to be reported to the EU Trade Repositories, including financial and non-financial counterparties that enter into derivative contracts, the beneficiary of derivative contracts, the broking entity and the clearing member. Under the Transparency Directive Officially Appointed Mechanisms are obliged to obtain the LEI of the issuer of financial instruments admitted to trading on regulated markets. ## Question 4 \[Last update: 20/12/2016] Q\&A 1672 In the case where the issuer does not pay the annual fees for maintaining its LEI to the Local Operating Unit, what is the responsibility of operators of trading venues and systematic internalisers and what measures should be taken? ## Answer 4 While issuers of financial instruments should ensure that their LEI is renewed according to the terms of any of the accredited Local Operating Units of the Global Entity Identifier System, under Article 3(2) of RTS 23 operators of trading venues and systematic internalisers are not expected to ensure that the LEI pertaining to the issuer of the financial instrument has been renewed. ## Question 5 \[Last update: 04/02/2019] Q\&A 1501 How should operators of trading venue(s) and systematic internaliser(s) populate field 5 (issuer or operator of the trading venue identifier) of Table 3 of the Annex to RTS 23 and related MAR RTS and ITS where the issuer of the instrument has a branch(es) that have a LEI? ## Answer 5 Field 5 should be populated with the LEI of the firm's head office, even if the branch may be considered eligible for a LEI in some cases. ## Question 6 \[Last update: 19/07/2021] Q\&A 1502 * (a) In case of a financial instrument issued by an Alternative Investment Fund (AIF) or; an undertakings for collective investment in transferable securities (CIUUCITS), which LEI code should be reported in the field 5 (Issuer or operator of the trading venue identifier) of RTS 23 and related RTS and ITS under MAR Article 4? * (b) In case of a financial instrument issued by an umbrella fund that is an AIF or an UCITS, which LEI code should be reported in the field 5 (Issuer or operator of the trading venue identifier) of RTS 23 and related RTS and ITS under MAR Article 4? ## Answer 6 * (a) The LEI of the fund should be reported in field 5 of RTS 23 and related RTS and ITS under MAR Article 4. * (b) If sub-funds are part of the umbrella fund structure, then the LEI of the sub-fund should be reported in field 5 of RTS 23. ## Question 7 \[Last update: 25/03/2022] Q\&A 1503 How should operators of trading venue(s) and systematic internaliser(s) populate field 5 (issuer or operator of the trading venue identifier) of Table 3 of the Annex to RTS 23 and related MAR RTS and ITS in case of depository receipts? ## Answer 7 Field 5 should be populated with the LEI of the issuer of the financial instrument represented by the depository receipt in line with MAR Article 3 (1) (21) 19 . ## \*new Question 8 Q\&A 740 What LEI should be used to report in FIRDS the issuer of sovereign bonds issued by an EEA member state? ## Answer 8 Reporting entities should refer to the list maintained by GLEIF, available at: and report the LEI pertaining to the sovereign entities included in the below list: ### Table | Country | GLEIF Name | LEI | | ------- | ---------- | --- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). | Estonia | Eesti Vabariigi Rahandusministeerium | 254900EIG0O7C6C9R437 | | ----------- | ---------------------------------------------------------- | -------------------- | | Estonia | Eesti Pank | 6YJ6OTG0PYO45FO7Q425 | | Finland | Republic of Finland, Bonds / Suomen valtio JVK:t | 743700M6Y2OQRVSBRD14 | | France | Direction Generale du Tresor | 969500KCGF3SUYJHPV70 | | Germany | Bundesrepublik Deutschland | 529900AQBND3S6YJLY83 | | Greece | Trapeza Tis Ellados | 529900SL3K21WAN6X611 | | Greece | Hellenic Republic-Ministry of Finance | 2138003EKTMKZ5598902 | | Hungary | Government Debt Management Agency Pte. | 5299008DH62LEB10JK83 | | Iceland | Central Bank of Iceland | 549300K5GD3JPA2LLG98 | | Ireland | National Treasury Management Agency | 549300KXBEJAOJ9OVF93 | | Italy | Repubblica Italiana | 815600DE60799F5A9309 | | Latvia | Latvijas Republikas Valsts kase | 25490002QDEB2KTLNK39 | | Lithuania | Lietuvos bankas | 5299002QI7G5XEIYAO60 | | Lithuania | Ministry of Finance (State Treasury Department) | 529900F7Y171QF1RSU09 | | Luxembourg | Grand Duchy of Luxembourg | 22210065LIUFB00MNF63 | | Malta | Republic of Malta | 549300CZVZYSMSGX6X78 | | Netherlands | De Staat der Nederlanden | 254900G14ALGVKORFN62 | | Norway | Finansdepartementet | 549300L0BT3FJTN9MX24 | | Poland | Skarb Państwa Rzeczypospolitej Polskiej | 259400R9L8QEP0TPXS31 | | Portugal | República Portuguesa (Republic of Portugal) | 549300P6U1FJ3IMP7K42 | | Romania | Ministerul Finantelor Publice | 315700IASY927EDWBK92 | | Slovakia | Ministerstvo financií Slovenskej republiky | 097900BHFM0000074794 | | Slovenia | Republika Slovenija | 485100000LWQHIX4XX88 | | Spain | Secretaría General del Tesoro y Financiación Internacional | 9598007A56S18711AH60 | | Sweden | Riksgäldskontoret | ERE94C0BSULG2RM19605 | ## 3 ## Date and time of the request of admission and admission \[Last update: 14/12/2017] ## Question 1 \[Last update: 20/12/2016] Q\&A 1673 What should be populated in field 10 (Date of request for admission to trading) and field 11 (Date of admission to trading or date of first trade) in the cases where the instrument was listed far in the past, e.g. when the MIFID I rules were not yet applicable and the concept of Regulated Market had not yet been introduced? ## Answer 1 If the dates and times to be provided in fields 10 and 11 are known, those dates and times should be provided even if the request for admission and the admission occurred at a time where MiFID I did not yet apply. Otherwise, either the date of establishment of the given trading venue or systematic internaliser or the application date of MiFID I (i.e. 01 November 2007) should be used, whichever date is more recent. ## Question 2 \[Last update: 20/12/2016] Q\&A 1674 In some cases, the time of the request and of the admission is not known, e.g. when the instrument was listed far in the past or when the request was submitted by postal service. In such cases, would it be possible to populate fields 10 and 11 with a default time? ## Answer 2 When the time is not available, the default time of midnight (00:00:00) should be provided. ## Question 3 \[Last update: 20/12/2016] Q\&A 1675 Can both fields 10 and 11 be populated with the same value where the request for admission to trading and the admission to trading takes place on the same day? ## Answer 3 Yes. ## Question 4 \[Last update: 02/02/2017] Q\&A 1676 Which date and time should be populated by a trading venue in Field 10 (Date of request for admission to trading) in case it receives more than one request for admission to trading of a specific financial instrument on a given day? ## Answer 4 In case more than one request for admission to trading of a specific financial instrument is received by a trading venue on a given day, Field 10 (Date of request for admission to trading) should be populated with the date and time of the first request for admission to trading. ## Question 5 \[Last update: 02/02/2017] Q\&A 1677 Which date should be populated in Field 11 (Date of admission to trading or date of first trade) - the date and time of the admission to trading or the date and time of the first trade, order or quote? ## Answer 5 Field 11 (Date of admission to trading or date of first trade) should be populated with the date and time of the event which takes place first. ## Question 6 \[Last update: 14/12/2017] Q\&A 1678 What date should be populated in RTS 23Annex Table 3 Field 11 (Date of admission to trading or date of first trade) where the actual date is still unknown and the issuer makes the request for admission to trading (Field 8)? ## Answer 6 If Field 11 (Date of admission to trading or date of first trade) is not known at the time of submission of reference data for FIRDS it should be reported with the default value of 999912-31T00:00:00, unless the financial instrument has a maturity/termination date, in which case that date should be used. As soon as date of admission to trading or date of first trade is known the FIRDS reference data should be amended with the actual date. ## 4 Instrument identification code and Underlying instrument code \[Last update: 25/03/2022] ## Question 1 \[Last update: 25/03/2022] Q\&A 1504 What ISINs, CFI codes and FISNs can be used to identify financial instruments? ## Answer 1 For the purpose of reporting reference data under the requirements of MiFIR Article 22 & 27, ISO 6166 ISINs, ISO 10962 CFI codes and ISO 18774 FISNs issued by the relevant National Numbering Agency (NNA) should be used. For further information please refer to the following link: . ## Question 2 \[Last update: 02/02/2017] Q\&A 1679 By when do ISINs have to be obtained for financial instruments submission of reference data for which is triggered by an order, quote or trade taking place? ## Answer 2 For financial instruments for which submission of reference data is triggered by an order, quote or trade taking place, the ISINs have to be allocated in time to be included in the submission of reference data required under Article 2 of RTS 23. ## Question 3 \[Last update: 02/02/2017] Q\&A 1680 How should Field 26 (Underlying instrument code) be populated in the case of a futures contract on sovereign bonds? ## Answer 3 In case of a futures contract on sovereign bonds, field 26 (Underlying instrument code) should be populated with the ISIN of the cheapest-to-deliver bond. If this is unknown, this field should be populated with the ISIN of any of the bonds issued by the issuer. This concept also applies to transaction reports under Article 26 MIFIR for OTC derivatives where the underlying deliverable bond can be chosen from several bonds issued by the same issuer. ## 5 Maturity Date, expiry date and termination date \[Last update: 04/02/2019] ## Question 1 \[Last update: 04/02/2017] Q\&A 1681 What date should be populated in Field 15 (Maturity date) for perpetual debt financial instruments? ## Answer 1 For perpetual debt financial instruments field 15 (Maturity date) should be populated with the value 9999-12-31 (in accordance with the ISO format). ## Question 2 \[Last update: 04/02/2019] Q\&A 1682 How should Field 15 (Maturity date) of Table 3 of the Annex to RTS 23 and related MAR RTS and ITS be populated in case of trading in bonds after their originally intended maturity date? ## Answer 2 For bonds that were not paid out on the originally intended maturity date (and therefore have not expired, because, for example, they defaulted), the maturity date should be set to 999912-31 (in accordance with the ISO format, like for perpetual debt financial instruments) until they are finally paid out, in which case the maturity date should be updated with the actual date of redemption'. ## Question 3 \[Last update: 04/02/2019] Q\&A 1683 How should field 15 (maturity date) and field 24 (expiry date) of Table 3 of the Annex to RTS 23 and related MAR RTS and ITS be populated, if these dates are non-trading dates, e.g. a weekend or a bank holiday? ## Answer 3 The maturity date/expiry date defined by the issuer or the prospectus of the financial instrument should be used. No adjustment should be made to the next or previous working day for the purpose of instrument reference data reporting. ## Question 4 \[Last update: 04/02/2019] Q\&A 1684 When should an instrument be terminated in FIRDS? ## Answer 4 When field 12 (termination date) of Table 3 of the Annex to RTS 23 and related MAR RTS and ITS is initially left empty, the reporting entity is expected to fill it in when the instrument is going to be terminated. This also includes the cases when the given instrument has matured/expired, i.e. where fields 15 (maturity date) or 24 (expiry date) are applicable to the given instrument and are populated in the report. The termination date should be earlier than or equal to the maturity/expiry date in the cases where the maturity/expiry date is populated. ## Question 5 \[Last update: 29/07/2019] Q\&A 1685 What date should be populated in Field 24 (Expiry date) of RTS 23 for financial instruments without a defined expiry date \[e.g. perpetual FX Rolling Spot Futures] for which the population of Field 24 is mandatory according to the CFI validation rules? ## Answer 5 For instruments without a defined expiry date for which the population of Field 24 (Expiry date) is mandatory according to the CFI validation rules \[e.g. perpetual FX Rolling Spot Futures] Field 24 should be populated with the value 9999-12-31 (in accordance with the ISO format). In case the expiry date becomes determined during the life cycle of the financial instrument Field 24 should be updated accordingly. ## 6 Classification of Financial Instruments (CFI) and Financial Instrument Short Name (FISN) \[Last update: 02/02/2017] ## Question 1 \[Last update: 02/02/2017] Q\&A 1686 Which version of the CFI is applicable for the purposes of the Commission Delegated Regulation \[RTS 23]? ## Answer 1 For the purposes of reporting reference data under the requirements of the RTS 23[^7], the ISO 10962:2015 CFI code is applicable. ## 7 Request for admission to trading by issuer \[Last update: 02/02/2017] Question 1 \[Last update: 02/02/2017] Q\&A 1687 How should Field 8 (Request for admission to trading by issuer) be populated? ## Answer 1 Field 8 (Request for admission to trading by issuer) should be populated with 'true' if the request for admission to trading was received from the issuer or the trading venue is aware of the issuer's approval for admission of its financial instrument to trading. Otherwise it should be populated with 'false'. ## 8 Base Point Spread of the index/benchmark of a floating rate bond \[Last update: 02/02/2017] ## Question 1 \[Last update: 02/02/2017] Q\&A 1688 In case of a decimal field with insufficient granularity to accommodate the complete actual value how should the field be populated, for example in the case of a base point spread with a 0.5 base point, how should the value be reported in Field 22 (Base Point Spread of the index/benchmark of a floating rate bond)? ## Answer 1 In case of a decimal field with insufficient granularity to accommodate the complete actual value, the value has to be rounded up/down to the next integer. For the given example of base point spread with a 0.5 base point, the base point spread would be populated with a value of 1. ## 9 Field 23 - Seniority of the Bond \[Last update: 03/04/2017] ## Question 1 \[Last update: 03/04/2017] Q\&A 1689 Do the same standards apply to the character denoting seniority of a bond in field 3 and the attributes listed in field 23 (seniority of the bond) of RTS 23 of MiFIR? ## Answer 1 No, different standards apply to field 3 and field 23 of RTS 23. Field 3 is populated for all instruments with the ISO 10962:2015 CFI code while field 23 is populated according to ISO 20022 standard and only applies to debt instruments. There is no validation rule in place that compares the value in field 3 with that populated in field 23. ## 10 Business Case: Inflation Indexed bond \[Last update: ## 03/04/2017] Question 1 \[Last update: 03/04/2017] Q\&A 1690 How should transactions on 'inflation indexed bonds' be reported under RTS 22? ## Answer 1 Example of transaction report on 'inflation indexed bonds': An investment firm acquires a DBRI 0.1% 04/15/2026 (ISIN Code DE0001030567) by trading over the counter at 110.00%. The nominal value of the transaction is 1000000 EUR. The net amount for this transaction is 1111274.01 EUR. Considering that for the purpose of this example: ## The static characteristics (as defined upon the issue of the financial instrument) are: * -Maturity Date: April 15 th 2026 * -Coupon frequency: Annual * -Day Count Convention: ACT/ACT * -Day to Settle Convention: 2 business days after the trade date ## The variables (dynamic characteristics depending on the market conditions) are: * -Trade Date: July 25 th 2016 * -Settlement Date: July 27 th 2016 (as per the Day to Settle Convention) * -Last Coupon Date: April 15 th 2016 * -Next Coupon Date: April 15 th 2017 * -Accrued number of days: 103 (i.e., the number of days between the Last Coupon Date and the Settlement Date) * -Period basis: 365 (i.e., the total number of days between the Last Coupon Date and the Next Coupon Date) * -Quantity: 1000000 (i.e., the nominal or monetary value of the transaction) * -Clean price: 110.00 * -Index ratio: 1.009990 * -Accrued interest: 0.02821918 (i.e., 𝑁𝑜𝑚𝑖𝑛𝑎𝑙 𝐶𝑜𝑢𝑝𝑜𝑛 𝐴𝑛𝑛𝑢𝑎𝑙 𝐶𝑜𝑢𝑝𝑜𝑛 𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 x 𝐴𝑐𝑐𝑟𝑢𝑒𝑑 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐷𝑎𝑦𝑠 𝑃𝑒𝑟𝑖𝑜𝑑 𝑏𝑎𝑠𝑖𝑠 = 0.1 1 x 103 365 ) The net amount will be calculated as follows (pursuant to the formula provided in field 35 of RTS 22): Net amount 22 = \[(Clean price x Nominal value) + (Accrued coupons x Nominal value)] x Index ratio i.e. \[(( 110 100 x 1000000 EUR) + ( 0.02821918 100 x 1000000 EUR))] x 1.009990 =1111274.01 EUR. | N | Field name | Values | XML representation | | -- | ---------- | --------- | -------------------------------------- | | 30 | Quantity | '1000000' | ... ... 1000000 110.00 1111274.01 XOFF | ## 11 Field 14 and Field 17 - Total issued nominal amount \[Last update: 26/09/2018] ## Question 1 Q\&A 1691 In the case of Bonds or other forms of securitised debt, what should be reported in Commission Delegated Regulation (EU) 2017/585 Annex Table 3 Field 14 (Total issued nominal amount) if the total nominal amount changes? Similarly, what should be reported in Commission Delegated Regulation (EU) 2017/585 Annex Table 3 Field 17 (Nominal value per unit/minimum traded value) if nominal value per unit/minimum traded value changes? ## Answer 1 In the case of Bonds or other forms of securitised debt, a trading venue should update Field 14 (Total issued nominal amount) accordingly if the total nominal amount changes (increasing or decreasing). The same approach should be applied to Field 17 (Nominal value per unit/minimum traded value). Trading venues are not expected to report under Field 14 the total size of the issuance programme (i.e. the total nominal amount that can be issued under this programme) under which the specific instruments have been issued but only the nominal amount effectively issued for the specific ISIN being reported (and taking into account the tap issuances and buy-backs that might occur for this specific ISIN). ## 12 Field 30 - Quantity \[Last update: 07/07/2017] ## Question 1 Q\&A 1692 How shall Field 30 (Quantity) in Commission Delegated Regulation (EU) 2017/590 Annex I Table 2 be reported for a transaction where there have previously been acquisitions or disposals that are excluded from the meaning of a transaction? For example, a decrease in notional amount in a financial instrument which has previously had pre-determined contractual down payments exempted from transaction reporting under Commission Delegated Regulation (EU) 2017/590 Article 2(5)(j)? ## Answer 1 Competent authorities require an accurate and holistic view of transactions that are within the scope of reporting requirements under Article 26 of MiFIR. Therefore, Article 15(5) of Commission Delegated Regulation (EU) 2017/590 obliges an Investment Firm to ensure that a collective view of the transaction reports reported by the Investment Firm as the executing entity accurately reflects all changes in its position and in the position of its clients that arise from reportable transactions. It should be noted that the reporting requirements are not intended to capture the Investment Firm's or the Investment Firm's client's actual position. What is of interest to competent authorities is the change of position resulting from reportable transactions. Therefore only acquisitions or disposals that are reportable transactions under Article 2 of Commission Delegated Regulation (EU) 2017/590 are reported and only the amount of the acquisition or disposal that takes place at the date time of the execution of the reportable transaction should be reported in field 30. Scenario: Decrease in notional amount of a financial instrument originally reported with a notional amount of EUR 10 mill. The instrument has an ongoing amortisation cash flow and after 2 years, the contract has a remaining notional of EUR 8.5 million due to amortisations, i.e. contractually pre-determined payments that have not been reported due to the exemptions under Article 2(5)(j) of Commission Delegated Regulation (EU) 2017/590. The contract is then terminated, i.e. the notional amount is decreased to zero, in a transaction that was not contractually pre-determined to take place. Field 30 (Quantity) shall be populated with 8.5 mill. This corresponds to the actual decrease of notional and it reflects the change in position of the investment firm resulting from a reportable transaction at the point of execution. ## 13 Reference Data for financial instruments \[Last update: 07/07/2017] ## Question 1 Q\&A 1693 What information trading venues need to provide with respect to reference data reported under Commission Delegated Regulation (EU) 2017/585 for bonds where the coupon is calculated based on a complex formula involving several indices? ## Answer 1 In case of bonds for which the coupon is calculated based on a complex formula that involves several indices, trading venues should provide the reference data using the following default values: * -Field 18 ('Fixed Rate') and Field 19 ('Identifier of the index / benchmark of a floating rate bond') should be left blank ; * -Field 20 ('Name of the index / benchmark of a floating rate bond') should be populated with the expression 'FORMULA'; * -Field 21 ('Term of index / benchmark of a floating rate bond') should be populated with '0 'DAYS''; ## 14 Financial instruments' volatile attributes \[Last update: 05/10/2017] Question 1 \[Last update: 05/10/2017] Q\&A 1694 * (a) How to complete reference data and transaction reports for financial instruments with a fixed rate that is a volatile attribute. * (b) How to complete reference data and transaction reports for financial instruments with a strike price that is a volatile attribute. ## Answer 1 * (a) Where a swap rate or forward rate financial contract is quoted as the fixed rate and it is considered to be an attribute of the transaction rather than an attribute of the financial instrument, the respective reports should be completed as follows: Transaction report[^8] - the price (field 33) of the transaction should be populated with the fixed rate value. The upfront payment (field 38) should be populated with a value of zero. Reference data report[^9] - the relevant fixed rate leg (field 43 or 44) of the financial contract should not be populated The above is applicable to the financial instruments with specific CFI codes for which the fixed rate is considered as a volatile attribute. The CFI validation document will be kept up to date to reflect that the fixed rate related fields should be non-applicable for the relevant CFI codes. * (b) Where the strike price of a financial contract is considered to be an attribute of the transaction rather than an attribute of the instrument then the respective reports shall be completed as follows: Transaction report - the price (field 33) of the transaction shall be populated with the strike price value. The upfront payment (field 38) shall be populated with the value of the option premium. Reference data - the strike price field shall not be populated. The above is applicable to the financial instruments with specific CFI codes for which the strike price is considered as a volatile attribute. The CFI validation document will be kept up to date to reflect that this field should be non-applicable for these codes. If the trading model deviates from (a) and (b) above then the transaction report shall be completed in line with ESMA's published guidelines for transaction reporting, order record keeping and clock synchronisation under MiFID II. In all cases transaction reports must be reported consistently with reference data. ## 15 FX Swaps reporting \[Last update: 26/09/2018] ## Question 1 Q\&A 1695 How should a transaction in an FX swap admitted to trading on a trading venue or traded on a trading venue be reported under Article 26 and Article 27 of MiFIR? ## Answer 1 If the instrument executed on a trading venue was an FX swap, it should be reported as an executed FX swap based on the requirement of Article 26(1) and in accordance with this Q\&A. The same principle will apply to trading carried out outside of the trading venue. If the instrument executed on a trading venue was an FX forward, it should be reported as an executed FX forward based on the requirement of Article 26(1). The same principle will apply to trading carried out outside of the trading venue. If the instrument admitted to trading or traded on a trading venue was an FX swap, it should be reported as an FX swap based on the requirement of Article 27(1) and in accordance with this Q\&A. If the instrument admitted to trading or traded on a trading venue was an FX forward, it should be reported as an FX forward based on the requirement of Article 27(1). ## Examples On March 13th 2018, investment firms A and B enter in a EUR/GBP (the currency mentioned first is the 'base' currency. The other currency is the 'terms' or 'quote' currency) spot-forward swap or a forward starting swap instrument on a trading venue regardless of how the instrument has been subsequently confirmed or settled. The instrument has the following characteristics: * -notional of the instrument: 1M€; * -maturity date of the instrument: September 15th 2018; * -the tenor of this instrument is 6 months * -ISIN code of the financial instrument: EZ0123456789; * -the price of the instrument is given in 5 swap points26 expressed in units of terms currency per unit of base currency according to the market convention for the currency pair which is this example is 0.0001£ per 1€; * -The EURGBP FX spot rate reference is 0.8200. The counterparty 27 that for the far leg (which is closer to the maturity date) is delivering the currency which is first when sorted alphabetically by ISO 4217 standard should be identified as seller. Therefore, the party which, on the near leg, delivers the currency which is first when sorted alphabetically should be identified as buyer. In our example, investment firm B who will (in 6 months) receive the GBP and deliver the EUR is the seller of the FX Swap. Investment firm A who will (in 6 months) deliver the GBP and receive the EUR is the buyer of the FX swap. The relevant fields in the transaction reporting as per article 26 of MIFIR should look like: 26 The swap points are the difference between the rate for the near leg and the rate for the far leg 27 As per Article 9 EMIR, and Question 24 of the Q\&A No 648/2012 on OTC derivatives | # | Field | Reporting of IF A | Reporting of IF B | | ----- | ------------------------------ | ----------------------------- | ----------------------------- | | 7 | Buyer | LEI of IF A | LEI of IF A | | 16 | Seller | LEI of IF B | LEI of IF B | | 28 | Trade date time | 2018-03- 13:Thh:mm:ss:ddddddZ | 2018-03- 13:Thh:mm:ss:ddddddZ | | 30 | quantity | 1,000,000 | 1,000,000 | | 31 | quantity currency | EUR | EUR | | 33 | price | 0.0005 | 0.0005 | | 34 | Price currency | GBP | GBP | | 36 28 | Venue | {MIC} | {MIC} | | 41 | instrument identification code | EZ0123456789 | EZ0123456789 | The price should be populated with the swap points and the monetary value XML tag should be used 29 . In the quantity field #30 the executing entity (buyer and seller) should report the amount of the FX SWAP in the base currency for the front (near) leg. In the quantity currency field #31, the executing entity (buyer and seller) should report the base currency of the FX SWAP. The price currency field should be populated with the terms currency i.e. GBP in this example. The below table shows how the transaction reports would change if the amount or currency of the notional differed. The fields 13 and 47 (see next page) in the reference data (RTS 23) will remain unchanged. | Scenario 1 (example above) EURGBP; Notional amount: EUR 1 million | Scenario 2 EURGBP; Notional amount: GBP 1 million | | ----------------------------------------------------------------- | ------------------------------------------------- | | | Firm A: 'I want a EURGBP FX Swap. The notional amount is EUR 1 million.' Firm B: 'My offer is 5 (swap points). The EURGBP FX spot rate reference is 0.8200.' | Firm A: 'I want a EURGBP FX Swap. The notional amount is GBP 1 million.' Firm B: 'My offer is 5 (swap points). The EURGBP FX spot rate reference is 0.8200.' | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | FX spot rate reference (applies to front leg) | 0.8200 | 0.8200 | | Swap points | 0.0005 | 0.0005 | | FX forward rate reference (applies to far leg) | 0.8205 | 0.8205 | | Cash flows 30 | | | | Front leg (EUR payment) | -1,000,000 | -1,219,512 | | Front leg (GBP payment) | 820,000 | 1,000,000 | | Far leg (EUR payment) | 1,000,000 | 1,218,769 | | Far leg (GBP payment) | -820,500 | -1,000,000 | | Transaction report | | | | Field 4 executing entity identification code firm | LEI of IF A | LEI of IF A | | Field 7 Buyer | LEI of IF A | LEI of IF A | | Field 16 Seller | LEI of IF B | LEI of IF B | | Field 30 quantity | 1,000,000 | 1,219,512 | | Field 31 Quantity currency | EUR | EUR | | Field 33 Price (monetary value) | 0.0005 | 0.0005 | | Field 34 Price currency | GBP | GBP | | Field 41 instrument identification code | EZ0123456789 | EZ0123456789 | The quantity in field 30 in the transaction report is always shown as positive. The examples show the reports of firm A but the reports of firm B would be identical. As per article 27 of MiFIR, the trading venue or SI admitting to trade or trading this instrument shall report it in FIRDS. The following table shows the expected reporting of the instrument reference data by trading venues or SI (only the relevant fields are displayed): | # | Field | Value | | - | ------------------------------ | ------------ | | 1 | Instrument identification code | EZ0123456789 | | 3 | Instrument classification | SFA\*\*\* or SFC\*\*\* 31 | | -- | ------------------------- | ------------------------- | | 13 | Notional currency 1 | EUR | | 24 | Expiry date | 2018-09-15 | | 34 | Delivery type | 'PHYS' 32 | | 47 | Notional currency 2 | GBP | Notional currency 1 should be populated with the 1st currency when sorted alphabetically by ISO 4217 standard. Notional currency 2 should be populated with the second currency when sorted alphabetically by ISO 4217 standard. ## 16 Interest Rate Swaps reporting \[Last update: 26/09/2018] ## Question 1 Q\&A 1696 What is the relationship between the interest rate term of the interest rate swap contract (tenor) field 41 33 and expiry date and the ISIN? ## Answer 1 If the expiry date and the interest rate term of the contract (tenor) are the same and the other fields in the reference data are the same then the instrument will have the same ISIN. So, for example, a forward starting contract that has the same expiry date and tenor and the same other characteristics as a contract starting immediately will have the same ISIN (see Examples 1-3 in the table below) and if the tenor and/or expiry of two instruments that otherwise share the same characteristics differ then they will have a different ISIN (see Examples 3-7 in the table below). ## Examples | Scenari o | Trading date | Amount of forward start/effectiv e from date Field (IR of | 41 term | Expiry date | | --------- | ------------ | --------------------------------------------------------- | ------- | ----------- | | | | | contract) 34 | | | | - | ----------- | -------------------- | ------------ | ---------------------------------- | ------------- | | 1 | 28/02/201 8 | 2 years (28/02/2020) | 8 YEARS | 28/02/2028 (28/02/2018 + 2 Y + 8Y) | EZ000000000 1 | | 2 | 28/02/201 9 | 1 year (28/02/2020) | 8 YEARS | 28/02/2028 (28/02/2019+1Y+8 Y) | EZ000000000 1 | | 3 | 28/02/202 0 | None (28/02/2020) | 8 YEARS | 28/02/2028 (28/02/2020+8Y) | EZ000000000 1 | | 4 | 26/02/201 8 | 2 years (26/02/2020) | 8 YEARS | 26/02/2028 (26/02/2018+2Y+8 Y) | EZ000000000 2 | | 5 | 28/02/201 8 | 5 years (28/02/2023) | 5 YEARS | 28/02/2028 (28/02/2018+5Y+5 Y) | EZ000000000 3 | | 6 | 28/02/201 8 | 6 years (28/02/2024) | 4 YEARS | 28/02/2028 (28/02/2018+6Y+4 Y) | EZ000000000 4 | | 7 | 28/02/202 0 | 2 years (28/02/2022) | 8 YEARS | 28/02/2030 (28/02/2018+ 2Y+8Y) | EZ000000000 5 | ## The instrument reference data would be as follows: | Rules for population of fields | Field no. | Field Name | | ------------------------------------------------------------------------------------------------------------- | --------- | ------------------------------ | | | 1 | Instrument identification code | | | 3 | Instrument classification | | The currency of leg 1 35 | 13 | Notional currency 1 | | | 24 | Expiry date | | | 25 | Price multiplier | | the floating rate in case of a fixed/floating IRS or the floating rate of leg 1 36 in a floating/floating IRS | 28 | Underlying index name | | the floating rate in case of a fixed/floating IRS or the floating rate of leg 1 36 in a floating/floating IRS | 29 | Term of the underlying index | ### Table | The value P - Physical is to be used when an interest rate swap is Deliverable where Deliverable means that the settlement, i.e. payment, currency amounts are paid in the respective reference currency for each leg of the swap for which the payments are being made. The value C - Cash is to be used when an interest rate swap is Non-Deliverable where Non-Deliverable means that the settlement, i.e. payment, currency amounts are paid in a currency other than the respective reference currency for each leg of the swap for which the payments are being made. | 34 | Delivery type | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -- | ------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). Example: A contract has a term of 19 years 11 months and 6 days = 19\*12 + 11 months with remainder of 6 days, which is rounded down. Therefore, the term is 239 months. 39 It is a volatile element and will therefore not be populated. | | 44 40 | Fixed rate of leg 2 | | -------------------------------------------------------------------------------------- | ----- | ---------------------------- | | The information of the floating rate of leg 2 (the other leg) in floating/floating IRS | 45 | Floating rate of leg 2 | | The information of the floating rate of leg 2 (the other leg) in floating/floating IRS | 46 | IR Term of contract of leg 2 | ## Question 2 Q\&A 1697 How should a transaction in an interest rate swap admitted to trading on a trading venue or traded on a trading venue be reported under Article 26 and Article 27 of MiFIR? ## Answer 2 ## Example 1: CFI code SRC*S* fixed-floating with single currency The principles for reporting of a fixed-floating swap are covered in the ESMA Q\&A 1 in section 14 on financial instruments' volatile attributes. ## 10 Years 3% EUR VS EURIBOR 6 MONTHS Investment Firm X buys an interest rate swap (ISIN EZ0000000006) from Investment Firm Y at a notional amount of EUR 100,000,000 on Trading Venue M on 26 February 2018 at 12:05:41:567 UTC. The expiry date of the swap is 28 February 2028. Firm X pays 3% while Firm Y pays EURIBOR 6 Months Transaction report would be as follows: | N | Field | Values Report Investment Firm X | Values Report Investment Firm Y | | -- | ------------------------------------ | ------------------------------- | ------------------------------- | | 4 | Executing entity identification code | {LEI} of Investment Firm X | {LEI} of Investment Firm Y | | 7 | Buyer identification code | {LEI} of Investment Firm X | {LEI} of Investment Firm X | | 16 | Seller identification code | {LEI} of Investment Firm Y | {LEI} of Investment Firm Y | | 28 | Trading date time | 2018-02- 26T12:05:41:56 7 | 2018-02- 26T12:05:41:56 7 | | -- | ------------------------------ | ------------------------------------ | ------------------------------------ | | 30 | Quantity '100000000' | | '100000000' | | 31 | Quantity currency 'EUR' | | 'EUR' | | 33 | Price 3 | | 3 | | 34 | Price Currency | | | | 36 | Venue 41 | Segment {MIC} of Trading Venue M | Segment {MIC} of Trading Venue M | | 38 | Up-front payment | 0 | 0 | | 41 | Instrument identification code | {ISIN} of instrument \[EZ0000000006] | {ISIN} of instrument \[EZ0000000006] | As set out in the RTS Table of fields (field 7 buyer identification code) the buyer is the counterparty paying the fixed rate. X is paying the fixed rate so is the buyer. The price field is populated with the amount of the fixed rate (3%). Field 43 (Fixed rate of leg 1) is blank in the instrument reference data. The instrument reference data would be as follows: | Field no. | Field Name | Value | | --------- | ------------------------------ | ------------ | | 1 | Instrument identification code | EZ0000000006 | | 3 | Instrument classification | SRC*S* | | 13 | Notional currency 1 | EUR | | 24 | Expiry date | 2028-02-28 | | 25 | price multiplier | 1 | | 28 | Underlying index name | EURI | | 29 | Term of the underlying index | 6 MNTH | | 34 | Delivery type | PHYS | | -- | ---------------------------- | ------- | | 40 | Reference rate | EURI | | 41 | IR Term of contract | 10 YEAR | | 42 | Notional currency 2 | | | 43 | Fixed rate of leg 1 | | | 44 | Fixed rate of leg 2 | | | 45 | Floating rate of leg 2 | | | 46 | IR Term of contract of leg 2 | | ## Answer 2 ## Example 2: CFI SRA*S*, Tenor basis swap (float-to-float single currency) ## 10 Years EUR EURIBOR 3 months + 2 basis points VS EURIBOR 6 MONTHS In the buyer identification code field the RTS provides: In the case of basis swaps (float to float) interest rate swaps the buyer shall be the counterparty that pays the spread Firm X Investment trades a basis swap (ISIN EZ0000000007) with Investment Firm Y at a notional amount of EUR 100,000,000 on Trading Venue M on 26 February 2018 at 12:05:41:567 UTC. The expiry date of the swap is 28 February 2028. Investment Firm X pays 3 month EUR EURIBOR + 2 basis points while Investment Firm Y pays 6-month EUR EURIBOR. Transaction report would be as follows: | N | Field | Values Report Investment Firm X | Values Report Investment Firm Y | | - | ------------------------------------ | ------------------------------- | ------------------------------- | | 4 | Executing entity identification code | {LEI} of Investment Firm X | {LEI} of Investment Firm Y | | 7 | Buyer identification code | {LEI} of Investment Firm X | {LEI} of Investment Firm X | | 16 Seller identification code | {LEI} of Investment Firm Y | {LEI} of Investment Firm Y | | --------------------------------- | ------------------------------------ | ------------------------------------ | | 28 Trading date time | 2018-02- 26T12:05:41:56 7 | 2018-02- 26T12:05:41:56 7 | | 30 Quantity | '100000000' | '100000000' | | 31 Quantity currency | 'EUR' | 'EUR' | | 33 Price | 2 | 2 | | Price Currency | | 34 | | 36 Venue 42 | Segment {MIC} of Trading Venue M | Segment {MIC} of Trading Venue M | | 38 Up-front payment | 0 | 0 | | 41 Instrument identification code | {ISIN} of instrument \[EZ0000000007] | {ISIN} of instrument \[EZ0000000007] | Firm X is paying the spread and is therefore populated as the buyer. If the spread was negative i.e. Firm X was paying 3 month EUR EURIBOR - 2 basis points then Firm X should still be reported as the buyer but the price would be reported as '-2' in the reports of X and Y. We are identifying the buyer as the payer of the spread In the reference data the following should be shown: * Leg 1 (field 28/40 and 29) = the leg with the reference rate that is first when sorted alphabetically * Leg 2 (field 45 and 46) the other leg. * Notional currency 1 = the currency for the legs. Should the reference data be identical as in the example being considered here then the following rules should be applied to determine which term applies to leg 1 and is to be populated in field 29: * i. if the term unit is the same order the term value numerically from lowest to highest * ii. if the term unit is different order chronologically by the term unit. 42 If this transaction is carried out outside the trading venue then field 36 should be populated with XOFF. The instrument reference data would be as follows: | Field no. | Field Name | Value | | --------- | ------------------------------ | ------------ | | 1 | Instrument identification code | EZ0000000007 | | 3 | Instrument classification | SRA*S* | | 13 | Notional currency 1 | EUR | | 24 | Expiry date | 2028-02-28 | | 25 | price multiplier | 1 | | 28 | Underlying index name | EURI | | 29 | Term of the underlying index | 3 MNTH | | 34 | Delivery type | PHYS | | 40 | Reference rate | EURI | | 41 | IR Term of contract | 10 YEAR | | 42 | Notional currency 2 | | | 43 | Fixed rate of leg 1 | | | 44 | Fixed rate of leg 2 | | | 45 | Floating rate of leg 2 | EURI | | 46 | IR Term of contract of leg 2 | 6 MNTH | As set out in the Commission Delegated Regulation field 46 is the reference period of the interest rate of leg 2. ## 17 FX forward reporting \[Last update: 07/10/2019] Question 1 \[Last update: 07/10/2019] Q\&A 1698 How should a transaction carried out on a trading venue on a FX forward be reported under Article 26 and Article 27 of MiFIR? Answer 1 ## Example: On March 13th, 2018, investment firms A and B enter in a EUR/GBP (the currency mentioned first is the 'base' currency, while the other currency is the 'terms' or 'quote' currency) FX forward instrument on a trading venue. The instrument has the following characteristics: * -Notional of the instrument: €1M; * -Effective date of the transaction: March 15th 2018 (T+2); * -Expiry date of the instrument: September 15th 2018; * -The tenor of this instrument is 6 months; * -ISIN code of the financial instrument: EZ1234567891; * -The price of the instrument is the FX forward rate expressed as a price of base currency in the quoted currency according to the market convention for the currency pair; * -The EUR/GBP FX forward rate reference is 0.8200. The counterparty that is receiving the currency which is first when sorted alphabetically by ISO 4217 standard should be identified as the buyer 43 . In our example, investment firm A who will (in 6 months) deliver the GBP and receive the EUR is the buyer of the FX forward, while investment firm B who will (in 6 months) receive the GBP and deliver the EUR is the seller of the FX forward. 43 As per field 7 (Buyer identification code) on table 2 of Annex 1 of RTS 22 ## A) The relevant fields in the transaction reporting as per article 26 of MiFIR should be: | # | Field | Reporting of IF A | Reporting of IF B | | ----- | ------------------------------ | ---------------------------- | ---------------------------- | | 7 | Buyer | LEI of IF A | LEI of IF A | | 16 | Seller | LEI of IF B | LEI of IF B | | 28 | Trading date time | 2018-03-13:Thh:mm:ss.ddddddZ | 2018-03-13:Thh:mm:ss.ddddddZ | | 30 | Quantity | 1,000,000 | 1,000,000 | | 31 | Quantity currency | EUR | EUR | | 33 | Price | 0.82000 | 0.82000 | | 34 | Price currency | GBP | GBP | | 36 44 | Venue | {MIC} | {MIC} | | 41 | Instrument identification code | EZ1234567891 | EZ1234567891 | The price should be populated with the forward rate expressed as a price of base currency in the quoted currency and the monetary value XML tag should be used 45 . In the quantity field #30 the executing entities (buyer and seller) should report the amount of the FX forward in the base currency. The quantity in field #30 in the transaction report is always shown as positive. 44 If this transaction is carried out outside a trading venue then field 36 should be populated with XOFF. 45 Notional currency 1 may not be the base currency of the contract. In the quantity currency field #31, the executing entities (buyer and seller) should report the base currency of the FX forward. The price currency field should be populated with the term / quote currency (i.e. GBP in this example). Although the examples show the reports of firm A, the reports of firm B would be identical. * B) As per article 27 of MiFIR, the trading venue or SI admitting to trade or trading this instrument shall report it in FIRDS. The following table shows the expected reporting of the instrument reference data by trading venues or SIs (only the relevant fields are displayed): | # | Field | Value | | -- | ------------------------------ | ------------ | | 1 | Instrument identification code | EZ1234567891 | | 3 | Instrument classification | JFTX\*P | | 13 | Notional currency 1 | EUR | | 24 | Expiry date | 2018-09-15 | | 34 | Delivery type | 'PHYS' 46 | | 47 | Notional currency 2 | GBP | Notional currency 1 should be populated with the 1st currency when sorted alphabetically by ISO 4217 standard. Notional currency 2 should be populated with the second currency when sorted alphabetically by ISO 4217 standard. ## 18 Reporting of reference rates not included in RTS 23 and 22 \[Last update: 28/05/2021] Question 1 Q\&A 1505 Following the creation of new risk-free rates, it is important to clarify how: 46 For populating the delivery type field, the definitions in the ISO 10962:2015 CFI standard should be considered. The value 'PHYS' should be populated in the following case: 'delivery of traded currencies on settlement date'. The value 'CASH' should be populated in the following case: 'on settlement date of the trade, if the settlement amount is positive, then the currency buyer will pay that amount in the settlement currency to the currency seller; if that amount is negative, the seller will make that payment to the buyer'. * (a) Trading Venues and SIs should report financial instruments based on this rate under RTS 23; * (b) MiFID investment firms should report this rate in transaction reports where the reference data fields have to be reported under RTS 22; and * (c) How other reference rates should be reported that are not explicitly included in RTS 23 and RTS 22. * (d) Are voluntary switch to risk-free rates considered reportable transactions under MiFIR Article 26? * (e) In case a financial instrument with a fallback rate is assigned a new ISIN, should reporting entities populate Field 1 with the new ISIN under RTS23? ## Answer 1 At the time RTS 23 and RTS 22 were developed, risk-free rates were not yet widely used in contracts, therefore the list of standardised codes for reporting of reference rates specified in these Regulations did not include the code for these rates. Since there is no code, the freetext format is applicable for fields where the name of the rate should be populated. However, in order to ensure consistent reporting and enable the reconciliation of the reports in question, the 4-letter code assigned to risk-free rates, in the ISO 20022 standard should be populated in these fields. For instance, in the case of €STR it should be reported 'ESTR'. ## (a) RTS 23 reporting by trading venues and SIs Where applicable, the ISIN assigned for risk-free rates should be reported. For instance, in the case of €STR it should be reported as ISIN 'EU000A2X2A25'. This should be in addition to the 4-letter code of the rate 'ESTR'. This would apply to the following fields: | Instrument type | RTS 23 Field number | RTS 23 Field name | Value | | --------------- | ------------------- | ---------------------------------------------------------- | -------------- | | | 19 | Identifier of the index/bench-mark of a floating rate bond | 'EU000A2X2A25' | | Bonds or other forms of securitised debt | 20 | Name of index/ bench-mark of a floating rate bond | N/A 47 | | ---------------------------------------- | -- | ------------------------------------------------- | -------------- | | Derivative and Securitised | 26 | Underlying instrument code | 'EU000A2X2A25' | | Derivatives | 28 | Underlying index name | 'ESTR' | | Interest Rate Derivatives | 40 | Reference rate | 'ESTR' | | Interest Rate Derivatives | 45 | Floating rate of leg 2 | 'ESTR' | ## (b) RTS 22 reporting by MiFID investment firms The ISIN assigned to a given rate should be reported, e.g. in the case of €STR, 'EU000A2X2A25' would be populated in the Underlying instrument code (field 47) . If an ISIN is not available for a given rate, this field should not be populated. The Underlying index name (field 48) should be reported as 'ESTR' in the free-text field, regardless of whether the ISIN is also reported in field. ## (c) Reporting of other reference rates not included in RTS 22/23 Similarly, for other reference rates that are not included in the list of standardised codes in RTS 22 or RTS 23, the 4-letter code assigned to that reference rate in the ISO 20022 standard should be reported as described in ISO 20022 Benchmark Curve Name Code at the following link. This is to the extent that such codes are available and the field(s) referred in the answers to questions (a) and (b) requiring ALPHANUM-25 values are applicable. ## (d) Voluntary switch to risk-free rates No, the voluntary switch to risk-free rates is not considered a reportable transaction under MiFIR Article 26 as it would fall under RTS 22 Article 2(5)(i) exemption (the creation, expiration or redemption of a financial instrument as a result of pre-determined contractual terms, or as a result of mandatory events which are beyond the control of the investor where no investment decision by the investor takes place at the point in time of the creation, expiration or redemption of the financial instrument). ## (e) Fallback of the reference rate Yes. If the financial instrument based on the fallback rate is assigned a different ISIN than the equivalent financial instrument based on LIBOR, the reporting entities should: 1. Terminate the financial instrument in FIRDS, when the instrument ceases referring to LIBOR, and 2. Resubmit to FIRDS the financial instrument reference data with the new ISIN when switching to a different rate in case the new financial instrument with its ISIN is admitted to trading or is traded in accordance with Article 2 of RTS 23. ## 19 Reporting of Emission Allowances \[Last update: 11/07/2022] *new* Question 1 \[Last update: 11/07/2022] Q\&A 1506 How should Trading Venues and SIs report emission allowances (i.e., European Union Allowances (EUAs) and European Union Aviation Allowances (EUAAs)) auctioned for the phase 4 of the EU Emission Trading System (ETS) 48 (hereafter 'phase 4 emission allowances' or derivatives thereof under MiFIR Article 27 and RTS 23? ## Answer 1 The ISIN displayed on European Commission's website to phase 4 emission allowances should be reported in FIRDS under RTS 23. Field 1 - Instrument identification code should be reported with ISIN EU000A2QMW50 for EU allowances and EU000A2QMW68 for EU aviation allowances . In case of derivatives having as underlying a phase 4 emission allowance, Field 26 - Underlying instrument code should be populated with EU000A2QMW50 for EU allowances and EU000A2QMW68 for EU aviation allowances. The table below clarifies the different reporting scenarios based on the type of emission allowance. The fields displayed in the tables are all RTS 23 fields that are applicable to emission allowances or derivatives thereof in the FIRDS CFI validation rules. Example 1 - Reporting of phase 4 EUA (spot) | RTS 23 Field number | RTS 23 Field name | Value | Content to be reported 49 | | ------------------- | ----------------- | ----- | ------------------------- | Example 2 - Reporting of a future on phase 4 emission allowance | 1 | Instrument identification code | EU000A2QMW50 | ISIN displayed on the European Commission's website. | | -- | ------------------------------------------------------ | ------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | 2 | Instrument full name | EUA Allowance Units Phase 4 | | | 3 | Instrument classification | ITNXXX | | | 4 | Commodities or emission allowance derivative indicator | No | | | 5 | Issuer or operator of the trading venue identifier | LEI | LEI of the regulated market appointed as an auction platform pursuant to COMMISSION REGULATION (EU) No 1031/2010' | | 6 | Trading Venue | Segment {MIC} of Trading Venue | | | 8 | Request for admission to trading by issuer | No | | | 11 | Date of admission to trading or date of first trade | 10/04/2022 | | | 12 | Termination date | 10/04/2024 | | | 13 | Notional currency 1 | EUR | | | RTS 23 Field number | RTS 23 Field name | Value | Content to be reported 50 | | ------------------- | ------------------------------------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | 1 | Instrument identification code | {ISIN} of financial instrument | | | 2 | Instrument full name | XXX FUTURE ON EEA | | | 3 | Instrument classification | FCNPSX | | | 4 | Commodities or emission allowance derivative indicator | Yes | | | 5 | Issuer or operator of the trading venue identifier | {LEI} of issuer | | | 6 | Trading Venue | Segment {MIC} of Trading Venue | | | 8 | Request for admission to trading by issuer | No | | | 11 | Date of admission to trading or date of first trade | 10/04/2022 | | | 12 | Termination date | 10/04/2023 | | | 13 | Notional currency 1 | EUR | | | 24 | Expiry date | 10/04/2023 | | | 25 | Price Multiplier | 1000 | Lot size /contract size , e.g. for exchange traded derivatives, 1 lot corresponds to 1,000 allowances or 1,000 tCO2. EUAs | | 26 | Underlying Instrument code | EU000A2QMW50 | ISIN displayed on the European Commission's website. | | -- | ---------------------------- | ------------ | ---------------------------------------------------- | | 28 | Underlying index name | | Optional | | 29 | Term of the underlying index | | Optional | | 34 | Delivery type | 'PHYS' | | | 35 | Base product | ENVR | | | 36 | Sub product | EMIS | | | 37 | Further sub product | EUAE | | | 38 | Transaction type | OTHR | | | 39 | Final price type | EXOF | | Example 3 - Reporting of option on a future on phase 4 emission allowance ### Table | RTS 23 Field number | RTS 23 Field name | Value | Content to be reported 51 | | ------------------- | ----------------- | ----- | ------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). | 6 | Trading Venue | Segment {MIC} of Trading Venue | | | -- | --------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | 8 | Request for admission to trading by issuer | No | | | 11 | Date of admission to trading or date of first trade | 10/04/2022 | | | 12 | Termination date | 10/04/2023 | | | 13 | Notional currency 1 | EUR | | | 24 | Expiry date | 10/04/2023 | | | 25 | Price Multiplier | 1000 | Lot size /contract size , e.g. for exchange traded derivatives, 1 lot corresponds to 1,000 allowances or 1,000 tCO2. EUAs | | 26 | Underlying Instrument code | {ISIN} of the underlying future contract | ISIN of the underlying future | | 28 | Underlying index name | | Optional | | 29 | Term of the underlying index | | Optional | | 30 | Option type | 'PUTO' | | | 31 | Strike price | 90.00 | Price at which the underlying is purchased or sold when the option is exercised | | 31 | Strike price currency | 'EUR' | | | 33 | Option exercise style | 'EURO' | | | 34 | Delivery type | 'PHYS' | | | 35 | Base product | ENVR | | | 36 | Sub product | EMIS | | -- | ------------------- | ---- | | 37 | Further sub product | EUAE | | 38 | Transaction type | OTHR | | 39 | Final price type | EXOF | ## *new* Question 2 \[Last update: 11/07/2022] Q\&A 1507 In case of phase 4 emission allowances or derivatives thereof reported with an ISIN which is different from the ISIN displayed on the European Commission website, * a) should trading venues and SIs amend the record in FIRDS with the correct ISIN displayed on the European Commission's website? * b) how should trading venues amend the record concerning phase 4 emission allowances in FIRDS with the correct ISIN displayed on the European Commission's website? * c) how should trading venues and SIs amend the record concerning futures on phase 4 emission allowances in FIRDS with the correct ISIN displayed on the European Commission's website? ## Answer 2 * a) yes * b) Trading venues that previously submitted phase 4 emission allowances with a different ISIN in FIRDS (i.e. not the EU ISIN for phase 4) should: * i. Terminate the incorrect phase 4 emission allowances in FIRDS, and * ii. Resubmit in FIRDS the phase 4 emission allowance with the ISIN for phase 4 (i.e. EU000A2QMW50 or EU000A2QMW68) displayed by the European Commission. * c) Trading venues and SIs that previously submitted futures on phase 4 emission allowances with a different underlying ISIN (i.e. not the EU ISIN for phase 4) as underlying should: * i. Terminate the future in FIRDS, and * ii. Resubmit in FIRDS the future on phase 4 emission allowance with the ISIN of the phase 4 emission allowances as underlying (i.e. EU000A2QMW50 or EU000A2QMW68) displayed by the European Commission. ## *new* Question 3 \[Last update: 11/07/2022] Q\&A 1508 How should trading venues record phase 4 emission allowances and derivatives thereof under MiFIR Article 25 and RTS 24 for the purpose of the order book record keeping? ## Answer 3 Trading venues should record phase 4 emission allowances under RTS 24 Field 18 - Financial instrument identification code with the following ISINs displayed on European Commission's website: * EU000A2QMW50 for phase 4 emission allowance * EU000A2QMW68 for phase 4 emission aviation allowance In case of derivatives on phase 4 allowances, trading venues should record these instruments with the ISIN assigned by the National Numbering Agency in Field 18 - Financial instrument identification code. ## Example: | RTS 24 Field number | RTS 24 Field name | Value | Content to be reported 52 | | ------------------- | ---------------------------------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | | 18 | Financial instrument identification code | EU000A2QMW50 or EU000A2QMW68 | ISIN displayed on the European Commission's website and assigned by the relevant National Numbering Agency. | ## 20 Complex trades \[Last update: 04/02/2019] Questions 1 \[Last update: 04/02/2019] Q\&A 1699 * a) Does a complex trade as defined under Article 12 of RTS 22 need to have a single price available for the transaction? 52 In case of further clarification of the description of the fields are needed these are provided in this column * b) If there are prices available for the components of a complex trade does it mean that it is not a complex trade? * c) How should the TVTIC (field 3 of RTS 22) be populated in transaction reports of a complex trade? * d) How should a complex trade be transaction reported under article 26 of MiFIR where the components contain reportable and non-reportable financial instruments? * e) If a component instrument or a complex trade (e.g. strategy) has an ISIN, does it make it reportable under article 26 of MIFIR? * f) How should a complex trade (e.g. a strategy or other instrument where a transaction in the instrument is a complex trade) be reported in the instrument reference data under article 27 of MiFIR and article 4 of MAR? * g) For an instrument where a transaction is a complex trade (for example a strategy) should a component of the instrument be reported in the instrument reference data under article 27 of MIFIR and article 4 of MAR if it is not admitted to trading or traded on a trading venue? ## Answers * a) Yes as stated in 5.35.9 of the Guidelines, a transaction should only be considered to involve two or more financial instruments when there is one single transaction in multiple financial instruments simultaneously for one single price. * b) No, there may be a price because the components may be traded separately. If there is a single price available for a single transaction in multiple financial instruments, then it is a complex trade. * c) The TVTIC provided by the TV that is applicable for that leg of the complex trade should be reported in each leg. If the TV provides the same TVTIC for more than one leg of a complex trade, then that TVTIC should be used for each leg to which it is applicable. If a TV provides different TVTICs for some legs, then the TVTIC applicable for each leg should be reported. If a leg of a complex trade is not executed on a TV, then the TVTIC field will not be populated for that leg. * d) Only the legs for the components of a complex trade that are financial instruments that are reportable under article 26(2) should be transaction reported. The components to be reported include not only financial instruments that are admitted to trading or trading on a trading venue (reportable instruments under article 26(2)(a)), but also instruments that are not admitted to trading or traded on a trading venue but are financial instruments that are reportable under article 26(2)(b) or (c), for example a future on an equity where the future is not admitted to trading or traded on a trading venue but the underlying equity is admitted to trading on a trading venue. Even where only one of the components is a reportable financial instrument, field 40 of RTS 22 should be populated with a complex trade ID since this indicates that the transaction in the reportable financial instrument is part of a complex trade and explains why the price reported may deviate from the price of the transaction in the reportable financial instrument itself. * e) No. Just because an instrument or a complex trade (e.g. a strategy) has an ISIN it does not mean that it is a reportable financial instrument. Some instruments and complex trades may have ISINs but are not financial instruments under MIFID II. For example commodities such as gold may have an ISIN but are not financial instruments under Section C of Annex I of MIFID II. Other instruments may be financial instruments but not a reportable instrument under article 26(2). For example an interest rate derivative is a financial instrument under Section C of Annex I of MiFID II but unless the instrument is admitted to trading or traded on a trading venue it is not a reportable financial instrument under 26(2) regardless of whether it has an ISIN. * f) Rather than the instrument reference data for the complex trade (e.g. strategy or other instrument where a transaction in the instrument is a complex trade) being reported, the instrument reference data for the components that make up the strategy should be reported under article 27 of MiFIR and article 4 of MAR. This is because the strategy is not a financial instrument itself. This is the case even if the strategy happens to have an ISIN. Each component should be reported as a separate record and in the same way as if it was not part of a strategy - all of the instrument reference data fields should be populated with the instrument reference data for the component. * g) No, only the components that are admitted to trading or traded on a trading venue should be reported in the instrument reference data. ## 21 FIRDS fields 8 to 11 \[Last update: 26/09/2018] ## Question 1 Q\&A 1700 How should a trading venue or SI populate fields 8 to 11 in reports under Art. 4 MAR and Art. 27 MiFIR? ## Answer 1 A trading venue or SI should populate fields 8 to 11 in reports under Art. 4 MAR and Art. 27 MiFIR as shown in the scenarios described below. ### Table | Column 1 | Column 2 | Column 3 | Case 1 Admission to trading (only on RM) | Case 2 Admission to trading (only on RM) | Case 3 Admission to trading (only on RM) | Case 4 Admission to trading (only on RM) | Case 5 Admission to trading (only on RM) | Case 6 Admission to trading (only on RM) | Case 7 traded (MTF and OTF) | Case 8 traded (MTF and OTF) | Case 9 SI | | -------- | -------- | -------- | ---------------------------------------- | ---------------------------------------- | ---------------------------------------- | ---------------------------------------- | ---------------------------------------- | ---------------------------------------- | --------------------------- | --------------------------- | --------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | Column 1 | Column 2 | instruments on a trading venue. | Column 4 | Column 5 | Column 6 | Column 7 | Column 8 | Column 9 | Column 10 | Column 11 | Column 12 | | -------- | -------- | ------------------------------- | -------- | -------- | -------- | -------- | -------- | -------- | --------- | --------- | --------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). Note: if the issuer has requested the admission to trading, this is taken to mean that the issuer approved the trading on that trading venue at the time of the request. Furthermore, if the situation alters because the issuer has changed its mind after making the request, field 9 should be updated by being left blank. ## 22 Reporting of Nominal value per unit and minimum traded value \[Last update: 25/03/2022] Question 1 \[Last update: 25/03/2022] Q\&A 1509 How should field 17 (Nominal value per unit/minimum traded value) be populated in FIRDS? ## Answer 1 The population of field 17 should be in line with the characteristics defined in the prospectus, as indicated in its own prospectus or admission document. In case the instrument was issued in units, field 17 should be populated with the nominal value per unit. If the instrument was issued in nominal amount (e.g. instrument priced in percentages), then field 17 should be populated with the minimum traded value (i.e. the minimum specified denominations, in case such denominations are available, otherwise the lowest specificied multiples). ## 23 Defined List of Instruments \[Last update: 08/04/2019] ## Question 1 \[Last update: 08/04/2019] Q\&A 1701 How should operators of trading venue(s) report instrument reference data in accordance with Article 2 of RTS 23[^7] and related MAR RTS and ITS 54 in cases where they operate on the basis of a defined list of instruments? ## Answer 1 MiFIR article 27 on the provision of reference data states that operators of trading venues shall provide competent authorities with reference data ' with regard to financial instruments admitted to trading on regulated markets or traded on MTFs or OTFs'. According to MiFIR Article 27, the concept of 'traded' applies to MTFs, OTFs and SIs. Article 2 of RTS 23 states that the concept of 'traded' 'includes' , but is not limited to, cases ' where orders or quotes are placed '. This provision should be read in combination with the further explanations given by ESMA in the Consultation Paper and subsequent Final Report related to RTS 23, which describe the rationale and the considerations behind this requirement. 54 Commission Delegated Regulation (EU) 2016/909 of 1 March 2016 supplementing Regulation (EU) No 596/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the content of notifications to be submitted to competent authorities and the compilation, publication and maintenance of the list of notifications. Commission Implementing Regulation (EU) 2016/378 of 11 March 2016 laying down implementing technical standards with regard to the timing, format and template of the submission of notifications to competent authorities according to Regulation (EU) No 596/2014 of the European Parliament and of the Council. As already clarified by ESMA in the Final Report, the operators that do not work with a defined list of instruments should submit reference data where orders or quotes are placed or the first trade occurs. This clarification should be read in conjunction with the previously published Consultation Paper, which stated in more detail that 'reference data submissions by a given trading venue for a given financial instrument will be triggered from the moment trading commences on that financial instrument in that particular trading venue. This means that each day an operator is open for trading, it should submit reference data only if an order or quote is placed in the instrument between 18:00 CET on the previous day and 18:00 CET on that day. If the following day there is no order/quote, then the operator should not report reference data. Therefore, with respect to operators of trading venues that do work with a defined list of financial instruments, ESMA has clarified that ' the obligation to supply reference data will be triggered from the moment of admission to trading or from the moment of the inclusion of the financial instrument in the list'. These trading venues should provide instrument reference data for all these instruments regardless of whether an order or quote was placed on the instrument or a trade occurred on a given day. The concept of 'defined list' applies to all cases where the relevant details pertaining to the financial instrument concerned referred to in Table 3 of the Annex to RTS 23 are definable before the start of the trading day. This is generally the case for securities (including but not limited to equities and bonds), however, it is not necessarily the case for derivative instruments. It should be noted that the two regimes described in the second and third paragraph above apply to each individual TV/SI depending on the specific business model of the TV/SI. This means that if a TV operates on the basis of a defined list, such TV should always submit reference data in accordance with the third paragraph of this answer, the placement of an order on the instrument does not per se change the nature of the TV's business model. ## 24 Transaction reporting \[Last update: 31/03/2023] ## Question 1 \[Last update: 03/04/2017] Q\&A 1702 Where the price of a transaction is not available at the time of execution (e.g. the NAV for certain ETFs), how can investment firms fulfil their post-trade transparency obligations under Articles 20 and 21 of MiFIR and their transaction reporting obligations under Article 26 of MiFIR for those transactions? ## Answer 1 If the price of a transaction is not available at the time of execution, investment firms should fulfil the applicable reporting obligations using 'PNDG' as price, specified in the field 'Price' of table 3 of Annex I of RTS 1, table 2 of Annex II of RTS 2 and/or field 33 of table 2 of Annex I of RTS 22. As soon as the price of the transactions (including the NAV in the particular case of ETFs) becomes available, investment firms should cancel the original reports with the 'PNDG' price (using the cancellation flag for post-trade transparency publication purposes) and publish new reports/ send new transaction reports pertaining to the given transactions using the actual price that became available (using the amendment flag for post-trade transparency publication purposes). The date and time specified in the field 'Publication date and time' of table 3 of Annex I of RTS 1, table 2 of Annex II of RTS 2 and/or field 28 of table 2 of Annex I of RTS 22 should always refer to the original date and time of the execution. ## Question 2 \[Last update: 28/09/2020] Q\&A 1510 How are different national identifiers specified in Annex II of RTS 22 represented? ## Answer 2 The table below shows the list of national client identifiers for natural persons to be used in transaction reports pursuant to the priority specified in Annex II of the Commission Delegated Regulation (EU) 2017/590. Information related to the format of the identifier is not provided in the case of CONCAT, since the procedure for generating such identifier is defined in Articles 6(1) and 6(4) of the Commission Delegated Regulation (EU) 2017/590. ### Table | Country code | Country name | National client identifier | Format of the identifier | Potential source of the information | | ------------ | ------------ | -------------------------- | ------------------------ | ----------------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | DE | Germany | CONCAT | CONCAT | CONCAT | | -- | ------- | ------ | ------ | ------ | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | GB | United Kingdom | UK National Insurance number | Two prefix letters, followed by six digits with one suffix letter, which is always A, B, C, or D. It looks something like this: AB123456A. The characters D, F, I, Q, U and V are not used as either the first or second letter of the prefix. The letter O is not used as the second letter of the prefix. For administrative reasons HMRC andDWP have sometimes used reference numbers which look like NINOs but which do not use valid prefixes. The administrative prefixes used are OO, CR, FY, MW, NC, PP, PZ, TN. These should not be used. | The NINO is an administrative number primarily for the use ofHM Revenue and Customs (HMRC) or the Department for Work and Pensions (DWP). It can be on a plastic National Insurance card, paper card or letter from HRMC and may also be obtained from payslips, form P60, tax returns or letters from the DWP/HRMC. | | -- | -------------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | Column 1 | Column 2 | Personal code (Asmens kodas) | It is 11 digits long. Format GYYMMDDNNNC, where G is the gender (4 or 6 for women; 3 or 5 for men); YYMMDD is the date of birth; NNN - serial number; C - check digit. | Passport, National ID, Driving license | | -------- | -------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | Column 1 | Column 2 | CONCAT | CONCAT | CONCAT | | -------- | -------- | ------ | ------ | ------ | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | Column 1 | Column 2 | CONCAT | CONCAT | CONCAT | | -------- | -------- | ------ | ------ | ------ | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ### Table | SI | Slovenia | Personal Identification Number (EMŠO: Enotna Matična Številka Občana) | It consists of 13 digits. The first 7 numbers represent the date of birth of the person - DDMMYYY. Digits 8 and 9 represent the number of a re gister where EMŠO was assigned: • 10 -19 - Bosnia and Hercegovina (if signed in before 18 February 1999) • 20 -29 - Montenegro (if signed in before 18 February 1999) • 30 -39 - Croatia (if signed in before 18 February 1999) • 40 -49 - Macedonia (if signed in before 18 February 1999) • 50 -59 - Slovenia (if signed in before 18 February 1999, if later number 50 is used) • 60 -69 - (not in use) • 70 -79 - Serbia (if signed in before 18 February 1999) • 80 -89 - Autonomous Province of Vojvodina (if signed in before 18 February 1999) • 90 -99 - Kosovo (if signed in before 18 February 1999)). Digit 10, 11 and 12 are a combination of gender and serial number for persons, born on the same day (000-499 for male and 500-999 for female). Number 13 is a control number and is calculated by a special procedure, defined in Article 4 of the Regulation on the way of assigning the personal identification number (Nos. no. 8/99). | Slovenian Personal Identity Card Slovenian National Passport | | -- | -------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | Full table: see [document](https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-56_qas_mifir_data_reporting.pdf). ## Question 3 \[Last update: 07/07/2017] Q\&A 1703 Could there be circumstances where the buyer and seller in a transaction report made under Article 26 of MiFIR are the same? ## Answer 3 Yes, where a firm or investment firm, Firm A, instructs an investment firm, Firm B, to make a simultaneous buy and sell for its clients but Firm A has not complied with the conditions for transmission under article 4 of Commission Delegated Regulation (EU) 2017/590. If Firm B executes these transactions outside a trading venue then it should report the ISO 17442 LEI of Firm A in the buyer and seller fields in its transaction reports. ## Question 4 Q\&A 1704 How shall Field 30 (Quantity) in Commission Delegated Regulation (EU) 2017/590 Annex I Table 2 be reported for a transaction where there have previously been acquisitions or disposals that are excluded from the meaning of a transaction? For example, a decrease in notional amount in a financial instrument which has previously had pre-determined contractual down payments exempted from transaction reporting under Commission Delegated Regulation (EU) 2017/590 Article 2(5)(j)? ## Answer 4 Competent authorities require an accurate and holistic view of transactions that are within the scope of reporting requirements under Article 26 of MiFIR. Therefore, Article 15(5) of Commission Delegated Regulation (EU) 2017/590 obliges an Investment Firm to ensure that a collective view of the transaction reports reported by the Investment Firm as the executing entity accurately reflects all changes in its position and in the position of its clients that arise from reportable transactions. It should be noted that the reporting requirements are not intended to capture the Investment Firm's or the Investment Firm's client's actual position. What is of interest to competent authorities is the change of position resulting from reportable transactions. Therefore only acquisitions or disposals that are reportable transactions under Article 2 of Commission Delegated Regulation (EU) 2017/590 are reported and only the amount of the acquisition or disposal that takes place at the date time of the execution of the reportable transaction should be reported in field 30. Scenario: Decrease in notional amount of a financial instrument originally reported with a notional amount of EUR 10 mill. The instrument has an ongoing amortisation cash flow and after 2 years, the contract has a remaining notional of EUR 8.5 million due to amortisations, i.e. contractually pre-determined payments that have not been reported due to the exemptions under Article 2(5)(j) of Commission Delegated Regulation (EU) 2017/590. The contract is then terminated, i.e. the notional amount is decreased to zero, in a transaction that was not contractually pre-determined to take place. Field 30 (Quantity) shall be populated with 8.5 mill. This corresponds to the actual decrease of notional and it reflects the change in position of the investment firm resulting from a reportable transaction at the point of execution. ## Question 5 \[Last update: 05/10/2017] Q\&A 1705 In the case of a transaction on an OTC derivative contract[^10], what is expected in the transaction report when any of the following characteristics of that contract is changed: fields 50 to 56 of annex 2 of CDR 2017/590? ## Answer 5 When any of those characteristics of the contract change, the transaction thereof should be considered as a new contract and therefore two transaction reports are expected: * -One materializing the closing out of the initial derivative contract (swapping the buyer and the seller). * -One for the opening of the new contract with the new characteristics. ## Question 6 \[Last update: 05/10/2017] Q\&A 1706 Consider a scenario where an investment firm (Bank B) executes a reportable transaction under a discretionary mandate for a Client A (portfolio management). * a) Does the Client A also have an obligation to report this transaction under Art. 26 MiFIR? * b) Does the Client A also have an obligation to report this transaction under Art. 26 MiFIR when a fund management company that is not a MiFID II investment firm (Firm Z) is interposing between client and Bank B? ## Answer 6 Yes, in both cases there is an own reporting obligation for Client A under Art. 26 MiFIR, if Client A is an investment firm. Client A has to report under Art. 26 MiFIR because it provides the service under Art. 3 (1) (c) Commission Delegated Regulation (EU) 2017/590 'dealing on own account'. Dealing on own account as it is defined in Art. 4 (1) (6) MiFID II means trading against proprietary capital resulting in the conclusion of transactions in one or more financial instruments. Even though the client outsources the investment decision and execution to Bank B it is still considered to be 'dealing on own account' under Art. 3 (1) c Commission Delegated Regulation (EU) 2017/590. ## Question 7 \[Last update: 14/11/2017] Q\&A 1707 How should transactions be transaction reported where portfolio management has been outsourced? ## Answer 7 Consider the following example, where Banks A, B and Firm Z are investment firms: * Client has a portfolio at Bank B. * The client is a German national, Max Mustermann. His date of birth is 01/04/1974. * Bank B has outsourced the portfolio management (discretionary mandate) to Firm Z, which is an investment firm undertaking portfolio management. * Firm Z sends a purchase order to Bank A for execution without meeting the conditions for transmission under article 4 of Commission Delegated Regulation (EU) 2017/590. Firm Z is acting in an 'any other' trading capacity. * Firm Z does not have a contract with the Client. * Bank A executes the order on a Trading Venue. * Bank A transfers the financial instruments from its own account to the account of Bank B just for settlement purposes. * Bank B books the financial instruments from its account into the account of the Client. ## a) Bank A and Bank B are acting in an own account trading capacity The reports by Bank A and Bank B will be as follows: | | | Bank A's reports | Bank A's reports | Bank B's reports | Bank B's reports | | -- | ------------------------------------ | ------------------- | ------------------- | ------------------- | ----------------------- | | N | Field | Report 1 Values | Report 2 Values | Report 1 Values | Report 2 Values | | 3 | TVTIC | '1234' | | | | | 4 | Executing entity identification code | {LEI} of Bank A | {LEI} of Bank A | {LEI} of Bank B | {LEI} of Bank B | | 7 | Buyer | {LEI} of Bank A | {LEI} of Firm Z | {LEI} of Bank B | 'DE19740401MA X##MUSTE' | | 12 | Buyer decision maker code | | | | {LEI} of Firm Z | | 16 | Seller | {LEI} of CCP | {LEI} of Bank A | {LEI} of Firm Z | {LEI} of Bank B | | 21 | Seller decision maker code | | | | | | 29 | Trading capacity | 'DEAL' | 'DEAL' | 'DEAL' | 'DEAL' | | 36 | Venue | {MIC} of TV | 'XOFF' | 'XOFF' | 'XOFF' | | 57 | Investment decision within firm | Algo or national ID | Algo or national ID | Algo or national ID | Algo or national ID | | 59 | Execution within firm | Algo or national ID | Algo or national ID | 'NORE' | 'NORE' | Bank A is receiving instructions from Firm Z without the transmission requirements being met so it will report Firm Z as the buyer in its client side report. Bank B's counterparty for execution purposes is Firm Z and since Bank B has not met the transmission conditions it will report its client as the buyer and itself, Bank B, as the seller. Bank B has outsourced the discretionary management for its client to Firm Z so there is a power of representation. However, field 12 is only populated where the decision is made under a power of representation and the buyer is a client of the executing entity. Therefore field 12 is only populated in Report 2 of Bank B, since in Report 1 Bank B is itself the buyer. Even though Firm Z is making the investment decision on behalf of Firm B, field 57 is a mandatory field where a firm is acting in an own account trading capacity since the firm is accepting the risk. Therefore this should be populated with the algo or person in Bank B that is primarily responsible for the decision to delegate. Field 59 is a mandatory field but where the execution decision is made outside the firm it is populated with 'NORE'. In this scenario the execution decision is being made by Firm Z as it is deciding when and how to execute (by sending orders to Firm A) and therefore this field is populated with 'NORE' in Bank B's reports . ## Reporting by Firm Z | | | Portfolio Management Firm Z | | -- | ------------------------------------ | --------------------------- | | N | Field | Report X Values | | 3 | TVTIC | | | 4 | Executing entity identification code | {LEI} of Firm Z | | 7 | Buyer | {LEI} of Bank B | | 12 | Buyer decision maker code | {LEI} of Firm Z | | 16 | Seller | {LEI} of Bank A | | 21 | Seller decision maker code | | | 29 | Trading capacity | 'AOTC' | | 36 | Venue | 'XOFF' | | 57 | Investment decision within firm | Algo or national ID | | 59 | Execution within firm | Algo or national ID | Firm Z is acting on behalf of Bank B and since Bank B has not met the transmission conditions it will report Bank B as the buyer and Bank A as the seller. Firm Z is making an investment decision on behalf of Bank B so it will populate field 12 with its LEI and will populate field 57 with the algo or national ID of the person responsible for the investment decision within the firm. * b) Bank A and Bank B are acting in any other trading capacity and Bank B is not meeting the conditions for transmission under article 4 of the Commission Delegated Regulation (EU) 2017/590. | N | Field | Bank A's report | Bank B's report | | -- | ------------------------------------ | ------------------- | ---------------------- | | 3 | TVTIC | '1234' | | | 4 | Executing entity identification code | {LEI} of Bank A | {LEI} of Bank B | | 7 | Buyer | {LEI} Firm Z | 'DE19740401MAX##MUSTE' | | 12 | Buyer decision maker code | | {LEI} of Firm Z | | 16 | Seller | {LEI}CCP | {LEI} of Firm Z | | 21 | Seller decision maker code | | | | 29 | Capacity | 'AOTC' | 'AOTC' | | 36 | Venue | {MIC} of TV | 'XOFF' | | 57 | Investment decision within firm | | | | 59 | Execution within firm | Algo or national ID | 'NORE' | Since the buyer in Bank B's report is its client and there is a power of representation field 12 is populated with the LEI of Firm Z in Bank B's report. Since the execution decision is made outside the firm (being made by Firm Z) field 59 is populated with 'NORE' in Bank B's report. ## Questions 8 \[Last update: 14/11/2017] Q\&A 1708 * (a) What are the reporting obligations for a typical primary issuance (IPO)? * (b) How should field 28 (Trading date time) be populated in this scenario? * (c) How should field 59 (Execution within the firm) be populated in this scenario? * (d) What would transaction reporting look like for a typical equity IPO example? ## Answers 8 * (a) Primary issuance occurs through a group of banks that form a syndicate. This is shown in the example below where Banks A, B and C form a syndicate. One client may receive calls from a number of syndicate banks to introduce the new issue and the client will in turn indicate their interest to buy the financial instrument being marketed through each of those banks. A single order book is maintained across the syndicate which results in a single allocation of the financial instrument to the client. A 'coordinating bank' will buy from the issuer/seller and sell to another bank or banks in the syndicate that act as the 'billing and delivering bank(s)' (B\&D-bank). A B\&D-bank will then sell to the client. A 'coordinating bank' may also perform the role of a B\&D-bank. The example below shows two situations, one where Bank A is acting as a 'coordinating bank' and Banks B and C are acting as the B\&D-bank and one where Bank A is acting as both the 'coordinating bank' and B\&D bank. In this example Banks A, B and C are all investment firms acting in an own account trading capacity but it is also possible for these banks to act in any other capacity. The executions that take place are indicated by legs no. 1, 2, 3 and 4. The direction of the arrows indicates the direction of flow of the financial instruments. All of the execution legs that are applicable to the situation are reportable. So if Bank A is the 'coordinating bank' and Banks B and C are the B\&D-banks then legs 1, 2 and 3 are reportable. If Bank A is both the 'coordinating bank' and the B\&D-bank then legs 1 and 4 are reportable. If the issuer or the client are investment firms they will have to transaction report as well as Banks A, B and C. Settlement activity should not be reported. If there are additional investment firms involved in the chain that are executing then they will also need to transaction report. * (b) This should be the date time at which the pricing and the allocations are finalised between the issuer and the syndicate. This is normally before the first listing date. * (c) Where a client is making a decision for a primary issuance, then the activity by an investment firm to action that decision is just an administrative function as the investment firm has no discretion on how to exercise and therefore field 59 should be populated with 'NORE'. Where the investment firm is making the decision under a discretionary mandate it should be populated with a person or algorithm within the investment firm. * (d) Issuing Company Z plans a primary issuance of 400 units of equity and engages a syndicate involving Investment Firm X and Investment Firm Y to run a book build on its behalf. Investment Firms X and Y are acting as B\&D-banks responsible for recording the transactions in their books and records, confirming the purchase to the client and selling the units to the clients. Investment Firm Y is also acting as a 'coordinating bank'. Client A and B have placed subscription orders for 200 units and 100 units respectively with Investment Firm X. Client C has placed subscription orders for 100 units with Investment Firm Y. Investment Firm Y will buy from the issuer/seller and sell to Client C and to Investment Firm X. The request for admission takes place on 26-06-2018 and the listing date is 27-06-2018. The transaction price of 99 for a unit is agreed between the syndicate and the issuer and the pricing and allocations are finalised between Issuing Company Z and the syndicate on 26-062018 at 19:00:00. Assuming for the purposes of this example that Investment Firms X and Y are dealing on own account, the reports that need to be made by X and Y are indicated by Reports no. 1 - 6 in the figure below. The direction of the arrows indicates the direction of flow of the financial instruments. Settlement activity should not be reported. ## How would Investment Firm X report? | N | Field | Report 1 Values | Report 2 Values | Report 3 Values | | -- | ------------------------------------ | -------------------------- | -------------------------- | -------------------------- | | 4 | Executing entity identification code | {LEI} of Investment Firm X | {LEI} of Investment Firm X | {LEI} of Investment Firm X | | 7 | Buyer identification code | {LEI} of Investment Firm X | {LEI} of ClientA | {LEI} of Client B | | 16 | Seller identification code | {LEI} of Investment Firm Y | {LEI} of Investment Firm X | {LEI} of Investment Firm X | | 28 | Trading date time | '2018-06- 26T19:00:00Z' | ,2018-06- 26T19:00:00Z' | ,2018-06-26T19:00:00Z' | | 29 | Trading capacity | 'DEAL' | 'DEAL' | 'DEAL' | | 30 | Quantity | '300' | '200' | '100' | | 33 | Price | '99' | '99' | '99' | | 36 | Venue | 'XOFF' | 'XOFF' | 'XOFF' | | 59 | Execution within the firm | 'NORE' | 'NORE' | 'NORE' | ## How would Investment Firm Y report? | N | Field | Report 4 Values | Report 5 Values | Report 6 Values | | -- | ------------------------------------ | -------------------------- | -------------------------- | -------------------------- | | 4 | Executing entity identification code | {LEI} of Investment Firm Y | {LEI} of Investment Firm Y | {LEI} of Investment Firm Y | | 7 | Buyer identification code | {LEI} of Investment Firm Y | {LEI} of Investment Firm X | {LEI} of Client C | | 16 | Seller identification code | {LEI} of Issuing Company Z | {LEI} of Investment Firm Y | {LEI} of Investment Firm Y | | 28 | Trading date time | '2018-06- 26T19:00:00Z' | '2018-06- 26T19:00:00Z' | '2018-06- 26T19:00:00Z' | | -- | ------------------------- | ----------------------- | ----------------------- | ----------------------- | | 29 | Trading capacity | 'DEAL' | 'DEAL' | 'DEAL' | | 30 | Quantity | '400' | '300' | '100' | | 33 | Price | '99' | '99' | '99' | | 36 | Venue | 'XOFF' | 'XOFF' | 'XOFF' | | 59 | Execution within the firm | 'NORE' | 'NORE' | 'NORE' | If Issuing Company Z or Clients A, B or C are investment firms they will also need to transaction report. ## Questions 9 \[Last update: 14/11/2017] Q\&A 1709 * (a) When are corporate events reportable? * (b) Are corporate events resulting from a default option reportable? * (c) Is an event still reportable where the investor has given a standing instruction? * (d) What is meant by the investor not making an investment decision at the point in time of the creation, expiration or redemption of the financial instrument in article 2(5)(i) of Commission Delegated Regulation (EU) 2017/590? * (e) Are lapsed rights reportable? * (f) How should corporate events be reported? * (g) How should field 59 (Execution within the firm) be populated for corporate events? ## Answers 9 * (a) Corporate events are reportable where the investor has an opportunity to make an investment decision if the event does not come within one of the exclusions under article 2(5) of Commission Delegated Regulation (EU) 2017/590. In practice, because many corporate actions are effected through the mandatory issue of an intermediary instrument this brings them within the exclusions because the issue is mandatory and therefore not reportable under 2(5)(i) and the exercise of the intermediary instrument is excluded under 2(5)(h). * (b) Yes. This is regardless of whether the default option is actively selected or results from no action. This is because the investor may have taken no action in the knowledge that they would receive the default option. Therefore they are regarded as effectively taking an investment decision. * (c) Yes, where the investor has an opportunity to make an investment decision. This is because the investor had the opportunity to change their mind and revoke the instruction and may have chosen not to do so. Therefore they are regarded as effectively taking an investment decision. * (d) This should be interpreted as the investor (or someone acting for them under a power of representation) not making an investment decision at the point in time when they could have made an investment decision for a particular corporate event. Thus it refers to the point of time of the initiation of the creation, expiration or redemption rather than the time of its completion. Consequently, if the investor did take a decision to initiate the creation, expiration or redemption or could have taken such a decision but received a default option or could have taken a decision despite a standing instruction being in place it does not come within the exclusion under article 2(5)(i) and the action is reportable unless it comes under one of the other exclusions in article 2(5). * (e) No. This is considered to be within the exclusion in Article 2(5)(h) of Commission Delegated Regulation (EU) 2017/590. * (f) The transactions resulting from the event should be reported. Where an investment firm, Firm A, is giving instructions to take up an event on behalf of itself or a client it should report the party initiating the event if it is executing with that entity directly or the intermediary it is executing with an intermediary. For example, consider a corporate event where an investor makes a choice of receiving cash or additional financial instruments without there being an intermediate financial instrument and receives the financial instruments. Assuming that Firm A is acting in an 'any other' trading capacity and is executing directly with the issuer, Firm A will report the buyer as the client and populate the seller field with the LEI of the issuer. If the client is also an investment firm, the client will report Investment Firm A as the seller and if the issuer is also an investment firm the issuer will report Investment Firm A as the buyer. If Firm A is executing with an intermediary Firm A will report the intermediary. Where payment is made the price should reflect this. If there is no payment then the price field should be populated with 'NOAP'. If there is a pending price it should be reported as 'PNDG' and updated when the price is known. The trading date and time would be the date and time that the corporate action was completed by the entity initiating the event, so in the example above the date time in the confirmation of the transaction by the issuer. * (g) Where a client is making a decision for a corporate event, then the activity by an investment firm to action that decision is just an administrative function as the investment firm has no discretion on how to exercise and therefore field 59 should be populated with 'NORE'. Where the investment firm is making the decision under a discretionary mandate it should be populated with a person or algorithm within the investment firm. ## Question 10 \[Last update: 14/11/2017] Q\&A 1710 ## Are both legs of a swap reportable, when one leg contains an index such as LIBOR or EURIBOR? ## Answer 1 In the case of a swap, where one leg contains e.g. LIBOR or EURIBOR, it is key for competent authorities to have visibility of both legs of the reported swap. Therefore in transaction reports for an OTC swap, where one leg of a swap contains at least one reportable financial instrument, also the complementing leg of the given swap containing indices, such as LIBOR or EURIBOR, should be identified in a transaction report, as shown in Example 106 in section 5.35.7.1 of the ESMA Guidelines. ## Question 11 \[Last update: 14/12/2017] Q\&A 1711 * (a) Where there is more than one level of underlying instrument which should be considered when determining whether an instrument is in scope for reporting under article 26(2)(b) and (c) of MIFIR? * (b) Does the concept of an underlying for the purposes of Article 26(2)(b) or (c) of MiFIR extend to investments in a collective investment undertaking or an exchange traded fund? * (c) What is the implication of Answer (b)? * (d) Does the concept of underlying extend to the instruments on which ADRs, GDRs are based for the purposes of Article 26(2)(b) of MIFIR ? * (e) What is the implication of Answer (d)? * (f) Does the concept of an underlying for the purposes of Article 26(2)(b) of MiFIR extend to convertible bonds, reverse convertible bonds and reverse convertible notes? * (g) What is the implication of Answer (f)? * (h) Does the concept of an underlying for the purposes of Article 26(2)(b) or (c) of MiFIR extend to warrants? * (i) What are the implications of Answer (h)? ## Answers 11 * (a) The underlying is the direct or immediate underlying for the instrument rather than any ultimate underlying. For example, consider a CFD on an option on an equity. The immediate underlying is the option. Therefore, if the option is traded on a trading venue then the CFD is a reportable instrument under article 26(2)(b) and if the option is not traded on a trading venue then the CFD is not a reportable instrument under article 26(2)(b). This is regardless of whether the equity that is the ultimate underlying is traded on a trading venue. * (b) No, the concept of underlying does not extend to such situations. * (c) Transactions in a unit of a collective investment undertaking or an exchange traded fund are only reportable if the unit of a collective investment undertaking or the exchange traded fund is itself admitted to trading or traded on a trading venue or a request for admission has been made. * (d) Yes. * (e) Where a transaction takes place in an ADR, GDR (the main instrument) where the underlying instrument on which the main instrument is based is traded on a trading venue the transaction is reportable under article 26(2)(b). Where a transaction report is made on the basis of the instrument being in scope of 26(2)(b) the underlying instrument on which the main instrument is based should be reported in field 47 (Underlying instrument code). Where the main instrument is also in scope under 26(2)(a) then the underlying does not need to be populated in the transaction report as only the ISIN of the main instrument needs to be reported (in field 41). * (f) Yes. * (g) Where a transaction takes place in a convertible bond, reverse convertible bond or reverse convertible note (the main instrument) and the instrument into which the bond can be converted is traded on a trading venue the transaction is reportable under article 26(2)(b). Where a transaction report is made on the basis of the instrument being in scope of 26(2)(b) the underlying instrument into which the main instrument can be converted should be reported in field 47. Where the convertible bond, reverse convertible bond or reverse convertible note is also in scope under 26(2)(a) then the underlying does not need to be populated in the transaction report as only the ISIN of the convertible bond needs to be reported (in field 41). * (h) Yes. * (i) Where a transaction takes place in a warrant and the instrument on which the warrant is based is traded on a trading venue the transaction is reportable under article 26(2)(b). Where the warrant is based on an index or a basket composed of financial instruments traded on a trading venue the transaction is reportable under 26(2)(c). Where the warrant is also in scope of Article 26(2)(a) then the underlying does not need to be populated in the transaction report as only the ISIN of the warrant needs to be reported (in field 41). ## Question 12 \[Last update: 14/12/2017] Q\&A 1712 ## Are transactions executed through non-EU branches of EU investment firms subject to transaction reporting under Article 26 of MiFIR? ## Answer 12 Yes, transactions executed through non-EU branches of EU investment firms are subject to transaction reporting under Article 26 of MiFIR since a branch has no legal personality and is part of the investment firm according to Article 4(1)(30) of MIFID II. This requirement applies to transactions executed in financial instruments specified in Article 26(2) of MiFIR. The transaction reports should be sent to the competent authority of the home Member State of the investment firm following Article 14 of the RTS 22 and the branch should be identified with the LEI of its head office even if it may be considered eligible for an LEI in some cases (see first paragraph, point 5.5 of the ESMA Guidelines on Transaction Reporting). ## Question 13 \[Last update: 28/09/2020] Q\&A 1511 Consider a scenario where an Investment Firm A executes a reportable transaction through an execution algorithm provided by another Investment Firm B 59 . * a) How should field[^11] (Execution within firm) of RTS 22 be reported when Investment Firm A uses the execution algorithm provided by Investment Firm B? * b) Would Investment Firm A's reporting differ if Firm B was not a MiFID II Investment Firm and therefore did not have the obligation to report this transaction under Art. 26 MiFIR? * c) Where Investment Firm B is using Investment Firm A's membership to access the market, is Investment Firm B executing the transaction and does Investment Firm B have to transaction report? ## Answer 13 * a) The reporting obligations are the same as where Investment Firm A decides to send an order for execution to Investment Firm B. Investment Firm A should populate field 59 with the person or algorithm identifier within their firm that is primarily responsible for using Investment Firm B's algorithm. Investment Firm A shall not populate a code for Investment Firm B's algo, only its own information. The scenario is: IF A → IF B (algorithm) → CCP (Trading Venue or Investment Firm) Assuming that Investment Firm A is buying an instrument and dealing on own account trading capacity, and Investment Firm B is acting in 'any other' trading capacity, the respective reports should be completed as follows: | N | Field | Investment Firm A's report | Investment Firm B's report | | -- | ------------------------------------ | ----------------------------------------------------------------- | ------------------------------------------------ | | 4 | Executing entity identification code | {LEI} of Investment Firm A | {LEI} of Investment Firm B | | 7 | Buyer identification code | {LEI} of Investment Firm A | {LEI} of Investment Firm A | | 16 | Seller identification code | {LEI} of Investment Firm B | {LEI} of CCP | | 29 | Trading capacity | 'DEAL' | 'AOTC' | | 59 | Execution within firm | Natural person's ID or code of algorithm within Investment Firm A | Code for Investment Firm B's execution algorithm | * b) No. Investment Firm A's reporting is the same as specified in a). * c) Yes. Investment Firm B is conducting the activity of executing a client order according to Art. 3 of RTS 22. The scenario is: IF A → IF B (algorithm) → IF A (membership) → CCP (Trading Venue) Assuming that both Investment Firm A is buying an instrument and dealing on own account, and the subsequent steps in Investment Firm B and A are in 'any other' trading capacity, the respective reports should be completed as follows: | N | Field | IF A's report 1 | IF B's report | IF A's report 2 | | -- | ------------------------------------ | ----------------------------------------------------------------- | ------------------------------------------------ | -------------------------- | | 4 | Executing entity identification code | {LEI} of Investment Firm A | {LEI} of Investment Firm B | {LEI} of Investment Firm A | | 7 | Buyer identification code | {LEI} of Investment Firm A | {LEI} of Investment Firm A | {LEI} of Investment Firm B | | 16 | Seller identification code | {LEI} of Investment Firm B | {LEI} of Investment Firm A | {LEI} of CCP | | 29 | Trading capacity | 'DEAL' | 'AOTC' | 'AOTC' | | 59 | Execution within firm | Natural person's ID or code of algorithm within Investment Firm A | Code for Investment Firm B's execution algorithm | 'NORE' | In order to match Investment Firm B's reports and reflect its involvement in more than one part of 'the chain', Investment Firm A has to submit two reports: * one for its trade as a client with Investment Firm B (Report 1). * one for its market-side trade with the Central Counterparty or another Investment Firm (Report 2). \*new Question 14 Q\&A 632 What ISO 3166-1 country code should trading venues and investment firms use to identify stateless natural persons for the purposes of transaction reports? ## Answer 14 When identifying stateless natural persons, trading venues and investment firms should use the ISO 3166 code 'ZZ', followed by a CONCAT code generated in accordance with Article 6(4) of Commission Delegated Regulation (EU) 2017/590 (RTS22). ## 25 Order Record Keeping \[Last update: 07/07/2017] ## Question 1 Q\&A 1713 Are actionable indications of interest subject to the order record keeping requirements for Investment Firms and trading venues under Article 25(1) and (2) of MiFIR? ## Answer 1 Yes. An 'actionable indication of interest' is defined in Article 2(1)(33) of MiFIR as 'a message from one member or participant to another within a trading system in relation to available trading interest that contains all necessary information to agree on a trade'. Actionable indications of interest are subject to pre-trade transparency requirements under Articles 3(1) and 8(1) of MiFIR, along with current bid and offer prices and the depth of trading interests at those prices. To ensure that relevant and sufficient data is kept at the disposal of competent authorities, paragraphs 1 and 2 of Article 25 of MiFIR set out the obligation on investment firms and trading venues to maintain records of, amongst others, the relevant data relating to these orders, including actionable indications of interest. [^1]: Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU. [^2]: Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) N0 648/2012. [^3]: Commission Delegated Regulation (EU) 2016/1437 of 19 May 2016 supplementing Directive 2004/109/EC of the European Parliament and of the Council with regard to regulatory technical standards on access to regulatory information at Union level 15 [^4]: Commission Delegated Directive of 7.4.2016 supplementing Directive 2014/65/EU of the European Parliament and of the Council with regard to safeguarding of financial instruments and funds belonging to clients, product governance obligations and the rules applicable to the provision or reception of fees, commissions or any monetary or non-monetary benefits. The Commission Delegated Directive was published on 7 April 2016 and no objection has been expressed by the European Parliament or the Council on the MiFID II Delegate Directive and Delegated Regulation within the period set in Article 89 of MiFID II. [^5]: Commission Delegated Regulation of 18.5.2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to definitions, transparency, portfolio compression and supervisory measures on product intervention and positions. The Commission Delegated Regulation was published on 18 May 2016 and no objection has been expressed by the European Parliament or the Council on the MiFID II Delegate Directive and Delegated Regulation within the period set in Article 50 of MiFIR. [^6]: Commission Delegated Regulation (EU) 2016/909 of 1 March 2016 supplementing Regulation (EU) No 596/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the content of notifications to be submitted to competent authorities and the compilation, publication and maintenance of the list of notifications [^7]: Please note that, for ease of reference, RTS have been numbered in this document in accordance with the numbering used in the package sent by ESMA to the Commission in September 2015 (ESMA/2015/1464). Readers are nevertheless invited to consult the Commission and European Parliament websites for updated versions of those RTS. [^8]: COMMISSION DELEGATED REGULATION (EU) 2017/590 with regard to regulatory technical standards for the reporting of transactions to CAs. Available at the following link [^9]: COMMISSION DELEGATED REGULATION (EU) 2017/585 with regard to regulatory technical standards for the data standards and formats for financial instrument reference data. Available at the following link [^10]: MIC code-field 36 = 'XXXX'. These are all derivatives falling under MiFIR Article 26(2)(b) and (c). [^11]: It is assumed in the examples that (Investment) Firm B is executing and retaining control of the execution. If Firm B would only be acting by e.g. providing technology to Investment Firm A, and not be executing and retaining any control, Firm B would not transaction report. In such case Investment Firm A should report the direct market execution, not identify B as a counterparty, and identify the algorithm they (Firm A) have used (even if it was provided to them by Firm B. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.mica.wtf/eu-level/q-and-a/esma-qa-70-1861941480-56-mifir-data-reporting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.