Case Study 21.2: Building Algorithmic Trading Controls for a New Entrant — Priya's Challenge at Aether Capital

The Situation

Organization: Aether Capital Management (fictional EU-regulated quantitative trading firm) Priya's engagement: Designing and implementing a MiFID II-compliant algorithmic trading controls framework for a new entrant to EU algorithmic trading Timeline: Q2–Q4 2023 Regulatory backdrop: MiFID II Article 17 / RTS 6; FCA / BaFin authorization as investment firm

Background: Aether Capital's Business

Aether Capital Management was founded in 2021 by a team of former sell-side quantitative analysts. The firm's strategy: systematic factor investing in European equities and equity options, with execution fully automated through proprietary algorithms.

By 2023, Aether had received investment firm authorization from BaFin (German Federal Financial Supervisory Authority) and was building its trading infrastructure for launch. The founding team — engineers and mathematicians — had deep expertise in strategy development and trading systems. They had limited experience with the regulatory requirements for algorithmic trading.

Priya Nair was engaged to build Aether's algorithmic trading compliance framework from the ground up. Her scope: design the pre-trade risk control architecture, establish governance processes, produce the required documentation, and prepare for the first annual self-assessment.

Priya's Initial Assessment

Priya's first week at Aether revealed both strengths and gaps.

Strengths: The technology was sophisticated. Aether's order management system (OMS) was custom-built and well-engineered. The developers had implemented basic pre-trade checks as part of the OMS design. The algorithms had been backtested extensively. Code review processes were disciplined.

Gaps — regulatory compliance:

Gap 1: No formal algorithm inventory. Aether had five algorithms in development: three equity factor execution algorithms, one options execution algorithm, and one market-making algorithm for European index options. None were formally documented from a compliance perspective — the documentation was technical (code, architecture diagrams) but not regulatory (purpose, risk parameters, governance sign-off).

Gap 2: Pre-trade controls incomplete. The OMS had order size limits and basic price checks. It did not have: position limits, intraday loss limits, order rate limits, or a kill switch. The lack of a kill switch was the most critical gap — RTS 6 requires a kill switch before trading begins.

Gap 3: No testing protocol. Algorithms had been tested by the development team in simulation. There was no formal testing protocol — no documented test plan, no pass/fail criteria, no independent review of test results before deployment.

Gap 4: No change management process. The development team routinely modified algorithm parameters during strategy development. When asked how parameter changes would be approved in production, the CTO said "we'd discuss it and update the config file." This was not a compliant change management process.

Gap 5: No governance structure. No committee had been established to oversee algorithmic trading. No one had formal responsibility for algorithmic trading risk.

The Build Program: 5 Months

Priya developed a 5-month implementation plan.

Month 1: Kill Switch (Highest Priority)

The kill switch was the first priority — without it, Aether could not begin live trading.

Aether's engineering team built a kill switch integrated into the OMS at multiple levels:

Instrument-level kill: Cancel all orders for a specific instrument immediately. Used when there's an issue with a specific security (data feed error, unexpected corporate event).

Desk-level kill: Cancel all orders across all instruments for a specific algorithm. Used when a single algorithm is misbehaving.

Firm-wide kill: Cancel all outstanding orders across all algorithms and all venues simultaneously. Used for system-wide emergencies.

Technical implementation: the kill switch was implemented as a dedicated high-priority message queue separate from the order routing path. When activated, kill messages bypassed all other queue processing and went directly to each venue's cancel interface. Cancel confirmation was required from each venue; if any venue did not confirm within 5 seconds, an automated escalation alert was generated.

Testing: The kill switch was tested against all venues (XETRA, Euronext, CBOE Europe) in a UAT environment, simulating 200 outstanding orders across 30 instruments. Full cancellation: 1.8 seconds. The engineering team documented: venues contacted, cancellation times, confirmation receipt.

Month 2–3: Complete Pre-Trade Control Framework

Priya designed the full pre-trade control framework:

Algorithm-level limits (set per algorithm): - Maximum order size by instrument class (equities vs. options) - Maximum notional per order - Price band by instrument (5% for liquid equities, 10% for less liquid, 3% for index options) - Position limit long/short by instrument - Order rate limit: maximum orders per second and per minute - Intraday loss limit: automatic kill switch activation threshold

Firm-level limits (apply across all algorithms): - Total firm-level long position in a single instrument (prevents multiple algorithms building correlated positions) - Total firm-level intraday loss limit (a higher-level threshold that halts all algorithms if reached)

Priya introduced a constraint: limit values for each parameter required approval from both the CTO (technical sign-off) and the Risk Manager (risk sign-off). Parameter changes during production required the same dual sign-off and a 24-hour notice period (except emergency changes, which required post-hoc review within 4 hours).

Month 4: Algorithm Inventory and Testing Protocol

Algorithm inventory: Priya created a standardized registration template for each algorithm:

Algorithm ID: AETH-EQ-001
Algorithm Name: European Equity Factor Execution — Momentum
Version: 1.0.0 (live) / 1.0.1 (in development)
Purpose: Execute momentum factor portfolio rebalancing orders in EU equities
Strategy type: Execution (own account)
Instruments: XETRA and Euronext large-cap equities
Average daily orders: ~1,200 per rebalancing event (typically 1x/week)
Maximum single-day exposure: €45M notional
Pre-trade limits configured: [list all parameters]
Last deployed: [date]
Last tested: [date + link to test report]
Annual self-assessment: [approved date + signatory]

Five algorithms were registered. The registration process required the developer, the CTO, and the Risk Manager to all sign off.

Testing protocol: Priya established a four-stage testing requirement for any new algorithm or material algorithm change:

  1. Unit testing: Developer-run; documented pass/fail against predefined test cases
  2. Integration testing: QA team-run in simulation; documented against test plan
  3. Kill switch testing: Kill switch activated against the algorithm in simulation; full order cancellation verified
  4. Paper trading: Algorithm runs in real-time against live market data, generating orders that are logged but not submitted. Minimum 5 trading days before production approval.

Approval gate: The CTO and Risk Manager must both sign the testing completion certificate before any algorithm goes to production.

Month 5: Governance Structure and First Self-Assessment

Priya established an Algorithmic Trading Risk Committee — monthly meetings, chaired by the CRO, with the CTO, Head of Trading, Risk Manager, and Head of Compliance as members. The committee's mandate:

  • Review monthly risk reports (including P&L, kill switch activations, rejection rates)
  • Approve new algorithm deployments
  • Review and approve parameter changes
  • Approve the annual self-assessment

First annual self-assessment: Priya drafted the first self-assessment document — 34 pages covering all required elements. The document was presented to the Algorithmic Trading Risk Committee, reviewed by the Supervisory Board, and submitted to BaFin (who had requested a copy as part of Aether's authorization conditions).

BaFin's response: a single-page acknowledgment. "The self-assessment demonstrates an appropriate pre-launch controls framework for a new entrant of this type. BaFin expects the framework to evolve as trading commences and actual operational experience is accumulated."

The First Incident

Two weeks into live trading, Aether's momentum equity algorithm (AETH-EQ-001) generated a position in Fresenius SE that exceeded the single-instrument position limit. The kill switch was not triggered — instead, the order was rejected and an alert was generated.

Investigation: A corporate restructuring at Fresenius had split the company's shares into two instruments with different ISINs. AETH-EQ-001's position limit was monitored per ISIN. The algorithm held positions in both ISINs — each below the per-ISIN limit — but the aggregate position in the economic entity "Fresenius" was above the intended limit.

Resolution: Aggregate position limits now consider economic linkages (same ultimate issuer) in addition to per-ISIN limits. The ISIN mapping table was extended to include issuer-level groupings.

Priya's documentation: "The first operational incident revealed a position limit implementation gap that backtest simulation had not anticipated. This is expected for any algorithmic trading system — real-world market events surface edge cases that simulation does not. The key is detection, rapid response, and documented remediation. Our framework performed as designed: the alert triggered, the investigation was completed within 2 hours, and the remediation was deployed within 24 hours."

Discussion Questions

1. Priya identified "no kill switch" as the highest-priority gap — preventing Aether from beginning live trading. This prioritization required the engineering team to interrupt its other work. How should a compliance professional communicate risk priorities to a technology team that may not share the same urgency about regulatory requirements?

2. Aether's founding team resisted Priya's 24-hour notice period for parameter changes, arguing it would make the firm uncompetitive. They wanted same-day parameter adjustments when market conditions changed. How should Priya respond to this objection? Is the 24-hour period a regulatory requirement or a Priya-designed control that could be adjusted?

3. The paper trading phase (Stage 4 of testing) requires 5 trading days of live market simulation before production approval. A new algorithm that would capture a time-limited market opportunity might be delayed by this requirement. How should the testing protocol handle time-sensitive deployments without compromising the control?

4. The first incident — aggregate position limit gap due to corporate restructuring — was detected by the control framework (alert generated, order rejected). However, the position limit itself was inadequate. Does this constitute a failure of Aether's pre-trade controls? How should it be documented in the next self-assessment?

5. Priya built the algorithmic trading controls framework for Aether from scratch. In contrast, larger established firms have existing frameworks they must update and maintain. From a regulatory compliance perspective, is it easier to build a compliant framework from scratch (greenfield) or to remediate an existing inadequate framework? What are the specific advantages and risks of each approach?