Tick data won't save your backtest — for most strategies it makes things worse

The standard advice is: if you want an honest backtest, get tick data. I think that advice is wrong for most strategies, and following it usually makes the backtest worse, not better. Not because tick data is inaccurate — it's the most accurate thing you can get — but because the way most people use it substitutes resolution for rigor, and the two are not the same thing.

Here's the failure mode. A researcher builds a strategy on 1-minute bars, gets a Sharpe they like, and someone — a mentor, a forum post, their own nagging doubt — tells them the backtest is dishonest because it's built on bars. So they rebuild the whole pipeline on tick data: every trade, every quote update, timestamped to the microsecond. The backtest gets slower, the code gets three times more complex, and the Sharpe... barely moves, or moves in a direction nobody can explain. They ship it anyway, because tick data feels more rigorous, and rigor-feeling is not the same as rigor.

What tick resolution actually buys you

Tick data tells you the sequence and price of every trade and (if you pay for it) every order book update. That's real information. It lets you reconstruct queue position, estimate fill probability at a given price level, and see adverse selection — whether the market moves against you right after your hypothetical fill. All of that matters enormously if your holding period is measured in seconds and your edge is measured in fractions of a tick.

But most strategies we see at Stratmill — and most strategies retail and semi-pro researchers actually run — hold positions for minutes to days. At that horizon, the thing that determines whether your backtest is honest isn't whether you modeled the 40th trade inside a given minute. It's whether you modeled the spread, the funding rate, the slippage curve, and the fact that your limit order sits behind other people's orders in the queue. You can get all four of those wrong on tick data and all four right on 1-minute bars. Resolution and honesty are orthogonal.

That last number is the one people underweight. A tick-level backtest isn't just "the same backtest with more rows." Trades on most exchanges arrive out of order relative to your ingestion timestamp, get retroactively corrected, get split across multiple matching engine shards, and — on several venues we've ingested from — occasionally duplicate or drop entirely during a reconnect. Building a tick pipeline that's actually more correct than a well-built bar pipeline, rather than just more granular, is a real systems project. Most teams don't do that project. They point a backtester at a vendor's tick file and call it done, which means they've swapped a known, documented set of approximations (OHLCV) for an unknown, undocumented set (whatever the vendor's tick reconciliation logic happens to do on a bad day).

The noise you're buying

There's a second cost that's less about engineering and more about statistics. Individual trade prints bounce between the bid and the ask — that's the bid-ask bounce, and it's been a known artifact in market microstructure literature since the 1980s. If your signal operates on anything faster than a few seconds, tick-level backtesting can make you see structure in what is actually just the bounce. I've watched a researcher find a beautiful mean-reversion pattern on trade-by-trade data that evaporated the instant they aggregated to even 5-second bars, because the pattern was the bounce.

A quant I know — ex-market-making, now running a small crypto book — put it to me this way: "Tick data is a magnifying glass. If you point it at your edge, great. If you point it at your noise, you'll spend six months modeling your noise beautifully." He now backtests almost everything on 1-second or 1-minute bars and only drops to tick data for the specific question of "would this limit order have actually filled," which is a fill-probability question, not a signal question.

That split is the right instinct, and it's the one most tick-data advocates skip. The honest use of tick data isn't running your whole strategy on it — it's using it surgically, for the one or two questions bar data genuinely can't answer.

When the critics are right

All of that said, there are strategies where tick data isn't optional, and I'd be overstating the case to pretend otherwise. If you're running anything that looks like market making — quoting both sides, managing inventory tick by tick, caring about your position in the queue at a specific price level — bar data can't represent your problem at all. The entire economics of that strategy live inside the minute, not across minutes. Same for latency-sensitive statistical arbitrage between venues, where the question is literally "which trade happened first," and for options market making around large size, where a few hundred milliseconds of adverse selection after a print is the whole game. In those regimes, backtesting on bars isn't a simplification, it's a category error — you're not testing a lower-resolution version of your strategy, you're testing a different strategy that happens to share a name with the real one.

So the claim isn't "tick data is bad." It's that reaching for it is often a way of avoiding a harder, less glamorous question: is my cost model right? Is my fill assumption right? Would this order have actually been filled, or am I assuming a fill at a price the book never really offered me? Those questions are answerable on 1-minute or even 1-second bars if you're honest about queue position and spread. Tick data makes them answerable with more precision, at several times the engineering cost, for strategies where that extra precision changes nothing about the conclusion. Spend the extra effort where the horizon actually demands it, and skip it everywhere else — that's a better use of a research team's time than defaulting to the finest-grained data available because finer feels more rigorous.