Methods of transferring financial data: FIX protocol


    The stock market is a high-tech industry - in addition to the physical IT infrastructure and high-tech trading robots, the players in this market are developing technical standards for data transfer protocols. With today's material, we are opening a series of topics about financial information transfer protocols. The first issue provides information on one of the oldest protocols - Financial Information eXchange, or FIX for short.

    A bit of history

    The creation of the FIX protocol was initiated by a number of US financial institutions in 1992 - brokers and investment funds wanted to speed up the process of trading on the exchange. At that time, a significant part of trading operations was carried out using a telephone, and the FIX protocol allowed translating interactions into electronic form.

    As a result, an open standard for the transmission of information in electronic form was born, which is not controlled by any of the large organizations. Today, FIX has become an industry standard that is used by financial market participants from different countries to communicate their products.

    How it works

    Currently, the protocol is defined at two levels - sessions (work on data delivery) and applications (description of data content). There are two versions of the protocol syntax - traditional, of the form Tag = Value and in XML format (FIXML). Let's consider each of them.

    Tag Value Syntax

    FIX protocol messages typically contain a header and, in fact, a message body. Each message is a stream of = fields separated by special characters - in the FIX specification, the ASCII character SOH (# 001, 0x01) is used to separate data.

    Tags contain data in a format TagNum, and the tag field cannot be empty (in addition, the value must be positive and not start with zeros). A message with an empty Tag field will be rejected.

    A message body usually consists of a header, a message body, and a trailing element. The first message field is always the beginning of the line ( BeginString , tag # 8), then the length of the message body ( BodyLength tag # 9) and the type of message ( MsgTypetag # 35). The last character of the trailer is always the checksum (tag # 10).

    Often messages contain both the encrypted part and the characters transmitted in text form - this scheme is usually used to validate and verify data. For example, passing an encrypted SenderCompID value indicating the sender is an outdated validation method.

    To provide greater flexibility, FIX protocol contains the so-called user fields - User Defined Fields. They are used when transferring data between collaborating financial institutions. Tag numbers from 5000 to 9999 were reserved for custom fields - they could be reserved on the official website of the standard. These numbers were later used up., so a new interval was allocated - from 20,000 to 39999.

    Messages in Tag Value format look as follows (the ^ symbol is a SOH delimiter):

    8=FIX.4.2^9=251^35=D^49=AFUNDMGR^56=ABROKER^34=2^52=20030615-01:14:49^11=12345^ 1=111111^63=0^64=20030621^21=3^110=1000^111=50000^ 55=IBM^48=459200101^22=1^54=1^60=2003061501:14:49 38=5000^40=1^44=15.75^15=USD^59=0^10=127

    FIXML Syntax

    Work on creating syntax in XML format began in 1998, and the first version of FIXML appeared in January 1999.

    A new application for a transaction in the FIXML format is described as follows:

    Here ClOrdID - id-orders, side = ”2” means a sell order, then the transaction time, type of order (2 corresponds to the Limit order) and its price pX are indicated. The Acct field indicates the user account number.

    Further in the message information on the security and the number of securities that need to be bought or sold are indicated. As a result, a simple message will look something like this:

    At the beginning of the path of the XML version of FIX, only the DTD syntax determination mechanism was used. Subsequently, the W3C organization developed a new mechanism, XML Schema, which forced FIX developers to adapt the standard to use this syntax variant.

    This step made it possible to improve the XML version of the FIX protocol, in particular, users were able to add attributes and contextual abbreviations to messages.

    The basic organization of an XML schema assumes the existence of data types used in fields that are contained in a separate file. FIX fields are defined in a special shared file, and components and FIXML syntax elements in special component files. FIXML messages are defined using special files indicating the category.


    An example of a message about sending an application for FIXML (Schema):

    FIX Messages

    Each message sent in the format of the FIX protocol consists of mandatory, optional and conditionally mandatory (depending on the meaning of other parts of the message) fields.

    Messages are divided into three categories:
    • Pre-trading messages;
    • Trading messages (applications and transfer of information about transactions);
    • Post-trading messages.

    FIX on Russian exchanges

    Using the FIX protocol, anyone can directly connect to the Moscow Exchange. In addition, the exchange is working to unify FIX access for all available markets (stocks, derivatives, foreign exchange).

    ITinvest also provides its customers with access to the Moscow Exchange markets through direct connection via the FIX protocol. In addition, special IT services have been created for high-frequency traders and algorithmic traders, from server colocation in the M1 data center to providing access to virtual machines for hosting a trading robot.

    Other protocols

    To obtain market information (Market Data), the FAST protocol (Fix Adapted for STreaming) is used - a standard developed by the creators of the FIX protocol, which allows significant data compression capabilities to transfer large volumes of market information with minimal time delays. In addition to the Moscow Exchange, it is used on the NYSE, Nasdaq-OMX and many other world sites.

    Also, for direct connection, the so-called native protocols are used, which arose even before the MICEX and RTS exchanges were merged into the Moscow Exchange.

    So on the markets related to the RTS exchange (FORTS - futures and options , Standard), for direct transactions and receiving data in connection mode, it is usedProtocol Plaza II. In order to carry out trading operations and obtain exchange data on sites previously referred to the MICEX (currency and stock markets), the MICEXBridge (TEAP) bidirectional gateway is used.

    These protocols will be discussed in our next articles. That's all for today, thank you for your attention, we will be happy to answer questions in the comments.

    PS If you notice a typo or mistake - write in a personal message, and we will quickly fix it.

    Also popular now: