09 · FIX Protocol Deep Dive: The Common Language of Global Institutional Trading

Domestic futures have CTP; crypto exchanges have REST/WebSocket — but the common language of overseas institutional markets (CME, Interactive Brokers, interbank) is FIX. It is finance's oldest and most widely deployed "text exchange format" — no SDK, no private binary, just a field dictionary and line after line of Tag=Value.

This article explains what FIX is, what messages look like, how the core message types are used, how sessions stay alive and how state stays aligned — ending with selection advice and derivative specs (FAST compression, the crypto exchange landscape).

1. What Is FIX

FIX (Financial Information eXchange) is the de facto standard messaging protocol for global financial trading. Key facts:

A widely repeated saying: FIX is not software or an interface library — it is a "dictionary". It specifies how bytes are encoded, how messages are numbered, how state is represented; how you transport them (direct TCP, dedicated lines, authenticated networks) is each firm's own business.

FIX was born in a world where "every bank had its own private format": in the 90s, connecting to N counterparties meant writing N parsers. FIX's ambition was one format with an industry-maintained field dictionary — an idea later inherited by the XML/JSON era, but in low-latency text messaging FIX remains the old master.

2. Where FIX Sits in the Trading Chain

Strategy / Order Management System (OMS)
        │ internal order intent
        ▼
┌───────────────────────────────┐
│      FIX engine (client side)     │  ← owned by the software company / buy-side
│  message assembly / parsing / session management │
│  sequence maintenance / heartbeat / resend       │
└──────────────┬────────────────┘
               │ FIX connection (dedicated line / authenticated network / public internet + encryption)
┌──────────────▼────────────────┐
│      FIX gateway (counterparty side)   │  ← exchange / market maker / bank / clearing house
│  usually they provide the onboarding docs and test environment │
└──────────────┬────────────────┘
               ▼
     Exchange matching / market maker internals / interbank market

One-line positioning: FIX is the last-mile protocol between your OMS and the counterparty. Inside your own system you can use any stack (message queues, REST, gRPC), but once traffic leaves through institutional channels, the exit is FIX.

Typical users:

3. FIX Message Structure

3.1 Three Sections: Header / Body / Trailer

Every FIX message has exactly three parts (using FIX 4.x as example):

Convention: besides 8 and 35 in the Header, 49/56/34/52 are mandatory Session-layer fields too; 10=CheckSum must be the final field of the entire message — any field appended after it breaks validation.

3.2 Tag=Value Format and a Minimal Readable Example

FIX's encoding rule can be stated in one sentence: each field pair is =, fields separated by SOH (0x01, ASCII 1). For human reading SOH is usually written as |; when decoding, just split on |.

A minimal readable NewOrderSingle:

8=FIX.4.4|35=D|49=SENDER01|56=TARGET01|34=7|52=20260816-10:00:00.000|11=ORD10001|55=ESU6|54=1|60=20260816-10:00:00.000|38=2|40=2|44=4100.50|10=092

A very practical engineering point: the | is display-only; on the wire the bytes are \x01 (SOH). A raw SOH must never appear inside string values, and text values must not contain = either (use another separator). The classic rookie mistake is stuffing text containing | into a Value.

3.3 CheckSum

The 10=CheckSum algorithm: sum the ASCII codes of every byte in the whole message (from 8= through the last SOH before the trailer), take modulo 256, format as 3 decimal digits (zero-padded):

checksum = sum(all bytes) % 256, output like "092"

• The calculation excludes 10= itself but includes every field's equals sign and SOH.
• Compute the checksum before parsing the body — messages failing checksum must be dropped (usually a sign of packet splits/merges or mismatched field dictionaries).

3.4 Session Layer vs Application Layer

FIX splits concerns into two layers, and this is where integrators most often get confused:

The two layers must be implemented separately: when the Session layer breaks (sequence mismatch, dead heartbeats), it takes business down with it — so make the Session layer robust first (reconnect, resend, sequence persistence), then talk business logic.

4. Core Message Types

4.1 35=D NewOrderSingle (Placing an Order)

Required fields for ordering:

4.2 35=8 ExecutionReport (Fill Report)

The report is FIX's most complex message: every single status change of an order pushes a new 35=8, carrying dual states 39=OrdStatus and 150=ExecType. Key fields:

Engineering iron rule: dedupe reports by 17=ExecID; trust status from 39=OrdStatus. After reconnects and resends the same report may arrive twice; identical ExecID means drop the duplicate.

4.3 35=F OrderCancelRequest and 35=G Replace

4.4 35=A Logon (Login)

The only entry into a Session; required items:

5. Session Lifecycle

       Client                                  Counterparty
         │                                      │
         │──────── 35=A Logon (108=30)────────▶│
         │◀─────── 35=A Logon (with peer seq)─────│
         │                                      │
   ┌─────▼─────┐  normal flow: messages themselves keep alive ┌─▼─────┐
   │   Logged in    │◀────────────────────────────▶│ Logged in │
   │           │  idle > N seconds → send 35=0 heartbeat   │       │
   └─────┬─────┘  no response within peer's 35=0 window →          └─┬─────┘
         │        send 35=1 TestRequest probe        │
         │        still no response → disconnect + reconnect          │
         │                                      │
         │──────── 35=5 Logout (closing)──────────▶│
         │◀─────── 35=5 Logout ──────────────────│
         ▼                                      ▼

Three core mechanisms:

1. 34=MsgSeqNum (message sequence number): every message increments within the session; both sides track "what I've sent" and "what I expect from you". Receiving 34 larger than expected → send 35=2 ResendRequest; smaller than expected → duplicate message, discard directly or handle as Gap Fill.
2. Heartbeat interval: negotiated at login via tag 108 (commonly 10s/30s/60s, per counterparty requirements). Send a Heartbeat proactively when idle past the interval; both sides must hear from the other before timeout (any application message counts as a heartbeat), otherwise send TestRequest; if that times out too, declare disconnection.
3. Logout: at normal close or shutdown, send 35=5 before dropping the connection; an abrupt goodbye leaves a hung Session on the counterparty side, which may reject your reconnect or force a sequence reset.

Sequences are the lifeblood of a FIX session: they must be persisted (to disk/database). After a crash-restart you resume from the previous number, not back to 1 — otherwise the counterparty concludes "messages were lost" and demands a full resend.

6. Order Status and ExecType

Every order change manifests as a 35=8, where 39=OrdStatus and 150=ExecType are two easily confused fields that must be read together:

How to read them (one sentence): 39 describes "what the order looks like now"; 150 narrates "which change this message reports". E.g., after sending a cancel you first receive 150=6 PendingCancel, and only when the 39=4 Canceled report follows is the cancel actually successful; if 150=6 is followed by 35=9 OrderCancelReject, the cancel failed and the order lives.

• ExecType=8 (Rejected) and ExecType=4 (Canceled) must not be conflated: Rejected means "never became an order", Canceled means "became an order and was then canceled".
• On partial fills, 32/31 (LastQty/LastPx) update per fill and 14/151 (CumQty/LeavesQty) follow — use 14 and 151 for remaining quantity; don't accumulate 32 yourself (resends would double-count).

7. FIX Pros and Cons

7.1 Advantages

7.2 Disadvantages

7.3 Versus Exchange Proprietary APIs

7.4 When You Actually Need Direct FIX Connectivity

• The counterparty only offers FIX (CME and other exchanges, most overseas brokers, interbank).
• You need one codebase for multiple markets: unify the OMS egress over FIX, hide market differences in configuration.
• You need institution-grade reliability semantics (sequence resend, reconciliation, audit): REST polling can't provide these.
• Not needed: domestic futures counters only (use CTP), crypto-only (official REST/WS is simpler) — FIX isn't "more advanced", it's "a requirement of a different market".

8. Derivative Specs: FAST and the Crypto Landscape

8.1 FAST (FIX Adapted for STreaming)

• What it is: a compression encoding spec from the FIX Protocol organization for market data/high-throughput scenarios, using templates (XML describing field encoding) + bitmaps to shrink payloads dramatically — market data volume compressed to a tenth of text FIX or lower.
• Where it's used: real-time market data direct feeds at CME etc.; order acknowledgments mostly remain plain FIX.
• Engineering cost: template management, delta encoding (values only sent when changed from prior field), out-of-order recovery are all new complexity — FAST isn't "readable and done"; the decoder must strictly match their templates.
• Concept check: FAST is an encoding layer inside the same protocol family, not a new protocol; confirm upfront whether the counterparty wants "FIX Session + FAST market data" or plain FIX.

8.2 Crypto Exchanges' Current FIX Support

Characteristics of crypto FIX:

• Authentication is usually a variant of "API Key + pre-shared secret/signature", not traditional CompID password pairs — read their docs carefully before integrating.
• Price precision, tick sizes, and order type enums differ entirely from domestic conventions; field mapping must be done item by item.
• For most individuals and small/mid teams, official REST/WebSocket remains the better choice; FIX is merely one option on the "institutional channel" menu.

Risk Warning