To get the full experience of our online specs, you really need to use something a little bigger. Do you mind firing up your tablet or computer please?
Many trading venues have adopted a market data dissemination protocol known as 'ITCH'. While 'ITCH' is a registered service mark of The Nasdaq OMX Group, unlike the FIX Protocol there is no industry body which publishes an ITCH standard, so FixSpec have created this example specification from our analysis of numerous ITCH specifications in production around the world. Thankfully the venues which have adopted ITCH have re-used similar patterns and identifiers, so while the specifics change, the overall structures and patterns remain consistent.
ITCH messages are fixed-length in nature; fields are not preceeded by a delimiter or tag number like in FIX or SWIFT, but instead their start and end positions are indicated by an offset relative to the start of the message (where the first character has an index of zero), and the length of the field. For example a field with an offset of 4 and a length of 10 means that the field starts from the 5th character you see (remember the first character is zero!), and continues for 10 values. Take a look at the message here for examples.
The ITCH application messages can be transmitted using a variety of TCP protocols, but our analysis indicates that most venues use the SOUP TCP protocol (currently managed by NASDAQ), and it is this SOUP protocol which handles many of the session-related aspects of an interface such as logon, logoff and hearbeat messages. Market data messages themselves are wrapped in a SOUP message for transmission as either Sequenced or Unsequenced packets. In order to provide a clear, easy-to-read specification here, FixSpec present standard SOUP messages for session items and present all market data messages wrapped in Sequenced data packets, which our analysis indicates is a common implementation.
ITCH messages are typically ASCII or hexidecimal encoded. This example specification assumes ASCII message content to assist readability and understanding.
Our analysis found two broad approaches to handling timestamps in ITCH interfaces.
Each of these approaches have their own advantages and disadvantages, but for the purposes of this example specification we assume that our fictitious venue follows the first approach presented above.
Seems this is the only instance of this field in this spec unfortunately.
The field also appears in the following technical messages:
The field also appears in the following functional views:
Want a head start on a new FIX spec using a FIXatdl file?
Import the XML and we'll create a skeleton spec based on the content.
FixSpec.com is FREE website helping the financial services community to connect faster and easier. Registered users get access to an awesome range of developer tools and an ever-expanding specification repository.
Cool! Check your inbox for a password reset link. If you don't receive it, then your email may not be in our records so try registering it instead.
We are so glad you decided to sign up.
We aim to make this website as simple and enjoyable as possible, but if you get stuck at any point or have any suggestions then please get in touch.
Use the "Help" tab on the right, or email us at email@example.com.
To help you find your way around, we've built a short interactive tour of the site.Start the whirlwind tour! (2-3 mins) No thanks, I'll just look around myself.