Financial Information Exchange Protocol

Version: 4.2
Date: March 1, 2000

Financial Information Exchange Protocol

DISCLAIMER

THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER.

NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES.

No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein).

Preface

The Financial Interface eXchange (FIX) effort was initiated in 1992 by a group of institutions and brokers interested in streamlining their trading processes. These firms felt that they, and the industry as a whole, could benefit from efficiencies derived through the electronic communication of indications, orders and executions. The result is FIX, an open message standard controlled by no single entity, that can be structured to match the business requirements of each firm. The benefits are:

From the business flow perspective, FIX provides institutions and brokers a means of reducing the clutter of unnecessary telephone calls and scraps of paper, and facilitates targeting high quality information to specific individuals.
For technologists, FIX provides an open standard that leverages the development effort so that they can efficiently create links with a wide range of counter-parties.
For vendors, FIX provides ready access to the industry, with the incumbent reduction in marketing effort and increase in potential client base.

Openness has been the key to FIX's success. For that reason, while encouraging vendors to participate with the standard, FIX has remained vendor neutral. Similarly, FIX avoids over-standardization. It does not demand a single type of carrier (e.g., it will work with leased lines, frame relay, Internet, etc.), nor a single security protocol. It leaves many of these decisions to the individual firms that are using it. We do expect that, over time, the rules of engagement in these non-standardized areas will converge as technologies mature.

FIX is now used by a variety of firms and vendors. It has clearly emerged as the inter-firm messaging protocol of choice. Periodic Technical Forum meetings are held to discuss modification of the specification and are open for all to attend. Those interested in providing input to the protocol are encouraged to contact the Technical Committee Chairpersons, Scottt Atwell, American Century Investments, (US) 816-340-7053 (scott_atwell@americancentury.com) or Peter White, Goldman, Sachs & Co., (UK) 011-44-171-552-1315 (peter.white@gs.com). Periodic Technical Forum meetings are announced via email and on the WWW, go to http://www.fixprotocol.org for details.

We look forward to your participation.

FIX Protocol Ltd

March, 2000

US Steering Committee	European Steering Committee	Japanese Steering Committee
Alliance Capital	Abn Amro Bank NV.
American Century	Alliance Capital	Daiwa Securities Group Inc.
Capital Research	Axa Sun Life	DLIBJ Asset Management Co., Ltd.
Credit Suisse Asset Management	Baillie Gifford	Goldman Sachs (Japan) Ltd.
Donaldson, Lufkin & Jenrette	Barclays Global Investors
Fidelity Capital Markets	Barclays Stockbrokers	Merrill Lynch Japan Incorporated
Fidelity Mgmt & Res. Co.		Morgan Stanley Dean Witter Japan Limited
The Goldman Sachs Group, Inc.	Captial Research
Merrill Lynch	Commerzbank AG	Nikko Salomon Smith Barney
Morgan Stanley DW&D	Credit Suisse First Boston	Nippon Life Insurance Company
Paine Webber	Deutche Bank	Nomura Asset Management Co., Ltd.
Putnam Investments	Donaldson, Lufkin & Jenrette	Nomura Securities Co., Ltd
Salomon Smith Barney	Dresdner RCM Global Investors	The DaiwaBank, Ltd.
State Street Global Advisors	Fidelity International	The Mitsubishi Trust and Banking Corporation
	Foreign and Colonial Mgmt Limited	The Mitsui Trust & Banking Co., Ltd
	Goldman, Sachs International	The Sumitomo Trust & Banking Co., Ltd.
	HSBC	UBS Warburg
	Instinet
	J.P. Morgan Investment Mgmt, Inc.
	Mercury Asset Management
	Merrill Lynch
	Morgan Stanley DW&D
	Royal Sun Alliance
	Salomon Smith Barney
	Warburg Dillon-Read

Release Notes

TBC

Introduction

The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to securities transactions. It is intended for use between trading partners wishing to automate communications.

The message protocol, as defined, will support a variety of business functions. FIX was originally defined for use in supporting US domestic equity trading with message traffic flowing directly between principals. As the protocol evolved, a number of fields were added to support limited cross-border and fixed income trading. Similarly, the protocol was expanded to allow third parties to participate in the delivery of messages between trading partners. As subsequent versions of FIX are released, it is expected that functionality will continue to expand.

FIX was written to be independent of any specific communications protocol (X.25, asynch, TCP/IP, etc.) or physical medium (copper, fiber, satellite, etc.) chosen for electronic data delivery. It should be noted that if an “unreliable” or non-stream protocol is used, the Logon, Logout, and ResendRequest message processing is particularly susceptible to unordered delivery and/or message loss.

The protocol is defined at two levels: session and application. The session level is concerned with the delivery of data while the application level defines business related data content. This document is organized to reflect the distinction.

FIX Message Format and Delivery

The following section summarizes general specifications for constructing and transmitting FIX messages.

Message Format

The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer.

Each message is constructed of a stream of <tag>=<value> fields.

Except where noted, fields within a message can be defined in any sequence sequence (Relative position of a field within a message is inconsequential.) The exceptions to this rule are:

General message format is composed of the standard header followed by the body followed by the standard trailer.
The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).
The last field in the standard trailer is the CheckSum (tag #10).
Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document.
- If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry.
- Repeating groups are designated within the message definition via indentation and the 🡪 symbol.

It is permissible for fields to be repeated within a repeating group (e.g. "384=2<SOH>35=6<SOH>385=R<SOH>35=7<SOH>385=R<SOH>" represents a repeating group with 2 repeating instances).

In addition, certain fields of the type "MultipleValueString" can contain multiple individual values separated by a space within the "value" portion of that field followed by a single "SOH" character (e.g. "18=2 9 C<SOH>" represents 3 individual values: '2', '9', and 'C').

It is also possible for a field to be contained in both the clear text portion and the encrypted data sections of the same message. This is normally used for validation and verification. For example, sending the SenderCompID in the encrypted data section can be used as a rudimentary validation technique. In the cases where the clear text data differs from the encrypted data, the encrypted data should be considered more reliable. (A security warning should be generated).

All fields (including those of data type data i.e. SecureData, RawData, SignatureData, XmlData, etc.) in a FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" (#001), is used for field termination. Messages are delimited by the "SOH" character following the CheckSum field. All messages begin with the "8=FIX.x.y" string and terminate with "10=nnn<SOH>".

There shall be no embedded delimiter characters within fields except for data type data.

Data Types

Data types (with the exception of those of type "data") are mapped to ASCII strings as follows:

int

Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9"). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999").

Examples:

723 in field 21 would be mapped int as |21=723|.
-723 in field 12 would be mapped int as |12=-723|

float

Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties.

Qty

float field (see definition of "float" above) capable of storing either a whole number (no decimal places) of "shares" or a decimal value containing decimal places for non-share quantity asset classes.

Price

float field (see definition of "float" above) representing a price. Note the number of decimal places may vary.

PriceOffset

float field (see definition of "float" above) representing a price offset, which can be mathematically added to a "Price". Note the number of decimal places may vary and some fields such as LastForwardPoints may be negative.

Amt

float field (see definition of "float" above) typically representing a Price times a Qty.

char

Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m ≠ M).

Boolean

A char field (see definition of "char" above) containing one of two values:

'Y' = True/Yes
'N' = False/No

String

Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. morstatt ≠ Morstatt).

MultipleValueString

String field (see definition of "String" above) containing one or more space delimited values.

Currency

String field (see definition of "String" above) representing a currency type.

Valid values:

See Appendix A - Valid Currency Codes

Exchange

String field (see definition of "String" above) representing a market or exchange.

Valid values:

See Appendix C - Reuters Exchange Mnemonics

UTCTimestamp

Time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period required.

Valid values:

YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-59 (without milliseconds).
YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-59, sss=000-999 (indicating milliseconds).

UTCTimeOnly

Time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss (milliseconds) format, colons, and period required.

Valid values:

HH = 00-23, MM = 00-59, SS = 00-59. (without milliseconds)
HH = 00-23, MM = 00-59, SS = 00-59. sss=000-999 (indicating milliseconds).

LocalMktDate

Date of Local Market (vs. UTC) in YYYYMMDD format.

Valid values:

YYYY = 0000-9999, MM = 01-12, DD = 01-31.

UTCDate

Date represented in UTC (Universal Time Coordinated, also known as "GMT") in YYYYMMDD format.

Valid values:

YYYY = 0000-9999, MM = 01-12, DD = 01-31.

data

Raw data with no format or content restrictions. Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH). Caution: the value of one of these fields may contain the delimiter (SOH) character. Note that the value specified for this field should be followed by the delimiter (SOH) character as all fields are terminated with an "SOH".

month-year

char field representing month of a year in YYYYMM format

Valid values:

YYYY = 0000-9999, MM = 01-12.

day-of-month

int field representing a particular day of a month.

Valid values:

1-31.

Sequence Numbers

All FIX messages are identified by a unique sequence number. Sequence numbers are initialized at the start of each FIX session (see Session Protocol section) starting at 1 (one) and increment throughout the session. Monitoring sequence numbers will enable parties to identify and react to missed messages and to gracefully synchronize applications when reconnecting during a FIX session.

Each session will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a separate series to monitor for sequence gaps on incoming messages.

Heartbeats

During periods of message inactivity, FIX applications will generate Heartbeat messages at regular time intervals. The heartbeat monitors the status of the communication link and identifies incoming sequence number gaps. The heartbeat interval is declared by the session initiator using the HeartBtInt field in the Logon message. The heartbeat interval timer should be reset after every message is transmitted (not just heartbeats).

Ordered Message Processing

The FIX protocol assumes complete ordered delivery of messages between parties. Implementers should consider this when designing message gap fill processes. Two options exist for dealing with gaps, either request all messages subsequent to the last message received or ask for the specific message missed while maintaining an ordered list of all newer messages. For example, if the receiver misses the second of five messages, the application could ignore messages 3 through 5 and generate a resend request for messages 2 through 5, or, preferably 2 through 0 (where 0 represents infinity). Another option would involve saving messages 3 through 5 and resending only message 2. In both cases, messages 3 through 5 should not be processed before message 2.

Possible Duplicates

When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate message is generated. The message will be a retransmission (with the same sequence number) of the application data in question with the PossDupFlag included and set to "Y" in the header. It is the receiving application's responsibility to handle the message (i.e. treat as a new message or discard as appropriate). All messages created as the result of a resend request will contain the PossDupFlag field set to “Y”, messages lacking the PossDupFlag field or with the PossDupFlag field set to “N” should be treated as original transmissions. Note: When retransmitting a message with the PossDupFlag set to Y, it is always necessary to recalculate the CheckSum value. The only fields that can change in a possible duplicate message are the CheckSum, OrigSendingTime, SendingTime, BodyLength and PossDupFlag. Fields related to encryption (SecureDataLen and SecureData) may also require recasting.

Possible Resends

Ambiguous application level messages may be resent with the PossResend flag set. This is useful when an order remains unacknowledged for an inordinate length of time and the end-user suspects it had never been sent. The receiving application must recognize this flag and interrogate internal fields (order number, etc.) to determine if this order has been previously received. Note: The possible resend message will contain exactly the same body data but will have the PossResend flag and will have a new sequence number. In addition the CheckSum field will require recalculation and fields related to encryption (SecureDataLen and SecureData) may also require recasting.

Data Integrity

The integrity of message data content can be verified in two ways: verification of message length and a simple checksum of characters.

The message length is indicated in the BodyLength field and is verified by counting the number of characters in the message following the BodyLength field up to, and including, the delimiter immediately preceding the CheckSum tag ("10=").

The CheckSum integrity check is calculated by summing the binary value of each character from the “8” of “8=“ up to and including the <SOH> character immediately preceding the CheckSum tag field and comparing the least significant eight bits of the calculated value to the CheckSum value (see Appendix B - CheckSum Calculation for a complete description).

Required Fields

Each message within the protocol is comprised of required, optional and conditionally required (fields which are required based on the presence or value of other fields) fields. Systems should be designed to operate when only the required and conditionally required fields are present.

Message Acknowledgment

The FIX session protocol is based on an optimistic model; normal delivery of data is assumed (i.e. no acknowledgment of individual messages) with errors in delivery identified by message sequence number gaps. Each message is identified by a unique sequence number. It is the receiving application's responsibility to monitor incoming sequence numbers to identify message gaps for response with resend request messages.

The FIX protocol does not support individual message acknowledgment. However, a number of application messages require explicit application level acceptance or rejection. Orders, cancel requests, cancel/replace requests and allocation require specific application level response, executions can be rejected with the DK message but do not require explicit acceptance.

Encryption

The exchange of sensitive data across public carrier networks may make it advisable to employ data encryption techniques to mask the application messages.

The choice of encryption method will be determined by mutual agreement of the two parties involved in the connection.

Any field within a message can be encrypted and included in the SecureData field, however, certain explicitly identified fields must be transmitted unencrypted. The clear (unencrypted) fields can be repeated within the SecureData field to serve as an integrity check of the clear data.

When encryption is employed, it is recommended but not required that all fields within the message body be encrypted. If repeating groups are used within a message and encryption is applied to part of the repeating group, then the entire repeating group must be encrypted.

Embedded in the protocol are fields, which enable the implementation of a public key signature and encryption methodology, straight DES encryption and clear text. The previously agreed upon encryption methodology is declared in the Logon message. (For more detail on implementation of various encryption techniques see the application notes section on the FIX Web Site.)

User Defined Fields

In order to provide maximum flexibility for its users, the FIX protocol accommodates User Defined Fields. These fields are intended to be implemented between consenting trading partners and should be used with caution to avoid conflicts, which will arise as multiple parties begin begin implementation of the protocol. It is suggested that if trading partners find that particular User Defined Fields add value, they should be recommended to the FIX Technical Committee for inclusion in a future FIX version.

The tag numbers 5000 to 9999 have been reserved for use with user defined fields.

The tag numbers 5000 to 9999 have been reserved for use with user defined fields, which are used as part of inter-firm communcation. These tags can be registered/reserved via the FIX website. The tag numbers greater than or equal to 10000 have been reserved for internal use (within a single firm) and do not need to be registered/reserved via the FIX website.

Session Protocol

A FIX session is defined as a bi-directional stream of ordered messages between two parties within a continuous sequence number series. A single FIX session can exist across multiple physical connections. Parties can connect and disconnect multiple times while maintaining a single FIX session. Connecting parties must bi-laterally agree as to when sessions are to be started/stopped based upon individual system and time zone requirements. It is recommended that a new FIX session be established once within each 24 hour period. It is possible to maintain 24 hour connectivity and establish a new set of sequence numbers by sending a Logon message with the ResetSeqNumFlag set.

The FIX session protocol is based on an optimistic model. Normal delivery of data is assumed (i.e. no communication level acknowledgment of individual messages) with errors in delivery identified by message sequence number gaps. This section provides details on the implementation of the FIX session layer and dealing with message sequence gaps.

The following terms are used throughout this section:

Valid FIX Message is a message that is properly formed according to this specification and contains a valid body length and checksum field
Initiator establishes the telecommunications link and initiates the session via transmission of the initial Logon message.
Acceptor is the receiving party of the FIX session. This party has responsibility to perform first level authentication and formally declare the connection request “accepted” through transmission of an acknowledgment Logon message.

A FIX session is comprised of three parts: logon, message exchange and logout.

Logon

Establishing a FIX connection involves three distinct operations: creation of a telecommunications level link, authentication/acceptance of the initiator by the acceptor and message synchronization (initialization). The sequence of connection follows:

The session initiator establishes a telecommunication link with the session acceptor.
The initiator sends a Logon message. The acceptor will authenticate the identity of the initiator by examining the Logon message. The Logon message will contain the data necessary to support the previously agreed upon authentication method. If the initiator is successfully authenticated, the acceptor responds with a Logon message. If authentication fails, the session acceptor should shut down the connection. The session initiator may begin to send messages immediately following the Logon message, however, the acceptor may not be ready to receive them. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established.
The initiator sends a Logon message. The acceptor will authenticate the identity of the initiator by examining the Logon message. The Logon message will contain the data necessary to support the previously agreed upon authentication method. If the initiator is successfully authenticated, the acceptor responds with a Logon message. If authentication fails, the session acceptor should shut down the connection. The session initiator may begin to send messages immediately following the Logon message, however, the acceptor may not be ready to receive them. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established.
After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon message. Depending on the encryption method being used for that session, this Logon message may or may not contain the same session encryption key. The initiator side will use the Logon message being returned from the acceptor as confirmation that a FIX session has been established. If the session acceptor has chosen to change the session encryption key, the session initiator must send a third Logon back to the other side in order to acknowledge the key change request. This also allows the session acceptor to know when the session initiator has started to encrypt using the new session key. Both parties are responsible for infinite loop detection and prevention during this phase of the session.
After authentication, the initiator and acceptor must synchronize their messages through interrogation of the MsgSeqNum field before sending any queued or new messages. A comparison of the MsgSeqNum in the Logon message to the internally monitored next expected sequence number will indicate any message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment Logon message MsgSeqNum to the next expected value. The section on message recovery later in this document deals with message gap handling.
It is recommended to wait a short period of time following the Logon or to send a TestRequest and wait for a response to it before sending queued or new messages in order to allow both sides to handle resend request processing. Failure to do this could result in a ResendRequest message being issued by one’s counterparty for each queued or new message sent.
It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, ... which can result in many resent PossDupFlag=Y messages.
When using the ResetSeqNumFlag to maintain 24 hour connectivity and establish a new set of sequence numbers, the process should be as follows. Both sides should agree on a reset time and the party that will be the initiator of the process. Note that the initiator of the ResetSeqNum process may be different than the initiator of the Logon process. One side will initiate the process by sending a TestRequest and wait for a Heartbeat in response to ensure of no sequence number gaps. Once the Heartbeat has been received, the initiator should send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this point new messages from either side should continue with MsgSeqNum of 2. It should be noted that once the initiator sends the Logon with the ResetSeqNumFlag set, the acceptor must obey this request and the message with the last sequence number transmitted “yesterday” may no longer be available.

Message Exchange

After completion of the initialization process, normal message exchange begins. The formats for all valid messages are detailed in the sections 'Administrative Messages' and 'Application Messages'.

Logout

Normal termination of the message exchange session will be completed via the exchange of Logout messages. Termination by other means should be considered an abnormal condition and dealt with as an error. Session termination without receiving a Logout should treat the counterparty as logged out.

It is recommended that before sending the Logout message, a TestRequest should be issued to force a Heartbeat from the other side. This helps to ensure that there are no sequence number gaps.

Before actually closing the session, the Logout initiator should wait for the opposite side to respond with a confirming Logout message. This gives the acceptor a chance to perform any Gap Fill operations that may be necessary. Once the messages from the ResendRequest have been received, the acceptor should issue the Logout. The session may be terminated if the acceptor does not respond in an appropriate timeframe.

Note: Logging out does not affect the state of any orders. All active orders will continue to be eligible for execution after logout.

Message Recovery

During initialization, or in the middle of a FIX session, message gaps may occur which are detected via the tracking of incoming sequence numbers. The following section provides details on how to recover messages.

As previously stated, each FIX participant must maintain two sequence numbers for each FIX session, one each for incoming and outgoing messages which are initialized at ‘1’ at the beginning of the FIX session. Each message is assigned a unique (by connection) sequence number, which is incremented after each message. Likewise, every message received has a unique sequence number and the incoming sequence counter is incremented after each message.

When the incoming sequence number does not match the expected number corrective processing is required. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. If the incoming sequence number is greater than expected, it indicates that messages were missed and retransmission of the messages is requested via the Resend Request (see the earlier section, Ordered Message Processing.

When the incoming sequence number does not match the expected number corrective processing is required. Note that the SeqReset-Reset message is an exception to this rule as it should be processed without regards to its MsgSeqNum. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. If the incoming sequence number is greater than expected, it indicates that messages were missed and retransmission of the messages is requested via the Resend Request (see the earlier section, Ordered Message Processing.

Note: For the purposes of the following paragraphs requester refers to the party requesting the resend and resender refers to the party responding to the request. The process of resending and synchronizing messages is referred as “gap filling”.

Upon receipt of a Resend Request, the resender can respond in one of three ways:

retransmit the requested messages (in order) with the original sequence numbers and PossDupFlag set to “Y”
issue a SeqReset-GapFill with PossDupFlag set to “Y” message to replace the retransmission of administrative and application messages
issue a SeqReset-Reset with PossDupFlag set to “Y” to force sequence number synchronization

During the gap fill process, certain administrative messages should not be retransmitted. Instead, a special SeqReset-GapFill message is generated. The administrative messages which are not to be resent are: Logon, Logout, ResendRequest, Heartbeat, TestRequest and SeqReset-Reset and SeqReset-GapFill. The SeqReset-GapFill can also be used to skip application messages that the sender chooses not to retransmit (e.g. aged orders). This leaves Reject as the only administrative message- which can be resent.

All FIX implementations must monitor incoming messages to detect inadvertently retransmitted administrative messages (PossDupFlag flag set indicating a resend). When received, these messages should be processed for sequence number integrity only; the business/application processing of these message should be skipped (e.g. do not initiate gap fill processing based on a resent ResendRequest).

If there are consecutive administrative messages to be resent, it is suggested that only one SeqReset-GapFill message be sent in their place. The sequence number of the SeqReset-GapFill message is the next expected outbound sequence number. The NewSeqNo field of the GapFill message contains the sequence number of the highest administrative message in this group plus 1. For example, during a Resend operation there are 7 sequential administrative messages waiting to be resent. They start with sequence number 9 and end with sequence number 15. Instead of transmitting 7 Gap Fill messages (which is perfectly legal, but not network friendly), a SeqReset-GapFill message may be sent. The sequence number of the Gap Fill message is set to 9 because the remote side is expecting that as the next next sequence number. The NewSeqNo field of the GapFill message contains the number 16, because that will be the sequence number of the next message to be transmitted.

Sequence number checking is a vital part of FIX session management. However, a discrepancy in the sequence number stream is handled differently for certain classes of FIX messages. The table below lists the actions to be taken when the incoming sequence number is greater than the expected incoming sequence number.

NOTE: In *ALL* cases except the Sequence Reset - Reset message, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag is not set. A Logout message with some descriptive text should be sent to the other side before closing the session.

Response by Message Type

Message Type	Action to Be Taken on Sequence # mismatch
Logon	Must always be the first message transmitted. Authenticate and accept the connection. After sending a Logon confirmation back, send a ResendRequest if a message gap was detected in the Logon sequence number.
Logout	If a message gap was detected, issue a ResendRequest to retrieve all missing messages followed by a Logout message which serves as a confirmation of the logout request. DO NOT terminate the session. The initiator of the Logout sequence has responsibility to terminate the session. This allows the Logout initiator to respond to any ResendRequest message. If this side was the initiator of the Logout sequence, then this is a Logout confirmation and the session should be immediately terminated upon receipt. The only exception to the “do not terminate the session” rule is for an invalid Logon attempt. The session acceptor has the right to send a Logout message and terminate the session immediately. This minimizes the threat of unauthorized connection attempts.
ResendRequest	Perform the Resend processing first, followed by a ResendRequest of your own in order to fill the incoming message gap.
SeqReset-Reset	Ignore the incoming sequence number. The NewSeqNo field of the SeqReset message will contain the sequence number of the next message to be transmitted.
SeqReset-GapFill	Send a ResendRequest back. Gap Fill messages behave similar to a SeqReset message. However, it is important to insure that no messages have been inadvertently skipped over. This means that GapFill messages must be received in sequence. An out of sequence GapFill is an abnormal condition
All Other Messages	Perform Gap Fill operations.

Standard Message Header

Each administrative or application message is preceded by a standard header. The header identifies the message type, length, destination, sequence number, origination point and time.

TTwo fields help with resending messages. The PossDupFlag is set to Y when resending a message as the result of a session level event (i.e. the retransmission of a message reusing a sequence number). The PossResend is set to Y when reissuing a message with a new sequence number (e.g. resending an order). The receiving application should process these messages as follows:

PossDupFlag—if a message with this sequence number has been previously received, ignore message, if not, process normally.
PossResend—forward message to application and determine if previously received (i.e. verify order id and parameters).

The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when using a single point-to-point FIX session between two firms. Assumption (A=sellside, B =buyside):

	SenderCompID	OnBehalfOfCompID	TargetCompID	DeliverToCompID
A to B directly	A		B
B to A directly	B		A

The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when using a single FIX session to represent multiple firms. Assumption (A=sellside, B and C=buyside, Q=third party):

		SenderCompID	OnBehalfOfCompID	TargetCompID	DeliverToCompID	OnBeahlfOfSendingTime
Send from A to B via Q
1)	A sends to Q	A		Q	B
2)	Q sends to B	Q	A	B		A’s SendingTime
B responds to A via Q
1)	B sends to Q	B		Q	A
2)	Q sends to A	Q	B	A		B’s SendingTime
Send from A to B *AND* C via Q
1)	A sends to Q	A		Q	B
2)	Q sends to B	Q	A	B		A’s SendingTime
3)	A sends to Q	A		Q	C
4)	Q sends to C	Q	A	C		A’s SendingTime
B *AND* C send to A via Q
1)	B sends to Q	B		Q	A
2)	Q sends to A	Q	B	A		B’s SendingTime
3)	C sends to Q	C		Q	A
4)	Q sends to A	Q	C	A		C’s SendingTime

Standard Message Trailer

Each message, administrative or application, is terminated by a standard trailer. The trailer is used to segregate messages and contains the three digit character representation of the Checksum value.

Administrative Messages

The administrative messages address the utility needs of the protocol. The following section describes each message and provides the message layout.

Administrative messages will be generated from both sides of the connection.

Heartbeat

The Heartbeat monitors the status of the communication link and identifies when the last of a string of messages was not received.

When either end of a FIX connection has not sent any data for [HeartBtInt] seconds, it will transmit a Heartbeat message. When either end of the connection has not received any data for (HeartBtInt + “some reasonable transmission time”) seconds, it will transmit a Test Request message. If there is still no Heartbeat message received after (HeartBtInt + “some reasonable transmission time”) seconds then the connection should be considered lost and corrective action be initiated. If HeartBtInt is set to zero then no regular heartbeat messages will be generated. Note that a test request message can still be sent independent of the value of the HeartBtInt, which will force a Heartbeat message.

Heartbeats issued as the result of Test Request must contain the TestReqID transmitted in the Test Request message. This is useful to verify that the Heartbeat is the result of the Test Request and not as the result of a regular timeout.

Logon

The logon message authenticates a user establishing a connection to a remote system. The logon message must be the first message sent by the application requesting to initiate a FIX session.

The HeartBtInt (108) field is used to declare the timeout interval for generating heartbeats.

Upon receipt of a Logon message, the session acceptor will authenticate the party requesting connection and issue a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can also be used by the initiator to validate that the connection was established with the correct party.

The session acceptor must be prepared to immediately begin processing messages after receipt of the Logon. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon, however it is recommended that normal message delivery wait until after the return Logon is received to accommodate encryption key negotiation.

The confirmation Logon can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a Logon message with a new key. This is only valid for encryption protocols that allow for key negotiation. (See the FIX Web Site’s Application notes for more information on a method for encryption and key passing.)

The Logon message can be used to specify the MaxMessageSize supported (e.g. can be used to control fragmentation rules for very large messages which support fragmentation). It can also be used to specify the MsgTypes supported for both sending and receiving.

Test Request

The test request message forces a heartbeat from the opposing application. The test request message checks sequence numbers or verifies communication line status. The opposite application responds to the Test Request with a Heartbeat containing the TestReqID.

The TestReqID verifies that the opposite application is generating the heartbeat as the result of Test Request and not a normal timeout. The opposite application includes the TestReqID in the resulting Heartbeat. Any string can be used as the TestReqID (one suggestion is to use a timestamp string).

Resend Request

The resend request is sent by the receiving application to initiate the retransmission of messages. This function is utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process.

The resend request can be used to request a single message, a range of messages or all messages subsequent to a particular message.

Note: the sending application may wish to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Reset-GapFill message is used to skip messages that a sender does not wish to resend.)

Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.

To request a single message: BeginSeqNo = EndSeqNo
To request a range of messages: BeginSeqNo = first message of range, EndSeqNo = last message of range
To request all messages subsequent to a particular message: BeginSeqNo = first message of range, EndSeqNo = 0 (represents infinity) .

Reject

The reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&) which successfully passes de-encryption, CheckSum and BodyLength checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.

Rejected messages should be logged and the incoming sequence number incremented.

Note: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop which may be encountered in this situation.

Generation and receipt of a Reject message indicates a serious error that may be the result of faulty logic in either the sending or receiving application.

If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number.

Whenever possible, it is strongly recommended that the cause of the failure be described in the Text field (e.g. INVALID DATA - FIELD 35).

If an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific “reject” messages, which should be used. All others can be rejected at a business-level via the Business Message Reject message. See the Business Message Reject message

Note that in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a Business Message Reject with BusinessRejectReason = “Application not available at this time” should be issued.

Scenarios for session-level Reject:

`SessionRejectReason`
0 = Invalid tag number
1 = Required tag missing
2 = Tag not defined for this message type
3 = Undefined Tag
4 = Tag specified without a value
5 = Value is incorrect (out of range) for this tag
6 = Incorrect data format for value
7 = Decryption problem
8 = Signature problem
9 = CompID problem
10 = SendingTime accuracy problem
11 = Invalid MsgType
(Note other session-level rule violations may exist in which case SessionRejectReason is not specified)

Sequence Reset (Gap Fill)

The sequence reset message is used by the sending application to reset the incoming sequence number on the opposing side. The sequence reset message can be used in the following situations:

During normal resend processing, the sending application may choose not to send a message (e.g. an aged order). The Sequence Reset can be used to mark the place of that message.
During normal resend processing, a number of administrative messages are not resent, the Sequence Reset message is used to fill the sequence gap created.
In the event of an application failure, it may be necessary to force synchronization of sequence numbers on the sending and receiving sides

The sending application will initiate the sequence reset. The message in all situations specifies NewSeqNo to reset as the value of the next sequence number to be transmitted.

If the GapFillFlag field is not present (or set to N), it can be assumed that the purpose of the sequence reset message is to recover from an out-of-sequence condition. The MsgSeqNum in the header should be ignored (i.e. the receipt of a sequence reset message with an out of sequence MsgSeqNum should not generate resend requests).

If the GapFillFlag field is present (and equal to Y), the MsgSeqNum should conform to standard message sequencing rules (i.e. the MsgSeqNum of the SequenceReset-GapFill message should represent the beginning MsgSeqNum in the GapFill range because the remote side is expecting that next message).

The sequence reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request may appear as SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, and message 10. This could then followed by SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum is less than expected. If so, the SeqReset-GapFill is a duplicate and should be discarded.

Logout

The logout message initiates or confirms the termination of a FIX session. Disconnection without the exchange of logout messages should be interpreted as an abnormal condition.

Before actually closing the session, the logout initiator should wait for the opposite side to respond with a confirming logout message. This gives the remote end a chance to perform any Gap Fill operations that may be necessary. The session may be terminated if the remote side does not respond in an appropriate timeframe.

The logout initiator should not send any messages after the logout.

Application Messages

The exchange of business related information is accomplished through the passing of application messages. The application message is composed of the standard header followed by the message body and trailer.

Descriptions and formats of the specific messages follow.

Advertisement messages are used to announce completed transactions. The advertisement message can be transmitted in various transaction types; NEW, CANCEL and REPLACE. All message types other than NEW modify the state of a previously transmitted advertisement identified in AdvRefID.

Indications of Interest

Indication of interest messages market merchandise which the broker is buying or selling in either a proprietary or agency capacity. The indications can be time bound with a specific expiration value. Indications are distributed with the understanding that other firms may react to the message first and that the merchandise may no longer be available due to prior trade.

Indication messages can be transmitted in various transaction types; NEW, CANCEL, and REPLACE. All message types other than NEW modify the state of the message identified in IOIRefID.

News

The news message is a general free format message between the broker and institution. The message contains flags to identify the news item's urgency and to allow sorting by subject company (symbol). The News message can be originated at either the broker or institution side.

Email

The email message is similar to the format and purpose of to the News message, however, it is intended for private use between two parties.

Quote Request

In some markets it is the practice to request quotes from brokers prior to placement of an order. The quote request message is used for this purpose.

Quotes can be requested on specific securities or forex rates.

Securities quotes can be requested as either market quotes or for a specific quantity and side. If OrderQty and Side are absent, a market-style quote (bid x offer, size x size) will be returned.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
- Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
- e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
- CCY1 and CCY2 are ISO currency codes
The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
See Appendix O – Foreign Exchange Trading
Forex quotes can be requested as indicative or at a specific quantity level. If an indicative quote is requested (OrderQty and Side are absent), the broker has discretion to quote at either a specific trade level and side or to provide an indicative quote at the mid-point of the spread. The broker can also choose to respond to an indicative quote by sending multiple quote messages specifying various levels and sides.

Quote

The quote message is used as the response to a Quote Request message and can be used to publish unsolicited quotes.

Quotes supplied as the result of a Quote Request message are tagged with the appropriate QuoteReqID, unsolicited quotes can be identified by the absence of a QuoteReqID.

The symbol used for forex quotes is, in ISO codes, “currency1.currency2” (e.g. GBP.USD) and the quote will be returned as a rate expressed as currency1/currency2. BidPx indicates the rate at which the broker is willing to buy currency1 and deliver currency2, OfferPx indicates the rate at which the broker is willing to sell currency1 and receive currency2. Indicative rates are quoted in the BidPx field and may contain a level in the BidSize field.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
- Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
- e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
- CCY1 and CCY2 are ISO currency codes
The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
See Appendix O – Foreign Exchange Trading

Orders can be generated based on Quotes. Quoted orders include the QuoteID and are OrdType=Previously Quoted or Forex - Previously Quoted.

Example: Quote for Single Security
QuoteID=XXX
QuoteReqID=YYY
Symbol=AA
MaturyMonthYear=199901
StrikePrice=25.00
PutOrCall=1
BixPx=5.00
OfferPx=5.25
BidSize=10
OfferSize=10

Mass Quote

The Mass Quote message can contain quotes for multiple securities to support applications that allow for the mass quoting of an option series. Two levels of repeating groups have been provided to minimize the amount of data required to submit a set of quotes for a class of options (e.g. all option series for IBM).

A QuoteSet specifies the first level of repeating tags for the Mass Quote message. It represents a group of related quotes and can, for example, represent an option class.

Each QuoteSet contains an optional repeating group of QuoteEntries which can represent an option series.

It is possible the number of Quote Entries for a Quote Set (option class) could exceed one’s physical or practical message size. It may be necessary to fragment a message across multiple quote messages. Message size limits must be mutually agreed to with one’s counterparties.

The grouping of quotes is as follows:

NoQuoteSets – specifies the number of sets of quotes contained in the message
- QuoteSetID – Is a unique ID given to the quote set
- Information regarding the security to which all of the quotes belong
- TotQuoteEntries – defines the number of quotes for the quote set across all messages
- NoQuoteEntries – defines the number of quotes contained within this message for this quote set
  - QuoteEntryID – Is a unique ID given to a specific quote entry
  - Information regarding the specific quote (bid/ask size and price)

If there are too many Quote Entries for a Quote Set to fit into one physical message, then the quotes can be continued in another Mass Quote message by repeating all of the QuoteSet information and then specifying the number of Quote Entries (related symbols) in the continued message. The TotQuoteEntries is provided to optionally indicate to the counterparty the total number of Quote Entries for a Quote Set in multiple quote messages. This permits, but does not require, a receiving application to react in a stateful manner where it can determine if it has received all quotes for a Quote Set before carrying out some action. However, the overall approach to fragmentation is to permit each mass quote message to be processed in a stateless manner as it is received. Each mass quote message should contain enough information to have the Quote Entries applied to a market without requiring the next message if fragmentation has occurred. Also, a continued message should not require any information from the previous message.

Maximum message size for fragmentation purposes can be determined by using the optional MaxMessageSize field in the Logon message or by mutual agreement between counterparties.

Requesting Acknowledgement for Mass Quotes

Applications can optionally support acknowledgement of quotes using the QuoteResponseLevel tag. The QuoteResponseLevel is used to specify the level of acknowledgement requested from the counterparty. A QuoteResponseLevel of 0 indicates that no acknowledgement is requested. A ResponseLevel of 1 requests acknowledgement of invalid or erroneous quotes. A QuoteResponseLevel of 2 requests acknowledgement of each Mass Quote message.

See Appendix H: Mass Quote Message Scenarios

Notes on usage for Options Markets:

It is assumed that for many options markets, the Mass Quote message will be used to generate quotes in high volumes in an unsolicited manner. This means that multiple quotes will be sent to the counterparty (an exchange) without acknowledgement. The Mass Quote message can be used to send quotes for multiple classes, each with multiple series.

Example: Multiple Option Series for a single Option Class (No Fragmentation)

QuoteID=XXX
QuoteReqID=YYY
NoQuoteSets=1
- QuoteSetID=1
- Symbol=AA
- TotQuoteEntries=2
- NoQuoteEntries=2
- Other quote set fields
- QuoteEntryID=1
  - MaturyMonthYear=199901
  - StrikePrice=25.00
  - PutOrCall=1
  - BixPx=5.00
  - OfferPx=5.25
  - BidSize=10
  - OfferSize=10
- QuoteEntryID=2
  - MaturyMonthYear=199901
  - StrikePrice=30.00
  - PutOrCall=1
  - BixPx=3.00
  - OfferPx=3.25
  - BidSize=10
  - OfferSize=10

Example: Multiple Option Series for a single Option Class (Fragmentation)

First Message:

QuoteID=XXX
QuoteReqID=YYY
NoQuoteSets=1
- QuoteSetID=1
- Symbol=AA
- TotQuoteEntries=3
- NoQuoteEntries=2
- Other quote set fields
- QuoteEntryID=1
  - MaturyMonthYear=199901
  - StrikePrice=25.00
  - PutOrCall=1
  - BixPx=5.00
  - OfferPx=5.25
  - BidSize=10
  - OfferSize=10
- QuoteEntryID=2
  - MaturyMonthYear=199901
  - StrikePrice=30.00
  - PutOrCall=1
  - BixPx=3.00
  - OfferPx=3.25
  - BidSize=10
  - OfferSize=10

Second Message:

QuoteID=XXX
QuoteReqID=YYY
NoQuoteSets=1
- QuoteSetID=1
- Symbol=AA
- Other quote set fields
- TotQuoteEntries=3
- NoQuoteEntries=1
- QuoteEntryID=3
  - MaturyMonthYear=199901
  - StrikePrice=35.00
  - PutOrCall=1
  - BixPx=2.00
  - OfferPx=2.25
  - BidSize=10
  - OfferSize=10

Quote Cancel

The Quote Cancel message is used by an originator of quotes to cancel quotes.

The Quote Cancel message supports cancelation of:

All quotes
Quotes for a specific symbol or security ID
All quotes for a security type
All quotes for an underlying

Canceling a Quote is acccomplished by indicating the type of cancelation in the QuoteCancelType field.

The Quote Cancelation only applies to quotes made by the current FIX user.

Options usage notes:

Normal usage would be to cancel the quotes for a symbol. This is the reason that the use of further nesting similar to the quote is not used in this message. You are able to cancel quotes for specific series by specifying each option series in the repeating group.

It is recommended that all Cancel messages be acknowledged using the Quote Acknowledgement message

Quote Status Request

The quote status request message is used by the institution to generate an execution report that contains the quote status message back from the counterparty. It is used to retrieve the status of the originating party’s quotes and not to obtain market data information.

Quote Acknowledgement

An optional response to Quote, Mass Quote, Quote Cancel, and Quote Request message is the Quote Acknowledgement message. The use of the Quote Acknowledgement message is optional per Quote, Mass Quote, or Quote Request message. It is intended to provide application level acknowledgement of quotes. The level of response requested from a receiver of the Quote Acknowledgement message is specified in the QuoteResponseLevel tag.

Market Data Request

Some systems allow the transmission of real-time quote, order, trade and/or other price information on a subscription basis. A Market Data Request is a general request for market data on specific securities or forex quotes.

A successful Market Data Request returns one or more Market Data messages containing one or more Market Data Entries. Each Market Data Entry is a Bid, an Offer, a Trade associated with a security, the opening, closing, or settlement price of a security, the value of an index, or the trading session high price, low price, or VWAP. Market Data Entries have a price and usually a quantity associated with them. For example, in an order book environment, requesting just the top of book will result in only two active Market Data Entries at a time – one for the best Bid and one for the best Offer. For a full book, the Bid and Offer side may each have several Market Data Entries. Each Market Data Entry might represent an aggregate for each price tier, and only one Market Data Entry per side per price would be active at a time. This is referred to as an Aggregated book. Or several Market Data Entries at one price tier could each represent a broker, Market Maker, ECN or Exchange’s quote in a security, or individual orders in a book. This is a Non-Aggregated book. Alternately, a Market Data Entry could represent a completed trade in a security, the value of an index, the opening, closing, or settlement price of an instrument, or the trading session high price, low price, or VWAP.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
CCY1 and CCY2 are ISO currency codes
The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
See Appendix O – Foreign Exchange Trading

A Snapshot causes the current state of the market to be sent. A Snapshot + Updates causes the current state of the market to be sent, and any updates as they occur, until the client requests that the Snapshot + Updates be disabled.

When just a Snapshot is requested, the complete data for only one security or forex quote will be returned per FIX Market Data message.

When Snapshot + Updates is requested, updates may be full or incremental:

Full Refresh. This mode is optimized to trade off increased bandwidth for simplicity in processing and is intended for requests on only a few instruments. Each FIX Market Data message in response to the request will contain the complete data requested for one instrument. If more than just the top of book is requested, this means that both sides, and all price tiers, must be reported in that Market Data message.
Incremental Refresh. This mode is optimized for handling requests for many instruments while conserving bandwidth. Each Market Data Entry is assigned an MDEntryID unique among all other active entries, and several incremental updates of entries for different instruments can be included in one FIX Market Data message.

One specifies whether a list of trades, a 1-sided or 2-sided book, index, opening, closing, settlement, high, low and VWAP prices should be returned by using the NoMDEntryTypes field and MDEntryType repeating group to list all MDEntryType values that should be returned.

While this document specifies many parameters and modes in a request, the recipient of the request is not required to support all of them. A Market Data Request Reject may be sent in response to a request indicating that it cannot be honored.

Market Data – Snapshot / Full Refresh

The Market Data messages are used as the response to a Market Data Request message. In all cases, one Market Data message refers only to one Market Data Request. It can be used to transmit a 2-sided book of orders or list of quotes, a list of trades, index values, opening, closing, settlement, high, low, or VWAP prices, or any combination of these.

Market Data messages sent as the result of a Market Data Request message are tagged with the appropriate MDReqID. Unsolicited Market Data messages can be sent; in such cases, MDReqID will not be present.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
CCY1 and CCY2 are ISO currency codes
The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
See Appendix O – Foreign Exchange Trading

Market Data messages include many fields, and not all are required to be used. A firm may, at its option, choose to send the minimum fields required, or may choose to send more information, such as tick direction, tagging of best quotes, etc.

Market Data messages can take two forms. The first Market Data message format used for a Snapshot, or a Snapshot + Updates where MDUpdateType = Full Refresh (0) is as follows:

For Market Data Requests where a Bid or Offer is added, changed, or deleted, every update to a Market Data Entry results in a new Market Data message that contains the entirety of the data requested for that instrument, not just the changed Market Data Entry. In other words, both sides of the market, or just one side in the case of a request of only bids or offers, for the depth requested, must be sent in one FIX Market Data message.
A Market Data message may contain several trades, an index value, opening, closing, settlement, high, low, and/or VWAP price for one instrument, but only one instrument per message.
Messages containing bids and/or offers cannot contain trades, index value, opening, closing, settlement, high, low, and/or VWAP prices.

Market Data – Incremental Refresh

The second Market Data message format is used for incremental updates. Market Data Entries may have an MDEntryID unique among all currently active Market Data Entries so they can be referenced for the purposes of deleting and changing them later. When changing a Market Data Entry, it may keep the same MDEntryID, in which case only MDEntryID would be populated, or the MDEntryID may change, in which case MDEntryID will contain the new ID, and MDEntryRefID will contain the ID of the Market Data Entry being changed. An MDEntryID can be reused within a day only if it has first been deleted.

Alternately, in the case of displaying the best quotes of Market Makers or Exchanges, and not orders in an order book, MDEntryID can be omitted for simplification. In this case, a New Market Data Entry will replace the previous best quote for that side and symbol for the specified Market Maker or Exchange. Deletion of a Market Data Entry would not specify an MDEntryID or MDRefID, and would remove the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange. A Change of a Market Data Entry would not specify an MDEntryID or MDRefID, and would replace the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange.

The Market Data message for incremental updates may contain any combination of new, changed, or deleted Market Data Entries, for any combination of instruments, with any combination of trades, quotes, index values, open, close, settlement, high, low, and VWAP prices, so long as the maximum FIX message size is not exceeded. All of these types of Market Data Entries can be changed and deleted.

Adding, Changing, or Deleting Market Data Entries requires special consideration of the MDEntryPositionNo field, if the sender wishes to specify it and the receiver wishes to process it. For example, assume ten bids for a security. Adding a bid with MDEntryPositionNo = 4 requires the receiver to shift down other Market Data Entries, i.e. the Market Data Entry in the 4th display position will shift to the 5th, the 5th shifts to the 6th, etc. until the 10th shifts to the 11th. The sender must NOT send a modification of all MDEntries in the 4th through 10th positions just to update the MDEntryPositionNo field; the recipient must infer the change. Similarly, deleting a Market Data Entry in the 7th position causes the 8th Market Data Entry to move into the 7th position, the 9th to shift into the 8th position, etc. A Change of the MDEntryPositionNo field of a Market Data Entry causes the Market Data Entries lying between the old and new positions to shift. For instance, a Market Data Entry that occupied the 5th position is changed to the 8th position. This means that the Market Data Entry in the 6th position shifts up to the 5th position, the 7th position shifts to the 6th, and what was in the 8th position shifts into the 7th to make room for the changed Market Data Entry that is being moved into the 8th position.

Several techniques are employed to conserve bandwidth:

An instrument only needs to be identified when a Market Data Entry is first created.
In cases where the identification of an instrument is long, the sender has the option of referring to a previous active Market Data Entry of the same instrument instead of duplicating the information.
A new Market Data Entry will default to the same instrument of the previous Market Data Entry in the same Market Data message if neither Symbol nor MDEntryRefID are specified.
In the case of a change in a Market Data Entry, only the fields changing need to be sent as part of the change to the Market Data Entry; for example, a change of the MDEntrySize but not the MDEntryPx or other attributes of the Market Data Entry only requires listing the MDEntrySize field, in addition to MDUpdateAction and MDEntryID if used in the original Market Data Entry
When creating a new Market Data Entry with a future or option instrument similar to the instrument in the previous Market Data Entry in the same FIX message, one may send just symbol identification fields that have changed, such as MaturityMonthYear, MaturityDay, PutOrCall, StrikePrice, OptAttribute, and SecurityExchange.
MDEntryID can be reused within the same day after it is deleted. This is helpful for distributing order books because an order that is suspended and then reinstated can have its MDEntryID deleted upon suspension and later reused, with MDUpdateAction = New(0) upon reinstatement, thus avoiding having to re-map the MDEntryID.

Market Data Request Reject

The Market Data Request Reject is used when the broker cannot honor the Market Data Request, due to business or technical reasons. Brokers may choose to limit various parameters, such as the size of requests, whether just the top of book or the entire book may be displayed, and whether Full or Incremental updates must be used.

Security Definition Request

The Security Definition Request message is used for the following:

Request a specific Security to be traded with the second party. The request security can be defined as a complex security made up of one or more underlying securities.
Request a list of the Security Types that can be traded with the second party.
Request a list of Securities that can be traded with the second party. This request can optionally be qualified with Symbol, TradingSessionID, SecurityExchange, and Security Type.

See Appendix I: Security Definition, Security Status, and Trading Session Message Scenarios

Security Definition

The Security Definition message is used for the following:

Accept the security defined in a Security Definition message.
Accept the security defined in a Security Definition message with changes to the definition and/or identity of the security.
Reject the security requested in a Security Definition message
Return a list of Security Types
Return a list of Securities

Security Status Request

The Security Status Request message provides for the ability to request the status of a security. One or more Security Status messages are returned as a result of a Security Status Request message.

The Security Status Request message contains a SubscriptionRequestType field. This tells the counter party what type of request is being made:

0 – indicates that the requestor only wants a snapshot or the current status.
1 – indicates that the requestor wants a snapshot (the current status) plus updates as the status changes. This is similar to subscribing for information and can be implemented in applications as a subscription mechanism.
2 – indicates that the requestor wishes to cancel any pending snapshots or updates – in essence making this an unsubscribe operation.

Security Status

The Security Status message provides for the ability to report changes in status to a security. The Security Status message contains fields to indicate trading status, corporate actions, financial status of the company. The Security Status message is used by one trading entity (for instance an exchange) to report changes in the state of a security.

It is expected that the Security Status message that is sent as a response should indicate what type of request is being provided. If the message is being generated as a result of a RequestType =1, then the response should have a RequestType=1 to permit the requestor to determine why the message was sent.

Trading Session Status Request

The Trading Session Status Request is used to request information on the status of a market. With the move to multiple sessions occurring for a given trading party (morning and evening sessions for instance) there is a need to be able to provide information on what product is trading on what market.

The Trading Session Status Request message can be used to inquire the trading status of a trading party. The Trading Session Status message can be used to subscribe to updates to the status of a trading session by setting the RequestType field to 1.

To list the securities available during a particular trading session, see the SecurityDefinitionRequest message.

Trading Session Status

The Trading Session Status provides information on the status of a market. With the move to multiple sessions occurring for a given trading party (morning and evening sessions for instance) there is a need to be able to provide information on what product is trading on what market.

The Trading Session Status can provide an optional repeating group of securities that are available for trading during that session.

New Order - Single

The new order message type is used by institutions wishing to electronically submit securities and forex orders to a broker for execution.

Orders can be submitted with special handling instructions and execution instructions. Handling instructions refer to how the broker should handle the order on its trading floor (see HandlInst field). Execution instructions contain explicit directions as to how the order should be executed (see ExecInst field).

New Order messages received with the PossResend flag set in the header should be validated by ClOrdID and order parameters (side, symbol, quantity, etc.) to determine if the order had been previously submitted. PossResends previously received should be acknowledged back to the client via an Execution - Status message. PossResends not previously received should be processed as a new order and acknowledged via an Execution - New message.

The value specified in the TransactTime field should allow the receiver of the order to apply business rules to determine if the order is potentially "stale" (e.g. in the event that there have been communication problems). To support forex accommodation trades, two fields, ForexReq and SettlCurrency, are included in the message. To request a broker to execute a forex trade in conjunction with the securities trade, the institution would set the ForexReq = Y and SettlCurrency = “intended settlement currency”. The broker would then execute a forex trade from the execution currency to the settlement currency and report the results via the execution message in the SettlCurrAmt and SettlCurrency fields.

The order message can also be used to request a straight forex trade. Conventions for identifying a forex transaction are as follows:

The forex Symbol is defined in "EBS" (Electronic Banking System) format: "CCY1/CCY2".
Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
(e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
CCY1 and CCY2 are ISO currency codes
The value of the Currency field represents the denomination of the quantity fields (e.g. JPY represents quantity of JPY).
In the case of a Forex - Swap (buying (or selling) a currency at one value date and selling (or buying) the same currency at a different value date), Side should represent the side of the FutSettDate2 transaction.
OrdType = Forex - Market, Forex - Limit, Forex- Swap, or Forex - Previously Quoted
Netting can be specified via the ExecInst field.
See Appendix O – Foreign Exchange Trading

Orders involving or requiring Pre-Trade Allocation consist of the following steps:

Buyside sends a New Order request message specifying one or more AllocAccount and AllocShares values within the repeating group designated by NoAllocs.
Sellside sends Execution Report messages for the “New” and resulting fills.
Post-Trade Allocation messaging takes place

To “take” an IOI (or Quote) from an ECN or exchange and not display the order on the book, the New Order message should contain the TimeInForce field with ImmediateOrCancel and an OrdType field with Previously Indicated ( or Previously Quoted).

The presence of DiscretionInst on an order indicates that the trader wishes to display one price but will accept trades at another price. For example a sell order with OrdType = Limit, Price=50.00, DiscretionInst = Related to displayed price and DiscretionOffset = -0.25 means that the order should be displayed as an offer for 50.00, but will match any bid >= 49.75 Discretionary pricing can also be used when pegging an order - for example to indicate that a buy order is to be displayed as pegged to the bid minus 0.25, but can be matched by anything <= the offer, set OrdType=Pegged, ExecInst = Primary Peg, PegDifference = -0.25, DiscretionInst = Related to market price and DiscretionOffset = 0.

See Appendix D: Order State Change Matrices

Execution Reports

The execution report message is used to:

confirm the receipt of an order
confirm changes to an existing order (i.e. accept cancel and replace requests)
relay order status information
relay fill information on working orders
reject orders
report post-trade fees calculations associated with a trade

NOTE: Execution reports do not replace the end-of-day confirm. Execution reports are to be regarded only as replacements for the existing fill messages currently communicated via telephone.

Each execution report contains three fields which are used to communicate both the current state of the order as understood by the broker and the purpose of the message: OrdStatus, ExecType and ExecTransType.

In an execution report the OrdStatus is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus field. The order statuses are as follows (in highest to lowest precedence):

Precedence	OrdStatus	Description
12	Pending Cancel	Order with an Order Cancel Request pending, used to confirm receipt of an Order Cancel Request. DOES NOT INDICATE THAT THE ORDER HAS BEEN CANCELED.
11	Pending Replace	Order with an Order Cancel/Replace Request pending, used to confirm receipt of an Order Cancel/Replace Request. DOES NOT INDICATE THAT THE ORDER HAS BEEN REPLACED.
10	Done for Day	Order not, or partially, filled; no further executions forthcoming for the trading day
9	Calculated	Order has been completed for the day (either filled or done for day). Commission or currency settlement details have been calculated and reported in this execution message
8	Filled	Order completely filled, no remaining quantity
7	Stopped	Order has been stopped at the exchange. Used when guranteeing or protecting a price and quantity
6	Suspended	Order has been placed in suspended state at the request of the client.
5	Canceled	Canceled order with or without executions
5	Expired	Order has been canceled in broker’s system due to time in force instructions.
4	Partially Filled	Outstanding order with executions and remaining quantity
3	Replaced	Replaced order with or without executions
2	New	Outstanding order with no executions
2	Rejected	Order has been rejected by broker. NOTE: An order can be rejected subsequent to order acknowledgment, i.e. an order can pass from New to Rejected status.
2	Pending New	Order has been received by brokers system but not yet accepted for execution. An execution message with this status will only be sent in response to a Status Request message.
1	Accepted for bidding	Order has been received and is being evaluated for pricing. It is anticipated that this status will only be used with the “Disclosed” BidType List Order Trading model.

The ExecType is used to identify the purpose of the execution report message. To transmit a change in OrdStatus for an order, the broker(sell side) should send an Execution Report with the new OrdStatus value in both the ExecType AND the OrdStatus fields to signify this message is changing the state of the order. The only exception to this rule is that when rejecting a cancel or cancel/replace request the CancelReject message is used both to reject the request and to communicate the current OrdStatus. An ExecType of Pending Cancel or Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. An ExecType of Canceled or Replace is used to indicate that the cancel or cancel/replace request has been successfully processed.

Execution information (e.g. new partial fill or complete fill) should not be communicated in the same report as one which communicates other state changes (such as pending cancel, pending replace, canceled, replaced, accepted, done for day etc).

Any fills which occur and need to be communicated to the customer while an order is “pending” and waiting to achieve a new state (i.e. via a Order Cancel Replace (aka Order Modification) Request) must contain the “original” (current order prior to state change request) order parameters (i.e. ClOrdID, OrderQty, Price, etc). These fills will cause the CumQty and AvgPx to be updated. An order cannot be considered replaced until it has been explicitly accepted and confirmed to have reached the replaced status via an execution report with ExecType = ‘Replace’, at which time the effect of the replacement (ClOrdID, new quantity or limit price etc) will be seen. Note that due to the precedence rules above, in reports where ExecType=Replace, OrdStatus may not = Replaced.

Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. Requests to replace the OrderQty to a level less than the CumQty will be interpreted by the broker as requests to stop executing the order. Requests to change price on a filled order will be rejected (see Order Cancel Reject message type). The OrderQty, CumQty, LeavesQty, and AvgPx fields should be calculated to reflect the cumulative result of all versions of an order. For example, if partially filled order A were replaced by order B, the OrderQty, CumQty, LeavesQty, and AvgPx on order B’s fills should represent the cumulative result of order A plus those on order B.

The general rule is: OrderQty = CumQty + LeavesQty.

There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0.

Execution report messages are transmitted with a transaction type (ExecTransType) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID, and are used to cancel or correct a previously reported execution. Transaction type STATUS indicates that the execution message contains no new information, only summary information regarding order status.

The NEW transaction type indicates that this message represents a new order, a change in status of the order, or a new fill against an existing order. The combination of the ExecTransType, ExecType, and OrdStatus fields will indicate how the message is to be applied to an order.

The CANCEL transaction type applies at the execution level. The Cancel transaction will be used to cancel an execution which has been reported in error. The canceled execution will be identified in the ExecRefID field. Note: ExecTransType of Cancel should not be used to cancel a previous ExecutionRpt with ExecTransType of Cancel (e.g. cannot cancel a cancel).

The CORRECT transaction type applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the ExecRefID field. If a single execution is corrected more than once, ExecRefID should refer to the ExecID of the last corrected ExecutionRpt (same convention as ClOrdID and OrigClOrdID). To correct an ExecutionRpt which was previously canceled, an ExecutionRpt with ExecTransType=New should be sent (e.g. cannot send ExecTransType=Correct for an ExecutionRpt with ExecTransType=Cancel). Note: Data reported in the CumQty, LeavesQty, and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

See Appendix D: Order State Change Matrices for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects.

An ExecutionRpt with ExecType = Restated represents an ExecutionRpt sent by the sellside communicating a change in the order or a restatement of the order’s parameters without an electronic request from the customer. ExecRestatementReason must be set. This is used for GT orders and corporate actions (see below), changes communicated verbally to the sellside either due to normal business practices or as an emergency measure when electronic systems are not available, repricing of orders by the sellside (such as making Sell Short orders compliant with uptick / downtick rules), or other reasons (Broker option). ExecRestatementReason can also be used to communicate unsolicited cancels.

The field ClOrdID is provided for institutions to affix an identification number to an order to coincide with internal systems. The OrderID field is populated with the broker-generated order number. Unlike ClOrdID/OrigClOrdID which requires a chaining through Cancel/Replaces and Cancels, OrderID and SecondaryOrderID are not required to change through changes to an order.

The underlying business assumption of orders that can trade over multiple days, such as GTC and Good Till Date orders expiring on a future trading date (henceforth referred to as GT orders) is that a GT order that is not fully executed and has not been canceled and has not expired on a given day remains good for the broker to execute the following day. Note that the concept of day is determined by the market convention, which will be security specific. At the end of each trading day, once the order is no longer subject to execution, the broker may optionally send an Execution Report with ExecType=Done for Day(3). When the ExpireDate or ExpireTime of a Good Till Date order is reached, or a GTC order reaches a maximum age, the order is considered expired and the broker may optionally send an Execution Report with ExecType and OrdStatus=Expired(C).

In handling GT orders, the OrderQty, CumQty and AvgPx fields will represent the entirety of the order over all days. The fields DayOrderQty, DayCumQty, and DayAvgPx can be used on days following the day of the first trade on a GT order. Prior to the start of business each day, for all GT orders that have partial fills on previous days, DayCumQty and DayAvgPx are set to zero, and DayOrderQty becomes the LeavesQty. The following relationship holds: DayOrderQty = OrderQty – (CumQty – DayCumQty). Since (CumQty – DayCumQty) represents the volume traded on all previous days, DayOrderQty = OrderQty – Volume traded on all previous days. Note that when changing the quantity of an order, both OrderQty and DayOrderQty will change. Requests to change or cancel an order will be made in terms of the total quantity for the order, not the quantity open today. For example, on an order where OrderQty=10000 and 2000 shares trade during the previous days, a request to change OrderQty to 15000 will mean that 13000 shares will be open. See Appendix D – Order State Change Matrices for examples of canceling and changing GT orders partially filled on previous days.

A Cancel on an execution (trade bust) happening the same day of the trade will result in CumQty and DayCumQty each decreasing by the quantity busted, and LeavesQty increasing by the quantity busted. OrderQty and DayOrderQty will remain unchanged. If the business rules allow for a trade bust to be reported on a later date than the trade being busted, the OrderQty and DayCumQty will remain unchanged, the LeavesQty and DayOrderQty will increase by the quantity busted, and the CumQty will decrease by the quantity busted.

If bilaterally agreed between counterparties, a broker may wish to transmit a list of all open GT orders, permitting reconciliation of the open orders. Typically this transmission may occur at the end of the trading day or at the start of the following trading day. There is no expected response to such retransmission; in the event of a reconciliation problem this should be resolved manually or via the DK message. Assuming no corporate actions have occurred, the broker will send an Execution Report with ExecType = Restated (D) and ExecRestatementReason = GT renewal / restatement (no corporate action) (1) for each open GT order. These Execution Reports may have DayCumQty and DayAvgPx restated to zero, and DayOrderQty restated to LeavesQty if the transmission occurs at the start of the following business day. The broker has the option of changing the OrderID and SecondaryOrderID fields, or leaving them unchanged. If they are changed, then the buy-side should use these new ID fields when sending Order Cancel Request, Order Cancel/Replace Request, and Order Status Request messages.

In the case of a corporate action resulting in the adjustment of an open GT order, the broker will send an Execution Report with ExecType = Restated (D) and ExecRestatementReason = GT Corporate action (0) with the order’s state after the corporate action adjustment. In the case of stock splits, OrderQty, CumQty, AvgPx, and LeavesQty will be adjusted to reflect the order’s state in terms of current shares, not pre-split shares. See Appendix D – Order State Change Matrices for examples of GT order restatement with and without a corporate action.

Don’t Know Trade

The Don’t Know Trade (DK) message notifies a trading partner that an electronically received execution has been rejected. This message can be thought of as an execution reject message.

This message has special utility when dealing with one-way execution reporting. If the initial Order Acknowledgment message (LastShares=0 and OrdStatus=New) does not match an existing order this message can be used to notify the broker of a potential problem order.

Note that the decision to DK an execution lies with the institution. Some of the mismatches listed in the DKReason field may be acceptable and will not require a DK messages to be generated.

Order Cancel/Replace Request

The order cancel/replace request is used to change the parameters of an existing order.

Do not use this message to cancel the remaining quantity of an outstanding order, use the Cancel Request message for this purpose.

Cancel/Replace will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.) It can be used to re-open a filled order by increasing OrderQty.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Replace be sent unless the Order Cancel/Replace Request can be immediately accepted (ExecutionRpt with ExecType=Replaced) or rejected (Order Cancel Reject message).

The Cancel/Replace request will only be accepted if the order can successfully be pulled back from the exchange floor without executing. Requests which cannot be processed will be rejected using the Cancel Reject message. The Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification.

Note that while it is necessary for the ClOrdID to change and be unique, the broker’s OrderID field does not necessarily have to change as a result of the Cancel/Replace request.

Only a limited number of fields can be changed via the cancel/replace request message. All other fields should be retransmitted as sent in the original order. The fields which can be changed via this message are:

`ExecInst`	`ExpireDate`	`OrderQty2`
`OrderQty`	`ExpireTime`	`OpenClose`
`OrdType`	`MinQty`	`CoveredOrUncovered`
`Price`	`MaxFloor`	`Side (i.e. sell to sell plus)`
`HandlInst`	`StopPx`	`MaxShow`
`TimeInForce`	`PegDifference`	`LocateReqd`
`TradingSessionID`	`DiscretionInst`
`EffectiveTime`	`DiscretionOffset`
	`CashOrderQty`

When modifying ExecInst fields in a replacement order, it is necessary to re-declare all ExecInst in the replacement order. ExecInst’s will not be carried forward from the original order to the replacement unless re-declared.

Order Cancel Request

The order cancel request message requests the cancelation of all of the remaining quantity of an existing order. Note that the Order Cancel/Replace Request should be used to partially cancel (reduce) an order).

The request will only be accepted if the order can successfully be pulled back from the exchange floor without executing.

A cancel request is assigned a ClOrdID and is treated as a separate entity. If rejected, the ClOrdID of the cancel request will be sent in the Cancel Reject message, as well as the ClOrdID of the actual order in the OrigClOrdID field. The ClOrdID assigned to the cancel request must be unique amongst the ClOrdID assigned to regular orders and replacement orders.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Cancel be sent unless the Order Cancel Request can be immediately accepted (ExecutionRpt with ExecType=Canceled) or rejected (Order Cancel Reject message).

Order Cancel Reject

The order cancel reject message is issued by the broker upon receipt of a cancel request or cancel/replace request message which cannot be honored. Requests to change price or decrease quantity are executed only when an outstanding quantity exists. Filled orders cannot be changed (i.e quantity reduced or price change. However, the broker/sellside may support increasing the order quantity on a currently filled order).

When rejecting a Cancel/Replace Request, the Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification

The execution message responds to accepted cancel request and cancel/replace request messages.

Order Status Request

The order status request message is used by the institution to generate an order status message back from the broker.

Allocation

The Allocation message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. It can also be used as a confirmation message through which third parties can communicate execution and settlement details between trading partners. In addition, the allocation message can be sent by the broker to communicate fees and other details that can only be computed once the sub-account breakdowns are known.

Allocation is typically communicated Post-Trade (after fills have been received and processed). It can, however, also be communicated Pre-Trade (at the time the order is being placed) to specify the account(s) and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities.

An allocation message can be submitted as preliminary, calculated, calculated without preliminary, new, cancel or replace. The AllocTransType field indicates the purpose of the message. When submitting calculated, replace, or cancel AllocTransType messages the RefAllocID field is required. Replacement allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique AllocID and use RefAllocID to specify the AllocID from the preliminary. Calculated without preliminary are sent unsolicited from the sellside and do not require RefAllocID.

The allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown below in typeface Bold-Italic and indented with the 🡪 symbol. The field’s relative position in the message is important. For example, each instance of allocation must be in the order shown below.

The total shares allocated must equal the Shares value which must equal the total executed quantity of the original order. If present, the total shares in the execution section must also be equal to this value.
The number of sub-account instances is indicated in NoAllocs.
Multiple orders can be combined for allocation by identifying the number of orders in the NoOrders field and each individual order in the OrderID fields. Combined orders must have the same ticker, trade date, settlement date and side.

Pre-Trade Allocation consists of the following steps:

Buyside sends a New Order request message specifying one or more AllocAccount and AllocShares values within the repeating group designated by NoAllocs.
Sellside sends Execution Report messages for the “New” and resulting fills.
Post-Trade Allocation messaging takes place

Post-Trade Allocation can be computed via one of two methods:

Using Average Price: Each AllocAccount has a single AllocAvgPx
Using Executed Price: Combination of each AllocAccount and AllocPrice (unique LastPx) (e.g. Japan)

Post-Trade Allocation supports three different message flows:

Buyside initiated without Misc Fees
Buyside-initiated with Misc Fee computation
Sellside-initiated

See Appendix K: Example Usage of Allocations for more examples and details.

Allocation ACK

The allocation ACK message is used to acknowledge the receipt and status of an allocation message received from the institution.

It is possible that multiple Allocation ACK messages can be generated for a single allocation to detail the receipt and then the acceptance or rejection of the allocation.

Settlement Instructions

The Settlement Instructions message provides either the broker’s or the institution’s instructions for trade settlement. The SettlInstSource field indicates if the settlement instructions are the broker’s or the institution’s. This message has been designed so that it can be sent from the broker to the institution, from the institution to the broker, or from either to an independent “standing instructions” database or matching system.

The Settlement Instructions message can be used in one of two modes (SettlInstMode):

To provide “standing instructions” for the settlement of trades occurring in the future, messages should include some combination of.

AllocAccount
LastMkt
Side
SecurityType
SettlLocation
SettlDeliveryType
EffectiveTime

To provide settlement instructions for a specific Allocation Account either as overriding or standing instructions to support matching. The following key should be used to tie the settlement instructions to the corresponding Allocation message.
(TradeDate + AllocID + AllocAccount)

The Settlement Instruction detail can be either explicitly specified (via SecuritySettl* and CashSettl* fields) or can exist on within an independent standing instructions database and can be referenced via the StandInstDbType, StandInstDbName, and StandInstDbID fields.

Bid Request

The BidRequest Message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention (e.g. US/European model) the BidRequest message can be used to request a bid based on the sector, country, index and liquidity information contained within the message itself. In the “Non disclosed” convention the entry repeating group is used to define liquidity of the program. See Appendix N – Program/Basket/List Trading for an example.

In the “Disclosed” convention (e.g. Japanese model) the BidRequest message can be used to request bids based on the ListOrderDetail messages sent in advance of BidRequest message. In the “Disclosed” convention the list repeating group is used to define which ListOrderDetail messages a bid is being sort for and the directions of the required bids.

The pair of fields SideValue1 and SideValue2 are used to show the monetary total value in either direction (buy or sell) of the transaction without revealing whether it is the buy-side institution intention to buy or sell.

The two repeating groups, NoEntries and NoBidComponents are mutually exclusive and a function of which bidding model is being used. If the “Non Disclosure” method is being used the portfolio of stocks being traded is described by a number of “bid desciptors” entries. If the “Disclosure” Method is being used the portfolio is fully disclosed, except for side, by a number of “list” entries enumerating the lists that list the stocks to be traded.

A BidRequest message with BidRequestTransType cancel may be used to indicate to sell side firms that they no longer need to store details of the BidRequest as they have either lost the bid or the List has been canceled.

Bid Response

The Bid Response message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention the Bid Response message can be used to supply a bid based on the sector, country, index and liquidity information contained within the corresponding bid request message. See Appendix N – Program/Basket/List Trading for an example.

In the “Disclosed” convention the Bid Response message can be used to supply bids based on the List Order Detail messages sent in advance of the corresponding Bid Request message.

New Order - List

The NewOrderList Message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention the New Order - List message is sent after the bidding process has been completed, by telephone or electronically. The New Order - List message enumerates the stocks, quantities, direction for the trade and may contain pre-allocation information.

This message may also be used as the first message for the transmission of a program trade where the bidding process has been done by means other than FIX. In this scenario the messages may either be used as a staging process, in which case the broker will start execution once either a ListExecute is received or for immediate execution, in which case the orders will be executed on receipt.

In the “Disclosed” convention the New Order - List message is sent before the bidding process is started, by telephone or electronically. The New Order - List message enumerates the stocks and quantities from the bidding process, and may contain pre-allocation information. The direction of the trade is disclosed after the bidding process is completed.

See Appendix N – Program/Basket/List Trading for an example.

List Strike Price

The strike price message is used to exchange strike price information for principal trades. It can also be used to exchange reference prices for agency trades.

List Status

The list status message is issued as the response to a List Status Request message sent in an unsolicited fashion by the sell-side. It indicates the current state of the orders within the list as they exists at the broker's site.

Orders within the list are statused at the summary level. Individual executions are not reported, rather, the current state of the order is reported.

The message contains repeating fields for each. The relative position of the repeating fields is important in this message, i.e. each instance of ClOrdID, CumQty, LeavesQty, CxlQty and AvgPx must be in the order shown below.

Description of ListOrderStatus field values:

“InBiddingProcess”: indicates that a list has been received and is being evalutated for pricing. It is envisaged that this status will only be used with the "Disclosed" List Order Trading model.
“ReceivedForExecution”: indicates that a list has been received and the sell side is awaiting the instruction to start working the trade. It is envisaged that this status will be used under both models.
“Executing”: indicates that a list has been received and the sell side is working it.
“Canceling”: indicates that a List Cancel Message has been received and the sell side is in the process of pulling any orders that were being worked. The status of individual order can be found out from the detail repeating group.
“AllDone”: indicates that a list has been executed as far as possible for the day.
“Alert”: used whenever any of the individual orders have a status that requires something to be done. For instance alert would be used when a buy-side firm has submitted a list that has individual stock reject that have not been addressed.
“Rejected” used when a response cannot be generated. For example when the ListID is not recognised. The text field should include an explanation of why the Request s been rejected.

List Execute

The list execute message type is used by institutions to instruct the broker to begin execution of a previously submitted list. This message may or may not be used, as it may be mirroring a phone conversation.

List Cancel Request

The list cancel request message type is used by institutions wishing to cancel previously submitted lists either before or during execution.

After the list has been staged with the broker, it can be canceled via the submission of the List Cancel message. If the list has not yet been submitted for execution, the List Cancel message will instruct the broker not to execute it, if the list is being executed, the List Cancel message should trigger the broker's system to generate cancel requests for the remaining quantities of each order within the list. Individual orders within the list can be canceled via the Order Cancel Request message.

List Status Request

The list status request message type is used by institutions to instruct the broker to generate status messages for a list.

Fragmentation for List Order Messages

The messages used in program trading support fragmentation for the same reason and in the same way as some other FIX messages (e.g. Mass Quote). If there are too many entries within a repeating group to fit into one physical message, then the entries can be continued in another message by repeating all of the top level information and then specifying the number of entries in the continued message. A “Total Entries” field is provided to specify the total number of entries in a repeating group which is split over multiple messages. This permits, but does not require, a receiving application to react in a stateful manner where it can determine if it has received all entries in a repeating group before carrying out some action. However, the overall approach to fragmentation is to permit each message to be processed in a stateless manner as it is received. Each message should contain enough information to have the entries applied to a system without requiring the next message if fragmentation has occurred. Also, a continued message should not require any information from the previous message. The messages that support fragmentation and the repeating groups supporting it are listed in the table below.

Message	“Total Entries” field	Repeating group that may be fragmented
New Order - List	`TotNoOrders`	Orders repeating group following the NoOrders field in the message definition table
List Strike Price	`TotNoStrikes`	Strike price repeating group following the NoStrikes field in the message definition table
List Status	`TotNoOrders`	Status per order repeating group following the NoOrders field in the message definition table

Maximum message size for fragmentation purposes can be determined by using the optional MaxMessageSize field in the Logon message or by mutual agreement between counterparties.

Note: The TotNoOrders field has been added to the List Status message to support fragmentation in same way as other FIX messages. The NoRpts and Rpt``Seq fields are preserved to backwards compatibility with previous versions of FIX which supported a stateful form of fragmentation.

Business Message Reject

The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.

See the session-level Reject message

It should NOT be used in the following situations:

Session-level problem meeting the criteria of the session-level Reject message	Use the session-level Reject message (MsgType=3)
In response to New Order - Single Order Status Request New Order - List List Execute	Use the Execution Report message
In response to: Order Cancel Request Order Cancel/Replace Request List Cancel Request	Use the Order Cancel Reject message
In response to: Execution Report	Use the Don’t Know Trade (DK) message
In response to: Allocation	Use the Allocation ACK message
In response to: List Status Request	Use the List Status message
In response to: Quote Request Quote Mass Quote Quote Cancel Quote Status Request	Use the Quote Acknowledgment message
In response to: Market Data Request	Use the Market Data Request Reject message
In response to: Security Definition Request	Use the Security Definition message
In response to: Security Status Request	Use the Security Status message
In response to: Trading Session Status Request	Use the Trading Session Status message

Note the only exception to this rule is in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system. In this situation a Business Message Reject with BusinessRejectReason = “Application not available at this time” can be issued if the the system is unable to send the specific “reject” message listed above due to this condition.

Messages which can be referenced via the Business Message Reject message are:

(the “ID” field BusinessRejectRefID refers to noted in [ ])

Indication of Interest (IOI) [IOIid]
Advertisement [AdvId]
News [Headline]
Email [EmailThreadID]
Order Cancel Reject [ClOrdID]
Allocation ACK [AllocID]
List Status [ListID]
Don’t Know Trade (DK) – may respond with Order Cancel Reject if attempting to cancel order [ExecID]
Settlement Instructions [SettlInstID]
Market Data-Snapshot/Full Refresh [MDReqID]
Market Data-Incremental Refresh [MDReqID]
Market Data Request Reject [MDReqID]
Quote Acknowledgment [QuoteID]
Security Definition [SecurityResponseID]
Security Status [SecurityStatusReqID]
Trading Session Status [TradSesReqID]

Scenarios for Business Message Reject:

`BusinessRejectReason`
0 = Other 1 = Unknown ID 2 = Unknown Security 3 = Unsupported Message Type (receive a valid, but unsupported `MsgType`) 4 = Application not available 5 = Conditionally Required Field Missing

Whenever possible, it is strongly recommended that the cause of the failure be described in the Text field (e.g. “UNKNOWN SYBMOL: XYZ”).

Appendix A

Valid Currency Codes

Currency codes used in FIX are those defined in ISO 4217 standard. To obtain the current valid list please contact the ISO 4217 secretariat at +44-181-996-9000.

Note: Prices defined in FIX messages should be made consistent with the currency code used. In some markets, prices are quoted as multiples or fractions of the currency, FIX messages should normalize the amount to coincide with the indicated code (e.g. UK securities are quoted in pence but must be represented in FIX messages as pounds).

Appendix B

CheckSum Calculation

The checksum of a FIX message is calculated by summing every byte of the message up to but not including the checksum field itself. This checksum is then transformed into a modulo 256 number for transmission and comparison. The checksum is calculated after all encryption is completed, i.e. the message as transmitted between parties is processed.

For transmission, the checksum must be sent as printable characters, so the checksum is transformed into three ASCII digits.

For example, if the checksum has been calculated to be 274 then the modulo 256 value is 18 (256 + 18 = 274). This value would be transmitted a |10=018| where "10=" is the tag for the checksum field.

A sample code fragment to generate the checksum field is as follows:

  
  char *GenerateCheckSum( char *buf, long bufLen )    
  {
    static char tmpBuf[ 4 ];
    long idx;
    unsigned int cks;
  
    for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );
    sprintf( tmpBuf, "%03d", (unsigned int)( cks % 256 ) );
    return( tmpBuf );
  }

Appendix C

Reuters Exchange Mnemonics

Exchanges A–L

Exchange	Mnemonic
Alberta Stock Exchange	AL
American Stock Exchange	A
Amman Stock Exchange	AM
Amsterdam Stock Exchange	AS
Australian Stock Exchange	AX
Bahrain Stock Exchange	BH
Basle Stock Exchange	BS
Barcelona Stock Exchange – Floor Trading	BC
Barcelona Stock Exchange – CATS Feed	MC
Belfox	b
Berlin Stock Exchange	BE
Berne Stock Exchange	BN
Bologna Stock Exchange	BL
Bombay Stock Exchange	BO
Bordeaux Stock Exchange	BD
Boston Stock Exchange	B
Bremen Stock Exchange	BM
Brussels Stock Exchange	BR
Chicago Board Options Exchange	W
Cincinnati Stock Exchange	C
Colombo Stock Exchange	CM
Copenhagen Stock Exchange	CO
Deutsche Terminboerse (DTB)	d
Dusseldorf Stock Exchange	D
European Options Exchange	E
Florence Stock Exchange	FL
Frankfurt Stock Exchange	F
Fukuoka Stock Exchange	FU
Geneva Stock Exchange	G
Genoa Stock Exchange	GE
Hamburg Stock Exchange	H
Hanover Stock Exchange	HA
Helsinki Stock Exchange	HE
Hiroshima Stock Exchange	HI
Hong Kong Stock Exchange	HK
Integrated Bourse Trading and Information System (IBIS)	IB
Interbolsa (Portugal)	IN
Istanbul Stock Exchange	IS
Jakarta Stock Exchange	JK
Japanese Securities Dealers Association	Q
Johannesburg Stock Exchange	J
Karachi Stock Exchange	KA
Korea Stock Exchange	KS
Kuala Lumpur Stock Exchange	KL
Kyoto Stock Exchange	KY
Lagos Stock Exchange	LG
Lausanne Stock Exchange	LA
Le Nouveau Marche	LN
Lille Stock Exchange	LI
Lisbon Stock Exchange (Portugal)	LS
London Stock Exchange	L
Luxembourg Stock Exchange	LU
Lyon Stock Exchange	LY

Exchanges M–Z

Exchange	Mnemonic
Madrid Stock Exchange – Floor Trading	MA
Madrid Stock Exchange – CATS Feed	MC
Marseille Stock Exchange	MS
MATIS	MT
MEFF Renta Variable	I
Mexican Stock Exchange	MX
Midwest Stock Exchange	MW
Milan Stock Exchange	MI
MONEP Paris Stock Options	p
Montreal Exchange	M
Munich Stock Exchange	MU
Muscat Stock Exchange	OM
Nancy Stock Exchange	NC
Nagoya Stock Exchange	NG
Nairobi Stock Exchange	NR
Nantes Stock Exchange	NT
Naples Stock Exchange	NA
NASDAQ	O
NASDAQ Dealers – International	OI
NASDAQ Dealers – Bulletin Board	OB
New York Stock Exchange	N
New Zealand Stock Exchange	NZ
Niigata Stock Exchange	NI
Osaka Stock Exchange	OS
Oslo Stock Exchange	OL
Pacific Stock Exchange	P
Palermo Stock Exchange	PL
Paris Stock Exchange	PA
Philadelphia Stock Exchange	PH
Philadelphia Stock Exchange – Options	X
Rome Stock Exchange	RO
Sao Paulo Stock Exchange	SA
Sapporo Stock Exchange	SP
Singapore Stock Exchange	SI
Shanghai Stock Exchange	SS
Shenzhen Stock Exchange	SZ
Stockholm Options Market	o
Stockholm Stock Exchange	ST
Stuttgart Stock Exchange	SG
Swiss Options and Financial Futures Exchange (SOFFEX)	Z
Taiwan Stock Exchange	TW
Tel Aviv Stock Exchange	TA
Thailand Stock Exchange	BK
Third Market	TH
Tokyo Stock Exchange	T
Toronto Options Exchange	K
Toronto Stock Exchange	TO
Tradepoint Stock Exchange	TP
Trieste Stock Exchange	TR
Tunis Stock Exchange	TN
Turin Stock Exchange	TU
Vancouver Stock Exchange	V
Venice Stock Exchange	VE
Vienna Stock Exchange	VI
Zimbabwe Stock Exchange	ZI
Zurich Stock Exchange	Z

Other

Exchange	Numeric Value
None	0
American Stock Exchange Options	1
Chicago Mercantile Exchange (CME)	2
London International Financial Futures Exchange (LIFFE)	3
POSIT	4
London Traded Options Market	5
Montreal Exchange Options (MOE)	6
New York Stock Exchange Options (NYO)	7
Pacific Stock Exchange Options (PAO)	8
Vancouver Options Exchange (VAO)	9
NYSE BBSS (broker booth system)	10
Non-exchange-based Over The Counter Market	11

Appendix D

Order State Change Matrices

The following matrices are included to clarify the sequence of messages and the status of orders involved in the submission and processing of new orders, executions, cancel requests, cancel/replace requests and order status requests. The matrices have been arranged in groups as follows:

Ref	Group	Description
D1	Vanilla	Filled order
D2	Vanilla	Part-filled day order, done for day
D3	Cancel	Cancel request issued for a zero-filled order
D4	Cancel	Cancel request issued for a part-filled order – executions occur whilst cancel request is active
D5	Cancel	Cancel request issued for an order that becomes filled before cancel request can be accepted
D6	Replace to increase qty	Zero-filled order, cancel/replace request issued to increase order qty
D7	Replace to increase qty	Part-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace
D8	Replace to increase qty	Filled-order followed by cancel/replace request to increase order quantity
D9	Replace not for qty change	Cancel/replace request (not for quantity change) is rejected as a fill has occurred
D10	Replace to decrease qty	Cancel/replace request sent whilst execution is being reported – the requested order qty exceeds the cum qty . Order is replaced then filled
D11	Replace to decrease qty	Cancel/replace request sent whilst execution is being reported – the requested order qty equals the cum qty – order qty is amended to cum qty
D12	Replace to decrease qty	Cancel/replace request sent whilst execution is being reported – the requested order qty is below cum qty – order qty is amended to cum qty
D13	Replace - sequence	One cancel/replace request is issued which is accepted – another one is issued which is also accepted
D14	Replace - sequence	One cancel/replace request is issued which is rejected before order becomes pending replace – then another one is issued which is accepted
D15	Replace - sequence	One cancel/replace request is issued which is rejected after it is in pending replace – then another one is issued which is accepted
D16	Replace - chaining	One cancel/replace request is issued followed immediately by another – broker processes sequentially
D17	Replace - chaining	One cancel/replace request is issued followed immediately by another – broker rejects the second as order is pending replace
D18	Unsolicited reports	Telephoned order
D19	Unsolicited reports	Unsolicited cancellation of a part-filled order
D20	Unsolicited reports	Unsolicited replacement of a part-filled order
D21	Unsolicited reports	Unsolicited reduction of order quantity by sell side
D22	Order reject	Order rejected due to duplicate ClOrdID
D23	Order reject	Order rejected because the order has already been verbally submitted
D24	Status	Order status request rejected for unknown order
D25	Status	Status request followed by "Nothing done".
D26	Status	Order sent, immediately followed by a status request. Subsequent status requests sent
D27	GT	GTC order partially filled, restated (renewed) and partially filled the following day
D28	GT	GTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day
D29	GT	GTC order partially filled, restated(renewed) and canceled the following day
D30	GT	GTC order partially filled, restated(renewed) followed by replace request to increase quantity
D31	Resend	Poss resend
D32	TIF	Fill or kill order that cannot be filled
D33	TIF	Immediate or Cancel order that cannot be immediately hit
D34	Execution correct/cancel	Filled order, followed by correction and cancellation of executions
D35	Execution correct/cancel	A cancel of a partially filled order followed by an execution cancel(bust) and new execution.
D36	Execution correct/cancel	GTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions.
D37	Stopped/Guarantee	A stopped (execution price guarantee) report followed by execution.

The Table below shows which state transitions have been illustrated by the matrices in this Appendix (marked with an asterisk). The row represents the current value of OrdStatus and the column represents the next value as reported back to the buy-side via an execution report or order cancel reject message. Next to each OrdStatus value is its precedence – this is used when the order exists in a number of states simultaneously to determine the value that should be reported back. Note that absence of a scenario should not necessarily be interpreted as meaning that the state transition is not allowed:

OrdStatus (precedence value)	New (2)	Partially Filled (4)	Filled (8)	Done For Day (10)	Pending Cancel (12)	Pending Replace (11)	Replaced (3)	Canceled (5)	Rejected (2)	Stopped (7)
Pending New (2)	*								*
New (2)	*	*	*	*	*	*	*		*	*
Partially Filled (4)		*	*	*	*	*		*
Filled (8)		*	*			*
Done for Day (10)		*
Pending Cancel (12)	*	*	*		*			*
Pending Replace (11)	*	*	*			*	*	*
Replaced (3)		*
Canceled (5)
Rejected (2)
Stopped (7)		*

How to read the Order State Change Matrices:

The ‘Execution Report’ message is referred to simply as ‘Execution’
The ‘Order Cancel/Replace Request’ and ‘Order Cancel Request’ messages are referred to as ‘Replace Request’ and ‘Cancel Request’ respectively
The shaded rows represent messages sent from buy-side to the sell-side
In general where two lines of a matrix share the same time, this means either
- that there are two possible paths (e.g. a request is accepted or rejected) – in this case the first row of the two possible paths is the reject case which is italicized. The non-italicized row is the path that is continued by the remainder of the matrix
- that two messages are being sent at the same time but in different directions such that the messages cross on the connection (e.g. a cancel request is sent at the same time as the sell-side is sending an execution) – in this case both lines have bold text
For scenarios involving cancel requests or cancel/replace requests ‘ X’ refers to the original order, ‘Y’ refers to the cancel/replacing order. A similar convention is used for corrections or cancels to executions

D1 - Filled order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	Exec Type	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by sales
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by trader/exchange
3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution of 2000
4		Execution(X)	Partial Fill	Partially Filled	New	10000	3000	7000	1000	Execution of 1000
5		Execution(X)	Fill	Filled	New	10000	10000	0	7000	Execution of 7000

D2 - Part-filled day order, done for day

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution of 2000
4		Execution(X)	Partial Fill	Partially Filled	New	10000	3000	7000	1000	Execution of 1000
5		Execution(X)	Done for Day	Done for Day	New	10000	3000	0	0	Assuming day order. See other examples which cover GT orders

D3 - Cancel request issued for a zero-filled order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	New	10000	0	10000	0
3	Cancel Request(Y,X)					10000
4		Cancel Reject (Y,X)		New		10000				If rejected by salesperson
4		Execution (Y,X)	Pending Cancel	Pending Cancel	New	10000	0	10000	0
5		Cancel Reject (Y,X)		New		10000				If rejected by trader/exchange
5		Execution (Y,X)	Canceled	Canceled	New	10000	0	0	0

D4 - Cancel request issued for a part-filled order - executions occur whilst cancel request is active

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution for 2000
4	Cancel Request(Y,X)					10000
4		Execution(X)	Partial Fill	Partially Filled	New	10000	5000	5000	3000	Execution for 3000. This execution passes the cancel request on the connection
5		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected
5		Execution (Y,X)	Pending Cancel	Pending Cancel	New	10000	5000	5000	0	‘Pending cancel’ order status takes precedence over ‘partially filled’ order status
6		Execution(X)	Partial Fill	Pending Cancel	New	10000	6000	4000	1000	Execution for 1000 whilst order is pending cancel – ‘pending cancel’ order status takes precedence over ‘partially filled’ order status
7		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected
7		Execution (Y,X)	Canceled	Canceled	New	10000	6000	0	0	‘Canceled’ order status takes precedence over ‘partially filled’ order status

D5 - Cancel request issued for an order that becomes filled before cancel request can be accepted

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution for 2000
4	Cancel Request(Y,X)					10000
4		Execution(X)	Partial Fill	Partially Filled	New	10000	5000	5000	3000	Execution for 3000. This execution passes the cancel request on the connection
5		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected
5		Execution (Y,X)	Pending Cancel	Pending Cancel	New	10000	5000	5000	0	‘Pending cancel’ order status takes precedence over ‘partially filled’ order status
6		Execution(X)	Fill	Pending Cancel	New	10000	10000	0	5000	Execution for 5000 whilst order is pending cancel. ‘Pending cancel’ order status takes precedence over ‘filled’ order status
7		Cancel Reject (Y,X)		Filled		10000				Cancel request rejected – CxlRejectReason = 0 (too late to cancel)

D6 - Zero-filled order, cancel/replace request issued to increase order qty

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3	Replace Request(Y,X)					11000				Request to increase order qty to 11000
4		Cancel Reject (Y,X)		New		10000				If request is rejected by salesperson
4		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	0	10000	0
5		Cancel Reject (Y,X)		New		10000				If rejected by trader/exchange
5		Execution (Y,X)	Replace	Replaced	New	11000	0	11000	0	‘Replaced’ order status takes precedence over ‘new’ order status
6		Execution (Y)	Partial Fill	Partially Filled	New	11000	1000	10000	1000	Execution for 1000
7		Execution (Y)	Partial Fill	Partially Filled	New	11000	3000	8000	2000	Execution for 2000

D7 - Part-filled order, followed by cancel/replace request to increase order qty, execution occurs whilst order is pending replace

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					12000				Request increase in order quantity to 12000
5		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected
5		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	1000	9000	0	‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6		Execution(X)	Partial Fill	Pending Replace	New	10000	1100	8900	100	Execution for 100 before cancel/replace request is responded to
7		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected
7		Execution (Y,X)	Replace	Partially Filled	New	12000	1100	10900	0	‘Partially filled’’ order status takes precedence over ‘replaced’ order status
8		Execution(Y)	Fill	Filled	New	12000	12000	0	10900	Execution for 10900

D8 - Filled order, followed by cancel/replace request to increase order quantity

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Fill	Filled	New	10000	10000	0	10000	Execution for 10000
4	Replace Request(Y,X)					12000				Request increase in order quantity to 12000
5		Cancel Reject (Y,X)		Filled		10000				If request is rejected
5		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	10000	0	0	‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6		Cancel Reject (Y,X)		Filled		10000				If request is rejected
6		Execution (Y,X)	Replace	Partially Filled	New	12000	10000	2000	0	‘Partially filled’ order status takes precedence over ‘replaced’ order status.
7		Execution(Y)	Fill	Filled	New	12000	12000	0	2000	Execution for 2000

D9 - Cancel/replace request (not for quantity change) is rejected as a fill has occurred

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					10000				Assume in this scenario that client does not wish to increase qty (e.g. client wants to amend limit price)
4		Execution (X)	Fill	Filled	New	10000	10000	0	9000	Execution for 9000 – the replace request message and this execution report pass each other on the connection
5		Cancel Reject (Y,X)		Filled		10000				CxlRejectReason = 0 (too late to cancel)

D10 - Cancel/replace request sent whilst execution is being reported – the requested order qty exceeds the cum qty. Order is replaced then filled

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request a decrease order quantity to 8000 (leaving 7000 open)
4		Execution(X)	Partial Fill	Partially Filled	New	10000	1500	8500	500	Execution for 500 sent. Replace request and this execution report pass each other on the connection
5		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected by salesperson
5		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	1500	8500	0	‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6		Execution(X)	Partial Fill	Pending Replace	New	10000	1600	8400	100	Execution for 100 occurs before cancel/replace request is accepted
7		Cancel Reject (Y,X)		Partially Filled		10000				If request is rejected by trader/exchange
7		Execution (Y,X)	Replace	Partially Filled	New	8000	1600	6400	0	‘Partially filled’ order status takes precedence over ‘replaced’ order status. Replace is accepted as requested order qty exceeds cum qty
8		Execution (Y)	Fill	Filled	New	8000	8000	0	6400	Execution for 6400.

D11 – Cancel/replace request sent whilst execution is being reported – the requested order qty equals the cum qty – order qty is amended to cum qty

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3	Replace Request(Y,X)					7000				Client wishes to amend order qty to 7000 shares
3		Execution(X)	Partial Fill	Partially Filled	New	10000	7000	3000	7000	Execution for 7000 - the replace message and this execution report pass each other on the connection
4		Execution (Y,X)	Replace	Filled	New	7000	7000	0	0	The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’ or ‘replaced’

D12 – Cancel/replace request sent whilst execution is being reported – the requested order qty is below cum qty – order qty is amended to cum qty

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3	Replace Request(Y,X)					7000				Client wishes to amend order qty to 7000 shares
3		Execution(X)	Partial Fill	Partially Filled	New	10000	8000	2000	8000	Execution for 8000 - the replace message and this execution report pass each other on the connection
4		Execution (Y,X)	Replace	Filled	New	8000	8000	0	0	The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’ or ‘replaced’

D13 – One cancel/replace request is issued which is accepted – another one is issued which is also accepted

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request decrease in order quantity to 8000, leaving 7000 open
5		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	1000	9000	0	‘Pending replace’ order status takes precedence over ‘partially filled’ order status
6		Execution(X)	Partial Fill	Pending Replace	New	10000	1500	8500	500	Execution for 500
7		Execution (Y,X)	Replace	Partially Filled	New	8000	1500	6500	0	‘Partially filled’ order status takes precedence over ‘replaced’ order status
8		Execution (Y)	Partial Fill	Partially Filled	New	8000	3500	4500	2000	Execution for 2000
9	Replace Request(Z,Y)					6000				Request decrease in order quantity to 6000, leaving 2500 open
10		Execution (Z,Y)	Pending Replace	Pending Replace	New	8000	3500	4500	0
11		Execution (Z,Y)	Replace	Partially Filled	New	6000	3500	2500	0	‘Partially filled’ order status takes precedence over ‘replaced’ order status
12		Execution(Z)	Fill	Filled	New	6000	6000	0	2500	Execution for 2500

D14 – One cancel/replace request is issued which is rejected before order becomes pending replace – then another one is issued which is accepted

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request decrease in order quantity to 8000, leaving 7000 open
5		Cancel Reject (Y,X)		Partially Filled		10000				Request is rejected
6		Execution(X)	Partial Fill	Partially Filled	New	10000	1500	8500	500	Execution for 500
7		Execution(X)	Partial Fill	Partially Filled	New	10000	3500	6500	2000	Execution for 2000
8	Replace Request(Z,X)					6000				Request decrease in order quantity to 6000, leaving 2500 open. Note that OrigClOrdID = X
9		Execution (Z,X)	Pending Replace	Pending Replace	New	10000	3500	6500	0	Note that OrigClOrdID = X
10		Execution (Z,X)	Replace	Partially Filled	New	6000	3500	2500	0	Note that OrigClOrdID = X
11		Execution(Z)	Partial Fill	Partially Filled	New	6000	5000	1000	1500	Execution for 1500

D15 - One cancel/replace request is issued which is rejected after it is in pending replace - then another one is issued which is accepted

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request decrease in order quantity to 8000, leaving 7000 open
5		Execution (Y,X)	Pending Replace	Pending Replace		10000	1000	9000	0
6		Execution(X)	Partial Fill	Pending Replace	New	10000	1500	8500	500	Execution for 500. ‘Pending replace’ order status takes precedence over ‘partially filled’ order status
7		Cancel Reject (Y,X)		Partially Filled		10000				Request is rejected (e.g. by trader/exchange)
8		Execution(X)	Partial Fill	Partially Filled	New	10000	3500	6500	2000	Execution for 2000
9	Replace Request(Z,X)					6000				Request decrease in order quantity to 6000, leaving 2500 open. Note that OrigClOrdID = X
10		Execution (Z,X)	Pending Replace	Pending Replace	New	10000	3500	6500	0
11		Execution (Z,X)	Replace	Partially Filled	New	6000	3500	2500	0
12		Execution(Z)	Partial Fill	Partially Filled	New	6000	5000	1000	1500	Execution for 1500

D16 - One cancel/replace request is issued followed immediately by another - broker processes sequentially

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request decrease in order quantity to 8000, leaving 7000 open
5	Replace Request(Z,Y)					7000				Request decrease in order quantity to 7000, leaving 6000 open
6		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	1000	9000	0	Broker processes Replace (Y,X) first
7		Execution (Y,X)	Replace	Partially Filled	New	8000	1000	7000	0	Broker processes Replace (Y,X) first
8		Execution (Z,Y)	Pending Replace	Pending Replace	New	8000	1000	7000	0	Broker then processes Replace (Z,Y)
9		Execution (Z,Y)	Replace	Partially Filled	New	7000	1000	6000	0	Broker then processes Replace (Z,Y)
10		Execution(Z)	Fill	Filled	New	7000	7000	0	6000	Execution for 6000

D17 - One cancel/replace request is issued followed immediately by another - broker rejects the second as order is pending replace

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)					8000				Request decrease in order quantity to 8000, leaving 7000 open
5	Replace Request(Z,Y)					7000				Request decrease in order quantity to 7000, leaving 6000 open
6		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	1000	9000	0
7		Cancel Reject (Z,Y)		Pending Replace		10000				Rejected because broker does not support processing of order cancel replace request whilst order is pending cancel. CxlRejReason = ‘Order already in pending cancel or pending replace status’
8		Execution (Y,X)	Replace	Partially Filled	New	8000	1000	7000	0	‘Partially filled’ order status takes precedence over ‘replaced’ order status
9		Execution (Y)	Partial Fill	Partially Filled	New	8000	3000	5000	2000	Execution for 2000

This matrix illustrates the case where the broker does not support multiple outstanding order cancel or order cancel/replace requests

D18 – Telephoned order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1										Order for 10000 shares phoned to broker
2		Execution	New	New	New	10000	0	0	0	Confirm that the broker has accepted the order – note that broker does not need to capture a ClOrdID
3		Execution	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution of 2000
4		Execution	Partial Fill	Partially Filled	New	10000	3000	7000	1000	Execution of 1000
5		Execution	Fill	Filled	New	10000	10000	0	7000	Execution of 7000

D19 – Unsolicited cancel of a part-filled order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4										Broker verbally agrees to cancel order
5		Execution(X)	Canceled	Canceled	New	10000	1000	0	0	Broker signifies that order has been canceled - ExecRestatementReason = Verbal change

This scenario might occur if the buy-side has not implemented order cancel requests or alternatively there is an electronic communication problem at the point that the buy-side wishes to send a cancel request.

D20 – Unsolicited replacement of a part-filled order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3										Broker verbally agrees to increase order quantity to 11000
4		Execution(X)	Restated	New	New	11000	0	0	0	Broker signifies that order has been replaced ExecRestatementReason = Verbal
5		Execution(X)	Partial Fill	Partially Filled	New	11000	1000	10000	1000	Execution for 1000
6										Broker verbally agrees to increase order quantity to 12000
7		Execution(X)	Restated	Partially Filled	New	12000	1000	11000	0	Broker signifies that order has been replaced ExecRestatementReason = Verbal change

This scenario might occur if the buy-side has not implemented order cancel/replace requests or alternatively there is an electronic communication problem at the point that the buy-side wishes to send a cancel replace request

D21 - Unsolicited reduction of order quantity by sell side ( e.g. for US ECNs to communicate Nasdaq SelectNet declines)

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Restated	New	New	9000	0	9000	0	ExecRestatementReason="Partial Decline of OrderQty"
4		Execution(X)	Fill	Filled	New	9000	9000	0	9000

D22 - Order rejected due to duplicate ClOrdID

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	New Order(X)					10000				Order submitted with the same order id
5		Execution(X)	Rejected	Partially Filled	New	10000	1000	9000	0	OrdRejReason = duplicate order

D23 - Order rejected because the order has already been verbally submitted

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000				Order for 10000 sent electronically
2										Order passed verbally as there is communication problem and order does not arrive. The verbally passed order starts getting executed
3		Execution(X)	Rejected	Rejected	New	10000	0	0	0	Order finally arrives and is detected as a duplicate of a verbal order and is therefore rejected. OrdRejReason = duplicate of a verbal order

Note that the sell-side may employ a number of mechanisms to detect that the electronic order is potentially a duplicate of a verbally passed order, e.g. :

Checking the possdup flag on the order message header
Checking the incoming order details against other orders from the same client (e.g. side, quantity)
Looking at the transact time on the order as a guide to 'staleness'

D24 - Order status request rejected for unknown order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4	Status Request (Y)
5		Execution(Y)	Rejected	Rejected	Status	0	0	0		OrdRejReason = unknown order LastShares not required when ExecTransType=Status

D25 - Transmitting a CMS-style "Nothing Done" in response to a status request

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3	Status Request(X)
4		Execution(X)	New	New	Status	10000	0	10000	0	Text="Nothing Done"

D26 - Order sent, immediately followed by a status request. Subsequent status requests sent during life of order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2	Status Request (X)
3		Execution(X)	Pending New	Pending New	Status	10000	0	10000		Sent in response to status request. LastShares not required when ExecTransType=status
4		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected
4		Execution(X)	New	New	New	10000	0	10000	0
5	Status Request (X)
6		Execution(X)	New	New	Status	10000	0	10000		Sent in response to status request
7		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000	Execution for 2000
8	Status Request (X)
9		Execution(X)	Partial Fill	Partially Filled	Status	10000	2000	8000		Sent in response to status request
10		Execution(X)	Fill	Filled	New	10000	10000	0	8000	Execution for 8000
11	Status Request (X)
12		Execution(X)	Fill	Filled	Status	10000	10000	0		Sent in response to status request
13	Replace Request(Y,X)					12000				Request to increase order qty
14		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	10000	0	0
15		Execution (Y,X)	Replace	Partially Filled	New	12000	10000	2000	0
16	Status Request (X)
17		Execution (Y,X)	Partial Fill	Partially Filled	Status	12000	10000	2000		Sent in response to status request. Note reference to X to allow tie back of execution report to status request
18	Status Request (Y)
19		Execution(Y)	Partial Fill	Partially Filled	Status	12000	10000	2000		Sent in response to status request

D27 - GTC order partially filled, restated (renewed) and partially filled the following day

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	DayOrderQty	DayCumQty	Comment
Day 1,1	New Order(X)					10000
Day 1,2		Execution(X)	New	New	New	10000	0	10000	0
Day 1,3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000			Execution for 2000
Day 1,4		Execution(X)	Done for Day	Done for Day	New	10000	2000	8000	0			Optional at end of trading day
Day 2,1		Execution(X)	Restated	Partially Filled	New	10000	2000	8000	0	8000	0	ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2		Execution(X)	Partial Fill	Partially Filled	New	10000	3000	7000	1000	8000	1000	Execution for 1000

D28 - GTC order with partial fill, a 2:1 stock split then a partial fill and fill the following day

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	DayOrderQty	DayCumQty	Comment
Day 1,1	New Order(X)					10000
Day 1,2		Execution(X)	New	New	New	10000	0	10000	0
Day 1,3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000			Execution for 2000 @ 50
Day 1,4		Execution(X)	Done for Day	Done for Day	New	10000	2000	8000	0			Optional at end of trading day
Day 2,1		Execution(X)	Restated	Partially Filled	New	20000	4000	16000	0	16000	0	Sent the following morning after the split ExecRestatementReason = GTC corporate action. AvgPx=25, DayAvgPx=0
Day 2,2		Execution(X)	Partial Fill	Partially Filled	New	20000	9000	11000	5000	16000	5000	Execution for 5000
Day 2,3		Execution(X)	Fill	Filled	New	20000	20000	0	11000	16000	16000	Execution for 11000

D29 - GTC order partially filled, restated(renewed) and canceled the following day

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	DayOrderQty	DayCumQty	Comment
Day 1,1	New Order(X)					10000
Day 1,2		Execution(X)	New	New	New	10000	0	10000	0
Day 1,3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000			Execution for 2000
Day 1,4		Execution(X)	Done for Day	Done for Day	New	10000	2000	8000	0			Optional at end of trading day
Day 2,1		Execution(X)	Restated	Partially Filled	New	10000	2000	8000	0	8000	0	ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2	Cancel Request (Y,X)					10000
Day 2,3		Cancel Reject (Y,X)		Partially Filled		10000						If rejected by salesperson
Day 2,3		Execution (Y,X)	Pending Cancel	Pending Cancel		10000	2000	8000	0	8000	0
Day 2,4		Cancel Reject (Y,X)		Partially Filled		10000						If rejected by trader/exchange
Day 2,4		Execution (Y,X)	Canceled	Canceled		10000	2000	0	0	8000	0

D30 - GTC order partially filled, restated(renewed) followed by replace request to increase quantity

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	DayOrderQty	DayCumQty	Comment
Day 1,1	New Order(X)					10000
Day 1,2		Execution(X)	New	New	New	10000	0	10000	0
Day 1,3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000			Execution for 2000
Day 1,4		Execution(X)	Done for Day	Done for Day	New	10000	2000	8000	0			Optional at end of trading day
Day 2,1		Execution(X)	Restated	Partially Filled	New	10000	2000	8000	0	8000	0	ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2	Replace Request(Y,X)					15000						Increasing qty
Day 2,3		Cancel Reject (Y,X)		Partially Filled		10000						If rejected by salesperson
Day 2,3		Execution (Y,X)	Pending Replace	Pending Replace		10000	2000	8000	0	8000	0
Day 2,4		Execution (X)	Partial Fill	Pending Replace		10000	3000	7000	1000	8000	1000	Execution for 1000
Day 2,5		Cancel Reject (Y,X)		Partially Filled		10000						If rejected by trader/exchange
Day 2,5		Execution (Y,X)	Replace	Partially Filled		15000	3000	12000	0	13000	1000

D31 - Poss resend order

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0
3	New Order(X)					10000				PossResend=Y
4		Execution(X)	New	New	Status	10000	0	10000		Because order X has already been received, confirm back the current state of the order. Last shares not required when ExecTransType = Status
5	New Order(Y)					15000				PossResend=Y
6		Execution(Y)	New	New	New	10000	0	10000	0	Because order Y has not been received before, confirm back as a new order.

D32 - Fill or Kill order cannot be filled

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000				Order is FOK
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Canceled	Canceled	New	10000	0	0	0	If order cannot be immediately filled

D33 – Immediate or Cancel order that cannot be immediately hit

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000				Order is IOC
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	Execution for 1000
4		Execution(X)	Canceled	Canceled	New	10000	1000	0	0	If order cannot be immediately hit

D34 – Filled order, followed by correction and cancellation of executions

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	AvgPx	LastShares	LastPx	ExecId (ExecRefID)	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0		0		A	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0	0		B
3		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	100	1000	100	C	Execution for 1000 @ 100
4		Execution(X)	Fill	Filled	New	10000	10000	0	109	9000	110	D	Execution for 9000 @ 110
5		Execution(X)	Partial Fill	Partially Filled	Cancel	10000	9000	1000	110	0	0	E (C)	Cancel execution for 1000
6		Execution(X)	Partial Fill	Partially Filled	Correct	10000	9000	1000	100	9000	100	F (D)	Correct price on execution for 9000 to 100
7		Execution(X)	Fill	Filled	New	10000	10000	0	102	1000	120	G	Execution for 1000 @ 120
8		Execution(X)	Fill	Filled	Correct	10000	10000	0	120	9000	120	H(F)	Correct price on execution for 9000 to 120
9	Replace Request (Y,X)					12000							Request to increase order qty
10		Execution (Y,X)	Pending Replace	Pending Replace	New	10000	10000	0	120	0	0	I
11		Execution (Y,X)	Replace	Partially Filled	New	12000	10000	2000	120	0	0	J
12		Execution(Y)	Partial Fill	Partially Filled	Correct	12000	10500	1500	120	9500	120	K(H)	Correct execution of 9000 @ 120 to 9500 @ 120

D35 - A canceled order followed by a busted execution and a new execution

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	ExecID (ExecRefID	Comment
1	New Order(X)					10000
2		Execution(X)	New	New	New	10000	0	10000	0	A
3		Execution(X)	Partial Fill	Partially Filled	New	10000	5000	5000	5000	B	LastPx=50
4	Cancel Request(Y,X)					10000
5		Execution (Y,X)	Pending Cancel	Pending Cancel	New	10000	5000	5000	0	C
6		Execution (Y,X)	Canceled	Canceled	New	10000	5000	0	0	D
7		Execution(Y)	Partial Fill	Canceled	Cancel	10000	0	0	0	E(B)	Cancel of the execution. ‘Canceled’ order status takes precedence over ‘New’
8		Execution(Y)	Partial Fill	Canceled	New	10000	4000	0	4000	F	Fill for 4000. LastPx=51

D36 - GTC order partially filled, restated (renewed) and partially filled the following day, with corrections of quantity on both executions

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	DayOrderQty	DayCumQty	ExecID (ExecRefID)	Comment
Day 1,1	New Order(X)					10000
Day 1,2		Execution(X)	New	New	New	10000	0	10000	0			A
Day 1,3		Execution(X)	Partial Fill	Partially Filled	New	10000	2000	8000	2000			B	Execution for 2000
Day 1,4		Execution(X)	Done for Day	Done for Day	New	10000	2000	8000	0			C	Optional at end of trading day
Day 2,1		Execution(X)	Restated	Partially Filled	New	10000	2000	8000	0	8000	0	D	ExecRestatementReason = GTC renewal/restatement (no change) – optionally sent the following morning
Day 2,2		Execution(X)	Partial Fill	Partially Filled	New	10000	3000	7000	1000	8000	1000	E	Execution for 1000
Day 2,3		Execution(X)	Partial Fill	Partially Filled	Correct	10000	2500	7500	1500	8500	1000	F (B)	Correct quantity on previous day’s execution from 2000 to 1500
Day 2,4		Execution(X)	Partial Fill	Partially Filled	Correct	10000	2000	8000	500	8500	500	G (E)	Correct quantity on today’s execution from 1000 to 500

D37 – Transmitting a guarantee of execution prior to execution

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	ExecType	OrdStatus	ExecTransType	OrderQty	CumQty	LeavesQty	LastShares	Comment
1	New Order(X)					10000
2		Execution(X)	Rejected	Rejected	New	10000	0	0	0	If order is rejected by broker
2		Execution(X)	New	New	New	10000	0	10000	0
3		Execution(X)	Partial Fill	Stopped	New	10000	0	10000	1000	Text="You are guaranteed to buy 1000 at 50.10"; LastPx=50.10. This is similar to the concept of a ‘protected’ trade
4		Execution(X)	Partial Fill	Partially Filled	New	10000	1000	9000	1000	LastPx=50 * executed price is better than guaranteed

Appendix E

London SETS Order Types Matrix

The table below presents the representation of the London Stock Exchange Trading System (SETS) order types in the FIX protocol:

LSE Order Type	OrdType	TimeInForce	ExpireTime	Price	Comment
At Best	1	3	n/a	No
Fill or Kill - no limit price	1	4	n/a	No
Fill or Kill - limit price	2	4	n/a	Yes
Limit - day	2	n/a, 0	n/a	Yes
Limit - good until	2	6	Good Till Date	Yes
Execute and Eliminate	2	3	n/a	Yes
Market Orders - day	1	n/a, 0	N/a	No	SETS Release 3.1 Only
Market Orders -good until	1	6	Good Till Date	No	SETS Release 3.1 Only

Appendix F

Settlement Instruction Field Usage Matrix

Trade Settlement Type	F.I.X. Fields Required	F.I.X. Fields Optional
Standing Instructions Provided (i.e. to be stored in an internal or third-party standing instructions database)	`SettlInstID` `SettlInstTransType` `SettlInstRefID` (if `SettlInstTransType`=Cancel or Replace) `SettlInstMode=1` `SettlInstSource` `AllocAccount` (some combination of) * `LastMkt` * `Side` * `SettlLocation` * `SecurityType` * `SettlDeliveryType` * `EffectiveTime` `TransactTime` `StandInstDbType` (either `SettlDepositoryCode` or `SecuritySettl*`) `SettlBrkrCode` `SettlInstCode`	`ClientID` `ExecBroker` `Text` `StandInstDbName` `StandInstDbID` `SettlDepositoryCode` `SecuritySettlAgentName` `SecuritySettlAgentCode` `SecuritySettlAgentAcctNum` `SecuritySettlAgentContactName` `SecuritySettlAgentContactPhone` (`CashSettl` only if `SecuritySettl` fields provided) `CashSettlAgentName` `CashSettlAgentCode` `CashSettlAgentAcctNum` `CashSettlAgentContactName` `CashSettlAgentContactPhone`
Specific Allocation Account (trade) referencing existing Standing Instructions	`SettlInstID` `SettlInstTransType` `SettlInstRefID` (if `SettlInstTransType`=Cancel or Replace) `SettlInstMode=2` `SettlInstSource` `AllocAccount` `TradeDate` `AllocID` `LastMkt` `Side` `TransactTime` `StandInstDbType` `StandInstDbID` `SettlBrkrCode` `SettlInstCode`	`SettlLocation` `SecurityType` `ClientID` `ExecBroker` `Text` `StandInstDbName`
Specific Allocation Account (trade) providing details for settlement at a depository	`SettlInstID` `SettlInstTransType` `SettlInstRefID` (if `SettlInstTransType`=Cancel or Replace) `SettlInstMode=2` `SettlInstSource` `AllocAccount` `SettlLocation` `TradeDate` `AllocID` `LastMkt` `Side` `TransactTime` `SettlDepositoryCode` `SettlBrkrCode` `SettlInstCode`	`SecurityType` `ClientID` `ExecBroker` `Text` `SettlDeliveryType`
Specific Allocation Account (trade) providing details for a Single Agent (bank) for the security	`SettlInstID` `SettlInstTransType` `SettlInstRefID` (if `SettlInstTransType`=Cancel or Replace) `SettlInstMode=2` `SettlInstSource` `AllocAccount` `SettlLocation` `TradeDate` `AllocID` `LastMkt` `Side` `TransactTime` `SettlBrkrCode` `SettlInstCode` `SecuritySettlAgentName` `SecuritySettlAgentCode` `SecuritySettlAgentAcctNum`	`SecurityType` `ClientID` `ExecBroker` `Text` `SettlDeliveryType` `SecuritySettlAgentContactName` `SecuritySettlAgentContactPhone`
Specific Allocation Account (trade) providing details for a Two Agents (banks) one for the security and one for cash	`SettlInstID` `SettlInstTransType` `SettlInstRefID` (if `SettlInstTransType`=Cancel or Replace) `SettlInstMode=2` `SettlInstSource` `AllocAccount` `SettlLocation` `TradeDate` `AllocID` `LastMkt` `Side` `TransactTime` `SettlDeliveryType=Free` `SettlBrkrCode` `SettlInstCode` `SecuritySettlAgentCode` `SecuritySettlAgentAcctNum` `CashSettlAgentCode` `CashSettlAgentAcctNum`	`SecurityType` `ClientID` `ExecBroker` `Text` `SecuritySettlAgentName` `SecuritySettlAgentContactName` `SecuritySettlAgentContactPhone` `CashSettlAgentName` `CashSettlAgentContactName` `CashSettlAgentContactPhone`

Appendix G

Rule80A (aka OrderCapacity) Usage by Market

Note that the name of the Rule80A field is changing to “OrderCapacity” as Rule80A is a very US market-specific term. Other world markets need to convey similar information, however, often a subset of the US values. This appendix documents the market-specific usage of this field.

United States Listed Equity Markets

Rule80A’s values and usage details are documented in SEC Rule11Ac1-1/4. Note the purpose behind the rule is to restrict prices from rising or falling too fast providing more stability in the market. See Investments by Sharpe, 6th edition p. 50. Indicates the order type upon which exchange Rule 80A is applied.

The following values are valid and applicable when using FIX to communicate with the New York Stock Exchange (NYSE) or other US listed equity exchanges per the SuperDOT Notification document. The values and usage details when used for US trading are documented in SEC Rule11Ac1-1/4.

Valid values:
A = Agency single order
B = Short exempt transaction (refer to A type)
C = Program Order, non-index arb, for Member firm/org
D = Program Order, index arb, for Member firm/org
E = Registered Equity Market Maker trades
F = Short exempt transaction (refer to W type)
H = Short exempt transaction (refer to I type)
I = Individual Investor, single order
J = Program Order, index arb, for individual customer
K = Program Order, non-index arb, for individual customer
L = Short exempt transaction for member competing market-maker affiliated with the firm clearing the trade (refer to P and O types)
M = Program Order, index arb, for other member
N = Program Order, non-index arb, for other member
O = Competing dealer trades
P = Principal
R = Competing dealer trades
S = Specialist trades
T = Competing dealer trades
U = Program Order, index arb, for other agency
W = All other orders as agent for other member
X = Short exempt transaction for member competing market-maker not affiliated with the firm clearing the trade (refer to W and T types)
Y = Program Order, non-index arb, for other agency
Z = Short exempt transaction for non-member competing market-maker (refer to A and R types)

Japanese Equity Markets

Used to specify whether order is Agency or Principal.

Valid values:
A = Agency single order
P = Principal

Other Markets

All or a subset of the Rule80A (aka OrderCapacity) field values defined in the field reference may be applicable for other markets. Future markets will be included in this section as they are defined and brought forward to the FIX Technical Committee.

Appendix H

Mass Quote Message Scenarios

TBC

Appendix I

Security Definition, Security Status, and Trading Session Message Scenarios

TBC

Appendix J

Example Usage of Encoded Fields For Japanese Language Support

TBC

Appendix K

Example Usage of Allocations

TBC

Appendix L

Pre-Trade Message Targeting/Routing

Three fields, NoRoutingID, RoutingType, and RoutingID have been added to support list processing on third party networks. Vendor "indication of interest" systems generally have list management capabilities. These capabilities include blocking and targeting. To mirror the functionality of the vendor indication systems both blocking and targeting were supported.

Targeting

Targeting relates to the message that contains a list of targeted firms or targeted vendor maintained list identifiers to receive the indication. Generally, most vendor "indication of interest" systems maintain list identifiers that contain firm identifiers for their broker connections. For example, a broker has a list called "JapanList" that contains three institutions JapaneseFirm1, JapaneseFirm2, and JapaneseFirm3. The three firm identifiers are created by the vendor.

Targeting allows for the definition of the universe of firms to receive the indication of interest. A indication of interest message without the targeting identifiers (either firm or list) is assumed to be sent to the whole list of indication receiving firms managed by the vendor (i.e. every institution connected to the broker).

Specific targeting can be accomplished through the combination of firm identifiers and list identifiers. For example, a broker needs to send an indication of interest to a vendor maintained list of U.K. based clients called "UKList" and two U.S. based firms. The targeting section of the indication of interest would look as follows:

215=3^216=1^217=USFirm1^216=1^217=USFirm2^216=2^217=UKList^

Note: The ^ character represents the SOH delimiter.

Tag Explanation

215=3	Three pairs of routing types and IDs to be processed
216=1	Target ID to follow
217=USFirm1	Target ID named USFirm1
216=1	Target ID to follow
217=USFirm2	Target ID named USFirm2
216=2	Target list to follow
217=UKList	Target list named UKList

The vendor would assemble the destination list based on the two firm identifiers and the one list identifier.

Blocking

An indication with blocking contains a list of firm identifiers or vendor maintained list identifiers that will be excluded from the targeted list of indication receiving firms managed by the vendor. Using the blocking fields without targeting fields implies that indication of interest is being blocked from the whole universe of institutions available to the broker (i.e. everyone on the vendor's system but these firms).

Many "indication of interest" systems have sophisticated list handling mechanisms that need to be replicated. Blocking is not always performed from the whole universe of firms on the system (i.e. ALL).

Using a combination of targeting and blocking fields can allow for sophisticated list management capabilities. For example, let's assume that the broker intends to send an indication of interest to the universe defined by the broker's UKList and two U.S. based firms. However, the broker needs to exclude one UK based firm from the UKList. The targeting and blocking section would appear as follows:

215=4^216=2^217=UKList^216=1^217=USFirm1^216=1^217=USFirm2^216=3^217=UKFirm1^

Note: The ^ character represents the SOH delimiter.

Tag Explanation

215=4	Four pairs of routing types and IDs to be processed
216=2	Target list to follow
217=UKList	Target list named UKList
216=1	Target firm to follow
217=USFirm1	Target firm named USFirm1
216=1	Target firm to follow
217=USFirm2	Target firm named USFirm2
216=3	Blocked firm to follow
217=UKFirm1	UKFirm1 is blocked from receiving IOI

The vendor would assemble the targets based on the supplied UKList and two firm identifiers (USFirm1 and USFirm2) and then remove UKFirm1 from the combined list.

Other Issues

It is expected that every indication of interest message will have a unique IOIid for the fix session usually the trading day.

For canceling and replacing, the vendor system would cancel or replace every destination that has been identified on the previous indication of interest by the IOIid. Blocking and targeting information would not be required on the canceled or replaced indication of interest.

The use of vendor based firm identifiers requires periodic updates to the brokers to ensure proper blocking and targeting. It is expected that vendors will provide file base transfers of firm identifiers and company names until a more automated solution becomes available.

Appendix M

FIXML Support

The FIX Technical Committee has added two new fields XMLDataLen and XMLData to the Standard FIX Header to facilitate the creation of FIXML pilots.

The FIXML Working Group has been conducting a "proof of concept" pilot project to demonstrate evolution of FIX tag-value application messages to FIXML, a markup grammar based on the Extensible Markup Language (XML). This pilot, following the FIXML white paper and FIXML DTD, is the third deliverable in the process of creating a FIXML standard for the FIX Protocol.

The addition of these new fields will allow users to:

Modify an existing FIX engine by adding a validating XML parser to allow FIXML to be sent enclosed in a traditional FIX header and trailer.
Connect the modified FIX engine to an application that has the ability to send and receive FIX messages.
Measure the ease with which FIX engines can be ported over to FIXML.
Prove that FIXML messages will not break existing FIX engines. The same engine should be able to handle FIXML and FIX messages.

Appendix N

Program/Basket/List Trading

TBC

Appendix O

Foreign Exchange (F/X) Trading

TBC

Glossary

Business Terms

The following glossary is an attempt to identify business terms used in this document or related to implementing FIX globally. Requests for new terms and/or suggested definitions should be posted in the FIX Web Site’s Discussion section.

All or None	A round-lot market or limit-price order that must be executed in its entirety or not at all; unlike Fill or Kill orders, AON orders are not treated as canceled if they are not executed as soon as represented in the Trading Crowd. [`ExecInst`]
At the Opening	A market or limit-price order to be executed at the opening of the stock or not at all; all or part of any order not executed at the opening is treated as canceled. [`TimeInForce`]
Basis Price	A price established by joint agreement of odd-lot dealers in 100-share-unit stocks when: - no round-lot has occurred during the trading session, - the spread between the closing bid and offer is two points or more, and - on odd-lot the dealer has been given a “basis-price” order. [`OrdType`]
Buy Minus	A round-lot market order to buy “minus” is an order to buy a stated amount of a stock provided that its price is: - not higher than the last sale if the last sale was a “minus” or “zero minus” tick and - not higher than the last sale minus the minimum fractional change in the stock if the last sale was a “plus” or “zero plus” tick. A limit price order to buy “minus” also states the highest price at which it can be executed. [`Side`]
Day Order	A buy or sell order that, if not executed expires at the end of the trading day on which it was entered. [`TimeInForce`]
Do Not Increase	A limit order to buy, a stop order to sell, or a stop-limit order to sell which is not to be increased in shares on the ex-dividend date as a result of a stock dividend or distribution. [`ExecInst`]
Do Not Reduce	A limit order to buy, a stop order to sell, or a stop-limit order to sell that is not to be reduced in price by the amount of an ordinary cash dividend on the ex-dividend date. A do-not-reduce order applies only to ordinary cash dividends; it should be reduced for other distributions - such as when a stock goes “ex” stock dividend or “ex” rights. [`ExecInst`]
Fill or Kill	A market or limit-price order that is to be executed in its entirety as soon as it is represented in the Trading Crowd; if not so executed, the order is to be canceled. Not to be confused with Immediate or Cancel. [`TimeInForce`]
Good Till Canceled	An order to buy or sell that remains in effect until it is either executed or canceled; sometimes called an “open order”. [`TimeInForce`]
Good Till Executed	An order to buy or sell that remains in effect until it is executed.
Immediate or Cancel	A market or limit-price order that is to be executed in whole or in part as soon as it is represented in the Trading Crowd; any portion not so executed is to be canceled. Not to be confused with Fill or Kill. [`TimeInForce`]
Limit or Better	Indicates an order to - buy a security at the indicated limit price or lower, or to - sell a security at the indicated limit price or higher. [`OrdType`]
Limit With or Without	An order to be executed at a limit price, with or without round-lot sales; valid only for odd lot orders. [`OrdType`]
Market	Indicates an order to buy or sell a stated amount of a security at the most advantageous price obtainable after the order is represented in the Trading Crowd. [`OrdType`]
Market On Close	A round-lot order to be executed at - or as near to as practical - the close of the market. [`OrdType`]
Market Or Better	Indicates an order to buy or sell a stated amount of a security at the quoted market or better. [`OrdType`]
On Close	An odd-lot order to buy or sell to be filled at the price of the closing round-lot offer - plus the differential, for a buy order, or - minus the differential, for a sell order, or A crossing session order to buy or sell at the closing price. [`OrdType`]
Sell Plus	A round-lot market order to sell “plus” is an order to sell a stated amount of a stock provided that its price is: - not lower than the last sale if the last sale was a “plus” or “zero plus” tick and - not lower than the last sale minus the minimum fractional change in the stock if the last sale was a “minus” or “zero minus” tick. A limit-price order to sell “plus” also states the lowest price at which it can be executed. [`OrdType`]
Sell Short	An order to sell a security that the seller does not own; a sale effected by delivering a security borrowed by, or for the account of, the seller. Can only be executed on a “plus” or “zero plus” tick. [`OrdType`]
Sell Short Exempt	Short sale exempt from short-sale rules. [`OrdType`]
Stop	A stop order to buy which becomes a market order when the security trades at - or above - the stop price after the order is represented in the Trading Crowd. A stop order to sell which becomes a market order when the security trades at - or below - the stop price after the order is represented in the Trading Crowd. [`OrdType`]
Stop Limit	A stop order to buy which becomes a limit order at the limit price when the security trades at - or above - the stop price after the order is represented in the Trading Crowd. A stop order to sell which becomes a limit order at the limit price when the security trades at - or below- the stop price after the order is represented in the Trading Crowd. [`OrdType`]

Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy

Indexes

Message Layouts

Documentation

Financial Information Exchange Protocol

Table of Contents

DISCLAIMER

Preface

Release Notes

Introduction

FIX Message Format and Delivery

Message Format

Data Types

int

float

Qty

Price

PriceOffset

Amt

char

Boolean

String

MultipleValueString

Currency

Exchange

UTCTimestamp

UTCTimeOnly

LocalMktDate

UTCDate

data

month-year

day-of-month

Sequence Numbers

Heartbeats

Ordered Message Processing

Possible Duplicates

Possible Resends

Data Integrity

Required Fields

Message Acknowledgment

Encryption

User Defined Fields

Session Protocol

Logon

Message Exchange

Logout

Message Recovery

Response by Message Type

Standard Message Header

Standard Message Trailer

Administrative Messages

Heartbeat

Logon

Test Request

Resend Request

Reject

Sequence Reset (Gap Fill)

Logout

Application Messages

Advertisements

Indications of Interest

News

Email

Quote Request

Quote

Mass Quote

Quote Cancel

Quote Status Request

Quote Acknowledgement

Market Data Request

Market Data – Snapshot / Full Refresh

Market Data – Incremental Refresh

Market Data Request Reject

Security Definition Request

Security Definition

Security Status Request

Security Status

Trading Session Status Request

Trading Session Status

New Order - Single

Execution Reports