So I went to NASDAQs ftp site and downloaded the entire ITCH feed for November 9th, 2013. The file was large – 319MB compressed, and you can download it yourself from here:
ftp://emi.nasdaq.com/ITCH/11092013.NASDAQ_ITCH41.gz.
NASDAQ has a very simple document describing the specification here:
http://nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/NQTV-ITCH-V4_1.pdf
I skimmed over the specification to get an idea of how Market Data works. What I basically understand is that at the start of the trading day, NASDAQ sends a list of all securities that will be available to trade for that day following by a bunch of messages indicating changes to prices being offered to buy or sell for the security as well as actual trades.
The basic format of an ITCH 4.1 Market Data message is the size of the message, followed by the data, where the first byte of the data is the message type. So using this information we can easily decode an entire ITCH feed, paying attention only to messages that interest us.
Timestamp Message
| 0x05 | Length |
| 0x54 | Message Type ‘T’ |
| 0x00 | Second – byte 1 |
| 0x00 | Second – byte 2 |
| 0x58 | Second – byte 3 |
| 0xb7 | Second – byte 4 |
The ITCH standard says that all Integer fields are in Big-Endian format, so the timestamp in the message above is interpreted as 0x00 00 58 b7, or 22,711. See a nice online hex to dec converter here:
http://www.binaryhexconverter.com/hex-to-decimal-converter
Now 22,711 is the number of seconds since midnight, here is another online tool to convert this to a normal time in hours, minutes, and seconds:
https://www.tools4noobs.com/online_tools/seconds_to_hh_mm_ss/
So 22,711 is 06:18:31. That is pretty early in the morning, so it looks like this particular NASDAQ ITCH feed starts with pre-market trading.
I also used this online tool to convert ASCII to Hex:
The next message in this feed:
System Event Message
| 0x06 | Length |
| 0x53 | Message Type ‘S’ |
| 0x11 | Timestamp byte 1(nanoseconds since last Timestamp Seconds) |
| 0xcd | Timestamp byte 2 |
| 0x6c | Timestamp byte 3 |
| 0xc9 | Timestamp byte 4 |
| 0x4f | Event Code |
The possible event codes are:
- Daily
- ‘O’ – (0x4f) – Start of Messages
- ‘S’ – (0x53) – Start of System Hours
- ‘Q’ – (0x51) – Start of Market Hours
- ‘M’ – (0x4d) – End of Market Hours
- ‘C’ – (0x43) – End of Messages
- As Needed – In the event of an emergency market condition
- ‘A’ – (0x41) – Emergency Market Condition – Halt
- ‘R’ – (0x52) – Emergency Market Condition – Quote Only Period
- ‘B’ – (0x42) – Emergency Market Condition – Resumption
I included the “As Needed” Event Codes, because that is when things will get real bad, and you will probably want your FPGA to get ready to liquidate everything in your portfolio… More on that in the future, but for now we must stayed focused on trading Trump and his tweets.
So 0x4f means start of messages. Okay, continuing, I see a few more system event messages as well as some Timestamp messages. I skip these for now and come to the next message which sounds interesting and is a Stock Directory Message
Stock Directory Message
| byte # | length | data | description |
| 0 | 1 | 0x14 (decimal: 20) | Length |
| 1 | 1 | 0x52 | Message Type ‘R’ |
| 2-5 | 4 | 1d 48 bd c7 | Timestamp Nanoseconds |
| 6-13 | 8 | 41 20 20 20 20 20 20 20 | Stock (0x20 is a space, 0x41 is A) So this is for Agilent (http://finance.yahoo.com/quote/A?p=A) |
| 14 | 1 | 4e (‘N’) | Market Category – simply the exchange:
|
| 15 | 1 | 20 (space) | Financial Status Indicator – Indicates when a firm is not in compliance with NASDAQ continued listing requirements. This sounds like a way to find distressed stocks that are about to be delisted – lots of volatility with low volume.
|
| 16-19 | 4 | 00 00 00 64
(decimal: 100) |
Round lot size |
| 20 | 1 | 4e (N) | Round lots only – indicates if NASDAQ only accepts orders in round lot size
|
Okay, so we can now decode a couple of message types. But this is not important and is only distracting us from the goal. We can decode all of these messages inside a MicroBlaze Soft Core Processor running embedded C++ inside the FPGA, and then send a message to the rest of the FPGA telling it how to deal with the rest. So let’s keep scanning this Market Data file and find a message that helps us with trading.
I encounter a message of type “Reg SHO Short Sale Price Test Restricted Indicator”. I did some googling and found that Reg SHO is yet another loophole-filled attempt by regulators to prevent naked shorting. My favorite sentence from this Investopedia page http://www.investopedia.com/terms/r/regsho.asp is:
“a broker has reasonable belief that the equity to be short sold can be borrowed and delivered to a short seller on a specific date before short selling can occur”
Anyway, let’s keep scanning this file. I find a message of type ‘H’ – Stock Trading Action Message, this sounds pretty good…
Stock Trading Action Message
| byte # | length | data | description |
| 0 | 1 | 0x13 (decimal: 19) | Length |
| 1 | 1 | 0x48 | Message Type ‘H’ |
| 2-5 | 4 | 1d 50 bd 0d | Timestamp Nanoseconds |
| 6-13 | 8 | 41 42 2d 20 20 20 20 20 | Stock Symbol: AB- |
| 14 | 1 | 0x54 (T) | Trading State
|
| 15 | 1 | 20 (space) | Reserved |
| 16-19 | 4 | 20 20 20 20 | Trading Action Reason – I guess all spaces means “no reason” or “nothing to worry about” |
Okay, so it looks like the Trading Action Message just tells us when trading is officially open…etc. Nothing of use here for the FPGA plan. Anyway, on to the next message type that I find.
I continue running my analysis script and I find the following:
- Add Order with MPID
- Add Order Message
- Order Delete Message
This time I will not analyze the “Add Order with MPID” message unless it appears to have something of use. The Message Type is ‘F’, and it looks like this message will be useful to us. Additionally, MPID stands for “Market Participant Identifier” and appears to simply be your broker. See:
https://www.interactivebrokers.com/en/index.php?f=705
So, here is the analysis:
Add Order with MPID Attribution
| byte # | length | data | description |
| 0 | 1 | 0x22 (decimal: 34) | Length |
| 1 | 1 | 0x46 | Message Type ‘F’ |
| 2-5 | 4 |
02 43 d1 46 |
Nanoseconds portion of timestamp |
| 6-13 | 8 | 00 00 00 00 00 00 16 b2 | Order number – unique and is assigned during order entry |
| 14 | 1 | 0x42 | Type of order
|
| 15-18 | 4 | 00 00 00 64 (decimal: 100) | Number of shares |
| 19-26 | 8 |
5a 56 5a 5a 54 20 20 20 |
The stock symbol:
ZVZZT Funny… this looks like a test symbol, take a look at the Bloomberg quote: |
| 27-30 | 4 |
00 02 97 ac |
Display price, converts to: $16.99 |
| 31-34 | 4 | 4c 45 48 4d | NASDAQ MPID: LEHM (Is that Lehman Brothers?) |
So I am looking at the NASDAQ ITCH 4.1 specification (as you have obviously realized by now) and I see that the order immediately before “Add Order with MPID Attribution” is “Add Order – No MPID Attribution”, which is exactly the same as the message above, but without the last field. The only other difference is that the message type is ‘A’.
A word about Display Price
So the specification says that you convert all Integer price values and treat them as fixed pointed numbers with the first 6 places representing the integer portion and the remaining 4 representing decimal digits, and this leads to a maximum price of 200,000.0000.
So in the example message above:
000297ac is equal to 169900, which is 16.9900, or simply $16.99.
(see http://www.binaryhexconverter.com/hex-to-decimal-converter)
Okay, so we know when the market opens and trading is started, stopped…etc We know when a new order is added to the NASDAQ order book. What is next? Order Delete!
Order Delete is different from Order Cancel. Order Delete means that the entire order is removed or deleted from the Order Book, Order Cancel is whenever a portion of an order is cancelled.
Order Delete Message
| byte # | length | data | description |
| 0 | 1 | 0x0D (decimal: 13) | Length |
| 1 | 1 | 0x44 | Message Type ‘D’ |
| 2-5 | 4 |
21 95 1b cf |
Nanoseconds portion of timestamp |
| 6-13 | 8 |
00 00 00 00 00 00 031 6b |
Order reference number |
Order Cancel Message
| byte # | length | data | description |
| 0 | 1 | 0x (decimal: ) | Length |
| 1 | 1 | 0x58 | Message Type ‘X’ |
| 2-5 | 4 |
21 dd db e1 |
Nanoseconds portion of timestamp |
| 6-13 | 8 |
00 00 00 00 00 25 42 b7 |
Order reference number |
| 14-17 | 4 |
00 00 00 0a |
Number of shares being removed from order. Hmmm… is someone backing out of a position? Scared!!! that means sell! Eh, maybe not, they only removed 10 shares. But what if they are trading a high-priced stock like Amazon or Google? Oops, I meant Alphabet… and what about Berkshire Hathaway? |
Okay, so we have Add Order, Remove Order, Shorten Order. What is left? Order Execute and Order Modify. I will go with Order Executed.
Order Executed Message
| byte # | length | data | description |
| 0 | 1 | 0x19 (decimal: ) | Length |
| 1 | 1 | 0x45 | Message Type ‘E’ |
| 2-5 | 4 |
18 45 cd 07 |
Nanoseconds portion of timestamp |
| 6-13 | 8 |
00 00 00 00 00 00 e9 ca |
Order reference number |
| 14-17 | 4 | 00 00 03 e8 | Number of shares executed |
| 18-25 | 8 |
00 00 00 00 00 00 00 01 |
NASDAQ generated day-unique match number. |
Order Executed with Price Message
| byte # | length | data | description |
| 0 | 1 | 0x1e (decimal: ) | Length |
| 1 | 1 | 0x43 | Message Type ‘C’ |
| 2-5 | 4 |
01 74 a8 ca |
Nanoseconds portion of timestamp |
| 6-13 | 8 |
00 00 00 00 00 00 31 9b |
Order reference number |
| 14-17 | 4 | 00 00 00 64 (decimal: 100) | Number of shares executed. |
| 18-25 | 8 |
00 00 00 00 00 00 03 b0 |
NASDAQ generated day-unique match number. |
| 26 | 1 |
4e |
Printable
|
| 27-30 | 4 |
00 02 9c 5c |
Execution Price: 17.1100, or $17.11 |
I think that I have enough information to get started with the FPGA portion of this. So I will skip analyzing the Order Replace Message for now. So….
We have analyzed the following message types:
- Timestamp Message
- System Event Message
- Stock Directory Message
- Stock Trading Action Message
- Add Order – No MPID Attribution (well, kind of)
- Add Order with MPID Attribution
- Order Delete Message
- Order Cancel Message
- Order Executed Message
- Order Executed with Price Message
What is missing? I am looking at the ITCH 4.1 specification and I see the following message types:
- Order Replace
- Trade Message (Non-Cross)
- Cross Trade Message
- Broken Trade / Order Execution Message
- Net Order Imbalance Indicator (NOII) Message
- Retail Price Improvement Indicator (RPII)
So I can go ahead and analyze the rest of the messages, but I want to get to some coding. Coding as in drawing some LabVIEW program (no, not writing, but drawing). Anyway, I will take a look at how to write (aka draw) some LabVIEW for FPGA code that can handle the parsing and interpreting of the necessary information to react or trade to a Trump Event. Stay tuned.