Surviving the ESMA algorithmic trading audit: conformance testing under RTS 6 and Article 48

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

Why a non-binding briefing matters for compliance planning

ESMA's supervisory briefings do not create new legal obligations. They are convergence tools, intended primarily for national competent authorities, and firms are correct to note that a briefing is not subject to comply-or-explain in the way a formal ESMA guideline is. Treating the February 2026 briefing as optional reading on that basis, however, misreads what the document actually is.

The briefing was prompted by continued divergence in how NCAs across the EU were supervising algorithmic trading under MiFID II and RTS 6, including divergence that surfaced through ESMA's common supervisory action (CSA) on pre-trade controls. ESMA announced on 2 July 2025 that the CSA had concluded, reporting that most investment firms had integrated pre-trade controls into their trading activity and risk management frameworks, but that practices around implementation and governance were often divergent and not always robust. ESMA committed at the time to publishing further guidance, including clarifications and best practices, and the February 2026 supervisory briefing is that guidance. Where a supervisory briefing exists specifically to standardise enforcement practice, firms should expect the NCA examining them to be working from that briefing's expectations, even though the underlying legal text, RTS 6 itself, has not changed. The practical effect is closer to a soft law update than a genuinely optional reference document.

The legal architecture: MiFID II, Article 48, and RTS 6

Article 48 of MiFID II requires regulated markets to ensure their trading systems can maintain orderly trading under conditions of severe market stress and imposes specific testing criteria on that resilience. Under Article 18(5), the same obligations extend to multilateral trading facilities and organised trading facilities, not only to regulated markets narrowly defined. Regulated markets are also required to make members carry out appropriate algorithm testing and to provide environments that facilitate it.

The operational detail sits in the delegated regulations. Commission Delegated Regulation (EU) 2017/589, known as RTS 6, specifies systems and process requirements for investment firms engaged in algorithmic trading. A parallel instrument, RTS 7, addresses the equivalent obligations for trading venues. RTS 6 has applied since 3 January 2018, alongside the rest of MiFID II, and it remains the operative technical standard; the February 2026 supervisory briefing interprets and clarifies RTS 6 rather than replacing any part of it.

What counts as algorithmic trading: the scope question firms get wrong

Article 4(1)(39) of MiFID II defines algorithmic trading as trading in financial instruments where a computer algorithm automatically determines individual parameters of orders. ESMA's briefing spends considerable attention on this definition because, in its supervisory experience, firms and even some NCAs have applied it inconsistently.

The clarification that matters most operationally: even where humans intervene in the trading process, the involvement of a computer algorithm in determining any individual order parameter, for a purpose other than order routing or post-trade processing, makes the activity algorithmic trading within the meaning of MiFID II. This closes a gap some firms have used to argue that human-supervised or human-triggered systems fall outside RTS 6 because a person remains in the loop. ESMA's position is that the presence of human oversight does not remove an activity from scope if an algorithm is still setting order parameters.

Firms operating execution management systems, smart order routers with parameter-setting logic, or hybrid workflows where traders approve algorithmically generated order parameters before submission should re-examine whether those workflows have been correctly scoped into or out of RTS 6 compliance.

Pre-trade controls: the area with the clearest documented weaknesses

Pre-trade controls (PTCs) are designed to prevent erroneous orders and system malfunctions that could trigger disorderly trading conditions, and they are the area where ESMA's common supervisory action found the most divergent and least robust implementation and governance practices.

Scope of application

PTCs must apply to all orders submitted to trading venues, including quotes generated for market making purposes. ESMA's briefing goes further than the strict letter of RTS 6 by stating that it considers it best practice for firms not engaged in algorithmic trading to apply the specific PTC requirements anyway, grounding this expectation in MiFID II's general organisational requirements rather than the algorithmic trading provisions specifically. Firms that have treated PTC obligations as relevant only to their algorithmic desks should note that ESMA's supervisory expectation extends beyond that boundary.

The mandated control types

Article 15 of RTS 6 mandates specific categories of pre-trade controls: price collars, maximum order values and volumes, maximum message limits, and repeated automated execution throttles. These are not illustrative examples; ESMA's briefing treats them as the required minimum set, with firms expected to demonstrate implementation of each category rather than a subset judged sufficient by internal risk assessment.

Third-party and outsourced algorithm arrangements

Where a firm uses algorithms developed or operated by third parties, whether procured commercially or provided by another entity in a chain of arrangements, the firm remains fully and solely responsible for RTS 6 compliance. Outsourcing does not transfer or dilute the regulatory obligation. In cases where only one party in a contractual chain qualifies as a MiFID II investment firm, that entity is deemed responsible for RTS 6 compliance regardless of which party actually built or operates the algorithm.

This has a direct documentation consequence: a firm relying on a third-party algorithm needs its own evidence of testing, oversight, and control, not simply a vendor's assurance that the algorithm was tested. A parallel UK review under equivalent rules found this to be one of the clearer differentiators between stronger and weaker compliance programmes, with weaker programmes relying solely on vendor testing for third-party algorithms without documenting the firm's own procedures around that reliance.

Conformance testing: what "appropriate testing" actually requires

Before an algorithm is deployed, investment firms must certify and explain their algorithm testing activities to the trading venues on which they will trade. Trading venues are expected to embed testing obligations into their own rules and membership requirements, and conformance testing is explicitly made a condition of the due diligence trading venues apply to members.

Conformance testing and stress testing both require a testing environment strictly separated from the production environment, at both the investment firm and the trading venue level. Firms may use testing environments provided by a trading venue, a direct electronic access (DEA) provider, or a vendor, but using a third-party testing environment does not relieve the firm of responsibility for the testing outcome, and firms must also use their testing environment to conduct required stress tests, not only initial conformance checks.

A parallel supervisory review of principal trading firms under equivalent RTS 6 rules, examining the same conformance and stress testing obligations, found that most firms did complete required conformance testing, and some exceeded venue minimum requirements with clearly defined escalation triggers. The weaker programmes identified in that review shared common characteristics: ill-defined procedures for when conformance testing was required, weak record-keeping around what had actually been tested, and reliance on vendor-provided testing for third-party algorithms without independent documentation. The clearest practical takeaway is that codifying when conformance testing is required, what scenarios it must cover, and how the results are recorded is where firms most often fall short, not the existence of a testing programme itself.

Stress testing: the annual self-assessment obligation

Article 10 of RTS 6 requires that, as part of the mandatory annual self-assessment, investment firms test whether their algorithmic trading systems, and the procedures and controls around them, can withstand increased order flows or market stress. Firms are expected to design these tests with reference to the nature and scale of their own trading activity, rather than applying a generic industry template.

ESMA's supervisory guidance on this obligation has consistently suggested a specific benchmark: firms should be able to evidence a reasonable level of assurance that their systems can process at least twice the volume of the highest trading volume the firm reached during the preceding six months. This benchmark is a supervisory expectation communicated through guidance rather than a number written directly into RTS 6's text, which is precisely the kind of detail firms should expect to find clarified in supervisory briefings and Q&A output rather than in the base regulatory technical standard.

The parallel UK multi-firm review found that stronger stress testing programmes combined theoretical scenarios with actual historical stress periods and considered conduct risk implications before deployment, while weaker programmes lacked breadth in scenario coverage and adequate documentation. ESMA's own briefing encourages firms to broaden simulation and stress testing to include recent stress periods specifically, rather than relying only on generic theoretical scenarios that may not reflect the firm's actual market conditions.

Governance, the annual self-assessment, and the AI question

Article 9 of RTS 6 requires an annual self-assessment and validation process, culminating in a validation report covering the firm's algorithmic trading systems, trading algorithms and strategies, and its governance, accountability, and approval framework.

RTS 6 does not reference artificial intelligence explicitly, since it predates the current wave of AI integration into trading systems by several years. ESMA's briefing addresses this gap directly, noting that AI's capacity to analyse large datasets, identify complex patterns, and make autonomous decisions has materially changed the character of algorithmic trading since RTS 6 was drafted. The specific risk ESMA highlights is that a series of individually minor recalibrations to an AI-driven trading model can accumulate, if uncontrolled, into a material change in model output that was never subject to the scrutiny a deliberate, single material change would trigger.

ESMA's recommendation is that firms use the two provisions RTS 6 already provides, the annual self-assessment under Article 9 and the broader governance and control framework, to demonstrate oversight of AI's role in algorithmic trading, rather than waiting for a dedicated AI-specific RTS 6 amendment. The briefing also notes the interaction with Regulation (EU) 2024/1689, the AI Act, though the detailed compliance overlap between the AI Act's own risk classification framework and RTS 6's algorithmic trading governance requirements is still developing in supervisory practice.

The concept ESMA says needs a shared definition: "algorithmic trading strategy"

A more technical but operationally significant point in the briefing concerns the term "algorithmic trading strategy," which RTS 6 uses repeatedly across reporting, testing, documentation, and market abuse surveillance obligations without ever explicitly defining what constitutes a distinct strategy. ESMA's briefing flags this as a source of inconsistent interpretation between firms and between NCAs, given how central the term is to determining the scope of several separate compliance obligations at once.

For firms, the practical implication is that the boundary of what counts as one strategy versus multiple related strategies affects testing scope, self-assessment scope, and market abuse surveillance scope simultaneously. A firm that defines its strategies too broadly risks under-testing distinct algorithmic behaviours; a firm that defines them too narrowly risks a disproportionate documentation burden. ESMA's briefing does not resolve this with a bright-line rule, which means firms should expect continued NCA-level variation on this specific point even after the briefing's publication.

Summary of the core RTS 6 obligations referenced in the briefing

What firms should be doing now

The most immediate action for firms engaged in any form of automated order generation is re-testing the scope question: whether workflows involving human review of algorithmically generated order parameters have been correctly classified as algorithmic trading under the interpretation ESMA's briefing confirms. Misclassification here understates the entire compliance perimeter, not just one control.

For firms with existing conformance and stress testing programmes, the practical gap most likely to surface under supervisory review is documentation of the firm's own procedures where third-party or vendor-provided algorithms are involved, independent of whatever testing the vendor itself performed. A vendor's test report is not a substitute for the firm's own documented conformance and stress testing procedure.

For firms using AI within algorithmic trading systems, the annual self-assessment under Article 9 needs to explicitly address AI's role and the risk of cumulative model drift from incremental recalibration, since this is now a clearly signalled supervisory expectation even though RTS 6's text has not been amended to require it directly.

For the broader MiFID II and MiFIR technical standards environment this briefing sits within, see what are regulatory technical standards and why do they matter more than the regulation itself. For related operational resilience testing obligations under DORA, see who needs TLPT under DORA? Mapping the technical criteria.

Forseti monitors ESMA supervisory briefings, RTS updates, and Q&A publications continuously, anchored to verified official sources including EUR-Lex and ESMA publications. Start for free.