Trading platform FIX API integration development should be treated as production engineering, not as a networking task. A happy-path NewOrderSingle proves very little. The integration must still preserve a correct, explainable order record when a TCP connection drops, a counterparty requests retransmission, an execution report is replayed, or a cancel/replace response arrives out of the expected order.
Within POLADO’s FinTech & Trading Systems practice, we design FIX connectivity alongside OMS workflows, risk controls, audit evidence and operational tooling. The deliverable is not merely a connected FIX engine; it is an integration that can be recovered, monitored and supported in production.
Start with a FIX contract, not a generic protocol claim
FIX defines a common message framework, but every broker, venue and liquidity provider publishes its own implementation guide. The same message type may have different required tags, proprietary fields, instrument conventions, allowed TimeInForce values, session windows and recovery rules. “We support FIX 4.4” is therefore not a sufficient scope definition.
Before development, turn the counterparty documentation into a versioned interface contract covering:
- session and application versions, BeginString, CompID values, authentication and network controls;
- supported inbound and outbound message types, including order entry, execution, cancel/replace, status and administrative flows;
- required, conditional, optional and proprietary tags, with data types and validation rules;
- instrument, account, party, trader and routing identifier mappings;
- heartbeats, trading hours, sequence-reset policy, resend expectations and recovery ownership;
- test environment access, certification cases, production cutover process and incident contacts.
This agreement also defines where counterparty-specific logic belongs. For example, one destination may accept a symbol while another requires SecurityID plus SecurityIDSource. That variation should live in an adapter and controlled instrument-mapping layer—not leak into the UI, risk engine or general order model.
A FIX session is not a TCP connection
The FIX session layer is a bidirectional ordered message stream with a continuous sequence-number series. It can continue across sequential connections, so reconnecting does not automatically mean starting at sequence number 1. The FIX Trading Community’s session standard explicitly describes the session as durable across multiple connections and identifies recovery as a core purpose of the protocol.
Persist the state that makes recovery possible
For each session, persist the next outbound sequence number, the next expected inbound sequence number, logon state, reset policy and enough outbound message history to answer a valid resend request. Store the original wire message or a reproducible canonical representation, plus timestamps and send status. If a process stops after allocating a sequence number but before the network write is confirmed, a restart must know that the number was consumed and decide recovery behaviour deterministically.
High availability adds a separate requirement: one active owner per FIX session. Active/passive failover needs a durable shared state store and an explicit leader or fencing mechanism. Two nodes sending under the same session identity create an outbound sequence race; a load balancer does not solve that ownership problem.
Use heartbeats as an operational control
Heartbeat processing should have agreed thresholds for late messages, TestRequest issuance, timeout, reconnect backoff and alerting. Capture logon, logout, disconnect, reconnect, sequence mismatch and TestRequest timeout as structured events. That evidence lets an operator distinguish a remote outage, a credentials problem, an internal engine restart and a true session-level gap.
Sequence-number recovery needs a bilateral policy
Sequence numbers protect message ordering, but they only work when both parties retain the required state and follow compatible recovery behaviour. On detecting a gap, a counterparty can issue a ResendRequest. A retransmitted application message may require the original content with duplicate indicators and original sending time; a gap that consists of messages not to be replayed may require a SequenceReset gap fill. Those details must be tested against the counterparty’s guide, rather than assumed from a FIX-engine default.
Do not use ResetSeqNumFlag as a casual reconnect shortcut. A session reset requires bilateral agreement: the reset schedule, initiating party, eligibility during connection establishment and treatment of any open orders or unresolved gaps. The FIX session standard specifically warns that unsupported reset behaviour can create operational risks, including order overfills. A production runbook should say exactly who authorizes a reset, which records are checked first and what both sides must confirm afterward.
Make inbound business processing idempotent
Session sequence validation is necessary but it is not business idempotency. An execution report may be resent after a disconnect, observed again during failover or delivered in a duplicate scenario allowed by the counterparty’s workflow. An OMS must be able to decide both whether the transport message is expected and whether the underlying business event has already been applied.
Build a canonical execution-event store with the session and counterparty context, ExecID, OrderID, ClOrdID lineage, event type, quantities, prices, timestamps and raw-message reference. The exact uniqueness rule is counterparty-specific: ExecID may be sufficient in one implementation and require additional scope in another. Document the rule, enforce it in persistence where possible, and verify it through replay tests.
Map FIX orders and executions into a canonical state model
Copying FIX tags directly into one order table is a shortcut that becomes expensive when the next venue has a different dialect. Instead, map external messages into internal canonical entities: order intent, order revision, order state and execution event. Preserve the raw source message for investigation, but give internal services stable domain fields.
- ClOrdID identifies your request and anchors the client-side amendment chain. Generate a new unique value for a cancel/replace request.
- OrigClOrdID links a cancel or replace to the earlier request.
- OrderID is the counterparty order identifier and may or may not change on replacement.
- ExecID is a key candidate for deduplicating execution events.
- LastQty/LastPx describe the current execution, while CumQty/LeavesQty express aggregate order progress.
- ExecType describes the event; OrdStatus describes the order’s current state. They must not be collapsed into one simplistic status field.
Model partial fills, pending cancel, pending replace, replace, cancel reject and unsolicited cancellation as explicit state-machine transitions. This is distinct from liquidity-bridge routing or venue failover design. The focus here is trustworthy FIX-session and order semantics; see our FT10 FinTech work for an example of the broader domain context.
Classify rejects so people can act on them
A Session Reject, Business Message Reject, rejected Execution Report and Order Cancel Reject do not mean the same thing. A malformed or out-of-sequence message may indicate an adapter or session defect. A rejected order may represent an account permission, price-band, instrument-status or risk decision. A cancel reject may mean the order filled, was already changed or cannot be cancelled at that destination.
Operations should see more than “order failed.” Provide the raw message, parsed tags, internal order ID, counterparty reason code, correlation ID, event timeline and a relevant runbook action. This reduces unnecessary manual investigation while keeping a complete audit trail.
Certification and production-readiness checklist
- Approve field-level mappings, sample payloads and negative-validation cases for every in-scope message.
- Test disconnect/reconnect, inbound and outbound gaps, resend, duplicate delivery and approved reset procedures.
- Replay partial fills, delayed rejects and cancel/replace races into an isolated OMS environment.
- Define open-order and trade-status recovery, reconciliation and human escalation procedures.
- Implement session dashboards, alerts, secure raw-message retention, redaction and audit access rules.
- Complete counterparty certification, production cutover, rollback, contact matrix and on-call runbook.
Operational support begins after go-live. Monitor heartbeat delay, reconnect frequency, resend volume, sequence-gap events, reject-code distribution and order-to-acknowledgement latency. POLADO can provide this through Technical Support & Consulting, with controlled releases, incident-ready runbooks and evidence-based post-release checks.
Choose a partner that can explain failure modes
When evaluating FIX protocol integration services, ask more than whether a team can connect to the endpoint. Ask what happens after a restart, how a lost outbound message is recovered, which key prevents a duplicate execution from changing balances twice, and how an operator proves the state of an open order. Strong answers should include data ownership, persistence, test cases, monitoring and an escalation process—not only a list of FIX message types.
If you are assessing a broker, venue or institutional liquidity connection, contact POLADO for a FIX connectivity review. We can assess the counterparty specification, session ownership, mapping design, recovery plan and operational support model against your existing OMS, risk and reconciliation workflows.