5
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ 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. $\endgroup$
    – Matt Wolf
    Mar 2, 2013 at 4:19
  • $\begingroup$ @Freddy my question concerns whether volumes should be aggregated per price or not $\endgroup$
    – Dmitri Nesteruk
    Mar 2, 2013 at 16:32
  • $\begingroup$ @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. $\endgroup$
    – chrisaycock
    Mar 3, 2013 at 19:48

3 Answers 3

Reset to default
8
$\begingroup$

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

Improve this answer
$\endgroup$
0
5
$\begingroup$

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.

Improve this answer
$\endgroup$
9
  • $\begingroup$ 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'. $\endgroup$
    – Dmitri Nesteruk
    Mar 3, 2013 at 8:01
  • 1
    $\begingroup$ @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. $\endgroup$
    – Louis Marascio
    Mar 3, 2013 at 13:04
  • $\begingroup$ @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. $\endgroup$
    – Matt Wolf
    Mar 3, 2013 at 13:36
  • 1
    $\begingroup$ @Freddy OUCH is used for order entry, not market data. The relevant NASDAQ market data protocol is TotalView ITCH. $\endgroup$
    – Louis Marascio
    Mar 3, 2013 at 13:56
  • $\begingroup$ @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. $\endgroup$
    – chrisaycock
    Mar 3, 2013 at 14:27
2
$\begingroup$

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

Improve this answer
$\endgroup$
3
  • $\begingroup$ Why should I care that the orders come from different participants? If I see an offer for X units and I take it, it's the exchange's responsibility to split my order into several and execute them against the sellers. Right? $\endgroup$
    – Dmitri Nesteruk
    Mar 2, 2013 at 16:30
  • 1
    $\begingroup$ @DmitriNesteruk I assume you are re-cosntructing the order book from a raw message stream data coming from an exchange. Then you should also receive messages that a certain order has been executed and handle them properly. $\endgroup$
    – Alexey Kalmykov
    Mar 2, 2013 at 18:24
  • $\begingroup$ yes, of course, I get that info. The question is whether the microstructure is of any trading benefit whatsoever. I mean, should I be analyzing 'dark liquidity' or just let it be? $\endgroup$
    – Dmitri Nesteruk
    Mar 2, 2013 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.