SEBI's AI/ML guidelines 2026 contain a requirement that sounds simple: every AI system used in trading, research, or advisory must have a kill switch. In practice, building a kill switch that satisfies regulatory scrutiny is more demanding than most compliance teams initially expect — and more technically complex than IT teams typically budget for.
This guide explains what SEBI's kill-switch requirement means in technical terms, how to implement it across three different AI system categories (trading AI, advisory AI, and surveillance AI), what governance controls must surround the technical mechanism, and what testing evidence SEBI inspectors will expect to see.
What SEBI's Kill-Switch Requirement Actually Requires
A kill switch in SEBI's framework is not simply the ability to stop a running process. The regulatory requirement has four components that must all be in place:
1. Halt capability
The ability to stop an AI system's operational output immediately — stopping new orders from being placed, stopping new recommendations from being generated, stopping automated advice from being delivered to customers. This is the component most entities implement first and, often, consider sufficient. It is not.
2. State rollback capability
After halting, the system must be able to return to a known-good prior state. For a trading AI, this means the ability to roll back to the previous model version — including all associated parameters, feature encodings, and threshold configurations — without contaminating the current model state. For an LLM-based advisory system, this means reverting to a prior system prompt version and associated knowledge base state. A halt without rollback leaves the entity in a degraded-but-unclear operational state that compounds during investigation.
3. Validated fallback process
When AI is halted, operations must continue via a validated manual fallback process. For trading: rule-based order management or manual order review. For advisory: human adviser routing with documented handoff procedures. For surveillance: manual review queues with escalation to compliance officers. The fallback process must be tested — not just documented — before the AI system goes into production. An untested fallback that fails during an actual incident is worse than having no fallback, because it creates the appearance of preparedness without the substance.
4. Documented trigger criteria
The conditions under which the kill switch should be activated must be documented in advance. These are the kill-switch triggers — specific, observable events that require activation, not discretionary judgments. Pre-defined triggers reduce the risk of delayed activation when a crisis is ambiguous, which is when most AI incidents occur.
Kill-Switch Triggers: A Taxonomy for SEBI-Regulated Entities
Kill-switch triggers vary by AI system type. The following taxonomy covers the principal trigger categories for the three most common SEBI-regulated AI deployment types.
Trading AI Kill-Switch Triggers
- Performance breach. Model accuracy, Sharpe ratio, or signal-to-noise ratio falls below a predefined threshold over a rolling measurement window. The threshold must be set before deployment and documented in the model's governance record.
- Anomalous order pattern. Order frequency, average order size, or counterparty concentration deviates more than N standard deviations from baseline. This is the trigger most likely to be activated by RAIDAR — pre-empting SEBI scrutiny with internal activation demonstrates governance maturity.
- Market regime break. External market conditions deviate sufficiently from the training regime that model confidence intervals collapse. Triggered by volatility spikes, circuit breaker events, or liquidity gaps beyond model training parameters.
- Security or integrity event. Evidence of prompt injection, data poisoning, or adversarial manipulation of inputs affecting model decisions.
- Third-party model change. The vendor-supplied model underlying the trading strategy has been updated without adequate advance notice or re-validation.
Advisory AI Kill-Switch Triggers
- Financial advice boundary violation. System outputs containing investment recommendations that exceed its declared scope (for a general information service) or suitability parameters (for a robo-advisory service). Triggered by output classifier detection or customer complaint pattern analysis.
- Hallucination rate spike. Factual accuracy monitoring shows the system producing materially incorrect market data, NAV information, or regulatory guidance. For SEBI investment advisers, a mis-stated NAV or incorrect regulatory deadline has direct customer harm potential.
- Suitability failure. Recommendations systematically diverging from customer risk profiles, or recommending products outside the customer's declared investment mandate.
- Data source failure. RAG knowledge base or market data feed failure causing the system to operate on stale or incorrect information without detecting the gap.
Surveillance AI Kill-Switch Triggers
- False positive rate breach. Alert rate deviating beyond governance thresholds, indicating model drift. Over-alerting creates compliance resource exhaustion; under-alerting creates regulatory exposure.
- Known typology coverage failure. A surveillance AI no longer detecting a pattern class it was explicitly designed to cover — detectable via regular adversarial testing against known manipulation typologies.
- Adversarial evasion detected. Evidence that market participants are structuring trades to evade the AI surveillance model's detection logic.
Technical Kill-Switch Architecture
The technical architecture for a compliant kill switch has four layers. Each layer must be present; a switch that has halt capability but lacks rollback is incomplete regardless of how well-documented the halt procedure is.
| Layer | What it does | SEBI expectation | Common gap |
|---|---|---|---|
| L1 — Halt | Stops AI output immediately; prevents new decisions being issued to downstream systems | Activation time documented and tested; ≤ 5 minutes for trading AI in most governance frameworks | Halt stops the model but downstream queued decisions continue executing |
| L2 — Isolation | Separates the AI system from live market data, customer data feeds, and execution infrastructure during investigation | Isolation prevents further data ingestion that could contaminate incident evidence | Isolation not tested separately from halt; same time assumes same procedure |
| L3 — Rollback | Restores the prior model version, parameter set, and knowledge base to a timestamped checkpoint | Checkpoint integrity validated; rollback time documented and tested | Rollback capability exists for code but not for fine-tuned weights, system prompts, or RAG corpus versions |
| L4 — Fallback activation | Routes operational functions to the validated manual fallback while investigation is ongoing | Fallback process tested under realistic load; capacity adequate for peak operational periods | Fallback untested; routing procedure documented but personnel not trained; manual queue capacity underestimated |
Human-in-the-Loop: SEBI's Tiered Oversight Requirement
Beyond the kill switch, SEBI's AI guidelines require human-in-the-loop controls calibrated to AI system risk level. The tiered requirement means that high-risk AI systems cannot operate without defined human review gates — the kill switch is the emergency brake; human oversight is the normal operating control.
Tier 1: Autonomous operation with monitoring
Low-risk AI — internal data analysis, non-customer-facing research assistance, backoffice automation. Human review occurs at the output level (reviewing reports, not individual AI decisions). Kill-switch trigger threshold is relatively high (anomaly must be significant before activation).
Tier 2: Human-in-loop at defined gates
Medium-risk AI — algorithmic trading strategies below material thresholds, robo-advisory recommendations for standard risk profiles, surveillance flagging with human disposition. Human review gates are defined at specific transaction types, order sizes, or recommendation categories. The gate criteria must be documented.
Tier 3: Human pre-approval required
High-risk AI — AI generating investment recommendations for unsophisticated investors, trading AI managing institutional-scale positions, AI-driven research published under the entity's name. Every AI output in this category requires human review and approval before customer delivery or market execution. The human reviewer's identity and approval must be logged.
SEBI vs. RBI MRMF: Comparison for Dual-Regulated Entities
Bank-owned brokerages, NBFC-MFIs with securities operations, and other dual-regulated entities must satisfy both SEBI and RBI requirements simultaneously. The frameworks have significant overlap but material differences in emphasis:
| Requirement | SEBI AI/ML 2026 | RBI MRMF 2026 | How to satisfy both |
|---|---|---|---|
| Kill switch | Required; test evidence expected | Required; 4-layer architecture implied | Build to 4-layer; test and document for both |
| Human oversight | Tiered by risk; pre-approval for high-risk | Mandatory for consequential decisions; override governance | Override framework covers both; SEBI tier classification feeds RBI risk tiering |
| Third-party AI | Entity accountable regardless of vendor | Vendor models not exempt from validation | Vendor contract must give kill-switch access and 30-day change notice; entity validates |
| Model inventory | Implied by accountability requirements | Explicit mandatory requirement | Single inventory covers both; SEBI-specific fields (algo strategy classification) added |
| Explainability | RAIDAR surveillance context; adverse action | Customer-facing decisions; Fair Practices Code | Decision-level logging covers both; regional language requirement from RBI |
| Fairness testing | Not specified separately | Proxy variable screening mandatory | RBI fairness requirements apply to all credit/investment AI regardless of regulator |
What Testing Evidence SEBI Expects
SEBI inspections of AI governance will focus on evidence, not policy. The following artifacts constitute the minimum evidence set for demonstrating kill-switch compliance:
- Kill-switch test records. Dated records of kill-switch activation tests, recording activation time, rollback time, fallback activation time, and any issues encountered. SEBI's expectation is at minimum annual testing for standard-risk AI; more frequent for high-risk systems or systems that have triggered previous incidents.
- Trigger criteria documentation. The written list of kill-switch trigger conditions, signed off by the compliance function and the AI system owner. This document must predate the system's production deployment.
- Fallback capacity assessment. Evidence that the manual fallback process can handle production-level volumes during peak periods. For a trading desk, this means the compliance and risk functions have reviewed manual order-handling capacity against peak trading day volumes.
- Activation authority matrix. Who can activate the kill switch, under what conditions, and without requiring additional approval. A kill switch that requires management approval in a fast-moving market event will not be activated in time.
- Post-incident review. If the kill switch has been activated in production (not just in testing), the post-incident review must be completed and filed. Incidents without completed post-incident reviews are a governance finding regardless of kill-switch effectiveness.
RAIDAR: What Entities Need to Know
SEBI's RAIDAR (Risk-based AI for Detection of Anomalous Research) surveillance tool is the regulatory counterpart to the kill-switch requirement. Where the kill switch is a control the entity exercises, RAIDAR is the control SEBI exercises — a surveillance AI watching for AI-driven market anomalies.
Entities with algorithmic and AI-driven trading strategies should understand three implications of RAIDAR:
- Pattern sensitivity. RAIDAR identifies statistical patterns that deviate from market norms. AI trading strategies that optimize for alpha in ways that create unusual order-flow patterns — even strategies that are fully legal — may trigger RAIDAR flags. Entities should review their algo strategies' order-flow footprints before deployment.
- First-mover advantage of internal activation. If an entity's internal governance detects the same anomaly that RAIDAR would flag, and the entity activates its kill switch before SEBI initiates an inquiry, the governance posture in any subsequent inspection is substantially stronger. Internal trigger criteria should be set conservatively.
- Explainability obligation for flagged strategies. If a RAIDAR flag results in a SEBI inquiry, the entity must be able to explain what the AI strategy was doing and why the order patterns occurred. A governance framework that cannot produce this explanation on short notice is effectively operating a black-box trading strategy from SEBI's perspective.
Implementation Checklist: SEBI AI Kill-Switch Compliance
Technical
- L1 Halt mechanism implemented and documented (target activation time ≤5 min for trading AI)
- L2 Isolation from live data feeds tested separately from halt
- L3 Rollback to prior model version — code, weights, prompts, RAG corpus
- L4 Fallback process activated and validated under realistic load
- Downstream queue cleared on halt (no queued AI decisions executing after halt)
Governance
- Trigger criteria documented and signed off before production deployment
- Activation authority matrix — named individuals, no approval chain required for time-sensitive activation
- Human-in-loop tier classification documented for each AI system
- Override rate monitoring for trading and advisory AI (detect automation bias drift)
- Vendor AI contracts include kill-switch access rights and 30-day change notice
Testing and Evidence
- Annual kill-switch test records (at minimum); semi-annual for high-risk AI
- Fallback capacity assessment completed against peak volume scenarios
- Post-incident review on file for any production activations
- RAIDAR-readiness review: order-flow footprint analysis for algo strategies
- Explainability documentation for flagged strategy patterns
Zytra for SEBI AI compliance
Zytra generates the kill-switch test records, trigger criteria documentation, and audit trails that SEBI inspections require — alongside RBI MRMF validation evidence, DPDP obligations, and the India-specific fairness requirements no international AI governance platform covers.