The FIX Protocol. FIX message architecture.
Atom
14.10.2019


Today it is impossible to imagine stock trading without the use of FIX Protocol. However, it appeared relatively recently - in 1992.
The increase in speed and data volume has prompted the creation of a fundamentally new connection with high bandwidth and reliable connectivity.
Today, the fifth version of the FIX5 Protocol has been released, which should replace the previous FIX4. However, the most popular for use is still FIX4, which has proven itself as the optimal solution for data transmission.
The Protocol itself exists in two syntaxes, XML (second name FIXML) and Tag=Value. It is worth saying that the Protocol is divided into 3 levels - transport, session, application.

fix_protocol.jpg

For a better understanding of the mechanism of the Protocol, consider each of the levels separately.
Let's start with the transport layer of the FIX Protocol.
This level describes the structure of the message transmitted through the FIX Protocol. Gives a description of how the message structure is constructed.
Considering it it is possible to tell the following that it is the usual line containing the cipher written by means of syntax of FIX of the Protocol. In fact , it is a cipher containing a message to be sent to the trading floor.

FIX_connector_data.png

The example shows the message transport LAYER fix Protocol, which is directed to the exchange Lmax. This message conveys the information that the trader wants to log in to the trading system to make transactions.
At first glance, this message is a set of numbers and symbols, but let's analyze what information this message contains.
In our example, we see the syntax of type "Tag=Value". All messages consist of several components - fields, these fields are divided by vertical lines. Each field is divided into two parts by the sign "=". It turns out that to the left of the sign is equal-the "Tag", and to the right-the "Value". Tags are always positive and integers that indicate the name of the field. Each exchange provides a kind of documentation, according to which messages are encrypted and decrypted by the FIX Protocol. It specifies the names of the "Tags" that describe the data type and the description of the data itself.
Almost all fields are standardized, having the same meaning on all trading floors. However, it is worth saying that at the same time, not every exchange supports them. Messages sent via the FIX Protocol contain mandatory and optional fields, as well as conditionally required fields, the presence of which is conditioned by the presence of other fields. In the diagram below we can clearly see the division of the message into fields.
Let's look at an example of such a record.

FIX_protocol_messenge.png

The separation of fields occurs by means of the SOH symbol, which stands for-Start of Heading, and belongs to the ASCII encoding method. In this case, this symbol is not displayed as an abbreviation, but is conditionally indicated by a vertical line and from the point of view of the UNICODE format has the value “\u0001”.
The same is worth noting that the message is built from three parts. Conventionally, they are shown in different colors:
- Green-header
- Pink-body
- Lilac - checksum
Let's take a closer look at what each of the parts is.
The message header can contain a different number of fields, consider the main ones that must be in the FIX message:
- 8 = FIX.4.4-this field indicates the Protocol version, it is always the first.
- 9 = 123-this field indicates the size of the FIX message, it is the second message size, always the second in a row
- 35 = V-this field means the name of the operation to be performed, in this case V-market data query, this field is always the third.
- 34 = 2-denotes which account message is calculated for the current session.
- 49 = FIXtest1 – this field means the sender user ID, which is assigned by the exchange.
- 54 = 20120924-14:05:44.952 is the current time of sending the message.
- 56 = LMXBDM-this field is the value of the identifier that is assigned to the recipient by the exchange.
Considering the body of the FIX message, we can say that this is a list of fields that correspond to each of the types of requests. The practice of using a set of fields or groups that contain the same tags is also used.
Let's assume we need to request information on a list of tools. In this case, each of them will have the same tag, and differ only in content. We list the necessary tools, using a separate field for each. This type of record is called a group or set of fields. They will all have the same tag or data type, and differ only in content.
Consider the checksum. The calculation is performed in accordance with a special algorithm, the calculation takes the header and body. In the beginning, the length of the "header plus body" is calculated, then divide the length by 256 and get the remainder. The checksum consists of three characters. If in the remainder of the division we got 20, then forward we add 0, and get 020. As a result, the checksum in our case will have the form " 10 = 020|".
Now consider the session-level Protocol. This FIX message Protocol regulates the mechanism of establishing/disconnecting the connection, maintaining the connection, reporting missing data. It consists of a number of messages:
1. Logon (35=A) - by means of this message, the user is authenticated by the server. It is sent first, and serves as a signal to the beginning of the data transfer session. On successful startup, a response message is received, on error-a message about the error occurred.
2. Logout (35=5) - this message indicates a disconnection from the server.
3. Heartbeat (35=0) - this message notifies the readiness of counterparties, is sent to both parties, another name is the message "pulse". The frequency of sending the pulse is set by the user in the First logon message.
4. Test Request (35=1) - this message is a test message and is sent when the counterparty has not sent a pulse message within the specified period. The session will be closed if this message remains unanswered.
5. Resend Request (35=2) is a request message that is directed to send a repeated message. Resend Request, for example, can repeat to give a signal that the exchange would repeat the missed information.
6. Reject (35=3) – the message is sent in response if the previous one is incorrectly formed.
7. Sequence Reset (35=4) - this message can take two forms.
- in the field GapFillFlag (tag 123) is the value " Y”, used to ignore administrative messages, if there is a repetition of their sending.
- in the second case, it is used To reset the MsgSeNum counter.
The last level of FIX messages is applied.
This level has the most capacious description, this is due to the fact that this level contains information that is necessary to work with the trading platform.
Let's look at the main messages of this level:
1. Market Data Request (35=V) - the message sends a signal that the user subscribes to the stream of transmitted data on quotes in the current time period. The user can unsubscribe from receiving data through a similar request, specifying the ID of the previous message. In this case, he will receive a message MarketDataSnapshotFullRefresh (35=W).
2. New Order Single (35=D) – a message about the user's desire to place an order in the system. The user has the ability to set their own ID, this simplifies the process of tracking the execution, partial execution or cancellation of the order.
3. Execution Report (35=8) – execution report message that provides information on the status of the order executed or canceled, and for what reasons. This report is specified as Exec Type (Tag 150).
4. OrderCancelRequest (35=F) - message about the request to cancel the placed order.

fix_protocol_trading.jpg

We have analyzed the main aspects of working with messages transmitted by means of FIX Protocol. The number of such messages and query options is huge, and every year the possibilities and tools for working with FIX Protocol are growing. The specification of such messages is regulated by the exchange, leaving a standardized form for recording requests.
Let me remind you that the transmission of such messages takes place directly when directly connected to the trading floor, through FIX connectors. The cost of such connectors and their name are different, more information about the specification of connectors can be found on our website.




Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy