wep - nyse liffe us - client spec v1.7[1]

8/9/2019 WEP - NYSE Liffe US - Client Spec v1.7[1]

1/51

Disclaimer

NYSE Euronext 2009This document contains information which is confidential and of value to NYSE Euronext. It may be used by NYSE Euronextclients 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 inNYSE Euronext.

No part of this publication may be redistributed or reproduced in any form or by any means or used to make any derivativework (such as translation, transformation, or adaptation) without written permission from NYSE Euronext. NYSE Euronextreserves the right to alter any of its rules, procedures or contract specifications, and such an event may affect the validity of theinformation in this document.

Whilst all reasonable care has been taken to ensure that the information contained in this publication is accurate and notmisleading at the time of publication, NYSE Euronext shall not be liable (except to the extent required by law) for the use of theinformation contained herein however arising. Neither NYSE Euronext, nor its servants nor agents, is responsible for anyerrors or omissions contained in this publication, which is published for information only and shall not constitute investmentadvice.

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.

NYSE Liffe U.S.

Datafeed Specifications

Universal Trading Platform

STATUS

Version 1.7

20 February 2009


2/51

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

Table Of Contents

Table Of Contents 2

Chapter 1 Introduction 4Copyright Trademark Statements 4Notice 4Document History 4Overview 5Terms and Definitions 6

Chapter 2 NYSE Liffe U.S. Group Assignments 7Overview 72.1 NYSE Liffe U.S. Services 7

2.2 Primary Production IP Addresses 82.3 Secondary Production IP Addresses 82.4 Primary Backup Production IP Addresses 82.5 Secondary Backup Production IP Addresses 92.6 Primary Production Retransmission IP Addresses 92.7 Secondary Production Retransmission IP Addresses 92.8 Primary Backup Production Retransmission IP Addresses 92.9 Secondary Production Retransmission IP Addresses 102.10 Primary Test IP Addresses 112.11 Secondary Test IP Addresses 112.12 Primary Test Retransmission IP Addresses 112.13 Secondary Test Retransmission IP Addresses 112.14 Retransmission Request Thresholds 12

Chapter 3 NYSE Liffe U.S. Processing Information 13Overview 133.1 Access to Data 133.2 Real-Time Market Data 143.3 Packet Structure 143.4 Sequence Numbers 153.5 Compression 153.6 Standing Data 153.7 Gap Detection 153.8 Recovering Missed Data 153.9 Line Arbitration 163.10 Retransmission Server 163.11 Retransmission Server Heartbeat 17

3.12 System Behaviour on Start and Restart 183.13 Cancellations and Corrections 18

Chapter 4 NYSE Liffe U.S. Operational Information 19Overview 194.1 Feed Operation Hours 194.2 Trading Calendar 194.3 Exchange System Failure 194.4 Client System Failure 19

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


3/51


5.1 General Processing Notes 205.2 Data Classification 215.3 Time Conventions 215.4 Sequence Numbers 215.5 Price Formats 225.6 Prices in ticks 225.7 Data Types 225.8 Security Identifiers 225.9 Product Codes 235.10 Packet Header Format 24

5.11 Market Update 255.12 Settlement Prices 275.13 Outright Standing Data 285.14 Strategy Standing Data 295.15 Product Availability 315.16 Market Status 325.17 Exchange Message 345.18 Value-Added Parameters 355.19 Open Interest 375.20 Option Valuation 38

Chapter 6 NYSE Liffe U.S. Feed Technical Message Specifications 39Overview 396.1 Packet Header Format 396.2 Packet Sequence Number Reset 406.3 Heartbeat 406.4 Heartbeat Response 406.5 Retransmission Request 416.6 Retransmission Response 426.7 Retransmission Message 42

Appendix A Message Processing 43Overview 43A.1 Processing of messages 43A.2 Processing of Heartbeat Messages 44A.3 Processing of Data messages 45A.4 Processing of Sequence Number Reset messages 46

A.5 Processing of Gap Handling 47A.6 Retransmission Requests 48

Appendix B Price Format Codes 49Overview 49


4/51


Chapter 1 Introduction

CopyrightTrademarkStatements

NYSE Euronext refers to NYSE Euronext and its affiliates and references to NYSE Euronext

in this publication include each and any such company as the context dictates. NYSE

, NYSE

Euronext

, Euronext,

NYSE Arca

, NYSE Liffe

and NYSE LiffeU.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 andaccurate at the time of publication.

However, information is subject to change without notice.

Document

History

V1.0, 25 September 2008, Initial Version

V1.3, 5 December 2008, Updated document formatV1.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.


5/51


Overview This document details the Specifications of the Universal Trading Platform Market Data Feedfor 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 thedevelopment of client applications by Members, Independent Software Vendors and QuoteVendors.


6/51


Terms andDefinitions

Service

Multicast Group/Channel

Exchange

Product

Expiry

Series

AMR

AQS

RFQ

SFTI

Big Endian

Monotonical

UDP

TCP

FAST

Set of multicast channels providing data for a predefined

data set.

A single multicast stream, corresponding to a single

multicast address.

Trading Exchange such as Liffe, or a group of related

products for trading, for example London financials, NYSE

Arca Equities, NYSE Arca Bonds.

Term used to define each separate product such as Euriborfutures (I), 30 year bonds (ZB) or $10 Dow Futures (ZD).

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

for example Euribor Future September 2008, FTSE 100

options December 2009.

All option contracts of the same class that also have the

same unit of trade, expiration date, and exercise price.

Automated Market Reference, unique identifier used on

LIFFE CONNECT.

Options model used for price limits and settlement prices.

Request for Quote.

Secure Financial Transaction Infrastructure

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.

Incrementally increase in value by one.

User Datagram Protocol.

Transmission Control Protocol.

FIX Adapted for STreaming, protocol offering significant

compression capabillities for the transport of high-volume

market data feeds and ultra low latency applications.


7/51


Chapter 2 NYSE Liffe U.S. Group Assignments

Overview The following chapter provides all of the necessary connectivity information in order tosubscribe to the NYSE Liffe U.S. Market Data Feed.

2.1 NYSE LiffeU.S. Services

The NYSE Liffe U.S. data feed will be split into services. Each service will deliver a set ofupdate messages for a certain range of symbols. A unique ServiceID is associated witheach service.

The table below describes the categorization of the data feed.

Service Service

ID

Description

NYSE Liffe U.S. Precious

Metals Level 11 Multicast addresses assigned to deliver market data for NYSE

Liffe U.S. Precious Metals. Level 1 data only.

NYSE Liffe U.S. Precious

Metals Level 1 + Level 22 Multicast addresses assigned to deliver market data for NYSE

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.


8/51


2.2 PrimaryProduction IPAddresses

The table below defines the Primary Production IP/Multicast group and port assignments forall messages in the NYSE Liffe U.S. feed.

Alternative source IP addresses are shown in brackets.

NYSE Liffe U.S. Service Source IP Source

Network

Source

Netmask

Multicast

Address

Multicast

PortNYSE Liffe U.S. Precious Metals Level 1 156.48.100.4

(156.48.100.5)

156.48.100.0 255.255.255.240 224.0.60.241 31020

NYSE Liffe U.S. Precious Metals Level 1

+ Level 2

156.48.100.4

(156.48.100.5)

156.48.100.0 255.255.255.240 224.0.60.240 31022

NYSE Liffe U.S. Standing Data 156.48.100.4

(156.48.100.5)

156.48.100.0 255.255.255.240 224.0.60.242 31024

2.3 SecondaryProduction IP

Addresses

The table below defines the Secondary Production IP/Multicast group and port assignmentsfor all messages in the NYSE Liffe U.S. feed.



Network

Source

Netmask

Multicast

Address

Multicast

Port

NYSE Liffe U.S. Precious Metals Level 1 156.48.100.196

(156.48.100.197)

156.48.100.192 255.255.255.240 224.0.60.249 31021


+ Level 2

156.48.100.196

(156.48.100.197)

156.48.100.192 255.255.255.240 224.0.60.248 31023


(156.48.100.197)

156.48.100.192 255.255.255.240 224.0.60.250 31025

2.4 PrimaryBackupProduction IPAddresses

The table below defines the Primary Backup Production IP/Multicast group and portassignments for all messages in the NYSE Liffe U.S. feed.



Network

Source

Netmask

Multicast

Address

Multicast

Port


(156.48.101.5)

156.48.101.0 255.255.255.240 224.0.60.241 31020


+ Level 2

156.48.101.4

(156.48.101.5)

156.48.101.0 255.255.255.240 224.0.60.240 31022


(156.48.101.5)

156.48.101.0 255.255.255.240 224.0.60.242 31024


9/51


2.5 SecondaryBackupProduction IPAddresses

The table below defines the Secondary Backup Production IP/Multicast group and portassignments for all messages in the NYSE Liffe U.S. feed.



Network

Source

Netmask

Multicast

Address

Multicast

Port


(156.48.101.197)

156.48.101.192 255.255.255.240 224.0.60.249 31021


+ Level 2

156.48.101.196

(156.48.101.197)

156.48.101.192 255.255.255.240 224.0.60.248 31023


(156.48.101.197)

156.48.101.192 255.255.255.240 224.0.60.250 31025

2.6 PrimaryProductionRetransmissionIP Addresses

The table below defines the Primary Production Retransmission TCP/IP group and portassignments for all messages in the NYSE Liffe U.S. feed.

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

156.48.102.4 156.48.102.0 255.255.255.240 31010

NYSE Liffe U.S. Standing Data 156.48.102.4 156.48.102.0 255.255.255.240 31010

2.7 SecondaryProductionRetransmissionIP Addresses

The table below defines the Secondary Production Retransmission TCP/IP group and portassignments for all messages in the NYSE Liffe U.S. feed.




+ Level 2

156.48.102.5 156.48.102.0 255.255.255.240 31012


2.8 PrimaryBackupProductionRetransmission

IP Addresses

The table below defines the Primary Backup Production Retransmission TCP/IP group andport assignments for all messages in the NYSE Liffe U.S. feed.

Backup retransmission addresses will be used in disaster recovery situations only. Clientswill be informed by the exchange of a switch to Backup IP addresses.




+ Level 2

156.48.102.68 156.48.102.64 255.255.255.240 31011



10/51


2.9 SecondaryProductionRetransmissionIP Addresses

The table below defines the Secondary Backup Production Retransmission TCP/IP groupand port assignments for all messages in the NYSE Liffe U.S. feed.

Backup retransmission addresses will be used in disaster recovery situations only. Clientswill be informed by the exchange of a switch to Backup IP addresses.




+ Level 2

156.48.102.69 156.48.102.64 255.255.255.240 31013



11/51


2.10 PrimaryTest IPAddresses

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



Network

Source

Netmask

Multicast

Address

Multicast

Port


(156.48.100.37)

156.48.100.32 255.255.255.240 224.0.60.244 32020


+ Level 2

156.48.100.36

(156.48.100.37)

156.48.100.32 255.255.255.240 224.0.60.243 32022


(156.48.100.37)

156.48.100.32 255.255.255.240 224.0.60.245 32024

2.11 SecondaryTest IPAddresses

The table below defines the Secondary Test IP/Multicast group and port assignments for allmessages in the NYSE Liffe U.S. feed.


NYSE Liffe U.S. Service Source IP SourceNetwork

SourceNetmask

MulticastAddress

MulticastPort


(156.48.100.213)

156.48.100.208 255.255.255.240 224.0.60.252 32021


+ Level 2

156.48.100.212

(156.48.100.213)

156.48.100.208 255.255.255.240 224.0.60.251 32023


(156.48.100.213)

156.48.100.208 255.255.255.240 224.0.60.253 32025

2.12 Primary

TestRetransmissionIP Addresses

The table below defines the Primary Test Retransmission TCP/IP group and port

assignments for all messages in the NYSE Liffe U.S. feed.




+ Level 2

156.48.102.36 156.48.102.32 255.255.255.240 31010


2.13 SecondaryTestRetransmissionIP Addresses

The table below defines the Secondary Test Retransmission TCP/IP group and port

assignments for all messages in the NYSE Liffe U.S. feed.




+ Level 2

156.48.102.37 156.48.102.32 255.255.255.240 31012



12/51


2.14RetransmissionRequestThresholds

The table below defines the Retransmission Request thresholds for the NYSE Liffe U.S.Feed.

The numbers below represent the thresholds per service.

Capability Description Threshold Action

Prevention of invalid subscribers Incoming requests from subscribers that arenot in the enabled subscribers source ID list

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.

N/A Request will not beprocessed.

Limitation of request for a large

number of packetsOnly retransmission requests for x number

of packets or less will be honoured.

1000 Request will not be

processed.

Limitation of generic requests If the number of a subscribers generic

requests reaches the threshold number of

requests per day, the subscriber will be

blocked and retransmission requests from

that subscriber will no longer be honoured

during that particular day.

1000 Subsequent

retransmission

requests from that

subscriber will be

blocked.


13/51


Chapter 3 NYSE Liffe U.S. Processing Information

Overview The following chapter will provide you with information about how to interact with theUniversal Trading Platform Market Data Feed for NYSE Liffe U.S..

3.1 Access to

Data

Customers connect to multicast addresses for the real-time market data messages, and canalso connect to a TCP/IP server for packet retransmission requests and responses.

Exchange

Client

Real-Time Server RetransmissionServer

DualMulticastChannels

TCP/IP


14/51


3.2 Real-TimeMarket Data

Real-time market data is message-based over the UDP/IP protocol with fixed lengthbinary and ASCII fields.

It uses the push-based publishing model. This means that data will be published basedon its availability. Once an update is available, it will be published to the appropriatemulticast group.

For capacity reasons, market data will be split across a number of multicast groupsorganised into predefined data sets, called services.

Each service will deliver a set of data for a certain market segment. Dual multicastchannels are made available for line arbitrage and redundancy purposes.

The client application will be responsible for issuing Multicast subscriptions to one ormore of the Multicast Groups assigned to each product.

The process of subscribing to a Multicast Group is also known as joining a MulticastGroup. Upon session termination, the subscribers host system should issue an unjoinmessage. This will terminate delivery of data to that hosts local network.

If a client application terminates without issuing an unjoin message, the network willeventually issue a timeout for the Multicast Group subscription that will automaticallyterminate delivery of the Multicast packets to the hosts local network.

The join and unjoin processes are standard functions. No specific instructions areprovided here, as they are specific to the users operating system and programminglanguage.

3.3 PacketStructure

All packets of data sent on the Universal Trading Platform Market Data Feed will have acommon packet header followed by one or more messages (with the exception of sometechnical message packets that do not contain any messages).

The packet header format is the same for all packets, and contains characteristics ofthe 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 eachmessage 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 neverstraddle multiple packets.

The message size will never exceed the maximum packet length (less the packetheader size).

Packet Header Message 1 Message 2 Message n


15/51


3.4 SequenceNumbers

All messages conform to the line level sequencing. Each service has its own sequencenumber 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 afailure recovery. A reset sequence number message will be sent to clients via the MulticastGroups to inform of such event.

3.5Compression

FAST compression is not used for the NYSE Liffe U.S. Feed. All data will be uncompressed.

3.6 StandingData

Standing data messages are disseminated via the multicast channels. Standing 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 GapDetection

UDP can at times be unreliable and may drop packets from either or both the primary and

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

The NYSE Liffe U.S. Feed provides 2 different mechanisms for recovering 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

multicast channelRecover from other channel using linearbitrage

Dropped packet(s) on both primary and

secondary multicast channelsRecover dropped packet(s) fromretransmission server


16/51


3.9 LineArbitration

Client applications should check the Packet Sequence Number (PSN) for every packet

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

3.10RetransmissionServer

If a packet is lost from both the primary and secondary channels, clients then make a

TCP/IP request to have the packets resent. Packets are resent from the Retransmission

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:

PSN

101102103104

106107

Primary Secondary

PSN

101102103104105106107

Gap detectedon primary

channel

Dropped packet canbe recovered fromsecondary channelwithout needing to

perform aretransmission

request


17/51


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 thereason for failure.

3.11RetransmissionServerHeartbeat

Users can choose to either disconnect following each retransmission request, or remain

connected to the Retransmission Server.

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 messageshould they wish to remain connected. Such a response has to be received by the server

within 5 seconds of a heartbeat message.

Client ExchangeTCP/IP

TCP/IP

Retransmission request

Requested messages

Client Exchange

Retransmission response

Client Exchange

TCP/IP

Heartbeat response

Heartbeat


18/51


3.12 SystemBehaviour onStart andRestart

At the start of the day, the feed will send the following messages:

Standing Data Messages (721/731) for each future, option and strategy instrument

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 andlast 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.13CancellationsandCorrections

The NYSE Liffe U.S. feed does not support explicit trade cancellations and/or corrections.

In the event of a trade cancellation/correction the value-added parameters will be updated to

provide new high/low, volume, trade count and percentage change as appropriate.


19/51


Chapter 4 NYSE Liffe U.S. Operational Information

Overview The following chapter provides some additional operational information about the UniversalTrading Platform Market Data Feed for NYSE Liffe U.S..

4.1 FeedOperationHours

Operational hours for the NYSE Liffe U.S. Feed are as follows:

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 TradingCalendar

The following link provides the holiday schedule for NYSE Liffe US:

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 ExchangeSystemFailure

The exchange system is designed to be extremely resilient. However there are measures in

place to safeguard against unexpected system failures.

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 ClientSystemFailure

Real-time market data will be made available on two different multicast groups. This offers

clients the possibility to set up more than one receiving system processing the same data. In

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.


20/51


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

The following processing notes apply to the messages sent through the feed:

All fields will be sent for every packet.

Only field values will appear in the published messages (e.g., no names or tags willappear in the message)

The field names that appear in the message format documents are for referencepurposes 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 amessage will never straddle a packet boundary.


21/51


5.2 DataClassification

The table below shows how messages are distributed over the difference NYSE Liffe U.S.Datafeed services.

Message Type Service ID 1

NYSE LiffeU.S. Precious

Metals Level 1

Service ID 2

NYSE LiffeU.S. Precious

Metals Level 1

+ Level 2

Service ID 3

NYSE LiffeU.S. Standing

Data

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 TimeConventions

The base for timestamps is the number of milliseconds since the previous Sunday 00:00:00

UTC (Co-ordinated Universal Time).

For example a timestamp of 315000000 refers to Wednesday 15:30:00 UTC.

5.4 SequenceNumbers

The feed contains two sequence 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.


22/51


5.5 PriceFormats

All price fields are sent in integer format.

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:

ScaleCode

IntegerValue10

=

For example, a price of 98.75 is represented by an Integer of 9875 and a ScaleCode of 2.

5.6 Prices inticks

All prices in the feed are provided in an integer number of ticks. In order to convert from 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 quotevendors 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 DataTypes

Binary data is in network byte order (Big Endian format).

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 SecurityIdentifiers

The feed allows for different Security IDs to be used on different services. Users should use

the SecurityIDSource field to determine the Security ID to be used.


23/51


5.9 ProductCodes

The following product codes are used for NYSE Liffe U.S.:

Product ProductCodeGold Futures

ZGGold Options

OZGMini-Gold Futures

YGSilver Futures

ZISilver Options

OZIMini-Silver Options

YI


24/51


5.10 PacketHeaderFormat

Each packet comprises a packet header followed by one or more messages.

The table below describes the packet header fields for all derivatives feed messages.

Field Offset Size

(Bytes)

Format Description

PacketLength 0 2 BinaryInteger

Length of the packet including the 16-byte packet header.

PacketType 2 2 Binary

Integer

Identifier for the type of data contained in the packet.

799 Generic Derivatives Message

PacketSeqNum 4 4 Binary

Integer

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

Integer

Time in milliseconds indicating the packet broadcast time. The number

represents the number of milliseconds since the previous Sunday 00:00

UTC.

ServiceID 12 2 Binary

Integer

Numeric value identifying the service.

DeliveryFlag 14 1 Binary

Integer

Indicates delivery method.

0 - Real Time message

2 - Retransmission message

NumberMsgEntries 15 1 Binary

Integer

The number of messages that are contained within the packet.


25/51


5.11 MarketUpdate

The table below describes the body fields of a Market Update message.

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

(Bytes)

Format Description

MsgSize 0 2 Binary

Integer

Length of the message body, excluding the 2 byte MsgSize field.

MsgType 2 2 Binary

Integer

Numeric message type identifier:

701 - Market Update v1

SourceTime 4 4 Binary

Integer

Milliseconds since the previous Sunday 00:00 (UTC)

SeriesSequenceNumber 8 4 Binary

Integer

Sequence number for the message, monotonically increasing and

unique for each series.

1 4,294,967,294

SecurityIDSource 12 1 Binary

Integer

Type of the security code

8 - AMR

SecurityID 13 15 ASCII

String

Security code (source of code indicated by SecurityIDSource field)

If SecurityIDSource = 8 then this field will contain the AMR code.

SnapshotFlag 28 1 Binary

Integer

Indicates whether the price updates in the message are snapshots.

0 - Real-time event/update

1 - Snapshot

Filler 29 1 - Reserved for future use

UpdateCount 30 2 Binary

Integer

Number of updates. Indicates number of times the following group of

three fields (Update Type, Price and Volume) will be repeated in the

message.

> UpdateType - 2 Binary

Integer

Type of update

1 - Best Bid

2 - Best Offer3 - 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 Trade16 - Strategy Leg Trade Price

17 - Implied Bid

18 - Implied Offer

19 - Indicative Open PriceFiller - 2 - Reserved for future use.

> Price - 4 Binary

Signed

Integer

Price. See notes below for full explanation of contents.

> Volume - 4 Binary

Integer

Volume. See notes below for full explanation of contents.


26/51


Update Type Price VolumeBest 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 volumeExchange 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

Notes The UpdateCount is used to specify multiple price/volume updates for the series, included within themessage.

The SnapshotFlag indicates whether the price/volume updates correspond to a real-time event or asnapshot. A snapshot will be sent at a pre-defined time at the start of day to provide details of anyorders such as GTC orders (Good Til Cancelled), and exceptionally following an intraday servicerestart.

For example, a trade execution could result in updates to the last trade price, best bid and offer andtotal trade volume.

The Best Bid/Offer is the best explicit buy or sell price and aggregated volume at the bestprice.

The Bid/Offer update is explicit buy or sell price and aggregated volume at any price levelother than best. In the case where the Bid/Offer is the best price, both the Bid/Offer and theBest 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 indicatesthe type of trade involved. For example a Conventional trade is a central order book trade, aBlock Trade is a wholesale trade type, the strategy leg trade indicates that the traded priceand 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 outbuy/sell price can be calculated, and it is better than or equal to the best explicitly quotedprice, or b) a previously transmitted implied buy/sell price or volume changes, or can no longerbe implied.

The Indicative Open Price indicates that the information is a change to an indicative openingprice 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:


27/51


5.12SettlementPrices

The table below describes the body fields of a Settlement Prices message.

This message can be transmitted at any time during Market Trading or Session End. It givesofficial (final) settlement and closing prices for outright products.


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


711 - Settlement Prices v1


Integer


InfoBlockType 8 1 Binary

Integer

Type of Info Block

1 - Connect CommodityInfoBlock 9 7 ASCII

String

Identifies the entity (format indicated by InfoBlockType field).

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

Integer

Type of update

2 - Official Daily

4 - Official Market Close

6 - Official Expiry

8 - Official IntraDay

10 - Official YDSPUpdateCount 18 2 Binary

Integer


three fields (SecurityIDSource, SecurityID and Price) will be repeated

in the message.> SecurityIDSource - 1 Binary

Integer


8 - AMR> SecurityID - 15 ASCII

String



> Price - 4 Binary

SignedInteger

Settlement price.

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

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

Market Close - Published at the end of each day's trading in the contract. No further trades willbe sent after the Market Close has been received.

Expiry - Exchange Delivery Settlement Price (EDSP). Final official settlement prices for anexpiring 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 aredifferentiated from daily settlements.

YDSP Yesterday Daily Settlement Price. Previous trading day's daily settlement price.


28/51


5.13 OutrightStanding Data

The table below describes the body fields of an Outright Standing Data message.

This message is transmitted by the system during the referential data download at the start ofthe day, or when there is an intra-day change to the list of valid outright markets available for aparticular 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 oroption) instrument that will update on the feed.

Field Name Offset Size(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


721 - Outright standing data v1


Integer


ExchangeCode 8 1 ASCII

Char

Single character code that indicates the type of products traded on the

exchange.

ProductCode 9 3 ASCII

String

Physical product code.

ExpiryDate 12 4 BinaryInteger

Date of expiry.Format is YYYYMMDD.

Day is always set to 00.

ExercisePrice 16 4 Binary

Integer

Exercise Price.

Will be zero for futures.

LotSize 20 4 Binary

Integer

Number of items of underlying in one lot of the contract.

ContractType 24 1 ASCII

Char

Generic contract type.

F - Future

O - Option

OptionType 25 1 ASCII

Char

For options only.

C - Call

P - Put


NoSecurityIDs 27 1 Binary

Integer

Number of alternate security IDs given. Indicates number of times the

group of two fields (SecurityIDSource and SecurityID) will be repeated

in the message.

> SecurityIDSource - 1 Binary

Integer


8 - AMR

> SecurityID - 15 ASCII

String



Notes The NoSecurityIDs field indicates the different codes used to represent the instrument. This allowsmultiple references to be connected to the series.


29/51


5.14 StrategyStanding Data

The table below describes the body fields of a Strategy Standing Data message.

This message is transmitted by the system during the referential data download at the start ofthe day, or when there is an intra-day change to the list of valid strategy markets available fora particular product. The feed may also send standing data following a systemfailure/recovery.

A single strategy standing data update message will be sent for every strategy instrument thatwill update on the feed.


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


731 - Strategy standing data v1


Integer


ExchangeCode 8 1 ASCII

Char

Single character code that indicates the type of products traded on the

exchange.

ProductCode 9 3 ASCII

String

Physical product code.

ExpiryDate 12 4 Binary

Integer

Date of expiry.

Format is YYYYMMDD

Day is always set to 00.

ContractType 16 1 ASCII

Char

Generic contract type.

F - Future

O - OptionStrategyCode 17 1 ASCII

StringExchange-recognised market code

For example E = Calendar Spreads

For full list of values see

http://www.nyse.com/pdfs/recognised_strategies.pdf


NoSecurityIDs 19 1 Binary

Integer

Number of alternate security IDs given. Indicates number of times the

group of two fields (SecurityIDSource and SecurityID) will be repeated

in the message.> SecurityIDSource - 1 Binary

IntegerType of the security code

8 - AMR> SecurityID - 15 ASCII

StringSecurity code (source of code indicated by SecurityIDSource field)

If SecurityIDSource = 8 then this field will contain the AMR code.NumLegs

-1 Binary

IntegerNumber of legs in the strategy. Maximum 32.

Filler - 3 - Reserved for future use.

> LegRatio

-

4 BinaryInteger

Ratio of lots for the leg. For contingent trades, the delta. Also used for

inter-commodity spread trades. Should be used in conjunction with

LegRatioScaleCode.> LegRatioScaleCode

-

1 Binary

IntegerScale code for LegRatio field.

> LegBuySell

-

1 ASCIIChar

B - Buy

S - Sell> NoLegSecurityIDs - 1 Binary

IntegerNumber of alternate security IDs given for the strategy leg. Indicates

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 BinaryInteger


8 - AMR> > LegSecurityID - 15 ASCII

StringSecurity code (source of code indicated by LegSecurityIDSource field)

If LegSecurityIDSource = 8 then this field will contain the AMR code.


30/51


Notes The NoSecurityIDs field indicates the different codes used to represent the instrument. This allowsmultiple references to be connected to the strike.


31/51


5.15 ProductAvailability

The table below describes the body fields of a Product Availability message.

This message indicates whether individual products are available or unavailable for trading. Itis transmitted at start of day and whenever the products availability changes.


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


741 - Product Availability v1


Integer


InfoBlockType 8 1 BinaryInteger

Type of Info Block


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

Integer

Trading date of the logical trading day.

Format is YYYYMMDD.

TradingAvailableFlag 20 1 Binary

Integer

Indicates product availability:

0 - Product is not available for trading

1 - Product is available for trading

Filler 21 3 - Reserved for future use.

ThrottleSize 24 4 Binary

Integer

Flag to identify the number of order messages permitted per

second

Notes InfoBlockType and InfoBlock is used to define standard (product) information for the series withinmessage.

Upon receiving a Product Available message with TradingAvailableFlag = 1, the user shouldclear 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 asnapshot of market data, as set out in section 3.12.


32/51


5.16 MarketStatus

The table below describes the body fields of a Market Status message.

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)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


751 - Market Status v1


Integer



Integer

Type of the security code (according to level at which the market mode

applies product, expiry or market)

8 - AMR

9 - Expiry

10 - Product


String



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

Integer

Number of market mode updates for the specified SecurityID. Indicates

number of times the following field (Market Mode) will be repeated in

the message.

> MarketMode - 2 Binary

Integer

Market mode setting

1 - Closed

2 - Block Open

3 - Block Closed

4 - ExPit Extend Open

5 - ExPit Extend Closed6 - Halted

7 - Open

8 - Pre Closed

9 - Pre Open

10 - Price Limits Enabled

11 - Price Limits Disabled

12 - Restricted Open

13 - Session 1

14 - Session 2

15 - Session 3

23 - Quote Width Exemption 1

24 - Quote Width Exemption 2

25 - Quote Width Exemption 330 - Trading Unhalt

31 - Terminate

32 - Un-Terminate

39 - Expire

40 - Pre-Expiry


33/51


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 andstrategy markets in that product have changed. In this case the SecurityID field will contain theExchange Code, Generic Contract Type and Product Code. For example, for Gold futures this field willtake the value CFZG .

If a market mode change is transmitted for an expiry, this indicates that all individual outright markets inthat product expiry month, and in some cases strategy markets with at least one leg in that productexpiry 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 fieldwill take the value COOZI 20090600.

If a market mode change is transmitted for a series, this indicates that only the individualoutright/strategy instrument has undergone a change of state. In this case the SecurityID field willcontain the AMR Code.

Note that the format of this message allows multiple mode changes for the same entity to becommunicated 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/disabledfor 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 thiscase all orders (including GTC Orders) that remain unmatched in the central order book will bepulled 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.


34/51


5.17ExchangeMessage

The table below describes the body fields of an Exchange Message.

This message is used to process one of a number of predefined messages and text messagesfrom Exchange officials.

The text of the message can be in English or the exchange local language.


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


761 - Exchange Message v1


Integer



Integer

Type of Info Block


String




NewsCount 16 4 Binary

Integer

Count of text messages. Indicates number of times the following

group of fields (MsgType, Importance, TextFormat and Text) will berepeated in the message.

> MsgType - 1 ASCII Char Generic message classification

T = Text message

> Importance - 1 Binary

Integer

Importance of the message, values from 1-99

1 - most important

99 - least important

> TextFormat - 1 Binary

Integer

Format of the Text field

1 - ASCII

> Filler - 1 - Reserved for future use.

> Text - 250 Refer to

TextFormat

field

Message text.

> Filler - 2 - Reserved for future use.

Notes InfoBlockType and InfoBlock is used to define standard (product) information for the series withinmessage.


35/51


5.18 Value-AddedParameters

The table below describes the body fields of a Value-Added Parameters message.

A Value-Added Parameters message is sent as a result of a change in one of the followingparameters:

Daily high/low price Yearly high/low price Lifetime high/low price Cumulative volume (book/OTC/total) Open price Trade count

Percentage change


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


771 - Value-Added Parameters v1


Integer



Integer


8 - AMRSecurityID 9 15 ASCII

String




Integer


three fields (Update Type, Price and Volume) will be repeated in the

message.


> UpdateType - 2 BinaryInteger

Type of update

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

Signed

Integer

Price. See notes below for full explanation of contents.

> Volume - 4 Binary

Integer

Volume. See notes below for full explanation of contents.

Notes The UpdateCount is used to specify multiple price/volume updates for the series, included within themessage.

For example, a trade execution could result in updates to the high price, trade count and cumulativevolume.

Trades are classified as either book or OTC (over the counter) as follows (701 message Update Typeprovided in brackets):

Book trades Conventional Trade (6), Guaranteed Cross (10), Strategy Leg Trade Price (16)


36/51


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 theprevious day settlement price. Note that the value of the price field will be an integer. The last2 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/ATrade Count N/A Number of Trades Matched in the Day

Percentage Change Percentage Change for the Day (2 decimal places) N/A


37/51


5.19 OpenInterest

The table below describes the body fields of an Open Interest message.

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


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 Binary

Integer


781 - Open Interest v1


Integer



Integer

Type of Info Block


String





Integer


three fields (SecurityIDSource, SecurityID and OpenInterest) will be

repeated in the message.


> SecurityIDSource - 1 Binary

Integer


8 - AMR

> SecurityID - 15 ASCII

String



> Open Interest - 4 Binary

Integer

Open interest.

Notes The UpdateCount is used to specify multiple open interest values in a single message (for a singleproduct). For example open interest values for all FTSE 100 futures.

InfoBlockType and InfoBlock is used to define standard (product) information for the series withinmessage.


38/51


5.20 OptionValuation

The table below describes the body fields of an Option Valuation message.

This message is sent whenever the AQS system calculates a new theoretical bid/ask quote foran option series.


(Bytes)

Format Description

MsgSize 0 2 Binary

Integer


MsgType 2 2 BinaryInteger

Numeric message type identifier:791 - Option Valuation


Integer


SecurityIDSource 8 1 BinaryInteger


8 - AMR


String



TheoreticalBidPrice 24 4 Binary

Integer

Theoretical buying price generated by the AQS system from

underlying prices.

TheoreticalAskPrice 28 4 Binary

Integer

Theoretical selling price generated by the AQS system from underlying

prices.

Delta 32 4 BinarySigned

Integer

The delta of an option, i.e. the change in the value of an option basedon change in the underlying.

Should be used in conjunction with DeltaScaleCode.

Vega 36 4 Binary

Signed

Integer

The vega of an option, i.e. the change in the value of an option for a 1-

percentage point move in the underlying.

Should be used in conjunction with VegaScaleCode.

DeltaScaleCode 40 1 Binary

Integer

Scale code for Delta field.

VegaScaleCode 41 1 Binary

Integer

Scale code for Vega field.

Filler 42 2 - Reserved for future use.

Notes


39/51


Chapter 6 NYSE Liffe U.S. Feed Technical MessageSpecifications

Overview Technical Messages allow conversing parties to exchange session-specific information, forexample processing heartbeats, resetting the packet sequence number, and requesting data

retransmission.

6.1 PacketHeader Format

All technical messages will contain a common packet header followed by a single technical

message body.

The table below describes the header fields of a Derivatives Feed technical message.

Field Offset Size

(Bytes)

Format Description

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.


40/51


6.2PacketSequenceNumber Reset

This message is sent to reset the Packet Sequence Number. Note that this message will

contain a valid sequence number. The message format is shown below.

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

Field Offset Size

(Bytes)

Format Description

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

Subscribers that choose to establish and remain connected to the TCP/IP Retransmission

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

This message will be sent by subscribers that choose to establish and remain connected to

the TCP/IP retransmission server intraday.

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 = optionalServiceID = Service ID of the service on which the heartbeat was sent.

DeliveryFlag = 0

NumberMsgEntries = 1 (only 1 retransmission request should be sent per packet)

Field Offset Size

(Bytes)

Format Description

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.


41/51


42/51


6.6RetransmissionResponse

This message will be sent immediately via TCP/IP in response to the subscribers request

for retransmission messages.

Field Offset Size

(Bytes)

Format Description

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.

Field is null padded, left aligned.

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

Message

Upon receipt of a valid retransmission request message, the requested message(s) will be

sent. This message(s) has the same message format and content as the original sent by the

system.


43/51


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

Upon receipt of a valid retransmission request message, the requested message(s) will be

sent. This message(s) has the same message format and content as the original sent by the

system.

Message Type?

Get messages

HeartbeatMessage

Start capturing messages

Refer to DataMessage Flowchart

Reset SequenceNumber Message

DataMessage

Refer to ResetSequence Number

Message Flowchart

Refer to HeartbeatMessage Flowchart


44/51


A.2 Processingof HeartbeatMessages

The following is the recommended way of processing Heartbeat messages.

Gap detected from(previous PSN + 1) to

(current PSN)

Is current PSNgreater than

previous PSN?

Ignore message

Get the packet sequencenumber (PSN)

yes

no


45/51


A.3 Processingof Datamessages

The following is the recommended way of processing Data messages.

Is current PSN lessthan or equal to the

previous PSN?

Ignore message

Gap detected from(previous PSN + 1) to

(current PSN 1)

Is current PSNgreater than

previous PSN + 1?

Process message

Receive new message

yes

no

yes

no


46/51


A.4 Processingof SequenceNumber Resetmessages

The following is the recommended way of processing Sequence Number Reset messages.

Store the (Next SequenceNumber 1) as the last

sequence numberreceived

Get the Next SequenceNumber out of the

message


47/51


A.5 Processingof GapHandling

The following is the recommended way of handling message gaps.

Are missing packetsavailable on

Secondary channel

RequestRetransmission for

gap interval

Get missed packets fromSecondary channel and

fill the gap

Is entire gap filled?

Proceed with next packet

no

yes

no

yes


48/51


A.6RetransmissionRequests

The following is the recommended way of interacting with the retransmission server.

Is theretransmission

request accepted?

Contact NYSEEuronext support

Initiate a TCP/IPconnection with the

retransmission server

Send a RetransmissionRequest message

Begin PSN

End PSN

Source ID

Do the receivedmessages fill the

gap?

Close the TCP/IPconnection to the

retransmission server

yes

no

no

yes


49/51


Appendix B Price Format Codes

Overview The following table provides a full list of price format codes that can be used on the NYSELiffe U.S. Datafeed.

Format

Code

Format Long Name Price

Format

Price In

Ticks

Meaning

A Halves

(1/2)

PPPFFT PPP - Dollars, three digits

FF - Cents, two digits

T - Half of cents, values 0, 5

2445

2890

4415

$2.44

$2.89

$4.41

A Half One Hundreds

(1/2 of 1/100)

PPPFFT PPP - Points, three digit

FF - Decimal, two digits

T - Half One Hundredths indicator,

value 0 or 5

99125

98290

99375

99.125

98.29

99.375

B Fourths

(1/4)



T - Quarter of cents, values 0, 2, 4, 6

6722

6724

6726

$6.72

$6.72

$6.72

C Modified Fourths

(1/4)



T - Quarter of cents, values 0, 2, 5, 7

6722

6725

6727

$6.72

$6.72

$6.72

D Eighths

(1/8)



T - Eighths of cents, values 0 - 7

244

1123

477

$.24 4/8

$1.12 3/8

$.47 7/8

E Modified DecimalFourths

PPPPPF PPPPP - Points 5 digits

F - 0, 2, 5, 7

1235

457

110

123.50

45.75

11.00

F Thirty-seconds

(1/32)

PPPPFF PPPP Points, four digits

FF Thirty-seconds of a point,

values 00 31

10911

9810

11216

109 11/32

98 10/32

112 16/32

G Sixty-fourths

(1/64)

PPPPFF PPPP - Points, four digits

FF - Sixty-fourths of a point,

values 00 63

224

38

510

2 24/64

38/64

5 10/64

H Half thirty-seconds

(1/2 of 1/32)

PPPFFT PPP - Points, three digits

FF - Fraction, two digits, values 00 31

T - Half Thirty-second indicator,

109125

110110

99165

109 12.5/32

110 11/32

99 16.5/32


50/51


value 0 or 5

I Quarter thirty-seconds

(1/4 of 1/32)



T - Quarter thirty-seconds indicator,

value 0, 2, 5, or 7

101122

99235

111017

121180

101 12.25/32

99 23.5/32

111 01.75/32

121 18/32

J Half Sixty-fourths

(1/2 of 1/64)



T - Half sixty-fourths indicator,

value 0 or 5

wep - nyse liffe us - client spec v1.7[1]

Documents