Backtesting is only as good as the data and assumptions you feed into it. In India, traders often choose between two common data types: tick data (every trade) and OHLC bars (open–high–low–close for fixed intervals). Both have a place. The trick is to understand the trade-offs and model execution realistically so simulated results reflect what will happen on the NSE, BSE or MCX when you go live.
Start with the basics: what each type gives you.
Tick data records every executed trade with price, volume and timestamp. It is rich and lets you simulate order matching, slippage, partial fills and micro-structure effects. OHLC bars (for example 1-minute or 5-minute bars) aggregate ticks into four numbers per interval and are far lighter to store and faster to compute on. OHLC is often enough for strategies that trade infrequently or use indicators that don’t need intrabar detail.
When to prefer tick data:
When OHLC works fine:
Common pitfalls and how to avoid them
One frequent mistake is treating an OHLC bar as if every price between open and close actually happened in a given sequence. This can create unrealistic fills. If you use OHLC, adopt conservative rules: assume the worst intrabar price movement relevant to your order type or use randomised intrabar ticks consistent with the bar’s range to estimate fills.
Another pitfall is ignoring execution costs. In India, your backtest should include brokerage (fixed + percentage), exchange transaction charges, GST on brokerage, and stamp duty. Instead of a single percent, model a realistic roundtrip cost like ₹20-₹200 per trade plus a small percentage (e.g., 0.01–0.05%) depending on instrument and broker. Adjust these ranges to match your broker (Zerodha, Upstox, etc.) and product (equity, F&O, commodity).
Practical techniques to bridge tick and OHLC
- If you only have 1-minute OHLC but need intrabar behavior, create synthetic ticks by interpolating volume across the bar or using a volume-weighted approach. Though imperfect, it gives better execution estimates than assuming fills at the close.
- Use downsampling for tick data: aggregate ticks to 100–500 ms buckets or to 1-second bars for faster testing while preserving intraday sequence.
- Replay ticks selectively: for long historical ranges, keep tick replay for high-liquidity sessions or around your trade signals, and use OHLC elsewhere to save time and space.
Model realistic fills and slippage
- For market orders, simulate slippage as a function of order size relative to average trade size or volume at the top-of-book. A simple model: slippage = k * (order_size / avg_trade_size) with k tuned from past data.
- For limit orders, model fill probability and partial fills. Use historical tick sequences to compute the chance a limit at X would have been executed during the bar.
- Include latency where relevant: in HFT scenarios, milliseconds matter. For retail algos on NSE, consider round-trip latencies of tens to hundreds of milliseconds depending on connectivity.
Storage, speed and practicality
Tick datasets are large. For Indian equities, storing years of tick data for many symbols can be costly. Use selective storage — keep ticks for your target universe and recent high-volatility days. Consider cloud or compressed binary formats and index by timestamp for fast seeks.
Validation and walk-forward testing
No matter the data type, always validate on out-of-sample periods and use walk-forward testing. If you develop on 1-minute bars and then test on tick replay, differences reveal execution risk. Reconcile P&L between OHLC and tick simulations to identify where assumptions diverge.
Final thought: match fidelity to strategy. Use tick data when microstructure matters; use OHLC when you need scale and the strategy tolerates intrabar uncertainty. In both cases, simulate realistic costs, slippage and order mechanics in the Indian market to get backtests that guide profitable live trading.
Start with the basics: what each type gives you.
Tick data records every executed trade with price, volume and timestamp. It is rich and lets you simulate order matching, slippage, partial fills and micro-structure effects. OHLC bars (for example 1-minute or 5-minute bars) aggregate ticks into four numbers per interval and are far lighter to store and faster to compute on. OHLC is often enough for strategies that trade infrequently or use indicators that don’t need intrabar detail.
When to prefer tick data:
- High-frequency strategies, scalping or market-making that depend on order book dynamics.
- Intrabar signals such as VWAP reversion, tick-by-tick pattern recognition, or modelling partial fills.
- When you must estimate slippage precisely for large orders relative to average trade size.
When OHLC works fine:
- Swing strategies, most trend-following systems and many mean-reversion rules that act on 1-minute or higher bars.
- When storage, computation time and simplicity matter, and you only need end-of-bar decisions.
Common pitfalls and how to avoid them
One frequent mistake is treating an OHLC bar as if every price between open and close actually happened in a given sequence. This can create unrealistic fills. If you use OHLC, adopt conservative rules: assume the worst intrabar price movement relevant to your order type or use randomised intrabar ticks consistent with the bar’s range to estimate fills.
Another pitfall is ignoring execution costs. In India, your backtest should include brokerage (fixed + percentage), exchange transaction charges, GST on brokerage, and stamp duty. Instead of a single percent, model a realistic roundtrip cost like ₹20-₹200 per trade plus a small percentage (e.g., 0.01–0.05%) depending on instrument and broker. Adjust these ranges to match your broker (Zerodha, Upstox, etc.) and product (equity, F&O, commodity).
Practical techniques to bridge tick and OHLC
- If you only have 1-minute OHLC but need intrabar behavior, create synthetic ticks by interpolating volume across the bar or using a volume-weighted approach. Though imperfect, it gives better execution estimates than assuming fills at the close.
- Use downsampling for tick data: aggregate ticks to 100–500 ms buckets or to 1-second bars for faster testing while preserving intraday sequence.
- Replay ticks selectively: for long historical ranges, keep tick replay for high-liquidity sessions or around your trade signals, and use OHLC elsewhere to save time and space.
Model realistic fills and slippage
- For market orders, simulate slippage as a function of order size relative to average trade size or volume at the top-of-book. A simple model: slippage = k * (order_size / avg_trade_size) with k tuned from past data.
- For limit orders, model fill probability and partial fills. Use historical tick sequences to compute the chance a limit at X would have been executed during the bar.
- Include latency where relevant: in HFT scenarios, milliseconds matter. For retail algos on NSE, consider round-trip latencies of tens to hundreds of milliseconds depending on connectivity.
Storage, speed and practicality
Tick datasets are large. For Indian equities, storing years of tick data for many symbols can be costly. Use selective storage — keep ticks for your target universe and recent high-volatility days. Consider cloud or compressed binary formats and index by timestamp for fast seeks.
Validation and walk-forward testing
No matter the data type, always validate on out-of-sample periods and use walk-forward testing. If you develop on 1-minute bars and then test on tick replay, differences reveal execution risk. Reconcile P&L between OHLC and tick simulations to identify where assumptions diverge.
Final thought: match fidelity to strategy. Use tick data when microstructure matters; use OHLC when you need scale and the strategy tolerates intrabar uncertainty. In both cases, simulate realistic costs, slippage and order mechanics in the Indian market to get backtests that guide profitable live trading.