Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Conditional approval lets a trading system hold an order for a person to decide only while that order stays inside pre-set risk and compliance boundaries. An order that breaches a hard boundary is blocked rather than queued for sign-off, and an order that passes review proceeds only if the checks still hold at release. The mechanics below follow the EU framework, where MiFID II and RTS 6 set binding requirements for relevant investment firms and ESMA’s 2026 supervisory briefing explains how supervisors expect those requirements to be applied.
Which rules apply, and how much weight each carries
This guide uses the EU framework as its only reference point. It does not describe how other jurisdictions treat these controls. Within the EU, the binding requirements for relevant investment firms come from MiFID II and RTS 6. ESMA’s 2026 supervisory briefing is a different kind of document: it sets out what supervisors expect to see, and it does not create new legal obligations.
| Source | Status | What it contributes here |
|---|---|---|
| MiFID II, Article 17 | Binding on relevant EU investment firms | Effective systems and risk controls, trading thresholds and limits, controls against erroneous orders and disorderly markets, testing, monitoring, continuity arrangements, and records that allow supervisors to monitor activity |
| RTS 6 | Binding on relevant EU investment firms | Kill functionality requirement, as ESMA describes it in its Q&A (covered in the emergency-stop section below) |
| ESMA Supervisory Briefing on Algorithmic Trading in the EU (February 2026) | Nonbinding convergence tool | Supervisory expectations on soft and hard blocks, calibration, aggregation of parent and child orders, testing after change, and outsourcing |
| ESMA answer to ESMA_QA_1612 (7 July 2017) | ESMA Q&A response | Clarifies that kill functionality does not need to be a single unified software system |
Human sign-off does not change the classification
MiFID II’s definition of algorithmic trading turns on whether a computer algorithm determines order parameters with limited or no human intervention. It does not turn on whether a person approved the order before submission. ESMA’s February 2026 briefing says this directly: human intervention to authorise orders does not negate algorithmic trading where an algorithm determines individual order parameters such as price, timing, or quantity. The briefing defines the underlying strategy this way:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →“An algorithmic trading strategy is a set of decision logic, implemented through one or more algorithms, that autonomously pursues a defined trading objective.”
#1 Best Overall
The test asks who determines the parameters, not how that logic is built. The briefing’s attention to machine-learning components in change testing shows that model-based logic falls within its scope. A conditional approval layer is therefore a control inside algorithmic trading, not a way out of it. Systems that only route orders without determining other trading parameters are treated differently in the briefing, so the first design question is which parameters your software actually sets.
Soft blocks and hard blocks
ESMA’s briefing separates two kinds of check. The handling steps in the next section are design choices built on that split, not a sequence ESMA prescribes.
| Aspect | Soft block | Hard block |
|---|---|---|
| Nature | Alert at a lower threshold | Barrier that traders cannot independently override |
| Effect on the order | Prompts review; the order waits for an explicit human decision | The order does not proceed |
| Trader authority | A named reviewer can approve, modify or cancel, and the decision is recorded | No independent override; changes to the limit go through governance |
How a conditional approval flow works
Treat each order as moving through explicit states rather than through a single pass-or-fail check. The sequence below is an editorial design pattern derived from ESMA’s soft and hard block distinction.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Generated. The algorithm sets the order’s price, timing or quantity.
- Checked. The order is tested against hard limits and soft thresholds at both parent and child level.
- Blocked. If any hard limit is breached, the order stops here, and no trader action moves it forward.
- Held for review. If a soft threshold is reached, the order waits and is assigned to a named reviewer.
- Released or cancelled. The reviewer can release or cancel the order. A release is valid only if the checks still pass against current data; if market data has changed since the hold, re-run the checks before release.
- Monitored. After submission, the system tracks cumulative execution and remains able to withdraw orders through the kill function.
What each approval record must capture
Every hold needs a record that can be reconstructed later. At minimum, it should contain:
- the order parameters as generated, and any parameters the reviewer changed
- the exposure snapshot used for the check, with its timestamp
- the soft-block reason that triggered review
- the reviewer’s identity and role
- the decision, its timestamp, and whether the checks were run again after any modification
The record makes each review auditable. Because it captures reviewer changes and whether they were rechecked, it also shows what happened between the hold and the release.
Tuning limits without losing control
Dynamic tuning lets thresholds move as conditions change. The key distinction is between what may inform a calibration and who may change the limit. ESMA expects parameters to reflect the firm’s intended risk exposure and the market conditions it trades in, and it expects setting and review to involve trading, risk management and compliance.
Inputs that can inform calibration
- the firm’s desired risk exposure and risk tolerance
- activity levels, instruments and venues
- price levels and liquidity
- volatility
Who holds the authority to change limits
Traders should not independently revise hard-block parameters. Parameter-setting procedures should be documented, with risk and compliance involved in setting and reviewing them. Calibration inputs describe conditions; they do not give a trading desk the power to loosen a boundary.
Bounded changes and escalation
The controls below are implementation advice drawn from ESMA’s documentation and control expectations. ESMA does not specify them word for word.
- Limit how far a threshold can move in a single change, so that no one adjustment can shift a boundary by a large amount.
- Assign one named owner to each parameter set.
- Log every change with the old value, the new value, the approvers and the reason.
- Escalate when market data is stale or conditions leave the calibrated range, and fall back to a pre-approved, more conservative setting until the escalation is closed.
Checking parent and child orders together
A child order can pass its own check while the parent order’s aggregate breaches a limit. ESMA’s briefing says that volume and value checks on child orders alone are not sufficient to prevent erroneous orders. Apply limits at both parent and child levels, and monitor cumulative child execution against the parent’s quantity and value. The same monitoring helps detect runaway execution loops.
Consider an illustrative case (the figures are hypothetical and are not taken from ESMA). A parent order is meant to buy 100,000 shares, and each child order is capped at 20,000 shares. Every child passes its own check. If the execution loop does not track how much of the parent has already executed, it can keep sending children. After ten children, it has executed 200,000 shares, twice the parent quantity. Child-only checks would not flag that. A cumulative check against the parent quantity would.
When algorithm testing has to happen
Testing is required before deployment and again after material change. ESMA’s briefing identifies conformance testing, stress testing and scenario analysis. The intensity of testing should be proportionate to the nature, scale and complexity of the business. Firms should document their testing procedures and the internal authorisation to deploy.
Free tools Windows power users keep installed
One-click scans. No signup required.
What counts as a material change
ESMA defines material change broadly, to include any modification that may alter a system’s behaviour, risk profile or compliance posture. The briefing’s examples include:
- changes to risk thresholds
- changes to kill logic
- changes to risk controls more generally
- changes to external dependencies, such as data or system providers
- retraining of machine-learning components
Capacity benchmark
For capacity stress testing, ESMA’s 2026 briefing describes a benchmark of twice the volume of messages and trades processed in the preceding six months. For full trading-volume testing, it describes twice the highest trading volume reached in that period, covering the cycle from order generation through post-trade processing. These are testing benchmarks set out in the briefing, not measured market statistics.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Kill functionality and emergency stop
ESMA’s answer to ESMA_QA_1612, dated 7 July 2017, sets out the kill requirement under Article 12 of RTS 6:
“The requirement for an investment firm to have a kill functionality pursuant to Article 12 of RTS 6 obliges the firm to have the ability as an emergency measure to immediately pull any or all outstanding orders from any or all trading venues.”
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Three design consequences follow:
- A single decision should be able to withdraw all outstanding orders, or a chosen subset, across every connected venue.
- The kill function does not need to be one unified software implementation. ESMA’s Q&A allows procedures and switches to differ between systems, provided one decision produces immediate cancellation.
- Good practice is to keep the kill path separate from the approval queue, so that a backlog of held orders cannot delay a withdrawal.
Outsourcing and third-party algorithms
Outsourcing does not transfer regulatory accountability. The investment firm remains responsible for compliance with algorithmic trading requirements even where a provider supplies the algorithm, runs part of the chain, or hosts the system. Firms should keep oversight and the ability to suspend or terminate activity. In practice, an outsourcing agreement should:
Quick Recap
- specify operational roles and support obligations
- guarantee access to performance data, test results and records
- preserve the firm’s ability to monitor, suspend or terminate algorithmic trading without the provider’s consent
What is and is not established
- The framework described here is EU-specific. It is not a jurisdiction-by-jurisdiction comparison, so check how your national competent authority applies these requirements.
- These sources do not establish any market-wide figure on the performance, adoption, losses or accuracy of conditional approval. The benchmarks in this article are testing benchmarks.
- The kill-functionality answer dates from July 2017. Read it alongside the 2026 briefing rather than as a standalone statement.
- Before relying on any requirement described here, confirm the current text of MiFID II and RTS 6 with your compliance function or counsel.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
