FIX protocol

from Wikipedia, the free encyclopedia
Components of the FIX protocol

The FIX protocol ( Financial Information eXchange ) is a communication protocol and open standard for the exchange of information that was created by banks , brokers , stock exchanges and other service providers .

The use of a common standard is intended to simplify the exchange of information between the applications of the various manufacturers.

The FIX interface was created in 1990 through cooperation between banks, brokers, stock exchanges and service providers and has established itself as an open interface.

standardization

In 1998, a number of companies and organizations formed a non-profit organization, FIX Protocol Limited , to jointly advance the development of the FIX protocol standard. Today this organization includes more than 170 companies.

The latest specification is currently version 5.0 SP2 (Service Pack 2), but older versions are still in use in practice.

implementation

The FIX protocol includes an interface that can be implemented by software manufacturers without licensing costs.

The FIX dictionary contains the vocabulary used. All FIX messages are structured according to certain rules and structures that are specified there.

As a rule, only part of the vocabulary is implemented, the scope of the implementation is agreed between the communication partners (trading partners) and commissioned from the in-house software developer. If necessary, the vocabulary (the FIX dictionary) can be expanded without great effort, but the standardized vocabulary will usually be used.

Due to the standardization of the interface, changes and extensions can be made later with little effort, after agreement between the trading partners.

Standard software can also be used, which can then be adapted to the requirements of the trading partner if necessary.

FIX data format

FIX messages are defined on the basis of an ASCII byte stream. Each telegram consists of a series of key number-value pairs, the individual value pairs are separated by a byte with value 1 (ASCII SOH). The key numbers ( tags ) are coded in ASCII decimal notation, the value follows separated by an equal sign (ASCII 61). Numerical values ​​are also coded in ASCII decimal notation, while ASCII character strings are used directly. For each basic data type there is a prescribed ASCII coding for the value representation, which takes over the usual representations for the terminal formatting (sprintf / sscanf).

Depending on the version of the FIX protocol, a number of value pairs are prescribed: Each telegram begins with a header in which the first value pair states the version number ("8 = 4.2") and a value pair encodes the message type ("35 = 8"). According to the FIX version, the message type is followed by mandatory or optional value pairs that follow the header block in the middle message block. The telegram is ended with a final block (trailer) with the required value pairs, the last value pair containing a checksum ("10 = 64").

An overall telegram for an "Execution Report" (confirmation of the transactions, e.g. the purchase of shares) looks like this:

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

As a makeshift, "|" used for the SOH separator. In FIX4, the header requires three pairs of values ​​- BeginString (8), BodyLength (9) and MsgType (35). In FIX5 the header consists of five mandatory value pairs plus one optional value pair - BeginString (8), BodyLength (9), MsgType (35), SenderCompID (49), TargetCompID (56) and optionally ApplVerID (1128). The BodyLength is calculated from the number of bytes from including MsgType (35) to excluding checksum (10), whereby the SOH separators are included. The checksum is formed over the entire message (excluding the checksum field itself) by adding up the bytes and taking the remainder of the bytes (modulo 256).

When sending FIX telegrams via UDP , the header block must begin at the beginning of the packet; telegrams must not be split over several UDP packets.

FAST data format

The data representation via ASCII with the identification of each value with a key number is very complex for a bandwidth-intensive data stream, for example the representation of all market data on a liquid trading center. For this reason, an alternative byte-oriented binary coding was defined as "FIX Adapted for Streaming", or FAST for short (acronym for English fast , meaning "fast").

With FAST, in addition to the FIX directory, a template (template description) that is published by the sending side (the trading venue) is required on the recipient side to interpret the data stream. The main optimization is that a large part of the key numbers in the template is assigned a basic value (default) so that they no longer have to be sent in every telegram (e.g. the FIX version) and instead of name values ​​only index values ​​of a list ( Enum). The numerical values ​​(also index values) are coded in binary. The template then defines a mandatory arrangement of fields so that the key numbers (tags) no longer have to be sent, and finally for the value coding it can be specified that only the difference to the value of the previous key pair is coded.

It has become established to publish the FAST template as XML text, with the XML schema (FIXML) being defined by the FIX standardization committee. FIXML goes back to an initiative of the CME in June 2002; the final version for FIX 4.4 was published in January 2004.

Individual evidence

  1. ↑ FIXML 4.4 Schema Overview Presentation 20040109 (PDF; 1.1 MB) August 16, 2004. Accessed on November 15, 2011.  ( Page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: dead link / fixprotocol.org  

Web links