FIX Protocol Overview and Tutorial

FIX (Financial Information eXchange) is the messaging standard used by banks, broker-dealers, exchanges, and investment managers to communicate trade information in real time. If your system sends or receives orders electronically, it's almost certainly speaking FIX.

The protocol dates back to 1992, predating XML, REST, and most of the infrastructure the industry now takes for granted. That's part of why it looks the way it does - tag=value pairs over a raw TCP socket - but it's also why it's battle-tested in ways that newer protocols aren't. FIX handles sequence numbering, gap detection, session recovery, and message resend out of the box.

FIXSIM is a web-based FIX simulator used by QA teams, OMS/EMS vendors, and broker-dealers to test FIX connectivity without a live counterparty. If you're here to learn the protocol before building or testing, you're in the right place.

History

FIX was created in 1992 to replace telephone calls and proprietary file formats for communicating equity trades between investment managers (buy side) and execution brokers (sell side). Before FIX, every broker had their own format. FIX standardized the conversation.

Worth noting: FIX predates XML (1998) and Google (1998). People new to the protocol often ask why it isn't XML-based or why it has so many versions. The answer is the same as for most entrenched financial infrastructure - it was designed under the constraints of its time, it worked, and replacing it is harder than extending it. There is an XML-based variant (FIXML), but raw FIX tag=value remains dominant in production.

Connectivity

A FIX session runs over a point-to-point TCP/IP socket. One side is the Initiator (typically the buy-side firm or OMS), the other is the Acceptor (typically the broker or trading venue). Before any FIX messages can be exchanged, the TCP connection must be established. A telnet to the host and port is enough to verify basic reachability.

Transport layer options include:

• Local loopback (for development and testing)
• LAN / intranet
• Internet with TLS/SSL
• Private leased lines (common at large institutions)

Starting with FIX 5.0, the protocol formally separated the transport layer from the application layer, allowing FIX messages to run over alternative transports like message queues. In practice, most production sessions still use the built-in TCP session layer.

FIX Versions

Production FIX starts at version 4.0. Earlier versions have been deprecated. The version used on any given session depends on what the counterparty supports - there's no universal upgrade path.

FIX 4.0

Legacy equity trading. Still in use at some older institutions but declining. Order cancel and correct workflows have known ambiguities in the spec.

FIX 4.2 - Released 2000

The most widely deployed FIX version for equity and equity derivatives (futures and options). Cancel and replace workflows are clearly defined. Also used for simple FX spot and forward trading.

FIX 4.4 - Released 2003

The version of choice for fixed income and more complex FX. Also used for equity where counterparties have moved off 4.2. FIXSIM supports FIX 4.4 for all order types and execution workflows.

FIX 5.0 / 5.0 SP1 / 5.0 SP2

Introduced transport layer separation and FIXT 1.1 as the session protocol. Used for OTC products including credit default swaps (CDS) and interest rate swaps (IRS). Service packs added support for additional asset classes and message types.

Session Handshake

Once the TCP connection is up, the Initiator sends a Logon message (35=A) to the Acceptor. The Acceptor validates the SenderCompID (tag 49), checks the incoming sequence number, and either responds with its own Logon (session accepted) or closes the socket (session rejected).

After logon, both sides send periodic Heartbeats (35=0) at the interval negotiated in the Logon message (HeartBtInt, tag 108 - typically 30 or 60 seconds). Heartbeats confirm not just that the socket is open, but that the counterparty is actively processing messages. If a heartbeat is missed, a TestRequest (35=1) is sent. If that goes unanswered, the session is considered lost and disconnects.

Message Delivery and Sequence Numbers

Every FIX message carries a MsgSeqNum (tag 34) that increments by one for every message sent. The session starts at sequence number 1 on Logon and counts up from there across the trading day. Both sides track the sequence numbers they've sent and received.

If a gap is detected - say messages 4 through 11 were not received - the receiving side issues a ResendRequest (35=2) for the missing range. No subsequent messages are processed until the gap is filled. This is the FIX protocol's built-in guaranteed delivery mechanism and it operates at the session layer, below the application layer.

At the start of each trading day, sequence numbers typically reset to 1 via a Logon with ResetSeqNumFlag (tag 141=Y). Some firms keep sequence numbers running across days - this is a configuration choice negotiated with the counterparty.

Application Message Types

The session layer (Logon, Heartbeat, ResendRequest, etc.) handles connectivity. The application layer handles business logic. Common application message types:

• New Order Single (35=D) - Submit a new order for execution
• Execution Report (35=8) - Acknowledge, fill, cancel, or reject an order
• Order Cancel Request (35=F) - Request to cancel an open order
• Order Cancel/Replace Request (35=G) - Modify price or quantity of an open order
• Order Cancel Reject (35=9) - Broker unable to process cancel or replace
• New Order Multileg (35=AB) - Complex trades with multiple legs
• Allocation Report (35=AS) - Post-trade account allocation breakdown

Each message type has a defined set of required and optional tags. Required tags that are missing or malformed will typically result in a reject or a session-level error.

Custom Tags

FIX allows custom tag ranges (above 5000 for user-defined fields) for firm-specific data. Broker-dealers commonly use custom tags to pass algorithmic trading parameters - algorithm name, strategy type, urgency level - alongside a standard New Order Single.

Any counterparty that needs to process custom tags must explicitly support them in their implementation. FIX certification usually includes testing that custom tags are handled correctly on both sides.

Testing FIX Connections

When building or certifying a FIX integration, you need a counterparty to test against before going live. FIXSIM acts as that counterparty - it accepts your FIX connection, responds to orders with configurable execution reports, and lets you test edge cases that would be hard to reproduce against a live broker.

Things you can test with FIXSIM:

• Session establishment and logon/logout workflows
• Order submission, partial fills, full fills, and rejections
• Cancel and replace handling
• Sequence number gap detection and resend request handling
• High-volume and stress testing
• Custom tag processing