Historical Data & Computation
One engine, two data stores. How every replay endpoint computes, what is stored versus derived, and the parity guarantees that make a backtest on this platform mean something.
Abstract
Most historical options datasets are a different product from the vendor's live feed: different pipeline, different assumptions, different bugs. FlashAlpha's replay is the same product pointed at a different data store. A historical request runs through the analytics engine that serves live traffic, over inputs stored as they were known at the requested minute, and returns the same response shape the live endpoint returns. That identity - schema parity, engine parity, input integrity - is the subject of this document, and each leg of it is enforced by machinery, not by promise.
Practical reference for calling the replay API (routes, the at= parameter, coverage, quotas) lives in the Historical API docs. This page is the computation model behind it. The operational verification layer - reconciliation, guards, fleet health - is documented at Data Quality & Monitoring.
The parity model
1. Schema parity
Every replay route returns the exact response shape of its live counterpart - same fields, same units, same conventions. The consequence is operational, not cosmetic: a strategy validated against replay runs unmodified in production, because switching from backtest to live is a base-URL swap, not a rewrite. 50+ live routes are mirrored with a required at= timestamp; earnings, the screener, and structure pricing are live-only and say so rather than pretending.
2. Engine parity, pinned by test
Live and historical share one analytics code path, and the sharing is not an architecture diagram - it is asserted by automated engine-parity tests that compare every greek between the live calculator and the historical computation across a grid of strikes, tenors, and volatilities. Where the two sides carry documented unit-convention differences, the tests assert those divergences stable, so a silent drift in either direction fails the build. An engine fix that lands on the live API is, by construction, the same fix in replay on the next deploy.
Parity extends beyond greeks: for index symbols, the parity-derived synthetic spot (recovered from the option chain with no seed price) is validated externally against official index closes using frozen chain fixtures - the computation is checked against a number we do not produce.
3. Input integrity: point-in-time, never restated
The inputs are the part of a backtest that must never be clever. Stored inputs are point-in-time and immutable: what the replay sees at minute t is what a live consumer could have known at minute t. Raw inputs are never restated; if an upstream correction matters, it is documented in the changelog, never applied silently under an existing backtest.
What is stored, what is computed
| Endpoint family | Inputs in replay | Computation |
|---|---|---|
| Option quotes & chains | Minute-stamped quotes stored at capture (SPY from 2017-01-03) | Served as stored - the raw record |
| Greeks & IV | Solved at capture time, minute-stamped - the values a live consumer saw | Served point-in-time; engine parity pins the calculator |
| Exposure (GEX/DEX/VEX/CHEX), levels, summary, narrative, 0DTE | The stored point-in-time chain, greeks, and start-of-day OI | Recomputed on demand through the live engine at the requested minute |
| Open interest | Official settled OI as of that session's open - currently on an effective T+2 settlement basis, stated rather than smoothed | No intraday estimation in settled replay: replay sees what the session opened with |
| Volatility, VRP, surfaces (SVI) | EOD-stamped series and surface parameters; leak-bounded percentiles | Series served point-in-time; derived stats computed by the live engine |
| Options & stock flow (tape, flow analytics, OI simulator) | The stored raw print tape | Flow analytics replay through the same flow engine that runs intraday |
| Earnings, screener, structure pricing | Live-only, by design - stated in the docs rather than approximated | |
New metrics are born backtestable
The one-engine model has a consequence that matters more to systematic desks than any single endpoint: a computation implemented once exists twice. The moment a new metric ships on the live API, the same code answers at= requests over every stored minute in the archive - it arrives with its own multi-year, point-in-time history on day one, no re-ingestion, no separate backfill pipeline, no second implementation to diverge.
This is why custom-metric work is a first-class engagement rather than a services afterthought. A fund or prop desk that needs a bespoke analytic - a house exposure convention, a custom flow classification, a signal built on our stored inputs - gets it live and backtestable across the archive in the same delivery, computed by the same engine that the parity tests pin. The metric your researchers validate over 2017-2026 is byte-for-byte the metric your production system polls. Custom-metric engagements run through the institutional desk.
No lookahead, by construction
- OI cannot leak. Replay serves the open interest the session opened with. The intraday flow simulator's estimates are available in the flow suite as estimates - labelled, never blended into the settled record.
- Percentiles are leak-bounded. VRP percentiles and z-scores at minute t are computed over history up to t only - the construction is stated in the methodology.
- Refusal beats fiction. Where an input fails freshness or sanity verification, the serving layer refuses with a machine-readable fault rather than interpolating - the guard behaviour documented at Data Quality & Monitoring.
Verify it yourself
Frozen sample captures - actual API responses at at=2024-08-05T10:30:00, one of the most violent sessions in the archive, not illustrative mockups - are public under /docs/samples. Pull the same timestamps on an Alpha key and the bytes should tell the same story; per-symbol coverage truth comes from GET /v1/tickers rather than from marketing copy. Coverage headline: 80+ billion minute-level option rows across 26 fully-ramped symbols, SPY from 2017-01-03; per-symbol start dates vary (SPX from 2022) - query, do not assume.
Frequently asked questions
Is the historical data the same as the live data?
Same engine, same schemas, different store: minute-stamped quotes and greeks since 2017, start-of-day official OI, EOD-stamped surface parameters - served through the code path that answers live traffic. An SDK switches between the two with a base-URL swap.
How is lookahead bias prevented?
By the inputs' construction: each replayed minute sees only what was knowable then. OI is the session-open official value, greeks are the values solved at capture, percentiles are computed over history up to that minute, and raw inputs are never restated.
Are live and historical computations actually identical?
One shared code path, asserted by per-greek engine-parity tests that also pin the small set of documented convention divergences as stable - drift fails the build. Index spot recovered by put-call parity is additionally validated against official closes via frozen external fixtures.
Does historical output change when the engine improves?
Inputs never change; the engine is current. A documented improvement propagates to replay on deploy and is versioned in the changelog - visible, dated, citable. Silent restatement is the thing that never happens.