MRKT: Level 3 Market Data Explained: What It Is, When You Need It, and Where It Gets Difficult

Overview

Level 3 market data is the most granular commonly discussed view of order book activity. It shows individual orders and the message-level events that affect them, such as adds, cancels, modifications, and executions.

In plain terms, Level 3 lets you track how the visible book changes order by order. You do not only see the best quote or aggregated depth.

This level of detail matters because it enables workflows that aggregated feeds cannot support cleanly. Examples include order book reconstruction, queue position modeling, and realistic fill simulation.

At the same time, the extra granularity increases volume, engineering complexity, and the risk of misinterpreting feed semantics.

If you only need top-of-book monitoring, broad liquidity context, or basic execution review, Level 2 may be enough. If you need to understand individual order lifecycles and how displayed liquidity evolves message by message, Level 3 becomes much more relevant.

Level 1, Level 2, and Level 3 are different views of the same market

Level 1, Level 2, and Level 3 are best understood as increasingly detailed views of the same trading venue. Think of them as observation granularity rather than three separate markets.

The distinction matters because each level changes what you can observe and what inferences are realistic. Higher levels reveal more of the supply-and-demand processes that generate price and size changes.

Level 1 usually gives you the basic quote and trade view: best bid, best ask, and last trade information. Level 2 adds market depth, typically showing resting size at multiple price levels, often in aggregated form. Level 3 goes deeper by exposing individual visible orders and their lifecycle events; naming and exact fields vary by venue and vendor.

A practical way to think about the hierarchy is this: Level 1 helps you see where the market is. Level 2 helps you see how much displayed liquidity is near the market. Level 3 helps you study how that displayed liquidity is built, consumed, changed, and removed over time.

What Level 3 adds beyond Level 2

The key jump from Level 2 to Level 3 is the move from aggregated depth to message-level order visibility. With Level 2, you may know that 1,500 shares are resting at a price level. With Level 3, you may see that this displayed size is made up of several separate visible orders. Each order has its own identifier and event history.

That change matters when sequencing, not just snapshot size, drives your analysis.

This difference matters for workflows that depend on order sequencing rather than static depth snapshots. Queue modeling, passive fill simulation, and microstructure research frequently require knowing whether displayed liquidity was added, partially executed, repriced, or canceled.

Aggregated depth typically cannot answer those questions reliably. In practice, the presence or absence of order identifiers and fine-grained event types often determines whether a model can simulate fills or estimate queue position credibly.

A short worked example makes the difference concrete. Suppose the best bid is 100.00 and Level 2 shows 1,000 shares there. Level 3 might reveal that the 1,000 shares are actually three visible orders: 400, 300, and 300.

Assume you plan to join that bid with a 100-share passive buy order, and the venue uses visible time priority. If the front 400-share order is partially filled for 150, then a separate 200-share buy order joins after the existing queue, Level 2 may still show roughly the same price-level depth while your expected place in line changes. The practical outcome is that fill probability can worsen or improve even when the headline depth number barely moves.

Why more detail does not always mean better decisions

More detail helps only when the decision depends on that detail. If your task is event-driven discretionary trading, broad execution review, or monitoring macro releases, message-level order data may add complexity without changing the decision much.

The practical question is whether the marginal insight from Level 3 changes outcomes enough to justify engineering, storage, and validation costs.

Level 3 also raises the bar for storage, replay, validation, and interpretation. You need to process high message volumes, handle resets and missing sequences, and understand venue semantics well enough not to confuse a feed artifact with real market behavior.

In many workflows, the real choice is not “Do I want the best data?” but “What is the minimum data level that supports a trustworthy answer?”

What Level 3 market data usually contains

Level 3 market data usually contains the stream of events needed to update a visible order book at the individual-order level. In practice, that often means messages tied to order entry, change, reduction, and execution.

Feeds also include identifiers, prices, sizes, sides, timestamps, and exchange sequencing fields when provided. Because exchanges and asset classes differ, there is no single universal Level 3 schema. Public descriptions from vendors and market-data operators commonly frame Level 3 as individual-order or market-by-order style data rather than aggregated price-level depth, but the exact field set still depends on the source feed.

Equities, futures, and crypto exchanges can differ materially in field names, event types, auction handling, aggressor flags, and whether certain actions are explicit or must be inferred. That variability is why vendor normalization exists. It is also why normalized datasets can sometimes smooth away details that matter for precise research.

The message types that change the book

A generic Level 3 feed often revolves around a small set of book-changing events. Exact names vary, but the functional categories are usually familiar:

Add / new order: inserts a visible order into the book at a price and size.
Cancel / delete: removes all or part of a resting order without a trade.
Modify / replace: changes order attributes such as price or size, depending on venue rules.
Execution / fill: reduces resting displayed size because a trade occurred.
Clear / reset / book state event: signals that the book should be refreshed, reset, or treated with caution.

These categories matter because accurate order book reconstruction is an exercise in applying them in the correct order. Misclassifying an event type or mishandling a reset can cause the reconstructed book to drift from the venue’s actual displayed state.

Market-by-order is close to Level 3, but not always identical

Market-by-order data is often used as a near-synonym for Level 3 because both generally refer to individual visible orders rather than aggregated price-level depth. But the terms are not perfectly interchangeable across every exchange, vendor, or asset class.

Some feeds expose full visible order-level detail, while others package order events differently or omit fields that researchers care about. A normalized vendor dataset may also label something as Level 3 even though some exchange-native nuance has been simplified.

That is why it is safer to inspect the actual schema and event semantics—order IDs, replace semantics, and aggressor flags—than to rely on the label alone. Where a provider documents those distinctions publicly, reviewing the raw or exchange-native field definitions is usually more informative than marketing labels.

How a reconstructed order book is built from Level 3 events

A reconstructed order book is built by replaying Level 3 events in the correct order. You maintain an in-memory or stored view of the current visible book state.

The core process is straightforward in concept: start from a known state, apply each add, cancel, modify, and execution in sequence, and update the book after every message. The practical challenge is handling feed edges and exceptional states correctly.

A reliable reconstruction workflow usually begins with a clean starting point such as a venue snapshot or a session boundary defined by the feed. From there, each message updates the active set of visible orders.

Adds put orders into the book at their price and side. Partial executions reduce size, and cancels remove the remaining visible size.

If you ignore resets, sequence gaps, auction states, or book-clear messages, you can produce a book that looks plausible but is wrong in ways that contaminate backtests and execution analysis.

Because reconstruction is stateful, validation and testing are essential. Good practice includes reconciling reconstructed depth to periodic snapshots, simulating edge-case sequences, and instrumenting checks that surface impossible states early.

Worked example: one order from add to partial fill to cancel

A simple order lifecycle shows how message-level state changes work.

Event 1: Add. A buy order with ID 78124 enters at 100.00 for 500 shares. The reconstructed bid book now includes that order at 100.00 with visible size 500.
Event 2: Partial execution. A sell order trades against it for 200 shares. The order remains in the book, but its remaining visible size falls from 500 to 300.
Event 3: Modify or replace. The venue reports a size reduction or a replace event that changes the remaining displayed size from 300 to 250. Your reconstructed book must reflect the venue’s event semantics, not assume every change is a cancel.
Event 4: Cancel. The remaining 250 shares are removed without a trade. The order ID leaves the visible book entirely.

The outcome is straightforward only if messages are applied in the right order. If your system processes the cancel before the partial fill because of bad ordering logic, the reconstructed state becomes inconsistent immediately.

Why sequence numbers often matter more than timestamps

Sequence numbers often matter more than timestamps because reconstruction depends on the exact order the venue says events occurred. Two messages can share the same timestamp resolution, arrive slightly out of order, or be timestamped in ways useful for latency analysis but not sufficient for authoritative book replay.

Using the publisher or exchange sequence as the primary ordering key preserves causality at message granularity. Timestamps remain valuable for measuring delays, aligning datasets, or studying reaction time. But they do not always preserve the event ordering needed for deterministic replay.

This sequencing challenge is one reason operators discussing Level 3 normalization emphasize cleaning and ordering logic. See Optiver/BMLL’s public framing of Level 3 complexity for an example of those practical concerns.

When Level 3 data is worth the cost and complexity

Level 3 data is worth pursuing when your workflow depends on individual order behavior rather than just price-level depth. The strongest cases are workflows where the difference between “1,000 shares at this price” and “five separate visible orders with different event histories” changes the answer in a material way.

Where aggregated depth masks the dynamics you need to model, Level 3 becomes a practical necessity.

For many traders and analysts, Level 2 is enough. If you are evaluating liquidity broadly, monitoring order book pressure, or reviewing execution quality at a coarse level, the jump to message-level data may not justify the engineering burden.

The right decision typically comes from pilot testing a limited dataset against a concrete research or execution question.

Use cases that genuinely benefit from Level 3

Some use cases benefit directly from Level 3 order data because aggregated depth loses the key information:

Queue position modeling: estimating where a passive order might sit relative to visible resting liquidity.
Passive fill simulation: testing whether a limit order would likely have been executed under specific queue assumptions.
Microstructure research: studying cancellation behavior, order replenishment, and short-horizon liquidity dynamics.
Execution analysis: separating adverse selection, queue loss, and visible liquidity withdrawal around trading decisions.
Surveillance and pattern analysis: examining behaviors such as rapid placement and cancellation that may be relevant to spoofing-style pattern detection.

These use cases depend heavily on feed quality, venue semantics, and how much of the order lifecycle is truly visible. Feasibility therefore varies by venue and vendor.

Minimum viable data level by workflow

The useful question is not “What is the richest feed?” but “What is the minimum viable data level for my task?” A compact decision guide looks like this:

Basic market monitoring or signal dashboards: Level 1 is often enough.
Depth awareness, liquidity stacking, and broad DOM analysis: Level 2 is usually the minimum useful level.
Historical depth imbalance studies without order-level queue logic: Level 2 is often sufficient.
Order book reconstruction at the individual-order level: Level 3 is usually required.
Queue position modeling and passive fill simulation: Level 3 is typically the practical minimum.
Cross-venue normalized microstructure research: Level 3 may be needed, but only if normalization quality is strong enough for the comparison.

The takeaway is simple: use Level 3 when the research question breaks under aggregation. Otherwise, lower levels often provide a better cost-to-complexity tradeoff.

What Level 3 data cannot tell you reliably

Level 3 data is powerful, but it is not omniscient. It improves visibility into displayed order flow, not into every source of liquidity, every trading intention, or every venue-specific state transition.

Treat a reconstructed book as a well-informed model of what was visible to that feed. Do not treat it as an exhaustive record of all market interest.

Researchers often overinterpret a reconstructed book as if it were a complete model of supply and demand. In reality, Level 3 usually describes the visible book as represented by a particular feed. It does not automatically include hidden liquidity, off-book trades, or every contextual signal needed to explain why an order appeared and disappeared.

Hidden liquidity, iceberg behavior, and off-book activity

Hidden liquidity is the most obvious limit. If a venue supports non-displayed or partially displayed interest, the visible Level 3 feed may not reveal the full available liquidity at a price.

Iceberg orders can further complicate interpretation because the displayed portion may refresh in ways that are only partly visible from message data. Auction events and non-continuous trading states also introduce semantics that differ from continuous-book behavior.

The practical implication is that even a careful reconstruction can remain incomplete. Analyses that assume a reconstructed book equals total market liquidity will be systematically biased. Where hidden or off-book activity is material, treat results as scenario-based estimates rather than exact counts.

Queue position is modeled, not perfectly observed

Queue position is usually inferred, not directly observed in a perfect sense. Even with order IDs and precise sequencing, you are modeling your place in line from the visible information available, not reading a universal ground-truth queue file from the venue.

Factors that can distort that model include hidden size ahead of you, venue-specific priority rules, replace semantics, timestamp granularity, and normalization that flattens exchange-native detail.

That does not make queue position modeling useless. It means the result should be treated as a probabilistic or scenario-based estimate with explicit assumptions and error bounds, not as an exact historical fact.

Why Level 3 looks different across equities, futures, and crypto venues

Level 3 looks different across equities, futures, and crypto because the feeds are built by different venues with different matching rules, message schemas, and market structure conventions. The term “Level 3” is broad. Implementation details are not standardized enough to assume one dataset behaves like another.

This variation matters for cross-venue comparability and portability of signals.

In equities, you may encounter venue-specific direct feeds and exchange-native order identifiers tied to continuous matching and auction states. In futures, depth and semantics may reflect product-specific matching engines.

In crypto, Level 3 can be available more openly on some venues, but schemas and field meanings vary widely. Public vendor material commonly describes crypto Level 3 as the individual-order view of the book, but open availability does not mean consistent semantics across exchanges. This makes cross-exchange comparison especially sensitive to normalization choices.

Normalization helps, but it can also hide venue-specific meaning

Normalization helps by making datasets easier to query, compare, and load into research systems. For many teams, it is the only practical way to work across multiple venues.

But normalized market data can also hide meaning. If several exchange-native event variants are collapsed into a smaller common vocabulary, some venue-specific nuance disappears with the simplification.

When cross-venue microstructure fidelity matters, prefer datasets or pipelines that preserve exchange-native fields alongside normalized views. That way you can fall back to raw semantics when needed.

Operational realities: storage, replay, validation, and sourcing

Operationally, Level 3 data is not just “deeper Level 2.” It is a heavier data engineering problem. Message counts are high, historical storage grows quickly, and useful analysis often requires deterministic replay rather than ad hoc snapshots.

These factors affect storage format choices, indexing strategy, and testing workflows long before strategy logic is considered.

Replay matters because many questions cannot be answered from end-of-minute or even end-of-second states. If you want to understand queue evolution, liquidity withdrawal around news, or passive fill likelihood, you often need to rebuild the event stream in order.

That requirement drives the need for durable, ordered event logs and robust recovery procedures.

Sourcing is also more complicated than simply buying a file. Depending on venue and vendor, costs can reflect exchange licensing, historical depth, redistribution limits, and the labor needed to normalize or maintain the feed.

Think in terms of cost drivers—coverage, fidelity, latency, and support—rather than fixed prices when evaluating options.

What to validate before trusting a reconstructed book

Before trusting a reconstructed book, validate the mechanics as well as the content:

Sequence continuity: check for gaps, duplicates, and out-of-order messages.
Session boundaries and resets: confirm how the feed signals day starts, book clears, or recovery states.
Crossed or locked book anomalies: identify impossible or suspicious states and determine whether they are real venue conditions or replay errors.
Auction and special-state handling: verify that non-continuous-trading events are not being treated like ordinary adds and fills.
Snapshot alignment: if you use snapshots, confirm they reconcile with replayed event state at known checkpoints.

A reconstructed book is only as trustworthy as its validation logic. Plausible-looking depth is not enough if the underlying event chain is broken.

Buy vs build for Level 3 data

The buy-versus-build decision is usually about operating model more than ideology. Building from raw exchange feeds gives maximum control but also maximum responsibility for parsing, cleaning, normalization, replay, and maintenance.

Buying a normalized dataset reduces that burden but may limit transparency into exchange-native nuance and restrict how you can use or redistribute the data.

A practical evaluation checklist should include:

Venue coverage: do you need one venue, one asset class, or broad cross-venue history?
Schema fidelity: do you need exchange-native detail or is normalized data acceptable?
Latency tolerance: are you doing live low-latency trading, offline research, or both?
Historical replay needs: do you need deterministic event replay at scale?
Engineering capacity: do you have staff for parsers, recovery logic, and ongoing feed changes?
Licensing constraints: can you work within exchange and redistribution terms?

For many teams, the right answer is phased rather than absolute. Start with a narrow use case, test whether Level 3 changes decision quality, and expand scope only if benefits justify the operational burden.

How to decide whether Level 3 market data belongs in your workflow

Level 3 market data belongs in your workflow when the specific question you are asking cannot be answered reliably with aggregated depth. That is the cleanest decision rule.

If your model, backtest, or execution review depends on individual visible order lifecycles, message-level sequencing, or queue dynamics, Level 3 is likely justified. If not, lower data levels often provide a better cost-to-complexity tradeoff.

If your edge comes from macro interpretation, event context, or broad liquidity awareness, lower levels or alternative tools may be more valuable than maintaining a full Level 3 replay stack. Examples include economic calendars, event tagging, and aggregated liquidity metrics. For a product-oriented example that prioritizes market research and event context over execution infrastructure, see MRKT’s economic calendar and MRKT’s disclaimer.

A practical final test is to ask three questions:

Will Level 3 materially change the answer?
Can you validate and maintain the reconstruction properly?
Do the expected research or execution gains outweigh the operational burden?

If the answer to any of those is no, narrow the scope before you buy or build. A sensible next step is to run a small pilot on one venue, one instrument set, and one clearly defined question such as passive fill simulation or queue-loss analysis. If all three answers are yes and the pilot changes your conclusions in a meaningful way, Level 3 data likely belongs in your workflow.