FIXT And The FIX 5.0 Transport Split

Early versions of the FIX protocol (up through 4.4) bundled two very different jobs into one specification: the session layer, which handles the mechanics of keeping a connection alive (logon, heartbeats, sequence numbers, resending dropped messages), and the application layer, which carries the actual business content (new order, execution report, market data). Because these were tangled together, upgrading one meant effectively upgrading both, even if only the trading message content needed a change.

FIX 5.0 split them apart. FIXT (the FIX Transport protocol) now owns only the session-management layer — connection setup, heartbeats, message sequencing, and resend logic — independent of whatever application content rides on top of it. The application layer (the actual order and execution message types) became a separate, versioned specification that sits on top of FIXT. This means a firm can upgrade its application-level message set (say, to support a new order type) without touching the underlying session protocol at all, or vice versa — a counterparty can run FIXT 1.1 as the transport while exchanging FIX 5.0 SP2 application messages, as long as both sides agree on the pairing during logon.

In practice, most trading counterparties still refer informally to "FIX 4.2" or "FIX 5.0" as if it's one thing, and the FIXT split is mostly invisible in day-to-day order flow — but it matters when negotiating a new connection, since the logon message must specify both the transport version and the application version separately, and a mismatch between the two is a common source of connectivity setup errors.