Algorithmic Trading in India: What It Is (and Isn’t)

If you are learning to trade with code, the first question is not which broker API to use. It is what, exactly, your software will do. Algorithmic trading in India means automated execution logic generates trading orders. It is broader than high-frequency trading (HFT), different from merely following a systematic method, and does not require artificial intelligence.

Why the four labels are so often confused

“Algo trading” is used loosely for almost any trading workflow that involves rules, charts or software. That creates confusion at the point where a person moves from research to execution. A spreadsheet can calculate a signal without sending an order. A broker API can automate execution after a human chooses the trade. A fully automated system can do both. Only some of these systems have the speed, turnover and infrastructure associated with HFT.

The easiest way to separate the terms is to ask three questions:

1. How is the decision made? Is it discretionary or based on repeatable rules?
2. Which steps does software perform? Does it collect data, calculate a signal, manage risk, transmit the order or reconcile the fill?
3. Does automated logic generate a trading order? This is the important boundary in SEBI’s formal algo-trading framework.

Speed is a fourth question, not the definition of algo trading. A five-minute strategy that sends a few orders through an API can be algorithmic without being high-frequency.

Systematic trading is a method for making decisions

Systematic trading means that a trader follows a defined, repeatable process. The rules might specify which securities are eligible, what creates an entry, where a position is closed, how much capital can be used and when trading must stop.

Imagine a trader who downloads end-of-day prices, screens for a moving-average condition and records the qualifying stocks in a spreadsheet. The next morning, the trader checks liquidity and manually places the orders. The decision process is systematic because the rule is repeatable. The order-generation step is still manual.

Systematic does not necessarily mean mechanical in every detail. A rules-based screen may produce ten candidates while a human chooses three after checking the day’s liquidity or a corporate announcement. That workflow can be systematic and partly automated, but calling it fully automated would hide the human decision.

“Systematic trading” is therefore a useful description of how decisions are made. It is not, by itself, the legal test for whether an order is algorithmic under the Indian framework.

Automated trading describes what software performs

Automation is a spectrum rather than a switch. A trading workflow may automate one stage or nearly all of them:

• downloading and cleaning market data;
• calculating indicators and signals;
• applying position and loss limits;
• creating an order request;
• sending and retrying an order through a broker API;
• monitoring acceptance, rejection and fills; and
• reconciling the broker’s position with the system’s records.

A charting programme that sends an alert is automated at the monitoring stage. If a person reads the alert and clicks the order button, the execution remains manual. At the other end, a system can receive data, evaluate its rules, apply risk checks and send an order without per-trade confirmation.

There is also a common institutional example. A portfolio manager may decide to buy 50,000 shares, while an execution programme divides that instruction into smaller child orders and releases them over time. The investment decision is human, but software is automating order generation and execution.

That distinction matters when you design a system. A backtest that produces a buy or sell column is not automatically a live algorithm. A live system has to manage identifiers, order states, retries, partial fills and disconnections as well as the signal itself.

Algorithmic trading is centred on automated order generation

SEBI’s 30 March 2012 circular defines an algorithmic order as one generated using automated execution logic. The circular also requires controls around automated orders, including price and quantity checks, safeguards against dysfunctional or runaway algorithms, order identification and records that support an audit trail (1).

In plain English, the useful test is: does software use automated logic to generate the trading order? The order does not have to be a market order, the strategy does not have to use machine learning and the system does not have to send hundreds of orders a second. A deterministic rule such as “send a limit order when conditions A, B and C are satisfied” can fall within the broad concept if software evaluates the conditions and generates the order.

SEBI’s April 2018 Board memorandum adds a wider market-structure description. It refers to automated, rule-based trading in which decision-making is delegated to a computer model, and describes HFT as a type of algorithmic trading associated with latency sensitivity, high daily portfolio turnover and a high order-to-trade ratio (2).

The two sources answer different parts of the question. The 2012 circular gives the practical order-generation boundary. The 2018 memorandum explains how broader algorithmic trading relates to the narrower HFT category.

HFT is a specialised subset, not the default meaning of “algo”

High-frequency trading is defined by the design of the system and its market behaviour, not by the fact that it uses code. Latency is central: the system is built to receive information, make decisions and place or cancel orders very quickly. High turnover and a high order-to-trade ratio are also relevant. Co-location or infrastructure close to an exchange may reduce communication time, but proximity alone does not turn an ordinary strategy into HFT.

An API system that checks five-minute candles and submits a few orders during the session can be algorithmic while being nowhere near HFT. The same is true of a daily rebalancing script. Conversely, a human portfolio manager using an execution algorithm may be participating in algorithmic execution even though the investment decision was not made by a computer.

The relationship can be stated simply:

All HFT is algorithmic trading, but most algorithmic trading is not HFT.

The bottom-right cell is systematic, automated algorithmic trading. It becomes HFT only when latency, turnover and order-to-trade behaviour are central characteristics of the system.

Five everyday workflows, classified

The product name—“bot”, “signal service”, “API strategy” or “execution engine”—does not settle the classification. Look at the complete workflow.

These are educational classifications based on the described facts, not broker-specific legal rulings. The implementation, exchange access route and applicable rules still matter.

An automated exchange does not make every trader an algo trader

NSE’s NEAT+ is a fully automated, screen-based, order-driven trading system: once an order reaches the exchange, the matching engine processes it electronically. NSE separately describes algorithmic trading as a non-NEAT front-end facility available through member infrastructure (3).

That gives us two different kinds of automation:

• exchange automation decides how received orders are prioritised and matched; and
• trader-side automation decides how an order is created and sent.

If a person enters an order manually and NSE matches it electronically, the exchange is automated. The trader’s order-generation process has not become algorithmic simply because the market uses an electronic matching engine.

The same distinction applies to software tools. Downloading prices through an API is not the same as generating orders through an execution API. Running a backtest in Python is not live algo trading. Looking at a chart on a computer is not algorithmic order generation.

How India’s framework developed

The regulatory story is easier to understand as a sequence of layers rather than as one new “algo law”.

2012: controls for automated orders. SEBI’s broad guidelines established the order-generation concept and required risk controls, identification and audit records. The emphasis was on preventing dysfunctional behaviour and ensuring that automated activity could be supervised.

2018: a clearer relationship with HFT. SEBI’s Board memorandum described automated, rule-based decision-making and placed HFT within the broader algorithmic category. Latency, turnover and order-to-trade behaviour became useful ways to describe the narrower subset.

2025: retail API participation. SEBI’s 4 February 2025 framework addressed the growing use of broker APIs by retail investors. It set roles for investors, brokers, algo providers and exchanges and covered authentication, risk management, provider empanelment and the distinction between white-box and black-box algos (4).

2026: all-broker applicability. SEBI’s 30 September 2025 glide-path circular stated that the retail framework, implementation standards and exchange modalities would apply to all stock brokers from 1 April 2026 (5). NSE’s current algo-provider page refers participants to consolidated circular NSE/INVG/73992 dated 30 April 2026 and shows a 31 July 2026 page update (6).

This article stops at the framework’s meaning and timeline. Static IPs, algo IDs, order-rate thresholds, provider obligations and white-box/black-box restrictions are operational questions for the dedicated guide to SEBI’s retail algo-trading rules. Requirements can change, so check the live regulator and exchange pages before implementation.

A trading system contains more than a signal

Many first projects are built around a single line such as “buy when the moving average crosses”. A live system needs several kinds of logic around that signal.

Strategy logic

This is the hypothesis: what market condition permits an entry or exit? The rule might compare a price with a moving average, test an opening-range breakout or rank securities by momentum. A signal is not evidence of an edge. The later guide to the strategy-idea research pipeline covers how to test and reject ideas before connecting them to an account.

Risk logic

Risk logic decides whether a valid signal is allowed to become an order. It can cap position size, total exposure, daily loss and simultaneous positions. A strategy component should not be the only component that can disable these controls. The separate guide to position sizing and risk management for algos develops those calculations.

Execution logic

Execution logic converts an approved intent into a broker order. It must specify the instrument identifier, side, quantity, order type, price and validity, and must prevent duplicate orders when a network response is delayed. The underlying Indian rules for order types, lot sizes and settlement belong to the next article in this cluster.

State and operations logic

A live system must know whether an order was accepted, rejected, partially filled, cancelled or left uncertain after a disconnection. It must compare its internal position with the broker’s records and preserve enough information to explain each action. This is why a historical signal script and a live algorithm are different products; the execution gap is covered in why live results can differ from backtests.

Machine learning is optional rather than definitional. If you want to understand what is realistic and what is prediction hype, see machine learning for trading.

A five-question test for your own workflow

Before calling a project “algo trading”, describe it precisely:

1. Are the decisions repeatable? If yes, the method is systematic or rules-based.
2. Which steps are automated? Name data, signal, risk, order, monitoring and reconciliation separately.
3. Does automated logic generate trading orders? If yes, that is the central SEBI algo boundary.
4. Does the system depend on extreme latency, high turnover and a high order-to-trade ratio? If yes, it has characteristics associated with HFT.
5. Can the system explain, limit and stop its own actions? This does not define an algo, but it separates a controlled implementation from a script that merely emits signals.

For example, a Python programme that calculates a 20/50 moving-average crossover after each five-minute candle, applies a position cap and sends a broker-API order is systematic, automated and algorithmic. It is not automatically HFT. If the same programme only writes “BUY” to a file for a person to review, its signal generation is automated but the order-generation step remains manual.

What to learn next

Once the terminology is clear, the next practical question is what happens after an order leaves the programme. Indian market mechanics for code-first traders explains order types, lot sizes, sessions and settlement—the details that determine whether an otherwise correct instruction can be accepted and filled as expected. Before testing a strategy, also review the maths needed for algorithmic trading so that win rate, expected value and costs are interpreted correctly.

Sources and scope

The definitions and regulatory milestones above are based on sources (1)–(6). The workflow classifications are educational examples, not legal or broker-specific advice. Rules can change, so recheck current SEBI and NSE pages before implementation.

Sources

1. SEBI, Broad Guidelines on Algorithmic Trading (2012)
2. SEBI, Measures for Strengthening the Algo-Trading Framework (2018)
3. NSE, NEAT+ Trading Technology
4. SEBI, Retail Algo-Trading Framework (2025)
5. SEBI, Retail Algo Framework Glide Path (2025)
6. NSE, Empanelled Algo Providers