Liquidity
FIX connectivity without the production surprises
FIX has been the standard for institutional order flow for a long time, and every venue implements it slightly differently. The protocol is rarely what goes wrong. What goes wrong is the assumption that two FIX implementations will agree on everything, discovered for the first time in production.
Where FIX sessions usually break
Most connectivity incidents fall into a short list of categories, and almost all of them can be found in testing if someone looks for them deliberately.
Symbol and precision mismatches between what the venue sends and what the platform expects
Different interpretations of time-in-force and order expiry
Sequence gaps after a disconnect that are not recovered cleanly
Rate limits on the venue side that are hit during bursts
Rejections that arrive in a format the receiving system does not parse
Certification is the cheapest insurance
Every new session should be certified against a test environment before it carries real flow, and the test should include the unhappy paths: rejections, cancellations, partial fills, amendments of partially filled orders, and a disconnect in the middle of an order. A certification that only exercises a clean buy and sell proves very little.
Recovering order state after a disconnect
The hardest moment in FIX connectivity is reconnection. Orders may have been filled while the session was down, and the platform needs to know their true state before it does anything else. Sequence recovery handles the messages that were missed, but some venues also require their order history to be queried directly, page by page, within their rate limits, to rebuild state reliably.
Whatever the mechanism, the platform should treat an order's state as unknown until it has been confirmed, and say so to the people watching the console.
Keeping the logs
Every inbound and outbound message should be retained with timestamps. When a counterparty disputes a fill, the conversation should be a comparison of two logs rather than of two memories. Logs are also the fastest way to diagnose a new venue's quirks during certification.
In short
What to take away
Most FIX incidents are mismatched assumptions, not protocol failures
Certify every session, including rejections and disconnects
Treat order state as unknown after a reconnect until it is confirmed
Retain every message so disputes are settled by records
Read next
Certify your next session properly
Bring the venue you are connecting next and we will run its certification on a staging hub, failure paths included.