Key takeaways
- FIX session management controls whether a broker can trust the order and market data messages moving through its liquidity setup.
- Sequence gaps, resend loops and unplanned resets can turn a small connectivity issue into a pricing, execution or exposure problem.
- Brokers should define clear rules for session ownership, recovery, monitoring and failover before live flow depends on the connection.
FIX session management basics for brokers
FIX session management is the control layer that keeps a broker and its liquidity connections aligned. It covers logon, logout, heartbeats, sequence numbers, resend handling and recovery after disconnects.
This is not only a technical matter. It affects pricing continuity, order state, position accuracy and the dealing desk view of what has happened.
A FIX connection can look healthy at the network level and still be unsafe for trading. The socket may be open while sequence numbers are wrong, resend requests are repeating or execution reports are delayed. Treat the session as a controlled process, not just a pipe.
Most broker setups use separate sessions for market data and trading. This is cleaner because price traffic and order traffic have different risk profiles. A busy price stream should not delay order acknowledgements, fills or cancels.
When reviewing FIX connectivity options, check how sessions are created, who initiates logon, how credentials are managed and what happens during reconnects.
Sequence numbers, resends and duplicate execution risk
FIX uses sequence numbers so both sides can detect missing or duplicated messages. Each inbound and outbound message has a number. If a broker receives a number higher than expected, something is missing. If it receives a lower number, it may be a duplicate, a late resend or a reset issue.
This matters most around orders and execution reports. Missing a market data update is usually manageable if fresh prices continue. Missing an execution report is different. The platform may show an order as working while the external side has filled, rejected or cancelled it.
Risk managers should know the broker policy for these cases:
- When to request a resend.
- When to accept a gap fill.
- When to stop routing new orders.
- When manual reconciliation is required.
- Who can approve a sequence reset.
Sequence resets should not be casual fixes. They may be valid during agreed maintenance or controlled onboarding, but resetting without understanding the missing range can hide an order state problem. The safer rule is simple: identify what was missed before declaring the session clean.
A resend request asks the other side to replay a range of messages. Some replayed messages may be administrative. Others may be order acknowledgements or execution reports. A gap fill tells the receiver that certain sequence numbers are intentionally skipped, often for messages that do not need to be replayed.
The main operational risk is duplicate processing. If the bridge or order management layer does not identify repeated execution reports correctly, positions and client trade history can be wrong. Infrastructure should use order identifiers, execution identifiers and message state checks to prevent this.
Brokers should test resend behaviour before production flow starts. Test disconnect during an order, reconnect with a missing execution report, resend of a filled order and cancel during recovery. The aim is to confirm that the platform, bridge and risk records end in the same state.
Market data sessions need separate controls
Market data sessions have different failure modes. A price stream can be logged on and still be unusable if updates are delayed, incomplete or not aligned with the symbols your trading platform expects. Session health and price quality are related, but they are not the same thing.
A broker should monitor both. Session checks confirm that heartbeats, test requests and sequence numbers are behaving. Price checks confirm whether bid and ask updates are current, tradable and within broker limits.
A market data session that keeps recovering through resends may look active, but it may still produce stale or unstable pricing for clients. This can quickly become a client dispute, exposure issue or routing decision.
Use price aggregation and stale price alerts to reduce the chance that one weak feed becomes the broker price. Use monitoring and LP health alerts so operations staff can see disconnects, resend loops, delayed feeds and routing changes in time to act.
For CFDs, symbol setup also matters. If symbols are mapped incorrectly, a clean FIX session can still deliver prices or trades to the wrong internal instrument. Session controls do not replace symbol governance.
What to monitor during live sessions
A practical broker dashboard should show more than connected or disconnected. Dealing and operations teams should be able to see:
- Logon state for each session.
- Last inbound and outbound message time.
- Heartbeat and test request activity.
- Current inbound and outbound sequence numbers.
- Open resend ranges.
- Reconnect count.
- Order reject rate by session.
- Delayed execution reports.
- Market data gaps or stale symbols.
Alerts should be specific. A message such as price session connected but no updates for selected symbols is more useful than a generic FIX problem. So is trading session waiting for resend range.
Specific alerts reduce guesswork. They help the desk decide whether to keep routing, fail over, disable a symbol or reconcile orders.
Responsibility should also be clear. Technology may own the session, but the dealing desk owns execution impact and risk owns exposure. If nobody is assigned to make the decision, sessions can stay in a half-working state for too long.
Building a safer FIX recovery process
A recovery process should be written before an incident. It should state when to reconnect, when to stop order routing, when to switch routing, when to disable pricing and when to run reconciliation.
The procedure should also define who can contact the LP, who can change configuration and who can reopen the session for trading.
After any serious session issue, review the logs against platform trades and positions. Confirm order acknowledgements, rejects, cancels and fills. For market data, confirm whether stale prices reached clients and whether spread or markup controls behaved as expected.
If the broker uses a bridge, check that it can separate price and trade sessions, surface sequence problems, manage recovery cleanly and give staff useful monitoring. XiroLink supports LP aggregation, markups, Centroid compatible FIX, market data and monitoring in a broker bridge setup.
FIX is reliable when it is controlled. For brokers, the goal is not just to connect. The goal is to know the exact state of prices, orders and risk when the connection is normal, busy or recovering.
Frequently asked questions
Should a broker use one FIX session for both prices and orders?
Usually no. Separate sessions make it easier to protect execution when a market data stream is busy or unstable, but the final design depends on the LP and bridge setup.
What is the main risk of poor FIX sequence handling?
The main risk is uncertainty. The broker may not know whether orders, cancels or execution reports were received, which can create duplicate actions, stale order states or exposure errors.
How often should FIX session logs be reviewed?
Critical alerts should be monitored in real time. Full log reviews are usually done after incidents, onboarding, configuration changes and periodic operational checks.