Financial Information Exchange Protocol

Version: 4.1
Date: April 1, 1998

Table of Contents

• Financial Information Exchange Protocol
  • Table of Contents
  • DISCLAIMER
  • Preface
  • Release Notes
    • Session Level
    • Overall
    • Quote and QuoteRequest
    • IOIs, Advertisements, News, and Email
    • Orders, Execution Reports, and DK’s
    • Allocation and AllocationACK
    • Settlement Instructions
    • Appendix and App Notes
  • Introduction
  • FIX Message Format and Delivery
    • Message Format
    • Data Types
      • int
      • float
      • char
      • time
      • date
      • 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
    • Message Header
    • 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
    • New Order - Single
    • Execution Reports
    • Don’t Know Trade
    • Order Cancel/Replace Request
    • Order Cancel Request
    • Order Cancel Reject
    • Order Status Request
    • Allocation
    • Allocation ACK
    • Settlement Instructions
    • New Order - List
    • List Status
    • List Execute
    • List Cancel Request
    • List Status Request
  • Appendix A
    • Valid Currency Codes
  • Appendix B
    • CheckSum Calculation
  • Appendix C
    • Reuters Exchange Mnemonics
      • Exchanges A–L
      • Exchanges M–Z
      • Other
  • Appendix D
    • Order State Change Matrices
      • Filled Order
      • Partially Filled Order
      • Canceled Order
      • Partially Filled Order followed by Replace Request to Decrease Order Quantity
      • Replaced Order
      • Filled Order followed by a CancelReject
      • Partially Filled Order followed by a Cancel Request
      • Partially Filled Order followed by Replace Request to Increase Quantity
      • Filled Order followed by Replace Request to Increase Quantity
      • Rejected Order due to Duplicate ClOrdID
  • Appendix E
    • London SETS Order Types Matrix
  • Appendix F
    • Settlement Instruction Field Usage Matrix
  • Glossary
    • Business Terms

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

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, 816-340-7053 (scott_atwell@americancentury.com) or Sam Johnson, Goldman, Sachs & Co., 212-357-1186 (sam.johnson@gs.com). Technical Committee meetings are announced via email and on the WWW, go to http://www.fixprotocol.org for details.

We look forward to your participation.

The FIX Committee

February, 1998

Back to top ↑

Release Notes

The FIX Protocol specification, Version 4.1, is now available. This version addresses changes requested since the publication of Version 4.0 in the Spring of 1997. The document and release notes are available on the FIX Web Site at http://www.fixprotocol.org You can link directly to the specs page (without HTML frames) at http://www.fixprotocol.org/cgi-bin/rbox/sections.cgi?dir=TOOLS/SPECS

FIX 4.1 includes major changes for order handling, allocations, settlement instructions, futures and options support, and expanded forex trading capability. Order handling changes include the exclusive use of the Cancel/Replace message to reduce quantity (partial cancel). Very few changes were made to the session level. Potentially the most significant is that fact that all ID fields are now of a character data type (see narrative below).

Changes in the version 4.1 include:

Session Level

• Added a new field ResetSeqNumFlag to the Logon message. Described the specific procedure which should be used when using this feature in the “Logon” portion of the “Session Protocol” section.
• Clarified the description of the Sequence Reset message to highlight the language which specifies that the NewSeqNo contains the next number to be transmitted.
• Clarified the description of the “Message Recovery” section regarding handling multiple Resend Requests in a row and Sequence Reset - Gap Fill potential gotchas. Clarified that SeqReset-GapFill and SeqReset-Reset should be sent with PossDupFlag=Y when responding to a ResendRequest. Added the fact that one can check the MsgSeqNum of the SeqReset-GapFill to help avoid one of the gotchas.
• Clarified and explicitly stated in the “Message Recovery” section that the Reject message is the only administrative message which can be resent.
• Highlighted in the “Message Format” section the fact that FIX message fields are not positional and explicitly noted the exceptions.
• Clarified the description of the “Logout” portion of the “Session Protocol” section to recommend that one send a TestRequest to force a Heartbeat which should help ensure that there are no sequence number gaps prior to sending the Logout message.
• Highlighted the fact that all fields including those of data type data must have their value delimited by the field delimiter (SOH) character.
• Added the following statement: “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.” to the “Introduction” section following the sentence “FIX was written to be independent of any specific communications protocol...”
• Clarified the “is set” references to PossDupFlag and PossResend within the “Message header” section to explicitly specify “is set to Y”.

Overall

• Made all business level ID fields type char. This changed the data type of the following fields: AdvID, AdvRefID, ExecID, ExecRefID, IOIid, IOIRefID, AllocID, RefAllocID from int to char. The field reference section has noted this in bold for each of these fields. There was significant debate regarding the best way to accomplish this change. A majority vote by the FIX Technical Committee determined that the existing field tags and names should remain and the data type in the field reference should simply be changed starting in FIX 4.1 and beyond. These fields should continue to be used as int in versions prior to 4.1.
• Added four new optional fields to the Standard Header: SenderLocationID, TargetLocationID, OnBehalfOfLocationID, and DeliverToLocationID which can allow firms to specify a geographic location and/or desk associated with business messages in addition to the CompID and SubID values.
• Added SymbolSfx, IDSource, SecurityID, Issuer, and SecurityDesc to all messages containing Symbol. OrdStatusRequest had IDSource and SecurityID added. News, Email, and Don’t Know Trade had SymbolSfx, IDSource, SecurityID, Issuer, and SecurityDesc added.
• Replaced references to “MsgSeqNo” with “MsgSeqNum” throughout the spec.
• Clarified the usage of the Commission field such that if CommType is percentage, Commission should be represented as a decimal (i.e. .05 for 5%).
• Added a Glossary of Business Terms to the appendix. The FIX Web Site’s Discussion area will have a thread devoted to identifying terms which need to be defined and providing definitions.
• Added new field SecondaryOrderID to the ExecutionRpt and OrderCancelReject. This field can be optionally used by the party accepting the order to provide the order id used by an exchange or executing system.
• Added a cautionary note regarding the Text field in the Field Reference concerning the fact that it does not have a specified maximum length.
• Added two new enumerations to the Side field: Undisclosed for IOIs and Cross for orders where counterparty is an exchange.
• Corrected several spelling mistakes.
• Noted in Field Definitions section and both of the field cross-references that SendingDate and CxlType are no longer used. Noted that tag 101 does not have a field defined.
• Added for consistency in the Field Definitions section, valid values for “price” fields: AvgPx, LastPx, BidPx, OfferPx, and PrevClosePx and for “shares” fields: LastShares, AllocShares, CxlQty, MinQty, BidSize, and OfferSize.
• In order to support symbol identification for Futures and Options, added SecurityType and six new fields: MaturityMonthDate, MaturityDay, PutOrCall, StrikePrice, OptAttribute, and SecurityExchange to all messages containing Symbol.
  • Futures now require SecurityType=”FUT”, Symbol, and MaturityMonthDate.
  • Options now require SecurityType=”OPT”, Symbol, MaturityMonthDate, PutOrCall, and StrikePrice.
• Noted in Field Definitions section description for MsgType that when it is used for User Defined messages, the format should be U1, U2, etc.
• Added two new data types used in the field reference. “month-year” represents a month and year combination as a char in YYYYMM format. “day-of-month” represents a day within a month as an int 1-31. Used to handle cases in which day of the month may or may not be specified.

Quote and QuoteRequest

• Made BidPx on the Quote message optional. Clarified the description to indicate that either BidPx, OfferPx, or both must be specified.
• Added TransactTime to the Quote message.
• Added OrderQtyType to the QuoteRequest (see Orders, Execution Reports, and DK’s changes listed below).
• The following were added to better support foreign exchange (F/X) trading:
  • Added FutSettDate to the Quote and QuoteRequest messages to allow one to request/send a quote for a particular value date when requesting F/X quotes.
  • Added two new fields, OrderQty2 (the qty in the future) and FutSettDate2 (the value date in the future), and OrdType to the Quote and QuoteRequest messages to allow one to request/send a quote for “Forex - Swap”. Side should be the Side of the FutSettDate2 transaction.
  • Added new fields BidSpotRate, BidForwardPoints, OfferSpotRate, and OfferForwardPoints to the Quote message.
  • Specified that for F/X trading BidPx and OfferPx within the Quote message should represent the “all-in” (aka “outright” aka “contract”) rate.

IOIs, Advertisements, News, and Email

• Added NoRelatedSym (required) to News and Email messages.
• Added a new required field Subject and new optional field EmailThreadID to the Email message.
• Added a new required field Headline to the News message.
• Added a new optional field URLLink to the IOI, Advertisement, and News messages.
• Added two new enumerations for IDSource: “ISO Currency Code” and “ISO Country Code” which can be used for News and Email messages.
• Added TradeDate to the Advertisement message.
• Added TransactTime to the IOI message.
• Added “At the midpoint” and “Pre-open” as enumerations to the IOIQualifier field. Changed the language in the field reference for enumeration “Q” from “Current quote” to “At the market (previously called current quote)”.
• Added new field NoIOIQualifiers to the IOI message. Made IOIQualifier a repeating group to allow for multiple values.
• Added LastMkt to the Advertisement message.

Orders, Execution Reports, and DK’s

• Clarified that the Order Cancel/Replace Request can also be considered an Order Modification Request to reduce, increase, or change the parameters of an open order and that it can be used to re-open a filled order by increasing OrderQty. Removed the “It is recommended…” wording. Clarified that Cancel Reject should specify both the ClOrdID and OrigClOrdID values provided on the Cancel/Replace Request. Defined OrderQty as “Total Intended Order Quantity”.
• Modified the description of the Order Cancel Request message removing the ability to use it to partially cancel (reduce) an order and noting that Order Cancel/Replace Request should be used instead.
• Removed the CxlType field from the Order Cancel Request.
• Added new field LeavesQty to ExecutionRpt making the implicit LeavesQty = OrderQty - CumQty defunct. Modified the ExecutionRpt description when referring to “CumQty and AvgPx” to include LeavesQty as well.
• Clarified that ExecID must be unique for the day or the life of the order if the order spans more than one day.
• Added new enumeration to ExecInst value ‘U’ to denote customer display instruction in order to satisfy SEC Rule 11Ac1-1/4.
• In order to support brokers who allow their customers to submit an order with a “dollar quantity” vs. share quantity, a new field CashOrderQty was added to the New Order - Single, New Order - List, and Order Cancel/Replace Request messages. These messages conditionally require either OrderQty or CashOrderQty to be specified. The broker is responsible for converting and computing the CashOrderQty amount into a specific OrderQty number of shares at the time of accepting the order. The share quantities are used for all subsequent messages.
• Added “Unknown Order” and “Duplicate Order” to OrdRejReason code (to be used in conjunction with OrdStatus of Rejected) to reject a Status Request due to an unmatched order.
• Revised order status progression for clarity. A new required field ExecType to the ExecutionRpt with the same possible values as OrdStatus. Noted in the description of the ExecutionRpt that ExecType describes the specific ExecutionRpt (i.e. Pending Cancel) while OrdStatus will always identify the current order status (i.e. Partially Filled). The Order State Change Matrix in the appendix has been updated and addresses reducing order quantity and some more complicated scenarios.
• The description of the ExecutionRpt message now includes a list of OrdStatus value precedence.
• Added OrigClOrdID and OrdStatus to Order Cancel Reject. Clarified its definition to specify that it refers to the previous order NOT the initial order for the day when canceling or replacing an order multiple times.
• Clarified the DontKnowTrade message indicating that LastShares and LastPx are only required if they were specified on the ExecutionRpt (i.e. not required on the ExecutionRpt if ExecTransType=Status).
• Removed NoMiscFees, MiscFees repeating group, and NetMoney from the ExecutionRpt message as it will now be provided via the Allocation message with AllocTransTyp=”Calculated” sent from the broker to institution.
  • Replaced narrative details re: OrdStatus=”Calculated” to reference “report post-trade calculations” vs. “report miscellaneous fees”.
  • OrdStatus=”Calculated” can still be used to provide the Commission or SettlCurrency related details.
• Added SettlCurrFxRate and SettlCurrFxRateCalc to the ExecutionRpt message (consistent with add to Allocation message).
• The following were added to better support foreign exchange (F/X) trading:
  • Added “Netting” as an enumeration to the ExecInst field.
  • Replaced the OrdType field enumeration for “Forex” with “Forex - Market”. Added OrdType field enumerations: “Forex - Limit”, “Forex - Swap”, and “Forex - Previously Quoted”.
  • Added OrderQty2 (the qty in the future) and FutSettDate2 (the value date in the future) to the New Order - Single, Order Cancel/Replace Request, and New Order - List messages to allow one to send an OrdType = “Forex - Swap”. Side should be the Side of the FutSettDate2 transaction.
  • Added two new fields to the ExecutionRpt message: LastSpotRate and LastForwardPoints.
  • Specified that for F/X trading the LastPx field in the ExecutionRpt should represent the “all-in” (aka “outright” aka “contract”) rate.
  • Specified that for F/X trading the Price field in the New Order - Single, New Order - List, Order Cancel/Replace Request, and Order Cancel Request messages should represent the “all-in” (aka “outright” aka “contract”) rate.
• Added LeavesQty as a required field to the List Status message.
• Modified the description of OrderQty within the Order Cancel Request removing reference to CxlType field which has been removed. It now states that OrderQty = LeavesQty + CumQty.
• Modified the description of the ExecutionRpt message noting the general rule of OrderQty = CumQty + LeavesQty. Noted that there can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay, Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0.
• Modified the description of the Order Cancel Reject message clarifying that it should specify both the ClOrdID and OrigClOrdID values provided on the Cancel/Replace Request.
• Modified the description of the use of ExecTransType=Correct in the ExecutionRpt message to clarify what the value of ExecRefID should be if a single execution is corrected multiple times.
• Noted in New Order - Single, New Order -List, and Order Cancel/Replace Request that StopPx is required if OrdType = “Stop” or OrdType = ”Stop limit”.
• In order to support orders for Futures and Options, added OpenClose and two new fields: CoveredOrUncovered and CustomerOrFirm to the New Order - Single, Order Cancel/Replace Request, and New Order - List messages.
• Added missing enumerations: E, O, P, R, S, and T to the Rule80A field’s valid values.
• Modified the description of the ExecutionRpt message stating that ExecutionRpt messages used to communicate state changes should be sent separately and should not be used to also convey new partial fill details (i.e. do not report a partial fill or filled in a Done for the Day, Reject, etc.)
• Added new field, MaxShow, to the New Order - Single, Order Cancel/Replace Request, and New Order - List messages which controls the order quantity shown to other customers (i.e. via an IOI).
• Added LocateReqd to the Order Cancel/Replace Request message.
• Modified the list of fields which can be changed on an Order Cancel/Replace Request to include: StopPx, CashOrderQty, OrderQty2, OpenClose, CoveredOrUncovered, Side (i.e. sell to sell plus), MaxShow, and LocateReqd. Corrected the inconsistency in wording regarding the ability for HandlInst to change.
• Modified the description for New Order - Single to specify that TimeInForce of ImmediateOrCancel and OrdType of Previously Indicated (or Previously Quoted) should be used when responding to an IOI (or Quote) from an ECN or exchange and one wishes to “take” the IOI (or Quote) if still available and not be displayed on the book otherwise.
• Modified the description for the Price field in New Order - Single, Order Cancel/Replace Request, and New Order - List messages to indicate that it can be used to specify a limit price for a pegged order, previously indicated, etc.
• Added new field, PegDifference, to the New Order - Single, ExecutionRpt, Order Cancel/Replace Request, and New Order - List messages which specifies the price difference for a pegged order.
• Modified the description for ExecutionRpt noting 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.
• Noted in the ExecutionRpt message that Price, StopPx, and PegLimit are required if specified on the order.

Allocation and AllocationACK

• Considerable revisions have been made to the Allocation message in order to properly support foreign trading requirements and other overall enhancements.
• Modified AllocTransType to include enumerations for “Preliminary (without MiscFees and NetMoney)” and “Calculated (with MiscFees and NetMoney)”.
• Modified MiscFeeTyp to include enumeration for “Markup” in the event the broker is acting as principal on a trade.
• Added a new field AllocAvgPx to AllocAccount repeating group to provide ability to specify different average prices for each account. Required for US domestic as well as foreign trading.
• Added a new field AllocNetMoney to the AllocAccount repeating group.
• Moved SettlCurrAmount and SettlCurrency from the “overall” section to within the AllocAccount repeating group.
• Added two new fields, SettlCurrFxRate and SettlCurrFxRateCalc, to the AllocAccount repeating group to go along with SettlCurrAmount and SettlCurrency.
• Added a new field SettlInstMode to the AllocAccount repeating group to indicate the type of Settlement Instructions which will be provided via the Settlement Instructions message.
• Added two new fields, NumDaysInterest and AccruedInterestRate, to the “overall” section to support convertible bonds.
• Added new field AccruedInterestAmt to the AllocAccount repeating group to support convertible bonds.
• Moved NoMiscFees and MiscFees repeating group from the “overall” section to within the AllocAccount repeating group.
• Removed the DlvyInst repeating group. Added BrokerOfCredit and a new field AllocText to the AllocAccount section to support communicating step-out details (ProcessCode indicates this).
• Moved LastMkt from within the Execs repeating group to the “overall” level.
• Modified the narrative details for the message to include:
  • “In addition, the allocation record can be sent by the broker to communicate fees and other details which can only be computed once the sub-account breakdowns are known.
  • That “preliminary” and “calculated” are now valid AllocTransTyp values.
  • Created a diagram to show the typical flow for US domestic trading (without MiscFees)
  • Created a diagram to show the typical flow for international trading (with MiscFees).
• Designed such that the institution accepts or rejects the “Computed” Allocation via the AllocationAck message which is consistent with current flow within various ETC systems such as: Global OASYS, Crest, DTC, etc.
• Added LastCapacity to the Execs repeating group in order to support the SFA’s “Conduct of Business” requirements for trade confirmations.
• Allow AllocTransTyp=Cancel to appear without the currently required Orders and AllocAccount sections.
• The following were added to better support foreign exchange (F/X) trading:
  • Specified that for F/X trading the AvgPx and AllocAvgPx fields in the Allocation message should represent the “all-in” (aka “outright” aka “contract”) rate.
  • Added two new optional fields to the Allocation Message: AllocLinkID and AllocLinkType which can be used to link two different Allocation messages (each with unique AllocID) together, i.e. for F/X “Netting” or “Swaps”.
• Added two new fields, NotifyBrokerOfCredit and AllocHandlInst, to the AllocAccount repeating group in the Allocation message.

Settlement Instructions

• Added a new Settlement Instructions message in an attempt to support communicating Settlement Instructions in a vendor-neutral manner.
• Includes the capability to support “standing” instructions as well as those for a specific allocation and allocation account (associate with an actual trade).
• Supports worldwide equities:
  • Supports settlement at a depository or settlement at a country via local agent banks/custodians.
  • Supports different details for the settlement of the security vs. the settlement of the cash.
  • Remains consistent with existing worldwide initiatives such as the IUG Working Group (now a subcommittee of ISITC) in Europe.
• Supports Settlement Instructions sent from:
  • Broker to Institution
  • Institution to Broker
  • Broker to a third-party (i.e. a standing instructions database, depository, custodian bank, etc.)
  • Institution to a third-party (i.e. a standing instructions database, depository, custodian bank, etc.)
• Serves to bridge the gap between the information brokers and institutions transmit/receive via F.I.X. and the information both need to support “back-office” needs (i.e. transmitted via ISITC to/from agent/custodian banks)

Appendix and App Notes

• Updated Appendix C - Reuters Exchange Mnemonics starting a list to specify values (used by LastMkt, ExDestination, and SecurityExchange) for exchanges which either do not have a 1-2 character Reuters abbreviation (i.e. Chicago Mercantile Exchange ) or would have one which collides with an existing (i.e. London Stock Exchange and LIFFE both use L as Reuters abbreviation). These and other Options Exchanges have been added with a numeric value starting from 0.
• Updated Appendix D - Order State Change Matrices.
• Added Appendix E - London SETS Appendix which specifies how the OrdType, TimeInForce, and ExpireTime fields should be used.
• Added Appendix F - Settlement Instruction Field Usage Matrix.

Back to top ↑

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.

Back to top ↑

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 (Relative position of a field within a record is inconsequential.) Any exceptions are explicitly defined otherwise: four header/trailer fields (BeginString, BodyLength, MsgType, and CheckSum) and fields within repeating data groups.

It is permissible for fields to be repeated. In the case where a field allows multiple values, these repeating fields are logically added together to form the data for that field. 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, etc.) in a FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" (#001), is used for field termination. Records are delimited by the “SOH” character following the CheckSum field. All records 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 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.

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

time

Time/date combination in YYYYMMDD-HH:MM:SS format, colons and dash required.

Valid values:

• YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-59.

date

Date 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. 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 record length and a simple checksum of characters.

The record 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 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.

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

Back to top ↑

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.

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

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 be agreee on a reset time. 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.

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

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:

1. retransmit the requested messages (in order) with the original sequence numbers and PossDupFlag set to “Y”

2. issue a SeqReset-GapFill with PossDupFlag set to “Y” message to replace the retransmission of administrative and application messages

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

Two fields helps 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).

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 messages are 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 monitos 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.)

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.

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

Reject

The reject message should be issued when a message is received butcannot be passed through to the application level. 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 disregbard 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).

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 GapFill 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 Gap Fill 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.

Back to top ↑

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.

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

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.

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.

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

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.

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 ISO codes, as “held-currency.new-currency” (e.g. “USD.GBP” indicates a desire to convert a held amount of USD to GPB)
• Side is defined in terms of whether the OrderQty is currency required or currency held (e.g. a forex order can be expressed as either “S 3,200,000 USD for GPB” or “B 2,000,000 GBP for USD”, at a rate of 1.6 USD/GBP, these trades are equivalent in that the broker is receiving 3,200,000 USD and delivering 2,000,000 GBP). 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.

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

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 on working orders
5. reject orders
6. 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 message will contain information that will describe the current state of the order and execution status as understood by the broker. State changes should be sent as separate messages and should not be used to also convey new partial fill details (i.e. do not report a partial fill or filled in a Done for the Day, Reject, etc.)

Execution report messages can be transmitted as transaction types (ExecTransType) 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 canceled 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. 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). 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.

The ExecType field describes the specific ExecutionRpt while OrdStatus will always identify the current order status.

An Order State Change Matrix appears in the appendix.

To transmit a change in OrdStatus for an order, the broker(sell side) should send an Execution Report with the new OrdStatus value in ExecType AND OrdStatus to signify this message is changing the state of the order. The only exception to this rule is when sending a CancelReject in response to a Cancel or Replace request, the CancelReject message is used. Furthermore, partial/complete fill information should be sent in a separate Execution Report than order accept(New), cancel accept(Canceled), cancel/replace accept(Replaced) or Done For Day reports.

The OrdStatus field is used to identify the status of the current 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:

NOTE: The canceled and replaced order status is 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 CumQty will be rejected. 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, Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0.

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.

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.

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:

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

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 record instructs a broker on how to allocate executed shares to sub-accounts. The allocation record 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 record can be sent by the broker to communicate fees and other details which can only be computed once the sub-account breakdowns are known.

An allocation message can be submitted as preliminary, calculated, 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.

The allocation record contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown below in typeface Bold-Italic. The field’s relative position in the record 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.

The typical flow for US domestic trading (without MiscFees) is as follows:

The typical flow for international trading (with MiscFees) is as follows:

¹ Settlement Instructions may occur anywhere in the flow and may represent standing instructions.

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.

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

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

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

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, LeavesQty, 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 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.

Back to top ↑

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

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 *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 );
  }

Back to top ↑

Appendix C

Reuters Exchange Mnemonics

Exchanges A–L

Exchanges M–Z

Other

Back to top ↑

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 and cancel/replace requests. These state diagrams are presented from the broker’s view. (Note: x refers to the original order, y refers to the cancel/replacing order)

Filled Order

Partially Filled Order

Canceled Order

¹ information only transmitted as the result of an Order Status Request on this order

Partially Filled Order followed by Replace Request to Decrease Order Quantity

¹ information only transmitted as the result of an Order Status Request on this order

Replaced Order

¹ information only transmitted as the result of an Order Status Request on this order

Filled Order followed by a CancelReject

Partially Filled Order followed by a Cancel Request

Partially Filled Order followed by Replace Request to Increase Quantity

Filled Order followed by Replace Request to Increase Quantity

Rejected Order due to Duplicate ClOrdID

Back to top ↑

Appendix E

London SETS Order Types Matrix

The FIX OrdType (tag 40) field takes as valid values the CMS specification order types. For exchanges that do not use the CMS specification (e.g. London Stock Exchange) the issue of how exchange order types are represented in the FIX protocol arises. The table below presents the representation of the four London Stock Exchange Trading System (SETS) order types in the FIX protocol:

Back to top ↑

Appendix F

Settlement Instruction Field Usage Matrix

Back to top ↑

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.

Back to top ↑