Case Study 21.1: The Algorithm That Didn't Know It Was Wrong — Cornerstone's Pre-Trade Control Gap

The Situation

Organization: Cornerstone Financial Group (fictional composite institution) Challenge: A fixed income execution algorithm generating erroneous orders following a market data vendor feed disruption — and a pre-trade control framework that failed to catch it Timeline: March 2024 Regulatory backdrop: MiFID II Article 17 / RTS 6 requirements; FCA algorithmic trading supervisory review ongoing

Background

Cornerstone's fixed income trading desk uses an execution algorithm ("FI-EXEC-03") to slice large bond orders across multiple trading venues, executing systematically to minimize market impact. FI-EXEC-03 receives reference prices from Cornerstone's market data infrastructure (a Bloomberg terminal feed processed through an internal pricing system).

On the morning of March 7, 2024, Cornerstone's market data infrastructure experienced a partial disruption. The Bloomberg feed for EUR-denominated investment grade corporate bonds was interrupted at 8:14 AM and switched to a fallback data source. The fallback source provided prices for most instruments, but for six instruments it provided prices denominated in the wrong currency — GBP prices for EUR bonds, without a currency conversion.

The result: six EUR corporate bonds appeared in the pricing system at approximately 88% of their correct values (EUR/GBP rate approximately 0.88 at the time).

FI-EXEC-03 interpreted the lower prices as attractive buying opportunities and began aggressively purchasing those six bonds, filling orders at market prices above its reference.

What Went Wrong

The data error: The fallback pricing system did not validate currency denomination before consuming the data. A GBP price consumed as a EUR price was factually incorrect, but syntactically valid.

The pre-trade control gap: Cornerstone's pre-trade price band check for FI-EXEC-03 was configured with a ±10% band — the order price must be within 10% of the reference price. The algorithmic orders were placed at market prices, which were the correct EUR prices. The reference price in the system was the incorrect GBP-as-EUR price. The actual bond prices (correct) were approximately 13% higher than the reference prices (incorrect) — just above the 10% band.

Wait: if the actual price was 13% above the erroneous reference, the price band check should have rejected the orders.

The problem: FI-EXEC-03 was placing market orders, not limit orders. The pre-trade controller's price band check only applied to limit orders — the submitted limit price was compared to the reference. For market orders, no price was submitted — so no price band check occurred.

The critical gap: Market orders bypass the price band check. A correct pre-trade control framework should apply price band logic to market orders as well — estimating the likely execution price from the order book and comparing to the reference.

The consequence: Over 47 minutes, FI-EXEC-03 executed purchases of six bonds totaling €127 million notional. The average execution price was approximately 8.4% above the algorithm's (incorrect) reference price. When the data error was corrected at 9:01 AM, the algorithm ceased generating orders (as the bonds were now correctly priced and no longer appeared cheap).

The realized loss was not catastrophic — €127 million of bond purchases at market prices resulted in positions that the firm could liquidate without major impact. But the execution was economically suboptimal: Cornerstone had purchased €127 million of bonds at prices above any reasonable interpretation of fair value for its strategy.

The Discovery and Response

At 9:03 AM, the fixed income risk manager, Claudia Reyes, noticed that FI-EXEC-03 had executed significantly more volume in six specific instruments than warranted by client orders. She checked the algorithm's log: it had placed 834 buy orders in 47 minutes — approximately 17 orders per minute.

At 9:04 AM: Claudia activated the kill switch for FI-EXEC-03. All outstanding orders — 12 remaining open buy orders — were canceled within 2 seconds.

At 9:08 AM: Root cause identified — pricing system fallback data consuming GBP prices as EUR.

At 9:15 AM: Internal incident report filed. CRO and Head of Fixed Income trading notified.

At 10:30 AM: Cornerstone's compliance team filed a mandatory incident notification to the FCA under MiFID II Article 16 (notification of material issues) and the firm's own algorithmic trading incident reporting protocol.

At 2:00 PM: The €127 million bond portfolio was reviewed by the Head of Fixed Income. Decision: retain the positions (the bonds were liquid; execution cost analysis showed the over-payment was approximately 0.4% of notional, or €508,000 — a recoverable cost over the bonds' holding period).

The FCA's Response

The FCA reviewed the incident within its algorithmic trading supervisory framework. Key findings:

  1. The kill switch worked: FI-EXEC-03 was halted within seconds of Claudia's decision. This was noted positively.

  2. The pre-trade control gap was a regulatory concern: The price band check not applying to market orders was identified as a RTS 6 Article 13(1)(a) deficiency. Paragraph 13(1)(a) requires a price collar "preventing the sending of orders outside set price bands" — the FCA's reading was that market orders must be covered by equivalent protection, even if the implementation differs from limit orders (e.g., by estimating execution price from the order book).

  3. The data fallback process was inadequate: No currency denomination validation existed in the fallback pricing pipeline. This was an infrastructure gap contributing to the incident.

  4. The 47-minute duration: The FCA questioned why the incident ran for 47 minutes before detection. The firm's risk monitoring showed FI-EXEC-03's activity in real-time — why didn't the volume spike trigger an earlier alert?

Cornerstone's response: The trading volume alert threshold for FI-EXEC-03 was set based on normal execution patterns. The 47-minute period fell within the high-end of the normal range — it was not flagged because the algorithm's daily volume limit had not been reached.

FCA's view: Real-time activity monitoring should include relative measures (rate of change compared to plan) not just absolute limits.

Remediation Program

Cornerstone implemented a three-stream remediation:

Stream 1: Pre-trade control enhancement - Price band checks extended to market orders: for any market order, the system fetches the current order book depth, estimates a worst-case execution price (at the 5th level of the order book), and compares to the reference. If the estimated execution price deviates more than the price band threshold from the reference, the order is flagged for review before routing.

Stream 2: Data quality validation - Currency denomination validation added to all pricing feeds including fallbacks: any price sourced from a fallback without explicit currency confirmation generates a data quality warning and triggers a fallback-indicator flag in the pricing system. - Instruments with fallback-sourced prices are flagged in the algorithm's data feed; FI-EXEC-03 is configured to treat fallback-priced instruments as "reduced confidence" — limiting order size to 10% of normal for those instruments until primary data is restored.

Stream 3: Real-time monitoring enhancement - Volume rate alerts: in addition to absolute volume limits, FI-EXEC-03 now monitors its execution rate against the daily execution plan. If the algorithm is executing at more than 2× its plan rate (e.g., because it perceives artificially cheap instruments), a real-time alert is generated.

Discussion Questions

1. The pre-trade price band check was applied only to limit orders, not market orders. Is this a common design gap in pre-trade control frameworks? What is the technical challenge of applying a price band check to a market order (where no price is submitted)?

2. The algorithm ran for 47 minutes before detection. The real-time monitoring flagged nothing because the absolute volume limit was not exceeded. What does this reveal about the design of "real-time monitoring" in the context of algorithmic trading controls? What types of metrics should be monitored, and what are the tradeoffs between sensitivity (catching problems early) and specificity (not generating excessive false alerts)?

3. Cornerstone's decision to retain the €127 million bond positions rather than liquidate was an economic judgment — the recovery over the bonds' holding period was estimated to exceed the liquidation cost. From a governance perspective, who should make this decision? The trading desk? Risk management? Compliance? The CRO?

4. The FCA found that the 47-minute incident duration was a concern but did not impose a financial penalty. What factors would typically lead the FCA to impose a penalty vs. a finding requiring remediation? Was Cornerstone's handling of the incident — quick kill switch, immediate notification, transparent root cause analysis — likely a mitigating factor?

5. The data vendor's pricing fallback provided GBP prices labeled as EUR without currency validation. Under the 2023 Interagency Third-Party Guidance (US) or equivalent third-party risk frameworks, what provisions should have been in Cornerstone's contract with the data vendor regarding data quality and notification of feed disruptions?