23 June 2025
ESMA12-2121844265-384

ESMA
European Securities and Markets Authority

Final Report

On RTS 23 on supply of reference data under Art.27

Acronyms

APA	Approved Publication Arrangement
BMR	Regulation (EU) 2016/1011 of the European Parliament and of the Council of 8 June 2016 on indices used as benchmarks in financial instruments and financial contracts or to measure the performance of investment funds and amending Directives 2008/48/EC and 2014/17/EU and Regulation (EU) No 596/2014
CDS	Credit Default Swaps
CFI	Classification of Financial Instruments
CP	Consultation Paper
CSDR	Central Securities Depositories Regulation
CSDR	Refit Regulation (EU) 2023/2845
DPE	Designated Publishing Entity
DTI	Digital Token Identifier
EEA	European Economic Area
EU	European Union
EMIR	Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties, and trade repositories
ESAP	Regulation (EU) 2023/2859 of the European Parliament and of the Council of 13 December 2023 establishing a European single access point providing centralised access to publicly available information of relevance to financial services, capital markets and sustainability
ESMA	European Securities and Markets Authority
FIGI	Financial Instrument Global Identifier
FIRDS	Financial Instruments Reference Data System

FITRS
Financial Instruments Transparency System
ISIN
International Securities Identification Numbering LEI Legal Entity Identifier MIC Market Identifier Code MiFIR Review Regulation (EU) 2024/791 of the European Parliament and of the Council of 28 February 2024 amending Regulation (EU) No 600/2014 as regards enhancing data transparency, removing obstacles to the emergence of consolidated tapes, optimising the trading obligations, and prohibiting receiving payment for order flow MiFIR Regulation (EU) No 600/2014 of the European Parliament and of Council 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/20123 MTF Multilateral Trading Facility NCAs National Competent Authorities OTC Over-The-Counter OTF Organised Trading Facility REMIT Regulation on Wholesale Energy Market Integrity and Transparency RTS Regulatory Technical Standard RTS 1 Commission Delegated Regulation (EU) 2017/587 RTS 23 Commission Delegated Regulation (EU) 2017/585 RTS 3 Commission Delegated Regulation (EU) 2017/577 SFTR Regulation (EU) 2015/2365 of the European Parliament and of the Council of 25 November 2015 on transparency of securities financing transactions and of reuse and amending Regulation (EU) No 648/2012 TOTV Instruments Traded On a Trading Venue TRS Total Return Swaps

ESMA European Securities and Markets Authority

TV
Trading Venue uTOTV
Instruments (Derivatives) whose Underlying is Traded on a Trading Venue

1 Executive Summary ....................................................................................................6

2 Context and objective of this publication......................................................................7

3 Feedback statement on the proposals of amending RTS 23 .......................................9

3.1 Adapting reference data for the use for transparency requirements .....................9

1. Reporting frequency.............................................................................................9

2. Additional data elements to be transposed from RTS 1 and 2 ............................11

3.2 New OTC derivative identifier.............................................................................21

3.3 Date by which reference data are to be reported................................................22

2. Approach to assessing the consistency with EMIR/SFTR and ensuring the use of relevant international standards.................................................................................24

3. Changes to the reportable details.......................................................................25

3.4 Adapting reference data for the use for publications under CSDR......................29

1. General approach ..............................................................................................29

2. Additional information concerning instruments published pursuant to CSDR......31

3.5 Other enhancements..........................................................................................33

1. New fields to be included....................................................................................33

2. Fields to be amended.........................................................................................37

3. Fields to be removed..........................................................................................39

3.6 Format for reporting............................................................................................40

1. Background........................................................................................................40

2. Feedback statement Q70 ...................................................................................41

3.7 Reporting by DPEs.............................................................................................42

1. Background........................................................................................................42

2. Feedback statement Q71-Q72 ...........................................................................42

3.8 Scope of reference data to be reported ..............................................................44

1. Background........................................................................................................44

2. Feedback statement Q73 ...................................................................................45

4 Conclusions...............................................................................................................45

1 Executive Summary

Reasons for publication

The revised texts of MIFIR and MiFID II were published in the Official Journal of the EU on 8 March 2024. ESMA has been empowered to develop various technical standards further specifying certain requirements. ESMA launched a public consultation on May 20241 which included proposals for the amendment of the Regulatory Technical Standard specifying the requirements on reference data under Art.27 of MiFIR (RTS 23).

Following the feedback received, with the objective to reduce burden to market participants, ESMA decided to not propose any changes to the existing RTS 23 at this stage and focus on a more comprehensive review of regulatory reporting, as further clarified in the Call for Evidence2 that is published at the same time of this Final Report (FR).

This FR provides a summary of the feedback to the consultation.

The first section of the Final Report (Section 2) explains the content of the document and the rationale for not proposing amendments to the current text of the RTS 23.

The other sections of the FR summarise the feedback received on the following topics: adaptation of reference data for the transparency requirements (Section 3.1); new OTC derivative identifier (Section 3.2); date by which the data are to be reported (Section 3.3), alignment with the EMIR and SFTR reporting requirements and international standards (Section 3.4); changes for the use for publications under CSDR (Section 3.5); other enhancements to the list of fields to be reported (Section 3.6); format for reporting (Section 3.7); reporting of DPEs (Section 3.8) and the scope of the reporting (Section 3.9).

Next Steps

This FR does not include proposed changes to the existing RTS 23. The feedback received to the consultation and summarised in the FR will serve as valuable input in the context of the comprehensive review.

ESMA
European Securities and Markets Authority

2 Context and objective of this publication

1. The revised texts of MIFIR and MiFID II were published in the Official Journal of the EU on 8 March 2024. ESMA was empowered to develop various technical standards further specifying certain requirements. ESMA launched a Consultation in May 20243 which included proposals for the amendment of the L2 provisions specifying the requirements on reference data under Art. 27 of MiFIR (RTS 23).

2. Since the publication of the consultation, there has been at EU level an increased focus on burden reduction and simplification. The European Commission set the goal of reducing reporting burden by 25% for all companies and by 35% for SMEs4 . In line with this goal, the EC set out a vision for an implementation and simplification agenda aimed at reducing the regulatory load for people, business and administrations in the EU5 .

3. When it comes to the regulatory requirements on financial transaction reporting, EU legislation includes three key reporting frameworks for financial markets: Markets in Financial Instruments Regulation (MiFIR6 ) for transactions in financial instruments, European Market Infrastructure Regulation (EMIR7 ) for derivatives transactions, and Securities Financing Transactions Regulation (SFTR8 ).

4. These legal frameworks were developed in the aftermath of the 2008 financial crisis. As such, each serves a specific purpose, and their implementation followed different timelines. However, taken together, and despite the efforts to avoid it, the resulting requirements impose significant costs on reporting entities, including inconsistent and duplicative reporting.

[1] https://www.esma.europa.eu/sites/default/files/2024-05/ESMA74-2134169708-7241_CP_Package_on_the_MiFIR_Review_- _RTS_2__RCB_and_Reference_Data.pdf

[2] ESMA12-437499640-3021 Call for Evidence on a comprehensive approach for the simplification of financial transaction reporting.

[3] https://www.esma.europa.eu/sites/default/files/2024-05/ESMA74-2134169708-7241_CP_Package_on_the_MiFIR_Review_- _RTS_2__RCB_and_Reference_Data.pdf

[4] A Competitiveness Compass for the EU

[5] As stated in its communication of 11 February 2025 entitled ‘A simpler and faster Europe: Communication on implementation and simplification’

[6] Regulation (EU) No 600/2014

[7] Regulation (EU) No 648/2012

[8] Regulation (EU) 2015/2365

5. Based on feedback received from market participants during the reviews of the L2 reporting technical standards related to these reporting frameworks, including RTS 23, ESMA concluded that the significant burden stemming from these reporting obligations originates from the siloed sectorial approach in the respective L1 frameworks, which led to overlaps and misalignments. While ESMA, during the Level 2 work, strived to ensure the best possible alignment of reporting obligations across all the regimes, and despite the efforts to avoid it, the issues related to duplicative obligations and inefficient processes stemming from the siloed approach to rulemaking could not be addressed.

6. Additionally, in line with the EC supervisory data strategy9 , the co-legislators in the latest review of MiFIR, gave a mandate10 to ESMA to assess the feasibility of more integration in transaction reporting and streamlining of data flows to reduce duplicative or inconsistent requirements for transaction data reporting in particular between MiFIR, EMIR and SFTR frameworks by March 2028. While the deadline for such a report is not imminent, ESMA in coordination with the Commission Services, considers that this is the right time to advance this assessment and look at the reporting frameworks in a more comprehensive manner, with a view to identifying options to achieve simplification and burden reduction and avoiding continued implementation cost due to the ongoing sectorial reviews while proceeding with this reform.

7. A Call for Evidence (CfE)11 is being launched in parallel to the publication of this Final Report to consult relevant stakeholders and gather feedback on opportunities to integrate, streamline and simplify with a view to reduce the burden associated with complying with financial regulatory reporting requirements without compromising the robustness of supervisory oversight. It seeks input from stakeholders to identify major cost drivers and collect views on how best to work towards a comprehensive review for the simplification of financial transaction reporting.

8. Based on the above considerations and the decision to focus on a comprehensive approach addressing the current limitations rather than implementing Level 2 changes, this Final Report does not include proposed changes to the existing RTS 23 nor includes a draft RTS for submission to the European Commission. The Final Report includes a summary of the responses received to the Consultation. Given the

[9] Strategy on supervisory data in EU financial services - European Commission COM(2021) 798 final

[10] This mandate is included in Article 26(11) of MiFIR.Review.

[11] ESMA12-437499640-3021 Call for Evidence on a comprehensive approach for the simplification of financial transaction reporting.

interconnected nature12 of RTS 23 and RTS 22 the same approach has been applied to the review of RTS 23 as done for RTS 22 and RTS 24. Please refer to the relevant Final Report for specific considerations on RTS 22 and RTS 2413 .

9. Finally, it is important to explain how the regime will work on the basis of the current RTS 23. In this respect, ESMA issued public statement14 in March 2024. This statement builds on the EC interpretative notice15 and clarifies that until the revised RTS becomes applicable, the Level 1 rules in force prior to the MiFIR review—together with RTS 23— will continue to apply.

3 Feedback statement on the proposals of amending RTS 23

3.1 Adapting reference data for the use for transparency requirements

1. Reporting frequency

3.1.1.1 Background

10. The reporting frequency of reference data for the purposes of transaction reporting is defined in Articles 2 and 7 of RTS 23, which prescribe, respectively, that trading venues shall report them at the end of each trading day.

11. As it concerns transparency reference data, Article 3 of Commission Delegated Regulation (EU) 2017/577 (hereinafter RTS 3) provides for daily reporting from Trading Venues (TVs), Approved Publication Arrangements (APAs) and Consolidated Tape

[12] When reference data is reported under RTS 23 and published in FIRDS, Investment Firms can link the instrument details in RTS 22 transaction reports using only the ISIN, without duplicating the instrument attributes already reported under RTS 23. For efficiency, if a financial instrument is reported under RTS 23 (and the relevant ISIN is included in field 41 of the RTS 22 report), and its reference data is available in FIRDS, it is not necessary to report the instrument characteristics again in the transaction report.

[13] ESMA12-2121844265-4779 Final Report on transaction data reporting under Art. 26 and RTS 24 on order book data to be maintained under Art. 25 of MiFIR.

[14] ESMA74-2134169708-7163 Public Statement on the transition for the application of the MiFID II/MiFIR review https://www.esma.europa.eu/sites/default/files/2024-03/ESMA74-2134169708-7163_Public_statement_on_specific_revised_MiFIR_provisions.pdf

[15] https://finance.ec.europa.eu/news/commission-publishes-draft-interpretative-notice-transitional-provision-mifir-review-2024-03-27_en

Providers (CTPs) of the quantitative data, whereas the reference data is reported with a different frequency defined separately for equity and non-equity instruments.

12. Given the consolidation of the reference data reporting under RTS 23, ESMA proposed to define, under the revised RTS 23, a common daily reporting frequency applicable to all reference data as well as to amend the relevant provisions in the RTS 23 on methods and arrangements, which refer to the timeline for provision, exchange and publication of reference data to reflect the direct reporting of reference data to ESMA.

3.1.1.2 Feedback statement Q51

Q51: Do you agree with the proposal for a daily reporting of reference data for both transaction reporting and transparency purposes?

13. Twenty-three respondents provided input to this question. All supported the alignment of the reporting frequency of reference data for transaction reporting and transparency purposes as well as setting the frequency to daily, in line with the current reporting under the RTS 23.

14. The respondents considered this to be a sensible approach and flagged the following:

This frequency is already in place for both transaction and transparency reporting for bonds.
The streamlined reporting under a common frequency will facilitate more accurate and complete reporting, thus improving the efficiency of reporting.
It is expected that this change will lead to a decrease in rejections caused by inconsistencies between RTS 23 and RTS 2 reporting, which currently occur also due to the mismatch in the timing of provision of the reference data under each RTS.
It will provide market participants with a unique and consolidated source of reference data.
Daily reporting of reference data for both transaction reporting and transparency purposes is consistent with the US FINRA TRACE daily reporting requirement.

15. Several respondents made also some additional comments related to the frequency or timing of the submitted reports. For instance, two respondents stated that reference data is required to determine whether a transaction report is required pursuant to Art. 26 of MiFIR, therefore the reference data must be reported timely.

16. One respondent suggested to consider more dynamic / real-time updates in the long term as the technologies evolve.

17. Two respondents suggested that in the future RTS 23 data should be integrated into ESAP. The respondent noted that ESAP will provide users with a single API and could eventually evolve into a key information source for the EEA capital markets. In this regard, ESMA highlights that ESAP L1 text already sets out that the reference data reported under Art. 27 of MiFIR shall be made accessible on ESAP starting from January 2030.

18. One respondent asked for confirmation whether the proposal is for all reference data in the current RTS 1, RTS 2, RTS 3 and RTS 23 to be sent under RTS 23 on a daily basis. ESMA confirms that this is indeed the case, and that the proposal was intended to apply to all reference data.

19. One respondent requested sufficient implementation time, exceeding 12 months.

20. Two respondents suggested that stricter rules should apply to the trading venues and that they should report the reference data on the day before the instrument is admitted to trading. ESMA notes that such a proposal would require a broader consultation and notes that the experience gained with reference data reporting under the current RTS 23 has not evidenced a need for the reporting of reference data ahead of the admission to trading. This is notwithstanding the fact that the reference data are also expected to be reported when ‘a request for admission has been made’ (Art.27(1) of MiFIR Review).

2. Additional data elements to be transposed from RTS 1 and 2

3.1.2.1 Background

21. The original MiFIR framework mandated ESMA to separately define reference data for the purposes of transaction reporting (Article 27(3), RTS 23) and for the purposes of transparency calculations (Article 22(3), RTS 1 and 2). The revised text of Article 27(1) provided that reference data reported pursuant to that Article shall be used for both transaction reporting and transparency disclosures.

22. ESMA considered that the most efficient way for reflecting this change in the implementing legislation was by adapting the reference data elements defined in RTS 23 to the new use case of supporting the transparency calculations. This solution would allow to streamline the reporting of all relevant reference data in one consistent submission of information and would result in a burden reduction of the overall number of reference data fields.

23. In the Consultation Paper (CP) ESMA assessed potential practical issues that may limit the extent to which such alignment can be achieved and made a number of proposals on which feedback was solicited.

3.1.2.2 Feedback statement Q52 -Q59

Q52: For the purposes of both equity and non-equity transparency, do you prefer to retain the MiFIR identifier as currently defined or to rely on other fields for classification purposes? If latter, please outline the proposed solution.

24. The majority of respondents either expressed preference for retaining the MiFIR identifier or did not object. Some of those respondents that did not object also suggested that the MiFIR identifier could be consistently retained alongside the CFI code or suggested some modifications to improve the MiFIR identifier mapping. Among the arguments in support of retaining the MiFIR identifier, respondents mentioned its broad use as it is deeply embedded in market’s practices to classify instruments and underlyings, in particular for equity and bonds, as it proved to be useful under the transparency regime.

25. Some respondents expressed a preference for the CFI code, mentioning that it provides better granularity comparing to the MiFIR identifier and that the standard is broadly used – both globally and across other EU legislative files. Furthermore, it is more interoperable. CFI’s fair access as well as its alignment, and the dependency with the ISIN across all asset classes were also mentioned.

26. Some of the respondents confirmed the existing classification in the mapping table mismatches between the MiFIR identifier and the CFI code which were also flagged in the CP. One respondent suggested, for that reason, to maintain the RTS 2 sub-asset for OTC derivatives. Another respondent stressed that the industry has undergone investments and the alignment between the two identifiers has gradually improved over the years, therefore the current system of mapping MiFIR identifiers to CFI code should be retained and the work should continue to improve further the alignment between the identifiers. Furthermore, it was also stressed that an improved mapping would decrease the entities’ reliance on other external data sources. In particular, it was suggested for ESMA to improve the mapping to MIFIR identifier for those instruments with CFI construct EY**** to distinguish when it is a derivative, securitised derivative, or ETC/ETN. This would the need to rely on different sources to capture the additional characteristics that are not available through the CFI code and minimise the erroneous classifications. Additionally, one respondent suggested enhancing the visibility and readability of the existing excel table mapping.

27. One respondent has flagged limitations in the MiFIR identifier with regards to the classification of the correct bonds type related to the lack of separation between the definition of type of issuer (e.g. Sovereign, Other public, Corporate) and type of payoff/security (e.g. Convertible, Covered). That respondent suggested that either the MiFIR identifier could be modified, or the CFI classification could be leveraged (requiring possibly some adjustments to the standard). Another respondent suggested to address the limitation in the CFI granularity for bonds by supporting the inclusion of the proposed new fields 13a and 13b (bond type and issuance date) of RTS 2 in the RTS 23 and using them in conjunction with the CFI.

28. A few respondents raised concerns about the potential increase of number of rejections and consistency validations if both CFI and MiFIR identifier are included in RTS 23. Those respondents stressed that rejection of the reference data submission would have more significant implications in validation rules than it was the case with the RTS 2 validations and admission to trading. They therefore suggested to implement in such cases reporting warnings instead of rejection messages to the submission of the MiFIR Identifier.

29. A few respondents also requested further clarity on which fields would be mandatory and which optional, flagging that e.g. MiFIR identifier should be optional for those instruments that are not under the scope of the transparency regime. ESMA notes that such aspects would be taken into account for the validation rules that further specified in L3 (technical documentation) rather than in the RTS itself.

30. Some respondents also stressed that the process to correct CFI codes by the NNA should be swifter. ESMA takes note of this comments and is aware that there is not a one-to-one relationship between the two codes, and in some cases mapping the MiFIR identifier can be problematic if the wrong CFI is allocated, and this may lead to data quality inconsistencies. However, such improvements are beyond the scope of this RTS’s review and should be further discussed in the implementation phase.

31. One respondent asked for confirmation that with the submission of reference data applying to both transparency and transaction reporting purposes, all reference data will be submitted to FIRDS only, and not into FITRS. ESMA confirms that this was indeed the proposal: to streamline all reference data into a single reporting flow and submission to one system, FIRDS.

32. Finally, one respondent noted that the description of the field ‘MiFIR identifier’ in the “Content to be reported” column of Table 3 in the Annex table excludes Derivatives although the code “DERV” is included in the “format and standard to be used for reporting” column. ESMA confirms that this was omission and that the value Derivatives was meant to be retained in the final version of the RTS 23.

Q53: Is in your view, the granularity level of the MiFIR identifier adequate for the purposes of MiFIR transparency in the equity and non-equity space? If not, how should it be adjusted?

33. The majority of respondents who replied to this question considered the granularity of the MiFIR identifier as adequate, in particular in respect to equity and cash bond instruments. Three respondents flagged that increasing the granularity could result in more issues regarding the alignment of classification. It has been highlighted that the issues of mapping the right MiFIR Identifier is due to the incorrect assignment of CFIs by the NNAs (e.g. cases for which NNAs do not allocate CFI codes, or the CFIs are incoherent with the relevant Prospectus or Final Terms, or CFIs are invalid ones or amended after the listing) leading to different trading venues reporting different CFI codes for the same instrument. This in turn results in the submission of incorrect CFIs to ESMA reference data. To minimise such data quality issues, respondents flagged the importance to improve the correction process established and applying strict timelines for NNAs. In line with the preferences expressed under the question 52, some of the respondents additionally reiterated their view on the choice between MiFIR identifier and the use of the CFI along with additional data fields.

34. One respondent flagged that additional specification of the "settlement location" (EIC code) is essential for the detailed calculation of the annual transparency results. ESMA did not deem it relevant to add any “additional specification” given that EIC code was included under ‘delivery point or zone’ field (new field 39b) for commodity derivatives. Going forward the transparency calculations will be performed only on equity and equity-like instruments; therefore the proposed addition was not considered relevant.

35. Further issues raised by respondents are generally covered in the feedback summarised above for the question 52.

Q54: How do you expect the change in scope of instruments subject to transparency to impact transparency reference data? Would you agree to maintain the current whole set of reference data for non-equity instruments, currently in RTS 2, in RTS 23? If not, please specify which reference data should not be retained in the view of the revised scope.

36. A slight majority of respondents broadly supported the move of all or most of the reference data for non-equity from the RTS 2 to the RTS 23 recognising the envisaged simplification of the reporting requirements to improve consistency and accuracy of data.

37. One respondent outlined that this would lead to a more focused and effective data reporting system that eliminates unnecessary data collection and processing. At the same time, several respondents flagged that it may not be necessary to incorporate certain transparency reference data fields into RTS 23 and that the decision should be made only once the full analysis on the transparency needs has been completed.

38. Two respondents flagged that the assessment of the data to be transposed needs to also take into account the content of the Delegated Act on OTC ISIN identifier of the European Commission.

39. One respondent flagged that the approach to transparency calculations for bonds has changed, therefore not all the fields related to bonds would need to be moved to RTS 23.

40. Two respondents flagged that it may be unnecessarily burdensome to require reporting of transparency reference data for the derivatives that are no longer in scope of transparency. Another respondent highlighted that the proposed incorporation of the current whole set of reference data for non-equity instruments, currently in RTS 2 (Annex IV) into RTS 23 should apply only to TVs and DRSPs and should not lead to imposing any additional data reporting obligations to DPEs that are not relevant.

41. ESMA acknowledges that the scope of reference data reporting pursuant to the revised Article 27 covers some derivatives that are not in scope of transparency. However, having divergent requirements depending on whether the derivative is subject to transparency regime or not would render the reporting more complex and prone to reporting issues. Furthermore, as explained in the CP, the set of reference data points for derivatives reported for transparency purposes is expected to be simplified. For that reason, ESMA would consider it more beneficial to introduce harmonised reporting requirements and fields for all derivatives in scope of Article 27.

42. One respondent raised concerns about misalignment of the concept of OTC derivative under EMIR and MiFIR. ESMA wished to highlight that the definition of OTC derivative in MiFIR Review text is aligned with EMIR16; furthermore, any potential changes to such definition would in any case be out of scope of review of this RTS.

[16] Article 2(32a) of Regulation (EU) 2024/791 ““OTC derivative” means an OTC derivative as defined in Article 2, point (7), of Regulation (EU) No 648/2012;’”

Q55: Do you agree with deleting Field 5 of RTS 2, Annex IV, and use the CFI code for the purposes of derivatives’ contract type classification?

43. Almost all those that responded to this question supported the removal of the field 5 ‘Contract type’17 that is reported for derivatives (MiFIR Identifier = “DERV”) from the list of reference data fields that should be transposed from RTS 2 into RTS 23 as the field is considered redundant. They agreed with relying on the CFI for retrieving directly such information instead of including this field in the revised RTS 23.

44. A few respondents urged for caution, flagging that:

The reliability of the reported CFI codes should be improved and the misclassification problems addressed.
The field ‘Contract type’ is well used and heavily imbedded into the overall reference data process.
Additional guidance may be needed due to certain minor divergences between the allowable values in the current field 5 and the corresponding categories in the CFI.

Q56: Do you agree with the proposed alignment between RTS 23 and RTS 2 as set out in this section? Please provide details on which alignment is (not) feasible and why, considering the impact in terms of comprehensiveness and consistency of the reported information.

45. Respondents generally supported the proposed approach of consolidating consistently RTS 23 data fields with RTS 2 reference ones to avoid duplicative concepts across the technical standards. One respondent explicitly appreciated the initiative to eliminate duplicative fields to ease the reporting burden and to rely mostly on the CFI code.

46. A few respondents expressed concerns as the proposed approach would disregard the differences in obligations concerning trading venues vis-à-vis the DPEs and flagged that DPEs should not be subject to any additional requirements concerning reference data for transparency purposes. ESMA acknowledges this comment, but - based on the assumption of the simplification of transparency reference data for derivatives and the intent not to create complex customised rules for different subsets of derivatives, it

[17] See field 5 of Table 2 of Annex IV of RTS 2 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:02017R0583-20240101

would be preferable to consider extending the complete set of fields to all derivatives in scope of Article 27.

47. With regards to the “Reporting day”, one respondent flagged that this field already exists in RTS 23 as part of the DATINS message header. ESMA acknowledged that this is true and therefore agrees that the inclusion of such new field (Reporting day) would be redundant.

48. With regards to field 17 ‘Issuer of the underlying bond’ of RTS 2, one respondent highlighted that it can be deleted to the extent that the field 27 ‘Underlying issuer’ of RTS 23 requires the reporting of the LEI of the underlying issuer applicable to all asset classes. The respondent flagged that currently the issuer of the underlying and ISIN or index name are mutually exclusive. ESMA takes note of the comment for the potential implementation of L3 validation rules in terms of consistency checks between the underlying issuer LEI applicable to all asset classes (existing Field 27 of RTS 23 that includes the Field 17 of RTS 2) and other relevant fields.

49. Another respondent requested revision of the guidance on the use of fields 26 and 27 (Underlying ISIN and Underlying issuer) for CDS, stating that CDS are predominantly based on reference entities rather than specific reference obligations. In this regard ESMA clarifies that RTS 23 does not favour provision of one field over the other but simply states that in case of CDS on specific reference entity, the reports should contain the LEI of that entity, whereas in the cases of CDS on specific instruments they should contain the ISIN of such instrument. This may be further explained in L3 guidance.

50. Finally, one respondent flagged wrong references in the CP for the fields Maturity date (correct references are: Annex IV, Table 2 Field 8 ‘Maturity date’ of RTS 2 and Table 3 of the Annex of Field 15 ‘Maturity date’ of RTS 23). Wrong references were included also for Emission allowances sub-type (correct references are Field 11 in RTS 2 ‘Emission allowances sub type’ of Annex IV in Table 2 and field 36 ‘Sub product’ in RTS 23 that references to the classification of Emission allowances to be used according to Table 2). For the avoidance of doubt, ESMA confirms that those references in the CP were incorrect.

Q57: As it concerns “underlying type” classification, do you agree with the proposed reliance on CFI and other reporting fields? With specific regards to Field 27, do you have proposals on how that field may be streamlined?

51. The majority of those who replied to this question agreed with relying on the CFI code, possibly supplemented by additional attributes, for the purpose of reporting the information on the underlying type. Some respondents concurred with ESMA’s assessment that the CFI code itself would not fully cover the information reported currently under RTS 2 for the underlying in equity instruments and flagged that the current specification of the field 27 of RTS 2 (‘Underlying type’ for equity derivatives) makes the mapping to CFI complex. One respondent highlighted that field 27 does not allow to represent accurately the diversity of underlying types of indices and other equity derivative products. Those respondents suggested better alignment with the CFI categories.

52. Another respondent commented on fields related to Credit derivative underlying, flagging that reference to field 33 in RTS 2 (‘Underlying Index code’= ISIN of the CDS index) is missing. In addition it was flagged that field 24 in RTS 2 (‘Reference rate’) for Interest rate derivatives is mapped to field 40 ‘ Reference rate’ in RTS 23, but then field 40 is replaced in the CP with the modified field 28 (Indicator of the underlying index or floating reference rate of leg 1=’INDEX’) and new field 28a (‘Name of the underlying index or floating rate of leg 1’=’ ALPHANUM-50 ’ ). ESMA takes note of these comments.

Q58: Do you see additional room for simplification and/or alignment of reference data for transaction reporting and transparency purposes? What would be the impact in terms of one-off and ongoing costs, benefits and change management of such simplifications, in particular with respect to reducing and consolidating data flows to ESMA that exist currently?

53. Similarly to the questions above, a few respondents suggested that no additional obligations should apply to DPEs in terms of transparency reference data and its consolidation under RTS 23. On a general note, another respondent highlighted also that the RTS 2 review for derivatives as well as the review of the scope of transaction reporting could provide further opportunities for simplification and efficiencies.

54. One respondent expressed support for a simplification of the regime for identifiers across transparency and transaction reporting and, if OTC ISIN is retained, the removal of problematic data fields for code assignment (as suggested for IRS) across all asset classes.

55. A few respondents highlighted that some NCAs require trading venues to daily report reference data directly to them due to alleged absence of certain data necessary for their supervision activities in RTS 23. The respondents suggested that the NCAs and ESMA should define an exhaustive list of the data necessary and include it in RTS 23. ESMA notes this aspect and will work in cooperation with NCAs to identify the unnecessary duplications.

56. A few respondents highlighted that sufficient time for implementation needs to be granted and that the specific timelines should be made know as soon as possible along with a cost-benefit analysis to balance the potential long-term benefits.

57. Additional suggestions for simplification were raised. One respondent proposed to remove Field 30 of the current RTS 23 which refers to the Option type for derivatives, which in turn would be covered by the CFI. ESMA acknowledges that this information could be derived from the CFI (similarly to some other fields present in the RTS 23).

58. One respondent suggested also to merge RTS 2 Field 25 “Term of the underlying interest rate” and its relevant description into RTS 23 field 29 ‘Term of the underlying index or floating rate of leg 1 – time period ‘, given that these field are already required to be consistent

59. Similarly, a suggestion was made to merge RTS 23 field 41’ Tenor of contract – time period’ into RTS 23 field 29 ‘Term of the underlying index or floating rate of leg 1 – time period’. As outlined in the ESMA Q&A18 these two fields represent different information and should not be merged: while field 41 is dedicated for the term or tenor of the interest rate derivative contract, field 29 instead indicates the term/duration of the underlying index.

60. ESMA confirms that field 25 “Term of the underlying interest rate” of RTS 2 could be potentially merged into with field 41 “Tenor of contract – time period” into RTS 23. It would correspond to RTS 23 field 41 ‘Tenor of contract – time period’ without any further change in the Annex of RTS 23.

61. One respondent flagged that field ‘Notional Currency 2’ is currently duplicated in the table. ESMA confirms that the field is included twice (field 42 and 47) in separate sections – once for IR derivatives and once for FX derivatives and such element will be taken into consideration for future amendments.

62. Another respondent flagged that RTS 2, table 2, field 22 (‘Inflation index ISIN code’) might be redundant. ESMA confirms that this field would indeed be already covered by the generic field containing the ISIN of the underlying (Field 26 of RTS 23).

63. One respondent asked how the new field 4b (Action type) in RTS 23 interacts with the current possibility to CANCEL an instrument in FIRDS. This aspect is covered in more detail in the Section 3.5.1.

[18] https://www.esma.europa.eu/publications-data/questions-answers/1697.

64. One respondent underlined that the approach of individual TVs submitting their own version of reference data, by its very design, creates ambiguity for users as it is prone to error and data quality inconsistency. According to that respondent ESMA should instead work with a reference data provider to minimise such issues. ESMA takes note of the comment, highlighting that such approach is not in line with the MiFIR framework setup that is specified in L1.

65. Another respondent invited ESMA to consider extending the scope of the reference data repository to include the list of underlying indices of financial products and to establish a centralized repository of members/participants of each trading venue. Similarly to the comment above, such proposal goes beyond the scope of ESMA mandate under MiFIR and of the RTS 23.

66. Finally, some respondent flagged the need to ensure alignment with RTS 22 on transaction reporting, in particular where ‘trimming down’ the data elements associated with instrument identifiers may require an associated migration of a small number of data elements to RTS 22. ESMA confirms that the alignment and correlation of the RTS 22 and RTS 23 are taken into consideration given the interdependency of the two data sets.

Q59: Do you have suggestions on how the fields mentioned above may be improved and streamlined?

67. Two respondents flagged that field 39 of RTS 2 "Issuer of sovereign and public type" has not been included in RTS 23 (proposed new field 48f to be added), as it is not mentioned in the consolidated version of RTS 23 amendments in the annex of the CP. ESMA confirms that the field was unintentionally omitted and it should have been incorporated in RTS 23, in line with the clarifications provided in the CP (see table under paragraph 339 of the CP).

68. Some respondents suggested that certain fields of RTS 2 could be removed from the field-by-field transposition into RTS 23 as they can be derived from other sources, such as CFI, ISIN or UPI. The fields mentioned include Field 19: Issuance date of the underlying bond, Field 28: Parameter, Field 35: Series, Field 36: Version, Field 37: Roll month, Field 38: Next roll date.

69. One respondent asked whether fields 13b ‘Issuance date’ in the Bond section and 46b ‘Issuance date of the underlying bond’ in the Interest rate derivatives section are not redundant. ESMA confirms that these two fields convey the same information, but they pertain to different types of instruments: bonds in the first case and derivatives in the latter.

3.2 New OTC derivative identifier

3.2.1.1 Background

70. Article 27(5) 19 of the revised MiFIR sets out that the Commission shall adopt delegated acts to specify the identifying reference data to be used with regard to OTC derivatives for the purpose of the transparency requirements. Furthermore, Art. 27 (1)20 specifies that with regard to OTC derivatives the identifying reference data that should be used for transparency reporting of OTC derivatives shall be based on a globally agreed unique product identifier and on any other relevant identifying reference data.

71. At the time of the CP, ESMA included some general considerations on potential amendments to the RTS 23 based on the information known at that time and in light of the targeted consultation 21 on OTC derivatives identifier for public transparency purposes issued on 29 November 2023. Among the indications contained in the CP, it was clarified that the OTC derivatives could have been identified: i) with ISO 4914 UPI complemented by additional attributes to be used as identifying reference data; or ii) with a modified ISO 6166 ISIN as the basis for the identification of instruments. In addition, the CP on RTS 23 proposed to remove - for IRSs instruments only - field 24 ‘Expiry date’ from the list of reference data fields to be submitted as it was considered no longer relevant according to the same assumptions and the feedback provided to the EC’s Consultation.

72. On January 2025 the EC published the final text of the Delegated Act22 with regards to the OTC derivatives identifier and identifying reference data to be used for public transparency purposes23 .

[19] 19Art. 27(5) “By 29 June 2024, the Commission shall adopt delegated acts in accordance with Article 50 to supplement this Regulation by specifying the identifying reference data to be used with regard to OTC derivatives for the purposes of the transparency requirements laid down in Article 8a(2) and Articles 10 and 21. The Commission is empowered to adopt delegated acts in accordance with Article 50 to supplement this Regulation by specifying the identifying reference data to be used with regard to OTC derivatives for the purposes of Article 26.”

[20] Art. 27(1) “With regard to OTC derivatives, identifying reference data shall be based on a globally agreed unique product identifier and on any other relevant identifying reference data.”

[21] https://finance.ec.europa.eu/regulation-and-supervision/consultations-0/targeted-consultation-otc-derivatives-identifier-public-transparency-purposes_en

[22] EC Delegated Act on OTC derivatives identifier: Register of Commission Documents - C(2025)417

[23] https://finance.ec.europa.eu/regulation-and-supervision/consultations-0/targeted-consultation-otc-derivatives-identifier-publictransparency-purposes_en

3.2.1.2 Feedback statement Q60

Q60: Do you agree with the above assessment of the necessary adjustments to be made in the RTS 23 to accommodate for the identifying reference data?

73. Some of the respondents explicitly supported the assessment presented by ESMA in the CP, including the proposed removal of the field ‘Expiry date’ for IRS. However, most of the respondents emphasised, in line with the caveats made by ESMA in that paper, that the necessary adjustments could not be fully assessed until the final content of the EC Delegated Act were available.

74. Additionally, some of the respondents reiterated their preferences in terms of the choice between the modified ISIN and the UPI or made further suggestions with regards to how the OTC ISIN should be modified. In this regard ESMA notes that this is outside of the scope of the review of the RTS as it has been specified in the final text of the EC Delegated Act.

75. Finally, a few respondents advocated for the UPI to be added to RTS 23 as a new field irrespective of the potential choice of OTC ISIN as the identifier.

76. ESMA takes note of the comments received and highlights that until further amendments are implemented on RTS 23, the rules set out in the current RTS 23 will continue to apply for the purpose of OTC derivatives identifying reference data used in transaction reporting. With refence to the OTC derivatives identifying reference data to be used for the purposes of the transparency requirements, ESMA makes reference to the provision included in the EC Delegated Act.

3.3 Date by which reference data are to be reported

3.3.1.1 Background

77. The MiFIR review adds a new letter c) to Article 27(3), requesting ESMA to define “the date by which reference data are to be reported”.

78. This amendment in the mandate is in line with the recommendations set out in the MiFIR Review report24, where ESMA proposed to align the mandates under Article 27 of MiFIR with the one under Article 9 of EMIR by adding a requirement to specify among

[24] https://www.esma.europa.eu/sites/default/files/library/esma74-362-1013_final_report_mifir_review_-_data_reporting.pdf See section 12.3. 2

others ‘the date by which reference data are to be reported’ and ‘the frequency of reports’.

79. Under EMIR, ESMA used this mandate to postpone the application of one specific requirement, notably the requirement to send update reports for outstanding derivatives in order to align them with the new rules. The date by which entities need to comply with this requirement was offset by 6 months compared to the application date of the revised ITS on reporting under Article 9 of EMIR.

80. ESMA considered if a similar solution was needed under RTS 23 and concluded that a transitional period for certain requirements was not necessary. Consequently, ESMA proposed in the CP that the ‘date by which the reference data are to be reported’ should be equal to the date of application of the final revised RTS 23.

81. Furthermore, ESMA proposed that the date of application should be set sufficiently in the future to allow for an adequate lead-in time for market participants and regulators to implement the new requirements. In line with EMIR, ESMA proposed that the application date is set 18 months after the publication of the technical standards in the EU Official Journal to allow for at least 12 months of implementation period from the moment when full technical documentation was expected to be available.

3.3.1.2 Feedback statement Q61

Q61: Do you see a need to specify the ‘date by which the reference data are to be reported’ different from the date of application or have other comments with regards to the proposed timeline? If so, please specify.

82. Twenty three respondents provided input to this question. The vast majority of them supported ESMA’s proposal with regards to the mandate on the “date by which reference data are to be reported”. Several respondents supported in particular an 18 months implementation period, assuming that the technical requirements would have been published as early as possible thus allowing sufficient lead time for implementation.

83. One respondent requested six additional months. A few respondents advocated for a more general alignment of timelines, also across other related RTSs.

84. None of the respondents identified a need for setting a “date by which reference data are to be reported” which is different from the date of application. Some respondents explicitly confirmed the assessment and that there was no need for such differentiation.

85. Four respondents expressed the view that the new derivatives identifier should be available and integrated into FIRDS before the RTS 23 implementation date, whereas two respondents expressed a preference for the related changes to be coordinated to the same date and flagging that an earlier introduction of the new ISINs could create reporting issues.

86. Another respondent commented that it would be beneficial for CTPs that the FIRDS database included all the new instruments planned for the next trading day, as this would allow for conducting data controls against the FIRDS database before the start of the trading day. ESMA takes note of this suggestion. However, such a change would not be possible for venues without a defined list of traded instruments.

2. Approach to assessing the consistency with EMIR/SFTR and ensuring the use of relevant international standards

3.3.2.1 Background

87. Article 27(3) of the revised MiFIR requires ESMA, when developing the RTS, to “take into account international developments and standards agreed at Union or international level, and the consistency of those draft regulatory technical standards with the reporting requirements laid down in Regulations (EU) No 648/2012 and (EU) 2015/2365”.

88. In the CP, ESMA listed the following international standards that appeared relevant for the reference data purposes: ISO 6166 ISIN, ISO 17442 LEI, ISO 10962 CFI, ISO 10383 MIC, ISO 18774 FISN, ISO 8601 for dates and times, ISO 4217 for currencies as well as ISO 20022 dictionary for data elements contained therein.

89. ESMA has assessed the consistency of the fields detailed in the currently applicable RTS 23 with the reporting requirements set out in EMIR and SFTR technical standards.

90. The adherence to the international standards and consistency with EMIR and SFTR reporting requirements has equally been considered with regards to the new fields proposed in other sections of this CP.

3.3.2.2 Feedback statement Q62

Q62: Are there any other international developments or standards agreed at Union or international level that should be considered for the purpose of the development of the RTS on reference data?

91. Nineteen respondents provided input to this question. Overall, respondents expressed support for the effort undertaken to further align RTS 23 with the international standards. They also flagged the following additional standards for ESMA’s consideration: UPI and ISO 15022. One respondent also reminded ESMA to ensure consistency with FSB recommendations, ISRO principles and other EU regulations.

92. ESMA therefore considered further the following specific international standards:

With regards to the UPI, please refer to Section 3.2.
Regarding ISO 15022, ESMA confirms that reporting under RTS 23 should continue to be based on the ISO 20022 methodology that is the commonly used standard between financial institutions.

93. Finally, one respondent commented that the standards used may be adapted in respect of new instruments such as crypto-assets, their derivatives and instruments that may be digitally held on-chain. In this regard ESMA evaluated if the ISO 24165 DTI (Digital Token Identifier) should also be added to the RTS 23, similarly to the proposal made in the CP on the RTS 22 on transaction reporting. It was considered that the DTI should not be included as a field in RTS 23 considering that multiple DTIs may be allocated to the same ISIN, and therefore its inclusion would deviate from the objective of keeping the granularity of the data at ISIN level.

3. Changes to the reportable details

3.3.3.1 Background

94. In the CP ESMA requested feedback on the table (Table 1 Section 14.4.2) containing a detailed field-by-field assessment of the consistency of each of the reference data elements with the international standards, EMIR and SFTR.

3.3.3.2 Feedback statement Q63

Q63: Do you agree with the changes proposed in the tables above? Should any other changes be considered to align the MiFIR reporting specifications with the international standards, EMIR and / or SFTR?

95. The majority of respondents supported the proposal to better align RTS 23 with EMIR, SFTR and international standards. Several comments and additional suggestions were made in this regard.

96. A few respondents argued that fields 20 (Indicator of the index/benchmark of a floating rate bond), 28 (Indicator of the underlying index or floating rate of leg 1) and 45 (Indicator of the floating rate of leg 2) should be reportable only on the basis of recognised ISO codes, highlighting difficulties with consistent reporting of names “as assigned by the index provider”. A respondent suggested to expand the list of 4-letter codes and to rely on such list instead of ISINs, another respondent suggested to use the Financial Instrument Global Identifier (FIGI) for the same purpose, another argued for the need of a list of industry-agreed valued.

97. ESMA wishes to clarify that these lists of standardised codes are not intended to be completed. The 4-letter codes should be reported only for those benchmarks which are included as possible values according to the ISO list. The requirement to provide the full name of the relevant index/rate complements the list of ISO codes and is aimed at covering other benchmarks for which a code is not provided. ESMA does not see a need to expand the current list, which is sufficient for the need identified at present. However, in order to address the comment received, ESMA may consider in a future review to make the field “name provided by the index provider” mandatory in validation rules only where fields 20 (Indicator of the index/benchmark of a floating rate bond)/28(Indicator of the underlying index or floating rate of leg 1)/45(Indicator of the floating rate of leg 2) cannot be provided.

98. Furthermore, this same respondent highlighted that some data is provided as input attributed for UPI and suggested to take this into consideration.

99. A few respondents noted that the commodity classification table proposed in the CP and the one used under EMIR and SFTR were not identical. ESMA confirms that this was an oversight, and the intention was to have a full alignment between the table provided in the Annex of the draft RTS and the table provided in paragraph 355 of the CP.

100. Three respondents proposed to maintain the value OTHR in the field Option style (field 33), to account for the cases where none of the specific values EURO/AMER/BERM is adequate (Ex Corporate Warrant CFI start with RW*). ESMA confirms that the value OTHR could be retained.

101. One respondent noted the following specific aspects:

field 30 Option type: this could be derived from the CFI. As specified in Section 3.1.2 ESMA agrees that the option type can in most cases be derived from the CFI (similarly to some other fields present in the RTS 23), however due to relevance of this field for authorities it was preferred that the field remains also directly reportable to FIRDS.
field 31. Strike price: for index products whose prices are given in index points, index points should be included in the "monetary" definition. ESMA confirms that it should indeed be the case.
fields 41. IR term of contract: it could be merged with field 29. Term of the underlying index. In this regard ESMA clarifies that field 29 refers to the term of the underlying index, whereas field 41 – to the term (duration) of the whole contract and the fields should not be merged.
field 42. Notional currency 2: it has the same name as field 47 and should be renamed. Please refer to question 58 with regards to feedback on this field.

102. One respondent suggested to add further fields for bonds, such as: Issuer type (e.g. Sovereign, Other public, Corporate), Covered and Convertible bond flag (e.g. Yes/No).

103. Two respondents inquired about field 14 “Total issued nominal amount”. One respondent asked to clarify whether this field would refer to the first issuance including or excluding any amount held back for possible future tapping. Another respondent disagreed with the description of the field, stating that the notional of bonds is inherently known and there is no calculation to be performed of “number of bonds multiplied by their face value”. ESMA notes that a Q&A25 was published on this field and clarifies that in the case of bonds or other forms of securitised debt, a trading venue should update Field 14 if the total nominal amount changes (increasing or decreasing) reflecting the outstanding amount.

104. One respondent suggested to add a new field for Total Return Swaps (TRS) traded as spreads to the performance of the underlying basket and where it is not possible to provide the ISINs of the components of the underlying basket.

105. One respondent suggested to explore further alignment with CSDR and ESAP. However, ESMA has not identified the need for further alignment at this stage.

106. Another field proposed by respondents is an identity for digital events traded as a single price such as Triggers, Barriers, Corridors, range K/o’s’; Knock-ins or related derivative types with multiple conditionalities and more complex sets of mutually contingent options. ESMA took note of the comment, however such information on

[25] Q&A1691 of ESMA70-1861941480-56 Q&As on MiFIR data reporting

digital options presents a complex level of reporting given its granularity which needs to be further assessed.

107. With regards to ‘OTHC’ (Other C10 derivatives) one respondent proposed to add explicitly a new category for traded certificates such as Guarantees of Origin [“GOO”] and for traded crypto-asset derivatives. In ESMA’s view, GOO are not financial instruments therefore there is no need to consider further this category.

108. With regards to commodities classification, one respondent noted that some of the existing sub products identify specific national delivery points (e.g. GASP for Germany) and inquired if this could be better supported by having a code for every EU country’s national gas delivery point rather than just a selected few. ESMA notes that indeed all references to national delivery points should be deleted and this was not done consistently in the CP. That respondent also suggested adding sub product ‘AMMO’ – Ammonia to sub product ‘NGAS’ – Natural Gas (base product ‘NRGY’ – Energy) as Ammonia is used to package hydrogen as a vehicle for energy and is equivalent to the existing LNGG further sub product. ESMA agrees AMMO would need to be added as the value proposed is consistent with the other values at that level (LNG, NatGas, Hydrogen).

109. Another respondent flagged that the proposed change to the commodities classification may also impact UPIs, as the three parameters of Base / Sub / Further Sub-Product are attributes of the UPI generation templates for commodity products. ESMA acknowledges that this is the case. However, since the proposed change would only involve the addition of “OTHR” for a number of the categories (rather than amendments or deletions), this should not provide a backwards compatibility issue for the users.

110. One respondent commented that field 19 (Identifier of the index/benchmark of a floating rate bond) should be optional as in EMIR.

111. Another respondent asked that the ISIN should be removed as an identifier since a user should not need to check an index ISIN on ANNA web portal to understand if it is -for example – Euribor or ESTR. In these regards, ESMA notes that field 20 is expected to serve the purpose of ensuring the consistent reporting of index/ benchmark of a floating rate according to the ISO 20022 standard, without need for users to refer to the ANNA web portal based on the ISIN.

112. Furthermore, a comment was received that field 22 (Basis point spread of the index/benchmark of a floating rate bond) should be fully aligned with EMIR, while field 25 (Price multiplier) should be removed since the same was done for EMIR. With regards to field 22, ESMA notes that no discrepancy was identified between field 22 of RTS 23 and EMIR field 93 (“Spread of leg 1”) when the spread is expressed in basis points. With regards to the field 25, the reason to retain it under MiFIR was related to its relevance for ETD derivatives.

113. Another respondent commented that for any reference data elements relating to leg 1 or leg 2, it should be clarified how to determine the designations (for example, according to that respondent, in fix-float interest rate swap the fix leg is usually seen as leg 1 and the float leg (and its index) as leg 2). ESMA clarifies that it is preferred not to rely on any particular convention that would force entities to report the legs in a fixed order. Instead, in line with EMIR, a flexible approach should allow entities to report legs in any order.

114. Regarding field 29 (Term of the underlying index or floating rate of leg 1 – time period) and 29a (Term of the underlying index or floating rate of leg 1 – multiplier), one respondent inquired about the change of code from DAYS to DAIL, and asked whether 29a has to be populated with 1 whenever 29 = DAIL. ESMA clarifies that this is not the case and the meaning of DAIL would be the same as that of the previous DAYS.

115. Some respondents flagged that ESMA should add the ISO 4913 UPI into RTS 23. For comments related to the OTC derivatives identifier, please refer to Section 3.2.

3.4 Adapting reference data for the use for publications under CSDR

1. General approach

3.4.1.1 Background

116. The Central Securities Depositories Regulation (CSDR) was revised in 2023, and the amending Regulation (EU) 2023/2845 (CSDR Refit) entered into force on 17 January 2024. CSDR Refit introduces, among others, a new requirement for ESMA to publish the list of financial instruments within the scope of the settlement discipline regime under CSDR (please refer to the box under paragraph 356 of the CP for further details). For efficiency and consistency purposes, it was proposed to explore if this requirement can be supported by integrating the CSDR reference data within the publication of reference data for reference data reporting and transparency purposes under the Article 27 of MiFIR.

117. With respect to the scope of the instruments to be published for CSDR purposes (transferable securities, money-market instruments, units in collective investment undertakings and emission allowances), it is relevant to note that they constitute a subset of the MiFID financial instruments and will be required to be reported under

Article 27 of MiFIR to the extent that they are (i) admitted to trading or traded on a trading venue or (ii) the issuer has approved trading of the issued instrument or (iii) a request for admission to trading has been made. It should be noted that under CSDR the respective instruments should be published if they are admitted to trading or traded on a trading venue or cleared by a CCP. Based on information available to ESMA at this stage, currently there are no instruments that are cleared by CCPs but not admitted to trading or traded on trading venues.

118. The revised CSDR requires only to publish a list of financial instruments and does not set out additional requirements with regards to the reference data that should accompany those publications. Consequently, in terms of the scope of information to be published, the reference data publications under Article 27 of MiFIR would appear sufficient to formally satisfy the requirements of CSDR.

3.4.1.2 Feedback statement Q64

Q64 : Do you foresee any challenges with the proposed approach under which the CSDR publications would be integrated in FIRDS?

119. The feedback among the respondents was quite mixed: eight respondents did not anticipate any challenges with ESMA’s proposal, while ten respondents expressed concerns. Among these ten, one respondent strongly opposed the proposal, suggesting that both datasets should remain separate to preserve FIRDS’ primary purpose of providing instrument reference data.

120. Six respondents highlighted potential challenges in integrating CSDR publication data into FIRDS, citing issues such as data compatibility, data quality, technical integration, regulatory compliance, operational impact, and user experience. One respondent highlighted that one challenge would be to understand the identifier and the granularity to be used.

121. Finally, three respondents saw no benefits in integrating this data into FIRDS, as the demand to consolidate all relevant reference data for penalties calculation in a single central database is not fulfilled by this incremental change, making it unnecessary to go beyond the CSDR REFIT requirement to “publish a list of financial instruments”. ESMA agrees that the mandate for ESMA is only to publish and keep updated on its website a list of the financial instruments referred to in Article 5(1) of CSDR26 . ESMA notes that given that no additional effort is demanded to market participants, integration into FIRDS and the other available reference data could be a

[26] Transferable securities, money-market instruments, units in collective investment undertakings and emission allowances

solution that allows ESMA to optimise the effort and resources relying to a large extent on an existing system instead of developing a brand-new publication.

122. One respondent requested confirmation from ESMA that the additional CSDR-related data applies only to trading venues and not investment firms. ESMA confirms that it is indeed the case.

123. One respondent raised concerns about the risks of increased cross-regulation comparisons, including data quality tests between RTS 23 and data reported under other regimes like EMIR and SFTR. The majority of respondents who anticipated potential challenges emphasized the need for greater clarity on how the integration would work in practice and its full implications. They noted that the feasibility largely depended on the proposed technical solution and the integration process.

124. One respondent who did not foresee any challenges highlighted that, while FIRDS was originally built for MiFIR/MAR purposes, the proposal represents a practical solution to streamline the existing and forthcoming reporting regimes, thereby reducing the burden on reporting entities adapting to multiple repositories.

2. Additional information concerning instruments published pursuant to CSDR

3.4.2.1 Background

125. Instruments published pursuant to CSDR will constitute a subset of financial instruments published in FIRDS. To enable easy identification of the instruments that are in scope of the CSDR publications, a Boolean flag was proposed to be added to the reference data.

126. Furthermore, it should be noted that for the purpose of the calculation of cash penalties under CSDR, the CSDs are required to determine the market value of financial instruments to be used as a reference price. In the case of equities, the relevant market for price is the most relevant market in terms of liquidity as published in FITRS27 . In case of debt instruments admitted to trading on a trading venue within the Union, the closing price derived from the trading venue within the Union with the highest turnover is used28. To support the CSDs, ESMA publishes currently, on a voluntary and best effort basis, with a quarterly frequency, a list of the debt instruments in scope (identified with ISIN) and the corresponding trading venue that recorded the highest volume traded (identified with a MIC code). Should CSDR calculation be

[27] Financial Instruments Transparency System

[28] point b) of Article 7 of Delegated Regulation (EU) 2017/389

integrated in FIRDS, the relevant information could also be included, e.g. as an additional field which – for each instrument in scope of CSDR publication – would specify whether a given combination of MIC-ISIN is relevant for the determination of a reference price (by indicating the MIC with the highest turnover or the most relevant market in terms of liquidity).

3.4.2.2 Feedback statement Q65

Q65: Do you have any comments with regards to the inclusion of additional fields in the instrument reference data published by ESMA to indicate whether the instrument is in the scope of CSDR and to specify which MIC corresponds to a venue with the highest turnover or the most relevant market in terms of liquidity?

127. A total of 20 respondents provided input. Two expressed outright opposition, while two others noted some concerns, emphasizing that the viability of a new CSDR flag depends on how it would be populated. They also highlighted that adding new fields could increase complexity, lead to implementation costs, and present challenges in specifying the most relevant MIC. ESMA would like to clarify that the original proposal was that ESMA would provide the additional fields in FIRDS so no extra complexity, burden or costs for entities was expected.

128. Seven respondents expressed support for the proposal. However, among these, three indicated their agreement was conditional on ESMA itself processing the additional information.

129. One respondent asked if CSDs would need to consider a new ESMA flag in the future or continue to apply CSDR SDR penalties for any ISINs listed in FIRDS except for shares subject to Short Selling Regulation exemption. Additionally, some respondents raised issues with the inclusion of new fields in FIRDS for penalties calculations under CSDR. They argued that such changes, while potentially useful, would not fully address the need for a comprehensive central database of all reference data required for penalties calculation.

130. ESMA notes in this regard that indeed the proposed approach would require CSDs to apply the new filter in FIRDS to obtain the list of ISINs in scope of CSDR cash penalties and exclude the shares that have the principal trading venue in a third country, as per the list published by ESMA under the Short Selling Regulation.

131. Additionally, some respondents raised issues with the inclusion of new fields in FIRDS for penalties calculations under CSDR. They argued that such changes, while potentially useful, would not fully address the need for a comprehensive central database of all reference data required for penalties calculation. ESMA notes that the purpose of this field was to respond to a specific mandate included in CSDR Refit, and not to create a comprehensive database.

132. Respondents emphasized that ESMA is best positioned to identify instruments within the scope of CSDR publications and to calculate the most relevant market in terms of liquidity or the trading venue with the highest turnover. They further noted that, without ESMA’s involvement, it would be challenging for trading venues submitting RTS 23 data to obtain such information, as this would require sourcing data from external entities or companies.

133. Several respondents raised concerns about specifying the MIC that corresponds to the venue with the highest turnover or the most relevant market in terms of liquidity. While not opposing the proposal, they emphasized the complexity of determining the "most relevant" MIC, particularly due to the potential for frequent changes between venues over time. The challenges around identifying and managing this MIC designation were highlighted, with some questioning whether it adds sufficient clarity or efficiency. The need for historical tracking of MIC changes was also highlighted as a potential concern.

134. Lastly, there was a suggestion that this information could be better managed within FITRS rather than FIRDS, in line with how similar data is handled for shares. Since the point of the new obligation introduced by Article 7 of CSDR is to publish “a list of financial instruments”, ESMA deemed it more relevant to leverage on FIRDS where these fields are be made available to the public.

3.5 Other enhancements

1. New fields to be included

3.5.1.1 Background

135. Based on the experience acquired over the past years in the use of reference and transaction data, NCAs and ESMA consulted on certain new data fields which would be useful to provide comprehensive information and capture additional aspects related to the financial instruments that can be retrieved from the reporting entities. Seven new fields were proposed in the CP and are presented in the following section.

3.5.1.2 Feedback statement Q66

Q66: Do you support inclusion of the new fields listed above?

136. Twenty-one respondents provided input on this question. Of these, three expressed full support for the inclusion of all seven fields. The first two fields in particular —LEI of the administrator of the benchmark (20b) and LEI of the fund manager (5a) —faced significant opposition. Additionally, some requested further clarification regarding the field “Action type”.

137. The new fields Minimum trading value (17a), LEI of the Designated Publishing Entity (6a), Venue of first admission to trading (6b), and Delivery period (39a) were generally more well-received by respondents.

138. Respondents generally sought clarity from ESMA on which fields would be optional and which would be mandatory, emphasizing that if the fields are made mandatory, they may encounter difficulties retrieving the necessary information and that these new fields should only be required from the date the requirements become applicable.

139. It was also requested to confirm whether the additional fields would apply solely to trading venues. ESMA notes that the new requirements would have been applied to trading venues and to designated publishing entities as indicated in Article 2 of the draft RTS provided in the CP.

Field-by-Field Feedback

3.5.1.2.1 LEI of administrator of benchmark (20b) and LEI of fund manager (5a)

140. The majority of respondents were not in favour of the inclusion of these fields, especially since it was felt that they were added without sufficient context or justification. Some respondents highlighted the significant technical challenges and costs involved in identifying and populating them. They argued that these fields seem more relevant to trade data than to reference data under RTS 23. Some respondents also suggested that ESMA could retrieve this information from its existing systems, such as the Benchmarks Reference Data System, instead of requiring trading venues to establish new channels to report the data. ESMA notes that it would not be possible to link information in the two registers without a connecting “key” such as the LEI. Furthermore, the Benchmark register is too narrow in scope.

141. One respondent agreed with including these fields, but only for use in the registry and not for transparency reporting or transaction reporting, where the information would not provide added value. Furthermore, one respondent invited ESMA to consider that it is only necessary to identify a benchmark administrator in the event that a relevant product is index-linked (i.e. passive product) or “used” for the purposes set under Regulation 1011/2016/EU (BMR), and to note that third countries benchmark administrators often do not have one.

142. Lastly, one respondent argued that while prospectuses and final terms may mention the names of these entities, sometimes along with their addresses, they do not provide LEI codes, raising the question of whether all fund managers and benchmark administrators have an LEI code by default.

143. ESMA notes that as highlighted by several respondents currently there is no obligation for fund managers or benchmark administrators to obtain an LEI and it might therefore be challenging to report this information. However, all benchmark administrators and fund managers are expected to obtain an LEI in light of the upcoming requirements under the ESAP Regulation starting in January 2028. Furthermore, in the context of the AIFMD/UCITS review, ESMA has a mandate to define the identifiers for AIF/UCITS and their management companies by 16 April 2027.

3.5.1.2.2 Minimum trading value (17a)

144. Several respondents raised specific concerns about this field. One noted that the minimum trading value is not exclusively determined by the trading venue and can vary based on the trading protocols used. Others argued that this is not true reference data and, apart from listed derivatives, it seems unnecessary for most non-equity instruments. One respondent agreed with the inclusion of this field, recommending that no limitations be imposed on trading outside of a venue for executing small client trades. Another respondent argued that the new field 17a (Minimum Trading Value) is confusing and its purpose is unclear.

145. ESMA highlights that this field was intended only for bonds, and therefore the value should not vary based on trading protocols.

3.5.1.2.3 LEI of the Designated Publishing Entity (DPE) (6a)

146. Seven respondents provided input to this proposal, and they all agreed to include this field. However, five of them had strong concerns about making the LEI of the DPE publicly available. They argued that from a transparency standpoint, the identity of a SI is anonymized for public reporting, and respondents felt the same approach should apply to DPEs in order to prevent any risks associated with reverse engineering or with identifying counterparties based on the DPE’s LEI. Furthermore, one respondent agreed with including it, but only for use in the registry and not for additional purposes such as transparency reporting or transaction reporting, where the information would not provide in their view added value.

147. Further details about the LEI of the DPE is discussed in Q71 and 72.

3.5.1.2.4 Venue of first admission to trading (6b)

148. There was broad support for the inclusion of this field. However, respondents sought clarification from ESMA on whether it will be limited to shares and ETFs or if it will also apply to non-equity instruments. Some expressed the concern that, in the case of OTC derivatives, this field introduces unnecessary complexity, as it is not always accurate to consider these instruments equivalent to equities. ESMA outlines that this field would not be relevant to OTC derivatives.

149. In addition, according to a few respondents, all capital raising operations should be considered as initial admission to trading.

150. Another respondent suggested that it should be clarified that it has to be populated only by the relevant trading venue – i.e. other venues that are not the primary venue should not have to populate it. ESMA notes that this was indeed the assumption.

151. Some others noted that the draft RTS only refers to regulated markets but that certain MTFs are also primary venues.

3.5.1.2.5 Action Type (4b)

152. Respondents found it unclear how this field would be used and requested that ESMA provided more detailed explanations on its purpose and the workflow it is intended to support. Without this clarification, respondents were uncertain about the relevance and practical application of the action type field.

153. One respondent agreed with including the field, but only for use in the registry and not for additional purposes such as transparency reporting or transaction reporting, where the information would not provide added value. Please note that this field is further discussed in Q68.

3.5.1.2.6 Number of Hours of Delivery during the delivery period (39a)

154. Respondents asked for a clearer definition of what ESMA means by the “delivery period,” as this term can vary across different types of commodity trades. Some respondents suggested that, without a precise definition, there is a risk that market participants would interpret and populate the information inconsistently.

155. One respondent suggested that this field should align with the REMIT (Regulation on Wholesale Energy Market Integrity and Transparency) data item, crossreferencing all product details rather than duplicating only a single characteristic.

156. Some questioned whether this field belongs in RTS 23, arguing that it pertains more to trade-level data rather than instrument-level data.

2. Fields to be amended

3.5.2.1 Background

157. In the CP ESMA proposed amendments to six existing fields in the RTS 23 Table 3 of the Annex to ensure comprehensive descriptions and improve consistency across fields. Furthermore, it consulted on how to monitor de-listings and readmissions. This section reviews the feedback received on each proposal.

3.5.2.2 Feedback statement Q67-Q68

Q67: Do you agree with the amendment listed above for the existing fields?

158. More than half of the respondents expressed support for the proposed amendments (See Section 14.6.2 of the CP for details). Specifically, there was no opposition to proposal 1 and 5. However, concerns were raised regarding proposal 2 and the linked proposal 3, which proposed to monitor cases of de-listing and later readmission to trading by allowing trading venues to report multiple values for relevant fields.

159. Respondents requested clarification on how these multiple values would have to be represented, including aspects such as the choice of delimiter, sequencing rules, and whether there would be limits on the number of values for each field. Respondents also questioned whether the proposal would align with the definitions and applications of the field “Action Type” as it is used in EMIR or if a new framework would be created for MiFIR. Further detail about the proposal for the new field Action Type is provided in Q68.

160. Some respondents opposed the proposal, arguing that it would increase complexity with little benefit, as in their view allowing multiple entries could lead to errors and misinterpretation of data. They expressed concerns about their systems' capabilities to handle such information and the potential need for significant modifications to infrastructure to maintain multiple admission dates for readmitted instruments. They argued that increased complexity may adversely affect system performance, particularly when managing large volumes of daily reported data, making it challenging to ensure data consistency and accuracy. One respondent suggested ESMA to consider re-using data already reported by trading venues, as the information about the admitted instruments i.e., when this instrument is terminated and re-admitted to trading is already available to ESMA.

161. As for proposal 3, regarding the amendment to Field 11 (Date of admission to trading or date of the first trade)'s description, it was recommended to change "not the original admission date" to "not only the original admission date" or to remove this clause entirely, in order to avoid ambiguity.

162. Regarding proposal 4, which concerns moving field 7 (Financial Instrument Short Name) to the general fields section instead of the venue-related section, one respondent sought clarity in cases where the FISN for the same instrument differs across various MICs. This respondent noted that it is unclear whether to expect a rejection or a warning, as is the case today, and that using the FISN code provided by ANNA (though agreeable) would require significant time and resources from exchanges. ESMA notes that the FISN, like the CFI, refers to a specific instrument and should not vary by TV. Any issue in these regards is due to misreporting or misalignment between different NNAs and is beyond the remits of ESMA’s work.

163. Lastly, concerning Proposal 6, which involves amending Field 31 (Strike price) to account only for options and warrants that have a strike price, only one respondent provided detailed comments. This respondent opposed the inclusion of alphanumeric characters (e.g., NOAP) in a price field and recommended adopting the same approach that was taken in RTS 1, which introduced a ‘missing price’ indicator, including a ‘not applicable’ value. ESMA acknowledges that in RTS 1 an ad hoc field is included for ‘missing price indicator’. However, considering that Field 31 already includes the option “PNDG” (pending) for situations in which the price is not currently available, ESMA deemed it less impactful to add the option “NOAP” rather than remove PNDG from Field 31 and add an entirely new field to be used specifically for situations where the price is not available.

Q68: With regards to monitoring of de-listing and re-admission, which option is preferable in your view: (i) reporting by the trading venue of all previous trading periods in the repeatable fields 10, 11 and 12 or (ii) implementing adequate reporting logic of events impacting the instrument (new, modification, termination etc) in order to enable ESMA to reconstruct all trading periods?

164. Sixteen respondents provided feedback to this question.

165. Six respondents, predominantly from fintech firms, expressed a preference for Option 1. They believed that trading venues should have comprehensive access to all relevant information concerning the listing and admission history of instruments on their platforms. They argued that publishing the full admission history enhances traceability and helps prevent potential issues arising from updates.

166. On the other hand, seven respondents, mainly from exchanges and investment services, favoured Option 2. They advocated for reporting events directly: the new field ‘Action type’ would be an adequate recipient of all changes in the history of an instrument and ESMA would have all relevant information from this field to build the life of all instruments reported under RTS 23. This method may reduce the need to manage vast amounts of historical data, thereby minimizing the risk of errors and ensuring scalability. However, these respondents acknowledged that this approach could significantly impact trading venues’ system performance, as they should implement a reporting logic that may not align with existing systems. They emphasized that in their view Option 1, which involves trading venues reporting all previous trading periods in repeatable fields (10, 11, and 12), would demand substantial development efforts in both the upstream trading and reporting systems, as the current systems are not structured to maintain multiple validity periods for a single record.

167. Additionally, a few respondents recognized both benefits and drawbacks to each option. They noted that both proposed solutions would necessitate modifications to their IT systems to access historical data and requested further clarification to better understand the technical implications and impacts associated with both approaches. In addition, according to few respondents, all capital raising operations should be considered as initial admission to trading.

3. Fields to be removed

3.5.3.1 Background

168. The current RTS 23 offers a comprehensive set of reference data that has generally been effective for transaction reporting. This data, reported under Article 27, helps regulators understand the key characteristics of financial instruments and supports the analysis and reporting of transaction reports submitted under Article 26 of MiFIR.

169. However, based on practical experience, NCAs and ESMA have identified certain attributes that are less frequently used in regulatory analyses or are inconsistently reported. These attributes can be more easily obtained from other sources. To reduce the reporting burden, it was proposed that these less commonly used attributes no longer be reported under Article 27.

170. Therefore, ESMA proposed to suppress the reporting of fields 23 (Seniority of the bond), 38 (Transaction type), 39 (Final price type), 40 (Reference rate), and 48 (FX type) in the current RTS 23.

3.5.3.2 Feedback statement Q69

Q69: Do you support suppressing the reporting of the fields listed above?

171. All 17 respondents supported the proposal to remove reporting of the specified fields. They believed this would further simplify the reporting process, reduce administrative burdens, and eliminate redundant data.

172. While no respondents opposed the proposal, some expressed a minor reservation, suggesting that the removal of the "Reference rate" field should be carefully assessed alongside other data sources to ensure no essential information is lost. Such assessment has already been done by ESMA and as mentioned in the CP, the data in field 40 “Reference rate” is already reported under the modified field 28 “Underlying index name”29 .

3.6 Format for reporting

1. Background

173. In the CP, ESMA proposed a transition from the XML format to JSON for reference data reporting under RTS 23, following the findings that emerged from a commissioned study 30 on data formats and transmission protocols. This study,

[29] In the new version of RTS 23, field 28 is renamed as “Indicator of the underlying index or floating rate of leg 1”.

[30] ESMA12-437499640-2360 Study on data formats and transmission protocols (europa.eu) –Throughout this study, a shortlist of data formats was assessed against various technical criteria. For a summary of the scores of each format under each technical criterion, please refer to page 58. Additionally, justification for the final recommendation can be found on page 121.

published in January 2024, identified JSON as the most suitable format for regulatory reporting, considering its advantages in syntax simplicity, developer-friendliness, flexibility for complex data structures, and improved parsing and serialization speed. JSON also facilitates faster and more reliable data transmission while enhancing overall data quality.

174. While the transition offers clear advantages, ESMA acknowledged the associated operational costs and the need for a gradual implementation.

2. Feedback statement Q70

Q70: Do you foresee any challenges with the use of JSON format compared to XML? Please provide estimates of the costs, timelines of implementation and benefits (short and long term) related to potential transition to JSON.

175. The general feedback among respondents reveals a cautious stance towards transitioning from XML to JSON as standard reporting format. While some saw potential benefits, including improved efficiency, reduced complexity in data handling, and better integration with modern programming tools, many respondents highlighted substantial challenges that make an immediate switch more cumbersome for reporting entities. Concerns primarily regard the significant costs and time required for implementation. Firms operating across multiple jurisdictions also raised concerns that adopting JSON could lead to inefficiencies due to the divergence from globally established XML standards, particularly in regions like the United States and Asia, where XML remains the norm.

176. Several respondents highlighted the importance of applying a phased approach to any transition, recommending a period of dual-format coexistence to allow firms to adapt gradually without incurring in compliance issues. They stressed the need for a thorough cost-benefit analysis to justify such a structural change, along with guarantees of long-term stability in regulatory requirements. A few respondents advocated for harmonization of data standards rather than mandating a single format, proposing that regulators should establish universal guidelines that support both XML and JSON, as well as other formats like CSV, to ensure flexibility and interoperability. Ultimately, while the advantages of JSON were recognized in specific contexts, the feedback underscored the need for careful planning, global alignment, and sufficient implementation timelines to avoid unnecessary costs and complexity.

3.7 Reporting by DPEs

1. Background

177. Article 27 of the revised MiFIR introduces the obligation for DPEs to report reference data for financial instruments which are not admitted to trading or traded on a trading venue and for which a request for admission has not been made. Article 21a of the revised MiFIR requires competent authorities to grant investment firms DPE status for specific classes of financial instrument and mandates ESMA to maintain a register of DPEs, detailing their identity and the classes of financial instrument for which they are DPEs.

178. ‘Classes of financial instruments’ as referred to in Article 21a is not a defined term under MiFIR. To ensure that the DPE status is assigned in a consistent manner allowing for efficient reporting of the reference data, it was necessary to clarify the categorisation of the classes of financial instruments for the purpose of the DPE register. Such categorisation was based on broad categories of financial instruments, such as shares, depositary receipts, ETFs, certificates, other equity-like instruments, bonds, interest rate derivatives, credit derivatives, structured finance products and emission allowance.

179. Additionally, a new field was proposed to be added to identify the DPE submitting the reference data using a LEI code.

180. Regarding reporting responsibility, Article 21a specifies which counterparty is responsible for publishing a transaction via an APA depending on whether one, both or neither counterparties are DPEs. However, Article 27 does not provide similar instructions for reference data reporting, meaning that if both counterparties are DPEs, each of them shall report reference data to ESMA.

2. Feedback statement Q71-Q72

Q71: In addition to including a field to identify the DPE, are there any other adjustments needed to enable comprehensive and accurate reporting of reference data by the DPEs?

181. Overall, the majority of the respondents supported the proposal and consider the inclusion of a field to identify the DPE as a worthy adjustment and stated that an implementation could support a more comprehensive and accurate reporting by DPEs. However, some respondents opposed the proposed approach and provided the following suggestions.

182. With regards to the risk of duplications of reference data, two respondents suggested that only the DPE selling the instrument should have reported the reference data, similar to the provisions in Article 21a of MiFIR. Two other respondents proposed, as an alternative approach, implementing validation and control mechanisms within ESMA’s system to prevent duplicate records when multiple DPEs report the same data. ESMA notes that the rules for transparency and reference data are different, and that where both of the parties to a transaction are DPEs each DPE should provide identifying reference data according to Article 27(1).

183. A few respondents suggested anonymizing DPE information in the public domain to protect confidentiality and prevent the DPE from being linked to individual post-trade transparency reports. ESMA notes that the DPE status is not mandatory but upon request Article 21a specifies that competent authorities shall grant investment firms DPE status ‘for specific classes of financial instruments’.

184. Furthermore, the LEI of the DPEs is already available publicly in the DPE Register.

Q72: With regards to the categorisation of classes of financial instruments for the purpose of the DPE register, how such classes should be designated in the register? Is there any further information that should be included in the register to ensure its usability and interoperability with other relevant systems? Do you foresee any practical implementation challenges, and if so, how they could be mitigated?

185. Overall, the majority of respondents supported the proposal to categorize financial instruments in the DPE register, with alignment to MiFIR identifiers and other relevant regulations. This alignment was expected to enhance the accuracy and comprehensiveness of reporting by DPEs.

186. Two respondents emphasized the need for sufficient time for investment firms and data vendors to establish connectivity with the register. They suggested a testing phase before full implementation to ensure a smooth transition and address any interoperability issues. Another two respondents raised concerns about the timing misalignment between the DPE rules and the DPE register into force.

187. On the topic of taxonomy, respondents highlighted the importance of a standardized taxonomy with unique identifiers and clear mappings. Two respondents stressed the need for precise criteria that clearly distinguish between different types of instruments to avoid unnecessary reporting. One respondent recommended that the DPE register should include a standardized taxonomy, unique identifiers, descriptions, parent-child relationships, and mappings to other taxonomies. Two respondents emphasized that key data such as LEI, asset class, and dates should be easily accessible in a user-friendly format, avoiding Excel lists.

188. Some respondents pointed out potential implementation challenges. One respondent specifically suggested developing a detailed implementation roadmap with key milestones and deadlines. They also recommended a testing phase to validate the usability of the DPE register and identify any issues.

189. Additional suggestions by two respondents included synchronizing the timing of DPE rules with other legal acts and potentially limiting DPE reporting to unlisted instruments.

190. ESMA notes that the DPE register31 is available since 29 September 2024 and the relevant categorisation are already established32, therefore no further guidelines are deemed to be necessary.

3.8 Scope of reference data to be reported

1. Background

191. The revised MiFIR modifies the scope of reference data to be reported. In addition to the instruments ‘admitted to trading or traded on a trading venue or where the issuer has approved trading of the issued instrument or where a request for admission to trading has been made’ which continue to be reported by the trading venues, the revised Article 27 requires DPEs to report other OTC derivatives that fall within the scope of Article 26(2). Article 26(2) covers also, in addition to the instruments mentioned above, the instruments where the underlying is a financial instrument traded on a venue or an index or a basket composed of financial instruments traded on a venue as well as OTC derivatives in scope of transparency which are referred in the Article 8a(2).

192. ESMA included in the CP clarifications on the scope as well as a visual representation of the changes in the scope.

[31] https://www.esma.europa.eu/sites/default/files/2024-07/ESMA74-2134169708-7345_Public_statement_on_DPE_regime.pdf

[32] See Section on DPEs https://www.esma.europa.eu/trading/mifid-ii-and-mifir-review

2. Feedback statement Q73

Q73: Are any other adjustments needed to enable comprehensive and accurate reporting of Article 8a(2) derivatives under RTS 23?

193. Respondents provided a few further suggestions regarding the potential revision of the RTS 23 to accommodate for the new reporting scope.

194. A few respondents commented on the scope itself, asking for further clarifications. In this regard ESMA recalls that the scope of reporting is determined in L1 and as such it is outside the mandate of any Level 2 revision.

195. Specifically with regards to DPEs, two respondents asked if they should report only unlisted instruments, whereas another two asked if they would report only uTOTV. In this regard ESMA confirms that the MiFIR review Level 1 framework would require DPEs to report reference data only for the financial instruments referred to in Article 26 which are not traded on a trading venue – such instruments could include both uTOTV as well as Article 8a2 derivatives.

196. These two respondents also argued that currently there is overreporting since all venues report all reference data for all instruments every day, whilst it should be enough to report when something changes.

197. Another respondent noted that the rejection mechanism implemented by ESMA should be changed and only erroneous records should be rejected rather than the entire message. ESMA notes that this comment is not relevant to the RTS but it is noted for future technical implementation.

198. One respondent expressed a concern about the lack of real-time updates in FIRDS which can lead to inaccuracies, especially when instruments become listed (TOTV) after initial reporting but are not immediately reflected in FIRDS.

4 Conclusions

199. This Final Report (FR) summarises the responses received by market participants to the consultation on the proposed amendments to the RTS 23. Based on the feedback received and with the objective to reduce burden to market participants and in view of the comprehensive review that ESMA is carrying out in the context of the Call for Evidence, this FR does not include proposed changes to the existing RTS 23. The feedback received to the consultation and summarised in the FR will serve as

ESMA
European Securities and Markets Authority

valuable input for future amendments to the technical standards and to the Level 1 text in the context of the comprehensive review.

Final Report

Acronyms

Table of Contents

1 Executive Summary

Reasons for publication

Contents

Next Steps

2 Context and objective of this publication

3 Feedback statement on the proposals of amending RTS 23

3.1 Adapting reference data for the use for transparency requirements

1. Reporting frequency

3.1.1.1 Background

3.1.1.2 Feedback statement Q51

Q51: Do you agree with the proposal for a daily reporting of reference data for both transaction reporting and transparency purposes?

2. Additional data elements to be transposed from RTS 1 and 2

3.1.2.1 Background

3.1.2.2 Feedback statement Q52 -Q59

Q53: Is in your view, the granularity level of the MiFIR identifier adequate for the purposes of MiFIR transparency in the equity and non-equity space? If not, how should it be adjusted?

Q55: Do you agree with deleting Field 5 of RTS 2, Annex IV, and use the CFI code for the purposes of derivatives’ contract type classification?

Q57: As it concerns “underlying type” classification, do you agree with the proposed reliance on CFI and other reporting fields? With specific regards to Field 27, do you have proposals on how that field may be streamlined?

Q59: Do you have suggestions on how the fields mentioned above may be improved and streamlined?

3.2 New OTC derivative identifier

3.2.1.1 Background

3.2.1.2 Feedback statement Q60

3.3 Date by which reference data are to be reported

3.3.1.1 Background

3.3.1.2 Feedback statement Q61

2. Approach to assessing the consistency with EMIR/SFTR and ensuring the use of relevant international standards

3.3.2.1 Background

3.3.2.2 Feedback statement Q62

3. Changes to the reportable details

3.3.3.1 Background

3.3.3.2 Feedback statement Q63

3.4 Adapting reference data for the use for publications under CSDR

1. General approach

3.4.1.1 Background

3.4.1.2 Feedback statement Q64

2. Additional information concerning instruments published pursuant to CSDR

3.4.2.1 Background

3.4.2.2 Feedback statement Q65

3.5 Other enhancements

3.5.1.1 Background

3.5.1.2 Feedback statement Q66

Field-by-Field Feedback

3.5.1.2.1 LEI of administrator of benchmark (20b) and LEI of fund manager (5a)

3.5.1.2.2 Minimum trading value (17a)

3.5.1.2.3 LEI of the Designated Publishing Entity (DPE) (6a)

3.5.1.2.4 Venue of first admission to trading (6b)

3.5.1.2.5 Action Type (4b)

3.5.1.2.6 Number of Hours of Delivery during the delivery period (39a)

2. Fields to be amended

3.5.2.1 Background

3.5.2.2 Feedback statement Q67-Q68

Q67: Do you agree with the amendment listed above for the existing fields?

3. Fields to be removed

3.5.3.1 Background

3.5.3.2 Feedback statement Q69

Q69: Do you support suppressing the reporting of the fields listed above?

3.6 Format for reporting

1. Background

2. Feedback statement Q70

3.7 Reporting by DPEs

1. Background

2. Feedback statement Q71-Q72

3.8 Scope of reference data to be reported

1. Background

2. Feedback statement Q73

4 Conclusions

Lineage

Similar documents from other regulators