Docstoc

PSE FIX SPECIFICATION Open order

Document Sample
PSE FIX SPECIFICATION Open order Powered By Docstoc
					                     PSE FIX SPECIFICATION
Overview
• This presentation in general describes the implementation of the FIX 4.4 as
  used by the PSE via the PSE FIX Gateway for Equities.
• This presentation assumes the reader thoroughly understands the FIX 4.2 or
  4.4 protocol which is available at http://www.fixprotocol.org/.
• This document is not intended as a guide to constructing a FIX client. Rather,
  it is a checklist to ensure that a firm‘s FIX client, constructed according to the
  FIX 4.4 , will be compatible with the PSE FIX Gateway on the ambiguous
  details of the FIX specification.

About the PSE FIX Gateway
• The PSE FIX Gateway strictly follows the FIX 4.4.
                 PSE FIX SPECIFICATION
PSE FIX Certification

• PSE will be asking NYSE-AEMS to provide a fully automated
  method for customers to test their FIX connection through a
  certification suite of automated FIX certification and testing tool.
• Certification testing will be required. The PSE will provide a test
  system for the system vendors that is driven with canned data
  outside of normal market hours.
• Before a subscriber can go live, it is mandatory to complete
  approved test scripts to become FIX Certified.
                    PSE FIX SPECIFICATION
System Architecture
• Each client sends orders to their assigned session and port on the PSE FIX
   Gateway. The PSE FIX Gateway then routes the order to the appropriate
   destination.
• The PSE FIX Gateway is designed to route orders to all destinations.
                   PSE FIX SPECIFICATION
Session Protocol
Only the following FIX Session MsgTypes may be sent to the PSE FIX Gateway:
Administrative Messages – FIX Session    Message Type
Heartbeat                                        35=0
Test Request                             35=1
Resend Request                           35=2
Session Reject                           35=3
Sequence Reset                           35=4
Logout                                   35=5
Logon                                    35=A
                    PSE FIX SPECIFICATION
Only the following FIX Application MsgTypes may be sent to the PSE FIX
   Gateway:
Application Messages – Pre Trade Message Type
New Order Single                  35=D
Order Cancel Request              35=F
Order Cancel/Replace Request      35=G
Execution Report                  35=8
Order Cancel Reject               35=9

Application Messages – Post Trade Message Type
Trade Capture Report              35=AE
Trade Capture Report Ack          35=AR

• Any other MsgType sent to the PSE FIX Host will result in a Reject.
                     PSE FIX SPECIFICATION
Sequencing and Reconnecting
• PSE resets inbound and outbound numbers to 1 at midnight , which could lead
   to problems if your firm remains connected at midnight. Your firm is required
   to log out before midnight, and connect again some time after midnight.

Logon
• The logon message must be the first message you send after establishing a
  TCP connection on the port agreed upon with PSE. EncryptMethod must be 0
  – None. Your firm must wait for a Logon from PSE before sending other
  messages and beginning gap fill operations.
• If your firm disconnects during the trading day and reconnects again, the
  logon you will receive in reply may have a sequence number greater than
  expected. It is critical that your firm detects this condition and issues a Resend
  Request to retrieve any missed Executions.
• Your firm must specify a heartbeat interval in the Logon message, which the
  PSE host will use to determine if the connection is active.
                       PSE FIX SPECIFICATION
Logout
• It is your firm‘s responsibility to log out at the end of each day before midnight You
   must verify, prior to logout, that there are no live or pending orders, otherwise your
   firm may miss trade reports.
• The party initiating the logout must be the party that breaks the TCP connection to
   PSE. This requirement allows for both sides to issue a Resend Request should the
   logout or its reply arrive with a sequence gap. If you receive a logout with a sequence
   gap, as per the protocol specification, issue a Resend Request and then your own
   logout.
Heartbeat and Test Request
• The PSE Host will use the heartbeat interval specified by the client in the Logon
   message to determine if the client is alive and the networks connecting your firm to
   PSE are functional. A value of 0 will disable this check, and the PSE Host will not
   send test requests nor break the connection if the client becomes idle.
• We recommend a heartbeat interval of 30 seconds. A value too small will waste
   bandwidth, and a value too large will defeat the purpose of the heartbeat. After
   HeartBtInt + 2 seconds of inactivity, the PSE Host will send a Test Request to
   determine if the firm is still active. After 2 * HeartBtInt + 4 seconds of inactivity, the
   PSE Host will send a logout and immediately drop the connection.
• PSE expects that your firm will use a similar method to determine if the PSE Host is
   active.
                    PSE FIX SPECIFICATION
Resend Request
• If your firm receives a Resend Request with a sequence gap, it is critical that
   you resend the appropriate messages first before sending your own Resend
   Request.
• The FIX protocol specification defines two methods to recover from gaps in
   messages. One method, should your firm receive messages 1-10, then 15,
   would be to request 11-14 and then process 15. We recommend against this
   method because it can cause certain race conditions that increase recovery
   time.
• Instead, we recommend that your firm discard message 15, and request
   messages 11-999999. PSE will resend all messages with sequence numbers
   greater than or equal to 11. Note that this circumstance refers to the general
   case; the FIX protocol specification outlines more specific recovery behavior
   for certain out of sequence Administrative messages.
                PSE FIX SPECIFICATION
Reject

• We recommend that your firm use the Reject message as
  sparingly as possible.
• As per the FIX specification, any message your firm rejects
  will not be resent. Your firm should keep a record of which
  messages the FIX Host rejects, and never resend them.
• We will send a reject (Msgtype=3) in the event that a
  customer has sent a properly formatted message, but a data
  field (price for example) is not populated with a proper value.
                PSE FIX SPECIFICATION
Sequence Reset
• It is required that a Sequence Reset – Gap Fill occurs in
  sequence. For instance, if resending 10-15, and 11-14 are
  Administrative messages other than Reject, the client should
  resend 10, then 11 should be a Sequence Reset – Gap Fill,
  with a NewSeqNum of 15, and then resend 15. As per the
  specification, all messages in answer to a Resend Request
  must be flagged Poss Dupe. We interpret this part of the
  specification to mean that the Sequence Reset – Gap Fill itself
  must be flagged Poss Dupe as well.
• A Sequence Reset – Gap Fill is the preferred method for
  handling errors. PSE will never send a Sequence Reset –
  Reset automatically. It is only sent by manual intervention,
  possibly to stop an endless loop of Resend Requests and
  resends, and we recommend that your firm do the same. We
  make no attempt to recover skipped messages when we
  receive a Sequence Reset – Reset, which is advantageous to
  breaking out of an infinite resend loop.
                PSE FIX SPECIFICATION
FIX Application messages.
• this is not a complete reference and should be used in
   conjunction with the FIX protocol specification.

New Order – Single
• In addition to requirements for the standard FIX message
  header, only the following fields are used by the application
  layer for a New Order – Single message. Any other fields
  specified in the message are ignored. (refer to your fix 4.4
  pse material)
                PSE FIX SPECIFICATION
Order Cancel Request
• When we receive a cancel request, we respond with an
  Execution Report that has ClOrdID set to the ClOrdID of the
  cancel, and OrigClOrdID set to the ClOrdID of the order.
• An order with a cancel pending must not be considered closed
  until we send an Execution message with a status indicating
  that the order is closed.
• An order may have only one cancel pending at a time.
  Sending a second cancel while one is pending will result in the
  second cancel being rejected. Only after the first cancel is
  rejected can your firm send another cancel.
• In addition to requirements for the standard FIX message
  header, only the following fields are used by the application
  layer for an Order Cancel Request. Any other fields specified
  in the message are ignored.
                  PSE FIX SPECIFICATION
Cancel/Replace Overview
• The FIX Protocol enables us to send either a new OrderID with each
  change, or keep the same OrderID. We use a new OrderId for each
  change.
• Considerable confusion exists surrounding the OrderQty field of a
  change. Some firms believe that it represents the new open quantity on
  the order. This differs markedly from the FIX semantics of changing an
  order. OrderQty in FIX represents the total number of shares the trader
  wants to purchase or sell.
• For example, on an order for 1000 shares with 200 traded, an Order
  Cancel/Replace Request with OrderQty = 600 means that the trader
  wants a total of 600 shares (and 400 shares are now open.) It does not
  mean the 43 trader wants to take home 600 more shares for a total of
  800. In other words, the trader is changing the order from 1000 to 600
  shares, or reducing the quantity by 400. If the client attempts to
  change the quantity of an order to a value less than the remaining
  shares open on the order, the order will be cancelled.
• While we allow limit orders to be changed into market orders, we do not
  allow market orders to be changed. We do not allow multiple changes to
  be active on an order at any given point in time. A change must be
  successful or fail before we allow another change on the order.
• However, an order with a change pending can be canceled.
                 PSE FIX SPECIFICATION

Execution Reports

• Clients can expect to receive an acknowledgement on any
  order placed as well as any subsequent fills in the form of an
  execution report or MsgType=8.
• Execution reports are used to convey the status of an order.
  PSE sends you an execution report when the order is accepted
  by the appropriate destination or when a cancel or
  cancel/replace has been received or completed.
               PSE FIX SPECIFICATION

Trade Capture Report

The Trade Capture Report is used for
1. Entry of a Declaration
2. Declaration Notification to the Counterpart
3. Trade Cancellation Request
4. Trade Declaration Refusal issued by Counterpart

Trade Capture Report Ack
The Trade Capture Report Ack is used for
1. Acknowledgement of a Declaration
2. Elimination Notice - Expire
3. Declaration Cancellation Notice
4. Declaration Refusal Notice
5. Execution Notice
                 PSE FIX SPECIFICATION

 FIX message format layout
• The message fields are delimited using the ASCII 01 <start of
   header> character. They're composed of a header, a body and
   a trailer. The header must contain the 8 (BeginString), 9
   (BodyLength), 35(MsgType) tags. The trailer is always
   terminated by a 10 tag, a checksum.
• Header+Body+Trailer : FIX Content
• Example of a FIX message : Execution Report

8=FIX.4.2 | 9=67 | 35=8 | 49=PHLX | 56=PERS |
  11=ATOMNOCCC9990900 | 52=20071123-05:30:00.000 |
  20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 |
  40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C |
  32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=102 |
• Note that the "I" (pipe char) is the printout of SOH (ascii).
Body
Order / Trade Details Info
Trailer
Security Check thru Signature and CheckSum.
               PSE UTP SPECIFICATION
Overview
• The Universal Trading Platform Market Data Feed provides high
  speed real-time market data for NYSE Euronext markets.
• The 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
                    PSE UTP SPECIFICATION
Access
• Subscribers must join the multicast groups for primary feeds, as well as
  secondary feeds to assist in recovery. To request retransmissions of lost
  packets, subscribers must establish a TCP/IP connection.
• The system uses UDP (User Datagram Protocol). Data feeds for specific
  markets are sent to different multicast addresses. This addressing scheme
  allows customers to subscribe to the specific data feeds they need. Data feeds
  types are:
        Multicast Order Book
        Multicast Retransmission
        Multicast Refresh (Request Based)
        Multicast Refresh (Interval Based)
• Clients must supply PSE with their IP address and port and request either the
  binary or FAST compacted data feed.
• PSE supplies subscribers with the following parameters:
        IP address for the data feed the client has requested
        Port for the data feed the client has requested
        Username
                      PSE UTP SPECIFICATION
Packet Retransmission
• In the event a packet is lost on the primary feed for a multicast group, clients can
   retrieve the lost packet from the secondary feed.
• UDP can at times be unreliable and may drop packets from both the primary and
   secondary data feeds. If a packet is lost from both the primary and secondary feeds,
   clients then make a TCP/IP request to have the packets resent. Packets are resent via
   the Retransmission Multicast Feed.
• Subscribers have the option to connect to the TCP/IP Recovery Server to request
   dropped packets from the PSE multicast feed. This method is highly recommended in
   order to maintain a stable and accurate order book.
• The Recovery Server accepts connections on predefined addresses and ports and
   requires a heartbeat reply before responding to requests. It accepts primary and backup
   connections to assist recovery on the subscriber‘s end.
• After a client establishes a TCP/IP connection, PSE will immediately send a heartbeat
   request message to the client. Clients must respond to this request with a heartbeat
   response within a specific timeframe – otherwise, PSE will close the connection. After
   receiving the initial heartbeat response, the
• Recovery Server will send heartbeats to the client every 30 seconds to ensure that the
   TCP/IP connection is live.
• Note that the Source ID that the client specifies in the heartbeat response message will
   be validated by PSEBook. Each Source ID may only be logged in once per port at any
   given time.
                   PSE UTP SPECIFICATION
Compaction
• For the compaction multicast groups, book messages are compacted before
  transmission and several are transmitted in a single packet.
• Each packet has a header containing the packet size and sequence number.
• Packet headers are not compacted.
• For subscribers using compaction (also known as ―FIX Fast protocol‖) instead
  of binary, subscribers must expand compacted book messages before
  processing them.
                   PSE UTP SPECIFICATION
General Processing Notes
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‘ 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 network byte order (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.
                   PSE UTP SPECIFICATION
Packet Structure
• All packets of data sent on the Universal Trading Platform Market Data Feed
   will have a common packet header followed by one or more messages (with
   the exception of some technical messages that do not contain any messages).
• The packet header format is the same for all packets, and contains packet
   length, number of messages within the packet, packet sequence number etc.
• 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).
                      PSE UTP SPECIFICATION
Packet Header
• The packet header provides information including the total packet length, a packet
   sequence number, the number of messages within the packet and a send timestamp.

•   The format of each message within a packet will vary according to message type.
    However, regardless of the message type, each message will start with a 2-byte
    message length followed by a 2-byte message type.

Sequence Numbers
All messages conform to the line level sequencing. Each channel has its own packet
sequence number. Subscribers can use packet sequence numbers to determine the
following:
• Missing (gapped) packets
• Unordered packets
• Duplicate packets
Clients should note that the packet sequence number per channel might restart from one
following a failure recovery. A reset packet sequence number message will be sent to
clients via the Multicast Groups to inform of such an event.
                   PSE UTP SPECIFICATION
Detecting and Recovering Missed Data
UDP can at times be unreliable and may drop packets from both the primary and
secondary data feeds. The UTP Market Data 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:
                   PSE UTP SPECIFICATION
Gap Detection
• 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.
• The following diagram illustrates how the PSN should be used to detect gaps
  in the feed.
                PSE UTP SPECIFICATION
Gap Detection
                    PSE UTP SPECIFICATION
Line Arbitration
• 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 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:
                   PSE UTP SPECIFICATION
Line Arbitration
                      PSE UTP SPECIFICATION
Retransmission Server
• 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.
• After a client establishes a TCP/IP connection, the Retransmission Server will
   periodically send heartbeat request messages to the client. Clients must respond to this
   request with a heartbeat response within a specific timeframe – otherwise, the
   Retransmission Server will close the connection. This timeframe is currently set to
   thirty seconds but is subject to change—so clients should make this configurable.
   (Clients will be informed of changes to the timeframe via customer notice.)
• 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 number of retransmissions allowed per client per day is limited.
• The length of each retransmission is limited to a pre-defined number of packets.
                  PSE UTP SPECIFICATION
Retransmission Server
                   PSE UTP SPECIFICATION
Sample Feed and Port Assignments

Uncompacted Feed
                  PSE UTP SPECIFICATION
Sample Feed and Port Assignments

Compacted Feed
                  PSE UTP SPECIFICATION
Sample Feed and Port Assignments

Retransmission Uncompacted Feed
                  PSE UTP SPECIFICATION
Sample Feed and Port Assignments

Retransmission Compacted Feed
                  PSE UTP SPECIFICATION
The FIX FAST Protocol
Overview
• Subscribers can choose to receive the ArcaBook real-time data feed in the
   FAST Protocol. This protocol is a standard method for compacting real-time
   market data resulting in reduced bandwidth and reduced latency.
• The complete FAST specification is available at:
   http://fixprotocol.org/documents/1766/FAST%20SERDES%20Specification%
   200.5%202005-07-28.zip and
   http://fixprotocol.org/documents/1536/BMF%20Specification%200.14.zip
                      PSE UTP SPECIFICATION
The FAST Protocol uses two main approaches to reduce bandwidth:
•    Omit Redundant Fields: this uses two FAST features:
1.   FAST Templates that specify the FAST field encoding to control field omission and
     reconstitution. Field encoding schemes define whether fields can be omitted and how
     they should be interpreted if omitted. For example, Copy encoding specifies that if a
     field is not present, you should use a copy of the field from the previous message.
     Increment encoding specifies that you should use the previous value and increment it
     by some constant (usually 1). A field defined with an encoding scheme of ‗None‘
     means that it will always be present.
2.   Presence Map that indicates which fields are actually present in a message. The
     combination of field encoding templates and presence maps allows the contents of a
     message to be communicated fully while reducing the number of bytes on the wire.
•    Variable Length Fields: that compact the bits used to represent a field‘s value. This
     uses continuation bit encoding to separate the fields. Only the first seven bits of a
     byte transmit data. The high bit is the continuation bit that indicates whether data for
     the field continues or stops. When the high bit is set, this is called a stop bit and
     indicates the end of the variable length field.
                 PSE UTP SPECIFICATION
Recommended way of processing messages:
                   PSE UTP SPECIFICATION
Processing of sequence number reset messages:
                   PSE UTP SPECIFICATION
Processing of heartbeat messages:
                   PSE UTP SPECIFICATION
Processing of heartbeat response messages:
                   PSE UTP SPECIFICATION
Processing of data messages:
                   PSE UTP SPECIFICATION
Processing of handling gaps in messages:

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:15
posted:12/23/2010
language:English
pages:42
Description: PSE FIX SPECIFICATION Open order