Tick Data vs OHLCV Bars: Choosing the Right Futures Data

Two views of the same trading activity

A trade record describes an executed transaction at a point in time. An OHLCV bar summarizes a collection of those transactions over an interval. The bar’s open, high, low, and close describe traded prices; volume sums contracts traded. Compression makes the series easier to store and analyze, but it discards ordering and variation inside the interval.

The choice is therefore about information retained, not sophistication. A daily breakout system gains little from replaying every trade if its orders are evaluated after the session close. A strategy that exits seconds after entry cannot be reconstructed reliably from daily bars. Start with the decision timeline, then choose the coarsest representation that preserves the decisions being tested.

Both forms can contain the same market events while supporting different conclusions. If a five-minute bar rises from 5,000 to 5,010, its range alone does not reveal whether price first fell to 4,995 or moved directly upward. That path may be irrelevant to one model and decisive to another.

What a futures trade record contains

In the per-contract derived tick datasets, each record has a UTC ts, a float64 price, and uint32 trade volume. The recv_time equals ts, while event_time is null. These conventions should be handled as dataset properties, not assumed to be universal tick-schema rules.

The bid_sz and ask_sz fields are executed volume at the bid and ask. They describe the side on which trades executed; they are not resting bid or offer sizes. Consequently, they cannot reconstruct queue depth, available liquidity, or an order book. Open interest is unavailable and oi is zero, rather than an observation that open interest vanished.

Multiple trades can share a timestamp, and timestamps alone need not establish their original sequence. Prices may repeat while volume changes. Before aggregating, sort deterministically where required and avoid deduplicating on timestamp and price unless the documentation explicitly supports that rule.

The data documentation defines these fields and the continuous-series additions. Continuous ticks include price_raw and back_adjustment, where price = price_raw + back_adjustment. Know which price a strategy consumes before comparing ticks with bars.

How OHLCV aggregation changes information

For a non-empty bucket, the open is the first trade price, the close is the last, and high and low bound all trade prices. Volume is the sum of trade volume, while trade_count counts records. Two bars with identical OHLCV values can therefore have very different activity: one may contain many small trades and another a few large ones.

Aggregation also creates ordering ambiguity. If a long position has a stop at 4,995 and a target at 5,005, and both appear within one bar, OHLCV cannot say which was reached first. Selecting the target because it produces a favorable result introduces look-ahead at the path level. Use finer data, apply a conservative rule, or exclude the ambiguous outcome through a declared policy.

An omitted bucket means there were no trades to aggregate; it is not automatically an error. Do not manufacture zero-volume bars unless your model requires a regular calendar. If you do insert them, distinguish structural gaps from actual observations and avoid assigning an invented close to a tradable event.

Bid, ask, execution, and quotes

Executed-at-bid and executed-at-ask volume can help classify trade flow, but execution fields are not quotations. A trade at the bid does not reveal how many contracts remained available there, how long the price had been quoted, or whether your order would have joined a queue. Trade-side fields should not be renamed as book sizes in analysis code.

This distinction matters for fills. A tick backtest can use subsequent trades as evidence that prices traded, but it still needs assumptions for latency, order type, partial fills, and slippage. It cannot infer market impact merely from historical executed volume. Bars require even stronger assumptions because they contain no event sequence within the interval.

Volume and trade_count answer different questions. Volume measures contracts traded; trade count measures the number of trade records. Average trade size can be approximated as volume divided by trade count where the denominator is positive. None of these fields is a direct measure of resting liquidity.

Match resolution to the strategy

Choose resolution from signal frequency and execution sensitivity. Daily bars suit slow positioning, contract-level research, and long samples with modest computational cost. Hourly or thirty-minute bars can support intraday models whose decisions occur at completed intervals. Five-minute and one-minute bars preserve more path information while remaining manageable across many markets.

Ten-second bars help when entries and exits occur within minutes, but they still hide ordering inside ten seconds. Ticks are warranted when the signal depends on trade flow, when stops and targets are tightly spaced, or when the exact event path materially changes the result. Using ticks for a monthly signal usually adds processing burden without improving the hypothesis.

Test the decision rather than following a fixed rule of thumb. Run the strategy at two or more defensible resolutions and compare ambiguous trades, not just returns. A large change under finer resolution reveals an execution assumption that deserves attention. Stability does not prove correctness, but instability identifies where bar compression is consequential.

For a broader research workflow, see the guide to backtesting with historical futures data, including contract selection, validation, and chronological testing.

Understand bar boundaries and sessions

An interval label is meaningful only with an alignment rule. These derived bars use epoch-aligned UTC boundaries for 10s, 1m, 2m, 5m, 30m, 1h, and 4h intervals. Daily bars instead follow the Chicago 17:00 trading session, including daylight-saving changes. Thus a daily bar should not be assumed to align with a UTC midnight or a local calendar date.

Bars are derived from back-adjusted continuous ticks and contain ts, open, high, low, close, volume, and trade_count. The adjustment used in ticks carries into the summary. Negative adjusted prices can be valid, so checks should focus on OHLC relationships rather than requiring every price to exceed zero.

Before joining bars from different intervals, inspect their timestamps and coverage. Do not close a five-minute signal using an unfinished one-hour bar, and do not assign a daily session’s information to an earlier session. Empty intervals are omitted, which preserves the distinction between no trades and a recorded zero.

A concrete overnight example

Consider a rule that buys at the Chicago 17:00 session reopen, places a target 20 points above entry, and places a stop 10 points below. The first completed one-hour bar contains both exits:

interval          open     high     low      close
17:00–18:00       5000     5025     4988     5012
target            5020
stop              4990

The bar gives no defensible answer about which level was reached first.

Resolve the exit sequence

1. Identify every interval containing either exit level.
2. Move to finer bars only for those ambiguous intervals.
3. Keep the same entry, cost, and tie-breaking assumptions at each step.

One-minute bars may resolve the sequence: suppose the 17:08 bar reaches 4,990 while later bars first reach 5,020 at 17:31. Under the stated stop and entry assumptions, the stop precedes the target. If either level is touched inside the 17:08 bar itself, the ambiguity remains at that finer scale and ticks may be needed.

Now consider an overnight strategy that enters only after the daily close and exits at the next daily open. The same intrabar path cannot alter those decision times, provided the execution model is otherwise sound. Daily bars are then sufficient for signal reconstruction. The difference is not the market being traded; it is whether unresolved path information changes an order.

In both cases, apply session-aware labels and account for contract rolls. An adjusted gap at a roll is not automatically an executable overnight return, and an empty interval around a closure is not an invitation to synthesize trading activity.

Plan storage, validation, and performance

Ticks require more rows, more memory, and more careful grouping than bars. Process only needed columns and periods, aggregate once for repeated experiments, and retain deterministic alignment rules. Bars reduce computational cost but do not remove the need to inspect underlying events when results depend on intrabar execution.

A compact validation suite should check:

• High at least as large as open, close, and low, with low no greater than those prices.
• Monotonic timestamps, nonnegative volume and trade count, and expected session boundaries.
• Aggregate volume and record counts against source ticks on sample intervals.
• The raw-price plus adjustment identity for continuous ticks.

Performance work should preserve semantics. Downcasting timestamps or prices can alter boundaries and calculations; filling omitted buckets can change indicators; sorting by timestamp without considering equal-time trades can change an open or close. Optimize only after tests establish the expected output on small examples.

When tick detail does—and does not—matter

Tick detail matters when a model consumes individual trades, events within seconds drive decisions, or finer sequencing resolves competing exits. It also helps researchers measure how sensitive a proposed fill is to event order. Even then, historical trades do not supply queue position or guarantee a fill.

Tick detail usually does not matter for completed-bar signals with widely separated exits, slow portfolio allocation, or exploratory feature research at daily frequency. Well-constructed bars preserve the prices and activity those models need while making broader tests practical. Additional granularity can even encourage overfitting by multiplying arbitrary microstructure parameters.

The practical standard is sufficiency: retain the least detailed data that can reconstruct every signal and order decision without guessing. Document the remaining ambiguity, run sensitivity checks where it matters, and treat historical execution as an assumption-laden model rather than a promise of future results.