Introduction
The financial markets all around the world are executing trillions of dollars of transactions at the speed of light. Ensuring the integrity of each transaction is essential, and FIX protocol was introduced to facilitate each transaction smoothly.
Before FIX, the systems from different parties involved in financial trading, like traders and brokers, couldn’t communicate with one another easily. The orders were placed manually over the phone or using custom-built, slow software. This led to delays, errors, and inefficiencies in trading.
That’s why FIX, or Financial Information eXchange, protocol was introduced that provided a common language to facilitate financial transactions. It acts as a universal translator, which converts the complicated jargon used in trading into a language that every system can understand.
What is Financial Information eXchange (FIX) Protocol?
The Financial Information eXchange (FIX) was developed in 1992 by a group of market participants led by the FIX Trading community. It is a text-based electronic communication protocol for the international real-time exchange of information related to trading of financial instruments. It is both flexible and robust, making it the standard protocol for global trading platforms.
Here’s an example of what a FIX message looks like, which hedge funds, mutual funds, banks, and proprietary trading firms send to Brokers (e.g., Morgan Stanley, Goldman Sachs) for executing buy/sell orders:
8=FIX.4.4 | 9=178 | 35=D | 49=SENDER_COMP | 56=TARGET_COMP | 34=1 | 52=20250220-12:30:15.123 | 11=123456 | 55=AAPL | 54=1 | 38=100 | 40=2 | 44=150.50 | 59=0 | 10=128
This translates to a new limit buy order for 100 shares of Apple (AAPL) at $150.50, sent by SENDER_COMP to TARGET_COMP on Feb 20, 2025, at 12:30:15.123 UTC (52=20250220-12:30:15.123)
Another example of a FIX message is:
8=FIX.4.4 | 35=D | 55=TSLA | 54=2 | 38=50 | 40=1
This represents a market order to sell 50 shares of Tesla (TSLA) using FIX version 4.4.
FIX Message Structure
Let’s try to understand the FIX message structure in detail.
All the FIX messages are text only (ASCII text) and follow certain definitions. The contents of a FIX message are put together using fields and their associated value. Each field has its definition, which includes the name, number, data type, and value.
For instance, the field Begin String is associated with number/tag = 8. Let’s break down its definition as per the components:
Name = Begin String
Number/Tag = 8
Data Type = String
Value = FIX4.4
The begin string field indicates what type of FIX protocol version is being used, like FIX 4.2, FIX 4.4, and FIX 5.0. It helps ensure that both the receiver and sender’s systems are compatible and helps the trading systems parse the message easily.
Each message is composed of a sequence of such pairs. The field is the tag, and the value is the description associated with that tag. An ASCII character delimits each tag value, which is 0X01. Also, each tag doesn’t repeat in a single FIX message, except in the case of repeating groups.
To understand the different tags, here’s a FIX message:
8=FIX.4.4 | 9=176 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=35 | 58=EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=35 | 14=0 | 6=0 | 10=128 |
| Tag | Name | Description | Value |
| 8 | Begin String | The FIX version being used | FIX4.4 |
| 9 | BodyLength | Length of the message body (176 characters) | 176 |
| 35 | MsgType | Defines the type of FIX message, like new order or execution report | 8 (Execution Report) |
| 49 | SenderCompID | Each sender has a unique code; like in this, PHLX represents the Philadelphia Stock Exchange | PHLX |
| 56 | TargetCompID | Receiver’s identifier | PERS |
| 52 | SendingTime | Timestamp of message creation (2007-11-23 05:30:00.000 UTC) | 20071123-05:30:00.000 UTC |
| 11 | ClOrdID | Unique order ID assigned by the client | 9990900 |
| 20 | ExecTransType | Specifies how this execution message relates to previous ones, like new, cancel, correct | 3 (Status) |
| 150 | ExecType | Represents the reason for sending this execution report (e.g., new trade, cancelled, pending changes). | E (Pending Replace) |
| 39 | OrdStatus | Represents the reason for sending this execution report (e.g., new trade, cancelled, pending changes). | E (Pending Replace) |
| 55 | Symbol | Security being traded | MSFT (Microsoft) |
| 167 | SecurityType | Defines the category of the traded financial instrument, like stock, bond, etc. | CS (Common Stock) |
| 54 | Side | Specifies whether the order is a buy or sell order. Here, 1 means Buy, 2 means Sell, etc. | 1 |
| 38 | OrderQty | Quantity of the order | 15 |
| 40 | OrdType | Indicates the type of order, like market, limit, or stop. Here, 1 stands for Market Order and 2 stands for Limit Order | 2 |
| 44 | Price | Specifies the price at which the order should be executed (for limit orders). | 35 |
| 58 | Text | Free text description for additional comments or notes. | EQUITY TESTING |
| 59 | TimeInForce | Defines how long the order remains valid. Here 0 means Day Order. | 0 |
| 47 | Rule80A (Order Capacity) | Identifies the type of trader placing the order, like customer and market maker. In this case, C means Customer | C |
| 32 | LastShares | Number of last shares executed. | 0 |
| 31 | LastPx | Price of last executed trade | 0 |
| 151 | LeavesQty | Number of remaining shares that need to be executed | 35 |
| 14 | CumQty | Total executed shares so far | 0 |
| 6 | AvgPx | Average Price of executed trades | 0 |
| 10 | CheckSum | Message integrity check (128). | 128 |
The FIX specification includes over 500+ predefined fields, with some of them being mandatory fields and some being optional fields. The number of mandatory fields varies as per specific message type like. A new order message will have 10-12 mandatory fields, and the execution report will have 8 mandatory fields. Each message can typically contain around 100 fields.
FIX Architecture
FIX protocol is used for automated trading of securities, derivatives, and other financial instruments. To understand how the FIX protocol works, it is essential to know about its architecture and components.
When it comes to FIX architecture, it contains two main layers:
- Session Layer: This layer deals with initialization, maintenance, and termination of connections to deliver high performance. It supports a bi-directional stream of ordered message transfer between two parties. The session layer handles the handshake between the parties, data integrity, message delivery, and sequencing.
- Application Layer: This layer deals with business-specific functions, like order creation, cancellation, replacement, etc. The trade between the parties is handled by this layer, which includes subscribing to market data processes and parsing the trade capture, execution reports.
FIX Methodology
Every trading application would interface with a FIX engine, which is connected to a network of other applications. FIX engine is the computer component that is the real interface between two systems or parties who are talking in FIX language. The FIX engine can be a commercial piece of software licensed by Itiviti, B2Bits or FIX Flyer, or it can be open-source as well, like QuickFix. The network can be:
- Public internet secured using VPN or secure tunnel
- A point-to-point telecom provider, like IPC, or BT Radianz
- A hub-and-spoke FIX network such as NYFIX.
The choice of network doesn’t affect how the FIX messages are constructed.
Messages on FIX protocol can be classified into two types: Session Level called the Admin Messages, and Application Level messages. Session-level messages help in establishing FIX sessions between two engines, and the application messages are for business purposes like NewOrderSingleMessage to send an order via FIX.
The MsgType (Tag = 35) is an important tag in FIX protocol as it is used to identify the type of FIX message. Every FIX message should have a corresponding MsgType; otherwise, the FIX engine will reject those messages by saying they are not valid messages.
A connection between two FIX engines is established, which is called a FIX session. Every FIX session has a pre-agreed host/port and comp ID. A single FIX engine can be used to serve multiple clients on the broker side, so every client is uniquely identified using the combination of IP, port, and comp ID. Comp ID is generated by combining SenderCompID and TargetCompID, which are two separate tags in the FIX protocol.
FIX protocol operates over TCP/IP for reliable transmission. The messages follow a structured sequence of apt communication:
Step 1. Session Establishment (Handshake)
A FIX session needs to be established before sending the actual trade messages. A FIX session is established between the two parties (e.g., a broker and an exchange) to ensure both parties are synchronized and authenticated. The connection is initiated when the sender or broker opens the TCP/IP socket with an exchange, and a logon message (35=A) is sent to authenticate and synchronize. Here’s an example:
8=FIX.4.4 | 35=A | 49=Broker123 | 56=ExchangeXYZ | 34=1 | 52=20250220-12:30:00 | 98=0 | 108=30 | 10=128
Step 2. Message Exchange
After the FIX session is established, the trade messages are exchanged. If the order is accepted, an execution report (35=8) is sent, and if it is rejected, a reject message is sent (35=3).
Step 3. Heartbeat Messages
FIX uses a persistent TCP connection, so both sides need to ensure the session remains open. That’s why Heartbeat messages (35=0) are sent at regular intervals, like every 30 seconds, to keep the connection alive. Here’s an example:
8=FIX.4.4 | 35=0 | 49=Broker123 | 56=ExchangeXYZ | 34=4 | 52=20250220-12:31:00 | 10=128
Step 4. Sequence Number Handling
Every FIX message has a sequence number (Tag=34) to ensure that messages are received in order. However, if a message is lost or skipped, the receiving party detects a gap in the sequence number and sends a request to resend it. It is done using a resend message (35=2). Here’s an example:
8=FIX.4.4 | 35=2 | 49=ExchangeXYZ | 56=Broker123 | 34=5 | 7=3 | 16=4 | 10=128
If there is a duplicate message, it is ignored or flagged.
Step 5. Session Termination
The FIX session is terminated at the end of the trading day or if the connection needs to be terminated using the Logout message (35=5). Here’s an example:
8=FIX.4.4 | 35=5 | 49=Broker123 | 56=ExchangeXYZ | 34=6 | 10=128
Advantages of FIX Protocol in Financial Communication
The FIX protocol is designed to deliver high performance and reliability. Here are the advantages of the FIX protocol:
- It becomes the global standardization as it offers a unique language and framework for the electronic trading ecosystem. It promotes interoperability between buy-side firms, sell-side firms, exchanges, and regulators.
- The adoption of the FIX protocol boosts trading efficiency while reducing costs. It provides a uniform platform for financial trade message exchanges, reducing the errors and time required for trade processing. It reduces the costs as it removes the multiple proprietary systems. Its ability to facilitate direct market access and algorithmic trading reduces costs by supporting strategic order execution.
- It fosters real-time communication and supports transparency within the financial trading community. The real-time transmission of trade orders provides current data to all the parties involved in the trade.
- Since the stakes are high, the FIX protocol incorporates robust security measures, especially in High-Frequency Trading (HFT) environments where security is critical. It uses TLS for encryption over TCP and also supports message authentication and validation.
Challenges with FIX
Just like with everything else, FIX has its fair share of challenges that need to be addressed. The protocol can be complex to implement. In complicated scenarios, the FIX message can become large, adding overhead and it will require optimization.
There are different versions of FIX (FIX 4.0, FIX 4.4, and FIX 5.0), and it can cause compatibility issues. Since this protocol is used in real-time, the security needs to be robust and it can be misused otherwise.
FIX and Blockchain
Some people speculate that blockchain could replace the FIX protocol. However, it’s more likely that blockchain will enhance or complement FIX rather than replace it entirely. Blockchain can settle trades instantly, unlike FIX, which executes orders promptly, but trade settlement in traditional markets takes T+2 days (two business days).
Regardless, blockchain cannot replace FIX because:
- FIX can handle millions of orders per second, while blockchains like Ethereum struggle with congestion.
- HFT firms depend on ultra-low latency (microseconds), which blockchain can’t match yet due to block confirmation times.
The Bottom Line
Consider FIX like WhatsApp for Wall Street, but instead of sending text messages, it sends trades. It is the language of global financial markets that buy-side and sell-side firms, trading platforms, and regulators use to communicate trade information.
Being non-proprietary, open-source, and free, it is being developed to support evolving businesses and market needs, as it forms the basis for executing millions of transactions placed by thousands of firms.
It is being transformed to adapt to new financial instruments, like cryptocurrencies and tokenized assets. Besides, it is being integrated with other technologies, like REST APIs and WebSockets, to provide more flexibility, real-time updates, and easier integration with modern web-based systems.
FIX is the way the world trades, and it will likely remain the industry standard for trading orders. It is an essential component that minimizes trading costs and maximizes efficiency.