What Is OHLCV Data and How to Use It for Trading

OHLCV is the universal format of financial market data. Every charting platform, every backtesting framework, every trading API speaks it. Understanding exactly what it represents — and what it hides — is foundational for anyone building algo trading systems.

How a Candle Is Constructed

A candle aggregates all trades in a fixed time window:

• Open: price of the first trade
• High: maximum price across all trades
• Low: minimum price across all trades
• Close: price of the last trade
• Volume: sum of quantities

Aggregating OHLCV from Tick Data in Python

import polars as pl

ticks = pl.read_parquet("ETH_trades.parquet").with_columns(
    pl.from_epoch("time", time_unit="ms").alias("dt")
)

ohlcv_1h = (
    ticks.group_by_dynamic("dt", every="1h")
    .agg([
        pl.col("price").first().alias("open"),
        pl.col("price").max().alias("high"),
        pl.col("price").min().alias("low"),
        pl.col("price").last().alias("close"),
        pl.col("qty").sum().alias("volume"),
    ])
    .sort("dt")
)
print(ohlcv_1h.head())

Common Mistakes

• Treating close as execution price: use the open of the next candle instead
• Ignoring gaps: missing candles must be documented, not assumed continuous
• Mixing timeframes incorrectly: always aggregate from the same tick source

Which timeframe should you use?

OHLCV vs tick data: when OHLCV is enough

OHLCV is enough when your rules fire on candle closes (moving averages, RSI, daily rebalancing). It is not enough when the result depends on what happened inside the candle: whether the stop or the target was hit first, how a limit order would have filled, or how much slippage a market order would have paid. For those questions you need trade-level data; see tick data vs OHLCV.

Five checks before you trust an OHLCV file

1. Missing candles (gaps) in the expected time grid.
2. Duplicate timestamps.
3. Timezone: use UTC end to end.
4. Volume units: base asset or quote currency.
5. Impossible candles (high below open/close, low above open/close).

import pandas as pd
df = pd.read_csv("btcusdt_1h.csv", parse_dates=["timestamp"]).set_index("timestamp").sort_index()
full = pd.date_range(df.index.min(), df.index.max(), freq="1h", tz=df.index.tz)
print("missing candles:", len(full.difference(df.index)))
print("duplicates:", df.index.duplicated().sum())
bad = df[(df.high < df[["open","close"]].max(axis=1)) | (df.low > df[["open","close"]].min(axis=1))]
print("invalid candles:", len(bad))

Where to get clean OHLCV

The Glitch List publishes a free OHLCV Bundle (7 coins) in six timeframes for several major pairs. Every pack ships with an integrity declaration that lists its own known gaps, so you know what you are backtesting on. If you need trade-level precision, the same catalog includes tick-level datasets. If you already have trade logs, the Backtest CSV Auditor checks them for overfitting and data-quality problems.

Browse the full dataset catalog

FAQ

What does OHLCV stand for?

Open, High, Low, Close and Volume: the first and last trade price, the highest and lowest price, and the total traded quantity for one fixed time interval (a candle).

What is the difference between OHLCV and tick data?

OHLCV compresses all trades inside an interval into five numbers. Tick data keeps every individual trade with its timestamp, price, size and side, so it preserves the order of events that OHLCV hides.

Which OHLCV timeframe is best for backtesting?

Use the timeframe your strategy actually decides on: 1m to 15m for intraday systems, 1h to 4h for swing systems and 1d for slow portfolio rules. Lower timeframes give more rows and more noise, and make gaps and timestamp errors matter more.

How do I check an OHLCV file for errors?

Look for missing candles, duplicate timestamps, timezone mistakes, mixed volume units (base vs quote) and impossible candles where the high is below the open or close. A short pandas script catches all of these in seconds.

Summary

OHLCV data is a compressed representation of market activity. That compression is useful — but it destroys information. Knowing what was lost, and when that matters, separates a robust backtesting setup from one that produces results you cannot trust in production.