M I T 303 B I T - M I L L E N N I U M E X C H A N GE. MITCH Specification. Issue 6.7 October 2014

Transcription

1 M I T 303 B I T - M I L L E N N I U M E X C H A N GE MITCH Specification Issue 6.7 October 2014

2 Contents MITCH Specification Introduction Purpose Readership Document series Document history Enquiries System Architecture Real-Time Channel Replay Channel Recovery Channel Service Description Overview of a trading day Trading on the order book Trade Reporting Start of Day (Market Open) List of instruments Daily Schedule Trading Status Order Book Management Executions Execution of Hidden Quantity Auctions Cross Orders Time and sales Announcements End of Day Connectvity Transmission Standards Multicast Channels Replay and recovery Channels CompIDs Production IP Addresses and Ports Failure and Recovery Recovery Recipient Failures... 22

3 5.1.1 Replay Channel Recovery Channel Failures at the Exchange Snapshots on the Real-time channel Resetting Sequence Numbers MITCH multicast channels Message Formats Packet Composition Sequence Numbers Timestamps Data Types Administrative Messages Application Messages Unit Header Administrative Messages (Client Initiated) Login Request Replay Request Snapshot Request Logout Request Administrative Messages (Server Initiated) Heartbeat Login Response Replay Response Snapshot Response Snapshot Complete Application Messages Time System Event Symbol Directory Symbol Status Add Order Add Attributed Order Order Deleted Order Modified Order Book Clear Order Executed Order Executed with Price / Size Trade Auction Trade Off-Book Trade Trade break Auction Info Statistics

4 Recovery Trade Announcements Daily Schedule Data Mapping Conversion of Order ID Order ID format (in binary) Order ID format (in ASCII) Base 62 mapping table Conversion of Trade ID Trade ID format (in binary) Trade ID format (in ASCII) Base 62 mapping table Conversion of Negative Values in Price Fields Encoding Negative Values in Price Fields Decoding Negative Values in Price Fields Trading Halt Reason Codes Order book scenarios Order book scenarios for instrument Order book scenarios for segment

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

6 1 Introduction Borsa Italiana will provide the MITCH protocol enabling clients to receive real-time data at lowest possible latencies. The MITCH 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) (ii) (iii) (iv) (v) (vi) (vii) (viii) 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. Price and volume for each executed on-book trade. Price, volume, trade type, date and time of each confirmed off-book trade. Indicative auction price and the associated trade volume and imbalance. Official opening and closing price as well as previous day s closing price, static reference price and dynamic reference price. Instrument trading status. Announcements 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 MITCH 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 MITCH feed as well as details on how to connect to the Replay and Recovery services available on Millennium Exchange. When read in conjunction with the other Millennium Exchange guides, it is intended that these documents provide all of the details directly connected Borsa Italiana customers require to develop to the new services. This document is particularly relevant to technical staff within Borsa Italiana s member firms, information vendors and other market participants interested in receiving Borsa Italiana market data. 6

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 MITCH Specification (this document) MIT305 BIT Markets Reference Data 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: English Version: 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. 7

8 The changes are applied in the following sections: , , 5.4, 5.7.2, 5.7.5, 5.8.3, , 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, , , , , 6, 6.7.4, 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: , , , 6.6.3, 6.7.5, 6.8.3, 6.8.4, , , , March 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. Added the following sections: Changes are applied in the following sections: , , , 6.6.3, 6.7.4, 6.8.4, , 7.1.1, 7.1.2, 7.2.1, 7.2.2, March 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: 7.1.1, 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: , , April 2012 Updated version of this document published via the Borsa Italiana s website and distributed to customers. 8

9 Changes are applied in the following sections: 2.1, 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, 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: 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: , Added the following sections: 7.3, 7.3.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: , , Added the following sections: , , December 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, , , , February 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana s website and 9

10 distributed to customers. Changes are applied in the following sections: Changed sections 3.1.2, , , 6.7.5, 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. Changes are applied in the following sections: Changed sections 3.1.4, , , Added sections 3.1.9, May 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: , June 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: 4.3, , , August 2013 Updated version of this document valid for Drop 8.0 published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: 3.1.5, , , , , , , March 2014 Updated version of this document published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: , , 6.6.1, 6.8.5, 6.8.6, 7.1,

11 6.6 April 2014 Updated version of this document published via the Borsa Italiana s website and distributed to customers. Changes are applied in the following sections: October 2014 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, 3.1.5, , 4.1.3, , , 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: Service Desk Free Toll Number: MIT-migration@borsaitaliana.it ; clients-services@borsaitaliana.it 11

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. Real-Time Channel A (UDP) Market Data Group (Main Site) Replay Channel (TCP) Recovery Channel (TCP) 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. Instruments, Order Book Updates, Trades, Indicative Auction Info, Trading Status, Announcements, Daily Schedules Missed Message Request Missed Messages Snapshot Request Order Book Snapshot 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). Recipients 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. 12 Instruments, Order Book Updates, Trades, Indicative Auction Info, Trading Status, Announcements, Daily Schedules Real-Time Channel B (UDP) Missed Message Request Replay Channel (TCP) Missed Messages Market Data Group (Backup Site) Snapshot Request Order Book Snapshot Recovery Channel (TCP)

13 Updated the data types MITCH 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. 13

14 3 Service Description 3.1 Overview of a trading day 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 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 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. 14

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 MITCH 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 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. Furthermore a Daily Schedule message will be disseminated if a Closing Auction Call session is extended due to a price monitoring or market order imbalance. However the same extensions for an Opening Auction Call will not prompt a Daily Schedule message 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 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 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. 15

16 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 relevant order information in FIX or Native Trading gateway. The MITCH 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 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 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 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 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 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. Moreover, when amending the quote prices, Order Modified messages will be sent to the relevant sides. Order Modified message will be sent to the unmarketable side of the quote first. Marketability is decided by looking at the updated quote prices against the prices of the orders/quotes already sitting in the book. This passive order can even be the quote which is to be amended by the quote modification being processed. If both sides are unmarketable, the buy side will be processes first. This 16

17 will make sure order book does not move to locked/crossed states due to the intermediate stages in handling quote modification. 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 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 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. 17

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

19 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

20 4 Connectvity 4.1 Transmission Standards 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 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 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 MITCH feeds. System allows a CompID to connect to a Recovery and Replay channel at the same time, either in the same market data gateway or in different market data gateways. But the system would not allow a CompID to connect to more than one channel of the same channel type at the same time. For an example connecting to two Replay channels or two Recovery channels at the same time would not be allowed 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

21 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

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

23 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 closes the 2nd TCP/IP connection without sending a Login Response message. First connection is not closed in this case Heartbeats The server will not send heartbeats on the Replay channel during periods of inactivity 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 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

24 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 Recovery Channel The TCP Recovery channel should be used by recipients to recover from a largescale 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 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

25 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 closes the 2nd TCP/IP connection without sending a Login Response message. 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 Heartbeats The server will not send heartbeats on the Recovery channel during periods of inactivity 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. 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. 25

26 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 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) (ii) (iii) (iv) All sub books for all instruments in a specified segment. All sub books for a single instrument. Multiple sub books for a single instrument. 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 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 26

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

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