-
What trading groups are disseminated via the Euronext Cash Full Order Book?
Euronext Cash Full Order Book disseminates full market depth for all Euronext Equities trading groups.
-
How do I determine the Best Bid and Offer at the opening of the market?
If processing the 140 Quotes messages, Euronext advises customers to always use the value in level 1 of the Quotes message (Msg Type=140, QuoteNumber=1) as the best bid and offer.
If only processing the 230 Order messages from the Full Order Book product, Euronext advises customers to maintain a complete image of the full order book, and treat the top level as the best bid and offer.
-
What is the fastest way of maintaining an order book for the Euronext Cash Markets?
The fastest way of maintaining an order book for Euronext Cash is by using the 230 Order Book messages – the full Order Book product. These are disseminated in Service ID 104 of the Universal Trading Platform Market Data Feed. This product is lower latency than the BBO10 product (140 messages) because the price levels disseminated as the content of the BBO10 messages are derived from the details of the Order Book messages. Therefore the 230 messages are always sent before the 140 messages, and receiving the Full Order Book information is always faster than the BBO10 information.
-
What recovery mechanisms are in place for the Full Order Book product?
Two interactive multicast packet recovery methods are provided by the Universal Trading Platform Market Data Feed for the Full Order Book product:
1. Retransmission Server – This is used to fill small packet gaps in multicast traffic, which are inevitable with a multicast data feed and can occur due to many factors in between the market data leaving the exchange and arriving at the users application.
2. Refresh Server – This is used for any significant outage at the client’s site, which would lead to a significant loss of packets, or a client intra day start up. A request is sent to the exchange system, which responds with a snapshot of the up to date order book.
In the event of an outage at the exchange side, Euronext Cash Market Operations may retransmit the order books. Clients should ensure their applications process the 230 message Action Type ‘F’, which clears order books before they would be retransmitted from the exchange.
-
Is this product the same as NYSE Arca Europe for order book processing?
NYSE Arca Europe uses the same delivery method from the Universal Trading Platform Market Data Feed, meaning that clients can use common code to process both the Euronext Equities and NYSE Arca Europe Full Order Books.
-
What time is the reference data sent in the morning?
The reference data is sent at ~6.11am CET. The production feed timetable can be found in section 4.6 of the Universal Trading Platform Market Data Feed Specifications.
-
What is the difference between start of day and end of day reference data?
The morning reference data contains all of the instruments for the current trading day. The evening reference data contains all of the instruments for the next trading day.
The following fields are not provided in the evening referencial:
- LastAdjPrice and LastAdjPriceScaleCode (last adjusted closing price)
- PrevVolumeTraded (volume traded on the previous day)
- DateOfLastTrade (date of the last trade)
- PrevDayCapitalTraded and PrevDayCapitalTradedScaleCode (capital traded on the previous day)
- The field PeriodIndicator takes a different value (M for Morning or E for Evening)
-
Retransmissions – How many source IDs are allocated for retransmissions?
As standard 4 source IDs are allocated per customer for retransmissions per environment (4 for Production and 4 for EUA). The UTP Helpdesk manage the allocation of source IDs and they can be contacted at utp@nyx.com or +33 1 49 27 50 90.
-
When using retransmissions, what should my application do if a retransmission request is rejected?
If a retransmission request is rejected, the Retransmission Response message will be sent to the customer with the field Status = ‘R’. The field ‘RejectReason’ will contain a reference as to why the request has been rejected. Customers should firstly log the reject reason in order to be able to trouble shoot why their application is not successfully using the retransmission server. Depending on the reject reason, customers should either mark the packet as permanently lost and if required send a refresh request, or if getting a rejection about maximum thresholds use a new source ID (this should also trigger a network investigation as encountering 1000 individual gaps suggests a serious problem).
-
What are the limitations of the retransmission server for customers?
Customers are allocated 4 source ID’s. For each source ID in a given trading day, 1000 retransmission requests are permitted. Each request has a limit of 1000 packets. Once this threshold is reached, requests for retransmissions will be rejected with ‘RejectReason’ = 4, “max requests reached in a day”.
-
How does the exchange count the number of requests sent? Is this counted per retransmission server or for both?
The number of requests are counted per retransmission server. Therefore in a given trading day, a source ID will have 1000 requests for the primary retransmission server, and 1000 requests for the secondary retransmission server. All requests are counted whether they are successful or rejected.
-
Can I send requests to both the primary and secondary retransmission server?
Yes, you can send requests to both the primary and secondary retransmission server. The two servers run in a hot hot mode, and both contain the exact same cache of packets. However, customers should refer to section 4.7.3 of the Universal Trading Platform Market Data Feed specs which details the ‘High Availability Retransmission Behavior’. This details essential logic required for customers applications regarding failover scenarios between the primary and secondary retransmission servers.
-
For the refresh server, do I need new source IDs?
The retransmission servers and refresh servers all use the same Source ID’s. Therefore for the refresh server, the same source ID’s received initially for retransmissions should be used. This applies to both primary and secondary servers.
-
Can I send requests to both the primary and secondary refresh server like I can for retransmissions?
It is not possible to send requests to both the primary and secondary refresh servers. The secondary server is alive during the day. However is in a standby mode and will not service requests. If you send a request to the secondary refresh server when it is in secondary mode, you will receive a refresh response message with a ‘RejectReason’ =7, “Refresh request sent to incorrect server (secondary instead of primary)”.
-
Can I recover all data for a given trading day?
It is not possible to recover every single packet from a given trading day from the real time feed. It is possible to have up to date information from the refresh server which facilitates intra day start ups or customer side outages. If customers wish to have every tick from a given trading day recovered they can purchase the NYSE Euronext Tick Data product where the data can be downloaded from an FTP site.
-
How many retransmission requests per day do Euronext consider to be normal?
If customer applications are completing line arbitrage by consuming dual multicast lines, network packet loss should be minimal and very rare. If more than 5 retransmission requests per day are being sent, investigations should be initiated on the customers site to determine why. Common causes of packet loss at the customer side are:
- UDP buffer sizes set too low on the UDP socket. Customers can use the netstat –s command in linux to check if packet loss is caused by UDP buffer overflows. If the receive number buffer error number increases in the UDP section of the netstat –s output, it means packets are being lost due to an overflow.
- Consuming dual multicast lines on the same network interface.
- Inefficient CPU balancing (for example the same CPU is handling the network interface, hard drive and application).
- Inefficient application implementation causing high CPU.
- UDP multicast traffic being sent through a firewall
-
My application started late, when I send a retransmission request for the 1st packets of the day (reference data), I am getting rejected every time - why?
The 1st packet of the day with packet sequence number = 1 is the 'Reset Packet Sequence Number' packet. This is a technical message therefore is not cached by the retransmission server. Your request for the first packets of the day should start from packet sequence number 2.