Systematic Execution in India: APIs, Algos & SEBI Rules

Building a strategy is one thing. Putting it into production at scale is entirely different. Your backtest assumes you can place 1,000 orders per day with zero latency, zero fees, and zero regulation. Live execution hits reality: broker APIs have rate limits (3 orders per second on Kite Connect). SEBI has a circular you've never heard of. Your risk controls are optional suggestions until the market moves 200 points in your face.

This module walks through the complete infrastructure stack for systematic execution in India | the APIs that connect you to exchanges, SEBI's algorithmic trading regulations, and the risk controls that separate professional traders from blown-up retail accounts.

The Indian broker API landscape

Every systematic strategy needs three things from a broker: order placement, market data (real-time and historical), and portfolio monitoring. Indian brokers have mostly solved this with APIs. Let me walk you through the major players:

Zerodha Kite Connect

Market share: The dominant retail API in India. Most systematic traders start here. What it offers: Order placement, live market data via WebSocket, historical OHLC data, portfolio data, account details. Rate limits: 3 orders per second, 200 market data requests per minute (WebSocket is less restricted). Cost: ₹2,000 per month (one-time or recurring). Authentication: OAuth 2.0 with a user redirect flow | you generate an access token, store it, refresh it daily. Libraries: kiteconnect Python library is mature and well-maintained.

I started with Kite Connect in 2019. It's simple, reliable, and the documentation is clear. The catch: you're limited to 3 orders/second, which matters if you're deploying a complex multi-leg strategy. The WebSocket for real-time data is WebSocket-based, which means you need connection management code (reconnect on drop, queue orders if disconnected, etc.).

Upstox API

Cost: Free (no monthly subscription). What it offers: Order placement, live data, historical data, portfolio. Rate limits: 10 orders per second (better than Kite). Authentication: OAuth 2.0, similar flow to Kite. WebSocket: Yes, for live data streaming.

Upstox is growing fast among algo traders because of the free tier and higher order rate limit. The documentation is not as comprehensive as Kite, but sufficient for most use cases.

Angel One SmartAPI

Cost: Free. What it offers: Order placement, live data, historical data. Rate limits: 10 orders per second. Authentication: API token-based (simpler than OAuth). WebSocket: Yes.

SmartAPI is popular with day traders. The authentication flow is simpler than Kite (no OAuth redirect), which makes testing easier. Rate limits are generous (10 OPS).

Others: IIFL, 5paisa, Dhan, Flattrade

These brokers all have APIs, all free or cheap. All have order placement, live data, and WebSocket support. Rate limits vary (typically 5-10 OPS). The key difference is commission structure, execution speed (latency), and reliability of their infrastructure during market crashes. Most have less documentation and smaller developer communities than Kite, so debugging is harder when things break.

Key consideration: authentication and session management

Every API requires you to authenticate and get an access token. Kite Connect tokens expire daily. Upstox tokens are longer-lived. You need production code that handles token refresh automatically | missing a refresh means your strategy silently stops placing orders mid-day. For production systems, this is a critical detail:

• Store tokens securely: Never hardcode API keys or session tokens in your code. Use environment variables or encrypted config files.
• Implement token refresh: Check token expiry and refresh before it expires, not after.
• Handle connection drops: WebSocket connections drop. Build reconnection logic with exponential backoff.
• Queue orders during disconnections: If your WebSocket drops, queue pending orders and execute them when connection restores.

SEBI's algo trading circular (February 2025)

In February 2025, SEBI released circular SEBI/HO/MRD/MRD-PoD-2/P/CIR/2025/23, fundamentally changing algo trading regulation in India. This is the single most important regulation change for retail algo traders in the past decade.

The key changes

1. Mandatory Algo-ID registration from April 2026. Every algorithm must be registered with the exchange via your broker. You can't just run Python scripts anymore | each algo needs an Algo-ID assigned by the broker after approval. The registration process includes:

• White-box vs black-box classification: White-box algos submit code/logic to the exchange. Black-box algos don't, but require more compliance documentation.
• Broker approval: Your broker reviews your algo, not just SEBI. Brokers have responsibility for client algos under a 'principal' model.
• Audit trail: Every order must be tagged with the Algo-ID, traceable to you and your algorithm. SEBI can audit this anytime.

2. Orders Per Second (OPS) threshold: 10 OPS. This is critical. Algos that exceed 10 orders per second must undergo additional compliance review:

• Below 10 OPS: Standard registration. You submit your logic, get Algo-ID, you're good.
• Above 10 OPS: Enhanced surveillance, additional testing requirements, proof that your algo doesn't cause market disruption.
• Impact on strategy: If you're building a high-frequency execution algorithm (multi-leg rebalance, or rapid order cancellation), you'll cross 10 OPS easily. You need to plan for this during design phase.

3. API-based retail orders will also need Algo-ID tagging. This is the part that surprised most traders. If you're using an API to systematically place orders (even if it's not "algorithmic" in the sense of autonomous decision-making), SEBI now requires that you tag every order with an Algo-ID. This means even a simple systematic rebalance script needs registration.

4. Record-keeping and audit trail: You must maintain complete logs of every order, every cancellation, every execution detail for 5 years minimum. SEBI can audit this during investigations. The format is strict: timestamp, Algo-ID, order details, execution price, execution time, cancellation reason if applicable.

Impact on your strategy

If you're running a systematic strategy on RupeeCase or planning to build your own:

• Registration timeline: From April 2026, you can't execute any algo without registration. Plan your strategy deployment date accordingly | you'll need 2-3 months to complete broker approval and SEBI registration.
• Rate limits and execution speed: Design with 10 OPS in mind. If you need >10 OPS, budget for enhanced compliance review. Avoid high-frequency execution unless absolutely necessary.
• Order tagging: Your API calls must include Algo-ID in the payload (usually a field your broker provides). If you're using Kite Connect or another API, the broker handles this automatically once you have Algo-ID.
• Risk controls become mandatory: SEBI expects kill switches, position limits, order rate limiters. covered these in the next section.

Building your first systematic execution pipeline

The architecture of a systematic execution system is surprisingly simple:

Signal generation → Order management → Execution → Monitoring

Let me break this down:

Signal generation layer

Your strategy produces trading signals (e.g., "buy 100 shares of Reliance at ₹2,450 or better"). These signals are computed once per rebalance interval | daily, hourly, or minute-by-minute depending on your strategy. Store these signals in a queue or database:

• Time-based triggers (cron): Run every day at 09:25 AM (pre-open auction), compute all signals, store them.
• Event-based triggers: On every tick of new market data, compute signals. This is more complex (requires real-time data pipeline) but allows faster reaction to market moves.
• Hybrid approach: Most retail systematic strategies use cron (time-based) because it's simpler to reason about and debug. HFT firms use event-based.

Order management layer

Once you have signals, you need to:

• Check current portfolio: API call to get current holdings, cash balance, margin available. Compare signal to current position | if you already own 100 Reliance, don't place a second order.
• Check risk constraints: Before placing any order, verify position limits (e.g., no single position >10% of portfolio), order rate (not exceeding OPS limits), max daily loss. If any constraint violated, skip the order.
• Construct order: Format the order with Algo-ID, order type (limit or market), price, quantity, time-in-force. Use limit orders for systematic strategies | market orders are risky with large sizes.
• Place order: Send to broker API. Catch exceptions: network errors, rate limit errors, insufficient margin, invalid price tick. Log everything.

Execution layer

Different order types are suited for different scenarios:

• Limit orders: Standard for systematic execution. You specify price; order sits in book until it fills or you cancel. Advantage: predictable execution, no slippage surprises. Disadvantage: might not fill if price moves away.
• Bracket orders: Place a primary order + take-profit and stop-loss orders simultaneously. If primary fills, stops activate. Good for strategies with fixed risk/reward targets.
• Cover orders: Like bracket orders but with mandatory stop-loss. Used for positional trading. Good for reducing margin requirements.
• Market orders (avoid for systematic): Execute immediately at best available price. High slippage risk. Acceptable only for very liquid stocks (Nifty futures) or small sizes.

Monitoring and error handling

The messy part of production systems is handling failures:

• What happens if API fails mid-rebalance? You've placed 5 orders, API crashes on order 6. You have 5 fills and 5 unfilled signals. Option 1: retry the API call (exponential backoff). Option 2: skip this rebalance, try again next cycle. Option 3: manual intervention | log the error and notify you to fix it.
• What if network breaks between order placement and confirmation? You sent the order but didn't get a response. Did it execute? Your code must: query the broker API for recent orders, check if the order was placed, avoid duplicate orders. This is called idempotency | placing the same order twice should not result in 2 executions.
• Logging and audit trail: SEBI requires complete logs. Every order, every execution, every error must be logged with exact timestamps. Use a central logging service (ELK stack, Datadog, or even a simple database). Never rely on print() statements.
• Paper trading before live: Test your execution pipeline on paper (simulated orders) for at least 1 week before going live with real money. This catches 80% of bugs.

Risk controls every algo must have

SEBI expects these. Your broker expects these. Your accountant will ask for proof of these. You need these so you don't lose your entire portfolio in 3 minutes.

Position limits

Before placing any order, check: What's my current position in this stock? What's my portfolio weight? Never allow a single position to exceed X% of your total portfolio. Example:

• Portfolio value: ₹10L
• Max position limit: 15%
• Max position size: ₹1.5L
• Current Reliance holding: ₹80,000
• Signal: buy ₹1L more Reliance
• Check: ₹80,000 + ₹1L = ₹1.8L > ₹1.5L | REJECT. Place smaller order for ₹70,000 instead.

This is the simplest risk control and prevents any single bet from dominating your portfolio.

Order rate limits (self-imposed)

You know SEBI's 10 OPS limit. But impose your own limit lower than this. Example: allow maximum 6 OPS. Why? Buffer for unexpected spikes. If your code has a bug that causes order spam, you cap it at 6 instead of hitting the 10 OPS wall and triggering SEBI review.

Max daily loss kill switch

This is critical. Set a threshold: if my strategy is down ₹50,000 today (or 5% of portfolio), stop placing orders. Don't try to recover losses by increasing order size. Stop, investigate, come back tomorrow. Implementation:

• Track P&L in real-time: current portfolio value minus initial portfolio value.
• Before each signal execution, check: if P&L < -₹50,000, skip this signal.
• Log and notify you: send an email or alert that the kill switch triggered.

Fat finger protection

Your algorithm should never place an order larger than X. Example: max order size ₹2L. If signal says "buy ₹5L", cap it at ₹2L. This prevents runaway orders if your position sizing code has a bug.

Market hours validation

Only place orders during market hours. Prevent accidental orders at 11:59 PM or during market halts. Check: is market open? Simple logic:

• NSE equity market: 09:15 to 15:30
• Pre-open auction: 09:00 to 09:15
• If current time outside these windows, skip order placement.

Duplicate order detection

This is subtle. Your code generates a signal to buy Reliance. You place the order. API returns a response: "Order placed, order ID 12345". But then your code runs again (maybe cron job ran twice) and generates the same signal. You place the order again. Now you have 2 identical orders in the market.

Prevention: before placing an order, query the broker API for recent orders. Check if an identical order already exists in the market. If yes, skip. This is idempotency.

Network failure handling and recovery

Your code is placing orders. Network breaks. API connection dies. Your code must:

• Detect failure: Catch exceptions on API calls. Log them.
• Retry with backoff: Retry the failed call (e.g., after 5 seconds, then 10 seconds, then 30 seconds). Don't retry infinitely | stop after 3-5 attempts.
• Manual escalation: If all retries fail, send alert. Don't silently drop the order.

Circuit breaker response

What happens when the market hits a circuit breaker and trading halts for 45 minutes? Your algo keeps running, but orders can't be placed. Options:

• Check market status: query the exchange for circuit status. If breaker triggered, skip order placement for this cycle.
• Queue orders: store pending signals in a queue. When market reopens, replay them.
• Manual override: send alert asking if you want to execute pending orders after circuit lift.

The compliance checklist

SEBI's 2025 circular is real. Here's what you need to do (or your broker will do on your behalf):

Algo-ID registration (post-April 2026)

• Contact your broker's compliance team.
• Provide: algorithm description (in plain English, not code), logic flow, risk controls implemented.
• Broker submits to exchange for Algo-ID assignment.
• Once assigned, you tag every order with this Algo-ID (broker API handles this automatically).
• Timeline: start this 2-3 months before you want to go live.

Record keeping (5 years minimum)

• Every order placed: timestamp, Algo-ID, symbol, quantity, price, order type.
• Every execution: execution price, execution quantity, execution time.
• Every cancellation: cancellation timestamp, reason.
• P&L logs: daily mark-to-market, positions, fees.
• Use a database or structured logs (not just text files). Easy to query and audit.

Audit trail format

SEBI specifies format: CSV with columns like order_id, timestamp, algo_id, symbol, side (BUY/SELL), quantity, limit_price, order_status (PLACED/EXECUTED/CANCELLED), execution_price, execution_quantity. Store this continuously, not just monthly.

SEBI investigation readiness

If SEBI comes knocking (unlikely, but it happens), they'll ask for:

• Algorithm code and logic documentation.
• Complete execution logs for a date range.
• Risk control settings at that time.
• P&L explanation for any abnormal trading activity.
• Proof that you didn't engage in market manipulation (wash trades, spoofing, etc.).

Have this ready. Not theoretical | keep it organized and timestamped.

Broker's right to shut down your algo

Your broker can shut down your algo at any time if:

• It generates excessive orders (above OPS limit consistently).
• It creates unusual market disruption (massive volatility spike, circuit breaker triggered, large rejection rate).
• It violates SEBI rules (market manipulation, fraudulent activity).
• Your account has unsettled fund issues or margin violations.

You'll get a notification and a chance to explain. But broker has final say. Plan accordingly.

Penalties for non-compliance

• Running unregistered algo post-April 2026: Up to ₹25L penalty + potential action against broker.
• Failure to maintain audit trail: ₹5-10L penalty.
• Market manipulation via algo: ₹1Cr+ penalty, potential imprisonment.

Compliance is not optional. It's expensive to ignore.

The RupeeCase Terminal approach

Here's the insight: if building all this from scratch sounds complex, it is. That's why RupeeCase Terminal handles the hard parts:

• Pre-built systematic strategies: No need to code APIs. Choose a strategy, set parameters, execute.
• Built-in risk controls: Position limits, daily loss kill switch, order rate limiting | all automatic.
• SEBI compliance built-in: Every order tagged with strategy ID, audit trails maintained, 5-year logs kept.
• Execution engine: Handles order placement, connection management, error recovery, paper trading simulation.
• No API coding required: Use the terminal UI instead of writing Python scripts.

If you want to execute systematic strategies without managing infrastructure, you track your execution on rupeecase.com.

Why I wrote this module