23 June 2025
ESMA12-2121844265-4779
Final Report
On RTS 22 on transaction data reporting under Art. 26 and RTS 24 on order book data to be maintained under Art. 25 of MiFIR

ESMA - 201-203 rue de Bercy - CS 80910 - 75589 Paris Cedex 12 - France - Tel. +33 (0) 1 58 36 43 21 - www.esma.europa.eu 2 Acronyms ACTX Agency Cross Trade APA Approved Publication Arrangement ARM Approved Reporting Mechanism 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 CDE Technical Guidance CDS Credit Default Swaps CFD Contracts for Difference CFI Classification of Financial Instruments CP Consultation Paper CSDR Central Securities Depositories Regulation CTP Consolidated Tape Provider 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 ESMA European Securities and Markets Authority

ESMA - 201-203 rue de Bercy - CS 80910 - 75589 Paris Cedex 12 - France - Tel. +33 (0) 1 58 36 43 21 - www.esma.europa.eu 3 FIGI Financial Instrument Global Identifier FIRDS Financial Instruments Reference Data System FITRS Financial Instruments Transparency System FSB Financial Stability Board IRD Interest Rate Derivative ISIN International Securities Identification Numbering LEI Legal Entity Identifier MIC Market Identifier Code MICA Market in Crypto Assets 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 MRMTL Most Relevant Market in Terms of Liquidity MTF Multilateral Trading Facility NCAs National Competent Authorities OTC Over-The-Counter OTF Organised Trading Facility PM Price Multiplier RCA Relevant Competent Authority RM Regulated Market

ESMA - 201-203 rue de Bercy - CS 80910 - 75589 Paris Cedex 12 - France - Tel. +33 (0) 1 58 36 43 21 - www.esma.europa.eu 4 RTS Regulatory Technical Standard RTS 1 Commission Delegated Regulation (EU) 2017/587 RTS 22 Commission Delegated Regulation (EU) 2017/590 RTS 23 Commission Delegated Regulation (EU) 2017/585 RTS 24 Commission Delegated Regulation (EU) 2017/580 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 SI Systematic Internalisers TIC Transaction Identification Code TOTV Instruments Traded On a Trading Venue TPAC Packaged Trade TV Trading Venue TVTIC Trading Venue Transaction Identification Code UPI Unique Product Identifier uTOTV Instruments (Derivatives) whose Underlying is Traded on a Trading Venue

Table of Contents
1 Executive Summary ....................................................................................................9
2 Context and objective of this publication....................................................................11
Part 1: Amendments to RTS 22........................................................................................13
3 Feedback statement on the proposal of amending RTS 22 .......................................13
3.1 Scope of the reporting........................................................................................13
3.1.1 Background.................................................................................................13
3.1.2 Feedback statement Q1 ..............................................................................15
3.2 Amendments stemming from L1 changes of Art. 26 ...........................................17
3.2.1 Amendments to Article 16 of RTS 22 - most relevant market in terms of liquidity
3.2.1.1 Background..........................................................................................17
3.2.1.2 Alignment to MRMTL............................................................................17
3.2.1.3 Feedback statement Q2-Q3 .................................................................18
3.2.1.4 Emission allowances and units in CIUs other than ETFs......................19
3.2.1.5 Feedback statement Q4.......................................................................19
3.2.1.6 Equity instruments in the first year of admission...................................19
3.2.1.7 Feedback statement Q5.......................................................................19
3.2.1.8 Determination rules for instruments not traded on trading venues falling
under Art.8a(2).......................................................................................................20
3.2.1.9 Feedback statement Q6.......................................................................20
3.2.1.10 Other enhancements on rules for index derivatives and depositary
receipts 21
3.2.1.11 Feedback statement Q7.......................................................................21
3.2.2 New fields according to the revised Art.26(3) and 26(9)(c),(j)......................22
3.2.2.1 Effective date .......................................................................................22
3.2.2.2 Feedback statement Q8-Q9 .................................................................22
3.2.2.3 Entity subject to the reporting obligation...............................................23
3.2.2.4 Feedback statement Q10 .....................................................................24

3.2.2.5 TVTIC ..................................................................................................25
3.2.2.6 Feedback statement Q11-Q16 .............................................................26
3.2.2.7 INTC Identifier......................................................................................35
3.2.2.8 Feedback statement Q17-Q18 .............................................................35
3.2.2.9 Chain Identifier.....................................................................................38
3.2.2.10 Feedback statement Q19-Q20 .............................................................38
3.2.2.11 Amendment for defining relevant categories of indices.........................41
3.2.2.12 Feedback statement Q21 .....................................................................41
3.2.2.13 Date by which transactions are to be reported .....................................41
3.2.2.14 Feedback statement Q22 .....................................................................42
3.2.2.15 Amendments to align the reporting requirements with EMIR and SFTR
and with international standards ............................................................................43
3.2.2.16 Feedback statement Q23-Q24 .............................................................43
3.2.2.17 Alignment of reporting of direction........................................................48
3.2.2.18 Feedback statement Q25 .....................................................................48
3.2.2.19 Alignment of reporting of price..............................................................50
3.2.2.20 Feedback statement Q26 .....................................................................50
3.2.2.21 Alignment of reporting of complex trade component ID ........................52
3.2.2.22 Feedback statement Q27-Q28 .............................................................52
3.3 Other enhancements..........................................................................................54
3.3.1 DLT financial instruments (DTI)...................................................................54
3.3.2 Feedback statement Q29 ............................................................................54
3.3.3 Amendments to clarify Article 4: on transmission of an order ......................56
3.3.4 Feedback statement Q30 ............................................................................56
3.3.5 Amendments to clarify Article 7: details for the decision maker in the case of
investment decisions taken by portfolio / fund managers...........................................58
3.3.6 Feedback statement Q31 ............................................................................58
3.3.7 Amendments in data fields linked to reference data changes according to Art.
27 59
3.3.8 Feedback statement Q32 ............................................................................59

3.3.9 New fields to be added in Table 2 Annex I ..................................................62
3.3.10 Feedback statement Q33 ............................................................................62
3.3.11 Fields to be amended in Table 2 of Annex I and Annex II............................65
3.3.12 Feedback statement Q34 ............................................................................68
3.3.13 Fields to be removed in Table 2 of Annex I .................................................71
3.3.14 Feedback statement Q35 ............................................................................71
3.4 List of exempted transactions (Art. 2(5) of RTS 22)............................................71
3.4.1 Disposal of financial instruments in the context of liquidation / bankruptcy /
insolvency procedures...............................................................................................71
3.4.2 Feedback statement Q36-37.......................................................................71
3.4.3 Auctions in emission allowances .................................................................73
3.4.4 Feedback statement Q38 ............................................................................73
3.4.5 Novations having clearing purpose..............................................................74
3.4.6 Feedback statement Q39 ............................................................................74
3.5 Format for reporting............................................................................................75
3.5.1 Feedback statement Q40 ............................................................................75
3.6 Use of transaction data for transparency and volume cap calculations...............76
3.6.1 Feedback statement Q41-Q43 ....................................................................77
Part 2: Amendments to RTS 24........................................................................................80
4 Feedback statement on the proposals of amending RTS 24 .....................................80
4.1 Amendments stemming from L1 changes – format for reporting.........................80
4.1.1 Feedback statement Q44-45.......................................................................80
4.2 Amendments in data fields stemming from changes in RTS 22..........................82
4.2.1 Feedback statement Q46 ............................................................................83
4.3 Other enhancements in data fields .....................................................................83
4.3.1 Feedback statement Q47-Q49 ....................................................................84
5 Conclusions...............................................................................................................86

1 Executive Summary
Reasons for publication
The revised text 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 Consultation on October 20241 which included proposals for the amendment of Regulatory Technical Standards specifying the requirements on transaction data under Art.26 of MiFIR (RTS 22) and order book data under Art.25 MiFIR (RTS 24). Following the feedback received, with the objective to reduce burden to market participants, ESMA decided to not propose any changes to the existing RTSs 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). Contents This FR provides a summary of the feedback to the consultation. The first section of the Final Report (Context and objective of this publication) explains the content of the document and the rationale for not proposing amendments to the current text of RTS 22 and RTS 24. The other sections include a summary of the relevant feedback resulting from the consultation. The first part focuses on RTS 22 (Part 1) and summarises the feedback received on the following topics: the scope and changes stemming from the revised L1 (Section 3.1 and 3.2); other changes as further enhancements to fields (Section 3.3); exempted transactions from the reporting (Section 3.4), format for reporting (Section 3.5); and use of transaction data for transparency and double volume cap calculations (Section 3.6). The second part of this FR focuses on RTS 24 (Part 2) and summarises the feedback received on the following topics: amendments stemming from the revised L1 (Section 4.1) on format empowerment; the changes linked to RTS 22 (Section 4.2) and other enhancements to the order book data elements (Section 4.3).

Next Steps
This FR does not include proposed changes to the existing RTSs 22 and 24. The feedback received to the consultation and summarised in the FR will serve as valuable input in the context of the comprehensive review. 1 ESMA12-2121844265-3745 Consultation Paper - Review of RTS 22 on transaction data reporting under Art. 26 and RTS 24 on order book data to be maintained under Art. 25 of MiFIR https://www.esma.europa.eu/sites/default/files/2024-10/ESMA12- 2121844265-3745_Consultation_Paper_Review_of_RTS_22_on_transaction_data_reporting.pdf 2 ESMA12-437499640-3021 Call for Evidence on a comprehensive approach for the simplification of financial transaction reporting

2 Context and objective of this publication

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 October 20243 which included proposals for the amendment of the L2 provisions specifying the requirements on transaction reporting under Art.26 of MiFIR (RTS 22) and order book data under Art.25 of MiFIR (RTS 24).
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 SMEs 4 . 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 .
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 (MiFIR 6 ) for transactions in financial instruments, European Market Infrastructure Regulation (EMIR7 ) for derivatives transactions, and Securities Financing Transactions Regulation (SFTR8 ).
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.
Based on feedback received from market participants during the reviews of the L2
reporting technical standards related to these reporting frameworks, including of RTS 3 ESMA12-2121844265-3745 Consultation Paper - Review of RTS 22 on transaction data reporting under Art. 26 and RTS 24 on order book data to be maintained under Art. 25 of MiFIR https://www.esma.europa.eu/sites/default/files/2024-10/ESMA12- 2121844265-3745_Consultation_Paper_Review_of_RTS_22_on_transaction_data_reporting.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

22, 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 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 RTSs 22 and 24 nor includes a draft RTS for submission to the European Commission. The Final Report includes a summary of the responses received to the Consultation. As further detailed in the document the feedback received was quite negative on some aspects, pointing at limitations of the current regime and as such supporting the need to rethink from a broader perspective the regulatory reporting framework before implementing amendments to the technical standards. It is relevant to note that 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, 22 and 24 the same approach has been applied to the review of RTS 22 and 24 as done for RTS 23. Please refer to the relevant Final Report for specific considerations on RTS 2313 .
9. Finally, it is important to explain how the regime will work on the basis of the current
RTS 22 and 24. In this respect, ESMA issued a public statement14 in March 2024. This statement builds on the EC interpretative notice15 and clarifies that until the revised RTSs becomes applicable, the Level 1 rules in force prior to the MiFIR review— together with RTS 22 and 24 —will continue to apply.
Part 1: Amendments to RTS 22
3 Feedback statement on the proposal of amending RTS
3.1 Scope of the reporting
3.1.1 Background
10. The revised MiFIR expands the scope of transactions that must be reported, in
particular concerning derivatives. Under the updated text of Article 26(2), OTC derivative transactions, except those specified in Article 8a(2), must be reported only when executed on a trading venue. The revised Regulation introduces additional 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. The order record keeping requirements apply to Investment Firms and Trading Venues in relation to all orders and all transactions in financial instruments which they have carried out, as well as to all orders in financial instruments which are advertised through their systems, pursuant to Article 25(1) and (2). Therefore, a subset of data are interlinked with the reference data reported according to Art.27 and pertain to the transactions reported under Art.26 of MiFIR. Most importantly, these data supplement the transaction data available to NCAs and ESMA, as the data elements made available to the NCAs and prescribed in RTS 24 include the details and information that link the orders with executed transactions under the scope of Article 26(1) and (3). 13 ESMA12-2121844265-384 Final Report on RTS 23 on supply of reference data under Art.27 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

reporting obligations for the OTC derivatives mentioned in Article 8a(2) that must be reported regardless of they are executed on a trading venue.
11. The new transactions defined in Art.8a(2) under the revised scope of MiFIR reporting
include certain OTC derivatives in euros, Japanese yen, US dollars, or pounds sterling that:

are subject to clearing obligations, are centrally cleared, and have specific
contract tenors for IRS (e.g., 1, 2, 3, 5, 7, 10, 12, 15, 20, 25, or 30 years).
are single-name credit default swaps (CDS) referencing a globally systemically
important bank and are centrally cleared.
are CDS referencing an index of globally systemically important banks and are
centrally cleared.

The first figure below represents a decision tree illustrating which transactions are in
scope of the revised Article 26(2), whilst the following figure is a comparison of the transactions in scope of reporting under the current and the revised requirements.
Figure 1. Decision tree of transactions in scope of the revised Article 26(2).
Figure 2. Comparison of the transactions in scope of reporting under the current and
revised requirements.

3.1.2 Feedback statement Q1
Q01: Are any other adjustments needed to enable comprehensive and accurate reporting of transactions which will enter into scope of the revised Article 26(2)?
15. Several respondents asked for additional clarity about the notion of centrally cleared.
Some respondents asked whether that would include transactions for which the parties have voluntarily decided to centrally clear the contract, whilst others asked what the criteria are for determining whether a product is "centrally cleared”. Since many trades are accepted for clearing with some delay after execution, and waiting for clearance would not be compatible with reporting requirements; it was suggested by the respondents that transactions “for which there is an intention to clear” could be considered as “centrally cleared”. ESMA notes that there is no definition of “centrally cleared” other than a definition in EMIR indicating that to be centrally cleared a transaction needs to be cleared through a CCP. Furthermore, Article 8a paragraph 2(a) includes in the scope the OTC derivatives that “are centrally cleared”, in addition to those which are “subject to a clearing obligation”. Therefore, both voluntary clearance and transactions for which there is an intention to clear are transactions which should be considered “centrally cleared”.
16. One respondent noted that the current definition is difficult to interpret as, for example,
centrally cleared IRS transactions that are not TOTV may have to be reported by DPEs

under FIRDS. ESMA notes that based on the new Article 26 these transactions fall under art 8a(2) regardless of whether they are executed on a TV, therefore in principle they should be reported.
17. One respondent highlighted the importance of the timeliness and consistency between
the clearing process and post-trade transparency reporting requirements to avoid discrepancies, as well as the availability of ISINs created in FIRDS by Systematic Internalisers (SIs).
18. One respondent inquired about the possibility of extending the requirements of Article
26 to AIFMs and UCITS Management Companies, as mandated under Article 52(14)(b) of the MiFIR review. ESMA notes that for the time being there are no indications from the co-legislators on the intention to expand the scope of reporting to AIFMs and UCITS Management Companies.
19. One respondent argued that ISIN codes for instruments executed outside of trading
venues are very difficult to obtain. Therefore, and in the same vein as for FX transactions, they recommended limiting the reporting to the proposal of how to report such additional field. ESMA notes that it is not within ESMA’s remit to change the scope of the reporting obligation set in L1.
20. One respondent suggested refining the MIFIR reporting framework to allow for the
identification of the arranging broker, rather than only the executing members which play no role in the price discovery process, and recommended such information could be captured adding a new field in RTS 22.
21. One respondent asked for additional clarity on the reporting of transactions on spread
bets and Contracts for Difference (CFDs) under the revised Article 26(2), such as the specific fields for reporting (for example underlying asset, notional amount and the nature of the contract) and how to handle amendments or cancellations of these trades. ESMA notes that this level of detail is not suited for a L2 review and but should be provided in the L3 guidance.
22. Furthermore, respondents asked whether financial instruments where the underlying is
a basket composed of financial instruments that are traded on a trading venue are still in scope. ESMA confirms they should be in scope based on Article 26(2)(c).
23. Several respondents highlighted the need for clear and consistent identification of
GSIBs in the context of single-name credit default swaps referencing GSIB and asked ESMA to provide an official and regularly updated list of GSIB LEIs. Some respondents suggested that, alternatively or ad interim, the list of LEI prepared by ISDA could be used to ensure consistency or the list prepared by the Financial Stability Board (FSB).

For more clarifications on this matter the MiFIR Consultation Paper 416 issued by ESMA provides a detailed analysis.
3.2 Amendments stemming from L1 changes of Art. 26
3.2.1 Amendments to Article 16 of RTS 22 - most relevant market in terms of
liquidity
3.2.1.1 Background
24. The revised MiFIR Article 26(1) requires NCAs to ensure that transaction reports are
sent to multiple relevant authorities, including those supervising the most relevant market in terms of liquidity, the transmitting investment firm, branches, and trading venues.
25. RTS 22 establishes criteria for determining the "Most Relevant Market in Terms of
Liquidity" (MRMTL) and "Relevant Competent Authority" (RCA). ESMA’s proposal in the CP was aligning the RCA determination with MiFIR's MRMTL concept, revising the rules to cover a broader range of instruments, and addressing deficiencies in the current application, particularly for equity instruments.
3.2.1.2 Alignment to MRMTL
26. The consultation paper highlighted discrepancies in the determination of the MRMTL
and the RCA for equity instruments. Currently, MRMTL is determined by the venue with the highest turnover, while the RCA is identified as the authority of the regulated market (RM) with the highest turnover, even if the instrument has higher turnover on a multilateral trading facility (MTF). This divergence results in some cases where the RCA is not the authority competent to supervise the MRMTL.
27. The consultation explored two proposals: (1) aligning the determination of the RCA to
the MRMTL concept, without prioritizing regulated markets, and (2) modifying the RCA determination to give priority to the regulated market of first admission to trading, instead of using turnover as the main factor. 16 ESMA74-2134169708-7311 Consultation Paper on transparency for derivatives, package orders and input/output data for the derivatives consolidated tape https://www.esma.europa.eu/sites/default/files/2025-04/ESMA74-2134169708- 7311_MiFIR_Review_Consultation_Package_4_-Derivatives__Transparency__CTP_Input_Output.pdf

3.2.1.3 Feedback statement Q2-Q3
Q02: Does the existing divergence in the implementation of the MRMTL concept under Art. 4 and Art. 26 of MiFIR results in any practical challenges for the market participants? If so, please explain the nature of these challenges and provide examples.
28. Limited feedback was received, with most respondents, primarily banks and venues
that submit transaction reports for non-MiFID firms, indicating that the divergence in MRMTL implementation under MiFIR Articles 4 and 26 has minimal impact. One respondent noted that the main effect of MRMTL alignment would be on Approved Reporting Mechanisms (ARMs). Some market participants, particularly those operating across both the UK and the EU, may be impacted by the change as should need to maintain separate systems to manage different MRMTL interpretations, potentially leading to increased costs and a higher risk of errors. Q03. To what extent the rules applied for the determination of the RCA and RCA_MIC are relevant for your operations? Do you agree with the potential alignment of the RCA rules with the RCA_MIC rules for equities? Please provide details in your answer.
29. The question received limited feedback; however, most respondents supported
aligning the RCA rules with the RCA_MIC rules for equities outlining the potential advantages (such as improved data availability, quality, and accuracy). However, a few respondents opposed shifting from a liquidity-based calculations to an approach that uses the date of listing (RCA MIC). The main concern raised was the potential decrease of supervisory monitoring, where the former RCA calculated under the original framework might lose responsibility over market abuse or insider trading investigations, which could lead to confusion and regulatory gaps. Additionally, some respondents noted that focusing only on primary markets might not fully reflect the liquidity or other trading characteristics of certain instruments.
30. A few respondents acknowledged that this question primarily concerns market
authorities, as the rules for determining the RCA and the RCA_MIC are not currently perceived relevant for market participants. Authorities have expressed a preference for retaining the current rule for which the liquidity is the primary criterion for determining the RCA and the RCA_MIC, thereby supporting the status quo. They emphasized that liquidity-based assessments better reflect trading activity and help maintain existing regulatory responsibilities and supervisory competence.

3.2.1.4 Emission allowances and units in CIUs other than ETFs
31. Article 16 of RTS 22 states that the RCA determination for equities, emission
allowances, and CIUs should be based on turnover, as defined in RTS 1. However, MRMTL calculations under RTS 1 do not cover emission allowances or CIUs, except ETFs, leading to missing turnover data for these instruments.
32. Currently, their RCA is determined applying a residual rule based on the venue of first
admission to trading. Since these instruments are not subject to pre-trade transparency, it was proposed to amend the rule to align with current practices and refer to the venue of first admission to trading.
3.2.1.5 Feedback statement Q4
Q04: Do you agree with the proposed RCA determination rule for emission allowances and CIUs other than ETFs? Please provide details in your answer.
33. The feedback on this question was limited, and respondents generally supported the
proposed RCA determination rule. No significant concerns were raised, and no alternative methodologies for RCA determination were suggested.
3.2.1.6 Equity instruments in the first year of admission
34. To address limitations in RCA determination for equity instruments in their first year of
admission, Article 16(2) of RTS 22 currently relies on the first market where admission to trading was requested or the instrument was first traded. However, incorrect or inconsistent reporting to ESMA’s FIRDS system has led to inaccurate RCA determinations.
35. To solve this, it was proposed in the CP that until sufficient turnover data was available,
the RCA should have been identified as the competent authority of the regulated market where the instrument was first admitted to trading. In case the instrument was not traded on a regulated market, the MRMTL should have been determined taking into consideration the relevant MTFs.
3.2.1.7 Feedback statement Q5
Q05: Do you agree with the proposed RCA determination rule for equities for which no sufficient data is available to calculate the turnover? Please provide details in your answer.

The feedback showed broad support for the proposed RCA determination rule, with
respondents appreciating its simplicity and clarity. Some requested a clear list that qualifies what are the first admission operations, emphasizing that capital increases resulting in new ISINs, such as those arising from mergers, splits, or other corporate actions, should not be treated as new admissions to trading. They also highlighted the importance of linking old and new ISINs to maintain MRMTL continuity.
3.2.1.8 Determination rules for instruments not traded on trading venues falling
under Art.8a(2)
ESMA identified gaps in the current RCA determination rules for certain derivatives
subject to transaction reporting under Article 26(2)(d) of MiFIR, particularly for Interest Rate Derivatives (IRDs) and Credit Default Swaps (CDS). Existing rules do not apply effectively due to the absence of an issuer, the nature of underlying benchmarks, and the scope of reporting obligations.
To address these issues, ESMA proposed in the CP the following approaches:

For CDS on specific debt obligations: maintain the current RCA rule, assigning the
competent authority of the most relevant market in terms of liquidity for the underlying security.
For CDS on reference entities: assign the RCA based on the Member State where
the reference entity has its registered office.
For CDS on indexes: determine the RCA based on the authority supervising the
benchmark administrator.
For the remaining CDS and IRDs traded on a venue: apply the RCA rule based on
the venue of first trading or first admission to trading.
For the remaining CDS and IRDs not traded on a venue: the MRMTL concept would
not apply, and transaction reports would only be shared with the NCAs responsible for the transmitting investment firms and relevant branches.
3.2.1.9 Feedback statement Q6
Q06: Do you agree with the proposed RCA determination rules for the derivative contracts falling under Article 8a(2) of MiFIR? Please provide details in your answer.

The feedback on this proposal was limited and presented mixed views. Two
respondents supported the list of proposed RCA determination rules, considering them a reasonable approach for handling the relevant derivative contracts. Other respondents instead raised concerns. Two respondents found the rules overly complex and suggested that a simpler framework would be preferable; however, they did not elaborate on possible alternatives. Additionally, two respondents pointed out that certain scenarios were not adequately addressed, particularly cases where: (i) a singlename CDS references to a debt obligation of an issuer outside the EU-27, and (ii) an index CDS references to an index administered by a non-EU benchmark administrator. ESMA notes that the raised scenarios fall under categories and in Section 3.2.1.8 that covers the CDS and IRD traded on or off-venue.
3.2.1.10 Other enhancements on rules for index derivatives and depositary
receipts
For index derivatives, the current rule links the RCA to the venue of first admission to
trading, which does not always ensure that Competent Authorities receive data on derivatives referencing key national equity indices. To address this, ESMA proposed that the RCA should instead be the authority supervising the benchmark administrator. If the index is not covered by the Benchmark Regulation (BMR) and lacks a designated supervisory authority, the existing rule, assigning the RCA to the venue of first trading, would continue to apply.
For depositary receipts on equities, the current approach follows the same turnoverbased rules as shares. However, because depositary receipts do not always trade on
the same venues as their underlying shares, this could result in different RCA assignments for the two instruments. To resolve this, ESMA suggested that the RCA for depositary receipts should align with the RCA of the Most Relevant Market of the direct underlying share. In cases where the depositary receipt does not have a share as its direct underlying, existing rules would apply: if the underlying is another depositary receipt, the RCA follows that of the original receipt; if the underlying is a derivative, the RCA follows the venue of first admission or trading of the derivative.
3.2.1.11 Feedback statement Q7
Q07: Do you agree with the proposed amendments to RCA determination rules for index derivatives and depositary receipts?
The feedback on this proposal was limited. One trading venue supported the change,
while another venue and an association opposed it. Few respondents were against the proposal and raised concerns about jurisdictional implications, arguing that requiring

trading venues to report to a foreign authority would create unnecessary operational complexity. They also warned that shifting RCA determination to the authority supervising the benchmark administrator could lead to data fragmentation, making it harder for any single regulator to monitor market activity effectively. Additionally, opponents highlighted the increased reporting burdens and oversight challenges, as moving away from a venue-based RCA system would require adjustments to reporting frameworks, potentially raising compliance costs. ESMA notes that the changes would not affect trading venues' reporting obligations, as the RCA framework solely determines the competent authority without altering existing reporting requirements. Additionally, NCAs already have arrangements in place to exchange data under Article 26(1) of the revised MiFIR, ensuring effective supervision without adding operational complexity.
3.2.2 New fields according to the revised Art.26(3) and 26(9)(c),(j)
3.2.2.1 Effective date
43. The revised Articles 26(3) and 26(9)(c) require transaction reports to include the
"Effective dates" of financial transactions. A new field indicating when the obligation under the transaction becomes effective was proposed in the CP line with EMIR Refit RTS (field 43 – Effective date). For debt instruments, the effective date has been identified as the settlement date. For derivatives contracts, instead it should be when the contract obligation starts, and might be a date identified in the future.
44. In the proposal made in the CP it is also specified that if the effective date is not stated
in the transaction’s contract, the information to be reported should be consistent with the execution date (RTS 22 field 28).
3.2.2.2 Feedback statement Q8-Q9
Q08: Do you have any further comment or suggestion in relation to the inclusion of a new field to capture the effective date in transaction reports?
45. The vast majority of respondents supported the introduction of the field “Effective date”
provided that its application is limited to derivatives. Other respondents claimed that the trade date should be sufficient for detecting market abuse for both equities and bonds and did not see any added value in applying this field to these asset classes.
46. Although one respondent was supportive to add the field “Effective date” for bonds,
another highlighted that settlement date is already provided in detail by CSDs to regulators via CSDR.

One respondent urged ESMA to clarify the definition of this new field, particularly where
a transaction provides for intermediary payments between the “Effective Date” and the “Maturity Date”.
The majority of respondents supported alignment of this field with EMIR field 43
“Effective date”.
However, one respondent argued that MiFIR has a definition of both “derivatives” and
“OTC” that is different to the EMIR definition of “OTC derivatives” and that therefore derivatives traded on MTFs and OTFs still qualify as “OTC derivatives,” despite not being OTC but rather as TOTV. ESMA notes that definition of OTC derivatives in EMIR and MIFIR are currently aligned following the MIFIR review.
One respondent believed that the “Execution Timestamp” provides precise information
about when a transaction occurs, and it seems redundant to introduce an additional field. Q09: Do you agree that the concept of effective date applies also to transactions in shares? If yes, should the intended settlement date be considered as the effective date? Please provide details in your answer.
None of the respondents agreed with the proposal that the concept of ”Effective date”
should apply also to transactions in shares. All respondents argued that the field is relevant only for derivates and that it would not be appropriate for this field to mean “Settlement date” in case of shares since the same logic should apply to all security types.
Several respondents specified that if equity should be included, the effective date
should be the execution date and not the settlement date, because an effective date is defined as the date at which obligation under the contract come into effect.
3.2.2.3 Entity subject to the reporting obligation
The revised L1 text of Art.26 (3) introduces a new data field to identify the entity subject
to the reporting obligation. This addition provides further oversight in cases where the executing entity, the submitting entity, and the responsible entity are different. The purpose of this new field is to identify which entity is ultimately responsible for the reporting.
Examples are when trading venues report on behalf of a member or a firm not subject
to MiFIR and relies on third parties for the submission. In such cases, the proposal in the CP was structured as follows: Field 4 contains the LEI of the executing entity that

is not subject to MiFIR, Field 6 includes the LEI of the third-party submitting entity, and the new field is expected to be populated with the LEI of the trading venue’s operator to indicate which entity has submitted the report.
3.2.2.4 Feedback statement Q10
Q10: Do you agree with the inclusion of this new field according to the analysed scenario? Please specify if you see additional cases to take into consideration in the definition of this new field.
55. The majority of respondents agreed that the new field is relevant for a specific scenario
where a trading venue is responsible for reporting a transaction via an Approved Reporting Mechanism because its member is not a MiFID entity. In such cases, the "Executing firm" would be the non -MiFID firm and the "Submitting firm" would be the ARM. Since the TV itself is not currently identified, the new field would help to cover this gap.
56. However, the same respondents outlined that they did not identify any other use case
for this field therefore were against ESMA expanding its application beyond this specific case scenario.
57. One respondent did not see a problem with inclusion of this field provided its definition
covers all the classes of contracts subject to the RTS.
58. Several respondents asked for additional clarity on the field definitions for fields 6 and
6b. One respondent flagged that from the consultation, it appears that the LEI of the Trading Venue Operator would populate both fields 6 and 6b in all the relevant TOTV cases and queried whether this is a duplicated field for TOTV trades, and whether more guidance is required. ESMA understands the concern, however the proposal was the only possible way to identify the relevant cases at hand.
59. One respondent suggested that the LEI of the concerned TV’s operator may be
deducible from the Segment -MIC already in the scope of reporting.
60. One respondent flagged that there is a similar field under both the SFTR and EMIR
regulations, titled 'entity responsible for the report'. As a result, if a new field is required, it should be aligned with the terminology currently in place for the EMIR / SFTR reporting regulations (i.e., from ‘entity subject to” to 'entity responsible for the report'). This member also flagged that under MiFID reporting it is infrequent to have an entity offering or providing delegated or assisted reporting.

One member suggested that if the field is only relevant for trading venues, it should be
associated directly with the TV and the field should be left blank for other entities.
One member noted that where a group operates both a TV and an ARM and may
submit TV reports under the LEI of the ARM, population of field 5 with ‘true/false’ might be useful to distinguish reports on behalf of ARM clients vs. Trading Venue reports.
ESMA notes that based on the feedback received the use cases of the field for the
identification of the entity responsible for the reporting appears limited.
3.2.2.5 TVTIC
MiFIR transaction data and its manipulation serve multiple purposes for regulators in
monitoring and supervising financial markets. To ensure proper use of these regulatory data, the aggregation process requires in-depth data cleaning and data quality. This is particularly important for identifying chains and aggregated order executions reports that are parts of the same transaction, reconstructing the full reporting path, determining the initial and consequently the final client of these partial reports. The creation of a new identifier to be included in the RTS 22 is relevant to reconstruct in a reliable manner the full history of the transaction applying a proper de-duplication approach, preventing overestimation of executed trades, and ensuring compliance with the revised Article 26 of MiFIR.
The consistent generation and transmission of new identifiers would enhance data
quality and comparability, improving the monitoring of complex financial transactions and reducing the need for additional regulatory inquiries.
The proposal for the Trading Venue Transaction Identification Code (TVTIC) presented
in the CP was to make mandatory the reporting of the code for all transactions on EEA trading venues, ensuring uniqueness, consistency, and anonymity in the requirement in line with the RTS 24. ESMA also proposed extending TVTIC reporting to non-EEA venues and introducing a new Transaction Identification Code (TIC) for off-venue transactions. For these two codes (TV TIC for non-EEA venues and TIC for off-venue transactions) it was also proposed a predefined syntax (a combination of a set of information together – please see 4.1.2.3. i) of the CP17 ) to further enhance the consistency across the entities for generating and disseminating these codes, including the identification of the responsible entities for their creation. 17 ESMA12-2121844265-3745 Consultation Paper on RTS 22 and 24 https://www.esma.europa.eu/sites/default/files/2024- 10/ESMA12-2121844265-3745_Consultation_Paper_Review_of_RTS_22_on_transaction_data_reporting.pdf

3.2.2.6 Feedback statement Q11-Q16
Q11: Do you agree with the assessment that the TVTIC reporting requirement applies to all type of on venue executed transactions (e.g., negotiated trades)?
67. Almost all market representatives agreed that the TVTIC reporting requirement should
apply to all types of on-venue executed transactions, including negotiated trades.
68. Three respondents pointed out that the guidelines state that when such trades are
brought onto the exchange they should be reported with the appropriate MIC code and, where applicable, the TVTIC. The same principle applies to negotiated trades executed off-book but still on-exchange, where the exchange’s MIC code should be used, and, if available, the TVTIC should be reported.
69. Another important aspect highlighted in the feedback was the need to ensure that to all
on-venue transactions a unique and consistent identifier had been allocated, regardless of the execution method. Two trading venues confirmed that they already assign a unique TVTIC to all transactions, including negotiated trades. However, respondents acknowledged internal operational challenges in ensuring the TVTIC’s consistency across trading venues, as some may not be able to provide the necessary information to the other counterparties or the concerned reporting entity. The feedback to address such issue was split among the respondents.
70. To address these challenges, some market participants suggested establishing a
harmonized methodology for generating TVTICs across all trading venues, along with standardized rules for their dissemination. This would enhance transparency and simplify the reporting process. One specific concern was that, in certain scenarios where brokers do not disseminate the TVTIC, the Investment Firms struggle to report in a timely and consistent manner.
71. In contrast, one market association proposed a more pragmatic approach, for
negotiated trades, where transactions are negotiated off-exchange but executed under the rules of a trading venue, the TVTIC field should remain optional, with both parties only required to report the MIC code of the trading venue. Along these lines, some feedback also recommended to provide comprehensive guidance before expanding the scope of TVTIC reporting requirements to all negotiated trades and non-EEA trading venues. For complex scenarios additional clarification and guidance was requested, such as when only one counterparty in a negotiated trade is a member or participant of the trading venue, or when an EU investment firm executes a client order on a non-EEA venue and therefore only single-sided reporting is expected.

Some respondents, representing trading venues, recommended leaving discretion to
venues while providing further guidance to investment firms for the correct reporting of the TVTIC. The trading venues expressed negative feedback in imposing a fixed syntax, arguing that instead of including additional reporting provisions, the proposal should focus only on improving consistency among venues that currently do not deliver the TVTICs in reliable manner. A predefined syntax and format, they warned, could require changes to the trading venues’ internal coding structures, leading to further backward compatibility issues rather than improving the overall harmonization.
A trading venue association suggested embedding the mutual recognition of the UTI
as an identifier within the reports. Some of the respondents confirmed that some venues already use the UTI internally as an alternate of TVTIC, and introducing a predefined syntax for TVTIC creation could force venues to provide two separate trade codes instead of one, increasing the data quality inconsistencies. One of the main recurring issues declared for the implementation of harmonised TVTICs is the inconsistent timing of the TVTIC’s dissemination by trading venues, particularly among OTFs trading bonds instruments. In some cases, delays are mainly caused by intermediaries, exposing then investment firms to risks of misreporting or underreporting.
Among respondents opposing to the extension of the TVTIC requirement to all onvenue transactions, including negotiated trades, the raised concerns were about the
potential introduction of stricter validation rules, which would create additional compliance burdens for the industry. Q12: Do you have views on how to improve the consistency of the reporting of TVTICs? Please provide your view on the proposal of making mandatory the reporting of such information in validation rules when the MIC code is provided.
The overall feedback was positive, with general support for the mandatory submission
of the TVTIC for transactions concluded on EEA venues when field 36 is populated with a valid venue MIC. According to two market representatives, specifying the requirement for such instances should not create practical issues, as it would be consistent with the current practices of trading venues that generate transaction reports for non-MiFID firms and have to comply with the ARMs' validation rules.
However, some market associations opposed the mandatory reporting of TVTIC for all
trade categories when a MIC code is provided. As suggested in Q11, a more pragmatic approach, similar to that of other non-EEA jurisdictions, should be adopted, aligning with UK trading venue practices. And for negotiated trades, the TVTIC field should be optional.
Regarding the consistency of TVTIC reporting, views were divided between potential
improvements and alternative approaches.
Market representatives reiterated feedback from Q11, emphasising that modifying the
TVTIC syntax would not resolve the existing data quality issues identified by regulators. Instead, regulatory guidance should ensure that entities correctly generate and report TVTICs in their submission.
Other respondents argued that a specific methodology or format for TVTIC generation
should not be mandated in L3, and instead, trading venues should have the flexibility to develop personalised TVTICs based on their own trading system architecture. Imposing a standardized approach could introduce unnecessary IT complexity without delivering clear benefits in terms of data quality e inconsistency across all venues. This view was shared by others, who stressed that the primary purpose of the TVTIC requirement is to create a unique transaction identifier at the level of an individual trading venue and trade while maintaining consistency and persistence per MIC and trading day. Each venue should remain only responsible for generating a valid and compliant TVTIC for its MICs.
Additionally, some considered the proposed changes to the wording used for the TVTIC
field definition as unnecessary. Concerns and requests of clarification were raised regarding the inclusion of condition (c) in the definition, which states that “its components should not disclose the identity of the counterparties.” Some respondents pointed out that the identity of the executing, submitting, buying, and selling entities is already disclosed. Another respondent confirmed that addressing a specific syntax would require significant costs for system’s development and testing.
Defining a common TVTIC syntax based on existing fields proposed in the CP, such
as ISIN, LEI/MIC, date, time, and quantity, does not appear ideal for the majority of respondents that are not in favour of implementing a predefined syntax. Authorities can already derive these values from transaction reports, and this approach does not guarantee uniqueness.
Regarding TVTIC syntax, trading venues currently use different approaches, often
relying on trade confirmation data elements that are not included in MiFIR transaction reporting fields.
While some respondents acknowledged that implementing TVTIC requirements poses
challenges, such as increased costs, IT infrastructure changes, and operational burdens, they recognise the advantages and long-term benefits. A TVTIC standardized methodology and transmission process could enhance reconciliation accuracy, improve data quality, and reduce asymmetries in supervisory tasks. Close collaboration

between regulators and trading venues was however, considered as essential to ensure the consistent and uniform provision of TVTICs.
84. Another response supported the proposal of defining a syntax that combines ISIN, LEI
of the generating entity, date, time, and quantity. This would harmonise the process while allowing counterparties to generate and share TVTICs independently if a nonEEA venue fails to comply with ESMA’s proposal. Among those advocating for a syntax-based approach for EEA venues, some prefer a simple and consistent logic that relies on readily available “execution-time” data.
85. One market representative suggested that trading venues should make available to the
public their internal TVTIC generation logic, allowing reporting entities to derive the correct TVTIC themselves. The same respondent recommended that EEA trading venues should be required to include TVTICs in the real-time electronic trade confirmations. Another respondent, in favour of changing validation rules, stressed that before making the reporting mandatory, it is crucial to resolve TVTIC inconsistencies in format and transmission mechanisms, particularly for OTFs.
86. Few respondents confirmed TVTIC should instead be a concatenation of elements
already reported under RTS 22 to reduce firms' burden of sourcing the TVTICs from multiple datasets. The suggested concatenation should include: “LEI/MIC Code of Execution Venue”, “LEI of Executing Entity”, ”CFI Code”, ”Instrument Identifier”, “Datetime of Trade Confirmation by the Executing Entity”.
87. Finally, some respondents reiterated the proposal stated in Q11 advocating for the
adoption of the UTI in the RTS 22 to replace the current TVTIC field.
88. ESMA notes that all concerns around format standardization, data quality, and
operational feasibility highlighted above provide a useful input irrespective of L2 changes. Q13: Do you have views on how to improve the consistency of the TVTIC (non-EEA TV TIC) generation process for transactions executed in non- EAA venue? Please provide your view on the proposed syntax methodology based on the already reported fields or suggest alternatives.
89. Very few respondents expressed their agreement in improving the consistency of
Trading Venue Transaction Identification Code across the border and expand the reporting provisions also to the non-EEA TVs for the reporting of a specific TIC code thorough the use of a common syntax that is based on a list of already reported information. A respondent - in favour of defining a unique and harmonized syntax for the TIC - proposed a different combination of existing data fields, including: trading

date, instrument identifier (such as ISIN), execution time, quantity, price, and venue identifier (such as MIC). They also emphasised the need for a fixed format, specifying character length, the order of components, and rules for special characters. Additionally, they highlighted the legal and operational challenges related to data privacy, particularly for trading venues operating across multiple EEA and non-EEA countries.
90. Another respondent suggested that incorporating the LEI as part of the TIC
methodology could reduce implementation efforts, especially for non-EEA trading venues, by facilitating the retrieval and dissemination of these codes to members. An industry representative recognised the benefits of reconciling data and reducing reporting inaccuracies, proposing a waterfall approach: if a non-EEA trading venue fails to generate and disseminate a TVTIC, counterparties should establish arrangements to ensure that a unique code is generated and shared within the execution chain.
91. Conversely, respondents opposing the proposal of enforcing the TIC code and defining
a specific syntax for non-EEA trading venues argued that such venues may neither create nor transmit the code to their members or participants, as they are not subject to EU law enforcement. Some also pointed out that combining existing data elements to build a unique TIC code could be cumbersome and create significant implementation challenges. They argued that authorities already have access to these data elements in their systems, making additional coding unnecessary to the industry.
92. Two respondents proposed an alternative a centralized approach at the NCA level for
generating the TIC code according to the proposed syntax. This approach would significantly reduce overall implementation costs and enhance supervisory activity and data quality. As a result, ESMA is encouraged to focus on harmonizing the existing TVTIC process within EU trading venues.
93. Another respondent noted that if a non-EEA venue were able to generate a TIC, it
would only be reported when the trading venue member falls within the scope of MiFIR obligations. Additionally, there are cases where a third-country intermediary acts as the executing broker for an EU investment firm. In such instances, the reconciliation based on TIC code would only be possible if both members on the non-EEA trading venue are subject to MiFIR reporting. According to some respondents, existing data fields could be already sufficient to de-duplicate reporting rather than creating a new combined data field to be reported.
94. Other respondents acknowledged the functional benefits of applying the same rules to
non-EEA trading venues to ensure consistency and maximize data utilization. However, they also recognized the limitations in enforcing this approach and instead advocated for revising validation rules. They suggested rejecting transactions executed

on a non-EEA venue when the TVTIC field is not reported. Such a change would likely impact both EEA and non-EEA trading venues, as many trading groups operate across both markets.
95. The generation and dissemination of a TIC code according to the proposed taxonomy
could lead to a proliferation of identifiers, adding another form of trade ID. Additionally, it was noted that the proposed syntax may not be always applicable, as ISIN is not universally used across the borders—for instance, by US trading venues for derivatives under Article 26(2)(b) and (c). In such cases, it is recommended to exclude ISIN from the concatenation of fields in the proposed syntax.
96. Another concern raised is that non-EEA venues may struggle to generate the TIC
accurately and in a timely manner, increasing compliance and implementation costs while affecting the quality of reported data. One respondent suggested using the UTI for trade matching; however, ESMA has previously clarified that the UTI is not a suitable candidate for linking transactions. The UTI was considered in the past for transaction report linking (see Section 12.3.1.2 of the Report issued in 2021 18 ), but ESMA determined that it is tailored for Trade Repositories reporting purposes and not aligned with the MiFIR reporting framework. This position was reinforced by the feedback received during the 2020 consultation.
97. Finally, another respondent proposed defining the requirement at a higher level, stating
that the identifier should be unique for the executing entity on a given day, while allowing firms to implement their own syntax as long as it meets this requirement. This approach would extend TVTIC reporting to non-EEA venues while making the field optional in such cases.
98. ESMA notes that the proposal is considered as impractical and burdensome based on
the respondents’ feedback and the various concerns raised for the reporting complexity of such new identifier. Q14: Do you agree with the proposal of identifying the non-EEA TV as the primary entity responsible for the creation of the non-EEA TV TIC code and for disseminating it?
99. The respondents indicated that if the TIC were to be introduced, the non-EEA trading
venue should be the primary entity responsible for executing and reporting transactions. This includes generating the TVTIC code and disseminating it. Identifying 18 Final Report - MiFIR review report on the obligations to report transactions and reference data https://www.esma.europa.eu/sites/default/files/library/esma74-362-1013_final_report_mifir_review_-_data_reporting.pdf

the trading venue as the primary source of trade information and assigning it the responsibility for creating the code as the "point of origin" aligns with the existing approach for EEA trading venues and is considered a logical conclusion. In such a case, the new field 3a “TIC” should not be defined as a mandatory field in the validation rules.
100. One respondent suggested that while the non-EEA TV may bear primary
responsibility, as a fallback, market-facing parties should derive the TVTIC themselves if the non-EEA TV is unwilling to share it.
101. On the other hand, the majority of the respondents opposing the proposal
highlighted enforcement challenges due to non-EEA firms not being subject to the same regulatory requirements. They pointed out significant implementation and reporting issues, as flagged in responses to Question 13. Specifically, challenges arise from the inability of non-EEA TVs to generate, maintain, and disseminate the TVTIC. Imposing this obligation on firms trading on non-EEA venues is deemed unfeasible, as these firms are not subject to MiFID II regulations and have no legal requirement to comply. Additionally, they may lack the necessary infrastructure or incentive to do so. Introducing a dedicated TIC code based on a specific syntax would further complicate the reporting process.
102. Some respondents emphasized the need to focus mainly on the harmonisation
the existing TVTIC process within EEA trading venues to ensure consistency and reliability before extending additional requirements to non-EEA platforms. The proposal to define a standardized TVTIC syntax across all EEA venues was not included, as ESMA, in collaboration with NCAs, had already conducted in the past a comprehensive assessment of the methodologies and internal processes used by EU venues to generate the TVTIC. The assessment concluded that the current operational arrangements were sound and effective for data reconciliation.
103. ESMA notes the general opposition to the proposal for a new TV TIC for nonEEA venues in its current form.
Q15: Do you have any further comment or suggestion in relation to the definition of a new transaction identification code (TIC) for off venue transactions? Please provide your view for the proposed syntax methodology for creating the TIC based on the already reported fields or suggest alternatives.
104. Most respondents strongly opposed the proposal of introducing a new TIC for
off-venue transactions. While some respondents acknowledged the need for a common approach to report consistently both on-venue and off-venue transactions to ensure

uniform market surveillance, they did not support the introduction of a new Transaction Identification Code (TIC) for off-venue transactions.
105. No practical alternative solutions were proposed, as the industry does not
consider this measure the most effective. Instead, respondents emphasised that introducing a new identifier would add unnecessary complexity and increase reporting costs.
106. As an alternative, some feedback suggested implementing the UTI code in
transaction reports, while one respondent recommended incorporating the UPI as an additional data element in the syntax to facilitate the trade matching. Another suggestion was to use the "Transaction Reference Number" in combination with the EMIR UTI approach, reconciling also the LEIs of the counterparties.
107. ESMA has already addressed the shortcomings in relation to the use of the UTI
in MiFIR in response to Question 13.
108. A market association opposing the TIC field proposed that, if ESMA were to
introduce a non-EEA TIC code, it should instead require the LEIs of both the transaction generator and the counterparty. This approach would enable firms to generate reports independently without relying on counterparties to provide a specific code. Additionally, it was suggested that inconsistencies in the time field of the proposed TIC syntax could be minimized by standardizing the format as hh:mm, given that reported time values may differ between parties.
109. Regarding the proposed syntax, one respondent highlighted that not all
instruments have ISINs, suggesting that the TIC code should be unique at the executing entity level for a given day, while allowing firms flexibility in choosing their syntax implementation. Some market representatives agreed on using the LEI along with other available information to define a syntax. Another respondent supported including the date, time, LEI, and ISIN but argued against incorporating quantity, as it does not contribute to creating a unique TIC code. To enhance readability, a suggestion was made to use separators between data elements in the syntax.
110. Finally, a centralized approach at the NCA’s level was proposed for deriving the
TIC by concatenating the relevant fields. According to the industry, this method could reduce reporting complexity and alleviate the burden on market participants.
111. Most respondents did not agree with the definition the TIC for off-venue
transaction; at the same time respondents did not provide concrete comments or specific alternatives to the suggested syntax. ESMA notes the inclusion of the TIC for

off-venue transaction was strongly opposed, including the developments of a harmonised syntax in the L3. Q16: Do you agree with the proposal of identifying the “market facing” firm acting as the seller as the primary entity responsible for the creation of the TIC code of off– venue transactions and for disseminating it to the other “market facing” firm acting as the buyer?
112. The majority of respondents reiterated their disagreement with the proposal for
a TIC for off-venue transactions, considering it impracticable. Consequently, the proposal to identify the "market-facing" firm acting as the seller as the primary entity responsible for creating the TIC code was not supported. Some respondents believe that NCAs should generate a TIC centrally and concatenating the existing fields if it is deemed necessary.
113. If the TIC for off-venue transactions were included in RTS 22 reporting, a
uniform syntax should be defined to enable all firms to generate a TIC autonomously. According to respondents, this approach would eliminate the need to designate a specific entity responsible for TIC creation and distribution, thereby streamlining the process and enhancing transaction identification accuracy and efficiency.
114. However, ESMA has already clarified in the CP that it is essential to identify the
entity responsible for generating the code, as imposing a uniform syntax across all parties involved in the transaction could lead to increasing inefficiencies or data quality issues. This view is supported by feedback from four market representatives, who agreed that, if a TIC code were implemented, the responsibility for generating the TVTIC for off-venue transactions should lie with a market-facing firm (i.e., any counterparty to a transaction, regardless of whether they are the seller or buyer).
115. One respondent suggested that the person executing the trade should generate
the TIC but raised concerns about cases where an order is routed through a chain of brokers. In such scenarios, the execution flow could make it challenging for the client (as the seller) to determine which broker executed the OTC transaction. The client would need to generate a TIC and transmit it back up the chain, a process that is difficult to implement in practice.
116. Another challenge in assigning responsibility for TIC generation and
dissemination arises when the concepts of "seller" or "buyer" do not apply, such as in derivatives, FX, money markets, spreads, or complex instruments. Additionally, certain cases involve trade counterparties that are not MiFID firms, act as agents, or involve more than two simple counterparties.

3.2.2.7 INTC Identifier
117. ESMA proposed in the CP the introduction of a new identification code (INTC
identifier) to link aggregated orders when Buyer or Seller Identification Codes (fields 7 – ‘Buyer identification code’, 7a – ‘Receiver of leg 1 identification code’,7b – ‘Receiver of leg 2 identification code ‘ or 16 – ‘Seller identification code’, 16a – ‘Payer of leg 1 identification code’,16b –’Payer of leg 2 identification code’) are reported as INTC. This code enables investment firms to connect market-side transactions with corresponding client allocations, ensuring accurate reporting of the executed aggregated orders. Previous consultations confirmed that implementation would be manageable since it only requires internal processing by the executing firm. Given that TVTIC alone is insufficient for linking transaction reports in cases of aggregated orders or OTC executions, the new identifier might provide further consistency across the data. In the proposal, ESMA asked feedback on a prescribed methodology for the creation of the new INTC codes (7c - ‘INTC Internal Code Identifier- Buyer’ and 16c - ‘INTC Internal Code Identifier- Seller’) that incorporates key elements such as the executing entity’s LEI, trade date, time, and ISIN.
3.2.2.8 Feedback statement Q17-Q18
Q17: Do you have any further comment or suggestion in relation to the inclusion of a new field (INTC identifier) to capture in detail the aggregate orders? Please provide views on the proposed methodology for defining a common syntax or suggest valuable alternatives.
118. The feedback on the inclusion of a unique INTC identifier highlighted both
potential benefits and concerns with a predominantly view suggesting keeping the proposal of introducing the INTC linking code without defining a prescriptive methodology for its creation.
119. Some respondents provided feedback on amendments to the field description
(Field 7c, Table 2, Annex I, RTS 22) for ensuring consistency.
120. Respondents in favour of the proposal recognised that introducing an INTC
identifier would enhance transaction reporting by strengthening the link between market-side and client-side executions of aggregated orders. However, they acknowledged that reconciling these elements is complex, as the process involves multiple transactions and partial executions across different transaction legs. A standardized syntax may not be sufficient, as to apply a successful reconciliation process would require significant coordination among the entities involved in various trade phases. Without this coordination, there is risk of incurring in errors during the

code’s generation and mismatched reports, which could further complicate the transaction reports’ reconciliation processes, particularly for high trade volumes or complex transactions.
121. Some of the respondents who supported the proposal suggested alternatives
to the proposed syntax (i.e. LEI+Date+Time+ISIN). Two respondents indicated that while it is feasible to populate fields 7c “INTC Internal Code Identifier – Buyer” and 16c “INTC Internal Code Identifier – Seller”, the inclusion of “time” data point in the identifier is problematic, as multiple transactions can occur throughout the day at different times. Instead, they proposed the implementation of a generic alphanumeric internal ID similar to the “Package Identifier” field that is used for complex trades. Another institution did not agree in considering the trade date and time in the syntax of the INTC identifier, arguing that trades executed in parallel may contribute to different aggregated orders. Instead, they suggested using the order submission date and time. One respondent found the proposed syntax redundant and unworkable, citing that: i) not all instruments have ISINs, ii) where the ISINs exist, they may not uniquely identify the traded instrument, iii) the syntax replicates data already available in other transaction report fields. Other respondents emphasised that investment firms have different methods for allocating the executions to clients. They recommended avoiding overly prescriptive formatting requirements and allowing firms to generate the identifier using their existing internal alphanumeric codes. This would imply to do not prescribe a precise syntax or methodology to generate the INTC code.
122. Instead of mandating a new identifier, another group of respondents suggested
leveraging existing information, defining a high-level requirement for uniqueness per executing entity, and leaving firms free to determine the specific syntax to be used.
123. Another alternative proposed was combining the UTI format with the LEI of the
issuing entity, particularly for derivatives, to promote international alignment and avoid an EU-specific syntax.
124. Others suggested leveraging existing identifiers, such as the “Transaction
reference number” (field 2), which they believe allows regulators to track OTC aggregated orders and related market executions, particularly when trading venues employ similar reporting strategies.
125. Lastly, as in the previous replies, some respondents questioned the necessity
of tracking additional data points, arguing that the INTC identifier would only impose additional operational burden without clear benefits. Among the respondents not in favour of the proposal, the view of few stakeholders is that NCAs should be able to link themselves the market-side and client-side executions and proposed an alternative approach that directly associates complex aggregated orders with the buyer and seller

fields, in line with one of the FCA Discussion Paper’s options (see Section 5.48 of FCA’s DP19).
126. Other respondents raised concerns about the feasibility and necessity of the
INTC identifier.
127. Some respondents suggested limiting transaction reporting by trading venues
to the "market -side", i.e. without any allocations. Some other respondents requested detailed guidance on reporting complex scenarios and integrating the reporting of the INTC identifier with the TVTIC and Chain ID fields. Respondents argued that if a Chain Identifier were introduced, the INTC identifier would become redundant, as the link between execution and aggregation would already be clear when MIC is reported as XOFF.
128. Additional concerns were raised regarding the difficulty and costs of gathering
data from external sources or firms not subject to MiFIR. The TVs may lack the necessary information to generate the INTC identifier, leading to incomplete reporting and an inability to validate third-party data. Some respondents outlined the impact on overall data quality, increased IT implementation costs, and potential data privacy violations.
129. Some suggested qualifying the INTC field as optional rather than mandatory.
Q18: Do you agree that the executing investment firm should be responsible for generating consistently the INTC identifier?
130. The majority of respondents supported the assessment that the executing
investment firm should be responsible for consistently generating the INTC identifier. However, consistently with the feedback received for Q17, several institutions raised concerns and additional considerations.
131. Among those that supported the identifier, some opposed to a common and
fixed syntax, and others suggested allowing firms to generate the INTC code according to their own internal systems.
132. Several respondents stressed the need to clarify the definition of "executing
investment firm" to avoid operational confusion and others instead suggested that the 19 DP24/2 Improving the UK transaction reporting regime https://www.fca.org.uk/publication/discussion/dp24-2.pdf

responsible entity should be the entity submitting the transaction report, not necessarily the broker or another intermediary.
133. The institutions and trading venues raised concerns and disagreed with the
proposal arguing that it would increase the reporting burden that a new identifier would create, especially on non-EEA entities and could also harm the market competitiveness. One respondent pointed out that assigning an identifier retroactively to existing orders could be challenging and may disrupt existing data flows.
134. As stated in the feedback submitted for Q17, several institutions suggested that
ESMA should limit the reporting only to the "market-side" transactions to avoid unnecessary complexity.
135. Other opposing to the proposal requested formal ESMA guidance on the
implementation of the INTC identifier along the lines of the same feedback provided for Q17.
3.2.2.9 Chain Identifier
136. ESMA proposes a new Chain Identifier code to link transaction report chains,
especially when an order is transmitted between firms for execution and fall under the definition of an order within the meaning of Art. 4 of RTS 22 (e.g. the conditions for transmissions are satisfied with fields 25 is “false” and fields 26 and 27 are not populated). The goal is to connect all transaction reports that are part of the same chain, preventing issues of double counting and ensuring accuracy in linking the buyer and seller. The code should be transmitted across all counterparties in the chain, starting with the executing firm and passed down until the final reporting entity. The Chain Identifier should be unique per transaction and per trade date. ESMA acknowledges challenges for non-MiFIR and non-EEA entities in transmitting this code and asked feedback to improve its implementation across both EEA and non-EEA markets. The proposed methodology for generating the code includes combining relevant identifiers like LEI, ISIN, price, and quantity.
3.2.2.10 Feedback statement Q19-Q20
Q19: Do you agree with the proposal of how to report such additional field to identify and link chains in transaction reports? Please provide views on the key information to be considered for defining a common methodology for the syntax. Otherwise, please suggest alternatives for defining it and improve the linking process among chains.

All respondents to the consultation, whilst sympathising with ESMA’s intention,
found the proposal impracticable. The arguments they raised were the following:

Aggregating multiple executions means that multiple chains are combined in one
report; this would require a repetitive structure in the reporting file and dozens of chain identifiers would have to be reported in this field, which would be very burdensome if not impossible to report across the chain.
The proposal would mean that all entities within a given chain would pass the code
across all counterparties involved in the chain flow and this would put significant strain on entities at the tail end of the chain and may threaten their ability to satisfy the t+1 reporting deadline.
Adopting the Chain Identifier would severely limit a firm’s ability to conduct real-time
reporting.
Execution confirmations are not suitable for transmitting the ID in time for the
production of the report. There is no link between producing transaction reports and receiving execution confirmations. These are two independent processes that are not synchronised in terms of content or timing.
For this identifier to be successfully implemented, transmission of the chain
identifier would need to be a real-time process, for example, via real-time execution confirmations and messaging services do not currently support this.
The proposal is very problematic in case of entities not subject to reporting (for
example non-EEA firms) forming part of the chain.
Creating identifier during order transmission offers immediate linkage of related
orders and easier tracking of the order lifecycle, but it risks revealing positions or strategies, potentially impacting the order process beyond reporting obligations. On the other hand, creating identifiers after execution protects sensitive trading information and separates the trading process from reporting requirements, but this method may lead to difficulties in accurately linking related transactions and might require complex reconciliation processes.
Client orders and market executions rarely follow a straightforward path. For
example, an RTO broker often split a client order into several market orders, and the executing broker may aggregate or divide them several times depending on market conditions.
The proposed L3 guidance foresees a methodology of combining TVTIC and MIC
code, but the TVTIC is not independently reproducible and relies on the transmission of the TVTIC.
Similar efforts under other regulatory reporting regimes, for example, the UTI and
Report Tracking Number under EMIR remain error -prone despite years of industry best efforts.

Several respondents made alternative suggestions, such as:

Letting authorities handling this themselves.
requiring TV to publish the identifiers of trades on their venue and then use these
IDs for this purpose.
Making this field optional.
INTC convention should be replaced in the buyer/seller fields with a specific code,
instead of adding a new data point.
the UTI could be the "Chain Identifier" where available in order to fulfil the amended
Art. 26(9)(j) mandate; where UTI may not be available, then it may be appropriate to develop a contingent methodology along the lines suggested as a separate Chain Identifier, but as such these cases would be few and should be limited to a single application once along the chain.

ESMA takes note of the arguments described by the respondents and
concerning the challenges to successfully implement such a new identifier. Q20: Do you agree with the proposal of identifying the entity executing transaction as the primary entity responsible for the creation of such code and for disseminating it?
If the field was to be introduced, many respondents supported the approach of
placing the responsibility to generate it on the participant that originates the transmission of orders to ensure proper identification. However, consistently with the feedback received on Q19, most respondents disagreed with the introduction of the field all together.

3.2.2.11 Amendment for defining relevant categories of indices
141. The new Art. 26(2)(e) mandates to specify in the L2 the “relevant categories of
indices” subject to the reporting. The proposal presented in the CP was to define the indices in RTS 22 with a reference to “benchmarks” according to Article 3(3) of Benchmark Regulation20 2016/1011. Among the indices covered by Article 3(1) of the BMR, ESMA in its previous assessment21 considered that only the ones that are also ‘benchmarks’ as defined in Article 3(3) of the BMR should be covered.
3.2.2.12 Feedback statement Q21
Q21: Do you agree with the proposed reference to Art. 3(3) of Benchmark Regulation to define the relevant categories of indices?
142. Respondents generally supported the proposed reference to Article 3(3) of
Benchmark Regulation, emphasising that this alignment would enhance clarity and legal certainty.
143. A few respondents expressed the need for further clarification regarding the
potential implications of this approach, particularly concerning consistency with other standards and existing reporting obligations. They cautioned that inconsistencies in definitions could result in discrepancies in data reporting and could complicate the management of reports and underlying instruments.
144. Some respondents suggested that ESMA should provide a list of LEI codes for
benchmarks and indices.
145. One respondent raised a concern that Article 3(3) refers to benchmarks, not
indices, and suggested ESMA using Article 3(1) instead to achieve the desired alignment. Another respondent noted that this reference should not apply to cash instruments.
3.2.2.13 Date by which transactions are to be reported
146. A new letter k) has been added to Article 26, requiring the definition of a deadline
for the reporting, similar to the provision in the revised Article 27(3)(c) for reference data regime. As a result, the proposed approach set the reporting deadline equal to the 20 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R1011 21 https://www.esma.europa.eu/sites/default/files/library/esma74-362-1013_final_report_mifir_review_-_data_reporting.pdf (see section 5)

application date of the revised RTS 22, which should be also aligned with the application requirements of the other RTSs (1, 2 and 23). To ensure a smooth transition, the proposed implementation period should ideally be 12 months from the availability of the technical documentation, based on the past experience with similar reporting frameworks.
3.2.2.14 Feedback statement Q22
Q22: Do you see a need to specify the ‘date by which the transaction data are to be reported’ different from the date of application of the relevant RTS 22 or have other comments with regards to the proposed timeline? If so, please specify.
147. While few respondents agreed with the proposal to align the date by which the
transaction data are to be reported to the date that will be defined for the application of RTS 22, most respondents advocated for specifying a transaction reporting date different from the application date of RTS 22.
148. All respondents stressed the importance of sufficient implementation time to
adapt and ensure legal certainty. Many respondents supported a minimum 18-month implementation period to allow market participants to properly implement the new rule and NCAs to monitor markets. Another respondent pointed out inconsistencies in the proposed timelines in the consultation paper, which mentioned both 18 and 12 months.
149. One respondent suggested the revised RTS 22 should be applicable 36 months
after publication in the Official Journal at the earliest.
150. It was also highlighted that RTS 22 depends on the provision of RTS 23
reference data reporting, and in general that all changes related to regulatory reporting, such as RTS 22, 23 and 24 should align.
151. One respondent emphasized the need to consider the operations of the
consolidated tape and suggested that the application of RTS 22 should be subsequent to the finalisation and implementation of (i) the rearranged transparency rules under RTSs 1, 2: (ii) the reference data revisions including the adoption of ISO UTI and UPI; (iii) the launch of the CTPs in the relevant three asset classes; and (iv) the proper coordination with third country changes, notably those by the FCA to UK RTS 22.
152. One respondent proposed that ARMs be required to implement Level 2
measures six months before market participants.
153. Other respondents mention additional elements as part of their response to this
question. In particular, one respondent suggested that the date by which transactions

are to be reported should be the T+1 date based on the local time zone of the relevant NCA.
154. Some comments also highlighted the need for additional guidance on reporting
and transitional arrangements between the old and new regimes to understand whether transactions executed before the entry into force of the new regime should follow the new or old model, the need for transactions executed before the implementation of the revised RTS 22 not to be re-reported and that the validation rules should be relaxed for transactions executed before the implementation date.
155. One respondent stated that this field is not applicable to Securities Financing
Transactions and requested further guidance on operational processes following the implementation of the revised RTS 22, such as cancellations and re-reporting transactions that are executed prior to the revised RTS 22.
3.2.2.15 Amendments to align the reporting requirements with EMIR and SFTR
and with international standards
156. Article 26(9) 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”.
157. A field-by-field consistency assessment was therefore conducted for the RTS
22 comparing the transaction data elements with the EMIR and SFTR technical standards on reporting and were proposed in the CP.
3.2.2.16 Feedback statement Q23-Q24
Q23: 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 transaction reporting?
158. Respondents generally supported the consideration of international
developments and standards in the development of the RTS on transaction reporting.
159. Several respondents highlighted the importance of ensuring that such
harmonization delivers clear benefits, such as improved data quality transparency, efficiency and reduced redundancies. However, few respondents emphasised that alignment should not only focus on harmonizing data fields across regulations but

should improve the usefulness and coherence of the information collected while considering the specific aims of each regulation, which respondents’ thought was not sufficiently considered in ESMA’s proposal.
160. A few respondents expressed concerns about the lack of a cost-benefit analysis
in the proposed changes. They believed it is essential to clarify the rationale behind the proposal to ensure that market participants' costs are justified and proportionate to the expected benefits.
161. Some respondents stressed the importance of reducing duplicate reporting,
particularly regarding listed derivatives under both EMIR and MiFIR, and encouraged closer alignment between EU and UK reporting standards to minimize compliance burdens for firms operating in both regions. Other respondents reinforced this point by emphasizing the necessity of achieving as much alignment as possible between the two regimes to maintain data quality and consistency.
162. One respondent suggested considering the Financial Instrument Global
Identifier (FIGI) to enhance the identification of OTC derivatives where no ISIN is available, while others recommended including the Digital Token Identifier (DTI) for crypto assets. ESMA notes that no need has been identified for the introduction of the FIGI. With regards to feedback on the proposal to introduce the DTI, please refer to Question 29.
163. One respondent highlighted the publication of the ISO 17442-3, expanding the
LEI standard to include verifiable LEIs (vLEIs). The main use cases for vLEIs are digital signing, authentication and permissions. The vLEI has been designed as a scalable and secure solution to authenticate and bind the legal entity and its authorised representatives cryptographically and can verify the representative’s authority to submit transaction data. ESMA acknowledges the value that vLEI might bring to reporting. Q24: Do you agree with the proposed alignment of fields with EMIR/SFTR requirements as presented in the table above? Are there any other fields that should be aligned?
164. The vast majority of respondents agreed in principle with pursuing further
harmonisation between MIFIR and EMIR/SFTR. However, whilst some agreed without reservations with ESMA’s proposals, and therefore agreed that fields representing the same data point should be identical across the various regimes, several others understood alignment in a different way and claimed that harmonisation should be sought only where appropriate, i.e. when alignment was useful for the specific MIFIR reporting needs. A few respondents argued that the full alignment proposed in the CP would lead to double reporting of the same information and that there would be no

added value of extra fields from EMIR for the purpose of market surveillance under MIFIR.
165. One respondent agreed with ESMA’s proposal for as long as it was the first step
towards a fully automated reporting of articulated data items into a single “data lake.”
166. With regards to the proposed field “Action type” (field 1): several respondents
disagreed with full alignment with EMIR and preferred to have distinct field name and values for MiFIR. In fact, they argued that even if the two action type values of NEWT and CANC are used within EMIR reporting, the application of these values under MiFIR transaction reporting differs, resulting in the same event being reported with different Action Type values between MiFIR and EMIR. As an example, one respondent flagged that if a transaction is reported and the notional amount is subsequently reduced, under EMIR the event would be reported with an action type of MODI, but under MiFIR it would have an action type of NEWT (due to the different ways lifecycle events are handled under the two reporting regimes). Therefore, although the proposal aligns the terminology of the field Action Type, the application and definition of the field would not be harmonised.
167. With regards to the proposed field “Report submitting entity ID” (field 6), one
respondent noted that since in MIFIR the submission is to an NCA and not to a TR as in EMIR, it should be clarified that the entity to which the field refers is the one submitting to the NCA and that when using an ARM, the LEI of the ARM should be reported. ESMA agrees with this comment but does not deem it necessary to add this level of detail in L2 and that the difference compared to EMIR is expected to be understood without room for misinterpretation by reporting entities.
168. With regards to the proposed fields “Indicator of the underlying index” (48a) and
“Name of the underlying index” (48b):

One respondent suggested to add the FIGI identifier for identifying an
underlying index in field 48a which, if used, would allow field 48b to be left blank.
Several respondents noted that field 48b is a free text field and therefore difficult
to use and suggested that ESMA should provide instead a list of allowable values, ideally aligned with the updated list of standardised codes in ISO 20022, in which case there would be no need for keeping field 48b at all. ESMA notes that the free text field is not going to be always populated in a consistent manner. However, the purpose of this field is for entities to report minor indexes which are not included in the list included in the RTS and as such their standardisation is less fundamental.
One respondent was supportive of dismissing field 48 and of further alignment
with EMIR.

With regards to the proposed field Term of the underlying index – multiplier (field
49), one respondent agreed that this field is discontinued and aligned with EMIR.
With regards to the proposed field “Strike price” (field 51):

A few respondents suggested to remove from fields 51 and 52 reference to “and
similar product” as that may bring uncertainty and room for interpretation. ESMA notes that this reference comes with CDE Technical Guidance22 and therefore it would not be appropriate to diverge from international standards.
A few respondents noted that there are contracts executed where the price
quotation is specified as “points”, which would not naturally align with either monetary amount or percentage for the Price value. They therefore suggested that ESMA should include the CDE format value of basis points. ESMA confirms that this change could be taken into account.
One respondent flagged that field 51 will be affected by decimal points as in EMIR
it is possible to report both decimal and percentage, with the exception of ETD IR options which are always reported in percentage. ESMA confirms that the same will apply for this field in MIFIR.

With regards to the proposed field “Option style” (field 53): several respondents
argued that the option OTHR should be maintained because for a specific instrument the other values are not appropriate (for example Warrant (CFI start with RW) or Entitlements (CFI start with R)). It was also highlighted that it is permissible as per the ISO CFI validation to report the 4th character (which reflects the Option style) to report these as “Miscellaneous” and therefore the ‘OTHR’ category could needed.
With regards to the proposed field “Expiration date” (field 55), several
respondents noted that this field should not be applicable at least for interest rate swaps following the European Commission Delegated Act23 which removed this field from the corresponding OTC ISIN. In the CP on RTS 22 it is outlined that the EC Delegated Act clarifies that in the case of IRS the expiry date should not be considered reference data but should rather be reported in the transaction reports. This data element should have 22 roc_20230929.pdf 23 EC Delegated Act on OTC derivatives identifier: Register of Commission Documents - C(2025)417

been modified in the revised RTS 23 to clarify that it does not apply to interest rate swaps. Instead in RTS 22 this data is already collected and was proposed in the CP to be then moved from the section pertaining to instrument characteristics to transaction details.
173. Respondents also took the opportunity provided by this question to comments
on other fields where no changes were proposed in the CP:

One respondent suggested removing the field price multipliers (field 46) in EMIR,
or else much more specific guidance should be provided as to how to report this field especially for CFDs and spreadbets. ESMA notes that it is beyond the scope of this consultation to remove fields from EMIR.
On “Waiver indicator” (field 61) and “OTC post-trade indicator” (field 63): a few
respondents claimed that these fields are very problematic and ambiguous for firms to populate and therefore ESMA should remove them. If the removal was not considered as an option, it suggested that ESMA should take into consideration the relevant changes in the RTS 2 transparency regime and clarify the applicability of “SIZE” in relation to “SSTI” or LRGS” or align the terminology. ESMA notes that field 61 is necessary not just for transparency and volume cap calculations but also for future analysis on waivers (one of the identified use cases of transaction reporting data).
Specifically on OTC post trade indicator (field 63), some respondents noted that the
allowable values should be limited to Agency Cross Trade (ACTX) and Packaged Trade (TPAC) and that some of the elements are never used as they do not trigger a reporting obligation under Art 26 of MiFIR (e.g. RPRI – price improvement, SDIV – special dividend) so they could be removed.
On fields 49 and 49e for the floating rate reference period – time period, one
respondent asked why in EMIR the possible values include ADHO and EXPI while they were omitted in the CP. Another respondent argued that it is unclear what field 49 means and how this change would bring alignment to regulation or international standard.
On fields 42 to 46: One respondent noted that FX options should only be reported
when executed on a trading venue and so fields 42-56 should never be required to be separately completed. ESMA notes that L2 legislation should not go into this level of detail.
Several respondents also noted that the UPI should be added as an instrument
identification field be used (a new field 41b) and, when used fields 42 -56 should be

left blank and information sourced directly by NCAs from the UPI referential data. ESMA notes that the approach to be adopted on UPI should be aligned with that adopted in RTS 23.

On field 43a “MiFIR identifier”: one respondent noted that the CFI code makes the
‘MiFIR identifier’ redundant, so this should therefore be removed.
On Field 3 Trading venue transaction identification code “TVTIC”: one respondent
suggested this field to be removed and replaced by the Unique Trade Identifier “UTI”. For discussion on the TVTIC, please refer to Q13.

A few respondents urged ESMA to discuss any changes to field validation rules
with the FCA as to avoid any major regulatory divergence.
Finally, one respondent argued that the consultation paper does not adequately
demonstrate a clear cost - benefit analysis for the proposed alignment measures
3.2.2.17 Alignment of reporting of direction
Currently, RTS 22 requires that the transaction report includes details on the
identifiers of the buyer and of the seller. Furthermore, the definitions of the respective fields provide rules on how to determine who should be considered the buyer and who the seller, for different type of products. The current approach proved to be suboptimal for certain products, notably for swaps, and work-around solutions needed to be implemented, under which + and – signs are used in the underlying field 48.
Indeed, for the products involving exchange of separate cash flows and assets,
the identification of buyer and seller is not straightforward. This challenge has been addressed in the EMIR reporting in the recent review of the technical standards; by specifying that for certain products the counterparties should indicate the payer / receiver of each leg of the transaction, rather than the buyer/seller in the transaction as a whole. This approach follows the recommendations of the globally agreed technical guidance on reporting of OTC derivatives. ESMA’s proposal in the CP aimed at aligning MIFIR with EMIR in the way the direction of trade is determined.
3.2.2.18 Feedback statement Q25
Q25: Do you agree with the proposed approach for the alignment of reporting of the information related to direction of the transaction?
The majority of respondents agreed with ESMA’s proposal, although several
respondents noted that there is a typo in the proposal regarding CFD and spread bets

and that the buyer shall be the counterparty which goes "long" on the contract, and the seller shall be the counterparty going "short" on the contract.
179. A few respondents strongly disagreed with the proposal and claimed that the
alignment would in fact be an unnecessary duplication of EMIR, which would lead to the introduction of 31 new or modified data fields for this issue alone which would cost significant effort. These respondents argued that this information is already available to NCAs via EMIR.
180. One respondent asked whether the draft of the new Article 16(a) implies that for
forwards related to currencies and of cross currency swaps (point 6) it will be no longer required to fill in the buyer/seller fields but only the field “payer/receiver of leg1” and “payer/receiver of leg 2”. ESMA confirms that that indeed the buyer/seller field in this case would no longer need to be filled in.
181. A respondent noted that there are several instruments (especially those under
Art.26(2)(b) and (c)) where the designation buyer/seller is not always applicable. E.g. a total return swap on equity or equity index, is not bought or sold per-se, but rather counterparties agree to exchange the economic benefit of the index/equity and a pre - set rate.
182. Another respondent flagged that it would be important to clarify that either fields
7/17 or 7a/16a and 7b/16b are populated and that, for example, it is not mandatory to populate the Buyer ID and Payer of Leg 1/Leg 2. Indeed, ESMA confirms that should be the case.
183. Two respondents argued that the proposed approach is overly complex:

One argued that it should be clearly stated that in a standard buy or sell transaction,
the buyer is the party receiving the instrument, and the seller is the party providing it. This principle should also apply to transactions such as currency swaps, regardless of the alphabetical order of the currencies. If the instruments reported under MiFIR have an ISIN and the reference data includes the direction of the cash flows, it argued that this proposed rule would be simpler and clearer.
Another argued that ESMA should use the existing nomenclature in the OTC space
of payer/receiver as a simple way to obtain the same result without generating costly IT developments.

3.2.2.19 Alignment of reporting of price
184. Similarly to the reporting of direction of a trade, EMIR Refit review introduced
significant changes to the way the price information is reported. The price related information is expected to be reported in the ‘Price’ field, only when it is not reported in other dedicated fields, such as fixed rate, spread etc.
185. The Consultation Paper proposed to apply this new approach also under MiFIR
and, should full alignment in terms of reportable fields not be desirable, proposed certain adjustments to the definition of price.
3.2.2.20 Feedback statement Q26
Q26: Do you agree with the proposed approach for the alignment of reporting of the information related to price?
186. The majority of respondents agreed with the proposal to align the price fields in
RTS 22 with EMIR.
187. However, respondents flagged the following issues:

in relation to FX Forwards and FX SWAPs it needs to be clarified how the price
should be reported and what is meant by “exchange rate”, also considering that there are different approaches in the industry in relation to reporting of FX SWAP transactions as either a near leg and a far leg or as a “single instrument”. “Exchange rate” might mean for instance “exchange rate 1” or the “forward exchange rate”.
For option contract, several respondents thought that the current status quo should
be maintained where price of the contract is equal to the option premium without adding a dedicated field for premiums, or alternatively, allow the option premium not to be reported at all (NOAP) where the ISIN pertains to an option or, in the absence of an ISIN, where the CFI code pertains to an option (either O or H*). This is due to the fact that option premium is a factor of the intrinsic value of the option (meaning the amount of money if the option exercised at the pre-set strike price vs market for the underlying) and a time value. Moreover, for options, strike price is a more important/key factor for market monitoring purposes than the premium. One respondent noted that if the price is reported in another field, the price field should remain blank. For example, for IRS Fixed rate, the price is reported on Leg 1, and in EMIR the price field is left blank as it is not mandatory. Requiring NOAP to be reported under RTS 22 risks creating differing interpretations

by market participants. ESMA should provide very clear Guidelines and examples on how the price should be reported.

The price value in respect of bond transactions is unclear. ESMA notes that the
price value for bonds does not change compared to the status quo, but further clarity could be provided in L3 guidance.
For contracts for which the price value is specified in points, ESMA should use the
CDE format value of ‘basis points’ in MiFIR transaction reporting. One respondent flagged that the price multiplier and quantity, which are not required in EMIR, should be removed.
The reporting of price for equity total return swap is not aligned, as the guidelines
on transaction reporting (ex. 109/110/111) are not aligned with EMIR (the first one asks for the price field to include the number of basis points over the fixed rate, the latter requires the price field to include the initial price of the underlying).
In light of the amended scope of the RTS, transaction reports for instruments such
as Forward Rate Agreements and Interest Rate Swaps (other than Article 8a(2) instruments) would not contain any price related fields, as “Price”, “Option Premium” and “Upfront Payment” are not relevant to these instruments. Therefore one respondent suggested that “Spread of Leg 1” (Field 49b), “Spread of Leg 2” (Field 49g), “Fixed rate of Leg 1” (Field 49i), “Fixed rate of Leg 2 (Field 49j), “Strike price (field 51) and “Strike price currency/currency pair” (field 52) should be reported for all instruments, where applicable, irrespective of whether the instrument is reported with ISIN or fields 42 -56. It also recommended that these price related fields should be reported as a subset of “Price” at field 33, and not in fields 42 -56 in order for instruments subject to EMIR QA ESMA_QA_1694 to be reported in dedicated price related fields and negate the need for the Q&A, thus further aligning with the requirements under EMIR Refit.
It is important to be able to report a price of zero, especially in certain derivatives
such as Total Return Swaps or unwinding protocols where the negotiated data element may be something other than price such as the spread within the floating leg. That would also be consistent with ESMA Guidelines on EMIR (Section 3.17). ESMA confirms that it would be possible to report a price of zero.
Further clarity is needed regarding the price type for Indices, specifically over
whether the price should be reported in basis points or as a monetary value.
There is a lack of guidance on spreads and other multilegged or contingent
arrangements.
3.2.2.21 Alignment of reporting of complex trade component ID

The Consultation proposed to align with EMIR the way to report MiFIR
transactions which cannot be effectively and accurately reported in a single report.
The definition in EMIR is based on the CDE Technical Guidance. Furthermore,
its wording is broader and would allow to capture additionally the trades that are executed separately but are mutually contingent, allowing to better understand the pricing patterns. For that purpose, it is proposed to bring MiFIR definition in line with EMIR.
Additionally, it was proposed to introduce an additional field ‘Package
transaction price’ to capture the price of the entire package, while the ‘Price’ field in each transaction report would reflect the price of the individual component.
3.2.2.22 Feedback statement Q27-Q28
Q27: Do you agree with the proposed alignment of the concept of complex trades with EMIR?
Most respondents did not disagree with the proposals to align the concept and
reporting of complex trades with EMIR since the intent is to create simplification and harmonisation.
One respondent in particular argued in favour of the option to denote trades with
multiple legs and rates as a “complex trade” because the single priced outcome would make trading operations and reporting greatly simpler. Although decomposing complex trades may allow for some data elements to be more clearly reflected - they argued - it is also likely to introduce the probability that inapplicable or incorrect values are reported in other fields or that the validation rules may require fields to be populated that are not relevant to the contract negotiated and executed.
However, many respondents only endorsed the modifications to the existing a
“Complex trade component ID” field of RTS 22 for the purpose of linking separate transactions that were executed together as part of the same package.
They highlighted that decomposing single complex trades into multiple
instruments (linked with a complex trade ID), purely for the purpose of transaction reporting, would add unnecessary complexity. It was argued that complex trades and

package transactions tend to be priced either in a single leg component and negotiated core economic term rather than as a monetary pricing component. Furthermore, artificially decomposing the trade into several components would impact price as well, for example for equity basis swaps.
195. Several respondents also noted that while this approach is valid, the current
MiFIR approach to complex trades seems clearer.
196. One respondent asked for a comprehensive harmonisation and alignment of
definitions of (i) RTS 22 complex trades (ii) RTS 2 package transactions (TPAC and PORT flags) and (III) EMIR – taking into account that RTS 2 and 22 include a wider range of instruments than EMIR derivatives. Additionally, Level 3 guidance on RTS 2 and 22 should get aligned too, particularly with respect to the “single -price - requirement”. They also recommended that the new field “Package transaction price” should be an optional field.
197. Several respondents highlighted the need for further detailed reporting guidance
from ESMA with respect to use cases where decomposition of a complex trade solely for the purpose of transaction reporting may not be feasible.
198. It was highlighted that table on page 40 of the CP refers to this field as 'Complex
trade component id', whereas 'Table 2' starting on page 130 has renamed it to 'Package identifier'. ESMA confirms that the proposal was to rename the field on page 40 to ' Package identifier', which would align with EMIR. Q28: Do you agree with adding the field ‘Package transaction price’ to align the reporting under MiFIR with EMIR Refit and CDE Technical Guidance?
199. Views were rather split on this question.
200. Respondents who did not agree argued that this field will be costly to implement
and of limited value. Several respondents argued that when a package of transactions is executed, there will not necessarily be a single package price. Instead, each transaction will have its own negotiated price, in which case market participants will need to artificially create a package price simply to meet the reporting requirements, thus reporting a data point which is not meaningful and potentially misguiding. These respondents therefore recommended ESMA to provide appropriate guidance and examples to articulate the reporting logic for package transactions rather than proposing new reporting fields.
201. One respondent argued that given that any instrument must be reported
separately, adding a package price field is impractical without a corresponding package

identifier. They argued that if an ISIN exists, there is no need for a package identifier, as the ISIN adequately identifies the transaction; conversely, if an ISIN does not exist or only applies to the underlying, the individual instruments must be reported. They recommended that for packages referring to multiple underlyings, each underlying should be reported as a separate trade executed simultaneously, ensuring clarity and compliance with reporting requirements.
202. According to another respondent’s view under certain circumstances it might be
difficult or irrelevant to provide such price. Examples they provided include: (i) when different components of the package can be traded on different venues or OTC (as per ESMA’s transparency Q&A), (ii) portfolio trades consisting of several bonds executed simultaneously and satisfying MEFRROC conditions consist of individual bond prices but not necessarily of a package price.
203. One respondent who agreed with the proposal explained that with the addition
of the ‘Package transaction price’ field any confusion or ambiguity about when to populate the existing ‘Complex trade component id’ for commonly traded packages will be removed, e.g. government bond switch transactions, or interest rate curve transactions etc.
204. Another respondent that agreed with the proposal stressed that while the
individual price per leg may not always be available, the agreed complex price must always be reported.
3.3 Other enhancements
3.3.1 DLT financial instruments (DTI)
205. ESMA's report on the DLT Pilot regime recommends adding a DLT identifier to
MiFIR transaction reports for blockchain-based financial instruments, using the ISO 24165 Digital Token Identifier. Given that the same DTI standard is also mandated for crypto assets under MiCA, the proposal includes additional fields in MiFIR Article 26 to be reported for consistency: the DLT financial instrument code and the DLT underlying identification code.
3.3.2 Feedback statement Q29
Q29: Do you agree with the proposed additional fields to allow for the reporting of the ISO 24165 Digital Token Identifier for DLT financial instruments and underlyings?

A small majority of respondents agreed with the proposal as it can enhance
transparency and market integrity. Some respondents emphasized that DTI standards are already adopted by market participants and recognised by regulators in various jurisdictions.
One respondent highlighted that reporting should include both an ISIN and a
DTI as the ISIN is essential to capture details of the security and the DTI to capture details relating to the token. One identifier cannot replace the other. One respondent highlighted that the DTI standard is already required for data reporting to Canadian Securities Administrators (CSA) by crypto-asset trading platforms.
A few respondents agreed with the proposal but noted specific concerns. Some
believed that the inclusion of the DTI is acceptable if there is no duplication of data. One respondent emphasized that if the DTI is introduced, conditionality should be added to the ISIN field to prevent redundancy and proposed that when a DTI value is provided within a transaction message, the ISIN field should be left blank. Another respondent recommended that if a DTI is included, ARMs should not be required to validate the existence or the validity of such identifier.
Some respondents noted that since the full name of the instrument is already
included as part of the DTI, requesting the instrument's name, underlier, or other related attributes separately is unnecessary; and questioned whether the field 47a “underlying identification code” is required since the underlying ISIN would have been already provided.
Some stressed the importance of clear guidance and further analysis to assess
the full impact of this addition, while others suggested a comprehensive cost-benefit analysis to evaluate the potential implications for market participants. One respondent highlighted that additional information such as the blockchain type and, where applicable, the smart contract address, should also be considered. The respondent noted that while the ANNA Service Bureau has established a connection between ISINs and DTIs, there is still uncertainty regarding where and how blockchain-specific information will be managed, especially for instruments not using smart contracts.
Some respondents were indifferent to the proposal at this stage. Two
respondents found it feasible to add the DLT “financial instrument code” and “underlying identification code” to the database.
However, a substantial minority of respondents disagreed with the proposal,
arguing that the ISIN should suffice for MiFIR transaction reporting.
One respondent stated that the inclusion of a DTI is not helpful for transaction
reporting at this stage, particularly due to the immaturity of the market and consequent potential differing interpretations for the reporting of a DTI, and stressed that data for DLT financial instruments should be open-sourced to ensure accessibility and minimise any additional costs to facilitate market growth.
One respondent highlighted that the integration with OTC derivatives’
underlying instruments is unclear, particularly given the ongoing discontinuation of ISINs for uTOTV instruments like equity derivatives, which are typically traded off - venue and do not require ISIN creation.
ESMA believes that this field is important for market monitoring and to
distinguish cryptocurrency/crypto assets as the underlying instrument. DTI was chosen as the identifier for DLT financial instruments and underlyings in the context of MICA (Market in Crypto Assets) Regulation and it is therefore deemed mature enough for the purpose of future RTS 22 reviews.
ESMA notes that it is not possible to forego the requirement to report the ISIN
because the current ESMA’s systems rely on the availability of the ISIN for all transactions and not requiring an ISIN when a DTI is available in the report would impair the logic of the ESMA system and be extremely burdensome. The ISIN allows to reconcile the transaction reporting with the reference data submitted for the instrument in FIRDS according to the provisions set in Art.27 of MiFIR.
3.3.3 Amendments to clarify Article 4: on transmission of an order
The proposed amendments to Article 4 of RTS 22 extend the scope of order
transmission to cases where an investment firm is trading on its own account (DEAL). Currently, when a firm sends an order to another firm for execution while trading on its own account, it is not considered order transmission under Article 4. This requires the investment firm to fulfil its own reporting obligations, leading to higher internal compliance costs.
3.3.4 Feedback statement Q30
Q30: Do you agree with the proposed amendments to Art.4 to extend the transmission of order agreement also to cases of acting on own account? Please detail your answer.
The majority of respondents supported the proposal of amending Article 4 of
RTS 22 to extend the scope of transmission of order agreement to include cases when

entities are acting on their own account (DEAL). They confirmed that it is logical to treat as a transmission of order such cases when an investment firm is trading on own account and sends the order to another investment firm for execution. Four feedback asked for level 3 guidance alongside the additional fields to ensure the requirements are clear. L3 guidance would be beneficial in relation to the different types of transactions, such as transmission of order agreement transactions, corporate actions, and asset transfers.
219. Two respondents welcome the inclusion as this would give counterparties the
possibility to delegate their reporting obligation. According to three respondents, this change would reduce the reporting burden, particularly for smaller entities, by allowing them to rely on their execution brokers to handle the reporting, provided that there is a bilateral agreement in place.
220. The proposal could still be beneficial for intra-group execution arrangements,
where entities acting on their own account may find the process more streamlined.
221. The application of this exemption depends on a mutual agreement between the
executing broker and the entity, ensuring the necessary data is provided for accurate reporting.
222. A respondent that supported the proposal believes that the drafting of Article 4
requires amendments and the field 25 “Transmission of order indicator” could be renamed to be better represent the intent, i.e. only where all the conditions of Art.4 are met the said flag should be provided. Along the same lines, a market association argues that the inclusion of "TBUY" and TSEL" are somewhat redundant given this information can be obtained via fields 26 "Transmitting firm identification code for the buyer".
223. The same respondent flags that several investment firms, considered
themselves as exempted from reporting because they provide the investment service "Reception and Transmission of Client Orders" and misinterpret the provision of exemptions of Art 26(4) of MiFIR re -transmitting firms with the investment service they provide.
224. A respondent expressed uncertainty in terms of applying such change in Art.4
recital 1a of RTS and asked for more examples to outline when it is relevant and not.
225. ESMA notes that feedback received is useful also under the current RTS 22 and
will consider if further L3 clarifications are needed to align the reporting case scenarios with the market practices.

3.3.5 Amendments to clarify Article 7: details for the decision maker in the case of
investment decisions taken by portfolio / fund managers
226. The new paragraphs 3 and 4 added under Article 7 clarify that portfolio or fund
managers should not be identified as external decision makers populating fields 1224- 15 when making investment decisions for a client, as long as there is no transmission agreement meeting the conditions set in Article 4 of RTS 22. As stated in the guidelines (section 5.9) and Q&A, in such cases, the portfolio or fund manager should be identified as the buyer/seller in the corresponding fields 7 and 16 of RTS 22 by the investment firm receiving and executing the orders and that submits the reporting, not as the decision maker. This applies even when the portfolio management client is also the client of the investment firm executing the order. To ensure correct identification, the proposal was to amend Article 7 to specify that portfolio and fund managers should always be identified as the buyer/seller in these situations.
3.3.6 Feedback statement Q31
Q31: Do you agree with the proposed amendments to Art.7 to include specific cases of portfolio and fund managers? Please detail your answer.
227. The majority of the feedback submitted supported the proposal of extending and
then clarifying in Art.7 the cases when a fund or portfolio management taking an investment decision for a client, should not be identified in field 12 (Buyer decision maker code) as external decision maker. Consequently, to avoid misinterpretation of the requirement, the portfolio and fund manager entities - acting under a discretionary mandate - should be identified as the buyer/seller, not as the decision maker or client, which is also aligned with existing Level 3 guidance.
228. Several respondents confirmed that the proposal is in line with the current
reporting market practice and referencing these cases in the RTS will enhance clarity and consistency of the reporting, minimizing misinterpretation issues and ensuring all market participants adhere to the same standards. The proposal is aligned with the approach established in example 69 of the guidelines and Q6 (1706) of the Q&A for the reporting of investment decisions by portfolio and fund managers on behalf of a client or fund.
229. It is drawn to the ESMA’s attention that the proposed change is relevant as
many fund managers (meaning AIFMs and UCITS Management Companies) may outsource the function of managing a fund’s portfolios to investment firms that are 24 field 12 is only populated where the decision is made under a power of representation.

authorised for the service of portfolio management (within the meaning of Annex I
section A point (4) of Directive 2014/65/EU). In such cases buyer/seller is identified as
the Fund while the investment decision maker fields are identified as the outsourced portfolio manager.
230. One respondent raised concerns that clarifying Article 7 may lead to
inconsistencies in interpretation due to the various roles that may exist during the process of executing a trade.
231. ESMA notes that feedback received might be relevant under the current RTS
22 and will consider if further L3 clarifications are needed to align the reporting with the market practices.
3.3.7 Amendments in data fields linked to reference data changes according to Art.
232. RTS 22 includes fields related to reference data for instrument characteristics
(fields 42–56) for those transaction in scope of revised Art. 26(2) that are not carried out on a trading venue, which are aligned with equivalent fields reported to FIRDS under RTS 23 (reference data regime). For efficiency, if an instrument is reported under RTS 23 (and then field 41 for the ISIN is reported under RTS 22) and its reference data is available in FIRDS, it is not necessary to report its characteristics under RTS 22. This approach has proven effective, and it is recommended to continue.
3.3.8 Feedback statement Q32
Q32: Do you have any comments on the proposed approach to updating the ‘Instrument details’ section in the Annex to the RTS 22? Please flag any additional aspects that may need to be considered.
233. Some respondents did not object to the general principle of amending the
reference data for OTC transactions to take into consideration the alignment with RTS 23 and incorporating then the EC Delegated Act fields also in the reference data instrument section of RTS 22. In general, the proposal of aligning the relevant section with the changes in RTS 23 for reference data was supported given the interlinked nature of the reporting framework and systems. However, it has been requested the changes to RTS 22 and RTS 23 also have clearer and detailed L3 guidance to support these changes to ensure full alignment.
234. A positive support has been expressed by one respondent to collect the MiFIR
identifier for those instruments whose reference data is not already present in FIRDS,

in line with the proposal in the CP on RTS 23 of including FITRS related reference data reporting previously collected under RTS 2.
235. Feedback has been raised to question the added value of the granularity that is
being requested for the inclusion of reference data for instrument characteristics for market abuse and supervision purposes, specifically under fields 48 and 49 (and their respective sub - fields). In their view, the dissemination of such detailed instrument characteristics does not materially contribute to the full and complete understanding of the instrument.
236. One respondent argued that the rationale behind 17 new subfields in the
"Instrument Details" section remains unclear. ESMA notes that for instruments not admitted to trading in a TV the reporting is not provided in reference data FIRDS. If a transaction is executed on such instruments, then, given the absence of reference data in FIRDS, also the instrument reference details should be reported along the transaction ones according to RTS 22 and that is the rationale for adding the new subfields.
237. Five respondents raised concerns due to the impossibility of providing useful
feedback as at the time of publication of the CP a comprehensive proposal was not provided as not all the elements to develop were available. As a general remark, the proposal would result in redundancy and significantly increase complexity, particularly for OTC derivatives. For example, the respondents flagged that the MiFIR Identifier field (43a), Asset of the underlying field (47b), underlying type field (47c) and parameter (new field 56a) included in reference data reporting for OTC transactions overlaps with the existing CFI code (field 43) and does not provide additional useful information for the NCAs.
238. The same respondent also believes that field 47a (DLT underlying code) is not
widely available and it is suggested replacing the proposed field with a data point similar to EMIR e.g. Tokenised Security or Underlying is a crypto asset Boolean Y/N value. ESMA clarifies that a public register25 is available to source all ISINs that have been linked to DTIs.
239. Two respondents raised concerns for field 47a and asked clarification. If the DTI
for the underlying could be left blank when an ISIN is provided in field 41, given that 25 https://anna-web.org/digital-assets/

the DTI data element is currently not included in the RTS 23 reference data submission. Please refer to Q29 for further clarifications on this matter.
240. Fields 41 "ISIN" and 47 "Underlying identification" have inconsistent names, and
one stakeholder recommends amending the field names as "Instrument ISIN" and "Underlying instrument ISIN" respectively. ESMA notes the proposal of aligning the fields’ names
241. Another feedback has been submitted in relation to field 56a "Parameter": given
that this refers specifically to the MiFIR identifier, this reference should be also reported in the field name, e.g., "MiFIR identifier sub -parameter" and the respondent queries how field 47a will be populated.
242. According to some respondents, the introduction of the Unique Product
Identifier (UPI) would already provide sufficient detail for regulators to identify and analyse these products, making fields 42 to 56 and their subfields unnecessary for identifying OTC derivatives without an ISIN.
243. An important aspect raised in another feedback is the request of clarity for the
instruments falling outside transparency but captured in the transaction reporting regime (RTS 2) and under the scope of the EC Delegated Act. A greater number of OTC derivatives are reportable under RTS 22 than under RTS 2, and it has been outlined the importance of reference data to be as consistent as possible across products. According to some stakeholders the set of RTS 22 changes would provide opportunity to remove all fields from the OTC ISIN which result in ISIN code inflation and propose to remove the expiry date from the ISIN in other products such as equity swaps.
244. Another respondent noted that the DA focuses on transparency reporting and
not transaction reporting. Therefore, it agrees that despite different approaches could potentially be taken for the reference data of OTC ISINs and similar instruments across the transparency and transaction scope this should not be the way forward. The respondent’s view is that the same underlying reference data and ISIN should be used consistently for both transparency and transaction reporting.
245. A respondent flag that table on page 130 of the CP were expected modifications
in line with the DA’s provisions: “expiration date” to be moved to the transaction details
section and inclusion of the “term of contract”.
246. The same stakeholder expressed the view that identification of OTC derivative
products in both transparency and transaction reporting should be based on the Unique

Product Identifier (UPI), supplemented by additional fields as needed; and UPI should be an option in RTS 22 reporting if there is no ISIN in FIRDS.
247. ESMA takes note of all comments. Further clarifications are included in the
dedicated section26 of the Final Report on RTS 23 as regards to the EC Delegated Act . ESMA notes that consistency should be ensured between RTS 22 and 23 for all aspects related to reference data for instrument characteristics.
3.3.9 New fields to be added in Table 2 Annex I
248. Over the past years the NCAs and ESMA have identified some possible
enhancements to Table 2 in the Annex of RTS 24 to gather additional information for certain reporting cases and provide clarification to the reporting of the existing fields.

Proposal Proposed changes in RTS

1 Add a new field for the categorisation of the clients and to mirror the client categories specified under Art.30 and 24 of MiFID II Client category - indicator of the category of the client: - eligible counterparties 56 - professional clients (other than eligible counterparties) - clients treated as professionals on request - retail clients 2 Adding a new field for reporting timestamp for New and Cancellation (field 1 – Action type). The new field would provide validity timestamp to know when the new/ cancellation report was issued. Validity Timestamp – Action type
3.3.10 Feedback statement Q33
Q33: Do you support inclusion of the new fields listed above? Please provide details in your answer. 26 Section 3.2. New OTC derivative identifier of ESMA12-2121844265-384. 27 https://ec.europa.eu/transparency/documents-register/detail?ref=C(2025)417&lang=en

Around one third of respondents did not oppose the inclusion of the two new
fields, one third strongly opposed, whilst the remaining third recommended ESMA to make some adjustments to its proposal or provide further clarification without expressing a strong view. Validity timestamps
Those against the introduction of this new field raised the following concerns:

It may be redundant as the current submission timestamp already serves the same
functional purpose.
It is not clear from the proposal what logic ESMA is expecting reporting firms to
follow.
The name of that field is not used in other reporting regimes and instead of
introducing a new field to avoid using time delays ESMA should utilise level 3 guidance.
If the goal is to track the sequence of new and cancelled actions, a simple
timestamp would suffice. Since "validity" is not used in other reporting contexts, its interpretation could lead to errors.
ISO20022 XML file sent to the Competent Authority already contains the Creation
Date (XML tag <CreDt>) in the header.
Do not see benefits compared to IT costs when adapting systems.
‘Validity timestamp’ should be replaced by using the CDE field ‘Event timestamp’.
‘Event timestamp’ was introduced in version 3 of the CDE with the definition commencing “Date and time of occurrence of the event”. The draft version 4 of the CDE proposes adding “for which a report is made” to the end of that definition.
ESMA should provide clearer Level 3 guidance on the way to report sequencing
and time delays would serve the same purpose.
the NEWT/CANC timestamp naming convention of “validity” is confusing. ESMA
should clarify that in such scenario, following the initial NEWT (that is not linked to a CANC), any subsequent amendments (consisting of CANC and NEWT) should get timestamped with either the occurrence or submission of such amendment and if ESMA would like to see identical timestamps of CANC and NEWT in such scenario.

One respondent asked if the Validity timestamp would act as a submission
timestamp and if it would be validated to require same day submissions or can this be used to populate historical date / times, flagging a risk of state generation logic implementation.
Another respondent asked whether ESMA considered the scenario where a
client might correct a transaction leading to a ‘cancel’ and a new report being issued at the same time with the same timestamp.
Those in favour of the introduction of this field were so because inclusion of this
field could enhance ESMA/NCA’s ability to identify the last valid transaction report. The comments these respondents made include the following:

One respondent supported the reporting timestamp but requested to clarify who
should set it (e.g., the reporting firm or, where they use one, their ARM). This respondent also noted that it is not clear if this new field would impact trade/order flow to a venue for their transaction reporting and record-keeping requirements. Typically, this data today lives downstream of the trading platform and the firm’s transaction report can be enriched accordingly with client details for reporting. But this data does not get passed in the order and trade flow or from member to venues. It could be gathered outside of the trading platform by venues if required, as part of their existing client short code/long code mapping process, but as with any requirement to pass information between firms/venues (including, but not limited to, client classification) this will impose a significant implementation burden and may be problematic for non -electronic trading flows.
One suggested aligning Validity Timestamp with the field under EMIR called Event
Date.
Client category

Those against client category field raised the following concerns:

It may be redundant because NCAs could acquire information on retail clients they
could filter all reports by national Id or by LEI.
If the amendments have to cater for the storage of historical information on the
category since NCAs might inquire about transactions in the past, this would make the proposal even more costly.
For non -EEA branches that service non-EEA clients there is no obligation to
categorise clients, so it should not be a mandatory field.
It would be difficult to manage the classification of a specific client given that its
categorization may depend on the Asset Class.
Does not seem to serve any of the goals of detecting market abuse.
Client categorisation is a dynamic process and subject to changes particularly for
clients treated as professional clients on request.
As the trading venue reporting transaction data on behalf of non -MiFIR firms, some
trading venues are reluctant to ask additional information from investment firms about their own clients.
Do not see benefits compared to IT costs when adapting systems.

The majority of respondents believed that if retained, the client category should
include only one category for “professional client”, regardless of whether the client has opted for such treatment or not.
The respondents who were in favour of this field asked:

that ESMA provide a worked example within Level 3 guidance to ensure consistent
implementation;
that there is no new validation which could create reporting problems for other
fields.

One respondent asked if it was correct to assume that this new field “client
category” would only be applicable for the client -facing report and if the category apply to the buyer /seller or to the decision -maker.
Another respondent asked who should be considered the client when both
parties are sell side / market -facing, including where one is a non -EU investment Firm. in cases where Article 26(5) applies this field is not practicable and of limited or no value
3.3.11 Fields to be amended in Table 2 of Annex I and Annex II
In the CP, ESMA suggested a number of amendments to the fields for the
reporting of the transaction details listed in Table 2 of Annex I. Those amendments are summarised in the table below.

Proposal Amendment to Table 2 Annex I

1 To amend the field 35 Net amount
Expand the reporting of the field to all kind of instruments and not only to debt instruments and add NOAP for instruments when the information is not available 2 To amend fields 7 Buyer identification code and 16 Seller identification code To clarify in the description how to report buyer/seller in case the trade is concluded on a third-country TV and/or using an anonymous orderbook and not clearing via a CCP given that in certain circumstances it is not possible to retrieve natural person ID or the LEI of the counterparty. 3 To amend field 4 Executing entity identification code To capture cases where the member, participant or user is a natural person allowed to trade under the respective exemption pursuant to REGULATION (EU) 2022/858 (DLT Pilot Regime), the field should be populated with the LEI of the operator of the DLT MTF or TSS permitted to operate under the DLT Pilot Regime. 4 To amend field 47 Underlying instrument code to also cover cases when the underlying is a basket of indices To amend the description adding: “Where the underlying is a basket of indices, include where available, the ISIN of each index composed of financial instruments traded on a trading venue. Field 47 shall be reported as many times as necessary to list all reportable instruments in the basket” 5 To amend fields 7 Buyer identification code and 16 Seller identification code. To clarify that “INTC” shall only be used with INTC shall be used to designate an aggregate clients account within the investment firm in order to report a transfer into or out of that account with an associated allocation to the individual

aggregate orders from multiple clients clients out of or into that account respectively. 6 To modify field 25 Transmission of order indicator Add an indication about to whom the order has been transmitted to account for cases where the seller and buyer are both investment firms, in which case it is impossible to determine who gave the order and who received it. To correct this, field 25 Transmission of order indicator could be populated with one of the following three values:

NOAP : no transmission of order.
The equivalent of the current
"false".
TBUY: order transmitted to the
buyer
TSEL: order transmitted to the
seller
7 To amend field 59 Execution within the firm to reflect in the field description cases where the decision of the execution was made by a client or by another person from outside the investment firm To add ‘NORE’ in the list of values to be provided for cases identified in Section
5.12 of Guidelines on transaction
reporting
8 To convert field 62 Waiver indicator into a simple Boolean flag indicating the use of reference price waiver Proposed name: Reference price waiver indicator Proposed definition: Indicator of whether the transaction was executed under a reference price waiver Proposed format: ‘true’ – yes, ‘false’ -no 9 To update the list of flags in field 63 OTC post-trade indicator It is proposed to align the list of flags in line with the current Table 3 Annex II of RTS2 and Table 4 of Annex I of RTS 1. Additional amendments will be

incorporated based on the outcome of the relevant consultation
260. ESMA also proposed to amend Annex II as follows:

Proposal Amendments to Annex II

1 Remove references to UK To modify the table 2 To update the priority identifiers where needed
1) To remove CONCAT as the second
priority identifier for Finland (every person with Finnish nationality does have the 1st priority identifier, so it should always be used).
3.3.12 Feedback statement Q34
Q34: Do you agree with the amendments listed above for the existing fields? Please provide details in your answer.
261. On proposal 1 of the amendments to Table 2 of Annex I, respondents provided
the following input:

One argued that there is no necessity to expand the scope of the net amount field
since this same amount for the same transaction is already reported under EMIR. Another respondent noted that expanding the Net Amount field to all products would provide an opportunity to remove the Price Multiplier (PM) field as considered no longer necessary.
Others flagged that it is not clear whether the changes to Field 35 Net Amount
should apply to certain types of instruments (e.g., shares) where the concept of clean price, coupons or nominal value might not be applicable. It has also been raised that net amount is not applicable to derivatives as there is no cash amount paid at the settlement of a derivative transaction. The indicator NOAP implies the data is not available while for certain instruments this is not accurate and rather the field is not populated because the data is non-existent.
One respondent flag that the use of this field should be limited to equities and debt
instruments only, where the concept of net amount is more relevant. Another feedback instead asked how the net amount would be expected to be calculated for all applicable instruments.

On proposal 2 of the amendments to Table 2 of Annex I one respondent noted
that not reporting a natural person’s identifier or a corporate entity’s LEI should only be permitted when it is fundamentally impossible to report or the information is nonexistent, not simply because a party has failed to obtain the data from the client.
On proposal 3 of the amendments to Table 2 of Annex I there were no specific
comments.
On proposal 4 of the amendments to Table 2 of Annex I, respondents provided
the following comments:

In the scenario where no ISIN is allocated to the indices included in the basket
it has been raised from one respondent to refer to the list of equity indices compiled by ANNA - DSB for the UPI generation.
One respondent asked clarifications to populate field 48b ‘Name of the
underlying index’ with multiple index names.

On proposal 5 of the amendments to Table 2 of Annex I, respondents raised the
following points:

INTC should be withdrawn and both the market facing and the client-side leg
may be identified with specific codes under buyer/ seller fields.
No need for further modification because such change aligns with existing
reporting practices. For some, the use of the MIC as a buyer or seller identifier when no counterparty or CCP is identified is already common practice. Some drafting changes in the field description have been also raised to clarify the reporting.

On proposal 6 of the amendments to Table 2 of Annex I:

One respondent requested further clarification at Level 3 regarding the
interpretation of the proposed amendments.
Another respondent noted that the proposed changes are not consistent with
the market’s reporting scenarios and would have IT implications for entities.

On proposal 7, of the amendments to Table 2 of Annex I there were no
comments.
On proposal 8, of the amendments to Table 2 of Annex I:

Several respondents noted that field ‘Reference Price Waiver Indicator’ should
be deleted according to the revised Article 10 of MiFIR Review instead of being potentially converted to a Boolean (Y/N) option.
One argued that the proposal should consider the information that also are
relevant for efficiently using transaction reporting data to the transparency calculations. For example, it has been raised that all pre-trade waivers should be covered by the field (e. g. LRGS is currently not covered).

On proposal 9 of the amendments to Table 2 of Annex I, respondents
commented the following:

The field leads to unnecessary inaccuracies and its use is not clear. In
particular, the list of values in the RTS should clarify the definition of Post -trade large -in-scale transactions (LRGS); and it potentially should be limited to only Agency Cross Trade (ACTX) and Packaged Trade (TPAC). Some of the elements of field 63 were not used as they do not trigger a reporting obligation under Art 26 of MiFIR (e.g. RPRI – price improvement, SDIV – special dividend).
It is not clear how this field should be populated after the introduction of new
values to RTS 2 taking into consideration the associated significant implementation costs. and how cancellations of transactions are handled to ensure consistency with the reporting to the APAs.

On the proposals of the amendments to Annex II, respondents provided the
following comments:

Given the existence of multiple 2nd and 3rd priority identifiers in Annex II of the
proposed draft RTS, it is not clear how the new proposed draft of Article 6 (2) of RTS 22 in the CP would allow investment firms to apply the requirement to obtain from clients the information on the highest priority identifier.
The proposal for Finland identifiers may cause problems for Finnish residents
using financial services in other countries.

3.3.13 Fields to be removed in Table 2 of Annex I
271. In the CP ESMA noted that the current Art.26 (3) does not foresee the obligation
of indicating the short sale transactions and suggested that this data element can be then removed from the reporting requirements. The relevant article of the RTS 22 (Article 11) can also be removed.
3.3.14 Feedback statement Q35
Q35: Do you support suppressing the reporting of the field listed above? Please provide details in your answer.
272. Respondents generally supported the suppression of the "Short Selling
Indicator" field in transaction reporting.
273. One respondent emphasized the importance of coordinating with the FCA to
avoid regulatory divergence between the two jurisdictions as it can increase costs and complexity for market participants.
3.4 List of exempted transactions (Art. 2(5) of RTS 22)
3.4.1 Disposal of financial instruments in the context of liquidation / bankruptcy /
insolvency procedures
274. The disposal of financial instruments in instances such as liquidation,
bankruptcy, or insolvency procedures raises compliance issues for the investment firm that is not able to obtain the client's LEI code when a court or insolvency administrator orders the sale, and the client is a legal entity. This creates difficulties for the entity executing and reporting the transaction. Similar cases include sales due to insolvency, corporate actions involving non-tradable share fractions, and bank’s account terminations requested before MiFID II. The proposal is to amend the list of exempted transactions in Article 2(5) of RTS 22 to cover these situations.
3.4.2 Feedback statement Q36-37
Q36: Do you agree with the proposal of including in the list of exempted transactions under Art.2(5) the disposal or selling of financial instruments ordered by a court procedure or decided by insolvency administrator in the context of a liquidation / bankruptcy / insolvency procedure?

Respondents generally supported the proposal, as overall feedback recognizes
the challenges in reporting (or the pending reporting of) such scenarios by the industry. One respondent highlighted that the exemption acknowledges the unique nature of these transactions, which are carried out under legal obligations and do not reflect typical market activities.
One respondent believed that the proposed exemption is already sufficiently
covered under the existing provisions of Art. 2(5)(i): “the creation, expiration or redemption of a financial instrument as a result of pre-determined contractual terms, or as a result of mandatory events which are beyond the control of the investor where no investment decision by the investor takes place at the point in time of the creation, expiration or redemption of the financial instrument;...“. Therefore, the stakeholder believes that a mere clarification would be adequate instead of a new article to specify the exemption.
Additionally, one respondent highlighted the importance of maintaining
flexibility, noting that exemptions should not be mandatory. This will allow firms to continue reporting such transactions voluntarily if it aligns with the compliance requirements. Q37: Do you consider that the exemption in Art.2 (5) should take into consideration also other similar instances as described? Please elaborate your answer.
The respondents generally supported expanding the exemption in Article 2(5)
to include additional instances similar to those described in the previous question. Expanding the scope of the exemption would simplify reporting requirements and ensure greater consistency in transaction reporting under MiFIR.
Many respondents emphasized that all corporate actions should be exempted,
noting the current exemption only applies to debt instruments but not equities to close this gap so that all corporate action events are out of scope for MiFIR trans-action reporting. A respondent outlined that the exclusion should be extended to include corporate action events, except for tender offers and tradeable right lines.
It is suggested assessing the opportunity to add within the RTS text the terms
“..shares..” or “..share capital..” prior to “(…) a bond or other form of securitised debt (…).
A few respondents advocated for the complete removal of Securities Financing
Transactions executed by ESCB members, from MiFIR transaction reporting, pointing out that the UK has made similar changes (see FCA Handbook Notice No 96).
Some respondents suggested additional specific exemptions (Clearinghouse,
forced liquidations of client positions due to insufficient balance to cover margin position).
Some respondents highlighted that the automatic sale of subscription rights
after the exercise period does not constitute a reportable transaction since the report is not based on an investor's active decision.
A few respondents stressed the need for flexibility to adapt to future needs and
to keep exemptions optional for reporting entities.
Given the existence of a wide variety of events and characteristics of the
transactions, ESMA notes reservations regarding the proposal to exempt all corporate actions. Such instances should be further assessed to do not impair the NCA’s supervisory capabilities.
3.4.3 Auctions in emission allowances
During the years the industry has long sought clarification on whether auctions
of emission allowances fall under the scope of Article 26 of MiFIR. NCAs and ESMA agreed that investment firms participating as bidders in these auctions are not required to fulfil additional reporting obligations. Transactions involving emission allowances executed by trading venues on auction platforms are instead subject to reporting under
Article 34 of CDR 2023/2830, which prevail over the MiFIR reporting requirements.
Therefore, the proposal is to amend Article 2(5) to include these transactions in the list of exempted transactions.
3.4.4 Feedback statement Q38
Q38: Do you agree with the assessment and the proposal of expanding the perimeter of the exempted transactions to auctions in emission allowances?
The vast majority of respondents agreed with the proposal to expand the
perimeter of exempted transactions to auctions in emission allowances. Many argued that exempting these transactions would reduce unnecessary reporting obligations, enhance the overall clarity and usefulness of the data collected by regulators.
Two respondents noted that if the exemption implies that reports should be
rejected when submitted, validation rules would also need to be revised. Additionally, one respondent disagreed, arguing that the existing reporting regime is effective and that there are no convincing reasons for treating auctions of emission allowances

differently from auctions of other financial instruments. It considered that special treatment for emissions auctions is unnecessary, potentially increasing compliance costs.
289. One respondent suggested that while the exemption is beneficial, it should not
be mandatory, allowing reporting entities the flexibility to report these transactions if they find it advantageous for transparency or operational requirements.
3.4.5 Novations having clearing purpose
290. The current list of transactions exempted from the reporting obligation under
Art. 2(5) also includes novations in derivatives, where one party is replaced by a third party. Novations are used in the clearing of CDS, as they allow a CCP to act as an intermediary between the original market counterparties. Since the exposure of the dealers to the underlying credit remains unchanged, transaction reporting may be seen as less critical for market abuse detection, especially since such events are already reportable under EMIR. However, in cases where novations do not involve a CCP and are used by market counterparties to adjust exposure, they should be properly reported for detection and monitoring purposes. Therefore, the proposal is to narrow the scope of novations excluded in Article 2(5)(e), specifying that novations should not be exempt from reporting when related to clearing arrangements. As a result, the novations without clearing purposes would fall in the scope of the reported transactions.
3.4.6 Feedback statement Q39
Q39: Do you agree with the proposal of narrowing the perimeter of the exempted novations to transactions having clearing purposes?
291. Slightly more than half of respondents supported the proposal, with one
respondent suggesting that ESMA should go even further by abolishing the novation exemption altogether.
292. A significant number of respondents opposed the proposal. Few respondents
highlighted that novation do not constitute new transactions and have no impact on market decisions. They also argued that MiFIR reporting should not duplicate EMIR reporting and that the current exemption should be retained. One respondent suggested that ESMA should provide clear guidelines to prevent misinterpretation of the regulatory changes.
293. Some respondents acknowledged the rationale behind the proposal but
cautioned that narrowing the exemption solely to transactions with clearing purposes

can be too restrictive. They emphasized that the proposed approach imposes unnecessary reporting requirements that could complicate processes without raising meaningful supervisory benefits.
3.5 Format for reporting
294. In line with Article 1 of RTS 22, transaction reports are currently required to be
submitted in a common XML template aligned with the ISO 20022 methodology. The CP presented the opportunity to evaluate alternative data formats with the aim of enhancing the efficiency of data transmission and processing. As part of a broader initiative to modernise regulatory reporting frameworks, ESMA consulted on a potential transition from XML to JSON, an approach already under consideration for other reporting regimes). The CP highlighted the advantages of using over XML, including simpler syntax, greater reliability, improved parsing performance, and overall gains in processing efficiency.
3.5.1 Feedback statement Q40
Q40: Please provide your views on the format for reporting and any challenges you foresee 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.
295. The majority of respondents opposed the transition from XML to JSON for
transaction reporting under MiFIR RTS 22. While they recognise that JSON presents advantages such as a simpler and more compact syntax, industry respondents largely argue that XML remains the more suitable format due to its widespread adoption, robust validation capabilities, and alignment with other regulatory reporting frameworks (e.g., EMIR, SFTR).
296. Key concerns and challenges identified in the feedback received are:

High implementation costs: need to overhaul systems, conduct testing, and train
personnel. Many firms have already heavily invested in XML-based reporting under EMIR and SFTR, making an additional transition burdensome.
Data validation & schema robustness: XML benefits from strong schema definition
(XSD), allowing for strict data validation. JSON lacks an equivalent standardised schema validation mechanism.
Interoperability with other reporting: XML is already the standard for financial
reporting under MiFIR, EMIR, SFTR, and other non-EU global regulations

Challenges were identified also as regards to timelines for Implementation,
highlighting that a minimum transition period of 18-36 months is needed to ensure smooth adaptation. Some respondents propose a phased-in approach or a period of dual reporting (XML & JSON) to mitigate risks.
The potential benefits were identified from stakeholders in a reduction in data
transmission size and easier human readability (short-term). Some outlined that JSON could be more future-proof and adaptable in the long term, but others believe XML already meets the international standards and does not require replacement.
Some alternatives and recommendations were also raised, In detail:

Maintaining the XML as the primary format due to its established role and
compatibility with regulatory frameworks.
If JSON is considered, to conduct a thorough cost-benefit analysis before its
implementation to ensure a robust validation framework is in place beforehand.
Focusing on data content standardization (ISO 20022 methodology) rather than
changing the format itself.
ESMA notes the feedback received. This Final Report does not include changes to the existing RTS 22; therefore, no changes are proposed to the format of reporting
3.6 Use of transaction data for transparency and volume cap
calculations

ESMA evaluated in the CP the potential use of transaction data, already
reported under Article 26 of MiFIR, as the sole input for performing transparency and volume cap calculations. This initiative seeks to enhance efficiency, reduce duplicative reporting obligations, and maximise the value of existing datasets by moving away from the separate submission of aggregated quantitative data to ESMA’s Financial Instruments Transparency System (FITRS) and DVCAP systems.
To assess the feasibility of this shift leading to significant burden reduction,
ESMA conducted a proof-of-concept project aimed at replicating the transparency calculations currently performed in FITRS using the transaction data available since
Although limited in scope and based on a simplified methodology, the exercise

demonstrated that transaction data could serve as a reliable input for these calculations. The underlying approach involved a series of data pre-processing steps, including the deduplication of reports (based on key identifying fields such as TVTIC, ISIN, price, quantity, and timestamp), exclusion of non-relevant or chain transactions, and the conversion of transaction values to EUR. Additional quality checks were applied to identify and remove outliers.
302. The results of the calculations derived from transaction data were then
compared with the outcomes produced by the FITRS system over the same reference period and instrument set. The comparison revealed a high degree of consistency across most indicators, with a strong alignment in the classification of instruments into policy buckets. These findings suggest that, despite known limitations and the need for further methodological refinement, transaction data is a viable input for transparency calculations.
303. The proof-of-concept also highlighted the challenges that would still need to be
addressed to enable full-scale implementation, focusing particularly on the fields relevant to the calculations.
3.6.1 Feedback statement Q41-Q43
Q41: Should the use of transaction data to perform the calculations be feasible, what would be the costs and the benefits of using this data and discontinuing the specific reporting flows (FITRS and / or DVCAP), including in relation to the change and run costs of reporting systems, data quality assurance and other relevant aspects?
304. Several respondents were supportive of the proposal, agreeing that the use of
transaction data could simplify the reporting burden and reduce duplicative data. Some respondents acknowledged the potential benefits of discontinuing the reporting flows for non-equities, particularly since the MiFIR review. However, for equities several respondents do not see any significant cost savings. One respondent emphasized that a thorough assessment of the operational impact on reporting entities would be necessary.
305. Some respondents expressed concerns regarding the proposed use of
transaction data for transparency calculations, highlighting the reporting complexity and significant costs it would impose on investment firms. Other respondents argued that the existing system of reporting to FITRS should be retained due to its proven effectiveness. Respondents also raised concerns about potential data quality issues that might arise from relying solely on transaction data.

One respondent noted that on the subject of new identifiers required for the
deduplication of transactions, the industry does not have any mechanism to pass those identifiers from one firm to another in the required T+1 timeframe, and suggested guidance on how to report existing identifiers and cope with the use of the available data.
ESMA notes that no cost increase for investment firms is expected in relation to
the use of transaction data for transparency calculations. The calculations will be performed using transaction data as it is reported for the purpose of Article 26 of MiFIR. Q42: Do you have any comments on the methodological approach outlined above?
Respondents expressed concerns about the reliability and accuracy of the data
for transparency calculations, particularly highlighting the challenges in determining the LIS threshold. Issues related to waivers, such as the lack of visibility in trading systems, were also raised, with many suggesting these issues should be addressed before moving forward with the proposal.
A large number of respondents called for further clarification from ESMA,
especially regarding the methodology
Some respondents noted that the new approach could offer greater robustness,
as it would enable the tracing of all liquidity determinations back to the originating transaction population.
According to the analysis performed so far by ESMA, including the results that
were published in the Consultation Paper, it has been proven that transparency calculations could be performed using transaction data with high reliability. The analytical work has led to the identification of a number of data quality issues affecting transaction data and, subsequently, the results of the calculations. ESMA has developed a specific Data Quality Engagement Framework with a set of targeted tests28 to address these issues and will work closely with the Competent Authorities to ensure the expected improvements. Addressing these data quality issues will not only improve the accuracy of transparency calculations but will also have a positive effect on all monitoring and analytical activities of competent authorities and ESMA that rely on this data. 28 https://www.esma.europa.eu/document/mifir-art26-transaction-data-dq-framework-technical-document-dqef
ESMA also intends to continue the work on the calculation methodology, in
order to ensure accurate results of the calculations.
It should be also noted that a number of data quality issues affecting FITRS
data occurred over the years and might have affected the quality of transparency calculations performed so far; therefore, not all the differences between the calculations based on FITRS and transaction data can be attributed to insufficient quality of transaction data or the shortcomings of the calculation methodology. Given the expected discontinuation of FITRS reporting, the work on data quality of this data set has been suspended, which will allow to prioritise the work on transaction data. Q43: Do you have other comments on this potential change, e.g. on specific issues, challenges or alternatives that could be considered by ESMA in its assessment?
Some respondents suggested that ESMA should focus on further refining
transaction reporting. Concerns were raised about the difficulty in ensuring the completeness of reported transactions, while others noted that the proposed changes would primarily impact trading venues with minimal benefits for investment firms. A respondent inquired whether future data from APAs and trading venues, intended for CTPs, could replace FITRS data flows.
ESMA takes note of this proposal to use CTP data for the calculations. However,
given that this data is not yet available, it is premature to assess its feasibility. This option could be reassessed in the future once CTP reporting is established and reaches a sufficient level of quality.

Part 2: Amendments to RTS 24
4 Feedback statement on the proposals of amending RTS
4.1 Amendments stemming from L1 changes – format for reporting
316. The amendments to Article 25 of MiFIR address a limitation in the previous
version, which did not grant NCAs the power to impose a specific format for order data submissions from TVs. This gap was highlighted in previous reviews, including the MAR review, and the MiFIR review has since expanded ESMA’s mandate to ensure a harmonized, machine-readable format for order records.
317. The transition to a harmonized format is seen as beneficial by trading venues,
as in the past consultations they have indicated that maintaining multiple file formats for the same reporting requirements created unnecessary costs. The proposal of adopting an electronic and machine-readable format, in line with ISO 20022, had the main goal of simplifying data collection and analysis for NCAs, meanwhile enhancing the overall regulatory efficiency.
318. The proposals of the CP presented also the opportunity to consider alternative
formats to the XML syntax currently used in MiFIR reporting, with JSON emerging as a suitable candidate for regulatory reporting.
4.1.1 Feedback statement Q44-45
Q44: Do you agree with the proposal of adopting JSON as standard and format of order book data keeping and transmission? Please justify your answer.
319. The feedback on this proposal showed a wide range of opinions, with a general
leaning toward caution or opposition. While some respondents supported the proposal, citing JSON's modernity, efficiency, and lightweight structure, particularly its ability to handle high volumes of data effectively, most expressed significant concerns about the implications of such a change.
320. A few respondents acknowledged the benefits of aligning order book data
transmission with other established regulatory reporting formats and believed that JSON could offer performance improvements and reduce data verbosity compared to older formats like XML.

However, the majority of responses were critical of the proposal. Many
respondents highlighted the substantial financial, operational, and technical burdens associated with moving from XML-based systems to JSON. These include the need for extensive redevelopment of existing systems, staff retraining, and lengthy testing and validation processes to maintain data integrity. Several stakeholders emphasized that the industry has already made considerable investments in XML infrastructure, and a shift to JSON would incur costs that, in their view, outweigh any expected benefits.
There were also concerns about a lack of clear advantages to justify adopting
JSON, especially given the absence of complex data structures in the current reporting requirements. Some respondents questioned the rationale of mandating JSON when XML is already widely used and internationally recognized, and in many cases, better supported by tools, standards, and industry familiarity.
In addition, a number of respondents criticized what they saw as inconsistencies
in ESMA’s approach across different regulatory technical standards. While JSON is being considered for some areas, it has already been ruled out for others, such as commodity derivatives. This approach was seen as potentially leading to increased complexity and fragmentation. Smaller trading venues might also be disproportionately affected by such a change.
Finally, even among those not fully opposed to JSON, there was strong
emphasis on the need for sufficient implementation timelines (at least 12 months), harmonized adoption across all NCAs, and long-term commitment to the chosen format. Without these guarantees, respondents feared that the transition would introduce more challenges than it solves, both technically and operationally.
Overall, while a few respondents acknowledged potential benefits of JSON, the
prevailing industry view is that the transition lacks a strong justification at this time and poses considerable risks and costs that require more thorough analysis and coordination. Q45: Please provide your views on the format of reporting and any challenges you foresee with the use of JSON format compared to XML. Please provide estimates of the costs, timelines and benefits (short and long term) related to the potential implementation of JSON syntax.
The feedback on the use of JSON format for reporting under RTS 24 largely
aligned with the views expressed in responses to Q40 and Q44. While some acknowledged potential benefits of JSON, such as more efficient data handling, smaller data size, and better performance with large datasets, the majority expressed

significant concerns about the challenges and costs of transitioning from the existing XML format.
327. Many stakeholders emphasized that XML, especially as based on ISO 20022
standards, is a mature, stable, and widely supported format with well-established schema validation capabilities. In contrast, JSON lacks native schema validation, which would require additional development effort and external tools to ensure data integrity. The shift to JSON would necessitate significant changes to current systems, including investment in development, testing, and staff training, with estimated timelines ranging from 18 to 36 months due to the complexity and need for industry-wide coordination.
328. A clear, mandatory transition phase was considered essential to allow market
participants sufficient time to adapt to new requirements. Early publication of detailed guidelines was also deemed critical to minimize uncertainty and facilitate a smooth implementation.
329. While JSON might offer technical advantages for data transmission and storage
in the long term, the immediate costs and risks were considered substantial, with many suggesting that efforts would be better focused on improving the existing XML-based framework or prioritizing other regulatory changes with greater market impact.
330. Overall, the feedback reflected caution toward adopting JSON as a replacement
for XML, highlighting that the benefits do not clearly outweigh the costs and complexities involved. Any move toward JSON was recommended to be gradual, welljustified, harmonized across jurisdictions, and supported by robust technical specifications and sufficient time for implementation.
4.2 Amendments in data fields stemming from changes in RTS 22
331. To align with the changes in RTS 22, several fields in Table 2 of Annex I of RTS
24 were proposed to be amended for consistency and efficiency across the reporting regimes. The proposed changes included updates to the TVTIC description, the addition of a DLT financial instrument identification code, revisions to price-related fields (28, 29, 30), the introduction of a dedicated field for leg 1 currency, and adjustments to the buy-sell indicator (field 32). These amendments aimed at enhancing data clarity and improve regulatory reporting consistency.

4.2.1 Feedback statement Q46
Q46: Do you have any comments on the proposed approach to updating the field list in the Annex of RTS 24 to align with the proposed RTS 22 fields? Please flag any additional aspects that may need to be considered.
332. The vast majority of respondents supported ESMA’s proposal or had no further
comments. However, several provided detailed feedback on specific aspects:

Concerns were raised about the applicability of RTS 24 fields to RFQ systems,
noting that these fields are designed for CLOB functionality and do not align with the bilateral nature of RFQ workflows. A proportionate approach was requested.
Another respondent highlighted inconsistencies between RTS 22 and RTS 24 in
the treatment of joint accounts, specifically regarding the character limit in the Client Identification Code field, which may be insufficient for reporting multiple fiscal codes.

One respondent recommended including the INTC identifier to complete
alignment with RTS 22.
Another respondent emphasized the need for numeric-only field identifiers to
maintain tabular data integrity, suggesting new fields be numbered from 52 onward rather than using alphanumeric labels like "18a" or "29a".
Finally, one respondent stressed the importance of evaluating whether RTS 22
fields are appropriate for RTS 24, and called for a thorough cost-benefit analysis, clear guidance, and adequate transition periods.
4.3 Other enhancements in data fields
The CP identified additional potential enhancements to Table 2 in the Annex of
RTS 24 to improve reporting accuracy and align with the changes proposed in RTS 22. A new field was proposed to capture the date and timestamp when a transaction is cancelled after validation by both parties. Additionally, minor updates were suggested for existing fields, such as changes to the "execution within firm" field to reflect amendments from RTS 22, and updates to the "client identification code" for aggregated orders.

4.3.1 Feedback statement Q47-Q49
Q47: Do you support inclusion of the new fields listed above?
337. While respondents generally supported the inclusion of new fields, several
raised concerns about their necessity and implementation:

Field 1 was viewed as redundant, with many noting that the existing “Date and Time”
field already captures relevant information. Instead, respondents suggested using a new flag in field 21 to indicate trade cancellations, similar to how the “CAME” flag is used for order cancellations.
One respondent argued that field 33a (“Transaction cancellation date time”) does not
pertain to order events and questioned the relevance of order-related fields (e.g. displayed quantity, order event) in this context. They also pointed out that negotiated trades are not covered under this specification and should be reported differently.
Another respondent questioned how transaction cancellations should be handled under
both RTS 22 and RTS 24, particularly in cases involving multiple executions, and recommended referencing transaction reporting records instead.
Regarding field 3 (Client identification code), concerns were raised about the unclear
instruction to add a new value alongside PNAL and AGGR. Clarification was requested on how these values should be treated under RTS 22 once INTC is introduced.
One respondent emphasized that new fields should only be added if they demonstrably
improve data quality and address reporting gaps, cautioning against unnecessary burdens.
Lastly, a respondent referenced the existing guidelines on transaction reporting, order
record keeping and clock synchronisation under MiFID II and suggested that intra-day cancelled transactions should not be reportable under RTS 24. Q48: Do you agree with the amendments listed above for the existing fields?

Respondents generally supported the proposed amendments. Several
respondents stressed the need for clear implementation guidance to prevent confusion and noted that the changes would require technical adjustments by trading venues and market participants.
Concerns were raised regarding the applicability of RTS 24 to RFQ systems.
Some respondents called for further amendments to Article 1(1) of RTS 24, a review of

ESMA’s Level 3 guidance, or even an exemption of RFQ systems from RTS 24 obligations, including the removal of related references in the Guidelines on transaction reporting. One respondent also highlighted potential backward-compatibility issues arising from the proposed changes. Q49: Do you have further suggestions to improve or streamline the other fields in RTS 24?
340. Two respondents recommend that the amendments to the RTS24 fields should
be more in line with RTS22 to map consistently across the reports and reduce the burden.
341. One feedback raised further amendments to be taken into consideration. It is
requested to remove the fields questioning why such information are relevant for market surveillance:

“Liquidity Provision Activity” (field 8) as the reporting is challenging for firms.
“Initial quantity” (field 36) as the “Remaining quantity including hidden” (field 37),
“Displayed” (field 38) and “Traded Quantity” (field 39) should already provide all the information required to track orders over the lifetime.

From three feedback emerged improvements to be considered in the revised
RTS 24:

Validity Period (field 10) should be DAYV instead of DAVY to follow the logic that
applies to the other fields.
The Order Restriction (field 11) includes multiple entries, and it is asked NCAs to
clarify the use of this field and ensure a harmonized approach as some NCAs require different information.
It is also suggested amending the definition of SESR (standing for Session
Restriction) and VFCR (standing for Valid for Closing Restriction ).
Investment Decision, Legal Entity ID, Non-Executing Broker fields should be
complemented with 'EMPTY' in case customers do not report on time the code and ‘INVALID’ when long codes are invalid. This does not apply to RTS22 as transactions remain in pending state until the information is provided.
Transaction Cancellation Date and Time” could also be used for trade busts (cases
when the trade is unilaterally cancelled by the venue).
A list of amendments to the format specified in the RTS 24 for some fields have
been raised.
To clarify the uniqueness of Field 15 “sequence number”. It is questioned if it is
intended as unique per order ID (field 20) or across the trading venue (for all orders). The following drafting proposal has been provided for field 15: ”Each and every event listed in section G shall be identified using positive integers in ascending order. The sequence number shall be unique to each type of event for the order ID; consistent across all events, timestamped by the operator of the trading venue; be persistent for the date that the event occurs.”

A respondent remarked the same feedback already reported for RTS 23 on the
challenges on the additional and different requests are received at a local level from NCAs to ensure a harmonized and consistent approach is taken across the EU.
As a final comment, a respondent outlined that it would be beneficial and more
efficient to streamline the reporting if the submission of data may be performed directly and centrally at ESMA’s level, instead to the single NCAs. A central system would significantly reduce issues with respect to information exchanges between entities and different NCAs would also optimise the data exchange information between NCAs themselves. 5 Conclusions
This Final Report (FR) summarises the responses received by market
participants to the consultation on the proposed amendments to the RTS 22 and 24. 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 RTSs 22 and 24. The feedback received to the consultation and summarised in the FR will serve as valuable input for future amendments to the technical standards and to the Level 1 text in the context of the comprehensive review.

Final Report on RTS 22 on transaction data reporting and RTS 24 on order book data

Proposal Proposed changes in RTS

Proposal Amendment to Table 2 Annex I

Proposal Amendments to Annex II

Lineage

Similar documents from other regulators