Key Takeaways — Chapter 21: Algorithmic Trading Controls and Kill Switches

Core Definitions

Algorithmic trading: Use of computer programs to generate, route, and execute trading orders based on predefined rules. Accounts for 60–70% of equity market volume.

MiFID II Article 17: The foundational EU requirement for algorithmic trading controls — requiring systems resilience, pre-trade risk controls, kill switch capability, annual self-assessment, and market-making obligations.

RTS 6 (Delegated Regulation EU 2017/589): Technical standards implementing Article 17 — specifying pre-trade controls, real-time monitoring, kill switch requirements, and testing protocols.

Kill switch: Emergency halt capability — immediately cancels all outstanding orders and prevents new order submission. Must cancel across all venues, be tested regularly, and auto-activate on loss limit breach.


Types of Algorithmic Trading

Type Description Primary Risk
Execution algorithms VWAP, TWAP — optimize large order execution Data errors, parameter misconfiguration
Market-making algorithms Continuous bid/ask quoting, profit from spread Adverse selection, withdrawal during stress
Statistical arbitrage Exploit pricing relationships Model error, correlated position risk
High-frequency trading Very short holding periods, co-location Feedback loops, quote stuffing
Systematic/quant Factor models, trend-following Model risk, regime change

MiFID II Article 17 / RTS 6 Requirements

Requirement RTS 6 Article Description
Pre-trade risk controls Art. 13 Price bands, size limits, notional limits, position limits
Real-time monitoring Art. 14 Continuous automated monitoring of all orders
Kill switch Art. 14(2) Immediate cancellation of all outstanding orders across all venues
Order-to-trade ratio Art. 13(1)(e) Limits on excessive order cancellation
Intraday loss limit Art. 14(1)(c) Automatic halt if intraday loss exceeds threshold
Annual self-assessment Art. 9 Full review of all algorithms and controls, senior management approval
Algorithm testing Art. 10 Pre-deployment testing in non-production environment
Change management Art. 10(4) Documentation and approval required for all algorithm changes

Pre-Trade Risk Controls

Control Purpose Calibration Basis
Order size limit Prevent outsized orders Market liquidity, typical order sizes
Price band Reject erroneous prices Market volatility, instrument type
Notional limit Cap order value Risk appetite, capital
Position limit Prevent concentration Market liquidity, risk appetite
Order rate limit Prevent system overload, quote stuffing Exchange rules, system capacity
Fat-finger filter Catch obvious data entry errors Multiple of typical spread from mid
Intraday loss limit Stop runaway algorithms Daily P&L targets, risk appetite

Kill Switch: Key Requirements

  1. Immediate — no delay between activation and order cancellation
  2. Comprehensive — cancels orders on all trading venues simultaneously
  3. Tested — tested at least annually (quarterly best practice)
  4. Automated trigger — activates automatically on intraday loss limit breach
  5. Audit trail — every activation logged with time, person, reason
  6. Defined authority — pre-defined who can activate and who must approve reactivation
  7. Reactivation protocol — documented investigation and sign-off required before going live again

The Knight Capital Lesson (August 1, 2012)

Fact Detail
Cause Software deployment error reactivated legacy "Power Peg" algorithm
Duration 45 minutes of undetected malfunction
Impact $6.65 billion in unintended trades; $440 million loss
Why 45 minutes? No automated loss-triggered kill switch; manual diagnosis took time
Regulatory outcome SEC/CFTC enforcement; firm was ultimately acquired by Getco
Lesson Kill switches must auto-activate on loss thresholds; cannot rely solely on manual diagnosis

Annual Self-Assessment: Required Elements

  • [ ] Complete algorithm inventory (all algorithms including execution tools and legacy)
  • [ ] Development and testing process documentation
  • [ ] Pre-trade risk limits (all limits, with calibration rationale)
  • [ ] Kill switch operational status and test results
  • [ ] Stress test results
  • [ ] Incident log for the year (failures, misbehavior, unusual patterns)
  • [ ] Governance: oversight, limit change approval authority
  • [ ] Senior management approval sign-off

Common deficiencies: incomplete inventory (missing execution algorithms), no kill switch test documentation, limit calibration undocumented, stale content from prior year.


Market-Making Obligations (Article 17(3))

Firms with market-making algorithms must: - Enter written agreement with trading venue - Quote continuously for ≥50% of venue's continuous trading hours (equity default) - Have systems capable of continuous quoting - May withdraw in "exceptional circumstances" — definition intentionally narrow

The tension: HFT market makers withdraw during volatility → exacerbates price drops → regulators want continuous liquidity → market makers say forced quoting in stress = widened spreads


Algorithm Development: Testing Protocol

Unit Testing (component-level)
    ↓
Integration Testing (full algorithm in simulation)
    ↓
Stress Testing (extreme market scenarios, kill switch test)
    ↓
Parallel Running (limited live capacity alongside existing system)
    ↓
Full Deployment (with continuous monitoring)

Change management: Any parameter or code change requires formal documentation and approval before implementation. Emergency changes require documented post-hoc review.