Most writing about SEBI's algo trading framework is aimed at retail traders deciding whether their strategy is still allowed. This one is for the people who have to build the thing: what the software must actually do, and by when.
The short version: from April 1, 2026, the framework applies to all stock brokers. If you operate an algo product that reaches retail clients through a broker API, the compliance surface is now part of your architecture, not a document you write afterwards.
The dates, from the circulars themselves
The timeline moved several times, which is why you will find contradictory dates in circulating blog posts. Here is the actual sequence:
- February 4, 2025 — SEBI issues the circular Safer participation of retail investors in Algorithmic trading (SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/13). Originally effective August 1, 2025.
- July 22, 2025 — Exchanges publish the detailed operational modalities.
- July 29, 2025 — Effective date pushed to October 1, 2025.
- September 30, 2025 — Circular SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/132 introduces a glide path: brokers who were ready went live from October 1, 2025; the rest had to hit milestones — apply to register at least one algo strategy by 31 October 2025, complete registration by 30 November 2025, and participate in a mock session by January 3, 2026.
- January 5, 2026 — Brokers who missed those milestones are barred from onboarding new retail clients for API-based algo trading.
- April 1, 2026 — The framework, implementation standards, and operational modalities apply to all stock brokers.
If a vendor tells you the rules "start in April 2026," they are describing the final deadline, not the start. Registration and empanelment obligations have been live since late 2025 — April 2026 is when the exemptions run out.
What this means structurally
Three constraints shape the architecture more than anything else.
Orders route through a broker, never straight to the exchange. An algo provider cannot hold a direct exchange connection. Your execution path terminates at a broker API, and the broker owns the client relationship and the complaint process. Design your system so the broker adapter is a swappable boundary — you will eventually support more than one.
Every algo order carries a unique exchange-issued identifier. Algo orders flowing through a broker's API must be tagged with a unique ID obtained from the exchange via the broker. This is not a field you invent; it is issued. Practically, your order model needs the tag as a first-class, non-nullable attribute, and your logs need to retain it, because attribution after the fact is exactly what it exists for.
Strategies get registered, and providers get empanelled. Algo products offered to retail through an API require registration with the exchange through the broker, and providers must be empanelled. Brokers are required to deal only with empanelled providers. The engineering consequence: strategy versioning stops being an internal detail. If a registered strategy's behaviour changes materially, you need to know which version was live at any moment.
What the software actually needs
Independent of the paperwork, here is the build list:
- Algo-ID propagation. Tag at order creation, carry it through modifications and cancellations, and persist it with every fill. Never reconstruct it later.
- Risk controls that run before the order leaves. Order-rate limits, daily loss caps, maximum position and exposure checks. These are pre-trade gates, not dashboards you read afterwards.
- A kill switch an operator can actually reach. One action that halts new orders and optionally flattens positions — tested, not theoretical.
- Immutable execution logs. Append-only, timestamped, sufficient to reconstruct why a given order existed. Assume you will one day explain a specific trade to someone.
- Static IP and two-factor authentication on API access paths, per the security requirements around API-based automated trading.
- Behaviour under failure. Reconnects, partial fills, stale ticks, duplicate acknowledgements, broker downtime. This is where real money is lost, and it is almost always under-specified.
The part people get wrong
Teams treat compliance as a layer to add near launch. It is not a layer — Algo-ID tagging and pre-trade risk checks sit directly on the order path, the hottest and most correctness-sensitive code you have. Retrofitting them means rewriting that path under deadline pressure, which is the worst possible time to touch it.
The cheaper sequence is to build the order path with the tag and the gates from the first commit, then add strategy logic on top. The constraints are not the interesting part of the system, but they are the part that determines whether you are allowed to run it.
This is an engineering summary, not legal advice. Registration status, empanelment, and your obligations as a provider or broker depend on your specific setup — confirm them against the current circulars and with your compliance counsel.
Where this leaves builders
The framework raised the floor. Building a retail-facing algo product is now a regulated software problem with audit requirements, not a weekend script against a broker API. That is a real barrier — and for teams who build it properly, a durable one.
If you are scoping a system against these requirements, we build exactly this: strategy engines, broker integrations, risk controls, and the audit trail underneath.