Stop future information from leaking into your backtest

BotSpot capabilities

1. Distinguish look-ahead bias from data leakage

Look-ahead bias occurs when a historical decision uses information that was unavailable at that decision time. Data leakage is broader: evaluation data influences strategy construction, feature preparation, parameter selection, or model training.

Every input needs at least two clocks: when the underlying event occurred and when the value became available to the strategy. A reporting period end, market-data timestamp, database timestamp, and public release time may describe different moments.

• Event time: when the trade, accounting period, or corporate event occurred.
• Availability time: when the strategy could first receive and use the information.
• Decision time: when strategy logic evaluated available inputs.
• Execution time: earliest modeled time when resulting order could trade.

2. Reconstruct point-in-time information

A current database snapshot can contain corrected prices, revised fundamentals, renamed symbols, and today's index members. Querying that snapshot by historical date does not automatically recreate the information available then.

Use point-in-time records keyed by availability time. Preserve dataset version, source, timezone, revision identifier, and ingestion rule so another test can reconstruct the same information set.

• Reject any feature whose availability time is later than the simulated decision.
• Apply a documented reporting lag when reliable point-in-time timestamps are unavailable.
• Version datasets instead of silently replacing corrected history.
• Record whether missing values were genuinely unavailable or introduced during collection.

3. Use historical universes, not today's survivors

Testing old periods against securities that exist today excludes many delisted companies and can use index membership learned after the fact. This survivorship bias changes both candidate selection and measured results.

Rebuild the eligible universe at each historical date. Include delistings, historical constituents, ticker changes, listing dates, and securities that later failed whenever the strategy could have selected them.

• Do not apply today's S&P 500 or exchange list to earlier dates.
• Track stable security identifiers across ticker and company-name changes.
• Model delisting events and final position treatment.
• Confirm data coverage includes removed assets, not only active symbols.

4. Delay fundamentals until publication

Financial values belong to a reporting period but are not knowable on that period's end date. A quarterly result should enter the simulation only after its filing or release became publicly available.

Amended filings, restatements, and vendor revisions need separate availability timestamps. Do not replace an original value with its latest revision throughout earlier history.

• Store period end, filing form, accession number, acceptance time, and amendment status.
• Use the original filing value until a later amendment becomes available.
• Apply market-hours rules when information arrives after the close.
• Document vendor processing delay when provider availability trails public release.

5. Align bars, indicators, signals, and orders

Bar timestamps require explicit interpretation. Alpaca, for example, timestamps a minute bar at the left edge of its interval, while the complete high, low, close, and volume are known only after that interval finishes.

Compute indicators from completed observations. Unless an intrabar model supplies information available before the close, a signal using a bar's closing value cannot also receive that same closing price as an instantaneous fill.

• Define exchange timezone, daylight-saving behavior, session calendar, and extended-hours policy.
• Assert that every indicator input ends at or before the decision time.
• Shift signals to the next feasible execution event when they depend on completed bars.
• Keep warm-up observations before the test period from contributing trades or results.
• Inspect rolling-window and resampling boundaries for accidental forward fills.

6. Handle corporate actions consistently

Splits, dividends, spin-offs, symbol changes, and delistings affect prices, holdings, indicators, and cash. Raw and adjusted datasets answer different questions; mixing them can create false signals or double-count returns.

Choose and document one normalization policy for each calculation. If total-return-adjusted prices already incorporate dividends, adding the same dividends as separate cash flows can count them twice.

• Verify price and volume adjustment choices together.
• Test split dates for discontinuities in indicators and position quantities.
• Keep historical symbol mappings without rewriting earlier identity.
• Confirm benchmark and strategy returns use compatible dividend treatment.
• Reset or warm up live indicators when normalization differs around corporate events.

7. Fit preprocessing inside each training window

Machine-learning leakage can occur before model fitting. Scaling, imputation, feature selection, dimensionality reduction, and threshold selection must not learn from evaluation periods.

Split chronologically before fitting transforms. During walk-forward evaluation, fit every learned preprocessing step again using only the current training window, then transform the later evaluation window without refitting.

• Never fit normalization statistics on the full historical sample.
• Keep future labels separate from features used at decision time.
• Perform feature selection inside each training fold.
• Preserve unseen evaluation data until model and workflow choices are frozen.

Backtest leakage checklist

• Can every input be traced to source and first-available timestamp?
• Does an automated assertion enforce feature time less than or equal to decision time?
• Does universe history include prior constituents, ticker changes, and delistings?
• Are original and amended fundamental values available as separate vintages?
• Do completed-bar signals execute no earlier than their first feasible trade?
• Are raw, split-adjusted, dividend-adjusted, and total-return series used consistently?
• Are preprocessing steps fitted only on each training window?
• Can one sample trade be replayed using only records visible at that moment?
• Are data version, timezone, calendar, normalization, and reporting-lag rules saved with results?

Limitations and risk

Passing these checks does not prove a strategy has an edge. Historical datasets can still contain errors, missing observations, vendor-specific corrections, or timestamps that do not represent real delivery latency.

Treat unexpectedly strong results as a reason to inspect data lineage, trades, and timing before interpreting performance.

Frequently asked questions

Sources

• QuantConnect research guide: look-ahead and survivorship bias
• QuantConnect live and backtest reconciliation
• QuantConnect event-handler timing and corporate actions
• SEC EDGAR timestamp definitions
• SEC EDGAR data APIs
• Alpaca market-data timestamp semantics
• Alpaca historical-bar adjustment options
• scikit-learn data-leakage guidance
• Lumibot backtesting documentation

Sources verified 2026-08-14.