MiFID II and Algorithmic Trading AI: Best Execution, Kill Switches, and the Algo Register

MiFID II Article 17 was written specifically for algorithmic trading. It predates large language models, but its requirements translate directly to AI trading agents: you need a kill switch, an algo register, annual conformity testing, and an audit trail that covers every order generated by the algorithm.

The FCA's equivalent rules in the UK (post-Brexit) mirror MiFID II Article 17 almost exactly. If you operate in both jurisdictions, you're dealing with two regulators but essentially the same requirements.

Article 17: What It Actually Requires

Resilience and capacity — your algorithmic trading systems must have sufficient capacity to handle peak order volumes and "withstand inadequate market conditions."

Kill switches — you must be able to cancel outstanding orders and immediately halt trading if the algorithm behaves abnormally. The kill switch must work at the system level, not just at the application level.

Annual self-assessment — investment firms must annually assess the compliance of their algorithmic trading strategies and implement any required improvements.

Testing before deployment — algorithms must be tested before deployment to ensure they don't create disorderly market conditions or contribute to market manipulation.

Algo register — a record of all algorithmic trading strategies deployed, including their parameters, risk controls, and the names of responsible persons.

Audit trail — all orders generated by the algorithm must be tagged with an algo flag so they can be identified in post-trade analysis.

The AI Agent Translation

For an AI agent executing trades, each requirement maps to a specific control:

MiFID II Requirement	UAPK Implementation
Kill switch	require_human_approval: ["trade:execute"] — no trade without approval; revoke approval capability to halt
Algo register	Manifest with agent ID, version, capabilities — version-controlled
Audit trail	Interaction records with algo_flag, timestamp, order parameters, decision chain
Risk controls	amount_caps, per_action_type_budgets, allowed_hours in manifest
Annual self-assessment	Manifest review + framework evidence update cycle

The require_human_approval on trade:execute implements the practical kill switch: to halt the algo, withdraw the human approver's ability to issue override tokens. No new trades can proceed until the capability is restored.

Amount Caps and Best Execution

MiFID II's best execution obligation (Article 27) requires that firms take all sufficient steps to get the best possible result for clients. For algorithmic execution, this means the algorithm's parameters must be set to pursue best execution, not the firm's interests.

Amount caps in the manifest enforce a different but related control: order size limits that prevent the algorithm from inadvertently moving markets or concentrating too much risk in a single trade.

{
  "policy": {
    "amount_caps": {
      "GBP": 50000,
      "EUR": 60000,
      "USD": 65000
    },
    "approval_thresholds": {
      "action_types": ["trade:execute"],
      "amount": 10000,
      "currency": "GBP"
    }
  },
  "constraints": {
    "require_human_approval": ["trade:execute"],
    "per_action_type_budgets": {
      "trade:execute": 100
    },
    "audit_retention_days": 2555
  }
}

The approval_thresholds field creates a two-tier approval requirement: all trade executions go through the standard HITL gate, but trades above £10,000 get flagged for senior approval. This mirrors common internal trading desk governance.

per_action_type_budgets.trade:execute: 100 limits the agent to 100 trades per day — a hard stop that prevents runaway execution.

The DORA Stack for Large Platforms

For investment firms that are also significant enough to fall under DORA (Digital Operational Resilience Act), the requirements stack:

• MiFID II Article 17 (algorithmic trading controls)
• DORA (ICT risk management, incident reporting, operational testing)
• GDPR (if client personal data is processed)
• SFDR (if ESG fund classification is involved)

UAPK's qualification funnel recommends all four for an EU investment manager. The manifest builder questions for each are distinct — but the policy fields they generate are complementary. audit_retention_days: 2555 satisfies both MiFID II's 5-year record retention and DORA's incident documentation requirements.

FCA Divergence Post-Brexit

The UK's version of algorithmic trading rules (MAR, MiFID onshored in the UK Statutory Instruments, and FCA PS21/20) diverges from MiFID II in a few areas:

• The FCA has proposed a more principles-based approach to AI oversight, aligning with the UK's pro-innovation AI strategy
• The UK Senior Managers and Certification Regime (SMCR) assigns personal liability to named individuals for AI governance failures
• Post-Brexit MiFID equivalence decisions affect which firms need dual authorisation

For firms operating in both the EU and UK, the safest approach is to comply with the stricter of the two on any given requirement. UAPK's manifest builder surfaces both MiFID II and FCA as separate frameworks when the UK geography is selected — the questions differ where the regulations differ.

The Audit Trail Requirement in Practice

MiFID II requires that the audit trail for algorithmic orders is "sufficiently detailed to enable effective supervision." ESMA has published technical standards specifying what fields the record must contain.

For an AI agent, the UAPK interaction record captures: the agent ID, the order parameters (symbol, side, quantity, price, currency), the timestamp, the policy evaluation result, and the human approver's identity if applicable. That covers the core MiFID II fields. The hash chain ensures the records haven't been altered — which regulators increasingly check.