Historical Tick Data for Backtesting: The Complete Guide
How to source, clean and use historical tick data for backtesting futures strategies — resolution, survivorship, weekend gaps and the mistakes that make backtests lie.
A backtest is a promise your strategy makes about the future, written in the past tense. Whether that promise is worth anything comes down, more than any other single factor, to the quality of the historical tick data underneath it. Garbage in, confident garbage out — and confident garbage is the most expensive kind, because it gets traded.
This is a practical guide to sourcing and using tick data for backtesting futures strategies, with a bias toward the failure modes that quietly inflate results.
Related: CME market data pricing 2026 · CME data feed providers compared.
What “tick data” actually means
A tick is a single market event: most often a trade, sometimes a quote change. Each trade tick carries price, size, a timestamp, and ideally the aggressor side — whether the trade hit the bid or lifted the offer. That last field is gold for any order-flow or microstructure work, and a surprising number of “tick” datasets omit it or fake it.
Tick data sits at the top of a resolution hierarchy:
| Resolution | Example | Good for |
|---|---|---|
| Daily bars | OHLCV per day | Long-horizon, position trading |
| Minute bars | OHLCV per minute | Swing, some intraday |
| Tick (trades) | Every print | Intraday, execution modeling |
| Full order book (L2) | Every book update | Microstructure, market making |
The rule of thumb: you can always downsample, never upsample. Aggregating ticks into minute bars is one line of code; recovering the intrabar path from a minute bar is impossible. When storage is cheap and you’re unsure, store the ticks.
Why bars lie to intraday strategies
Say your strategy enters when price crosses a level, with a stop a few ticks away. On a 5-minute bar, all you see is open, high, low, close. Did price hit your entry before or after it hit your stop? The bar can’t tell you. Backtest engines paper over this with assumptions — and those assumptions are where fantasy P&L is born.
We have seen this firsthand. An opening-range breakout strategy looked clearly profitable on bar data. Rebuilt on ticks, with fills modeled at the actual price path, the edge evaporated: the bar-based engine had been booking fills at level prices that, tick-by-tick, never actually traded the way the model assumed. The strategy was a booking artifact, not an edge. Only tick-resolution data exposed it.
If your strategy’s decisions happen inside a bar — entries, stops, targets at specific prices — you need tick data to test it honestly. Full stop.
The data-quality checklist
Before you trust a dataset, interrogate it:
1. Does it have real aggressor side?
Many feeds infer side with a tick rule (was the trade above or below the previous price?) rather than reporting the true aggressor from the exchange. The inference is wrong often enough to ruin delta and order-flow studies. Confirm whether side is genuine or reconstructed.
2. Are timestamps consistent and high-resolution? One canonical unit, ideally microseconds, applied everywhere. Mixed units across symbols or date ranges silently corrupt every join and every latency calculation. This is the most common, least visible data bug there is.
3. How are contract rolls handled? Futures expire. A continuous series stitches contracts together at roll dates, and how it stitches (back-adjusted, ratio-adjusted, or raw) changes every level-based result. Know which method you have, and whether the roll is volume/OI-driven or a naive calendar roll.
4. Are there corrupt or duplicate records? Weekend and holiday sessions, exchange test messages, and vendor glitches produce malformed rows. We quarantine corrupt weekend files rather than let them poison a study; you should at least detect and exclude them. A few thousand bad ticks in the wrong place can manufacture or destroy an “edge.”
5. Does it span multiple regimes? This is strategic, not technical, but it’s the big one. A dataset covering only a calm, trending year will bless strategies that die the moment volatility regime-shifts. For futures, multi-year coverage that includes trending, choppy, calm and panicked markets is the minimum for any claim of robustness.
Sourcing tick data without selling a kidney
Historically, clean tick data meant either a direct exchange feed (with CME’s own data fees on top) or a specialist vendor charging four figures a month. That’s changed. Developer-focused providers now redistribute normalized, real-time and historical futures data at indie prices, usually exposing history through a simple REST endpoint:
# pull every NQ trade for a session as normalized JSON
curl "https://api.tick-stream.xyz/v1/history/ticks?symbol=NQ&start=2026-06-01&end=2026-06-02" \
-H "Authorization: Bearer sk_live_…"
The thing to look for is the same vendor for live and historical data with identical normalization. If your backtest data and your live feed disagree on timestamp units, aggressor convention, or roll logic, your live results will diverge from your backtest for reasons that have nothing to do with the strategy — and you’ll waste weeks chasing a ghost.
tickstream keeps a multi-year, schema-uniform tick archive (every NQ tick back to 2019, microsecond-stamped, with genuine exchange aggressor side) that’s the same feed it streams live. That continuity — backtest and production drawing from one normalized source — is the unglamorous feature that saves the most debugging.
A sane backtesting workflow
- Pull ticks, not bars, for anything intraday. Store them; downsample on demand.
- Validate the data against the checklist above before you write a single line of strategy code.
- Model fills on the tick path, including spread and a realistic slippage assumption. If a strategy only works with instant, free fills, it doesn’t work.
- Hold out data the strategy has never seen, across a different regime, and only believe results that survive it.
- Reconcile your first live fills against the backtest. Divergence usually means a data-normalization mismatch, not a broken strategy.
The bottom line
Most failed strategies don’t fail because the idea was bad — they fail because the backtest was generous. Bar data hides the intrabar path, inferred aggressor side corrupts order flow, mixed timestamps poison joins, and single-regime samples reward fragility. Tick data, validated and regime-diverse, doesn’t make backtesting easy, but it makes it honest. And honest is the only kind worth doing, because the market grades on a curve you can’t argue with.
Frequently asked questions
What is tick data and why use it for backtesting?
Tick data is the record of every individual trade (and often every quote change) in a market, with price, size, timestamp and aggressor side. It is the highest-resolution data available. Backtesting on tick data — rather than minute or daily bars — lets you model intrabar price path, slippage and fills realistically, which matters enormously for intraday and execution-sensitive strategies.
How much historical tick data do I need?
Enough to span multiple market regimes. A few months can fit a strategy to one environment and tell you nothing about robustness. For futures, aim for several years covering trending, ranging, high- and low-volatility periods. The single most common cause of failed live strategies is a backtest that only saw one regime.
What resolution should backtesting data be?
Use the highest resolution your strategy's decisions require. Daily strategies can use daily bars; intraday and execution strategies need tick or full order-book data. Downsampling from ticks to bars is trivial; the reverse is impossible, so when in doubt store ticks.