FIX Engine – Demystifying FIX Message

Understanding the FIX Engine

The Financial Information Exchange (FIX) protocol emerged in the 1990s as a standardized means for financial firms to communicate. Unlike proprietary solutions, FIX offers a global standard, promoting interoperability. The FIX protocol is a text-based, transport-agnostic protocol extensively employed by financial institutions for order transmission, execution report receipt, and market data dissemination. With various versions available, institutions typically tailor a specific FIX version to suit their unique requirements and use cases. Most of the communication between exchanges, brokers, banks and other financial institutions takes place using FIX.

Though FIX Protocol Ltd/FIX Trading Community supervised the protocol's development, they did not produce or market FIX engines; instead, they provided the blueprint for others to create them.

A FIX engine serves as middleware between your enterprise and that of your business partners, facilitating message exchange. It manages network connections, sends and receives FIX messages, and validates their adherence to the FIX format. Numerous FIX engine providers, both commercial and open-source, offer various functionalities. QuantXpress stands out in this domain with its QX.FIX Engine, enabling businesses to harness FIX's power for streamlined communication and a competitive edge in the financial market.

Origins of the FIX Engine

Initially, the sole option for utilizing a FIX engine involved developing a custom solution (commercial versions followed suit). Dubbed a "FIX Engine," this software component facilitated connection and communication using the FIX protocol. However, due to variations in interpretation and implementation of the protocol, disagreements arose, particularly during testing phases regarding message resending and correction responses.

Deconstructing the FIX Protocol Engine

The FIX engine facilitates low-level communication and FIX message encoding/decoding (parsing). Typically leveraging the TCP/IP protocol, FIX engines establish connections by either initiating or accepting them. Traditionally, investment managers (buy-side) act as initiators, while broker/dealers (sell-side) serve as acceptors. A critical function of the FIX engine involves managing network connection, sending, receiving, validating and replaying messages, ensuring sequential and ordered message processing, Persist FIX session state. Additionally, the engine must incorporate logic to handle missing messages for seamless recovery.

FIX Messages

At the heart of this communication lies the FIX message, a structured format that carries vital information between trading platforms and participants. Let's delve into the anatomy, construction, and significance of these FIX messages.

Anatomy of a FIX Message

FIX messages follow a key-value pair format, containing information for a transaction state. Tags correspond to fields in the FIX specification. Each message comprises a header, body, and trailer.

1.Header: Acting as the introduction, the header contains vital details such as the version of the FIX protocol being employed (e.g., FIX.4.2), the total length of the message (excluding the header and trailer), and the message type (e.g., order, execution report). The important tags in FIX message header sections are:
Here are some important tags commonly found in the header section:

2.Body:Serving as the essence of the message, the body carries specific data pertinent to the message type. Depending on the message type, the body may include details such as order quantity, security identifier, price, and timestamps.

3.Trailer:Functioning as the closing segment, the trailer contains a checksum value. This checksum is calculated based on the entirety of the message content and acts as a vital security measure to ensure data integrity during transmission.

Building Blocks: Tags and Values

Each FIX message is a sequence of tag-value pairs, separated by a special character (SOH - Start of Header). Tags are numerical identifiers representing specific data points (e.g., tag 8 represents BeginString, tag 55 represents Symbol). Values correspond to the data associated with each tag. For instance, the tag-value pair "55=MSFT" indicates the message pertains to the security with the symbol "MSFT" (Microsoft).

A FIX message adheres to a standard format, commencing with the header, followed by the message body fields, and concluding with the trailer. The header typically includes tags like BeginString (tag #8), BodyLength (tag #9), and MsgType (tag #35), while the trailer culminates with the CheckSum (tag #10).

Field Components

The tag value pair represent a Field. Each FIX message is composed of a sequence of such pairs, tag being the field and value being the value associated with that field in the pair. Each tag-value pair is delimited by an ASCII control character i.e. 0X01. Each tag has its own meaning. The definition of a field within a FIX message comprises four key components:

Name: This provides a human-readable description of the field's purpose within the FIX protocol. It acts as a label, offering clear context for what the field represents.

Number(Tag): Each field is assigned a unique numerical identifier known as a tag. Tags are integral to FIX messaging, enabling standardized communication and interoperability between different systems and counterparties. For instance, the tag "8" represents the BeginString field in FIX protocol specifications.

Data Type: The data type specifies the format and nature of the data contained within the field. Common data types in FIX messaging include strings, integers, floats, dates, and more. Understanding the data type is essential for accurately parsing and interpreting the field's value. In the example of the BeginString field, the data type is "String," indicating that the value represents a textual string.

Value: The The actual value associated with the field in a particular message instance conveys specific information relevant to the message context. Values are often delimited by ASCII control characters, such as 0X01, for clear demarcation within the message. For instance, the value "FIX.4.4" in the BeginString field indicates the protocol version being utilized, providing essential information for message processing and interpretation.

Let's examine the BeginString field as an example to elucidate the concept of field definitions:

Name: BeginString
Number: 8
Data Type: String
Value: FIX.4.4

Sample FIX Message and Interpretation

Let's examine a sample raw FIX message and decipher its contents:

Another Example

In this example:

Tag 8 represents the FIX protocol version.
Tag 9 denotes the length of the message.
Tag 35 indicates the message type (e.g., 'A' for Logon).
Tags like 49 and 56 may represent sender and target identifiers, respectively.
Tag 10 serves as the checksum to ensure data integrity.

Calculating Body Length

Determining the length of the body is crucial for processing FIX messages accurately.

Here's a step-by-step guide to calculating the body length:

1. Start counting characters from the beginning of the message, including the tag 35 field.
2. Continue counting until you reach, but do not include, the tag 10 (Checksum) field.
3. Include all characters, including SOH delimiters, in your count.

For example:

In this example:

We start counting from the beginning, including tag 35 (MsgType).
We continue counting until we reach, but do not include, tag 10 (Checksum).
The total count, including SOH delimiters, is 65 characters.

Therefore, the body length of this FIX message is 65.

Calculating Checksum – Ensuring Data Integrity

The checksum serves as a vital component in FIX messages for ensuring data integrity during transmission. By validating the checksum at the receiving end, parties can verify that the transmitted message has not been corrupted or tampered with en route. This verification mechanism enhances the reliability of financial transactions and minimizes the risk of errors or malicious interference

The checksum is computed by summing up the ASCII values of all bytes up to the checksum field and taking the remainder when divided by 256.

Let's illustrate the checksum calculation with an example:

Suppose the calculated checksum sum is 274. To transform this into a modulo 256 number, we perform the operation: 274 % 256 = 18. Therefore, the checksum value to be transmitted is 18.

In the FIX message, the checksum field is represented by the tag "10=". Thus, the checksum value 18 would be transmitted as "|10=018|".

Repeating Groups

FIX messages may contain repeating groups, allowing for the repetition of fields within a defined group. These groups are delimited by specific tags and enable the efficient conveyance of nested or repetitive information.

Example: Consider the following representation of a repeating group within a FIX message:

384=2372=6385=R372=7385=R

In this example, the repeating group is delimited by tags 372 and 385. Each repetition of the group is separated by the tag 372, serving as a delimiter indicating the start of a new instance.

Key Concepts

Field Repetition: Fields within a repeating group can be repeated multiple times to convey varying instances of related data.

First Field Requirement: The first field within a repeating group is mandatory and serves as a delimiter to indicate the start of each repetition.

NoXXX Field: This field specifies the number of instances of the repeating group and precedes the actual content of the group.

Required Fields: If a field within a repeating group is marked as required, it must appear in every instance of that group.

Nested Repeating Groups: Repeating groups can be nested within other repeating groups, allowing for multi-level nesting to represent complex data structures.

FIX Session vs Admin Messages

FIX messages can be categorized into two main types administrative messages and application messages, each serving distinct purposes within the trading ecosystem:

1. Administrative Messages:

Administrative messages are primarily concerned with the management and maintenance of the FIX session between trading parties. These messages handle basic administrative tasks necessary for establishing, maintaining, and terminating communication channels. Key examples of administrative messages include:

Logon (35=A): The Logon message is the initial message sent by a trading party to authenticate itself with the FIX server and establish a data transfer session. It serves as the starting point for communication between counterparties, ensuring that both parties are properly identified and authorized to participate in the session.

Heartbeat (35=0):Heartbeats play a crucial role in maintaining the health and integrity of FIX sessions by verifying that the communication channels between counterparties are operational and responsive.

Logout (35=5):The Logout message signals the orderly termination of the FIX session and indicates that the trading parties are disconnecting from the trading server. It serves as a formal notification of session closure, allowing both parties to perform any necessary cleanup or finalization tasks before ending the communication session.

Resend Request (35=2): The Resend Request message is utilized to request the re-transmission of lost or out-of-sequence FIX messages during a session. Typically, the FIX Engine that detects a sequence gap or missing message sends the Resend Request to prompt the re-transmission of specific messages. When re-sending messages, the sending FIX Engine may assess factors like message relevance, timeliness, and market dynamics to avoid re-transmitting stale or outdated data.

Test Request (35=1): The Test Request message is employed to verify the operational status and responsiveness of the counterparties' FIX Engines. A FIX Engine sends the Test Request to prompt its counterpart to generate a Heartbeat message in response, confirming the active status of the communication channel. The TestReqID field (tag 112) included in the Test Request serves to confirm that the subsequent Heartbeat response is specifically triggered by the Test Request, rather than a routine timeout. Upon receiving the Test Request, the opposing FIX Engine responds with a Heartbeat message containing the TestReqID, affirming the active status of the communication line.

Sequence Reset Request (35=4): The Sequence Reset message is utilized to synchronize and reset the incoming sequence number on the opposing FIX engine, especially in scenarios where message sequence integrity is compromised or requires adjustment.

Modes of Operation

Sequence Reset - Gap Fill (GapFillFlag = 'Y'): This mode is employed when there is a need to fill the gaps caused by missing messages or selectively omitted messages during Resend Request processing. It allows the sending FIX engine to transmit only essential or relevant messages to fill the sequence gaps, avoiding the re-transmission of unnecessary administrative or session-level messages.

Sequence Reset - Reset (GapFillFlag = 'N' or not present): This mode should be used sparingly and only in extreme cases, such as catastrophic failures or disasters that cannot be resolved through Gap Fill mode. It resets the message sequence entirely, effectively restarting the sequence numbering from a designated point, which can have significant implications and should be used with caution.

Administrative messages play a vital role in ensuring the integrity and stability of the FIX communication infrastructure, facilitating secure and reliable data exchange between trading entities.

2. Application Messages:

Application messages constitute the core of FIX communication, conveying essential business information related to trade orders, executions, market data, and the current state of orders. Unlike administrative messages, which focus on session management, application messages directly impact trading decisions and operational activities. Key examples of application messages include:

New Order Single (35=D): Initiates a new order request, indicating the user's desire to place a trade in the market. This message includes essential order details such as security identifier, order type, quantity, and price.

Execution Report (35=8): Provides detailed information about the status of executed trades, canceled orders, or order modifications. Execution reports convey critical trade execution details, including execution price, quantity, and order status.

Market Data Request (35=V): Subscribes to real-time market data feeds, enabling traders to receive updated information on quotes, market depth, and other relevant market metrics.