The Financial Information eXchange (“FIX”) Protocol is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. These market participants share a vision of a common, global language for the automated trading of financial instruments.
FIX is the industry-driven messaging standard that is changing the face of the global financial services sector, as firms use the protocol to transact in an electronic, transparent, cost efficient and timely manner. FIX is open and free, but it is not software. Rather, FIX is a specification around which software developers can create commercial or open-source software, as they see fit. As the market’s leading trade-communications protocol, FIX is integral to many order management and trading systems. Yet, its power is unobtrusive, as users of these systems can benefit from FIX without knowing the language itself.
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 focuses on the delivery of data using the “FIX Session Protocol”
About FIX messages
The FIX Protocol currently exists in two syntaxes:
The same business message flow applies to either syntax. A specific syntax is simply a slightly different way to represent the same thing in much the same way that “3” and “three” represent the same thing.
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 with a field delimiter between fields in the stream. Tags are of data type TagNum. All tags must have a value specified. Optional fields without values should simply not be specified in the FIX message. A Reject message is the appropriate response to a tag with no value.
Except where noted, fields within a message can be defined in any sequence (relative position of a field within a message is inconsequential.) The exceptions to this rule are:
General message format is composed of the standard header followed by the body followed by the standard trailer.
The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).
The last field in the standard trailer is the CheckSum (tag #10).
Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.
A tag number (field) should only appear in a message once. If it appears more than once in the message it should be considered an error with the specification document. The error should be pointed out to the FIX Global Technical Committee.
In addition, certain fields of the data type MultipleValueString can contain multiple individual values separated by a space within the “value” portion of that field followed by a single “SOH” character (e.g. “18=2 9 C<SOH>” represents 3 individual values: ‘2’, ‘9’, and ‘C’).
It is also possible for a field to be contained in both the clear text portion and the encrypted data sections of the same message. This is normally used for validation and verification. For example, sending the SenderCompID in the encrypted data section can be used as a rudimentary validation technique. In the cases where the clear text data differs from the encrypted data, the encrypted data should be considered more reliable. (A security warning should be generated).
All fields (including those of data type data i.e. SecureData, RawData, SignatureData, XmlData, etc.) in a FIX message are terminated by a delimiter character. The non-printing, ASCII “SOH” (#001, hex: 0x01, referred to in this document as <SOH>), is used for field termination. Messages are delimited by the “SOH” character following the CheckSum field. All messages begin with the “8=FIX.x.y<SOH>” string and terminate with “10=nnn<SOH>”.
There shall be no embedded delimiter characters within fields except for data type data.
It is permissible for fields to be repeated within a repeating group (e.g. “384=2<SOH>372=6<SOH>385=R<SOH>372=7<SOH>385=R<SOH>” represents a repeating group with two repeating instances “delimited” by tag 372 (first field in the repeating group.).
If the repeating group is used, the first field of the repeating group (start field) is required. This allows implementations of the protocol to use the first field as a “delimiter” indicating a new repeating group entry. The first field listed after the NoXXX, then becomes conditionally required if the NoXXX field is greater than zero.
The NoXXX field (for example: NoTradingSessions, NoAllocs) which specifies the number of repeating group instances (leading field) occurs once for a repeating group and must immediately precede the repeating group contents.
The NoXXX field is required if one of the fields in the repeating group is required. If all members of a repeating group are optional, then the NoXXX field should also be optional.
If a repeating group field is listed as required, then it must appear in every repeated instance of that repeating group.
Repeating groups are designated within the message definition via indentation and the ‘ symbol.
Some repeating groups are nested within another repeating group (potentially more than one level of nesting).
Nested repeating groups are designated within the message definition via indentation and the ‘ symbol followed by another ‘ symbol.
If a nested repeating group is used, then the outer repeating group must be specified
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 Global Technical Committee for inclusion in a future FIX version.
The tag numbers 5000 to 9999 have been reserved for use with user defined fields, which are used as part of inter-firm communcation. These tags can be registered/reserved via the FIX website.
The tag numbers greater than or equal to 10000 have been reserved for internal use (within a single firm) and do not need to be registered/reserved via the FIX website.
Many of the FIX Application Messages are composed of common “building blocks” or sets of data fields. For instance, almost every FIX Application Message has the set of symbology-related fields used to define the “Instrument”: Symbol, SymbolSfx, SecurityIDSource, SecurityID:.. EncodedSecurityDesc. Rather than replicate a common group of fields, the FIX specification specifies several key component blocks below which are simply referenced by component name within each Application Message which uses them. Thus when reviewing a specific message definition, the appropriate group of fields should be expanded and used whenever a component block is identified.
Note that some component blocks may be part of repeating groups thus if the component block is denoted as part of a repeating group, then the entire group of fields representing the component block are to be specified at the component block’s repeating group “level” in the message definition and follow repeating group rules concerning field order. See “Repeating Groups” for more details.
About FIX sessions
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.
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). The HeartBtInt value should be agreed upon by the two firms and specified by the Logon initiator and echoed back by the Logon acceptor. Note that the same HeartBtInt value is used by both sides: the Logon “initiator” and Logon “acceptor”.
Ordered Message Processing
The FIX protocol assumes complete ordered delivery of messages between parties. Implementers should consider this when designing message gap fill processes. Two options exist for dealing with gaps, either request all messages subsequent to the last message received or ask for the specific message missed while maintaining an ordered list of all newer messages. For example, if the receiver misses the second of five messages, the application could ignore messages 3 through 5 and generate a resend request for messages 2 through 5, or, preferably 2 through 0 (where 0 represents infinity). Another option would involve saving messages 3 through 5 and resending only message 2. In both cases, messages 3 through 5 should not be processed before message 2.
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.
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.
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.
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.
The integrity of message data content can be verified in two ways: verification of message length and a simple checksum of characters.
The message length is indicated in the BodyLength field and is verified by counting the number of characters in the message following the BodyLength field up to, and including, the delimiter immediately preceding the CheckSum tag (“10=”).
The CheckSum integrity check is calculated by summing the binary value of each character from the “8” of “8=” up to and including the <SOH> character immediately preceding the CheckSum tag field and comparing the least significant eight bits of the calculated value to the CheckSum value (see “CheckSum Calculation” for a complete description).
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, allocations, etc. require specific application level responses, executions can be rejected with the DK message but do not require explicit acceptance. See “Volume 1 - Business Message Reject” for details regarding the appropriate response message to specific application level messages.
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 sequential (not concurrent) 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. Resetting the inbound and outbound sequence numbers back to 1, for whatever reason, constitutes the beginning of a new FIX session.
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.
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.
Unregistered Acceptor is the acceptor, which does not exist by the time the new incoming logon message appears.
FIX Connection is comprised of three parts: logon, message exchange, and logout.
FIX Session is comprised of one or more FIX Connections, meaning that a FIX Session spans multiple logins.
About FIX 5.0
With the release of FIX 5.0 in October 2006, the FPL Global Technical Committee (GTC) introduced a new framework, the transport independence (TI) framework, which separated the FIX Session Protocol from the FIX Application Protocol. Under the TI framework the application protocol messages can be sent over any suitable session transport technology (e.g. WS-RX, MQ, publish/subscribe message bus), where the FIX Session Protocol is one of the available options as a session transport for FIX application messages. From this release forward the FIX Application layer and the FIX Session layer will have their own versioning moniker. The FIX Application layer will retain the traditional version moniker of “FIX x.y” while the FIX Session layer will utilize a new version moniker of “FIXT x.y” (note that the version numbers will be independent of each other). The diagram below illustrates how previously the FIX Session layer was tighly coupled to the Application layer. With the advent of Application Versioning and Transport Independence, the FIX Session and Application layers have been decoupled and are now independent.
Transport Independence (TI) Framework
The transport independence (TI) framework separates the previously coupled FIX Session layer from the FIX Application layer. Under this framework the FIX Application Protocol can use any transport technology in addition to the FIX Session Protocol. The diagram below illustrates how various transport mechanisms, including the FIX Session layer, can be used to carry the full suite of FIX Application versions.
To support this framework a key new field has been added called ApplVerID (application version ID, tag 1128). Depending on the use case ApplVerID may be optional or required. Additionally, the FIX field BeginString will no longer identify the FIX application version, but identifies the FIX Session Protocol version. The sections below discuss the four main uses cases supported by the TI framework.
Application Versioning allows extensions to the current base application version to be applied using a formal release process. Extension Packs represent the individual gap analysis proposals submitted to the GTC for review and approval. Extension Packs are grouped into Service Packs and are applied to the base application version, usually the most current FIX application version. A new application version is formed when a new Service Pack is applied to a base version. In the diagram below, FIX 4.4 has been extended via Service Pack 0, forming a new application version called FIX 5.0. As new Extension Packs are approved they will be grouped into Service Pack 1 which is then released to form the next application version identified as FIX 5.0 SP1. These application versions are expressed using the new tag ApplVerID.