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

Level 3 market data (also called market-by-order data) is the most granular commonly discussed view of order book activity, showing individual visible orders and the message-level events that affect them — such as adds, cancels, modifications, and executions. Level 3 enables workflows that aggregated feeds cannot support cleanly, including order book reconstruction, queue position modeling, and passive fill simulation, but the extra granularity increases message volume, engineering complexity, and the risk of misinterpreting feed semantics.

• Level 3 goes beyond Level 2's aggregated depth by exposing individual order lifecycles, not just price-level totals

• Naming conventions, exact fields, and event semantics vary by venue, asset class, and vendor — there is no single universal Level 3 schema

• If your workflow depends only on top-of-book quotes or broad liquidity context, Level 2 may be enough

• The practical decision rule: use Level 3 when the research or execution question breaks under aggregation

• A reconstructed order book is only as trustworthy as the validation logic behind it

Overview

Level 3 market data provides the message-level, individual-order view of a trading venue's visible book — sometimes called the order-by-order or market-by-order feed. Where Level 2 typically shows aggregated depth at each price level, Level 3 reveals how that depth is built, consumed, changed, and removed over time through discrete order events.

This page explains what Level 3 data contains, how it differs from Level 1 and Level 2, when it justifies its cost and complexity, what it cannot tell you reliably, and how to evaluate whether it belongs in your workflow. The audience includes traders, quantitative researchers, data engineers, and operations teams evaluating market data infrastructure.

The extra granularity matters because it enables analysis — such as queue position modeling and passive fill simulation — that depends on individual order sequencing rather than static depth snapshots. At the same time, Level 3 raises the bar for storage, replay, validation, and interpretation. The right question is often not "Do I want the richest data?" but "What is the minimum data level that supports a trustworthy answer?"

Level 1, Level 2, and Level 3: 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 — observation granularity rather than three separate markets. The distinction matters because each level changes what you can observe and what inferences are realistic.

Level 1 usually provides 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: 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 with its own identifier and event history.

That change matters for workflows that depend on order sequencing rather than static depth snapshots. Queue modeling, passive fill simulation, and microstructure research can 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 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. 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 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 — and also why normalized datasets can sometimes smooth away details that matter for precise research.

Message Types That Change the Book

A generic Level 3 feed often revolves around a small set of book-changing events. Exact names vary by venue and vendor, 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 (sometimes abbreviated MBO) is often used as a near-synonym for Level 3 because both generally refer to individual visible orders rather than aggregated price-level depth. 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. Inspecting the actual schema and event semantics — order IDs, replace semantics, and aggressor flags — is safer than relying 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, maintaining 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.

Ignoring resets, sequence gaps, auction states, or book-clear messages 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:

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.

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.

3. Modify or replace. The venue reports a size reduction or a replace event that changes the remaining displayed size from 300 to 250. The reconstructed book must reflect the venue's event semantics, not assume every change is a cancel.

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.

Common failure modes in order book reconstruction: Processing events out of sequence (e.g., applying a cancel before a partial fill) causes immediate state inconsistency Ignoring resets, sequence gaps, or book-clear messages produces a book that looks plausible but drifts from the venue's actual displayed state Treating non-continuous-trading events (auctions, halts) like ordinary adds and fills introduces silent errors Confusing a feed artifact with real market behavior when venue semantics are not well understood

Why Sequence Numbers Often Matter More Than Timestamps

Sequence numbers often matter more than timestamps for reconstruction because replay 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. For an example of how these practical concerns are framed publicly, see Optiver/BMLL's published perspective on Level 3 complexity.

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 price-level depth alone. 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 Can 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?"

The takeaway: 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 improves visibility into displayed order flow, but it is not omniscient. It does not automatically include hidden liquidity, off-book trades, or every contextual signal needed to explain why an order appeared and disappeared. A reconstructed book is best understood as a well-informed model of what was visible to that feed, not as an exhaustive record of all market interest.

Researchers can 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.

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 (orders with a visible portion that refreshes after execution) 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.

Even a careful reconstruction can remain incomplete. Analyses that assume a reconstructed book equals total market liquidity can 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 venues 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

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.

Key evaluation criteria:

• 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 of such alternative tools include economic calendars, event tagging systems, and aggregated liquidity metrics — tools that prioritize market research context over execution-grade order data. For a product-oriented example of this distinction, MRKT's economic calendar focuses on market research and event context rather than execution infrastructure (see MRKT's disclaimer for scope).

A practical final test is to ask three questions:

1. Will Level 3 materially change the answer?

2. Can you validate and maintain the reconstruction properly?

3. 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.

Frequently Asked Questions

What is Level 3 market data? Level 3 market data is the most granular commonly discussed view of order book activity, showing individual visible orders and the message-level events that affect them — such as adds, cancels, modifications, and executions. It goes beyond Level 2's aggregated depth by exposing order lifecycles rather than just price-level totals.

How does Level 3 differ from Level 2? Level 2 typically shows resting size at multiple price levels in aggregated form. Level 3 exposes the individual visible orders that make up that aggregated size, each with its own identifier and event history. The key difference is message-level order visibility versus price-level depth snapshots.

Who needs Level 3 market data? Level 3 is most relevant for workflows that depend on individual order behavior — such as queue position modeling, passive fill simulation, microstructure research, execution analysis, and surveillance. If your work requires only top-of-book quotes or broad liquidity context, Level 2 may be sufficient.

Is Level 3 the same as market-by-order data? 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 depth. However, the terms are not perfectly interchangeable across every exchange, vendor, or asset class. Inspecting the actual schema and event semantics is safer than relying on the label alone.

What can Level 3 data not tell you? Level 3 data describes the visible book as represented by a particular feed. It does not automatically include hidden liquidity, off-book trades, or the full available liquidity at a price when a venue supports non-displayed interest. Queue position is modeled from visible information, not read from a universal ground-truth source.

Does Level 3 data look the same across asset classes? No. 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. The term "Level 3" is broad, and implementation details are not standardized enough to assume one dataset behaves like another.

What are common mistakes in order book reconstruction from Level 3 events? Common mistakes include processing events out of sequence, ignoring resets or book-clear messages, treating auction states like ordinary continuous trading, and confusing feed artifacts with real market behavior. Each of these can cause the reconstructed book to drift from the venue's actual displayed state.

Should I buy or build my Level 3 data infrastructure? The decision depends on operating model. Building from raw exchange feeds gives maximum control but requires staff for parsers, recovery logic, and ongoing maintenance. Buying a normalized dataset reduces that burden but may limit transparency into exchange-native nuance. Many teams start with a narrow pilot before committing to a full build.