Skip to content
All library documents

Why Order Books Need Order-Level Data Alongside Price Aggregates

Article Quant Q&A · Author: Dmitri Nesteruk

Summary

The document discusses whether orders at the same price should be combined into one displayed quantity or kept as separate records. Its practical recommendation is to retain each active order and its properties, then aggregate quantities by price when an application needs a level-based view. This reflects how many feeds report later cancellations, replacements, and executions by order identifier, requiring the book to locate the original order.

An example shows why the distinction matters: if several bids share a price, a cancellation or execution against one order changes the remaining quantity differently from an update to a single merged total. The answers also note that order sizes may contain information for liquidity analysis, since one large order and many smaller orders with equal combined volume need not represent the same market conditions. The discussion assumes the feed contains order identifiers and relevant message updates; the original question’s stated lack of participant and fill details limits what can be inferred about who traded or what was executed.

Key ideas

  • Keep individual active orders addressable when feed updates refer to them by order identifier.
  • Maintain price-level aggregates separately when an application needs best bid, best ask, or depth by price.
  • A merged quantity can make cancellations and executions ambiguous if the constituent orders are not retained.
  • Order-size patterns may matter to liquidity analysis even when total displayed volume is equal.

Tags

Full text
# Is it worth preserving orderbook structure when building it from individual orders?


# Is it worth preserving orderbook structure when building it from individual orders?












Say I'm building an order book and two bids come in at price $p$ and volumes $v_1$ and $v_2$. Which option is better

- To store the order as $\{p, v_1+v_2\}$ or

- To store the order as $\{p,v_1\}$ and $\{p,v_2\}$ and then manually aggregate orders when I need, say, a `bestBid` value

Is there any analytical insight that can be gained from the actual size of the orders? If there is, can you point me to some literature in this field? Thanks.

Please note: there is nothing in the feed to indicate who the order came from and what order has been filled - all I have are the prices and volumes.

## Answer by Louis Marascio (score 9)

https://quant.stackexchange.com/a/7414

The "correct" way is the way best suited to your trading. Regardless as to your data structure of choice, you have to maintain a list of all orders active on your book. That's because subsequent messages reference Order ID and you have to look up the corresponding order to determine the price level being acted upon.

Given that you have to maintain a reference of all orders and their properties, it makes sense to not aggregate until you need to (at the api level).

## Answer by chrisaycock (score 6)

https://quant.stackexchange.com/a/7415

Louis's answer hints at the problem. Most market-data feed formats only use the order's reference ID for cancel, replace, or execute; they do not list the symbol or side. So you'll need a way to look-up the particular order by ID alone just to make adjustments. You can aggregate by price if your application requires it, but just know that the "level book" will be a separate container from the order book.

Example:

> new order 1: buy IBM $202.91 100 shares new order 2: buy IBM $202.91 200 shares new order 3: buy IBM $202.91 100 shares cancel 2 execute 1

The only way to know that 100 shares are remaining is if you had stored the orders separately.

## Answer by Alexey Kalmykov (score 2)

https://quant.stackexchange.com/a/7412

I have never implemented an order book, but I don't see immediate benefits from this aggregation. If you merge the volumes, then during the actual execution you'll have additionally to take into account that these orders came from different market participants. This seems to add additional complexity to your implementation.

From the point of view of market liquidity measures it makes a difference if you have one large order of volume $v$ or many small orders with total volume $v$.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.