Crypto Data Quality Checklist

Most articles about crypto data quality start with a list of checks.

Check for missing candles.

Check for duplicate trades.

Check timestamps.

It's good advice.

But it misses the bigger problem.

The quality of your market data doesn't just affect the accuracy of your charts. It shapes every decision built on top of that data… your backtests, execution models, trading signals, research, dashboards, and even the models you train.

If the underlying data is wrong, everything that follows becomes less reliable. This is especially true in cryptocurrency markets.

Unlike traditional finance, there is no single exchange, no universal symbol format, and no standard way to publish market data. Every exchange has its own APIs, naming conventions, timestamps, precision rules, and maintenance schedules. The same asset may trade simultaneously on dozens of venues, each producing slightly different market events.

That's why crypto data quality isn't simply about collecting more data. It's about understanding whether the data you're using accurately represents what happened in the market.

Let’s walk through a practical checklist that data engineers, quantitative researchers, and trading teams can use before trusting an exchange feed. Along the way, we'll show how normalized metadata, tick-level trades, quotes, order books, and OHLCV data make these validation steps much easier.

Why Crypto Data Quality Matters More Than Most People Think

Imagine two research teams building the exact same trading strategy.

They use the same indicators.

The same parameters.

The same exchange.

The same date range.

Yet one strategy reports a 24% annual return while the other barely breaks even.

Did one team build a better model?

Not necessarily.

Often, the difference comes from the market data itself.

Small inconsistencies accumulate over thousands of market events. A handful of missing candles can change a moving average crossover. Duplicate trades can inflate volume-based indicators. A stale order book can make simulated executions look far better than what would have happened in live markets.

The strategy hasn't changed.

The data has.

That is why professional trading firms spend as much time validating market data as they do developing trading models.

The Hidden Cost of Bad Data

Not every data issue causes obvious failures. Many produce subtle errors that quietly influence research results.

The dangerous part is that most of these issues don't generate errors.

Your code still runs.

Your charts still look reasonable.

Your backtest still produces a result.

It's only later, often after deployment, that the difference between the simulation and reality becomes obvious.

A Good Backtest Starts Before the First Trade

Many developers think of data validation as something that happens after downloading historical data.

In reality, it starts much earlier. Before loading a single trade or candle, you should answer a simple question:

Am I looking at the right market?

That sounds obvious, but it's surprisingly easy to get wrong.

Crypto markets are fragmented across hundreds of exchanges. Assets can share ticker symbols. Instruments can have similar names while representing completely different products.

For example, "BTCUSDT" might refer to:

• A spot market
• A perpetual futures contract
• A quarterly futures contract
• An options market

All of them involve Bitcoin.

None of them behave the same way.

Running a spot strategy on perpetual futures data or mixing multiple instrument types in one dataset can completely invalidate your conclusions. This is why metadata deserves much more attention than it usually gets.

Step 1: Validate Exchange and Symbol Coverage

One of the simplest ways to improve crypto data quality is to validate metadata before requesting historical market data.

Metadata answers questions that raw trades or candles cannot.

• Does this exchange actually provide historical trades for the period I'm testing?
• Was this symbol already listed?
• Is this a spot market or a perpetual contract?
• Has the symbol been delisted?
• Am I using the exchange's native identifier or a normalized one?

These checks take seconds, yet they eliminate many of the mistakes that later appear as "bad market data."

CoinAPI exposes standardized metadata for exchanges, assets, and symbols, allowing developers to verify data availability before downloading large historical datasets. Rather than relying on inconsistent exchange-specific identifiers, markets are represented using a normalized symbol_id format that includes the exchange, market type, base asset, and quote asset. This makes it much easier to compare markets consistently across more than 400 exchanges.

A Practical Metadata Checklist

Before starting a backtest, confirm:

Skipping this step often leads developers to chase imaginary data quality issues that are actually metadata issues.

Step 2: Don't Assume Missing Candles Mean Bad Data

One of the most common complaints in crypto is:

"Your API has missing candles."

Sometimes that's true.

Often, it isn't.

A missing candle doesn't automatically mean data has been lost. It simply means there was no aggregated bar for that period. The reason behind that gap is what matters.

For highly liquid pairs like BTC/USDT, a missing one-minute candle is unusual and deserves investigation.

For a thinly traded altcoin, however, it's entirely possible that no trades occurred during that minute. In that case, no OHLCV candle should exist because there was nothing to aggregate.

The same visual gap on a chart can represent very different situations.

This distinction matters because each scenario requires a different response.

If an exchange was under maintenance, the gap reflects reality.

If a symbol didn't exist yet, there is nothing to recover.

If no trades occurred, artificially inserting candles may introduce information that never existed in the market.

Instead of asking "Are candles missing?", ask a better question:

"Why are they missing?"

That answer usually comes from combining OHLCV with other datasets not from looking at candles alone.

CoinAPI's OHLCV data includes fields such as trades_count, volume_traded, time_open, and time_close, making it easier to distinguish between inactive trading periods and genuine data problems. Combined with exchange and symbol metadata, developers can determine whether a gap reflects market behavior, listing history, or an operational event rather than assuming the feed is incomplete.

A Simple Candle Validation Checklist

Before trusting an OHLCV dataset, verify that:

• Candle timestamps progress continuously according to the selected interval.
• Period boundaries match the requested granularity.
• price_high is never lower than the open, close, or low.
• price_low is never higher than the open, close, or high.
• volume_traded and trades_count are internally consistent.
• Any gaps can be explained by listing dates, exchange maintenance, or genuine market inactivity not by assumptions.

One final recommendation: don't rely on OHLCV data alone.

When a gap looks suspicious, compare it against the underlying trade stream. If trades exist but no candle was produced, you've likely found a genuine aggregation issue. If neither trades nor candles exist, the market itself may simply have been inactive.

That distinction can save hours of unnecessary debugging and prevent much bigger mistakes later in your research.

Step 3: Detect Duplicate Trades Before They Distort Your Results

At first glance, duplicate trades seem easy to identify.

If two trades have the same timestamp, price, and size, surely one of them must be a duplicate.

Not necessarily.

Large exchanges can execute multiple legitimate trades at exactly the same price within the same millisecond. In highly liquid markets, it's common to see several trades with identical prices, sizes, and timestamps, especially when a large market order matches against multiple resting orders.

Deleting these "duplicates" can actually remove real market activity.

Instead, professional data teams rely on unique trade identifiers whenever they're available.

CoinAPI trade data includes fields such as uuid, time_exchange, time_coinapi, price, size, and, for some exchanges, native trade identifiers. These make it possible to distinguish true duplicate events from legitimate high-frequency trading activity.

What Should You Validate?

One useful habit is to periodically rebuild a handful of candles directly from raw trades. If the reconstructed candle differs significantly from the published OHLCV data, it's worth investigating whether the issue comes from missing trades, duplicate events, or aggregation logic.

Step 4: Compare Exchange Time with Ingestion Time

Every market event has a timeline.

A trade happens on the exchange.

The exchange timestamps it.

The data provider receives it.

The event reaches your application.

Those moments are not identical.

Many developers only look at one timestamp, but that only tells half the story.

CoinAPI exposes both:

• time_exchange – when the event occurred or was timestamped by the exchange.
• time_coinapi – when CoinAPI received and processed the event.

The difference between these timestamps provides a simple but powerful way to monitor feed health.

A small difference is expected.

A sudden increase may indicate:

• exchange congestion
• network issues
• delayed market data
• temporary infrastructure problems

More importantly, comparing timestamps helps identify events arriving out of sequence. A backtest that processes trades in the wrong order can produce execution results that never could have happened in reality.

Timestamp Validation Checklist

• Events should appear in chronological order.
• Timestamp differences should remain reasonably consistent.
• Watch for sudden latency spikes.
• Flag events with timestamps in the future.
• Investigate large jumps between consecutive events.

You don't necessarily need to define a universal "acceptable" latency threshold… different exchanges behave differently. What matters is detecting unusual changes within the same feed over time.

Step 5: A Beautiful Order Book Can Still Be Wrong

Many trading strategies don't execute at the last traded price.

They execute against the order book.

That makes quote and order book quality just as important as trade quality.

Imagine a backtest that assumes you can buy 20 BTC at the displayed ask price.

If that order book snapshot was already several seconds old, the liquidity may have disappeared before your simulated order arrived.

Your strategy looks profitable.

Real trading tells a different story.

This is why stale order books are one of the most expensive hidden problems in quantitative research.

CoinAPI provides normalized Level 1, Level 2, and Level 3 market data, allowing teams to validate both top-of-book quotes and deeper liquidity depending on their execution model.

Quote and Order Book Health Checks

One important nuance: a crossed or locked order book isn't always bad data. Some exchanges briefly publish these states during rapid market updates. The key is to detect patterns, not isolated events.

Step 6: Can You Rebuild the Market From Raw Trades?

This is one of the simplest and most powerful tests you can perform.

Instead of trusting aggregated OHLCV data blindly, try rebuilding a sample of candles yourself.

Every candle is simply a summary of individual trades.

f your reconstructed candle closely matches the published one, that's a strong signal that the underlying trade data and aggregation logic are consistent.

If it doesn't, you've learned something valuable before trusting months… or years of historical data.

CoinAPI uses the same normalized symbol_id across trades and OHLCV datasets, making this kind of reconciliation significantly easier than stitching together exchange-specific datasets manually.

Step 7: Validate Precision Before Simulating Execution

This check is often forgotten because it doesn't affect charts.

It affects execution.

Every exchange defines its own rules for price increments and minimum order sizes.

A simulator that buys 0.00000017 BTC may produce excellent backtest results...

...even though that order could never have been submitted to the exchange.

Likewise, prices rounded to invalid tick sizes can create fills that are impossible in live trading.

CoinAPI symbol metadata includes price and size precision, allowing trading systems to validate order parameters before simulation or execution.

Before running a strategy, confirm that:

• Prices respect the market's tick size.
• Order sizes match the exchange's allowed precision.
• Position sizing logic cannot generate impossible orders.
• Different exchanges are not assumed to use identical precision rules.

Small details like these rarely change a chart… but they can dramatically change whether a strategy survives contact with a real exchange.

Step 8: Learn to Tell the Difference Between Missing Data and Missing Markets

One of the biggest mistakes in crypto research is treating every gap as a data quality problem.

Sometimes the feed is broken.

Sometimes the market simply wasn't there.

An exchange may pause trading for scheduled maintenance.

A symbol may have been delisted.

A newly launched market may not yet have existed during your test period.

These situations require different conclusions.

Professional teams always combine market data with metadata and operational information before concluding that data is missing.

That extra step prevents countless false alarms and saves hours of debugging.

The Crypto Data Quality Checklist

Before trusting an exchange feed, ask yourself these questions:

No single validation guarantees perfect data quality.

Together, however, these checks dramatically reduce the risk of building research, trading systems, or analytics on unreliable market data.

Why Normalized Market Data Makes Validation Easier

None of these validation steps are particularly difficult.

The challenge is performing them consistently across hundreds of exchanges that all expose different APIs, symbol formats, timestamps, and data structures.

That's where normalization becomes valuable.

CoinAPI's Market Data API provides real-time and historical trades, quotes, order books, OHLCV data, and standardized metadata through a single, consistent schema. Instead of maintaining exchange-specific validation logic, developers can build one repeatable workflow that works across more than 400 exchanges. Features such as normalized symbol_id values, exchange and symbol metadata, precision fields, and both time_exchange and time_coinapi timestamps help simplify many of the quality checks discussed in this guide.

Whether you're building a quantitative trading strategy, evaluating market microstructure, training AI models, or powering production trading systems, validating your data should be the first step… not the last.

Build Your Crypto Data Quality Pipeline with CoinAPI

Every validation step in this checklist becomes easier when your market data follows a consistent schema.

CoinAPI's Market Data API provides normalized trades, quotes, OHLCV data, order books, and metadata across 400+ cryptocurrency exchanges, making it easier to validate historical datasets, monitor real-time feeds, and build repeatable data quality workflows without maintaining exchange-specific integrations.

Whether you're backtesting quantitative strategies, developing trading infrastructure, building AI models, or running market analytics, high-quality data is the foundation everything else depends on.

Explore CoinAPI's Market Data API and start building more reliable trading systems with normalized, real-time and historical cryptocurrency market data.

Related Topics

• What Is Level 4 (L4) Order Book Data?
• CoinAPI Introduces Hyperliquid L4 Data
• Tracking the Whales: Using Hyperliquid L4 Wallet Data for an Edge
• Building a Reproducible Hyperliquid Order Book Replay from CoinAPI Book L4 Flat Files
• What Data Is Available Through CoinAPI WebSocket DS for Hyperliquid?
• Demystifying Level 4 (L4) Order Book Data: Why Waiting for Block Confirmations Is Dead on Arrival