FIX Protocol

FIX messages are composed of a sequence of tag=value pairs delimited by the SOH character (ASCII 001). Each numeric tag maps to a specific field name defined in the FIX dictionary. For example, 35=D indicates a New Order Single message, while 44=150.25 sets the limit price. This simple, non-proprietary structure ensures language-agnostic parsing and backward compatibility across protocol versions, allowing systems written in C++, Java, or Python to communicate seamlessly without complex serialization frameworks.

FIX operates on a dedicated session layer above TCP/IP that guarantees ordered, once-and-only-once message delivery. Each session is identified by a unique combination of SenderCompID and TargetCompID. The protocol uses sequence numbers (tag 34) on every message to detect gaps, duplicates, or replays. Heartbeat messages (tag 35=0) maintain session liveness during idle periods. If a disconnection occurs, both parties negotiate the last successfully processed sequence number to resend missed messages, ensuring zero data loss during failover.

FIX defines a rigorous order lifecycle with explicit message types for each state transition. Key states include:

• New (39=0): Order acknowledged by broker
• Partially Filled (39=1): Some quantity executed
• Filled (39=2): Order fully executed
• Canceled (39=4): Order removed from book
• Rejected (39=8): Order refused with reason code

Execution reports (tag 35=8) communicate fills, partial fills, and state changes in real time, providing a complete audit trail from order inception to final settlement.

The FIX protocol reserves a range of user-defined tags (5000-9999) that allow counterparties to extend the standard dictionary with proprietary data without breaking interoperability. Institutional brokers use these custom fields to transmit specialized analytics, algorithmic trading parameters, or compliance metadata alongside standard order flow. The protocol also supports custom message types via tag 35 values in the U-series range, enabling private negotiation of bespoke workflows while maintaining the core session and administrative message infrastructure.

For high-frequency trading environments where bandwidth and latency are critical, FIX messages can be encoded using the FAST (FIX Adapted for STreaming) protocol. FAST applies field-level encoding templates that eliminate redundant tag transmission and apply binary compression algorithms to numeric values. A FAST template defines field operators like delta, copy, and increment that encode only the difference from a previous value or a constant. This reduces message size by over 90% compared to tag-value text encoding, making FIX viable for market data feeds exceeding millions of messages per second.

FIX Orchestra provides a machine-readable XML schema that formally describes a counterparty's FIX implementation, including supported messages, fields, enumerations, and workflow scenarios. Instead of exchanging static PDF specification documents, firms can publish an Orchestra file that automated onboarding tools consume to generate code stubs, validate messages, and configure session parameters. This eliminates manual integration errors and reduces the time to onboard a new trading counterparty from weeks to hours by standardizing the representation of implementation rules.

The transport-level connection between two counterparties that manages message delivery, sequencing, and recovery. A FIX session is identified by the combination of SenderCompID and TargetCompID.

• Logon (MsgType A): Initiates the session with heartbeat interval and sequence number negotiation
• Heartbeat (MsgType 0): Maintains session liveness during idle periods
• ResendRequest (MsgType 2): Triggers recovery of missed messages using sequence number gaps
• Logout (MsgType 5): Gracefully terminates the session

Sequence numbers are strictly monotonically increasing, ensuring no message loss or duplication.

The business-layer messages that encode the full lifecycle of a securities transaction, from order origination to fill confirmation.

• NewOrderSingle (MsgType D): The primary order entry message containing symbol, side, quantity, price, and order type
• ExecutionReport (MsgType 8): Confirms order receipt, partial fills, full fills, or cancellations with ExecType field indicating the event
• OrderCancelRequest (MsgType F): Requests cancellation of an outstanding order, referenced by OrigClOrdID
• OrderCancelReplaceRequest (MsgType G): Modifies an existing order's price or quantity while preserving priority

Each order is uniquely identified by the client-assigned ClOrdID, which persists across all subsequent execution reports.

Real-time streaming messages that disseminate quote and trade information from exchanges to market participants.

• MarketDataSnapshotFullRefresh (MsgType W): Provides a complete image of the order book at a given depth level
• MarketDataIncrementalRefresh (MsgType X): Streams delta updates for bid/ask changes and trades, minimizing bandwidth
• MarketDataRequest (MsgType V): Subscribes to specific instruments and data types with MDEntryType specifying bid, offer, or trade

Incremental refreshes use MDUpdateAction to indicate whether an entry is new, changed, or deleted, enabling efficient order book reconstruction.

A FIX engine is the software component that serializes, transmits, and deserializes FIX messages, abstracting the protocol complexity from trading applications.

• Message Store: Persists outbound and inbound messages to disk for guaranteed delivery and recovery
• Sequence Number Management: Tracks expected inbound and outbound sequence numbers, triggering resend requests on gaps
• Session State Machine: Manages transitions between disconnected, connected, logged-on, and recovery states
• Validation Layer: Enforces message schema compliance, required field presence, and data type constraints before transmission

High-performance engines process millions of messages per second using zero-copy parsing and kernel bypass networking.

The protocol has evolved through multiple versions, with FIX 4.2, FIX 4.4, and FIX 5.0 SP2 being the most widely deployed in production environments.

• FIX 4.2: Introduced support for advanced order types and allocations; remains the baseline for many equity markets
• FIX 4.4: Added support for algorithmic trading parameters, strategy tags, and enhanced post-trade allocation models
• FIX 5.0 SP2: Modularized the specification into transport and application layers; introduced FIXT 1.1 session layer for transport independence
• FIX Orchestra: Machine-readable specification format enabling automated code generation and schema validation

Backward compatibility is maintained through version negotiation during the Logon exchange.

Messages are encoded as a sequence of tag=value pairs delimited by the SOH (Start of Header) character (ASCII 0x01). This human-readable format enables straightforward debugging while maintaining parsing efficiency.

• Tag 35 (MsgType): Identifies the message type and determines the expected body structure
• Tag 55 (Symbol): The ticker symbol of the instrument being traded
• Tag 54 (Side): Indicates buy (1) or sell (2)
• Tag 38 (OrderQty): The quantity of shares or contracts
• Tag 44 (Price): The limit price for the order

Body length is specified in Tag 9 (BodyLength) to enable efficient message framing without scanning for delimiters.