data_trade_start / data_trade_end
data_trade_start and data_trade_end are symbol metadata timestamps that indicate the earliest and latest times for which trade events are available for a symbol. They define the outer bounds of trade data coverage and are commonly used to constrain historical trades queries and to validate that a symbol has trade data for the period you analyze.
Why It Matters
Trade data often has different availability than quotes or order books. A symbol may have trades coverage without reliable quotes, or trades coverage may start later due to integration. If your analysis relies on trades (volume, realized volatility, execution validation), you should use trade-specific coverage rather than overall data_start/data_end.
How to use these fields?
Typical usage:
- When requesting trades for a period, clip your request to the intersection of your analysis window and [
data_trade_start,data_trade_end]. - Filter out symbols that do not overlap your required period.
- Build point-in-time universes that require trade data to exist as of time t.
Should you use data_trade_end for active markets?
Yes, but treat it as a moving boundary that updates as new trades are collected. For reproducibility, store the time you pulled the metadata and the exact bounds used in your study.
What if data_trade_start/ data_trade_end conflict with observed trades?
Occasional mismatches can happen due to late-arriving data, backfills, or normalization updates. If you observe trades outside the bounds, treat the metadata as a guide and add validation checks. For published research, document how you resolved discrepancies.
Are these fields useful for tradable-universe filters?
They are useful as a prerequisite (“trade data exists”), but tradability also depends on recent activity and liquidity. Combine coverage bounds with trailing trade counts/volume or spread/depth metrics evaluated point-in-time.
Outer bounds, not completeness guarantees
Coverage bounds do not guarantee continuous trading or complete capture. There can be gaps within the window due to venue outages, illiquidity, or data issues. For robust pipelines, measure completeness and consider excluding symbols with large gaps if your use case requires continuity.
Real-world example
You compute 1-minute realized volatility from trades for a set of symbols in 2021. Some symbols have data_trade_start in mid-2021. If you don’t enforce trade coverage bounds, you’ll interpret missing early-2021 trades as zero activity, underestimating volatility and biasing comparisons.