Blog
Blog
Traders hit the same wall over and over: the candle looks clean, the top-of-book looks active, and the feed looks available, but the actual market context is still missing. Coverage and price are what the sales pages show. The question that actually decides whether a strategy becomes usable is whether the provider has already solved the market-context and feature-computation problem, or left it to you.
That gap has a real cost. A quant team that spends six weeks building a normalization pipeline before running a single backtest has not been unlucky. They hired the wrong kind of vendor.
The raw feed from an exchange WebSocket is not a useful input to a strategy. It is a sequence of events: order placements, cancellations, partial fills, queue updates. On a liquid pair at a major venue, that sequence runs to tens of thousands of events per hour. Every downstream metric, whether bid-ask spread, order flow imbalance, depth asymmetry, or price impact, has to be computed from that raw sequence.
That computation is not trivial. Cont, Kukanov, and Stoikov established in the Journal of Financial Econometrics (12(1):47-88, 2014) that order flow imbalance carries statistically significant predictive power for short-term price movement. The signal has held up. The engineering required to extract it cleanly, across exchanges with different tick structures, different latency profiles, and different API schemas, has not become easier.
A provider that hands you WebSocket events has given you the raw material. The data pipeline that turns those events into features your strategy can consume is still entirely your problem.
Exchange coverage and normalisation. The BTC/USDT pair trades simultaneously on dozens of live venues. Single-exchange OFI is noisy because professional participants route orders based on fee structures, not information. Cross-exchange OFI, aggregated across many venues and normalised to a consistent depth basis, filters out that routing noise and gets closer to the actual directional pressure in the market. A provider that covers one or two exchanges is giving you a fragment of the picture. The normalisation problem is the hard part: different lot sizes, different tick granularities, different timestamp precision. A provider that has done this correctly is not the one that just connected WebSockets.
Pre-computed versus raw delivery. This is the axis that determines research velocity more than any other. Raw data delivery means you build and maintain the computation layer. Every new feature requires new pipeline code. Every exchange API change potentially breaks your calculations. Pre-computed feature delivery means querying for the metric you need and receiving it, not the raw material from which it might be derived. A trading desk that can test a hypothesis about OFI divergence in an afternoon, rather than spending a week on pipeline engineering first, runs more experiments per month. More experiments per month produces better strategies. The compounding is real.
Historical depth and replay fidelity. Backtesting a microstructure strategy on candle data produces a fiction. The intracandle sequence of events, the actual bid-ask state at each decision point, the depth available at the moment an order would have been placed, none of that survives aggregation into open-high-low-close. Providers with historical event archives allow replaying what the orderbook actually looked like, not a summarised reconstruction. The length of that archive varies enormously: providers that launched recently cannot offer data from the 2018 bear market, the March 2020 crash, or the FTX collapse with full depth. If your strategy requires validation across multiple regime types, archive depth is not a secondary consideration.
Latency and feed stability. A feature computed on stale data is not the feature you think it is. An OFI calculation based on a snapshot that is 800 milliseconds old during a fast market move is measuring the past, not the present. Feed stability compounds this: a provider whose WebSocket reconnections introduce gaps in the event sequence, without clear gap detection, allows stale calculations to propagate as current data. The failure mode is silent. The strategy keeps running on numbers that no longer reflect market state, without knowing they are wrong.
Pricing transparency. Institutional providers with enterprise sales processes offer opaque pricing that requires a multi-week procurement cycle to discover. For a researcher who wants to evaluate whether a hypothesis is worth pursuing, a two-week delay to get a quote is not a minor inconvenience. It is a hard barrier that kills hypotheses that were never given the chance to be wrong. Self-serve access with visible pricing changes what gets tested. Providers that require a sales call before revealing what their product costs have designed a friction that selects against the exploratory research that produces real edge.
The market splits into three categories.
Institutional archive providers prioritise historical depth, regulatory-grade reference pricing, and compliance documentation. Kaiko is the strongest example: a decade of data used in index construction methodologies, auditable VWAP reference rates, and a position in regulated workflows that took years to build. The tradeoff is cost, a sales cycle before evaluation, and no pre-computed microstructure features. A compliance team at an asset manager needs what Kaiko built. A quant researcher running hypothesis experiments on a Tuesday afternoon generally does not.
Historical tick replay providers prioritise faithful event-level replay for backtesting execution logic. Tardis.dev is the benchmark here: full event archives for major exchanges, a replay API that streams historical data as if it were arriving live, and a Node.js client that serious quants cite approvingly. For a researcher who needs to reconstruct exactly what the orderbook looked like during a specific episode, or test execution logic against the actual sequence of events from several years ago, Tardis solves that problem correctly. The constraint is that the architecture is built for offline analysis. Wiring it into a live production system that needs computed features in the next second is not the intended use case.
Live feature delivery providers compute microstructure metrics from live feeds across many exchanges and serve them through an API. The buyer does not receive raw events. They receive the derived metrics, normalised, timestamped, ready to query. DepthSignal is built around this model: dozens of pre-computed microstructure features across many live exchanges, accessible through a consistent API schema, with self-serve trial access. The constraint is explicit: if a strategy requires computing a custom metric that the provider does not offer, the raw event stream is not available. You are consuming a feature catalogue, not a data warehouse.
Every provider has a genuine structural limitation. Kaiko does not offer pre-computed microstructure features or self-serve access. The feature engineering is the buyer's problem. Tardis does not have an architecture designed for live production use. Their replay pipeline is not built to deliver OFI to a live strategy making decisions in the next 500 milliseconds. DepthSignal does not have Kaiko's compliance history or Tardis's multi-year replay depth. A researcher who needs to test a strategy against tick data from 2017 will not find that at DepthSignal.
These are not product failures. They are architectural choices reflecting the problem each provider set out to solve. The mistake is choosing a provider based on name recognition and discovering the architectural mismatch after the engineering investment.
The decision tree is not complicated once the architecture is understood.
Compliance teams, index administrators, and regulated funds that need auditable reference pricing and multi-year historical provenance: Kaiko. The compliance paper trail is the product, and it took a decade to build. A newer provider cannot offer a comparable audit history regardless of data quality.
Quant researchers who need to backtest execution logic at tick resolution, validate strategies against historical market episodes with full depth, or study how specific events played out event-by-event: Tardis. Their replay infrastructure handles this workflow correctly and the data quality for major venues is serious.
Quant teams building live strategies where the primary bottleneck is feature computation time, not data access: DepthSignal. The economics of a research cycle where OFI is already computed and queryable, rather than a pipeline to build first, compound quickly. A team running three experiments per week produces better-validated strategies than a team that spends two weeks building the feature layer before the first experiment starts.
Some organisations need more than one of these. A fund with both a compliance reporting requirement and an active quant research desk is not facing an either-or decision. That is two different infrastructure problems that happen to involve orderbook data. Using the same vendor for both is the category error that produces expensive compromises.
Trial a provider against your actual use case, not a toy query. A toy query confirms the credentials work. It does not reveal how the feed behaves during a volatility event, how gap handling is implemented when an exchange connection drops, or whether the feature values during thin liquidity periods match your expectations.
For live feature delivery: run the trial against your actual symbol set and exchange list, check feature values during at least one high-volatility period, and verify that the feature definitions match what you think they mean. OFI computed at different depth levels with different normalisation assumptions produces different numbers that are not interchangeable.
For historical replay: run against a data window that includes at least one regime change or stress period. A provider whose replay works correctly during calm markets but introduces sequencing artefacts during the March 2020 gap-and-recover is not one to base a strategy on.
The developers who evaluate most carefully are the ones who discovered the hard way that the trial query and the production query live on different assumptions.
Every article framing this as a comparison between providers eventually circles back to the same structural point. There is no universal best orderbook API in 2026. There is the right provider for the specific problem your team is trying to solve, and there is the expensive mistake of confusing the two.
A compliance team and a quant researcher working at the same firm might give you opposite answers about which provider is "best." Both are right. The question was never which provider wins. It was always: which problem are you actually solving?
There is no universal winner. The right API depends on whether you need historical replay, compliance-grade reference data, or live computed microstructure features for active research.
Usually not. Raw events still need cleaning, normalization, feature computation, and gap handling before they become usable for strategy research or execution analysis.
Depth, trades, venue context, status signals, and documentation that explains what each field means without forcing the trader to reverse-engineer the feed.
When research speed matters more than custom pipeline control. If the bottleneck is computing OFI, depth asymmetry, or market-impact features yourself, pre-computed delivery removes weeks of engineering overhead.
Because the feed is only the first layer. Normalization, gap handling, replay integrity, field semantics, and feature computation are where most of the real engineering cost sits.
No. A market data API should provide evidence and context. The trade decision, sizing, and risk controls remain with the trader.
Visual temporarily unavailable
This section's visual is under review. The article text, FAQ, and references remain current while a replacement is prepared.