
Most algorithmic trading compliance programs are built to answer the detection question. I learned clearly that they're not built to answer the examination question when I ran a mock FINRA Rule 15c3-5 drill with a client's compliance team and asked them one thing: "Walk me through what your highest-volume algorithm did on August 5, 2024."
They had the order logs. They had the execution confirmations. What they could not produce was an explanation of why the risk thresholds were set at the levels they were, whose decision it was to set them there, or when those settings had last been formally reviewed. A real FINRA examiner would have stopped the review at that question. We spent the rest of the day understanding why they couldn't answer it.
I've been building the compliance intelligence layer at Veriprajna's algorithmic trading compliance practice for mid-market broker-dealers and asset managers since the Citigroup fine landed in 2024. The pattern I kept finding was not that firms lacked surveillance tools. It was that they had designed their compliance programs around detection and assumed that was enough.
What the Citigroup Fine Actually Says

I keep coming back to the Citigroup case because the fine breaks down differently than most compliance summaries describe it. The standard version is: fat-finger error, $444 billion erroneous basket, controls caught most of it, BaFin and UK regulators fined Citi a combined $92 million (EUR 12.975 million from BaFin, GBP 61.6 million from two British regulators) for the controls that didn't catch enough.
What the BaFin enforcement action specifically cites is the failure to maintain effective systems and risk controls for algorithmic trading operations — not the size of the erroneous basket, but the inability to explain the algorithm's decision chain and justify its threshold settings. Citi could produce the execution records. They could not adequately reconstruct why the algorithm did what it did with the $189 billion that reached it.
That distinction matters to me because it's the same gap I keep finding in client compliance programs. The documentation of what happened is generally solid. The documentation of why the controls allowed it — and the reasoning behind the threshold settings — almost never is. The examiner question my client couldn't answer in the mock drill and the examiner question that cost Citigroup $92 million are structurally the same question.
The Self-Assessment That Said "Covered by Vendor SLA"

About eight months into building this practice, I was reviewing a client's MiFID II RTS 6 self-assessment. It had cleared their internal review. The compliance officer handed it over with some confidence — it was thorough, she said, and covered all the required elements.
I opened the IT outsourcing section. The section was there, which put this client ahead of some others. One sentence: "Covered by vendor SLA."
The FCA's August 2025 multi-firm review of 10 principal trading firms found this pattern across multiple firms — IT outsourcing sections either missing entirely or resolved with a vendor SLA reference. The FCA's finding was that the RTS 6 self-attestation sits with the firm, not the vendor. The vendor SLA doesn't satisfy the self-assessment obligation. Firms that had filed on that basis received individual attestation requirements and ongoing supervisory follow-up.
I asked my client who had confirmed that interpretation with the FCA. Nobody had. The vendor had provided written assurance that the SLA covered the compliance obligation. Nobody had tested whether the FCA agreed.
The algorithm inventory had the same pattern: most strategies documented, with a significant portion pending an engineering team response to a documentation request that had been sitting unanswered for several months. FINRA Rule 16-21 requires registration of the persons primarily responsible for developing algorithmic trading strategies. The algorithms with unclear ownership in the inventory were also the ones where no registered person was named.
What I've learned from rebuilding a number of these self-assessments is that most of the work is not compliance interpretation — it's organizational data collection. Getting engineering to document what was built, getting operations to document their kill-switch procedures, getting vendors to produce written confirmation of what their SLA does and does not cover. The regulatory framework is clear. The internal coordination to satisfy it is the bottleneck that most compliance programs underestimate.
The gap in most RTS 6 self-assessments isn't a compliance question. It's an organizational one — getting the engineering team and the vendor on the same page about who owns what before the examiner schedules the call.
The Validation Template That Said "Pending"

A few months after that engagement, I was sitting with a compliance officer at a different firm. She was trying to write the GNN section of her SR 11-7 model validation report — the 2011 Federal Reserve and OCC guidance governing model risk management at U.S. financial institutions.
The challenger-model section of her template was highlighted yellow. The note in the cell said "pending." Her external validation vendor had no challenger template for a graph neural network (GNN) processing counterparty relationship topology. The standard SR 11-7 challenger-model test requires comparing primary model outputs against an alternative model on the same inputs. When the primary model is a GNN and the challenger is a logistic regression on historical price data, the comparison doesn't establish validity — it establishes that two architecturally incompatible systems produce different numbers. The challenge doesn't mean what SR 11-7 intended it to mean.
GARP noted in February 2026 that SR 11-7 "remains one of the few stable reference points for model governance" while acknowledging that generative and agentic AI "break its assumptions by introducing opacity, stochasticity, and autonomy." The GNN architectures that academic research demonstrates reaching AUC-ROC of 0.891 versus 0.734 for conventional approaches — with early warning lead times extended by 11.5 days, per research in Springer Nature and ACM — cannot be validated using the standard SR 11-7 challenger template without modification.
What she needed was not a new compliance regime. She needed a bridge document: a custom validation addendum that satisfied SR 11-7's intent for validation, documentation, governance, and monitoring while accommodating the architectural reality of graph-topology models. That document now lives in our standard engagement kit at Veriprajna. It's the most-requested artifact we produce from that practice.
SR 11-7 doesn't break under modern AI. It just needs a bridge. The problem is that nobody at most mid-market firms has written the bridge yet — and the examiner arrives before it exists.
Why the Surveillance Teams I Talk To Keep Optimizing the Wrong Number

One conversation that shifted how I think about this was with a surveillance team that had just reduced their false positive rate from 32% to 26%. They were pleased about it. I asked what percentage of the remaining 26% turned into actionable findings. Roughly four percent of total alerts, they said.
An Eventus and Datos Insights survey found that 70% of banks and broker-dealers report false positive rates above 25% in their trade surveillance systems. Most of the effort I've seen invested in compliance engineering goes into reducing that rate. What I kept noticing is that the false-positive optimization effort was consuming the bandwidth that the documentation gap — the one that cost Citigroup $92 million — needed instead.
Detection is necessary. NICE Actimize, Nasdaq's surveillance platform, and Eventus (Validus) do the detection function reasonably well across equities, FX, and derivatives. The cross-asset contagion dynamics of the August 2024 flash crash — the Nikkei falling 12.4% in a single session, algorithmic strategies unwinding in correlated mass when the Bank of Japan rate decision and U.S. jobs data arrived simultaneously — require Generative Adversarial Network (GAN)-based and GNN-LSTM architectures not yet standard in commercial platforms. GAN-based anomaly detection research from 2025 demonstrates 94.7% accuracy at sub-3ms latency for novel pattern detection across up to 150,000 transactions per second. Those architectures exist. They're not yet in the products most mid-market firms are buying.
But the surveillance team that reduced its false positive rate from 32% to 26% still couldn't answer the August 5 question. Detection is the wrong number to optimize if what your examiner asks about is the decision chain before the halt.
The Three Clocks I Track For Every Mid-Market Client

I now open every engagement with EU exposure by asking which of three regulatory deadlines is most proximate, because each requires a different kind of preparation and clients almost uniformly treat them as future problems until they're not.
DORA — the Digital Operational Resilience Act — entered into force in January 2025. First Register of Information submissions to European Supervisory Authorities were due April 30, 2025. The information and communications technology (ICT) third-party service provider obligations are current. If a client's trading infrastructure relies on cloud providers, data vendors, or technology services that qualify as critical ICT providers, the resilience-testing and incident-reporting regime is already active.
By August 2, 2026, financial firms with EU exposure must have technical documentation, conformity assessments, CE marking, and EU database registration for AI systems classified as high-risk under Article 6 of the EU AI Act. February 2026 European Commission guidelines were expected to clarify where algorithmic trading AI falls on that classification. If the classification lands as high-risk, the preparation window from this article's publication is roughly two quarters.
For any desk trading Indian markets, the clock ran out in October 2025. The Securities and Exchange Board of India (SEBI)'s February 2025 directive required a unique Algo-ID per strategy, exchange approval before live deployment, static-IP authentication, kill-switch documentation, and comprehensive order logging by October 1, 2025. Firms without the algorithm inventory needed to generate Algo-ID applications are past the compliance date.
No major surveillance vendor offers a unified framework mapping controls across SEC Rule 15c3-5, MiFID II RTS 6, EU AI Act, DORA, and SEBI simultaneously. Most mid-market firms running multi-jurisdictional programs are managing these as separate processes, which means the compliance calendar for each jurisdiction is independently tracked and the gaps between the frameworks stay invisible until an examination spans jurisdictions.
The Question That Mock Examination Left Me With
My client from that first drill has since built a complete algorithm inventory register, rebuilt their RTS 6 self-assessment with the IT outsourcing section properly documented, and extended their SR 11-7 model validation framework to cover their GNN contagion monitor. The kill-switch architecture was the last piece — and the most counterintuitive one. Most kill-switch failures I've encountered aren't hardware problems. They're latency problems: the gap between the algorithm's order-generation thread and the risk gateway's circuit-breaker check is long enough that a fill can complete before the halt instruction lands. The fix is architectural, not configurational. Once that was in place, this client can now answer the August 5 question in under a minute.
What I've been thinking about since is the mid-market firms we haven't reached yet. Running compliance programs built in 2018 or 2019. The same vendor SLA assumptions. The same documentation backlogs. Heading into an examination environment where the SEC and CFTC combined for a record $25.3 billion in enforcement actions in 2024, and where the FCA sent individual attestation requirements to every firm in its August 2025 multi-firm review.
The compliance gap in algorithmic trading is not a mystery. The examination questions are known. The regulatory deadlines are published. The documentation frameworks are defined. What most mid-market firms are missing is the combination of compliance architecture knowledge and engineering execution to close the gap before the examiner schedules the first call.
The 9:47 AM question is coming. Whether it takes thirty seconds or three months to answer is largely a function of decisions being made right now.
If you're working through what examination-ready looks like for a multi-jurisdictional algo trading program, I'd find it useful to compare notes on where the specific gaps are. The patterns are consistent enough across mid-market firms that the solutions tend to converge faster when compared directly.