Historical data quality determines whether a backtest reconstructs a trading opportunity or manufactures one. Missing delisted stocks, revised economic figures and incorrectly timed price bars can change which trades appear possible, not just the accuracy of the final return.
The task is to reproduce what the strategy could have known, bought and sold at each decision point. Before comparing results from trading strategy backtesting software, check the history feeding it. A sophisticated engine cannot rescue a dataset that gives the strategy tomorrow’s information today.
Define the Data Requirements Before Downloading History
Start with the trading decision, then choose the data. A strategy that rebalances after company filings needs publication history and dated fundamentals. An intraday strategy using stop orders needs enough price detail to test its order sequence. More rows do not automatically mean better evidence.
Write down the required instruments, venues, trading sessions, fields and frequency. Record whether prices represent trades, bids, asks, midpoints or settlements. Also establish how the supplier handles missing observations, corporate actions and corrections.
Use a short acceptance specification rather than relying on a product description:
| Data requirement | Question to resolve | Suggested check |
|---|---|---|
| Coverage | Does history include securities that stopped trading? | Inspect inactive instruments and their final records. |
| Timing | When could the strategy first use each observation? | Compare event, publication and receipt timestamps. |
| Price basis | Are prices raw, adjusted or synthetic? | Reconcile observations around a corporate action or contract roll. |
| Completeness | Are gaps genuine or caused by collection failures? | Compare missing intervals with sessions and trading status. |
| Reproducibility | Can the same dataset be restored later? | Save the download version, documentation and file checksums. |
Define rejection rules before examining profitability. Otherwise, an inconvenient missing interval can become surprisingly easy to excuse.
Stop Look-Ahead Bias at the Timestamp
Look-ahead bias occurs when a decision uses information that was unavailable at that moment. A common route is confusing a bar’s label with the time its contents became known. A bar covering 10:00 to 10:05 cannot provide its completed high, low and close at 10:00. The distinction between bar start and availability is documented in QuantConnect’s bar timing and time-frontier documentation.
Suppose a hypothetical strategy buys when a five-minute bar closes above a moving average. If it calculates the signal from that completed bar but fills at the bar’s opening price, the test has reversed cause and effect. Buying at the completed closing price also needs justification: the strategy cannot observe the final close and then submit an order retroactively.
Keep separate timestamps for the event and its usable arrival wherever possible. Normalize time zones without discarding exchange-local session rules. Test daylight saving transitions and overnight sessions explicitly.
For a simple audit, select several trades and reconstruct their timelines. Ask what data existed when the signal fired, when the order became active and which subsequent observation justified the fill.
Keep Point-in-Time Fundamentals and Economic Data
A reporting period is not a publication date. A hypothetical company might report results for a quarter ending March 31 on May 8. A strategy using those results cannot trade on them in March simply because the database assigns them to that quarter.
Preserve the original filing or release identifier, its availability timestamp and later amendments. Do not assume a convenient cross-sectional download already supplies historical knowledge states. The SEC’s XBRL frames endpoint selects the last-filed fact that best fits the requested calendar period; that is not automatically a reconstruction of what investors knew on an earlier date. Check the SEC’s EDGAR API definitions before treating such output as point-in-time input.
When exact availability is missing, a conservative reporting delay can support an exploratory test. Label it as an assumption. A fixed delay does not recover original values after restatements, nor prove that every company published within that delay.
Economic series require the same discipline. Later revisions can replace the estimates traders originally saw. The St. Louis Fed’s ALFRED vintage-data service preserves historical versions so researchers can retrieve data as reported on past dates.
For intraday release strategies, verify the publication time separately. A date-level vintage does not, by itself, establish the exact second a value reached a trading system.
Rebuild the Universe That Existed Then
Survivorship bias arises when the test includes surviving instruments but excludes those that disappeared. Testing an old stock strategy against today’s index members introduces another problem: the universe already reflects later membership decisions. Survivorship-free coverage and historical index membership are related requirements, not interchangeable ones.
Build eligibility separately for each historical decision date. Apply listing status, membership, price and liquidity filters using information available then. Keep securities through their relevant exit events rather than dropping their histories when they vanish from the current symbol list.
Stable identifiers help maintain continuity across name and ticker changes. The CRSP US Stock Databases specification includes active and inactive securities, corporate actions and permanent security identifiers.
Ask how final proceeds and delisting returns enter the portfolio calculation. A security disappearing from the file is not permission to liquidate it at the last convenient quote. Also inspect missing fundamental data: automatically excluding every incomplete record can change the tested universe in ways that need investigation.
Separate Corporate Adjustments From Executable Prices
Raw prices, split-adjusted prices and dividend-adjusted series serve different purposes. They should not share a column simply called “price” without further documentation.
Consider a hypothetical two-for-one split. A holding of 100 shares priced at $80 becomes 200 shares at a mechanically equivalent $40 before other market movement. A portfolio calculation that halves the price but leaves the share count unchanged invents a loss. A signal calculation that ignores the split can invent a price collapse.
Adjusted history can support return comparisons and indicators. It is not automatically unsuitable for backtesting. Problems arise when an adjustment changes something the strategy needed to observe in its original units.
A rule that buys stocks trading below $10 needs the nominal price available on the decision date, not a historical level reduced by a future split. Likewise, avoid counting dividends twice by combining dividend-inclusive returns with separate dividend credits.
Keep signal calculations and portfolio accounting consistent. Document which series drives indicators, which prices determine order quantities and how dated corporate actions update shares and cash. Reconcile at least one split and one distribution manually before accepting the portfolio report.
Check Futures Rolls and Feed Compatibility
A continuous futures series joins successive contracts into a longer history. Its usefulness depends on the construction rules. Front-contract and active-contract histories can switch contracts differently; CME Group’s continuous price series methodology distinguishes those approaches and identifies its daily observations as settlement-based values.
For a futures backtest, retain the underlying contract identifier and roll schedule. Reconstruct positions and profit or loss from the contracts the strategy would hold, including the trades needed to roll them. Do not treat a smooth research series as an order book.
Check how any back adjustment affects price levels, returns and threshold rules. A level-based signal deserves particular scrutiny when earlier prices change as later contracts are added.
Feed compatibility matters outside futures too. Before joining files, compare venue coverage, quote versus trade fields, session boundaries and bar construction. Use overlapping periods to investigate differences rather than averaging conflicting values into an apparently cleaner history.
Do Not Let the Fill Model Repair Bad Data
Price history records observations. A fill model decides whether an order could execute against them. Those are separate jobs. Stale observations, queue position and market impact can create differences between simulated and live fills, as detailed in QuantConnect’s backtest and live-trading reconciliation documentation.
A daily high above a sell limit does not establish that every requested share would have sold. Likewise, a bar containing both a stop price and a profit target does not reveal which was reached first.
For a hypothetical long position with a $98 stop and a $104 target, a bar with a $97 low and $105 high supports more than one possible sequence. Seek finer observations where available. If the sequence remains unknown, report the ambiguity and test adverse assumptions rather than always awarding the target.
Keep historical spread observations separate from assumed spread costs. Where quotes are missing, state the substitute and test sensitivity. Apply the same approach to fees, slippage, borrowing costs and order size. Better price history does not supply every missing execution condition.
Audit Data Without Polishing Away Risk
Data cleaning should correct evidence, not improve the strategy. A large price move may be an error, a corporate action or a genuine market event. Automatically deleting extreme returns can remove the conditions the test needs to survive.
Use a repeatable audit process:
- Preserve the original download. Keep raw files unchanged. Record supplier, retrieval time, schema, adjustment settings and dataset version.
- Run structural checks. Flag duplicates, unordered timestamps, missing fields, unexpected session gaps and inconsistent units. For ordinary price bars, investigate observations whose high falls below their low or whose open or close lies outside the reported range.
- Review exceptions with context. Compare suspicious records with corporate actions, trading status and another suitable feed. Record the reason for every correction, exclusion or unresolved discrepancy.
- Rerun with controlled changes. Compare the original and audited histories using identical strategy settings. Attribute changes in trades and returns to the data changes rather than adjusting the strategy simultaneously.
Do not fill missing prices indiscriminately. Carrying the last observation forward may support valuation under a stated stale-price policy, but it does not establish a fresh execution opportunity. Keep observed and synthetic records distinguishable.
Useful audit outputs include missing-interval rates by instrument and session, stale-data flags, unresolved identifier changes and performance sensitivity to disputed observations. Measure gaps against expected trading activity, not every minute on the calendar.
Finish with trade-level reconciliation. Inspect ordinary trades as well as the largest winners and losses. A strategy should not depend on one unexplained print.
Decide Whether Results Are Fit for Further Testing
Data quality and research bias need separate checks. A clean dataset can still support an overfit strategy. Fitting normalization rules, selecting features or choosing parameters using the entire test period can contaminate later evaluation even when every market observation is correct. Handle those questions through overfitting checks and walk-forward testing, rather than expecting data cleaning to solve them.
Before proceeding, require a reproducible dataset, a defensible historical universe, documented availability rules and an explanation for material data exceptions. If reasonable treatments of unresolved records reverse the result, classify the evidence as inconclusive.
Then use paper trading for automated strategies to compare incoming data, signal timing and simulated orders with the historical implementation. That comparison can expose differences that static files miss, though simulated fills still are not live execution.
Passing these checks does not establish future profitability. It establishes something more modest and necessary: the backtest is worth evaluating rather than repairing.