Point-in-Time Option Contract Selection

Abstract

Options backtests fail when they select instruments from the wrong universe. A stock signal can be simple, but the traded object is an option contract with listing history, expiration schedule, strike geometry, liquidity, and quote behavior. Contract selection has to be point-in-time or the rest of the backtest is unstable.

For developers, the goal is to make the selector answer one question: which contracts could the strategy have discovered at this timestamp?

The Contract Selector's Job

A selector should start with listed contracts for the underlying and historical date. It should filter by DTE, type, strike or delta target, status, liquidity, spread, and any strategy-specific constraints. Then it should return the selected contract and the rejected candidates.

The rejected candidates are not clutter. They are how you debug the next failure. A no-trade day caused by no_listed_expiry_in_dte_window means something different from a no-trade day caused by wide spreads or stale quotes.

Separate Discovery From Ranking

A reliable selector has two phases. Discovery asks which contracts existed at the historical decision time. Ranking chooses the preferred expression from that discovered set. Keeping those phases separate makes the selector easier to test and easier to audit.

Discovery should not know the strategy's favorite strike. It should return the available universe with listing state, expiration, type, strike, and any reference fields needed downstream. Ranking can then apply the strategy's policy: closest target delta, nearest moneyness bucket, minimum DTE, maximum spread, minimum price, or a custom scoring rule.

This separation matters because bugs often hide inside convenience functions. A helper that both invents candidate expirations and chooses the best contract can silently mix historical discovery with modern assumptions. If discovery and ranking are separate, a unit test can freeze the universe and prove that the ranking rule behaves consistently.

Avoid Modern-Chain Leakage

Modern-chain leakage happens when today's contract list influences an old backtest date. It can be obvious, such as selecting a contract that did not exist. It can also be subtle, such as using an expiration schedule that was not available for that underlying on the trade date.

The cure is an as-of workflow. Discover the universe at the historical date, then select within that universe. Do not generate Fridays and assume they were listed. Ask the data.

DTE Windows Need Listed Expiration Evidence

Days-to-expiration filters look simple, but they are not enough on their own. A rule such as "select 30 to 45 DTE" only defines an allowed range. It does not prove that the underlying had listed expirations inside that range, or that the desired option type and strike region were available with usable quotes.

For index ETFs, weekly expirations can make this feel easy. For other underlyings, listing patterns can be sparser or can change over time. A developer who generates expirations mechanically can create a clean-looking backtest that trades contracts the market did not offer. The correct selector starts with listed expirations, then applies the DTE window to that observed set.

The same principle applies to strike choice. A target moneyness or delta rule should rank available contracts. It should not imply that an ideal strike existed. If the closest available strike is too far from the target, the selector should record that fact or reject the trade.

Cache Carefully

Contract caches are useful, but the cache key has to include the information that affects selection. If the same day has multiple entries with different underlying prices, a moneyness-based selector cannot safely reuse a strike chosen for the earlier price bucket.

This is a common developer bug because the cache looks like a performance improvement. It becomes a research defect when it silently reuses the wrong instrument.

Cache Keys Should Describe The Policy

A safe cache key usually needs more than underlying and date. It may need the as-of timestamp, option type, DTE window, price bucket or underlying reference price, strike target, delta target, liquidity policy, and data vendor or snapshot version. If any of those fields can change the selected contract, they belong in the key or in a lower-level cached object.

One practical pattern is to cache discovery broadly and ranking narrowly. The listed contract universe for SPY on a date can be reused across many strategy variants. The ranked winner for a specific moneyness, DTE, and liquidity policy should be treated as strategy-specific. This keeps performance benefits without corrupting the research object.

When a cache hit occurs, log it. A cache is part of the experiment. If the selected contract changes after a cache-key fix, the old results should be considered a different run, not a small formatting change.

Diagnostics For The Selector

A point-in-time selector should produce diagnostics even when it succeeds. Useful fields include candidate count, expiration count, selected DTE, selected moneyness, quote availability, spread width, and the top rejection reason for nearby alternatives. These diagnostics turn contract selection into something measurable.

They also expose boundary cases. A strategy may perform well only when the selected contract has unusually tight spreads. Another may fail because its target DTE rarely exists. A third may be sensitive to strike rounding. None of those findings are visible if the backtest only records the final symbol.

Takeaway

Point-in-time contract selection turns an options backtest from a stock-signal study into a tradable-instrument study. The selector should be timestamped, explainable, and suspicious of generated calendars.