M I T 3 0 3 – B I T - M I L L E N N I U M E X C H A N G E ... · 7 Section 4.1.1.1 Section...

M I T 3 0 3 – B I T - M I L L E N N I U M E X C H A N G E

Level 2-ITCH Specification

Issue 2.0 · October 2011

Contents

1 Introduction .......................................................................... 5

1.1 Purpose .......................................................................................... 5

1.2 Readership ..................................................................................... 5

1.3 Document series ............................................................................ 6

1.4 Document history ........................................................................... 6

1.5 Enquiries ........................................................................................ 7

2 System Architecture ............................................................. 8

2.1 Real-Time Channel ........................................................................ 8

2.2 Replay Channel ............................................................................. 9

2.3 Recovery Channel ......................................................................... 9

3 Connectvity ......................................................................... 10

3.1 Transmission Standards .............................................................. 10 3.1.1 Multicast Channels ........................................................................... 10 3.1.2 Replay and recovery Channels ........................................................ 10 3.1.3 CompIDs .......................................................................................... 10

3.2 Production IP Addresses and Ports ............................................. 10

3.3 Failure and Recovery ................................................................... 10

4 Recovery ............................................................................. 12

4.1 Recipient Failures ........................................................................ 12 4.1.1 Replay Channel................................................................................ 12 4.1.2 Recovery Channel ............................................................................ 14

4.2 Failures at the Exchange ............................................................. 25 4.2.1 Snapshots on the Real-time channel ................................................ 25 4.2.2 Resetting Sequence Numbers .......................................................... 26

5 Message Formats ............................................................... 27

5.1 Packet Composition ..................................................................... 27

5.2 Sequence Numbers ..................................................................... 27

5.3 Timestamps ................................................................................. 27

5.4 Data Types ................................................................................... 28 5.4.1 Administrative Messages ................................................................. 28 5.4.2 Application Messages ...................................................................... 29

5.5 Unit Header .................................................................................. 31

5.6 Administrative Messages (Client – Initiated) ................................ 32

3

5.6.1 Login Request .................................................................................. 32 5.6.2 Replay Request................................................................................ 32 5.6.3 Snapshot Request ............................................................................ 32 5.6.4 Logout Request ................................................................................ 33

5.7 Administrative Messages (Server – Initiated) ............................... 34 5.7.1 Heartbeat ......................................................................................... 34 5.7.2 Login Response ............................................................................... 34 5.7.3 Replay Response ............................................................................. 34 5.7.4 Snapshot Response ......................................................................... 35 5.7.5 Snapshot Complete .......................................................................... 36

5.8 Application Messages .................................................................. 38 5.8.1 Time ................................................................................................. 38 5.8.2 System Event ................................................................................... 38 5.8.3 Symbol Directory .............................................................................. 39 5.8.4 Symbol Status .................................................................................. 40 5.8.5 Add Order ........................................................................................ 42 5.8.6 Add Attributed Order ........................................................................ 43 5.8.7 Order Deleted .................................................................................. 44 5.8.8 Order Modified ................................................................................. 45 5.8.9 Order Book Clear ............................................................................. 46 5.8.10 Order Executed ................................................................................ 46 5.8.11 Order Executed with Price / Size ...................................................... 46 5.8.12 Trade ............................................................................................... 47 5.8.13 Auction Trade ................................................................................... 48 5.8.14 Off-Book Trade ................................................................................ 49 5.8.15 Trade break ...................................................................................... 52 5.8.16 Auction Info ...................................................................................... 54 5.8.17 Statistics .......................................................................................... 55 5.8.18 Recovery Trade................................................................................ 57 5.8.19 Announcements ............................................................................... 59 5.8.20 Daily Schedule ................................................................................. 60

6 Data Mapping ...................................................................... 65

6.1 Conversion of Order ID ................................................................ 65 6.1.1 Order ID format (in binary) ............................................................... 65 6.1.2 Order ID format (in ASCII) ................................................................ 65

6.2 Conversion of Trade ID ................................................................ 67 6.2.1 Trade ID format (in binary) ............................................................... 67 6.2.2 Trade ID format (in ASCII) ................................................................ 67

7 Trading Halt Reasons ......................................................... 70

8 Order book scenarios ........................................................ 71

8.1 Order book scenarios for instrument ............................................ 71

8.2 Order book scenarios for segment ............................................... 71

4

Disclaimer The London Stock Exchange Group has taken reasonable effort to ensure that the information contained in this publication is correct at the time of going to press, but shall not be liable for decisions made in reliance on it. The London Stock Exchange Group will always endeavour to provide notice to customers of changes being made to this document, but this notice cannot always be guaranteed. Therefore, please note that this publication may be updated at any time. The information contained is therefore for guidance only.

5

1 Introduction Borsa Italiana will provide the Level 2-ITCH protocol enabling clients to receive real-time data at lowest possible latencies.

The Level 2-ITCH market data feed is a stream of fixed width binary messages which provides the following real-time information for each instrument traded on Borsa Italiana markets.

(i) The full depth for the electronic order book; the feed provides information on the side, price and displayed quantity of each order in the order book.

(ii) Price and volume for each executed on-book trade.

(iii) Price, volume, trade type, date and time of each confirmed off-book trade.

(iv) Indicative auction price and the associated trade volume and imbalance.

(v) Official opening and closing price as well as previous day’s closing price, static reference price and dynamic reference price.

(vi) Instrument trading status.

(vii) Announcements

(viii) Daily Schedules.

The feed also provides a daily download of the instrument list of Borsa Italiana markets.

1.1 Purpose The purpose of this document is to provide a technical description of the Level 2-ITCH Service available on the Millennium Exchange platform, including message types and fields.

1.2 Readership This document outlines the detailed message types and fields for the Level 2-ITCH feed as well as details on how to connect to the Replay and Recovery services available on Millennium Exchange. When read in conjunction with the other Millennium Exchange guides, it is intended that these documents provide all of the details directly connected Borsa Italiana customers require to develop to the new services. This document is particularly relevant to technical staff within Borsa Italiana’s member firms, information vendors and other market participants interested in receiving Borsa Italiana market data.

6

1.3 Document series This document is part of a series of documents which provide an overview of the trading and information services available from the Borsa Italiana post the migration to Millennium Exchange. For reference the full range of documents is outlined below: Trading

• MIT201 BIT – Guide to New Trading System • MIT202 BIT – FIX Trading Gateway (FIX 5.0) • MIT203 BIT – Native Trading Gateway Specification • MIT204 BIT – Post Trade Gateway (FIX 5.0) Specification • MIT205 BIT – Drop Copy Gateway (FIX 5.0) Specification

Market Data Services

• MIT301 BIT – Guide to Market Data Services • MIT303 BIT – Level 2-ITCH Specification (this document) • MIT305 BIT – Markets Reference Data and FTSE indices constituents

This series principally covers non-regulatory information and does not override or supersede the Rules of Borsa Italiana Exchange. The latest version of this document series can be found at the following links: Italian Version:

http://www.borsaitaliana.it/borsaitaliana/intermediari/gestione-mercati/migrazionemillenniumit-mit/millenniumitmigration.htm

English Version:

http://www.borsaitaliana.it/borsaitaliana/intermediari/gestione-mercati/migrazionemillenniumit-mit/millenniumitmigration.en.htm

1.4 Document history This document has been through the follow iterations:

Issue Date Description

1.0 August 2011 First issue of this document published via the Borsa Italiana’s website and distributed to customers.

2.0 September 2011 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

The changes are applied in the following sections:

7

Section 4.1.1.1 Section 4.1.2.3 Section 5.4 Section 5.7.2 Section 5.7.5 Section 5.8.3 Section 5.8.17 Section 7

In subsequent issues, where amendments have been made to the previous version, these changes will be identified using a series of side bars as illustrated opposite.

1.5 Enquiries Please contact either Client Technology Services or your Technical Account Manager if you have any functional questions about the Millennium Exchange services outlined in this document. Client Technology Services (ITA) can be contacted at:

• Telephone: +39 0272426409 - 348 – 606 – 647

• Service Desk Free Toll Number: 00800 26772000

• Email: [email protected] ; [email protected]

8

2 System Architecture The market data feed is load balanced by market data group.

While each group will contain multiple instruments, each instrument is assigned to just one market data group. Although the group an instrument is assigned to may change from interday, it will not change intraday.

Each market data group is disseminated on a dedicated multicast market data channel.

Two TCP recovery channels are available per market data group: Replay and Recovery.

While a recipient may connect to the Replay channel to recover from a small data loss, it should use the Recovery channel after a large data loss (i.e. late joiner or major outage).

2.1 Real-Time Channel

The Real-Time channel is the primary means of disseminating market data. Real-time updates to instruments and all market data supported by the feed are available on this multicast channel.

The list of active instruments in the market data group is broadcast at the start of the trading day. The details of instruments created during trading hours as well as updates of the trading status of instruments are also disseminated.

Real-time updates to order books and indicative auction information are published along with the details of each trade. The official opening and closing price of each instrument as well as previous day’s closing price will also be disseminated on this channel. The initial static and dynamic reference prices as well as updates to static reference price will also be disseminated.

9

Level 2-ITCH will also broadcast any announcements made by Market Supervision and any changes to an instrument’s trading schedule. Each application message includes a sequence number which is incremented by one for every message disseminated on the Real-Time channel within a particular market data group. The sequence numbers of each is reset to 1 at the start of each day.

During periods of inactivity the market data channel will broadcast a Heartbeat message. Heartbeat messages maintain will be sent at constant intervals and exercise communication between a client application and Millennium Exchange.

Recipients have access to two identically sequenced Real-Time feeds: one from the Primary site (Primary Feed) and one routed via the Secondary site (Secondary Feed) Recipients may process both feeds and arbitrate between them to minimise the probability of a data loss. The secondary feed will be subject to additional minimal latency as it is routed via the Secondary Data Centre.

2.2 Replay Channel The TCP Replay channel permits recipients to request the retransmission of a limited number of messages already published on the Real-Time channel. This channel may be used by recipients to recover from a small data loss.

The Replay channel supports the retransmission of the last messages published on the Real-Time channel. The channel does not support the retransmission of messages published on the Recovery channel or from previous trading days.

During normal service the replay service will only be available on the Primary feed. The Secondary feed replay service is only available in the event of a failure of the Primary feed.

2.3 Recovery Channel The TCP Recovery channel permits recipients to request a snapshot of the order book for any active instrument in the market data group. This channel may be used by recipients to recover from a large-scale data loss.

While a Recovery channel is available from the Secondary feed, it will only be activated in the unlikely event of a Primary feed failure.

10

3 Connectvity

3.1 Transmission Standards

3.1.1 Multicast Channels

The multicast channel utilises UDP over IP version 4 (IPv4) Ethernet standards. UDP header information is as defined in the IETF RFC 791 (IPv4) and RFC 768 (UDP) transmission standards. Each UDP packet will contain just one Unit Header.

3.1.2 Replay and recovery Channels

The Recovery and Replay channels utilise TCP over IP version 4 (IPv4) Ethernet standards. TCP header information is as defined in the IETF RFC 793 standard and IPv4 is as defined in the RFC 791 standard.

3.1.3 CompIDs

The CompID of each client wishing to connect to the Recovery and Replay channels must be registered with the Borsa Italiana before communications can begin. Each CompID will be assigned a password on registration. The same CompID could be used to login to Recovery and Replay channels across market data groups. A client could also use the same CompID to login to the Recovery and Replay Channels of both FAST and Level 2-ITCH feeds. Whilst the same CompID can be used across multiple replay and recovery service, a CompID can only be logged into one service at any one time.

3.1.3.1 Passwords

Each new CompID will be assigned the password mit_1234 on registration.

3.2 Production IP Addresses and Ports The feed is load balanced by market data group. The Symbol Directory messages available on the Real-Time channel of the various market data groups may be utilized by recipients to identify the instruments assigned to each group. The Borsa Italiana reference data package will also identify the channel to which an instrument is assigned.

3.3 Failure and Recovery Borsa Italiana will provide full component resiliency at the Primary data centre. For all TCP/IP connections clients will be given IP addresses for the Primary/feed and for the Secondary/feed.

11

On unexpected disconnection from the Production feed gateway a client should try to reconnect 3 times to the primary gateway with a time out value of three seconds on each connection before attempting to connect to the Production Site secondary feed gateway. Upon successful connection to the Secondary feed gateway, clients should treat this gateway as master. Clients should continue to do this until a time when the Secondary feed gateway becomes unavailable. If this gateway becomes unavailable, clients should attempt to reconnect to the Primary feed gateway. Should this also be unavailable, clients should contact the Exchange for guidance.

Clients should use the Production Site pair until directed that a site failover has been invoked – this will be clearly communicated to clients. Following this site failover, the Secondary site pair of gateways should be used as above; clients should connect using the same IP addresses as employed at the Primary Site.

12

4 Recovery

4.1 Recipient Failures Recipients have access to two identically sequenced multicast feeds: Primary feed and Secondary feed. Recipients may process both feeds and arbitrate between them to minimise the probability of a data loss.

If a gap in sequence numbers is detected on the multicast channel, the recipient should assume that some or all of the order books maintained on its systems are incorrect and initiate one of the recovery processes outlined below.

4.1.1 Replay Channel

The TCP Replay channel should be used by recipients to recover from a small-scale data loss. It permits clients to request the retransmission of a limited number of messages already published on the multicast channel. The channel could be configured to support the retransmission of the last messages published.

Each CompID may login to the Replay channel of a particular market data group up to a limited number times each day. The total number of Replay Requests that a client may send for a particular market data group is also limited. Recipients may request the Exchange to reset its login and request counts. This feature is intended to help manage an emergency situation and should not be relied upon as a normal practice. If a client submits multiple requests on the Replay channel, they will be processed serially (i.e. one at a time). Clients are unable to cancel outstanding Replay Requests.

4.1.1.1 Establishing a Connection

The client should use the relevant IP address and port to establish a TCP/IP session with the Replay channel. The client should initiate a session by sending the Login Request message. The client should identify itself by specifying its CompID in the Username field. The server will validate the CompID, password and IP address. Once the client is authenticated, the server will respond with a Login Response message with the Status “A”. If a logon attempt fails because of an invalid CompID or invalid password or IP address or if a message is sent prior to the login being established, the server will break the TCP/IP connection with the client without sending a Login Response message.

13

If a client has exceeded the number permitted of log-ons for the current day, the server will reject any new logon attempt with a Login Response and then break the TCP/IP connection. The Status of such a Login Response message will be “b”. If a Login Request is not received within 5 seconds of the establishment of a TCP/IP connection or a Replay Request is not received within 5 seconds of a successful logon, the server will break the TCP/IP connection with the client.

A logon attempt to the Replay channel made by an already logged in client will receive a Replay Response Message with Status = e (Failed (Other)).

4.1.1.2 Heartbeats

The server will not send heartbeats on the Replay channel during periods of inactivity.

4.1.1.3 Requesting Missed Messages

Once connected to the Replay channel, clients may use the Replay Request message to request the retransmission of missed messages. The request should include the sequence number of the first message in the range to be retransmitted along with the number of messages to be retransmitted. The retransmission request will be serviced from the server’s cache of the last messages published on the multicast channel. If the retransmission request includes one or more messages that are not in the server’s cache, the entire request will be rejected and no messages will be retransmitted.

4.1.1.4 Response to a Retransmission Request

The server will respond to the Replay Request with a Replay Response message to indicate whether the retransmission request is successful or not. A Status other than “A” will indicate that the request has been rejected.

In the case of a successful request, the server will retransmit the requested messages immediately after the Replay Response. The sequence numbers of the retransmitted messages will be the same as when they were first disseminated on the multicast channel. The framing of the replayed messages inside of Unit Headers may differ between the original transmission and the retransmission.

4.1.1.5 Termination of the Connection

If the client does not send a Logout Request and terminate the connection within 5 seconds of the retransmission of the last missed message, the server will break the TCP/IP connection with the client.

14

4.1.2 Recovery Channel

The TCP Recovery channel should be used by recipients to recover from a large-scale data loss (i.e. late joiner or major outage). It permits clients to request a snapshot of the order book for the active instruments in the market data group. Each CompID may login to the Recovery channel of a particular market data group a limited number of times each day. The total number of Snapshot Request messages that a client may submit for a particular market data group is also limited. Recipients may request the Exchange to reset its login and request counts. This feature is intended to help manage an emergency situation and should not be relied upon as a normal practice.

If a client submits multiple requests on the Recovery channel, they will be processed serially (i.e. one at a time). Active requests of multiple clients will be served on a round robin basis. Clients are unable to cancel outstanding Snapshot Requests.

4.1.2.1 Establishing a connection

The client should use the relevant IP address and port to establish a TCP/IP session with the Recovery channel. The client should initiate a connection by sending the Login Request message. The client should identify itself by specifying its CompID in the Username field. The server will validate the CompID, password and IP address of the client. Once the client is authenticated, the server will respond with a Login Response message with the Status “A”. The client must wait for the server’s Login Response before sending additional messages. Messages received from the client before the exchange of logons will be ignored. If a logon attempt fails because of an invalid CompID or IP address or if a message is sent prior to the login being established, the server will break the TCP/IP connection with the client without sending a Login Response message.

If a logon attempt fails because of an invalid password, a locked CompID or if logins are not currently permitted, the server will send a Login Response and then break the TCP/IP connection with the client. If a client has already exceeded the number of permitted log-ins for a particular day, the server will reject any new logon attempt with a Login Response and then break the TCP/IP connection. The Status of such a message will be “b”.

If a Login Request is not received within 5 seconds of the establishment of a TCP/IP connection or a Snapshot Request is not received within 5 seconds of a successful logon, the server will break the TCP/IP connection with the client. A logon attempt to the Recovery channel made by an already logged in client will receive a Replay Response Message with Status = e (Failed (Other)).

15

4.1.2.2 Heartbeats

The server will not send heartbeats on the Recovery channel during periods of inactivity.

4.1.2.3 Requesting Order Book Snapshots

Once connected to the Snapshot channel, clients may use the Snapshot Request message to download the list of active instruments, request a snapshot of an order book, statistics or trading status or download the trades published during the last (a configurable time on the Central System) minutes. The Snapshot Type field of the message should be used to indicate the nature of the request.

The server will transmit Error! Reference source not found. to indicate whether the request is accepted or rejected. A Status other than “A” will indicate that the request is rejected.

If the request is successful, a series of application messages (e.g. Add Order, Symbol Directory, Recovery Trade, etc.) will then be disseminated to serve the request.

A Snapshot Complete message will be sent once all application messages have been transmitted in response to a request. Snapshot Complete messages may also be sent prior to the final Snapshot Complete to indicate that all messages relating to a particular sub book or instrument have been transmitted.

A Snapshot Request may optionally include a Request ID which, if specified, will be included in each Error! Reference source not found. and Snapshot Complete sent in response to it.

4.1.2.4 Instrument List

A Snapshot Request with a Snapshot Type of Instrument (2) may be used to request the details of all active instruments in the market data group or those in the group from a particular segment. The request will be deemed as one for all instruments if it does not contain a value in the Segment field. The Sequencer Number, Instrument ID, Sub Book and Last Trade Time fields of the request will be ignored by the server.

The server will send a Snapshot Response to indicate whether the request is accepted or rejected. The Sequence Number and Order Count fields of this message should be ignored.

If the request is successful, the server will then disseminate a series of Symbol Directory messages. Each such message will provide the details of a requested instrument.

The server will transmit a Snapshot Complete once the details of all instruments are disseminated. The message will include the appropriate value in the Segment field if the request was for a particular segment. The Sequence Number, Instrument ID, Sub Book and Trading Status fields of the message should be ignored.

The Snapshot Complete will be immediately followed a Snapshot Complete if there are no active instruments for the specified segment.

16

4.1.2.5 Order Book Snapshots

Once connected to the Recovery channel, clients may use the Snapshot Request message to request a snapshot of the current order book for all instruments in a specified segment or for a particular instrument. If a client specifies both the Segment and the Instrument ID in the Snapshot Request message, it will be taken as a request for the stated segment. The request should include the sequence number from which the client can build its order books. But the sequence number that is stated in the Snapshot Request message will be ignored, and the current snapshot of the order book will be sent regardless of the sequence number that is sent.

4.1.2.6 Response to a Snapshot Request for an Instrument

The server will transmit a Snapshot Response to indicate whether a Snapshot Request for an Instrument is accepted or rejected. A Status other than “A” will indicate that the request is rejected. The Sequence Number and Order Count fields of the Snapshot Response will be zero if the request is accepted or rejected.

If the request is successful, the server will disseminate a snapshot of the current order book for the requested instrument via series of Add Order and Add Attributed Order messages. Each such message will represent a single active order and will not include a sequence number. If a particular price point contains multiple orders, they will be disseminated in terms of their time priority (i.e. the oldest order first). Once order book details are served a Symbol Status message will be sent indicating the trading status of the book. The Symbol Status message sent as a response to the Snapshot Request will contain value 9 in the field “Session Change Reason”.

The server will transmit the Snapshot Complete message once the details all active orders for the instrument’s order book are disseminated. The message will include the sequence number with which the order book snapshot was synchronised and the instrument to which it relates. The client may begin processing the buffered messages for the instrument from the Real-Time channel once the order book snapshot is processed.

In a situation where the instrument has an empty order book, the system should respond with a Symbol Status message coupled with a Snapshot Complete message, while only a Snapshot Complete message is to be expected if the instrument has no on book definition attached.

If a Snapshot Request is made for an instrument (suspended or not) before the first tradable session, the Snapshot Complete message sent in response will contain

value zero in the sequence number field. Snapshot Request for Suspended Instruments:

If a Snapshot Request is sent for an instrument which is suspended before the first tradable session indicated to the client, the Snapshot Complete message sent in response will contain value zero in the sequence number field.

However if the instrument is suspended after the first tradable session and a Snapshot Request is sent for the instrument, the Snapshot Complete message sent in response will contain the sequence number it synchronises with, in the real time channel.

17

The Trading Status field in the Symbol Status message sent for the order book of the suspended instrument (except for the off book) will contain a null value.

4.1.2.7 Response to a Snapshot Request for a Segment

The server will transmit a Snapshot Response to indicate whether a Snapshot Request for a segment is accepted or rejected. A Status other than “A” will indicate that the request is rejected. The Sequence Number and Order Count fields of the Snapshot Response will be zero whether the request is accepted or rejected.

If the request is successful, the server will disseminate a snapshot of the current order book for all instruments in the requested segment via series of Add Order and Add Attributed Order messages. Each such message will represent a single active order and will not include a sequence number. If a particular price point contains multiple orders, they will be disseminated in terms of their time priority (i.e. the oldest order first). Once order book details are served a Symbol Status message will be sent indicating the trading status of the book respectively. The Symbol Status message sent as a response to the Snapshot Request will contain value 9 in the field “Session Change Reason”.

Order book snapshots for the requested instruments will be transmitted serially (i.e. one instrument at a time). The server will transmit a Snapshot Complete message once the details all active orders for a particular instrument’s order book are disseminated. This message will include the sequence number with which the order book snapshot for the instrument was synchronised. While such a Snapshot Complete will include the instrument to which it relates, it will not include a value in the Segment field. The client may begin processing the buffered messages for the instrument from the Real-Time channel once its order book snapshot is processed.

The server will also transmit a Snapshot Complete message once the details all active orders for all instruments in the requested segment are disseminated. The Sequence Number field of the message will be zero. While the final Snapshot Complete will include an indication of the segment to which it relates, it will not include a value in the Instrument ID field.

In a situation where one or more instruments in a segment do not have the requested market data (e.g. requesting order book snapshot for an instrument which has only off book definition attached) the system should send the market data for the instruments where the data is available and not send any response for the instruments which do not have the requested market data. A Snapshot Complete message will be sent at the end of serving the requested messages and this will impliedly indicate to the user that some instruments did not have the requested market data.

If all the instruments in the segment do not have the requested market data, only a Snapshot Complete message would be sent.

In a situation where one or more instruments in a segment have empty order books, the system sends a Symbol Status message followed by a book level Snapshot Complete message for the instruments with empty order books. The system will send the relevant market data followed by the Symbol Status and the book level Snapshot Complete message for the other instruments. A segment level Snapshot Complete message will be disseminated at the end of serving the request

18

If a Snapshot Request is made for a segment before the first tradable session, the Snapshot Complete messages sent in response for each instrument will contain value zero in the sequence number field.

Snapshot Request for Suspended Instruments

If a Snapshot Request is sent for a segment where one or more of its instruments are suspended before the first tradable session is indicated to the client, the Snapshot Complete message sent in response to the suspended instrument will contain value zero in the sequence number field.

However if the instrument or instruments of the segment are suspended after the first tradable session and a Snapshot Request is sent for the segment, the Snapshot Complete message sent in response for the suspended instrument will contain the sequence number it synchronises with, in the real time channel.

The Trading Status field in the Symbol Status message sent for each book of the suspended instrument (except for the off book) will contain a null value.

4.1.2.8 Statistics Snapshots

Statistics are maintained per sub book of an instrument (i.e. regular or off-book). A Snapshot Request with a Snapshot Type of Statistics (4) may be used to request a snapshot of the statistics for one of the following:

(i) All sub books for all instruments in a specified segment.

(ii) All sub books for a single instrument.

(iii) Multiple sub books for a single instrument.

(iv) A single instrument and sub book combination.

The request will be deemed as one for a segment if it contains a value in the Segment field (the contents, if any, of the Instrument ID and Sub Book fields will be ignored). It will be deemed as one for all sub books of an instrument if it only contains a value in the Instrument ID field.

As the server currently only supports statistics for the regular book, the results of a statistics request for all sub books for a particular instrument and the regular book of the instrument will be identical. A statistics request that includes the off-book sub book will be rejected.


If the request is successful, the server will then disseminate a snapshot of the statistics for each requested sub book via a series of Statistics messages. A separate message will be published for each type of statistic (e.g. opening price, closing price, previous day’s closing price, static reference price, dynamic reference price etc.).

19

Statistics snapshots for the requested sub books will be transmitted serially (i.e. one sub book at a time). The server will transmit a Snapshot Complete once all statistics for a particular sub book are disseminated. The message will include the sequence number of the Real-Time channel with which the statistics snapshot was synchronized and the instrument and sub book to which it relates. It will also include the current trading status of the sub book. The client may begin processing the buffered messages for the instrument from the Real-Time channel once the statistics snapshot is processed. The Segment field of the message should be ignored. Just a Snapshot Complete will be transmitted for a sub book if there are no statistics for it (i.e. no trades for the day).

In the case of segment-level request, the server will also transmit a Snapshot Complete message once the statistics for all sub books in the requested segment are disseminated. This final Snapshot Complete will include an indication of the segment to which it relates. The Sequence Number, Instrument ID, Sub Book and Trading Status fields of the message should be ignored.

4.1.2.9 Missed Trades

A Snapshot Request with a Snapshot Type of Trades (3) may be used to request missed trades for all instruments in a particular segment or for a single instrument. The ability to request missed trades for a particular instrument and sub book combination is not currently available1. The request should include the sending time of the last trade on the Real-Time channel processed by the client in the Last Trade Time field. The request will be deemed as one for a segment if it contains a value in the Segment field (the contents, if any, of the Instrument ID field will be ignored).

The server only caches the trades published during the last minutes on the Real-Time channel. If the request includes a Last Trade Time that is prior to that of the oldest trade in the server’s cache, all eligible trades in the cache will be retransmitted. Clients are unable to recover trades not in the server’s cache.


If the request is successful, the server will then disseminate the continuous trades, auction trades, off-book trades and trade cancellations missed by the client via a series of Recovery Trade messages.

Trades for the requested instruments will be transmitted serially (i.e. one instrument at a time). The server will transmit a Snapshot Complete once all trades for a particular instrument are disseminated. The message will indicate the instrument to which it relates. The Sequence Number, Segment, Sub Book and Trading Status fields of the message should be ignored. Just a Snapshot Complete will be transmitted for an instrument if there are no trades for it in the server’s cache.

In the case of segment-level request, the server will also transmit a Snapshot Complete message once trades for all instruments in the requested segment are disseminated. This final Snapshot Complete will include an indication of the segment

1 The Sub Book field is ignored by the server if the Snapshot Request is for missed trades.

20

to which it relates. The Sequence Number, Instrument ID, Sub Book and Trading Status fields of the message should be ignored.

4.1.2.10 Trading Status

Trading status is maintained per sub book of an instrument (i.e. regular or off-book). A Snapshot Request with a Snapshot Type of Symbol Status (1) may be used to request the trading status for one of the following:

(i) All sub books for all instruments in a specified segment.

(ii) All sub books for a single instrument.

(iii) Multiple sub books for a single instrument.

(iv) A single instrument and sub book combination.

The request will be deemed as one for a segment if it contains a value in the Segment field (the contents, if any, of the Instrument ID and Sub Book fields will be ignored). It will be deemed as one for all sub books of an instrument if it only contains a value in the Instrument ID field.


If the request is successful, the status for each requested sub book will be disseminated via a series of Symbol Status messages. Each such message will include the applicable Trading Status and a Session Change Reason of Unavailable (9).

The server will transmit a Snapshot Complete message after the Symbol Status for a particular sub book. The Snapshot Complete will include the sequence number of the Real-Time channel with which the trading status was synchronized and the instrument and sub book to which it relates. The Segment and Trading Status fields of the message should be ignored.

In the case of segment-level request, the server will also transmit a Snapshot Complete once the trading status for all sub books in the requested segment is disseminated. This final Snapshot Complete will include an indication of the segment to which it relates. The Sequence Number, Instrument ID, Sub Book and Trading Status fields of the message should be ignored.

4.1.2.11 Announcements

Once connected to the Snapshot channel, the clients may use the Snapshot Request message to request the Announcements messages for the entire day or for a specific period of time.

4.1.2.11.1 Requesting Announcements for the Entire Day

To request the Announcements for all the available instruments and the public announcements that are sent for the entire day via the particular ITCH gateway, the

21

Snapshot Type of the Snapshot Request message should be set to ‘5’. In this scenario no value should be tagged for the Segment, Flags or Instrument ID fields.

In this scenario the ‘Sending Time’ field of the Snapshot Request message should contain the time value that reflects the sending time of the first sent message via the real time channel or the earliest possible value for the current trading day (e.g. 00:00:00).

If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Response message will indicate that the request is rejected.

Snapshot Type field in the Snapshot Response will be set to ‘5’ in order to indicate that the response is sent for the request which was received for Announcements messages. This field should be tagged when the request is accepted or rejected.

If the request is successful, the server will disseminate the Announcements messages for the entire day for all the available instruments as well as any public announcements that were sent on the current trading date via the Announcements messages. After the dissemination of the last message sent in response to the request, a Snapshot Complete message should be sent.

Snapshot Type field in the Snapshot Complete messages will be set to ‘5’ in order to indicate that the messages are sent in response for the request which was received for Instruments.

The Segment, Instrument ID and Flags fields should not be tagged in Snapshot Complete message in this instance.

The Snapshot Complete message should include the sequence number with which the recovery snapshot was synchronized in the ‘Sequence Number’ field.

4.1.2.11.2 Requesting Missed Announcements for a Specific Period of Time

To request the missed announcements for all the available instruments and the public announcements that are sent for a specific period of time via the particular ITCH gateway, the Snapshot Type of the Snapshot Request message should be set to ‘5’. In this scenario no value should be tagged for the Segment, Flags or Instrument ID fields.

In this scenario the ‘Sending Time’ field of the Snapshot Request message should contain the time value that reflects the sending time of the last received announcements message via the real time channel.

If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Type field in the Snapshot Response will be set to ‘5’ in order to indicate that the response is sent for the request which was received for Announcements messages. This field should be tagged when the request is accepted or rejected.

If the request is successful, the server will disseminate the Announcements messages that were disseminated via the real time channel after the specified time of

22

the Snapshot Request message. In this scenario the server will disseminate the Announcements messages for all the available instruments as well as any public announcements that were sent on the current trading date after the specified time, via the Announcements messages. After the dissemination of the last message sent in response to the request, a Snapshot Complete message should be sent.

Snapshot Type field in the Snapshot Complete messages will be set to ‘5’ in order to indicate that the messages are sent in response for the request which was received for Instruments.

The Segment, Instrument ID and Flags fields should not be tagged in Snapshot Complete message in this instance.


4.1.2.12 Auction Info

Once connected to the Snapshot channel, clients may use the Snapshot Request message to request the last sent Auction Info message for all the instruments in a particular segment, or for a specified instrument.

The system behaviour should be as follows upon the client request message:

If the Segment field is tagged with/without either the Flags or Instrument ID fields, it will be taken as a request for the stated Segment.

If the Instrument ID field is tagged without the Segment field, it will be taken as a request for the particular instrument, regardless of whether the Flags field has been tagged.

23

4.1.2.12.1 Requesting Auction Info Messages for a Segment

To request the last sent Auction Info messages of all active instruments trading in a particular segment, the Snapshot Type of the Snapshot Request message should be set to ‘6’ and the relevant segment should be stated in the Segment field. In this scenario any values for the Instrument ID field or Flags field will be ignored.

If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Response message will indicate that the request is rejected. Snapshot Type field in the Snapshot Response will be set to ‘6’ in order to indicate that the response is sent for the request which was received for Auction Information. This field should be tagged when the request is accepted or rejected.

If the request is successful, the server will disseminate the last sent Auction Information messages via Auction Info messages. Once the Auction Information for all the instruments for the stated segment is transmitted a single segment level Snapshot Complete message should be sent.

Snapshot Type field in the Snapshot Complete messages will be set to ‘6’ in order to indicate that the messages are sent in response for the request which was received for Auction Information.

Only the Segment field should be tagged in the segment level Snapshot Complete message with the particular segment.


4.1.2.12.2 Requesting Auction Information for a Particular Instrument

To request the last sent Auction Information of an instrument, the Snapshot Type of the Snapshot Request message should be set to ‘6’ and the relevant instrument should be stated in the Instrument ID field. An order book may be optionally specified in the Flags field, and the value of this field will be ignored. In this scenario no value should be tagged for the Segment field.

If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Response message will indicate that the request is rejected.

Snapshot Type field in the Snapshot Response will be set to ‘6’ in order to indicate that the response is sent for the request which was received for Auction Information. This field should be tagged when the request is accepted or rejected.

If the request is successful, the server will disseminate the last sent Auction Information message for the instrument via the Auction Info message. After the dissemination of such Auction Information message an Instrument level Snapshot Complete message should be sent.

Snapshot Type field in the Snapshot Complete message will be set to ‘6’ in order to indicate that the messages are sent in response for the request which was received for Auction Information.

24

The instrument level Snapshot Complete message will not populate the Segment field or the Flags field, but will be tagged with the Instrument ID field.


4.1.2.13 Daily Schedule

Once connected to the Snapshot channel, the clients may use the Snapshot Request message to request the Daily Schedule message which would give the latest picture of the day’s schedule.

If the sessions are uninterrupted without any auction extensions or manual or automatic interventions, the remainder of the schedule for that instrument would be disseminated with the ‘Schedule Change Reason’ given as ‘Unchanged’ (U).

If the trading cycle is interrupted manually or automatically (Halt, Trading Stop, auction Extensions), a successful snapshot request would return a Daily Schedule message with the ‘No of Session’ = 0, and the ‘Schedule Change Reason’ = X (Unavailable).

The system behaviour should be as follows upon the client request message.

a) If the Segment field is tagged with/without either the Flags or Instrument ID fields, it will be taken as a request for the stated Segment.

b) If the Instrument ID field is tagged without the Segment field, it will be taken as a request for the particular instrument, regardless of whether the Flags field has been tagged.

4.1.2.13.1 Requesting the Daily Schedule for a Segment

To request the Daily Schedule messages of all active instruments trading in a particular segment, the Snapshot Type of the Snapshot Request message should be set to ‘7’ and the relevant segment should be stated in the Segment field. In this scenario any values for the Instrument ID field or Flags field will be ignored.

If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Response message will indicate that the request is rejected. Snapshot Type field in the Snapshot Response will be set to ‘7’ in order to indicate that the response is sent for the request which was received for the Daily Schedule. This field should be tagged when the request is accepted or rejected.

If the request is successful, the server will disseminate the latest picture of the schedule at that exact moment via the Daily Schedule messages. Once the schedules for all the instruments for the stated segment are transmitted a single segment level Snapshot Complete message should be sent.

Snapshot Type field in the Snapshot Complete message will be set to ‘7’ in order to indicate that the messages are sent in response for the request which was received for the Daily Schedule.

Only the Segment field should be tagged in the segment level Snapshot Complete message with the particular segment.

25


4.1.2.13.2 Requesting the Daily Schedule for a Particular Instrument

To request the Daily Schedule for an instrument, the Snapshot Type of the Snapshot Request message should be set to ‘7’ and the relevant instrument should be stated in the Instrument ID field. An order book may be optionally specified in the Flags field, and the value of this field will be ignored. In this scenario no value should be tagged for the Segment field. If the request is successful a Snapshot Response message will be sent with the status ‘A’ to state that the request is accepted. A Status other than “A” of the Snapshot Response message will indicate that the request is rejected. Snapshot Type field in the Snapshot Response will be set to ‘7’ in order to indicate that the response is sent for the request which was received for the Daily Schedule. This field should be tagged when the request is accepted or rejected. If the request is successful, the server will disseminate the latest picture of the schedule at that exact moment via the Daily Schedule message. After the dissemination of the schedule an instrument level Snapshot Complete message should be sent. Snapshot Type field in the Snapshot Complete message will be set to ‘7’ in order to indicate that the messages are sent in response for the request which was received for the Daily Schedule. The instrument level Snapshot Complete message will not populate the Segment field or the Flags field, but will be tagged with the Instrument ID field. The Snapshot Complete message should include the sequence number with which the recovery snapshot was synchronized in the ‘Sequence Number’ field

4.1.2.14 Termination of the Connection

If the client does not send a Logout Request and terminate the connection or submit another Snapshot Request within few seconds of the transmission of the Snapshot Complete message, the server will break the TCP/IP connection with the client.

4.2 Failures at the Exchange

4.2.1 Snapshots on the Real-time channel

In the unlikely event of an outage at the Exchange, recipients may be required to refresh their order book and statistics displays for one or more instruments. In such a scenario the server will, on the Real-Time channel, broadcast an Order Book Clear message for each affected instrument. In such an event recipients must discard the contents of their order book and statistics displays for these instruments.

26

The server will then transmit a series of Add Order, Add Attributed Order and Statistics messages, on the Real-Time channel, to disseminate the current order book and statistics for each affected instrument.

4.2.2 Resetting Sequence Numbers

If the market data feed is, in the unlikely event of an outage, failed over to the backup site or is restarted, the message sequence number of the multicast channel will be reset to 1.

27

5 Message Formats This section provides details on the data types, unit header, nine administrative messages and fifteen application messages utilised by the server. For each message, a description of each field is provided along with the applicable data type, offset and length (in bytes).

5.1 Packet Composition The Unit Header is used to deliver all administrative and application messages to and from the server on all three channels. A Unit Header may contain zero, one or more payload messages. While a Unit Header may contain multiple application messages, it will never contain more than one administrative message. A Unit Header will not contain both administrative and application messages.

5.2 Sequence Numbers All application messages transmitted by the server on the multicast and Replay channels are sequenced. The Unit Header only contains the sequence number of the first message. Each subsequent message in the Unit Header will have an implied sequence number one greater than the previous message. The sequence number of first message of the next Unit Header can be determined by adding the value in the Message Count field of the Unit Header to the value in its Sequence Number field. The application messages sent by the server on the Recovery channel as well as all administrative messages transmitted by both the server and the client are un-sequenced. The Unit Header used to transport all such messages, other than a Heartbeat, will include a Sequence Number of zero.

5.3 Timestamps The server will, on the multicast channel, transmit a Time message for every second for which at least one application message is generated. The time specified in this message serves as a reference for the times specified in all other application messages. The timestamps in all other messages are specified as a nanosecond offset from the most recent Time message – accurate to the millisecond. This message is not transmitted during periods where no application messages are generated for the multicast channel. The retransmission of messages on the Replay channel will include the Time messages originally broadcast on the multicast channel (i.e. with the same timestamp).

28

While Time messages will be included when an order book snapshot is provided on the Recovery channel, the times in these messages will be different from those published when the active orders were originally disseminated on the multicast channel. Clients are unable to determine the time at which an active order was submitted from the messages transmitted on the Recovery channel.

5.4 Data Types The fields of the various messages utilised by the server will support the data types outlined below.

All Reserved Fields with Alpha Data Type will be populated with Spaces (Hex 0x20). All other Reserved Fields will be populated with Hex 0x00.

5.4.1 Administrative Messages

Name Message Type Usage

ASCII Hex

Data Type Length Description

Alpha Variable These fields use standard ASCII character bytes. They are left justified and padded on the right with spaces.

Bit Field 1 A single byte used to hold up to eight 1-bit flags. Each bit will represent a Boolean flag. The 0 bit is the lowest significant bit and the 7 bit is the highest significant bit.

Byte 1 A single byte used to hold one ASCII character.

Date 8 Date specified in the YYYYMMDD format using ASCII characters.

Time 8 Time specified in the HH:MM:SS format using ASCII characters.

Price 8 / 4 Signed Little-Endian encoded four byte integer field with eight implied decimal places (when length is 8, it will be eight decimal places; when length is 4, it will be 4 decimal places).

UInt8 1 8 bit unsigned integer.

UInt16 2 Little-Endian encoded 16 bit unsigned integer.



29

Heartbeat - - Used by the server, on the Real-Time channel, to exercise the communication line during periods of inactivity.

Login Request

(soh) 0x01 Used by the client to login to the Replay or Recovery channel.

Login Response

(stx) 0x02 Used by the server to accept or reject a login request to the Replay or Recovery channel.

Logout Request

(enq) 0x05 Used by the client to logout of the Replay or Recovery channel.

Replay Request

(etx) 0x03 Used by the client to request a retransmission of messages on the Replay channel.

Replay Response

(eot) 0x04 Used by the server to respond to a retransmission request on the Replay channel.

Snapshot Request

� 0x81 Used by the client to request for a snapshot of the current order book on the Recovery channel.

Snapshot Response

‚ 0x82 Used by the server to respond to a snapshot request on the Recovery channel.

Snapshot Complete

ƒ 0x83 Used by the server to indicate that the transmission of an order book snapshot is complete.

5.4.2 Application Messages

Applications messages may only be sent by the server.

Name Message Type Usage

ASCII Hex

Time T 0x54 Sent by the server for every second for which at least one application message is generated. This message is not transmitted during periods where no other application messages are generated.

System Event S 0x53 Sent to indicate the start and end of the day.

Symbol Directory

R 0x52 Used to disseminate information (e.g. instrument id, segment, ISIN, underlying, etc.) on each instrument.

Symbol Status H 0x48 Indicates the trading session (e.g. opening auction call regular (continuous) trading, etc.) that currently applies to an instrument.

30

Add Order A 0x41 Sent to indicate that an anonymous limit or market order is added to the order book.

Add Attributed Order

F 0x46 Indicates that an attributable limit order, market order (named order) or a named quote is added to the order book. The identity of the submitting firm is included in the message.

Order Deleted D 0x44 Sent to indicate that the remainder of a displayed order is cancelled.

Order Modified U 0x55 Indicates that the displayed quantity or price of a displayed order has been updated. The message will include an indication whether the order has retained or lost its time priority.

Order Book Clear

y 0x79 Sent to instruct recipients to remove all orders from the order book for the specified instrument.

Order Executed E 0x45 Indicates that the displayed portion of an order is fully or partially filled at its displayed price. The executed quantity is included in the message.

Order Executed With Price/ Size

C 0x43 Sent if a displayed order is fully or partially filled at a price that is different from its displayed price. The executed quantity and price is included in the message along with an indication of whether the trade should update time and sales and statistics displays.

Trade P 0x50 Sent if the non-displayed portion of an iceberg order is fully or partially filled. Sent if Cross/BTF orders are executed.

Auction Trade Q 0x51 Sent to report details of an auction (e.g. opening, closing, etc.). The message indicates the price and bulk volume associated with the auction.

Off-Book Trade x 0x78 Sent to report the details of a privately negotiated trade.

Trade Break B 0x42 Indicates that a previously reported traded is cancelled.

Auction Info I 0x49 Used to disseminate the indicative auction price and the tradable quantity and imbalance at this price.

31

Statistics w 0x77 Used to disseminate official opening and closing prices. Used to disseminate static reference price, dynamic reference price and previous day’s closing price.

Recovery Trade 0x76 Used to disseminate the trade details via the recovery channel

Announcements 0x75 Used to disseminate the announcements

Daily Schedule 0x74 Used to disseminate the daily schedule

5.5 Unit Header

Field Offset Length Type Description

Length 0 2 UInt16 Length of the message block including the header and all payload messages.

Message Count

2 1 UInt8 Number of payload messages that will follow the header.

Market Data Group2

3 1 Byte Identity of the market data group the payload messages relate to.

Sequence Number

4 4 UInt32 Sequence number of the first payload message.

Payload 8 Variable - One or more payload messages.

2 The Market Data Group specified on the client initiated messages will not be validated.

32

5.6 Administrative Messages (Client – Initiated)

5.6.1 Login Request


Length 0 1 UInt8 Length of message including this field.

Message Type

1 1 Byte Hex Meaning

0x01 Login Request

Username 2 6 Alpha CompID assigned to the client.

Password 8 10 Alpha Password assigned to the CompID.

5.6.2 Replay Request



Message Type


0x03 Replay Request

Market Data Group

2 1 Byte Identity of the market data group the replay request relates to.

First Message

3 4 UInt32 Sequence number of the first message in range to be retransmitted.

Count 7 2 UInt16 Number of messages to be resent

5.6.3 Snapshot Request



Message Type


0x81 Snapshot Request

33

Sequence Number

2 4 UInt32 Sequence number from which client can build the order book.

Segment 6 6 Alpha Segment the request relates to. The field should contain only spaces if it does not relate to a segment.

Instrument ID

12 4 UInt32 Instrument Identifier. Instrument the request relates to. The field should contain only spaces if it does not relate to an instrument.

Sub Book 16 1 Bit Field Bit Name Meaning

0 Regular 0: No

1: Yes

1 Off-Book

0: No

1: Yes

Snapshot Type

17 1 UInt8 Value Meaning

0 Order Book

1 Symbol Status

2 Instrument

3 Trades

4 Statistics

5 Announcements

6 Auction Information

7 Daily Schedule

Last Trade Time

18 8 Time Sending time of the last processed trade specified in terms of local time for the server (i.e. not UTC). This field is ignored if the Snapshot Type is not Instrument (3).

Request ID 26 4 UInt32 Optional identifier of the request

5.6.4 Logout Request



Message Type


0x05 Logout Request

34

5.7 Administrative Messages (Server – Initiated)

5.7.1 Heartbeat

A Unit Header with a Message Count of zero will be used by the server as a Heartbeat message. Such a message will never increment the sequence number of the Real-Time channel. However, the next expected sequence number will be included in the Sequence Number to enable recipients to detect gaps on the Real-Time channel.

5.7.2 Login Response



Message Type


0x02 Login Response

Status 2 1 Byte Status of the login request.

Value Meaning

A Login Accepted

a CompID Inactive/Locked

b Login Limit Reached

c Service Unavailable

d Concurrent Limit Reached

e Failed (Other)

5.7.3 Replay Response



Message Type


0x04 Replay Response

35

Market Data Group

2 1 Byte Identity of the market data group the replay request relates to.

First Message

3 4 UInt32 Sequence number of the first message in range to be retransmitted. This will be zero if Status is not “A”.

Count 7 2 UInt16 Number of messages to be resent. This will be zero if Status is not “A”.

Status 9 1 Byte Status of the replay request.

Value Meaning

A Request Accepted

D Request Limit Reached

I Invalid Market Data Group

O Out of Range

U Replay Unavailable

c Concurrent Limit Reached

d Unsupported message type

e Failed (Other)

5.7.4 Snapshot Response



Message Type


0x82 Snapshot Response

Sequence Number

2 4 UInt32 Sequence number with which the snapshot is synchronised. Sequence Number will be zero if the request is accepted or rejected.

Order Count 6 4 UInt32 Number of orders that will be transmitted in the snapshot. Order Count will be zero if the request is accepted or rejected

36

Status 10 1 Byte Status of the snapshot request.

Value Meaning

A Request Accepted

O Out of Range

U Snapshot Unavailable

a Valid Segment or Symbol Not Specified

b Request Limit Reached

c Concurrent Limit Reached

d Unsupported message type

e Failed (Other)

Snapshot Type


0 Order Book

1 Symbol Status

2 Instrument

3 Trades

4 Statistics

5 Announcements


7 Daily Schedule

Request ID 12 4 UInt32 Identifier, if any, of Snapshot Request.

5.7.5 Snapshot Complete



Message Type


0x83 Snapshot Complete

Sequence Number

2 4 UInt32 Sequence number with which the snapshot is synchronised.

37

Segment 6 6 Alpha Segment the snapshot relates to. The field will contain only spaces if it does not relate to a segment.

Instrument ID

12 4 UInt32 Instrument Identifier. Instrument the snapshot relates to. The field will contain only spaces if it does not relate to an instrument.

Reserved 16 1 Bit Field Reserved for Future Use

Sub Book 17 1 Bit Field Bit Name Meaning

0 Regular 0: No

1: Yes

1 Off-Book

0: No

1: Yes

Trading Status

18 1 Byte Value Meaning

H Halt

T Regular (Continuous) Trading / Start of Trade Reporting

R Resume Order Deletion period

S Trading Stop

a Opening Auction Call (Pre-Open)

b Post-Close

c Market Close (Closed)

d Closing Auction Call

e Re-Opening (AESP or Resume) Auction Call

g OPA Auction Call

v End of Trade Reporting

w No Active Session

y Pre-Trading (Start of Trading)

38

Snapshot Type


0 Order Book

1 Symbol Status

2 Instrument

3 Trades

4 Statistics

5 Announcements


7 Daily Schedule

Request ID 20 4 UInt32 Identifier, if any, of Snapshot Request.

5.8 Application Messages

5.8.1 Time



Message Type


0x54 Time

Seconds 2 4 UInt32 Number of seconds since midnight. Midnight will be in terms of the local time for the server (i.e. not UTC).

5.8.2 System Event



Message Type


0x53 System Event

Nanosecond 2 4 UInt32 Nanoseconds since last Time message.

39

Event Code 6 1 Byte Value Meaning

C End of Day

O Start of Day

5.8.3 Symbol Directory



Message Type


0x52 Symbol Directory


Instrument ID

6 4 UInt32 Instrument Identifier.

Reserved 10 1 Byte Reserved field


Symbol Status

12 1 Alpha Value Meaning

H Halted

S Suspended

a Inactive/Underlying Suspended

This field will contain a space if the instrument is active.

ISIN 13 12 Alpha Instrument identification number.

Price Band Tolerances (%)

25 4 Price Price Band Tolerance (%) of the instrument

Dynamic Circuit Breaker Tolerances (%)

29 4 Price Dynamic Circuit Breaker Tolerance (%) of the instrument

Static Circuit Breaker Tolerances (%)

33 4 Price Static Circuit Breaker Tolerance (%) of the instrument

40

Segment 37 6 Alpha Segment the instrument is assigned to.

Underlying 43 6 Alpha Identifier of the underlying instrument. This field will contain only spaces if the instrument is not a derivative.

Currency 49 3 Alpha ISO Currency Code

Reserved Field

52 1 Byte Reserved for Future Use

Reserved Field

53 4 Alpha Reserved for Future Use

Reserved Field

57 8 Price Reserved for future use

Reserved Field

65 8 Date Reserved for future use

Reserved Field

73 6 Alpha Reserved for future use

Reserved Field

79 8 Date Reserved for future use

Reserved Field

87 4 Price Reserved for future use

Flags 91 1 Bit Field Bit Name Meaning

0 Inverse Order Book

0: No

1: Yes

5.8.4 Symbol Status



Message Type


0x48 Symbol Status


Instrument ID



41


Trading Status


H Halt

T Regular (Continuous Trading/Start of Trade Reporting


S Trading Stop


b Post-Close




g OPA Auction Call


w No Active Session



Halt Reason 14 4 Alpha Reason for the trading halt. This field will contain only spaces if Trading Status is not “H” and “S”.

42

Session Change Reason


0 Scheduled Transition

1 Extended by Market Supervision

2 Shortened by Market Supervision

3 Market Order Imbalance

4 Price Outside Range

5 Circuit Breaker Tripped

9 Unavailable

New End Time

19 8 Time New time the session will end. The field will contain only spaces if Session Change Reason is “0”. New End Time will be in terms of the local market time (i.e. not UTC).

Book Type 27 1 UInt8 Value Meaning

1 On-Book

2 Off-Book

5.8.5 Add Order



Message Type


0x41 Add Order


Order ID 6 8 UInt64 Unique identifier of the order.

Side 14 1 Byte Value Meaning

B Buy Order

S Sell Order

Quantity 15 8 UInt64 Displayed quantity of the order.

43

Instrument ID




Price 29 8 Price Limit price of the order. Will indicate the yield if instrument is traded on yield.


4 Market Order

0: No

1: Yes

Implied Price 38 8 Price The field will populate the Implied Price for an instrument only traded on Yield.

5.8.6 Add Attributed Order



44

5.8.7 Order Deleted



Message Type


0x44 Order Deleted


Order ID 6 8 UInt64 Identifier for the order.


Message Type


0x46 Add Attributed Order


Order ID 6 8 UInt64 Unique identifier of the order.

Side 14 1 Byte Value Meaning

B Buy Order

S Sell Order

Quantity 15 8 UInt64 Displayed quantity of the order.

Instrument ID




Price 29 8 Price Limit price of the order. Will indicate the yield if instrument is traded on yield.

Attribution 37 11 Alpha Identity of firm that submitted the order.


4 Market Order

0: No

1: Yes


45

Instrument ID


5.8.8 Order Modified



Message Type


0x55 Order Modified



New Quantity

14 8 UInt64 New displayed quantity of the order.

New Price 22 8 Price New limit price of the order. Will indicate the yield if instrument is traded on yield.


0 Priority Flag

0: Priority Lost

1: Priority Retained

Instrument ID



46

5.8.9 Order Book Clear



Message Type


0x79 Order Book Clear


Instrument ID


Reserved 10 1 Byte Reserved for Future Use

Reserved 11 1 Byte Reserved for Future Use


5.8.10 Order Executed



Message Type


0x45 Order Executed



Executed Quantity

14 8 UInt64 Quantity executed.

Trade Match ID

22 8 UInt64 Unique identifier of the trade.

Instrument ID


5.8.11 Order Executed with Price / Size

47

5.8.12 Trade



Message Type


0x50 Trade




Message Type


0x43 Order Executed With Price/Size



Executed Quantity


Display Quantity

22 8 UInt64 Displayed quantity of the order after the execution.

Trade Match ID


Printable 38 1 Byte Value Meaning

N Non-Printable

Y Printable

Price 39 8 Price Price at which the order was executed. Will indicate the yield if instrument is traded on yield.

Instrument ID



48

Executed Quantity


Instrument ID




Price 20 8 Price Executed price. Will indicate the yield if instrument is traded on yield.

Trade Match ID



Cross ID 37 20 Alpha The unique ID of the Cross/BTF Order. Will only be populated in case of Cross/BTF order executions. In other scenarios, the field will be populated with blank (null) value.

Cross Type 57 1 Int8 The type of the Cross/BTF Order. Will only be populated in case of Cross/BTF order executions. In other scenarios, the field will be populated with blank (0) value.

Value Meaning

5 Internal Cross

6 Internal BTF

7 Committed Cross

8 Committed BTF


5.8.13 Auction Trade



Message Type


0x51 Auction Trade

49


Quantity 6 8 UInt64 Quantity executed in auction.

Instrument ID




Price 20 8 Price Price of auction. Will indicate the yield if instrument is traded on yield.

Trade Match ID


Auction Type


C Closing Auction

O Opening Auction

A Re-Opening (AESP or Resume) Auction

P OPA


5.8.14 Off-Book Trade



Message Type


0x78 Off-Book Trade


50

Executed Quantity


The Off Book Trade message should not publish the quantity of the off book trade message (means it will ne 0), if the Trade Capture Report contained the value Yes (1) for the field Request Not to Publish Quantity Indicator for the instruments of type ‘non-share’.

The Off Book Trade message should publish the quantity of the off book trade message, if the Trade Capture Report contained the value No (0) for the field Request Not to Publish Quantity Indicator for the instruments of type ‘non-share’.

Instrument ID 14 4 UInt32 BIT Instrument Identifier.



Price 20 8 Price Executed price.

Trade Match ID


Reserved Field


Trade Time 40 8 Time Time off-book trade was executed. The time is specified in terms of the local time for the server (i.e. not UTC).

Trade Date 48 8 Date Date off-book trade was executed.

Traded Currency

56 4 Alpha Currency in which an off book trade has occurred other than for the trading currency of the relevant instrument.

The possible values will be the ISO 4217 codes for currency. However the following values too will be disseminated.

Value Meaning

GBX GB Pennies

ITL Italian LIRA

51

Original Price 60 8 Price Price in the execution currency. The field should contain only zeroes if the trade did not take place in a currency other than for the trading currency of the instrument.

Execution Venue

68 5 Alpha The possible values will be the ISO 10383 codes for Exchange ID. However the following values too will be disseminated.

Value Meaning

EXPA TBD

SI Systematic Internalizer

XOFF TBD

Flags 73 1 Bit Field

Bit Name Meaning

0 Late Trade

0: No

1: Yes

2 Channel Type

1: Primary

5 Bargain Condition Indicator

0: No

1: Yes

The value should be always set to P (Primary).


Current Market Price Value Indicator


D Current Market Price

This should be tagged with the value ‘D’ when the value that was submitted by the original trade via the FIX 5.0 SP2 Post Trade Gateway has been set to ‘Yes’. This should be tagged with the value ‘ ’ (i.e. a space filled), if a value has not been specified in the original trade or it has been specified as ‘No’ in the original trade.

52

Negotiated Trade Indicator


N Agreed Operation

This should be tagged with the value ‘N’ when the value that was submitted by the original trade via the FIX 5.0 SP2 Post Trade Gateway has been set to ‘Yes’. This should be tagged with the value ‘ ’ (i.e. a space filled), if a value has not been specified in the original trade or it has been specified as ‘No’ in the original trade.

Venue Identification Code

88 11 Alpha Venue outside the system which involved in the off-book trade

5.8.15 Trade break



53

Message Type


0x42 Trade Break


Trade Match ID

6 8 UInt64 Identifier of the cancelled trade.

Trade Type 14 1 Byte Value Meaning

T On-Book Trade

N Off-Book Trade

Instrument ID



54

5.8.16 Auction Info



Message Type


0x49 Indicative Auction Info


Paired Quantity

6 8 UInt64 Quantity that will be matched at the indicative price.

Imbalance Quantity

14 8 UInt64 Quantity that is eligible to be matched at the indicative price but will not be matched.

Imbalance Direction


B Buy Imbalance

N No Imbalance

O Insufficient Orders for Auction

S Sell Imbalance

Instrument ID




Price 29 8 Price Indicative auction price. Will indicate the yield if instrument is traded on yield.

Auction Type


C Closing Auction

O Opening Auction


P OPA Auction

55

5.8.17 Statistics



Message Type 1 1 Byte Hex Meaning

0x77 Statistics


Instrument ID 6 4 UInt32 Instrument Identifier.



Statistic Type 12 1 Alpha Value Meaning

O Opening Price

C Closing Price

s Static Reference Price

d Dynamic Reference Price

P Previous Close Price

Price 13 8 Price Opening or Closing price. Note that If the Opening or Closing Price is cleared through the Service Desk, a null value will be stamped in this field. Will indicate the yield if instrument is traded on yield.

56

Open/ClosePriceIndicator

21 1 Alpha

Will only be populated if the Statistic Type is P, O or C. Will be blank in other scenarios.

Value Meaning

A UT

B AT

D Last AT

E Last UT

F Manual

G Mid point

average

H VWAP

I Previous

Close

i

Normal

Hours

Closing

Price (TAH

Static

Reference

Price)

W

None (used

when

publishing

Previous

Close

Price)

Z Price

Unavailable

Reserved 22 1 Bit Field

Reserved for future use

57

5.8.18 Recovery Trade



Message Type


0x76 Recovery Trade

Nanosecond 2 4 UInt32 Nanoseconds offset from the last Time message.

Executed Quantity


Instrument ID




Price 20 8 Price Executed price.

Trade ID 28 8 UInt64 Unique identifier of the trade.

Auction Type



C Closing Auction

O Opening Auction

This field will contain a space if the trade is not an auction trade.

Reserved Field


Trade Time 41 8 Time Time trade was executed. The time is specified in terms of the local time for the server (i.e. not UTC).

Trade Date 49 8 Date Date the off-book trade was executed. This field will contain only spaces for on-book trades.

Action Type 57 1 Byte Value Meaning

C Cancelled Trade

N Trade

58

Traded Currency

58 4 Alpha Currency in which an off book trade has occurred other than for the trading currency of the relevant instrument. This will contain only spaces for on-book trades.

The possible values will be the ISO 4217 codes for currency. However the following values too will be disseminated.

Value Meaning

GBX GB Pennies

ZAC 100th of RAND (cents) (JSE specific)

ITL Italian LIRA

Original Price

62 8 Price Price in the execution currency. The field should contain only zeroes if the trade did not take place in a currency other than for the trading currency of the instrument. This will contain only spaces for on-book trades.

Execution Venue

70 5 Alpha The possible values will be the ISO 10383 codes for Exchange ID. However the following values too will be disseminated. This will contain only spaces for on-book trades.

Value Meaning

EXPA TBD

SI Systematic Internalizer

XOFF TBD

Flags 75 1 Bit Field

This will contain only spaces for on-book trades

Bit Name Meaning

0 Late Trade

0: No

1: Yes

5 Bargain Condition Indicator

0: No

1: Yes

59

Cross ID 76 20 Alpha The unique ID of the Cross/BTF Order. Will only be populated in case of Cross/BTF order executions. In other scenarios, the field will be populated with blank (null) value.

Cross Type 96 1 Int8 The type of the Cross/BTF Order. Will only be populated in case of Cross/BTF order executions. In other scenarios, the field will be populated with blank (0) value.

Value Meaning

5 Internal Cross

6 Internal BTF

7 Committed Cross

8 Committed BTF

Implied Price

97 8 Price The field will populate the Implied Price for an instrument only traded on Yield.

5.8.19 Announcements



Message Type 1 1 Byte Hex Meaning

0 x 75 Announcements


Time 6 8 Time Time the announcement was published. Time will be specified in terms of the local time for the server.

Urgency 14 1 Byte Value Meaning

0 Regular

1 High Priority

2 Low Priority

Headline 15 50 Alpha Headline or subject of the announcement.

60

Text 65 120 Alpha Text of the announcement.

Instruments 185 30 Alpha Pipe separated Identification numbers of the securities for which the announcement has been sent for.

Underlying/Market 215 30 Alpha Pipe separated Identification numbers of the underlying securities/markets for which the announcement has been sent for.

Time (UTC) 245 8 Time UTC Time at which the announcement was published

5.8.20 Daily Schedule


Unit Header


Message Type


0x74 Daily Schedule


Instrument ID 6 4 UInt32 Instrument Identifier.

Book Type 10 1 UInt8 Value Meaning

1 On-Book

2 Off-Book

Schedule Change Reason


U Unchanged

K Unavailable

X Session Extension

S Session Shortening

No of Sessions

12 2 UInt16 Number of sessions the times are indicated for

61

Session 1 14 1 UInt8 Value Meaning

H Halt

T Regular (Continuous) Trading/Start Trade Reporting


S Trading Stop


b Post-Close




g OPA Auction Call


w No Active Session

x End of Post Close


Start Time 15 8 Time Session start time in HH:MM:SS format using ASCII characters (Time displayed in Local time).

End Time 23 8 Time Session end time in HH:MM:SS format using ASCII characters.

(Time displayed in Local time).

Session 2 31 1 UInt8 Value (enumeration assigned for each session)




62





















63





















64









65

6 Data Mapping

6.1 Conversion of Order ID

6.1.1 Order ID format (in binary)

The composition of the binary Order IDs assigned by the market data feed is given below. This Order ID is specified as a Little-Endian encoded unsigned integer.

20 bits 2bits 3 bits 2bits 32 bits (4 bytes)

<number of sec> [0-3] [0-7] [0-3]

The number of 5 minutes intervals from Jan 1, 2010)

ID

Partition id Thread

id Order number

8 bytes

6.1.2 Order ID format (in ASCII)

The composition of the Order IDs assigned by the matching system is given below. This Order ID is specified as ASCII printable characters and will not exceed 12 bytes.

12 bytes

0-9, A-Z, a-z

Base 62 encoded order id

The FIX Order ID can be directly converted to ITCH Order ID by using base 62 decoding.

E.g.:

OrderID in FIX (Ascii base 62 characters)

004Xj7Wu76ta

OrderID in ITCH gateway (Binary ID converted to decimal)

61512470073704470

Steps to follow

• Convert using base 62 conversions in to decimal as depicted below

• Note: Please refer to the base 62 conversion table attached below

66

FIX Order ID

(Ascii Character)

Corresponding decimal value

Base 62^x Value Multiplied decimal value

a 36 62^0

1

36

t 55 62^1

62

3,410

6 6 62^2

3,844

23,064

7 7 62^3

238,328

1,668,296

u 56 62^4

14,776,336

827,474,816

W 32 62^5

916,132,832

29,316,250,624

7 7 62^6

56,800,235,584

397,601,649,088

j 45 62^7

3,521,614,606,208

158,472,657,279,360

X 33 62^8

218,340,105,584,896

7,205,223,484,301,570

4 4 62^9

13,537,086,546,263,600

54,148,346,185,054,200

0 0 62^10

839,299,365,868,340,000

-

0 0 62^11

839,299,365,868,340,000

-

61,512,470,073,704,470

Base 62 mapping table:

0 0 20 K 40 e 60 y

1 1 21 L 41 f 61 z

2 2 22 M 42 g

3 3 23 N 43 h

4 4 24 O 44 i

5 5 25 P 45 j

6 6 26 Q 46 k

7 7 27 R 47 l

8 8 28 S 48 m

9 9 29 T 49 n

10 A 30 U 50 o

11 B 31 V 51 p

12 C 32 W 52 q

13 D 33 X 53 r

67

14 E 34 Y 54 s

15 F 35 Z 55 t

16 G 36 a 56 u

17 H 37 b 57 v

18 I 38 c 58 w

19 J 39 d 59 x

Note Please use 64 bit integer data types for the calculation. If not the received integers will overflow.

6.2 Conversion of Trade ID

6.2.1 Trade ID format (in binary)

The composition of the binary Trade IDs assigned by the market data feed is given below. This Trade ID is specified as a Little-Endian encoded unsigned integer. Trade ID format (binary)

20 bits 2bits 3 bits 2bits 24 bits

<number of sec> [0-15] [0-7] [0-3]

The number of 5 mins intervals from Jan 1, 2010)

ID

Partition id Thread

id Trade number

8 bytes

6.2.2 Trade ID format (in ASCII)

The composition of the Trade IDs assigned by the matching system is given below. This Trade ID is specified as ASCII printable characters. Trade ID format (ASCII )

10 bytes

0-9, A-Z

Base 36 encoded Trade ID

The FIX Trade ID can be directly converted to ITCH Trade ID by using base 36 decoding.

68

E.g.:

ASCII Trade ID for FIX G5DIF33YV0

Binary Trade ID ( decimal ) for ITCH market data feed

73120274710544

FIX Trade ID

(Ascii Character)

Corresponding decimal value

Base 36^x Value

Multiplied decimal value

0 20 36^0

1

20

V 15 36^1

36

540

Y 18 36^2

1,296

23,328

3 23 36^3

46,656

1,073,088

3 23 36^4

1,679,616

38,631,168

F 35 36^5

60,466,176

2,116,316,160

I 2 36^6

2,176,782,336

4,353,564,672

D 33 36^7

78,364,164,096

2,586,017,415,168

5 25 36^8

2,821,109,907,456

70,527,747,686,400

G 0 36^9

101,559,956,668,416

-

73,120,274,710,544

Base 36 mapping table:

0 G 20 0

1 H 21 1

2 I 22 2

3 J 23 3

4 K 24 4

5 L 25 5

6 M 26 6

7 N 27 7

69

8 O 28 8

9 P 29 9

10 Q 30 A

11 R 31 B

12 S 32 C

13 T 33 D

14 U 34 E

15 V 35 F

16 W

17 X

18 Y

19 Z

70

7 Trading Halt Reasons Code Reason

101 Instrument-level circuit breaker tripped

9998 Matching partition suspended

9999 System suspended

Space Reason not available

71

8 Order book scenarios

8.1 Order book scenarios for instrument Scenario ITCH GW

Instrument has the requested market data

1. Snapshot Response message is sent with the status ‘Request Accepted’

2. A series of Add Order and Add Attributed Order messages will be sent which will be followed by a Symbol Status message and a Snapshot Complete message for each book of the instrument

Instrument has an empty order book


2. A Symbol Status and a Snapshot Complete message will be sent for the instrument

Instrument does not have On book trading definition attached


2. A Snapshot Complete message will be sent for the instrument

8.2 Order book scenarios for segment

Scenario ITCH GW

All the market data are available


2. A series of Add Order and Add Attributed Order messages will be sent which will be followed by a Symbol Status and a Snapshot Complete message for order book of the Instrument

3. A single Snapshot Complete message will be sent for the segment

72

One or more instruments have empty On Book


2. A series of Add Order and Add Attributed Order messages will be sent which will be followed by a Symbol Status and a Snapshot Complete message for Each Instrument with active orders/quotes in the book

3. A Symbol Status and a Snapshot Complete message will be sent for the instruments with Empty On Book


One or more instruments do not have On book trading definition attached

1. Snapshot Response message is sent with the

status ‘Request Accepted’ 2. A series of Add Order and Add Attributed

Order messages will be sent which will be followed by a Symbol Status message and Snapshot Complete message for each Instrument with active orders/quotes in the book

3. A Snapshot Complete/ Symbol Status message will not be sent for the instruments with no On Book Trading definition attached


All the instruments in the segment have empty On book


2. A Symbol Status and Snapshot Complete message will be sent for each instrument since all the instruments that have Empty On Books


All the instruments in the segment do not have On book trading definition attached


2. A Snapshot Complete/ Symbol Status message will not be sent for each instrument since no On Book Trading definition is attached


73

Copyright © October 2011 London Stock Exchange plc. Registered in England and Wales No. 05369106. London Stock Exchange plc has used all reasonable efforts to ensure that the information contained in this publication is correct at the time of going to press, but shall not be liable for decisions made in reliance on it. London Stock Exchange and the coat of arms device are registered trade marks of London Stock Exchange plc. London Stock Exchange 10 Paternoster Square London EC4M 7LS Telephone: +44 (0)20 7797 1000 www.londonstockexchange.com

V2.0

M I T 3 0 3 – B I T - M I L L E N N I U M E X C H A N G E ... · 7 Section 4.1.1.1 Section...

Documents

Transcript of M I T 3 0 3 – B I T - M I L L E N N I U M E X C H A N G E ... · 7 Section 4.1.1.1 Section...