NSDQ ITCH dump parsing: Low Price & High Price issues

Discussion in 'App Development' started by edmaster, Jul 30, 2015.

  1. edmaster

    edmaster

    I implemented a tool wich parses NSDQ ITCH daily dump files to get some data for my customer. Parsed stock High Price and Low Price are different from http://www.nasdaq.com/symbol/immu/historical data (to compare I used IMMU stock in 01 June 2015 to compare data).
    The reason is two Order Executed Message events which contains too lower price and too higher price. The executions are not cancelled: there are no Broken Trade / Order Execution Message events. The first Order Executed Message event is received before NSDQ opening time, the second before NSDQ closing time (market is opened).

    Can you help to identify which order executions have to be ignored to get correct Low Price and High Price.

    Thanks!
     
  2. @edmaster

    Make sure you do not apply volume/price to your calcs if Printable field is == 'N':

    Printable: Indicates if the execution should be reflected on time and sale displays and volume calculations. “N” = non-printable “Y” = printable

    Also, daily H/L values usually exclude extended hours trades.
     
    edmaster and dvfurlong like this.
  3. edmaster

    edmaster

    THANKS! for really qiuck answer. Order Executed Message event doesn't have Printable flag (Order Executed With Price Message event has Printable flag, but Executed Message event doesn't).
    Order Executed Message event with higher High Price (by official NSDQ historical web site) was recieved before opening. I can ignore it, thanks! But Order Executed Message event with lower Low Price (by official NSDQ historical web site) was received at 5 minutes before 16PM. Is it extended hours execution?
     
  4. No, prior to 16:00 these should be included in regular trading session. ITCH does not provide any flags specifying whether the order is extended hours or not, unfortunately.

    So you use original order's price when you get order executed msg for your high/low calcs?

    And do you process all of Modify/Cancel/Delete/Replace messages?

    There is always a possibility of packet loss since it's a UDP feed. Are all of your sequence numbers correct and do not show any message gaps?