16 December 2024
ESMA74-2134169708-7768
MiFIR Review Final Report
Technical Standards related to Consolidated Tape Providers and DRSPs

List of acronyms
APA Approved Publication Arrangement
ARM Approved Reporting Mechanism
CBA Cost-Benefit Analysis
CP Consultation Paper
CSV Comma-Separated Values
CT Consolidated Tape
CTP Consolidated Tape Provider
DEG Data Expert Group
DORA Digital Operational Resilience Act
DPE Designated Publishing Entity
DRSP Data Reporting Service Provider
EBBO European Best Bid and Offer
ESMA European Securities and Markets Authority ETF Exchange-Traded Fund EU European Union GUI Graphical User Interface HFT High Frequency Trading ITS Implementing Technical Standard MiFID II Markets in Financial Instruments Directive II MiFIR Markets in Financial Instruments Regulation MTF Multilateral Trading Facility

NCA National Competent Authority
NTP Network Time Protocol
OSI Open Systems Interconnection
OTC Over The Counter
OTF Organised Trading Facility
RTS Regulatory Technical Standards
SI Systematic Internaliser
SMSG Securities and Markets Stakeholder Group
TV Trading Venue
UTC Coordinated Universal Time

Table of Contents
Table of Contents...............................................................................................................4
1 Executive Summary ....................................................................................................7
2 Introduction .................................................................................................................8
3 RTS on input and output data of CTPs ........................................................................9
3.1 Quality of transmission protocols..........................................................................9
3.2 Quality and substance of data ............................................................................12
3.2.1 Transmission of data “as close to real time as technically possible” ............12
3.2.2 Standards and format of data to be transmitted to the CTP.........................15
3.2.3 Input and output data ..................................................................................18
3.2.3.1 Regulatory data .......................................................................................18
3.2.3.2 Post-trade core market data ....................................................................31
3.2.3.3 Pre-trade core market data......................................................................55
3.2.4 Presentation of output data .........................................................................70
3.3 Data quality measures and enforcement standards............................................72
3.3.1 Input data quality.........................................................................................72
3.3.2 Output data quality ......................................................................................75
4 RTS on the revenue redistribution scheme................................................................77
4.1 Mandate under Article 27h(8)(a) and (b) of MiFIR ..............................................77
4.1.1 Methodology ...............................................................................................78
4.1.1.1 Application of the criteria at MIC level and availability of information .......78
4.1.1.2 From weights to monetary amounts to percentages.................................81
4.1.1.3 Calculation of the trading volumes ...........................................................82
4.1.1.4 Frequency of the revenue distribution scheme.........................................83
4.1.1.5 Determination of the list of data contributors............................................83
4.1.1.6 First year of operations ............................................................................85
4.1.2 Weighting assigned to each criterion...........................................................86
4.1.2.1 Weights ...................................................................................................86
4.1.2.2 Frequency ...............................................................................................88
4.1.3 Methodology and weights in the RTS..........................................................91

4.2 Mandate under Article 27h(8)(c) of MiFIR...........................................................92
4.2.1 ESMA’s criteria............................................................................................92
4.2.2 Procedure for the suspension and the resumption of redistribution .............95
4.2.3 Notification of suspension ...........................................................................99
4.2.4 Approach to retained revenue and interest applied ...................................100
5 RTS on the synchronisation of business clocks.......................................................102
5.1 Reference time.................................................................................................102
5.2 Level of accuracy for operators of trading venues ............................................103
5.3 Level of accuracy for members, participants or users of a trading venue..........104
5.4 Traceability to UTC...........................................................................................106
5.5 Application of clock synchronisation requirements to new entities ....................106
6 RTS/ITS on the authorisation and organisational requirements for DRSPs .............110
6.1 Authorisation, organisational requirements and publication arrangements of APAs
and ARMs (RTS 13)....................................................................................................110
6.2 Authorisation of CTPs ......................................................................................111
7 Annexes ..................................................................................................................114
7.1 Annex I – Summary of Responses to the Consultation Paper ..........................114
7.1.1 RTS on input and output data of CTPs......................................................114
7.1.2 RTS on the revenue redistribution scheme................................................136
7.1.3 RTS on the synchronisation of business clocks.........................................147
7.1.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
7.1.5 Feedback from the DEG............................................................................154
7.2 Annex II – Cost-Benefit Analysis ......................................................................155
7.2.1 RTS on input and output data of CTPs......................................................155
7.2.2 RTS on the revenue redistribution scheme................................................170
7.2.3 RTS on the synchronisation of business clocks.........................................174
7.2.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
7.3 Annex III – Draft Technical Standards ..............................................................185
7.3.1 Draft RTS on input and output data of CTPs .............................................185
7.3.2 Draft RTS on the revenue redistribution scheme.......................................222
7.3.3 Draft RTS on the synchronisation of business clocks ................................231
7.3.4 Draft RTS on the authorisation of APAs and ARMs...................................239

7.3.5 Draft ITS on the authorisation of APAs and ARMs ....................................258
7.3.6 Draft RTS on the authorisation of CTPs ....................................................279
7.3.7 Draft ITS on the authorisation of CTPs......................................................295
7.4 Annex IV – Legislative mandate to develop technical standards.......................314
7.4.1 RTS on input and output data of CTPs......................................................314
7.4.2 RTS on the revenue redistribution scheme................................................315
7.4.3 RTS on the synchronisation of business clocks.........................................316
7.4.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
7.5 Annex V – Example of a list of data contributors ..............................................319
7.6 Annex VI – Simulation of revenue distribution scheme .....................................322

1 Executive Summary
Reasons for publication
The latest amendments to the Markets in Financial Instruments Regulation (MiFIR) have changed the provisions around the establishment of Consolidated Tape Providers (CTPs) and for Data Reporting Service Providers (DRSPs). ESMA was mandated by the European Commission to develop several technical standards and to periodically organise competitive CTP selection procedures. ESMA has proposed and publicly consulted on these technical standards and in this report presents the received feedback and its final proposals. Contents
Section 2 describes the RTS on input/output data relating to the mandate under Article 22b
of MiFIR which requires ESMA to specify (a) the minimum requirements for the quality of transmission protocols, (b) the data to be disseminated by the CTP, (c) what constitutes as close to real time as technically possible, and (d) the data to be transmitted to the CTP. Compared to ESMA’s original proposal, changes were introduced regarding input data formats, CTP’s responsibilities on input data quality and latency requirements.
Section 3 covers the RTS on the revenue redistribution scheme relating to the mandate
under Article 27h of MiFIR which requires ESMA to specify the methodology relied on by the Equity CTP to redistribute revenues to data contributors. Furthermore, the RTS also include the criteria under which the CTP can suspend data contributors from revenue redistribution. The final RTS include several refinements to allow more flexibility to the CTP in the application of such scheme.
Section 4 presents the RTS on clock synchronisation relating to the mandate under
Article 22c of MiFIR which transposes the clock synchronisation requirement previously set
out in MiFID II. ESMA’s draft RTS specify the level of accuracy to which business clocks must be synchronised, including UTC traceability requirements and maximum divergence levels. The final draft RTS largely align with the original proposal.
Section 5 covers the Technical Standards on the authorisation of DRSPs relating to the
mandates under Articles 27d and 27db of MiFIR. This includes ESMA’s proposal (i) to amend the existing RTS 13 and the related ITS to exclude CTPs; and (ii) for a new RTS and a new related ITS specifically for the authorisation of CTPs. ESMA’s approach from the consultation paper was largely maintained. Next Steps ESMA submitted the Final Report to the European Commission on 16 December 2024. In accordance with Article 10 of Regulation (EU) No 1095/2010 (‘ESMA Regulation’), the Commission has three months to decide whether to endorse.

2 Introduction

The latest legislative amendment to the Markets in Financial Instruments Regulation
(“MiFIR review”) was published in the Official Journal of the European Union on 8 March 2024 and entered into force on 28 March 2024.
The MiFIR review changed in particular the provisions around the establishment of
Consolidated Tape Providers (CTPs) and for Data Reporting Service Providers (DRSPs). It requires ESMA to develop several new Regulatory Technical Standards (RTS) and to revise existing ones.
In May 2024, ESMA published a Consultation Paper 1
(CP) presenting those draft technical standards covering: (i) the input and output data requirements of CTPs, (ii) the revenue redistribution scheme for the equity CTP, (iii) the synchronisation requirements for business clocks, and (iv) the authorisation and organisational requirements for DRSPs. Moreover, it also included (v) ESMA’s initial reflections on the assessment criteria for the CTP selection.
ESMA has received 39 responses to this open consultation, along with advice from ESMA’s
Securities and Markets Stakeholder Group 2
(SMSG), and advice from the Data Expert
Group 3
(DEG). ESMA has analysed the received feedback and has adjusted its initial proposals accordingly. This Final Report summarises, for each technical standard, (i) the original proposal from the consultation, (ii) the received feedback, and (iii) ESMA’s conclusion and next steps.
Following this introduction, Section 3 covers the RTS on input and output data of CTPs,
Section 4 the RTS on the revenue redistribution scheme for the Equity CTP, Section 5 the
RTS on the synchronisation of business clocks, and Section 6 the RTS/ITS on the authorisation and organisational requirements for DRSPs. Annex I contains the summaries of responses per question from the open consultation, Annex II ESMA’s Cost-Benefit Analyses (CBAs), Annex III the final draft technical standards, Annex IV ESMA’s legislative mandates, and Annex V and VI cover examples in relation to the RTS on the revenue redistribution. 1 MiFIR Review Consultation Package - Technical Standards related to Consolidated Tape Providers and DRSPs, and assessment criteria for the CTP selection procedure (23 May 2024). 2 SMSG advice to ESMA on its Consultation Papers (17 September 2024). 3 Reports by the expert stakeholder group on equity and non-equity market data quality and transmission protocols (17 October 2024).

3 RTS on input and output data of CTPs
3.1 Quality of transmission protocols
Proposal in the CP
6. ESMA's proposals focussed on defining the minimum standards for transmission protocols
to ensure efficient, secure, and high-quality data transmission from data contributors to the CTPs.
7. The key proposals include a set of requirements covering the following features of
transmission protocols:
− Performance: Protocols must maintain low latency (<100 ms), high throughput (>100 Mbps), optimized connection setup (<500 ms), and scalability; − Reliability: Error detection, correction, and recovery mechanisms must be in place to ensure data integrity and continuity; − Security: Data confidentiality, authentication, authorization, and non-repudiation must be ensured to protect transmitted data; − Compatibility: Protocols must be open and interoperable with widely recognized standards, ensuring smooth communication across diverse systems and platforms.
8. Moreover, taking into consideration cost efficiency, ESMA proposed a single set of
requirements applicable across all asset classes. This would streamline compliance, reduce administrative burdens, and improve operational efficiency for data contributors reporting to multiple CTPs. Feedback to the consultation
9. The consultation provided an opportunity to gather feedback from stakeholders on both the
overall framework and specific elements of the proposed requirements.
10. General feedback. While respondents expressed general support for the proposed
categories of requirements, they suggested improving clarity by specifying which Open Systems Interconnection (OSI) layer (e.g., transport, application, encoding) applies to each requirement. Regarding the possibility to include additional categories of requirements, respondents recommended including provisions to address evolving market and technological needs, such as backward compatibility. The benefits of a harmonised set of requirements across the three CTPs were recognised. However, respondents highlighted the need to differentiate performance requirements where necessary to reflect specific asset class characteristics.

Performance requirements. Respondents generally considered the proposed
performance requirements as too stringent, especially regarding latency and throughput. Most respondents proposed a reduction or recalibration of these requirements. − Latency requirements: Respondents suggested refining the definition of latency (e.g., time to submit a message vs round-trip time). They recommended recalibrating latency by asset class, with less stringent requirements for bonds, and aligning them with a revised real-time definition. Alternative latency measures, such as using median values or confidence intervals, were also proposed. − Throughput requirements: Respondents recommended lower requirements for smaller data contributors and adjusting throughput requirements based on the data format used (e.g., JSON, which requires higher throughput).
Reliability requirements. Respondents generally supported the proposed reliability
requirements but recommended limiting them to specific layers, such as the transport and application layers. They suggested clarifying which entities the requirements apply to, noting that some requirements, like error correction mechanisms, may be redundant for CTPs, as they are not expected to modify the data.
Security requirements. Respondents generally did not oppose the proposed security
requirements but considered the encryption requirements redundant. Given the nonconfidential nature of the market data transmitted to CTPs, respondents questioned the necessity of encryption for this type of data.
Compatibility requirements. Respondents generally supported the proposed
compatibility requirements but requested clearer definitions of "openness" and "interoperability." A few respondents raised concerns about the openness requirement, as many data contributors use internally developed protocols. Similarly, some questioned the necessity of interoperability, arguing that the limited number of parties involved in the CTP ecosystem may reduce the need for such requirements. ESMA’s assessment and next steps
In response to feedback requesting greater clarity on the application of requirements to
specific OSI layers, ESMA clarifies in the Annex I of the draft RTS which layers 4 apply to each category of requirements. ESMA recognises that this approach aims to provide data ISO/IEC 7498-1:1994 - Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model

The Open Systems Interconnection (OSI) model is a reference model from ISO that provides a common basis for the coordination
of standards development for the purpose of systems interconnection. The 7 different layers are: Physical Layer (1), Data Link Layer (2), Network Layer (3), Transport Layer (4), Session Layer (5), Presentation Layer (6), Application Layer (7).

contributors with a more structured and understandable framework for implementation, ensuring that all protocol standards are applied consistently and appropriately.
16. ESMA has adjusted the performance requirements based on asset class, aligning them
with the differentiated timeliness requirements (further details on the revised proposal in
Section 3.2.1). For data contributors to the equity CTP, ESMA has proposed a minimum
latency of 50 milliseconds to support pre-trade timeliness standards. For contributors to the bonds and derivatives CTPs, a minimum latency of 500 milliseconds has been set, based on the revised timeliness requirement. Additionally, ESMA clarifies that latency should be measured from the data contributor’s outbound transmission to the CTP’s inbound receipt. Suggestions to measure latency using confidence intervals were also incorporated into ESMA’s assessment for revising the timeliness requirements applicable to the equity CTP (further elaborated in Section 3.2.1).
17. Regarding reliability requirements, ESMA has decided to maintain the original proposal,
despite requests to exclude the CTP from error correction mechanisms. ESMA clarifies that it is not feasible to exclude one party from essential protocol features, as both data contributors and the CTP must adhere to a consistent reliability standard. Although the CTP is not expected to correct market data directly, it is responsible for sending other messages to data contributors—such as receipt confirmations and notifications of data quality issues—that should require error correction capabilities.
18. ESMA acknowledges feedback suggesting that encryption may be redundant for the nonconfidential nature of market data. However, ESMA clarifies in this Final Report that
encryption is not included as a requirement in the RTS. Instead, ESMA has limited the security requirements to essential measures, including secure transport layers, authentication, authorization, and non-repudiation.
19. Finally, ESMA has taken into account feedback requesting backward compatibility in
transmission protocols. As a result, this requirement has been added to the set of Compatibility requirements within the RTS. This requirement ensures that protocols can operate with older versions of themselves or previous technologies, allowing new systems to maintain interaction with legacy systems.
Table 1: Transmission protocols requirements and OSI layers
Performance
Latency Layer 3 (Network)
Throughput Layer 1 (Physical), Layer 2
(Data link)
Connection setup time optimization Layer 4 (Transport)

Scalability
Layer 3 (Network), Layer 2
(Data link), Layer 4
(Transport) and Layer 7
(Application)
Reliability
Error detection mechanism Layer 2 (Data link), Layer 4 (Transport) Error correction mechanism Layer 2 (Data link), Layer 4 (Transport) Recovery mechanism Layer 4 (Transport), Layer 5 (Session) Security Secure transport layer Layer 4 (Transport), Layer 7 (Application) Authentication Layer 7 (Application Layer) Authorisation Layer 7 (Application Layer) Non-repudiation Layer 7 (Application Layer) Compatibility Open solution Layer 7 (Application Layer) Interoperability Layer 7 (Application Layer) Backward compatibility Layer 7 (Application Layer)
3.2 Quality and substance of data
3.2.1 Transmission of data “as close to real time as technically possible”
Proposal in the CP
20. In the CP ESMA proposed that:
− for post-trade data, regardless of asset class, data contributors should transmit data to the CTP no later than 100 milliseconds from the execution timestamp (field 1 of Table 3 of Annex I of RTS 1 and field 1 of Table 2 of Annex II of RTS 2) for transactions executed on a trading venue and no later than 200 milliseconds from the execution timestamp for transactions executed OTC;

− for pre-trade equity data, considering the abovementioned high time-sensitiveness of the EBBO, data contributors should transmit data to the CTP no later than 50 milliseconds from the timestamp of the submission of the order (field 1 of Table 1b of
Annex I of RTS 1).
21. Furthermore, no proposal was made in the context of deferred trades, but ESMA looked
for feedback in this regard as to understand if ad-hoc latency should have been proposed. Feedback to the consultation
22. In general, respondents claimed that the latencies proposed in the CP (i) are too stringent,
(ii) should be differentiated across instruments, (iii) should be calculated using a different reference point for data sent by APAs to the CTP.
23. Reference time for OTC transactions: Respondents indicated that the latency should be
calculated from the point in time when the APA receives the relevant data from the investment firm or DPE instead of the execution timestamp. Since it is only from that point that an APA is able to proceed to transmission and public dissemination, the execution timestamp is not considered an appropriate determinant.
24. Alternatively, the latency measured from the execution timestamp in the non-equity space
should be set to 5 minutes.
25. Timeliness thresholds CTP: Respondents provided a wide range of alternative ways to
define “as close to real-time as technically possible”. The general feedback argued in favour of a less ambitious approach, whereas a minority of respondents would be supportive of a more latency-sensitive approach. Market participants proposed setting differentiated latency thresholds for the CTPs by asset classes, suggesting a 50-100 millisecond range for equity venues depending on market share, and longer latencies for bond workflows to be measured in seconds. Furthermore, several respondents flagged the need to relax timeliness requirements for pre-trade data due to volume challenges, as well as proposing alternative measures to measure latency requirements such as confidence intervals or empirically determined thresholds.
26. As far as an ad-hoc latency for deferred trades is concerned, most of the respondents
replied that it is not necessary. Only one respondent suggested that the delay could be 5 seconds.
27. Finally, the data expert stakeholder group (DEG) for bonds established under Article 22b(2)
of MiFIR also provided feedback in this respect (see Annex I). In summary, the DEG indicated that the latency does not take into account the fact that APAs receive the information from investment firms and that currently APAs and trading venues may transmit messages within 1 or 2 seconds. Any requirement to lower latency to 100 - 200ms may incur additional infrastructure investments.

ESMA’s assessment and next steps
28. Based on the analysis of feedback received, ESMA has adjusted the proposal of the draft
RTS in respect of definition of real-time for the transmission of data to the CTP as follows:
29. Reference time for OTC transactions: ESMA acknowledges the comments raised by
respondents indicating that APAs would face challenges in meeting the requirement to transmit data within 200 milliseconds after the execution timestamp, as the data first needs to be received from investment firms or DPEs, whose timeliness is beyond APAs’ control. To address this concern, ESMA has revised the requirement so that the timeliness threshold is based on a certain amount of time after the reception of the data rather than the execution timestamp. As a result, a "reception timestamp" field has been added to the set of input fields that must be transmitted to the CTP.
30. Timeliness thresholds for equity CTP: to ensure low latency, which is considered a
crucial aspect of the equity CTP, ESMA confirms the thresholds proposed in the CP and maintains the thresholds proposed for pre-trade data. For post-trade data, ESMA has aligned the requirements for transactions executed on trading venues to those executed OTC. Additionally, ESMA endorsed the suggestion to implement these requirements using a confidence interval rather than as a hardcoded time requirement. Specifically for the equity CTP, the requirement will be that transactions should meet the timeliness threshold with 95% of the confidence interval on a daily basis. Furthermore, by means of introducing the confidence interval, the latency for post-trade equity data can be further reduced and aligned with that of the pre-trade ones. In this way, both pre-trade and post-trade data flow would be synchronised. Last but not least, it is recalled that those time intervals are the maximum latencies allowed but nothing prevents data contributors from sending the data with more stringent delays. Indeed, it is expected that data contributors send the data to the CTP as soon as possible and without artificial delays compared to sending of data for other purposes, including proprietary feeds, to meet such requirements.
31. As a result, the confirmed requirements are as follows:
− For pre-trade data, data contributors should transmit data to the CTP within 50 milliseconds with a 95% confidence interval from the timestamp of the order submission (field 1 of Table 1 of Annex III of the input/output data RTS). − For post-trade data, trading venues should transmit data to the CTP no later than 50 milliseconds from the execution of the trade executed on-exchange (field 1 of Table 7 of Annex II of the input/output data RTS) with a 95% confidence interval, and APAs should transmit data to the CTP no later than 50 milliseconds from the reception of data related to trades executed OTC (field 9 of Table 7 of Annex II of the input/output data RTS) with a 95% confidence interval.

Timeliness thresholds for bonds and derivatives CTPs: ESMA acknowledges the need
to differentiate post-trade timeliness requirements for non-equity CTPs, where the latency demands are less stringent than for equity. To maintain consistency with existing transparency requirements which allow for a less stringent latency for non-equity transactions compared to equity transactions ESMA agrees to have less demanding timeliness thresholds for bonds and derivatives. Additionally, unlike the requirements for equity, confidence intervals are not included for bonds and derivatives as these timeliness thresholds are less stringent and can therefore be met on a continuous basis. The requirements have been adjusted as follows:
− For on-exchange transactions, data contributors should transmit post-trade data to the CTP within 500 milliseconds after the execution timestamp (field 1 of Table 6 of Annex II of the input/output data RTS). For OTC transactions, data contributors should transmit post-trade data to the CTP within 500 milliseconds after the reception timestamp (field 12 of Table 6 of Annex II of the input/output data RTS).
Deferred trades: ESMA confirms the proposal of not adopting an ad-hoc approach for
deferred trades, considering that most of the respondents to the CP commented that this is not considered a provision necessary.
3.2.2 Standards and format of data to be transmitted to the CTP
Proposal in the CP
The consultation paper proposes that data contributors transmit data to the CTP in a
harmonized format, presenting two alternatives: (i) JSON - recognised for its flexibility - and (ii) binary formats like FAST and SBE, which offer enhanced latency performance. Prescribing a harmonised format is a requirement designed to alleviate the burdensome, costly, and time-consuming process of sourcing data from contributors who utilize diverse data-sharing arrangements.
This proposal was based on findings from a study commissioned by ESMA to Accenture
in 2023 5
, which evaluated the most suitable data formats for CTPs. The study highlighted JSON as a suitable option for generic regulatory reporting; however, it raised concerns regarding its performance in real-time transmission specific to CTP use cases. In contrast, binary formats like FAST and SBE were identified as more suitable for real-time data transmission, offering enhanced performance in terms of latency.
Furthermore, ESMA proposed requiring a single data format solution across all asset
classes. Stakeholders were invited to provide feedback on whether different formats should 5 ESMA12-437499640-2360 Study on data formats and transmission protocols.

be adopted for equity, bond, and derivatives CTPs, considering the distinct business needs and operational requirements of each asset class. Feedback to the consultation
37. The feedback received during the consultation showed a clear preference among
stakeholders for binary formats such as FIX SBE and FAST over JSON for transmitting data to the CTP. This preference was primarily driven by the superior performance of binary formats in handling real-time, high-volume data transmission, which is crucial for market data feeds. Many respondents noted that binary formats are already well-established in the industry for real-time data exchange, providing lower latency, higher throughput, and greater reliability. JSON, while appreciated for its flexibility and ease of use in general regulatory reporting, was widely considered inadequate for CTP purposes due to its verbosity and limitations in efficiently processing large datasets with the low latency required in trading environments.
38. There was considerable support for the adoption of a single binary format across all asset
classes (equity, bond, and derivatives) to promote consistency, streamline integration, and enhance cost-efficiency for data contributors and the CTP. The use of a unified format was viewed as beneficial in reducing the complexity associated with managing multiple data standards, which could otherwise lead to discrepancies, higher operational costs, and increased development time. However, some respondents pointed out the need for flexibility to accommodate the specific requirements of different asset classes, such as the distinct data characteristics and latency needs of equities versus bonds.
39. To address the need for flexibility, stakeholders proposed to allow the CTP to choose the
input data format based on its technical needs and the preferences of data contributors, including the possibility for the CTP to permit data contributors to transmit data in multiple formats, with the CTP responsible for normalising the data.
40. Lastly, the feedback from the DEG is in general against the prescription of a specific data
format by ESMA, in particular for bond and derivatives. The Bond subgroup is supporting compliance with ISO, but it is against overly prescriptive requirements. The Equity subgroup expressed its feedback against JSON, as it is considered too verbose, and suggested alternative formats such as SBE, FAST, ITCH. ESMA’s assessment and next steps
41. Based on the feedback received from the consultation and the DEG, as well as further
evaluation of the proposed data formats, ESMA has formulated the requirements for the input data format. Acknowledging the request for flexibility while highlighting the imperative need for a harmonized data format to ensure standardization and data quality, ESMA does not prescribe a specific data format in the RTS. Instead, it requires that the input data be submitted in a standardised format in accordance with ISO 20022 methodology. This

approach reflects ESMA's commitment to standardization and harmonization in market data reporting, aligning with international best practices.
42. As highlighted in the European Commission's Fitness Check of EU Supervisory Reporting
Requirements 6
, there is a necessity for employing international standards, such as ISO, to foster greater consistency in market data reporting across various frameworks. This initiative, part of the Regulatory Fitness and Performance (REFIT) program, revealed that inefficiencies persist within the current reporting landscape, primarily due to ambiguities in requirements and insufficient adoption of common formats and identifiers. A lack of harmonization and standardization poses challenges, prompting ongoing efforts to enhance reporting practices globally. By advocating for the use of ISO 20022-compatible formats, ESMA aims to align the CTP's data reporting with international best practices, thereby facilitating improved harmonization across data contributors. Central to this proposal is the imperative of enhancing data quality. By standardizing the input data format, ESMA aims to simplify the reconciliation of diverse reporting flows, thus improving overall reporting efficiency.
43. In terms of governance, ESMA has carefully considered the robustness of the ISO 20022
governance framework. Indeed, this standard allows for ESMA’s involvement in the governance process, thereby ensuring that the timelines for development, intellectual property rights, and overall standardization processes are adequately addressed.
44. ISO 20022's extensibility is another compelling advantage. Its three-layer architecture,
encompassing a comprehensive business model absent in many other technical formats, allows for the inclusion of industry-agreed definitions across the financial sector. This extensibility will enable ESMA to adapt and expand the standard in response to emerging needs, thereby reinforcing the foundation for future innovation in data reporting.
45. Additionally, ESMA acknowledges the advice from the Data Experts Group, which
advocated for the autonomy of CTPs in deciding on data formats. By mandating ISO 20022-compatible formats, ESMA strikes a balance between flexibility and high-quality, future-proof data transmission.
46. In response to the strong support expressed by respondents to the consultation for binary
formats, ESMA's proposal does not preclude the use of such formats. Consequently, CTP applicants will be required to demonstrate compliance with ISO 20022 methodologies. If current compatibility is not achievable, they must provide a timeline and concrete plans for future alignment, ensuring uniform preparation of messages prior to the CTP going live.
47. ESMA is aware that this approach may still result in different formats being used for various
asset classes due to their specific requirements. However, limiting the choice to 6 Results of the fitness check of supervisory reporting requirements in EU financial services legislation - European Commission.

ISO 20022-compatible formats aims to reduce potential variation and streamline integration by maintaining a common structural foundation. This approach will help alleviate the operational burden for data contributors who support multiple asset classes while still accommodating the distinct needs of each.
48. Finally, the proposal from respondents to allow data contributors to transmit data in multiple
formats was not taken into account, based on provisions provided by Article 22a(1) of MiFIR. At the same time, given the varying market practices and their level of maturity across different asset classes, adherence to a single syntax when transmitting the data to the data centre of a CTP is not necessary where well-established market practice already exists, e.g. in the case of the equity asset class.
3.2.3 Input and output data
3.2.3.1 Regulatory data
Proposal in the CP
49. Regulatory data - as defined in Article 2(36c) of MiFIR, which states that they are data
related to the status of systems matching orders in financial instruments and to the trading status of individual financial instruments - is a new concept which was never specified in existing MiFIR transparency frameworks. Therefore, ESMA proposed in the CP a set of regulatory data, with a level of granularity at the level of instrument and of the systems matching orders for equity and bonds.
50. The proposed fields are in Tables 1 and 2 on page 28-30 of the CP2 7
for the bond CTP and on page 165 of CP3 8 for the equity CTP.
Feedback to the consultation
51. The main feedback received on regulatory data both for bonds and equity CTP –
collected respectively through the CP2 and CP3 – are summarised in the following paragraphs.
52. Regulatory data not relevant for bonds CTP. Stakeholders highlighted that applying
regulatory data requirements uniformly across bonds and equities may not be suitable. Respondents noted that bonds generally lack centralised price discovery due to their dispersed trading environment across various trading venues and OTC markets. Consequently, some respondents recommended limiting the scope of regulatory data for bonds, arguing that it may not yield meaningful transparency benefits for bond markets. 7 ESMA74-2134169708-7225 MiFIR Review Consultation Package - CTPs and DRSPs. 8 ESMA74-2134169708-7011 MiFIR Review - Consultation Package 3 (equity transparency, volume cap, circuit breakers, SI, the equity CTP, flags under RTS 2).

They raised that requiring regulatory data in this context could create unnecessary operational burdens for venues without enhancing investor insight.
53. Reporting by APAs. Some respondents called for including APAs within the scope of
entities required to report regulatory data. Respondents observed that APAs play a critical role in publishing post-trade transparency data and suggested that regulatory data be reported consistently across all entities handling relevant data. By including APAs in this reporting requirement, the data could offer a more comprehensive view of the market’s operational status, contributing to the completeness and consistency of the CTP data. Respondents also recommended clarifying the handling of outages at the APA level to ensure transparency across all transaction reporting systems.
54. Granularity of Trading System data. Some feedback questioned the appropriate level of
granularity for trading system data, remarking in particular cases where venues operate multiple trading systems or phases under a single MIC. Stakeholders emphasised that regulatory data should allow for sufficient flexibility to capture distinct trading phases and operational conditions of different market segments, such as auction, continuous, or periodic trading. They suggested that overly prescriptive granularity requirements may create confusion and recommended allowing for data to be segmented as necessary based on the unique characteristics of each trading system.
55. Currency as an additional identifier. Stakeholders noted that using only ISIN and
segment MIC as identifiers might not adequately distinguish instruments, especially when a single ISIN is traded in multiple currencies. To address this, it was recommended to include the currency as a mandatory identifier for the CTP. This approach would ensure that each instrument is uniquely identified in cases where multiple listings exist within a single venue. Including currency as an identifier aligns with efforts to enhance data clarity, ensuring that users of the consolidated tape receive accurate and unambiguous information.
56. Instrument Status reporting. Feedback highlighted the need for clarity and flexibility in
instrument status reporting. Respondents pointed out that traditional status indicators like "suspended" or "halted" may not fully capture all trading scenarios. For example, when trading halts for specific currencies or segments under a single system, different status indicators might be needed. Some also suggested using an "Active" or "OK" status to indicate when an instrument resumes trading after a halt.
57. Use of FIX MMT Standards. Several respondents encouraged the use of FIX Market
Model Typology (MMT) standards, particularly for defining trading phases and instrument status at a granular level. According to those stakeholders, the FIX MMT framework is already well-established across markets, and its adoption could streamline regulatory data reporting by using a standard format familiar to both venues and market participants. Stakeholders suggested that incorporating FIX MMT levels, such as MMT Level 2 for

trading modes, could facilitate accurate reporting and foster consistency across trading venues, supporting both transparency and usability.
58. Synchronisation of clocks across reporting entities. Feedback underscored the
importance of synchronising clocks among all reporting entities to maintain data accuracy, particularly for time-sensitive data like instrument status changes. Respondents recommended setting a precise standard for clock synchronisation to ensure consistent timestamps across trading venues, APAs, and other participants. This would improve the reliability and comparability of data on the consolidated tape, allowing users to trust the sequence and timing of reported events across different market entities.
59. ESMA collected some feedback also specifically on regulatory data for the equity CTP.
60. Primary MIC as an identifier. For equities, feedback recommended including the Primary
MIC to enhance instrument identification in cases of multiple listings or cross-listings. According to respondents, the Primary MIC would serve as a reliable identifier for the originating venue of an equity instrument, allowing market participants to distinguish primary listings from secondary ones. By incorporating the Primary MIC, the CTP can offer a more precise view of equity trading activities, which would be especially beneficial in fragmented markets.
61. The Expert Stakeholder Group (DEG) established under Article 22b(2) of MiFIR also
provided feedback (see Annex I).
62. DEG on bonds: In relation to regulatory data, the DEG highlighted in their advice that there
is no demand for the instrument data and for regulatory data for systems other than central limit order book or quote-driven type of trading systems. Thus, calling for a simplification of the regulatory data for bonds.
63. DEG on equity: In relation to regulatory data, the DEG highlighted in their advice to
uniquely identify instrument, the currency is also a relevant element on top of the ISIN and MIC. ESMA’s assessment and next steps
64. Scope of regulatory data. ESMA acknowledges the feedback regarding the limited
applicability of regulatory data requirements for instruments without centralised price discovery, such as bonds. However, ESMA is required to define requirements in line with the reporting framework established under Article 22a of MiFIR, which mandates that regulatory data must be transmitted by data contributors to all three CTPs for bonds, equities, and derivatives. Consequently, while ESMA understands the concerns raised, these requirements cannot be modified under the existing legislative mandate.
65. Granularity and status of instruments and order matching systems. To address
concerns about the level of granularity and the clarity of instrument status reporting, ESMA

has incorporated the FIX MMT standards to align with widely used industry practices, further improving the usability of regulatory data for CTP reporting.
66. The revised regulatory data tables for fields applicable to the equity and bond CTPs are
presented below. Readers can view the revision in track changes, including newly added fields and revisions to existing fields based on feedback received. Two additional columns have been included to indicate whether each field is intended as input and/or output and a brief explanation of ESMA's assessment that contributed to each change. Bonds:
Table 2: Data related to the status of individual financial instruments, input and output
data tables for BONDS (excluding ETCs and ETNs) # Field identi fier Description Format Input /Output data field ESMA’s assessment of the feedback received Instru ment identif icatio n code Code used to identify the financial instrument {ISIN} Both Instru ment status start date and time Date and time from which the instrument status is valid The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Both Instru ment status end date and time Date and time from which the instrument status is no longer valid, where relevant. When the instrument status is “removed from trading” the field should be left blank. {DATE_TIME_FORMAT} This field is no longer necessary after having introduced the status ACTIVE in the instrument status Curre ncy Major currency in which the instrument is traded {CURRENCYCODE_3} Both In line with the feedback received, the field currency is added to uniquely identify the instrument. 4 Instru ment Date and time on which the instrument status is {DATE_TIME_FORMAT} Output This field has been modified to take into

Field identi fier
Description Format
Input
/Output data field
ESMA’s assessment of the feedback received status Ddiss emin ation date and time disseminated by the CTP The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. account the merging of the status of the instrument with that of the trading system. Instru ment status Description of the status of the financial instrument. The status of the financial instrument can be:
(1) suspended from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (2) removed from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (3) subject to a trading halt, on the trading venue identified in the field “Trading venue”, in accordance with Articles 18(5) and 48(5) of Directive 2014/65/EU (4) ACTV the instrument is available for trading after a suspension, removal or halt ‘SUSP’ – the instrument is suspended ‘REMV’ – the instrument is removed ‘HALT’ – the instrument is subject to a trading halt ‘ACTV’ - the instrument is available for trading after a suspension, removal or halt Both In line with the feedback received, the active status is added to indicate that the instrument is available for trading. Tradi ng venu e Identification of the trading venue on which the instrument status is valid (segment MIC where available, {MIC} Both

Field identi fier
Description Format
Input
/Output data field
ESMA’s assessment of the feedback received otherwise operating MIC).
The trading venue is a regulated market, an
MTF or an OTF.
Tradi ng syste m
Type of trading system on which the instrument is traded CLOB - Central Limit Order Book 'QDTS' - Quote Driven Market PATS - Periodic Auction 'RFQT' Request for Quotes ‘VOIC’ - Voice trading system HYBR - Hybrid System OTHR - Any Other Both In line with the feedback received, to ensure that an instrument traded on different trading types but having different status is clearly reported and identified.

Table 3: Data related to the status of the system matching order, input and output data
tables for BONDS (excluding ETCs and ETNs)

Field

identifier
Description Format Input
/Output data field
ESMA’s assessment of the feedback received
Trading venue
Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market, an MTF or an OTF. {MIC} Both Trading system Type of trading system on which the system status is provided CLOB - Central Limit Order Book 'QDTS' - Quote Driven Market PATS - Periodic Auction RFQT Request for Quotes ‘VOIC’ – voice trading system HYBR - Hybrid System OTHR - Other Both System status start date and time Date and time from which the system status is valid The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Both System status end date and time Date and time from which the system status is no longer valid {DATE_TIME_FORMAT}

System status
Dissemin ation date and time
Date and time on which the system status is disseminated by the CTP.
The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Output Trading system status Description of the status of the trading system. The trading system can be: (1) subject to an outage; or (2) in one of the following trading phase:
preopening, opening auction, trading, closing auction, trading-at-last, closed Status of the trading system on which the instrument is traded ACTV – Active System OTAG - Outage of the trading system POTG - Partial outage of the trading system Both In line with the feedback received an active status and a partial outage option have been added.

Shares and ETFs:
Table 4: Data related to the status of individual financial instruments, input and output
data tables for SHARES and ETFs

Field
Input
/Output data field
ESMA’s assessment of the feedback received
Instrument identificatio n code
Code used to identify the financial instrument {ISIN} Both Instrument status start date and time Date and time from which the instrument status is valid For transactions executed on a trading venue, The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Both Instrument status end date and time Date and time from which the instrument status is no longer valid {DATE_TIME_FORMAT} This field is no longer necessary after having introduced the status ACTIVE in the instrument status 3 Currency Major currency in which the instrument trades. {CURRENCYCODE_3} Both In line with the feedback received, the field currency is added to uniquely identify the instrument Instrument status Disseminati on date and time Date and time on which the instrument status is disseminated by the CTP The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Output Instrument status Description of the status of the financial instrument. The status of the financial instrument can be:
(1) suspended from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (2) removed from trading, on the trading venue identified in the field “Trading venue”, in ‘SUSP’ – the instrument is suspended ‘RMOV’ – the instrument is removed ‘HALT’ – the instrument is subject to a trading halt ‘ACTV’ - the instrument is available for trading after a suspension, removal or halt Both In line with the feedback received, the active status is added to indicate that the instrument is available for trading

Field
Input
/Output data field
ESMA’s assessment of the feedback received accordance with Article 32 and 52 of Directive 2014/65/EU (3) subject to a trading halt, on the trading venue identified in the field “Trading venue”, in accordance with Articles 18(5) and 48(5) of Directive 2014/65/EU (4) ‘ACTV’ the instrument is available for trading after a suspension, removal or halt. Trading venue Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market or an MTF. {MIC} Both Trading system Type of trading system on which the instrument is traded. ''CLOB' - Central Limit Order Book 'QDTS' - Quote Driven Market 'PATS' - Periodic Auction 'RFQT' - Request for Quotes HYBR’ - Hybrid System ’OTHR’ - Other Both In line with the feedback received, to ensure that an instrument traded on different trading types but having different status is clearly reported and identified. Trading phase Type of trading phase of the trading system on which the instrument trades. ‘UDUC’ - Undefined Auction ‘SOAU‘ - Scheduled Opening Auction ‘SCAU‘ - Scheduled Closing Auction ’SIAU’ - Scheduled Intraday Auction ‘UAUC’ - Unscheduled Auction Both In line with the feedback received, to ensure that an instrument traded on different trading types and phases but having different status is clearly reported and identified.

Field
Input
/Output data field
ESMA’s assessment of the feedback received
‘ODAU’ - On Demand
Auction (Frequent
Batched Auction)
‘CONT’ - Continuous
Trading
‘MACT’ - At Market Close
Trading
‘OMST’- Out of Main
Session Trading
‘TROE’- Trade Reporting
(On Exchange)
’TROF’ - Trade Reporting
(Off Exchange)
’TRSI’ - Trade Reporting
(Systematic Internaliser)
OTHR - other
Most
Relevant
Market in terms of liquidity
Identification of the trading venue in Field 6 being the most relevant market TRUE – Yes FALSE - No Output In line with the feedback received, to identify the Primary Listing, this field is maintained. This information shall be retrieved from the transparency calculations published by ESMA currently in FITRS IT System

Table 5: Data related to the status of the system matching orders, input and output data
tables for SHARES and ETFs

Field
Input
/Output data field
ESMA’s assessment of the feedback received
Trading venue
Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market or an MTF. {MIC} Both Trading system Type of trading system on which the system status is provided ''CLOB' - Central Limit Order Book 'QDTS' - Quote Driven Market 'PATS' - Periodic Auction 'RFQT' - Request for Quotes HYBR’ - Hybrid System ’OTHR’ - Other Both System status start date and time Date and time from which the system status is valid. The level of granularity shall be in accordance with the requirements set out in
Article 2 of Delegated
Regulation (EU) 2017/574.
{DATE_TIME_FORMAT}
Both As requested in the feedback the timestamps are required to be with the level of granularity required in the business clock synchronisation RTS. System status end date and time Date and time from which the system status is no longer valid {DATE_TIME_FORMAT} This field is no longer necessary after having introduced the status ACTIVE in the instrument status System status disseminati on date and time Date and time on which the system status is disseminated by the CTP. The level of granularity shall be in accordance with the requirements set out in
Article 5 of Delegated
Regulation (EU) 2017/574.
{DATE_TIME_FORMAT}
Output
Trading phase
Type of trading phase of the trading system
‘UDUC’ - Undefined Auction Both In line with the feedback

Field
Input
/Output data field
ESMA’s assessment of the feedback received
‘SOAU‘ - Scheduled
Opening Auction
‘SCAU‘ - Scheduled Closing
Auction
’SIAU’ - Scheduled Intraday
Auction
‘UAUC’ - Unscheduled
Auction
‘ODAU’ - On Demand
Auction (Frequent Batched
Auction)
‘CONT’ - Continuous
Trading
‘MACT’ - At Market Close
Trading
‘OMST’- Out of Main
Session Trading
‘TROE’- Trade Reporting
(On Exchange)
’TROF’ - Trade Reporting
(Off Exchange)
’TRSI’ - Trade Reporting
(Systematic Internaliser)
OTHR - other received, to ensure that an instrument traded on different trading types and phases but having different status is clearly reported and identified. Trading system status Status of the trading system ACTV – Active System OTAG - Outage of the trading system POTG - Partial outage of the trading system Both In line with the feedback received an active status and a partial outage option have been added, as an example, to cater for the case when the outage affects only few instruments.

3.2.3.2 Post-trade core market data
Proposal in the CP
67. In the CP, ESMA identified two main principles that should guide the definition of the input
/ output fields for the CTP post-trade core market data:
− Parsimony: the input data to the CTP should only be specified anew where necessary, i.e. where the data is not already specified in RTS 1 / 2. − Consistency: where the data is already specified in RTS 1 / 2, the RTS on input/output should be drafted in such a way that the same information is not duplicated in both RTSs. To achieve this objective, the fields common to both RTSs will be specified in RTS 1 / 2, and cross-references to those fields will be made in the RTS on input/output. This approach ensures that future changes to RTS 1/ 2 are automatically applied to the CTP fields defined in the CTP RTS on input/output.
68. Level 1 provides a definition of core market data and requires ESMA to spell out both input
and output data in a way that consistency with existing transparency regimes (i.e. RTS 1 and 2) is ensured. Therefore, for the definition of bond and equity CTP fields (both input and output), ESMA performed a gap analysis between the information that the CTP should receive / disseminate and the post-trade transparency fields defined in the RTS 1 and 2.
69. As a result of this analysis, ESMA proposed to include two fields in the list of output fields
that are not present in RTS 2, i.e. the timestamp information on the dissemination of core market data – that should be produced by the CTP - and the type of trading system – which should be provided by the data contributor as input data.
70. Furthermore, ESMA identified two fields to be transmitted to and published by the CTP that
are included in RTS 2 but not envisaged by the Level 1 definition of core market data. Those were the venue of publication and the Transaction Identification Code. The former would help data users to identify the APA that performed the publication of the report as published by the CTP (in the case of off-venue transactions) and to reconcile this information with the one published individually by APAs. The Transaction Identification Code would allow data users to obtain an accurate and comprehensive picture of the transactions which have taken place, including events affecting those transactions after their initial publication (amendments, cancellations, deferrals).
71. The proposed fields are in Section 3.2.2.3.3, page 30 onwards of the CP2 for the core
market data of the bonds CTP, whereas the ones related to the equity CTP are provided at page of CP3. Feedback to the consultation
72. The following comments were received on post-trade data for both, bonds and equity CTP.

Removing references to RTS 1 / 2 fields. Several respondents expressed a preference
for this RTS to directly include the explicit list of required post-trade data fields, rather than referencing the ones provided by RTS 1 and RTS 2. Respondents noted that crossreferencing to other regulatory sources might complicate the implementation process, as it requires data contributors to consult multiple documents to ensure compliance. By consolidating the field requirements into a single, comprehensive list within this RTS, ESMA could reduce ambiguity and facilitate a clearer understanding of reporting obligations.
Removing unnecessary fields. Some stakeholders recommended that ESMA revises the
list of input data fields, suggesting that not all fields listed in RTS 1 and 2 are essential for the CTP’s operation. They argued that certain data points add little value to the consolidated tape’s core functionality and could be omitted to reduce complexity and costs. By focusing only on key fields, ESMA could lower operational burdens for data contributors, and enhance the overall usability of the consolidated tape for end users.
Reception and reporting timestamps for APAs. Feedback indicated strong support for
including timestamps to provide precise data on when trades are received by APAs from investment firms/DPEs and transmitted to the CTP. This additional timestamp would enhance data accuracy and traceability, especially for the verification of timeliness requirements.
Erroneous Trade Flag. As detailed in Section 3.3 – Data quality measures, feedback from
the consultation strongly highlighted the role and responsibilities of the CTP in managing data quality issues. Specifically, several respondents recommended that ESMA assigns the CTP a role in flagging potentially erroneous data to the public. In response, stakeholders suggested adding an “erroneous trade flag” to the list of output fields to indicate trades with potential inaccuracies. Additionally, some respondents proposed including a field in the input data set to allow APAs to flag instances of potential erroneous trades submitted by investment firms or DPEs directly to the CTP.
NLTS (Non-Limited Trading System) Flag for Equity CTP. For equities, respondents
agreed with adding an NLTS flag to identify trades executed under a pre-trade large-inscale (LIS) waiver.
Cancellation and Amendments. It was noted that the consultation lacks detail on how
corrections to previously reported data would be handled by the CTP. In practice, trading venues and APAs frequently make amendments or cancellations to previously published data. Participants invited ESMA to give clear guidelines on how the CTP would process and disseminate such corrections to ensure data accuracy and consistency over time (both in real-time and historical data corrections).
DEG. Finally, the DEG highlighted that, to uniquely identify an instrument, the currency is
also a relevant element on top of the ISIN and MIC. Furthermore, they invited ESMA to leverage trade flagging standards widely adopted, such as the FIX MMT model.
Moreover, they suggested that the post-trade CTP receives the execution timestamp by
TV, APA and DPE or IF and the trade publication time stamp by each TV, APA. In addition, they advised that at a minimum the CT should publish on top of two previously mentioned timestamps the reception timestamp by the CT for each message and the trade publication timestamp by the CT. While the latter is included in the table, the former will be added as suggested.
Finally, the DEG also advised that, in the case of inaccurate information detected, the CT,
on top of informing the entity to check the correctness of the data, to publish the trade accompanied by a “Suspicious data” flag. ESMA has integrated this feedback in the final proposal presented in the next sub-section. ESMA’s assessment and next step
Based on the feedback received, ESMA has integrated the tables of post-trade data while
keeping the references to RTS 1 and RTS 2. This should provide a clear, explicit list of required input and output fields directly within this RTS. Although the substance and format of those fields align with those in RTS 1 and 2, ESMA acknowledged that consolidating them in this RTS enhances clarity and eliminates the need for cross-referencing.
In response to the received feedback, ESMA has streamlined the list of fields, removing
those deemed non-essential, to reduce complexity.
ESMA has incorporated additional fields as suggested by respondents. Notably, APA
timestamps have been added to support timeliness checks, the NLTS flag has been maintained in the table for equities to support the application of revenue redistribution requirements (this flag is necessary to calculate the pre-trade transparent turnover of the trading venue for criterion 3 under Article 27(7)(c)), and the erroneous trade flag has been introduced to enhance data quality. For further details about roles and responsibilities of the CTP as for data quality assurance, please refer to ESMA’s assessment in Section 3.3.
Below, ESMA presents the updated tables of input and output data fields specific to bond
and equity CTPs, including explanatory text of the field on top of the simple reference to RTS 2 or RTS 1. The tables in the RTS will however, only include the references, when possible, to the fields in the post-trade transparency reports of Table 2 of Annex II of RTS 2 for bonds or Table 3 of Annex I of RTS 1 for equities.
The column financial instrument has been removed for bonds, as contrary to the post-trade
transparency information, fields should be reported for all bonds.
Changes are highlighted in red, with explanations on ESMA’s assessment in the final
column of each table. The text highlighted in light blue corresponds to the version included in the RTS.

Bonds:
Table 6: Data related to the core market data, input and output data tables for BONDS (excluding ETCs and ETNs)

Field identifier Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 1 Input /Output data field ESMA’s assessment of the feedback received Trading date and time Date and time when the transaction was executed. For transactions executed on a trading venue, the level of granularity shall be in accordance with the requirements set out in
Article 2 of Commission Delegated Regulation (EU) 2017/574 (1).
For transactions not executed on a trading venue, the date and time shall be when the parties agree the content of the following fields: quantity, price, currencies, as specified in fields 31, 34 and 44 of Table 2 of Annex I of Delegated Regulation (EU) 2017/590, instrument identification code, instrument classification and underlying instrument code, where applicable. For transactions not executed on a trading venue the time reported shall be granular to at least the nearest second. Where the transaction results from an order transmitted by the executing firm on behalf of a client to a third party where the conditions for transmission set out in Article 4 of Delegated Regulation (EU) 2017/590 were not satisfied, this shall be the date and time of the transaction rather than the time of the order transmission. Field 1 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Regulated Market (RM) Multilateral Trading Facility (MTF), Organised Trading Facility (OTF) Approved Publication Arrangement (APA) {DATE_TIME_ FORMAT} Both

Instrument identification code
Code used to identify the financial instrument Field 2 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {ISIN}. Both 3 Price Traded price of the transaction excluding, where applicable, commission and accrued interest. The traded price shall be reported in accordance with standard market convention. The value provided in this field shall be consistent with the value provided in the field “Price Notation”. Where price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated. Field 3 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {DECIMAL-18/13} in case the price is expressed as monetary value {DECIMAL-11/10} in case the price is expressed as percentage or yield {DECIMAL-18/17} in case the price is expressed as basis points Both 4 Missing Price Where price is currently not available but pending, the value shall be “PNDG”. Where price is not applicable the value shall be “NOAP”. Field 4 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA “PNDG” in case the price is not available “NOAP” in case the price is not applicable Both Price currency Major currency in which the price is expressed (applicable if the price is expressed as monetary value). Field 5 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {CURRENCY CODE_3} Both

6 Price notation
Indication as to whether the price is expressed in monetary value, in percentage, in basis points or in yield The price notation shall be reported in accordance with standard market convention. For credit default swaps, this field shall be populated with “BAPO”. For bonds (other than ETNs and ETCs) this field shall be populated with percentage (PERC) of the notional amount. Where a price in percentage is not the standard market convention, it shall be populated with YIEL, BAPO or MONE, in accordance with the standard market convention. The value provided in this field shall be consistent with the value provided in the field “Price”. Where the price is reported in monetary terms, it shall be provided in the major currency unit. Where the price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated. Field 6 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA “MONE” —Monetary value “PERC” —Percentage “YIEL” — Yield “BAPO” — Basis points Both This field has been adapted to cater only for bonds which are the relevant instrument of the CTP.

7 Quantity
For financial instruments traded in units, the number of units of the financial instrument. Empty otherwise. Field 7 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {DECIMAL- 18/17} Both Quantity in measurement unit The equivalent amount of commodity or emission allowance traded expressed in measurement unit. RM, MTF, OTF, APA {DECIMAL- 18/17} In line with the feedback received, this field has been removed since it is not relevant for bonds. Notation of the quantity in measurement unit Indication of the notation in which the quantity in measurement unit is expressed. RM, MTF, OTF, APA “TOCD” —tonnes of carbon dioxide equivalent, for any contract related to emission allowances “TONE” — metric tonnes “MWHO” —megawatt hours “MBTU” — one million British thermal units “THMS” Therms “DAYS”— days or {ALPHANUM-4} otherwise In line with the feedback received, this field has been removed since it is not relevant for bonds.

Notional amount
This field shall be populated:
(i) for bonds (excluding ETCs and ETNs), with the face value, which is the amount repaid at redemption to the investor; (ii) for ETCs and ETNs and securitised deriva tives, with the number of instruments exchanged between the buyers and sellers multiplied by the price of the instrument exchanged for that specific transaction. Equivalently, with the price field multiplied by the quantity field; (iii)for structured finance products (SFPs), with the nominal value per unit multiplied by the number of instruments at the time of the transaction; (iv) for credit default swaps, with the notional amount for which the protection is acquired or disposed of; (v) for options, swaptions, swaps other than those in (iv), futures and forwards, with the notional amount of the contract; (vi) for emission allowances, with the resulting amount of the quantity at the relevant price set in the contract at the time of the trans action. Equivalently, with the price field multiplied by the quantity in measurement unit field; (vii) for spread bets, with the monetary value wagered per point movement in the underlying financial instrument at the time of the transaction; (viii) for contracts for difference, with the number of instruments exchanged between the buyers and sellers multiplied by the price of the instrument exchanged for that specific transaction. Equivalently, with the price field multiplied by the quantity field. Field 10 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {DECIMAL-18/5} Both This field has been adapted to cater only for bonds which are the relevant instrument of the CTP.

Notional currency
Major currency in which the notional amount is denominated.
In the case of an FX derivative contract or a multi-currency swap or a swaption where the underlying swap is multi-currency or a currency CFD or spread-betting contract, this will be the notional currency of leg 1. Field 11 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {CURRENCY CODE_3} Both This field has been adapted to cater only for bonds which are the relevant instrument of the CTP. 10 Venue of execution Identification of the venue where the transaction was executed. Use the ISO 10383 segment MIC for transactions executed on an EU trading venue. Where the segment MIC does not exist, use the operating MIC. Use “SINT“ for financial instruments admitted to trading or traded on a trading venue, where the transaction on that financial instrument is executed on a Systematic Internaliser. Use MIC code “XOFF” for financial instruments admitted to trading or traded on a trading venue, where the transaction on that financial instrument is neither executed on an EU trading venue nor executed by a systematic internaliser. If the transaction is executed on an organised trading platform outside of the EU then in addition to “XOFF” also the population of the field “Third-country trading venue of execution” is required. Field 13 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {MIC} – EU trading venues or “SINT” — systematic inter naliser “XOFF” — otherwise Both

Third-country trading venue of execution
Identification of the third-country trading venue where the transaction was executed. Use the ISO 10383 segment MIC. Where the segment MIC does not exist, use the operating MIC. Where the transaction is not executed on a third- country trading venue, the field shall not be populated. Field 14 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. APA {MIC} Both Date and Time when the data contributor received the data Date and time when the transaction report was received by and trading venue or APA. The level of granularity shall be in accordance with the requirements set out in Article 6 of Delegated Regulation (EU) 2017/574. RM, MTF, OTF, APA {DATE_TIME_ FORMAT} Input This field has been added, as also proposed in the feedback received, to allow the CTP to check the latency within which the APA publishes the data. Publication Date and Time of the data contributor Date and time when the transaction was published by a trading venue or APA. For transactions executed on a trading venue, the level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. For transactions not executed on a trading venue, the time reported shall be granular to at least the nearest second. Field 15 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. . RM, MTF, OTF, APA {DATE_TIME_ FORMAT} Both

Venue of publication
Code used to identify the trading venue and APA publishing the transaction. Field 16 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {MIC} Both Transaction Identification Code Alphanumerical code assigned by trading venues (pursuant to
Article 12 of Commission Delegated Regulation (EU) 2017/580
(2)) and APAs and used in any subsequent reference to the specific trade. Field 17 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA {ALPHA NUMERICAL-52} Both 18 Transaction to be cleared Code to identify whether the transaction will be cleared. RM, MTF, OTF, APA “TRUE” — trans action to be cleared “FALSE” — trans action not to be cleared In line with the feedback received, this field has been removed since it is not relevant for bonds. 16 Reception Date and Time by the CTP Date and time when the transaction was received by the CTP. The level of granularity shall be in accordance with the requirements set out in Articles 2 and 6 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output In line with the equity CTP this field is added to ensure that is clear the date and time at which the data was received by the CTP. Publication Date and Time of the CTP Date and time when the transaction was published by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output As suggested in the feedback received, it has been clarified that this is the date and time at which the CTP published the information.

18 Flags
Applicable flags for the purpose of post-trade transparency.
Where none of the specified circumstances apply, the transaction should be published without a flag. Where a combination of flags is possible, the flags should be reported separated by commas. Field 19 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF, APA As defined in Table 3 of
Annex II
Both In line with RTS 2 it is allowed to report flags either in one field or in several ones. 19 Suspicious Data Flag Data quality flag reported by the CTP when the APA or the CTP have identified trades that for them might be subject to data quality issues. CTP TRUE or FALSE Output According to stakeholders, it is more informative to publish information with a flag indicating that there is a potential data quality issue than not publish the information at all. Therefore, this field has been added.

20 Trading
System Type
Type of trading system on which the transaction was executed.
When the field 'Venue of execution' is populated with "SINT" or "XOFF", this field shall not be populated. Field 20 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. RM, MTF, OTF 'CLOB' -- central limit order book trading system, as defined in Article 1(1) of this Commission Delegated Regulation 2017/583 RTS. 'QDTS' -- quote driven trading systems, meaning a system where transactions are concluded on the basis of firm quotes that are continuously made available to participants, which requires the market makers to maintain quotes in a size that balances the needs of members and participants to deal in a commercial size and the risk to which the market maker exposes itself. 'PATS' -- periodic auction trading systems, as defined in Article 1(2) of this RTS. Both

45 'RFQT' -- request for quote trading systems, meaning a trading system where a quote or quotes are provided in response to a request for a quote submitted by one or more other members or participants. The quote is executable exclusively by the requesting member or market participant. The requesting member or participant may conclude a transaction by accepting the quote or quotes provided to it on request. ‘VOIC’ – voice trading system, meaning a trading system where transactions between members are arranged through voice negotiation. ‘HYBR’ – hybrid trading system meaning a system falling into two or more of the types of trading systems referred to above. ‘OTHR’ – any other trading system, meaning any other type of trading system not covered above.

Shares and ETFs:
Table 7: Input and Output table for post-trade core market data for SHARES and ETFs
Field num
Field identifier
Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 2 Input / Output data field ESMA’s assessment of the feedback received 1 Trading date and time Date and time when the transaction was executed. For transactions executed on a trading venue, the level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. For transactions not executed on a trading venue, the date and time when the parties agree the content of the following fields: quantity, price, currencies, as specified in fields 31, 34 and 44 of Table 2 of Annex I of Delegated Regulation (EU) 2017/590, instrument identification code, instrument classification and underlying instrument code, where applicable. For transactions not executed on a trading venue the time reported shall be granular to at least the nearest second. Where the transaction results from an order transmitted by the executing firm on behalf of a client to a third party where the conditions for transmission set out in Article 4 of Delegated Regulation (EU) 2017/590 were not satisfied, Regulated Market (RM), Multilateral Trading Facility (MTF), Organised Trading Facility (OTF) Approved Publication Arrangement (APA) {DATE_TIME_FORMAT} Both

this shall be the date and time of the transaction rather than the time of the order transmission. Field 1 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 2 Instrument identification code Code used to identify the financial instrument. Field 2 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF, APA {ISIN} Both 3 Price Traded price of the transaction excluding, where applicable, commission and accrued interest. Where price is reported in monetary terms, it shall be provided in the major currency unit. Where price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated. Field 3 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF, APA {DECIMAL-18/13} in case the price is expressed as monetary value {DECIMAL-11/10} in case the price is expressed as percentage or yield {DECIMAL-18/17} when the price is expressed as basis points in the case of certificates and other equity-like financial instruments Both This field has been adapted to cater only shares and ETFs. 4 Missing Price Where price is currently not available but pending, the value shall be “PNDG”. Where price is not applicable, the value shall be “NOAP”. RM, MTF APA “PNDG” in case the price is not available “NOAP” in case the price is not applicable Both

Field 4 of Table 3 of Annex I of Delegated
Regulation (EU) 2017/587
5 Price currency Major currency unit in which the price is expressed (applicable if the price is expressed as monetary value). Field 5 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF APA {CURRENCYCODE_3} Both 6 Price notation Indication as to whether the price is expressed in monetary value, in percentage or in yield. RM, MTF APA MONE’ — Monetary value in the case of equity and equity-like financial instruments “PERC” — Percentage in the case of certificates and other equity-like financial instruments “YIEL” — Yield in the case of certificates and other equity-like financial instruments “BAPO” — Basis points in the case of certificates and other equity-like financial instruments This field has been deleted since it should always be monetary value in the case of the CTP for shares and ETFs. 7 6 Quantity Number of units of the financial instruments. RM, MTF, APA {DECIMAL-18/17} in case the quantity is expressed as number of units Both This field has been adapted to

The nominal or monetary value of the financial instrument.
Field 7 of Table 3 of Annex I of Delegated
Regulation (EU) 2017/587
{DECIMAL-18/5} in case the quantity is expressed as monetary or nominal value accommodate only shares and ETFs. 8 7 Venue of execution Identification of the venue where the transaction was executed. Use the ISO 10383 segment MIC for transactions executed on an EU trading venue Where the segment MIC does not exist, use the operating MIC. Use “SINT” for financial instruments admitted to trading or traded on a trading venue, where the transaction on that financial instrument is executed on a Systematic Internaliser. Use MIC code “XOFF” for financial instruments admitted to trading or traded on a trading venue, where the transaction on that financial instrument is neither executed on an EU trading venue nor executed on a systematic internaliser. If the transaction is executed on an organised trading platform outside of the EU then in addition to the MIC code “XOFF” also the population of the field “Third-country trading venue of execution” is required. Field 8 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF, APA {MIC} – EU trading venues or “SINT” — systematic internaliser “XOFF” — otherwise Both

8 Third-country trading venue of execution
Identification of the third-country trading venue where the transaction was executed. Use the ISO 10383 segment MIC. Where the segment MIC does not exist, use the operating MIC. Where the transaction is not executed on a third-country trading venue, the field shall not be populated. Field 9 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 APA {MIC} Both 9 Date and Time when the data contributor received the data Date and time when the transaction report was received by an APA. The level of granularity shall be in accordance with the requirements set out in Article 6 of Delegated Regulation (EU) 2017/574. APA {DATE_TIME_ FORMAT} Input This field has been added, as also proposed in the feedback received, to allow the CTP to check the latency within which the APA publishes the data. 10 Trading system Type of trading system on which the transaction was executed. When the field 'Venue of execution' is populated with "SINT" or "XOFF", this field shall not be populated. Field 10 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF ''CLOB' -- central limit order book trading systems. A continuous auction order book trading system as defined in Table 1 of Annex I of RTS 1and a trading system combining elements of a continuous auction order book trading defined in Table 1 of Annex I of RTS 1and of periodic auction trading system as Both

defined in Table 1 of Annex I of RTS 1.
'QDTS' -- quote driven trading systems. As defined in Table 1 of Annex I of RTS 1. 'PATS' -- periodic auction trading systems. As defined in Table 1 of Annex I of RTS 1. 'R F Q T' -- request for quote trading systems. As defined in Table 1 of Annex I of RTS 1. ‘HYBR’ -- hybrid trading systems. As defined in
Table 1 of Annex I of RTS 1. A trading system
combining elements of a continuous auction order book trading defined in
Table 1 of Annex I of RTS 1
and of periodic auction trading system defined in
Table 1 of Annex of RTS 1
shall not be considered a hybrid system but a CLOB.
’OTHR’ -- for any other trading system. As defined

in Table 1 of Annex I of
RTS 1.
11 Publication date and time of the data contributor Date and time when the transaction was published by a trading venue or APA. For transactions executed on a trading venue, the level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. For transactions not executed on a trading venue, the date and time shall be granular to at least the nearest second. Field 11 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF, APA {DATE_TIME_FORMAT} Both In line with the feedback received, it is clarified that this is the date and time at which the data contributor has published the data. 12 Venue of Publication Code used to identify the trading venue or APA publishing the transaction. Field 12 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 RM, MTF, APA {MIC} Both 13 Transaction identification code Alphanumerical code assigned by trading venues (pursuant to Article 12 of Commission Delegated Regulation (EU) 2017/580 (1) and APAs and used in any subsequent reference to the specific trade. The transaction identification code shall be unique, consistent and persistent per ISO 10383 segment MIC and per trading day. Where the trading venue does not use segment MICs, RM, MTF, APA {ALPHANUM-52} Both

the transaction identification code shall be unique, consistent and persistent per operating MIC per trading day. Where the APA does not use MICs, it shall be unique, consistent and persistent per 4- character code used to identify the APA per trading day. The components of the transaction identification code shall not disclose the identity of the counter- parties to the transaction for which the code is maintained. Field 13 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 14 Reception Date and Time by the CTP Date and time when the transaction was received by the CTP. The level of granularity shall be in accordance with the requirements set out in Articles 2 and 6 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output In line with the feedback received, it is clarified that this is the date and time at which the CTP has received the data. 15 Publication Date and Time of the CTP Date and time when the transaction was published by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output In line with the feedback received, it is clarified that this is the date and time at which the CTP has published the data. 16 Flags This field should be populated with the list of all applicable flags as described in Table 4 of
Annex 1. Including, when applicable, the
“NTLS” (Pre-trade large in scale waiver flag) for transactions which are executed in accordance RM, MTF, APA As per Table 4 of Annex 1 Both Only input for NTLS flag According to stakeholders, it is more informative to publish information with a flag indicating

with Article 4(1), point (c), of Regulation (EU) No 600/2014.
Where none nof the specified circumstances apply, the transaction should be published without a flag. Where a combination of flags is possible, the flags should be reported separated by commas. that there is a potential data quality issue than not publish the information at all. Therefore, this field has been added. Suspicious Data Flag Data quality flag reported by the CTP when the APA or hte CTP have identified trades that for them might be subject to data quality issues. CTP TRUE or FALSE Output

3.2.3.3 Pre-trade core market data
Proposal in the CP
88. For the input table, ESMA proposed a detailed table, Table 1b in Section 4.1.3.1 of the
CP3, on the pre-trade transparency fields to be published which served as the basis of the information to be transmitted to the CTP for the purpose of publishing the European best bid and offer and the relevant data for auctions trading systems.
89. Furthermore, it was recalled that the information to be sent to the CTP is limited to the best
bid and offer of shares and ETFs available for trading in continuous order books and auction trading systems of regulated markets and multilateral trading facilities.
90. Finally, it was proposed to exclude from the input and, consequently, from the output data
for the CTP, one field included in Table 1b, “the aggregate number of orders and the instruments that they represent at each price level for at least the five best bid and offer price levels”. Considering that the pre-trade transparency information to be published by the CTP is limited to the EBBO, it did not seem necessary to require such field.
91. As far as the pre-trade output table is concerned, Figures 14-16 in CP3 presented the
expected outcome for a continuous auction order book and for an auction trading system to be published by the CTP. The tables did not include extra fields compared to those required by Level 1.
92. Table 5 in the RTS on the input / output data in Annex 10.4.8. in CP3 provided the output
table, i.e. for the core market data for shares and ETFs to be disseminated by the pre-trade
CTP.
Feedback to the consultation
93. Removing references to RTS 1. Similar to the post-trade data feedback, respondents
expressed a preference for this RTS to contain a standalone list of required pre-trade data fields, rather than referencing RTS 1. Consolidating these requirements directly in this RTS would simplify compliance by providing a comprehensive field list within a single document, thus reducing the need for cross-referencing, and enhancing clarity. Input data feedback:
− Feedback against removal of Quantity Currency Unit (Field 8). Some stakeholders opposed the exclusion of Field 8, by arguing that this field is necessary in cases where instruments are traded in multiple currencies, as it helps avoid confusion and ensures that data accurately reflects trading conditions.

− Support for exclusion Aggregated Number of Orders and Quotes (Field 9). Feedback generally supported the exclusion of Field 9 proposed by ESMA. Respondents noted that this data is not essential for the CTP’s core functions, particularly given its focus on delivering pre-trade transparency. − Data sequencing and timestamp requirements. Respondents highlighted the importance of including fields that enable sequencing and timestamp accuracy. These elements would support the correct chronological ordering of trades and ensure accurate aggregation by the CTP, which is particularly valuable in cases where latency can affect data integrity. − Addition of MMT Flags and Place of Listing. Stakeholders recommended including MMT flags to standardise trading system type indicators and enhance data usability. Adding the Place of Listing was also suggested, as it would help users accurately identify the venue associated with each trade, especially for instruments listed across multiple markets. − Revised labels for trade direction: Feedback also included recommendations to revise field labels, particularly the "Buy/Sell" labels, which some found too simplistic. Suggestions included adopting standardized terms like "Best Bid" and "Best Ask" to better reflect industry terminology and improve data interpretation. Output data feedback:
− Aggregation across market phases. Stakeholders raised concerns about data aggregation across different market phases, such as continuous trading and auction phases. They emphasised that output data should reflect the unique characteristics of each market phase, with clarity on how data from these phases is combined or presented. − Timestamp and sequencing. In line with feedback on input data, respondents stressed the importance of timestamps and data sequencing for output data to ensure accuracy. Sequencing by timestamps would allow the CTP to present data in a clear, consistent order, especially where varied latency and market phases might otherwise complicate the data flow. − Simplification of Bid/Ask currency and auction data. Respondents suggested simplifying currency indicators for bid and ask prices to streamline the data format. − Additional Fields. Stakeholders recommended that some fields included in the input data—such as MMT flags and Place of Listing—also be incorporated into output data. This would create consistency across input and output tables, ensuring that the CTP provides a cohesive dataset for both pre-trade transparency and subsequent data dissemination.

DEG: Finally, the DEG advised that the trading system (matching engine) timestamp and
each TV’s pre-trade publication timestamp should be provided to the CTP.
Furthermore, on top of the two previous timestamps, the following ones should be provided
in the CTP publication: the EBBO calculation timestamp by the CT for each EBBO message and the EBBO publication timestamp by the CTP.
The DEG also advised ESMA to give the CT latitude in determining the optimised methods
that align with the needs of the market in relation to the calculation time. Similarly, it suggested to uniquely identify an instrument by ISIN/MIC/currency as to leave room for aggregation at currency level to vendors.
Finally, the DEG also advised that the publication should be as close to real-time as
possible from the calculation and that an EBBO should be published as long as one TV is trading in a continuous trading phase. ESMA’s assessment and next step
In response to feedback suggesting that Field 8 (Quantity Currency) be included in the
CTP’s input and output data, ESMA clarifies that this field is not present in the output table because the required volume is already defined in terms of quantity, i.e. number of shares or ETFs. Therefore, ESMA does not consider this field necessary in this context, as it is sufficiently represented by the price currency. Furthermore, the volume in monetary amounts can be directly calculated by multiplying the price and the quantity.
In order to address the comment on the aggregation across different market phases
(continuous vs auction), ESMA has included in the input and output tables the trading phase to ensure that granularity is sufficient to distinguish among the different market phases.
Regarding the feedback pointing that it would be crucial to include the order entry
timestamp to allow the CTP to reorder BBO based on the actual order time, ESMA notes that this value was already included in the proposed input table in the CTP. Therefore, no further modifications are made in this respect.
Considering some unclarities and a call to separate the table of the CTP from that of
RTS 1, ESMA distinguishes the input table of the CTP from the table of pre-trade transparency information in RTS 1.
The new input and output tables of the pre-trade equity CTP are provided below. They
also reflect feedback on the proposal to include additional fields. Regarding the suggestion to add the Place of Listing, ESMA considers that the publication of the Most Relevant Market in Terms of Liquidity (MRMTL) sufficiently addresses this need. Additionally, based on respondents’ feedback, ESMA has implemented the suggestion to revise the labels for trade directions.
Changes are highlighted in red, with explanations on ESMA’s assessment in the final
column of each table. The text highlighted in light blue corresponds to the version included in the RTS.

Input table:
Table 8: Input table for pre-trade core market data for SHARES and ETFs

Field identifier Description and details to be published

Format to be populated as defined in Table 2
ESMA’s assessment of the feedback received
1 Update date and time
For continuous order books, the date and time when the best bid and best offer were received for execution, cancelled, or modified into the trading system. For auction trading systems, the date and time at which the price would best satisfy the trading algorithm and any modification of the price (field 5) or quantity (field 8) thereafter. The level of granularity shall be in accordance with the requirements set out in
Article 2 of Delegated Regulation (EU) 2017/574.
The fields price (Field 5) and quantity (Field 8) should be updated at the end of every trading phase.

For continuous order book Field 1 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For periodic auctions Field 1 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. {DATE_TIME_FORMAT} This field has been modified to clarify that whenever there is a new price/potential volume in an ongoing auction, the trading venue should resubmit the info to the CTP.

For auction trading systems, the date and time at which the price would best satisfy the trading algorithm and any modification of the price (field 5) or quantity (field 8) thereafter. The level of granularity shall be in accordance with the requirements set out in
Article 2 of Delegated Regulation (EU) 2017/574.
The fields price (Field 5) and quantity (Field 8) should be updated at the end of every trading phase. 2 Instrument identification code Code used to identify the financial instrument. Field 2 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. {ISIN} 3 Side For continuous order books, the side of the order or quote. For auction trading system, this field is not mandatory. Field 3 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. This field is mandatory only for continuous order books. ‘BUYI' – for bid or 'SELL’ – for ask This field has been removed for the auction trading system in line with the feedback received. 4 Price For continuous order books, the price of the first best bid and the first best ask orders excluding, where applicable, commission and accrued interest. For auction trading system, the price at which the auction trading system would best satisfy its trading algorithm. The price shall be provided in the major currency unit. {DECIMAL-18/13}

Where price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated.

For continuous order books this field corresponds to Field 5 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587 of the best bid and offer. For periodic auctions Field 5 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For auction trading system, the price at which the auction trading system would best satisfy its trading algorithm. The price shall be provided in the major currency unit. Where price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated. 5 Price currency Major currency unit in which the price is expressed. Field 6 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. {CURRENCYCODE_3} 6 Quantity For continuous order books, the number of units of the financial instruments attached to the orders or quotes. For auction trading system the aggregated quantity attached to the price that would best satisfying the trading algorithm. {DECIMAL-18/17} in case the quantity is expressed as number of units in the case of equity and equity-like financial instruments

For continuous order books, this field corresponds to Field 8 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For periodic auctions, this field corresponds to Field 8 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For auction trading system the aggregated quantity attached to the price that would best satisfying the trading algorithm. 7 Venue Identification of the trading venue through the system of which orders are advertised. Use the ISO 10383 segment MIC for or, where the segment MIC does not exist, use the operating MIC. Field 11 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. {MIC} 8 Trading system Type of trading system type where the order or quote is advertised

This field corresponds to Field 12 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. ''CLOB' -- central limit order book trading systems. A continuous auction order book trading system as defined in Table 1 of
Annex I and a trading
system combining elements of a continuous auction order book As per comments of stakeholders, the name of the field has been modified to cater for the case where a trading system runs two different trading types.

This field shall be populated for CLOB, PATS and, HYBR system types. trading defined in Table 1 of Annex I and of periodic auction trading system defined in Table 1 of
Annex I.
'PATS' -- periodic auction trading systems. As defined in Table 1 of
Annex I.‘HYBR’ -- hybrid
trading systems. As defined in Table 1 of
Annex I. A trading
system combining elements of a continuous auction order book trading defined in Table 1 of Annex I and of periodic auction trading system defined in Table 1 of
Annex shall not be
considered a hybrid system but a CLOB.
’OTHR’ -- for any other trading system. As defined in Table 1 of
Annex I.

9 Trading system phase
Type of trading system phase during which the order is advertised This field corresponds to Field 13 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. ‘UDUC’ - Undefined Auction ‘SOAU‘ - Scheduled Opening Auction ‘SCAU‘ - Scheduled Closing Auction ’SIAU’ - Scheduled Intraday Auction ‘UAUC’ - Unscheduled Auction ‘ODAU’ - On Demand Auction (Frequent Batched Auction) ‘CONT’ - Continuous Trading ‘MACT’ - At Market Close Trading ‘OMST’- Out of Main Session Trading OTHR - Other

10 Publication date and time
Date and time when the information was published by the trading venue. The level of granularity shall be in accordance with the requirements set out in
Article 2 of Delegated Regulation (EU) 2017/574.
This field corresponds to Field 14 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. {DATE_TIME_FORMAT}

Output table:
Table 9: Output table for pre-trade core market data for SHARES and ETFs for continuous order books

Field identifier Description Format as defined in Table 1 ESMA’s assessment of the

feedback received
1 Entry date and time Field 1 of Table 1 of Annex III of Commission delegated this Regulation 2017/587 of the best bids and offers into the order book as reported by the trading venue. The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} 2 Instrument identification code Field 2 of Table 1b of Commission delegated Regulation 2017/587. Field 2 of Table 1 of Annex III of this Regulation {ISIN} 3 Currency Major currency unit in which the European best bid and offer prices are expressed. This corresponds to Field 5 of Table 1 of
Annex III of this Regulation
{CURRENCYCODE_3} The currency of the instrument has been added to uniquely identify the instrument as per feedback received. 34 Best bid European best bid (Field 4 of Commission delegated Regulation 2017/587) in continuous order books. Field 4 of
Table 1 of Annex III of this Regulation
{DECIMAL-18/13}
4 Best bid currency Major currency unit in which the European best bid is expressed (Field 6 of Commission delegated Regulation 2015/587). {CURRENCYCODE_3} 5 Best bid volume The corresponding aggregated volume to the European best bid. This corresponds to Field 6 of Table 1 of Annex III of this Regulation {DECIMAL-18/17} 6 EBBO timestamp Date and time of the calculation of the EBBO. {DATE_TIME_FORMAT} As per feedback received, it is clarified that this timestamp

The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. refers to the calculation time of the EBBO by the CTP. 7 MRMTL Most relevant market in terms of liquidity as defined in Article 4(4) of Commission Delegated Regulation 2017/587. {MIC} 85 Best offer European best offer (Field 4 of Commission delegated Regulation 2015/587) in continuous order books. This corresponds to Field 4 of Table 1 of Annex III of this Regulation {DECIMAL-18/13} 8 Best offer currency Major currency unit in which the European best offer is expressed (Field 6 of Commission delegated Regulation 2015/587). {CURRENCYCODE_3} This field has been removed as per comments received in the consultation. Indeed, there is only one currency for the prices of the instrument, both on the bid and on the ask side. 9 Best offer volume The corresponding aggregated volume to the European best offer. This corresponds to Field 6 of Table 1 of Annex III of this Regulation {DECIMAL-18/17} 1210 Dissemination date and time Date and time when the data related to the order was disseminated by the CTP to the subscribers. Field The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} 1311 Publication date and time This corresponds to Field 14 of Commission delegated Regulation 2017/587. This corresponds to Field 10 of Table 1 of Annex III of this Regulation. {DATE_TIME_FORMAT}

Table 10: Output table for pre-trade core market data for SHARES and ETFs for auction trading systems

Field identifier Description Format as defined in Table 1

ESMA’s assessment of the feedback received
1 Indicative date and time This corresponds to Field 1 of Table 1 1b of Annex III Commission delegated Regulation 2015/587 of this Regulation.. {DATE_TIME_FORMAT} 2 Instrument identification code Field 2 of Table 1b of Commission delegated Regulation 2015/587. This corresponds to Field 2 of Table 1 of
Annex III of this Regulation.
{ISIN}
3a Lowest auction price Lowest auction price. This field corresponds to Field 4 of Table 1 of
Annex III of this Regulation
{DECIMAL-18/17} Considering the aggregation of the auction prices and volumes across different venues, it is important to provide useful indicators to market participants of the lowest, highest and volume weighted auction price. 3b Highest auction price Highest auction price. This field corresponds to Field 4 of Table 1 of
Annex III of this Regulation
{DECIMAL-18/17}
3c Volume weighted auction price Volume weighted auction price. This field corresponds to Field 4 of Table 1 of
Annex III of this Regulation weighted by
Field 6 of Table 1 of Annex III of this
Regulation
{DECIMAL-18/17}
4 Currency Major currency unit in which the auction price is expressed. This field corresponds to Field 5 of Table 1 of
Annex III of this Regulation
{CURRENCYCODE_3} The currency of the instrument has been added to uniquely identify the instrument as per feedback received. 5 Auction volume Total auction volume, where applicable, across venues. This corresponds to {DECIMAL-18/13}

Field 6 8 of Table 1 of Annex III of this
Regulation. Commission delegated
Regulation 2015/587
6 Dissemination date and time Date and time when the data related to the order was disseminated by the CTP to the subscribers Field 10 of Table 1b The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Clear references to the level 1 provision have been added to this field. 7 Publication date and time This field corresponds to Field 10 of
Table 1 of Annex III of this Regulation 12
of Commission delegated Regulation
2015/587
{DATE_TIME_FORMAT} Clear references to the level 1 provision have been added to this field. 8 MRMTL Most relevant market in terms of liquidity as defined in Article 4(4) of Commission Delegated Regulation 2017/587. {MIC} In line with the feedback receive, this field has been added to identify the MRMTL of the instrument.

3.2.4 Presentation of output data
Proposal in the CP
104. In the CP, ESMA proposed that the CTP disseminates core and regulatory data in
multiple formats to ensure both machine-readability and human-readability. The proposed formats for data publication are as follows:
− same format prescribed for input data, to ensure machine-readability for advanced data users; − Comma Separated Values (CSV), to ensure easy accessibility and usability for less advanced data users; − Graphical User Interface (GUI), to ensure human-readability.
105. Additionally, ESMA proposed that the CTP publishes documentation on its website
detailing how the data can be accessed and update this documentation with a three-month notice period to avoid disruptions in data provision. Feedback to the consultation
106. Respondents in general supported ESMA’s proposal for ensuring both machinereadability and human-readability in the dissemination of core and regulatory data,
recognizing the need to address the diverse requirements of institutional and retail users. However, some stakeholders raised concerns about the proposed approach.
107. Several respondents questioned the necessity of providing data in multiple formats.
They argued that a single machine-readable format, combined with a graphical user interface (GUI), could be sufficient to meet user needs while simplifying the operational demands on CTPs. Concerns were also raised regarding the feasibility of implementing multiple formats within the proposed timeline, with some suggesting that a binary format and GUI could serve most users’ needs.
108. One potential CTP candidate suggested removing the requirement to publish data in
the same format prescribed for input data, emphasizing that alternative transmission protocols could also be suitable for both input and output processes.
109. Additionally, various stakeholders emphasized that the GUI should be primarily
targeted at retail investors and academia, recommending that access be restricted accordingly. They highlighted the importance of enabling users to customize their view of the data through specific search criteria, visual indications, and simplified charts to enhance human readability. At the same time, they supported keeping the entire dataset

available for download in CSV format to facilitate research and data analysis. This approach would also allow users to generate customized CSV files based on selected criteria.
110. Some feedback focused on the presentation of pre- and post-trade data within the GUI,
with suggestions to conflate the two data types to prevent overwhelming retail users with frequent updates. A recommended delay of one minute for presenting human-readable data was proposed to make the data more manageable.
111. Lastly, there were suggestions for allowing flexibility in the data formats provided,
enabling CTPs to offer data in any format requested by a sufficient number of users. ESMA’s assessment and next steps
112. In light of the feedback received and the general support for ensuring both machinereadability and human-readability, ESMA intends to prescribe all three formats outlined in
the consultation paper for the dissemination of core and regulatory data. Despite concerns regarding the necessity of multiple formats that emerged from the consultation, ESMA emphasizes that, as specified in Article 27h(1)(e) of the revised MiFIR, a CTP must ensure that core market data and regulatory data are easily accessible, machine-readable, and usable for all users, including retail investors. This underscores the importance of catering to all segments of users to facilitate their ability to consult the data disseminated by the CTP.
113. To this end, the following requirements will be implemented:
− Publication in the same format as for input data: the CTP will publish data in one of the formats used by data contributors for input data. This approach is not only cost-efficient for the CTP but also mitigates the risk of data quality issues associated with data transformation. This requirement aligns with the proposal made in Section 3.2.2 on the standards and format of data to be transmitted to the CTP. Thus, output data will also be required to be published in an ISO 20022-compliant format, enabling advanced users of the CTP to effectively process the data. − Publication in Comma Separated Values (CSV): the CTP will also publish data in CSV format to ensure easy accessibility and usability for less advanced data users who still benefit from machine-readable data. − Graphical User Interface (GUI): the implementation of a GUI will enhance humanreadability, providing a user-friendly way for all investors to interact with the data.
114. These requirements are designed to accommodate the specific needs of users, ranging
from the least to the most sophisticated.

In addition to these mandatory formats, ESMA allows the CTP the flexibility to publish
data in additional formats on a voluntary basis, taking into account the usage patterns of the regulatory community, which commonly employs ISO-compliant formats (such as JSON). This additional option aims to maximize accessibility for the broadest possible audience. Should the CTP wish to adopt any formats beyond those mandated, such additions will be subject to evaluation as part of the selection procedure.
Lastly, in light of the comments and suggestions made by some respondents regarding
the specifications of the GUI, its access, and the presentation of data, ESMA notes that further guidance on these aspects may be provided in Level 3, as they fall outside the scope of this RTS. Additionally, these topics will be considered during the selection phase under criterion (j): "the use of modern interface technologies by the applicant for the dissemination of core market data and regulatory data and for connectivity."
3.3 Data quality measures and enforcement standards
3.3.1 Input data quality
Proposal in the CP
In the CP, ESMA proposed comprehensive data quality measures for the CTPs to
ensure the quality of input data received from data contributors. This includes conducting (i) completeness checks to verify that all required data fields are present and accurately populated, (ii) ensuring format adherence to prescribed regulatory requirements, (iii) employing outlier detection methodologies to identify potential erroneous trades by analysing price and volume information, and (iv) monitoring the timeliness of data submissions to meet real-time requirements.
Furthermore, ESMA proposed that CTPs need to establish cooperation arrangements
with data contributors to ensure prompt resolution of data quality issues and enhance data reliability. These arrangements include confirming receipt of data, flagging quality issues, and ensuring corrections. The data quality framework proposed by ESMA in its CP also envisaged the CTP blocking the publication of any incomplete or potentially erroneous trade report received from data contributors until the data quality issue is resolved.
Regarding the enforcement tools to ensure data quality, such as temporary suspension
of revenue redistribution and notification to competent authorities, ESMA proposed that CTPs shall document these procedures and make them publicly available to enhance transparency and accountability in enforcing data quality standards.

Feedback to the consultation
120. While there was general consensus on the importance of data quality in the CTP
framework, most of respondents expressed general disagreement with the proposal regarding the identification of erroneous trades and the corrective actions. The majority emphasized that trading venues and APAs should retain responsibility for error identification, considering they are already subject to existing data quality requirements. It was suggested that the CTP should publish trades as received and collaborate with data contributors to address data quality issues, potentially flagging trades as “under investigation” rather than blocking the publication while waiting for corrective actions from data contributors.
121. Regarding referential data, several trading venues and potential CTP applicants
highlighted the importance of aligning data between data providers and the CTP to minimize inconsistencies. They advocated for embedding referential elements directly into systems to address potential discrepancies at the source. One respondent specifically noted that this alignment would enable the CTP to perform data quality checks against the Financial Instruments Reference Data System (FIRDS).
122. Feedback on data quality measures emphasized a need for a differentiated approach.
Some respondents recommended categorizing issues based on their complexity, with simpler cases being fully automated to achieve optimal latency and more complex issues requiring manual intervention. They suggested that technical problems should be managed within the transport protocol, while functional issues, such as message format errors, would require deeper analysis and potential software updates.
123. The majority of respondents did not support granting enforcement powers to the CTP.
They disagreed with proposals to suspend revenue for non-compliance, viewing this as a punitive measure that could disrupt the industry. One trading venue recommended that any enforcement actions should be considered only as a last resort, allowing data providers a reasonable period to resolve issues before imposing sanctions.
124. To enhance collaboration, one respondent emphasized the need for formal cooperation
agreements between data contributors and CTPs and proposed including a model agreement to standardise cooperation across trading venues, CTPs, and ESMA. ESMA’s assessment and next steps
125. In light of the feedback received during the consultation, with the majority of
respondents opposing the proposal for the CTP to directly identify and correct erroneous trades, ESMA has decided to revise roles and responsibilities of the CTP in ensuring data quality. Specifically, ESMA endorses the respondents' suggestion that the CTP should only flag trades that appear to be potentially erroneous, instead of blocking its publication.

However, it is essential to clarify what constitutes a "potentially erroneous" trade. In this
context, ESMA specifies that input data which is incomplete or does not adhere to the prescribed formats – meaning it is non-compliant with MiFIR reporting instructions – shall not be published by the CTP. In such cases, the CTP is required to promptly notify the data contributor that submitted the data, who shall acknowledge the issue and initiate the process of resubmitting corrected data. Conversely, information that appears likely to be erroneous, such as outliers or anomalous numerical values (e.g., unusual monetary amounts), should be published and accompanied by a flag signalling a potential data quality issue. The CTP shall promptly alert the data contributor, who must then verify and confirm the accuracy of the flagged data. Article 10 of the draft RTS has been amended to reflect this adjustment, and further guidance on how to implement the flagging of such data will be provided by ESMA in Level 3 measures.
Regarding the feedback on aligning data with reference data, ESMA understands this
as a request to consider validation rules that incorporate checks against common referential data. This approach will be further explored as part of the technical implementations, including message schemas and Level 3 measures.
As for the recommendation to categorize issues based on their complexity, ESMA does
not intend to adopt this approach within this RTS. Rather than providing detailed lists that classify checks by complexity or specify timeframes for resolution, as suggested by some respondents, the RTS aims to establish a general set of minimum data quality checks to maintain a consistent baseline standard across CTPs. This general approach will support CTPs in identifying 'potentially erroneous' trades and those that should not be published, without requiring specific distinctions between types of checks. Applicants will have the opportunity to propose their specific methodologies and arrangements for data quality, which will be evaluated during the selection process under Article 27da(2)(f) of MiFIR: "the appropriateness of the applicant’s methods and arrangements to ensure data quality." This approach encourages automated solutions for data quality checks, which will be viewed favourably in the assessment process.
In response to the widespread disagreement to granting enforcement powers to the
CTP, ESMA highlights that such powers are not specified in this RTS, but they are mandated by Level 1 regulation. Enforcement powers are intended by ESMA as the suspension of revenue redistribution and the notification of severe data quality issues to CAs. The mandate for ESMA is instead to specify in Level 2 the enforcement standards, which are considered as the procedures that CTPs can take to make use of those powers to ensure timely resolution of data quality issues caused by data contributors. Therefore, ESMA intends to maintain its proposed approach, requiring CTPs to publish clear, nondiscretionary policies detailing the procedures for activating enforcement measures, as specified in Article 27h(8)(c) and Article 22a(8) of Regulation (EU) No 600/2014.
Finally, concerning the comments on cooperation arrangements with data contributors,
ESMA clarifies that formalizing these interactions has been a consistent objective. This aspect has now been made more explicit in the draft RTS, particularly in Article 10, paragraph 10, to ensure clarity regarding the responsibilities of CTPs and their data contributors.
3.3.2 Output data quality
Proposal in the CP
In the CP, ESMA proposed that CTPs employ three key mechanisms to ensure the
reliability and accuracy of output data, (i) continuous real-time monitoring of IT systems to promptly identify and resolve technical issues, (ii) periodic data reconciliations to verify the correct publication of trade reports and rectify any inconsistencies, and (iii) establishing feedback channels from data users to gather input on data quality.
Additionally, CTPs are required to document these mechanisms internally and ensure
continuous compliance. They must also annually publish performance statistics and incident reports related to data quality and data systems on their website, as specified by ESMA through a separate RTS, to enhance transparency and adherence to data quality standards. Feedback to the consultation
Most respondents expressed agreement with ESMA's proposal. However, several
respondents suggested improvements to the outlined provisions to ensure effective implementation and raised requests for clarification on specific aspects of the proposal.
Some respondents called for more detailed instructions from ESMA on how the CTP
should manage reconciliations, particularly in cases where errors are identified, and recommended that those requirements include clearly defined timeframes for making corrections to enhance accountability. They sought clarity on whether ESMA intended to require a comprehensive reconciliation process or if a simpler approach, such as reconciling reported volumes, would suffice. To support effective reconciliation, respondents also suggested implementing transaction IDs or reference number tags for each trade, allowing users to track changes more easily. This could be complemented by a flagging system to mark transactions under investigation, ensuring greater transparency throughout the reconciliation process.
Regarding feedback channels to be used by the CTP, some respondents proposed the
introduction of a chatbot, alongside a detailed Q&A section specifically designed for retail investors. This would aim to provide quick and accessible support to users seeking clarification. Another respondent suggested that communication channels should rely

primarily on electronic messaging, recommending the use of market data feeds for updates over private messaging systems, to ensure consistency and efficiency in information dissemination. ESMA’s assessment and next steps
136. ESMA confirms the proposals outlined in the consultation paper regarding data quality
measures for output data. While ESMA acknowledges the requests for further clarifications on certain aspects, such as the frequency and modality of periodic reconciliations, it considers that this level of prescription cannot be detailed in the draft RTS. The requirements for CTPs are intended to mirror those already established for APAs, which, for reasons of proportionality, are not overly prescriptive. CTPs will be expected to comply with these requirements and implement appropriate procedures.
137. Furthermore, ESMA recalls that the data quality methodologies employed by CTPs,
including on the frequency and modality of reconciliation checks, will be assessed during the selection phase. Once the CTP is authorised and becomes operational, ESMA will actively monitor and verify these data quality methodologies as part of its ongoing supervisory activities to ensure that high standards are maintained.
138. Regarding the suggestions for additional features to enhance the communication
between the CTP and its clients on data quality matters, such as implementing a chatbot, Q&A sections, or formalising communication channels, ESMA acknowledges the proposals raised by respondents. However, ESMA believes that the modalities for implementing such features should be left to the discretion of the CTPs as a matter of implementation choice and cannot be mandated through regulatory requirements. The minimum requirements established in this RTS are designed to ensure adequate standards of data quality without prescribing specific implementation details. This approach allows CTPs the flexibility to adopt additional measures that best suit their operational models while still meeting the essential requirements for maintaining data quality.

4 RTS on the revenue redistribution scheme
4.1 Mandate under Article 27h(8)(a) and (b) of MiFIR
139. According to paragraph 5 of Article 27h of MiFIR part of the revenues generated by the
CTP for shares and ETFs shall be redistributed to data contributors meeting one or more of three criteria ("revenue distribution scheme") for which ESMA has to specify the weighting and the methodology in a draft RTS, as mandated in Article 27h(8)(a) and (b) of MiFIR. Furthermore, ESMA has to specify the criteria under which the CTP can suspend the participation of a data contributor in the revenue redistribution scheme as well as the conditions to resume the application of such scheme, as mandated in Article 27h(8)(c) of MiFIR.
140. For convenience, before analysing the feedback received on the different proposals in
relation to the revenue distribution scheme of the equity CTP, the main elements of the scheme defined in Level 1, are provided in the table below.
141. It is important to stress that several elements of the revenue distribution scheme are
already defined in Level 1 and that the mandate of ESMA is limited in this respect. Furthermore, it is relevant to stress that ESMA has the mandate to define the weighting, the methodology and the suspension criteria of the revenue distribution scheme for the equities and ETFs CTP and not for the bonds or derivatives CTPs. Therefore, the latter are out of the scope of this section of the Final Report.
Table 11: Main elements of the revenue distribution scheme
CRITERION as defined in
Article 27h(6) of MiFIR
WEIGHT RELEVANT TRADING VOLUME
#1 SMALL TRADING VENUE – “(a) the data contributor is a regulated market or an SME growth market whose annual trading volume of shares represents 1 % or less of the annual trading volume of shares in the Union (“small trading venue)” According to the mandate in Article 27h(8) of MiFIR such criterion shall have the highest weight
Article 27h(7) of MiFIR determines that
the weight of this parameter shall be multiplied by the total annual trading volume generated by that trading venue

#2 YOUNG INSTRUMENTS – “(b) the data contributor is a trading venue that provided initial admission to trading of shares or ETFs on 27 March 2019 or thereafter” According to the mandate in Article 27h(8) of MiFIR such criterion shall have the second highest weight The relevant trading volume to use shall be:
(i) in the case of small trading venues, their total annual trading volume; (ii) in the case of trading venues other than small trading venues, the trading volume pertaining to the shares and ETFs referred to in point (b) of paragraph 6 of Article 27h. #3 PRE-TRADE TRANSPARENT TRADING VENUE – “(c) the data are transmitted by a trading venue and pertain to transactions in shares and ETFs that have been concluded on a trading system that provides pre-trade transparency, where those transactions did not result from orders that were subject to a waiver from pre-trade transparency pursuant to Article 4(1), point (c) of MiFIR. According to the mandate in Article 27h(8) of MiFIR such criterion shall have the lowest weight The relevant trading volume to use shall be the volume pertaining to transactions in shares and ETFs concluded on a trading system that provides pre-trade transparency per the terms in point (c) of
Article 27h(6) of MiFIR.
4.1.1 Methodology
4.1.1.1 Application of the criteria at MIC level and availability of information
Proposal in the CP
Application of the criteria at MIC level
142. In relation to the methodology to follow for the distribution of the revenue, the first
element analysed in the CP was the level at which the calculations should be performed.
143. ESMA considered that in most cases, the operating MIC refers to a trading venue while
the segment MIC refers to a trading system or dedicated segment of the venue. On this basis, doing the calculations at the segment MIC level, both for the identification of the trading venue, the assessment of the criteria and the distribution of revenues, should avoid the issue of the correct determination of the proper MIC to use for such purposes. However, this approach appeared too granular for criterion 1 and might result in a very high number of trading venues eligible to this criterion. Therefore, ESMA considered using the operating MIC for the calculations for criterion 1 (see Section 4.1.2.1.5 and Annex V of the CP).

Availability of information
144. Concerning the availability of information by the CTP to carry out the revenue
distribution scheme, ESMA considered that:
− the CTP has all the information to determine the volume for a small trading venue; − the CTP has all the information to determine the volume for young instruments. However, in this context, two options were presented for the collection of the information: FIRDS vs. direct data collection by the CTP; − the CTP would have all information to define pre-trade transparent volume of trading venues when a new flag is introduced in the input data which data contributors have to transmit to the CTP, namely the flag to identify pre-trade large in scale (LIS) trades. Feedback to the consultation Application of the criteria at MIC level
145. In relation to which MIC to use for the performance of the calculation, views were mixed
between the support for ESMA’s proposal and the use of the segment MIC. Furthermore, stakeholder provided no indication on how to identify the links of groups with investment firms to identify the list of data contributors that can opt-in in accordance with Article 22a(2)(a) where it is specified that those small venues with close links with an investment firm or a market operator whose annual trading volume of shares represents more than 1% of the annual trading volume of shares in the Union, are mandated to contribute to the CTP. Availability of information
146. Stakeholders generally agreed with ESMA’s assessment.
147. One respondent noted that regarding criterion 1 ESMA should clarify whether the basis
for determining whether a venue is a Small Trading Venue is the annual trading volume of shares that are reported to the CTP or whether it should be based on total EU trading volume (which is information not available to the CTP).
148. Several respondents requested ESMA to clearly define in the RTS which operations
are eligible under the concept of ‘initial admission to trading’ (e.g. IPOs, private placements, M&As, spin-offs, transfers, etc.) and to make amendments to RTS 23 to identify those.
149. As far as the information to determine the volume for young instruments is concerned,
the majority of stakeholders expressed a preference for the use of FIRDS for the

identification of the TV with first admission to trading. Only one respondent preferred the use of the CTP data and another one advocated for a combination of the two.
150. In relation to the flag to identify pre-trade large in scale (LIS) trades, the majority of
respondents agreed with the introduction of the new flag. Few respondents advocated for the publication of the information in the post-trade transparency reports and not leave it only to the CTP for the purpose of the revenue distribution scheme.
151. Most respondents agreed with ESMA’s proposal to rely on post-trade data containing
relevant transparency flags to determine appropriate pre-trade transparent trading volumes and saw it as the only reliable approach. One respondent argued to exclude all non-price forming trades from pre-trade transparent trading volumes, including those executed on periodic auction systems at prices pegged to an external venue. ESMA’s assessment and next steps Application of the criteria at MIC level
152. Considering the limited and mixed feedback received and, the clear intention of colegislators to exempt only a small subset of trading venues as indicated in recital 18’, ESMA
reiterates the proposal put forward in the CP. Relying for the first criterion on segment MIC level would result in close to half of the trading venues contributing to the CTP to meet this criterion (77 out of 169 segment MIC would have an annual trading volume of shares representing 1 % or less of the annual trading volume of shares in the Union, compared to 59 when the calculations are done at operating MIC level).
153. Hence, ESMA considers that the calculations should be performed at operating MIC
level to ensure a fair representation of the small trading venues eligible for the revenue distribution and to perform the calculations for the two other criteria at segment MIC level. An example on how the calculations should be performed is presented in Annex VI. Availability of information
154. As concerns the “annual trading volume of shares in the Union”, ESMA considers that,
despite the fact that the CTP might not have the full picture, the percentage of trading missing would be negligible (~2%) and the results of those who are mandated to contribute would not change 9 . Therefore, ESMA reiterates the proposal included in the CP, and the volume reported to the CTP should be used as annual trading volume executed in the EU. 9 On the basis of the analysis performed on the basis of 2023 data reported to FITRS.

Considering that most stakeholders preferred the use of FIRDS for the identification of
the TV with first admission to trading, ESMA proposes this solution and no additional amendments, on top of the new field already requested for the purpose of the identification of the venue of first admission for the purpose of transparency for equity and equity-like instruments.
In relation to the flag to identify trades benefitting from the large in scale (LIS) waiver,
considering that most respondents agreed with the introduction of the new flag, ESMA confirms such proposal. However, considering the sensitivity of this information and the number of flags already published, ESMA still considers that the flag should not be published by the CTP or by trading venues in the post-trade transparency reports.
In light of the received feedback, ESMA considers post-trade data the only viable option
to determine actual pre-trade transparent trading volumes for the purpose of criterion 3.
Regarding the other technical comments made, ESMA agrees that more clarity on the
transactions qualifying as ‘initial admission to trading’ would be necessary. However, such clarification is not covered by the mandate for developing the draft RTS and would hence need to be provided via further guidance on the matter.
Regarding the exclusion of non-price forming trades from criterion 3, please refer to
Section 4.1.1.2.
4.1.1.2 From weights to monetary amounts to percentages
Proposal in the CP
To determine the amount of revenues that each contributor should receive, Level 1
requires that the weight has to be multiplied by a measure of trading volume which is differently defined for each criterion. In order to avoid that such value in monetary amount might be larger than the total amount to be redistributed, ESMA suggested in the CP converting those values into percentages. Feedback to the consultation
In general, respondents agreed with the conversion into percentages. However, it is
worth noting that two market participants proposed different methodologies. One disagreeing respondent claimed that the conversion into percentages is flawed and does not accurately reflect the value contributed by different entities. The respondent recommended a more dynamic model that considers the value of the information using the Market Model Typology (MMT). Another respondent suggested the use of a different approach, such as a multi-factor model.

ESMA’s assessment and next steps
162. Considering the broad support received to the weights, ESMA proposes to maintain the
percentage-based approach which is an inherent part of the methodology based on the weights proposed. The alternative options to determine the weights could be considered in the future review of the weights under an RTS review should the proposed approach be in need of improvement.
4.1.1.3 Calculation of the trading volumes
Proposal in the CP
163. To avoid an inconsistent approach in the calculations of trading volumes, ESMA
proposed a list of transactions to include, exclude, add and subtract for each criterion on the basis of the list of flags for the purpose of post-trade transparency set in Table 4 of
Annex I of RTS 1. When a transaction is subject to several flags, if one of them requires
exclusion from the calculations, such flag should prevail.
Feedback to the consultation
164. Several respondents argued that transactions flagged as PRIC, RFPT, NLIQ, OILQ and
NTLS, should be excluded from the calculation of trading volumes for the purpose of criteria 1 and 2, to appropriately recognise and reward those venues that contribute to price formation through pre-trade transparency. In addition, those respondents considered that transactions using the flags below should be excluded from the criterion 3 computation, in contrast to ESMA’s proposal:
− BENC and PORT transactions, as these are not pre-trade transparent; − SIZE and ILQD transactions, as these are not executed on a trading venue; − TNCP and RPRI transactions (not mentioned in the CP), as these are not executed on a trading venue. ESMA’s assessment and next steps
165. After a more detailed assessment of the mandate, ESMA concluded that the Level 1
text does not provide for the possibility to remove certain types of transactions from the trading volumes on which to base the redistribution of revenue, with the exception of criterion 3 which only covers pre-trade transparent transactions. Therefore, ESMA no longer proposes to determine the list of transactions that should be included or excluded from the calculations.

However, ESMA considers that the transactions to be considered should be single
counted and exclude cancelled and add amended transactions. Therefore, other ways to handle cancelled or amended transactions than the use of the flags serving these purposes are permissible as long as all transactions are single-counted and there are no missing or duplicated values.
4.1.1.4 Frequency of the revenue distribution scheme
Proposal in the CP
The specification of the frequency of the revenue redistribution is not covered by the
scope of the mandate for ESMA to develop RTS. Without any prejudice to that, ESMA analysed this topic and concluded that distribution of revenues at least on an annual basis based on estimated eligibility with a periodic balance adjustment seemed a good basis. Feedback to the consultation
Only a few respondents agreed with ESMA’s view of an annual distribution of the
revenues. Most market participants preferred a model with a quarterly allocation with any potential balance adjustment at year end. Among those, few respondents considered that also a monthly distribution could be appropriate. ESMA’s assessment and next steps
Considering that the specification of the frequency of distribution is not covered by the
scope of the mandate for ESMA, no specifications will be made in the RTS in this respect. ESMA encourages the future equity CTP to take this feedback into account when specifying the frequency of the revenue redistribution.
4.1.1.5 Determination of the list of data contributors
Proposal in the CP
ESMA proposed to publish one list of all eligible data contributors (segment MICs
offering trading in shares or ETFs), comprising those obliged as well as those not obliged to report data to the CTP and their opt-in status.
Under this proposal, the list would have been updated annually by 15 January each
year and ESMA considered that once a data contributor had reported data to the CTP, it would be obliged to keep reporting data to the CTP until the end of its 5-year term.
In the same context ESMA proposed that, considering that annual trading volumes shall
be used for the determination of mandatory contribution by a trading venue, new trading venues starting operations are not obliged to contribute for the first year of their “life” as long as they are not part of a group or have close links with an investment firm or a market operator recording more than 1% of the annual trading volume in the EU. Those trading venues may though opt-in for contributing data to the CTP. Feedback to the consultation
Several respondents agreed that the list of those obliged to contribute to the CTP from
the beginning should be published annually alongside new entrants, SMEs growth markets, and small exchanges that have opted-in or out of the CT.
One respondent agreed that there should be a mechanism to avoid excessive
fluctuations in the list of mandatory contributors to the CTP. Such mechanism could foresee that once a venue moves to mandatory contribution, it remains in this category. ESMA’s assessment and next steps
In light of the received feedback, ESMA maintains its proposal for publishing one list,
comprising all eligible trading venues (segment MICs offering trading in shares or ETFs), and indicating whether a venue is obliged to report data to the CT, whether a venue is not obliged to report data, and, where relevant, if the venue has voluntarily opted in.
Following the feedback received to the consultation, and in order to ensure that the list
is always up to date, ESMA intends to update the list immediately once a trading venue starts or ends operations. Furthermore, ESMA intends to take voluntary opt-ins into account immediately. The calculations to determine if a trading venue exceeds the size threshold will be performed semi-annually by 15 January and by 15 July taking into account a full calendar year of historical data for the list to be updated accordingly.
In the case of new trading venues two scenarios can materialise:
− The venue could be part of or have links with a group with more than 1% of EU volume, and therefore be mandated to contribute to the CTP. − The venue might not be part of or have links to such a group.
In both cases, an assessment will be made at the next assessment window once the
trading venue has at least one full calendar year of data, and it might be mandated to contribute from the day after the results are published. In both cases, the new trading venues can opt-in before the assessment and contribute data to the CTP.
A data contributor should participate in the revenue distribution scheme from the day it
starts to contribute data.
An example of such a list of contributors and related updates can be found in Annex V.
Based on recital 18 of the MiFIR review, as soon as a trading venue has started
reporting data to the CT due to voluntary opt-in, it will be required to keep reporting data to the CTP for the entirety of its operations, at least for the remainder of its 5-year term.
4.1.1.6 First year of operations
Proposal in the CP
ESMA acknowledged the possibility for the CTP to have some issues during the first
year of operations. Therefore, market participants were asked to identify those issues and make proposals to solve them. Feedback to the consultation
Some respondents considered, that for the first year, it would be extremely challenging
for both the CTP and the data contributors to be fully operational (e.g. establish and test connections, implement methods for identifying errors), in particular in case of changes to the protocol chosen by ESMA for the reception of data by the CTP.
Some respondents considered it as challenging for the CTP (i) to process the data from
100% of the data sources in the first year of CT operation – in this regard it was claimed that partial data from that first period of operation should yield an appropriate result and a full year of volume data is not required, and (ii) to choose the level of revenue redistribution at the end of the first year of operation (even if partial).
Furthermore, market participants identified certain elements that ESMA should clarify
with respect to the timelines for ensuring the go-live of the CTP, notably when TVs and APAs start their API implementation work (once a CTP is selected, or once the CTP is authorised, by when TVs and APAs would need to complete their implementation work, how much time the CTP would have to complete its implementation work, whether ESMA will consider or require any extra time from when the CTP declares its work complete and the launch date, and whether ESMA will clarify at which point the clock for the fixed 5-year term starts ticking).
Overall, stakeholders considered that those processes should be started at the earliest
point in time possible.

ESMA’s assessment and next steps
187. ESMA appreciates the list of issues identified for the first year of operation of the CTP.
ESMA is in the process of finalising all the Final Reports with related relevant RTSs in line or in advance compared to the legal deadlines in order to ensure that the CTP can prepare itself to start operations.
188. In this context it is recalled that, according to Article 27db(4), following authorisation,
ESMA may grant the applicant authorised as a CTP a transition period to put in place the necessary operational and technical arrangements. ESMA’s general expectation is that such transition period, if granted, would be of a short period. The 5-year period for operating the CTP would start from the go-live date of the CTP.
189. Last but not least, ESMA appreciates the need of certain clarifications, especially those
around the amount to redistribute and encourages the future CTP to reflect on the points raised by stakeholders when specifying how much revenue to redistribute. Furthermore, when doing so, the CTP is expected to take into account its profitability and not endanger the long-term sustainability of its business.
4.1.2 Weighting assigned to each criterion
4.1.2.1 Weights
Proposal in the CP
190. Based on simulations and the steering provided in the revised MiFIR, ESMA proposed
the following set of weights: 4.5, 4.0 and 1.5 for the respective criteria small trading venue, young instruments, and transparent instruments. It was proposed that the weights (percentages) sum to 10 (100%). Feedback to the consultation
191. Trading venues replying to the consultation agreed with the proposed weights. Some
suggestions were made in this respect, such as accompanying the preferential treatment of small markets with certain obligations of connectivity, for instance to only reward trading venues that opt in within two years of the official launch of the CTP. Some respondents were also in favour of giving different weightings to different types of trading systems (e.g. opening/closing auctions vs. frequent batch auctions). Lastly, some respondents considered that IPOs for young securities should get a higher weight than disproportionally large IPOs such as government privatisations.

Among those few respondents that disagreed with the proposed weights (one
consultancy firm and one trading venue) the following remarks were made:
− the revenue distribution scheme set up in Level 1 and specified in the draft RTS is considered flawed and too rigid to work in practice; − the weighting for small trading venues should be significantly higher than the proposed
4.5 times in order to provide meaningful incentives for those venues to opt in;
− small trading venues that choose to opt-in should be guaranteed a minimum revenue share of EUR 2 million annually from the CTP.
As far as the sum of the weights to 10 is concerned, most respondents considered
ESMA’s proposal adequate. However, some respondents recommend foreseeing a review of the weights after an initial period of 12 or 18 months. ESMA’s assessment and next steps
ESMA takes note of the various comments received but considers that most of them
are not covered by the legal mandate and/or not supported by the approach provided for in the revised MiFIR. For example, the suggestion that only those small markets that have decided to opt in to provide data to the CTP within two years of the official launch should be eligible for any 'improved' weighting scheme is not supported by the revised MiFIR. Similarly, connectivity requirements should be met by all data contributors and MiFIR does not provide for the possibility to apply different weights depending on the trading system/mode.
Concerning the request for clarification of the listing activities to be included, ESMA
does not consider it possible to apply different weights dependent on the size of the IPO. However, ESMA agrees that further clarification of what types of listing activities are covered under the second criterion might be necessary.
ESMA agrees to conduct a review of the weights after an initial period to assess
whether adverse consequences have materialised and to assess if the legal intention is achieved.
Regarding the comment to apply weighting for "young instruments" with a rolling 5-year
time window, ESMA does not consider it relevant. An instrument will be considered young if it is admitted to trading on 27/3/2019 or thereafter. Therefore, all instruments admitted to trading on 27/3/2019 or later will be included under criterion 2 and not only for five years.
Regarding the comment on increasing the weight for small trading venues, ESMA
recognises that the share of revenues received by small trading venues will be limited. However, it does not appear that the solution lies in the level of weights to be set.
Therefore, in light of the feedback received, ESMA maintains the same proposed
weights of 4.5, 4 and 1.5 for the respective criteria of small trading venue, young instruments, and transparent instruments which are those maximising the percentage of revenues to be received by those data contributors who can opt-in. Therefore, also the proposal that the weights (percentages) sum to 10 (100%) is maintained.
4.1.2.2 Frequency
Proposal in the CP
ESMA proposed in the CP an annual frequency for the determination of the percentage
of revenues to be assigned to each trading venue in order to limit to the extent possible the burden of a continuous redetermination of the amount to be redistributed and, considering that the weights for small trading venues and for young instruments are to be applied to annual trading volumes determined by the CTP.
Furthermore, ESMA proposed that these calculations should occur within one month
from the end of each calendar year.
Finally, as far as the start of the application of the percentages is concerned, since this
is linked to the frequency of the revenue distribution, which is outside the scope of the mandate, ESMA proposed that they do not apply later than 1 February of each year. Feedback to the consultation
In general, there was agreement with ESMA’s proposals.
Two market participants advocated for a more ambitious model given that trading
volumes can fluctuate depending on several factors. More specifically, they considered that the weightings should be determined more frequently than annually and would suggest that a quarterly determination would be appropriate.
Some stakeholders saw merit in considering if the frequency of distribution could be
increased in the second or third year of operations, with part of the revenues being shared on a quarterly basis, and a final accounting taking place annually. This would acknowledge the need to fund operations of smaller trading venues, where costs are incurred during the year too.

ESMA’s assessment and next steps
206. Considering that the frequency of redistribution is not in the mandate of ESMA and that
a more frequent calculation of the percentages could encourage a more frequent distribution of the revenues (there appears to be broad support for a quarterly frequency), ESMA considers that the proposal should be slightly amended to allow for a more frequent determination of the percentages and leave some discretion to the CTP. However, the determination cannot be less frequent than annual.
207. Furthermore, as long as the frequency of the determination of the percentages is less
than annual, the annual volume for the calculations to be considered should indeed be annual on a rolling basis, e.g. for distribution in the month of April over the first quarter (January-March) of year t, the calculations should use the annual volumes from the beginning of April in year t-1 to the end of March in year t.
208. Last but not least, whatever frequency is determined, the percentages should be
determined by the 20 th calendar day of each month and applied over the previous quarter. As a result, the flowchart presented in the CP (Figure 7) is replaced by the figure below, based on the assumption of a quarterly frequency for the definition of the percentages as well as for the distribution of revenues (January, April, July, October).

Figure 1: Simulation of the revenue redistribution calendar

4.1.3 Methodology and weights in the RTS
Proposal in the CP
209. The proposal consists of Articles 1 to 6 of the draft RTS included in the CP.
Feedback to the consultation
210. Most of the respondents agreed with the proposed text and did not provide additional
or alternative suggestions. A minority of respondents however disagreed with the design and/or the concept of revenue distribution.
211. A few respondents proposed that the revenue redistribution is extended to all data
contributors, including APAs. Moreover, a few respondents suggested that the volume contributed by APAs should be excluded from the basis for revenue calculation as they are not included in the revenue redistribution.
212. One respondent called for more guidance on the application of the RCB requirements
to the CTP, noting that revenue redistribution may not occur if the costs of the CTP outweigh its revenues, and that providing expectations on the percentage range that would qualify as a reasonable margin could be helpful.
213. An association representing trading venues and some of its members called for an
explicit prohibition for the CTP to provide services beyond the ones foreseen in MiFIR, or alternatively mandating that such value-added services are provided by a separate legal entity, with additional licensing agreements, and that the revenue from these services are also redistributed to data contributors. ESMA’s assessment and next steps
214. ESMA underscores that both the existence and the design of the revenue redistribution
mechanism for the equity CTP are largely defined in MiFIR. ESMA cannot therefore extend the scope of the data contributors eligible for redistribution or exclude APA volume from the calculation basis.
215. Similarly, ESMA considers that allowing the CTP to take into account the costs incurred
by data contributors, with second-order effects on the fees charged to users and/or on the revenue redistributed to data contributors, would be in contradiction with the provisions in
Article 13 of MiFIR, based on the actual costs incurred as further specified in the RTS on
Reasonable Commercial Basis (RCB).

The approach to value added services will be assessed as part of the CTP selection
procedures, when specifying the governance arrangements that applicants are expected to have in place.
It should also be noted that the compliance with Article 13 of MiFIR forms an integral
part of the assessment of the level of fees envisaged by applicants during the selection
procedure.
4.2 Mandate under Article 27h(8)(c) of MiFIR
Articles 7 to 10 of the draft RTS proposed in the CP set out general principles for the
suspension and the resumption of the revenue redistribution scheme, including the provision of retained revenue, while maintaining flexibility for the CTP to specify the features of the scheme, notably the frequency of data quality checks and revenue redistribution.
4.2.1 ESMA’s criteria
Proposal in the CP
ESMA proposed a minimum set of criteria that the CTP should consider when
assessing whether a data contributor should be suspended from the revenue redistribution scheme due to serious and repeated breaches of the data requirements referred to in Articles 22a, 22b and 22c of MiFIR:
− #1 Timeliness: when, for three consecutive days, a data contributor has failed to submit transactions or has submitted later than as close to real time as technically possible, as defined in the RTS mandated by Article 22b of MiFIR, for more than 3 transactions and those reports account for at least a number of transactions that in percentage is not lower than 10% of the total number of transactions submitted in a single day. − #2 Quality, format and substance of data: where, for three consecutive days, a data contributor has submitted more than 3 incomplete reports or 3 reports containing potentially erroneous data, and those reports account for at least a number of transactions that in percentage is not lower than 10% of the total number of transactions submitted in a single day. − #3 Exceptional circumstances: all conditions that are out of the ordinary, unavoidable or unexpected, and that would have been otherwise identified as a serious and

repeated breach of the data requirements referred to in Articles 22a, 22b and 22c of MiFIR by data contributors. − #4 Quality of transmission protocol: the data contributor does no longer meet the minimum standards of the transmission protocol as defined in the RTS. − #5 Clock synchronisation: the data contributor does no longer synchronise the business clock in line with the accuracy required by the RTS.
220. The combination of two quantitative criteria (#1 and #2) and two qualitative criteria (#4
and #5), applying alternatively and with consideration for exceptional circumstances (#3), aimed to ensure that the CTP’s discretion in suspending revenue redistribution is framed in a fair, transparent and non-discriminatory manner. Feedback to the consultation
221. Most of the respondents agreed with the proposed criteria and did not provide additional
or alternative suggestions. One respondent suggested that suspensions do not take place during a two-year transitory period, to test the criteria and to detect potential failures due to outsourcing to third parties, also in light of the parallel implementation of DORA.
222. There was general support for criteria #3 (exceptional circumstances) and #4 (quality
of transmission protocol). A few respondents however disagreed on the definition of other criteria:
− Criterion #1 (timeliness): most responses from some trading venues considered that the criterion is too strict with the proposed definition of ‘as close to real time as technically possible’; some trading venues called for more lenience, e.g. a threshold higher than 3 transactions and/or for suspension only after 6 consecutive working days. One sole respondent deemed the 10% threshold as too lenient. − Criterion #2 (quality, format and substance of data): responses from some trading venues suggested that suspension only applies to ‘actual’ erroneous data (rather than ‘potentially’ erroneous data) and called for more lenience with suspension applying only after 6 consecutive working days. One sole respondent deemed the 10% threshold as too lenient. − Criterion #5 (clock synchronisation): one respondent pointed to the challenges to monitor the exact synchronisation of clocks beyond the yearly review required from data contributors in Article 7 of RTS 25.

Moreover, an association representing trading venues and some of its members
advocated for an alternative approach to the suspension of revenue redistribution, which would include:
− calculating penalties and/or suspension depending on the volumes of erroneous feeds, based on an extra weight according to the seriousness and scale of the breach; − establishing a Review Committee including representatives from the CTP, ESMA and the data contributor in breach, with longer timeframes for dialogue and assessment; − empowering ESMA (rather than the CTP) to decide on the penalties/suspension, and to act as ultimate recourse. ESMA’s assessment and next steps
ESMA underscores that the CTP is the deciding entity when it comes to suspension
and resumption of redistribution, and that MiFIR does not foresee any specific role for ESMA in relation to the suspension of revenue redistribution.
The CTP will be able to design a revenue redistribution mechanism that includes
additional features on top of the minimum requirements set out in the RTS, provided that such features allow to effectively remedy serious and repeated breaches of data requirements in a fair, transparent and non-discriminatory manner. ESMA would therefore caution against introducing complex features leading to lengthy interactions between the CTP and data contributors.
In light of the feedback received, ESMA puts forward a further calibration of the criteria,
coupled with clarifications on how these criteria could be assessed as part of the procedure for the suspension and resumption of redistribution (see Section 4.2.2).
Quantitative criteria on timeliness (#1) and on quality, format and substance of data
(#2) are explicitly linked to the checks that the CTP should perform on an on-going basis in accordance with the provisions on the management of incomplete or potentially erroneous information by CTPs in [the RTS on input/output]. The objective of this explicit link is to integrate the monitoring of suspension criteria in the day-to-day operations of the CTP.
ESMA also proposes that the threshold for seriousness is maintained at 10% of the
transactions executed/orders sent in a single day. ESMA also clarifies that this threshold should apply separately to the sending of orders and to the execution of transactions, in order to distinguish between pre-trade data and post-trade data when assessing data requirements.
In summary, ESMA proposes that a breach of data requirements should be considered
serious and repeated when:
− it occurred in three consecutive days,
− three trade (order) reports are late/missing (criterion #1) or incomplete/erroneous (criterion #2), and the volume of orders (for pre-trade data) and transactions (for posttrade data) covered in the trade reports deemed in breach amounts to at least 10% of the total number of orders (for pre-trade data) or transactions (for post-trade data) submitted in one day.
In this context, ESMA reminds stakeholders that such breaches do trigger the
procedure for the CTP to decide suspending the revenue distribution scheme, and that the CTP can decide to apply more stringent requirements for a suspension including lower thresholds on the number and volume of trade (order) reports constituting a serious and repeated breach of data requirement. However, the CTP should always assess the breach and take a decision when the thresholds set out in the RTS are reached.
ESMA also clarifies that the compliance with the qualitative criteria on quality of
transmission protocol and clock synchronisation (#4 and #5) does not have to be assessed on an on-going basis as long as the CTP is able to determine the number of days during which data contributors were in breach in each redistribution window.
4.2.2 Procedure for the suspension and the resumption of redistribution
Proposal in the CP
In the draft RTS visualised in a flowchart, ESMA proposed minimum requirements for
a fair procedure that the CTP should respect when designing its procedure for suspension and resuming redistribution.
ESMA’s proposal outlined specific timeframes for each step of the procedure, including
two days for the CTP to inform a data contributor in breach, one week for that data contributor to provide further evidence to the CTP, and one week for the CTP to make a final assessment on the presumed breach. Feedback to the consultation
Most respondents welcomed ESMA’s approach to outline minimum requirements for a
fair procedure and did not suggest an alternative approach.
One respondent suggested that the CTP should regularly publish reports on the data
quality of data contributors to increase public pressure.
Several respondents suggested to implement revenue redistribution in a lagged
manner (i.e. at the end of each distribution window), and with a sufficient time gap (i.e. a minimum of 2 weeks), such that the definite outcome of any potential breach is established before the actual payment date, and no reimbursements are necessary. In their view, such a design would allow to avoid additional administration and complexity in undoing suspensions and balancing payments.
Several respondents also suggested to implement an ad-hoc sanctions regime for data
contributors outside the revenue redistribution scheme, which could rely on the same data quality verification mechanism.
Several respondents, mostly data contributors, proposed to establish a Review
Committee which should consist of representatives from the CTP and ESMA, as well as from the data contributor with whom an issue has been detected. The same respondents further suggested that the volumes of erroneous feeds should be calculated based on an extra weight according to the scale of the breach, and that the RTS should allow a data contributor subject to suspensions to seek recourse from ESMA.
Most respondents agreed with the proposed time frames while a few respondents
recommended a minimum of 3 weeks to discuss potential data breaches in a dedicated review committee and another 3 weeks to resolve potential issues.
Half of the respondents agreed with the proposed one-week window for data
contributors to provide further evidence of non-breaches or did not provide additional or alternative suggestions. One disagreeing respondent suggested that the one-week period can be extended by the CTP. The rest of disagreeing respondents, mostly data contributors, were in favour of suspending the redistribution only as the last step after a dialogue between CTP and data contributors. ESMA’s assessment and next steps
By way of introduction, ESMA stresses that the procedure for revenue redistribution
should be further defined by the CTP and structured in such a way to incentivise timely resolution of breaches of data requirements. This includes ensuring that revenue is suspended in relation to the entire period during which the CTP considers the data contributor has seriously and repeatedly breached the data requirements.
ESMA also notes that neither the establishment of a review committee on breaches of
data requirements, nor the possibility for data contributors to seek recourse from ESMA or national authorities on suspension of revenue redistribution are foreseen in MiFIR.
ESMA highlights that CTPs will be required to publish performance statistics and
incident reports relating to data quality and data systems, in accordance with Article 27ha of MIFIR every year, and that ESMA will develop draft RTS on the content, timing, format and terminology of this reporting obligation. At this stage, ESMA recommends that the CTP considers publishing information on a voluntary basis on serious and repeated breaches of data requirements for each redistribution window.
ESMA welcomes the suggestion to implement revenue redistribution in a sufficiently
lagged manner to ensure a timely redistribution of suspended revenue to other data contributors (in case of breach). ESMA notes that this approach might be more suited for a frequent redistribution set-up (e.g. monthly, quarterly), as each payment may be an incentive to swiftly resolve breaches of data requirements.
ESMA is sympathetic to the idea of a sanctioning regime for those data contributors
outside the revenue redistribution scheme. However, such regime is not foreseen by the Level 1 text. ESMA would like to highlight that according to Article 10(8) of Commission Delegated Regulation 2017/571 (RTS 13 – currently under review), APAs may impose penalties on data contributors, and according to Articles 69 and 70 of MiFID II, ESMA and NCAs (as applicable) as competent authority for APAs may impose sanctions on APAs, if certain obligations also with regard to data quality are not fulfilled.
In light of the received feedback, ESMA considers the timeframes proposed in the CP
as drawing an appropriate balance between timely suspension of revenues in case of serious and repeated breaches and on-going dialogue between the CTP and data contributors. ESMA also agrees that the CTP can decide to grant more time for a data contributor to provide additional evidence.
In summary, the procedure for the suspension and the resumption of redistribution
should be designed against minimum requirements outlined below and summarised in
Figure 2 at the end of Section 4.2.
On an on-going basis, the CTP should perform checks on the trade reports in line with
the RTS on data quality and monitor for every data contributor:
− the number of days when input data reports are late/missing (criterion #1), based on timeliness checks;

− the number of days when input data reports are incomplete/erroneous (criterion #2), based on completeness checks, format adherence checks and Identification of erroneous trades; − the ratio of trade (order) reports in breach for criterion #1 and for criterion #2 over total number of trade (order) reports submitted in a day (‘breach ratio’).
249. The CTP should notify within two days a data contributor that was in breach of either
two criteria for three consecutive days and when the breach ratio was at least 10%. This notification should identify the trade (order) reports deemed in breach and the number of days in relation to which revenue would be suspended.
250. That data contributor should be allowed to provide additional evidence that the trade
(order) reports were not late/missing (criterion #1), that the data reported was not incomplete or erroneous (criterion #2), and/or that exceptional circumstances apply (criterion #3) within one week of the notification. Based on the additional evidence initially provided, the CTP can decide once to grant a longer period for the data contributor to provide further evidence.
251. By the end of each redistribution window, the CTP should assess whether each data
contributor has complied with minimum standards on quality of transmission protocol (criterion #4) and with the required accuracy of business clocks (criterion #5), and where relevant, the number of days the data contributors were in breach of either or both criteria.
252. Based on the on-going assessment of criteria #1 and #2 (including additional evidence
from data contributors) and the periodic assessment of criteria #4 and #5, the CTP should calculate the revenue that would be suspended for each data contributor. Revenue should be suspended for at least 3 days and as long as the breach persisted for criteria #1 and #2, and for all the days of non-compliance for criteria #4 and ‘#5.
253. On the last day of the redistribution window, the CTP should notify each data contributor
whether they would be subject to suspension of revenue redistribution. This notification should identify the criteria deemed in breach, with the corresponding trade (order) reports for criteria #1 and #2, and the number of days in relation to which revenue would be suspended. The CTP should notify the same information to the competent authorities of the data contributors, in accordance with article 22a(8) of MiFIR.
254. Data contributors should be allowed to provide additional evidence that the
transmission protocol was compliant with minimum requirements (criterion #4), that business clocks were synchronised with the required accuracy (criterion #5), and/or that exceptional circumstances apply (criterion #3) within one week of the notification. Based

on the additional evidence initially provided, the CTP can decide once to grant a longer period for the data contributor to provide further evidence.
255. The CTP should make a final decision on the suspension of the revenue based on the
evidence provided and redistribute revenue accordingly within two weeks after the end of the redistribution window, unless it has requested additional information from the data contributor.
256. When the CTP confirms its assessment that serious and repeated breaches of data
requirements occurred, the portion of revenue of the data contributor in breach for the corresponding days may be redistributed to other data contributors. When the CTP does not confirm its assessment, this portion of revenue should be redistributed to the data contributor that was deemed in breach.
257. The CTP should only retain revenue when the period for the data contributor to provide
additional evidence has not expired on the last day of the redistribution window. Such retained revenue should be redistributed with interest to the data contributor deemed in breach within two weeks of the CTP’s final decision, if and only if the CTP does not confirm its assessment based on the evidence provided by the data contributor.
4.2.3 Notification of suspension
Proposal in the CP
258. ESMA recalled the requirement for the CTP to notify the competent authority of the
data contributor “where [it] considers the quality of the data to be insufficient”, in accordance with Article 22a(8) of MiFIR. This obligation was considered already encompassed within the provisions of Article 22a of MIFIR and was therefore not specified in the RTS. Feedback to the consultation
259. Most respondents agreed with ESMA’s proposal and did not provide additional or
alternative suggestions.
260. One respondent was of the view that only the final decision on the suspension should
be notified to the competent authority of the data contributor. Another respondent suggested that the competent authority of the data contributor is informed of the initial suspension and its duration, that the data contributor has provided evidence of no breach, and the CTP will reassess its decision or that no evidence has been provided and the

suspension will be sustained; and of the outcome of the reassessment, if a reassessment is conducted. ESMA’s assessment and next steps
261. Notwithstanding the possibility for the CTP to consider that the quality of the data is
insufficient at any other point of time, ESMA expects that the CTP would notify the competent authority of a (potential) breach of data requirements under Articles 22a, 22b and 22c of MiFIR, both when notifying data contributors of the suspended revenue and corresponding breaches, as well as when distributing revenue, and therefore applying the suspension to data contributors in breach.
4.2.4 Approach to retained revenue and interest applied
Proposal in the CP
262. ESMA proposed that the CTP retains the revenue during one redistribution window
when it has decided to suspend the redistribution, with two possible avenues at the next redistribution window: (i) releasing the retained revenue with interest (compounded on the basis of the average ECB marginal lending facility rate during the suspension period) if the CTP considers that the data contributor was not in breach or (ii) redistributing the retained revenue to other data contributors, if the CTP confirms its initial assessment, after considering additional evidence from the data contributor. Feedback to the consultation
263. Most respondents agreed with ESMA’s proposal or did not provide additional or
alternative suggestions. One respondent suggested to specify the approach to currencies other than the euro, while another respondent suggested to use Euribor 360 as the reference rate.
264. Some disagreeing respondents expressed concerns that the approach may not be
suitable if the redistribution is less frequent (e.g. yearly). Another respondent posited that a systematic redistribution to other data contributors after the end of the revenue redistribution calculation period would allow to reduce the complexity of managing interest payments on retained revenue. ESMA’s assessment and next steps
265. ESMA proposes to maintain its proposed approach, bearing in mind that redistribution
will likely be more frequent than yearly (although it cannot be mandated in the RTS), and

that the CTP could look to design a revenue redistribution mechanism limiting the possibility to retained revenue.
266. ESMA also specifies in a revised Article 9(3) the approach to interest for currencies
other than the Euro, for cases where the CTP would be established in a Member State not using the Euro.
Figure 2: Visualisation of suspension process
sends trade reports
Monitoring:

number of days
of #1 and #2 breaches
ratio of trade
reports for #1 and #2 breaches
compliance with
#4 and #5 criteria
On-going basis
Every redistribution window
Notification of #1 and
#2 breaches within two days checks data quality Additional evidence on #1, #2 and #3 within one week Calculation of suspended revenue
#1 and #2: at least 3 days and as
long as the breach persisted
#4 and #5 : all days of noncompliance
Notification of suspended revenue and corresponding breaches Notification of suspended revenues and corresponding breaches Additional evidence on #3, #4 and #5 within one week Retained revenue if dialogue with data contributor is pending data contributor 1 data contributor 2 data contributor 3 data contributor N ... CTP CTP Data contributor Data contributor Competent authority of data contributor Redistributed revenue Notification of suspended revenue

5 RTS on the synchronisation of business clocks
5.1 Reference time
Proposal in the CP
267. ESMA proposed to maintain Coordinated Universal Time (UTC) as the reference time
for clock synchronisation, given that UTC was already specified as the reference time in RTS 25 and in alignment with international standards.
268. Synchronisation should be achieved through timing centres or global navigation
satellite systems, as these remain the most reliable and widely used methods. Feedback to the consultation
269. All respondents, except one, expressed their agreement with the proposed approach
on synchronisation to reference time.
270. The disagreeing party, a potential CTP candidate, suggested a less prescriptive
approach for CTPs, such as using cloud-based Network Time Protocol (NTP) for the first five years. ESMA’s assessment and next steps
271. ESMA confirms the proposal to use Coordinated Universal Time (UTC) as the standard
for clock synchronisation. UTC, already established in RTS 25, aligns with international standards and has been endorsed by the general conference on weights and measures (CGPM) as the global reference for civil time 10, providing a reliable and consistent time scale for financial markets.
272. Regarding the suggestion from one respondent for a less prescriptive approach for an
initial five-year period, ESMA underscores the need for consistent alignment across all entities, including CTPs. Introducing flexibility for some participants could undermine the objective of seamless synchronisation across the market. Therefore, ESMA does not consider appropriate a more lenient standard for certain entities. 10 Resolution 4 (2022) - BIPM.

5.2 Level of accuracy for operators of trading venues
Proposal in the CP
273. In the CP ESMA proposed to update the level of accuracy for operators of trading
venues. Under the current rules, the maximum allowed divergence from UTC and the timestamp granularity depends on the gateway-to-gateway latency of their systems. For latencies longer than 1 millisecond, the maximum divergence is 1 millisecond, and for shorter latencies, it is 100 microseconds.
274. Given the increase in high-frequency trading speeds, ESMA proposed to enhance the
timestamp granularity for trading venues with a latency below 1 millisecond to 0.1 microseconds. As for the other requirements applicable to operators of trading venues, ESMA proposed to transpose them as currently drafted into the new RTS on clock synchronisation. Feedback to the consultation
275. Feedback on the proposed timestamp granularity of 0.1 microseconds for operators of
trading venues with gateway-to-gateway latency under 1 millisecond was mixed. Half of the respondents opposed the proposal, citing the potential high costs and technical burdens of upgrading their systems to accommodate such fine-grained timestamps, arguing that these investments would not provide sufficient regulatory or competitive advantages to justify the expense. One respondent suggested different synchronisation rules for asset classes, particularly bonds, to avoid unnecessary expenses.
276. In contrast, the remaining respondents supported the proposal, highlighted recent
technological improvements that could accommodate this change and pointed out that a more granular timestamp could improve the accuracy of ordering in European trading platforms or markets. ESMA’s assessment and next steps
277. Since the time when accuracy level requirements for operators of trading venues were
first set in RTS 25, the speed and sophistication of high-frequency trading (HFT) have significantly increased, with major trading venues now timestamping messages to a precision of 100 nanoseconds. To address these advancements, ESMA maintains its proposed approach to enhance timestamp granularity for operators of trading venues with gateway-to-gateway latency below 1 millisecond to 0.1 microseconds. This enhancement ensures that timestamp accuracy supports precise ordering and sequencing in fast-moving markets, keeping pace with technological progress.

ESMA highlights that technological advancements have made such levels of accuracy
feasible for many trading venues. In competitive and increasingly automated markets, highly granular timestamps not only align with current capabilities but also strengthen market integrity by reducing discrepancies in order sequencing.
In addition, regarding the suggestion to apply different synchronisation rules for asset
classes such as bonds, ESMA notes the following:
− Scope of the requirement: the proposed requirement is limited to operators of trading venues with gateway-to-gateway latency below 1 millisecond and participants employing HFT techniques. This ensures that the requirement impacts only those for whom timestamp granularity is critically relevant, such as participants engaged in HFT and trading venues already operating with very low latencies. This approach is consistent with RTS 25, which ties stricter timestamp granularity to lower latency levels. − Limited impact on bonds: bonds are typically not traded using HFT strategies. Trading venues offering bonds exclusively are unlikely to meet the <1 millisecond latency threshold, meaning the stricter timestamp granularity requirements will not apply to them. For mixed-asset trading venues with <1 millisecond latency, the timestamping systems used are uniform across all instruments, including bonds, ensuring that the extension of granularity poses no additional operational challenges. − Harmonization of requirements: introducing different requirements for asset classes could create inconsistency and fragmentation across trading venues, undermining the objectives of harmonized reporting. ESMA believes that maintaining a single, harmonized approach to timestamp granularity across all trading venues—regardless of asset class—ensures consistency, reduces complexity, and upholds the integrity of reporting standards.
In conclusion, ESMA supports maintaining the proposed timestamp granularity
requirements, noting that the practical impact on bond trading is minimal.
5.3 Level of accuracy for members, participants or users of a trading
venue
Proposal in the CP
In the CP, ESMA proposed maintaining the current rules for accuracy levels for
members, participants, or users of a trading venue, which calibrate the maximum divergence from UTC and timestamp granularity according to the time sensitivity of the trading activity.
Accordingly, for participants using high-frequency trading techniques, the thresholds
should align with those set for trading venue operators with short gateway-to-gateway latency. If the proposal to increase timestamp granularity for trading venues is implemented, the same requirements should apply to HFT participants. Feedback to the consultation
The majority of respondents supported the proposed approach regarding the level of
accuracy for trading venue members, participants, or users. However, those who opposed expressed concerns that the existing differences in granularity and latency levels would continue to make it difficult to use time-stamped data to prove best execution. Additionally, for the bond data, any timestamp granularity exceeding what is already in use at bond trading venues and Approved Publication Arrangements is seen as redundant, irrespective of how users are classified. ESMA’s assessment and next steps
ESMA maintains its proposed approach for the level of accuracy for members,
participants, or users of a trading venue, ensuring consistency with existing standards and alignment with the requirements for operators of trading venues. The approach remains unchanged for all types of activity, except for those using high-frequency algorithmic trading techniques, where the more stringent accuracy requirements, aligned with those for operator of trading venues, will apply.
In response to concerns raised about different granularity and latency levels potentially
making it difficult to prove best execution, ESMA notes the importance of calibrating the expected level of accuracy to the specific activities each entity performs and the latency of their systems. This approach ensures that unnecessary operational costs are not imposed on entities that would not benefit from finer granularity. Trading venue members, participants, and users typically operate systems that correspond to the nature and complexity of their trading activities, and the accuracy requirements should be proportionate to these activities.
Regarding the comment on bonds, ESMA reiterates that the same reasoning applies:
the increased timestamp granularity primarily impacts high-frequency trading and would have minimal effect on bond markets. Bonds are typically not traded using high-frequency trading strategies, and trading venue participants engaging exclusively in bond trading generally do not operate systems with the low latencies targeted by the stricter requirements. For mixed-asset participants active on trading venues with gateway-togateway latencies below 1 millisecond, the systems they use are already equipped to meet higher granularity standards, given that these standards are designed to align with trading strategies involving high-frequency activities. This ensures that the additional requirements

do not impose unnecessary burdens on bond market participants or create operational inefficiencies.
5.4 Traceability to UTC
Proposal in the CP
287. In the CP, ESMA proposed extending the current requirement outlined in Article 4 of
RTS 25 to the relevant new entities. This requirement mandates that operators of trading venues and their members or participants establish a system for traceability to UTC and review their traceability system’s compliance at least once a year, as specified in Article 7 of the draft RTS. Feedback to the consultation
288. Most respondents supported the proposed approach on traceability to UTC, viewing it
as essential for consistency and easier synchronisation due to UTC's established standard. Only one respondent opposed it, concerned that the requirement may raise costs for the bond tape without providing tangible benefits to consumers. ESMA’s assessment and next steps
289. ESMA confirms the approach proposed in the consultation paper to extend the
requirement for traceability to UTC to new relevant entities, as outlined in Article 4 of RTS 25. Given the strong support from respondents and in alignment with existing standards, ESMA considers traceability essential to maintain consistent and accurate synchronisation across diverse systems.
290. In response to concerns over potential costs, particularly for the bond tape, ESMA
emphasizes that traceability to UTC provides foundational benefits for a sound reporting framework and the additional requirements envisaged in Article 7 of the draft RTS are manageable and do not imply significant costs or investments.
5.5 Application of clock synchronisation requirements to new
entities
Proposal in the CP
291. In the CP, the proposed accuracy levels for APAs, Sis, DPEs and CTPs were based
on their role in the data transmission chain:

− APAs: The proposal was to align accuracy requirements with those for trading venue operators, maintaining a maximum divergence from UTC of one millisecond and a timestamp granularity of one millisecond or better for all transactions published by the APA, as currently specified in Article 18 of RTS 13. − CTPs: The proposed accuracy level was one millisecond, both in terms of maximum divergence from UTC and of timestamp granularity. − SIs: The proposal was to define the accuracy levels for SIs according to the same gateway to gateway latency criterion applicable to operators of trading venues. − DPEs: The proposal was to set an accuracy requirement of one millisecond for both timestamp granularity and maximum divergence from UTC, regardless of the trading activity performed.
292. Stakeholders were also asked whether they believed more stringent requirements
should be set for SIs compared to DPEs, given that SIs have pre-trade transparency obligations. Feedback to the consultation
293. The feedback received on the proposed accuracy levels is summarized as follows:
− APAs: There was general agreement among respondents that APAs should adhere to standards similar to those of trading venues. However, some suggested that the maximum divergence from UTC should apply only to APAs using automated systems, recommending a different approach for manual processes, such as data entry through a web-GUI, due to the lack of automation. One respondent further proposed a less stringent requirement – a 1-second standard for both maximum divergence from UTC and timestamp granularity. − CTPs: Aside from those who expressed general agreement on accuracy levels for all entities, only few specific comments were raised regarding CTPs. One respondent recommended setting a higher accuracy level for CTPs compared to APAs. − Sis: Many respondents supported aligning SI accuracy requirements with those of trading venues, especially when low-latency gateways are involved, due to comparable business models. This alignment, they noted, would prevent SIs from gaining a competitive advantage. In contrast, some respondents, including market associations, disagreed, highlighting that SIs operate with different technical and operational structures, often involving manual processes. They argued that imposing trading venue-level granularity on SIs would impose unnecessary costs, particularly for smaller participants. SIs do not use a gateway-to-gateway model, typical of trading venues,

and Article 22c (1) of MiFIR only requires SIs to synchronize business clocks, not to match trading venue standards. Suggestions included exempting smaller local SIs from stringent requirements and applying them only to larger SIs contributing to the consolidated tape or setting different accuracy levels for equity versus bond transactions. − DPEs: Few respondents opposed the proposed accuracy levels for DPEs. One respondent suggested a less stringent requirement for DPEs in bond markets, recommending a 1-second timestamp granularity instead of the proposed 1-millisecond standard for both maximum UTC divergence and timestamp granularity, noting that the proposed standards appeared tailored to equity markets and were unnecessary for bond markets, where high accuracy standards could impose significant costs and hinder the goal of providing low-cost data access.
294. Some respondents argued that, given DPEs primarily provide reporting services and
do not engage extensively in trading activities, the proposed maximum UTC divergence and timestamp granularity were not justified. Another respondent recommended including DPEs in the short gateway-to-gateway latency category if the investment firm also conducts SI activities.
295. Some respondents opposed introducing more stringent requirements for SIs compared
to DPEs, arguing that firms operating as both SIs and DPEs typically use the same infrastructure and protocols. They highlighted that ESMA’s approach does not consider the different trading activities conducted by investment firms, such as voice trading. These respondents recommended an alternative framework based on activity or asset class, which would better reflect the distinct operational contexts of various trading practices.
296. Conversely, other respondents supported applying stricter requirements to SIs than to
DPEs. They argued that, as execution venues in high-frequency equity markets, SIs require tighter latency standards to prevent disadvantages for clients. DPEs, in contrast, focus on post-trade reporting, where the urgency is lower and thus does not necessitate the same stringent requirements due to the fundamentally different nature of their services.
297. Lastly, some respondents advocated for harmonizing timestamp granularity across all
market participants at the lowest practical level. While they recognized the need to balance technological costs with accuracy, they suggested introducing a transition period to allow firms to gradually upgrade their systems. ESMA’s assessment and next steps
298. ESMA maintains the proposed approach for all entities, emphasising that accuracy
requirements should reflect the role each entity plays in the data transmission chain.

As data submission to CTPs is expected to occur at a granularity level of milliseconds,
both the receiving entities (CTPs) and the submitting entities must meet this level of accuracy. These requirements are necessary to support the seamless transmission of data at the prescribed precision, ensuring the integrity of consolidated data disseminated by the CTP. Importantly, these requirements are independent of reporting timeliness obligations and pertain specifically to the technical capabilities of the systems involved, ensuring accuracy in the synchronisation, and recording of timestamps.
Regarding the suggestion to prescribe higher accuracy levels for CTPs compared to
APAs, ESMA does not recognise any significant benefits. The proposed alignment in terms of requirements across the two types of entities ensures that unnecessary operational costs are not imposed on entities where finer granularity offers no additional value. A uniform standard for CTPs and APAs avoids inconsistencies and upholds the principle of proportionality in regulatory requirements.
For SIs, in response to comments suggesting that the requirements are too strict,
ESMA notes that stricter accuracy levels will apply only to those SIs whose systems are comparable in latency to those of trading venues with the shortest gateway-to-gateway latency, ensuring that the principle of "same rules should apply to the same activities" is upheld. For other SIs and DPEs, the accuracy requirement remains set at one millisecond, which reflects the operational needs and technical capabilities of these entities.

6 RTS/ITS on the authorisation and organisational requirements for DRSPs
6.1 Authorisation, organisational requirements and publication
arrangements of APAs and ARMs (RTS 13)
Proposal in the CP
302. In the consultation, ESMA requested feedback on the proposed approach in RTS 13
concerning the authorisation of APAs and ARMs, and notably on the inclusion of new authorisation provisions on ownership structure and internal controls for APAs and ARMs. Furthermore, ESMA sought any other comments or suggestions on the draft RTS. Feedback to the consultation
303. Most respondents supported ESMA’s proposal to detach the regime on authorisation
and organisational requirements for CTPs and that for APAs and ARMs.
304. The majority of stakeholders generally supported ESMA’s proposal to include new
authorisation provisions on internal controls and ownership structure. Some of them however noted that compliance with the organisational requirements regime itself implies the set-up of internal controls and arrangements that should suffice for ensuring that the ARM / APA acts in line with the regulation, and notably advocated for more flexibility around internal audit planning. In this regard, a respondent advocated for clarifications on how these new requirements apply to already authorised APAs and ARMs.
305. Some additional remarks were presented by stakeholders. In relation to Article 6(3),
letter (e) of the draft RTS, one respondent proposed to delete the reference to “Internal Audit Committee” since it is not a mandatory requirement to have one.
306. A respondent raised a potential timing issue with the application of both DORA and the
current RTS 13 (i.e. pending the entry into force of the revised RTS 13) for common requirements such as the reporting of ICT incidents and business continuity. In light of that, it was suggested clarifying that DORA will supersede the sectoral legislation in the domain of digital operational resilience and outsourcing requirements in respect of services provided by ICT third-party service providers. In order to ensure consistency between RTS 13 and DORA, it was also proposed to align the wording of article 9 of RTS 13 with DORA by replacing “critical function” with “critical or important function”. ESMA’s assessment and next steps

ESMA notes the overall support for the proposed amendments. In this regard, ESMA
intends to clarify that the compliance with the proposed new requirements is expected on an ongoing basis by all stakeholders, including those who have previously been authorized. This is essential to ensure a level playing field among all parties.
With reference to the proposal to delete the reference to “Internal Audit Committee” in
Article 6(3), letter (d), ESMA acknowledges that the “Internal Audit Committee” is not
mandatory, as specified in Article 6(3), letter (b) of the draft RTS.
Regarding the proposal to align the wording of Article 9 of the draft RTS with DORA,
ESMA agrees that it is desirable to align the wording of RTS 13 with DORA to ensure consistency and certainty. Therefore, ESMA has amended the draft RTS 13 and replaced “critical function” by “critical or important functions”.
6.2 Authorisation of CTPs
Proposal in the CP
In the consultation, ESMA requested feedback on the information to be provided to
assess an authorisation request. ESMA clarified the information to be provided to assess the compliance of applicant CTPs in the areas of (i) organisation, (ii) ownership, (iii) governance, (iv) management body and (v) internal controls. This approach would allow ESMA as a supervisor to better understand the overall corporate governance of the applicant.
ESMA also made a proposal to provide information to assess compliance related to
business operativity. Under this provision, the selected CTP shall provide ESMA information on the total expenditure required to run the consolidated tape. The objective of this provision is to gain visibility on the envisaged operational costs of the CTP.
In addition, ESMA requested feedback on provisions covering the digital operational
resilience framework of CTP applicants, the aim of which is to ensure compliance with DORA.
Finally, ESMA requested feedback regarding the information to be provided in the
authorisation phase on the CTP energy efficiency and the arrangements of the applicant to ingest and consolidate data. Feedback to the consultation
The vast majority of stakeholders agreed with the approach pursued by ESMA in
drafting the RTS on CTP authorisation. Several stakeholders representing trading venues emphasised the importance of aligning the information on ownership with existing EU

regulations for financial service providers. They suggested that the threshold for disclosing shareholders holding more than 5% of capital or voting rights should be increased to 10%, consistent with the requirements for investment firms in the EU.
315. There was a consensus among stakeholders on the need for a clear and precise
definition of retail investors. Two respondents recommended using the definition of “retail client” from Article 4(1)(11) of MiFID II.
316. Several respondents pointed out potential conflicts of interest between the CTP and its
clients. They mentioned that if the CTP's consortium members have existing commercial interests in market data, they might favour their own offerings over the CTP services. This could result in higher fees or restrictive licensing terms, disadvantaging certain users. To address this, they recommended strict governance policies and transparent pricing to ensure fairness and accessibility for all clients.
317. Two respondents emphasised the importance of including diverse stakeholder
representation in the CTP's governance structure. They suggested that the governance should include data contributors, users from the buy-side, sell-side, and retail brokers to ensure balanced decision-making, on the ground that such a representation should facilitate meaningful discussions and valuable recommendations, ensuring that the CTP operates transparently and incorporates stakeholder feedback into its processes.
318. Two trading venues suggested that the RTS should include detailed requirements for
the CTP to provide information on their licensing models. According to these respondents, this information should cover licensing policies between the (i) CTP and clients, specifying the authorisations regarding data usage, and (ii) between the CTP and data contributors, allowing the CTP to use the transmitted data for providing a consolidated tape. They argued that clear and transparent licensing models would help ensure fair access and prevent discriminatory practices. ESMA’s assessment and next steps
319. ESMA acknowledges the feedback received by a few respondents on the need to align
ownership information with the requirements for investment firms. ESMA sees merit in such feedback, however, as it was expressed in the consultation paper, the reason to request information on shareholders owning as a minimum 5% of the CTP shares is to align with other ESMA direct supervisory mandates such EMIR, SFTR and SecReg. To ensure consistency among ESMA direct supervisory mandates, ESMA intends to keep the draft RTS as it is with the 5% threshold.
320. Regarding the proposal on the use of the MiFID II definition of retail clients, it is
important to highlight that MiFIR Article 27h refers to “retail investors” without any further

mandate to define retail clients, therefore ESMA is not in the position to support this proposal.
321. As far as potential conflicts of interest arising between the CTPs with clients and data
contributors are concerned, ESMA believes that the current draft RTS is sufficiently broad to capture these cases. Therefore, ESMA decided not to amend the draft RTS.
322. Whereas ESMA appreciates the motives to have relevant stakeholders represented in
the CTP governance, the MiFIR review does not provide a legal mandate to prescribe who should be represented at the Board. Therefore, ESMA believes that prescribing representation in that way would go beyond the mandate in MiFIR.
323. Concerning the provision of information on the licensing model during the authorisation
phase, ESMA is already taking this into consideration under Article 10 of the proposed draft RTS. The CTP will receive the data free of charge from data contributors. There is hence no need for licencing arrangements between the CTP and data contributors for the core offering of the CTP, i.e. the consolidation of (pre- and) post-trade as defined in MiFIR.

7 Annexes
7.1 Annex I – Summary of Responses to the Consultation Paper
7.1.1 RTS on input and output data of CTPs
Q1: Do you agree with grounding the assessment framework of the quality of transmission protocols on the identified categories of technical criteria? In general, respondents supported the proposal of spelling out the protocols requirements according to the categories identified by ESMA. However, most of the respondents highlighted that the requirements should better specified. Specifically:
− Layers specification: several respondents flagged that the requirements should refer to specific layers of the protocols (Transport/Application/Presentation/Encoding ecc); − Performance: start and end points for the measurement of latency to be more clearly defined, introducing confidence intervals instead of static requirements (several respondents); − Security/Encryption/Authentication: those requirements were deemed not necessary for some respondents as the market data are non-confidential; − Compatibility: most of existing protocols are not “open” solutions. Other categories of requirements proposed by respondents are flexibility and extensibility of the protocols to accommodate future changes and evolving market needs. Q2: Do you believe that additional categories of technical criteria should be considered for the definition of minimum requirements of the quality of transmission protocols? Additional categories of requirements identified were:
− Mandatory documentation/SLA/testing;
− Backward compatibility – to be included under Compatibility; − Accessibility for output data; − Extensibility;

− Service availability, which includes things such as failover times and scheduled downtimes. Q3: Do you agree with the proposal of introducing a single set of requirements across the three asset classes (equity, bonds, derivatives), or do you believe that different requirements should be tailored for each asset class? Almost all respondents recognised the benefits of having a harmonised set of requirements across the three asset classes, especially for those market operators involved in multiple asset classes. However, most of the feedback highlighted that although harmonisation is applicable to reliability, security and compatibility requirements, performance requirements should be differentiated on the basis of the asset class. In light of the different definition of “real-time” for equity and non-equity, and the different business case for pre-trade and post-trade data, most of the respondents suggested to calibrate the “latency” and “throughput” requirements accordingly. Q4: Do you consider that the proposed minimum requirements for the technical criteria related to performance are technically feasible, coherent with the objective of highquality data transmission to the CTP and in line with international standards? Please elaborate your response. Almost all the respondents did not support the proposed performance requirements. Except for one potential CTP applicant that believed that the performance requirements are not sufficient for a robust and fast CTP, all the remaining respondents advocated for a reduction/recalibration of latency and throughput requirements. Specifically:
− Latency requirements: The definition of latency should be better elaborated (i.e. time to submit single transaction vs RTT time, or time to submit info to CTP vs CTP-internal latency); the latency requirement is considered unnecessarily high. It was proposed to re-calibrate it according to the asset class (less stringent for bond) and/or to align it with the revised definition of real-time. It was proposed to require latency through median values or confidence intervals, rather than hard requirements. − Throughput requirements: Several respondents suggested to require less stringent requirements for small data contributors (providing a smaller volume of data). Throughput should be expressed in terms of messages per second rather than a measure such as Mbps. The requirement on throughput depends also on the choice of the format (e.g. JSON requires higher throughput).

Q5: Do you consider that the proposed minimum requirements for the technical criteria related to reliability are technically feasible, coherent with the objective of high-quality data transmission to the CTP and in line with international standards? Please elaborate your response. The general feedback from respondents was that it is fair to request reliability requirements (as proposed in the ESMA CP) but it would be more accurate to specify to which OSI layer and to which entities (i.e. data contributors or CTP) they are applicable. Indeed, several respondents argued that the ones supposed to ensure reliability of the data are the data contributors, whereas CTP is not supposed to modify the data received – so there is no point to add reliability requirements on CTP side. A few respondents commented that reliability requirements are redundant as data quality assurance is already performed at source by APA and TV. Q6: Do you consider that the proposed minimum requirements for the technical criteria related to security are technically feasible, coherent with the objective of high-quality data transmission to the CTP, and in line with international standards and other EU regulatory frameworks on information security (e.g. DORA)? Please elaborate your response. Most respondents argued that encryption requirements are redundant given the nonconfidentiality nature of market data transmitted to CTP. A few respondents commented that non-repudiation requirements are not useful as it is merely another aspect of authenticity, thus it is also ensured on a leased line. No specific comments on the coherence with DORA requirements were made. One respondent raised that the requirements should also comply with NIS 2 and CER Directive. Q7: Do you consider that the proposed minimum requirements for the technical criteria related to compatibility are technically feasible, coherent with the objective of highquality data transmission to the CTP and in line with international standards? Please elaborate your response. Respondents were all generally agreeing with the proposed compatibility requirements. Some clarifications were suggested on the wording to define those requirements, which might be misleading. Specifically, several respondents proposed the that the definition of “open solution” should envisage that protocols must be available under indefinite, irrevocable licenses that permit their usage for the regulatory purposes.

A few respondents criticised the “openness” requirement, highlighting that data contributors largely rely on in-house protocols. Rather than assessing the proprietary nature of the protocols, ESMA should require protocols that should be made free from license by any CTP (current or future) to avoid high switching costs or vendor lock-ins. Regarding interoperability, few respondents argued that this requirement is not important as the number of parties involved is limited. One respondent suggested to add “backward compatibility” as a new requirement. Q8: Do you agree with the proposed definition of “transmission of data as close to real time as technically possible”? If not, please explain. In general respondents were not in favour of the proposal and made some comments. Several stakeholders stated that the appropriate reference point for latency of transmitted data by APAs to the CTP should be calculated from the point of time that an APA receives and can publicly disseminate the relevant data and not from the time of the execution timestamp. Indeed, it is only from that point that an APA is able to proceed to transmission and public dissemination and therefore, the execution timestamp is not an appropriate determinant. Other respondents, regarding the pre-trade requirement of “no later than 50ms”, invited ESMA to add language prohibiting contributors from deliberately adding a delay (other than a reasonable time to convert their native feed to the prescribed CTP feed (i.e. JSON)) or introducing latency whilst adhering to the requirement to provide within 50ms. Several respondents indicated that 200ms is an inappropriate fast processing timing for nonequity markets. Others indicated that 100ms is an ambitious timing for equity and that the ‘onesize-fits-all’ approach proposed by ESMA for the 100 ms post-trade data transmission latency is inappropriate to reflect the different nature, scale and complexity of market data for nonequities. Others indicated that for all transactions not made on a CLOB, especially for bond and derivatives markets where transactions may take minutes, hours, or days to arrange, and where they are generally subject to deferrals, the concept of “as close to real time as technically possible” should be replaced by “as soon as possible,” in order to prevent trade execution being delayed in order to comply with the CTP requirements. Several respondents indicated that 50 milliseconds for pre trade latency is realistic for the ‘larger’ fragmented markets with appropriate network connectivity already established, this latency target could be more challenging for ‘smaller’ markets with less connectivity infrastructure and that are physically further in distance away from any central CTP hub. Finally, some respondents indicated alternative solutions for the definition of the latencies. One respondent proposed that the 50 milliseconds latency definition should be mandated for all

TVs executing with more than 1% European market share, with a potential maximum of 100 milliseconds for markets with less than 1% market share which by nature are generally less fragmented. Q9: Should ESMA consider specific rules for real-time transmission of transactions subject to deferred publication? Most of the respondents replied that there is no need for specific rules. Few respondents considered that there is need instead. Those stated that the CTP will not know when it can expect to receive the update. However, the latency consideration should be less onerous than the ones currently proposed by ESMA for real-time data. For 15 min delay to 4 -week deferral, 5 secs were considered to be appropriate. One respondent considered that alongside the publication timestamp received by the CTP (Annex I of Commission Delegated Regulation (EU) 2017/587 Table 3 (field 11)), it would be valuable for users if the CTP also received a flag indicating when a transaction benefitted from the deferred publication. This would enable the CTP to integrate the transaction into the tape with the appropriate flag thus ensuring that market participants understand the reason for the distance between the transaction and publication times. Another respondent instead considered that high requirements are even less desirable in the case of deferred publication. In the case of deferred publications (with the deferrals ranging from 15 minutes to 4 weeks as per revised MiFIR), there is even less need for a high-speed transmission in milliseconds. Furthermore, certain types of deferred publication such as “end of day”, might lead to a huge bulk of data needing to be published simultaneously, and it could be problematic from a technical perspective to publish such high amounts of data simultaneously within the high-speed latency guidelines. Less stringent latency requirements with respect to any deferred publication should be applied. Q10: Do you agree with the baseline proposal of adopting JSON as standards and format of data to be transmitted to the CTPs, or do you prefer alternative proposals? Please justify your answer and, if needed, provide additional advantages and disadvantages related to each proposal. The vast majority of respondents did not agree with the baseline proposal of adopting JSON as standards and format of data to be transmitted to the CTPs. Several responding parties, including potential CTP applicants, acknowledged the advantages of having a unified format for input data to the CTP, recognizing that it would streamline data integration. On the other hand, few of them even expressed concerns about the proposal to mandate a specific format for data transmission to CTPs, highlighting the potential lack of flexibility. Two respondents argued that prescribing a fixed protocol or format would limit CTPs' ability to adapt to alternative formats or protocols during their term or after a new CTP is appointed. They advocated for

greater flexibility to allow for market development and innovation, recommending that industry standards and functionality be prioritized over strict legal mandates. One respondent proposed that instead of relying on a single format, CTPs should adopt multiple joint data transmission standards that focus on key properties rather than specific schema formats. This approach would promote interoperability and future flexibility as new formats develop. Many respondents raised significant concerns regarding JSON’s suitability for real-time, highspeed, high-volume data transmission, in financial markets. They argued that JSON’s verbosity leads to larger message sizes and slower parsing speeds compared to more efficient binary formats like FAST or SBE. This inefficiency results in increased bandwidth usage, higher latency, and greater operational costs, which are critical issues in a market where speed is essential. One potential CTP applicant also emphasized the environmental costs of using JSON, noting that its larger data size and computational requirements lead to higher energy consumption and a larger carbon footprint. Some respondents further stressed the risk of discrepancies between ‘CT-compatible’ feeds using JSON and direct proprietary feeds, which could lead to delays and inconsistencies without proper synchronisation. Most importantly, JSON is not widely accepted by the industry for market data dissemination. Some respondents also criticized the criteria used in the ESMA Study to assess data formats, particularly the focus on human-readability and ISO 20022 compliance. They argued that human-readability is irrelevant for real-time data transmission, as both data contributors and the CTP possess the technical expertise to manage any format. They also contended that ISO 20022 compliance, while important in post-trade or payment services, is less critical for highvolume, low-latency data transmission in financial markets. One respondent noted that any transition to JSON must be coordinated across various regulatory reporting areas to avoid unnecessary complexity and costs, stressing the importance of full endorsement from all NCAs to ensure a smooth and consistent implementation of the new format. On alternative proposals, thirteen respondents advocated for the use of well-established binary protocols such as FIX and SBE, which are widely used in the financial industry due to their efficiency, low latency, and reliability. They highlighted that binary formats are already highly performant and used across many trading venues, making them more suitable for real-time data transmission than JSON. Forcing all trading venues to adopt JSON would increase costs, slow down data dissemination, and lead to both financial and environmental inefficiencies. There were also concerns about the timeline for implementing any new data transmission format. Many respondents emphasized that the adoption of a new format like JSON would require a phased approach and
sufficient time for development, testing, and industry alignment. They estimated that transitioning to a new format could take 12 to 18 months or more, depending on complexity.

Only few respondents expressed agreement with the proposal to use JSON for specific cases, like the bond post-trade tape. They noted that high-performance transmission protocols and compressed data formats may not be necessary for this type of data. JSON was seen as a balanced choice in terms of performance, readability, and ease of implementation, particularly for smaller trading venues, making it a cost-effective solution. Q11: Do you believe that the proposed standards and formats (baseline and any alternatives) are coherent with other CTP requirements (transmission protocols, realtime transmission and presentation of output data)? Please justify your answer. In response to whether the proposed standards and formats align with other CTP requirements, such as transmission protocols and real-time data output, most participants disagreed, with only a small minority showing support. The majority referenced their responses to a previous question (Q10), reiterating that adopting JSON for market data feeds would be costly, time-consuming, and inefficient. Concerns were raised about JSON's inefficiencies in message size and parsing speed, with several respondents stressing that established protocols like FIX, which have been tested and refined over time, are more reliable and efficient. Some participants suggested that the CTP should not mandate a single format but instead establish joint data transmission standards based on shared properties rather than specific formats. This approach would allow for future adaptability, ensuring interoperability and enabling the integration of new formats as they are developed, without the need for constant amendments to the CTP rules. Respondents emphasized the importance of relying on well-established data formats and protocols during the initial implementation phases, citing concerns about the lengthy timelines required (12-18 months) for developing new formats. One respondent partially agreed with the proposal but suggested that binary protocols like FIX or SBE, already widely used in the market, would be more appropriate for meeting the low-latency and cost-efficiency needs of the CTP. Q12: Do you find more suitable to prescribe one single format across the 3 CTPs (equity, derivatives, bonds) or to prescribe distinct formats according for different asset classes? Most respondents expressed support for adopting a single format across all three CTPs. They argued that this approach would be more efficient, consistent, and cost-effective, especially for data contributors providing data across multiple asset classes. A unified format would simplify integration, reduce operational uncertainty, and streamline processes for both data providers and users. Moreover, this consistency would benefit data users who rely on market data from all three CTPs, and it would also reduce the costs and complexity associated with implementing and maintaining multiple formats.

However, a slightly smaller group favored distinct formats for each asset class, highlighting the practical differences in market structure and technical requirements between equities, bonds, and derivatives. They argued that a single format might not meet the specific demands of each asset class effectively. For example, equities require faster transmission protocols and compressed formats due to higher data volumes, while bonds do not have the same performance needs. A universal format, they claimed, could result in unnecessary costs for bonds, with no added value. Some respondents also suggested a middle ground, proposing different formats for pre-trade and post-trade data, given their differing technical demands. They recommended maintaining consistency at the application layer to ensure the seamless combination of pre- and post-trade data when needed. Q13: Do you support the proposals on core and regulatory data? In particular, are there other relevant fields to be added to the regulatory data? Furthermore, would you propose the inclusion of supplementary fields for input core market data beyond those intended for dissemination by the CTP? Among stakeholders there was no full approval of the proposal, all provided some suggestions for the amendment of the fields. As far as the core market data is concerned, one association requested that any changes to the input/output data content for the CTP should be incorporated into the actual CTP RTS. Moreover, it was noted by those considering that requesting the full set of market data, including all post-trade transparency requirements under RTS 2, would exceed the data necessary for the CTP to be operational. Furthermore, some stakeholders claimed that additional input data by APAs are relevant, such as the timestamps for data reception and data dissemination by the CTP should be added compared to what has been defined on L1. Several stakeholders requested that, instead of requesting the CTP to filter out erroneous trades those are instead flagged. Therefore, they proposed that the CTP core market data output table should also include a separate field to reflect that and of a similar note if the trade is cancelled, amended, confirmed. As far as the regulatory data is concerned, it was noted by few market participants that the provisions and rationale around regulatory data may have been developed with equities in mind while they believed that this requirement should only be relevant for shares, where price discovery is typically derived from the primary exchange and where trading activity is therefore very much linked to the availability of the instrument for trading on the primary exchange. They claimed that for bonds, trading activity is instead distributed widely across several trading venues and OTC. Therefore, status of financial instruments or matching systems is not linked in the same way to trading activity.

Several respondents claimed that the same instrument can be traded in several currencies within the same system/MIC, yet it may have different statuses, meaning that one currency could be halted while trading continues in another. Therefore, they suggested that the currency should be added to uniquely identify the instrument. Furthermore, respondents claimed that trading venue may also operate multiple matching engine units, orderbooks or segment MICs. An outage could occur on one unit resulting in a subset of securities to being halted, but not the entire market. Several respondents noted that the implementation of ESMA’s proposals on fields of regulatory data can be challenging in certain cases, as it would require from those trading systems to develop relevant fields to reflect the trading status which do not currently exist and suggested to use FIX MMT. Several respondents stated that if an APA had an outage and was not publishing trade data to the CTP, the market would want to know this, so a simplified status message would be beneficial. Last but not least, they also noted that the venue status overlaps with topics covered under ESMA’s Final Report on Market Outages. This indicates that expressing a venue’s status simply as ‘working’ or ‘not working’ is an oversimplification (e.g. a trading system might be operational but there may be an issue with market data, outages go through various ‘stages’ – discovery, analysis, repair etc.). Several respondents reported that the “Instrument Status” is missing a Normal/Trading field for when there are no suspensions or halts and suggested to use FIX MMT. One respondent requested extra feedback about whether clocks should be synchronized to the same exacting standards also for status. Q14: Do you support the proposal of machine-readable and human-readable formats outlined in this section? While the majority of respondents supported this approach, recognizing the need to address the diverse requirements of institutional and retail users, some stakeholders raised concerns. Two trading venues questioned the necessity of multiple formats, suggesting that a single machine-readable format combined with a GUI might be sufficient to meet the objectives and simplify the operational demands on CTPs. Two different trading venues further expressed doubts about the feasibility of implementing multiple formats within the proposed timeframe, advocating instead for a binary format and a GUI as adequate solutions for most users. One potential candidate to CTP suggested to drop the requirement to publish in the same format prescribed for input data, as different transmission protocols might equally be allowed on the input and output.

Three respondents emphasized that the GUI should be primarily aimed at retail investors and academia, suggesting that access should be restricted accordingly. Different respondents highlighted that the GUI should enable users to customize the information they require through specific search criteria, visual indication and charts simplicity, in order to provide a view that is human readable and enhance. While the entire dataset should remain downloadable in CSV format well suited for the purpose of research and analysis of data, this would also allow for the generation of user-driven CSV files based on selected criteria. Furthermore, one potential CTP candidate suggested the conflation of pre- and post-trade data in the GUI to avoid overwhelming retail users with frequent updates. They recommended a 1- minute delay for presenting human-readable data. They also advocated for flexibility in formats, suggesting that CTPs should provide data in any format requested by a sufficient number of users. Finally, two respondents noted issues with the use of commas in the “flags” field as regards to the CSV format. They recommended alternative delimiters, such as space or semicolon, to prevent errors in data processing. Q15: Do you agree with the proposal of data quality measures and enforcement standards for input data? In response to the proposal on data quality measures and enforcement standards for input data, several stakeholders provided feedback that generally aligned with each other but occasionally diverged from the consultation paper's proposal. Their input highlighted various points of conflict and offered insights and suggestions on different aspects of this section of the RTS. For identification of erroneous trades and corrective action, several respondents were unified in opposing the CTP modifying data, even under exceptional circumstances. They believed that trading venues and APAs should handle error identification since they already apply rigorous surveillance and standardization. A correction mechanism was deemed disproportionate due to the significant resources it would require. The CTP should publish trades as received and work with contributors on data quality issues, potentially flagging trades as “under investigation.” Only one respondent suggested empowering the CTP to reject erroneous trades. Another respondent recommended an “erroneous trade” flag for post-trade data only and public outlier detection methodology. On referential data, a small group of respondents emphasized the importance of aligning data between providers and the CTP to prevent inconsistencies, embedding referential elements in the systems to prevent issues at the source. One respondent noted that this approach would enable the CTP to perform data quality checks against the FIRDS referential as well. The efficiency of these controls could be significantly enhanced if conducted before the trading day

begins. Therefore, it would be beneficial to amend RTS 23 Article 2.1 to ensure that the FIRDS database includes all new instruments scheduled for the next trading day. On data quality measures, a few respondents agreed that the focus should be on the performance of data contributors and exclude cases related to market abuse or erroneous trades by individual traders. Furthermore, some respondents recommended categorizing issues, separating those that can be fully automated for optimal latency from those requiring manual processing with different time constraints. They also stressed that technical issues should be handled within the transport protocol, while more complex functional problems, such as message format errors, will need time for analysis and potential software corrections. Furthermore, one respondent supported limiting the CTP’s data quality obligations, prioritizing those for APAs, and ensuring that CTP checks do not delay data publication. Regarding the enforcement standards, most respondents opposed giving the CTP enforcement powers, such as levying penalties, suggesting instead that serious data quality breaches be reported to competent authorities. They disagreed with suspending revenues for non-compliance. One respondent recommended punitive measures only as a last resort, after giving data providers time to resolve issues. Additional general suggestions were provided by several respondents. One potential CTP candidate suggested encouraging the development of a single CTP API, even if not mandated, to streamline processes. A different CTP candidate emphasized the need for corporate action information to perform accurate price checks. It proposed that ESMA require the primary place of listing to share corporate action feeds with the CTP. This measure would facilitate quality checks and help the CTP manage historical data effectively. One respondent suggested allowing CTPs to add optional output fields for value-added features. Finally, stressing the importance of having in place cooperation agreements with the data contributors, another respondent suggested to include a model agreement for use by CTPs to ensure consistency of cooperation between and among the trading venues, CTPs, and ESMA. Q16: Do you agree with the proposal of data quality measures for output data? There was general support for the data quality measures for output data outlined in Article 10(1), (2), (3), (7), and (10) of the draft RTS on input and output data of CTPs, with most respondents expressing agreement. Several respondents offered suggestions for improvement, such as that the periodic data reconciliations proposed by ESMA should include specific timeframes for corrections. They also suggested the use of transaction IDs or reference number tags for each trade to allow users to track changes, along with an appropriate flag to mark transactions under investigation.

On the feedback channels proposal, one CTP applicant proposed the introduction of a chatbot alongside a detailed Q&A for retail investors. Another suggested that communication channels should rely on electronic messaging, using market data feeds for updates rather than private messaging. There were also requests for clarification. One respondent sought to better understand the level of data quality measures that will be published and emphasized the importance of not disclosing individual contributor names in any public data or commentary on data quality. Two respondents asked for clarification on the periodicity of reconciliations and the extent of data checks, whether ESMA intends to require a full reconciliation or a simpler process such as a count of reported volumes. Some respondents, echoing previous feedback, expressed disagreement with certain provisions. They disagreed with Article 10(5)(a)-(d) and Article 10(6), arguing that the CTP should not be responsible for determining erroneous data, as APAs and trading venues already have robust quality measures in place. They recommended that the CTP publish potentially erroneous data with an alert flag, allowing users to treat it with caution without introducing unnecessary delays. Q64: What costs do you expect in order to comply with the proposed minimum requirements for the quality of transmission protocols? What benefits do you expect? Please indicate to what role (data contributor, CTP, or CT user) your response refers. With regards to the benefits, seven respondents believed that the primary benefit is the standardization of data, which is expected to enhance the overall quality and reliability of market data. Two of them, mentioned that developing these minimum requirements in line with recognized industry standards can lead to significant efficiencies in data transmission, reducing complexity and costs for market participants. One respondent mentioned that for data contributors their benefits include revenue distributed from the Consolidated Tape Provider (CTP). Additionally, improved data quality and lower data costs could potentially increase retail and institutional participation in EU equity trading, benefiting the market as a whole. One respondent mentioned that the use of FIX will imply reasonable costs for most data contributors and many CT end users. Regarding the costs, the majority of respondents raised concerns of the cost associated with the implementation of these requirements. Three respondent mentioned that data contributors will face both one-time and recurring costs, including the development and maintenance of new feed API contribution mechanisms if existing feeds are not permitted, as well as costs for physical infrastructure (servers, timing components, network connections), and operational

costs for space, power, cooling, and connectivity will also be significant. Furthermore, there may be latency costs if non-native feeds are used, impacting the speed and efficiency of data transmission. One respondent mentioned that costs associated with building and maintaining new versions of existing APIs for data transmission to the CTP, and managing errors and incomplete messaging, will be significantly lower for the bond tape than for the equity tape. Two respondents mentioned that costs related to the CTPs, include developing ingestion API adaptors and potential latency costs of translating new data formats into traditional streaming feeds. Additionally, there are costs for developing or paying for feed adaptors for ingesting data if using native existing feeds. Two respondents highlighted that smaller markets might face additional costs if they opt out of contributing data due to the development capabilities required. Additionally, several respondents have highlighted general concerns regarding the proposed requirements. Four respondents noted that data contributors might face revenue loss as they would transmit their data for free to the Consolidated Tape (CT), competing with their existing commercial offerings. Additionally, three respondents pointed out that the CT revenue share model might not provide sufficient incentives for Consolidated Tape Providers (CTPs) to generate profits to share with data contributors. The revenue distribution scheme lacks incentives for the CT to generate extra revenue or margin to redistribute to data contributors. One respondent mentioned that trading venues might overstate their estimated costs to implement and comply with the draft amended RTS to negotiate for maximum revenue sharing, potentially raising prices on market data and related services. Three respondents mentioned that adopting new protocols, especially if they differ by asset class, could result in high costs and significant time constraints for data contributors delivering data to multiple CTPs. They recommend using existing protocols for as long as possible or ensuring uniform standards across all asset classes. Two other respondents emphasized that developing minimum technical requirements in line with recognized industry standards would ensure cost efficiencies and simplicity in data transmission. In contrast, they recommend avoiding a generic cross-asset approach. For example, a below 100 milliseconds latency requirement for the bond CTP would unnecessarily increase costs without delivering meaningful benefits for data users. Q65: What costs do you expect in order to comply with the proposed data format for input and output data? What benefits do you expect? Please indicate to what role (data contributor, CTP, CT user) your response refers.

With regards to the benefits, two respondents believed that the primary benefit is the standardization and comparability of data, which will facilitate easier aggregation and dissemination by the CTP. They suggested adjusting data formats per asset class to balance costs and benefits. Two other respondents agreed instead with ESMA’s proposal to require a single data format across all asset classes, but given the tight schedule, it might be optimal to use currently applied formats and protocols for now. Another respondent believed that while there will be costs associated with making these changes, it is best to have a new dissemination format and protocol that is the same across all asset classes, as this will reduce long-term cost implications. One respondent highlighted that a standardized data format will enhance data quality and consistency, leading to more accurate and reliable best execution assessments. This will also improve transparency and reduce operational risks. They also mentioned that ingesting data in a standardized format will be more cost-effective for CT users compared to individual subscriptions to each data contributor. One respondent emphasized that the input/output data format is key to the success of the CT. Data quality is the most important driver for this success in the bond market, not latency. Regarding the costs, one respondent estimated high IT development costs for new data formats (approximately EUR 1 million per CTP), as well as additional costs for internal testing and new processes for the setup between CTP and exchange, which could add a further EUR 700k to 1 million. They urged ESMA to use existing data formats/protocols to avoid disproportionate costs, especially for smaller venues. Another respondent noted that implementing a new data format may require adjustments to existing systems, staff training, and data quality assessment, which could involve significant costs. Another respondent mentioned internal costs to implement a process to calculate traded notional from the post-trade feeds and MIC/Sub-MICs. ESMA received several other comments provided by the respondents, where one respondent suggested that the CTP input data involves different parties and serves different purposes than the CTP output data. Therefore, a separation should be made between these two streams, for example, with respect to the transmission protocol, data formats and standards, and the definition of real-time. Another respondent did not expect any specific costs associated with compliance to the proposed data formats. Lastly, one respondent emphasized that the CT needs to have an effective audit trail that helps market participants better understand how the markets are operating at any given point in time.

Q66: Do you expect the benefits from the proposed real time data transmission requirement for input data to outweigh the operational costs borne by data contributors? Four respondents believed that the benefits for the whole industry, such as deepening market access and allowing all market participants to have access to the same information at the same time, would outweigh any costs for data contributors. One of these respondents did only except the benefits to outweigh the cost if performance and clock synchronisation requirements are relaxed. Also, one of these respondents did highlight that the proposed timestamp granularity of 0.1 microseconds ensures accurate sequencing of trades, which is suitable for trade analytics in an increasingly algorithmic and AI-driven capital market. Five respondents did not believe the benefits of the proposed real-time data transmission requirement outweigh the costs. One respondent argued that the mandated JSON contribution feed specification will incur latency costs and technical challenges, potentially deterring some markets from contributing data in a timely manner. Two other respondents expressed concerns about the strictness of the proposed requirements, potential high costs for smaller market operators, and variability in data latency. They suggested more flexible standards. Another respondent also questioned the strict latency requirements, considering them disproportionate and highly burdensome, with unclear impacts on the data business. They urged ESMA to dismiss any latency differences between pre- and post-trade data and to introduce confidence intervals. Furthermore, another respondent also argued that the proposed 100 milliseconds requirement is unnecessary and will result in unnecessary costs. Lastly, five respondents did not provide a clear stance on the matter. One of these respondents emphasized that the current proposal is not technically feasible, therefore making a costbenefit analysis impossible at this time. While they acknowledged the benefits, they also highlighted significant additional operational costs. Another respondent only emphasized that data quality is more important than latency for the success of the bond market CT. Meanwhile, one respondent acknowledged potential short-term benefits but express concerns about longterm economic viability and competition with existing market data streams. They shared the desire that the benefits will outweigh the operational costs borne by data contributors, but whether this will be the case is far from evident at this stage. They stressed that the costs of transmitting the data (both setup and run costs) will need to be borne by the data contributor. Lastly, one respondent highlighted the need for clear definitions and consideration of technical capacities, suggesting that stringent standards may reduce the value of data from smaller market operators. Q67: Do you think that the input and output data fields strike a balance between reporting
burden for data contributors/CTPs and benefits for CT users? Six respondents agreed that there is a balance. Of these respondents, one respondent mentioned that adopting an open-source solution for input and output data would minimize the

burden for data contributors while allowing easy access to data. Another respondent believed the input strikes the right balance but emphasize that book depth should align with the level of depth needed by the CTP to provide to the end customer. One respondent suggested that the format and structure of these fields should have been adapted appropriately for the protocols of collection and distribution to improve efficiency. Four respondents did not believe there are a balance between the burden and benefits. Three of them are concerned that requesting the full set of market data, including all post-trade transparency requirements under RTS 2, exceeds what is necessary for the CTP to operate effectively. This would increase costs across the value chain, impacting both contributing trading venues and the CTP itself, with these costs ultimately passed on to data users. They suggest providing only essential data to avoid high costs and energy-intensive data processing. For the equity CTP, they emphasized that only the first bid and offer should have been requested to avoid unnecessary data and costs. They did not support a direct link between RTS 1 and RTS 2 with the data input requirements for the CTP. They also expressed concerns about frequent adaptation requests for changes to RTS 2 and RTS 1 data, which are costly for the industry. They proposed to incorporate any changes into the actual CTP RTS and plan them well in advance to reduce unnecessary burdens. One respondent recommended that only BBO/L1 data is supplied to the CTP to avoid inefficiencies and high costs. They were also concerned about potential frequent change requests would impact trading and market data systems. Two respondents did not respond to the question directly, one of them highlighted issues with the current market data infrastructure and revenue sharing schemes. Six respondents agreed that there was a balance. Of these respondents, one respondent mentioned that adopting an open-source solution for input and output data would minimize the burden for data contributors while allowing easy access to data. Another respondent believed the input strikes the right balance but emphasize that book depth should align with the level of depth needed by the CTP to provide to the end customer. One respondent suggested that the format and structure of these fields should be adapted appropriately for the protocols of collection and distribution to improve efficiency. Four respondents did not believe there is a balance between the burden and benefits. Three of them were concerned that requesting the full set of market data, including all post-trade transparency requirements under RTS 2, exceeds what is necessary for the CTP to operate effectively. That would increase costs across the value chain, impacting both contributing trading venues and the CTP itself, with these costs ultimately passed on to data users. They suggested providing only essential data to avoid high costs and
energy-intensive data processing. For the equity CTP, they emphasized that only the first bid and offer should be requested to avoid unnecessary data and costs. They did not support a direct link between RTS 1 and RTS 2 with the data input requirements for the CTP. They also expressed concerns

about frequent adaptation requests for changes to RTS 2 and RTS 1 data, which are costly for the industry. they proposed incorporating any changes into the actual CTP RTS and planning them well in advance to reduce unnecessary burdens. One respondent recommended that only BBO/L1 data is supplied to the CTP to avoid inefficiencies and high costs. They were also concerned about potential frequent change requests impacting trading and market data systems. Two respondents did not respond to the question directly, one of them highlighted issues with the current market data infrastructure and revenue sharing schemes. Q68: Do you think that the proposed data quality requirements are sufficient to achieve the CT’s objectives without generating excessive compliance burdens? Please explain. The majority generally agreed that the proposed data quality requirements are mostly sufficient to achieve the CT’s objectives, without generating excessive compliance burden. The technical checks such as completeness and timeliness check are considered crucial for data quality. However a few respondents were concerned about unnecessary burden, especially nontechnical checks like erroneous trade identification. One respondent added that these checks should not only be for input data and suggested, for equities, including pre-trade data. Two of these respondents, mentioned that they do not agree with ESMA’s proposals regarding data quality measures and enforcement standards for input data, and highlighted that “CTP cannot be expected to enhance the quality of data provided in terms of specific content; this responsibility should rest with the data contributors, who have systems and controls in place to ensure data quality.” Three respondents strongly opposed the requirements, citing a lack of benchmarks and operational resilience issues. One respondent argued that it should not be the CTP’s responsibility to ensure data quality; instead, the obligation should be on the data contributors, given they already have systems for these kinds of controls in place. Another respondent suggested that ESMA’s quality requirements should be revised and expressed concerns that ESMA is mixing the roles of APA and CTP, which could introduce unnecessary costs and confusion. It was also suggested that Article 10(5) (a) and (b) of the draft RTS should be deleted. Similarly, they did not considered Article 10(9) of the draft RTS to be relevant for the CTP.

Questions from ESMA’s third Consultation Package 11:
Q55 (CP3): Do you agree with the proposal for the Data related to the status of individual financial instruments? If not, please explain. Several technical comments were made in this context. Few respondents noted that venues today generally publish the trading phase of individual instruments, which is complementary to the proposed halted and suspended status. Therefore, it was recommended that the trading phase and “outage” status should be added to the instrument status. Two respondents suggested using the instrument’s trading phase of MMT’s ‘trading mode’ (MMT level 2) for this purpose, being already widely adopted. In the same context, one respondent had doubts on the concept of tracking status at the level of “trading systems” claiming that, as introduced in the CP, it will have practical value as it may not be meaningful to report system-level data separately from instrument-level data. Therefore, it questioned whether setting the tracking status at the level of trading system is more appropriate than setting it per symbol. In this light, it was recommended that ESMA reconsiders the utility of the trading system level in the regulatory data structure, as it may introduce unnecessary complexity without adding clear value. Several respondents considered that using solely the International Securities Identification Number (ISIN) and Trading Venue is insufficient to uniquely identify a financial instrument. This combination can be ambiguous, as trading venues may list a single ISIN with multiple currencies. Furthermore, multiple respondents also claimed that MTFs often have secondary listings for ISINs that involve not only different currencies but also multiple trading venues. Therefore, incorporating a Primary Market Identifier Code (MIC) alongside the ISIN and currency would provide a more robust and reliable method for identifying securities within a trading venue. Several stakeholders believed that the concept of an "Instrument status end date and time" does not accurately reflect the practices of trading venues. Typically, a message is disseminated when a security is reactivated, not when it is halted or suspended. To streamline the process and avoid unnecessary complexity, they suggested introducing an "Active" Instrument status. This would simplify the reporting process, especially during incidents where the final status may be uncertain at the time of the initial message. Similarly, one respondent suggested that a simple “Closed” message should also be added to indicate that trading has ceased, but without any extraneous reasons. 11 Third Consultation Package (CP3).

A coalition of trading venues asked ESMA to allow at least 12 -18 months for more complex necessary adaptions. Hence, for the same reasons there may be merit to allow the CTP to start with the existing data feeds available today, both for bonds and for equities. Q56 (CP3): Do you agree with the proposal for the data related to the status of status of systems matching orders? Would you consider that other identifiers of the trading system type should be used? Please explain. In general respondents were supportive of the proposal. However, several technical comments were made. Several respondents recommended the usage of MMT for system status, specifically the identification of trading phases. It was noted that, a CLOB can include both continuous auction and periodic auction trading. It therefore does not map directly on to RTS 1 Annex 1 Table 1. Changing the reference to continuous auction trading would solve this.It was also pointed out that in certain cases, the combination of segment MIC and trading system type may not uniquely identify a venue's trading behaviour. For example, a single venue might operate multiple market models (such as a lit order book, a dark order book, and a conditional order model) under the same MIC. These models may fall under the same trading system type but exhibit different characteristics. Therefore, it was stressed the importance of adding granularity to fully capture the range of trading behaviours occurring within a single trading venue. Moreover, it was identified that the regulatory data fields in Annex III Table 4 of the consultation assume that all instruments on a particular trading system are in the same trading phase. It is possible for trading venues to have different timings for their different phases within a specific trading system. Therefore, data contributors should share an additional identifier in order to ensure that, at the instrument level, the correct trading phase is available. One respondent claimed that it would be far simpler if the trading phase were to be integrated into the instrument Annex III Table 3 ‘Regulatory data specific to an instrument’. This would ensure perfect alignment with the trading systems and would also yield the additional benefit of allowing the CTP to correctly manage the EBBO representation (single price and size) when an instrument is in an auction phase. One respondent indicated that the proposed system status field appears to combine status at the system level with instrument-level trading phases while it is important to clearly differentiate system-wide statuses, such as operational outages, from trading phases that apply to individual instruments. The same respondent and another one also indicated that the outages typically occur in stages, such as discovery, analysis, and resolution, each of which could affect market operations differently. On this, it was recommended that the system status field be revised to reflect this more nuanced view of operational
disruptions. One of them suggested including the option of "partial outage" to provide a more granular indication of the disruption.

Other respondents, like the case of the data at instrument level, believed that field 4 (System Status end date and time) is redundant. A new message indicating the start of the subsequent trading phase should be sufficient to replace the previous status. This approach would avoid the potential need for two separate messages—one to terminate the old status and another to initiate the new one. One respondent claimed that trading venues, particularly MTFs, often admit both RTS 1 and RTS 2 instruments to trading under the same segment MIC covering a wide range of asset classes (e.g. Bonds, OTC derivatives, FX derivatives, Shares, ETFs, ETCs/ETNs, SFPs, etc.), which may sit on different technology stacks. In their view, this means that each system within the trading venue may have a different status and also any interruption in a given asset class may be entirely independent from another asset class. Therefore, it would be better for trading venues to manage communications about the availability of financial instruments and system statuses with their participants directly. An association of trading venues indicated that the concept of “system trading status” is overly precise while not covering all cases neither at such detail level. Thus, they suggested maintaining some degree of flexibility to ensure that the approach taken is appropriate considering the specific market organisation of certain data providers. Furthermore, they claimed that the exchange trading phases are hardly ever tied to the trading system itself, but rather are distinct per instrument identified by MIC, ISIN and currency. Trading phases per instrument may vary independently from the trading system. The only system trading status to be expected per trading system is one informing about the trading system being closed. Finally, they also recommended abstaining from requesting information on outages via trading venue data feeds. Q57 (CP3): Do you agree that the pre-trade data to the CTP should be that included in
Table 1b in section 4.1.3.1 except for fields 8 and 9? Please explain.
Regarding the input table, respondents generally agreed. However, several technical comments were made. One respondent recommended a more proportional approach and suggested differentiating between fully electronic systems, where microsecond precision is generally manageable, and systems involving manual processes (e.g., voice trading, high touch, block trades) stating that for manual workflows, such precision is impractical. Several respondents considered that field 8 (Quantity Currency) should be included in the input and output of the CTP in cases where instruments are traded in multiple quantities of different currencies. Several respondents considered that it is crucial to include the order entry timestamp to allow the CTP to reorder BBO based on the actual order time, mitigating issues related to network latency and “geographical disparities”.

Regarding the output table, several respondents requested clarifications on how the CTP should handle situations where different markets operate different ‘trading system types’ or in different trading phases at the same time. Furthermore, several respondents noted that Section 8.2.2 of the consultation paper contained examples of both matched and unmatched periodic auctions (Figures 15 and 16 respectively) while there is no requirement for pre-trade transparency for mismatched order booked under periodic auction trading models under RTS 1. Few respondents, as done in relation to the input data, highlighted the importance of the proper sequencing of data. More specifically, they requested that, to ensure that the CTP delivers accurate and organised information, the output data should be sequenced based on execution timestamps. They claimed that this would ensure that market participants receive a precise and transparent view of liquidity, free from the distortions caused by network latency or geographical disparities. One respondent, also suggested to include the following drafting: “(i)
Table 5 of Annex III by reference to each order for pre-trade data; to be re-ordered for the
purpose of dissemination by the CTP by their entry date and time”.
In the context of the timestamps, one respondent considered that publishing the Entry Date and Time (table 5 - Field 1) may be unnecessary. Indeed, once aggregated, the BBO typically contains orders from various trading venues, making the granularity of individual timestamps less relevant. Including this field can increase message size, potentially impacting processing times and storage requirements. Another respondent considered it beneficial that the “entry date and time” refers to the order entry timestamp. Another respondent instead proposed to change the field #1 – “Entry date and time” with “Update date and time” for any pre-trade events. Several respondents considered that the currency uniquely identify an instrument and that one single currency for the best bid and the best offer should be provided. Furthermore, several respondents argued to not consolidate data across different currencies. Few respondents also advocated for the introduction of the "Place of Listing" in the output data as crucial to uniquely identify instruments, especially those trading across multiple venues or in different currencies. One respondent noted that as market conditions and trading phases change there should be "Reset" messages incorporated to handle transitions between phases, such as moving from continuous trading to an auction phase: this would help to ensure the accurate reflection of trading activities and improve the usability of CT data. Few respondents noted that Field 6 [EBBO timestamp] needs to be properly defined and proposed to set this as the date/time that the CTP publishes this EBBO record. One respondent also identified that this field is not required by Level 1.

One respondent also noted that Figure 15 suggests that no aggregation of volume at the same price of two separate auctions running in parallel is required. However, in practice, several periodic auctions can run in parallel. It would be useful for ESMA to clarify this point while at the same time providing different alternatives on how to aggregate the auction price information in sequential order. Q58 (CP3): Do you agree with the proposal for the output table? Please explain. Several respondents requested clarifications on how the CTP should handle situations where different markets operate different ‘trading system types’ or in different trading phases at the same time. Furthermore, several respondents noted that Section 8.2.2 of the consultation paper contained examples of both matched and unmatched periodic auctions (Figures 15 and 16 respectively) while there is no requirement for pre-trade transparency for mismatched order booked under periodic auction trading models under RTS 1. Few respondents, as done in relation to the input data, highlighted the importance of the proper sequencing of data. More specifically, they requested that, to ensure that the CTP delivers accurate and organised information, the output data should be sequenced based on execution timestamps. They claimed that this would ensure that market participants receive a precise and transparent view of liquidity, free from the distortions caused by network latency or geographical disparities. One respondent, also suggested to include the following drafting : “(i)
Table 5 of Annex III by reference to each order for pre-trade data; to be re-ordered for the
purpose of dissemination by the CTP by their entry date and time” Another respondent considered it beneficial that the “entry date and time” refers to the order entry timestamp. Several respondents considered that the currency uniquely identify and instrument and that one single currency for the best bid and the best offer should be provided. Furthermore, several respondents argued to not consolidated data across different currencies. Few respondents also advocated for the introduction of the "Place of Listing" in the output data as crucial to uniquely identify instruments, especially those trading across multiple venues or in different currencies .One respondent noted that as market conditions and trading phases change there should be "Reset" messages incorporated to handle transitions between phases, such as moving from continuous trading to an auction phase: this would help to ensure the accurate reflection of trading activities and improve the usability of CT data. Another respondent instead proposed to change the field #1 – “Entry date and time” with “Update date and time” for any pre-trade events. Few respondents noted that Field 6 [EBBO timestamp] is not properly defined and proposed to set this as the date/time that the CTP publishes this EBBO record. An association of trading

venues highly appreciate that field 7 (most relevant market in terms of liquidity) will have to be included by the CTP and is not based on the input data. Q59 (CP3): Do you agree with the proposal for the input and output tables for the posttrade equity CTP? Please explain. Respondent in general agreed with ESMA’s proposal for the input and output table. However, several remarks were made. Two respondents suggested that CTPs should be permitted to add additional output fields (beyond those covered in this RTS) at the end of their messages for optional consumption to provide any ‘value added’ features they wish. One coalition of trading venues see merit in adding selected further data fields for APA data to the input data: alert flags, in case of unclear data quality of a transaction, cancel, amend, confirm on a similar note. At the same time, they also considered that this is important to inform the market about unclear data quality of OTC data while not holding back any information. Furthermore, there may be merit, in considering a similar “Alert flag” for the CTP as well, in case the CTP would detect any shortcomings in the context of contributed data or affecting the CTPs ability to provide a 100% secure EBBO. The same coalition of trading venues, suggested to add the timestamps for data reception and dissemination by the CTP, compared to what has been defined on L1. This would allow the CTP to perform data quality checks. Last but not least, it was noted that the consultation lacks detail on how corrections to previously reported data will be handled by the CTP. In practice, trading venues and APAs frequently make amendments or cancellations to previously published data. Clear guidelines are needed on how the CTP will process and disseminate such corrections to ensure data accuracy and consistency over time (both in real-time and historical data corrections).
7.1.2 RTS on the revenue redistribution scheme
Q17: On the basis of the issue presented in the above paragraph, what do you think is the right approach to identify a trading venue and group? How could a trading venue and a group be identified? How should the links with investment firms be determined? The views were mixed between the use of the segment MIC and the proposal made by ESMA, i.e. the use of the operating MIC for criterion 1 and the segment MIC for criteria 2 and 3. Only one respondent preferred the use of the operating MIC. Q18: Do you agree with the above assessment? If not, please explain. One respondent noted that regarding criterion 1 “The annual trading volume of shares in the Union” is not information available to the CTP as it will not receive the data from the opted-out

countries. Therefore, ESMA should clarify whether the basis for determining whether a venue is a Small Trading Venue is the annual trading volume of shares that are reported to the CTP. Another respondent asked ESMA to clarify the title and application of Table 4 “Availability of the information to the CTP” to explicitly state that it concerns cash equities only. Others made points less relevant to this question and more for other parts of the CP:
Several respondents requested ESMA to clearly define what operations are eligible under the concept of ‘initial admission to trading’ to duly recognise primary markets. The respondents suggested that ESMA includes a new Article under the RTS on the revenue distribution scheme specifying the eligible transactions and make amendments to RTS 23 to identify those. Another respondent requested ESMA to add the appropriate asset class as an identifier to ESMA’s list of potential data contributors. With regard to criterion 1 (small trading venue), one respondent asked ESMA to clarify the definition and handling of new trading venues. Will the CTP be obliged to take input data from all new trading venues immediately after launch? How will the revenue allocation model be calculated? i.e 1st January after launch/immediately on day of launch/1 calendar year after launch etc? What mechanisms should be implemented to mitigate the potential proliferation of new trading venues driven uniquely by CT data revenues? With regard to criterion 2 (young instruments), one respondent suggested to incorporate ADVT bands (as currently calculated by ESMA) to avoid that very large IPO’s or privatisations will dilute the small and mid-cap young market allocation. With regard to criterion 3 (pre-trade transparent volume), one respondent asked for clarification regarding the eligibility of frequent batch auctions for revenue redistribution. If those would be eligible a differentiation should be made between price-forming trades and trades matched at mid-point. Two respondents explicitly rejected the current design of the revenue redistribution scheme altogether as it would reinforcing improper data ownership and represent an over-engineered solution. Q19: For the identification of the venue of first admission to trading, do you prefer option (A) use of FIRDS, option (B) the CTP collects the relevant information itself? Please explain and provide any alternative option you consider more appropriate. Most respondents preferred the use of FIRDS for the identification of the TV with first admission to trading. Only one respondent preferred the use of the CTP data and another one advocated for a combination of the two.

Q20: Do you agree that a flag indicating that the transaction was subject to an LIS waiver should be information to be sent to (but not published by) the CTP? If not, please explain. The majority of respondents agreed with the introduction of the new flag. Few respondents advocated for the publication of the information in the post-trade transparency reports and not leave it only to the CTP for the purpose of the revenue distribution scheme. Q21: Could the determination of the pre-trade volume be done differently by the CTP (e.g. proxy this volume with the pre-trade data received) but at the same time sufficiently accurately? If yes, please explain. Most respondents agreed with ESMA’s proposal to rely on post-trade data containing relevant transparency flags to determine appropriate pre-trade transparent trading volumes, and saw it as the only reliable approach. One respondent suggest that volumes considered as executed on pre-trade transparent venues that do not result from the interactions of pre-trade transparent buy- and sell-orders or indications of interests posted on the trading venues on which the volumes are finally executed, but that result for instance from the execution of orders at a price pegged on the prices formed on another venue should be excluded from the computation of eligible volumes. These include volumes executed on periodic auction systems at prices pegged on an external venue. The respondent thus suggested to review the definition of trading systems in RTS 1. Two respondents suggested to estimate pre-trade transparent volume based on historical and real-time market data. Q22: Do you agree that the methodology to distribute the revenues should require the conversion of the values into percentages? If not, please explain. In general, respondents agreed with the conversion into percentages. One disagreeing respondent claimed that the conversion into percentages is flawed as observed in the US market system. In their view percentage alone does not accurately reflect the value contributed by different entities, and a more dynamic model that considers the value of the information using the Market Model Typology (MMT) would be more appropriate. Another respondent suggested the use of a different approach, such as a multi-factor mode, with factor analysis or regression against which the foreseen incentives can be optimised. Q23: Do you agree with the transactions to include and exclude for the determination of the volume for criteria #1 and #2? If not, please explain.

One respondent suggested to review the use cases of the following flags to validate whether they are genuinely price forming transactions available to the wider market BENC, PORT, SDIV, LRGS, SIZE. One respondent argued that subtracting cancelled trades will likely be managed differently (as the CTP would have created a link between the trade and its cancellation in its system already, meaning that a separate step to subtract cancelled trades will not be required) and requested ESMA to provide clarification if such an approach is permissible. One respondent proposed a mechanism to review inclusions and exclusions after a reasonable period of operation of the CT (e.g. 6months) to verify this has been the appropriate approach. Several respondents argued that transactions flagged as PRIC, RFPT, NLIQ, OILQ and NTLS, should also be excluded from the calculation of trading volumes for the purpose of criteria 1 and 2, to appropriately recognise and reward those venues that contribute to price formation through pre-trade transparency. In addition, the below should also be excluded from criterion 3 computation, in contrast to ESMA’s proposal:
− BENC and PORT transactions, as these are not pre-trade transparent. − SIZE and ILQD transactions, as these are not executed on a trading venue. − TNCP & RPRI transactions (not mentioned in the CP), as these are not executed on a venue. One respondent disagreed with ESMA proposal as many of the flags were more relevant to the non-equity CT than the equity CT, and there may be flagging issues and increase administrative burden. Another respondent disagreed, arguing that the criteria should include more granular data about the types of transactions, especially distinguishing between those that provide real market value and those that do not. Q24: What would be your view on the frequency of redistribution? Which issues do you foresee in the redistribution process? How could those issues be solved? Please explain. In general, respondents agreed that revenue should be redistributed at least annually. Many respondents advocated for a more frequent frequency of redistribution, either quarterly or monthly, with the possibility to re-balance the revenue allocation with adjustments at year end. Q25: Do you agree with the proposed timeline for the update of the list of data contributors and the identified issues? How could the issues be solved? Please explain.

One respondent suggests that all new trading venues should be required to contribute data to the CT from launch but should only be eligible to receive revenues from the CT after at least 1 year of operation to ensure that new business models do not evolve whereby new trading venues are created purely to exploit CT revenue allocation. Several respondents suggest that the list of those obliged to contribute to the CT from the beginning should be published annually alongside new entrants, SME growth markets, and small exchanges that have opted-in or out of the CT. On respondent indicated that rapid increases in market shares of new entrants or change of ownership could lead to some disruption and changes in what is generally a slowly evolving market share distribution. The respondent thus suggests following a quarterly approach for revenue redistribution (and proportional calculations in case the contributor lists changed within a calendar year. The same respondent considers that there should be a mechanism to avoid excessive fluctuations in the list of mandatory contributors to the CTP, as this would ultimately be detrimental for users. Such mechanism could foresee that once a venue moves to mandatory contribution, it remains in this category, unless there is a continuous breach of the 1% threshold for a period to be determined (e.g. two years). Two respondents believed it to be inappropriate to establish a regime for new trading venues starting operations which distinguishes between (i) those part of a larger group and (ii) others, and request further explanation from ESMA. One respondent enquired further clarity on the definition of “market operator”, i.e. if it would follow an operating or segment MIC logic. Further the respondent pointed out that Article 22a alludes only to shares (and not ETFs). Moreover, the respondent recommended to involve NCAs for the verification of the “close links” criterion. Q26: What would be your view on the issues for the first year of operations of the CTP? How could those issues be solved? Please explain. Respondents advocated for several clarifications from ESMA, namely:
− Will ESMA mandate that TVs and APAs start their API implementation work at T0 once a CTP is selected, or after T1 once the CTP is authorised? − Will ESMA impose a maximum time for TVs and APAs to complete their implementation work, consisting in having the data correctly delivered to the CTP including any QA and UAT time required to resolve any implementation issues? − Will ESMA impose a maximum time for the CTP to complete its implementation work, consisting in having the data correctly ingested by the relevant number of TVs and

APAs (stage 1) and delivered to test data users and including any QA and UAT time required to resolve any implementation issues (stage 2)? − Will ESMA consider or require any extra time from when the CTP declares its work complete and the launch date, for example for a final sign-off by ESMA itself? − Will ESMA unambiguously clarify at which time in the timeline does the fixed 5-year term start ticking from? Some respondents also considered it would be extremely challenging for both the CTP and the data contributors to:
− develop and test the data feeds in the protocol chosen by ESMA for the reception of data by the CTP if this were to be changed; − establish and test the connections; − implement and test the methods foreseen for error corrections, if any; − for the CTP, to process the data from 100% of the data sources in the first year of CT operation; and − chose the level of revenue distribution at the end of the first year of operation (even if partial). Q27: Do you agree with ESMA preferred proposal to set the weights of the revenue redistribution scheme to 4.5, 4.0 and 1.5 for the small trading venue criterion, the young instruments criterion and the transparent instruments criterion, respectively? If not, please explain. Respondents generally agreed. However, some observations were made, namely:
One respondent flagged that:
− Smaller markets: the ‘bonus’ of improved revenue allocation for small markets should be accompanied with certain obligations of connectivity. Only those small markets that have decided to opt in to providing data to the CTP within two years of the official launch should be eligible for any ‘improved’ weighting scheme. − Young Instruments. It does not appear that the use case of disproportionally large IPOs such as Government privatisations has been taken into consideration with these weightings. This could have a negative reallocation impact on small and mid-cap young securities which we do not believe is the desired outcome. ADVT bands should be

applied to young securities with much greater weightings being applied to the lowest ADVT bands. − Transparent Markets. Further reflection is required for auctions. Should open and closing auctions have a greater weighting than continuous trading? Should there be a weighting for frequent batch auctions? − Provided the weighting for "young instruments" is applied to only the traded notional of those recently admitted “young instruments”, this seems reasonable (i.e. a trading venue with 1,000 securities, 100 of which having had an IPO within the last 5 years, should receive a multiple of x1.5 for 900 of the securities (assuming trading took place on a pre-trade transparent venue) and x4 for the 100 young instruments). This should be applied on a monthly basis (i.e. if the 60th month since the IPO was in January, and ESMA proposes a revenue distribution on an annual basis, the x4 weighting would only be applied to the traded notional for that instrument in the January of that year, not the remaining 11 months when it ceased being a young instrument.) Several respondents considered that:
− ESMA should conduct a review of the weights after an initial period of 12 or 18 months, following the receipt of data from the CTP, the idea being to assess whether adverse consequences have materialised. The calibration can be done using a model that considers the sensitivities of the different stakeholders to changes in the weights. After the initial period of 12 or 18 months, there should be enough data to build such a model. − the revenue distribution model needed to be accompanied by an ad-hoc definition of Reasonable Commercial Basis requirements applicable to the CT in order for the whole economic model to work. Two respondents disagreed with the proposal. One respondent claimed that the revenue distribution scheme codified into RTS is flawed and far too rigid to work in practice. The colegislators should not have gone this far in prescribing this model this way and it lacks alignment with the value of data. Furthermore, it was claimed that the weighting for small trading venues should be significantly higher than the proposed 4.5 times because even with a factor of 100x, smaller trading venues would still get a too small revenue share to warrant posting to the CTP. The costs of reporting are largely fixed, while the revenues are proposed to be related to trading. Additionally, trading venues for large cap listings will typically be old, mature organisations with monopoly positions, as opposed to SME trading venues with much fewer listings to cover the reporting costs. An alternative approach reaching the same goal is to exclude in whole or

partially the trading volume in blue chip companies from the calculated total annual trading volume which the revenue distribution is based on. Last but not least, it was proposed, to further incentivize participation, that small trading venues that choose to opt-in should be guaranteed a minimum revenue share of EUR 2 million annually from the CTP. This guarantee would provide a clear commercial benefit for small trading venues, making the participation in the CTP economically viable despite their lower market data margins in comparison to larger exchanges. Q28: Would you consider appropriate that the weight (percentages) sum to 10 (100%)? If not, please explain and provide your alternative proposal for the weights (percentages). Most respondents consider ESMA’s proposal adequate. Some respondents recommend foreseeing a review of the weights after an initial period of 12 or 18 months. Q29: Do you agree with the proposed (i) frequency of the determination of the weights (ii) timing of determination of the weights (iii) timing of application of the weights? If not, please explain. Respondents generally agreed. However, they believed that there may be merit in considering if this frequency could be reduced in the second or third year of operations, with part of the revenues being shared on a quarterly basis, and a final accounting taking place annually. This would acknowledge the need to fund operations of smaller trading venues, where costs are incurred during the year too. However, two respondents believed in a more ambitious model given that trading volumes can fluctuate dependent on a number of factors. More specifically, the weightings should be determined more frequently than annual, and would suggest quarterly would be appropriate, in line with the revenue distribution frequency. Q30: Do you agree with the proposed text? Have you identified any missing points or issues? Most of the respondents agreed with the proposed text and did not provide additional or alternative suggestions. A minority of respondents however disagreed with the design and/or the concept of revenue distribution. A few respondents proposed that the revenue redistribution is extended to all data contributors, including APAs. Another respondent suggested that the volume contributed by APAs is excluded from in the basis for revenue calculation as they are not included in the revenue redistribution.

An association representing trading venues and some of its members advocated for a fundamental overhaul of the approach to the design of the CTP, including:
− Tailored requirements on the provision of data on a reasonable commercial basis (RCB), allowing the CTP to take into account the costs incurred by data contributors when producing the data provided to the CT for free; − Explicit prohibition for the CTP to provide services beyond the ones foreseen in MiFIR, or alternatively mandating that such value-added services are provided by a separate legal entity, with additional licensing agreements, and that the revenue from these services are also redistributed to data contributors. Q31: Do you agree with ESMA’s proposal on the criteria for a potential suspension of redistribution in case of serious and repeated breach by the CTP? If not, which alternative or/and additional criteria would you consider relevant? Most of the respondents agreed with the proposed criteria and did not provide additional or alternative suggestions. One respondent suggested that suspensions do not take place during a two-year transitory period, to test the criteria and to detect potential failures due to the outsourced third-party, also in light of the parallel implementation of DORA. There was general support for criteria #3 (exceptional circumstances) and #4 (quality of transmission protocol). A few respondents however disagreed on the definition of other criteria:
− Criterion #1 (timeliness): most trading venues considered that the criterion is too strict with the proposed definition of ‘as close to real time as technically possible’, some trading venues called for more leniency, e.g. a threshold higher than 3 transactions and/or for suspension only after 6 consecutive working days. One respondent deemed the 10% threshold too lenient. − Criterion #2 (quality, format and substance of data): some trading venues asked that suspensions only apply to ‘actual’ erroneous data (rather than ‘potentially’ erroneous data) and called for more leniency with suspension applying only after 6 consecutive working days. One respondent deemed the 10% threshold too lenient. − Criterion #5 (clock synchronisation): one respondent pointed to the challenges to monitor the exact synchronisation of clocks beyond the yearly review required from data contributors in article 7 of RTS 25. An association representing trading venues and some of its members advocated for an alternative approach to the suspension of revenue redistribution, which would include:

− calculating penalties and/or suspension depending on the volumes of erroneous feeds, based on an extra weight according to the seriousness and scale of the breach − establishing a Review Committee including representatives from the CTP, ESMA and the data contributor in breach, with longer timeframes for dialogue and assessment − empowering ESMA (rather than the CTP) to decide on the penalties/suspension, and to act as ultimate recourse. Q32: Do you agree with ESMA’s proposal on the procedure for the suspension and the resumption of redistribution? If not, which alternative approach would you consider suitable? One respondent suggested that the CTP should regularly publish reports on the data quality of data contributors to increase public pressure and that both the mandatory (equity and ETF CTP) and voluntary (Bond CTP) revenue distribution should be suspended upon a breach. Several respondents suggested to implement revenue redistribution in a lagged manner (i.e. at the end of each distribution window), and with a sufficient time gap (i.e. min 2 weeks), such that the definite outcome of any potential breach is established before the actual payment date, and no reimbursements necessary. Such a design would allow to discuss any potential breaches with the data contributor and help to avoid additional administration and complexity in undoing suspensions and balancing payments. Several respondents suggested to implement an ad-hoc sanctions regime for data contributors outside the revenue redistribution scheme, which could rely on the same data quality verification mechanism. Several respondents proposed to establish a Review Committee which should consist of representatives from the CTP and ESMA, as well as from the data contributor with whom an issue has been detected. It would be responsible for thoroughly assessing and discussing data quality issues, exploring relevant mitigations/solutions, and providing a minimum three-week timeframe for the data contributor to demonstrate non-breach. If required, the Committee should also define an appropriate timeframe for resolution, with a minimum of three weeks. Any penalties or suspension of remuneration should only be determined by ESMA after the data contributor has failed to correct the issue within the specified timeframe. The same respondents further suggested that the volumes of erroneous feeds should be calculated based on an extra weight according to the scale of the breach. Moreover, the same respondents believed that draft Article 8 should include a provision allowing the data contributor subject to the penalties and suspensions to seek recourse from ESMA.

Q33: Do you agree with ESMA’s proposal on the timing of the procedure for the suspension and the resumption of redistribution? If not, which alternative approach would you consider suitable? Most respondents, agreed with the proposed time frame while a few respondents recommended a minimum of 3 weeks to discuss potential data breached in a dedicated review committee and another 3 weeks to resolve potential issues. Q34: Do you agree with ESMA’s proposal regarding a one-week timeframe for data contributors to furnish evidence of non-breaches? If you disagree, could you suggest an alternative approach that you find appropriate? Half of the respondents agreed with the proposed one-week window or did not provide additional or alternative suggestions. One disagreeing respondent suggested that the one-week period can be extended by the CTP. The rest of disagreeing respondents, mostly data contributors, were in favour of suspending the redistribution only as the last step after a dialogue between CTP and data contributors. Q35: Do you agree with ESMA’s expectation on the notification to be made by the CTP to the competent authority of the data contributor once a suspension has been triggered? Most respondents agreed with ESMA’s proposal and did not provide additional or alternative suggestions. One respondent was of the view that only the final decision on the suspension should be notified to the competent authority of the data contributor, while another respondent suggested that the competent authority of the data contributor is informed of the initial suspension and its duration; that the data contributor has provided evidence of no breach and the CTP will reassess its decision or that no evidence has been provided and the suspension will be sustained; and of the outcome of the reassessment, if a reassessment is conducted. Q36: Do you agree with ESMA’s proposal on the approach to the retained revenue? In your view, which rate should apply to compound the interest on retained revenue? Most respondents agreed with ESMA’s proposal or and did not provide additional or alternative suggestions. One respondent suggested to specify the approach to currencies other than the euro, while another respondent suggested to use Euribor 360 as reference rate.

Some disagreeing respondents expressed concerns that the approach may not be suitable if the frequency of redistribution is too low (e.g. yearly). Another respondent posited that a systematic redistribution to other data contributors after the end of the revenue redistribution calculation period would allow to avoid the complexity of interest payment on retained revenue. Other respondents asked that the revenue redistribution mechanism is extended to other data contributors, and is complemented with ad hoc sanctions for repeated breaches, financial penalties and a ‘blacklist’ of data contributors repeatedly in breach. Q69: Which costs do you expect to implement the revenue distribution scheme? Please differentiate between one-off and on-going costs, between fixed and variable costs as well as between direct and indirect costs. Respondents suggested the revenue distribution to become effective only once the CTP has achieved cost recovery. A clear methodology for calculating revenues (profits) would have to be defined in advance and auditors may be required. Most respondents did not expect significant costs directly originating from the set up or ongoing management of the revenue scheme. One-off costs would relate to implementing the required reporting mechanisms or preliminary legal work and running costs would relate to the maintenance of data operations, monitoring, finance, control functions and auditors. Q70: Which costs do you expect to implement the suspension and the resumption of the revenue distribution scheme? Please differentiate between one-off and on-going costs, between fixed and variable costs as well as between direct and indirect costs. Respondents explained that those costs would be dependent on the envisaged design (including frequency of suspensions and distributions) of the revenue redistribution scheme. No concrete costs were mentioned.
7.1.3 RTS on the synchronisation of business clocks
Q37: Do you agree with the proposed approach on synchronisation to reference time? If not, please explain. Most respondents expressed their agreement with the proposed approach on synchronisation to reference time. However, one respondent, a potential CTP candidate, pointed out that at this stage, clock synchronisation is not offered by the leading cloud providers at the PTP (Precision Time Protocol) accuracy and SLA levels proposed by ESMA. They suggested implementing a more lenient solution, such as cloud-based NTP, during the first five years.

This would allow for a re-evaluation of the opportunity for more stringent requirements after this initial period if a tangible need justifies it. Additionally, clock synchronisation is more critical for pre-trade transparency than for posttrade, and its granularity is more relevant for equities and ETFs than for bonds. Smaller venues would be particularly affected by more expensive solutions. Therefore, they suggested different synchronisation rules for the various use cases. Q38: Do you support a timestamp granularity of 0.1 microseconds for operators of trading venues whose gateway-to-gateway latency is smaller than 1 millisecond? If not, please explain. Would you argue for an even smaller granularity? If yes, please explain. The feedback on the proposed timestamp granularity of 0.1 microseconds for operators of trading venues with gateway-to-gateway latency under 1 millisecond was mixed, with half of respondents opposing the proposal, including several trading venues representatives. These respondents raised concerns about the potential costs and technical burdens associated with upgrading their systems to accommodate such fine-grained timestamps. They argued that this level of granularity might not provide sufficient regulatory or competitive advantages to justify the required investments. Indeed, two events taking place within one microsecond in two different trading venues are un-distinguishable from a CTP perspective. Additionally, one respondent advocated for different synchronisation rules for asset classes, particularly bonds, to avoid unnecessary expenses. In contrast, the remaining respondents supported the proposed 0.1 microsecond granularity, generally advising against smaller granularity. They highlighted recent technological improvements that could accommodate this change and pointed out that a more granular timestamp could improve the accuracy of ordering in the European order book. One respondent advocated for a timestamp granularity of 0.1 microseconds to apply only to cash equities and ETFs, as this level of precision would be inappropriate for non-equities. A general observation from both sides was the importance of accurate event sequencing. This becomes crucial when multiple events occur within the same microsecond on the same instrument, and trading venues must be able to establish a sequencing policy to differentiate them effectively. Q39: Do you support the proposed approach on the level of accuracy for trading venue members, participants or users? If not, please explain. The majority of respondents supported the proposed approach regarding the level of accuracy for trading venue members, participants, or users. However, those who opposed expressed concerns that different granularity and latency levels would make it impossible to use timestamped data to prove best execution. They also noted that while a displayed precision level of 1µs is technically possible, the actual observed precision will likely be closer to the

millisecond. Additionally, for the bond tape, any timestamp granularity exceeding what is already in use at bond trading venues and Approved Publication Arrangements is seen as redundant, irrespective of how users are classified. Q40: Do you agree with the proposed approach on traceability to UTC? If not, please explain. Most respondents supported the proposed approach on traceability to UTC, viewing it as essential for consistency and easier synchronisation due to UTC's established standard. However, one respondent (potential CTP candidate) opposed it, concerned that the requirement may raise costs for the bond tape without providing tangible benefits to consumers. Q41: Do you agree with the proposed accuracy levels for APAs, SIs, DPEs and CTPs? If not, please explain. Most respondents welcomed the inclusion of CTPs alongside trading venues, SIs, DPEs, and APAs in the clock synchronisation requirements, recognizing it as a key step toward improving data quality and simplifying market data consolidation. However, about half of the respondents disagreed with the proposed accuracy levels for these entities. Some respondents highlighted that for APAs, the maximum divergence from UTC should only apply to those using automated systems. They argued that manual processes, such as data entry through a web-GUI, should be treated differently due to the lack of automation. While many agreed that APAs should adhere to the same standards as trading venues, one respondent suggested a less stringent requirement for APAs—a 1-second standard for both maximum divergence from UTC and timestamp granularity. There was considerable support for aligning SI requirements with those of trading venues. Three respondents argued that SIs and DPEs should follow similar accuracy standards, particularly when using low-latency gateways, given their comparable business models. This alignment, they suggested, would prevent SIs from gaining an unfair competitive advantage. Conversely, three respondents disagreed, arguing that SIs should not be treated the same as trading venues due to technical and operational differences. They pointed out that SIs often operate with a fundamentally different structure, involving manual processes, and that imposing trading venue-level granularity on them would create unnecessary costs, particularly for smaller participants. They emphasized that SIs do not operate with a gateway-to-gateway model similar to that of trading venues. Indeed, Article 22c (1) of MiFIR requires SIs (as well as APAs, CTPs, and DPEs) to synchronize their business clocks but does not mandate ESMA to treat SIs and trading venues as equivalent under regulatory technical standards. One of the respondents further suggested exempting smaller local SIs from these stringent requirements, applying them only to larger SIs contributing data to the consolidated tape. Additionally,

another respondent proposed an approach with different accuracy levels for equity and bond transactions. Regarding DPEs, respondents raised concerns that the proposed accuracy requirements were unjustified given their limited trading activities, arguing that the associated compliance costs would be burdensome, especially for smaller or medium-sized participants. One respondent proposed a less stringent requirement for DPEs in bond markets, suggesting a 1-second timestamp granularity instead of the proposed 1-millisecond standard for both maximum divergence from UTC and timestamp granularity. They noted that the proposed requirements for SIs and DPEs seemed to be modelled on (pre-trade) equity markets and were not necessary for bond markets. High accuracy standards come with significant costs, and respondents emphasized that these should not impede the broader CTP project of making data available at a low cost. Another respondent recommended including DPEs in the short gateway-to-gateway latency category when the investment firm also conducts SI activities. With regard to CTPs, some respondents did not endorse ESMA’s proposal, arguing that it precluded several cloud-based technologies that could deliver an acceptable solution at a lower cost. Another respondent suggested that the accuracy level for CTPs should be higher than that for APAs. Lastly, some respondents called for a harmonization of timestamp granularity across all market participants at the lowest practical level. While they acknowledged the balance between technological costs and the need for granularity, they recommended introducing a transition period for firms to gradually update their systems to meet the new standards. Q42: Do you think that more stringent requirements should be set for SIs compared to DPEs considering they have pre-trade transparency obligations? If not, please explain. Five respondents did not support introducing more stringent requirements for SIs compared to DPEs. They argued that firms functioning as both SIs and DPEs already use the same infrastructure and protocols. They also raised concerns that ESMA's approach does not account for the different trading activities performed by investment firms (e.g., voice trading). They recommended an alternative based on the activity/asset class instead. Furthermore, one of these respondents disagreed with this approach and suggested harmonizing the granularity of requirements across all firms playing a critical role in the market. On the other hand, five respondents supported stricter requirements for SIs compared to DPEs. They argued that SIs act as execution venues in equity markets with high trade frequencies and need stricter latency rules to prevent disadvantaging clients. In contrast, DPEs, which focus on post-trade reporting, should have less stringent requirements due to their different service nature.

7.1.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
Q43: Do you agree with the approach proposed by ESMA?
The general feedback was positive, with most respondents agreeing with the approach proposed by ESMA. Several respondents appreciated the harmonisation of rules across the EU, with APAs/ARMs being directly authorised by ESMA. Furthermore, they agreed with the separation of the RTS for the authorisation of APAs, ARMs, and CTPs, noting that it should benefit regulatory clarity and simplicity. A few respondents sought clarification on how the new authorisation provisions would apply to existing APAs and ARMs, particularly regarding the submission of additional information on ownership structure and internal controls. Q44: Do you agree to include new authorisation provisions on ownership structure and internal controls for APAs and ARMs? The general feedback from respondents was supportive of new authorisation provisions on ownership structure and internal controls for APAs and ARMs. Some of them, however, noted that compliance with the organisational requirements regime itself implied the set-up of internal controls and arrangements that should suffice for ensuring that the APAs/ARMs acted in line with the regulation, and notably advocated for more flexibility around internal audit planning. In this regard, a respondent advocated for clarifications on how these new requirements would apply to already authorised APAs and ARMs. Some additional remarks were presented by stakeholders. In relation to Article 6(3), letter (e) of the draft RTS, one respondent proposed to delete the reference to “Internal Audit Committee” since it was not a mandatory requirement to have one. Q45: Do you have any further comments or suggestions on the draft RTS? Please elaborate your answer. One respondent raised a potential timing issue with the application of both DORA and the current RTS 13 (i.e. pending the entry into force of the revised RTS 13) for common requirements such as the reporting of ICT incidents and business continuity. In light of that, it was suggested clarifying that DORA would supersede the sectoral legislation in the domain of digital operational resilience and outsourcing requirements in respect of services provided by ICT third-party service providers. In order to ensure consistency between RTS 13 and DORA, it was also proposed to align the wording of Article 9 of RTS 13 with DORA by replacing “critical function” with “critical or important function”.

Q46: Do you agree with the approach proposed by ESMA?
The general feedback was supportive of ESMA’s approach, and the majority of respondents supported the objective of aligning the CTP authorisation with the authorisation of other financial service providers in the EU. Some respondents believed there was merit in aligning the information on ownership in
Article 2 of the draft RTS with that applicable to service providers in the EU. Specifically, they
suggested that the threshold for disclosure of shareholders holding more than 5% of capital or voting rights should be aligned with the 10% threshold for investment firms seeking authorisation in the EU. A few respondents provided specific definitions for categories of data users, such as retail investors, academics, and civil society organisations. Q47: Do you foresee specific conflicts of interests that may arise between (i) CTP and data contributors and (ii) CTP and clients and users? The general feedback acknowledged potential conflicts of interest between CTPs and both, data contributors and clients/users. Several respondents explicitly pointed to conflicts of interest between the CTP and its clients. They mentioned that if the CTP's consortium members had existing commercial interests in market data, they might favour their own offerings over the CTP services. This could result in higher fees or restrictive licensing terms, disadvantaging certain users. To address this, they recommended strict governance policies and transparent pricing to ensure fairness and accessibility for all clients. A few respondents also expressed concerns about the CTP offering trading venue and APA services via the same legal entity, suggesting that ESMA should prohibit such practices. Q48: What other elements, if any, should be included in the RTS on authorisation of CTPs? One respondent highlighted the necessity of including stakeholder representation in the CTP’s governance structure to ensure meaningful discussions and valuable recommendations. Another respondent pointed out that it would have been beneficial for ESMA to define clear conditions for users to benefit from the CT free of charge, considering the potential impact that a lack of clarity might leave. Q49: Do you have any further comments or suggestions on the draft RTS? Please elaborate your answer.

Respondent emphasised the importance of transparency in the selection process of the CTPs, suggesting that ESMA should disclosed how decisions are made, including the history and minutes of bilateral meetings with CTP applicants. A respondent pointed out that the draft RTS on CTP authorisation should clarify which “state” is relevant and which factors ESMA considered to be crucial (e.g. nationality/residency of the individual/relevant times in cases of relocations). Furthermore, the same respondent suggested referring to “states” and not “member states”, as this could otherwise be interpreted that only individuals with a European nationality or residency are required to include a criminal record in the application process.

7.1.5 Feedback from the DEG
The full reports from the DEG are provided at the following link.

7.2 Annex II – Cost-Benefit Analysis
7.2.1 RTS on input and output data of CTPs
This section provides a cost-benefit analysis (CBA) for the draft RTS on input and output data of CTPs. The draft RTS on input and output data of CTPs is mandated in MiFIR Review (Level 1), where
Article 22b creates a mandate for ESMA to develop reporting instructions and data quality
requirements for prospective CTPs and data contributors.
The stakeholders identified are: data contributors, future CTPs, CT users, ESMA and NCAs. The main costs that stakeholders will have to bear are expected to arise from both the Level 1 and Level 2 frameworks. These costs will mainly concern the setup of IT systems and infrastructure to meet the new requirements for data transmission to the CTP and data dissemination from the CTP. ESMA provides below an analysis of the costs and benefits that could arise from the provisions in the draft RTS on input and output data of CTPs. The cost-benefit analysis covers the following proposals made by ESMA on the (1) the minimum quality standards of protocols for the data transmission, (2) the required quality and substance of data for the operation of CTs (for the equity and bond CTs), and (3) data quality measures to be adopted by CTPs. Minimum requirements for the quality of transmission protocols:
Policy
Objective
Ensuring the robustness and reliability of CTP data Option 1 ESMA adopts a prescriptive approach by specifying detailed, mandatory requirements for transmission protocols tailored to the specific needs of each type of CTP (equity, bonds, derivatives), which restricts the choice to a limited number of solutions Option 2 ESMA adopts a less prescriptive approach by providing minimum requirements transmission protocols grouped by four categories of technical features —Performance, Reliability, Compatibility, and Security—applied uniformly across all CTPs (equity, bonds, derivatives). However, for the latency metric, a specific minimum requirement is set, ensuring consistency with timeliness requirements. Preferred Option Option 2 is preferred as it offers a balanced approach by addressing all key aspects of data transmission quality, promoting consistency across

different CTPs. The guidelines ensure scalability and flexibility, while the specific latency requirement guarantees timely data. This approach minimizes operational complexity and compliance costs, making it practical and adaptable for diverse financial instruments. Option 1 - Prescriptive Approach Benefits Data contributors:

Detailed and specific technical features to be met by transmission
protocols help data contributors to comply with the exact regulatory requirements.
Rigid technical requirements can prevent future adoption of more
innovative solutions.
CTPs:
Standardized and asset-specific requirements may reduce complexity
and improve data handling and processing for each asset class.
Tailored requirements can lead to more efficient data handling and
processing for each asset class.
CT users:
Reduces costs for accessing high-quality market data, as the
operational costs of the consolidated tape would be lower if it should work with a limited number of protocols. Costs Data contributors:
Potentially higher operational and IT costs to ensure adherence to the
detailed requirements, such as setting up new systems to meet prescribed performance and reliability benchmarks tailored to each asset class.
Costs for smaller markets that might opt out of contributing data if they
lack the development capability for the mandated contribution model.
CTPs:
The need to implement detailed checks and thresholds for each
category (performance, reliability, etc.) may introduce complexity in daily operations, leading to higher maintenance and troubleshooting costs. CT users:
N/A
Innovationrelated aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the

framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects Potential carbon offset costs for the development of physical infrastructure. Proportionalityrelated aspects Option 1 provides clear and detailed transmission standards, benefiting data contributors and CTPs in terms of reliability and consistency. However, the costs are higher due to the prescriptive nature of the approach, leading to significant operational and compliance burdens. Option 2 - Less Prescriptive Approach Benefits Data contributors:

With fewer specific technical requirements, contributors have more
flexibility in how to design and manage their transmission systems, potentially reducing costs and fostering the adoption of innovative solutions in the future. CTPs:
CTPs have will dispose of a wider set of transmission protocols to be
chosen among the ones offered by data contributors, which will result in the design of more efficient system. CT users:
N/A
Costs Data contributors:
Less prescriptive requirements may introduce some uncertainty in
understanding and meeting the requirements, leading to potential compliance risks. CTPs:
CTPs should be able to work with potentially a higher number of
transmission protocols (compared to Option 1), which might result in higher operational costs. CT users:
Higher operational costs for the CTP might be reflected in higher
subscription fees for CT users.
Innovationrelated aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects Potential carbon offset costs for the development of physical infrastructure.

Proportionalityrelated aspects
Option 2 offers more flexibility to data contributors, still ensuring key elements in data transmission such as performance, reliability, security and compatibility. This approach may reduce costs and operational complexity but risks less consistency in transmission quality and potentially greater uncertainty for stakeholders. Data format for input and output data:
Policy
Objective
Ensure data contributors transmit data to the CTP in a harmonized format and that the CTP offers output data in a user-friendly format, considering the distinct business needs and operational requirements of each asset class. The proposed data format should also adhere to existing industry standards and practices. Option 1 Allow the data contributors to choose which input data format the data is required to be transmitted to the CTP. For output data, CTP will publish it in a Human-readable format (GUI) & Machine-readable formats (CSV and same format as input data). Option 2 Allow the CTP to choose which input data format the data contributors are required to transmit data in. For output data, CTP will publish it in a Human-readable format (GUI) & Machine-readable formats (CSV and same format as input data). Option 3 ESMA will prescribe a single solution for data format across all asset classes. For output data, CTP will publish it in a Human-readable format (GUI) & Machine-readable formats (CSV and same format as input data). Option 4 ESMA will prescribe a standard across all asset classes, allowing data contributors to transmit data only in a format that is ISO20022- compatible. For output data, CTP will publish it in a Human-readable format (GUI) & Machine-readable formats (CSV and an ISO20022- compatible format). Preferred Option The preferred option is Option 4, where ESMA enables data contributors to submit data in an ISO20022-compatible format. This approach offers significant flexibility, allowing the CTP to select a suitable format, while ensuring compatibility with international financial standards. Despite potential challenges, such as different formats across CTPs, the benefits of interoperability and reduced immediate

costs for contributors outweigh the cons. Over time, the adoption of this ISO20022 standard will enhance data quality and improve overall efficiency, benefiting both CTPs and users. Option 1 - Allow data contributors to choose input format Benefits Data contributors:

Cost savings implied by the flexibility to adopt already used data
formats for the transmission to the CTP.
CTPs:
N/A
CT users:
N/A
Costs Data contributors:
N/A
CTPs:
High operational effort in ingesting multiple data formats and
normalising input data.
Risk of incurring in data quality issues during the normalization of
input data.
CT users:
Higher operational costs of the CTP can be transferred to higher
subscription fees.
Data quality issues during the consolidation of multiple data
formats will affect the quality of output data.
Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS.

ESG-related aspects
ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data Proportionalityrelated aspects This option provides flexibility for smaller data contributors, allowing them to select formats compatible with their existing systems. It minimizes the need for expensive upgrades, enabling proportional adaptation. However, CTPs may face increased operational complexity and higher integration costs from handling multiple formats. Additionally, the overall quality of input and output data can be impaired under a scenario of market data transmitted in multiple formats. Option 2 - Allow CTP to choose input format Benefits Data contributors:

N/A
CTPs:
Reduced cost overhead by standardizing data formats.
Standardized formats can streamline operations and reduce data
quality issues.
CT users:
Lower operational complexity for the CTP will lead to lower
subscription fees and improved data quality.
Costs Data contributors:
Initial IT cost for transitioning and maintenance costs associated
with compliance to CTP's selected format.
CTPs:
N/A
CTP users:
N/A

Same as under Option 2.
CTPs:
Same as under Option 2.
CT users:
Same as under Option 2.
CT users will benefit of the same data format across the 3 asset
classes.
Costs Data contributors:
Costs in adapting to a uniform format across asset classes.
CTPs:
Initial implementation costs to support the prescribed format.
CT users:
Same as under Option 2.
Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data. Proportionalityrelated aspects A single prescribed format offers a clear and uniform solution that reduces the complexity of data processing for both small and large contributors. It eliminates the need for each contributor to manage multiple formats, fostering harmonization. However, smaller data contributors may face higher initial costs to adapt to the prescribed format, which could be disproportionate compared to larger entities that are already prepared for system upgrades. Option 4 - ESMA established a standards that allows data contributors to submit data in a harmonize format in accordance with ISO20022 methodology Benefits Data contributors:
This option allows data contributors to choose the most suitable
format for input data, enabling data contributors to benefit from formats that may better align with their technical infrastructure and transmission capabilities. This can help reduce the operational burden associated with stringent formatting requirements.
Since the format must be ISO20022-compatible, contributors
benefit from a level of interoperability with existing financial messaging standards, helping ensure smooth data exchange across systems. CTPs:
By aligning with ISO20022, CTPs can support global compatibility
with other financial entities, potentially reducing compliance costs while maintaining high standards for data integrity and security.
Reduced cost overhead by standardizing input data formats.
Standardized input formats can streamline operations and reduce
data quality issues.
CT users:
N/A.
Costs Data contributors:
Transitioning to a new input format may require upfront IT
development costs for contributors.
CTPs:
N/A
CT users:
Same as under Option 2.
Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data. Proportionalityrelated aspects ISO20022 compatibility allows contributors to adopt a globally recognized, standardized format, facilitating smoother data exchange across different systems and regions. This offers greater flexibility, benefiting contributors of all sizes, as they can choose from compatible formats. However, small contributors may still incur higher initial integration and maintenance costs to align with the ISO20022 standard, particularly if they need to upgrade their infrastructure or systems to ensure compliance. Real time data transmission requirements:
Policy
Objective
Define what constitutes “as close to real time as technically possible” for data transmission, to ensure timely and cost-effective dissemination.

Option 1 Specify that data contributors should transmit post-trade equity data to the CTP within 50 milliseconds after execution (TV) / reception (APA) with 95% confidence interval. Data contributors should transmit post-trade bonds and derivatives data to the CTP 500 milliseconds after execution (TV) / reception (APA). For the pre-trade equity data within 50 milliseconds after order submission. Option 2 Specify that data contributors should transmit post-trade data to the CTP within 100 milliseconds for trading venue transactions and 200 milliseconds for OTC transactions from execution, and pre-trade equity data within 50 milliseconds. Preferred Option Option 1 Benefits Data contributors:

Meeting a standard timing requirement improves data consistency,
supporting market confidence and potentially increasing trading volumes.
Allowing some deviation from the maximum standard allows
flexibility for smaller data contributors as well as to cater for unexpected small delays with a 95% confidence interval. The measurement from the time of reception instead from the execution allows the APAs to have control over the time necessary to send the data. CTPs:
Uniform, near-real-time data transmission enhances the quality
and reliability of data on the consolidated tape, making it a more valuable resource for market participants.
The same latency across data contributors allow to have a uniform
reception and dissemination of data.
CT users:
Access to standardized, real-time data supports better market
transparency and improved decision-making for users, enhancing market fairness and efficiency.
Reliable timing standards support effective trade sequencing,
benefiting trade analytics and reducing information asymmetry in the market. Costs Data contributors:
Data contributors face substantial costs for infrastructure upgrades
to meet the strict timing requirements, including initial setup and ongoing maintenance costs, which could be particularly challenging for smaller operators. CTPs:
CTPs may incur increased expenses to accommodate the highquality data flow, potentially leading to higher operating costs and
increased user fees to support the maintenance of upgraded systems.
CT users:
Increased costs may lead to higher subscription fees for CT users,
especially as CTPs transfer the expenses associated with the highspeed timing requirement. Innovation-related aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects Infrastructure upgrades for high-speed data processing may increase energy consumption, potentially impacting environmental goals unless contributors adopt energy-efficient technologies. Proportionalityrelated aspects This approach does not account for the diversity in contributor resources; smaller firms may bear disproportionate costs to comply, which could reduce their participation in the market. Strict requirements could create a barrier to entry for smaller firms, potentially impacting market diversity and increasing concentration among larger players. Data fields for input and output data:
Policy
Objective
Ensure that the data provided to and disseminated by the CTP is clear and comprehensive, while avoiding unnecessary reporting burden. The ultimate goal is to improve data quality and data aggregation as

well as ensure that investors have access to the information they need to stay informed. Option 1 For the core market data specify input and output data fields that are not covered in RTS 1 or RTS 2. For data fields already specified in these RTS, provide a cross-reference to the relevant RTS. Additionally, specify data fields related to the new concept “regulatory data” which is introduced by the MiFIR review. Benefits Data contributors:

clear and standardised requirements of data submission.
CTPs:
Higher quality under a profitable model.
CT users:
Ensures that the data provided is relevant and useful, enhancing
market transparency and decision-making.
General:
Ensures that market participants comply with regulatory
requirements.
Adoption of standardized data formats and protocols can
streamline operations and reduce complexity.
Efficient data processing and distribution can lead to cost savings
for all stakeholders.
Costs Data contributors / CTPs:
Costs associated with the initial setup of systems and
infrastructure to comply with data requirements.
Continuous costs related to maintaining and updating systems to
handle data requirements.
Costs associated with managing and processing large volumes of
data.
CT users:
If the RTS require more than the essential data, the additional
costs incurred by the CTP and data contributors are likely to be passed on to the end users. This could result in higher expenses for users, impacting the overall affordability and accessibility of market data.

Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data Proportionalityrelated aspects The identified benefits outweigh the comparably costs. Furthermore, the defined fields should be the minimum required for a successfully operational CTP. Therefore, the proposed measures do not go beyond to what is needed to address an investor protection, orderly market or financial stability risk. Data quality requirements:
Policy
Objective
Ensure that high-quality trade data from trading venues and APAs support the CT’s objectives of accuracy and reliability for market participants, without imposing excessive compliance burdens on data contributors or the CTP. Option 1 Require CTP to perform input data checks (completeness, format adherence, timeliness, accuracy, and error identification) and allow the CTP to block the publication of trades identified as containing obvious errors. Output data checks would mirror those required for APAs under RTS 13. Option 2 Require CTP to perform input data checks (completeness, format adherence, timeliness, accuracy, and error identification) but only to flag trades as potentially erroneous instead of blocking their publication. Output data checks would remain aligned with RTS 13 requirements. Preferred Option Option 2 offers a practical balance, maintaining rigorous data quality standards without the operational and financial burdens associated with blocking erroneous trades. By opting for a flagging mechanism, it preserves the CT’s reliability while supporting timely data access for users and minimizing undue costs for all stakeholders. Option 1 - Data quality checks, with Blocking Mechanism Benefits Data contributors:

High-quality, consistent data enhances contributor reputation,
improving trust and user engagement.
Clear quality standards provide contributors with a roadmap for
compliance, reducing ad hoc error handling.
CTPs:
Establishes the CTP as a high-quality data source, potentially
increasing user trust and attracting more users. Aligns CTP requirements with established standards (RTS 13), promoting industry consistency. CT users:
Access to reliable, high-quality data, enhancing the CT’s value as
a market information source.
Clear blocking of erroneous trades reduces data inaccuracies,
supporting more informed decision-making and reducing market risks associated with data errors. Costs Data contributors:
Minimal direct costs, as the burden lies primarily on the CTP.
CTPs:
Blocking erroneous trades may lead to potential challenges in
reconciling data with contributors and coordinating re-publication of corrected data.
Risk of delays in data dissemination due to blocking erroneous
trades.
CT users:
Potentially higher subscription fees due to increased CTP
operational costs, potentially impacting affordability for smaller users.
Risk of delayed data dissemination if trades are blocked frequently.
Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data.

Proportionalityrelated aspects
Option 1 is requiring CTPs to block the publication of erroneous trades, ensuring maximum data integrity but at the cost of flexibility and potentially delayed dissemination. This approach may burden CTPs without significantly improving outcomes for all users. Option 2 – Data Quality Checks and Error Flagging Mechanism Benefits Data contributors:

Enhanced operational flexibility as trades are flagged rather than
blocked.
CTPs:
Allows CTP to offer reliable data while avoiding some operational
complications from blocking trades.
Retains user confidence with flagged alerts for suspicious trades.
Aligns with RTS 13, promoting consistency while balancing
operational feasibility.
CT users:
Consistent access to timely data, even if flagged as potentially
erroneous, enables a transparent view of data quality and allows informed decision-making without interruption.
Improved overall data quality enhances market transparency and
efficiency.
Costs Data contributors:
Same as Option 1.
CTPs:
Requires advanced systems for real-time data monitoring, though
flagging is less resource-intensive than blocking.
Flagging avoids some operational burdens associated with
blocking and subsequent re-publication efforts.
CT users:
Marginally lower fees compared to Option 1, as operational costs
for CTP are reduced.
Innovation-related aspects
The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the

framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the input/output data RTS. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on input/output data. Proportionalityrelated aspects Option 2 supports proportionality by allowing CTPs to flag potentially erroneous trades instead of blocking them outright, Balances high data quality standards with operational flexibility, ensuring timely dissemination while maintaining transparency through flagged trades. This proportional approach is less disruptive and better suited to diverse market conditions.
7.2.2 RTS on the revenue redistribution scheme
This section provides a cost-benefit analysis (CBA) of the draft RTS on the revenue distribution scheme. This RTS is mandated in MiFIR (Level 1) which already includes most elements for the determination of the weights and therefore for the methodology. Moreover, ESMA notes that the questions raised in the CP regarding costs and benefits associated with the proposed amendments and not already covered by ESMA did not attract any answer. This CBA remains therefore of a mainly qualitative nature. The stakeholders identified are trading venues, ESMA, NCAs and the future CTPs. The main costs that the stakeholders will have to bear are expected to be derived from the Level 1 framework, therefore, those from the RTS are minor and mainly concern the adaptation of the existing IT systems to the reviewed requirements. ESMA provides below a detailed analysis of the costs and benefits that could arise from the provisions in the draft RTS. Weighting:
Policy
Objective
Incentivise small trading venues to opt-in and contribute data to the CTP. Option 1 The weights for small trading venue, young instruments and pre-trade transparent trading venue are proposed to be 4.5, 4.0, 1.5 respectively.

Option 2 The weights for small trading venue, young instruments and pre-trade transparent trading venue are proposed to be 6.5, 2.0, 1.5 respectively Option 3 The weights for small trading venue, young instruments and pre-trade transparent trading venue are proposed to be 5.5, 3.0, 1.5 respectively Option 4 The weights for small trading venue, young instruments and pre-trade transparent trading venue are proposed to be 6.0, 2.5, 1.5 respectively Option 5 The weights for small trading venue, young instruments and pre-trade transparent trading venue are proposed to be 5.0, 3.5, 1.5 respectively Preferred Option The first option (Option 1) was chosen since it maximises the revenue received by a trading venue being eligible to all three criteria. Benefits Qualitative description Quantitative description The first option was chosen since it maximises the revenue received by a trading venue meeting all the criteria based on the simulation provided in the CP. See Example #2 in the CP Cost to regulator Cost of setting up a monitoring framework for the correct application of the weights. N/A Compliance cost The compliance costs are limited since the schema does not provide for complexities (e.g. different weights for different types of trading systems or transactions compared to Level 1). N/A Other costs None identified. None identified. Innovationrelated aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. Proportionalityrelated aspects The identified benefits outweigh the comparably limited costs; hence no proportionality-related aspects are expected to be impacted by this option. Methodology:
Policy
Objective
Ensure a fair and transparent application of the revenue distribution scheme.

Option 1 Elements considered:

Use of Operating MIC vs Segment MIC: use of segment MIC with
the exception of the calculation for the first criterion
Conversion of weights into percentages: mandatory
Frequency of determination of the weights: at least annual but can
be more frequent
Calculation of total volumes in the EU by the CTP
Option 2 - Frequency of determination of the weights: annual Preferred Option Option 1 was preferred because more flexible and supported by market participants. Benefits Qualitative description Quantitative description The methodology is very simple and provides clarity on the elements to consider while leaving some flexibility to the CTP. N/A Cost to regulator Cost of setting up a monitoring framework for the correct application of the methodology. N/A Compliance cost:
The compliance costs are limited since the methodology does not provide for complexities. N/A Other costs None identified. None identified. Innovationrelated aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. Proportionalityrelated aspects The identified benefits outweigh the comparably limited costs; hence no proportionality-related aspects are expected to be impacted by this option. Suspension criteria:
Policy
Objective
Ensure that the suspension of data contributors from the revenue redistribution scheme is based on simple and objective criteria

Option 1 Quantitative criteria based on the on-going monitoring by the CTP of numerical thresholds on data contributors’ compliance with data requirements Option 2 Qualitative criteria based on the periodic assessment by the CTP of data contributors’ compliance with data requirements Preferred Option A mix of option 1 (quantitative criteria on timeliness, and on quality, format and substance of data) and option 2 (qualitative criteria on exceptional circumstances, quality of the transmission protocol and clock synchronisation) was preferred. Benefits Qualitative description Quantitative description The proposed criteria cover all the data requirements with which data contributors have to comply, while leaving some flexibility for the CTP to further specify the criteria. . N/A Cost to regulator Limited costs for supervision due to the simplicity of criteria. N/A Compliance cost Compliance costs for the CTP are reduced thanks to the links between the suspension of revenue redistribution and data quality checks. N/A Other costs None identified. None identified. Innovationrelated aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. Proportionalityrelated aspects The identified benefits outweigh the comparably limited costs; hence no proportionality-related aspects are expected to be impacted. Procedure for the suspension and the resumption of redistribution:
Policy
Objective
Ensure a fair procedure to suspend and resume revenue redistribution by striking a balance between incentivising high quality data contributions and reducing operational burdens on the CTP and data contributors. Technical Proposal ESMA proposes minimum requirements in terms of steps and timeline. Benefits Qualitative description Quantitative description

Ensuring fairness through minimum requirements.
N/A
Cost to regulator
Cost of supervising the CTP and its compliance with the proposed minimum requirements. N/A Compliance cost The compliance costs are limited as the proposed requirements remain high-level. N/A Other costs None identified. None identified. Innovationrelated aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the revenue distribution scheme. Proportionalityrelated aspects The identified benefits outweigh the comparably limited costs; hence no proportionality-related aspects are expected to be impacted.
7.2.3 RTS on the synchronisation of business clocks
This section provides a cost-benefit analysis (CBA) for the draft RTS on the synchronisation of business clocks. The draft RTS on the synchronisation of business clocks is mandated in MiFIR Review (Level 1). Article 22c of MiFIR expands the scope of the clock synchronisation requirements to include SIs, DPEs, APAs, and CTPs, in addition to trading venue operators and their members or participants, whose obligations were already established under RTS 25. RTS 25 will be repealed on the date the new RTS on clock synchronisation enters into force. The extension of the clock synchronisation requirement to these entities is geared towards ensuring that, in the context of consolidation of data by the CTP, timestamps reported by different entities can be compared meaningfully. The stakeholders identified are: TV operators and their members, participants or users, SIs, APAs, DPEs, future CTPs, ESMA and NCAs. The main costs that stakeholders are expected to bear will primarily arise from the Level 1 framework for the new entities brought into scope and from the Level 2 framework for entities already subject to the clock synchronisation requirements, as amended by this RTS. These costs are mainly associated with infrastructure upgrades for new entities and potential

adjustments to internal systems. Existing market participants who are already compliant with current requirements under RTS 25 may incur limited additional costs. ESMA provides below an analysis of the costs and benefits that could arise from the provisions in the draft RTS on the synchronisation of business clocks. Reference time Policy Objective To ensure that trading venues and their members, participants or users, SIs, DPEs, APAs and CTPs synchronise the business clocks they use to record the date and time of any reportable event, consistently and reliably, in alignment with international standards. Option 1 Use UTC as the reference time to which all subject entities shall synchronise their business clocks. Benefits • Ensures all entities adhere to a unified time standard, eliminating discrepancies in recording reportable events and aligning with international standards.

Enhances monitoring and supports effective regulatory oversight,
ensuring precise transaction sequencing in fast-paced markets.
Compliance costs
One-off costs: for new entities, there may be expenses related to the
initial setup of synchronisation systems, including acquiring and configuring hardware and software compatible with UTC standards.
On-going costs: new entities might incur recurring costs for
maintaining and calibrating time synchronisation systems, staff training, and IT support to ensure compliance with UTC alignment.
For entities already adhering to UTC under current RTS 25 standards,
it is unlikely they will face additional costs, as the proposal maintains the status quo for them. Innovationrelated aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovationrelated aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects Ensures timely and accurate reporting of reportable events without imposing additional costs on entities already adhering to existing clock synchronisation requirements under RTS 25, maintaining fairness and minimizing unnecessary burdens.

Traceability to UTC
Policy
Objective
To ensure robust and standardized time synchronisation practices across trading venues and their participants, with specific attention to the traceability of time to UTC. Option 1 Extend the existing requirement under Article 4 of RTS 25 to include all entities under Article 22c of MiFIR. The requirement for traceability to UTC will apply not only to operators of trading venues and their members or participants but also to new entities such as SIs, DPEs, APAs and CTPs. Benefits • Ensures all market participants, including new entities, adhere to a unified time traceability protocol, reducing discrepancies in reportable events and promoting data consistency.

Ensures the EU market remains aligned with global practices,
strengthening market compatibility, trust, and efficiency.
Facilitates effective regulatory monitoring by enabling precise
transaction sequencing and timing across all entities, supporting the integrity of fast-moving markets. Compliance costs
One-off costs: for new entities initial investment in clock
synchronisation systems capable of ensuring traceability to UTC and/or potential upgrades to infrastructure to meet regulatory traceability requirements.
On-going costs: maintenance and calibration of systems to preserve
UTC traceability.
Existing entities already compliant with RTS 25 will face no additional
costs.
Innovationrelated aspects
Innovation-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects The proposal ensures timely and accurate reporting of reportable events while imposing no additional costs on entities already complying with existing clock synchronisation requirements under RTS 25.

Level of accuracy for operators of trading venues Policy Objective To ensure that operators of trading venues adopt timestamp accuracy requirements that reflect advancements in high-frequency trading technology, enabling precise transaction sequencing and effective monitoring by NCAs, while maintaining consistency across asset classes. Option 1 Enhance timestamp granularity for operators of trading venues with gateway-to-gateway latency below 1 millisecond to 0.1 microseconds, while maintaining the existing requirements for other latency thresholds. Option 2 Retain the current timestamp granularity requirements for trading venues, with a maximum divergence of 100 microseconds for systems with latency below 1 millisecond. Preferred Option Option 1 Option 1 Benefits • Enhances the precision of timestamping, improving transaction sequencing, reducing latency-related errors, and making market events more traceable.

Helps NCAs more accurately monitor trading activities and ensure
compliance with market rules in high-frequency environments.
Keeps trading venues in line with industry standards and
technological progress in high-frequency trading, offering enhanced market efficiency.
Ensures the robustness of market infrastructure by addressing the
increasing demands for precision in trading venues with low-latency systems. Compliance costs
One-off costs: costs related to investment in upgrading systems to
accommodate 0.1-microsecond timestamp precision, which may include new hardware, software, and integration efforts.
On-going costs: increased costs related to system maintenance, staff
training, and updates to meet the more stringent timestamping requirements. Innovationrelated aspects By requiring enhanced timestamping granularity, this option promotes the development and adoption of new technology, keeping the market aligned with fast-evolving high-frequency trading standards.

ESG-related aspects
ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects Only entities with sufficient technological capability will be required to meet the stricter timestamping standards, ensuring that high-frequency traders and advanced trading venues adopt the highest level of precision. Option 2 Benefits • Keeps current timestamping standards, preserving existing sequencing without requiring new systems or additional complexity

No disruption to existing infrastructure, keeping the current
operational status quo and avoiding changes that could impact current systems.
No need for new investments, keeping operational and infrastructure
costs lower.
Lower benefits compared to option 1.
Compliance costs
One-off costs: no additional costs for upgrading timestamp precision.
Existing infrastructure can remain as is.
On-going costs: minimal ongoing costs, as no changes to
timestamping systems are needed.
Innovationrelated aspects
Maintains the current state without encouraging further technological progress, potentially lagging behind as markets and technologies evolve. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects This option does not impose new requirements on smaller entities or those that are already compliant with existing standards, thus maintaining proportionality across the market. Level of accuracy for members, participants or users of a trading venue Policy Objective To ensure that timestamping accuracy requirements for members, participants, and users of trading venues are proportionate to the time sensitivity and latency of their trading activities, while maintaining consistency with existing standards and aligning with the requirements for operators of trading venues. Option 1 Set differentiated accuracy levels for members, participants, and users of trading venues based on the time sensitivity of their trading activities, ensuring that those engaging in high-frequency trading adhere to the same stringent standards as trading venue operators, while other

participants meet proportionate requirements aligned with their activity profiles Option 2 Apply uniform accuracy levels across all members, participants, and users of trading venues, regardless of trading activity or latency characteristics, to promote consistency and simplicity in timestamping requirements while ensuring all participants contribute to accurate and reliable market data. Preferred Option Option 1 Option 1 Benefits • Alignment with operators of trading venues

Differentiated accuracy levels for high-frequency traders enable
precise sequencing of transactions, improving overall market integrity and reducing risks related to timing discrepancies.
Sets timestamping requirements based on the time sensitivity of
participants' trading activities, ensuring that high-frequency traders meet higher standards while others adhere to more proportionate requirements. Compliance costs
One-off costs: upgrading systems to support differentiated accuracy
levels requires additional infrastructure investment for those needing higher precision (e.g., high-frequency traders).
On-going costs: increased maintenance and operational costs for
high-frequency traders to ensure compliance with stringent timestamping requirements, such as monitoring and updating systems to handle higher accuracy. Innovationrelated aspects Differentiated requirements push high-frequency traders to adopt advanced technologies that ensure higher levels of accuracy, driving innovation in timestamping and trading systems. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects The increased granularity for high-frequency traders ensures that those who engage in time-sensitive activities adhere to more stringent requirements, while other participants are not burdened by unnecessary complexity. Option 2

Benefits • By applying uniform standards, Option 2 simplifies implementation and avoids potential fragmentation, providing a straightforward approach to timestamping across all participants.

Ensures that all market participants follow the same requirements,
which fosters simplicity and consistency across different types of trading activities.
Less benefits compared to option 1.
Compliance costs
There are no new requirements for infrastructure changes
Innovationrelated aspects
Does not incentivize the adoption of more advanced technologies.
ESG-related aspects
ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects Ensures fairness by applying the same level of accuracy across all market participants, regardless of the nature of their trading activity or latency. Level of accuracy for new entities Policy Objective To establish clear and consistent accuracy requirements for the timestamping systems for SIs, DPEs, APAs, and CTPs, ensuring that all market participants in the data transmission chain adhere to appropriate standards for UTC traceability, timestamp granularity, and maximum divergence, while accounting for the differing roles of these entities within the financial market ecosystem. Option 1 Set differentiated accuracy levels based on the role and latency characteristics of each entity, ensuring that all market participants contribute to the consolidation of data accurately and consistently. Benefits • The proposed differentiated accuracy levels for each entity align with their roles in the data transmission chain, ensuring that entities such as SIs with high-frequency trading activities adhere to stringent requirements, while DPEs, which focus on post-trade reporting, meet proportionate accuracy standards.
Ensures precise timestamping at the required level of granularity
based on entity type, which helps maintain the integrity of market data and improves the quality of consolidated tape.

Compliance costs

One-off costs: entities may face infrastructure upgrades, particularly
for SIs that require low-latency systems to comply with the gatewayto-gateway latency criteria for trading venues. Other entities (e.g., DPEs) will incur lower costs as they only need to meet 1-millisecond requirements.
On-going costs: cost related to maintenance of the systems to ensure
compliance with the timestamping requirements.
Innovationrelated aspects
The requirements align with the newly established CTP framework and all entities involved in the data dissemination chain. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed RTS on the synchronisation of business clocks Proportionalityrelated aspects Requirements are tailored to the specific role and technical capabilities of each entity in the data transmission chain, ensuring fairness and avoiding undue burdens.
7.2.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
This section provides a cost-benefit analysis (CBA) for:
− the draft amendments to RTS 13 on authorisation and organisation requirements for APAs and ARMs; and − the draft RTS on authorisation of CTPs. The draft RTS on authorisation of CTPs is mandated in MiFIR Review (Level 1). ESMA’s proposed amendments to RTS 13 are technical adjustments aimed at, on one the hand, splitting the DRSP authorisation regime between APAs/ARMs and CTPs as per MiFIR Review and, on the other hand, reflecting the entry into application of DORA (Level 1). The draft RTS on the authorisation of CTPs sets out information to be provided so ESMA can assess authorisation applications of market participants that will have been selected to potentially operate a CTP in the EU, and as such specifies the authorisation framework for that new business. The stakeholders identified are: APAs, ARMs, future CTPs, ESMA and NCAs. The main costs that the stakeholders will have to bear are expected to be derived from the Level 1 framework, therefore, those from the RTSs are minor.

ESMA provides below an analysis of the costs and benefits that could arise from the provisions in the draft RTS 13 that are new compared to the current RTS 13, and the draft RTS on authorisation of CTPs. Policy objective Enabling ESMA or CAs to assess/monitor whether APAs, ARMs and CTPs seeking authorisation have the necessary arrangements to meet their obligations under the MiFIR Review. Enabling ESMA to assess whether APAs, ARMs and CTPs comply at all times with DORA requirements in the areas of arrangements on ICT services with third-party service providers, business continuity, energy efficiency, record keeping arrangements and ICT risk-management. Technical Proposal The draft RTS 13 revised the following areas:
− New provisions regarding (i) ownership to identify entities exerting significant control over the applicant, and (ii) APAs and ARMs internal controls; − New provisions cross-referring to relevant obligations under DORA. The draft RTS on CTP authorisation specifies the information that must be provided to assess compliance with the following areas:
− organisation, (ii) ownership, (iii) governance, (iv) management body and (v) internal controls; − Business operativity of the CTPs; − Potential conflicts of interest; − DORA requirements. Benefits By aligning authorisation requirements for APAs and ARMs with requirements for other ESMA directly supervised entities, ESMA aims to ensure a consistent approach and predictability for all firms within its supervisory remit. The new requirements on ownership and internal controls would allow CAs and ESMA to have more information on the shareholder structure and the functioning of the second line of defence without incurring in major costs. An assessment conducted at the authorisation stage allows to mitigate risks post-authorisation. This approach aims to increase the

quality of services provided to the market and decrease the need for supervisory intervention. The draft RTS aims to provide clarity, legal certainty and predictability to applicants seeking authorisation as APAs, ARMs and CTPs. It will contribute to ensuring a consistent assessment of applications across the EU in the case of APAs and ARMs.
Article 9 on outsourcing complements the relevant provisions on
arrangements on ICT services with third-party service providers established in DORA. Furthermore, it aims to eventually strengthen CTPs resilience and business continuity. Proper identification and management of conflicts of interest by APAs, ARMs and CTPs will contribute to enhanced quality of, and confidence in, the services provided to clients. Costs to regulator One-off costs: CAs and ESMA will incur one-off staff costs to process APAs, ARMs and CTPs applications and ensure that applicants meet all relevant authorisation requirements. On-going costs: CAs and ESMA will incur minor additional on-going staff and IT costs for APAs, ARMs and CTPs supervision and for processing and reviewing changes to initial authorisation, including changes to the members of the management body or to their responsibilities. Regarding the new requirements for APAs and ARMs on the provision of information regarding (i) ownership and (ii) internal controls, CAs and ESMA would not receive additional information from existing APAs and ARMs, unless there is a material change in these areas. Compliance costs Regardless of existing legal authorisation requirements for APAs and ARMs, firms operating market infrastructures need and usually have arrangements in place in the areas newly introduced in the revised RTS. Therefore, while these policies and procedures are now proposed to be required at authorisation stage, APAs and ARMs applicants are not expected to incur significant additional costs. Regarding the new requirements for APAs and ARMs on the provision of information regarding (i) ownership and (ii) internal controls, these requirements will not apply to existing entities. Applicants will incur one-off costs to prepare all the documentation to be provided to ESMA or CAs for authorisation. These include but

may not be limited to staff costs and possibly fees for outsourced services (e.g. lawyers, consultants.). On-going costs will be incurred to update the information in case of changes to the initial conditions of authorisation. Other costs None identified Innovation-related aspects The CTP is a new entity and all operations have to be set-up from the outset based on Level 1 and Level 2 requirements. In this case, the framework derives from the Level 1 mandate. Therefore, innovation-related aspects are not of direct relevance to the specific nature of the proposed (i) revision of RTS 13 and (ii) RTS on the authorisation of CTP. ESG-related aspects ESG-related aspects are not of direct relevance to the specific nature of the proposed (i) revision of RTS 13 and (ii) RTS on the authorisation of CTP. Proportionalityrelated aspects The identified benefits outweigh the comparably limited costs; hence no proportionality-related aspects are expected to be impacted.

7.3 Annex III – Draft Technical Standards
7.3.1 Draft RTS on input and output data of CTPs
COMMISSION DELEGATED REGULATION (EU) 2024/XXX of XXXX supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council on markets in financial instruments with regard to regulatory technical standards on the quality of the transmission protocol, measures to address erroneous trade reporting and enforcement standards in relation to data quality, and quality and substance of the data for the operation of the consolidated tapes (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 2024/791 1 and in particular Article 22b(3), fifth subparagraph thereof, Whereas:
(1) Defining clear and harmonised reporting instructions for data to be transmitted to and disseminated by the CTPs is a key element for the orderly functioning of CTPs and effective and reliable data consolidation. (2) To achieve fast, secure and high-quality data transmission to the CTP, the transmission protocols chosen by data contributors should fulfil certain minimum requirements in terms of performance, security, reliability, and compatibility with other systems and applications supporting the reporting process. Upholding these standards is necessary to guarantee the integrity, accuracy, and timeliness of market data disseminated by the CTP. (3) To ensure timely availability of consolidated market data to investors, data contributors should be subject to strict submission latency requirements. Such requirements should however be calibrated to the varying degrees of time-sensitivity in market data. In particular, 1 OJ L 173 12.6.2014, p. 84.

pre- and post-trade data for equities requires tighter latency standards compared to bonds and derivatives, given their higher time-sensitivity. Furthermore, the defined latency thresholds should represent the maximum allowed limits. Whenever a faster latency is achievable, it should be used. In order to meet the requirement to transmit the data as close to real time as possible, data should be transmitted to the CTP without artificial delays compared to data transmission for other purposes, including transmission of proprietary data feeds. (4) Harmonisation of data format for the transmission of data to the CTP facilitates efficient reception and processing of input data. Harmonisation of data format for data transmission also streamlines the operations of CTPs in consolidating and disseminating data in a costefficient manner, reducing complexity, and enhancing overall operational effectiveness as well as ensuring the consistency and quality of data for the users of the CTP. The ISO 20022 standard defines a methodology that provides for harmonisation at three levels: the conceptual level specifying the semantics of data, the logical level specifying the message model, without regard to technology, and the physical level describing the syntax of the message in a technology that is used for the transmission of data. Given the broad adoption of ISO 20022 by markets participants in the context of regulatory reporting, the use of this standard should facilitate ensuring the consistency and comparability of data. Therefore, any format used for reporting under Article 22a of MiFIR should adhere to the above methodology. However, given the varying market practices and their level of maturity across different asset classes, adherence to a single syntax at a third level is not necessary where well-established market practice already exists, e.g. in the case of the equity asset class. (5) The content of the data to be transmitted to the CTPs should be defined with the objective of minimising reporting burden for data contributors while facilitating the dissemination of data essential for investors. In defining the input data fields functional to the production of core market data, consistency should be ensured with the existing pre- and posttrade requirements provided by the Commission Delegated Regulation (EU) 2017/587 2 and Commission Delegated Regulation (EU) 2017/583 3 respectively for equity and non-equity instruments. (6) The definition of regulatory data to be transmitted to the CTPs encompasses a new set of information enabling investors to be informed about the status of individual financial 2 Commission Delegated Regulation (EU) 2017/587 of 14 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council on markets in financial instruments with regard to regulatory technical standards on transparency requirements for trading venues and investment firms in respect of shares, depositary receipts,
exchange-traded funds, certificates and other similar financial instruments and on transaction execution obligations in respect of certain shares on a trading venue or by a systematic internaliser (OJ L 87, 31.3.2017, p. 387). 3 Commission Delegated Regulation (EU) 2017/583 of 14 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council on markets in financial instruments with regard to regulatory technical standards on transparency requirements for trading venues and investment firms in respect of bonds, structured finance products, emission allowances and derivatives (OJ L 87, 31.3.2017, p. 229).

instruments traded on a given trading venue, which includes details on trading suspension, removal, or halts. Additionally, regulatory data covers the status of system matching orders, including information on outages or normal trading phases, enabling investors to make wellinformed decisions in varying market conditions. (7) The dissemination of output data should occur thorough presentation methods that ensure both machine and human readability. To achieve this objective, requirements are prescribed to fulfil various degrees of abilities of data users. To cater for diverse user needs, the dissemination of output data should be provided in multiple formats, including an ISO 20022 methodology compliant format, for advanced analysis, CSV format for less advanced users, and a graphical user interface (GUI) for ensuring human readability. (8) The CTP is entrusted with the responsibility to ensure data quality on the input side, encompassing content, format, and timeliness checks. This obligation involves flagging potential data quality issues to data users and communicating with data contributors for facilitating the resubmission of corrected trade reports. In the event of serious data quality breaches, the CTPs are expected to apply enforcement standards in a non-discriminatory manner, when applying the enforcement measures at its disposal, such as suspending revenue redistribution or notifying data quality issues to competent authorities. Additionally, the CTP is expected to perform regular checks on the quality of output data, ensuring periodic reconciliation with the input data. (9) This Regulation is based on the draft regulatory technical standards submitted by the European Securities and Markets Authority (ESMA) to the Commission. (10) In accordance with Article 10 of Regulation (EU) No 1095/2010 4 ESMA has conducted open public consultations on the draft regulatory technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Securities and Markets Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1095/2010. (11) ESMA has considered the advice of the expert stakeholder group in accordance with
Article 22b third subparagraph thereof of Regulation (EU) No 600/2014.
HAS ADOPTED THIS REGULATION:
4 Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2020, p. 84).

Article 1
Definitions
For the purpose of this Regulation, the following definitions shall apply:
(a) “input data” means data transmitted by data contributors to the CTP, in accordance with Article 22a(1) of Regulation (EU) No 600/2014; (b) “output data” means data disseminated by the CTP, in accordance with Article 27h(1)(d) of Regulation (EU) No 600/2014.
Article 2
Minimum requirements for the quality of transmission protocols
1. For the purpose of the transmission of input data, data contributors shall offer the CTP
at least one transmission protocol compliant with the minimum requirements specified in Tables 1,2,3 and 4 of Annex I.
2. Upon agreement on the selected transmission protocol for the transmission of input
data, the CTP and data contributors shall ensure that the requirements provided by paragraph 1 are consistently met without interruption.
Article 3
Real time transmission of data to the CTP
1. As prescribed by Article 22a(1) of Regulation (EU) No 600/2014, in all cases data shall
be transmitted to the CTP as soon as technically possible, and no artificial delays shall be introduced during the data transmission.
2. Data contributors shall transmit pre-trade input data to the CTP for shares and ETFs
as close to real-time as is technically possible and in any case no later than 50 milliseconds after the timestamp of the order with a 95% of confidence interval measured on a daily basis.
3. Data contributors shall transmit post-trade input data related to transactions executed
on a trading venue to the CTP for shares and ETFs as close to real-time as is technically

possible and in any case no later than 50 milliseconds after the timestamp of the transaction with a 95% of confidence interval measured on a daily basis.
4. Data contributors shall transmit post-trade input data related to transactions executed
outside of a trading venue to the CTP for shares and ETFs as close to real time as is technically possible and in any case within 50 milliseconds after the timestamp of the reception of the trade report from the investment firm or Designated Public Entity (DPE).
5. Data contributors shall transmit bonds and derivatives post-trade input data related to
transactions executed on a trading venue to the CTPs as close to real-time as is technically possible and in any case within 500 milliseconds after the timestamp of the execution of the relevant transaction.
6. Data contributors shall transmit bonds and derivatives post-trade input data related to
transactions executed outside of a trading venue to the CTPs as close to real time as is technically possible and in any case within 500 milliseconds after the timestamp of the reception of the trade report from the investment firm or DPE.
Article 4
Data standards and format for the transmission of input data Data contributors shall transmit input data to the data centre of the CTP in a format that adheres to the ISO 20022 methodology.
Article 5
Data to be transmitted to the CTP for bonds
1. With regards to core market data for a given bond, data contributors shall transmit to
the data centre of the CTP, by reference to each transaction, the details set out in Table 6 of
Annex II of this Regulation. The details should be those flagged as input or both in the last
column.
2. With regards to regulatory data, data contributors shall transmit to the data centre of
the CTP, by reference to each financial instrument, the details set out in Table 2 of Annex II of this Regulation. The details should be those flagged as “both” in the last column of Table 2.

3. With regards to regulatory data, data contributors shall transmit to the data centre of
CTP, by reference to each trading system, the details set out in Table 3 of Annex II. The details should be those flagged as “both” in the last column of Table 3.
Article 6
Data to be transmitted to the CTP for shares and ETFs
1. With regards to post-trade core market data for a given share and ETF, data
contributors shall transmit to the data centre of the CTP, by reference to each transaction, the details set out in Table 7 of Annex II of this Regulation. The details should be those flagged as input or both in the last column of Table 7.
2. With regards to pre-trade core market data for a given share and ETF, data contributors
shall transmit to the data centre of the CTP, by reference to each best bid and offer and each price at which the auction system would best satisfy its trading algorithm, the details set out in
Table 1 of Annex III of this Regulation.
3. With regards to regulatory data, data contributors shall transmit to the data centre of
the CTP, by reference to each financial instrument, the details set out in Table 4 of Annex II of this Regulation. The details should be those flagged as “both” in the last column of Table 4.
4. With regards to regulatory data, data contributors shall transmit to the data centre of
the CTP, by reference to each trading system, the details set out in Table 5 of Annex II of this Regulation. The details should be those flagged as “both” in the last column of Table 5.
Article 7
Data to be disseminated by the CTP for bonds
1. With regards to core market data for a given bond, the CTP shall disseminate by
reference to each transaction the details set out in Table 6 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of Table 6.
2. With regards to regulatory data relating to bonds, the CTP shall disseminate:
(a) by reference to each financial instrument, the details set out in Table 2 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of
Table 2.

(b) by reference to each trading system, the details set out in Table 3 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of Table 3.
Article 8
Data to be disseminated by the CTP for shares and ETFs
1. With regards to post-trade core market data for a given share and ETF, the CTP shall
disseminate by reference to each transaction the details set out in Table 7 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of Table 7.
2. With regards to pre-trade core market data for a given share and ETF, the CTP shall
disseminate by reference to the EBBO or the price at which the auction system would best satisfy its trading algorithm, the details set out respectively, in Tables 2, 3 and 4 of Annex III of this Regulation. 3 With regards to regulatory data relating to shares and ETFs, the CTP shall disseminate:
(a) by reference to each financial instrument, the details set out in Table 4 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of
Table 4.
(b) by reference to each trading system, the details set out in Table 5 of Annex II of this Regulation. The details should be those flagged as output or both in the last column of Table 5.
Article 9
Dissemination of output data to ensure machine-readability and human-readability
1. The CTP shall disseminate the output data in a Graphical User Interface (GUI) to
ensure human readability.
2. The CTP shall also disseminate the output data in at least the following two formats
simultaneously:
(a) Comma-Separated Values (CSV); and

(b) An ISO 20022 methodology compliant format used for the transmission of input data.
3. CTPs shall:
(a) make instructions available to the public, explaining how and where to easily access and use the data, including identification of the electronic format; (b) make public any changes to the instructions referred to in point (a) at least three months before they come into effect, unless there is an urgent and duly justified need for changes in instructions to take effect more quickly; (c) include a link to the instructions referred to in point (a) on the homepage of their website.
Article 10
Management of incomplete or potentially erroneous information by CTPs

CTPs shall set up and maintain appropriate arrangements to ensure that they
accurately publish the information received from data contributors without themselves introducing any errors or omitting information and shall correct information where they have themselves caused the error or omission.
CTPs shall continuously monitor in real-time the performance of their IT systems
ensuring that the input data they have received have been successfully consolidated and published.
CTPs shall perform periodic reconciliations between the input data they receive and
the output data that they publish, verifying the correct publication of the information.
A CTP shall confirm the receipt of input data to the reporting data contributor, including
the transaction identification code assigned by the CTP. A CTP shall refer to the transaction identification code in any subsequent communication with the data contributor in relation to a specific set of information reported.
A CTP shall set up and maintain appropriate arrangements to identify receipt input data
that are incomplete, does not adhere to the details prescribed by Articles 5 and 6, or contain information that is likely to be erroneous. These arrangements shall include automated price and volume alerts, taking into account:
(a) the sector and the segment in which the financial instrument is traded;

(b) liquidity levels, including historical trading levels; (c) appropriate price and volume benchmarks; (d) if needed, other parameters according to the characteristics of the financial instrument.
6. Where a CTP determines that the input data it receives is incomplete or does not
adhere to any other reporting instructions, it shall not publish that information and shall promptly alert the data contributor submitting the input data.
7. Where a CTP determines that the input data it receives is likely to be erroneous, it shall
publish that information and shall promptly flag the potential data quality issue both to the public and to the data contributor.
8. Upon receiving notification of a data quality issue, data contributors shall acknowledge
the issue and, if necessary, shall initiate the process of resubmitting corrected data.
9. A CTP shall monitor the timeliness of input data received by data contributors for the
identification of serious and repeated breaches of timeliness requirements provided by
Article 3.
10. In exceptional circumstances CTPs shall delete and amend information in a trade report
upon request from the data contributor providing the information when that entity cannot delete or amend its own information for technical reasons.
11. CTPs shall have in place formalised interactive communication mechanisms with their
clients through which data users may flag to the CTP potential inaccuracies in the dissemination of output data.
12. CTPs shall publish non-discretionary policies outlining the procedure underpinning the
activation of measures to enforce data quality. These policies must include clear guidance on the application of such measures, ensuring adherence to non-discretionary application, proportionality, timeliness, consistency, and transparency.
Article 11
Entry into force

This Regulation shall enter into force on the twentieth day following that of its
publication in the Official Journal of the European Union.
This Regulation shall be binding in its entirety and directly applicable in all Member
States.
Done at Brussels, [DD MM 2024]
For the Commission
The President
[For the Commission
On behalf of the President
[Position]

ANNEX I
Minimum requirements for the quality of the transmission protocols
Table 1
Performance requirements
Metrics/ features Minimum requirements Primary OSI Layers Latency Latency shall be maintained below 50 milliseconds for the transmission of data to the shares and ETFs CTP. Latency shall be maintained below 500 milliseconds for the transmission of data to the bonds CTP. Latency shall be maintained below 500 milliseconds for the transmission of data to the derivatives CTP. Layer 3 (Network) Throughput Throughput shall exceed 100 Megabits per second (Mbps). Layer 1 (Physical), Layer 2 (Data link) Connection setup time Round Trip Time (RTT) for connection setup shall be less than 500 milliseconds. Layer 4 (Transport) Scalability The protocol must support operation in clustered or load-balanced environments. Layer 2 (Data link), Layer 3 (Network), Layer 4 (Transport) and Layer 7 (Application)
Table 2
Reliability requirements
Metrics / features Minimum requirements Primary OSI Layers Error detection mechanism The protocol shall include error detection mechanisms to ensure accurate identification of data transmission errors. Layer 2 (Data link), Layer 4 (Transport) Error correction mechanism The protocol shall incorporate error correction mechanisms to automatically rectify detected errors. Layer 2 (Data link), Layer 4 (Transport) Recovery mechanism The protocol shall feature recovery mechanisms to swiftly recover from transmission failures or Layer 4 (Transport), Layer 5 (Session)

interruptions, ensuring seamless continuity of data transmission operations.
Table 3
Security requirements
Metrics / features Minimum requirements Primary OSI Layer Secure transport layer The protocol shall support a secure transport layer to ensure the confidentiality of data during transmission. Layer 4 (Transport), Layer 7 (Application) Authentication The protocol shall support authentication credentials-based or certificate-based authentication mechanisms to verify the identity of communicating parties. Layer 7 (Application) Authorisation The protocol shall implement authorisation mechanisms to control access to specific resources or functionalities based on user roles or permissions. Layer 7 (Application) Non-repudiation The protocol shall incorporate non-repudiation mechanisms to ensure that the originator of a message cannot deny sending it. Layer 7 (Application)
Table 4
Compatibility requirements
Metrics / features Minimum requirements Primary OSI Layer Open solution The implementation of the protocols shall adhere to non-proprietary standards. Layer 7 (Application) Interoperability The protocol shall support at least one widely recognised internet standard. Layer 7 (Application) Backward compatibility The protocol shall be capable to work with older versions of itself or previous technologies. Layer 7 (Application)

ANNEX II
Data to be transmitted to and disseminated by the CTP for bonds
Table 1
Symbol table for Tables 2, 3, 4, 5, 6 and 7
Symbol Data Type Definition
{DATE_TIME_FORMAT} ISO 8601 date and time format Date and time in the following format:
YYYY-MMDDThh:mm:ss.ddddddZ.
— ‘YYYY’ is the year;
— ‘MM’ is the month;
— ‘DD’ is the day;
— ‘T’ — means that the letter ‘T’ shall be used — ‘hh’ is the hour; — ‘mm’ is the minute; — ‘ss.dddddd’ is the second and its fraction of a second; — Z is UTC time. Dates and times shall be reported in UTC. {ISIN} 12 alphanumerical characters ISIN code, as defined in ISO {MIC} 4 alphanumerical characters Market identifier as defined in ISO 10383 {CURRENCYCODE_3} 3 alphanumerical characters 3-letter currency code, as defined by ISO 4217 currency codes
Table 2
Regulatory data for bonds, per instrument

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field Instrument identificatio n code Code used to identify the financial instrument {ISIN} Both Instrument status start date and time Date and time from which the instrument status is valid. The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_F ORMAT} Both 3 Currency Major currency in which the instrument is traded {CURRENCYC ODE_3} Both Disseminati on date and time Date and time on which the instrument status is disseminated by the CTP The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_F ORMAT} Output Instrument status Description of the status of the financial instrument. The status of the financial instrument can be:
(1) suspended from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (2) removed from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (3) subject to a trading halt, on the trading venue identified in the field “Trading venue”, in accordance with Articles 18(5) and 48(5) of Directive 2014/65/EU (4) ACTV the instrument is available for trading after a suspension, removal or halt. ‘SUSP’ – the instrument is suspended ‘REMV’ – the instrument is removed ‘HALT’ – the instrument is subject to a trading halt ‘ACTV’ - the instrument is available for trading after a suspension, removal or halt Both

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field Trading venue Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market, an MTF or an OTF. {MIC} Both Trading system Type of trading system on which the instrument is traded CLOB - Central Limit Order Book 'QDTS' - Quote Driven Market PATS - Periodic Auction 'RFQT' Request for Quotes ‘VOIC’ - Voice trading system HYBR - Hybrid System OTHR - Any Other Both
Table 3
Regulatory data for bonds, per order matching system

Field

identifier
Description Format
Equivalent formats can be used, depending on the syntax used for data transmission field

Trading venue
Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market, an MTF or an OTF. {MIC} Both Trading system Type of trading system on which the system status is provided CLOB - Central Limit Order Book 'QDTS' - Quote Driven Market PATS - Periodic Auction RFQT Request for Quotes ‘VOIC’ - Voice trading system HYBR - Hybrid System OTHR - Other Both System status start date and time Date and time from which the system status is valid The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_F ORMAT} Both Dissemin ation date and time Date and time on which the system status is disseminated by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_F ORMAT} Output Trading system status Status of the trading system on which the instrument is traded ACTV – Active System OTAG - Outage of the trading system POTG - Partial outage of the trading system Both

Table 4
Regulatory data for shares and ETFs, per instrument # Field Format Equivalent formats can be used, depending on the syntax used for data transmission field Instrument identification code Code used to identify the financial instrument {ISIN} Both Instrument status start date and time Date and time from which the instrument status is valid The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Both 3 Currency Major currency in which the instrument trades. {CURRENCYCODE_3} Both Disseminatio n date and time Date and time on which the regulatory data is disseminated by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Output Instrument status Description of the status of the financial instrument. The status of the financial instrument can be:
(1) suspended from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (2) removed from trading, on the trading venue identified in the field “Trading venue”, in accordance with Article 32 and 52 of Directive 2014/65/EU (3) subject to a trading halt, on the trading venue identified in the field “Trading venue”, in accordance with Articles 18(5) and 48(5) of Directive 2014/65/EU (4) ‘ACTV’ the instrument is available for trading after a suspension, removal or halt. ‘SUSP’ – the instrument is suspended ‘RMOV’ – the instrument is removed ‘HALT’ – the instrument is subject to a trading halt ‘ACTV’ - the instrument is available for trading after a suspension, removal or halt Both Trading venue Identification of the trading venue on which the instrument status is valid (segment MIC where {MIC} Both

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field available, otherwise operating MIC). The trading venue is a regulated market or an MTF. Trading system Type of trading system on which the instrument is traded. ''CLOB' - Central Limit Order Book 'QDTS' - Quote Driven Market 'PATS' - Periodic Auction 'RFQT' - Request for Quotes HYBR’ - Hybrid System ’OTHR’ - Other Both Trading phase Type of trading phase of the trading system on which the instrument trades. ‘UDUC’ - Undefined Auction ‘SOAU‘ - Scheduled Opening Auction ‘SCAU‘ - Scheduled Closing Auction ’SIAU’ - Scheduled Intraday Auction ‘UAUC’ - Unscheduled Auction ‘ODAU’ - On Demand Auction (Frequent Batched Auction) ‘CONT’ - Continuous Trading ‘MACT’ - At Market Close Trading ‘OMST’- Out of Main Session Trading ‘TROE’- Trade Reporting (On Exchange) Both

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field ’TROF’ - Trade Reporting (Off Exchange) ’TRSI’ - Trade Reporting (Systematic Internaliser) OTHR - other Most Relevant Market in terms of liquidity Identification of the trading venue in Field 6 being the most relevant market TRUE – Yes FALSE - No Output
Table 5
Regulatory data for shares and ETFs, per order matching system # Field Format Equivalent formats can be used, depending on the syntax used for data transmission field Trading venue Identification of the trading venue on which the instrument status is valid (segment MIC where available, otherwise operating MIC). The trading venue is a regulated market or an MTF. {MIC} Both Trading system Type of trading system on which the system status is provided ''CLOB' - Central Limit Order Book 'QDTS' - Quote Driven Market 'PATS' - Periodic Auction 'RFQT' - Request for Quotes ‘HYBR’ - Hybrid System ’OTHR’ - Other Both System status start date and time Date and time from which the system status is valid The level of granularity shall be in accordance with the requirements set {DATE_TIME_FORMAT} Both

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field out in Article 2 of Delegated Regulation (EU) 2017/574. System status disseminati on date and time Date and time on which the system status is disseminated by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} Output Trading phase Type of trading phase of the trading system ‘UDUC’ - Undefined Auction ‘SOAU‘ - Scheduled Opening Auction ‘SCAU‘ - Scheduled Closing Auction ’SIAU’ - Scheduled Intraday Auction ‘UAUC’ - Unscheduled Auction ‘ODAU’ - On Demand Auction (Frequent Batched Auction) ‘CONT’ - Continuous Trading ‘MACT’ - At Market Close Trading ‘OMST’- Out of Main Session Trading ‘TROE’- Trade Reporting (On Exchange) ’TROF’ - Trade Reporting (Off Exchange) ’TRSI’ - Trade Reporting (Systematic Internaliser) OTHR - other Both

Field
Format
Equivalent formats can be used, depending on the syntax used for data transmission field Trading system status Status of the trading system ACTV – Active System OTAG - Outage of the trading system POTG - Partial outage of the trading system Both

Table 6
Post-trade core market data for bonds

Field identifier Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 1 Equivalent formats can be used, depending on the syntax used for data transmission Input /Output data field Trading date and time Field 1 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Instrument identification code Field 2 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both 3 Price Field 3 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both 4 Missing Price Field 4 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583 Both 5 Price currency Field 5 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both 6 Price notation Field 6 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both

7 Quantity Field 7 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Notional amount Field 10 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Notional currency Field 11 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Venue of execution Field 13 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Third-country trading venue of execution Field 14 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Date and Time when the data contributor received the data Date and time when the transaction report was received by an APA. The level of granularity shall be in accordance with the requirements set out in
Article 6 of Delegated Regulation (EU) 2017/574.
APA {DATE_TIME_ FORMAT}
Input

Publication
Date and Time of the data contributor
Field 15 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Venue of publication Field 16 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both Transaction Identification Code Field 17 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both 16 Reception Date and Time by the CTP Date and time when the transaction was received by the CTP. The level of granularity shall be in accordance with the requirements set out in Articles 2 and 6 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output Publication Date and Time of the CTP Date and time when the transaction was published by the CTP. The level of granularity shall be in accordance with the requirements set out in
Article 5 of Delegated Regulation (EU) 2017/574.
CTP {DATE_TIME_ FORMAT}
Output

18 Flags Field 19 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both 19 Suspicious Data Flag Data quality flag reported by the CTP when the APA or tte CTP have identified trades that for them might be subject to data quality issues. CTP TRUE or FALSE Output Trading System Type Field 20 of Table 2 of Annex II of Delegated Regulation (EU) 2017/583. Both

Table 7
Post-trade core market data for shares and ETFs Field num Field identifier Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 2 Equivalent formats can be used, depending on the syntax used for data transmission Input / Output data field 1 Trading date and time Field 1 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 2 Instrument identification code Field 2 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 3 Price Field 3 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 4 Missing Price Field 4 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 5 Price currency Field 5 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both

Field num
Field identifier Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 2 Equivalent formats can be used, depending on the syntax used for data transmission Input / Output data field 6 Quantity Field 7 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 7 Venue of execution Field 8 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 8 Third-country trading venue of execution Field 9 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 9 Date and Time when the data contributor received the data Date and time when the transaction report was received by an APA. The level of granularity shall be in accordance with the requirements set out in Article 6 of Delegated Regulation (EU) 2017/574. APA {DATE_TIME_ FORMAT} Input 10 Trading system Field 10 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 11 Publication date and time of the data contributor Field 11 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both

Field num
Field identifier Description and details to be published Type of execution or publication venue Format to be populated as defined in Table 2 Equivalent formats can be used, depending on the syntax used for data transmission Input / Output data field 12 Venue of Publication Field 12 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 13 Transaction identification code Field 13 of Table 3 of Annex I of Delegated Regulation (EU) 2017/587 Both 14 Reception Date and Time by the CTP Date and time when the transaction was received by the CTP. CTP {DATE_TIME_ FORMAT} Output 15 Publication Date and Time of the CTP Date and time when the transaction was published by the CTP. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. CTP {DATE_TIME_ FORMAT} Output 16 Flags This field should be populated with the list of all applicable flags as described in Table 4 of Annex 1. Including, when applicable, the “NTLS” (Pre-trade large in scale waiver flag) for transactions which are executed in accordance with Article 4(1), point (c), of Regulation (EU) No 600/2014. Where none of the specified circumstances apply, the transaction should be published without a flag. RM, MTF, APA As per Table 4 of Annex 1 Both Only input for NTLS flag

ANNEX III
Table 1
Pre-trade core market data for shares and ETFs to be transmitted to the CTP

Field identifier Description and details to be published

Format to be populated as defined in Table
Equivalent formats can be used, depending on the syntax used for data transmission 1 Update date and time For continuous order book Field 1 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For periodic auctions Field 1 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For auction trading systems, the date and time at which the price would best satisfy the trading algorithm and any modification of the price (field 5) or quantity (field 8) thereafter. The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574.

Field identifier Description and details to be published

Format to be populated as defined in Table
Equivalent formats can be used, depending on the syntax used for data transmission The fields price (Field 5) and quantity (Field 8) should be updated at the end of every trading phase. 2 Instrument identification code Field 2 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. 3 Side Field 3 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. This field is mandatory only for continuous order books. 4 Price For continuous order books this field corresponds to Field 5 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587 of the best bid and offer. For periodic auctions Field 5 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For auction trading system, the price at which the auction trading system would best satisfy its trading algorithm. The price shall be provided in the major currency unit.

Field identifier Description and details to be published

Format to be populated as defined in Table
Equivalent formats can be used, depending on the syntax used for data transmission Where price is currently not available but pending (“PNDG”) or not applicable (“NOAP”), this field shall not be populated. 5 Price currency Field 6 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. 6 Quantity For continuous order books, this field corresponds to Field 8 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For periodic auctions, this field corresponds to Field 8 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. For auction trading system the aggregated quantity attached to the price that would best satisfying the trading algorithm. 7 Venue Field 11 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587.

Field identifier Description and details to be published

Format to be populated as defined in Table
Equivalent formats can be used, depending on the syntax used for data transmission 8 Trading system This field corresponds to Field 12 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. This field shall be populated for CLOB, PATS and, HYBR system types. 9 Trading phase This field corresponds to Field 13 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587. 10 Publication date and time This field corresponds to Field 14 of Table 1b of Annex I of Delegated Regulation (EU) 2017/587.

Table 2
Symbol table for Tables 3 and 4
Symbol Data Type Definition
{DATE_TIME_FORMAT} ISO 8601 date and time format Date and time in the following format:
YYYY-MM-DDThh:mm:ss.ddddddZ.
— ‘YYYY’ is the year;
— ‘MM’ is the month;
— ‘DD’ is the day;
— ‘T’ — means that the letter ‘T’ shall be used — ‘hh’ is the hour; — ‘mm’ is the minute; — ‘ss.dddddd’ is the second and its fraction of a second; — Z is UTC time. Dates and times shall be reported in UTC. {ISIN} 12 alphanumerical characters ISIN code, as defined in ISO 6166 {MIC} 4 alphanumerical characters Market identifier as defined in ISO 10383

{DECIMAL-n/m} Decimal number of up to n digits in total of which up to m digits can be fraction digits Numerical field for both positive and negative values. — decimal separator is ‘.’ (full stop); — negative numbers are prefixed with ‘–’ (minus); Where applicable, values shall be rounded and not truncated. {CURRENCYCODE_3} 3 alphanumerical characters 3-letter currency code, as defined by ISO 4217 currency codes
Table 3
Pre-trade core market data for shares and ETFs to be disseminated by the CTP - EBBO

Field identifier Description

Format as defined in
Table 1
Equivalent formats can be used, depending on the syntax used for data transmission 1 Entry date and time Field 1 of Table 1 of Annex III of this Regulation 2015/587 of the best bids and offers into the order book as reported by the trading venue. {DATE_TIME_FORMAT} 2 Instrument identification code Field 2 of Table 1of Annex III of this Regulation {ISIN} 3 Currency Major currency unit in which the European best bid and offer prices are expressed. This corresponds to Field 5 of Table 1of Annex III of this Regulation {CURRENCYCODE_3} 4 Best bid European best bid in continuous order books. This corresponds to Field 4 of Table 1 of Annex III of this Regulation {DECIMAL-18/13} 5 Best bid volume The corresponding aggregated volume to the European best bid. This corresponds to Field 6 of Table 1of
Annex III of this Regulation
{DECIMAL-18/17}
6 EBBO timestamp Date and time of the calculation of the EBBO. {DATE_TIME_FORMAT}

The level of granularity shall be in accordance with the requirements set out in Article 2 of Delegated Regulation (EU) 2017/574. 7 MRMTL Most relevant market in terms of liquidity as defined in Article 4(4) of Commission Delegated Regulation 2017/587. {MIC} 8 Best offer European best offer in continuous order books. This corresponds to Field 4 of Table 1of Annex III of this Regulation {DECIMAL-18/13} 9 Best offer volume The corresponding aggregated volume to the European best offer. This corresponds to Field 6 of Table 1of
Annex III of this Regulation
{DECIMAL-18/17}
10 Dissemination date and time
Date and time when the data related to the order was disseminated by the CTP to the subscribers. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} 11 Publication date and time This corresponds to Field 10 of Table 1of Annex III of this Regulation {DATE_TIME_FORMAT}
Table 4
Pre-trade core market data for shares and ETFs to be disseminated by the CTP – indicative auction price

Field identifier Description

Format as defined in Table 1
Equivalent formats can be used, depending on the syntax used for data transmission 1 Indicative date and time This corresponds to Field 1 of Table 1 of Annex III of this Regulation. {DATE_TIME_FORMAT} 2 Instrument identification code This corresponds to Field 2 of Table 1 of Annex III of this Regulation. {ISIN} 3a Lowest auction price Lowest auction price. This field corresponds to Field 4 of Table 1 of Annex III of this Regulation {DECIMAL-18/17} 3b Highest auction price Highest auction price. This field corresponds to Field 4 of Table 1 of Annex III of this Regulation {DECIMAL-18/17} 3c Volume weighted auction price Volume weighted auction price. This field corresponds to Field 4 of Table 1 of Annex III of this Regulation weighted by Field 6 of Table 1 of Annex III of this Regulation {DECIMAL-18/17} 4 Currency Major currency unit in which the auction price is expressed. This field corresponds to Field 5 of
Table 1 of Annex III of this Regulation
{CURRENCYCODE_3}

5 Auction volume Total auction volume, where applicable, across venues. This corresponds to Field 6 of Table 1 of Annex III of this Regulation. {DECIMAL-18/13} 6 Dissemination date and time Date and time when the data related to the order was disseminated by the CTP to the subscribers. The level of granularity shall be in accordance with the requirements set out in Article 5 of Delegated Regulation (EU) 2017/574. {DATE_TIME_FORMAT} 7 Publication date and time This field corresponds to Field 10 of Table 1 of Annex III of this Regulation {DATE_TIME_FORMAT} 8 MRMTL Most relevant market in terms of liquidity as defined in Article 4(4) of Commission Delegated Regulation 2017/587. {MIC}

7.3.2 Draft RTS on the revenue redistribution scheme
COMMISSION DELEGATED REGULATION (EU) 2024/XXX of XXXX supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the revenue redistribution scheme (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 2024/791 ( ), and in particular Article 27h(8), last subparagraph, thereof, Whereas:
(1) To ensure the fair treatment of all trading venues across the Union contributing data to the consolidated tape provider (CTP) for shares and exchange traded funds (ETFs), it is crucial to clearly specify the methodology that the consolidated tape should apply when redistributing
part of its revenues to data contributors. Therefore, it is necessary to further specify the
minimum frequency at which the CTP should determine the relative share of (or percentage of) revenue to be redistributed per eligible trading venue. Accordingly, the CTP should redistribute revenues at least annually, although it may opt for a more frequent redistribution. (3) The weightings to be assigned to the criteria laid down in Article 27h(6) of Regulation (EU) No 600/204 for the revenue redistribution scheme, which are relevant for the determination of part of the revenues to be redistributee, should satisfy two conditions. Firstly, they should maximise the relative share of revenues that both, an eligible trading venue that meets all criteria laid down in Article 27h(6) of Regulation (EU) No 600/204, as well as, an opting-in eligible trading venue would have received among the different scenarios analysed. Secondly, the weightings should sum up to 10, being the equivalent to 100%. The weightings that satisfy these conditions, all else being equal are 4.5 for the criterion laid down in Article 1 OJ L 173 12.6.2014, p. 84.

27h(6) point (a), 4.0 for the criterion laid down in Article 27h(6) point (b) and 1.5 for the criterion laid down inArticle 27h(6) point (c). (4) It is necessary to ensure that the CTP uses the suspension of the revenue redistribution scheme in an equitable manner to deter serious and repeated breaches of the data requirements specified in Articles 22a, 22b, and 22c of Regulation (EU) No 600/2014. To this end, this Regulation specifies the criteria and the circumstances that the CTP should take into account when deciding to temporarily suspend the participation of data contributors in that scheme. The CTP should supplement and complement these criteria and circumstances to ensure the decision to suspend and the duration of the suspension take into consideration the seriousness of the breach, its impact on the revenue redistribution scheme, and any corrective actions put in place by the data contributor. (5) In order for the revenue redistribution scheme to foster an on-going dialogue between the CTP and each data contributor on the quality of data submitted, and thus for the suspension of the participation of a data contributor in that scheme to be used as a measure of last resort, this Regulation specifies minimum requirements ensuring that the process for suspending a data contributor from that scheme is transparent, non-discriminatory, fair and efficient. In particular, the CTP should share with suspended data contributors the information supporting the suspension and allow data contributors to submit additional information to the CTP. (6) In cases where the CTP confirms its decision to suspend a data contributor from the revenue redistribution scheme, the retained revenue may be redistributed to the other data contributors in the redistribution window following the final decision. (7) In cases where the CTP revises its decision to suspend a data contributor from the revenue redistribution scheme based on the additional information shared by that data contributor, the retained revenue should be redistributed to that data contributor at the next redistribution window following the final decision, with interest corresponding to the average rate of the European Central Bank’s deposit facility during the suspension period. (8) This Regulation is based on the draft regulatory technical standards submitted to the Commission by the European Securities and Markets Authority (ESMA). (9) ESMA has conducted open public consultations on the draft regulatory technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Securities and Markets Stakeholder Group established in

accordance with Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council ( ), HAS ADOPTED THIS REGULATION:
Article 1
Determination of the amount of revenues to be redistributed, of eligible data contributors and relevant assessment periods (Article 27h(8), point (b), of Regulation (EU) No 600/2014)

For the purposes of redistributing part of its revenues generated by the consolidated
tape to data contributors, the CTP shall first determine:
(a) the amount of revenues to be redistributed based on the total revenues generated by the CTP over the calculation window as specified by the CTP; and (b) the list of data contributors that are regulated markets, MTFs or SME growth markets and that transmitted data to the CTP over the assessment period, either for the full period or for part of it (the ‘eligible data contributors’).
The CTP shall then perform the calculations set out in Articles 2 to 5 at least on an
annual basis and, in any case, before the twentieth day of the month following the calculation window. Such calculations shall be performed using the trades recorded by each data contributor over the assessment period. The CTP shall apply the resulting percentages of those calculations retroactively over the latest calculation window.
For the purposes of paragraphs 1 and 2, the calculation window shall correspond to
each individual period over which part of the revenues of the CTP are redistributed.
For the purposes of paragraph 2, the assessment period shall correspond to the twelve
months over which the turnover, to be multiplied by each individual weight, is considered. 2 Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2010, p. 84).

Article 2
Methodology for calculating the amount of revenues to be redistributed under 27h(6), point (a), of Regulation (EU) No 600/2014 and weighting assigned to the related criterion (Article 27h(8), points (a) and (b), of Regulation (EU) No 600/2014)
1. For the purposes of calculating the amount of the revenues to be redistributed to eligible
data contributors that meet the criterion under Article 27h(6), point (a), of Regulation (EU) No 600/2014, the CTP shall determine the total annual trading volume generated in shares for each data contributor by summing each transaction record received by that data contributor.
2. The CTP shall determine the total annual trading volume of shares in the Union by
summing all transaction records received by each trading venue and approved publication arrangement.
3. For the purpose of the calculations in paragraphs 1 and 2, transactions shall be single
counted.
4. To determine whether eligible data contributors meet the criterion laid down in Article
27h(6), point (a), of Regulation (EU) No 600/2014, the CTP shall divide the amount determined under paragraph 1 by that determined under paragraph 2 for each operating Market Identifier Code (MIC) as defined in ISO 10383.
5. For those data contributors meeting the criterion laid down in Article 27h(6), point (a),
of Regulation (EU) No 600/2014, identified by segment MIC as defined in ISO 10383 or, by operating MIC whenever there is no segment MIC, the CTP shall apply a weight of 4.5 to the relevant annual trading volume referred to in Article 27h(7) point (a), of that Regulation generated by that MIC.
Article 3
Methodology for calculating the amount of revenues to be redistributed under Article 27h(6), point (b), of Regulation (EU) No 600/2014 and weighting assigned to the related criterion (Article 27h(8), points (a) and (b), of Regulation (EU) No 600/2014)
1. To determine whether eligible data contributors meet the criterion laid down in Article
27h(6), point (b), of Regulation (EU) No 600/2014, the CTP shall for each data contributor assess whether the data contributor on the basis of the information provided per financial instrument pursuant to Table 3 of the Annex to Commission Delegated Regulation (EU)

2017/585 (
), provides initial admission to trading of shares or ETFs on 27 March 2019 or thereafter. The CTP shall determine:
(a) for those data contributors meeting the criterion laid down in Article 27h(6), point (a), of Regulation (EU) No 600/2014, the total annual trading volume generated in shares and ETFs by summing each transaction record received by that data contributor; (b) for those data contributors not meeting the criterion laid down in Article 27h(6), point (a), of Regulation (EU) No 600/2014, the total annual trading volume pertaining to those shares and ETFs referred to in the first subparagraph. For the purpose of the calculations in points (a) and (b), transactions shall be single counted.
2. For data contributors with instruments meeting the criterion laid down in Article 27h(6),
point (b), of Regulation (EU) No 600/2014 identified by segment MIC and, by operating MIC whenever there is no segment MIC, the CTP shall apply a weight of 4.0 to the relevant annual trading volume as per Article 27h(7), point (b), of that Regulation generated by that MIC.
Article 4
Methodology for calculating the amount of revenues to be redistributed under Article 27(h)(6), point (c), of Regulation (EU) No 600/2014 and weighting assigned to the related criterion (Article 27h(8), points (a) and (b), of Regulation (EU) No 600/2014)

To determine whether eligible data contributors meet the criterion laid down in Article
27h(6), point (c), of Regulation (EU) No 600/2014, the CTP shall for each data contributor determine the total annual pre-trade transparent trading volume generated in shares and ETFs recorded per financial instrument by each data contributor separately. For the purpose of this calculation, the CTP shall include all transaction records received from the trading venue which are not flagged as negotiated transactions subject to conditions other than the current market price (PRIC flag), reference price transactions (RFPT flag), as negotiated transactions in liquid financial instruments (NLIQ flag), or negotiated transactions in illiquid financial instruments (OILQ flag) as defined in Table 4 of Annex I to Commission 3 Commission Delegated Regulation (EU) 2017/585 of 14 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the data standards and formats for financial instrument reference data and technical measures in relation to arrangements to be made by the European Securities and Markets Authority and competent authorities (OJ L 87, 31.3.2017, p. 368).

Delegated Regulation (EU) No 2017/587 (
) as well as those flagged as transactions subject to the pre-trade large in scale waiver (NTLS flag) as defined in Table 7 of Annex II to [the regulatory technical standards adopted pursuant to Article 22b(3) of Regulation (EU) No 600/2014]. Transactions shall in all cases be single counted.
2. For data contributors meeting the criterion laid down in Article 27h(6), point (c), of
Regulation (EU) No 600/2014 identified by segment MIC and, by operating MIC whenever there is no segment MIC, the CTP shall apply a weight of 1.5 to the relevant trading volume as per Article 27h(7), point (c), of that Regulation generated by that MIC, as determined under the first subparagraph of paragraph 1.
Article 5
Methodology for determining the amount of the revenue to be redistributed (Article 27h(8), point (b), of Regulation (EU) No 600/2014)
1. For each eligible data contributor, the CTP shall sum the results of the multiplications
of the weights by the trading volumes as set out in Articles 2 to 4.
2. The CTP shall determine the total sum of the results of the calculations under
paragraph 1 for all eligible data contributors.
3. The CTP shall divide, the sum per data contributor as set out in paragraph 1 by the
total sum as set out in paragraph 2. The resulting percentages for each data contributor shall be multiplied by the total monetary amount of revenues to be redistributed.
Article 6
Criteria for temporary suspension of the revenue redistribution scheme (Article 27h(8), point (c), of Regulation (EU) No 600/2014)
1. Where the CTP finds that a data contributor has seriously and repeatedly breached the
data requirements referred to in Articles 22a, 22b and 22c of Regulation (EU) 600/2014, it may decide to temporarily suspend the participation of that data contributor in the revenue redistribution scheme. 4 Commission Delegated Regulation (EU) 2017/587 of 14 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards on transparency requirements for trading venues and investment firms in respect of shares, depositary receipts, exchange-traded funds, certificates and other similar financial instruments and on transaction execution obligation in respect of certain shares on a trading venue or by a systematic internaliser (OJ L 87, 31.3.2017, p. 387).

2. When deciding whether to suspend the participation of the data contributor in the
revenue redistribution scheme as referred to in paragraph 1, the CTP shall take into account, whether, in particular, any of the following criteria is met:
(a) for three consecutive days, the data contributor has failed to submit trade or order reports or has submitted more than 3 trade or order reports later than as close to real time as technically possible, as defined in the [regulatory technical standards adopted pursuant to
Article 22b(3) of Regulation (EU) No 600/2014], and those trade or order reports account for
at least a volume of transactions or orders that in a percentage is not lower than the 10% of the total volume of transactions or orders submitted in a single day; (b) for three consecutive days, the data contributor has submitted more than 3 trade or orders reports that are incomplete or contain potentially erroneous data, as defined in the [regulatory technical standards adopted pursuant to Article 22b(3) of Regulation (EU) No 600/2014], and those trade or order reports account for at least a volume of transactions or orders that in percentage is not lower than the 10% of the total volume of transactions or orders submitted in a single day; (c) the data contributor does no longer meet the minimum quality of the transmission protocols, in accordance with [the regulatory technical standards adopted pursuant to Article 22b(3) of Regulation (EU) No 600/2014]; (d) the data contributor does no longer meet the minimum the level of accuracy to which business clocks are to be synchronised, in accordance with the requirements specified in the [regulatory technical standards adopted pursuant to Article 22b(3) of Regulation (EU) No 600/2014].
3. The CTP may decide not to suspend the participation of the data contributor in the revenue
redistribution scheme, where any circumstance occurred which is out of the ordinary, is unavoidable or unexpected, and caused what would have been otherwise found by the CTP as a serious and repeated breach by the data contributor of the data requirements referred to in Articles 22a, 22b and 22c of Regulation (EU) No 600/2014.
Article 7
Minimum requirements on fair procedure for the revenue redistribution scheme (Article 27h(8), point (c), of Regulation (EU) No 600/2014)
1. Where the CTP has found a repeated and serious breach by a data contributor in
accordance with the criteria set out in Article 6(2), points (a) and (b), it shall notify the data contributor as soon as practically possible and, in any case, not later than within two business

days as of the moment when it has found the breach. The CTP shall identify in this notification the trade or order reports in relation to which the data contributor is deemed in breach and the number of days in relation to which revenue redistribution may be suspended, and shall provide information to the data contributor supporting its assessment. The data contributor may request within one week from the notification referred to in the first subparagraph that the CTP reviews its assessment based on additional information proving that the data requirements were not breached, or that an exceptional circumstance occurred, in accordance with Article 6(3). The CTP shall review its assessment based on the information provided by the data contributor and, where it considers this information not complete, shall set a deadline by which the data contributor is to provide additional information.
2. On the last day of the period in relation to which revenue is redistributed, the CTP shall draw
up its final assessment of the breaches found in accordance with paragraph 1, and of the breaches found in accordance with Article 6(2), points (c) and (d). The CTP shall inform the data contributor of its final assessment not later than within two business days after the last day of the period in relation to which revenue is redistributed. The CTP shall inform the data contributor of the reasons for its final assessment, including the data requirements deemed in breach, and specify the amount of revenue that may be retained. A data contributor may request within one week from receipt of the information referred to in the second subparagraph that the CTP reviews its final assessment based on additional information proving that the data requirements were not breached, or that an exceptional circumstance occurred, in accordance with the conditions set out in Article 6(3). The CTP shall review its final assessment based on the information provided by the data contributor and, where it considers this information not complete, shall set a deadline by which the data contributor is to provide additional information.
3. The CTP shall inform the data contributor of its final decision on the suspension of the
revenue redistribution scheme not later than two weeks after informing the data contributor of its final assessment referred to in paragraph 2, second subparagraph.
Article 8
Conditions for the resumption of revenue redistribution and for provision of revenue retained plus interest (Article 27h(8) point (c), of Regulation (EU) No 600/2014)

1. Where, on the basis of the additional information provided by the data contributor in
accordance with Article 7(1), third subparagraph and Article 7(2) third subparagraph, the CTP finds that the data requirements have not been breached, it shall redistribute the revenue retained, with interest, no later than two weeks after the final decision referred to Article 7(3).
2. For the purpose of the calculation of the interest referred to in paragraph 1, the CTP
shall take into account the average rate of the European Central Bank’s deposit facility, or where the CTP is established in a Member State whose currency is not the Euro, the official interest rate for overnight credit charged by the central bank of the Member State where the CTP is established, over the period of the suspension of the revenue distribution scheme.
Article 9
Entry into force
1. This Regulation shall enter into force on the twentieth day following that of its
publication in the Official Journal of the European Union.
2. This Regulation shall be binding in its entirety and directly applicable in all Member
States.
Done at Brussels, [DD MM 2024]
For the Commission
The President

7.3.3 Draft RTS on the synchronisation of business clocks
COMMISSION DELEGATED REGULATION (EU) XXXX/XXX of XXX supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards for specifying the level of accuracy to which business clocks are to be synchronised and repealing Delegated Regulation (EU) 2017/574 (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012, and Article 22c thereof, Whereas:
(1) Clock synchronisation has a direct impact in many areas. In the area of market integrity, competent authorities need to be able to reconstruct all events relating to an order throughout the lifetime of each order in an accurate time sequence. Competent authorities need to be able to reconstruct these events over multiple trading venues on a consolidated level to be able to conduct effective cross-venue monitoring on market abuse. It is therefore necessary to establish a common reference time and rules on maximum divergence from the common reference time to ensure that all operators of trading venues and their members or participants are recording the date and time based on the same time source and in accordance with consistent standards. It is also necessary to provide for accurate time stamping to allow competent authorities to distinguish between different reportable events which may otherwise appear to have taken place at the same time. (2) In the context of the consolidation of data, clock synchronisation enables a meaningful comparison of the timestamps reported by different entities, such that pre- and post-trade transparency data can be part of a reliable consolidated tape. It is also essential for conducting cross-venue monitoring of orders and detecting instances of market abuse and allows for a

clearer comparison between the transaction and the market conditions prevailing at the time of their execution. (3) However, the achievement of these objectives does not require all entities to synchronise their clocks to the same level of accuracy. It is thus necessary to calibrate the expected level of accuracy to the type of activities that each entity performs, and to the latency levels of the systems that they operate, so to avoid the imposition of unnecessary operational costs to the entities subject to this requirement. (4) As it concerns operators of trading venues and systematic internalisers, the number of orders that they receive every second can be very high, much higher than that of executed transactions. Especially when using high-frequency trading techniques, this may extend to several thousands of orders per second depending on the trading venue or systematic internaliser, the type of members, participants or users and clients, and the financial instruments' volatility and liquidity. As a result, it is necessary to establish minimum granularity requirements for recording the date and time of reportable events by operators of trading venues and systematic internalisers that are proportionate to the speed at which they process and acknowledge orders. (5) Members, participants or users of trading venues operate systems that tend to match the nature and complexity of the trading activity that they perform on a given trading venue. Consequently, the applicable accuracy levels should be commensurate to the type of trading activity. (6) There are, however, trading models for which increased accuracy might not be relevant or feasible. Voice trading systems or request for quote systems where the response requires human intervention or does not allow algorithmic trading, or systems which are used for concluding negotiated transactions should be subject to different accuracy standards. Trading venues operating those trading systems are not typically susceptible to the high volume of events that can happen within the same second, meaning that it is not necessary to impose a finer granularity to time stamping of those events since it is less likely that there would be multiple events occurring at the same time. In addition, trades on those trading venues may be agreed using manual methods which can take time to agree. In those trading venues there is also an inherent delay between the moment when the trade is executed and the moment when the trade is recorded in the trading system, meaning that applying more stringent accuracy requirements would not necessarily lead to more meaningful and accurate record keeping by the operator of the trading venue, its members or participants. (7) As regards approved publication arrangements, designated publishing entities and consolidated tape providers, it should be noted that these entities operate systems for the purposes of data reporting, publication, consolidation and dissemination, and thus they
feature a weaker link to the type of trading activity that originated the order and transaction data they process. They should thus be subject to absolute accuracy requirements.

(8) Competent authorities need to understand how trading venues and their members or participants are ensuring their traceability to Coordinated Universal Time (UTC). This is because of the complexity of the different systems and the number of alternative methods that can be used to synchronise to UTC. Given that clock drift can be affected by many different elements, it is also appropriate to determine an acceptance level for the maximum divergence from UTC. (9) Commission Delegated Regulation (EU) No 2017/574 of 7 June 2016 supplementing Directive (EU) No 2014/65/EU of the European Parliament and of the Council with regard to regulatory technical standards for the level of accuracy of business clocks was adopted on the basis of Article 50 of Directive 2014/65/EU MiFID II. Since that Article was deleted, the clock synchronisation requirements are now established in Article 22c of Regulation (EU) No 600/2014. Following the deletion of Article 50 Directive 2014/65/EU and the establishment of clock synchronisation requirements in Article 22c of Regulation (EU) No 600/2014, it is necessary to update the regulatory framework to reflect this legislative change. Consequently, Commission Delegated Regulation (EU) 2017/574 should be repealed, and references to that Regulation should be understood as references to this Regulation. (10) This Regulation is based on the draft regulatory technical standards submitted to the Commission by the European Securities and Markets Authority. (11) The European Securities and Markets Authority has conducted open public consultations on the draft regulatory technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Securities and Markets Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council, HAS ADOPTED THIS REGULATION:
Article 1
Reference time
Operators of trading venues and their members, participants or users, systematic internalisers, designated publishing entities, APAs and CTPs shall synchronise the business clocks they use to record the date and time of any reportable event with the Coordinated Universal Time (UTC) issued and maintained by the timing centres listed in the database maintained by the Bureau international des poids et mesures. Operators of trading venues and their members, participants or users, systematic internalisers, designated publishing entities, APAs and CTPs may also synchronise the business clocks they use to record the date and time of any reportable event with UTC disseminated by a satellite system, provided that any offset from UTC is accounted for and removed from the timestamp.

Article 2
Level of accuracy for operators of trading venues and systematic internalisers
1. Operators of trading venues and systematic internalisers shall ensure that their
business clocks adhere to the levels of accuracy specified in Table 1 of the Annex according to the gateway-to-gateway latency of each of their trading systems. Gateway to gateway latency shall be the time measured from the moment a message is received by an outer gateway of the trading venue's system, sent through the order submission protocol, processed by the matching engine, and then sent back until an acknowledgement is sent from the gateway.
2. By derogation from paragraph 1, operators of trading venues and systematic
internalisers that operate a voice trading system, request for quote system where the response requires human intervention or does not allow algorithmic trading, or a system that formalises negotiated transactions in accordance with Article 4(1)(b) of Regulation (EU) No 600/2014 of the European Parliament and of the Council (2) shall ensure that their business clocks do not diverge by more than one second from UTC referred to in Article 1 of this Regulation. The operator of the trading venue or systematic internaliser shall ensure that times are recorded to at least a one second granularity.
3. Operators of trading venues and systematic internalisers that operate multiple types of
trading systems shall ensure that each system adheres to the level of accuracy applicable to that system in accordance with paragraphs 1 and 2.
Article 3
Level of accuracy for members, participants or users of a trading venue
1. Members, participants or users of trading venues shall ensure that their business clocks
used to record the time of reportable events adhere to the level of accuracy specified in Table 2 of the Annex.
2. Members, participants or users of trading venues that engage in multiple types of
trading activities shall ensure that the systems that they use to record reportable events adhere to the level of accuracy applicable to each of these trading activities in accordance with the requirements set out in Table 2 of the Annex.
Article 4
Level of accuracy for designated publishing entities

1. Designated publishing entities shall record the date and time of reportable events up to
one millisecond or better.
2. Designated publishing entites shall ensure that their business clocks used to record the
time of reportable events do not diverge by more than one millisecond from the reference time defined in Article 1.
3. By derogation from paragraphs 1 and 2, designated publishing entities that have also
acquired the status of systematic internaliser shall comply with Article 2.
Article 5
Level of accuracy for consolidated tape providers
1. Consolidated tape providers shall record the date and time of reportable events up to
one millisecond or better.
2. Consolidated tape providers shall ensure that their business clocks used to record the
time of reportable events do not diverge by more than one millisecond from the reference time defined in Article 1.
Article 6
Level of accuracy for approved publication arrangements
1. Approved publication arrangements shall record the date and time of reportable events
up to one millisecond or better.
2. Approved publication arrangements shall ensure that their business clocks used to
record the time of reportable events do not diverge by more than one millisecond from the reference time defined in Article 1.
Article 7
Compliance with the maximum divergence requirements Operators of trading venues and their members or participants shall establish a system of traceability to UTC. They shall be able to demonstrate traceability to UTC by documenting the system design, functioning and specifications. They shall be able to identify the exact point at which a timestamp is applied and demonstrate that the point within the system where the timestamp is applied remains consistent. They shall conduct a review of the compliance of the traceability system with this Regulation at least once a year.

Article 8
Repeal
Commission Delegated Regulation (EU) 2017/574 is repealed with effect from the date of entry into force of this Regulation. References to the repealed Regulation shall be construed as references to this Regulation.
Article 9
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, For the Commission The President

ANNEX
Table 1
Level of accuracy for operators of trading venues and systematic internalisers Gateway-to-gateway latency time of the trading system Maximum divergence from UTC Granularity of the timestamp

1 millisecond 1 millisecond 1 millisecond or better
≤ 1 millisecond 100 microseconds Increase granularity to 0.1 microseconds or better
Table 2
Level of accuracy for members, participants or users of a trading venue Type of trading activity Description Maximum divergence from UTC Granularity of the timestamp Activity using high frequency algorithmic trading technique High frequency algorithmic trading technique. microseconds
0.1 microseconds or
better
Activity on voice trading systems
Voice trading systems as defined in Article 5(5) of Commission Delegated Regulation (EU) 2017/583 (1) 1 second 1 second or better Activity on request for quote systems where the response requires human intervention or where the system does not allow algorithmic trading Request for quotes systems as defined in
Article 5(4) of Delegated
Regulation (EU) 2017/583
1 second 1 second or better
Activity of concluding negotiated transactions Negotiated transaction as set out in Article 4(1)(b) of 1 second 1 second or better

Regulation (EU) No
600/2014.
Any other trading activity All other trading activity not covered by this table. 1 millisecond 1 millisecond or better (1) Commission Delegated Regulation (EU) 2017/583 of 14 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council on markets in financial instruments with regard to regulatory technical standards on transparency requirements for trading venues and investment firms in respect of bonds, structured finance products, emission allowances and derivatives (OJ L 87, 31.3.2017, p. 229).

7.3.4 Draft RTS on the authorisation of APAs and ARMs
COMMISSION DELEGATED REGULATION (EU) 20XX/XXX of XX XXXX 202X supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards on the authorisation, organisational requirements for approved publication arrangements and approved reporting mechanisms (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of 15 May 2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/2012 ( ) and in particular Article 27d(4), second subparagraph, Article 27g(6), second subparagraph thereof, Article 27g(8), second subparagraph thereof and Article 27i(5), second subparagraph thereof, Whereas:

Commission Delegated Regulation (EU) 2017/571 of 2 June 2016 supplementing Directive
2014/65/EU of the European Parliament and of the Council with regard to regulatory technical standards on the authorisation, organisational requirements and the publication of transactions for data reporting services providers ( ) covers three different types of entities: approved reporting mechanisms (ARMs), approved publication arrangements (APAs) and consolidated tape providers (CTPs). Upon entry into force of Regulation (EU) 2024/791 ( ) authorisation requirements of CTPs are covered in Commission delegated regulation [delegated regulation adopted under Article 27db and 27f of Regulation (EU) No 600/2014]. Furthermore, certain authorisation and organisational requirements addressed 1 OJ L 173, 12.6.2014, p. 84. 2 OJ L 87, 31/03/2017, p. 126. 3 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, PE/63/2023/REV/1, OJ L, 2024/791, 8.3.2024.

to APAs and ARMs have been revised. Since these amendments would also necessitate substantial changes to Commission Delegated Regulation (EU) 2017/571, in order to improve the clarity and legal certainty, Commission Delegated Regulation (EU) 2017/571 should be repealed by this Regulation.
2. An applicant seeking authorisation as an APA or ARM should provide in its application for
authorisation a programme of operations and an organisational chart. The organisational chart should identify who is responsible for the different activities to enable European Securities and Markets Authority (ESMA) or the national competent authority to assess whether the data reporting services provider has sufficient human resources and oversight over its business. The organisational chart should not only cover the scope of the data reporting services but should also include any other services that the entity provides as this may highlight areas which may affect the independence of the data reporting services provider and give rise to a conflict of interest. An applicant seeking authorisation as an APA or ARM should also provide information on the composition, functioning and independence of its governing bodies in order for competent authorities to be able to assess whether the policies, procedures and corporate governance structure ensure the independence of the APA or ARM and the avoidance of conflicts of interest.
3. Conflicts of interest can arise between APAs or ARMs, clients using their services to meet
their regulatory obligations and other entities purchasing data from data reporting services providers. In particular, those conflicts may arise where the data reporting services provider is engaged in other activities such as acting as a market operator, investment firm or trade repository. If conflicts are left unaddressed, this could lead to a situation where the data reporting services provider has an incentive to delay publication or submission of data or to trade on the basis of the confidential information it has received. The data reporting services provider should therefore adopt a comprehensive approach to identifying, preventing and managing existing and potential conflicts of interest, including preparing an inventory of conflicts of interest and implementing appropriate policies and procedures to manage those conflicts and, where necessary, separate business functions and personnel to limit the flow of sensitive information between different business areas of the data reporting services provider.
4. All members of the management body of an APA or ARM should be persons who are of
sufficiently good repute and possess sufficient knowledge, skills and experience, as those persons play a key role in ensuring that the data reporting services provider meets its regulatory obligations and contribute to the business strategy of the data reporting services provider. It is therefore important for the data reporting services provider to demonstrate that it has a robust process for appointing and evaluating the performance of members of the management body and that clear reporting lines and regular reporting to the management body are in place.

APAs and ARMs fall under the scope of Regulation (EU) 2022/2554 (
) and are therefore subject to the digital operational resilience requirements included therein. Therefore, APAs and ARMs should demonstrate compliance with all obligations under Regulation (EU) 2022/2554 applicable to APAs and ARMs. They should demonstrate compliance in the areas of ICT risk-management, ICT third-party risk management, business continuity and back-up facilities, testing and capacity, security and incident reporting to ESMA or the national competent authority. It is therefore important that applicants are able to demonstrate during the authorisation phase their ability to comply with the requirements in Regulation (EU) 2022/2554 as soon as they start operating as an APA or an ARM.
An investment firm which has transaction reporting obligations, known as a ‘reporting firm’,
may choose to use a third party to submit transaction reports on its behalf to an ARM, that is a ‘submitting firm’. By virtue of its role the submitting firm will have access to the confidential information that it is submitting. However, the submitting firm should not be entitled to access any other data about the reporting firm or the reporting firm's transactions which are held at the ARM. Such data may relate to transaction reports which the reporting firm has submitted itself to the ARM or which it has sent to another submitting firm to send to the ARM. This data should not be accessible to the submitting firm as it may contain confidential information such as the identity of the reporting firm's clients.
An APA or ARM should monitor that the data it is publishing or submitting is accurate and
complete and should ensure that it has mechanisms for detecting errors or omissions caused by the client or itself. In the case of an ARM, this can include reconciliations of a sample population of data submitted to the ARM by an investment firm or generated by the ARM on the investment firm's behalf with the corresponding data provided by the competent authority. The frequency and extent of such reconciliations should be proportionate to the volume of data handled by the ARM and the extent to which it is generating transaction reports from clients' data or passing on transaction reports completed by clients. In order to ensure timely reporting that is free of errors and omissions an ARM should continuously monitor the performance of its systems.
Where an ARM itself causes an error or omission, it should correct this information without
delay as well as notify ESMA or the competent authority of its home Member State and any competent authority to which it submits reports of the error or omission as those competent authorities have an interest in the quality of the data being submitted to them. The ARM should also notify its client of the error or omission and provide updated 4 REGULATION (EU) 2022/2554 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011, OJ L 333, 27.12.2022, p. 1.

information to the client so that the client's internal records may be aligned with the information which the ARM has submitted to the competent authority on the client's behalf.
9. APAs should be able to delete and amend the information which they receive from an entity
providing them with information to deal with situations where, in exceptional circumstances, the reporting entity is experiencing technical difficulties and cannot delete or amend the information itself. However, APAs should not otherwise be responsible for correcting information contained in published reports where the error or omission was attributable to the entity providing the information. This is due to the fact that APAs cannot know with certainty whether a perceived error or omission is indeed incorrect since they were not party to the executed trade.
10. To facilitate reliable communication between an APA and the investment firm reporting a
trade, particularly in relation to cancellations and amendments of specific transactions, an APA should include in the confirmation messages to reporting investment firms the transaction identification code that has been assigned by the APA when making the information public.
11. To comply with its reporting obligation under Regulation (EU) No 600/2014 an ARM should
ensure the smooth flow of information to and from a competent authority, including the ability to transfer reports and deal with rejected reports. The ARM should therefore be able to demonstrate that it can comply with the technical specifications set out by the competent authority regarding the interface between the ARM and the competent authority.
12. An APA or ARM should also ensure that it stores the transaction and trade reporting
information which it handles for a sufficiently long period of time in order to facilitate the retrieval of historical information by competent authorities.
13. In order to ensure efficient dissemination of information made public by APAs and an easy
access and use of such information by market participants, the information should be published in a machine-readable format through robust channels allowing for automatic access to the data. While websites may not always offer an architecture that is robust and scalable enough and that allows for easy automatic access to data, these technological constraints may be overcome in the future. A particular technology should therefore not be prescribed, but criteria should be set out that need to be met by the technology which is to be used.
14. The provisions in this Regulation are closely linked, since they deal with the authorisation
and organisational requirements for APAs and ARMs. To ensure coherence between those provisions, which should enter into force at the same time, and to facilitate a

comprehensive view by stakeholders and, in particular those subject to the obligations, it is necessary to include these regulatory technical standards in a single Regulation.
15. This Regulation is based on the draft regulatory technical standards submitted by ESMA
to the Commission.
16. ESMA has conducted open public consultations on the draft regulatory technical standards
on which this Regulation is based, analysed the potential related costs and benefits and requested the opinion of the Securities and Markets Stakeholder Group established by
Article 37 of Regulation (EU) No 1095/2010 (
)
HAS ADOPTED THIS REGULATION:
CHAPTER I
AUTHORISATION
(Article 27d(1) of Regulation (EU) No 600/2014)
Article 1
Information to competent authorities

An applicant APA or ARM seeking authorisation shall submit to ESMA or the national
competent authority where relevant, the information set out in Chapter I, articles 2 to 7 and the information regarding all the organisational requirements set out in Chapter II.
An APA or ARM shall promptly inform ESMA or the national competent authority where
relevant of any material change to the information provided at the time of the authorisation and thereafter. 5 REGULATION (EU) No 1095/2010 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC, OJ L 331, 15/12/2010, p. 84.

Article 2
Information on the organisation

An applicant APA or ARM seeking authorisation shall include in its application for
authorisation a programme of operations referred to in Article 27d(1) of Regulation (EU) 600/2014. The programme of operations shall include the following information:
a. information on the organisational structure of the applicant, including an organisational chart and a description of the human, technical, and legal resources allocated to its business activities; b. information on the operational separation policies and procedures to ensure segregation between the APA or ARM and any other activity performed by the firm;
c. information on the compliance policies and procedures of the APA or ARM,
including:
i. the name of the person or persons responsible for the approval and
maintenance of those policies;
ii. the arrangements to monitor and enforce the compliance policies and
procedures;
iii. the measures to be undertaken in the event of a breach which may result
in a failure to meet the conditions for initial authorisation;
iv. a description of the procedure for reporting to ESMA or the national
competent authority where relevant, any breach which may result in a failure to meet the conditions for initial authorisation; d. a list of all outsourced functions and resources allocated to the control of the outsourced functions;
An APA or ARM offering services other than data reporting services shall describe
those services in the organisational chart.
Article 3

Information on the ownership
1. An applicant APA or ARM seeking authorisation shall include in its application for
authorisation:
a. a list containing the name of each person or entity who directly or indirectly holds 5 % or more of the applicant’s capital or of its voting rights or whose holding makes it possible to exercise a significant influence over the applicant’s management; b. a list of any undertakings in which a person referred to in point (a) holds 5 % or more of the capital or voting rights or over whose management they exercise a significant influence.
2. An applicant APA or ARM seeking authorisation shall include in its application for
authorisation a chart showing the ownership links between the parent undertaking, subsidiaries and any other associated entities or branches.
3. The undertakings shown in the chart referred to in paragraph 2 shall be identified by
their full name, legal status and legal address.
Article 4
Information on corporate governance
1. An applicant APA or ARM seeking authorisation shall include in its application for
authorisation information on the internal corporate governance policies and the procedures which govern its management body, senior management, and, where established, committees.
2. The information set out in paragraph 1 shall include:
a. a description of the processes for selection, appointment, performance evaluation and removal of senior management and members of the management body; b. a description of the reporting lines and the frequency of reporting to the senior management and the management body;

c. a description of the policies and procedures on access to documents by
members of the management body.
Article 5
Information on the members of the management body

An applicant APA or ARM seeking authorisation shall include in its application for
authorisation the following information in respect of each member of the management body:
a. name, date and place of birth, personal national identification number or an equivalent thereof, address and contact details; b. the position for which the person is or will be appointed;
c. a curriculum vitae evidencing sufficient experience and knowledge to
adequately perform the responsibilities; d. criminal records, notably through an official certificate, or, where such a document is not available in the relevant Member State, a self-declaration of good repute and the authorisation to the competent authority to inquire whether the member has been convicted of any criminal offence in connection with the provision of financial or data services or in relation to acts of fraud or embezzlement; e. a self-declaration of good repute and the authorisation to ESMA or the national competent authority where relevant, to inquire whether the member:
i. has been subject to an adverse decision in any proceedings of a
disciplinary nature brought by a regulatory authority or government body or is the subject of any such proceedings which are not concluded;
ii. has been subject to an adverse judicial finding in civil proceedings
before a court in connection with the provision of financial or data services, or for misconduct or fraud in the management of a business;
iii. has been part of the management body of an undertaking which was
subject to an adverse decision or penalty by a regulatory authority or

whose registration or authorisation was withdrawn by a regulatory authority;
iv. has been refused the right to carry on activities which require
registration or authorisation by a regulatory authority;
v. has been part of the management body of an undertaking which has
gone into insolvency or liquidation while the person held such position or within a year after which the person ceased to hold such position;
vi. has been otherwise fined, suspended, disqualified, or been subject to
any other sanction in relation to fraud, embezzlement or in connection with the provision of financial or data services, by a professional body;
vii. has been disqualified from acting as a director, disqualified from acting
in any managerial capacity, dismissed from employment or other appointment in an undertaking as a consequence of misconduct or malpractice; f. an indication of the minimum time that is to be devoted to the performance of the person's functions within the data reporting services provider; g. a declaration of any potential conflicts of interest that may exist or arise in performing the duties and how those conflicts are managed.
Article 6
Information on internal controls

An applicant APA or ARM seeking authorisation shall include in its application for
authorisation detailed information regarding its control environment. This shall include information regarding its compliance function, risk assessment, internal control mechanisms and the arrangements of its internal audit function.
The detailed information referred to in paragraph 1 shall contain:
a. an outline of the applicant’s control environment, including where it relies on outsourced functions; b. an assessment of its key risks that may arise in the running the APA or ARM;

c. the applicant’s internal control policies and procedures to ensure the
consistent and effective implementation of those policies; d. any policies, procedures and manuals for monitoring and evaluating the adequacy and effectiveness of the applicant’s systems; e. any policies, procedures and manuals for controlling and safeguarding the applicant’s information processing systems; f. the identity of the internal bodies in charge of evaluating any internal control findings.
3. An application for authorisation as an APA or ARMA shall contain the following
information with respect to the applicant’s internal audit function:
a. Information on its adherence to national or international professional standards; b. its internal audit function charter, methodologies, standards and procedures;
c. an explanation of how its internal audit methodology is developed and
applied taking into account the nature of the applicant’s activities, complexities and risks; d. In case there is an Internal Audit Committee, its composition, competences and responsibilities; e. In case there is an Internal Audit Committee, its work plan for the three years following the date of application, focusing on the nature and extent of the applicant’s activities, complexities and risks.
Article 7
Information on digital operational resilience

An applicant APA or ARM seeking authorisation shall include in its application for
authorisation evidence of compliance with the requirements on ICT riskmanagement organisation and capabilities, operational resilience strategy and

testing, incident management and ICT third-party risk monitoring under Regulation (EU) 2022/2554.
2. The information set out in paragraph 1 shall include policies and procedures
regarding the applicant’s arrangements on:
a. ICT risk-management b. ICT-related incident management
c. Digital operational resilience testing
d. ICT third-party risk monitoring.
CHAPTER II
ORGANISATIONAL REQUIREMENTS
(Article 27g(1), (3) and (5), Article 27i(2) and (4) of Regulation (EU) 600/2014)
Article 8
Conflicts of interest

An APA or ARM shall operate and maintain effective administrative arrangements,
designed to prevent conflicts of interest with clients using its services to meet their regulatory obligations and other entities purchasing data from data reporting services providers. Such arrangements shall include policies and procedures for identifying, managing and disclosing existing and potential conflicts of interest and shall contain:
a. an inventory of existing and potential conflicts of interest, setting out their description, identification, prevention, management and disclosure; b. the separation of duties and business functions within the data reporting services provider including:

i. measures to prevent or control the exchange of information where a
risk of conflicts of interest may arise;
ii. the separate supervision of relevant persons whose main functions
involve interests that are potentially in conflict with those of a client;
c. a description of the fee policy for determining fees charged by the data
reporting services provider and undertakings to which the data reporting services provider has close links; d. a description of the remuneration policy for the members of the management body and senior management; e. the rules regarding the acceptance of money, gifts or favours by staff of the data reporting services provider and its management body.
2. The inventory of conflicts of interest as referred to in paragraph 1(a) shall include
conflicts of interest arising from situations where the APA or ARM:
a. may realize a financial gain or avoid a financial loss, to the detriment of a client; b. may have an interest in the outcome of a service provided to a client, which is distinct from the client's interest in that outcome;
c. may have an incentive to prioritize its own interests or the interest of another
client or group of clients rather than the interests of a client to whom the service is provided; d. receive or may receive from any person other than a client, in relation to the service provided to a client, an incentive in the form of money, goods or services, other than commission or fees received for the service.
Article 9
Organisational requirements regarding outsourcing

Without prejudice to the obligations set in Regulation (EU) 2022/2554 on
management of ICT third-party risk, where an APA or ARM arranges for activities to be performed on its behalf by third parties, including undertakings with which it

has close links, it shall ensure that the third-party service provider has the ability and the capacity to perform the activities reliably and professionally.
2. An APA or ARM shall specify which of the activities are to be outsourced, including
a specification of the level of human and technical resources needed to carry out each of those activities.
3. An APA or ARM that outsources activities shall ensure that the outsourcing does
not reduce its ability or power to perform senior management or management body functions.
4. An APA or ARM shall remain responsible for any outsourced activity and shall adopt
organisational measures to ensure:
a. that it assesses whether the third-party service provider is carrying out outsourced activities effectively and in compliance with applicable laws and regulatory requirements and adequately addresses identified failures; b. the identification of the risks in relation to outsourced activities and adequate periodic monitoring;
c. adequate control procedures with respect to outsourced activities, including
effectively supervising the activities and their risks within the data reporting services provider; d. adequate business continuity of outsourced activities; For the purposes of point (d), the data reporting services provider shall obtain information on the business continuity arrangements of the third-party service provider, assess its quality and, where needed, request improvements.
5. An APA or ARM shall ensure that the third-party service provider cooperates with
ESMA or the national competent authority where relevant, in connection with outsourced activities.
6. Where an APA or ARM outsources a critical or important function it shall provide
ESMA or the national competent authority where relevant:
a. the identification of the third-party service provider; b. the organisational measures and policies with respect to outsourcing and the risks posed by it as specified in paragraph 4;

c. internal or external reports on the outsourced activities.
Article 10
Management of incomplete or potentially erroneous information by APAs
1. APAs shall set up and maintain appropriate arrangements to ensure that they
accurately publish the trade reports received from investment firms without themselves introducing any errors or omitting information and shall correct information where they have themselves caused the error or omission.
2. APAs shall continuously monitor in real-time the performance of their IT systems
ensuring that the trade reports they have received have been successfully published.
3. APAs shall perform periodic reconciliations between the trade reports they receive
and the trade reports that they publish, verifying the correct publication of the information.
4. An APA shall confirm the receipt of a trade report to the reporting investment firm,
including the transaction identification code assigned by the APA. An APA shall refer to the transaction identification code in any subsequent communication with the reporting firm in relation to a specific trade report.
5. An APA shall set up and maintain appropriate arrangements to identify on receipt
trade reports that are incomplete or contain information that is likely to be erroneous. These arrangements shall include automated price and volume alerts, taking into account:
a. the sector and the segment in which the financial instrument is traded; b. liquidity levels, including historical trading levels;
c. appropriate price and volume benchmarks;
d. if needed, other parameters according to the characteristics of the financial instrument.

6. Where an APA determines that a trade report it receives is incomplete or contains
information that is likely to be erroneous, it shall not publish that trade report and shall promptly alert the investment firm submitting the trade report.
7. In exceptional circumstances APAs shall delete and amend information in a trade
report upon request from the entity providing the information when that entity cannot delete or amend its own information for technical reasons.
8. APAs shall publish non-discretionary policies on information cancellation and
amendments in trade reports which set out the penalties that APAs may impose on investment firms providing trade reports where the incomplete or erroneous information has led to the cancellation or amendment of trade reports.
Article 11
Management of incomplete or potentially erroneous information by ARMs
1. An ARM shall set up and maintain appropriate arrangements to identify transaction
reports that are incomplete or contain obvious errors caused by clients. An ARM shall perform validation of the transaction reports against the requirements established under Article 26 of Regulation (EU) No 600/2014 for field, format and content of fields in accordance with Table 1 of Annex I to Commission Delegated Regulation (EU) 2017/590 ( ).
2. An ARM shall set up and maintain appropriate arrangements to identify transaction
reports which contain errors or omissions caused by that ARM itself and to correct, including deleting or amending, such errors or omissions. An ARM shall perform validation for field, format and content of fields in accordance with Table 2 of Annex I to Delegated Regulation (EU) 2017/590.
3. An ARM shall continuously monitor in real-time the performance of its systems
ensuring that a transaction report it has received has been successfully reported to the competent authority in accordance with Article 26 of Regulation (EU) No 600/2014. 6 COMMISSION DELEGATED REGULATION (EU) 2017/590 of 28 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the reporting of transactions to competent authorities, OJ L 87, 31/03/2017, p. 449.

4. An ARM shall perform periodic reconciliations at the request of ESMA or the
national competent authority where relevant, or the competent authority to whom the ARM submits transaction reports between the information that the ARM receives from its client or generates on the client's behalf for transaction reporting purposes and data samples of the information provided by the competent authority.
5. Any corrections, including cancellations or amendments of transaction reports, that
are not correcting errors or omissions caused by an ARM, shall only be made at the request of a client and per transaction report. Where an ARM cancels or amends a transaction report at the request of a client, it shall provide this updated transaction report to the client.
6. Where an ARM, before submitting the transaction report, identifies an error or
omission caused by a client, it shall not submit that transaction report and shall promptly notify the investment firm of the details of the error or omission to enable the client to submit a corrected set of information.
7. Where an ARM becomes aware of errors or omissions caused by the ARM itself, it
shall promptly submit a correct and complete report.
8. An ARM shall promptly notify the client of the details of the error or omission and
provide an updated transaction report to the client. An ARM shall also promptly notify ESMA or, where applicable, the competent authority and the competent authority to whom the ARM reported the transaction report about the error or omission.
9. The requirement to correct or cancel erroneous transaction reports or report omitted
transactions shall not extend to errors or omissions which occurred more than five years before the date that the ARM became aware of such errors or omissions.
Article 12
Connectivity of ARMs
1. An ARM shall have in place policies, arrangements and technical capabilities to
comply with the technical specification for the submission of transaction reports required by ESMA or the national competent authority where relevant, and by other competent authorities to whom the ARM sends transaction reports.

2. An ARM shall have in place adequate policies, arrangements and technical
capabilities to receive transaction reports from clients and to transmit information back to clients. The ARM shall provide the client with a copy of the transaction report which the ARM submitted to the competent authority on the client's behalf.
Article 13
Machine readability
1. APAs shall publish the information which has to be made public in accordance with
Article 27g(1) of Regulation (EU) No 600/2014 in a machine readable way.
2. Information shall only be considered published in a machine-readable way where
all of the following conditions are met:
a. it is a file format structured so that software applications can easily identify, recognise and extract specific data; b. it is stored in an appropriate IT architecture that enables automatic access;
c. it is robust enough to ensure continuity and regularity in the performance of
the services provided and ensures adequate access in terms of speed; d. it can be accessed, read, used and copied by computer software that is free of charge and publicly available. For the purposes of point (a) of the first subparagraph, the electronic format shall be specified by free, non-proprietary and open standards.
3. For the purposes of point(a) of the first subparagraph of paragraph (2), electronic
format shall include the type of files or messages, the rules to identify them, and the name and data type of the fields they contain.
4. APAs shall:
a. make instructions available to the public, explaining how and where to easily access and use the data, including identification of the electronic format; b. make public any changes to the instructions referred to in point (a) at least three months before they come into effect, unless there is an urgent and duly justified need for changes in instructions to take effect more quickly;

c. include a link to the instructions referred to in point (a) on the homepage of
their website.
Article 14
Details to be published by the APA

An APA shall make public:
(a) for transactions executed in respect of shares, depositary receipts, exchangetraded funds (ETFs), certificates and other similar financial instruments, the details of a transaction specified in Tables 2 and 3 of Annex I to Delegated Regulation (EU) 2017/587 and, use the appropriate flags listed in Table 4 of Annex I to Delegated Regulation (EU) 2017/587; (b) for transactions executed in respect of bonds, structured finance products, emission allowances and derivatives the details of a transaction specified in Tables 1 and 2 of Annex II to Delegated Regulation (EU) 2017/583 and use the appropriate flags listed in Table 3 of Annex II to Delegated Regulation (EU) 2017/583.
Article 15
Repeal
Commission Delegated Regulation (EU) 2017/571 is repealed.
References to the repealed Regulation shall be construed as references to this Regulation.
Article 16
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. This Regulation shall be binding in its entirety and directly applicable in all Member States.

Done at Brussels, XX XXXX.
For the Commission
The President

7.3.5 Draft ITS on the authorisation of APAs and ARMs
COMMISSION IMPLEMENTING REGULATION (EU) 20XX/XXX of XX XXXX 202X laying down implementing technical standards for the application of Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to the standard forms, templates and procedures for the authorisation of approved publication arrangements and approved reporting mechanisms and related notifications (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of 15 May 2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/2012 ( ), and in particular Article 27d(5), second subparagraph, thereof, Whereas:

Commission Delegated Regulation (EU) 2017/1110 ( 2
) provides standard forms, templates and procedures for the authorisation indistinctly of all data reporting services providers and related notifications. With the entry into force of Regulation (EU) 2024/791 of the European Parliament and of the Council ( 3 ), standard forms, templates and procedures for the authorisation of consolidated tape providers (CTPs) and related notifications are now covered in Commission Implementing Regulation (EU) 20XX/XXX [Implementing Regulation adopted under Article 27db(8) of Regulation (EU) No 600/2014]. In order to 1 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84). 2 Commission Implementing Regulation (EU) 2017/1110 of 22 June 2017 laying down implementing technical standards with regard to the standard forms, templates and procedures for the authorisation of data reporting services providers and related notifications pursuant to Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (OJ L 162, 23.6.2017, p. 3). 3 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 (OJ L 791, 8.3.2024, p.1).

improve the clarity and legal certainty, Delegated Regulation (EU) 2017/1110 should be repealed by this Regulation.
2. It is appropriate to set out common standard forms, templates and procedures to ensure a
common understanding and enforcement among competent authorities, as defined in
Article 2(1), point (18), of Regulation (EU) No 600/2014, of the authorisation process
regarding the provision of data reporting services by approved publication arrangements (APAs) and approved reporting mechanisms (ARMs) as well as to ensure efficient information flows. In order to facilitate communications between the applicant and the competent authority, competent authorities should designate a contact point and should publish the information on that contact point on their website.
3. The organisational requirements for APAs and ARMs differ from each other in some
respects. As a result, an applicant should only be required to include in its application the information needed for assessing the application for the data reporting service it intends to provide.
4. In order to allow competent authorities to assess whether changes to the management
body of an APA or ARM may pose a threat to the effective, sound and prudent management of the APA or ARM and to adequately take into consideration the interests of its clients and the integrity of the market, it is appropriate to set out clear time limits for the submission of information on those changes.
5. APAs and ARMs should be able to submit information on a change to the management
body after that change takes effect where the change is due to factors beyond the control of the data reporting services provider.
6. This Regulation is based on the draft implementing technical standards submitted to the
Commission by the European Securities and Markets Authority (ESMA).
7. ESMA has conducted open public consultations on the draft implementing technical
standards on which this Regulation is based. ESMA has not analysed potential related costs and benefits as this would have been disproportionate in relation to their scope and impact.

8. ESMA has requested the advice of the Securities and Markets Stakeholder Group
established by Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council ( 4 ), HAS ADOPTED THIS REGULATION:
Article 1
Designation of a contact point
Competent authorities shall designate a contact point for handling all information received from applicants seeking authorisation as an approved publication arrangement (APA) or approved reporting mechanism (ARM). The contact details of the designated contact point shall be made public and regularly updated on the competent authorities' websites.
Article 2
Provision of information and notification to the competent authority
1. An applicant for authorisation to provide the services of an APA or ARM under the
provisions of Title IVa of Regulation (EU) No 600/2014 shall provide the competent authority with all information in accordance with Article 27d of Regulation (EU) No 600/2014 by filling in the application form set out in Annex I.
2. The applicant shall notify the competent authority with information of all members of its
management body by filling in the notification form set out in Annex II.
3. The applicant shall clearly identify in its submission which specific requirement under the
provisions of Title IVa of Regulation (EU) No 600/2014 it refers to and in which document attached to its submission that information is provided. 4 Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331 15.12.2010, p. 84).

4. The applicant shall indicate in its submission whether any specific requirement under the
provisions of Title IVa of Regulation (EU) No 600/2014 or Commission Delegated Regulation (EU) 20XX/XXXX ( ) [RTS ON APAs/ARMs AUTHORISATION] is not applicable to the data reporting service referred to in paragraph 1 that it is applying for.
5. Competent authorities shall indicate on their websites whether duly completed application
forms, notifications and any related additional information are to be submitted electronically.
Article 3
Receipt of application
Within 10 working days from the receipt of the application, the competent authority shall send on electronically an acknowledgement of receipt to the applicant, including the contact details of the contact point designated pursuant to Article 1.
Article 4
Requests for additional information
The competent authority may send an information request to the applicant indicating which additional information is needed in order to proceed with the assessment of the application.
Article 5
Notification of changes to the membership of the management body
1. An APA or ARM shall notify electronically the competent authority of any change to the
membership of its management body before such change takes effect.
5Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Where, for substantiated reasons, it is not possible to make the notification before that change takes effect, it shall be made within 10 working days after the change.
2. The APA or ARM shall provide the information on the change referred to in paragraph 1 by
filling in the notification form set out in Annex III.
Article 6
Communication of the decision to grant or refuse the authorisation The competent authority shall inform electronically of its decision to grant or to refuse the authorisation.
Article 7
Repeal
Commission Implementing Regulation (EU) 2017/1110 is repealed.
References to the repealed Regulation shall be construed as references to this Regulation.
Article 8
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, XX XXXX 202X.

For the Commission
The President

ANNEX I
Application form for authorisation to provide data reporting services Reference number:………………. Date:………………………………. From:
Name of the applicant:
Address:
Legal Entity Identifier (where applicable):
(Contact details of the designated contact person at the applicant) Full name:
Telephone:
Email:
To:
ESMA:
Address
(Contact details of the designated contact point at ESMA) Address:
Telephone:
Email:

Dear [insert appropriate name]
In accordance with Article 2 of the Commission Implementing Regulation (EU) XXXX/XXXX ( 6 ) please find the authorisation application.

Person at the applicant in charge of preparing the notification.
Full Name:
Status/position:
Telephone:
Email:
Date:
Signature:
Commission Implementing Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].
Nature of the application (tick the relevant box(es)):
Authorisation - Approved Publication Arrangement (APA) Authorisation - Approved Reporting Mechanism (ARM) Content Content Please insert the information referred to under Commission Delegated Regulation (EU) 20XX/XXXX ( ) [RTS ON APAs/ARMs AUTHORISATION]. Please set out that information under the appropriate section or make reference to the relevant annexes containing the information. Information on the organisation (Article 2 of Delegated Regulation (EU) 20XX/XXX) …………………………………………………………………………………………………………… ……………… Information on the ownership (Article 3 of Delegated Regulation (EU) 20XX/XXX) …………………………………………………………………………………………………………… ……………… Information on corporate governance (Article 4 of Delegated Regulation (EU) 20XX/XXX) …………………………………………………………………………………………………………… ……………… Information on the members of the management body (Article 5 of Delegated Regulation (EU) 20XX/XXX) …………………………………………………………………………………………………………… ……………… 7Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Information on internal controls (Article 6 of Delegated Regulation (EU) 20XX/XXXX) ( ) …………………………………………………………………………………………………………… Information on digital operational resilience (Article 7 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Information on conflicts of interest (Article 8 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Information on organisational requirements regarding outsourcing (Article 9 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Information on Management of incomplete or potentially erroneous information by APAs (Article 10 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Information on Management of incomplete or potentially erroneous information by ARMs (Article 11 of Delegated Regulation (EU) 20XX/XXXX) ………………………………………………………………………………………………………… Information on connectivity of ARMs (Article 12 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Information on machine readability (Article 13 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… 8 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Information on the details to be published by the APA (Article 14 of Delegated Regulation (EU) 20XX/XXXX) …………………………………………………………………………………………………………… Notes:
ANNEX II
Application form for the list of members of the management body Reference number:…………. Date:………………………….. From:
Name of the applicant:
Address:
Legal Entity Identifier (where applicable):
(Contact details of the designated contact person at the applicant) Full Name:
Telephone:
Email:
To:
ESMA/National Competent Authority:

Address:
(Contact details of the designated contact point at ESMA /National Competent Authority) Address:
Telephone:
Email:
Dear [insert appropriate name]
In accordance with Article 2 of Commission Implementing Regulation (EU) 20XX/XXXX ( ) please find attached the notification relating to the members of the management body.

Person at the applicant in charge of preparing the application:
Full Name:
Status/position:
Telephone:
Email:
Date:
Signature
9 Commission Implementing Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].
List of members of the management body:
Member 1
Full name………………………………………………………………………………
Date and place of birth…………………………………………………………………….
Personal national identification number or equivalent thereof……………… Private address: ………………………………………………………………………… Contact details (Telephone and email address) ………………………………………… Position………………………………………………………………………………… Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience……………………………… Educational qualification and relevant training…………………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(d) of Commission Delegated Regulation (EU) 20XX/XXXX ( 10)……………………………… Self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(e) of Delegated Regulation (EU) 20XX/XXXX ………………………… 10 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed………………………………………… Additional information relevant for the assessment whether the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties pursuant to Article 27(f)(3) of Regulation (EU) No 600/2014 of the European Parliament and of the Council ( 11)………. Effective date…………………………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information] Member [N] Full name………………………………………………………………………………………. Date and place of birth……………………………………………………………………….. Personal national identification number or equivalent thereof…………………………… Private address: ……………………………………………………………………………… Contact details (Telephone and email address) …………………………………………… Position…………………………………………………………………………………… Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience…………………………… Educational qualification and relevant training…………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(d) of 11 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84).

Commission Delegated Regulation (EU) 20XX/XXXX ( 12 ) …………………………………………… Self-declaration of good repute and authorisation to the competent authority to make enquiries under 5(e)Article of Delegated Regulation (EU) 20XX/XXXX ……………………… Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed……………………………………………… Additional information relevant for the assessment whether the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties pursuant to Article 27f (2) of Regulation (EU) No 600/2014 of the European Parliament and of the Council………. Effective date………………………………………………………………………… 12 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

ANNEX III
Application form for changes to the membership of the management body Reference number:………………………….. Date:…………………………………………… From:
Name of the authorised reporting mechanisms and approved reporting mechanisms:
Address:
Legal Entity Identifier (where applicable):
(Contact details of the designated contact person at the authorised reporting mechanisms and approved reporting mechanisms) Full name:
Telephone:
Email:
To:
ESMA /National Competent Authority:
Address:
(Contact details of the designated contact point at ESMA /National Competent Authority) Address:
Telephone:
Email:

Dear [insert appropriate name]
In accordance with Article 4 of the Commission Implementing Regulation (EU) 20XX/XXXX ( 13) please find attached the notification on changes to the membership of the management body.

Person at the data reporting services provider in charge of preparing the notification:
Full Name:
Status/position:
Telephone:
Email:
Date:
Signed:
Information on member(s) leaving the management body
Member 1
Full name……………………………………………………………………………
Contact details (Telephone and email address) …………………………………… Position………………………………………………………………………… Effective date of departure from management body…………………………… Reasons for the departure from management body…………………………… Member [N] Full name……………………………………………………………………… 13 Commission Implementing Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Contact details (Telephone and email address) ………………………………………… Position………………………………………………………………………… Effective date of departure from management body……………………………… Reasons for the departure from management body…………………………………

Information on new member(s) of the management body
Member 1
Full name………………………………………………………………………………
Date and place of birth………………………………………………………..
Personal national identification number or equivalent thereof………………………… Private address: ……………………………………………………………………… Contact details (telephone and email address) ……………………………………… Position…………………………………………………………………… Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience………………………… Educational qualification and relevant training…………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(d) of Commission Delegated Regulation (EU) 20XX/XXX ( 14) ……………… 14 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(e) of Delegated Regulation (EU) 20XX/XXX ………… Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider……………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed………………………… Additional information relevant for the assessment that the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties referred to in Article 27f(23) of Regulation (EU) No 600/2014 of the European Parliament and of the Council ( 15) …………………………………………………………………………………………………… …………………………………………………………………………………………………… ………………………………………………………………………………………………… Effective date……………………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information] Member [N] Full name……………………………………………………………………………………… Date and place of birth………………………………………………………………………. Personal national identification number or equivalent thereof……………………… Private address: ………………………………………………………………………… Position………………………………………………………………………………….. Personal national identification number or equivalent thereof………………………… 15 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84).

Private address: …………………………………………………………………………….
Position……………………………………………………………………………………….
Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience………………………………… Educational qualification and relevant training…………………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(d) of Delegated Regulation (EU) 20XX/XXXX ( 16)……………………………. Self-declaration of good repute and authorisation to the competent authority to make enquiries under Article 5(e) of Delegated Regulation (EU) 20XX/XXXX ( 17)………………… Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed…………………………………………… Additional information relevant for the assessment that the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties referred to in Article 27f (2) of Regulation (EU) No 600/2014……………………………………………………………. Effective date……………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information]

Complete updated list of members of the management body:
16 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION]. 17 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON APAs/ARMs AUTHORISATION].

Name Position Effective data
Name
Position
Effective date

7.3.6 Draft RTS on the authorisation of CTPs
COMMISSION DELEGATED REGULATION (EU) 20XX/XXX of XX XXXX 202X supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards on the authorisation of consolidated tape providers (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of 15 May 2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/2012 ( ), and in particular Article 27db(7), last subparagraph, thereof, Whereas:

In accordance with Regulation (EU) No 600/2014, data reporting services providers
cover three different types of entities: approved reporting mechanisms (ARMs), approved publication arrangements (APAs) and consolidated tape providers (CTPs).
By virtue of the amendments introduced by Regulation (EU) 2024/791 of the European
Parliament and of the Council ( 2
), Article 27da(2) of Regulation (EU) No 600/2014 includes the selection criteria to determine whether an applicant can operate a CTP. This Regulation reflects these selection criteria to ensure that the applicant for authorisation referred to in Article 27da(4) of Regulation (EU) No 600/2014 has put in place the arrangements to operate the consolidated tape and that it has met such 1 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84). 2 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 (OJ L 791, 8.3.2024, p.1).

criteria. The provisions of this Regulation aims at facilitating the transition from the selection phase to the authorization phase of CTPs.
3. The applicant for authorisation referred to in Article 27da(4) of Regulation (EU) No
600/2014 should, in its application for authorisation to operate a consolidated tape, provide a programme of operations, an organisational chart and an ownership chart. The organisational chart should identify who is responsible for the different activities to enable the European Securities and Markets Authority (ESMA) to assess whether the CTP has sufficient human resources and oversight over its business. The organisational chart should not only cover the scope of the CTP, but also include any other services that the entity provides, as this may highlight areas which may affect the independence of the CTP and give rise to a conflict of interest. An applicant seeking authorisation as a CTP should also provide information on the composition, functioning and independence of its governing bodies and on its internal control environment in order for ESMA to be able to assess whether the policies, procedures and corporate governance structure ensure the independence of the CTP and the avoidance of conflicts of interest.
4. All members of the management body of a CTP should be persons who are of
sufficiently good repute and possess sufficient knowledge, skills and experience, as those persons play a key role in ensuring that the CTP meets its regulatory obligations and contribute to the business strategy of the CTP. It is therefore important for the CTP to demonstrate that it has a robust process for appointing and evaluating the performance of members of the management body and that clear reporting lines and regular reporting to the management body are in place.
5. Conflicts of interest can arise between the CTP and data contributors or data users. In
particular, those conflicts may arise where the CTP is engaged in other activities such as acting as a market operator, investment firm or trade repository. As part of its corporate governance, a selected applicant seeking authorisation as a CTP should prove to ESMA the establishment of appropriate frameworks to identifying, preventing and managing existing and potential conflicts of interest, including the preparation of an inventory of conflicts of interest and implementation of appropriate policies and procedures to manage those conflicts and, where necessary, separate business functions and personnel to limit the flow of sensitive information between different business areas of the CTP.
6. The outsourcing of activities, in particular of critical functions, is capable of constituting
a material change of the conditions for the authorisation of a CTP. To ensure that the outsourcing of activities does not impair the CTP's ability to meet its obligations under

Regulation (EU) No 600/2014 or lead to conflicts of interest, the CTP should be able to demonstrate sufficient oversight and control over those activities.
7. CTPs fall under the scope of Regulation (EU) 2022/2554 of the European Parliament
and of the Council (
) and are therefore subject to the digital operational resilience requirements laid down in that Regulation. In its application for authorisation, the CTP should provide assurance of its compliance with the requirements laid down in Regulation (EU) 2022/2554 in the areas of information and communication technology (ICT) risk management, ICT third-party risk management, business continuity and back-up facilities, testing and capacity, as well as security and incidents reporting to ESMA. It is therefore important that applicants are able to demonstrate during the authorisation phase their ability to comply with the requirements laid down in Regulation (EU) 2022/2554 as soon as they start operating the consolidated tape.
8. A CTP should prove that the data it is publishing is accurate and complete and should
ensure that it has mechanisms for detecting errors or omissions caused by the data contributors or itself, in accordance with Article 10 of Commission Delegated Regulation (EU) 20XX/XXX [RTS Input/Output data]. According with Article 10(4) of Regulation (EU) 2022/2554, CTPs should prove that it has in place data quality checks to detect completeness, omission and errors of trade reports published in their systems.
9. A CTP should prove that its systems are able to ingest data from trading venues and
APAs and to consolidate this information to clients and to the public without disruptions. A CTP should demonstrate its ability to consolidate and publish data in line with the requirements set out in Commission Delegated Regulation (EU) 20XX/XXX [RTS Input/Output data]
10. In the application phase, CTPs should demonstrate the ability to delete and amend the
information which they receive from an entity providing them with information to deal with situations where, in exceptional circumstances, the data contributor is experiencing technical difficulties and cannot delete or amend the information itself. However, CTPs should not otherwise be responsible for correcting information contained in published reports where the error or omission was attributable to the entity providing the information. This is due to the fact that CTPs cannot know with certainty whether a perceived error or omission is indeed incorrect, since they were not party to the executed trade. 3 Regulation (Eu) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011 (OJ L 333, 27.12.2022, p. 1).

A CTP should also demonstrate that it stores the trade reporting information which it
handles for a sufficiently long period of time in order to facilitate the retrieval of historical information by competent authorities. CTPs should ensure that they establish the necessary organisational arrangements to maintain the data for at least the period specified in Regulation (EU) No 600/2014 and are able to respond to any request to provide services regulated by that Regulation.
A CTP should disclose the total expenditure allocated to operate the consolidated tape,
as well as the fees charged to clients pursuant to Article 17 of Commission Delegated Regulation (EU) 20XX/XXX [RTS on RCB]. The CTP for bonds should disclose any arrangements for revenue redistribution in accordance with Article 27(5) of Regulation (EU) No 600/2014.
A CTP should provide the expected Power Utilisation Effectiveness (PUE) ratio to
enable ESMA to understand the energy efficiency over the activities related to data processing and hosting, in accordance with Regulation (EU) No 2020/852 of the European Parliament and of the Council ( 4 ).
Joint applicants referred to in Article 27da(2), point (n), of Regulation (EU) No 600/2014,
should prove the technical and logistical arrangements adopted to fulfil the necessity to jointly operate the consolidated tape.
This Regulation is based on the draft regulatory technical standards submitted to the
Commission by the ESMA.
ESMA has conducted open public consultations on the draft regulatory technical
standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Securities and Markets Stakeholder Group established by Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council ( 5 ), HAS ADOPTED THIS REGULATION:
Article 1
4 Regulation (EU) 2020/852 of the European Parliament and of the Council of 18 June 2020 on the establishment of a framework to facilitate sustainable investment, and amending Regulation (EU) 2019/2088 (OJ L 198, 22.6.2020, p. 13). 5 Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority) amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2010, p. 84).

Information to ESMA
(Article 27db(1) of Regulation (EU) No 600/2014)
1. A selected applicant seeking authorisation to operate a consolidated tape shall submit
to ESMA the information set out in Articles 2 to 15.
2. A CTP shall promptly inform ESMA of any material change to the information provided
at the time of the authorisation and thereafter.
Article 2
Information on the ownership
(Article 27da(2), point (d), of Regulation (EU) No 600/2014)
1. A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application for authorisation:
a. a list containing the name of each person or entity who directly or indirectly holds 5% or more of the applicant’s capital or of its voting rights or whose holding makes it possible to exercise a significant influence over the applicants management; b. a list of any undertakings in which a person referred to in point (a) holds 5 % or more of the capital or voting rights or over whose management they exercise a significant influence;
c. a chart showing the ownership links between the parent undertaking, subsidiaries
and any other associated entities or branches.
2. The undertakings mentioned in the chart referred to in paragraph 1, point (c), shall be
identified by their full name, legal status and legal address.
Article 3
Information on the organisation
(Article 27da(2), point (d), of Regulation (EU) No 600/2014)

1. A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application for authorisation the following information on the organisation:
a. information on the organisational structure of the applicant, including an organisational chart and a description of the human, technical and legal resources allocated to its business activities; b. information on the operational separation policies and procedures to ensure segregation between the CTP and any other activities performed by the firm;
c. information on the compliance policies and procedures of the CTP, including:
i. the name of the person or persons responsible for the approval and
maintenance of those policies;
ii. the arrangements to monitor and enforce the compliance policies and
procedures;
iii. the measures to be undertaken in the event of a breach which may result in
a failure to meet the conditions for initial authorisation;
iv. a description of the procedure for reporting to ESMA any breach which may
result in a failure to meet the conditions for initial authorisation;
v. a list of all outsourced functions and resources allocated to the control of
the outsourced functions.
2. A CTP offering services other than data reporting services shall describe those services
in the organisational chart.
Article 4
Information on corporate governance
(Articles 27da(2), point (d), of Regulation (EU) No 600/2014)
1. A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application for authorisation information on the internal corporate governance policies and the procedures which govern its management body, senior management, and, where established, committees.

2. The information set out in paragraph 1 shall include:
a. a description of the processes for selection, appointment, performance evaluation and removal of senior management and members of the management body; b. a description of the reporting lines and the frequency of reporting to the senior management and the management body;
c. a description of the policies and procedures on access to documents by members
of the management body.
Article 5
Information on the members of the management body (Articles 27f(2) of Regulation (EU) No 600/2014) A selected applicant seeking authorisation to operate a consolidated tape shall include in its application for authorisation the following information in respect of each member of the management body:
a. name, date and place of birth, personal national identification number or an equivalent thereof, address and contact details; b. the position for which the person is or will be appointed;
c. a curriculum vitae evidencing sufficient experience and knowledge to adequately
perform the responsibilities; d. criminal records, notably through an official certificate, or, where such a document is not available in the relevant Member State, a self-declaration of good repute and the authorisation to ESMA to inquire whether the member has been convicted of any criminal offence in connection with the provision of financial or data services or in relation to acts of fraud or embezzlement; e. a self-declaration of good repute and the authorisation to ESMA to inquire whether the member:
i. has been subject to an adverse judicial finding in civil proceedings before
a court in connection with the provision of financial or data services, or for misconduct or fraud in the management of a business;

ii. has been subject to an adverse judicial finding in civil proceedings before
a court in connection with the provision of financial or data services, or for misconduct or fraud in the management of a business;
iii. has been part of the management body of an undertaking which was
subject to an adverse decision or penalty by a regulatory authority or whose registration or authorisation was withdrawn by a regulatory authority;
iv. has been refused the right to carry on activities which require registration
or authorisation by a regulatory authority;
v. has been part of the management body of an undertaking which has gone
into insolvency or liquidation while the person held such position or within a year after which the person ceased to hold such position;
vi. has been otherwise fined, suspended, disqualified, or been subject to any
other sanction in relation to fraud, embezzlement or in connection with the provision of financial or data services, by a professional body;
vii. has been disqualified from acting as a director, disqualified from acting in
any managerial capacity, dismissed from employment or other appointment in an undertaking as a consequence of misconduct or malpractice; f. an indication of the minimum time that is to be devoted to the performance of the person’s functions within the CTP; g. a declaration of any potential conflicts of interest that may exist or arise in performing the duties and how those conflicts are managed.
Article 6
Information on internal controls
(Articles 27da(2), point (d), of Regulation (EU) No 600/2014)

A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application for authorisation the information regarding its control environment. This

shall include information regarding its compliance function, risk assessment, internal control mechanisms and arrangements of its internal audit function.
2. The detailed information set out in paragraph 1 shall contain:
a. an outline of the applicant’s control environment, including where it relies on outsourced functions; b. an assessment of its key risks that may arise in the running the consolidated tape;
c. the applicant’s internal control policies and procedures to ensure the consistent and
effective implementation of those policies; d. any policies, procedures and manuals for monitoring and evaluating the adequacy and effectiveness of the applicant’s systems; e. any policies, procedures and manuals for controlling and safeguarding the applicant’s information processing systems; f. the identity of the internal bodies in charge of evaluating any internal control findings.
3. A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application for authorisation the following information with respect to the applicant’s internal audit function:
a. its adherence to national or international professional standards; b. in case there is an Internal Audit Committee, its composition, competences and responsibilities;
c. its internal audit function charter, methodologies, standards and procedures;
d. an explanation of how its internal audit methodology is developed and applied taking into account the nature of the applicant’s activities, complexities and risks; e. a work plan for the Internal Audit Committee for the three years following the date of application, focusing on the nature and extent of the applicant’s activities, complexities and risks.
Article 7

Information on conflicts of interest
(Articles 27da(2), point (d), of Regulation (EU) No 600/2014) A selected applicant seeking authorisation to operate a consolidated tape shall include in its application for authorisation the information regarding its administrative arrangements designed to prevent conflicts of interest. Such arrangements shall include policies and procedures for identifying, managing and disclosing existing and potential conflicts of interest and shall contain:
a. an inventory of existing and potential conflicts of interest, setting out their description, identification, prevention, management and disclosure; b. the separation of duties and business functions within the CTP including:
i. measures to prevent or control the exchange of information where a risk of
conflicts of interest may arise;
ii. the separate supervision of relevant persons whose main functions involve
interests that are potentially in conflict with those of a client.
c. a description of the remuneration policy for the members of the management body
and senior management; d. the rules regarding the acceptance of money, gifts or favours by staff of the CTP and its management body.
Article 8
Information on business operativity
(Articles 27da(2), points (g) and (i), of Regulation (EU) No 600/2014)
1. A selected applicant seeking authorisation to operate a consolidated tape shall include
in its application the following information:
a. the expected total capital expenditure and the expected operating expenditure to run the consolidated tape; b. a description of the liquid net assets funded by equity to cover potential general business losses in order to continue providing services.

2. A selected applicant seeking authorisation to operate the consolidated tape for bonds
shall also provide information on the arrangements for revenue distribution in accordance with Article 27h(5) of Regulation (EU) No 600/2014].
Article 9
Information on outsourcing
(Articles 27da(2), points (a) and (l), of Regulation (EU) No 600/2014)
1. Where a CTP arranges for activities to be performed on its behalf by third parties,
including undertakings with which it has close links, a selected applicant seeking authorisation to operate a consolidated tape shall include in its application for authorisation confirmation that the third-party service provider has the ability and the capacity, to perform the activities reliably and professionally.
2. The applicant shall specify which of the activities are to be outsourced, including a
specification of the level of human and technical resources needed to carry out each of those activities.
3. The applicant that outsources activities shall provide evidence that the outsourcing
does not reduce its ability or power to perform senior management or management body functions.
4. The applicant shall provide evidence that it remains responsible for any outsourced
activity and shall adopt organisational measures to ensure:
a. that it assesses whether the third-party service provider is carrying out outsourced activities effectively and in compliance with applicable laws and regulatory requirements and adequately addresses identified failures; b. the identification of the risks in relation to outsourced activities and adequate periodic monitoring;
c. adequate control procedures with respect to outsourced activities, including
effectively supervising the activities and their risks within the data reporting services provider; d. adequate business continuity of outsourced activities;

For the purposes of point (d), the CTP shall obtain information on the business continuity arrangements of the third-party service provider, assess its quality and, where needed, request improvements.
5. Where the applicant outsources any critical or important function, it shall provide ESMA
with:
a. the identification of the third-party service provider; b. the organisational measures and policies with respect to outsourcing and the risks posed by it as specified in paragraph 4;
c. internal or external reports on the outsourced activities.
Article 10
Information on market data fees and licensing models (Articles 27da(2), point (h), of Regulation (EU) No 600/2014) A selected applicant seeking for authorisation to operate a consolidated tape shall provide ESMA with the market data policies referred to in Article 17 of Commission Delegated Regulation (EU) 20XX/XXX [RTS on RCB].
Article 11
Information on digital operational resilience
(Articles 27da(2), points (a), (b) and (l), of Regulation (EU) No 600/2014)

A selected applicant seeking authorisation to operate a consolidated tape shall include in
its application for authorisation evidence that the CTP complies with the requirements laid down in Regulation (EU) 2022/2554 on ICT risk management organisation and capabilities, operational resilience strategy and testing, incident management and ICT third-party risk monitoring. For the purposes of the first subparagraph, the applicant shall provide policies and procedures regarding the CTP’s arrangements on:

a. ICT risk management; b. ICT-related incident management;
c. digital operational resilience testing;
d. ICT third-party risk monitoring.
2. The information set out in paragraph 1 shall take into account the size and overall risk
profile, and the nature, scale and complexity of its services, activities and operations.
Article 12
Information on energy efficiency
(Articles 27da(2), point (m), of Regulation (EU) No 600/2014)

A selected applicant seeking authorisation to operate a consolidated tape shall provide in
its application for authorisation information on the expected power utilisation effectiveness ratio as defined by ISO/IEC 30134-2:2016 and the best practices referred to in the most recent version of the European Code of Conduct on Data Centre Energy Efficiency.
For the purposes of the expected power utilisation effectiveness ratio referred to in
paragraph 1, the applicant shall consider the activities set out in points 8.1 of Annexes I and II to Commission Delegated Regulation (EU) 2021/2139 ( ).
Article 13
Information on record keeping arrangements
(Articles 27da(2), point (k), of Regulation (EU) No 600/2014) 6 Commission Delegated Regulation (EU) 2021/2139 of 4 June 2021 supplementing Regulation (EU) 2020/852 of the European Parliament and of the Council by establishing the technical screening criteria for determining the conditions under which an economic activity qualifies as contributing substantially to climate change mitigation or climate change adaptation and for determining whether that economic activity causes no significant harm to any of the other environmental objectives (OJ L 442, 09.12.2021, p. 1).

A selected applicant seeking authorisation to operate a consolidated tape shall provide ESMA with information on the arrangements adopted to ensure that:
a. each key stage of the CTP business may be reconstituted; b. the original content of a record before any corrections or other amendments may be recorded, traced and retrieved;
c. measures to prevent unauthorised alteration of records are in place;
d. the data recorded are secured and confidential; e. a mechanism for identifying and correcting errors is incorporated in the record keeping system; f. the timely recovery of the records in the case of a system failure.
Article 14
Information on organisational requirements
(Articles 27da(2), point (b), of Regulation (EU) No 600/2014) A selected applicant seeking authorisation to operate a consolidated tape shall provide ESMA with the information on the arrangements in place to ensure compliance with the organisational requirements laid down in Article 27h of Regulation (EU) No 600/2014.
Article 15
Information on reception, consolidation and dissemination of data and data quality (Articles 27da(2), points (c), (e), (f) and (j), of Regulation (EU) No 600/2014) A selected applicant seeking authorisation to operate a consolidated tape shall provide ESMA in its application for authorisation information on:
a. the protocols required in Article 2 of Commission Delegated Regulation (EU) 20XX/XXX [RTS on input/output data] to ensure that the reception, consolidation

and dissemination of the data referred to in Article 27da(2), point (c), of Regulation (EU) No 600/2014 are in place; b. the technical description of the systems adopted to ensure that the speed for dissemination of core market data and regulatory data matches the information for which it has been selected;
c. the technical description of the methods adopted to ensure data quality, in
accordance with the requirements set out in Article 10 of Commission Delegated Regulation (EU) 20XX/XXX [RTS on input/output data]; d. the documentation certifying that the modern interface technologies adopted for the dissemination of market data and for connectivity comply with the minimum requirements set out in Article 9 of Commission Delegated Regulation (EU) 20XX/XXX [RTS on input/output data].
Article 16
Information from joint applicants
(Article 27da(2), point (n), of Regulation (EU) No 600/2014) In addition to the requirements set out in Article 1, the selected joint applicants seeking authorisation to operate a consolidated tape shall include in their application for authorisation information on the technical and logistical arrangements adopted to fulfil the necessity to jointly operate the consolidated tape.
Article 17
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, XX XXXX.

For the Commission
The President

7.3.7 Draft ITS on the authorisation of CTPs
COMMISSION IMPLEMENTING REGULATION (EU) 20XX/XXX of XX XXXX 202X laying down implementing technical standards for the application of Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to the standard forms, templates and procedures for the authorisation of consolidated tape providers and related notifications (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EU) No 600/2014 of 15 May 2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/2012 ( ), and in particular Article 27db(8), third subparagraph, thereof, Whereas:

It is appropriate to set out common standard forms, templates and procedures to ensure a
common understanding and enforcement by the European Securities and Markets Authority (ESMA) of the authorisation process regarding the provision of consolidated tape services as well as to ensure efficient information flows. In order to facilitate communications between the applicant and ESMA, ESMA should designate a contact point and should publish the information on that contact point on its website.
The organisational requirements for consolidated tape providers (CTPs) differ from each
other in some respects, based on the asset class the entity intends to operate. As a result, an applicant should only be required to include in its application the information needed for assessing the application for the asset class with respect to which the CTP intends to operate. 1 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84).
In order to allow ESMA to assess whether changes to the management body of a CTP may
pose a threat to the effective, sound and prudent management of the CTP and to adequately take into consideration the interests of its clients and the integrity of the market, it is appropriate to set out clear time limits for the submission of information on those changes.
CTPs should be able to submit information on a change to the management body after that
change takes effect where the change is due to factors beyond the control of the CTP.
This Regulation is based on the draft implementing technical standards submitted to the
Commission by ESMA.
ESMA has conducted open public consultations on the draft implementing technical
standards on which this Regulation is based. ESMA has not analysed potential related costs and benefits as this would have been disproportionate in relation to their scope and impact.
ESMA has requested the advice of the Securities and Markets Stakeholder Group
established by Article 37 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council ( 2 ), HAS ADOPTED THIS REGULATION:
Article 1
Designation of a contact point
ESMA shall designate a contact point for handling all information received from applicants seeking authorisation to operate a consolidated tape provider. The contact details of the designated contact point shall be made public and regularly updated on ESMA's website.
Article 2
2 Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331 15.12.2010, p. 84).

Provision of information and notification to ESMA

A selected applicant seeking authorisation to operate a consolidated tape under the
provisions of Title IVa of Regulation (EU) No 600/2014 shall provide ESMA with all information in accordance with Article 27db(1) of Regulation (EU) No 600/2014 by filling in the application form set out in Annex I.
The applicant shall notify ESMA with information of all members of its management body
by filling in the notification form set out in Annex II.
The applicant shall clearly identify in its submission which specific requirement under the
provisions of Title IVa of Regulation (EU) No 600/2014 it refers to and in which document attached to its submission that information is provided.
The applicant shall indicate in its submission whether any specific requirement under the
provisions of Title IVa of Regulation (EU) No 600/2014 or Commission Delegated Regulation (EU) 20XX/XXX ( 3 ) [RTS ON CTP AUTHORISATION] is not applicable to the CTP service that it is applying for.
ESMA shall indicate on its website whether duly completed application forms, notifications
and any related additional information are to be submitted electronically.
Article 3
Receipt of application
Within 10 working days from the receipt of the application, ESMA shall send electronically an acknowledgement of receipt to the applicant, including the contact details of the contact point designated pursuant to Article 1.
Article 4
Requests for additional information
3 Commission Delegated Regulation (EU) 20XX/XXX of XX XX XXXX [RTS ON CTP AUTHORISATION].

ESMA may send an information request to the applicant indicating which additional information is needed in order to proceed with the assessment of the application.
Article 5
Notification of changes to the membership of the management body

A CTP shall notify electronically ESMA of any change to the membership of its
management body before such change takes effect.
Where, for substantiated reasons, it is not possible to make the notification before that change takes effect, it shall be made within 10 working days after the change.
A CTP shall provide the information on the change referred to in paragraph 1 by filling in
the notification form set out in Annex III.
Article 6
Communication of the decision to grant or refuse the authorisation ESMA shall inform the applicant electronically of its decision to grant or to refuse the authorisation.
Article 7
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, XX XXXX 20XX.

For the Commission
The President

ANNEX I
Application form for authorisation to provide services as a consolidated tape provider Reference number:……. Date:………………………. From:
Name of the applicant:
Address:
Legal Entity Identifier (where applicable)
(Contact details of the designated contact person at the applicant) Full name:
Telephone:
Email:
To:
ESMA
Address
(Contact details of the designated contact point at ESMA) Address:
Telephone:
Email:

Dear [insert appropriate name]
In accordance with Article 2 of the Commission Implementing Regulation (EU) 20XX/XXXX ( ) please find the authorisation application.

Person at the applicant in charge of preparing the notification.
Full Name:
Status/position:
Telephone:
Email:
Date:
Signature:
4 Commission Implementing Regulation (EU) 20XX/XXXX of XX XXXX 20XX [RTS ON CTP AUTHORISATION].
Nature of the application
Authorisation – Consolidated Tape Provider (CTP) Content Please insert the information referred to under Commission Delegated Regulation (EU) 20XX/XXX ( 5 ). Please set out that information under the appropriate section or make reference to the relevant annexes containing the information. Information on the ownership (Article 2 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………… Information on the organisation (Article 3 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………… Information on corporate governance (Article 4 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on the members of the management body (Article 5 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on internal controls (Article 6 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on conflict of interest (Article 7 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on business operativity (Article 8 of Delegated Regulation (EU) 20XX/XXX) …………………………………………………………………………………………………… Commission Delegated Regulation (EU) 20XX/XXX [RTS ON CTP AUTHORISATION].

Information on outsourcing (Article 9 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on market data fees and licensing models (Article 10 of Delegated Regulation (EU) 20XX/XXX)……………………………………………………………………………………………… Information on digital operational resilience (Article 11 of Delegated Regulation (EU) 20XX/XXX)……………………………………………………………………………………………… Information on energy efficiency (Article 12 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on record keeping arrangements (Article 13 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on organisational requirements (Article 14 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information on reception, consolidation and dissemination of data and data quality (Article 15 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Information from joint applicants (Article 16 of Delegated Regulation (EU) 20XX/XXX) ………………………………………………………………………………………………….. Notes:

ANNEX II
Application form for the list of members of the management body Reference number……………. Date…………………………….. From:
Name of the applicant:
Address:
Legal Entity Identifier (where applicable):
(Contact details of the designated contact person at the applicant) Full Name:
Telephone:
Email:
To:
ESMA
Address:
(Contact details of the designated contact point at ESMA) Address:
Telephone:

Email:
Dear [insert appropriate name]
In accordance with Article 2 of Commission Implementing Regulation (EU) 20XX/XXXX ( ) please find attached the notification relating to the members of the management body.

Person at the applicant in charge of preparing the application:
Full Name:
Status/position:
Telephone:
Email:
Date:
Signature
List of members of the management body:
Member 1
Full name……………………………………………………………………………
Date and place of birth………………………………………………………………… Personal national identification number or equivalent thereof…………………………… Private address: ………………………………………………………………………… Contact details (Telephone and email address) ………………………………………… Position……………………………………………………………………………… Curriculum vitae attached to application: Yes/No 6 Commission Implementing Regulation (EU) 20XX/XXXX [RTS ON CTP AUTHORISATION].

Professional experience and other relevant experience………………… Educational qualification and relevant training…………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to ESMA to make enquiries under Article 5(d) of Commission Delegated Regulation (EU) 20XX/XXX ( ) Self-declaration of good repute and authorisation to ESMA to make enquiries under
Article 5(e) of Delegated Regulation (EU) 20XX/XXX…………………
Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed……………………………………………. Additional information relevant for the assessment whether the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties pursuant to Article 27f(2) of Regulation (EU) No 600/2014 of the European Parliament and of the Council ( 8 )………. Effective date………………………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information] Member [N] Full name………………………………………………………………………………… Date and place of birth……………………………………………… Personal national identification number or equivalent thereof…………………… Private address: ………………………………………………………………………… Contact details (Telephone and email address) ……………………………… 7 Commission Delegated Regulation (EU) 20XX/XXX [RTS ON CTP AUTHORISATION]. 8 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84).

Position………………………………………………………………………………………
Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience………………………………… Educational qualification and relevant training………………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to ESMA to make enquiries under Article 5(d) of Commission Delegated Regulation (EU) 20XX/XXX ( )………………………………… Self-declaration of good repute and authorisation to ESMA to make enquiries under
Article 5(e) of Delegated Regulation (EU) 20XX/XXX……………..
Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed…………………………………………… Additional information relevant for the assessment whether the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties pursuant to Article 27f(2) of Regulation (EU) No 600/2014 of the European Parliament and of the Council (6)………. Effective date………………………………………………………………………………… 9 Commission Delegated Regulation (EU) 20XX/XXX [RTS ON CTP AUTHORISATION].

ANNEX III
Application form for changes to the membership of the management body Reference number:……………………… Date:……………………………………… From:
Name of the consolidated tape provider:
Address:
Legal Entity Identifier (where applicable):
(Contact details of the designated contact person at the data reporting services provider consolidated tape provider) Full name:
Telephone:
Email:
To:
ESMA:
Address:
(Contact details of the designated contact point at ESMA) Address:
Telephone:
Email:

Dear [insert appropriate name]
In accordance with Article 4 of the Commission Implementing Regulation (EU) 20XX/XXXX ( 10) please find attached the notification on changes to the membership of the management body.

Person at the data reporting services provider in charge of preparing the notification:
Full Name:
Status/position:
Telephone:
Email:
Date:
Signed:
Information on member(s) leaving the management body
Member 1
Full name……………………………………………………………………
Contact details (Telephone and email address) ………………………………………… Position…………………………………………………………………………… Effective date of departure from management body…………………………… Reasons for the departure from management body……………………………… Member [N] 10 Commission Implementing Regulation (EU) 20XX/XXXX [RTS ON CTP AUTHORISATION].

Full name……………………………………………………………………………………
Contact details (Telephone and email address) …………………………………… Position……………………………………………………………………………… Effective date of departure from management body………………………………… Reasons for the departure from management body………………………………………

Information on new member(s) of the management body
Member 1
Full name……………………………………………………………………………………
Date and place of birth………………………………………………………………………… Personal national identification number or equivalent thereof……………………………. Private address: ………………………………………………………………………………. Contact details (telephone and email address) ……………………………………… Position…………………………………………………………………………………… Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience…………………………………… Educational qualification and relevant training……………………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to ESMA to make enquiries under Article 5(d) of Commission Delegated Regulation (EU) 20XX/XXX ( 11) 11 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON CTP AUTHORISATION].

Self-declaration of good repute and authorisation to ESMA to make enquiries under
Article 5(e) of Delegated Regulation (EU) 20XX/XXX ……………………………
Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider…………………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed………………………………………………… Additional information relevant for the assessment that the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties referred to in Article 27f(2) of Regulation (EU) No 600/2014 of the European Parliament and of the Council ( 12) …………………………………………………………………………………………………… …………………………………………………………………………………………………… …………………………………………………………………………………………………… ……………………………………………………………………… Effective date…………………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information Member [N] Full name………………………………………………………………………………… Date and place of birth…………………………………………………………………. Personal national identification number or equivalent thereof……………………. Private address: ……………………………………………………………………………… 12 Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173 12.6.2014, p. 84).

Position…………………………………………………………………………………………
Curriculum vitae attached to application: Yes/No Professional experience and other relevant experience…………………………… Educational qualification and relevant training…………………………………………… Criminal records attached to this application OR self-declaration of good repute and authorisation to ESMA to make enquiries under Article 5(d) of Delegated Regulation (EU) 20XX/XXX ( 13)………………………………………………… Self-declaration of good repute and authorisation to ESMA to make enquiries under Article 5(e) of Delegated Regulation (EU) 20XX/XXX…………………… Minimum time (approximate) that will be devoted to the performance of the person’s functions within the data reporting services provider………………………………… Declaration of any potential conflicts of interest that may exist or arise in performing the duties and how these conflicts are managed…………………………………………………… Additional information relevant for the assessment that the member is of sufficiently good repute, possesses sufficient knowledge, skills and experience and commits sufficient time to perform the duties referred to in Article 27f(2) of Regulation (EU) No 600/2014. ……………………………………………………………………………………………………… ……………………………………………………………………………… Effective date……………………………………………………………… [Please set out that information here or provide an explanation of how it will be provided, or make reference to the relevant annexes containing the information] — Complete updated list of members of the management body:
Name Position Effective data
13 Commission Delegated Regulation (EU) 20XX/XXXX [RTS ON CTP AUTHORISATION].

Name
Position
Effective date

7.4 Annex IV – Legislative mandate to develop technical standards
7.4.1 RTS on input and output data of CTPs
Article 22b of MiFIR

The data transmitted to the CTP pursuant to Article 22a(1) and the data disseminated by
the CTP pursuant to Article 27h(1), point (d), shall comply with the regulatory technical standards adopted pursuant to Article 4(6), point (a), Article 7(2), point (a), Article 11(4), point (a), and Article 11a(3), point (a), unless provided otherwise in the regulatory technical standards adopted pursuant to paragraph 3, points (b) and (d), of this Article.
The Commission shall establish an expert stakeholder group by 29 June 2024 to provide
advice on the quality and the substance of data and the quality of the transmission protocol referred to in Article 22a(1). The expert stakeholder group and ESMA shall work closely together. The expert stakeholder group shall make its advice public. The expert stakeholder group shall be composed of members with a sufficiently wide range of expertise, skills, knowledge and experience to provide adequate advice. The members of the expert stakeholder group shall be selected following an open and transparent selection procedure. In selecting the members of the expert stakeholder group, the Commission shall ensure that they reflect the diversity of market participants across the Union. The expert stakeholder group shall elect a Chair from among its members, for a term of two years. The European Parliament may invite the Chair of the expert stakeholder group to make a statement before it and to answer any questions from its members whenever so requested.
ESMA shall develop draft regulatory technical standards to specify the quality of the
transmission protocol, measures to address erroneous trade reporting and enforcement standards in relation to data quality, including arrangements regarding cooperation between data contributors and the CTP, and, where necessary, the quality and the substance of the data for the operation of the consolidated tapes. Those draft regulatory technical standards shall in particular specify all of the following:
a) the minimum requirements for the quality of the transmission protocols referred to in Article 22a(1); b) the presentation of the core market data to be disseminated by the CTP, in accordance with prevailing industry standards and practices;

c) what constitutes the transmission of data as close to real time as technically possible; d) where necessary, the data needed to be transmitted to the CTP in order for it to be operational, taking into account the advice of the expert stakeholder group established pursuant to paragraph 2, including the substance and the format of those data, in accordance with prevailing industry standards and practices. For the purposes of the first subparagraph of this paragraph, ESMA shall take into account the advice from the expert stakeholder group established pursuant to paragraph 2 of this Article, international developments, and standards agreed at Union or international level. ESMA shall ensure that the draft regulatory technical standards take into account the transparency requirements laid down in Articles 3, 6, 8, 8a, 8b, 10, 11, 11a, 14, 20, 21 and 27g. ESMA shall submit the draft regulatory technical standards referred to in the first subparagraph to the Commission by 29 December 2024. Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in the first subparagraph in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010.
7.4.2 RTS on the revenue redistribution scheme
Article 27h of MiFIR
8. ESMA shall develop draft regulatory technical standards to:
(a) specify the weighting assigned to each criterion laid down in paragraph 6; (b) further specify the method for calculating the amount of the revenue to be redistributed to data contributors as referred to in paragraph 7, second subparagraph. […] For the purposes of the first subparagraph, point (a), of this paragraph, the criterion laid down in paragraph 6, point (a), shall have a higher weighting than the criterion laid down in point (b) of that paragraph, and the criterion laid down in point (b) of that paragraph shall have a higher weighting than the criterion laid down in point (c) of that paragraph. ESMA shall submit the draft regulatory technical standards referred to in the first subparagraph to the Commission by 29 December 2024.

Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in the first subparagraph in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010. Recital (31) The effectiveness of a consolidated tape depends on the quality of the data transmitted to it by data contributors. In order to ensure a high level of data quality, ESMA should establish the conditions under which the CTP is allowed to temporarily suspend the redistribution of revenue in the event that the CTP proves that a data contributor has seriously and repeatedly breached the data requirements established in this Regulation. Where it is found that that data contributor complied with those data requirements, the data contributor should receive the share of the revenue to which they were entitled plus interest.
Article 27h - Organisational requirements for CTPs
8. ESMA shall develop draft regulatory technical standards to:
[…]
(c) specify the criteria under which the CTP can, where the CTP proves that a data contributor has seriously and repeatedly breached the data requirements referred to in Articles 22a, 22b and 22c, temporarily suspend the participation of that data contributor in the revenue redistribution scheme, and specify the conditions under which the CTP is to:
i) resume revenue redistribution; and ii) where there was no breach of those requirements, provide that data contributor with the revenue retained, plus interest. […] ESMA shall submit those draft regulatory technical standards to the Commission by 29 December 2024. Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in paragraph 1, point (c), in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010.’;
7.4.3 RTS on the synchronisation of business clocks
Article 22c - Synchronisation of business clocks

1. Trading venues and their members, participants or users, systematic internalisers,
designated publishing entities, APAs and CTPs shall synchronise the business clocks they use to record the date and time of any reportable event.
2. ESMA shall, in accordance with international standards, develop draft regulatory technical
standards to specify the level of accuracy to which business clocks are to be synchronised. ESMA shall submit those draft regulatory technical standards to the Commission by 29 December 2024. Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in the first subparagraph in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010.
7.4.4 RTS/ITS on the authorisation and organisational requirements for DRSPs
The MiFIR Review amended Article 27d of MiFIR concerning DRSP authorisation. While
Article 27d of MiFIR retains the provision for developing RTS for the authorisation of APAs and
ARMs, Article 27db(7) established a new mandate for ESMA to draft a standalone RTS for CTP authorisation. The MiFIR review also introduced two new articles mandating ESMA to draft authorisation ITS: Article 27d(3) for APAs and ARMs, and Article 27db(8) for CTPs.
Article 27d (4) and (5) of MiFIR Review:
4. ESMA shall develop draft regulatory technical standards to determine:
(a) the information to be provided pursuant to paragraph 1, including the programme of operations; (b) the information to be included in the notifications referred to in Article 27f(2) as regards APAs and ARMs.
5. ESMA shall develop draft implementing technical standards to determine standard
forms, templates and procedures for the information to be provided pursuant to paragraph 1 of this Article and the information to be included in the notifications referred to in Article 27f(2) as regards APAs and ARMs.

With regards to the authorisation requirements for CTPs, the mandate included in Article 27db requires ESMA to define the information necessary to evaluate the application and notably assess whether the CTP has put in place all the necessary arrangements to fulfil the selection criteria. In fact, the RTS on the authorization of CTP should reflect the selection criteria introduced by
Article 27da(2) of MiFIR, to ensure that the applicants has put in place the arrangements to
operate the consolidated tape and that the applicant has met the criteria. These measures are aimed to facilitate the transition from the selection phase to the authorization phase of the CTPs.
Article 27db
7. ESMA shall develop draft regulatory technical standards to determine:
(a) the information to be provided pursuant to paragraph 1; (b) the information to be included in the notifications referred to in Article 27f(2) as regards CTPs.
8. ESMA shall develop draft implementing technical standards to determine standard
forms, templates and procedures for the information to be provided pursuant to paragraph 1 of this Article and the information to be included in the notifications referred to Article 27f(2) as regards CTPs.

7.5 Annex V – Example of a list of data contributors

7.6 Annex VI – Simulation of revenue distribution scheme
In order to show how the calculations are performed, an example with fake data is provided below. The table below identifies if the Segment MIC has an annual trading volume of shares which represents more than 1 % of the annual trading volume of shares in the Union, if not, it is checked if it is part of a group meeting such threshold and if not, it is checked if it has links with a group of such size and, if not, it is checked if the regulated market or SME growth market operated by that investment firm or market operator accounts for more than 85 % of the annual trading volume of shares that were initially admitted to trading on that regulated market or SME growth market and, if not, it is finally checked the trading venue is operated by a market operator and not by an investment firm. If any of those requirements are met, the segment MIC is mandated to contribute otherwise it can opt-in.

SME Operating
MIC
Segment
MIC
TV
Type Group Total volume of the
Group
Article
22a(4) of
MiFIR
Article 22a(4)(a) of MiFIR
Article
22a(4)(b) of
MiFIR
Article
22a(2) of
MiFIR
FINAL
OUTCOME
Does the
Segment
MIC has an annual trading volume of shares represents more than 1 % of the annual trading volume of shares in the Union? Does the Segment MIC belong to a Group whose annual trading volume of shares represents more than 1 % of the annual trading volume of shares in the Union? Is the Segment MIC linked to a Group whose annual trading volume of shares represents more than 1 % of the annual trading volume of shares in the Union? (b) the regulated market or SME growth market operated by that investment firm or market operator accounts for more than 85 % of the annual trading volume of shares that were initially admitted to trading on that regulated market or SME growth market. Is the (nonSMEG) trading venue operated by a market operator? No OP1 SMIC1 MLTF Group 1 € 350,000,000.00 N MANDATED No OP1 SMIC2 MLTF Group 1 € 350,000,000.00 N MANDATED No OP1 SMIC3 MLTF Group 1 € 350,000,000.00 MANDATED

No OP2 SMIC4 MLTF Group 2 € 27,000,000.00 N N MANDATED MANDATED No OP2 SMIC5 RMKT Group 2 € 27,000,000.00 N N MANDATED MANDATED No OP3 SMIC6 MLTF Group 3 € 11,000.00 N N OPT-IN OPT-IN SMEG OP4 SMIC7 MLTF Group 4 € 300,000,000.00 N MANDATED No OP4 SMIC8 RMKT Group 4 € 300,000,000.00 N MANDATED No OP4 SMIC9 RMKT Group 4 € 300,000,000.00 N MANDATED No OP4 SMIC10 MLTF Group 4 € 300,000,000.00 N MANDATED No OP4 SMIC11 RMKT Group 4 € 300,000,000.00 MANDATED No OP5 SMIC12 MLTF Group 5 € - N N OPT-IN OPT-IN No OP6 SMIC13 RMKT Group 6 € 1,830,000,000.00 N MANDATED No OP6 SMIC14 RMKT Group 6 € 1,830,000,000.00 N MANDATED No OP6 SMIC15 RMKT Group 6 € 1,830,000,000.00 N MANDATED No OP7 SMIC16 MLTF Group 6 € 1,830,000,000.00 MANDATED

No OP7 SMIC17 MLTF Group 6 € 1,830,000,000.00 MANDATED No OP7 SMIC18 MLTF Group 6 € 1,830,000,000.00 MANDATED No OP7 SMIC19 MLTF Group 6 € 1,830,000,000.00 MANDATED No OP7 SMIC20 MLTF Group 6 € 1,830,000,000.00 N MANDATED No OP8 SMIC21 MLTF Group 7 € 12,000.00 N N MANDATED MANDATED No OP9 SMIC22 MLTF Group 8 € 70,000.00 N N MANDATED MANDATED No OP10 SMIC23 MLTF Group 9 € 100,000,000.00 N N OPT-IN OPT-IN No OP10 SMIC24 MLTF Group 9 € 100,000,000.00 N N OPT-IN OPT-IN No OP11 SMIC25 MLTF Group 10 € 25,000,000.00 N N OPT-IN OPT-IN No OP12 SMIC26 MLTF Group 11 € 18,000.00 N N OPT-IN OPT-IN No OP13 SMIC27 MLTF Group 12 € 3,000.00 N N MANDATED MANDATED No OP14 SMIC28 MLTF Group 13 € 370.00 N N MANDATED MANDATED No OP15 SMIC29 MLTF Group 14 € 45,000,000.00 N N OPT-IN OPT-IN

No OP15 SMIC30 MLTF Group 14 € 45,000,000.00 N N OPT-IN OPT-IN No OP16 SMIC31 MLTF Group 15 € 190,000,000.00 MANDATED No OP17 SMIC32 MLTF Group 16 € 1,450,000,000.00 N MANDATED No OP17 SMIC33 MLTF Group 16 € 1,450,000,000.00 MANDATED No OP18 SMIC34 MLTF Group 17 € 320,000,000.00 N MANDATED No OP18 SMIC35 MLTF Group 17 € 320,000,000.00 N MANDATED No OP18 SMIC36 MLTF Group 17 € 320,000,000.00 MANDATED No OP19 SMIC37 MLTF Group 18 € 2,280,000.00 N N OPT-IN OPT-IN No OP20 SMIC38 RMKT Group 19 € 85,000,000.00 N N OPT-IN OPT-IN No OP20 SMIC39 MLTF Group 19 € 85,000,000.00 N N OPT-IN OPT-IN No OP20 SMIC40 RMKT Group 19 € 85,000,000.00 N N OPT-IN OPT-IN No OP20 SMIC41 RMKT Group 19 € 85,000,000.00 N N OPT-IN OPT-IN No OP20 SMIC42 RMKT Group 19 € 85,000,000.00 N N OPT-IN OPT-IN

No OP20 SMIC43 MLTF Group 19 € 85,000,000.00 N N OPT-IN OPT-IN

The second step is to calculate if each segment MIC meets the first criterion. More specifically, for each segment MIC being an SME growth market or an RM, it is checked if the Operating MIC to which the segment MIC belongs has an annual trading volume of shares which represents 1 % or less of the annual trading volume of shares in the Union. If such conditions are met then the annual trading volume generated (in shares and ETFs) by that trading venue (segment MIC) is multiplied by the weight. The results of criterion 1 are provided below. ASSESSMEN OF CRITERION #1 - SMALL (RM/SME) TRADING VENUE SME Operatin g MIC Segmen t MIC TV Type Group Total volume in shares of the Operating MIC CONDITIO N #1 Is the venue an SME growth market or an RM? CONDITIO N #2 (calculated at Operating MIC) Is the venue a small trading venue (TV whose annual trading volume of shares represents 1 % or less of the annual trading volume of RESULT FOR CRITERIO N #1 Is a small (RM/SME) trading venue? REVENEUES FOR CRITERION #1 - Total annual trading volume generated by that trading venue (in shares + ETFs) WEIGHT FOR CRITERIO N #1 CONTRIBUTIO N FOR CRITERION #1

shares in the Union)?
(a) (b) (c) 1 (d) (e) 2 (f) (g) = (e) x (f)
No OP1 SMIC1 MLTF Group 1
€
336,000,000 No € - 4.50 € -
No OP1 SMIC2 MLTF Group 1
€
336,000,000 No € - 4.50 € -
No OP1 SMIC3 MLTF Group 1
€
336,000,000 No € - 4.50 € -
No OP2 SMIC4 MLTF Group 2
€
27,134,095 No Yes No € - 4.50 € -
No OP2 SMIC5
RMK
T Group 2
€
27,134,095 Yes €
27,020,000 4.50 €121,590,000
No OP3 SMIC6 MLTF Group 3
€
10,000 No Yes No € - 4.50 € -
SME
G OP4 SMIC7 MLTF Group 4
€
296,890,830 Yes No No € - 4.50 € -
1 Field (a) is used for this calculation.
2 The total annual trading volume generated by the segment MIC in shares and ETFs is used for this calculation.

No OP4 SMIC8
RMK T Group 4
€
296,890,830 Yes No No €

4.50 €
-
No OP4 SMIC9
RMK T Group 4
€
296,890,830 Yes No No €
4.50 €
-
No OP4 SMIC10 MLTF Group 4
€
296,890,830 No €
4.50 €
-
No OP4 SMIC11
RMK T Group 4
€
296,890,830 Yes No No €
4.50 €
-
No OP5 SMIC12 MLTF Group 5
€
No Yes No €
4.50 €
-
No OP6 SMIC13
RMK T Group 6
€
Yes € 150 4.50 € 675
No OP6 SMIC14
RMK T Group 6
€
Yes € 1,500 4.50 € 6,750
No OP6 SMIC15
RMK T Group 6
€
Yes € 20,000 4.50 € 90,000
No OP7 SMIC16 MLTF Group 6
€
1,828,000,000 No €
4.50 €
-
No OP7 SMIC17 MLTF Group 6
€
1,828,000,000 No €
4.50 €
-
No OP7 SMIC18 MLTF Group 6
€
1,828,000,000 No €
4.50 €
-
No OP7 SMIC19 MLTF Group 6
€
1,828,000,000 No €
4.50 €
-
No OP7 SMIC20 MLTF Group 6
€
1,828,000,000 No €
4.50 €
-

No OP8 SMIC21 MLTF Group 7
€
130,000 No Yes No €

4.50 €
-
No OP9 SMIC22 MLTF Group 8
€
70,000 No Yes No €
4.50 €
-
No OP10 SMIC23 MLTF Group 9
€
95,000,000 No Yes No €
4.50 €
-
No OP10 SMIC24 MLTF Group 9
€
95,000,000 No Yes No €
4.50 €
-
No OP11 SMIC25 MLTF
Group
€
25,000,000 No Yes No €
4.50 €
-
No OP12 SMIC26 MLTF
Group
€
20,000 No Yes No €
4.50 €
-
No OP13 SMIC27 MLTF
Group
€
3,000 No Yes No €
4.50 €
-
No OP14 SMIC28 MLTF
Group
€
500 No Yes No €
4.50 €
-
No OP15 SMIC29 MLTF
Group
€
45,000,000 No Yes No €
4.50 €
-
No OP15 SMIC30 MLTF
Group
€
45,000,000 No Yes No €
4.50 €
-
No OP16 SMIC31 MLTF
Group
€
190,000,000 No €
4.50 €
-
No OP17 SMIC32 MLTF
Group
€
1,044,000,000 No €
4.50 €
-
No OP17 SMIC33 MLTF
Group
€
1,044,000,000 No €
4.50 €
-

No OP18 SMIC34 MLTF
Group
€
318,000,000 No €

4.50 €
-
No OP18 SMIC35 MLTF
Group
€
318,000,000 No €
4.50 €
-
No OP18 SMIC36 MLTF
Group
€
318,000,000 No €
4.50 €
-
No OP19 SMIC37 MLTF
Group
€
2,000,000 No Yes No €
4.50 €
-
No OP20 SMIC38
RMK T
Group
€
82,330,000 Yes € 50,000 4.50 € 225,000
No OP20 SMIC39 MLTF
Group
€
82,330,000 No Yes No €
4.50 €
-
No OP20 SMIC40
RMK T
Group
€
82,330,000 Yes € 200,000 4.50 € 900,000
No OP20 SMIC41
RMK T
Group
€
82,330,000 Yes €
5,100,000 4.50 € 22,950,000
No OP20 SMIC42
RMK T
Group
€
82,330,000 Yes €
78,000,000 4.50 €351,000,000
No OP20 SMIC43 MLTF
Group
€
82,330,000 No Yes No €
4.50 €
-

The third step consists of checking for each segment MIC if it meets the second and third criteria. After that, the results of the multiplication of the relevant turnover by the respective weights are then transformed into percentages. The results are provided in the table below. ASSESSMENT OF CRITERION #2 - YOUNG TRADING VENUE SME Operating MIC Segment MIC TV Type Group CONDITION #1 Has the venue provided initial admission of shares or ETFs in the five years before 27/03/2019 or thereafter? REVENUES FOR CRITERION #2 WEIGHT FOR CRITERION #2 CONTRIBUTION FOR CRITERION #2 (h) 3 (i) (j) (k) = (i) x (j) No OP1 SMIC1 MLTF Group 1 Yes € 30,000,850.00 4.00 € 120,003,400.00 3 This is calculated at segment MIC level.

No OP1 SMIC2 MLTF Group 1
Yes € 46,002,500.00 4.00 € 184,010,000.00
No OP1 SMIC3 MLTF Group 1
Yes € 260,195,000.00 4.00 € 1,040,780,000.00
No OP2 SMIC4 MLTF Group 2
Yes € 113,000.00 4.00 € 452,000.00
No OP2 SMIC5 RMKT Group 2
Yes € 27,020,000.00 4.00 € 108,080,000.00
No OP3 SMIC6 MLTF Group 3
Yes € 5,050.00 4.00 € 20,200.00
SMEG OP4 SMIC7 MLTF Group 4
Yes € 823,000.00 4.00 € 3,292,000.00
No OP4 SMIC8 RMKT Group 4
No €

4.00 €
-
No OP4 SMIC9 RMKT Group 4
No €
4.00 €
-
No OP4 SMIC10 MLTF Group 4
Yes € 450.00 4.00 € 1,800.00
No OP4 SMIC11 RMKT Group 4
Yes € 9,000,000.00 4.00 € 36,000,000.00
No OP5 SMIC12 MLTF Group 5
Yes € 439,000,000.00 4.00 € 1,756,000,000.00
No OP6 SMIC13 RMKT Group 6
Yes € 150.00 4.00 € 600.00
No OP6 SMIC14 RMKT Group 6
Yes € 1,500.00 4.00 € 6,000.00

No OP6 SMIC15 RMKT Group 6
Yes € 20,000.00 4.00 € 80,000.00
No OP7 SMIC16 MLTF Group 6
Yes € 255,039,000.00 4.00 € 1,020,156,000.00
No OP7 SMIC17 MLTF Group 6
Yes € 181,018,000.00 4.00 € 724,072,000.00
No OP7 SMIC18 MLTF Group 6
Yes € 159,000,000.00 4.00 € 636,000,000.00
No OP7 SMIC19 MLTF Group 6
Yes € 1,154,000,000.00 4.00 € 4,616,000,000.00 No OP7 SMIC20 MLTF Group 6 Yes € 81,000,000.00 4.00 € 324,000,000.00 No OP8 SMIC21 MLTF Group 7 Yes € 9,000.00 4.00 € 36,000.00 No OP9 SMIC22 MLTF Group 8 Yes € 4,000.00 4.00 € 16,000.00 No OP10 SMIC23 MLTF Group 9 Yes € 440,000.00 4.00 € 1,760,000.00 No OP10 SMIC24 MLTF Group 9 Yes € 11,016,000.00 4.00 € 44,064,000.00 No OP11 SMIC25 MLTF Group 10 Yes € 25,001,000.00 4.00 € 100,004,000.00 No OP12 SMIC26 MLTF Group 11 Yes € 11,000.00 4.00 € 44,000.00 No OP13 SMIC27 MLTF Group 12 Yes € 150.00 4.00 € 600.00

No OP14 SMIC28 MLTF Group 13
Yes € 400.00 4.00 € 1,600.00
No OP15 SMIC29 MLTF Group 14
Yes € 15,000,750.00 4.00 € 60,003,000.00
No OP15 SMIC30 MLTF Group 14
Yes € 30,002,000.00 4.00 € 120,008,000.00
No OP16 SMIC31 MLTF Group 15
Yes € 33,000,000.00 4.00 € 132,000,000.00
No OP17 SMIC32 MLTF Group 16
Yes € 44,000,750.00 4.00 € 176,003,000.00
No OP17 SMIC33 MLTF Group 16
Yes € 1,404,000,000.00 4.00 € 5,616,000,000.00 No OP18 SMIC34 MLTF Group 17 Yes € 6,002,000.00 4.00 € 24,008,000.00 No OP18 SMIC35 MLTF Group 17 Yes € 109,006,000.00 4.00 € 436,024,000.00 No OP18 SMIC36 MLTF Group 17 Yes € 203,175,000.00 4.00 € 812,700,000.00 No OP19 SMIC37 MLTF Group 18 Yes € 308,000,000.00 4.00 € 1,232,000,000.00 No OP20 SMIC38 RMKT Group 19 Yes € 50,000.00 4.00 € 200,000.00 No OP20 SMIC39 MLTF Group 19 Yes € 119,000.00 4.00 € 476,000.00 No OP20 SMIC40 RMKT Group 19 Yes € 200,000.00 4.00 € 800,000.00

No OP20 SMIC41 RMKT Group 19
Yes € 5,100,000.00 4.00 € 20,400,000.00
No OP20 SMIC42 RMKT Group 19
Yes € 78,000,000.00 4.00 € 312,000,000.00
No OP20 SMIC43 MLTF Group 19
Yes € 1,000,250.00 4.00 € 4,001,000.00

ASSESSMEN OF CRITERION #3 - TRANSPARENT TRADING VENUE SME Operating MIC Segment MIC TV Type Group CONDITION #1 Does the venue provide pretrade transparency in shares or ETFs? REVENEUES FOR CRITERION #3 WEIGHT FOR CRITERION #3 CONTRIBUTION FOR CRITERION #3 (l) (m) (n) (o) = (m) x (n) No OP1 SMIC1 MLTF Group 1 No € - 1.50 € - No OP1 SMIC2 MLTF Group 1 Yes € 44,000,000.00 1.50 € 66,000,000.00 No OP1 SMIC3 MLTF Group 1 Yes € 3,000,000.00 1.50 € 4,500,000.00 No OP2 SMIC4 MLTF Group 2 Yes € 5,000.00 1.50 € 7,500.00 No OP2 SMIC5 RMKT Group 2 Yes € 4,000,000.00 1.50 € 6,000,000.00

No OP3 SMIC6 MLTF Group 3
No €

1.50 €
-
SMEG OP4 SMIC7 MLTF Group 4
Yes € 239,000.00 1.50 € 358,500.00
No OP4 SMIC8 RMKT Group 4
No €
1.50 €
-
No OP4 SMIC9 RMKT Group 4
No €
1.50 €
-
No OP4 SMIC10 MLTF Group 4
Yes € 11,000.00 1.50 € 16,500.00
No OP4 SMIC11 RMKT Group 4
Yes € 69,000,000.00 1.50 € 103,500,000.00
No OP5 SMIC12 MLTF Group 5
Yes € 373,000,000.00 1.50 € 559,500,000.00
No OP6 SMIC13 RMKT Group 6
Yes € 150.00 1.50 € 225.00
No OP6 SMIC14 RMKT Group 6
Yes € 1,000.00 1.50 € 1,500.00
No OP6 SMIC15 RMKT Group 6
No €
1.50 €
-
No OP7 SMIC16 MLTF Group 6
No €
1.50 €
-
No OP7 SMIC17 MLTF Group 6
Yes € 171,000,000.00 1.50 € 256,500,000.00
No OP7 SMIC18 MLTF Group 6
Yes € 83,000,000.00 1.50 € 124,500,000.00

No OP7 SMIC19 MLTF Group 6
No €

1.50 €
-
No OP7 SMIC20 MLTF Group 6
Yes € 81,000,000.00 1.50 € 121,500,000.00
No OP8 SMIC21 MLTF Group 7
No €
1.50 €
-
No OP9 SMIC22 MLTF Group 8
No €
1.50 €
-
No OP10 SMIC23 MLTF Group 9
No €
1.50 €
-
No OP10 SMIC24 MLTF Group 9
Yes € 93,000,000.00 1.50 € 139,500,000.00
No OP11 SMIC25 MLTF Group 10
Yes € 25,000,000.00 1.50 € 37,500,000.00
No OP12 SMIC26 MLTF Group 11
No €
1.50 €
-
No OP13 SMIC27 MLTF Group 12
No €
1.50 €
-
No OP14 SMIC28 MLTF Group 13
No €
1.50 €
-
No OP15 SMIC29 MLTF Group 14
Yes € 15,000,000.00 1.50 € 22,500,000.00
No OP15 SMIC30 MLTF Group 14
No €
1.50 €
-
No OP16 SMIC31 MLTF Group 15
No €
1.50 €
-

No OP17 SMIC32 MLTF Group 16
Yes € 44,000,000.00 1.50 € 66,000,000.00
No OP17 SMIC33 MLTF Group 16
Yes € 1,392,000,000.00 1.50 € 2,088,000,000.00 No OP18 SMIC34 MLTF Group 17 No € - 1.50 € - No OP18 SMIC35 MLTF Group 17 Yes € 109,000,000.00 1.50 € 163,500,000.00 No OP18 SMIC36 MLTF Group 17 No € - 1.50 € - No OP19 SMIC37 MLTF Group 18 Yes € 296,000,000.00 1.50 € 444,000,000.00 No OP20 SMIC38 RMKT Group 19 No € - 1.50 € - No OP20 SMIC39 MLTF Group 19 No € - 1.50 € - No OP20 SMIC40 RMKT Group 19 No € - 1.50 € - No OP20 SMIC41 RMKT Group 19 Yes € 93,000.00 1.50 € 139,500.00 No OP20 SMIC42 RMKT Group 19 Yes € 1,000,000.00 1.50 € 1,500,000.00 No OP20 SMIC43 MLTF Group 19 No € - 1.50 € - TOTAL - - - - - - - -

Finally, a simulation using the weights of the 5 scenarios provided in the CP are tested and the weights of 4.5, 4.0 and 1.5 maximise the percentage of revenues received by those TVs that can opt-in. Therefore, the weights are confirmed in the Final Report. The table below presents the results. SME Operating MIC Segment MIC TV Type Group TOTAL % of revenues to be received (p) = (g) + (k) + (o) (q) = (p) / (r) No OP1 SMIC1 MLTF Group 1 € 120,003,400.00 0.4926% No OP1 SMIC2 MLTF Group 1 € 250,010,000.00 1.0262% No OP1 SMIC3 MLTF Group 1 € 1,045,280,000.00 4.2904% No OP2 SMIC4 MLTF Group 2 € 459,500.00 0.0019% No OP2 SMIC5 RMKT Group 2 € 235,670,000.00 0.9673% No OP3 SMIC6 MLTF Group 3 € 20,200.00 0.0001%

SMEG OP4 SMIC7 MLTF Group 4
€ 3,650,500.00 0.0150%
No OP4 SMIC8 RMKT Group 4
€

0.0000%
No OP4 SMIC9 RMKT Group 4
€
0.0000%
No OP4 SMIC10 MLTF Group 4
€ 18,300.00 0.0001%
No OP4 SMIC11 RMKT Group 4
€ 139,500,000.00 0.5726%
No OP5 SMIC12 MLTF Group 5
€ 2,315,500,000.00 9.5041%
No OP6 SMIC13 RMKT Group 6
€ 1,500.00 0.0000%
No OP6 SMIC14 RMKT Group 6
€ 14,250.00 0.0001%
No OP6 SMIC15 RMKT Group 6
€ 170,000.00 0.0007%
No OP7 SMIC16 MLTF Group 6
€ 1,020,156,000.00 4.1873%
No OP7 SMIC17 MLTF Group 6
€ 980,572,000.00 4.0248%
No OP7 SMIC18 MLTF Group 6
€ 760,500,000.00 3.1215%
No OP7 SMIC19 MLTF Group 6
€ 4,616,000,000.00 18.9465%

No OP7 SMIC20 MLTF Group 6
€ 445,500,000.00 1.8286%
No OP8 SMIC21 MLTF Group 7
€ 36,000.00 0.0001%
No OP9 SMIC22 MLTF Group 8
€ 16,000.00 0.0001%
No OP10 SMIC23 MLTF Group 9
€ 1,760,000.00 0.0072%
No OP10 SMIC24 MLTF Group 9
€ 183,564,000.00 0.7534%
No OP11 SMIC25 MLTF Group 10
€ 137,504,000.00 0.5644%
No OP12 SMIC26 MLTF Group 11
€ 44,000.00 0.0002%
No OP13 SMIC27 MLTF Group 12
€ 600.00 0.0000%
No OP14 SMIC28 MLTF Group 13
€ 1,600.00 0.0000%
No OP15 SMIC29 MLTF Group 14
€ 82,503,000.00 0.3386%
No OP15 SMIC30 MLTF Group 14
€ 120,008,000.00 0.4926%
No OP16 SMIC31 MLTF Group 15
€ 132,000,000.00 0.5418%
No OP17 SMIC32 MLTF Group 16
€ 242,003,000.00 0.9933%

No OP17 SMIC33 MLTF Group 16
€ 7,704,000,000.00 31.6213%
No OP18 SMIC34 MLTF Group 17
€ 24,008,000.00 0.0985%
No OP18 SMIC35 MLTF Group 17
€ 599,524,000.00 2.4608%
No OP18 SMIC36 MLTF Group 17
€ 812,700,000.00 3.3358%
No OP19 SMIC37 MLTF Group 18
€ 1,676,000,000.00 6.8792%
No OP20 SMIC38 RMKT Group 19
€ 425,000.00 0.0017%
No OP20 SMIC39 MLTF Group 19
€ 476,000.00 0.0020%
No OP20 SMIC40 RMKT Group 19
€ 1,700,000.00 0.0070%
No OP20 SMIC41 RMKT Group 19
€ 43,489,500.00 0.1785%
No OP20 SMIC42 RMKT Group 19
€ 664,500,000.00 2.7275%
No OP20 SMIC43 MLTF Group 19
€ 4,001,000.00 0.0164%
TOTAL
-
-
-
-
€10,741,438,750
-

Final Report on the Technical Standards related to Consolidated Tape Providers and DRSPs (MiFIR Review)

Field

Field identifier Description and details to be published

Field identifier Description Format as defined in Table 1 ESMA’s assessment of the

Field identifier Description Format as defined in Table 1

Field

Field identifier Description and details to be published

Field identifier Description and details to be published

Field identifier Description and details to be published

Field identifier Description and details to be published

Field identifier Description

Field identifier Description

Lineage

Similar documents from other regulators