FIX Doctorsupport@fixdoctor.tech
FIX Knowledge Base

FIX Protocol Overview – How It Works End-to-End

The Financial Information eXchange (FIX) protocol is a messaging standard used for electronic trading. This overview explains the architecture, layers, and message flow that make FIX the backbone of modern trading systems.

FIX Protocol Layers

FIX operates in two main layers:

Session Layer

The session layer manages the connection, authentication, and message sequencing. It handles:

  • Session establishment and logon (MsgType=A)
  • Heartbeat messages (MsgType=0) to keep connection alive
  • Sequence number management (MsgSeqNum tag 34)
  • Session-level rejects (MsgType=3)
  • Logout and session termination (MsgType=5)
  • Test requests and responses

Application Layer

The application layer contains business messages for trading operations. It handles:

  • Order submission (NewOrderSingle, MsgType=D)
  • Order modifications (OrderCancelReplaceRequest, MsgType=G)
  • Order cancellations (OrderCancelRequest, MsgType=F)
  • Execution reports (ExecutionReport, MsgType=8)
  • Market data (MarketDataSnapshot, MarketDataIncrementalRefresh)
  • Business-level rejects

Message Flow Lifecycle

1. Session Establishment

Client → Exchange: Logon (35=A)

Exchange → Client: Logon (35=A)

Both parties exchange logon messages to establish the session. CompIDs are validated, and sequence numbers are synchronized.

2. Heartbeat Exchange

Client ↔ Exchange: Heartbeat (35=0) every 30-60 seconds

Regular heartbeat messages keep the connection alive and confirm both parties are online.

3. Order Submission

Client → Exchange: NewOrderSingle (35=D)

Exchange → Client: ExecutionReport (35=8, ExecType=0=New)

Client submits an order. Exchange acknowledges with an execution report showing the order was received (New status).

4. Order Execution

Exchange → Client: ExecutionReport (35=8, ExecType=F=Trade)

When the order is filled (partially or fully), exchange sends execution reports with ExecType=F and fill details.

5. Order Cancellation

Client → Exchange: OrderCancelRequest (35=F)

Exchange → Client: ExecutionReport (35=8, ExecType=4=Canceled)

Client requests cancellation. Exchange confirms with an execution report showing Canceled status.

6. Session Termination

Client → Exchange: Logout (35=5)

Exchange → Client: Logout (35=5)

Either party can initiate logout. Both parties exchange logout messages to gracefully close the session.

Key FIX Concepts

Sequence Numbers

Every message has a MsgSeqNum (tag 34) that increments by 1. Sequence numbers detect message loss, duplicates, and out-of-order delivery. Gaps indicate missing messages that need to be resent.

CompIDs

SenderCompID (tag 49) and TargetCompID (tag 56) identify the parties in a FIX session. These are configured during onboarding and must match exactly between counterparties.

Message Structure

FIX messages use tag=value pairs separated by a delimiter (typically SOH character). Each message has a header (session-level tags), body (application-level tags), and trailer (CheckSum tag 10).

Rejects

Reject messages (MsgType=3) indicate validation failures. Session rejects occur at the protocol level, while business rejects occur after business rule validation.

FIX Message Format

8=FIX.4.4|9=123|35=D|49=CLIENT|56=EXCHANGE|34=1|52=20231116-10:30:00|

11=ORDER123|55=AAPL|54=1|38=100|40=2|44=150.00|59=0|10=123|

This example shows a NewOrderSingle message with:

  • Header: BeginString (8), BodyLength (9), MsgType (35), CompIDs (49, 56), MsgSeqNum (34), SendingTime (52)
  • Body: ClOrdID (11), Symbol (55), Side (54), OrderQty (38), OrdType (40), Price (44), TimeInForce (59)
  • Trailer: CheckSum (10)

Related Resources

Learn more about FIX protocol: