Information-Driven Bars

A team builds a mean-reversion signal on 5-minute time bars, backtests it carefully, and it looks solid: Sharpe 1.8, smooth equity curve. Live, it underperforms badly in the first hour after the open and the last twenty minutes before the close — precisely the periods where a normal day's volume is heaviest. The backtest never singled those windows out for special treatment, because a time bar doesn't know or care how much actually happened inside it. A 9:31am bar during a busy open might contain fifty times the trades, the volume, and the information of a 2:15pm bar on a quiet Tuesday, and the backtest treated both as one observation.

That's the flaw: time bars sample the clock, not the market. Trading activity is wildly uneven across a session — heavy at the open and close, thin midday, spiking around news — so a fixed time grid oversamples the quiet stretches and undersamples the busy ones, exactly backwards from where the interesting information actually is.

Sampling activity instead of clock time

An information-driven bar closes not after a fixed number of minutes but after a fixed amount of something that measures activity: a fixed number of trades (a tick bar), a fixed number of shares traded (a volume bar), or a fixed dollar amount traded (a dollar bar, generally the most robust because it adjusts automatically for price moves that a share-count bar doesn't). The rule is simple to state: keep aggregating trades into the current bar until the running total of the chosen activity measure hits a threshold, then close the bar and start a new one.

The effect is that bars come out more frequent when the market is busy and less frequent when it's quiet — the sampling clock speeds up and slows down with the market itself. This has a statistically useful side effect: returns measured over information-driven bars tend to be closer to independent and identically distributed than returns measured over fixed time bars, because each bar represents roughly the same amount of new information rather than a fixed slice of a clock that doesn't know when information arrives.

Worked example: a volatile open, counted two ways

Take one stock's first ten minutes after the open, split into 1-minute time bars, alongside dollar bars each closing at $2 million traded:

Approach	Bars in first 10 minutes	Bars in a quiet 10-minute midday stretch
1-minute time bars	10	10
$2m dollar bars	34	3

Time bars give the volatile open and the sleepy midday stretch the same weight in the backtest — ten observations each — even though the open carried roughly eleven times as much dollar volume. Dollar bars give the open 34 observations and the quiet stretch 3, in rough proportion to how much actually happened. A statistic like a rolling correlation or a regression coefficient fit across a day of bars is implicitly an average over those bars; on time bars, that average is quietly dominated by whatever the quiet periods look like, since there are proportionally more of them relative to the information they contain — the reverse of what you'd want if the interesting signal lives in the busy periods.

Doing it properly

Pick the threshold — dollars, shares, or ticks per bar — by targeting a rough number of bars per day that matches how often you actually want to re-evaluate the signal, then hold it fixed across the backtest rather than tuning it against the result. A threshold chosen after seeing which one produces the best Sharpe ratio is no longer a sampling choice, it's a hidden parameter fit to the same data the strategy is being tested on.

Recompute any statistic that assumed evenly spaced time (autocorrelation, rolling windows measured "per bar") with the understanding that a bar no longer corresponds to a fixed duration, so a 20-bar rolling window covers a different amount of clock time on a busy day than a quiet one — usually the point, but it needs to be a deliberate choice, not a surprise discovered in production. Also be careful with labels and holding periods defined in calendar time — a strategy that exits "one hour after entry" needs that hour translated back into clock time even when its entries and signals are computed on information-driven bars, since the two clocks run at different speeds and mixing them silently reintroduces the exact unevenness the bars were built to remove. Finally, remember that information-driven bars change the unit the rest of the pipeline consumes, so any downstream component built assuming a fixed bar frequency — a risk check that expects one update per minute, a data pipeline sized around a known bar count — needs to be re-checked, not just the signal itself.