FIX's age works against the way it's usually discussed. Because the protocol has been stable since the late 1990s, it gets treated as a solved problem — implement the spec, connect to the venue, done. In practice, the spec is the easy part. Almost every real connectivity issue shows up in the space between what FIX defines and what a specific venue actually does with it.
That gap is wide, and it's wide by design. FIX is a framework for building a session and message protocol, not a fully specified wire format — which is exactly why two venues both claiming 'FIX 4.4 support' can require meaningfully different client implementations.
The dictionary is never quite the spec
Every venue ships a data dictionary that extends or restricts the base FIX specification: custom tags for venue-specific order types, required fields the base spec marks optional, enumerated values that don't match the standard list, and message types used in ways the spec didn't anticipate. None of this is a violation of FIX — it's exactly what the protocol was designed to allow — but it means a connectivity layer built against 'the FIX spec' in the abstract will fail against the first real venue it connects to.
The practical consequence is that a connectivity platform needs a per-venue dictionary and mapping layer as a first-class concept, not an edge case handled with conditional logic scattered through the codebase. Treating venue variance as the exception rather than the norm is one of the most common reasons connectivity projects run over schedule — the protocol work finishes on time, and then the integration work with the third real venue reveals how much of the first two integrations was accidentally venue-specific.
A session can look healthy and still be wrong
Heartbeats are not a correctness signal. A FIX session can be exchanging heartbeats on schedule — connection up, latency normal, nothing alerting — while the sequence numbers between client and venue have quietly desynced, or while an order was rejected with a reason code the receiving system didn't surface loudly enough to a human.
This matters because the failure mode isn't a dramatic outage; it's a silent one. An order sits in a state the sending system believes is correct and the venue does not agree with, and nothing in a naive transport-level monitoring setup catches it. Catching it requires treating sequence number state, message acknowledgment, and reject handling as application-level concerns that get monitored explicitly — not assuming that a connected session implies a correct one.
Recovery is where the real engineering is
The FIX session protocol includes resend requests and gap fills specifically because disconnections are expected, not exceptional. What the spec doesn't solve for you is what your application does with a resent message: whether it can safely detect that an order acknowledgment it's about to process is one it already handled, whether a fill that arrives twice after a reconnect gets booked twice, and whether your own sequence number state recovers to a value the venue agrees with.
This is where connectivity work and order-management work can't really be separated. A FIX engine that handles session-level recovery correctly but hands duplicate or out-of-order messages to an OMS that isn't built to deduplicate them hasn't actually solved the recovery problem — it's moved it one layer up, to a system that's often less equipped to handle it.
What this means operationally
In practice, connecting to a new venue over FIX means budgeting time for certification against that venue's specific dictionary and behavior, not just confirming the session establishes. It means building a connectivity layer that expects to be configured per counterparty — dictionary, required fields, custom tags, resend behavior — rather than one that assumes a single FIX implementation will work everywhere with minor tweaks.
None of this is a criticism of FIX as a protocol; it's a description of what building reliable connectivity on top of it actually requires. The protocol gives you a consistent session and message framework. Making that framework behave correctly against a specific venue, under real network conditions, with recovery that doesn't silently duplicate or drop anything — that's the engineering work, and it's where most of the actual effort in a connectivity project goes.