ESMA Supervisory Briefing on Algorithmic Trading in the EU

26 February 2026 ESMA74-1505669079-10311 ESMA - 201-203 rue de Bercy - CS 80910 - 75589 Paris Cedex 12 - France - www.esma.europa.eu 1 Supervisory Briefing on Algorithmic Trading in the EU Executive Summary

1. This supervisory briefing provides guidance to investment firms and national competent authorities (NCAs) on the supervision of algorithmic trading under MiFID II. It draws on insights from the 2024 Common Supervisory Action (CSA) on pre-trade controls, as well as supervisory experience and discussions with NCAs.
2. The briefing aims to promote convergence in supervisory practices across the EU, particularly in the areas of governance, testing, and outsourcing of algorithmic trading systems. It also clarifies key definitions and provides practical templates to support supervisory work. 1 Introduction and Scope
3. ESMA is mandated to play an active role in building a common supervisory culture by promoting common supervisory approaches and practices. This supervisory briefing is issued under Article 29(2) of the ESMA Regulation, which enables ESMA to develop practical convergence tools such as supervisory briefings. The content of this briefing is non-binding and not subject to a 'comply or explain' mechanism.
4. This briefing supports NCAs in assessing compliance with MiFID II requirements on algorithmic trading by investment firms and, as provided for in Article 1(5) of MiFID II 1 , by members or participants of regulated markets and MTFs who are not required to be authorised under this Directive. Given the complexity and speed of algorithmic trading, ESMA recognises that it poses specific risks to market integrity and orderly trading. To achieve consistent supervision and limit risks, it is necessary to clarify the scope of what constitutes an algorithm and algorithmic trading. This briefing complements existing guidance and aims to clarify expectations in areas where evidence of divergence in supervisory practices has emerged. The briefing focuses on governance, testing, outsourcing, and the interpretation of the key concepts of algorithmic trading and algorithms.
5. This briefing also includes targeted guidance on pre trade controls (PTC). In 2024, as a follow-up to the 2022 flash crash in the Nordics, ESMA in cooperation with NCAs conducted a common supervisory action with the aim to: i) gain a deeper understanding of how investment firms (IFs) comply with existing legal requirements on PTCs, ii) assess the adequacy of PTC implementation across jurisdictions, and iii) identify areas where further supervisory guidance could support a more harmonised and convergent application of PTCs throughout the EU. 1 Under Article 1(5) of MiFID II, Article 17(1) to (6) shall also apply to members or participants of regulated markets and MTFs who are not required to be authorised under this Directive pursuant to points (a), (e), (i) and (j) of Article 2(1). In this briefing, the reference to “investment firms” should therefore be read as including the entities covered by Article 1(5) of MiFID II.

2 6. The findings of this CSA highlighted that most investment firms have integrated PTCs in their trading activity and in their risk management framework. Nevertheless, the findings also suggested that further targeted guidance on PTC should be provided as practices related to implementation and governance are often divergent and not always robust. Considering that erroneous orders pose risks not only to the investment firm submitting them but also to the orderliness and stability of financial markets ESMA deems it necessary to issue guidance on this matter to ensure best practices are adopted by investment firms in the implementation of PTCs. 7. NCAs are encouraged to incorporate this guidance into their supervisory practices, including authorisation processes, thematic reviews, and on-site inspections. The briefing may also support the development of internal checklists and training materials for supervisory staff. Investment firms may use this briefing to verify their compliance with the requirements on algorithmic trading. 2 Algorithmic trading – key concepts What is algorithmic trading? 8. Algorithmic trading is defined in Article 4(1)(39) of MiFID II as trading in financial instruments where a computer algorithm automatically determines individual parameters of orders. Any trading in which a computer algorithm is involved determining any aspect other than merely the routing of an order to an execution venue or post-trade processing of transactions can be considered algorithmic trading. Even if a human would intervene in the trading process, the involvement of a computer algorithm determining any individual parameter of the order for other purposes than order routing or post-trade processing, would make this type of trading algorithmic trading. 9. Any use of algorithms which only serve to inform a trader of a particular investment opportunity is not considered as algorithmic trading, provided that the execution is not algorithmic (see ESMA_QA_1603). The algorithm thus doesn’t determine any of the parameters of the order. 10. Examples of algorithmic trading are cases where a computer algorithm automatically determines orders’ parameters such as: i) whether to initiate the order, ii) the timing of the order, iii) the price of the order, iv) the quantity of the order or v) how to manage the order after submission. 11. In some instances, activities which are not part of basic order processing can also qualify as algorithmic trading, if automated. Below is a list of activities to aid NCAs and investment firms further in identifying whether an activity qualifies as “determining trading parameters”:

1. Order Generation Logic • generating orders or quotes based on market signals, portfolio strategies, or risk thresholds.

3 • Signal-based trading, quantitative models, or machine learning-driven strategies including where the activities are not involved in direct execution but influence algorithmic trade decision-making and parameter determination. 2. Execution Strategy Selection • Choosing between execution strategies (e.g. aggressive vs passive, VWAP, TWAP, iceberg). • These strategies influence how and when orders are placed and managed. 3. Market Condition Analysis • Analysing market data (e.g. volatility, spread, depth) to determine whether and how to trade. • This includes real-time decision-making based on external inputs. 4. Portfolio Rebalancing Decisions • Deciding to rebalance portfolios or adjust exposures based on pre-defined rules or market conditions. 5. Risk Management Adjustments • Adjusting trading behaviour based on risk metrics (e.g. VaR, exposure limits, stop-loss triggers). 6. Liquidity Detection and Response • Detecting hidden liquidity or fragmented markets and adjust order placement accordingly. 7. Cross-Asset or Cross-Venue Optimisation • Determining which asset or venue to trade based on cost, latency, or execution quality — beyond simple routing. 12. ESMA has clarified the scope of algorithmic trading in ESMA QA 1490 on MiFID and MiFIR market structure topics in 2022. Since then, the use of computers in trading has further increased and evolved. Professional trading without the use of computer algorithms can be considered an exception nowadays. Especially investment firms authorised to deal on own account are most likely engaging in algorithmic trading. ESMA notes that credit institutions are also subject to rules on algorithmic trading when they engage in investment services or activities which involve the use of algorithmic trading. 13. The definition of algorithmic trading in MiFID II requires “[…] limited or no human intervention [...]”. ESMA notes that many firms engaging in trading using computer algorithms rely on human intervention to control the trading process and risks involved. For example, a trader may be required to authorise single or multiple orders prior to submission to execution venues. Some firms may therefore argue they do not engage in algorithmic trading because the order would not be submitted without human intervention. However, such intervention does not negate the fact that a computer algorithm has determined individual parameters of the order(s).

4 14. Article 4(1)(39) of MiFID II excludes from the definition of algorithmic trading “[…] any system that is only used for […] the processing of orders involving no determination of any trading parameters […]”, thus excluding only cases where human intervention takes place with respect to the determination of all individual trading parameters. Examples of systems not included in the definition of algorithmic trading are systems used for the purpose of: i) exclusively routing orders to one or more trading venues, ii) processing orders involving no determination of any trading parameters, iii) the confirmation of orders and iv) post-trade processing of executed transactions. 15. Although MiFID II excludes some order processing activities from the scope of algorithmic trading, some of those activities would qualify as algorithmic trading if automated. As an example, smart order routers (that determine parameters of the order other than the venue or venues where the order should be submitted) fall under the definition of algorithmic trading, whilst simple routers do not. 16. The table below provides a list of examples of activities which if automated would qualify as algorithmic trading:

1. Slicing orders prior to execution Breaking large orders into smaller parts to optimize execution.
2. Execution-driven venue switching Automatically re-routing remaining quantity across venues (incl. cancel/replace) in response to real-time price/liquidity/latency signals.
3. Order reallocation or rebalancing Adjusting order distribution across venues or instruments based on market conditions.
4. Execution strategy optimization Applying logic such as VWAP, TWAP, iceberg, or smart order routing that modifies order behaviour.
5. Dynamic order modification based on market data Adjusting price or quantity in real-time based on market movements.
6. The risks involved in algorithmic trading originate from the risks of one or more parameters of an order, as determined by a computer algorithm, which may endanger market integrity or orderly trading. All of these risks need to be properly managed, which is the aim of the regulations on algorithmic trading. What is an algorithm?
7. Without a common understanding of what, at a minimum, qualifies as an algorithm, investment firms may under-report algorithmic systems and fail to apply required controls, testing, and documentation applicable to an algorithm. Also, supervisory expectations become fragmented without a shared understanding. This undermines the effectiveness of supervisory actions and creates uncertainty around compliance obligations. This risk is exacerbated when investment firms rely on external

5 providers whose systems may contain embedded algorithms but fall outside direct regulatory oversight. 19. In line with the definition of algorithmic trading in Article 4(1)(39) MiFID II and Article 18 Delegated Regulation (EU) 2017/5652 , an algorithm should be understood as a computerised set of instructions or rules that autonomously determines one or more parameters of a trading order. 20. An algorithm is context-specific and may be tied to particular instrument(s), asset class(es), trading venue(s), or strategy(ies). Examples of parameters are timing, price or quantity. According to MiFID II and RTS 6/7 framework provisions, the algorithms must be testable and controllable. These practical boundaries make it possible to subject algorithms to supervisory scrutiny to ensure compliance with regulatory obligations and to safeguard market integrity. What is an algorithmic trading strategy? 21. Analogous to the need for a shared understanding of the concept of an algorithm, a common understanding of an algorithmic trading strategy is essential for effective risk management and consistent supervision. While MiFID II (Article 17(2)) and RTS 6 (Articles 5(4) and 9) refer to strategies in the context of reporting, testing, documentation, and market abuse surveillance, they do not detail what constitutes a distinct strategy. 22. This results in inconsistent interpretation and leads to several challenges such as effective testing and supervision thereof. Investment firms are required to test and validate each algorithmic trading strategy before deployment and after any material change. However, without a consistent interpretation, investment firms may either over-aggregate (e.g. treating multiple instruments and venues as one strategy) or over-fragment (e.g. claiming thousands of strategies). This undermines comparability and supervisory effectiveness. 23. In addition, supervisors must be able to link trading behaviour such as disorderly or abusive conduct, to specific strategies. A lack of a standardised concept makes it difficult to identify which strategy was responsible, particularly when multiple algorithms are deployed simultaneously. 24. An algorithmic trading strategy is a set of decision logic, implemented through one or more algorithms, that autonomously pursues a defined trading objective. Trading objectives such as market making, arbitrage, or execution optimisation may be specific to market conditions, instruments, or venues. An algorithmic trading strategy must result in observable trading behaviour. Each strategy must be testable, distinguishable, and subject to supervisory scrutiny to ensure compliance and market integrity. How and when should testing of algorithms should occur? 2 Delegated Regulation (EU) 2017/565

6 25. Firms engaged in algorithmic trading must ensure that their algorithm(s), algorithmic trading system(s) or algorithmic trading strategy(/ies) are tested to avoid contributing to disorderly markets or facilitating abusive practices. RTS 6 (and 7) require investment firms to conduct conformance testing, stress testing, and scenario analysis. 26. The scope, frequency, and intensity of testing vary significantly across the industry, depending on the nature, scale and complexity of the business. ESMA recognises the need for proportionality in applying the testing provisions and verifying compliance thereof. Investment firms specifically engaged in highly complex algorithmic trading may need to implement more extensive testing practices than those investment firms engaged in less complex algorithmic trading. 27. The harmonised understanding of what constitutes a discrete algorithm and strategy as put forward in this supervisory briefing, is essential for testing purposes. This will help achieving a consistent perspective on appropriate testing. 28. RTS 6 lists a number of testing requirements to be complied with by investment firms engaged in algorithmic trading3 . These requirements prescribe in detail what and how an investment firm needs to test. 29. Investment firms need to ensure that testing methodologies, procedures and internal authorisations to deploy algorithmic trading are well documented. Supervisors need to be able to assess compliance with the testing requirements based on this documentation. Investment firms should thus keep the documentation comprehensive and updated. 30. Testing of an algorithm, algorithmic trading system or algorithmic trading strategy is required following each ‘material change’ or ‘substantial update’ thereof. In this regard, firms should manage the risk that a series of minor or small changes due to recalibrations could accumulate over time, when uncontrolled or unchecked, into a material change in the model output without it being tested. A clarification of this terminology will enhance supervisory convergence. 31. A material change or substantial update is any modification that may alter the behaviour, risk profile, or compliance posture of an algorithm, algorithmic trading system or algorithmic trading strategy. Investment firms are required to timestamp, approve, and record all material changes. Good practice would be to consider retesting when changes would occur to the following non-exhaustive list of aspects: Change type Examples Logic or Decision Rules Altering how the algorithm determines price, timing, or quantity 3 MiFID II Aticles 5, 6 and 7 on testing and article 10 on stress testing.

7 Change type Examples Execution Behaviour Modifying order types, slicing logic, or routing mechanisms Scope Deploying the algorithm in new instruments, venues, or asset classes Risk Controls Changing thresholds, kill switch logic, or alert triggers External Dependencies Replacing third-party providers or data feeds, changes to the trading systems, or changes in access arrangements. Adaptive Capabilities Retraining or modifying machine learning components How should stress testing be conducted? 32. Investment firms should stress test their algorithmic trading systems to ascertain that their systems can withstand increased trade flows and market stress. To this end, investment firms are required by Article 10 of RTS 6 to stress test the capacity of their systems to process a high volume of messages and a high volume of trades. Systems would need to withstand twice the volume of messages or trades processed in the previous 6 months. While stress testing the volume of messages is relatively straight forward, ESMA recognises that stress testing of trading (i.e. the full cycle of order generation to post trade processing) is more complex. Therefore, investment firms should test their systems to evidence a reasonable level of assurance that their systems can process twice the volume of the highest volume of trading reached by the investment firm during the previous 6 months. Who is responsible for compliance with algorithmic trading requirements in case of outsourcing, use of third-party algorithms or in a chain of entities? 33. In the context of algorithmic trading, it is important to distinguish between the various configurations in which algorithms are operated or provided by third parties and how the allocation of responsibility for compliance with MiFID II and RTS 6 is determined. 34. First, where an investment firm engages in algorithmic trading and makes use of third-party algorithms or execution tools (i.e. procured or outsourced), the investment firm remains fully and solely responsible for compliance with MiFID II and RTS 6. 35. Outsourcing or reliance on external technology providers will not alter the firm’s regulatory obligations. The investment firm must therefore ensure that it maintains adequate understanding,

8 oversight, and control over the design, testing, and operation of the algorithms it uses, and that the contractual arrangements in place provide sufficient access to information and confidence to demonstrate compliance to the competent authority. 36. Second, where an order is initiated via an algorithm operated by another market participant (such as in a setup where one firm generates orders and another executes those orders), the entity executing the orders is deemed to be engaging in algorithmic trading for the purposes of MiFID II and thus bears responsibility for ensuring RTS 6 compliance. 37. In both cases, regulatory accountability cannot be transferred and should remain assigned. Thus, contractual arrangements and service-level agreements (SLAs) should clearly define the allocation of operational responsibilities and supporting obligations (e.g. testing, monitoring, record keeping) necessary to ensure compliance with RTS 6. Where both firms engage in algorithmic trading, both firms will remain subject to the obligations of RTS 6. In cases where only one of the parties qualifies as an investment firm within the meaning of MiFID II, that entity shall be deemed responsible for RTS 6 compliance. An example of such instance is the case when an algorithm is provided by a third-country entity which is not authorised to operate as an investment firm within the EU: in such scenario, the EU-based investment firm remains solely responsible for compliance with RTS 6. Who is responsible for compliance with algorithmic trading requirements in case of Direct Electronic Access (DEA)? 38. DEA providers4 are subject to several requirements applicable to algorithmic trading. Even if their clients are subject to those requirements too, because they engage in algorithmic trading, the DEA provider has to ensure its clients compliance: “An investment firm that provides DEA shall be responsible for ensuring that clients using that service comply with the requirements of this Directive and the rules of the trading venue” (Article 17(5) MiFID II). The DEA provider thus bears responsibility for its clients to comply with the algorithmic trading requirements as laid down in RTS 6. 39. If the client is an authorised investment firm under MiFID II, such client is directly responsible for complying with the algorithmic trading requirements. The NCA of this client is responsible for supervising compliance. However, this does not remove the responsibility of the DEA provider to ensure compliance of its client. 40. If the client is not an investment firm subject to MiFID II, the DEA provider bears sole responsibility for the compliance of its client with the appropriate regulations. The NCA of the DEA provider is 4 Under Article 48(7) of MiFID II, members or participants are only permitted to provide direct electronic access if they are investment firms authorised under this Directive or credit institutions authorised under Directive 2013/36/EU

9 responsible for supervising compliance with this responsibility. Therefore, the DEA provider will need to make sure it can verify the adherence with the appropriate requirements by its clients. How should outsourcing arrangements be structured? 41. Outsourcing arrangements related to algorithmic trading should clearly define the roles, operational responsibilities, and obligations of each party, including those necessary to ensure full compliance with RTS 6. Properly designed arrangements should clearly demonstrate that the investment firm retains effective control and oversight over all outsourced functions. 42. Outsourcing arrangements should be structured so that the firm maintains ongoing visibility and access to the functioning and performance of the outsourced algorithms, including the ability to review data, testing documentation, and records. They should also provide the firm with the unconditional capacity to monitor, suspend, or terminate algorithmic trading where necessary, without dependence on the third-party provider’s consent or intervention. Outsourcing agreements should therefore make clear that operational control and regulatory responsibility remain fully within the investment firm. What is the AI Act? 43. The Artificial Intelligence (AI) Act (Regulation (EU) 2024/1689) defines what an AI system is and requires 7 conditions to be met (Article 3(1)). When an algorithmic trading system meets the definition of an AI system it will need to comply with the requirements in the AI Act. It is relevant that Article 1 of RTS 6 states that as part of its overall governance and decision-making framework, an investment firm shall establish and monitor its trading systems and trading algorithms through a clear and formalised governance arrangement, which will need to integrate the AI Act requirements. 44. These arrangements need to have regard to the nature, scale and complexity of the business of the investment firm. They set out (a) clear lines of accountability, (b) effective procedures for the communication of information within the investment firm (c) a separation of tasks and responsibilities of trading desks on the one hand and supporting functions on the other. As a result, all those aspects have to be considered when an AI system is used. 45. On the basis of the definition of an AI system, different requirements apply under the AI Act. Four types of systems are identified: i.those bringing unacceptable risks, which are prohibited; ii.those bringing high risks. Those systems are subject to strict obligations (i.e., conformity assessments) before they can be put on the market; iii.those bringing limited risks for which the AI Act introduces specific disclosure and transparency obligations ensuring humans are informed when necessary, and;

10 iv.those bringing minimal risks for which no rules are provided. 46. As a result, specific rules from the AI Act may apply based on the riskiness of the AI system or the manner of its intended application (i.e. if it is intended for use by natural persons). While AI-based algorithmic trading is currently excluded from the scope as a high-risk use case under the AI Act, the scope of high-risk use cases is subject to annual review. Nevertheless, AI used in algorithmic trading may still constitute a limited risk use case depending on whether it is ‘intended to interact directly with natural persons”. In the scenario involving natural persons, deployers and providers of the AI system are subject to transparency requirements (Article 50 of the AI Act). However, the authorities in a Member State with competency under the AI Act (so called Market Surveillance Authorities) would be responsible for supervising such obligations when it comes to high-risk AI systems. What is the interaction between AI and algorithmic trading? 47. The integration of AI has transformed algorithmic trading due to its ability to analyse vast amounts of data, identify complex patterns, and make autonomous decisions on the fly. In this regard, firms should manage the risk that a series of minor or small changes due to recalibrations could accumulate over time, when uncontrolled or unchecked, into a material change in the model output without it being tested. 48. Although neither MiFID II nor RTS 6 specifically address AI, it is recommended that investment firms and NCAs recognise the use of AI in algorithmic trading. RTS 6 provides for two provisions which investment firms can use to demonstrate the use and their control of AI in algorithmic trading. 49. According to Article 9 of RTS 6, an investment firm shall annually perform a self-assessment and validation process and on the basis of that process issue a validation report. In the course of that process the investment firm shall review, evaluate and validate the following: (a) its algorithmic trading systems, trading algorithms and algorithmic trading strategies; (b) its governance, accountability and approval framework; (c) its business continuity arrangement; (d) its overall compliance with Article 17 of MiFID II, having regard to the nature, scale and complexity of its business. When investment firms are performing this assessment and validation process, NCAs should assess how firms are taking into consideration the use of AI as part of their self-assessment and validation under Article 9 of RTS 6. 50. According to Article 2 of RTS 6, an investment firm shall ensure that its compliance staff has at least a general understanding of how the algorithmic trading systems and trading algorithms of the investment firm operate. The compliance staff shall be in continuous contact with persons within the firm who have detailed technical knowledge of the firm's algorithmic trading systems and algorithms. As a result, on the one hand, the algorithmic trading systems and algorithms should be explainable and on the other hand, it is the investment firm’s responsibility to ensure they can adequately explain how AI impacts their algorithms’ decision-making.

11 How should the annual self-assessments of algorithmic trading systems be structured (MiFID II Article 17(1) / RTS 6 Article 9)? 51. Investment firms shall conduct and document the required self-assessment on an article-by-article basis, covering all relevant articles of RTS 6. In addition, the self-assessment should indicate per relevant article whether a firm considers itself compliant. The self-assessment should convey a clear rationale regarding a firm’s overall compliance status. 52. Annex I of RTS 6 sets out elements to be considered by an investment firm when assessing the nature, scale and complexity of its business. The criteria in this annex should be taken into account when drafting the self-assessment but are not criteria which need to be complied with. 53. Furthermore, NCAs are expected to verify that investment firms comply with Article 9(2) – (5) of RTS 6, which places primary responsibility for the self-assessment within a firm’s risk management function. Where applicable, the self-assessment must be subject to review by a firm’s internal audit function and must receive approval from senior management. 3 Targeted guidance on PTC following the CSA 3.1 Scope of PTCs If an IF engages exclusively in non-algorithmic trading and does not provide DEA, does it need to establish PTCs and related governance procedures? 54. IFs which do not engage in algorithmic trading nor provide DEA are not directly subject to the provisions in RTS 6. Similarly, IFs that engage in both algo and non-algo trading are not required to establish PTCs with respect to their non-algo trading activities. Nevertheless, those firms are expected to establish mechanisms aimed at preventing the sending of erroneous orders to a trading venue (‘controls’ hereafter), such as (if relevant) price collars, fat finger controls, maximum order values or maximum order volumes, coverage checks for positions in securities or in cash, warnings in case of old data feeds, etc. 55. It should be noted that: i. Article 16 of MiFID II sets organizational requirements for IFs which, amongst others, mandate IF to “take reasonable steps to ensure continuity and regularity in the performance of investment services and activities”. Sending erroneous orders to a trading venue can cause market wide consequences (e.g. lead to disorderly trading) but also impact the firm’s capacity to ensure the continuity and regularity of services due to remedial measures, risks mitigation measures to be implemented, etc. Hence, IFs are expected to establish controls which are aimed at preventing the sending of erroneous orders to the market.

12 ii. General organisational requirements for IFs are further specified in Article 21 of CDR 2017/565. According to this provision, IFs are expected (amongst others) to specify: i) decision-making procedures and an organizational structure which details reporting lines and allocates functions and responsibilities, and ii) adequate internal control mechanisms. IFs are expected to comply with these organizational requirements also when establishing procedures related to controls. Additionally, as per Article 21(5) of CDR 2017/565 investment firms are expected to “monitor and, on a regular basis, evaluate the adequacy and effectiveness of their systems, internal control mechanisms and arrangements established” and take measures to address any deficiencies. The latter entails that IFs are expected to regularly evaluate and review the effectiveness of the controls established and related procedures. iii. Article 23 of CDR 2017/565 specifies risk management requirements for IFs. This Article mandates IFs “to establish, implement and maintain adequate risk management policies and procedures which identify the risks relating to the firm’s activities, processes and systems (…)” and to “adopt effective arrangements, processes and mechanisms to manage the risks relating to the firm's activities, processes and systems”. Hence, the risk of sending erroneous orders to a trading venue should be considered and the establishment of appropriate controls is necessary to manage this risk. Additionally, as mandated by Article 23, controls should be calibrated based on a firm’s risk tolerance. 56. Overall, IFs which do not engage in algorithmic trading are expected to establish controls, calibrate those controls appropriately based on their risk tolerance, periodically review them to ensure their effectiveness and have in place appropriate policies, including clear responsibilities, regarding the operation of these controls. Although firms which do not engage in algorithmic trading are not required to establish PTCs as outlined in Art. 15 of RTS 6, ESMA encourages those firms to perform a risk-based self-assessment and where appropriate implement arrangements as those envisaged by Article 15 of RTS 6. ESMA deems compliance with those requirements a best practice. Are all orders submitted by an IF in scope of PTCs? Does this include quotes generated for the purpose of market making5? 57. Article 15 of RTS 6 mandates IFs to carry out PTCs on order entry for all financial instruments. This implies that all the orders sent to a TV should be subject to PTCs, independently of other elements such as the size of the order, the magnitude and frequency of the firm’s trading activity, and any other specificities. IFs are mandated to establish PTCs and should not solely rely on the PTCs set by trading venues. 58. Quotes, representing a binding commitment to buy and sell a financial instrument (Annex I, Table 1 of RTS 1), should also be subject to PTCs, as they are executable once sent to the market and can therefore entail risks as any other type of executable order. If quotes are generated through quotation algorithms the PTCs may be implemented automatically in the code of those algorithms. 5 This guidance and the following one is applicable only to IF engaging in Algo Trading.

13 Article 17(3)(c) of MiFID further requires market makers to have in place effective systems and controls to fulfil the agreement in place with the TV at all times. Which functions of the IF should be involved in the setting of PTCs? 59. PTCs should be set and reviewed in collaboration between trading, risk management and compliance functions, with the support of the IT function. The involvement of different functions – with different areas of expertise and responsibilities – ensures that PTCs are set meeting the requirements in Article 15 of RTS 6. PTCs should be sufficiently binding to meet the IFs overall risk limits (risk management) and legal constraints (compliance) while considering market-specific factors and business needs (trading). Should IFs implement all the types of PTCs mandated in Article 15 of RTS 6 for all financial instruments? 60. Yes, in principle IFs are expected to implement all the PTCs mandated in Article 15 of RTS 6, which include: i) price collars; ii) maximum order values; iii) maximum order volumes; iv) maximum message limits; and v) repeated automated execution throttles. Those should be established for each financial instrument on which algorithmic trading activity is undertaken. 61. In circumstances where: (i) a type of PTC is not pertinent (e.g. implementation of repeated automated execution throttles in cases where the algorithmic trading strategies are not subject to pre-set repeated execution; or controls on maximum volumes where instruments are traded based on value) or (ii) the goal of a type of PTC is already reached by the implementation of other PTCs, IFs are expected to include a justification in the annual self-assessment. Independently of any specificity in the tailoring of PTCs, IFs are expected to implement and appropriately calibrate PTCs to ensure their effectiveness on order entry. 3.2 Outsourcing Who is responsible for setting up, calibrating and testing PTCs in the case of: i) outsourcing of software used in the trading activity or ii) using third party systems offering algorithmic trading functionalities? 62. Article 4 of RTS 6 states that when an IF outsources or procures software or hardware used in algorithmic trading activities the IF remains fully responsible for the organizational requirements pertaining to IFs engaging in algorithmic trading. Furthermore, ESMA Q&A 34 on market structure issues6 states that: “when firms use third party systems offering algorithmic trading functionalities, 6 https://www.esma.europa.eu/sites/default/files/library/esma70-872942901- 38_qas_markets_structures_issues.pdf

14 they are ultimately responsible for compliance with the relevant requirements in Article 17 of MiFID II and RTS 6, as specifically detailed in Article 4 or RTS 6.” 63. The above implies that both in case of i) outsourcing of software used in the trading activity and in case of ii) use of third-party systems which offer algo trading functionalities, the IF is responsible for setting up, calibrating and testing PTCs. Nevertheless, there are instances where the IF might lack direct control over the system, its operation and the algorithms deployed and hence might not be materially able to ensure that all requirements are met. In this respect, Q&A 34 states that “firms can ensure compliance with those technical requirements that cannot be otherwise met by the firm itself through contractual arrangements with the system provider, where the latter commits to ensure that the system, its operation and the algorithms deployed are compliant with the relevant legal requirements.” The IFs remain nevertheless ultimately responsible to ensure compliance. 64. In reference to the setting and calibration of PTCs, it is important to note that to meet supervisory expectations IFs should not fully rely on the party to whom the trading activity has been outsourced (or on the service provider in case of third party systems), but rather actively contribute to the calibration of PTCs to ensure that the chosen parameters reflect their desired risk exposure. How should IFs set and calibrate PTCs when the risk management function is outsourced? 65. Article 16(5) of MiFID II requires that IFs outsourcing to third parties: i) the performance of operational functions which are critical for the provision of continuous and satisfactory service to clients; and ii) the performance of investment activities on a continuous and satisfactory basis, should take reasonable steps to avoid undue additional operational risk. Article 23 of CDR 2017/565 specifies the duties of the risk management functions which include: i) identifying and addressing risks related to the IF activity and setting, where appropriate the firm risk appetite and ii) monitoring the adequacy and effectiveness of the risk management policies and procedures. 66. In ESMA’s view the risk management function should be considered as performing functions which are critical for the provision of services and for the performance of investment activity. Hence, focussing on PTCs, ESMA is of the view that in case of outsourcing of the risk management function, including to a third-party provider but also to a separate entity within a corporate group, the IF should ensure that there is a designated internal function which contributes to the setting of PTCs from a risk management perspective, ensuring those are calibrated properly. Lacking such internal function ESMA is of the view that the IF would not be compliant with Article 16(5) of MiFID II by exposing itself to undue operational risks and furthermore would not comply with supervisory expectations as the IF remains responsible for compliance. 3.3 Direct Electronic Access Are IFs offering DEA (including DMA and Sponsored Access) expected to apply PTCs to orders submitted by their DEA clients to trading venues through the IF’s systems?

15 67. Yes. IFs are responsible for all orders submitted to trading venues via their systems. As such, firms offering DEA (including both DMA and Sponsored Access) must comply with Chapter 3 of RTS 6 – specifically Article 20, which outlines the requirements for PTCs. 68. DEA providers are expected to apply PTCs, including real-time monitoring, to all orders submitted by their DEA clients7 . These controls must be separate and distinct from any controls implemented by the DEA clients themselves. Regardless of whether the PTCs are developed internally, sourced from third parties, or offered by trading venues, they must be governed solely by the DEA provider. The provider remains fully responsible for the effectiveness of these controls and must retain exclusive authority to set or modify their parameters. The PTCs shall be calibrated based on the credit and risk limits assigned to each DEA client. 69. Article 22 of RTS 6 requires DEA providers to undertake a due diligence assessment of his perspective DEA clients to ensure they meet RTS 6 requirements, including PTCs. It should be noted that DEA clients that engage in algo trading face an obligation to set PTCs. However, any client-level controls do not relieve DEA providers of their obligations as they must independently comply with the requirements set out in Article 20 of RTS 6, regardless of the controls put in place by their clients. 3.4 Hard blocks and soft blocks Is the implementation of hard and soft blocks by IFs mandatory? 70. IFs in scope of RTS 6 must implement hard blocks and may implement soft blocks to comply with the requirements in Articles 15 and 16 of RTS 6. ESMA considers the implementation of soft blocks as a strongly recommended practice. What are ‘hard blocks’ and ‘soft blocks’ and which purpose do they serve? 71. Article 15 of RTS 6 mandates IFs to have in place mechanisms to block or cancel orders that do not meet set conditions (i.e. price, value, volume, etc.). To meet those requirements, IFs engaging in algorithmic trading are expected to establish two types of PTCs that can be defined as ‘hard blocks’ and ‘soft blocks’ that prevent (at least temporarily) the transmission of an individual order. 72. Hard blocks should be implemented to meet the requirements in Articles 15(1) and (3) of RTS 6. Hard blocks should be designed as mechanisms which block orders exceeding set price parameters, maximum order values and volumes, maximum message limits and limits on repeated execution of an algorithmic trading strategy. IFs can set the parameters underpinning hard blocks at their discretion taking into account: the firm’s desired risk exposure, the type of trading activity 7 As explained in ESMA_QA_1618, the obligations that fall on a DEA provider as per Article 17(5) of MiFID II and as specified in RTS 6 apply regardless whether the client is an authorised EU investment firms or not.

16 (e.g. market making algorithms vs order management algorithms), the asset classes and instruments traded, the overall risk tolerance of the IF, the trading venues on which trading takes place, and the financial instruments’ price levels, liquidity and volatility conditions. 73. The procedure for setting those parameters should be documented and involve at least the trading, risk management, and compliance functions. Traders should not be allowed to independently override hard blocks (and neither with the consent of a third party) without a prior thorough review of the parameters underpinning hard blocks. Any revision or modification of parameters should involve the risk management and compliance functions. 74. As an example, a mechanism which temporarily blocks an order but can be overridden at the trader or trading desk level does not constitute a hard block. A hard block should be set as a default limit which traders should not be able to overcome either directly (e.g. by modifying an order block’s parameters) or indirectly (e.g. by slicing blocked orders to circumvent the set parameters). Where possible, hard blocks parameters should be hard coded within an algorithm, ensuring that no order exceeding the limits can be introduced. 75. When IFs deploy soft blocks, those should be designed as mechanisms which provide alerts to the trader when the order approaches pre-trade, market or credit limits without triggering a hard block. Therefore, soft blocks should be designed using the criteria listed in Article 15 of RTS 6 but with lower thresholds and provide alerts to the trader, the staff engaged in real-time monitoring and any other relevant party before the submission of orders. 76. To ensure the effectiveness of soft blocks, it is recommended that those mechanisms require active input from the trader to be overridden or discarded (e.g. inputting again the order parameters, revising fields which set the characteristics of the order, etc.). 77. IFs can set the parameters underpinning soft blocks at their discretion based on their desired risk exposure and taking into account: the type of trading activity (e.g. market making algorithms vs order management algorithms), the asset classes and instruments traded, the overall risk tolerance of the IF, the trading venues on which trading takes place and the financial instruments’ price levels, liquidity and volatility conditions. 78. Ideally, soft blocks should be set with the involvement of the risk management and compliance functions. Soft blocks should be visible in the context of real time monitoring and especially multiple triggers of soft blocks should cause alerts for real time monitoring staff to check for unusual trading activity. 79. Where IFs decide to leave the calibration of soft blocks to the trading desk or to individual traders, training on the appropriate calibration of soft blocks and on the variables to be considered in the calibration should be provided. Soft blocks may be overridden by a trader as they should function as an operational warning or flexible limit to avoid operational risks and to the benefit of the trading and monitoring function. How should PTCs on order volumes and values be applied (case of ‘child orders’)?

17 80. In some instances, the orders which are submitted by an investment firm to a trading venue (or venues) are sliced in smaller orders which are individually submitted for execution (‘child orders’) until the total amount (or the desired amount) of the initial order (‘parent order’) is executed. 81. It should be noted that applying PTCs on order volumes and values exclusively to individual child orders is not sufficient to prevent the sending of erroneous orders and does not meet supervisory expectations. In fact, even if individual child orders would meet volume and/or value limits this does not ensure that the total volume and/or value of the parent order does not breach the limits. 82. IFs are expected to apply volume and/or value limits to both the parent order and the child orders, to ensure there is no erroneous order sent to the market resulting from an erroneous slicing of the original order. IF are also expected to ensure that when child orders are submitted by an automated algorithmic strategy, checks are applied to the cumulative volume and/or value of the orders to avoid exceeding the volume and/or value initially set for the parent order. This is intended to avoid possible loops of the executing algorithm. 3.5 Calibration, testing and revision of PTCs What are the supervisory expectations in PTCs calibration? 83. The purpose of PTCs is to prevent: i) sending erroneous orders, and ii) the malfunctioning of an IF’s system which could trigger disorderly markets conditions. For PTCs to be effective it is necessary for the parameters underpinning PTCs to be well calibrated. IFs are expected to set the methodology for the calibration of PTCs and document their rationale, using quantitative data. 84. Whilst each IF should independently set its methodology for PTC calibration, IFs are expected to consider at least: i. the type of trading activity (e.g. market making algorithms vs order management algorithms); ii. the potential impact of the full range of any trading signals in accordance with which the IF’s algorithmic trading systems are designed to act, having regard to whether such trading signals are generated using deterministic or non-deterministic technologies; iii. the asset classes and instruments traded; iv. the overall risk tolerance of the IF; v. the trading venues on which trading takes place; vi. the financial instruments’ price levels, liquidity and volatility conditions.

18 85. In relation to point ii of the above paragraph it should be noted that certain market participants are using more advanced AI-related technology in the generation and formulation of trading signals in accordance with which the traditional algorithmic trading technology then acts to impact on-market in the form of orders, cancellations and executions, often directly with no human intervention. This technology can include reinforcement learning, deep learning, neural-networks, and GenAI. IFs should consider risks posed by trading signals generated by more advanced AI-related technology when designing PTCs. This is in line with the text of Recital 2 and Point 3(b) of Annex 1 of RTS 6. 86. Dedicated key performance indicators in relation to the operation of PTCs and their effectiveness should be systematically available to provide insights on risky practices and the suitability of limits. 87. When feasible, it is considered good practice for IFs to undertake market impact checks during the trading sessions to measure the impact of their orders and dynamically update PTCs based on this assessment and the evolving market conditions. Should IFs test their PTCs to ensure that their functioning meets the intended outcome? 88. Yes, IFs are required to test PTCs. Testing is expected to take place periodically, as a minimum: i. at the time of design and calibration of PTCs and before they are deployed, ii. following any major change in the algorithm governing PTCs, when those are embedded in an algorithm, iii. following any risk event which may indicate that PTCs may not be operating as designed or after a major change in market conditions which could render PTCs not effective. 89. It is considered a good practice for IFs to i) test PTCs following each recalibration and before their deployment and ii) monitor the effectiveness of recalibrated PTCs after their deployment. What are the supervisory expectations in the revision of PTCs calibration? 90. IFs are expected to periodically revise the calibration of PTCs. While each IF has discretion in deciding how often to recalibrate its PTCs, IFs are expected to do so with a periodicity that ensures parameters underpinning PTCs are up to date and performing in a manner that ensures that the IF can meet its obligations under Article 17 of MiFID II on an on-going basis. 91. The frequency of recalibration shall consider the likelihood of changes in the variables used for the calibration of PTCs, including the potential impact of trading signals in accordance with which the IF’s algorithmic trading systems are designed to act. 92. IFs are expected to collect statistics on established PTCs, indicating at least the number of times they have been triggered over a set time period. The statistics collected should be used for the purpose of evaluating the effectiveness of established PTCs and in the context of their revision.

19 3.6 Governance practices in relation to PTCs How should IFs monitor PTCs? 93. In accordance with Article 16 of RTS 6, IFs are required to install a real time monitoring system to identify unanticipated trading activities undertaken by an algorithm. Unlike hard and soft blocks, real￾time monitoring alerts may lead to various pre-defined remedial actions that target not only an individual order but eventually the usage of one algorithm for one financial instrument, one market or one client or the usage of an entire algorithm. Real-time monitoring alerts may also lead to the cancellation of orders, a withdrawal from the market or the use of the kill functionality. 94. Article 16(1) of RTS 6 requires IFs to engage in real-time monitoring of all their algorithmic trading activity with the aim of detecting any signs of disorderly trading. The monitoring should also include the alerts from triggering PTCs. 95. Article 16(2) of RTS 6 further specifies how IFs should conduct real-time monitoring. This provision requires IFs to have ‘two lines of defense (hereafter 2 LoDs) and monitoring being undertaken: i) by the trader in charge of the trading algorithm (or algorithmic trading strategy), and ii) by the risk management function or by an independent risk control function established for this purpose. 96. Hence, IFs are required to have in place 2 LoDs, with the risk management (or control) function being necessarily independent from the trader. The independence of the risk management or control function implies that the function should not be hierarchically dependent from the trader, should be endowed with appropriate powers, tools and procedures to challenge the trader and should not be directly involved in the activity of the trader. As an example, the head of a trading desk should not be considered independent from the traders of the trading desk, and an IT function should not be considered as being endowed with the appropriate powers, tools and procedures to independently challenge a trader. 97. IFs are also expected to establish clear procedures to be followed once breaches of PTCs are reported but the firm nevertheless wishes to submit an order to the TV (as per Article 15(6) of RTS 6) and follow-up actions in various scenarios (e.g. triggering of execution throttles, repeated triggering of soft and/or hard blocks, etc.). The procedures should be documented in writing and the follow-up actions should be proportionate to the possible level of disruption that may result from any breaches. 98. The resources deployed in the monitoring of alerts and the complexity of the alert systems might vary depending on the type of trading activity (including volumes and type of algorithms used). 99. In monitoring real-time alerts generated by PTCs, IFs should also be aware of the link between real￾time monitoring controls under Article 17 of MiFID and RTS 6, and the requirement for effective systems and risk controls to ensure the trading systems cannot be used for any purpose that is contrary to MAR, or to the rules of a trading venue to which it is connected.