BMLL Adds Kalshi Historical Order Book Data—but Check Coverage Before Backtesting

As of September 30, 2026, BMLL says it offers institutional access to Kalshi historical order book data, normalized to the same schema used for CME Event Contracts. The announced access routes are Snowflake, SFTP and BMLL Data Lab.

The important qualification is that the public announcement does not provide a Kalshi coverage start date, field dictionary, granularity, replay guarantee, update schedule, price or licensing terms. Researchers should confirm those details before assuming that “same schema” means identical information content.

What BMLL has confirmed

BMLL and Kalshi announced the partnership on September 17, 2026. The official announcement says BMLL is normalizing Kalshi’s historical order book into its unified CME Event Contracts schema. It identifies research around Federal Reserve decisions, CPI releases and GDP reports as intended applications.

BMLL’s broader Data Feed supports other delivery methods, but the Kalshi release names only those three routes. BMLL describes Snowflake as native data sharing and SFTP as scheduled file delivery; Data Lab is its managed research environment (BMLL Data Feed).

This appears intended for organizations already equipped to license and process institutional market data—not for someone seeking a one-click public CSV of every historical Kalshi quote.

How this differs from Kalshi’s API

Kalshi’s own API provides several kinds of history. It partitions markets, candlesticks, trades, orders and market positions between live and historical endpoints using moving cutoff timestamps. Kalshi tells users to retrieve the relevant cutoff and combine live and historical results when necessary (Kalshi historical-data guide).

For price research, Kalshi’s historical candlestick endpoint supplies one-minute, hourly or daily bars. Its documented fields include YES-bid, YES-ask and traded-price summaries, plus volume and open interest (Kalshi candlestick documentation). Those bars may be sufficient for some lower-frequency studies.

They are not a historical order book. Kalshi’s REST order-book endpoint returns the current active bids at each YES and NO price level; the complementary asks can be inferred from the opposite side (Kalshi order-book documentation). The public REST documentation does not expose a historical sequence of book states. A researcher needs an independently collected archive or a historical data provider for that sequence.

BMLL’s product addresses that collection and normalization problem. Exactly which Kalshi book events it preserves, however, is not stated publicly.

A common schema does not make the markets equivalent

A shared schema lets equivalent fields be queried and processed consistently. It does not establish that Kalshi and CME contracts have equivalent liquidity, participants, settlement rules or economic meaning. See what is and is not comparable across BMLL’s Kalshi and CME data for the cross-venue issues.

There is also a narrower fidelity question. BMLL’s published CME Level 3 product contains every order insert, update, execution and cancellation, along with unique order IDs and exchange sequence numbers. BMLL says those fields support deterministic book replay and order-lifecycle analysis. But that product page explicitly describes CME Event Contracts, with data available from December 2025 (BMLL CME Level 3 product description).

The Kalshi announcement says “historical order book,” but does not say whether Kalshi records contain all the same order-level attributes. Normalization to the CME schema is therefore not proof of identical Level 3 depth or replay capability.

What to verify before licensing

Request a Kalshi-specific data dictionary, coverage matrix and sample spanning several market types. Then check:

1. Coverage: earliest date, category exclusions and changes in coverage over time.
2. Granularity: order messages, price-level updates, periodic snapshots or a combination.
3. Event ordering: sequence numbers, timestamp precision and treatment of simultaneous messages.
4. Book reconstruction: whether inserts, updates, cancellations and executions permit deterministic replay.
5. Trade linkage: whether executions connect to resting orders and identify aggressor side.
6. Reference data: contract wording, strike, close time, settlement source, outcome and lifecycle changes.
7. Corrections and outages: how gaps, busted trades, late records and vendor revisions appear.
8. Delivery: publication lag and update schedule for each access route.
9. Rights: permitted users, regions, retention, redistribution and derived-data terms.
10. Commercial terms: minimum commitment, trial access, storage and compute charges.

These checks depend on the research question. A study based on pre-specified probability snapshots may need clean quotes, contract metadata and outcomes. Queue-position or fill-probability research needs an ordered message history with much stronger completeness guarantees. Execution simulations must also prevent equal-time ordering errors and future leakage; use the prediction-market backtest timestamp checklist.

BMLL’s integration can remove a substantial collection and normalization job. It does not by itself make Kalshi and CME contracts economically interchangeable or establish that the data supports a particular backtest. Test the Kalshi sample against the exact statistic or simulation you plan to run before licensing it.