WEP - NYSE Liffe US - Client Spec v1.7

NYSE Liffe U.S.
Datafeed Specifications
Universal Trading Platform
STATUS
Version 1.7
20 February 2009
Disclaimer
© NYSE Euronext 2009
This document contains information which is confidential and of value to NYSE Euronext. It may be used by NYSE Euronext
clients only for the agreed purpose for which it has been provided.
All proprietary rights and interest in this publication shall be vested in NYSE Euronext and all other rights including, but without
limitation, patent, registered design, copyright, trademark, service mark, connected with this publication shall also be vested in
NYSE Euronext.
No part of this publication may be redistributed or reproduced in any form or by any means or used to make any derivative
work (such as translation, transformation, or adaptation) without written permission from NYSE Euronext. NYSE Euronext
reserves the right to alter any of its rules, procedures or contract specifications, and such an event may affect the validity of the
information in this document.
Whilst all reasonable care has been taken to ensure that the information contained in this publication is accurate and not
misleading at the time of publication, NYSE Euronext shall not be liable (except to the extent required by law) for the use of the
information contained herein however arising. Neither NYSE Euronext, nor its servants nor agents, is responsible for any
errors or omissions contained in this publication, which is published for information only and shall not constitute investment
advice.
The following information is subject to change on a regular basis. The user is responsible for ensuring that it shall keep itself
up to date with the latest versions published by NYSE Euronext, at all times, including any annexes, policies and guidelines.
Table Of Contents
Table Of Contents 2
Chapter 1 – Introduction 4
Copyright Trademark Statements 4
Notice 4
Document History 4
Overview 5
Terms and Definitions 6
Chapter 2 – NYSE Liffe U.S. Group Assignments 7

Overview 7
2.1 NYSE Liffe U.S. Services 7
2.2 Primary Production IP Addresses 8
2.3 Secondary Production IP Addresses 8
2.4 Primary Backup Production IP Addresses 8
2.5 Secondary Backup Production IP Addresses 9
2.6 Primary Production Retransmission IP Addresses 9
2.7 Secondary Production Retransmission IP Addresses 9
2.8 Primary Backup Production Retransmission IP Addresses 9
2.9 Secondary Production Retransmission IP Addresses 10
2.10 Primary Test IP Addresses 11
2.11 Secondary Test IP Addresses 11
2.12 Primary Test Retransmission IP Addresses 11
2.13 Secondary Test Retransmission IP Addresses 11
2.14 Retransmission Request Thresholds 12
Chapter 3 – NYSE Liffe U.S. Processing Information 13

Overview 13
3.1 Access to Data 13
3.2 Real-Time Market Data 14
3.3 Packet Structure 14
3.4 Sequence Numbers 15
3.5 Compression 15
3.6 Standing Data 15
3.7 Gap Detection 15
3.8 Recovering Missed Data 15
3.9 Line Arbitration 16
3.10 Retransmission Server 16
3.11 Retransmission Server Heartbeat 17
3.12 System Behaviour on Start and Restart 18
3.13 Cancellations and Corrections 18
Chapter 4 – NYSE Liffe U.S. Operational Information 19

Overview 19
4.1 Feed Operation Hours 19
4.2 Trading Calendar 19
4.3 Exchange System Failure 19
4.4 Client System Failure 19
Chapter 5 – NYSE Liffe U.S. Feed Message Specifications 20

Overview 20
NYSE Liffe U.S. Feed Specifications Version 1.7 Page 2 of 51

5.1 General Processing Notes 20
5.2 Data Classification 21
5.3 Time Conventions 21
5.4 Sequence Numbers 21
5.5 Price Formats 22
5.6 Prices in ticks 22
5.7 Data Types 22
5.8 Security Identifiers 22
5.9 Product Codes 23
5.10 Packet Header Format 24
5.11 Market Update 25
5.12 Settlement Prices 27
5.13 Outright Standing Data 28
5.14 Strategy Standing Data 29
5.15 Product Availability 31
5.16 Market Status 32
5.17 Exchange Message 34
5.18 Value-Added Parameters 35
5.19 Open Interest 37
5.20 Option Valuation 38
Chapter 6– NYSE Liffe U.S. Feed Technical Message Specifications 39

Overview 39
6.1 Packet Header Format 39
6.2 Packet Sequence Number Reset 40
6.3 Heartbeat 40
6.4 Heartbeat Response 40
6.5 Retransmission Request 41
6.6 Retransmission Response 42
6.7 Retransmission Message 42
Appendix A – Message Processing 43

Overview 43
A.1 Processing of messages 43
A.2 Processing of Heartbeat Messages 44
A.3 Processing of Data messages 45
A.4 Processing of Sequence Number Reset messages 46
A.5 Processing of Gap Handling 47
A.6 Retransmission Requests 48
Appendix B – Price Format Codes 49

Overview 49

Chapter 1 – Introduction
Copyright NYSE Euronext refers to NYSE Euronext and its affiliates and references to NYSE Euronext
®
Trademark in this publication include each and any such company as the context dictates. NYSE , NYSE
® ®, ® ® ®
Statements Euronext , Euronext NYSE Arca , NYSE Liffe and NYSE Liffe U.S. are registered marks
of NYSE Euronext.
© 2009, NYSE Euronext - All rights reserved.
Notice Every effort was made to ensure that the information in this document was complete and
accurate at the time of publication.
However, information is subject to change without notice.
Document V1.0, 25 September 2008, Initial Version

History V1.3, 5 December 2008, Updated document format
V1.4, 15 January 2009, Removed UpdateType and MarketMode values not applicable to
NYSE Liffe U.S.; removed protection fields from Product Availability message; removed
Underlying Symbol and UTP Market Identifier; added section 5.6 to clarify prices in ticks;
changed message numbers.
V1.5, 6 February 2009, added SnapshotFlag to MarketUpdate message; added ServiceID
values; provided IP addresses and port details; removed ReasonCode from Outright Standing
Data and Strategy Standing Data messages; removed MarketDataAvailableFlag from Product
Availability message; updated description for StrategyCode field; added note about availability
of Open Interest message; added available ProductCode values; clarified division of services
in section 5.2; additional RejectReason values in Retransmission Response message;
removed FAQ.
V1.6, 12 February 2009, change to Section 5.6 Price Formats explanation; added Appendix B
Price Format Codes; removed provisional settlement prices.
V1.7, 20 February 2009, update IP addresses for retransmission service; added note to 3.11
to make clear that heartbeat is only sent in periods of inactivity; update to table at end of
section 5.11 for Against Actual trades; add note to 5.13 and 5.14 descriptions to make clear
that standing data may be resent after a system failure/recovery; section 5.15 explain how
users should clear orderbooks on receipt of Product Available message; removed Clear
Subscription from Market Status message section 5.16; clarified which VAP parameters are
updated by book/OTC trades in section 5.18; added section 3.12 to clarify system behaviour
at start of day and following system recovery; clarified section 3.6; provided book/OTC trade
classification in section 5.18; added section 3.13 to clarify cancellation and corrections; added
section 4.2 to link to exchange trading calendar; provided standing data send time in section
4.1.

Overview This document details the Specifications of the Universal Trading Platform Market Data Feed
for NYSE Liffe U.S. (“NYSE Liffe U.S. Feed”).
The NYSE Liffe U.S. Feed provides high speed real-time market data for the NYSE Liffe U.S.
market.
It provides standing data, pricing and market status information for futures, options and
strategy instruments.
The NYSE Liffe U.S. Market Data Feed has the following high-level features:
• Multicast technology
• Optional FAST-based compression
• High system availability
• Ultra-low latency
• Reliable network solution
• High level of scalability
This document provides detailed information about the features of the feed, to support the
development of client applications by Members, Independent Software Vendors and Quote
Vendors.

Terms and Service Set of multicast channels providing data for a predefined
Definitions data set.
Multicast Group/Channel A single multicast stream, corresponding to a single

multicast address.
Exchange Trading Exchange such as Liffe, or a group of related

products for trading, for example London financials, NYSE
Arca Equities, NYSE Arca Bonds.
Product Term used to define each separate product such as Euribor

futures (I), 30 year bonds (ZB) or $10 Dow Futures (ZD).
Expiry For a given product, all series expiring on a particular date,

for example Euribor Future September 2008, FTSE 100
options December 2009.
Series All option contracts of the same class that also have the
same unit of trade, expiration date, and exercise price.
AMR Automated Market Reference, unique identifier used on

LIFFE CONNECT®.
AQS Options model used for price limits and settlement prices.
RFQ Request for Quote.
SFTI Secure Financial Transaction Infrastructure
Big Endian Refers to which bytes are most significant in multi-byte data
types. In big-endian architectures, the leftmost bytes are
most significant. This byte order also corresponds to
Network Byte Order.
Monotonical Incrementally increase in value by one.
UDP User Datagram Protocol.
TCP Transmission Control Protocol.
FAST FIX Adapted for STreaming, protocol offering significant

compression capabillities for the transport of high-volume
market data feeds and ultra low latency applications.

Chapter 2 – NYSE Liffe U.S. Group Assignments
Overview The following chapter provides all of the necessary connectivity information in order to
subscribe to the NYSE Liffe U.S. Market Data Feed.
2.1 NYSE Liffe The NYSE Liffe U.S. data feed will be split into services. Each service will deliver a set of
U.S. Services update messages for a certain range of symbols. A unique ServiceID is associated with
each service.
The table below describes the categorization of the data feed.
Service Service Description

ID
NYSE Liffe U.S. Precious 1 Multicast addresses assigned to deliver market data for NYSE
Metals Level 1 Liffe U.S. Precious Metals. Level 1 data only.
NYSE Liffe U.S. Precious 2 Multicast addresses assigned to deliver market data for NYSE
Metals Level 1 + Level 2 Liffe U.S. Precious Metals. Level 1 and level 2 data.
NYSE Liffe U.S. Standing Data 3 Multicast addresses assigned to deliver standing data for the
NYSE Liffe U.S. market
Refer to section 5.2 for a breakdown of how message types fall into each of the services.

2.2 Primary The table below defines the Primary Production IP/Multicast group and port assignments for
Production IP all messages in the NYSE Liffe U.S. feed.
Addresses Alternative source IP addresses are shown in brackets.
NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

Network Netmask Address Port
NYSE Liffe U.S. Precious Metals Level 1 156.48.100.4 156.48.100.0 255.255.255.240 224.0.60.241 31020
(156.48.100.5)
+ Level 2 (156.48.100.5)
NYSE Liffe U.S. Standing Data 156.48.100.4 156.48.100.0 255.255.255.240 224.0.60.242 31024
(156.48.100.5)
2.3 Secondary The table below defines the Secondary Production IP/Multicast group and port assignments
Production IP for all messages in the NYSE Liffe U.S. feed.

(156.48.100.197)
+ Level 2 (156.48.100.197)
(156.48.100.197)
2.4 Primary The table below defines the Primary Backup Production IP/Multicast group and port
Backup assignments for all messages in the NYSE Liffe U.S. feed.
Production IP Alternative source IP addresses are shown in brackets.
Addresses

(156.48.101.5)
+ Level 2 (156.48.101.5)
(156.48.101.5)

2.5 Secondary The table below defines the Secondary Backup Production IP/Multicast group and port
Backup assignments for all messages in the NYSE Liffe U.S. feed.
Production IP Alternative source IP addresses are shown in brackets.
Addresses

(156.48.101.197)
+ Level 2 (156.48.101.197)
(156.48.101.197)
2.6 Primary The table below defines the Primary Production Retransmission TCP/IP group and port
Production assignments for all messages in the NYSE Liffe U.S. feed.
Retransmission
IP Addresses
NYSE Liffe U.S. Service Source IP Source Network Source Netmask TCP Port
NYSE Liffe U.S. Precious Metals Level 1 156.48.102.4 156.48.102.0 255.255.255.240 31010
+ Level 2
NYSE Liffe U.S. Standing Data 156.48.102.4 156.48.102.0 255.255.255.240 31010
2.7 Secondary The table below defines the Secondary Production Retransmission TCP/IP group and port
Production assignments for all messages in the NYSE Liffe U.S. feed.
Retransmission
IP Addresses
+ Level 2
2.8 Primary The table below defines the Primary Backup Production Retransmission TCP/IP group and
Backup port assignments for all messages in the NYSE Liffe U.S. feed.
Production Backup retransmission addresses will be used in disaster recovery situations only. Clients
Retransmission will be informed by the exchange of a switch to Backup IP addresses.
IP Addresses
+ Level 2

2.9 Secondary The table below defines the Secondary Backup Production Retransmission TCP/IP group
Production and port assignments for all messages in the NYSE Liffe U.S. feed.
Retransmission Backup retransmission addresses will be used in disaster recovery situations only. Clients
IP Addresses will be informed by the exchange of a switch to Backup IP addresses.
+ Level 2

2.10 Primary The table below defines the Primary Test IP/Multicast group and port assignments for all
Test IP messages in the NYSE Liffe U.S. feed.

(156.48.100.37)
+ Level 2 (156.48.100.37)
(156.48.100.37)
2.11 Secondary The table below defines the Secondary Test IP/Multicast group and port assignments for all
Test IP messages in the NYSE Liffe U.S. feed.

(156.48.100.213)
+ Level 2 (156.48.100.213)
(156.48.100.213)
2.12 Primary The table below defines the Primary Test Retransmission TCP/IP group and port
Test assignments for all messages in the NYSE Liffe U.S. feed.
Retransmission
IP Addresses
+ Level 2
2.13 Secondary The table below defines the Secondary Test Retransmission TCP/IP group and port
Test assignments for all messages in the NYSE Liffe U.S. feed.
Retransmission
IP Addresses
+ Level 2

2.14 The table below defines the Retransmission Request thresholds for the NYSE Liffe U.S.
Retransmission Feed.
Request The numbers below represent the thresholds per service.
Thresholds
Capability Description Threshold Action

Prevention of invalid subscribers Incoming requests from subscribers that are N/A Request will not be
not in the enabled subscriber’s source ID list processed.
will not be honored.
Subscribers will need a source ID, which is a
string that uniquely identifies the subscriber
of the retransmission requests.
Please contact NYSE Euronext to get a
unique source ID.
Limitation of request for a large Only retransmission requests for x number 1000 Request will not be
number of packets of packets or less will be honoured. processed.
Limitation of generic requests If the number of a subscriber’s generic 1000 Subsequent
requests reaches the threshold number of retransmission
requests per day, the subscriber will be requests from that
blocked and retransmission requests from subscriber will be
that subscriber will no longer be honoured blocked.
during that particular day.

Chapter 3 – NYSE Liffe U.S. Processing Information
Overview The following chapter will provide you with information about how to interact with the
Universal Trading Platform Market Data Feed for NYSE Liffe U.S..
3.1 Access to Customers connect to multicast addresses for the real-time market data messages, and can
Data also connect to a TCP/IP server for packet retransmission requests and responses.
Exchange
Real-Time Server Retransmission

Server
Dual
Multicast TCP/IP
Channels
Client

3.2 Real-Time Real-time market data is message-based over the UDP/IP protocol with fixed length
Market Data binary and ASCII fields.
It uses the push-based publishing model. This means that data will be published based
on its availability. Once an update is available, it will be published to the appropriate
multicast group.
For capacity reasons, market data will be split across a number of multicast groups
organised into predefined data sets, called services.
Each service will deliver a set of data for a certain market segment. Dual multicast
channels are made available for line arbitrage and redundancy purposes.
The client application will be responsible for issuing Multicast subscriptions to one or
more of the Multicast Groups assigned to each product.
The process of subscribing to a Multicast Group is also known as ‘joining’ a Multicast

Group. Upon session termination, the subscriber’s host system should issue an ‘unjoin’
message. This will terminate delivery of data to that host’s local network.
If a client application terminates without issuing an ‘unjoin’ message, the network will
eventually issue a ‘timeout’ for the Multicast Group subscription that will automatically
terminate delivery of the Multicast packets to the host’s local network.
The ‘join’ and ‘unjoin’ processes are standard functions. No specific instructions are
provided here, as they are specific to the user’s operating system and programming
language.
3.3 Packet All packets of data sent on the Universal Trading Platform Market Data Feed will have a
Structure common packet header followed by one or more messages (with the exception of some
technical message packets that do not contain any messages).
The packet header format is the same for all packets, and contains characteristics of
the packet: packet length, packet type, packet sequence number, packet send time,
service identifier, delivery flag and the number of messages within the packet.
The format of each message in the packet depends on message type, but each
message will start with message size and message type.
The maximum length of a packet is 1400 bytes.
A packet will only ever contain complete messages. A single message will never
straddle multiple packets.
The message size will never exceed the maximum packet length (less the packet
header size).
Packet Header Message 1 Message 2 … Message n

3.4 Sequence All messages conform to the line level sequencing. Each service has its own sequence
Numbers number range. Subscribers can use sequence numbers to determine the following:
• Missing (gapped) packets
• Unordered packets
• Duplicate packets
Clients should note that the sequence number per channel might restart from one following a
failure recovery. A reset sequence number message will be sent to clients via the Multicast
Groups to inform of such event.
3.5 FAST compression is not used for the NYSE Liffe U.S. Feed. All data will be uncompressed.
Compression
3.6 Standing Standing data messages are disseminated via the multicast channels. Standing data
Data messages for all futures, options and strategies are sent at the start of the trading day, and
subsequently for any intraday changes (new option strikes, creation of strategy instruments).
Standing data may also be sent following recovery from a system failure.
Note that the standing data messages provide basic characteristics of each future, option
and strategy.
Additional referential data (for example last trading date, trading currency, underlying
instrument characteristics) can be obtained from a separate FTP service.
3.7 Gap UDP can at times be unreliable and may drop packets from either or both the primary and
Detection secondary data feeds.
Each packet has a Packet Sequence Number (PSN). PSNs start at one (1) and increase
monotonically (one by one and without gaps) with each subsequent message. Users should
use the PSN to detect gaps in the transmission of messages.
3.8 Recovering The NYSE Liffe U.S. Feed provides 2 different mechanisms for recovering missed data:
Missed Data • Line arbitration – using dual multicast channels
• Retransmission server – recovery of limited number of packets
These mechanisms should be used as follows:
Event Action
Dropped packet(s) on primary/secondary Recover from other channel using line
multicast channel arbitrage
Dropped packet(s) on both primary and Recover dropped packet(s) from

secondary multicast channels retransmission server

3.9 Line Client applications should check the Packet Sequence Number (PSN) for every packet
Arbitration received.
PSNs are unique and increase monotonically for each service.
The primary and secondary channels are identical in terms of:

• Packet contents
• PSNs
• Sequence in which packets are sent
In the event a packet is lost on the primary channel for a multicast group, clients can retrieve
the lost packet from the secondary channel.
As a first resort, clients should use the secondary channel to fill gaps on the primary
channel, as shown in the following diagram:
Primary Secondary
PSN PSN
101 101
102 102
103 103 Dropped packet can
Gap detected 104 104 be recovered from
on primary 105 secondary channel
channel 106 106 without needing to
107 107 perform a
retransmission
request
3.10 If a packet is lost from both the primary and secondary channels, clients then make a
Retransmission TCP/IP request to have the packets resent. Packets are resent from the Retransmission
Server Server.
The client makes a TCP/IP connection to the Retransmission Server for both requesting and
receiving retransmitted packets.
Retransmission requests should contain a Start PSN, an End PSN and a Source ID. The
Source ID identifies the client application, and will be supplied by the exchange. The request
will be rejected if an invalid Source ID is supplied. Each Source ID may only be logged in
once per port at any given time.
The retransmission functionality is designed to allow the user to recapture a small number of
missed packets. It is not intended that clients use the retransmission functionality to recover
data after long outages or on late start up. Accordingly, the number of packets that the user
can request is strictly limited. Equally, the number of retransmission requests permitted per
user is limited per day.
The following diagram illustrates the process of requesting dropped packets from the
retransmission server:

Retransmission request
Client Exchange
TCP/IP
Retransmission response
Requested messages
Client Exchange
TCP/IP
The request may be rejected for any of the following reasons:

• Invalid username;
• Invalid sequence number;
• Number of packets requested exceeds the predefined system limit;
• Number of retransmission requests in the current day exceeds the predefined
system limit.
In the case of such a failure, the user will receive a retransmission response to advise of the
reason for failure.
3.11 Users can choose to either disconnect following each retransmission request, or remain
Retransmission connected to the Retransmission Server.
Server
Heartbeat After a client establishes a TCP/IP connection, the Retransmission Server will periodically
send heartbeat request messages to the client in periods of inactivity. The heartbeat
frequency is 30 seconds.
The user must respond to the Heartbeat message with a Heartbeat Response message
should they wish to remain connected. Such a response has to be received by the server
within 5 seconds of a heartbeat message.
Heartbeat
Client Exchange
Heartbeat response
TCP/IP

3.12 System At the start of the day, the feed will send the following messages:
Behaviour on
Start and • Standing Data Messages (721/731) for each future, option and strategy instrument
Restart on the market;
• Product Availability Message (741) with TradingAvailableFlag = 1 for each
available product;
• A snapshot of market data for each available product, comprising:
o Market Update Messages (701) providing best bid/ask, order book and
last trade price for each instrument;
o Market Status (751) providing the market status for each product;
o Settlement Prices (711) providing Yesterday Settlement Prices for each
instrument.
Note that this sequence will also be followed on system recovery following a failure.
Therefore in exceptional circumstances a user may see this during the trading day.
It is important that each client clears all instrument order books for a particular
product on receipt of a Product Availability Message with TradingAvailableFlag = 1
for that product.
3.13 The NYSE Liffe U.S. feed does not support explicit trade cancellations and/or corrections.
Cancellations
and In the event of a trade cancellation/correction the value-added parameters will be updated to
Corrections provide new high/low, volume, trade count and percentage change as appropriate.

Chapter 4 – NYSE Liffe U.S. Operational Information
Overview The following chapter provides some additional operational information about the Universal
Trading Platform Market Data Feed for NYSE Liffe U.S..
4.1 Feed Operational hours for the NYSE Liffe U.S. Feed are as follows:
Operation
Hours
Event Time (EST) * =Next Day

Standing Data Sent 6:10pm
Session Start 6:25pm
Pre-Open 6:30pm
Open (Gold, Silver, Mini Gold, Mini Silver Futures) 7:16pm
Open (Gold, Silver Options) 7:18pm
Pre-Close 4:58pm*
Close 5:00pm*
Session Close 5:30pm*
4.2 Trading The following link provides the holiday schedule for NYSE Liffe US:
Calendar
http://www.nyse.com/pdfs/NYSE%20Liffe%20Notice%20142008.pdf
A single trading session will always run from 6:25pm to 5:30pm.
4.3 Exchange The exchange system is designed to be extremely resilient. However there are measures in
System place to safeguard against unexpected system failures.
Failure
Under normal operating conditions, the exchange system will send real-time messages on two
sets of unique broadcast groups. Thus, when appropriate, each market data service will
transmit a given packet over two multicast groups. This will allow customers to receive two
redundant feeds. The client application should be designed to handle the loss of one of the
two multicast channels without any interruption to service.
4.4 Client Real-time market data will be made available on two different multicast groups. This offers
System clients the possibility to set up more than one receiving system processing the same data. In
Failure the event of a client system failure, the backup client system should continue to process the
real-time data sent on the second broadcast group.

Chapter 5 – NYSE Liffe U.S. Feed Message Specifications
Overview The NYSE Liffe U.S. Feed service uses the push-based publishing model. This means that
data will be published on its availability.
The feed supplies both standing data and real-time messages.
A generic packet type is used for all NYSE Liffe U.S. Feed data messages:
• Generic Derivatives Message (799)
The following derivatives data messages are made available:

• Market Update v1 (701)
• Settlement Prices v1 (711)
• Outright Standing Data v1 (721)
• Strategy Standing Data v1 (731)
• Product Availability v1 (741)
• Market Status v1 (751)
• Exchange Message v1 (761)
• Value-Added Parameters v1 (771)
• Open Interest v1 (781)
• Option Valuation v1 (791)
5.1 General The following processing notes apply to the messages sent through the feed:
Processing • All fields will be sent for every packet.
Notes
• Only field values will appear in the published messages (e.g., no names or ‘tags’ will
appear in the message)
• The field names that appear in the message format documents are for reference
purposes only
• All the fields are contiguous, with reserved fields for alignment issues
• All field sizes are fixed and constant
• Binary fields are provided in Big Endian format
• ASCII string fields are left aligned and null padded.
• Segmentation of messages across packets will not be supported. This means a
message will never straddle a packet boundary.

5.2 Data The table below shows how messages are distributed over the difference NYSE Liffe U.S.
Classification Datafeed services.
Message Type Service ID 1 Service ID 2 Service ID 3
NYSE Liffe NYSE Liffe NYSE Liffe

U.S. Precious U.S. Precious U.S. Standing
Metals Level 1 Metals Level 1 Data
+ Level 2
Market Update v1 (701) – except update types 3 & 4
Market Update v1 (701) – update types 3 & 4
Settlement Prices v1 (711)
Outright Standing Data v1 (721)

Strategy Standing Data v1 (731)

Product Availability v1 (741)
Market Status v1 (751)
Exchange Message v1 (761)
Value-Added Parameters v1 (771)
Open Interest v1 (781)
Option Valuation v1 (791)
5.3 Time The base for timestamps is the number of milliseconds since the previous Sunday 00:00:00
Conventions UTC (Co-ordinated Universal Time).
For example a timestamp of 315000000 refers to Wednesday 15:30:00 UTC.
5.4 Sequence The feed contains two sequence numbers:

Numbers • The packet sequence number is part of the packet header, and should be used for
retransmission requests. It is unique per service, and common across a pair of dual
multicast channels.
• The series sequence number is part of the message body for the Market Update
message only and is unique to each series.

5.5 Price All price fields are sent in integer format.
Formats
Unless otherwise specified, prices are sent in absolute ticks. Section 5.6 shows how to
convert a price, which is denoted in absolute ticks, to a displayable price, using the price
format code.
In other cases, where explicitly specified in the message specifications, some fields appear in
an integer/ scale code format. In this case the value is represented by two fields, and should
be calculated using the following formula:
Integer
Value =
10 ScaleCode
For example, a price of 98.75 is represented by an Integer of 9875 and a ScaleCode of 2.
5.6 Prices in All prices in the feed are provided in an integer number of ticks. In order to convert from ticks
ticks to actual values, it will be necessary to apply a price format code.
The price format code is not provided in the Datafeed or in the Referential Data File on
the FTP server at present. The format codes that will be used for launch are provided
below. The format codes for subsequently launched products will be provided to quote
vendors in advance of the product launch.
Clients are required to manually configure the Price Format Code in their applications using
the values supplied by NYSE Liffe U.S..
The following Price Format Codes will be used for launch of the NYSE Liffe U.S. Datafeed:
Gold Futures (ZG) – ‘O’ (Tenths)

Gold Options (OZG) – ‘O’ (Tenths)
Mini-Gold Futures (YG) – ‘O’ (Tenths)
Silver Futures (ZI) – ‘P’ (Ten Hundredths)
Silver Options (OZI) – ‘P’ (Ten Hundredths)
Mini-Silver Options (YI) – ‘P’ (Ten Hundredths)
Appendix B provides a full list of Price Format Codes that will be used for NYSE Liffe U.S.
products, and how they should be used to convert prices from ticks to an actual value.
5.7 Data Binary data is in network byte order (Big Endian format).
Types
‘Binary Integer’ fields are unsigned.
‘Binary Signed Integer’ fields are signed, and can take negative values.
All alphanumeric fields are left justified and null padded.
5.8 Security The feed allows for different Security IDs to be used on different services. Users should use
Identifiers the SecurityIDSource field to determine the Security ID to be used.

5.9 Product The following product codes are used for NYSE Liffe U.S.:
Codes
Product ProductCode
Gold Futures
ZG
Gold Options
OZG
Mini-Gold Futures
YG
Silver Futures
ZI
Silver Options
OZI
Mini-Silver Options
YI

5.10 Packet Each packet comprises a packet header followed by one or more messages.
Header
The table below describes the packet header fields for all derivatives feed messages.
Format
Field Offset Size Format Description

(Bytes)
PacketLength 0 2 Binary Length of the packet including the 16-byte packet header.
Integer
PacketType 2 2 Binary Identifier for the type of data contained in the packet.
Integer ‘799’ – Generic Derivatives Message
PacketSeqNum 4 4 Binary This field contains the packet sequence number. It is unique for each
Integer broadcast channel (multicast group) and is used for gap detection. It
increases serially and monotonically and is reset to 1 at the beginning of
each trading day.
SendTime 8 4 Binary Time in milliseconds indicating the packet broadcast time. The number
Integer represents the number of milliseconds since the previous Sunday 00:00
UTC.
ServiceID 12 2 Binary Numeric value identifying the service.
Integer
DeliveryFlag 14 1 Binary Indicates delivery method.
Integer ‘0’ - Real Time message
‘2’ - Retransmission message
NumberMsgEntries 15 1 Binary The number of messages that are contained within the packet.
Integer

5.11 Market The table below describes the body fields of a Market Update message.
Update
A Market Update message is sent as a result of one of the following events:
• New top of book price and/or volume (explicitly entered or implied);
• New depth of book price and/or volume;
• New Indicative Opening price calculated;
• New Last Trade;
• New indicative open price.
Field Name Offset Size Format Description

(Bytes)
MsgSize 0 2 Binary Length of the message body, excluding the 2 byte MsgSize field.
Integer
MsgType 2 2 Binary Numeric message type identifier:
Integer ‘701’ - Market Update v1
SourceTime 4 4 Binary Milliseconds since the previous Sunday 00:00 (UTC)
Integer
SeriesSequenceNumber 8 4 Binary Sequence number for the message, monotonically increasing and
Integer unique for each series.
1 – 4,294,967,294
SecurityIDSource 12 1 Binary Type of the security code
Integer ‘8’ - AMR
SecurityID 13 15 ASCII Security code (source of code indicated by SecurityIDSource field)
String If SecurityIDSource = 8 then this field will contain the AMR code.
SnapshotFlag 28 1 Binary Indicates whether the price updates in the message are snapshots.
Integer ‘0’ - Real-time event/update
‘1’ - Snapshot
Filler 29 1 - Reserved for future use
UpdateCount 30 2 Binary Number of updates. Indicates number of times the following group of
Integer three fields (Update Type, Price and Volume) will be repeated in the
message.
> UpdateType - 2 Binary Type of update
Integer ‘1’ - Best Bid
‘2’ - Best Offer
‘3’ - Bid
‘4’ - Offer
‘5’ - Total Traded Volume
‘6’ - Conventional Trade
‘7’ - Block Trade
‘8’ - Basis Trade
‘9’ - Professional Trade
‘10’ - Guaranteed Cross Trade
‘11’ - Against Actual Trade
‘12’ - Asset Allocation Trade
‘13’ - External Match Trade
‘14’ - Exchange For Swap Trade
‘15’ - Exchange For Physical Trade
‘16’ - Strategy Leg Trade Price
‘17’ - Implied Bid
‘18’ - Implied Offer
‘19’ - Indicative Open Price
Filler - 2 - Reserved for future use.
> Price - 4 Binary Price. See notes below for full explanation of contents.
Signed
Integer
> Volume - 4 Binary Volume. See notes below for full explanation of contents.
Integer

Notes The UpdateCount is used to specify multiple price/volume updates for the series, included within the
message.
The SnapshotFlag indicates whether the price/volume updates correspond to a real-time event or a
snapshot. A snapshot will be sent at a pre-defined time at the start of day to provide details of any
orders such as GTC orders (Good ‘Til Cancelled), and exceptionally following an intraday service
restart.
For example, a trade execution could result in updates to the last trade price, best bid and offer and
total trade volume.
• The Best Bid/Offer is the best explicit buy or sell price and aggregated volume at the best
price.
• The Bid/Offer update is explicit buy or sell price and aggregated volume at any price level
other than best. In the case where the Bid/Offer is the best price, both the Bid/Offer and the
Best Bid/Offer will be sent.
• The Total Traded Volume indicates the change to the volume traded in this instrument (series)
since the start of the trading session as a result of a trade.
• The Trade update provides the last traded price and volume. The update trade type indicates
the type of trade involved. For example a Conventional trade is a central order book trade, a
Block Trade is a wholesale trade type, the strategy leg trade indicates that the traded price
and volume in an outright leg traded as part of a strategy order.
• Implied bid/offer prices are sent for a given outright series when either a) an implied out
buy/sell price can be calculated, and it is better than or equal to the best explicitly quoted
price, or b) a previously transmitted implied buy/sell price or volume changes, or can no longer
be implied.
• The Indicative Open Price indicates that the information is a change to an indicative opening
price and or volume, transmitted during Pre-Opening only.
Note that trade prices will not be provided for Against Actual trades, as per market convention.
The content of the price/volume fields depends on the value of the field UpdateType as follows:
Update Type Price Volume

Best Bid / Offer Best explicit buy/sell price Aggregated volume at this price
Bid / Offer Explicit buy/sell price in depth Aggregated volume at this price
Total Traded Volume N/A Accumulated volume for series for trading date.
Conventional Trade Trade price Traded volume
Block Trade Trade price Traded volume
Basis Trade Trade price Traded volume
Professional Trade Trade price Traded volume
Guaranteed Cross Trade Trade price Traded volume
Against Actual Trade N/A Traded volume
Asset Allocation Trade Trade price Traded volume
External Match Trade Trade price Traded volume
Exchange for Swap Trade Trade price Traded volume
Exchange for Physical Trade Trade price Traded volume
Strategy leg trade price Trade price Traded volume
Implied Bid / Offer Implied buy/sell price in depth Aggregated volume at this price
Indicative Open Price Indicative Opening price Indicative Opening volume

5.12 The table below describes the body fields of a Settlement Prices message.
Settlement
This message can be transmitted at any time during Market Trading or Session End. It gives
Prices official (final) settlement and closing prices for outright products.

(Bytes)
Integer
Integer ‘711’ - Settlement Prices v1
Integer
InfoBlockType 8 1 Binary Type of Info Block
Integer ‘1’ - Connect Commodity
InfoBlock 9 7 ASCII Identifies the entity (format indicated by InfoBlockType field).
String If InfoBlockType = 1 then the format will be 1 char Exchange Code, 1
char Generic Contract Type, 3 chars Product Code.
UpdateType 16 2 Binary Type of update

Integer ‘2’ - Official Daily
‘4’ - Official Market Close
‘6’ - Official Expiry
‘8’ - Official IntraDay
‘10’ - Official YDSP
Integer three fields (SecurityIDSource, SecurityID and Price) will be repeated
in the message.
> SecurityIDSource - 1 Binary Type of the security code
> SecurityID - 15 ASCII Security code (source of code indicated by SecurityIDSource field)
> Price - 4 Binary Settlement price.
Signed
Integer
Notes The UpdateCount is used to specify multiple updates for a given settlement type to be disseminated.
For example settlement prices for all FTSE 100 futures can be updated in a single message.
InfoBlockType and InfoBlock is used to define standard (product) information for the series within
message.
The following types of settlement prices can be transmitted (indicated by the UpdateType field):
• Daily - Used for daily margining and settlement calculations, and may be published before the
market closes.
• Market Close - Published at the end of each day's trading in the contract. No further trades will
be sent after the Market Close has been received.
• Expiry - Exchange Delivery Settlement Price (EDSP). Final official settlement prices for an
expiring contract, and are published as soon as a contract finishes trading on its expiry day.
• Intraday - Disseminated in the same way as settlement prices. The intraday settlements are
differentiated from daily settlements.
• YDSP – Yesterday Daily Settlement Price. Previous trading day's daily settlement price.

5.13 Outright The table below describes the body fields of an Outright Standing Data message.
Standing Data
This message is transmitted by the system during the referential data download at the start of
the day, or when there is an intra-day change to the list of valid outright markets available for a
particular product. The feed may also send standing data following a system failure/recovery.
A single outright standing data update message will be sent for every outright (future or
option) instrument that will update on the feed.

(Bytes)
Integer
Integer ‘721’ - Outright standing data v1
Integer
ExchangeCode 8 1 ASCII Single character code that indicates the type of products traded on the
Char exchange.
ProductCode 9 3 ASCII Physical product code.
String
ExpiryDate 12 4 Binary Date of expiry.
Integer Format is YYYYMMDD.
Day is always set to ‘00’.
ExercisePrice 16 4 Binary Exercise Price.
Integer Will be zero for futures.
LotSize 20 4 Binary Number of items of underlying in one lot of the contract.
Integer
ContractType 24 1 ASCII Generic contract type.
Char ‘F’ - Future
‘O’ - Option
OptionType 25 1 ASCII For options only.
Char ‘C’ - Call
‘P’ - Put
NoSecurityIDs 27 1 Binary Number of alternate security IDs given. Indicates number of times the
Integer group of two fields (SecurityIDSource and SecurityID) will be repeated
in the message.
Notes The NoSecurityIDs field indicates the different codes used to represent the instrument. This allows
multiple references to be connected to the series.

5.14 Strategy The table below describes the body fields of a Strategy Standing Data message.
Standing Data
This message is transmitted by the system during the referential data download at the start of
the day, or when there is an intra-day change to the list of valid strategy markets available for
a particular product. The feed may also send standing data following a system
failure/recovery.
A single strategy standing data update message will be sent for every strategy instrument that
will update on the feed.

(Bytes)
Integer
Integer ‘731’ - Strategy standing data v1
Integer
ExchangeCode 8 1 ASCII Single character code that indicates the type of products traded on the
Char exchange.
ProductCode 9 3 ASCII Physical product code.
String
ExpiryDate 12 4 Binary Date of expiry.
Integer Format is YYYYMMDD
Day is always set to ‘00’.
ContractType 16 1 ASCII Generic contract type.
Char ‘F’ - Future
‘O’ - Option
StrategyCode 17 1 ASCII Exchange-recognised market code
String
For example ‘E’ = Calendar Spreads
For full list of values see
http://www.nyse.com/pdfs/recognised_strategies.pdf
NoSecurityIDs 19 1 Binary Number of alternate security IDs given. Indicates number of times the
Integer
group of two fields (SecurityIDSource and SecurityID) will be repeated
in the message.
Integer
‘8’ - AMR
String
If SecurityIDSource = 8 then this field will contain the AMR code.
NumLegs 1 Binary Number of legs in the strategy. Maximum 32.
- Integer
Filler - 3 - Reserved for future use.
> LegRatio 4 Binary Ratio of lots for the leg. For contingent trades, the delta. Also used for
Integer
inter-commodity spread trades. Should be used in conjunction with
- LegRatioScaleCode.
> LegRatioScaleCode 1 Binary Scale code for LegRatio field.
- Integer
> LegBuySell 1 ASCII ‘B’ - Buy
Char
- ‘S’ - Sell
> NoLegSecurityIDs - 1 Binary Number of alternate security IDs given for the strategy leg. Indicates
Integer
number of times the following group of two fields
(LegSecurityIDSource and LegSecurityID) will be repeated in the
message.
> Filler - 1 - Reserved for future use.
> > LegSecurityIDSource - 1 Binary Type of the security code
Integer
‘8’ - AMR
> > LegSecurityID - 15 ASCII Security code (source of code indicated by LegSecurityIDSource field)
String
If LegSecurityIDSource = 8 then this field will contain the AMR code.
Notes The NoSecurityIDs field indicates the different codes used to represent the instrument. This allows
multiple references to be connected to the strike.

5.15 Product The table below describes the body fields of a Product Availability message.
Availability
This message indicates whether individual products are available or unavailable for trading. It
is transmitted at start of day and whenever the product’s availability changes.

(Bytes)
Integer
Integer ‘741’ - Product Availability v1
Integer
Integer
‘1’ - Connect Commodity
String If InfoBlockType = 1 then the format will be 1 char Exchange
Code, 1 char Generic Contract Type, 3 chars Product Code.
TradingDay 16 4 Binary Trading date of the logical trading day.
Integer Format is YYYYMMDD.
TradingAvailableFlag 20 1 Binary Indicates product availability:
Integer ‘0’ - Product is not available for trading
‘1’ - Product is available for trading
Filler 21 3 - Reserved for future use.
ThrottleSize 24 4 Binary Flag to identify the number of order messages permitted per
Integer second
Notes InfoBlockType and InfoBlock is used to define standard (product) information for the series within
message.
Upon receiving a Product Available message with TradingAvailableFlag = 1, the user should
clear all order books for that product.
For example if a Product Available message with TradingAvailableFlag = 1 is received with

InfoBlock = CFOZI, the client should clear the order books for all Silver Options.
A Product Available message with TradingAvailableFlag = 1 will always be shortly followed by a

snapshot of market data, as set out in section 3.12.

5.16 Market The table below describes the body fields of a Market Status message.
Status
Market mode changes may be notified for a product, an expiry or series.
This message is also used to notify the market of session changes.

(Bytes)
Integer
Integer ‘751’ - Market Status v1
Integer
SecurityIDSource 8 1 Binary Type of the security code (according to level at which the market mode
Integer applies – product, expiry or market)
‘8’ - AMR
‘9’ - Expiry
‘10’ - Product
If SecurityIDSource = 9 then the format will be 1 char Exchange Code,
1 char Generic Contract Type, 3 chars Product Code, 8 chars Expiry
Date (format YYYYMMDD).
If SecurityIDSource = 10 then the format will be 1 char Exchange Code,
1 char Generic Contract Type, 3 chars Product Code.
NoUpdates 24 2 Binary Number of market mode updates for the specified SecurityID. Indicates
Integer number of times the following field (Market Mode) will be repeated in
the message.
> MarketMode - 2 Binary Market mode setting
Integer ‘1’ - Closed
‘2’ - Block Open
‘3’ - Block Closed
‘4’ - ExPit Extend Open
‘5’ - ExPit Extend Closed
‘6’ - Halted
‘7’ - Open
‘8’ - Pre Closed
‘9’ - Pre Open
‘10’ - Price Limits Enabled
‘11’ - Price Limits Disabled
‘12’ - Restricted Open
‘13’ - Session 1
‘23’ - Quote Width Exemption 1
‘30’ - Trading Unhalt
‘31’ - Terminate
‘32’ - Un-Terminate
‘39’ - Expire
‘40’ - Pre-Expiry

Notes Market mode changes may be notified for a product, an expiry or a series.
If a market mode change is transmitted for a product, this indicates that all individual outright and
strategy markets in that product have changed. In this case the SecurityID field will contain the
Exchange Code, Generic Contract Type and Product Code. For example, for Gold futures this field will
take the value ‘CFZG ‘.
If a market mode change is transmitted for an expiry, this indicates that all individual outright markets in
that product expiry month, and in some cases strategy markets with at least one leg in that product
expiry month, have changed. In this case the SecurityID field will contain the Exchange Code, Generic
Contract Type, Product Code and Expiry Date. For example, for all June 2009 Silver options, the field
will take the value ‘COOZI 20090600’.
If a market mode change is transmitted for a series, this indicates that only the individual
outright/strategy instrument has undergone a change of state. In this case the SecurityID field will
contain the AMR Code.
Note that the format of this message allows multiple mode changes for the same entity to be
communicated in a single message.
• The Closed mode indicates that the product is in a Closed market state.
• Block Open/Closed to indicate that the product is open/closed for Block trading.
• ExPit Extend Open/Closed modes indicate that Block and Professional trading is currently
permitted/not permitted in the product.
• Halted mode indicates that the product is in a Trading halt market state.
• Open mode indicates that the product is in a Open market state.
• Pre Closed mode indicates that the product is about to move into a Closed market state.
• Pre Open mode indicates that the product is in a Pre Open market state.
• Price Limits Enabled/Disabled modes indicate the Dyanamic price limits are enabled/disabled
for the product.
• Session 1 to 3 modes indicate the current trading session.
• Quote Width Exemption 1 – standard legal widths are in effect.
• Quote Width Exemption 2 -double standard legal widths are in effect.
• Quote Width Exemption 3 – triple standard legal widths are in effect.
• Trading Unhalt – Trading has resumed for the indicated series / underlying.
• Terminate – indicates that the series/expiry/product has been suspended for trading. In this
case all orders (including GTC Orders) that remain unmatched in the central order book will be
pulled automatically by the Trading Host, and no new orders will be accepted.
• Un-Terminate – indicates that the series/expiry/product has been unsuspended.
• Expired mode indicates that the product has moved into the expired market state.
• Pre expiry mode indicates that product is about to move into an expired market state.

5.17 The table below describes the body fields of an Exchange Message.
Exchange
This message is used to process one of a number of predefined messages and text messages
Message from Exchange officials.
The text of the message can be in English or the exchange local language.

(Bytes)
Integer
Integer ‘761’ - Exchange Message v1
Integer
NewsCount 16 4 Binary Count of text messages. Indicates number of times the following
Integer group of fields (MsgType, Importance, TextFormat and Text) will be
repeated in the message.
> MsgType - 1 ASCII Char Generic message classification
T = Text message
> Importance - 1 Binary Importance of the message, values from 1-99
Integer ‘1’ - most important
‘99’ - least important
> TextFormat - 1 Binary Format of the Text field
Integer ‘1’ - ASCII
> Text - 250 Refer to Message text.
TextFormat
field
Notes InfoBlockType and InfoBlock is used to define standard (product) information for the series within
message.

5.18 Value- The table below describes the body fields of a Value-Added Parameters message.
Added
A Value-Added Parameters message is sent as a result of a change in one of the following
Parameters parameters:
• Daily high/low price
• Yearly high/low price
• Lifetime high/low price
• Cumulative volume (book/OTC/total)
• Open price
• Trade count
• Percentage change

(Bytes)
Integer
Integer ‘771’ - Value-Added Parameters v1
Integer
Integer three fields (Update Type, Price and Volume) will be repeated in the
message.
> UpdateType - 2 Binary Type of update
Integer
‘1’ - Daily High
‘2’ - Daily Low
‘3’ - Yearly High
‘4’ - Yearly Low
‘5’ - Lifetime High
‘6’ - Lifetime Low
‘7’ - Cumulative Volume Book
‘8’ - Cumulative Volume OTC
‘9’ - Cumulative Volume
‘10’ - Open Price
‘11’ - Trade Count
‘12’ - Percentage Change
> Filler - 2 - Reserved for future use
> Price - 4 Binary Price. See notes below for full explanation of contents.
Signed
Integer
> Volume - 4 Binary Volume. See notes below for full explanation of contents.
Integer
Notes The UpdateCount is used to specify multiple price/volume updates for the series, included within the
message.
For example, a trade execution could result in updates to the high price, trade count and cumulative
volume.
Trades are classified as either ‘book’ or ‘OTC’ (over the counter) as follows (701 message Update Type
provided in brackets):
• Book trades – Conventional Trade (6), Guaranteed Cross (10), Strategy Leg Trade Price (16)

• OTC trades – Block Trade (7), Basis Trade (8), Professional Trade (9), Against Actual Trade
(11), Asset Allocation Trade (12), External Match Trade (13), Exchange For Swap Trade (14),
Exchange For Physical Trade (15).
• Daily High/Low - Highest/Lowest trade price for the current trading day for book trades only.
• Yearly High/Low - Highest/Lowest trade price for the current year for book trades only.
• Lifetime High/Low - Highest/lowest trade price for the lifetime of the instrument for book trades
only.
• Cumulative Volume Book - Total traded volume on the instrument for book trades.
• Cumulative Volume OTC - Total traded volume on the instrument for OTC trades.
• Cumulative Volume - Total traded volume on the instrument for book and OTC trades.
• Open Price - Price of the opening book trade for the instrument.
• Trade Count - Number of book trades matched over the course of the current trading day.
• Percentage Change - The percentage change between the last traded book price and the
previous day settlement price. Note that the value of the price field will be an integer. The last
2 digits represent decimal points, so for example a field value of 325 will represent a change of
3.25%.
Update Type Price Volume

Daily High/Low Highest/Lowest Trade for the Day N/A
Yearly High/Low Highest/Lowest Trade for the Year N/A
Lifetime High/Low Highest/Lowest Trade for the instrument lifetime N/A
Cumulative Volume Book N/A Cumulative Volume Book
Cumulative Volume OTC N/A Cumulative Volume OTC
Cumulative Volume N/A Cumulative Volume
Open Price First Trade Price for the Day N/A
Trade Count N/A Number of Trades Matched in the Day
Percentage Change Percentage Change for the Day (2 decimal places) N/A

5.19 Open The table below describes the body fields of an Open Interest message.
Interest
Note that this message will not be implemented for launch of the NYSE Liffe U.S.
Datafeed. Users should refer to a separate Open Interest File service available on the
FTP Server.

(Bytes)
Integer
Integer ‘781’ - Open Interest v1
Integer
Integer three fields (SecurityIDSource, SecurityID and OpenInterest) will be
repeated in the message.
> Open Interest - 4 Binary Open interest.
Integer
Notes The UpdateCount is used to specify multiple open interest values in a single message (for a single
product). For example open interest values for all FTSE 100 futures.
InfoBlockType and InfoBlock is used to define standard (product) information for the series within
message.

5.20 Option The table below describes the body fields of an Option Valuation message.
Valuation
This message is sent whenever the AQS system calculates a new theoretical bid/ask quote for
an option series.

(Bytes)
Integer
Integer ‘791’ - Option Valuation
Integer
Integer
‘8’ - AMR
TheoreticalBidPrice 24 4 Binary Theoretical buying price generated by the AQS system from
Integer underlying prices.
TheoreticalAskPrice 28 4 Binary Theoretical selling price generated by the AQS system from underlying
Integer prices.
Delta 32 4 Binary The delta of an option, i.e. the change in the value of an option based
Signed on change in the underlying.
Integer Should be used in conjunction with DeltaScaleCode.
Vega 36 4 Binary The vega of an option, i.e. the change in the value of an option for a 1-
Signed percentage point move in the underlying.
Integer Should be used in conjunction with VegaScaleCode.
DeltaScaleCode 40 1 Binary Scale code for Delta field.
Integer
VegaScaleCode 41 1 Binary Scale code for Vega field.
Integer
Filler 42 2 - Reserved for future use.
Notes

Chapter 6– NYSE Liffe U.S. Feed Technical Message
Specifications
Overview Technical Messages allow conversing parties to exchange session-specific information, for
example processing heartbeats, resetting the packet sequence number, and requesting data
retransmission.
6.1 Packet All technical messages will contain a common packet header followed by a single technical
Header Format message body.
The table below describes the header fields of a Derivatives Feed technical message.

(Bytes)
PacketLength 0 2 Binary Length of the packet including the 16-byte packet header
PacketType 2 2 Binary Identifier for the type of data contained in the packet.
‘1’ - Packet Sequence Number Reset
‘2’ - Heartbeat Message
‘10’ - Retransmission Response message
‘20’ - Retransmission Request Message
‘24’ - Heartbeat Response Message
PacketSeqNum 4 4 Binary This field contains the packet sequence number. It is unique for each
broadcast channel (multicast group) and is used for gap detection. It
increases serially and monotonically and is reset to 1 at the beginning of
each trading day.
SendTime 8 4 Binary Timestamp in millisecond indicating the packet broadcast time. The
number represents the number of milliseconds since midnight of the last
Sunday 00:00 UTC.
ServiceID 12 2 Binary Numeric value identifying the service.
DeliveryFlag 14 1 Binary Indicates delivery method.
‘0’ - Real Time message
‘2’ - Retransmission message
NumberMsgEntries 15 1 Binary The number of messages that are contained within the packet. For
heartbeat messages this will be equal to 0, for all other technical
messages this will always be equal to 1.

6.2 This message is sent to ‘reset’ the Packet Sequence Number. Note that this message will
Packet contain a valid sequence number. The message format is shown below.
Sequence
Number Reset Packet Sequence Number Processing Notes.
Packet Sequence numbers normally begin at one (1) and increase monotonically with each
subsequent packet. There are two scenarios where the packet sequence number is reset
(besides the start of day). Firstly, if the value should exceed the maximum value that the
PacketSeqNum field may contain, it will be reset to one (1). Secondly, if the system fails and
it recovers, it sends a Packet Sequence Number reset message. The PacketSeqNum field
of that packet will be set to one (1) and the NextSeqNumber field will be set to two (2).

(Bytes)
Defined below are the ‘body’ fields of the Sequence Number Reset
NextSeqNumber 16 4 Binary Contains the sequence number value that the customer should
expect in the immediately succeeding data packet. Note that this
message will contain its own valid sequence number in the header
portion of the message.
6.3 Subscribers that choose to establish and remain connected to the TCP/IP Retransmission
Heartbeat server will receive heartbeat message to let them know that the connection is still alive.
Heartbeat messages are also applied to multicast feeds.
Heartbeat frequency is 30 seconds. Heartbeats will only be sent in periods of inactivity, i.e.
when no other message types are being sent.
Heartbeat Processing notes.

Heartbeat messages will only contain the common header with an empty body.
Heartbeat messages will be sent with the same sequence number as the most
recent message that was sent.
TCP/IP only, subscribers must respond to these heartbeat requests with a heartbeat
response message.
6.4 This message will be sent by subscribers that choose to establish and remain connected to
Heartbeat the TCP/IP retransmission server intraday.
Response
It should be sent every time a heartbeat is received from the exchange. This message lets
the system know that the connection is still alive.
Note that the fields in the packet header should be filled as follows:
PacketLength = ‘36’
PacketType = ‘24’
PacketSeqNum = optional
SendTime = optional
ServiceID = Service ID of the service on which the heartbeat was sent.
DeliveryFlag = ‘0’
NumberMsgEntries = ‘1’ (only 1 retransmission request should be sent per packet)

(Bytes)
Defined below are the ‘body’ fields of the Heartbeat Response
SourceID 16 20 ASCII String This field represents the Identifier of the source (client) requesting
retransmission.
Field is null padded, left aligned.

6.5 This message is sent by subscribers requesting missing messages. The system will
Retransmission retransmit the appropriate message(s).
Request
Note that the fields in the packet header should be filled as follows:
PacketLength = ‘44’
PacketType = ‘20’
PacketSeqNum = optional
SendTime = optional
ServiceID = Service ID of the service corresponding to the request, in other words the
service for which messages need to be recovered by the client.
DeliveryFlag = ‘0’
NumberMsgEntries = ‘1’ (only 1 retransmission request should be sent per packet)

(Bytes)
Defined below are the ‘body’ fields of the Retransmission Request
BeginSeqNum 16 4 Binary Begin Sequence Number of the requested range of messages to be
retransmitted. Note the Sequence Number refers to the
PacketSeqNum in the header.
Remark:
The service from which a retransmission is requested has to be
stated in the field ServiceID in the Packet header of the
RetransmissionRequest message.
EndSeqNum 20 4 Binary End Sequence Number of the requested range of messages to be
retransmitted. Note the Sequence Number refers to the
PacketSeqNum in the header.
Remark:
The service from which a retransmission is requested has to be
stated in the field ServiceID in the Packet header of the
RetransmissionRequest message.
SourceID 24 20 ASCII String This field represents the Identifier of the source (client) requesting a
retransmission. Source-ID is pre-set by the Exchange and is subject
to validation.

6.6 This message will be sent immediately via TCP/IP in response to the subscriber’s request
Retransmission for retransmission messages.
Response

(Bytes)
Defined below are the ‘body’ fields of the Retransmission Response
SourceSeqNum 16 4 Binary This field contains the request message sequence number assigned
by the client. It used by the client to couple the request with the
response message.
SourceID 20 20 ASCII String This field represents the Identifier of the source (client) requesting
retransmission.
Status 40 1 ASCII String Indicates whether the retransmission request was accepted or
rejected. Valid values:
‘A’ - Accepted
‘R’ - Rejected.
RejectReason 41 1 Binary Indicates the reason for the rejection. Valid values:
‘0’ - Message was accepted.
‘1’ - Rejected - invalid username (SourceID).
‘2’ - Rejected - invalid sequence number range.
‘3’ - Rejected - number of packets requested exceeds the
predefined system limit.
‘4’ - Rejected - number of retransmission requests in the
current day exceeds the predefined system limit.
‘5’ - Rejected - requested packets are not available
‘6’ - Rejected - incorrectly formatted request packet
6.7 Upon receipt of a valid retransmission request message, the requested message(s) will be
Retransmission sent. This message(s) has the same message format and content as the original sent by the
Message system.

Appendix A – Message Processing
Overview The following chapter provides workflow diagrams to simplify how the NYSE Liffe U.S.
messages should be processed.
A.1 Processing Upon receipt of a valid retransmission request message, the requested message(s) will be
of messages sent. This message(s) has the same message format and content as the original sent by the
system.
Start capturing messages
Get messages
Heartbeat Reset Sequence

Message Message Type? Number Message
Data
Message
Refer to Heartbeat Refer to Data Refer to Reset

Message Flowchart Message Flowchart Sequence Number
Message Flowchart

A.2 Processing The following is the recommended way of processing Heartbeat messages.
of Heartbeat
Messages
Get the packet sequence

number (PSN)
yes Is current PSN

greater than
previous PSN?
Gap detected from

(previous PSN + 1) to no
(current PSN)
Ignore message

A.3 Processing The following is the recommended way of processing Data messages.
of Data
messages
Receive new message
Is current PSN less yes

than or equal to the
previous PSN?
no Ignore message
yes Is current PSN

greater than
previous PSN + 1?
Gap detected from

(previous PSN + 1) to no
(current PSN – 1)
Process message

A.4 Processing The following is the recommended way of processing Sequence Number Reset messages.
of Sequence
Number Reset
messages
Get the Next Sequence

Number out of the
message
Store the (Next Sequence

Number – 1) as the last
sequence number
received

A.5 Processing The following is the recommended way of handling message gaps.
of Gap
Handling
Are missing packets no

available on
Secondary channel
yes
Get missed packets from

Secondary channel and
fill the gap
no
Is entire gap filled?
yes
Request
Retransmission for
gap interval
Proceed with next packet

A.6 The following is the recommended way of interacting with the retransmission server.
Retransmission
Requests
Initiate a TCP/IP
connection with the
retransmission server
Send a Retransmission
Request message
• Begin PSN
• End PSN
• Source ID
Is the no
retransmission
request accepted?
yes
Do the received no
messages fill the
gap?
yes
Close the TCP/IP Contact NYSE

connection to the Euronext support
retransmission server

Appendix B – Price Format Codes
Overview The following table provides a full list of price format codes that can be used on the NYSE
Liffe U.S. Datafeed.
Format Format Long Name Price Price In Meaning

Code Format Ticks
A Halves PPPFFT PPP - Dollars, three digits 2445 $2.44 ½
(1/2) FF - Cents, two digits 2890 $2.89
T - Half of cents, values 0, 5 4415 $4.41 ½
A Half One Hundreds PPPFFT PPP - Points, three digit 99125 99.125
(1/2 of 1/100) FF - Decimal, two digits 98290 98.29
T - Half One Hundredths indicator, 99375 99.375
value 0 or 5
B Fourths PPPFFT PPP - Dollars, three digits 6722 $6.72 ¼
(1/4) FF - Cents, two digits 6724 $6.72 ½
T - Quarter of cents, values 0, 2, 4, 6 6726 $6.72 ¾
C Modified Fourths PPPFFT PPP - Dollars, three digits 6722 $6.72 ¼
(1/4) FF - Cents, two digits 6725 $6.72 ½
T - Quarter of cents, values 0, 2, 5, 7 6727 $6.72 ¾
D Eighths PPPFFT PPP - Dollars, three digits 244 $.24 4/8
(1/8) FF - Cents, two digits 1123 $1.12 3/8
T - Eighths of cents, values 0 - 7 477 $.47 7/8
E Modified Decimal PPPPPF PPPPP - Points 5 digits 1235 123.50

Fourths
F - 0, 2, 5, 7 457 45.75
110 11.00
F Thirty-seconds PPPPFF PPPP – Points, four digits 10911 109 11/32
(1/32) FF – Thirty-seconds of a point, 9810 98 10/32
values 00 – 31 11216 112 16/32
G Sixty-fourths PPPPFF PPPP - Points, four digits 224 2 24/64
(1/64) FF - Sixty-fourths of a point, 38 38/64
values 00 – 63 510 5 10/64
H Half thirty-seconds PPPFFT PPP - Points, three digits 109125 109 12.5/32
(1/2 of 1/32) FF - Fraction, two digits, values 00 – 31 110110 110 11/32
T - Half Thirty-second indicator, 99165 99 16.5/32

value 0 or 5
I Quarter thirty- PPPFFT PPP - Points, three digits 101122 101 12.25/32
seconds
FF - Fraction, two digits, values 00 – 31 99235 99 23.5/32
(1/4 of 1/32)
T - Quarter thirty-seconds indicator, 111017 111 01.75/32
value 0, 2, 5, or 7 121180 121 18/32
J Half Sixty-fourths PPPFFT PPP - Points, three digits 105 10.5/64
(1/2 of 1/64) FF - Fraction, two digits, values 00 – 63 220 22/64
T - Half sixty-fourths indicator, 130 13/64
value 0 or 5
K 1/20 points PPPPFF PPPP - Points, four digits 28235 282.35
FF – .05 increments 31090 310.90
K Fives PPPPFF PPPP - Dollars, four digits 205 $2.05
FF - Cents, two digits, last digit 0 or 5 645 $6.45
L Half points PPPPPF PPPPP - Points, five digits 3225 322.50
F - Half Point, value 0 or 5 4640 464.00
M Five One PPPTTT PPP - Cents, three digits 210 $.00210

Thousandths
TTT - Thousandths of Cents, 640 $.00640
(5/1000)
last digit 0 or 5 445 $.00445
N One Hundredths PPPPFF PPPP - Cents, four digits 9912 $.9912
(1/100) FF - Hundredths of Cents, two digits 9874 $.9874
9923 $.9923
N Decimal 1/100 PPPPFF PPPP Points, FF – .01 increments 1245 12.45

points
O Tenths PPPPPF PPPPP - Dollars, five digits 2307 $230.70
F - Dimes, one digit, values 0 - 9 3804 $380.40
P Ten Hundredths PPPFFT PPP - Dollars, three digits 246 $.24 60/100
(10/100) FF - Cents, two digits 293 $.29 30/100
T - Ten-Hundredths of Cents, one digit
Values 0 – 9
Q No Decimals PPPPPP PPPPPP - Points, no decimal 11590 11590.00
R Modified PPPPFF PPPP - Points, four digits 12345 123.450

1/40 points
FF - where last F - 0, 2, 5, 7 987 9.875
4360 43.600
S Quarter One PPPFFT PPP - Dollars, three digits 980700 $98.07

Hundredths T
FF - Cents, two digits 980725 $98.07 ¼
TT - Quarters of Cents, two digits 981075 $98.10 ¾

Values 0, 25, 50, 75
Y Decimal Number of decimal places is dependent on the 94.795 94.795

denominator.
The price in ticks should be divided by the

denominator to obtain the actual price.

WEP - NYSE Liffe US - Client Spec v1.7

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

WEP - NYSE Liffe US - Client Spec v1.7

Hochgeladen von

Copyright:

Verfügbare Formate

NYSE Liffe U.S.

Universal Trading Platform

Chapter 2 – NYSE Liffe U.S. Group Assignments 7

Chapter 3 – NYSE Liffe U.S. Processing Information 13

Chapter 4 – NYSE Liffe U.S. Operational Information 19

Chapter 5 – NYSE Liffe U.S. Feed Message Specifications 20

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 2 of 51

Chapter 6– NYSE Liffe U.S. Feed Technical Message Specifications 39

Appendix A – Message Processing 43

Appendix B – Price Format Codes 49

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 3 of 51

© 2009, NYSE Euronext - All rights reserved.

However, information is subject to change without notice.

Document V1.0, 25 September 2008, Initial Version

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 4 of 51

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 5 of 51

Multicast Group/Channel A single multicast stream, corresponding to a single

Exchange Trading Exchange such as Liffe, or a group of related

Product Term used to define each separate product such as Euribor

Expiry For a given product, all series expiring on a particular date,

AMR Automated Market Reference, unique identifier used on

RFQ Request for Quote.

SFTI Secure Financial Transaction Infrastructure

Monotonical Incrementally increase in value by one.

UDP User Datagram Protocol.

TCP Transmission Control Protocol.

FAST FIX Adapted for STreaming, protocol offering significant

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 6 of 51

The table below describes the categorization of the data feed.

Service Service Description

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 7 of 51

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 8 of 51

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 9 of 51

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 10 of 51

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Service Source IP Source Source Multicast Multicast

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 11 of 51

Capability Description Threshold Action

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 12 of 51

Real-Time Server Retransmission

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 13 of 51

The process of subscribing to a Multicast Group is also known as ‘joining’ a Multicast

The maximum length of a packet is 1400 bytes.

Packet Header Message 1 Message 2 … Message n

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 14 of 51

These mechanisms should be used as follows:

Dropped packet(s) on both primary and Recover dropped packet(s) from

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 15 of 51

PSNs are unique and increase monotonically for each service.

The primary and secondary channels are identical in terms of:

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 16 of 51

The request may be rejected for any of the following reasons:

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 17 of 51

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 18 of 51

Event Time (EST) * =Next Day

A single trading session will always run from 6:25pm to 5:30pm.

NYSE Liffe U.S. Feed Specifications Version 1.7 Page 19 of 51

The feed supplies both standing data and real-time messages.