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

-
It depends on which bids came in, if both prices were equal and they represent the best bid then obviously you should aggregate the volumes. Otherwise, you allocate the volumes to the volume at each price level in the book that your new prices matched with. –  Matt Wolf Mar 2 '13 at 4:19
@Freddy my question concerns whether volumes should be aggregated per price or not –  Dmitri Nesteruk Mar 2 '13 at 16:32
@DmitriNesteruk Again, list examples. Don't say, "there is nothing in the feed to indicate who the order came from", since that is true of all exchanges with brokerage MPIDs. Just don't say that; it's tautology. Instead list the specific examples of your feed. –  chrisaycock Mar 3 '13 at 19:48

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. - Thanks, but this is not the way data actually comes in. Data comes in as 'someone canceled their order for 200 shares' and 'deal executed for 100 shares'. – Dmitri Nesteruk Mar 3 '13 at 8:01 @DmitriNesteruk What feed are you taking in? NYSE OpenBook is a level, rather than order, oriented feed. Perhaps you're using that? I don't know any other US equities feed that isn't order based. In which case you're situation might dictate a different design. Your implied above it was an order based feed by stating you had the ability to separate the orders into their aggregate sizes. – Louis Marascio Mar 3 '13 at 13:04 @LouisMarascio, admittedly I am not too knowledgeable about US feeds, but I am confused by your above statement. The link to the OUCH protocol does not point to that being a order-based feed which operates on IDs. Could you please help me to understand? Thanks. – Matt Wolf Mar 3 '13 at 13:36 @Freddy OUCH is used for order entry, not market data. The relevant NASDAQ market data protocol is TotalView ITCH. – Louis Marascio Mar 3 '13 at 13:56 @Freddy NASDAQ, BATS, and DirectEdge all list just the order ID for cancel, replace, and execute. The symbol and side are only listed for the initial new order. – chrisaycock Mar 3 '13 at 14:27 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). - 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\$.