Financial Information Exchange Protocol

Version: 2.7(a)
Date: January 17, 1995

Table of Contents

• Financial Information Exchange Protocol
  • Table of Contents
  • DISCLAIMER
  • Preface
  • Release Notes
  • Introduction
  • Session Protocol
    • 1. Connection, Authentication and Initialization
    • 2. Message Exchange
      • General Message Format and Content
      • Data Types
        • int
        • float
        • char
        • data
      • Sequence Numbers
      • Heartbeats
      • Possible Duplicates
      • Possible Resends
      • Data Integrity
      • Required Fields
      • Encryption
    • 3. Logout
    • Message Header
    • Message Trailer
  • Administrative Messages
    • Heartbeat
    • Logon
    • Test Request
    • Resend Request
    • Reject
    • Sequence Reset
    • Logout
  • Application Messages
    • Advertisements
    • Indications of Interest
    • News
    • Email
    • New Order - Single
    • Execution Reports
    • Order Cancel/Replace Request
    • Order Cancel Request
    • Order Cancel Reject
    • Order Status Request
    • Allocation
    • Allocation ACK
    • New Order - List
    • List Status
    • List Execute
    • List Cancel Request
    • List Status Request
  • Appendix A
    • Valid Currency Codes
      • Codes A–F
      • Codes G–L
      • Codes M–R
      • Codes S–Z
  • Appendix B
    • CheckSum Calculation

Back to top ↑

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

Back to top ↑

Preface

In mid-1992 Fidelity Investments and Salomon Brothers began work on a project to link the two firms' trading systems for the purpose of automating the exchange equity-related indication and execution messages. Fidelity determined that it could help its traders become more effective by automating portions of their broker communication and thus reduce the time spent on the phone placing routine orders and recording fills. Salomon's motivation was the desire to leverage its investment in technology into increased service for its clients. The initial system link was brought up in early 1993 and has been in production each trading day since.

At the onset of the effort it was recognized that the success of the linkage would be determined by the two firms' ability to develop a workable set of messages and protocols to be used for the information exchange. The firms decided that the effort would be most successful if other buy- and sell-side representatives were involved in the specification discussions. Throughout 1993 a group of large financial firms met regularly to refine the specification and to share their experiences in its implementation. The group felt it necessary to limit participation in the effort until the concept had been proven in production and the rate of requests for modification to the protocol had slowed to the point which indicated it had stabilized. By early 1994 the majority of the committee members had implemented the protocol and felt that the stabilization requirement for general release had been satisfied.

The Financial Information Exchange Protocol is the result of these efforts. It is offered to the financial community as a starting point towards the establishment of a standard for broker/institution communication.

Feedback on this protocol, including comments on existing content and suggestions for additional message types, is requested. Feedback should directed to me at Salomon. My phone number in New Jersey is (201) 896-7789.

Christopher Morstatt
Vice President
Salomon Brothers Inc
July, 1994

Back to top ↑

Release Notes

Attached is the latest FIX Protocol specification (Version 2.7) which addresses the changes requested since the publication of Version 2.6 on February 14, 1994.

Changes in this release include:

1. Revision of Preface to reflect current status.

2. The order of messages defined within the Application Messages section of the document has been rearranged for clarity.

3. Revision to indicate that sequence numbers should initialize to one each day.

4. Clarification of BodyLength in Data Integrity section.

5. Addition of Required Fields description.

6. Update of Message Header to reflect changes in unencrypted field identification and rearrangement of field order for clarification.

7. The Side field enumeration has been expanded to include traded and crossed for use in the Advertisement message.

8. The OrdStatus field enumeration has been expanded to include the statuses Stopped and Rejected.

9. A new optional field, OrdRejReason, has been added to the Execution message to be used in describing the reason for order rejections from the broker.

10. A new mandatory field, CxlOrdReqId, has been added to the Cancel Request and Cancel Reject messages to uniquely identify cancel request transactions.

11. The new optional field, ExDestination, has been added to the New Order - Single, New Order - List and Cancel/Replace Request messages to allow specification by the institution of where they would like the order executed.

12. The new conditionally required field, StopPx, has been added for use with stop and stop limit orders.

13. The OrdType enumeration has been expanded to include “limit on close”.

14. A new optional field, CxlRejReason, has been added to the Cancel Reject message to allow reporting of the reason for rejection of a cancel request.

15. Appendix B, Abbreviation Descriptions, has been removed from the document.

Please review the document and call me at (201) 896-7789 with any comments or changes.

Back to top ↑

Introduction

The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to Equity and Fixed Income transactions. It is intended for use between brokers and institutions wishing to automate communications.

The message protocol, as defined, will support the following electronic conversations:

• Equity order submissions, cancellations and replacements
• Equity execution reporting
• Equity order statusing
• Equity trade allocation
• Indication of interest communication
• Completed trade advertisements
• Directed email and news messaging

The FIX 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 protocol is independent of the telecommunications protocol (X.25, asynch, internet, etc.) and medium chosen for electronic data delivery.

Back to top ↑

Session Protocol

Each connection between an institution and broker will be defined as a session. The Financial Information Exchange session consists of three parts:

• Connection, authentication and initialization
• Message exchange
• Logout

The following section describes each of these parts.

1. Connection, Authentication and Initialization

All connections between a broker and institution are initiated from the institution's site. After establishing message level communication the sequence to connect to the broker is:

• Authenticate as a valid user by submitting the Logon message which contains the login name and password as agreed upon between the parties.
• After validation, the broker's system will start the initialization process which will:
  • forward all queued outgoing messages awaiting transmission,
  • issue a test request message, and,
  • if the response to the test request is other than 1 (one), issue a resend request for any untransmitted incoming messages.

2. 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'.

General Message Format and Content

The general format of a message is a standard message header followed by message body data and a standard trailer.

The Financial Information Exchange 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 (except certain of the administrative messages) is identified by a unique sequence number. It is the receiving application's responsibility to monitor incoming sequence numbers to identify gaps for response with resend request messages.

Each message is defined in a <tag>=<value> format. Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential except where explicitly defined otherwise).

Fields within a record are to be separated by a delimiter character; the non-printing, ASCII "SOH" (#001), is used for this purpose. Examples cited in this document will use the character "|" to represent the delimiter.

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

Data Types

Data types 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.

char

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

data

Raw data with no format or content restrictions. Data fields are always preceeded by a length field. Caution: may contain the delimiter (SOH) character.

Sequence Numbers

All messages are identified by unique sequence number. Sequence numbers are re-initialized each day starting at 1 (one). Each connection will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a series to monitor for sequence gaps on incoming messages.

Heartbeats

When message traffic is light the sending application will generate heartbeat messages at regular time intervals. The heartbeat will contain the next sequence number to be transmitted. The heartbeat is useful for identifying when the last of a string of messages are lost and for monitoring the status of the communication link.

Possible Duplicates

In certain circumstances the sending application may be unsure if a message was successfully transmitted to its destination. In such cases a poss dupe message will be generated. The poss dupe will be a resend (with the same sequence number) of the data in question with the PossDupFlag included and set to "Y" in the header. It is the receiving application's responsibility to handle the poss dupe 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, messages lacking the PossDupFlag field are original transmissions. The PossDup flag is used only to identify the resend of messages with a previously recorded sequence number.

Possible Resends

Application level messages which appear to the end-user to be in an ambiguous state may be resent with the PossResend flag set. An example of when this is useful include an order which remains unacknowledged for an inordinate length of time and which the end-user is may suspect has 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.

Data Integrity

Integrity of message data content can be verified in two ways; verification of record length and a simple checksum of characters. The record length is indicated in the BodyLength field and can be verified by counting the number of characters in the message following the BodyLength field up to, and including, the delimiter immediately preceeding the CheckSum tag (“10=”). An additional integrity check is to sum the ASCII value of each character up to, but not including, the CheckSum tag field and comparing the least significant eight bits of the calculated value to the CheckSum value (see Appendix C for a complete description).

Required Fields

Each message within the protocol is comprised required, non-required and conditionally required (fields which are required only when other fields are present) fields. Systems should be written to operate when only the required and conditionally required fields are present.

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 between the broker and institution.

Except where explicitly stated any field within a message can be encrpyted and included in the SecureData field.

Imbedded in the protocol are fields which enable the implementation of a public key signature and encryption methodology, straight DES encryption and clear text. The choice of encryption methodology will be defined in the LOGON message.

3. Logout

Normal termination of the message exchange session will be initiated by the customer via the submission of the LOGOUT message. Termination by other means will be considered an abnormal condition.

Message Header

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

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.

Back to top ↑

Administrative Messages

The administrative class of messages are intended to address the utility needs of the protocol. The following section describes the use of each message and provides the message layout.

Administrative messages will be generated from both the broker and institution side of the connection.

Heartbeat

When message traffic is light, the sending application will generate heartbeat messages at regular time intervals. The heartbeat will consist of the standard message header and trailer and will contain the next sequence number to be transmitted. The heartbeat is useful for identifying when the last of a string of messages are lost and for monitoring the status of the communication link.

The heartbeat is generated only when no regular message has been transmitted within the heartbeat interval. The heartbeat interval timer will be reset each time a regular message is transmitted. The interval value will be individually determined for each connection.

The standard message header is utilized for heartbeats with following provisions:

• The MsgType field is set to "0"
• The sequence number field contains the next message sequence number to be transmitted
• The sequence number is NOT incremented for heartbeats
• The SenderSubID, TargerSubID, SecureDataLen, SecureData, PossResendFlag and PossDup fields are not required.

Logon

The logon message is utilized authenticate a user attempting to establish a connection to a remote system. The logon message must be the first message sent by the connecting application.

Test Request

The test request message is utilized to force a heartbeat from the opposing application. The test request message is useful for checking sequence number or verifying communication line status. The receiving application will respond to the test request message with a heartbeat. Sequence numbers are not incremented for test request messages.

Resend Request

The resend request is introduced by the receiving application to initiate the retransmission of messages. This function would be utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process. Sequence numbers are not incremented for resend request messages.

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

• 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 = 99999

Reject

The reject message will be issued when a message is received which cannot be parsed or contains invalid information (i.e. fails one of the validation tests). Where possible the cause of the failure will be described in the Text field.

Sequence Reset

The sequence reset message is used to reestablish the incoming sequence number on the opposing side. In the event of an application failure it may be necessary to resync sequence numbers on the sending and receiving sides.

The sending application will initiate the sequence reset. The message is used to reset the value of the last sequence number sent (which on the receiving side will reset the value of the next expected sequence number).

It is assumed that the purpose of the sequence reset message is to recover from an out-of-sequence condition, therefore, 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).

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.

Logout

The logout message is to used to terminate the session. Disconnection without the sending of a logout message should be interpreted as an abnormal condition.

Back to top ↑

Application Messages

The exchange of business infomation 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.

Advertisements

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 the message AdvRefID.

Indications of Interest

Indication of interest messages are used to 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 intended for use as 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 record can be originated at either the broker or institution side.

Email

Format and purpose similar to News message, however, intended for private use between two parties.

New Order - Single

The new order message type is used by institutions wishing to electronically submit 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 HandInst field). Execution instructions refer to how the order should be handled at the exchange (see ExecInst field).

Execution Reports

The execution report message is used to:

1. confirm the receipt of an order
2. confirm changes to an existing order (i.e. accept cancel and replace requests)
3. relay order status information
4. relay fill information as orders are worked

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 message will contain information that will describe the current state of the order and execution status as understood by the broker.

Execution report messages can be transmitted as transaction types (ExecTranType) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID. 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 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 incorrect execution will be identified in the ExecRefID field.
• 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. Note: Data reported in the CumQty 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.

The OrdStatus field is used to identify the status of the current order. The order statuses are as follows:

NOTE: The canceled and replaced order status are set in response to accepted cancel and replace requests. These requests are only acted upon when there is an outstanding order quantity. Requests to replace OrderQty to a level less than the LeavesQty will be rejected (OrderQty = CumQty + LeavesQty). Requests to change price on a filled order will be rejected (see Order Cancel Reject message type).

The field ClOrdID is provided for institutions to affix an identification number to an order to coincide with internal systems. The OrdId field is populated with a broker generated order number.

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 for this purpose.

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

Only a limited number of fields can be changed via the cancel/replace request message. These fields are:

• ExecInst
• OrderQty
• OrdPx
• TimeInForce

Order Cancel Request

The order cancel request message is used to request the cancellation of all remaining quantity of an existing order.

Do not use this message to reduce the quantity of (i.e. partially cancel) an outstanding order, use the Cancel/Replace Request for this purpose.

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

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; orders which are filled cannot be changed.

The execution message will be used to respond 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 record is used by the institution to instruct the broker on how to allocate executed shares to sub-accounts.

The allocation record contains repeating fields for each sub-account; the repeating fields are shown below in typeface Bold-Italic. The relative position of the repeating fields is important in this record, i.e. 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.
• The number of instances of allocations 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.
• Single orders cannot be combined with list orders for allocation.

Allocation ACK

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

New Order - List

The new order list message type is used by institutions wishing to electronically submit lists of related orders to a broker for execution.

The New Order List is intended for use in staging lists to be executed by the broker. If the institution wishes to work a list using the broker's execution services the orders should be submitted as individual New Order - Single's.

After staging, the list can be operated on in the following ways:

Executions against orders within the list will not normally be reported as they occur. (If this feature is desired the institution and broker should arrange for this reporting as a custom feature using the Execution message.) Executions against the list will be reported within the List-Status message.

List Status

The list status message is issued as the response to a List Status Request message and 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 order; the repeating fields are shown below in typeface Bold-Italic. The relative position of the repeating fields is important in this record, i.e. each instance of ClOrdID, CumQty, CxlQty and AvgPx must be in the order shown below.

Each list status message will report on only a maximum of 50 orders; if the list contains more than 50 orders multiple status messages will be required.

List Execute

The list execute message type is used by institutions to instruct the broker to begin execution of a previously submitted list.

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

Back to top ↑

Appendix A

Valid Currency Codes

Codes A–F

Codes G–L

Codes M–R

Codes S–Z

Back to top ↑

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 22. This value would be transmitted a |10=022| where "10=" is the tag for the checksum field.

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

  char *cksum( char *buf, long bufLen )
  
  GenerateCheckSum (int checksum)
  {
    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 );	
  }

Back to top ↑