Start with the FIX session contract
A FIX connection is governed by more than host and port. We document FIX version, CompIDs, authentication, heartbeat interval, sequence-number policy, session schedule, reset rules, TLS or network requirements and environment endpoints before message testing starts.
Define exactly which messages are in scope
Market data and order routing use different message flows. The integration specification should list supported message types, required and optional tags, venue-specific fields, order types, time-in-force rules and execution-report states instead of assuming generic FIX behaviour.
- FIX session and network specification
- Supported message/tag matrix
- Sequence and resend policy
- Instrument and identifier mapping
- Order lifecycle and reject test cases
- Production session/log monitoring
Sequence recovery and reconnect behaviour
Production incidents often expose session-state assumptions. We test disconnects, reconnects, sequence gaps, resend handling, duplicate protection and session resets so both sides have a shared expectation of how connectivity recovers.
Instrument and order-lifecycle mapping
Symbols, sides, quantities, prices and identifiers must map consistently between internal systems and the counterparty. We trace an order from submission through acknowledgement, fill, partial fill, cancellation or rejection and retain identifiers needed for support investigation.
Certification and production observability
Before go-live, test cases should include valid and invalid messages, rejects, session transitions and recovery scenarios. Production monitoring then focuses on session state, heartbeat health, sequence anomalies, rejects and message-processing errors rather than connectivity alone.