FIX Protocol and Broker API Integration for Quants

FIX protocol (Financial Information eXchange) is the industry standard messaging language for electronic trading — orders, cancels, replaces, fills, and drop copies. Retail-style REST APIs are fine for research and small size; institutional execution usually means FIX sessions to brokers and venues. This article maps FIX concepts to practical OMS design and contrasts them with crypto/REST stacks like CCXT.

Why FIX exists

Exchanges and brokers need a common schema for:

NewOrderSingle, OrderCancelRequest, OrderCancelReplace
ExecutionReport (acks, partials, fills, rejects)
Market data (in some deployments)
Allocation / drop copy for middle office

FIX is text tag=value fields (55=AAPL, 54=1, 38=100). Versions (4.2, 4.4, 5.0) and dictionaries vary by broker — the spec is standard; the dialects are not.

Session layer

A FIX connection is a session with sequence numbers:

Logon → heartbeats → orders/executions → Logout

Concern	Why it matters
Sequence gaps	Missed fills; must ResendRequest
Heartbeats	Detect dead sockets before you think you are flat
CompID	Sender/target IDs identify your desk
Encryption / VPN	Usually private lines, not public internet

Losing sequence sync mid-day is an ops incident — not a code comment.

Order state machine

Your OMS must track states more carefully than a backtest:

pending_new → new → partially_filled → filled
                ↘ rejected
cancel_pending → canceled
replace_pending → replaced

class OrderState:
    PENDING_NEW = "pending_new"
    NEW = "new"
    PARTIAL = "partial"
    FILLED = "filled"
    CANCELED = "canceled"
    REJECTED = "rejected"

def apply_exec_report(state: str, exec_type: str) -> str:
    """Tiny illustrative mapper — real OMS tables are richer."""
    mapping = {
        ("pending_new", "reject"): OrderState.REJECTED,
        ("pending_new", "new"): OrderState.NEW,
        ("new", "partial_fill"): OrderState.PARTIAL,
        ("partial", "partial_fill"): OrderState.PARTIAL,
        ("partial", "fill"): OrderState.FILLED,
        ("new", "fill"): OrderState.FILLED,
        ("new", "canceled"): OrderState.CANCELED,
    }
    return mapping.get((state, exec_type), state)

Never assume a cancel succeeded until the ExecutionReport says so. Live vs paper gaps often start here (shadow trading).

REST/WebSocket vs FIX

	REST / WS APIs	FIX
Setup	Fast, key-based	Certs, sessions, conformance tests
Throughput	Rate-limited	Built for order flow
Partial fills	Varies	First-class
Institutional brokers	Limited	Standard
Crypto	Dominant	Rare (some venues emerging)

Many shops: research on vendor APIs → production equities/futures via FIX → crypto via exchange WS. Unify in an internal order schema so strategies do not care.

Drop copy and reconciliation

Drop copy sessions receive execution reports for booking and risk without sending orders. Use them to:

Reconcile OMS vs broker positions
Feed TCA
Detect missing fills after disconnects

End-of-day: broker files vs OMS vs custodian. Breaks are normal; uninvestigated breaks are how phantom P&L appears.

Engineering checklist for go-live

Conformance test suite against broker certification environment
Kill switch: cancel-all on disconnect / risk breach

(live deployment)

Idempotent clOrdID strategy (never reuse IDs)
Clock sync (NTP) for latency metrics
Simulate rejects, partials, out-of-order exec reports
Rate limits and throttling so you do not cancel-spam

Mapping strategy intents

Strategies speak intents; OMS speaks FIX:

intent: "buy 10k ADV participation VWAP"
  → child orders over time → NewOrderSingle messages

Keep execution algos in a separate module. Strategies should not build FIX tags.

Key takeaways

FIX is the institutional language for orders and fills — session + sequence disciplined
Model a real order state machine; never invent fills from silence
REST is fine for research; production multi-asset books often need FIX
Drop copy and reconciliation catch the bugs that wipe alpha
Strategies emit intents; OMS/FIX adapters own the wire protocol