Turquoise. TQ401 - Level 2 MITCH UDP Market Data. Issue January 2018

Transcription

1 Turquoise TQ401 - Level 2 MITCH UDP Market Data Issue January 2018

2

3 Contents 1.0 Introduction Purpose Readership Document Series Document History Enquiries Market Code per Multicast Channel Appendix A Execution Messages Appendix B Halt Reason Codes Connectivity Transmission Standards CompIDs Failover and Recovery Connectivity Policy Service Description Overview of a Trading Day Order Book Management Time and Sales Recovery Recipient Failures Service Interruptions Message Formats Packet Composition Sequence Numbers Timestamps Data Types Message Overview Unit Header Administrative Messages (Participant Initiated) Administrative Messages (Server Initiated) Application Messages 32

4 1.0 Introduction Turquoise provides real-time Level-2 market data via the MITCH UDP protocol. The market data feed is a stream of fixed width binary messages which provides the following real-time information: (i) Order depth for the entire Turquoise Lit (I) Order Book. The feed provides information on the side, price and displayed quantity of each Order in the Order Book. (ii) Indicative auction information for the Turquoise Lit Auctions Book. (iii) Price and volume for each executed on-book trade for the Turquoise Lit (I), Turquoise Lit Auctions (A) and Turquoise Plato (M) Order Books. (iv) Trading status of each instrument The feed also includes a daily download of the instrument list at Turquoise. 1.1 Purpose The purpose of this document is to provide full details of the Level-2 MITCH UDP Market Data service including message types and fields. 1.2 Readership This document outlines the detailed message types and fields for the Level-2 MITCH feed as well as details on how to connect to the Replay and Recovery services available at Turquoise. This document is particularly relevant to technical staff within the MTF s member firms, information vendors and other market participants interested in receiving Turquoise market data. 1.3 Document Series This document is part of series of technical documents providing a holistic view of full trading and information services available which can be found on the Turquoise website here Document Library. Interfaces and information dissemination For further information regarding Turquoise connectivity, trading and subscription to market data, please refer to the following documentation: TQ101 Guide to Migration TQ102 Connectivity Guide TQ103 Trading Technical Parameters TQ201 - Trading Gateway (FIX 5.0) Specification TQ202 - Post Trade Gateway (FIX 5.0) Specification 4

5 TQ203 Drop Copy Gateway (FIX 5.0) Specification TQ301 - Trading Gateway (Native) Specification TQ401 MITCH Level-2 Market Data Specification (this document) TQ501 Guide to Reference Data Services TQ502 Guide to Purchase and sales file Certification and Testing Services For further information regarding Certification of Participant s software and ongoing testing obligations with Turquoise, please refer to the following documentation: TQ601 Guide to Certification TQ602 Certification Report TQ603 Guide to Testing Services LSEG Group Ticker Plant For further information regarding subscription to Turquoise market data from the Group Ticker Plant (GTP), please refer to the following documentation which can be found on the GTP website here GTP Documentation Library : GTP001 Product Guide GTP002 Technical Guide GTP003 Statistics Guide GTP004 Parameters Guide GTP005 Testing Service Guide GTP006 External Source Guide GTP008 Market Attributes Guide 5

6 1.4 Document History This document has been through the follow iterations: Issue Date Description R March 2010 First issue of this document published. R April 2010 Updated to include Service Description. R May 2010 First issue of CDS release 2 document published. R July 2010 Second issue of document published. Change in description for Establishing a Connection. R August 2010 Value added to reflect inactive status of instrument for a Symbol Directory message. Execution messages added as Appendix A. Updated Trade Break message. R September 2010 Changed Sequence Number in Snapshot Request message to a Reserved Field as this is not validated. Added status e to Replay Response and Snapshot Response. R September 2010 Execution of a Hidden Quantity description clarified. Instrument Suspension description clarified. Added details of status e to sections and R October 2010 Added details of Trade Match ID allocation to Appendix A. R October 2010 Added halt reason codes as Appendix B November 2010 Updated Replay message cache size from 20,000 to 65,000 messages December 2010 Update to section 5.3 Timestamps January 2011 Added new values to Session Change Reason under Symbol Status message January 2011 Added details of Symbol Status message dissemination to sections and

7 May 2011 Revision of market data segments in section May 2011 Added Symbol Status value of w (No Active Session) to August 2011 Removed reference to market Order under Add Order message usage in section February 2013 Contact details updated September 2013 The following sections have been updated; 3.1.4; 5.5.2; 5.8.3; 5.9.3; October 2013 The document has been updated to reflect: Call Market and Order Submission Interval will not be available in Production, but will be available in CDS for testing purposes October 2014 Addition of Turquoise Plato Block Discovery messages. The following sections have been updated; 3.1.4; 5.5.2; and Section updated to include Trade Date. Call Market and Order Submission Interval will be available in Production October 2014 Changes to rebrand ITCH to MITCH January 2015 This document has been updated to reflect changes for Millennium 8.6 upgrade. Change Highlights: TradeMatchId changing from base 62 to base 36. Symbol changing from 6 to 8 characters. Changes to message lengths for Snapshot Request, Snapshot Complete, Symbol Directory, Symbol Status, Add Order, Order Book Clear, Trade. The following sections have been updated sections 3.3; 5.7.3; 5.8.5; 5.9.3; 5.9.4; 5.9.5; 5.9.8; ;

8 November 2015 The following sections have been updated to aid clarity: 2.4 Clarified Connectivity Policy Clarified that we use a G offset for encoding and decoding base 36 values Amended Replay connection behaviour when additional messages are sent prior to the exchange of Logons. Clarified that if a user attempts to login to the Replay Channel while already logged in, their connection will now be disconnected, and will no longer receive a Replay Response Message with status e. Clarified rapid login/logout safety mechanism Amended Recovery connection behaviour when additional messages are sent prior to the exchange of Logons. Clarified that if a user attempts to login to the Recovery Channel while already logged in, their connection will now be disconnected, and will no longer receive a Snapshot Response Message with status e. Clarified rapid login/logout safety mechanism. 5.3, Clarified that the Nanosecond field is accurate to the millisecond. 6.0 Added a new market Warsaw Stock Exchange. 8

9 October 2016 Updated Turquoise to Turquoise Plato where appropriate for Turquoise Plato TM Order Book and Turquoise Plato Block Discovery services, and updated Turquoise to Turquoise where appropriate. The following sections have been amended to aid clarity and also to reflect the changes introduced in the Millennium 9.1 upgrade: Clarified Deleting an order behaviour. 3.3 Clarified TradeMatchID behaviour Clarified Execution of Hidden Quantity behaviour Clarified enum a of the Status field Renamed Halt Reason to Reason for clarity Reserved field at offset 34 has been converted to field Trading Phase. Appendix A Clarified MITCH messages April 2017 The following sections have been amended to aid clarity and also to reflect the changes introduced in the Millennium 9.2 (MiFID II compliant) upgrade: 3.3.2, Clarified Trade Cancellation behaviour , Removed the Trade Break message , Extended the length of the Add Order and Order Book Clear messages with a Reserved Field Extended the length of the Trade message with a new Bit field called PTModFlags August 2017 Updated all references of Turquoise to Turquoise. 9

10 3.5.1.A 25 September 2017 Added changes related to the introduction of the Turquoise Lit Auctions TM Order Book: Introduction added Turquoise Lit Auctions TM 1.3 Document Series reformatted and added GTP links Start of Day added Turquoise Lit Auctions TM List Of Instruments added Turquoise Lit Auctions TM Trading Status added Turquoise Lit Auctions TM Instrument Suspension added Turquoise Lit Auctions TM 3.2 Order Book Management added Turquoise Lit Auctions TM Execution of Hidden Quantity added Turquoise Lit Auctions TM Recovery Channel clarified that recovery channel snapshot applicable only to Turquoise Lit TM Order Book Requesting Order Book Snapshots clarified that snaphot applicable only to Turquoise Lit TM Order Book Response to a Snapshot Request for a Segment clarified that snaphot applicable only to Turquoise Lit TM Order Book Administrative Messages - Clarified that Snapshot Request and Snapshot Complete applicable only to Turquoise Lit TM Order Book Application Messages - Added Auction Info message and clarified that existing Trade message applicable for Turquoise Lit Auctions TM Order Book Symbol Directory added Target Book = A for Turquoise Lit Auctions TM Symbol Status added Target Book = A for Turquoise Lit Auctions TM. Also removed references to trade reporting and Trading Status = t which are not applicable to Turquoise Auction Info New message for Turquoise Lit Auctions TM. 10

11 Trade added Trading Phase = 3 and Target Book = A for Turquoise Lit Auctions TM. 7.0 Appendix A Execution Messages. Clarified that existing examples are for Turquoise Lit Order Book and added examples for new Turquoise Lit Auctions TM order book A2 9 th October Trade Clarified that continuous trading (1) applicable to Turquoise Lit TM as well as Turquoise Plato TM Order Book A 11 October 2017 Fixed typo in multiple descriptions of the nanosecond field which is accurate to the microsecond not millisecond January Market Code per Multicast Channel Updated for change of Bolsa de Madrid MIC from XMCE to XMAD effective Jan 3 rd 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 the Technical Account Management Team or your Technical Account Manager if you have any questions about the Millennium Exchange services outlined in this document: Client Technology Services (UK) can be contacted at: Telephone: +44 (0) londontam@lseg.com 11

12 2.0 Connectivity 2.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 Unicast 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. 2.2 CompIDs The CompID of each Participant wishing to connect to the Recovery and Replay channels must be registered with Turquoise 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 CompID may, at any particular time, only be logged into one TCP channel across all market data groups. 2.3 Failover and Recovery Turquoise will have a resilient solution at the primary site. For all TCP/IP connections Participants will be given two pairs of IP addresses, a pair (Primary and Backup) for the primary site and a pair (Primary and Backup) for the secondary site. Participants will be directed to use the primary site pair until directed that a site failover has been invoked. Following this the secondary site pair should be used. On unexpected disconnection from the primary site primary gateway a Participant should try to reconnect 3 times to the primary gateway with a time out value of three seconds on each connection before attempting to connect to the primary site secondary gateway. This should then be retried a further 3 times. After six failed connection attempts (3 on each gateway) the Participant should contact Turquoise for guidance. 2.4 Connectivity Policy An application should attempt to connect a maximum of 3 times to the primary gateway with a minimum time out value of 3 seconds between attempts before attempting to connect to the secondary gateway and this should be retried a maximum of a further 3 times. After 6 failed connection attempts (3 on each gateway) the clients should contact London Stock Exchange for further guidance. 12

13 3.0 Service Description 3.1 Overview of a Trading Day Start of Day Turquoise s normal trading hours can be found in the Trading Service Description. The market data feed itself will be available prior to market open to allow Turquoise participants to establish a connection and download the Symbol Directory before continuous trading begins. Specific times for the market data feed availability are defined in the Guide to Connectivity. The regular trading day will, for each instrument, consist of a single trading session for the Turquoise Lit TM, Turquoise Lit Auctions TM and Turquoise Plato TM Order Books. The start and end times of each of these order Books differs based on the market and are detailed in the Turquoise Trading Service Description. The Symbol Status message will be published on the multicast channel to indicate when the trading session has commenced for an instrument as outlined below. Order Book Target Book Trading Status Book Type Turquoise Lit TM I T 1 Turquoise Lit Auctions TM A T 1 Turquoise Plato TM M T 1 Two minutes after the Start of Day, 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 List of Instruments A Symbol Directory message will be broadcast for each active and suspended instrument on the multicast channel at the Start of Day. This will be subsequent to the System Event message indicating Start of Day. The system will publish separate Symbol Directory messages for the Turquoise Lit TM, Turquoise Lit Auctions TM and Turquoise Plato TM Order Books. Recipients can distinguish the three Books by using the Target Book field Trading Status A Symbol Status message will also be broadcast for each active tradable instrument just after the dissemination of the Symbol Directory message at the start of day, as described in Start of Day above. Subsequently, Symbol Status messages will be used to disseminate status changes in real time. 13

14 3.1.4 Call Market The Symbol Status message will be published to indicate when a Turquoise Plato Uncross TM cycle has started for a particular instrument. The Symbol Status message will be published with Call Market (0) as the Trading Status. Once the Call Market has been published, the Order Submission Interval commences providing Participants 500ms (+/- 1ms) to send in their Orders before the next random period of the Turquoise Plato Uncross TM commences Trading Halt An instrument may be halted and resumed during the trading day. The Symbol Status message will be published to indicate when a particular instrument is halted. The Symbol Status message will be published with Halt (H) as the Trading Status. When trading is resumed a Symbol Status message will be published with the Trading Status indicating Regular Trading (T) The Symbol Status message publishing a halt will also indicate the reason for the halt in the Halt Reason field. When an instrument is halted Participants will not be able to submit new Orders or amend open Orders on the halted instrument. Open Orders can be cancelled. A trading halt will not be carried forward to the next trading day Instrument Suspension An instrument may be suspended during or outside trading hours. The suspension may be lifted later in the day or it may be carried forward to subsequent trading days. The Symbol Directory message will be published with a Status of S if an instrument is suspended during trading hours. A suspension of an instrument is applicable for on-book trading in the Turquoise Lit TM, Turquoise Lit Auctions TM and Turquoise Plato TM Order Books. When an instrument is suspended all open Orders will be deleted and Participants will not be able to submit new Orders until the suspension is lifted. If, at the start of a trading day, an instrument is still in a suspended state it will be included in the Symbol Directory messages published by the server but not the Symbol Status messages. If the suspension is lifted during the trading day recipients will receive a Symbol Directory message with a space in the Status field. A separate Symbol Status message will also be published if trading is enabled for the instrument 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. Participants will be unable to login to these channels after this time. 14

15 3.2 Order Book Management The market data feed will provide recipients with the Order depth for the entire Turquoise Lit TM Order Book. It provides the side, price and displayed quantity of each active Order. For the Turquoise Lit Auctions TM order book it provides indicative auction information only (no imbalance). There will be no Order depth provided for the Turquoise Lit Auctions TM or Turquoise Plato TM Order Books Adding an Order An Add Order message will be sent each time a new visible Order is added to the Turquoise Lit Order Book. The message includes the side, price and displayed quantity of the Order. The message also includes an identifier (Order ID) of the Order which will be referenced on all future updates (e.g. executed, modified, deleted etc.) for the Order Identifying Own Orders Using the Order ID mentioned above, recipients will be able to identify their own Orders on the market data feed. This same Order ID will be tagged in the corresponding execution reports sent via the FIX Trading Gateway, Drop Copy Gateway (SecondaryOrderID) and the Native Trading Gateway (SecondaryOrderID). The Order ID will be represented in 8 byte binary format in both the MITCH and Native Trading Gateway messages but will be represented in 16 character ASCII hexadecimal format in the FIX Trading and Drop Copy Gateway messages. Market data recipients connecting to the FIX Trading and Drop Copy Gateways for Order management will have to do a hexadecimal to binary conversation (or vice versa) to identify own Orders. Note that the field called Order ID on native execution reports (and FIX tag 37 on FIX Trading, Drop Copy and Post Trade Gateway execution reports) is also derived from the MITCH Order ID by conversion to a base62 ASCII character string, with the addition of an O prefix Deleting an Order An Order Deleted message will be used to notify recipients if a displayed Order is cancelled, expired or amended such that the remaining quantity of a partially executed order becomes zero. The Order ID 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 changes, its price changes 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. 15

16 3.2.4 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 or Order Modified message sent for it. As an Order may be filled in multiple executions, recipients may receive several Order Executed 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.3 Time and Sales Recipients may build time and sales and statistics displays by combining the execution information received via the Order Executed and Trade messages published by the server. Each of the above messages will include a day-unique identifier of the trade which will be referenced if a trade is ever cancelled. Trade Match IDs will not be sequential. Trade Match ID in MITCH matches exactly with the Trade Match ID field on native execution reports. It also matches with the TradeMatchID (880) on FIX Trading and Drop Copy execution reports but this is in base 36 (G offset). The same Trade Match ID will be stamped in base 36 (G offset) format in the TradeID (1003) of the Trade Capture Report published via the Post Trade Gateway. Recipients will be able to identify own trades by comparing the Trade Match ID published via market data with the TradeID (1003) published via the Post Trade Gateway. Recipients are expected to perform a binary to base 36 (G offset) conversion (or vice versa) in order to compare the two identifiers. The Trade Match ID published via the market data system will be in binary format Execution of Hidden Quantity The Trade message is sent whenever the non-displayed portion of an iceberg Order or a hidden Order is fully or partially filled during regular trading, or where there is a Turquoise Lit Auctions TM or Turquoise Plato order book uncross. An Order Executed message will not be sent in such a scenario. If both the displayed and non-displayed quantity of an iceberg order is partially/fully filled by an incoming order, an Order Executed message will be sent for the execution of the displayed portion, and a Trade message for the execution of the non-displayed portion. The replenishment will be indicated using an Add Order message which will take place after the execution of both the visible and hidden portions. If the replenished quantity gets an execution, an Order Executed message will be used to indicate it to the market Trade Cancellations A Trade message with the CANC flag will be sent if a trade is cancelled. The message will include the Trade Match ID of the cancelled trade. A trade cancellation is final and once cancelled, it cannot be reinstated. Details of trade corrections are not disseminated on the market data feed 16

17 4.0 Recovery 4.1 Recipient Failures Recipients have access to two identically sequenced multicast feeds: Feed A and Feed B. 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 that is not recoverable by arbitrating between the two feeds, 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 Participants to request the retransmission of a limited number of messages already published on the multicast channel. The channel supports the retransmission of the last 65,000 messages published. Each CompID may login to the Replay channel of a particular market data group up to a limited number of times each day. The total number of Replay Requests that a Participant may send for a particular market data group is also limited. Recipients may request that Turquoise 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 Participant submits multiple requests on the Replay channel, they will be processed serially (i.e. one at a time). Participants are unable to cancel outstanding Replay Requests Establishing a Connection The Participant should use the relevant IP address and port to establish a TCP/IP session with the Replay channel. The Participant should initiate a session by sending the Login Request message. The Participant should identify itself by specifying its CompID in the Username field. The server will validate the CompID, password and IP address. Once the Participant is authenticated, the server will respond with a Login Response message with the Status A. The Participant must wait for the server s Login Response before sending additional messages. Messages received from the Participant prior to a Login Request or prior to receiving the Login Response (before it being processed) will be ignored. If a logon attempt fails because of an invalid CompID, invalid password, invalid IP address or if a message is sent prior to the login being established, the server will break the TCP/IP connection with the Participant 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 Participant. If a Participant has exceeded the number of permitted 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. 17

18 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 Participant. If a customer attempts to log on to the Replay channel while already logged in, the server will break the TCP/IP connection with the Participant. A protection mechanism is in place in order to protect the gateway from rapid login/logouts. If a user reaches the thresholds for rapid login/logouts, any future logins/logouts will be delayed exponentially Heartbeats The server will not send heartbeats on the Replay channel during periods of inactivity Requesting Missed Messages Once connected to the Replay channel, Participants 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 65,000 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 Termination of the Connection If the Participant 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 Participant 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 Participants to request a snapshot of the Turquoise Lit TM 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 up to a limited number of times each day. The total number of Snapshot Request messages that a Participant may submit for a particular market data group is also limited. Recipients may request that Turquoise reset its login and 18

19 request counts. This feature is intended to help manage an emergency situation and should not be relied upon as a normal practice. If a Participant submits multiple requests on the Recovery channel, they will be processed serially (i.e. one at a time). Participants are unable to cancel outstanding Snapshot Requests Establishing a Connection The Participant should use the relevant IP address and port to establish a TCP/IP session with the Recovery channel. The Participant should initiate a session by sending the Login Request message. The Participant should identify itself by specifying its CompID in the Username field. The server will validate the CompID, password and IP address. Once the Participant 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 prior to a Login Request or prior to receiving the Login Response (before it being processed) will be ignored. If a logon attempt fails because of an invalid CompID, invalid password, invalid IP address or if a message is sent prior to the login being established, the server will break the TCP/IP connection with the Participant 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 Participant. If a Participant has exceeded the number of permitted 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 Snapshot Request is not received within 5 seconds of a successful logon, the server will break the TCP/IP connection with the Participant. If a customer attempts to log on to the Recovery channel while already logged, the server will break the TCP/IP connection with the Participant. At a particular point of time the Snapshot Channel can queue a limited number of unprocessed requests from a Participant. The server will reject any further Snapshot Request messages via a Snapshot Response message with status c. A protection mechanism is in place in order to protect the gateway from rapid login/logouts. If a user reaches the thresholds for rapid login/logouts, any future logins/logouts will be delayed exponentially Heartbeats The server will not send heartbeats on the Recovery channel during periods of inactivity. 19

20 Requesting Order Book Snapshots Once connected to the Recovery channel, Participants may use the Snapshot Request message to request a snapshot of the current Turquoise Lit TM Order Book for all instruments in a specified segment or for a particular instrument. If a Participant specifies both the Segment and Instrument ID in the Snapshot Request message, it will be taken as a request for the stated segment. A Participant may submit multiple Snapshot Requests 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. If the request is successful, the server will disseminate a snapshot of the current Order Book for each of the requested instruments via series of Add 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). Following the Add Order messages, a Symbol Status message will be sent indicating the trading status of that particular instrument. The Session Change Reason field within this message will contain the value 9. The server will transmit the Snapshot Complete message once the details of all active Orders are disseminated. The message will include the sequence number with which the Order Book snapshot was synchronised and the segment or instrument to which it relates. The Participant may begin processing the buffered messages from the multicast channel once the Order Book snapshot is processed. In a situation where the instrument has an empty Order Book, the system will respond with only a Snapshot Complete message 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. If the request is successful, the server will disseminate a snapshot of the current Turquoise Lit TM Order Book for all instruments in the requested segment via a series of Add 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). Following the Add Order messages, a Symbol Status message will be sent indicating the trading status of that particular instrument. The Session Change Reason field within this message will contain the value 9. 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 of all active Orders for a particular instrument are disseminated. This message will include the sequence number with which the Order Book snapshot for the instrument was synchronised. While such a Snapshot Complete will include the instrument to which it relates, it will not include a value in the Segment field. The Participant may begin processing the buffered messages for the instrument from the multicast channel once its Order Book snapshot is processed. 20

21 The server will also transmit a Snapshot Complete message once the details of 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 Symbol field Termination of the Connection If the Participant does not send a Logout Request and terminate the connection or submit another Snapshot Request within 5 seconds of the transmission of the Snapshot Complete message, the server will break the TCP/IP connection with the Participant. 4.2 Service Interruptions Snapshots on the Multicast Channel In the unlikely event of an outage at Turquoise, recipients may be required to refresh their Order Book for one or more instruments. In such a scenario the server will, on the multicast channel, broadcast an Order Book Clear message for the Order Book of each affected instrument. In such an event recipients must remove all Orders from the Order Book maintained for these instruments. The server will then transmit a series of Add Order messages on the multicast channel to disseminate the current picture of each Order Book 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. In such a case, messages sent on the multicast channel prior to the resetting of sequence numbers will not be available for retransmission on the Replay channel. 21

22 5.0 Message Formats This section provides details on the data types, unit header, nine administrative messages and thirteen application messages utilised by the server. For each message, a description of each field is provided along with the applicable data type, offset and length (in bytes). 5.1 Packet Composition The Unit Header is used to deliver all administrative and application messages to and from the server on all four channels. A Unit Header may contain zero, one or more payload messages. While a Unit Header may contain multiple application messages, it will never contain more than one administrative message. A Unit Header will not contain both administrative and application messages. 5.2 Sequence Numbers All application messages transmitted by the server on the multicast and Replay channels are sequenced. The Unit Header only contains the sequence number of the first message. Each subsequent message in the Unit Header will have an implied sequence number one greater than the previous message. The sequence number of the 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 Participant are unsequenced. The Unit Header used to transport all such messages, other than a Heartbeat, will include a Sequence Number of zero. 5.3 Timestamps Application messages on the Real-Time channel will include an indication of when they were transmitted. The server will, on the Real-Time 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 microsecond. The Time message is not transmitted during periods where no application messages are generated for the Real-Time channel. The retransmission of messages on the Replay channel will include the Time messages originally broadcast on the Real-Time 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 Real-Time channel. Participants are unable to estimate the time at which an active Order was submitted from the messages transmitted on the Recovery channel. 22

23 5.4 Data Types The fields of the various messages utilised by the server will support the data types outlined below. Data Type Length Description Alpha Variable These fields use standard ASCII character bytes. They are left justified and padded on the right with spaces. An empty alpha field is filled 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 Signed Little-Endian encoded eight byte integer field with eight implied decimal places. UInt8 1 8 bit unsigned integer. UInt16 2 Little-Endian encoded 16 bit unsigned integer. UInt32 4 Little-Endian encoded 32 bit unsigned integer. UInt64 8 Little-Endian encoded 64 bit unsigned integer. 5.5 Message Overview Administrative Messages Name Message Type Usage ASCII Hex Heartbeat - - Used by the server, on the multicast channel, to exercise the communication line during periods of inactivity. Login Request (soh) 0x01 Used by the Participant 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 Participant to logout of the Replay or Recovery channel. 23

24 Replay Request (etx) 0x03 Used by the Participant 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 Participant to request for a snapshot of the current Turquoise Lit TM 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 Turquoise Lit TM Order Book snapshot is complete Application Messages Application messages may only be sent by the server. Name Message Type Usage ASCII Hex Time T 0x54 Sent by the server for every second for which at least one application message is generated. This message is not transmitted during periods where no other application messages are generated. System Event S 0x53 Sent to indicate the start and end of the day. Symbol Directory R 0x52 Used to disseminate information (e.g. symbol, segment, ISIN, etc.) on each instrument. Symbol Status H 0x48 Indicates the trading session (e.g. continuous trading) that currently applies to an instrument. Also sent to advise of a Call Market, inviting participants to send Orders to participate in the Turquoise Plato Uncross TM within the Turquoise Plato TM Order Book. Add Order A 0x41 Sent to indicate that a limit Order is added to the Turquoise Lit Order Book. Order Deleted D 0x44 Sent to indicate that the remainder of a displayed Order is cancelled. 24

25 Order Modified U 0x55 Indicates that the displayed quantity or price of a displayed Order has been updated. The message will include an indication of whether the Order has retained or lost its time priority. Order Book Clear Order Executed y 0x79 Sent to instruct recipients to remove all Orders from the Order Book for the specified instrument. 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. Auction Info I 0x49 Provides indicative auction quantity and price for the Turquoise Lit Auctions TM order book. Trade P 0x50 Sent if the non-displayed portion of an iceberg Order or a hidden Order is fully or partially filled, or for a Turquoise Lit Auctions TM order book uncross. Also sent to denote trade cancellations. 5.6 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 Group 3 1 Byte Identity of the market data group the payload messages relate to. This field is not validated for Participant initiated messages. Sequence Number 4 4 UInt32 Sequence number of the first payload message. Payload 8 Variable - One or more payload messages. 25

26 5.7 Administrative Messages (Participant Initiated) Login Request Field Offset Length Type Description 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 Participant. Password 8 10 Alpha Password assigned to the CompID Replay Request Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 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 Snapshot Request Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x81 Snapshot Request ReservedField1 2 4 UInt32 Reserved for future use. 26

27 Segment 6 6 Alpha Segment the request relates to. The field should contain only spaces if the MTF Common Symbol field is populated. MTF Common Symbol 12 8 Alpha MTF Common Symbol for the instrument the request relates to. The field should contain only spaces if the Segment field is populated. If a segment is specified then any value in this field will be ignored. Target Book 20 1 Byte Value Meaning I Turquoise Lit Order Book Logout Request Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x05 Logout Request 5.8 Administrative Messages (Server Initiated) 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 multicast channel. However, the next expected sequence number will be included in the Sequence Number to enable recipients to detect gaps on the multicast channel Login Response Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x02 Login Response 27

28 Status 2 1 Byte Status of the login request. Value Meaning A a Login Accepted CompID Inactive/Locked b Login Limit Reached c d Service Unavailable Concurrent Limit Reached e Failed (other) Replay Response Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 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. 28

29 Status 9 1 Byte Status of the replay request. Value Meaning A D Request Accepted Request Limit Reached I Invalid Market Data Group O U Out of Range Replay Unavailable c Concurrent Limit Reached d e Unsupported message type Failed (other) Snapshot Response Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x82 Snapshot Response ReservedField1 2 4 UInt32 Reserved for future use. ReservedField2 6 4 UInt32 Reserved for future use. 29

30 Status 10 1 Byte Status of the snapshot request. Value Meaning A O Request Accepted Out of Range U Snapshot Unavailable a Segment or Symbol Not Specified 1 b c Request Limit Reached Concurrent Limit Reached d Unsupported message type e Failed (other) 1 The same status value is received for invalid segments, when the segment has no instruments, or the instruments in the segment are not assated with the Recovery service. 30

31 5.8.5 Snapshot Complete Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 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. MTF Common Symbol 12 8 Alpha MTF Common Symbol for the instrument the request relates to. The field should contain only spaces if it does not relate to an instrument. Target Book 20 1 Byte Value Meaning I Turquoise Lit Order Book 31

32 5.9 Application Messages Time Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 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) System Event Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x53 System Event Nanosecond 2 4 UInt32 Nanoseconds since last Time message. Accurate to the microsecond. Event Code 6 1 Byte Value Meaning C End of Day O Start of Day 32

33 5.9.3 Symbol Directory Field Offset Length Type Description Length 0 1 UInt8 Length of message including this field. Message Type 1 1 Byte Hex Meaning 0x52 Symbol Directory Nanosecond 2 4 UInt32 Nanoseconds since last Time message. Accurate to the microsecond. MTF Common Symbol 6 8 Alpha MTF Common Symbol for the instrument. Status 14 1 Alpha Value Meaning H S Halted Suspended a Inactive This field will contain a space if the instrument is active. ISIN Alpha Instrument identification number. ReservedField String Reserved for future use. Segment 39 6 Alpha Segment the instrument is assigned to. ReservedField Alpha Reserved for future use. Currency 51 3 Alpha ISO Currency Code Target Book 54 1 Byte Value Meaning I M Turquoise Lit Order Book Turquoise Plato TM Order Book A Turquoise Lit Auctions TM Order Book Security Exchange 55 4 Alpha Market Identifier Code 33