BMLL puts Kalshi and CME event-contract data into one schema, but valid comparisons still require matched contracts, quote types and timestamps.

BMLL’s Kalshi integration makes the format of Kalshi and CME prediction-market data comparable. It does not make the underlying contracts, liquidity or forecast quality automatically comparable.

Announced on September 17, 2026, the partnership adds Kalshi historical order-book data to BMLL and normalizes it to the schema used for CME Event Contracts. BMLL lists Snowflake, SFTP and its Data Lab as access routes. Its broader platform provides T+1 order-book data, although the announcement does not give the Kalshi history start date, field dictionary, licensing terms or price (BMLL announcement).

That is primarily a data-engineering improvement. The analytical comparison still belongs to the researcher.

BMLL data versus the direct Kalshi API

The important distinction is between BMLL’s historical market-wide order book and the records exposed through Kalshi’s documented API endpoints.

Question	BMLL normalized data	Direct Kalshi API
Main use	Historical, cross-venue research	Direct market data plus authenticated account records
Order book	BMLL says it integrates Kalshi’s historical order book	The documented market-orderbook endpoint returns the current book
Book representation	Normalized to the CME Event Contracts schema	YES bids and NO bids; asks are inferred
Delivery	Snowflake, SFTP or BMLL Data Lab	REST; WebSocket for live updates
Historical routing	Handled within BMLL’s product	Live and historical endpoints have changing, data-specific cutoffs
Published coverage start	Not stated for Kalshi in the announcement	Varies by endpoint and available records

Kalshi’s historical tiers cover markets, candlesticks, trades, orders and positions—not archived market-wide order-book snapshots. Account orders, fills and positions also differ conceptually from a venue-wide book.

The current order-book response contains price-level arrays for YES and NO bids. A YES ask is reconstructed as $1 minus a NO bid; the reverse applies to a NO ask. The endpoint can return a specified depth of one to 100 levels or all available levels (Kalshi order-book documentation).

Suppose the best YES bid is $0.61 and the best NO bid is $0.36:

• YES bid: $0.61
• Implied YES ask: $1.00 − $0.36 = $0.64
• YES spread: $0.03
• Quote midpoint: ($0.61 + $0.64) / 2 = $0.625

The most recent trade could differ from all three numbers. Treating a midpoint, best bid and transaction as the same “probability” would create a false venue comparison. Researchers should retain the original side and price type after normalization.

Kalshi’s public trades endpoint separately supplies trade identifiers, market tickers, prices, quantities, timestamps and taker-side fields, with pagination and optional block-trade filtering (Kalshi trades documentation). Trades are therefore directly retrievable; a replayable history of the full market book is not exposed through that endpoint.

What the common CME schema enables

For CME Event Contracts, BMLL describes a Level 3 market-by-order dataset containing insertions, modifications, executions and cancellations, with unique order IDs and exchange sequence numbers. It says coverage spans XCBT, XCEC, XCME and XNYM from December 2025 (BMLL CME Level 3 specification). Its separate trades product contains price, size and execution time while retaining amendments and cancellations (BMLL trades specification).

A common schema can reduce separate parsing and storage work and support one research framework for spreads, depth, price impact and lead–lag studies. It should also reduce the chance that different field mappings, rather than different markets, drive a result.

But “same schema” does not establish that the Kalshi product contains every CME Level 3 field, has identical timestamp precision, or preserves equivalent order IDs, corrections and sequence semantics. Those details require BMLL’s Kalshi data dictionary and sample files; the announcement does not specify them.

What normalization does not solve

Contract matching

Two markets can concern the same economic release while using different thresholds, release sources, observation periods, revision rules or settlement times. Compare the complete rules, not labels such as “CPI” or “Fed decision.”

A binary contract priced at $0.60 is naturally read as roughly 60% only for its precisely defined outcome. CME likewise describes prices from $0.01 to $0.99 as corresponding to market-implied likelihoods and says contracts conclude with a $1 or $0 payoff (CME prediction-market overview).

Timestamp alignment

A shared timestamp column does not guarantee a fair join. Determine whether each field represents exchange time, vendor receipt time or file time; verify time zones and precision; and use the last strictly prior observation when equal-time ordering is unknown. The same controls apply when joining event contracts to futures prices or economic-release data. See Prediction-Market Backtest Timestamp Errors for a fuller checklist.

Sample symmetry

BMLL states that its CME Event Contract coverage begins in December 2025, while its Kalshi announcement gives no corresponding start date. A cross-venue test should use the overlap period or report venue-specific windows. Otherwise, product mix and market maturity can masquerade as venue effects.

Direct Kalshi pulls also require careful routing. Kalshi divides records between live and historical tiers. Each data type has its own moving cutoff, so researchers must query /historical/cutoff, route requests according to the relevant timestamp and merge tiers where necessary (Kalshi historical-data guide).

Liquidity and executable prices

A midpoint is not an executable forecast. Record the best bid and ask, spread, depth at the required size, last-trade age and volume. If evaluating returns rather than calibration, include fees and slippage as well; Prediction-Market Fees Versus Quoted Price explains how to avoid double-counting those costs.

BMLL’s announcement asserts that Kalshi prices—and even midpoints in less-liquid contracts—are well calibrated. That is a vendor assertion, not a result established by the integration. Calibration requires dated price snapshots, resolved outcomes and a stated sampling rule. Normalized data can make that test easier; it cannot predetermine the answer.

A defensible comparison workflow

1. Match contract rules: source, threshold, observation period, closure and settlement treatment.
2. Restrict the sample to overlapping history: do not compare all available Kalshi data with CME data beginning in December 2025.
3. Choose one observation type: last trade, midpoint, executable bid or executable ask.
4. Set a timestamp rule: for example, the last valid quote strictly before an economic release.
5. Apply liquidity filters: state the minimum depth, maximum spread and maximum quote age.
6. Retain venue-native identifiers: normalized fields should not erase source contracts or raw side conventions.
7. Validate coverage: reconcile message counts, trades and daily volume before modeling.
8. Measure the intended target: use calibration or Brier scores for forecast quality; use fills, fees and slippage for trading performance.

The BMLL integration is common infrastructure, not proof that Kalshi and CME contracts are equivalent or equally accurate. Its value is that researchers can spend less time reconciling formats—and more time making those substantive comparisons correctly.