Does MiFID II Article 17 Apply to Your Trading Bot?

The signal

The useful operating document is a dated explanation of the legal entity, product, execution route and responsibility for each order parameter. That explanation should change when the business or system changes, rather than remain attached permanently to a software brand.

First identify the actor and its actual role

Article 17 imposes systems, risk-control and related duties on investment firms engaging in algorithmic trading; it also contains distinct provisions for market-making strategies, direct electronic access providers and general clearing members. [1] These roles should be recorded separately rather than compressed into “uses a bot”.

ESMA’s 26 February 2026 supervisory briefing also covers the specified exempt members or participants of regulated markets and multilateral trading facilities brought into Article 17(1)–(6) by MiFID II Article 1(5). [3] An authorisation exemption therefore does not, by itself, settle every trading-control question.

DN proposes a one-page actor record: legal entity, home jurisdiction, relevant authorisation or exemption basis, whose money is traded, services provided to others, venue membership and access arrangement. Attach the underlying contract or regulatory record to each factual statement. Do not substitute a marketing description such as “technology company” or “personal automation” for those facts.

A retail user, an investment firm executing orders and a supplier selling software may participate in the same workflow while occupying different positions. The proper review identifies the obligations of each. An API connection is evidence of a technical interface; whether it constitutes a legally defined access arrangement requires examination of the arrangement itself.

Then classify the instrument, including tokenised products

Financial-instrument classification comes before applying an algorithmic-trading definition that depends on it. A product’s token format, exchange category or marketing name is a starting clue, not a completed assessment. Keep the instrument’s contractual terms alongside the trading-system record.

ESMA’s March 2025 crypto-asset classification guidelines apply a technology-neutral, substance-based approach and explain that tokenising a financial instrument does not remove that status. Their examples do not replace case-by-case assessment. [4] A tokenised share, a derivative referencing crypto and a spot token should therefore not be assumed to follow one identical route.

For practical review, record what the holder can demand, from whom, and under which conditions. Identify whether the product represents a share, debt claim, derivative or another arrangement. Then record the classification conclusion, its supporting authority and any unresolved facts. The analyst should be able to explain the conclusion without relying on the word “blockchain”.

The opposite error also matters: a product falling outside the relevant financial-instrument classification does not become free of all EU obligations. Other regimes and conduct rules require their own scope analysis. The decision is which framework applies to which part of the activity, not whether a convenient label can switch regulation off.

Map who determines each order parameter

MiFID II’s definition turns on algorithms determining order parameters with limited or no human intervention. It excludes certain processing and routing functions that do not determine trading parameters. [2] The useful evidence is therefore the order-decision path.

ESMA’s 2022 answer on automated order management treats functions such as slicing orders or automatically redirecting unexecuted portions differently from simple routing that leaves the order’s parameters unchanged. [5] A supplier’s “execution assistance” label does not resolve that distinction.

The 2026 supervisory briefing says human authorisation before submission does not necessarily remove an algorithmically determined order from scope. It separately distinguishes an algorithm that merely informs a trader of an opportunity, where execution is not algorithmic. [3] The point is what the system actually determines, not whether a person appears somewhere in the workflow.

Consider two hypothetical designs. One displays a research alert and the trader independently chooses every order parameter. Another calculates size and price, then waits for an approval click. These descriptions are different evidence for the activity analysis; neither is a complete determination of the operator’s legal obligations.

A reviewable implementation record should name the source of initiation, timing, price, quantity and post-submission changes. Preserve a sample order trace showing the model output, any human modification and the final instruction. That trace makes the legal discussion concrete and exposes embedded execution logic that a high-level architecture diagram might miss.

A vendor contract cannot erase the regulated firm’s responsibility

ESMA’s third-party-systems answer says a firm remains ultimately responsible for the relevant Article 17 and RTS6 requirements when using a provider’s algorithmic functionality. It recognises contractual arrangements as a way to address technical requirements the firm cannot otherwise meet directly. [6]

The procurement implication is specific. Ask what the supplier can demonstrate about the version used, how material changes are communicated, which testing evidence is available, how faults are investigated and which records can be exported. A broad statement that a product is “compliant” does not answer those questions for the customer’s actual deployment.

Assign operational tasks explicitly: who configures a limit, who can change it, who receives an alert, who stops an order flow and who retains evidence. This is DN’s suggested responsibility map. It should distinguish a supplier’s contracted service from the obligations that remain with the operating firm.

The strongest countercase is a standardised provider with clear controls, robust evidence and well-defined customer responsibilities. Outsourcing can improve a firm’s operational capability. The analysis does not presume that building everything internally is safer; it asks whether the arrangement gives the responsible entity enough understanding and evidence to fulfil its role.

If several entities generate, route and execute orders, the contract map should follow that chain. A responsibility gap should remain an unresolved issue until the parties can explain it. Giving every box a vendor name is not the same as assigning accountable decisions.

Keep capacity, resilience and conduct controls connected

The current official Article 17 text references DORA in its resilience, business-continuity and testing provisions. [1] ESMA states that DORA applies from 17 January 2025 and addresses digital operational resilience across specified financial entities. [8] A 2026 review should therefore not rely solely on a pre-DORA checklist.

DN’s proposed evidence pack links each relevant obligation to an owner, a control, a test or observation, and a record that can be retrieved. This makes it possible to distinguish a documented policy from a demonstrated operation. A written procedure can be useful evidence of design while remaining insufficient evidence of execution.

For example, a stop control needs a defined scope: which orders or strategies it affects and who can activate it. A capacity test needs a workload definition and measured behaviour under that workload. An incident record needs the actual sequence of events. These are implementation questions to investigate, not a claim that this article has tested a trading system.

The scope decision still comes first. An organisation may voluntarily use rigorous controls even where a particular provision does not apply, but voluntary practice should be labelled as such. A useful framework can be adopted without describing every recommendation as a statutory obligation.

Use the load planner as a numerical comparison

RTS6 Article 10 specifies stress tests using twice the highest messaging load and twice the highest trading volume reached during the previous six months. It calls for tests suited to the activity and systems, without affecting production. The 2026 ESMA briefing reiterates the capacity expectation. [7] [3]

The tool simply doubles the two entered historical peaks and compares the planned test loads with those baselines. All defaults are hypothetical. A previous peak of 100,000 messages produces a 200,000-message baseline. A planned 180,000-message test is 20,000 below it, or 10% below. A previous trading-volume peak of two million consistent units produces a four-million-unit baseline; a five-million-unit plan is 25% above it.

Use the same observation interval, counting convention and system boundary for each historical-to-planned comparison. Do not compare an hourly peak with a daily test total, or message traffic at one gateway with the whole organisation’s trading volume. The trading-volume unit must remain consistent; the tool does not choose its legal or operational definition.

A positive headroom figure does not demonstrate that a test was run, that the system behaved acceptably or that other required scenarios were covered. It is capacity planning arithmetic. If the historical data are incomplete or no meaningful positive peak exists, this planner cannot establish the appropriate test design; the responsible team must address that gap directly.

Market integrity has its own scope

An Article 17 conclusion does not settle every market-abuse question. ESMA’s MAR overview describes coverage extending beyond regulated-market admissions to specified MTF and OTF instruments and instruments whose prices depend on or affect covered instruments. [9] The instrument and conduct therefore need their own assessment.

For crypto-assets within MiCA’s relevant scope, Article 86 applies its market-abuse title to assets admitted to trading or for which admission has been requested, including relevant behaviour away from a trading platform. [10] This should not be restated as a universal Article 17 obligation for all spot-token bots.

DN’s operational implication is to preserve the strategy’s purpose, order behaviour and relevant market context. If an alert flags suspicious conduct, it needs a reasoned investigation rather than an automatic assumption that the model’s output was legitimate. Conversely, a system flag alone does not establish a legal breach.

This article does not create a combined compliance score. Capacity, authorisation, instrument classification and conduct answer different questions. Merging them into one percentage would conceal an unresolved scope issue behind a superficially precise number.

Maintain a dated rule map as the product changes

Publication, entry into force, application and the date of a consolidated text are different fields. Record them separately, together with the source URL and the provision actually relied upon. A new press release can explain an existing rule; it does not necessarily create a new legal duty on its publication date.

The distinction is visible in the sources here. The February 2026 supervisory briefing explicitly describes itself as non-binding and outside a comply-or-explain mechanism. [3] DORA’s application date is a different kind of event. The source register labels official guidance, rulebook provisions and the dated technical standard rather than presenting them as interchangeable documents.

DN proposes rechecking the map when the entity’s service changes, a new instrument is introduced, venue access changes, a supplier adds execution functionality or the system begins determining a parameter previously chosen by a human. A legal conclusion based on yesterday’s workflow should not quietly be carried into a different one.

Keep a change log showing the earlier conclusion, the changed fact or source, the reviewer and the resulting action. This is a manual governance proposal; no regulatory-monitoring agent has been built and no compliance determination is automated here. The benefit is a clear queue of decisions that require human accountability.

The practical deliverable is a scope memo with evidence: actor, instrument, activity, access route, relevant obligations, current source versions and unresolved questions. That memo gives legal, compliance and engineering teams a common object to review. The calculator contributes one transparent planning calculation after that work; it cannot replace it.

The evidence, side by side

DN RTS6 Stress-Load Planning Comparison

Hypothetical workload planning after scope assessment; no legal applicability decision, compliance score or executed stress test.

All inputs finite and bounded; positive historical peaks; nonnegative planned loads; message counts must be whole numbers; denominators must be positive.

Does not decide whether Article 17 or RTS6 applies. Does not establish testing sufficiency, system resilience, conduct compliance or notification fulfilment. A zero or missing historical baseline needs a separate test-design decision rather than an invented percentage.

Scenarios to watch

Mixed numerical headroom

Default hypothetical loads.

Messaging plan is 10% below its baseline; trading-volume plan is 25% above. No compliance verdict.

Plans equal baselines

200,000 messages and four million volume units planned.

Zero numerical headroom on both measures; no evidence a test has been run.

No load planned

Both planned loads set to zero, historical peaks unchanged.

Both plans are 100% below the calculated baselines.

Method and limitations

We read ESMA’s official rulebook provisions, the February 2026 algorithmic-trading briefing, crypto-asset classification guidelines, published Q&As and regulator summaries of DORA and market integrity. These are used for their stated scope; guidance is distinguished from legislation.

RTS6 Article 10’s statutory excerpt was recovered from the official EUR-Lex indexed text and corroborated against paragraph 32 of the opened 2026 ESMA briefing. Several EUR-Lex page opens redirected to the journal homepage; the review does not claim to have read a full current consolidated directive through those failed opens.

The load calculator uses synthetic inputs and pure arithmetic. Tests cover mixed headroom, exact equality, zero planned loads and invalid zero historical peak. No trading system or legal applicability engine was tested.

National implementation, exemptions, cross-border arrangements and the exact services of an individual entity require a fact-specific professional assessment. This article does not give a personalised legal conclusion or extend EU rules automatically to other jurisdictions.

Source access date is not proof that every linked provision will remain unchanged. The tool provides neither a complete control catalogue nor a legal or operational certification.

Primary sources and evidence register

Source dates and reporting periods differ. Several documents from one issuer are one source family, not independent confirmations. The evidence download contains the observations used in this article.

Frequently asked questions

Does every bot user need an Article 17 compliance programme?

That cannot be inferred from using software. Establish the entity, instrument, activity and access arrangement before selecting the applicable obligations.

Does a human approval click settle the activity question?

No. Determine who or what sets the order parameters. The article explains why the actual decision path matters more than an interface label.

Does positive calculator headroom mean compliant?

No. It only compares planned numbers with entered historical baselines. It neither runs a test nor assesses the legal scope or the test outcome.

When should the scope memo be revisited?

DN proposes a review when material facts change: services, instruments, venue access, suppliers or responsibility for order parameters. Track official rule versions and their application dates separately.