Human approval and outsourced code do not settle a broker’s algorithmic-trading duties

A trader clicks to approve an order, but software has already selected its size, timing or price. Under ESMA’s interpretation of MiFID II, that human approval does not by itself make the trading non-algorithmic. Nor does buying the software from a vendor transfer the regulated firm’s responsibilities to its supplier. The European Securities and Markets Authority’s 26 February 2026 briefing explains why the relevant questions concern what the computer decides and what control the firm retains.[1][2]

The briefing is non-binding supervisory guidance and is not subject to a comply-or-explain mechanism. It interprets the existing MiFID II framework and regulatory technical standards, including RTS 6, rather than creating a new offence whenever a person approves a computer-generated order. Its practical contribution is to connect classification with governance, change management, testing and the ability to restrain orders before they reach a market.[1]

The point at which a manual trade becomes algorithmic

Article 4(1)(39) of MiFID II defines algorithmic trading by whether a computer algorithm automatically determines individual parameters of orders, including whether to initiate an order or how to determine its timing, price, quantity and management, with limited or no human intervention. ESMA says some firms place too much weight on the presence of a trader who authorises the order before it reaches a venue. If a computer has already decided an individual parameter beyond mere routing or post-trade processing, that intervention does not undo the character of the preceding calculation. Approval of a machine-selected price is not the same as independently choosing that price.[1]

The classification is nevertheless narrower than saying every electronic brokerage service operates an algorithmic-trading strategy. A system that merely displays a potential investment opportunity, leaving every order parameter to a person, is not automatically covered by this definition. Pure transmission of an order without determining trading parameters, confirmation services and post-trade processing are likewise outside this particular algorithmic category. A simple router choosing a destination is distinguishable from a smart router that changes price, timing or quantity to optimise execution. These boundaries matter to a firm with an execution-management system supplied by one company, a smart router supplied by another and its own discretionary dealers.[1]

Consider two hypothetical orders for the same instrument. In the first, a customer enters a limit price, size and validity period and software conveys those instructions to an execution venue without changing their substance. In the second, a dealer approves a parent order but software slices it into child orders, varies placement with market depth and changes aggression in response to available liquidity. A human may approve both parent instructions, yet the second system performs decisions of the sort ESMA identifies as algorithmic. The example is an interpretation of the published guidance, not a finding about any actual provider or its clients.[1]

A strategy needs an identity that survives the vendor interface

ESMA defines an algorithmic-trading strategy by its autonomous decision logic and observable trading objective. Supervisors need to be able to identify which strategy produced particular orders, even when several algorithms are deployed simultaneously. Treating an entire execution platform as one algorithm can obscure materially different risk profiles. Conversely, describing every parameter combination as a separate strategy can multiply documentation without making the actual trading logic more intelligible. The supervisory challenge is to set a meaningful boundary around behaviour that can be tested, linked to orders and controlled.[1]

For a broker, a useful inventory would connect a strategy’s purpose and authorised markets to its order parameters, limits, owner, version history and tests. This is an operational inference from ESMA’s guidance, not a claim that the authority mandates these exact database fields. Without that connection, a firm may hold a vendor product name without knowing which version produced a disputed order or which change altered its behaviour.[1]

What counts as a material change

One of the briefing's most consequential passages addresses cumulative change. An execution algorithm may undergo a series of small recalibrations that, taken together, alter its risk profile substantially. ESMA warns that firms must not let nominally minor changes escape testing when their accumulated effect materially changes behaviour. It identifies modifications to decision rules, execution and order-slicing logic, instruments, venues, risk-control thresholds, external data feeds, third-party providers and machine-learning components as examples to assess. The relevant question is not whether a developer labelled the release 'minor'; it is whether the operational result could differ materially.[1]

A record of model versions, inputs and approvals helps a firm examine that cumulative effect. ESMA also expects compliance staff to have a general understanding of the algorithms and to remain in contact with people who understand them technically. That connects the technical account of a change with the people responsible for evaluating its regulatory consequences.[1]

The two-volume stress test

Article 10 of RTS 6 specifies two capacity tests as part of the annual self-assessment. The messaging test uses twice the highest number of messages received and sent during the previous six months. The trade-volume test uses twice the highest volume of trading in the same lookback period. These are peak-based inputs, not twice the six-month aggregate. The tests must reflect the firm’s activity and systems and must not affect the production environment. ESMA’s briefing further stresses the challenge of testing trading from order generation through post-trade processing.[1][3]

The distinction between messages and trades is operationally significant. A market-making algorithm might produce many cancellations and amendments but comparatively few completed trades. Another system might process relatively low message counts while generating very high transaction volumes and post-trade reconciliation work. A load test that proves a gateway can receive twice its normal order messages does not by itself prove downstream allocation, clearing and controls will cope with twice the peak completed-trade volume. Each firm's look-back period, relevant maximum and processing chain need to be explicit before the result can be interpreted.[1]

A reproducible capacity test therefore needs a documented unit and interval for the peak, as well as the multiplier. Comparing a test measured per second with a historical figure measured per day would not establish equivalent capacity. The two peaks may also have occurred in different periods. Those are methodological implications of using peak messaging and trading activity; the rule is not a promise that doubling a number will cover every market shock or preserve execution prices.[1][3]

Why outsourcing does not transfer accountability

For procured or outsourced algorithms, ESMA says the investment firm retains its MiFID II and RTS 6 responsibilities. Arrangements should provide ongoing access to performance information, data, testing documentation and records, along with the capacity to monitor, suspend or terminate the algorithm’s trading without needing the vendor’s consent or intervention. These are substantive control questions. A contract asserting that a supplier is responsible is insufficient if the firm cannot obtain the information or stop the activity described.[1]

In more complex execution chains, the allocation of duties depends on which entity makes algorithmic decisions and which provides direct electronic access. ESMA discusses circumstances in which more than one investment firm in the chain can have obligations arising from its own activities. A direct-electronic-access provider requires independently effective controls over the orders it permits into the market. The question is not simply whether a client, another broker or a technology company promised to monitor risk. It is whether the regulated provider can demonstrate that its own protections function and that it can stop inappropriate access when necessary.[1]

A useful documentary test is to follow one hypothetical order from investment decision to venue acknowledgement. Identify the entity whose software selects quantity or timing; the person approving the deployment; the gateway applying pre-trade credit and price controls; the firm responsible for detecting disorderly orders; and the actor capable of disabling a strategy during an incident. If all five answers are attributed to a supplier without retained evidence or control at the regulated firm, the arrangement deserves scrutiny. This is a proposed review method, not a claim that ESMA has formally found any particular broker deficient.[1]

Pre-trade controls must exist where the order actually crosses the boundary

The supervisory briefing grew partly from ESMA's 2024 common supervisory action on pre-trade controls following the 2022 Nordic flash crash. Its findings were nuanced: most firms reviewed had integrated pre-trade controls into their trading and risk frameworks, but implementation and governance practices varied and were not always robust. It is therefore wrong to describe the document as proof that European algorithmic brokers operate without safeguards. The concern is consistency and demonstrated effectiveness, including the independence and configuration of risk limits relative to the software generating orders.[1]

Different controls address different problems. Price collars restrain erroneous prices; order-value and volume limits constrain excessive size; message limits address order traffic; and the RTS 6 emergency kill functionality requires the ability to cancel unexecuted orders. A price collar alone will not necessarily detect manipulative behaviour inside its permitted range. A documented cancellation function is also of limited practical value if the responsible firm cannot reach and operate it under stress.[1][3]

ESMA distinguishes hard blocks from soft blocks. Firms within the relevant RTS 6 scope must implement hard blocks; soft blocks are strongly recommended. A warning that a trader can override is different from a hard limit the trading desk cannot independently bypass. Changes to hard-block parameters should receive the relevant risk and compliance review. The distinction makes it necessary to test the response to a breach, rather than treating every alert or red warning on a screen as an effective order stop.[1]

The evidence that connects decisions to controls

A meaningful control review would connect live algorithms and their versions to testing approvals, vendor changes, order traces and emergency controls. It would also examine whether the firm can obtain evidence promptly and suspend trading when needed. That is a practical implication of the records reviewed here; this article does not test a named platform or infer that a broker’s arrangements fail because its code is supplied externally.[1]

The resulting test has three parts: identify the trading parameters chosen by software, evaluate changes that can alter its behaviour, and demonstrate that the responsible firm can control the resulting orders. Human judgement and specialist vendors can both play valuable roles. Neither removes the need to establish where decisions are made and whether the applicable safeguards work.[1]

Report an error or submit an update