MIT303 BIT - MILLENNIUM EXCHANGE Level 2-ITCH Specification · MIT303 – BIT - MILLENNIUM EXCHANGE...

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 6.6 ∙ April 2014

Contents

Level 2-ITCH Specification ......................................................... 1

1 Introduction .......................................................................... 6

1.1 Purpose .......................................................................................... 6

1.2 Readership ..................................................................................... 6

1.3 Document series ............................................................................ 7

1.4 Document history ........................................................................... 7

1.5 Enquiries ...................................................................................... 11

2 System Architecture ........................................................... 12

2.1 Real-Time Channel ...................................................................... 12

2.2 Replay Channel ........................................................................... 13

2.3 Recovery Channel ....................................................................... 13

3 Service Description ............................................................ 14

3.1 Overview of a trading day ............................................................ 14 3.1.1 Trading on the order book .................................................................... 14 3.1.2 Trade Reporting ................................................................................... 14 3.1.3 Start of Day (Market Open) .................................................................. 14 3.1.4 List of instruments ................................................................................ 15 3.1.5 Daily Schedule ..................................................................................... 15 3.1.6 Trading Status...................................................................................... 15 3.1.7 Order Book Management ..................................................................... 15 3.1.8 Executions ........................................................................................... 17 3.1.9 Execution of Hidden Quantity ............................................................... 17 3.1.10 Auctions ........................................................................................... 18 3.1.11 Cross Orders .................................................................................... 18 3.1.12 Time and sales ................................................................................. 18 3.1.13 Announcements ............................................................................... 18 3.1.14 End of Day ....................................................................................... 18

4 Connectvity ......................................................................... 19

4.1 Transmission Standards .............................................................. 19 4.1.1 Multicast Channels ............................................................................... 19 4.1.2 Replay and recovery Channels ............................................................ 19 4.1.3 CompIDs .............................................................................................. 19

4.2 Production IP Addresses and Ports ............................................. 19

4.3 Failure and Recovery ................................................................... 20

5 Recovery ............................................................................. 21

5.1 Recipient Failures ........................................................................ 21

3

5.1.1 Replay Channel ................................................................................... 21 5.1.2 Recovery Channel ............................................................................... 23

5.2 Failures at the Exchange ............................................................. 36 5.2.1 Snapshots on the Real-time channel .................................................... 36 5.2.2 Resetting Sequence Numbers ............................................................. 36 5.2.3 Level 2-ITCH multicast channels .......................................................... 36

6 Message Formats ............................................................... 38

6.1 Packet Composition ..................................................................... 38

6.2 Sequence Numbers ..................................................................... 38

6.3 Timestamps ................................................................................. 38

6.4 Data Types ................................................................................... 39 6.4.1 Administrative Messages ..................................................................... 40 6.4.2 Application Messages .......................................................................... 40

6.5 Unit Header .................................................................................. 42

6.6 Administrative Messages (Client – Initiated) ................................ 43 6.6.1 Login Request ...................................................................................... 43 6.6.2 Replay Request ................................................................................... 43 6.6.3 Snapshot Request ............................................................................... 43 6.6.4 Logout Request .................................................................................... 44

6.7 Administrative Messages (Server – Initiated) ............................... 45 6.7.1 Heartbeat ............................................................................................. 45 6.7.2 Login Response ................................................................................... 45 6.7.3 Replay Response ................................................................................. 45 6.7.4 Snapshot Response ............................................................................. 46 6.7.5 Snapshot Complete ............................................................................. 48

6.8 Application Messages .................................................................. 50 6.8.1 Time ..................................................................................................... 50 6.8.2 System Event ....................................................................................... 50 6.8.3 Symbol Directory .................................................................................. 50 6.8.4 Symbol Status ...................................................................................... 52 6.8.5 Add Order ............................................................................................ 54 6.8.6 Add Attributed Order ............................................................................ 55 6.8.7 Order Deleted ...................................................................................... 56 6.8.8 Order Modified ..................................................................................... 56 6.8.9 Order Book Clear ................................................................................. 58 6.8.10 Order Executed ................................................................................ 58 6.8.11 Order Executed with Price / Size ...................................................... 58 6.8.12 Trade ............................................................................................... 59 6.8.13 Auction Trade ................................................................................... 60 6.8.14 Off-Book Trade ................................................................................ 61 6.8.15 Trade break ...................................................................................... 64 6.8.16 Auction Info ...................................................................................... 65 6.8.17 Statistics .......................................................................................... 66

4

6.8.18 Recovery Trade................................................................................ 68 6.8.19 Announcements ............................................................................... 70 6.8.20 Daily Schedule ................................................................................. 71

7 Data Mapping ...................................................................... 76

7.1 Conversion of Order ID ................................................................ 76 7.1.1 Order ID format (in binary) ................................................................... 76 7.1.2 Order ID format (in ASCII) .................................................................... 77 7.1.3 Base 62 mapping table ........................................................................ 78

7.2 Conversion of Trade ID ................................................................ 79 7.2.1 Trade ID format (in binary) ................................................................... 79 7.2.2 Trade ID format (in ASCII) ................................................................... 80 7.2.3 Base 62 mapping table ........................................................................ 81

7.3 Conversion of Negative Values in Price Fields ............................ 82 7.3.1 Encoding Negative Values in Price Fields ............................................ 82 7.3.2 Decoding Negative Values in Price Fields ............................................ 82

8 Trading Halt Reason Codes ............................................... 83

9 Order book scenarios ........................................................ 84

9.1 Order book scenarios for instrument ............................................ 84

9.2 Order book scenarios for segment ............................................... 84

5

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.

6

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.

7

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 MIT306 BIT – MOT / EuroMOT Instrument Currency

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.

http://www.londonstockexchange.com/regulation/market_rules.asp





8

The changes are applied in the following sections:

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

3.0 December 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: 3, 5.1.2.6, 5.1.2.7, 5.1.2.12.2, 5.1.2.13, 6, 6.7.4, 6.8.14

3.1 February 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

The changes are applied in the following sections: 5.1.2.4, 5.1.2.9, 5.1.2.11.1, 6.6.3, 6.7.5, 6.8.3, 6.8.4, 6.8.12, 6.8.14, 6.8.17, 6.8.18

3.2 March 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Added the following sections: 5.2.3

Changes are applied in the following sections: 5.1.2.5, 5.1.2.6, 5.1.2.7, 6.6.3, 6.7.4, 6.8.4, 6.8.20, 7.1.1, 7.1.2, 7.2.1, 7.2.2, 9.1


Changes are applied in the following sections: 7.1.1, 7.2.1

4.0 April 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Changes are applied in the following sections: 5.1.2.6, 5.1.2.7, 6.8.20


9

Changes are applied in the following sections: 2.1, 5.1.2.6

4.2 May 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Changes are applied in the following sections: 1.3, 5.1.2.13

4.3 May 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Changes are applied in the following sections:

4.1.3

5.0 June 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Changes are applied in the following sections: 5.1.2.13, 5.1.2.13.1

Added the following sections: 7.3, 7.3.1, 7.3.2

5.1 August 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.

Changes are applied in the following sections: 5.1.1.1, 5.1.2.1, 7.2.1

Added the following sections: 3.1.7.1, 3.1.7.2, 3.1.7.3

5.2 December 2012 Updated version of this document published via the Borsa Italiana’s website and distributed to customers.


3.1.7.3, 5.1.1, 5.1.2.8, 5.1.2.9, 5.1.2.10, 5.1.2.13.1

6.0 February 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana’s website and

10

distributed to customers.


Changed sections 3.1.2, 5.1.2.9, 5.1.2.11.2, 6.7.5, 6.8.4

Added section 3.1.8,

6.1 April 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana’s website and distributed to customers.


Changed sections 3.1.4, 3.1.7.3, 5.1.2.1, 6.8.4

Added sections 3.1.9, 3.1.10

6.2 May 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana’s website and distributed to customers.


5.1.2.6, 5.1.2.7

6.3 June 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana’s website and distributed to customers.


4.3, 5.1.2.6, 5.1.2.10, 8

6.4 August 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana’s website and distributed to customers.


3.1.5, 5.1.1.1, 5.1.2.1, 5.1.2.8, 5.1.2.13, 5.1.12.13.1, 5.1.12.13.2, 6.6.1


Changes are applied in the following sections: 5.1.1.1, 5.1.2.1, 6.6.1, 6.8.5, 6.8.6, 7.1, 7.2

11


Changes are applied in the following sections: 6.8.6

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]

mailto:[email protected]

12

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.

Market Data Group (Main Site)

Real-Time

Channel A

(UDP)

Replay Channel

(TCP)

Recovery

Channel (TCP)

Instruments,

Order Book Updates,

Trades,

Indicative Auction Info,

Trading Status,

Announcements,

Daily Schedules

Recipients

Order Book

Snapshot

Market Data Group (Backup Site)

Real-Time

Channel B (UDP)

Replay Channel

(TCP)

Recovery

Channel (TCP)

Instruments,

Order Book Updates,

Trades,

Indicative Auction Info,

Trading Status,

Announcements,

Daily Schedules

Order Book

Snapshot

Snapshot

Request

Snapshot

Request

Missed

Messages

Missed

Messages

Missed

Message

Request

Missed

Message

Request

13

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 (currently set to 2 secs.) 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.

14

3 Service Description

3.1 Overview of a trading day

3.1.1 Trading on the order book

The regular trading day for on-book trading can, for each instrument, consist of many scheduled sessions: Pre Trading (Start of Trading), Opening Auction Call, Regular (Continuous) Trading, Re-Opening Auction Call, Closing Auction Call, Post-Close etc. The start time for each of these sessions may vary from one set of instruments to another. The Symbol Status message will be published on the Real-Time channel to indicate when a particular session has commenced for an instrument with a Book Type of “1”.

3.1.2 Trade Reporting

At the start of the reporting period a Symbol Status message, with a Trading Status of “T” and a Book Type of “2”, will be broadcast for each instrument for which trade reporting is permitted. Similarly, a Symbol Status message, with a Trading Status of “v” and a Book Type of “2”, will be broadcast for each such instrument at the end of the trade reporting period.

However, it should be highlighted that for the current implementation the value “v” will not be disseminated for Borsa Markets.

At the start of the CPX session, a Symbol Status message, with Trading Status of “u” will be broadcasted for each instrument for which the CPX session is started.

At the start of Post Close session, a Symbol Status message, with a Trading Status of “b” and a Book Type of “2”, will be broadcast for each instrument for which the Post Close session is started. Similarly, a Symbol Status message, with a Trading Status of “x” and a Book Type of “2”, will be broadcast for each such instrument at the end of the post close period.

A Symbol Status message, with a Trading Status of “c” and a Book Type of “2”, will be broadcast for each such instrument to indicate the market close.

3.1.3 Start of Day (Market Open)

The market data feed begins at the start of day. Few minutes after the Start of Day (means market open), a System Event message will be published with the Event Code “O”. Outside the Time message, this will be the first application message for the day.

15

3.1.4 List of instruments

A Symbol Directory message will be broadcast for each active and suspended instrument on the Real-Time channel at the Start of Day (means market open). This will be subsequent to the System Event message indicating Start of Day.

Depending on the ITCH Gateway Process configuration at the central site, Symbol Directory message could be broadcast for inactive instruments in the Real Time channel.

Price band tolerances %, static circuit breaker tolerances % and dynamic circuit breaker tolerances % will also be disseminated via the Symbol Directory message on the Real-Time channel at the Start of Day (i.e. the Start of Market). Then if those are changed intra-day, that will also be disseminated.

3.1.5 Daily Schedule

The market data feed will disseminate the daily schedule of all active and suspended instruments via the Daily Schedule message on the Real-Time channel at the Start of Day (i.e. the Start of Market). The Daily Schedule messages will be disseminated <n> (a configurable time) minutes after the Start of Market. Then if a scheduled session gets extended or shortened by BIT, the adjusted daily schedule from that point onwards will be disseminated.

The Daily Schedule will also be disseminated after Closing Auction Call where the start and end time of each session after Closing Auction Call is shifted forward by the action random time.

3.1.6 Trading Status

Symbol Status message will disseminate the status changes in the exchange real time. Symbol Status message will also indicate whether the status changes take place in the order book or off book.

3.1.7 Order Book Management

The market data feed provides recipients with the order depth for the entire order book. It provides the side, price and displayed quantity of each active order.

Details of all active orders will be sent at the start of the first session in which the order book is published. There after the order book updates will be sent incrementally real time.

3.1.7.1 Adding an Order

An Add Order message will be sent each time a new visible anonymous order is added to the order book. The message includes the side, price and displayed quantity of the order.

The message also includes an identifier of the order which will be referenced on all future updates (e.g. executed, deleted, modified, etc.) for the order. The recipients will be able to identify their own orders with this Order ID while ensuring anonymity as the same Order ID will also be tagged in the execution reports carrying the

16

relevant order information in FIX or Native Trading gateway. The ITCH messages will represent this Order ID in binary while the Trading gateways will represent the same Order ID in Hexadecimal. Order IDs are unique across instruments and days.

3.1.7.1.1 Market Orders

The displayed quantity of each market order is disseminated during an auction call session via the Add Order message. Such a message will include a price of zero and an indication that the order is a market order via the Flags field.

3.1.7.1.2 Attributed Orders

The Add Attributed Order message will be used in the case of an attributed/named order. The identity of the firm that submitted the order will be included in the message.

If the submitted named order is also a market order it will include a price of zero and an indication that the order is a market order via the Flags field.

3.1.7.1.3 Quotes

Quote message will be handled as two separate buy and sell orders. Buy side of the quote is added to the order book before Sell side. Once a Quote is added, an Add Order message for the Buy side will be sent which will be followed by an Add Order message for the sell side.

If the sell side of the quote is expired during the entry, an Add Order message for the Buy side will initially be sent before being followed up by Order Deleted message for Buy side.

3.1.7.2 Deleting an Order

An Order Deleted message will be used to notify recipients if a displayed order is cancelled or expired. The identifier of the order will be included in the message.

3.1.7.3 Modifying an Order

An Order Modified message will be sent if the display quantity of an order or its price is changed or if an order loses time priority. The message will include the applicable display quantity and price as well as an indication of whether the order has retained or lost its time priority. A modification will not result in the order being assigned a new Order ID.

Certain scenarios involving the execution of an iceberg order will result in the transmission of following messages: an Order Executed to report the execution and an Add Order message to report the replenishment. However, during an auction which involves execution of an iceberg order, Order Executed With Price/Size message will be sent followed by Add Order message to report order execution and replenishment respectively.

17

3.1.8 Executions

An Order Executed message will be sent whenever a displayed order is fully or partially filled at its displayed price. On receipt of this message recipients should deduct the quantity specified in the field Executed Quantity from the quantity displayed for the order in the order book. The Order Executed message does not contain an explicit price. The execution price will be the limit price of the order as indicated in the last Add Order, Add Attributed Order or Order Modified message sent for it.

An Order Executed With Price/Size message will be sent if a displayed order is fully or partially filled at a price different from its displayed price (e.g. during an auction) On receipt of this message recipients should change the quantity displayed for the order in the order book to that specified in the field Display Quantity. The message contains an explicit execution price and an instruction as to whether or not the trade should update time and sales and statistics displays.

At Continuous trading, if the partial execution of an iceberg order replenishes the initial visible quantity, instead of Order Executed With Price/Size message two other messages (Order Executed message and Add Order message) will be disseminated by the system. The Order Executed message will notify the trade and the subsequent Add Order message notify the replenished new visible quantity.

Following an auction, an Order Executed With Price/Size message will be disseminated to notify iceberg order execution with the Display Quantity set to zero (0) if the peak has been fully filled. An Add Order message will be disseminate after uncrossing to notify the iceberg replenishment.

As an order may be filled in multiple executions, recipients may receive several Order Executed and Order Executed With Price/Size messages for a particular order. The effect of each message is cumulative. When the displayed quantity of an order reaches zero it should be removed from the order book.

3.1.9 Execution of Hidden Quantity

The Trade message is sent whenever the non-displayed portion of an iceberg order is fully or partially filled during regular (continuous) trading. An Order Executed or Order Executed With Price/Size message will not be sent in such a scenario.

If both the displayed and non-displayed quantity of an iceberg order is partially filled by an incoming order, the server will transmit following messages if the execution happens as stated in the following scenario: an Order Executed message for the execution of the displayed portion, an Add Order message for the order replenishment, a Trade message for the execution of the non-displayed portion (after the replenishment) and an Order Executed message for the partial execution of the replenished visible quantity.

If both the displayed and non-displayed quantity of an iceberg order is partially filled by an incoming order, with no further executions on the replenished visible quantity, the server will transmit two messages: an Order Executed message for the execution

18

of the displayed portion, an Add Order message for the order replenishment, a Trade message for the execution of the non-displayed portion (after the replenishment).

If both the displayed and non-displayed quantity of an iceberg order is entirely filled by an incoming order, the server will transmit two messages: an Order Executed message for the displayed portion and a Trade message for the non-displayed portion.

3.1.10 Auctions

The executions that take place during an auction will be reported as a single bulk print via the Auction Trade message. This message will include details of the type of auction (i.e. Opening, Closing, Re-Opening etc.), the auction price and the total volume executed.

Each displayed order executed in the auction will be updated via an Order Executed With Price/Size message irrespective of whether or not it was executed at its displayed price. The Printable field of each such message will be “N” to indicate to recipients that it should not update time and sales and statistics displays. This is the only scenario in which the printable field will be populated with the value “N”.

3.1.11 Cross Orders

The market data feed will disseminate the Cross ID and Cross Type for an execution of a Cross/BTF order via the Trade message.

3.1.12 Time and sales

Clients may build time and sales and statistics displays by combining the execution information received via the Order Executed, Order Executed with Price/Size, Trade, Auction Trade and Off-Book Trade messages published by the server.

3.1.13 Announcements

The market data feed will disseminate the announcements made by market supervision via the Announcements message.

In addition to the actual text of the announcement and an associated headline or subject, recipients are provided with its urgency, the time it was generated and the list of instruments and underlying, if any, to which it relates.

3.1.14 End of Day

The market data feed will stop at end of day. A System Event message will be published with the Event Code “C”. This will be the last application message for the day. All open TCP/IP connections to the Recovery or Replay channels will be disconnected by the server. Clients will be unable to login to these channels after this time.

19

4 Connectvity

4.1 Transmission Standards

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

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

4.1.3 CompIDs

The CompID and the IP address 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. However, a CompID may, at any particular time, only be logged into one TCP channel across all market data groups. 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.

4.1.3.1 Passwords

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

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

20

4.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. On unexpected disconnection from the Production feed gateway a client should try to reconnect three times to the primary gateway with a time out value of five 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.

21

5 Recovery

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

5.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). Active requests of multiple clients will be served on a round robin basis. Clients are unable to cancel outstanding Replay Requests.

5.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 and password in the Username and Password field (Please note that passwords can only hold a maximum of 10 characters and as such, all passwords should adhere to this limit). 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.

22

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 log on attempt to the Replay Channel made by an already logged in client via the same TCP/IP connection will receive a Replay Response Message with Status = e [Failed (Other)].

If a client who is already logged in sends another log on attempt via a different TCP/IP connection the system responds with a Login Response message with Status = e (Failed (Other)) and closes 2nd TCP/IP connection. First connection is not closed in this case.

5.1.1.2 Heartbeats

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

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

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

23

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

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

5.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 and password in the Username and Password field (Please note that passwords can only hold a maximum of 10 characters and as such, all passwords should adhere to this limit). 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, IP address or invalid password 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 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 logged into the Replay channel n times during the current day (exceeding the configured number on the central site), the server will reject any new

24

logon attempt with a Login Response and then break the TCP/IP connection. The Status of such a Login Response message will be “b”. The Replay channel supports a configurable number concurrent logins across all clients. Once the number of active logins has reached this limit, the server will reject login requests from additional clients with a Login Response and then break the TCP/IP connection. The Status of such a Login Response message will be “d”.

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 log on attempt to the Recovery channel made by an already logged in client via the same TCP/IP connection will receive a Snapshot Response Message with Status = e [Failed (Other)].

If a client who is already logged in sends another log on attempt via a different TCP/IP connection the system responds with a Login Response message with status = e (Failed (Other)) and closes 2nd TCP/IP connection. First connection is not closed in this case.

At a particular point of time the Snapshot Channel can queue only a configurable number (currently set to 10) unprocessed requests from a client. The server will reject any further Snapshot Request messages via a Snapshot Response message. The Status of such a message will be “c”.

5.1.2.2 Heartbeats

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

5.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 Snapshot Response 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.

25

A Snapshot Request may optionally include a Request ID which, if specified, will be included in each Snapshot Response and Snapshot Complete sent in response to it.

5.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 Recover From 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 Response will be immediately followed a Snapshot Complete if there are no active instruments for the specified segment.

5.1.2.5 Order Book Snapshots

Order books are maintained per sub book of an instrument (e.g. regular etc.) A Snapshot Request with a Snapshot Type of Order Book (0) may be used to request a snapshot of the current order book 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.

BIT currently supports two sub books per instrument: regular and off-book. As an order book is only maintained for the regular book, the results of a request for all books for a particular instrument and the regular book of the instrument will be identical. An order book request that includes the off-book sub book will be rejected. 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.

A request that relates to a single sub book of an instrument may include the sequence number of the Real-Time channel from which the client can build its order books. The sequence number, if any, included in such a Snapshot Request is validated by the server against the sequence number with which its current order

26

book snapshot is synchronized. In the unlikely event the sequence number included in the Snapshot Request is higher than that with which the server’s current order book snapshot is synchronized, the request will be rejected. The Snapshot Response transmitted in such an event will include a Status of “O”.

The value in the sequence number field of a Snapshot Request is ignored by the server if the request relates to more than one sub book.

5.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 should be ignored if the request is rejected.

The Snapshot Response will, if the request is accepted, include the message sequence number of the Real-Time channel with which the instrument’s order book snapshot will be synchronized; this sequence number will be equal to or higher than the one, if any, included in the Snapshot Request (this is the behavior if a Sub Book is specified in the snapshot request; if a Sub Book is not specified in the snapshot request, the sequence number will be 0 in the response). The response will also include the total number of active orders for the requested instrument in the Order Count field if a Sub Book is specified in the Snapshot Request; if a Sub Book is not specified in the Snapshot Request, then the Order Count field will be 0 in the response.

Also note that if the Sub Book is specified yet the same Sub Book is not attached to the instrument then the Snapshot Request is rejected.

The client should buffer all messages on the Real-Time channel for the order book with sequence numbers greater than that specified in the Snapshot Response.

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

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 of the Real-Time channel with which the order book snapshot was synchronised and the instrument and sub book to which it relates. It will also include the current trading status of the book. 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 Snapshot Complete message, while a Snapshot Response message is to be expected (to notify the Snapshot Request is rejected) with the status “a” if the instrument has no on book definition attached.

27

If a Snapshot Request is made for an instrument (suspended or not) before the first tradable session, the value of the sequence number of Snapshot Complete message

will be synchronized with the real time channel. 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 the sequence number it synchronises with, in the real time channel.

Also 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. The Trading Status field in the Snapshot Complete message sent for the order book of the suspended instrument will contain a null value.

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 value "w" (No Active Session).

5.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 should be ignored.

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

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 of the Real-Time channel with which the order book snapshot for the instrument was synchronised. While such a Snapshot Complete will include the instrument and sub book to which it relates, it will not include a value in the Segment field. It will also include the current trading status of the book. 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.

28

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 book level Snapshot Complete message for the instruments with empty order books. The system will send the relevant market data followed by 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

If a Snapshot Request is made for a segment before the first tradable session, the value of the sequence number of Snapshot Complete messages sent in response for each instrument will be synchronized with the real time channel.

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 the sequence number it synchronises with, in the real time channel.

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

5.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:





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.

29

Server supports statistics for both regular book and off book. If SnapshotRequest is sent with SubBook=0 or 2 for the instrument with off-book definition attached, it is accepted. If SnapshotRequest is sent with SubBook=1 or 3 for the instrument with off-book definition attached, it is rejected. 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 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.).

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, in addition to the Snapshot Complete message disseminated per instrument, 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.

5.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 Recover From 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 Recover From 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.


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

30

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, in addition to the Snapshot Complete message disseminated per instrument, 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 to which it relates. The Sequence Number, Instrument ID, Sub Book and Trading Status fields of the message should be ignored.

5.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:





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.

Note that if the Sub Book is specified in the request yet the same Sub Book is not attached to the instrument then the Snapshot Request is rejected. If the request is sent with one for all sub books (i.e. SubBook=3) then all sub books must be attached to the instrument or else the request is rejected.


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

31

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, in addition to the Snapshot Complete message disseminated per instrument, 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.

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

5.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 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 Recover from 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.

32

5.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 Recover From 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 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.


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

33

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


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

34

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 and the message should state the current status of the particular book.

5.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 ‘Schedule Change Reason’ = U (Unchanged).

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

a) If the Segment field is tagged with/without the Instrument ID field, 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.

35

5.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 (this will be done for Halted and Suspended Instruments as well in addition to active instruments). The server will transmit a Snapshot Complete message once the Daily Schedule message is disseminated for a particular instrument. 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.


5.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. If the order book is specified, then the Snapshot Request is only accepted for requests valid for the specified order book. (E.g. if the instrument has the Off Book trading definition attached, only requests with SubBook=1 or 3 are accepted where as requests with SubBook=0 or 2 are rejected). 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 (this will be done for

36

Halted and Suspended Instruments as well in addiction to active instruments). 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 and the

message should state the current status of the particular book.

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

5.2 Failures at the Exchange

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

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.

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

5.2.3 Level 2-ITCH multicast channels

The table below outlines the initial proposed distribution of market data group across channels (unit header section 6.5).

37

Primary Market Data Group

(feed a)

Secondary Market Data

Group (feed b)

Channel name

A A MTA-A

B B MTA-B

C C ETF-A

D D ETF-B

E E MOT

F F SEDEX

G G TAH / PTTS / Admin TAH

X X Admin

H … Z H … Z Reserved for future use

If the market data feed is, in the unlikely event of an outage, failed over to the backup site the distribution of market data group across channels is changed as follows:

Primary Market Data Group

Secondary Market Data

Group

Channel name

a a MTA-A

b b MTA-B

c c ETF-A

d d ETF-B

e e MOT

f f SEDEX

g g TAH / PTTS / Admin TAH

x x Admin

h..z h..z Reserved for future use

38

6 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). In certain scenarios, a single event in the matching system will result in the publication of multiple messages on the market data feed. Recipients should ensure that their applications are developed to process each of the messages covered in this section irrespective of the order in which they are transmitted.

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

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

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

39

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

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

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.



40

6.4.1 Administrative Messages

Name Message Type Usage

ASCII Hex

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.

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

41

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.

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.

42

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.

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

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

43

6.6 Administrative Messages (Client – Initiated)

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

Maximum password length is 10 characters.

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

6.6.3 Snapshot Request



44

Message Type


0x81 Snapshot Request

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 zeros 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

Recover From 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 Trades (3) or Announcements (5).

Request ID 26 4 UInt32 Optional identifier of the request

6.6.4 Logout Request


45


Message Type


0x05 Logout Request

6.7 Administrative Messages (Server – Initiated)

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

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

6.7.3 Replay Response


46


Message Type


0x04 Replay Response

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)

6.7.4 Snapshot Response



Message Type


0x82 Snapshot Response

47

Sequence Number

2 4 UInt32 Sequence number with which the snapshot is synchronised. This will be zero if Status is not “A” or if a Sub Book is not specified in the snapshot request or if the snapshot request is for a segment. Ignore if Snapshot Type is not Order Book (0).

Order Count 6 4 UInt32 Number of orders that will be transmitted in the snapshot. Order Count will be zero if Order Book is empty or Status is not “A” or if a Sub Book is not specified in the snapshot request or if the snapshot request is for a segment. Ignore if Snapshot Type is not Order Book (0).

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)

48

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.

6.7.5 Snapshot Complete



Message Type


0x83 Snapshot Complete

Sequence Number

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

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 zeros 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

49

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)

z Closing Price Publication

u Closing Price Cross

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.

50

6.8 Application Messages

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

6.8.2 System Event



Message Type


0x53 System Event

Nanosecond 2 4 UInt32 Nanoseconds since last Time message.

Event Code 6 1 Byte Value Meaning

C End of Day

O Start of Day

6.8.3 Symbol Directory



Message Type


0x52 Symbol Directory


Instrument ID

6 4 UInt32 Instrument Identifier.

Reserved 10 1 Byte Reserved field

51


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

Segment 37 6 Alpha Segment the instrument is assigned to.

Underlying 43 4 UInt32 Identifier of the underlying instrument. This field will contain 0 if the instrument is not a derivative.

Reserved Field

47 2 Alpha Reserved for Future Use

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

52

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

6.8.4 Symbol Status



Message Type


0x48 Symbol Status


Instrument ID




53

Trading Status


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

x End of Post Close

y Pre-Trading (Start of Trading)

z Closing Price Publication

u Closing Price Cross


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

54

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” or “9”. New End Time will be in terms of the local market time (i.e. not UTC).

Sub Book 27 1 UInt8 Value Meaning

1 Regular

2 Off-Book

6.8.5 Add Order



Message Type


0x41 Add Order


Order ID 6 8 UInt64 Identifier for the order.

Side 14 1 Byte Value Meaning

B Buy Order

S Sell Order

55

Quantity 15 8 UInt64 Displayed quantity of the order.

Instrument ID

23 4 UInt32 BIT Instrument Identifier.



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.

6.8.6 Add Attributed Order



Message Type


0x46 Add Attributed Order



Side 14 1 Byte Value Meaning

B Buy Order

S Sell Order

Quantity 15 8 UInt64 Displayed quantity of the order.

Instrument ID

23 4 UInt32 BIT Instrument Identifier.



56

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


6.8.7 Order Deleted



Message Type


0x44 Order Deleted



Side 14 1 Bit Field Reserved for Future Use

Instrument ID


6.8.8 Order Modified



Message Type


0x55 Order Modified

Instrument ID

23 4 UInt32 BIT Instrument Identifier

57



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



58

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


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


6.8.11 Order Executed with Price / Size

59

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



60

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

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


6.8.13 Auction Trade



Message Type


0x51 Auction Trade

61


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


6.8.14 Off-Book Trade



Message Type


0x78 Off-Book Trade


62

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

63

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.

Reserved Field


Flags 73 1 Bit Field

Bit Name Meaning

2 Channel Type

1: Primary

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 NULL, if a value has not been specified in the original trade or it has been specified as ‘No’ in the original trade.

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

64

6.8.15 Trade break



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



65

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

66

6.8.17 Statistics



Message Type 1 1 Byte Hex Meaning

0x77 Statistics

Nanosecond 2 4 UInt32 Nanoseconds since last

Time message.

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 or Previous Close Price is manually cleared by the Exchange, a -1 value will be stamped in this field. Will indicate the yield if instrument is traded on yield.

67

Open/ClosePriceIndicator

21 1

Alpha

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

Value Meaning

A UT (Auction

Trade)

B AT (Regular

Trade)

D

Last AT (Last

Regular

Trade)

E

Last UT (Last

Auction

Trade)

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

68

Reserved 22 1 Bit Field

Reserved for future use

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

P OPA Auction

This field will contain a NULL 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.

69

Action Type 57 1 Byte Value Meaning

C Cancelled Trade

N Trade

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 zeros for on-book trades.

Reserved Field


Flags 75 1 Bit Field

This will contain only zeros for on-book trades. For off-book trades, it is required by the Borsa Italiana system in order to communicate that the exchange is always the primary to publish the trade. The value should be always set to P (Primary).

Bit Name Meaning

2 Channel Type

1: Primary

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

70

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.

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

Text 65 120 Alpha Text of the announcement.

71

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

6.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 (hex 55) Unchanged

K (hex 4B) Unavailable

X (hex 58) Session Extension

S (hex 53) Session Shortening

No of Sessions

12 2 UInt16 Number of sessions the times are indicated for

72

Session 1 14 1 UInt8 Value Meaning

T (hex 54)

Regular (Continuous) Trading/Start Trade Reporting

S

(hex 53)

Trading Stop

a

(hex 61)

Opening Auction Call (Pre-Open)

b (hex 62)

Post-Close

d (hex 64)

Closing Auction Call

g (hex 67)

OPA Auction Call

v (hex 76)

End of Trade Reporting

x (hex 78)

End of Post Close

y (hex 79)

Pre-Trading (Start of Trading)

z (hex 7A)

Closing Price Publication

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)

73





















74





















75












76

7 Data Mapping

7.1 Conversion of Order ID

7.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 4 bits 30 bits

Time Stamp [0-3] [0-7] [0-15] Unique Identifier

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

ID Partition id

Thread id Order number

8 bytes

Prefix O

Start Up Time Date and time the system was started specified as the number of five minute intervals since midnight 1st January 2010 (i.e. in UTC). The number of intervals is expressed as a string of ASCII characters representing base 62 digits

ID Type of the Identifier

ExecID 0

TradeID 1

OrderID 2

RFQID 3

Partition ID Load ID (1,2,3)

Tread ID Internal load ID (1,2,3,4)

Order number Seq number

77

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

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

7.1.2.2 Example

OrderID in FIX (Ascii base 62 characters)

O004Xj7Wu76ta

OrderID in ITCH gateway (Binary ID converted to decimal)

61512470073704470

Steps to follow

1. Remove the prefix ‘O’

2. Convert using base 62 conversions in to decimal as depicted below

3. The derived decimal value should be read in Binary format match the ITCH OrderID

Note: Please refer to the base 62 conversion table attached below 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

78

7.1.3 Base 62 mapping table

Note

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

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

79

7.2 Conversion of Trade ID

7.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 4 bits 22 bits

Time Stamp [0-2] [0-7] [0-15] Unique Identifier

The number of 5 mins intervals from Jan 1,

2010)

ID Partition id

Thread id Trade number

8 Bytes

Prefix T On-Book Trade

M Off-Book Trade

Start Up Time Date and time the system was started specified as the number of five minute intervals since midnight 1st January 2010 (i.e. in UTC). The number of intervals is expressed as a string of ASCII characters representing base 62 digits

ID Type of the Identifier

ExecID 0

TradeID 1

OrderID 2

RFQID 3

Partition ID Load ID (1,2,3)

Tread ID Internal load ID (1,2,3,4)

Trade number Seq number

80

7.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, a-z

Base 62 encoded Trade ID

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

7.2.2.2 Example

ASCII Trade ID for FIX T0VsRW8NQq

Binary Trade ID ( decimal ) for ITCH market data feed

112262475939900

Steps to follow

1. Remove the prefix ‘T’/’M’

2. Convert using base 62 conversions in to decimal as depicted below

3. The derived decimal value should be read in Binary format to match the ITCH

TradeID

81

FIX Trade ID (Ascii Character)

Corresponding decimal value

Base 36^x value Multiplied decimal value

q 52 62^0 1

52

Q 26 62^1 62 1612

N 23 62^2 3,844 88412

8 8 62^3 238,328 1906624

W 32 62^4 14,776,336 472842752

R 27 62^5 916,132,832 24735586464

s 54 62^6 56,800,235,584 3067212721536

V 31 62^7 3,521,614,606,208 109170052792448

0 0 62^8 218,340,105,584,896 0

112262475939900

7.2.3 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 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

82

7.3 Conversion of Negative Values in Price Fields

7.3.1 Encoding Negative Values in Price Fields

Decimal value = -1

Decimal value with eight implied decimal places = -100000000

Remove sign bit = 100000000

Convert to binary = 00000000 00000000 00000000 00000000 00000101 11110101

11100001 00000000

Add sign bit = 10000000 00000000 00000000 00000000 00000101 11110101

11100001 00000000

Hex value = 80 00 00 00 05 f5 e1 00

Hex value converted to Little endian = 00 e1 f5 05 00 00 00 80

7.3.2 Decoding Negative Values in Price Fields

Received bytes in hex = 00 e1 f5 05 00 00 00 80

Change the byte order to big endian = 80 00 00 00 05 f5 e1 00

Convert to binary = 10000000 00000000 00000000 00000000 00000101

11110101 11100001 00000000

Most significant bit is set. Therefore this is a negative value.

Remove the sign bit = 00000000 00000000 00000000 00000000 00000101

11110101 11100001 00000000

Convert to decimal = 100000000

Add sign to decimal = -100000000

Mark eight implied decimal places -1.00000000

83

8 Trading Halt Reason Codes Code Reason

1 News Pending (default)*

2 Fast Market (default)*

3 System Problem (default)*

101 Instrument-level circuit breaker tripped

102 Regulatory Halt

9998 Matching partition suspended

9999 System suspended

Space Reason not available / Manually Specified reason

*Please note that the reason for code 1,2 and 3 are set by default but can be modified in the ‘Session Change Reasons’ table in Exchange Manager. In addition, more reasons can be added thus halt reasons are sent out as per the set up on the said table.

84

9 Order book scenarios

9.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 Snapshot Complete message for each book of the instrument

Instrument has an empty order book


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

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

85

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


86

Copyright © April 2014 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

V6.6

MIT303 BIT - MILLENNIUM EXCHANGE Level 2-ITCH Specification · MIT303 – BIT - MILLENNIUM EXCHANGE...

Documents

Transcript of MIT303 BIT - MILLENNIUM EXCHANGE Level 2-ITCH Specification · MIT303 – BIT - MILLENNIUM EXCHANGE...