OHLCV finality is the state in which an open, high, low, close, and volume candle is considered complete and no longer expected to change.
OHLCV finality is a data quality concept used in market data systems to indicate that a candle has moved from provisional to finalized status. A candle may initially be calculated from trades or quotes received in real time, but its values can change if late-arriving trades, exchange corrections, or backfilled records are processed after the period ends.
A finalized OHLCV candle means the data provider does not expect further changes under normal processing rules. Finality is especially important for historical analytics, backtesting, reporting, and reconciliation workflows where stable values are required.
Finality does not always happen exactly at the period boundary. Depending on the exchange, asset class, data source, and aggregation process, a candle may require a short post-close reconciliation window before it is marked as final.
OHLCV finality helps users understand whether candle data is safe to use for production analytics, trading signals, backtests, and compliance reports. Without finality awareness, systems may treat provisional candles as permanent and later discover discrepancies when corrected or backfilled data becomes available.
For developers, OHLCV finality supports better cache invalidation, data versioning, and downstream reconciliation logic.
OHLCV finality means that the open, high, low, close, and volume values for a specific candle interval have been fully processed and are not expected to change. Before finality, the candle may still be provisional and subject to updates. This distinction helps teams know whether they are viewing a temporary value or a stable historical record. In real-time systems, a candle can appear complete because the time interval has ended, but that does not always mean every relevant market event has been included. Finality gives applications a clearer signal for when to store, compare, or audit the values. It is most useful when a provider exposes or documents when candle data should be treated as final.
OHLCV candles can change after a period closes because market data may arrive late, trades may be corrected, exchange data may be replayed, or a data provider may run a backfill process to improve completeness. These updates can affect price extremes, close values, and volume totals. For example, a late trade with a higher price than the original high would change the high value for that interval. A correction to trade size could also change the volume value. Some markets and exchanges have different reporting behavior, which means finality timing can vary by source. Data pipelines should account for these differences instead of assuming all candles become final immediately.
Developers should distinguish between provisional and final candles, especially in backtesting and reporting workflows. Applications may use recent candles for real-time decisions while periodically refreshing them after the reconciliation window to ensure final historical values are stored. A common approach is to cache live candles briefly, then re-request recent intervals after a delay. Systems that run backtests should use finalized historical data whenever possible so results are reproducible. Reporting tools should also record when data was retrieved and whether the values were considered final at that time. This reduces confusion when comparing stored results against later corrected market data.
A trading application receives a 1-minute BTC/USD candle at 12:01:00 showing a close price of 65,000 and volume of 18 BTC. A few seconds later, late trades for the 12:00:00–12:00:59 interval arrive, increasing the volume to 19.4 BTC and changing the high price. Once those records are processed and the reconciliation window ends, the candle is considered final.
CoinAPI Market Data API provides access to OHLCV and historical market data across many exchanges and assets. Understanding OHLCV finality helps API users decide when to rely on candles for real-time dashboards, backtesting, settlement analysis, and historical data storage.