The Financial Information Exchange (FIX) Protocol is the standard communication language for electronic trading across global financial markets. It defines how trading firms and exchanges exchange critical data, from placing orders to confirming trades, using a structured system of key-value pairs. This protocol is the underlying mechanism that allows automated, high-speed transactions to occur in modern finance.
What is the FIX Protocol?
The FIX Protocol, or Financial Information Exchange Protocol, is a standardized set of rules governing electronic communication in financial markets. It acts as a universal language, allowing different computer systems around the world to understand each other when exchanging financial information. This is particularly important for order management and order entry systems.
At its core, FIX is a key-value pair language. Every piece of information in a FIX message is represented by a numerical key, known as a tag, and its corresponding value. For instance, a key like 35 might represent the message type, and its value, such as ‘D’, could signify a “New Order” message. Other keys specify details like the stock symbol, quantity, price, the sender’s identity, the target exchange (like CME or ICE), and the time the message was sent. These keys and their potential values are either predefined within the FIX standard or agreed upon by the communicating parties. This structure ensures that all participants interpret trading instructions and data consistently.
How FIX Facilitates Trading Communication
Connecting and communicating using FIX relies on specialized software called a FIX engine. These engines operate on both the client side (e.g., an investment bank) and the server side (e.g., a stock exchange). A FIX engine performs two primary functions to enable electronic trading.
First, it establishes and maintains a connection, or session, with the other party. This is like two people greeting each other and agreeing to start a conversation. An exchange might manage hundreds, or even hundreds of thousands, of these sessions simultaneously with various trading firms globally. A single proprietary trading firm can also maintain multiple sessions with an exchange, often for different software applications.
Second, the FIX engine parses FIX messages. Parsing means decoding the string of key-value pairs into something meaningful and actionable. When a FIX engine receives a message like “35=D”, it decodes this to understand that a new order is being submitted. The engine knows that tag 35 relates to the message type and that ‘D’ specifically means “New Order.” This decoding process turns raw data into structured information that trading applications can use to process transactions or update market data. Both parties in a FIX communication speak the same FIX language, and the engine acts as the interpreter, ensuring each side understands the other’s intentions.
The Structure of FIX Messages
Every FIX message adheres to a consistent structure, comprising a header, a body, and a trailer. This standardized format ensures that all essential information is present and can be processed reliably. Messages are typically formatted as a string of key-value pairs, with each pair separated by a special character, often referred to as a null terminator or a space for readability.
The header contains general information common to all messages. This includes the FIX version being used (e.g., tag 8), a sequence number (tag 34), the sender’s identifier (tag 49), and the message’s send time (tag 52). Other header tags might specify the sender’s sub-ID (tag 50), destination (tag 56), or location (tag 142).
The body is where the specific trading instruction or data resides. Its content varies significantly based on the message type. For example, if a trader wants to define a new, custom trading strategy that does not yet exist on the exchange, they would send a Security Definition Request message, identified by tag 35 having a value of ‘C’. Within the body of such a message, tags like 1028 might indicate if the order is manual (‘Y’) or automated (‘N’). Tag 762 could specify the strategy type, such as ‘combo’ for a call spread. Tag 555 would state the number of “legs” or components in the strategy, for example, ‘2’ for a two-legged spread. Each leg would then have its own set of tags detailing the product code (e.g., treasuries), instrument name (e.g., OCNG1 call strike 137.5), ratio (e.g., 1), and side (e.g., 1 for buy, 2 for sell).
Finally, the trailer typically contains a single tag, tag 10, which represents a checksum. This checksum is a verification mechanism that helps ensure the message was constructed correctly and has not been corrupted during transmission.
Message Types and Communication Layers
FIX messages are categorized into two main layers, each serving a distinct purpose in the trading workflow, and each containing between 10 to 20 different message types.
The Session Layer manages the connection between trading parties. Messages in this layer are about establishing and maintaining communication. A “Logon” message, for instance, initiates a session. A “Heartbeat” message is sent periodically to confirm that both parties are still active and the connection is alive. If heartbeats stop, it signals that the session has likely terminated, and the other party is no longer communicating.
The Application Layer handles the actual business logic of trading. These messages are sent when a trader takes an action, such as clicking a “buy” or “sell” button. Common application layer messages include “New Order” (tag 35=D), “Cancel Order,” “Modify or Replace Order,” “Mass Quote,” and “Mass Quote Cancel.” These messages carry the detailed instructions for trading activities.
When an exchange receives an application layer message, it processes the request and sends a response. This response can either be an acceptance or a rejection. For example, a Security Definition Request (tag 35=C) might be followed by a Security Definition Request message (tag 35=D) from the exchange. This 35=D message can signify either acceptance or rejection. If the message is accepted, it will typically include the ID and name of the newly created instrument. If it is rejected, the 35=D message will contain tag 58, which provides a text explanation for the rejection. Another type of rejection is a session-level reject, indicated by a 35=J message. Understanding these nuances is key to properly handling responses in electronic trading systems.
Understanding FIX Dialects and Customizations
While FIX aims to be a universal language, it is not entirely uniform. Like natural languages, FIX has evolved to include different versions and dialects. This means that while the core protocol remains consistent, specific exchanges or trading platforms may introduce their own customizations or requirements.
Exchange-specific documentation is essential for understanding these variations. It details which tags are required, optional, or conditional for a particular message type on that exchange. For instance, a tag might be marked as ‘Y’, meaning it is required by the standard FIX protocol. However, another tag might be marked ‘Y*’, indicating it is required by a specific exchange (like CME) but not by the broader FIX standard. These ‘Y*’ tags are akin to “slang” that a particular exchange understands and requires, even if it is not part of the common FIX grammar. Other tags might be ‘N’ (not required) or conditional, meaning they are only needed under certain circumstances.
For example, when creating an instrument with multiple components, such as a call spread, an exchange like CME might require tag 555, which specifies the “leg count.” This tag could be a ‘Y*’ requirement for CME, meaning it is mandatory for their system, even if it’s not universally required by all FIX implementations. CME specifies that an instrument creation request can have up to 40 legs. These dialects mean that software developers must carefully consult an exchange’s specific FIX documentation to ensure their systems communicate correctly and comply with all trading rules.
