FIX Connectivity Checklist for a New Broker or Venue
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
Connecting a new broker, exchange or venue over FIX is mostly not about FIX syntax. It is about agreeing many small settings with the other side, testing the paths that only show up on a bad day, and keeping the evidence of what happened. This checklist follows the order the work is usually done in, from the first specification to the first week in production.
Before you start: the documents to collect
- The counterparty's rules of engagement or FIX specification: the FIX version, the message types they accept and send, the required and custom tags, and the values they use. Where their document and the standard differ, their document wins.
- Their data dictionary, if they publish one. Load it into the parser's dictionary manager so their custom tags and values are named when you read their logs.
- Connectivity details for each environment: addresses and ports, primary and backup, the network route (internet with TLS, VPN, leased line or a cross-connect in a shared data centre) and who to call when the line drops.
- Session identities for each environment: SenderCompID (49) and TargetCompID (56), and SenderSubID (50), OnBehalfOfCompID (115) or DeliverToCompID (128) if orders pass through a hub.
- The trading calendar and session hours, including half days and holidays, and what happens to open orders at the end of the day.
- The certification script: the scenarios the counterparty will ask you to run before production.
Session settings to agree
| Setting | Where it lives | What to agree |
|---|---|---|
| FIX version | BeginString (8); on FIXT.1.1 also DefaultApplVerID (1137) and ApplVerID (1128) | FIX.4.2, FIX.4.4, or FIXT.1.1 with an application version. See FIXT.1.1 and ApplVerID. |
| CompIDs | SenderCompID (49), TargetCompID (56) and any sub IDs | The exact values per environment. Engines compare them character by character. See CompID problem. |
| Heartbeat interval | HeartBtInt (108) on the Logon | One value for both sides; 30 seconds is common. |
| Sequence numbers | MsgSeqNum (34), ResetSeqNumFlag (141) | When they reset (daily, weekly or never) and whether a Logon with 141=Y is accepted. |
| Session schedule | Engine configuration | Start and end time and time zone, and for week-long sessions the first and last day. QuickFIX names these StartTime, EndTime, StartDay and EndDay. |
| Logon credentials | Username (553), Password (554), EncryptMethod (98) | Username and password if used, and 98=0 when encryption is handled by the network layer. |
| Resend handling | Resend Request (35=2), Sequence Reset (35=4) | Which messages they resend and which they gap-fill after a disconnect. See PossDupFlag and PossResend. |
| Clocks | SendingTime (52), TransactTime (60) | Both sides on synchronised UTC clocks, and how far apart SendingTime may drift before a message is rejected. See SendingTime accuracy problem. |
Certification: what to test
Most counterparties run a scripted certification in a test environment. Treat their script as the minimum. The paths that cause incidents are the ones that rarely happen, so test them on purpose and keep the log of every run.
- Logon, heartbeat and logout, including a Logon with a wrong password and the answer you get. See Logon rejected.
- A sequence gap in both directions: send a message with a higher MsgSeqNum (34) than expected and check the Resend Request (35=2); disconnect in the middle of the day and check what is replayed. See MsgSeqNum too high.
- Heartbeat timeout: stop sending and check that the other side sends a Test Request (35=1) and then disconnects. See heartbeat timeout.
- Every order type and time in force you will use: new, partial fill, full fill, cancel, replace, reject, and expiry at the end of the day.
- Rejects at each layer: a Reject (35=3) for a malformed message, a Business Message Reject (35=j) for an unsupported message, and an Execution Report (35=8) with 39=8 for an order the counterparty refuses, with the Text (58) text they send.
- Cancel and replace races: a cancel that arrives after the order filled, and a replace on a partly filled order. See too late to cancel.
- Post-trade messages, if they are in scope: allocations (Allocation Instruction (35=J)), confirmations (Confirmation (35=AK)) or trade capture reports (Trade Capture Report (35=AE)), and a drop copy session if you receive one.
- Open each run in the parser or the log analyzer. They read QuickFIX/J, QuickFIX/n and QuickFIX C++ logs as well as plain FIX, so every scenario can be checked message by message and the evidence kept.
Go-live
- Confirm production CompIDs, addresses and credentials, and send credentials separately from the rest.
- Agree the first-day plan: a small number of orders in liquid instruments, with someone watching each side.
- Agree the starting sequence numbers before the first Logon.
- Make sure the support desks on both sides know each other and the escalation path.
The first week: what to watch
- Reject rate and reasons per session. A reject reason that never appeared in certification usually means a field mapping was missed. The reject analysis ranks rejects by SessionRejectReason (373), BusinessRejectReason (380) and OrdRejReason (103).
- Acknowledgement latency per session, p50 and p99, compared with the certification runs. See how order latency is measured for the clocks and percentiles.
- Session health: disconnects, resend requests and gap fills per day. See session health.
- End-of-day state. Every order should end filled, cancelled, rejected or expired. An order that is still open on your side but not at the venue is the most expensive break to find late.
Questions
- What is a FIX rules of engagement document?
- The counterparty's own description of how it uses FIX: version, message types, required and custom tags, values and session behaviour. Where it differs from the FIX standard, it is the rule for that connection, so read it first.
- Should FIX sequence numbers reset every day?
- That depends on the counterparty. Daily resets are common, and some sessions keep one sequence for a week or longer. What matters is that both sides agree, and that a reset is never done silently in the middle of a session. See ResetSeqNumFlag (141) and Sequence Reset (35=4).
- Which FIX version should a new connection use?
- The one the counterparty supports and certifies. FIX 4.2 and FIX 4.4 remain common; FIX 5.0 SP2 runs over FIXT.1.1 with the application version in ApplVerID (1128). See compare FIX versions.
- What should we keep from certification?
- The full message log of every scenario, the counterparty sign-off and the settings both sides agreed. They answer most questions when something behaves differently in production.