Financial Information eXchange

Overview

The Financial Information eXchange (FIX) protocol is an electronic communications protocol initiated in 1992 for international real-time exchange of information related to securities transactions and markets. With trillions of dollars traded annually on the NASDAQ alone, financial service entities are employing direct market access (DMA) to increase their speed to financial markets. Managing the delivery of trading applications and keeping latency low increasingly requires an understanding of the FIX protocol.

History

The FIX protocol specification was originally authored in 1992 by Robert "Bob" Lamoureux and Chris Morstatt to enable electronic communication of equity trading data between Fidelity Investments and Salomon Brothers. FIX initially addressed information between broker-dealers and their institutional clients. At the time, this information was communicated verbally over the telephone. Fidelity realized that information from their broker-dealers could be routed to the wrong trader, or simply lost when the parties hung up their phones. It wanted such communications to be replaced with machine-readable data which could then be shared among traders, analyzed, acted on and stored. For example, broker-dealers call with an indication of interest (IOI) to buy or sell a block of stock. The FIX initiative created new messages such as the IOI. According to the FIX Trading Community, FIX has become the de facto messaging standard for pre-trade and trade communication in the global equity markets, and is expanding into the post-trade space to support straight-through processing, as well as continuing to expand into foreign exchange, fixed income and derivatives markets.

FIX Trading Community

The FIX Trading Community is a non-profit, industry-driven standards body with a mission to address the business and regulatory issues impacting multi-asset trading across the global financial markets through the increased use of standards, including the FIX Protocol messaging language, delivering operational efficiency, increased transparency, and reduced costs and risk for all market participants.

Users

FIX is widely used by both the buy side (institutions) as well as the sell side (brokers/dealers) of the financial markets. Among its users are mutual funds, investment banks, brokers, stock exchanges and ECNs. FIX has become the standard electronic protocol for pre-trade communications and trade execution. Although it is mainly used for equity transactions in the front office area, bond derivatives and FX-transactions are also possible. One could say that whereas SWIFT is the standard for back office messaging, FIX is the standard for front office messaging. However, today, the membership of FIX Protocol Ltd. is extending FIX into block trade allocation and other phases of the trading process, in every market, for virtually every asset class.

Technical specifications

Originally, the FIX standard was monolithic, including application layer semantics, message encoding, and session layer in a single technical specification. It remained monolithic through FIX version 4.2. Thereafter, message encodings and session layer specifications began to be split into separate documents, and ultimately, FIX evolved into a family of related technical standards.

Message encodings

Message encoding, called Presentation Layer in the Open Systems Interconnection model (OSI model), is responsible for the wire format of messages.

Tagvalue encoding (classic FIX)

The original FIX message encoding is known as tagvalue encoding. Each field consists of a unique numeric tag and a value. The tag identifies the field semantically. Therefore, messages are self-describing. Tagvalue encoding is character-based, using ASCII codes.

FIX tagvalue message format

A message is composed of a header, a body, and a trailer. The message fields are separated by the start of heading (SOH) character (ASCII 0x01). Up to FIX.4.4, the header contains three fields: 8 (BeginString), 9 (BodyLength), and 35 (MsgType). From FIXT.1.1 / FIX.5.0, the header contains five or six fields: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID) and the optional 1128 (ApplVerID). The content of the message body is defined by the message type (35 MsgType) in the header. The trailer contains the last field of the message, 10 (Checksum), always expressed as a three-digit number (e.g. 10=002). Example of a FIX message, Execution Report (35=8), with the pipe character (|) representing the SOH character:

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

Body

FIX messages are formed from several fields; each field has a tag value pairing that is separated from the next field by a delimiter SOH (0x01). The tag is an integer that indicates the meaning of the field. The value is an array of bytes that hold a specific meaning for the particular tag (e.g. tag 48 is SecurityID, a string that identifies the security; tag 22 is IDSource, an integer that indicates the identifier class being used). The values may be in plain text or encoded as pure binary (in which case the value is preceded by a length field). The FIX protocol defines meanings for most tags, but leaves a range of tags reserved for private use between consenting parties. The FIX protocol also defines sets of fields that make a particular message; within the set of fields, some will be mandatory and others optional. The ordering of fields within the message is generally unimportant, however repeating groups are preceded by a count and encrypted fields are preceded by their length. The message is broken into three distinct sections: the head, body and tail. Fields must remain within the correct section and within each section, the position may be important as fields can act as delimiters that stop one message from running into the next. The final field in any FIX message is tag 10 (checksum). There are two main groups of messages—admin and application. The admin messages handle the basics of a FIX session. They allow for a session to be started and terminated and for recovery of missed messages. The application messages deal with the sending and receiving of trade-related information such as an order request or information on the current state and subsequent execution of that order.

Body length

The body length is the character count starting at tag 35 (included) all the way to tag 10 (excluded), including trailing SOH delimiters. The example below (displayed with SOH delimiters as '|') has a body length of 65:

8=FIX.4.2|9=65|35=A|49=SERVER|56=CLIENT|34=177|52=20090107-18:15:16|98=0|108=30|10=062| ^ 5 + 10 + 10 + 7 + 21 + 5 + 7 ^ = 65

Checksum

The checksum of a FIX message is always the last field in the message, with tag 10 and a 3 character value. It is given by summing the ASCII value of all characters in the message (except for the checksum field itself), then modulo 256. For example, in the message above, the summation of all ASCII values (including the SOH characters with ASCII value 1) results in 4158. Performing the modulo operation gives the value 62. Since the checksum is composed of three characters, this results in 10=062.

FIXML

FIXML is an XML schema for FIX messages. It is semantically equivalent to tagvalue encoded messages but takes advantage of XML parser technology. FIXML is commonly used for back-office and clearing applications rather than trading.