SEBI's 2026 retail algo trading framework

Everything in chapters 1-133 was written against the technical mechanics of broker APIs. This chapter covers the regulatory layer wrapped around all of it since SEBI's February 4, 2025 circular, "Safer participation of retail investors in Algorithmic trading" — a framework that became fully mandatory for every stockbroker on April 1, 2026, and is already in force as of this writing. If you skip this chapter and go straight to chapter 44's first live order, it will likely be rejected for reasons this chapter explains.

Why this exists

Before this framework, a retail trader could get an API key and place algorithmic orders with essentially no exchange-level traceability back to "this specific piece of code placed this specific order." SEBI's stated goal is traceability and containment — if an algorithm malfunctions and floods the market with bad orders, regulators and exchanges need to identify and halt the source quickly. The framework puts your broker in the position of principal, formally responsible for every algorithm running on their platform through their API — which is why brokers, not just SEBI, now gate what you can do.

Timeline (for context — the deadlines have already passed)

If you're setting up a new API app today (chapter 4), you are onboarding directly into the fully mandatory regime — there is no legacy/grandfathered path.

Requirement 1: Static IP whitelisting — applies to everyone, no exceptions

Every order placed through the API must originate from a static IP address you've registered with your broker in advance. This applies regardless of order frequency or whether you'd call your setup "algo trading" — even a script that places one manual, human-reviewed order a day needs a whitelisted static IP, or every order request from that connection is rejected outright.

# There's no code-level workaround for this — it's an infrastructure requirement.
# Registration happens on the broker's developer console (e.g. developers.kite.trade),
# NOT via an API call. Typical steps:
# 1. Obtain a static IP — from your ISP, or from your cloud/VPS provider
#    (chapter 93's VPS deployment naturally gives you one; a home broadband
#    connection with a dynamic IP does NOT qualify without an add-on static-IP plan).
# 2. Log in to your broker's developer console, find "IP Whitelist" under your profile.
# 3. Enter the static IP. Changes may take some time to propagate — do this well
#    before you need to trade live, not the morning of.

This directly connects to why this course's deployment chapter (93) insisted on a real VPS rather than a personal laptop: a VPS's IP is already static by default, while a home connection typically is not.

Requirement 2: rate limits and Strategy ID registration for higher-frequency automation

A hard 10 orders/second ceiling applies by default to unregistered retail API usage. To place orders faster than that, your specific strategy must be registered with the exchange and issued a Strategy ID (sometimes called an Algo ID) — a unique identifier that gets attached to every order that strategy places, giving the exchange a direct trace from any specific order back to the registered algorithm and the broker that onboarded it.

def enforce_rate_limit_or_register(orders_per_second_needed: float, has_strategy_id: bool):
    if orders_per_second_needed > 10 and not has_strategy_id:
        raise RuntimeError(
            "Strategy exceeds the 10 orders/sec unregistered ceiling — "
            "register this strategy with your broker/exchange before deploying, "
            "or redesign to stay under the limit."
        )

Registering a strategy is a broker-mediated process (not a self-serve API call) — contact your broker's algo/API support team with your strategy's description before deploying anything that needs sustained throughput above the default ceiling. Chapter 20's rate-limit discipline (headroom, not exact compliance) now has a hard regulatory floor under it, not just a broker-courtesy throttle.

Requirement 3: market protection on market orders

Recent changes require market orders to carry a market protection parameter — effectively a maximum acceptable deviation band from the last traded price, so a market order can't fill arbitrarily far through a thin order book (chapter 26's depth-walking risk, now enforced exchange-side rather than left purely to the trader's own diligence). An order submitted with this protection explicitly disabled is rejected. The exact field name and default value are still settling across SDK versions as of this writing — check your broker's current API reference for the precise parameter before relying on chapter 44's plain market-order examples unmodified in production; add whatever protection parameter is now required rather than assuming the bare order_type="MARKET" call from earlier chapters still works unchanged.

What this changes about how you should read chapters 43-68

Nothing about the *concepts* — order anatomy, product types, order management — changed. What changed is the deployment checklist before any of it goes live:

def pre_live_compliance_checklist(broker_profile: dict, strategy_config: dict) -> list[str]:
    issues = []
    if not broker_profile.get("static_ip_registered"):
        issues.append("Static IP not registered — ALL orders will be rejected")
    if strategy_config.get("orders_per_second", 0) > 10 and not strategy_config.get("strategy_id"):
        issues.append("Exceeds 10 orders/sec without a registered Strategy ID")
    if not strategy_config.get("market_protection_configured"):
        issues.append("Market orders need explicit market protection parameter set")
    return issues

Run a check like this — adapted to your specific broker's current exact requirements, which this chapter deliberately doesn't hardcode since brokers are still actively adjusting implementation details — as a hard gate before chapter 44's first live order, and again before chapter 93's service deployment.

The honest caveat on this chapter specifically

Regulatory implementation details (exact parameter names, exact rate thresholds, exact registration workflows) are more likely to keep shifting than anything else in this course — this chapter reflects the framework as understood in September 2026, sourced from SEBI's original circular and broker developer-forum discussions, not from a stable, long-settled API reference. Treat every specific number and field name here as "verify against your broker's current developer documentation before deploying," more strongly than any other chapter's caveats — this is the one area where being six months out of date can mean your bot simply stops working entirely, not just performing suboptimally.

End of course.