--- title: "Systematic Execution in India | RupeeCase Learn" description: "The complete guide to algorithmic trading infrastructure in India. Broker APIs, SEBI's 2025 algo circular, risk controls, compliance." source_url: "https://www.rupeecase.com/learn/path-10/module-10-3-systematic-execution-in-india-apis-algos-and-sebi-rules" --- Skip to main content [Learn](/learn)›[Path 10: Strategy Implementation & Execution](/learn/path-10)›Module 10.3 # Systematic Execution in India: APIs, Algos & SEBI Rules The first algo I deployed made 47 trades in 3 minutes. It also violated 2 SEBI regulations I didn't know existed. Here's everything I learned the hard way about algorithmic trading in India | from broker APIs and SEBI's 2025 circular to risk controls that keep your strategy from blowing up. TK Tanmay Kurtkoti Founder & CEO, RupeeCase · QC Alpha ⏱ 18 min read ⟳ Updated 15 May 2026 ◆ Advanced 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 Copy text Share on X Post on LinkedIn Copy link Research Lab Qualifier Path 10, Module 3 of 6 done, complete all 6 + path test to unlock [Explore terminal →](https://invest.rupeecase.com) 📍 10.1 Market Microstructure→ 10.2 Cost of Trading→ 10.3 Systematic Execution→ 10.4 → 10.6 Calculator ### Broker API Rate Budget Indian broker APIs throttle retail accounts at 7 to 10 orders per second on average. This budget calculator shows whether your strategy fits. Universe size (stocks)Avg orders per rebalance per stockBroker API limit (orders/sec)Acceptable rebalance window (minutes) Quick check, Module 10.3 ## 3 questions. Get 2 right to mark this module complete. 0 of 3 answered ✓ Module complete. Keep going. Up next, Module 10.4 Paper Trading to Live: The Hardest Transition Your backtest shows 22% returns. Your paper trading shows 18%. Your live trading shows 8%. What went wrong, and how to bridge the gap between theory and reality. [Continue →](module-10-4-paper-trading-to-live-the-hardest-transition.html) PRACTICE WHAT YOU LEARNED Deploy systematic strategies on RupeeCase | free paper trading. [Get Started Free →](https://invest.rupeecase.com/signup) Related on RupeeCase [PodcastEP21: They dumped it, not trimmedFri 17 Apr, execution read](/podcast/episodes/2026-04-17.html) [DailyLiquidity and slippage todayLive execution notes](/daily/2026-04-17-pro-conviction-short-they-just-dumped-it.html) [CompareTracking error vs active fundWhat execution actually costs](/compare/rupeecase-nifty-vs-sbi-magnum-midcap.html) [ToolsCost calculators and checklistsSTT, brokerage, tax](/learn/tools.html) [StrategyAllCap Multi AssetLive execution case study | 2W rebalance](/strategies/allcap-multi-asset.html) © 2026 RupeeCase by QC Alpha · [rupeecase.com](https://www.rupeecase.com) · [All learning paths](https://www.rupeecase.com/learn) Newsletter ### What's working, what isn't. Strategy launches, monthly performance notes, and podcast calls that printed. Two or three emails a month. Built for people who actually read them. Subscribe By subscribing you agree to our [Privacy Policy](/privacy-policy.html). RupeeCase is not a SEBI registered Investment Adviser. Nothing in the newsletter is personalised investment advice. Built on India's regulated market infrastructure NSE Order routing BSE Backup venue SEBI Markets regulator NISM Certified author [About](/about.html). [Pricing](/pricing.html). [Risk Profile](/risk-profile.html). [Tools](/learn/tools.html). [Sitemap](/sitemap.html) [Privacy Policy](/privacy-policy.html). [Terms](/terms.html). [Disclaimers](/disclaimers.html). [Grievance](/grievance.html) RupeeCase is brought to you by Tanmay Kurtkoti.