Key takeaways
- FIX (Financial Information eXchange) is the industry-standard messaging protocol for orders, executions and market data, created in 1992 by Fidelity and Salomon Brothers.
- Classic FIX uses tag=value text messages with a header, body and checksum; a separate session layer handles logon, heartbeats, sequence numbers and gap recovery.
- FIX 4.2 and 4.4 still dominate bilateral connections; FIX 5.0 SP2 with FIXT 1.1 and today’s FIX Latest separate application and session versions.
- For low latency, the FIX family adds Simple Binary Encoding (SBE) and the FIX Performance Session Layer (FIXP), used by venues such as CME.
- FIX Orchestra makes rules of engagement machine-readable, cutting onboarding time; many crypto exchanges now offer FIX gateways.
What is the FIX protocol?
FIX (Financial Information eXchange) is the industry-standard language trading systems use to exchange orders, executions and market data. It defines what each message contains and how two systems keep a reliable session alive. Created in 1992, FIX now connects most buy-side firms, brokers, banks and many exchanges worldwide.
FIX began as a bilateral project between Fidelity Investments and Salomon Brothers, led by Robert Lamoureux and Chris Morstatt, to replace phone calls for equity orders. It is now maintained by the FIX Trading Community, a non-profit industry body, and covers equities, fixed income, FX, derivatives and digital assets.
FIX matters because it standardises connectivity. A buy-side order management system can connect to dozens of brokers using the same core messages; a broker can onboard a new client by agreeing a short list of custom tags rather than building a new API.
How a FIX message is structured
Classic FIX messages are text strings of tag=value pairs separated by a special delimiter character (SOH). Every message has a header identifying version, length, type, sender, target and sequence number, a body with business fields and a trailer containing a checksum.
A simplified New Order Single (shown with | instead of the SOH delimiter):
8=FIX.4.4|9=148|35=D|34=1080|49=CLIENT|56=BROKER|52=20261110-14:30:00.123|
11=ORD-0001|55=EURUSD|54=1|38=1000000|40=2|44=1.0850|59=0|60=20261110-14:30:00.120|10=xxx|
| Tag | Name | Meaning in the example |
|---|---|---|
| 8 | BeginString | Protocol version (FIX.4.4) |
| 9 | BodyLength | Byte length of the message body |
| 35 | MsgType | D = New Order Single |
| 34 | MsgSeqNum | Session sequence number |
| 49 / 56 | SenderCompID / TargetCompID | Who sent it, who receives it |
| 11 | ClOrdID | Client’s unique order ID |
| 55 | Symbol | Instrument |
| 54 | Side | 1 = Buy |
| 38 | OrderQty | Quantity |
| 40 | OrdType | 2 = Limit |
| 44 | Price | Limit price |
| 10 | CheckSum | Sum of bytes modulo 256 |
Tags 5000–9999 are reserved for user-defined fields, which is why every counterparty publishes rules of engagement listing the custom tags it expects.
Figure 1: Anatomy of a New Order Single
The session layer: logon, heartbeats and recovery
The FIX session layer keeps two systems synchronised over a long-lived connection. Each side numbers its messages, sends heartbeats when idle and requests a resend if it detects a gap. This lets sessions survive disconnects without losing or duplicating orders — the property that makes FIX trusted for real money.
Logon, heartbeats and sequence numbers
- Logon (35=A): the initiator sends credentials and a heartbeat interval (tag 108, often 30 seconds).
- Heartbeat (35=0): sent when no other message has been sent during the interval.
- Test Request (35=1): sent if the counterparty goes silent, forcing a heartbeat in response.
- Logout (35=5): ends the session cleanly.
Resend requests and gap fills
Both sides track the next expected sequence number. If a message arrives with a higher number than expected, the receiver sends a Resend Request (35=2). The sender replays the missing messages, or sends a Sequence Reset (35=4) in gap-fill mode for administrative messages that should not be replayed. This is why FIX engines persist every outgoing message to disk.
Figure 2: A FIX session from logon to logout
Key application messages
A small set of application messages covers most trading workflows: New Order Single, Execution Report, Order Cancel Request, Order Cancel/Replace Request and Order Cancel Reject for order management, plus Market Data Request, Snapshot and Incremental Refresh for market data.
| MsgType | Message | Direction | Purpose |
|---|---|---|---|
| D | New Order Single | Client → broker/venue | Submit an order |
| 8 | Execution Report | Broker/venue → client | Acknowledge, fill, cancel, reject |
| F | Order Cancel Request | Client → broker/venue | Cancel an order |
| G | Order Cancel/Replace Request | Client → broker/venue | Modify price or quantity |
| 9 | Order Cancel Reject | Broker/venue → client | Refuse a cancel or replace |
| V | Market Data Request | Client → provider | Subscribe to prices |
| W / X | Snapshot / Incremental Refresh | Provider → client | Stream market data |
| AE | Trade Capture Report | Either | Post-trade reporting |
The Execution Report is the workhorse: its ExecType and OrdStatus fields describe every state change in an order’s life.
FIX versions: 4.2, 4.4, 5.0 SP2 and FIX Latest
FIX 4.2 (2000) and FIX 4.4 (2003) remain the most widely used versions for order routing. FIX 5.0 introduced the FIXT 1.1 transport, separating session and application versions. Since FIX 5.0 SP2 (2009) the standard has evolved through approved extension packs rather than numbered releases, published today as “FIX Latest”.
| Version | Released | Still common for |
|---|---|---|
| FIX 4.2 | 2000 | Equity order routing, legacy integrations |
| FIX 4.4 | 2003 | Multi-asset routing, FX, many brokers |
| FIX 5.0 SP2 + FIXT 1.1 | 2009 | Venues, post-trade, newer platforms |
| FIX Latest | Continuous (extension packs) | New functionality, regulatory fields |
Because every firm customises FIX, “which version” matters less than the counterparty’s rules of engagement. Two FIX 4.4 connections can look very different in practice.
Encodings and session protocols: FIXML, SBE and FIXP
FIX separates what a message means from how it is encoded. Besides tag=value, the family includes FIXML (XML), FAST (compressed streaming), Simple Binary Encoding (SBE) for low latency and the FIX Performance Session Layer (FIXP) — a lightweight session protocol used with binary encodings.
- Tag=value: human-readable, flexible, slower to parse.
- FIXML: XML encoding, common in post-trade and clearing.
- FAST: template-based compression for market data, now largely legacy.
- SBE: fixed-layout binary messages that can be decoded without copying, designed for nanosecond-level parsing.
- FIXP: a session layer with recoverable, idempotent and unsequenced delivery modes, suited to binary order entry.
CME Group’s iLink 3 order entry and MDP 3.0 market data both use SBE, which shows how far binary FIX has moved into exchange connectivity. For latency comparisons with native protocols, see our protocols section.
FIX Orchestra and machine-readable rules of engagement
FIX Orchestra is a standard for describing a counterparty’s FIX implementation — messages, fields, valid values and workflows — in a machine-readable file. Instead of reading PDF specifications, developers can generate code, test cases and documentation automatically, cutting onboarding time.
Orchestra addresses FIX’s biggest practical problem: customisation. When every broker publishes its rules in a different document format, onboarding is slow and error-prone. With an Orchestra file, both sides can validate messages automatically before going live.
FIX in FX and crypto
FIX is the standard API for institutional FX: liquidity providers, ECNs, prime brokers and aggregators all offer FIX sessions for streaming prices and trading. Many crypto exchanges and prime brokers now offer FIX gateways too, giving institutions a familiar interface alongside REST and WebSocket APIs.
In FX, FIX connects brokers to liquidity providers and to aggregation engines. Market data usually arrives as streaming quotes (MsgType S or W/X), and trades as orders or quote responses. In crypto, FIX gateways appeal to institutions because they reuse existing OMS and EMS integrations, although REST and WebSocket APIs remain more common for retail-facing venues.
Getting started: engines, testing and certification
Most firms use a FIX engine rather than writing the session layer themselves — open-source options include the QuickFIX family, while commercial engines add performance, support and monitoring. Every counterparty requires a certification run in a test environment before granting production access.
A typical onboarding path:
- Obtain the counterparty’s rules of engagement (ideally as an Orchestra file).
- Configure the engine: CompIDs, version, heartbeat interval, TLS and IP whitelisting.
- Run certification scripts in the UAT environment — logon, orders, cancels, rejects, resend scenarios.
- Go live with monitoring of sequence gaps, rejects and latency.
Frequently asked questions
What is the FIX protocol?
FIX (Financial Information eXchange) is an open messaging standard used by banks, brokers, exchanges and investment firms to exchange orders, executions, quotes and market data electronically. It defines both message content and a session layer for reliable delivery.
Which FIX version should I use?
Use whatever your counterparties support. FIX 4.2 and 4.4 remain the most common for bilateral order routing; newer venues and post-trade workflows use FIX 5.0 SP2 or FIX Latest with the FIXT 1.1 session layer. Each counterparty publishes rules of engagement specifying the version and custom tags.
Is FIX fast enough for high-frequency trading?
Text-based tag=value FIX adds parsing overhead, so latency-critical firms prefer native binary protocols or binary FIX encodings such as SBE with the FIXP session layer. Classic FIX remains the standard for broker, buy-side and many FX connections.
What is a FIX engine?
A FIX engine is software that implements the FIX session layer and message parsing: it manages logon, heartbeats, sequence numbers, resend requests and message persistence, so applications can send and receive orders without handling protocol details.
How is the FIX checksum calculated?
The checksum (tag 10) is the sum of the byte values of every character in the message up to, but not including, the checksum field, taken modulo 256 and written as three digits.
Sources and further reading
- FIX Protocol — standards overview — FIX Trading Community, 2026
- Financial Information eXchange — Wikipedia, 2026
- FIX Orchestra — FIX Trading Community
- Simple Binary Encoding standard — FIX Trading Community
Svetlana Berezhnova is a co-founder of Westernpips and has been a trader since 2007. She has been with the company from its very beginning and is an expert in high-frequency trading and latency-sensitive trading software.
This article is for educational purposes and describes market structure; it is not investment, legal or tax advice. Statistics are attributed to their original sources, which should be consulted for methodology and limitations.
