OHLCV Data Quality Checks: What to Validate Before Backtesting or Trading

Most backtests do not fail because of the model. They fail because of the data.

If your OHLCV feed is incomplete, inconsistent, or retrospectively altered, a profitable strategy may be nothing more than a well-formatted illusion.

What OHLCV Data Quality Means

OHLCV represents Open, High, Low, Close, and Volume for a defined market interval. It is the base layer for charting, indicator calculation, backtesting, execution logic, and performance attribution.

OHLCV data quality means those records are reliable across time, price, volume, instrument coverage, and market history. This is not merely a data-engineering concern. It changes capital allocation decisions.

A trading system treats market data like an industrial control system treats sensor input. Bad input makes good logic dangerous.

What Most Teams Get Wrong

Most teams build indicators first and validate data later. That sequence is backwards.

Cleaning data after inspecting a strong backtest creates room for selection bias. You can quietly retain the observations that flatter the strategy.

Data quality is not a preprocessing task. It is part of strategy architecture.

A dataset can appear complete while containing missing bars, duplicate timestamps, impossible prices, inconsistent volume units, timezone errors, delisted symbols, or unadjusted corporate actions.

A Six-Layer Validation Framework

Use six distinct layers to assess OHLCV data. Each layer addresses a different failure mode.

1. Structural Integrity

Every record needs a valid timestamp, open, high, low, close, and volume value. The fields must also have usable types: timestamps must map to a standard time basis, while prices and volume must be numeric.

• Identify missing, NaN, infinite, and malformed values.
• Detect duplicate records by instrument, timeframe, and timestamp.
• Verify chronological ordering and expected interval spacing.
• Document whether each timestamp marks candle open or candle close.

A duplicate timestamp can generate a duplicate signal. In a live system, that can become a duplicate order.

2. Price Validity Inside Each Candle

Each candle must satisfy basic price constraints. These checks are simple, but skipping them is expensive.

These rules do not prove the data is correct. They remove data that is obviously wrong.

3. Temporal Continuity

One-minute data should contain a bar for every expected minute. The exception is a closed market, a scheduled halt, or an instrument that did not trade.

A gap is not always an error. Equity markets have trading sessions and holidays. Crypto markets trade continuously, so a multi-hour gap deserves immediate scrutiny.

• Attach an exchange calendar to the validation pipeline.
• Classify gaps as short, material, or critical.
• Record the reason and handling policy for every gap class.
• Never forward-fill a missing candle without documenting why.

Blind gap filling creates artificial liquidity and volatility. That can make a mean-reversion strategy look safer than it is.

4. Volume and Liquidity Consistency

Zero volume is not automatically bad data. It may be operationally real for an illiquid instrument or a specific market structure.

Zero volume with price movement, or extreme volume without related price behavior, needs investigation. The cause may be aggregation rules, unit mismatches, or feed defects.

For crypto, establish whether volume is denominated in the base asset or quote currency. A reported volume of 100 BTC is not comparable with 100 USDT.

5. Market Reality Alignment

The dataset must reflect the market’s actual history. Equities can split, pay dividends, change tickers, halt trading, or delist.

Using unadjusted equity prices in a long-horizon strategy can materially distort returns. Yet adjusted prices are not executable prices, which matters for live-trading assumptions.

For crypto, symbol mapping is equally important. BTC/USDT on two exchanges can have different execution quality, liquidity, custody risks, and reported volume.

6. Data Lineage and Reproducibility

Every dataset needs a passport: source, collection time, timezone, adjustment status, pipeline version, and cleaning rules.

Without lineage, you cannot explain why today’s result differs from next month’s result. A research system without lineage cannot be audited.

If you cannot explain where a price came from and how it changed, it is not ready to inform capital decisions.

Pre-Backtest Checklist

Run these checks automatically before every backtest.

1. Normalize all source timestamps to UTC and retain the original timezone.
2. Check for duplicate combinations of symbol, timeframe, and timestamp.
3. Compare candle intervals against the real market calendar.
4. Validate High, Low, Open, and Close relationships across all rows.
5. Reject negative, zero, NaN, and infinite prices, plus negative volume.
6. Flag abnormal volume, abnormal returns, and large price gaps.
7. Identify split and dividend adjustment status for equities.
8. Test the historical universe for survivorship bias.
9. Model transaction costs, spreads, slippage, and feed latency separately.
10. Store a data-quality report with every backtest run.

How One Bad Candle Breaks a Strategy

Consider a five-minute BTC/USDT breakout strategy. A provider publishes one candle with an erroneous high after a feed disruption.

The system interprets it as a resistance break. The backtest enters a trade, books a gain, and may present that point as evidence of alpha.

But the trade never existed in the real market. The model did not discover an edge. It traded a feed error.

Every signal should trace back to source candles and their validation status.

When to Repair Data

Not every issue should be repaired the same way. The correct policy depends on the market, timeframe, and intended use.

What Not to Automate

Some decisions cannot be reduced to a single rule. This is where system design separates itself from a cleaning script.

Filling Every Missing Candle

The fact that a system can create a candle does not mean it should. In intraday data, synthetic bars can damage the market microstructure your model depends on.

Deleting Every Outlier

An extreme move may be a data error. It may also be a liquidation cascade, a major announcement, or a sudden liquidity failure.

Flag it first. Then compare it with a second source, executed trades, or order-book data where available.

Treating One Provider as Absolute Truth

Market data depends on aggregation method, latency, symbol mapping, and adjustment policy. Two reputable sources can disagree on intraday candles.

Operational Reality

Data quality does not end when research begins. It must be monitored in production.

A serious pipeline treats data health as a service metric: missing-bar rate, ingest latency, duplicate count, rejected-record rate, and divergence from a reference source.

• Store raw data unchanged at ingestion.
• Label validation failures instead of erasing history.
• Version every transformation and repair policy.
• Allow research to consume only approved datasets.
• Place a data-quality gate before live order generation.

This architecture costs more. Raw storage, redundancy, and monitoring add complexity. The alternative is discovering data failure after it has influenced a position.

A Short Decision Tree

When a validation rule detects a problem, use this sequence.

• Is it a structural violation? If yes, reject and log the record.
• Does the market calendar explain it? If yes, record it as an expected market condition.
• Does a second source confirm it? If yes, it is more likely a real event.
• Does it affect a signal or execution? If yes, quarantine the dataset or time range.
• Is the repair policy defined and versioned? If not, do not use the data for sensitive research.

Key Takeaways

• OHLCV looks simple, but it embeds source and aggregation decisions.
• High, Low, Open, and Close checks are only the minimum control layer.
• Time, timezone, and the exchange calendar matter as much as price.
• Volume has little meaning without its unit, venue, and source context.
• Raw and adjusted datasets should remain separate.
• Every data repair must be traceable, versioned, and reproducible.
• A backtest without a data-quality report is an incomplete report.

FAQ

What does OHLCV mean?

OHLCV means Open, High, Low, Close, and Volume. These fields describe price behavior and trading activity for an asset during a defined period.

Can I use free OHLCV data for a backtest?

Yes, but only after validation. Cost is not the central issue; historical coverage, aggregation rules, latency, adjustment policy, and reproducibility matter more.

Should missing OHLCV candles be filled?

Not by default. First determine whether the market was open, whether the instrument was tradable, and why the gap occurred. Any synthetic candle should be explicitly labeled.

What is the difference between adjusted and raw OHLCV data?

Raw data preserves reported market prices. Adjusted data changes historical values for events such as stock splits and dividends, making longer-term return analysis more consistent.

Why are timestamps important in OHLCV data?

Signals are time-dependent. A timezone mismatch, a wrong candle-boundary convention, or duplicate timestamps can change backtest entries and exits.

Does zero volume always mean bad data?

No. Zero volume can be real in illiquid instruments or specific market conditions. It should be evaluated alongside price behavior, venue rules, and source methodology.

A good model cannot rescue bad data. It only executes the failure with greater confidence.

Sources [1] Clean OHLCV Data https://bitpredict.ai/resources/notebooks/clean_ohlcv_data [2] Complete Guide to OHLCV Data Cleaning in Big Data Pipelines https://narimani.me/post/14?lang=en [3] OHLCV Data Explained: Real-Time Updates ... - CoinAPI.io Blog https://www.coinapi.io/blog/ohlcv-data-explained-real-time-updates-websocket-behavior-and-trading-applications [4] ResearchRL/diffquant-data · Datasets at Hugging Face https://huggingface.co/datasets/ResearchRL/diffquant-data [5] Why Your Crypto Bot Keeps Failing: The Data Quality Problem (And How to Fix It) https://dev.to/paarthurnax_3f967358857ce/why-your-crypto-bot-keeps-failing-the-data-quality-problem-and-how-to-fix-it-a25 [6] Global Stocks OHLCV data | Real-time , Delayed, End-of-day https://finnhub.io/docs/api/stock-candles [7] OHLCV https://lib.rs/crates/ohlcv [8] REST API for Historical OHLCV & Trade Data - CryptoDataDownload https://www.cryptodatadownload.com/api/ [9] OHLCV Reader/Writer | PyneCore Documentation https://pynecore.org/docs/advanced/ohlcv-reader-writer/ [10] OHLCV Data | Hyperliquid API Docs https://www.dwellir.com/docs/hyperliquid/hyperliquid-index/ohlcv-data [11] Futures historical data https://docs.kraken.com/exchange/guides/general/historical-data [12] Binance fetch_ohlcv outputs same timestamp on different ... https://github.com/ccxt/ccxt/issues/25610 [13] Wrigggy/crypto-ohlcv-1m · Datasets at Hugging Face https://huggingface.co/datasets/Wrigggy/crypto-ohlcv-1m [14] OHLCV - Meteora Documentation https://docs.meteora.ag/api-reference/damm-v2/pools/ohlcv [15] Historical Data API - OHLCV Time Series Data https://api-docs.indstocks.com/historicalData/