By Meghna Sharma Automated trading systems use software to analyse market information and generate or execute trading orders according to predefined rules. Instead of manually deciding when to buy or sell, a trader can create a system that follows specific conditions automatically.
These systems range from relatively simple rule-based strategies to sophisticated algorithmic trading infrastructure used by professional trading firms. However, building an automated trading system is not simply a matter of writing a few lines of code. A reliable system requires a clearly defined strategy, quality market data, robust software, risk controls, testing and continuous monitoring.
In India, automated and algorithmic trading also operates within an exchange and regulatory framework. SEBI introduced a framework for safer participation of retail investors in algorithmic trading through brokers, with implementation standards from the exchanges. NSE currently provides facilities for algorithmic trading and has requirements concerning brokers, algo providers and API-based trading.
What Is an Automated Trading System?
An automated trading system is software that can analyse information and generate trading decisions based on predefined rules.
For example, a simple strategy might say:
Buy when the 20-day moving average crosses above the 50-day moving average.
Sell when the 20-day moving average falls below the 50-day moving average.
Once programmed, the system can monitor the relevant market and generate orders when the specified conditions occur.
NSE defines automated trading as software or a facility that automatically generates and pushes buy or sell orders into the exchange trading system when specified parameters are fulfilled.
Step 1: Define the Trading Strategy
The first stage is not coding. It is deciding exactly what the system is supposed to do.
A strategy should define:
- Entry conditions
- Exit conditions
- Position size
- Stop-loss rules
- Profit-taking rules
- Maximum number of positions
- Trading hours
- Instruments to trade
- Conditions under which trading should stop
For example, a momentum strategy could require a stock to cross a particular price level while trading volume exceeds a predefined threshold.
The rules need to be precise enough that a computer can interpret them without subjective judgment.
Step 2: Collect and Prepare Market Data
The system then needs reliable historical and, eventually, real-time data.
Depending on the strategy, this may include:
- Open, high, low and closing prices
- Trading volume
- Bid and ask prices
- Corporate-action information
- Futures data
- Options data
- Market-depth information
Data must be cleaned and checked before being used.
Incorrect prices, missing observations, duplicate records or improperly adjusted historical prices can produce misleading backtest results.
For example, if a stock underwent a split and historical data was not adjusted correctly, the system could interpret the corporate action as a massive price movement.
Step 3: Develop the Trading Logic
Once the rules and data are ready, developers convert the strategy into software.
A system may contain several components:
Data module: Receives market information.
Strategy engine: Determines whether trading conditions are satisfied.
Risk-management module: Checks whether the proposed order is within predefined limits.
Order-management system: Sends, modifies or cancels orders.
Monitoring system: Tracks positions, orders, errors and system health.
The software may communicate with a broker or exchange through approved interfaces such as APIs.
NSE provides API and algorithmic-trading facilities to trading members subject to exchange requirements.
Step 4: Backtest the Strategy
Before risking real money, developers normally conduct a backtest.
Backtesting means applying the trading rules to historical market data to determine how the strategy would have performed historically.
Important measures include:
- Total return
- Annualised return
- Maximum drawdown
- Volatility
- Win rate
- Average profit and loss
- Number of trades
- Risk-adjusted return
- Transaction costs
For example, a strategy might appear to generate a 20% annual return before costs. After brokerage, taxes, slippage and other realistic assumptions, the return could be substantially lower.
This is why a backtest should not simply report gross theoretical profits.
Step 5: Avoid Overfitting
One of the biggest dangers in automated trading is overfitting.
Overfitting occurs when a strategy is excessively tailored to historical data and performs well in the past but poorly on new data.
Suppose a developer tests dozens of moving-average combinations and selects the one that produced the highest historical return. The result may look impressive, but the chosen parameters could simply be exploiting random patterns in the historical dataset.
A better approach is to separate data into different periods.
For example:
Training period → Develop the strategy
Validation period → Refine and evaluate
Out-of-sample period → Test performance on unseen data
The goal is to determine whether the strategy has a robust underlying logic rather than simply memorising historical market behaviour.
Step 6: Include Realistic Trading Costs
A backtest without trading costs can create an unrealistic picture.
Automated strategies may generate numerous orders, so costs can accumulate.
Testing should consider relevant factors such as:
- Brokerage
- Exchange charges
- Taxes and statutory levies
- Bid-ask spreads
- Slippage
- Market impact
- Data costs, where applicable
A strategy that produces very small profits per trade may become unprofitable once realistic execution costs are included.
Step 7: Paper Trading and Simulation
After historical testing, developers can move to a simulated or paper-trading environment.
Here, the system operates using live or representative market data without necessarily risking actual trading capital.
This stage can reveal problems that historical backtesting cannot.
For example:
- API disconnections
- Delayed data
- Incorrect order states
- Duplicate orders
- Unexpected market conditions
- Software crashes
- Incorrect position calculations
NSE provides test-market and simulated-market facilities for members to test trading and risk-management software, including algorithmic-trading systems.
Step 8: Stress Testing
A strategy should also be tested under abnormal market conditions.
Developers can simulate:
- Sudden price crashes
- Large overnight gaps
- Extreme volatility
- Illiquid markets
- Trading halts
- Data interruptions
- Broker/API failures
- Multiple simultaneous positions
The purpose is not only to determine whether the strategy makes money, but also to determine how it fails.
A robust system should have controls that prevent a technical failure from turning into an uncontrolled trading position.
Step 9: Build Risk Controls
Risk management should operate independently of the strategy’s profit-making logic.
Useful controls may include:
- Maximum order quantity
- Maximum daily loss
- Maximum position size
- Maximum number of orders
- Price limits
- Exposure limits
- Automatic shutdown conditions
- Duplicate-order protection
- Connectivity monitoring
For example, if a system normally trades 100 shares but suddenly attempts to place an order for 100,000 shares because of a software error, a risk-control layer should be able to reject the order.
This separation between strategy logic and risk controls is an important part of professional automated trading design.
Step 10: Deploy Gradually
A system should generally not move directly from backtesting to full-scale live trading.
A controlled deployment might involve:
- Historical backtesting
- Out-of-sample testing
- Simulation
- Small live position
- Performance monitoring
- Gradual scaling
The system should be monitored for differences between expected and actual execution.
A profitable backtest does not guarantee profitable live trading.
Regulatory Considerations in India
Automated trading in India is subject to exchange and SEBI requirements.
SEBI’s framework for safer retail participation in algorithmic trading through brokers establishes responsibilities for investors, stock brokers, algo providers and market infrastructure institutions. The framework became applicable to all stock brokers from April 1, 2026, following the implementation timeline.
NSE also states that algo providers serving the retail framework are subject to an empanelment process involving parameters such as infrastructure and systems.
NSE’s retail-algo FAQs further clarify that orders received through client APIs are treated as algo orders and require appropriate tagging under the applicable framework.
Therefore, traders should not assume that any third-party software or API-based strategy can automatically be deployed without checking the broker’s and exchange’s applicable requirements.
Common Problems With Automated Trading Systems
Even a carefully designed system can fail.
Common problems include:
Bad Data
Incorrect or delayed market data can generate incorrect signals.
Execution Differences
The actual fill price may differ from the price assumed during backtesting.
Software Bugs
A coding error can generate unintended orders.
Strategy Decay
A strategy that worked historically may stop working as market behaviour changes.
Overfitting
Excessive optimisation can make historical results look better than the strategy’s real-world capability.
Connectivity Failures
A system may lose communication with the broker or market-data provider.
These risks demonstrate why automated trading requires continuous supervision.
How Performance Should Be Evaluated
After deployment, investors should compare actual results with the original testing assumptions.
Important measures include:
- Net return
- Maximum drawdown
- Slippage
- Transaction costs
- Execution speed
- Win/loss distribution
- Tracking error between expected and actual trades
- System downtime
- Risk-limit breaches
A strategy should not be judged only by its total profit.
For example, two systems may both generate ₹1 lakh in profits, but one may have experienced a maximum drawdown of ₹20,000 while the other experienced a drawdown of ₹2 lakh. Their risk profiles are very different.
Conclusion
Automated trading systems are built through a combination of financial strategy, software engineering, data management and risk control. The process normally begins with clearly defined trading rules, followed by data preparation, coding, historical backtesting, out-of-sample testing, simulation, stress testing and controlled live deployment.
Testing is particularly important because a strategy that looks profitable on historical charts may perform very differently after transaction costs, slippage and real-world execution constraints are considered.
In India, automated trading also has regulatory and exchange-level requirements. SEBI’s retail algorithmic-trading framework and NSE’s implementation standards are designed to make automated trading safer and more controlled.
Ultimately, automation does not eliminate trading risk—it changes how trading decisions are made and executed. A good automated system therefore needs not only a potentially profitable strategy but also reliable data, robust software, strict risk limits, realistic testing and continuous monitoring.