Source-aware field guide · 20 answers
FIX Protocol Connectivity
Technical buyer answers for FIX versions, session layers, dictionaries, order entry, market data, drop copy, certification and recovery.
Published · reviewed for scope, source visibility and answer ownership
How to use this guide
Technical buyer answers for FIX versions, session layers, dictionaries, order entry, market data, drop copy, certification and recovery. It is written for institutional connectivity buyers, solution architects, FIX developers, operations teams and certification reviewers. The collection explains protocol-scoping evidence and does not claim FxTrusts supports a FIX version, message flow, venue or counterparty without a signed specification and test record. Use it to turn a sales conversation into a responsibility map, evidence request and acceptance plan that named reviewers can approve.
Each answer supports one operating decision: Which application version, session profile, dictionary, message flow, transport, bilateral convention and certification case governs each connection? The word FIX alone is insufficient because counterparties may implement different standard versions, extensions, workflows and operating rules. Work from the actual entity, instruments, client locations, counterparties and deployment design because the same label can describe materially different services.
The primary reference set is FIX Trading Community — Supported Versions of the FIX Protocol; FIX Trading Community — FIX 4.4 Specification; FIX Trading Community — FIX Session and FIXT; FIX Trading Community — FIX Standards. These sources define standards, regulatory expectations or official operating concepts; they do not endorse FxTrusts or prove a feature in any deployment. Recheck the current source, signed order form, technical specification, permissions and test record before a production, trading or compliance decision.
How to Specify a Complete FIX Version Stack
A complete FIX version stack identifies the application message version, session profile, encoding, transport security, dictionary release and bilateral extensions used by an endpoint.
- Use it to
- Write these elements separately for market data, order entry, drop copy and any administrative connection before development begins.
- Check the boundary
- A proposal that states only FIX API does not define compatible messages, tags, session behavior or current support status.
Is FIX 4.4 Still a Supported Version?
FIX Trading Community lists FIX 4.4 as a supported version and maintains its repository in the Orchestra standard while the published functional specification remains fixed.
- Use it to
- Confirm that the counterparty implements the required FIX 4.4 messages, fields and bilateral rules rather than inferring compatibility from the version name.
- Check the boundary
- Standards support does not prove that FxTrusts or any provider offers a FIX 4.4 endpoint in a particular deployment.
Is FIX 5.0 SP2 Still Maintained?
FIX Trading Community has moved FIX 5.0 Service Pack 2 to unsupported versions, meaning reported errors are not analyzed or corrected for that version.
- Use it to
- Treat an existing FIX 5.0 SP2 connection as a bilateral implementation and record its exact errata, extension packs, dictionaries and counterparty commitments.
- Check the boundary
- Unsupported does not mean unusable, but it should not be described as the maintained latest FIX application specification.
What Replaced FIX 5.0 SP2 as the Latest Specification?
FIX Latest is the maintained successor to FIX 5.0 SP2 and accumulates functionality through FIX Extension Packs according to FIX Trading Community guidance.
- Use it to
- Select a specific repository release or extension-pack baseline and preserve it with code generation, validation and certification artifacts.
- Check the boundary
- The label FIX Latest can drift over time unless both parties pin the exact repository content used by the connection.
What Is FIXT 1.1 in a FIX Connection?
FIXT 1.1 identifies the transport-independent FIX session layer used with FIX 5.0 and later application messages, rather than the application message version itself.
- Use it to
- Document FIXT session behavior and the default or per-message application version identifiers as separate configuration items.
- Check the boundary
- Reading BeginString FIXT.1.1 as the business-message dictionary can cause the wrong messages and fields to be validated.
Does BeginString Identify the FIX Application Version?
BeginString identifies the session profile; from FIX 5.0 onward FIXT.1.1 remains the session value while application versions are identified separately.
- Use it to
- Validate BeginString together with DefaultApplVerID, ApplVerID where used and the counterparty dictionary during logon and message processing.
- Check the boundary
- A matching BeginString confirms neither application-level compatibility nor bilateral support for an order or market-data workflow.
What Is a FIX Data Dictionary?
A FIX data dictionary defines messages, components, fields, data types, enumerations, required status and structural rules for a chosen standard and implementation.
- Use it to
- Version the standard dictionary and explicit counterparty extensions, then use the same baseline for validation, code generation and certification.
- Check the boundary
- Accepting unknown or misplaced tags silently can hide incompatibilities and create business states neither side interprets consistently.
How to Document Bilateral FIX Extensions
Bilateral FIX extensions add or constrain fields, enumerations, messages and workflows agreed by the two endpoint operators beyond the base dictionary.
- Use it to
- Give every extension a definition, data type, valid values, condition, example, owner and version history in the interface specification.
- Check the boundary
- A custom tag number alone does not explain semantics, and ungoverned reuse can collide with another counterparty convention.
How to Scope FIX Session Identities
FIX session identity scope covers SenderCompID, TargetCompID, qualifiers, credentials, endpoint, environment, trading entity and permitted application flows.
- Use it to
- Maintain a connection inventory that maps each identity pair to certificates, network rules, dictionaries, schedules, owners and revocation procedures.
- Check the boundary
- Reusing identifiers or credentials across environments weakens isolation and can route certification traffic toward production systems.
How Do FIX Sequence Numbers Support Recovery?
FIX sequence numbers establish ordered session messages and support detection and recovery of gaps, duplicates and replayed traffic under the agreed session profile.
- Use it to
- Define reset policy, persistence, resend handling, gap fills, duplicate flags and operational escalation for every session lifecycle event.
- Check the boundary
- Resetting sequence numbers to restore connectivity can conceal missing business messages unless both sides reconcile application state.
How Do Heartbeats and Test Requests Work in FIX?
FIX heartbeats and TestRequest messages help detect session liveness when expected traffic is absent, using the negotiated heartbeat interval and matching identifiers.
- Use it to
- Test idle, delayed, congested and one-way failure scenarios and connect timeout decisions to safe order-state reconciliation.
- Check the boundary
- A live heartbeat proves session traffic is exchanged but does not prove market data is fresh or business messages are processing.
How to Separate FIX Market Data and Order Entry
FIX market data distributes quotes or books, while FIX order entry carries trading instructions and execution state; they may use different sessions and dictionaries.
- Use it to
- Specify subscriptions, snapshots, incremental updates, orders, cancels, reports, permissions and recovery independently for the two flows.
- Check the boundary
- Receiving a FIX price feed does not grant executable order access, and an order session may not distribute market data.
What Is a FIX Drop Copy Session?
A FIX drop copy session delivers copies of trading events for monitoring, risk, booking or reconciliation without necessarily accepting order instructions.
- Use it to
- Define event population, timing, identifiers, corrections, busts, allocations, recovery and authoritative use for each consumer.
- Check the boundary
- Drop copy can be incomplete for a control purpose if it omits rejects, pending states, manual activity or required account identifiers.
How to Specify a FIX Order Lifecycle
A FIX order lifecycle maps new, pending, accepted, partly filled, filled, replaced, cancelled, rejected and expired states to messages and business rules.
- Use it to
- Create state-transition examples for every supported order type including cancel races, late fills, duplicate reports and disconnect recovery.
- Check the boundary
- Implementing message schemas without shared state semantics can leave the two parties disagreeing about the live order.
How to Scope FIX Market Data Messages
FIX market-data scope defines instruments, subscription types, depth, entry actions, identifiers, timestamps, snapshots, incremental updates and recovery behavior.
- Use it to
- Use counterparty examples to prove book construction, deletion, reset, stale detection and resubscription across realistic symbol loads.
- Check the boundary
- A parser that accepts a message does not establish that the resulting book remains complete and correctly ordered.
What Does FIX Certification Prove?
FIX certification proves that agreed test cases passed for named endpoints, software versions, dictionaries, configurations and message flows at a recorded time.
- Use it to
- Trace certification cases to production requirements and retain requests, responses, logs, results, defects, waivers and sign-off.
- Check the boundary
- A certificate or prior counterparty test should not be generalized to another version, environment, instrument set or workflow.
How to Secure a FIX Connection
FIX connectivity security covers endpoint authentication, encrypted transport where required, network restrictions, credential protection, authorization, logging and incident revocation.
- Use it to
- Document certificates, keys, source addresses, users, rotations, expiry alerts, support access and both parties responsible for changes.
- Check the boundary
- A protocol standard does not automatically encrypt transport or determine the security controls applied by an endpoint.
How to Normalize FIX Identifiers and Timestamps
FIX normalization maps order, execution, account, instrument and party identifiers plus timestamp precision and timezone across internal and counterparty records.
- Use it to
- Preserve original values while maintaining explicit crosswalks and synchronized clocks for routing, support, surveillance and reconciliation.
- Check the boundary
- Replacing external identifiers or truncating timestamps can make duplicates, event order and counterparty disputes difficult to reconstruct.
How to Test FIX Load and Recovery
FIX load and recovery testing measures message processing, queueing, liveness, persistence and state reconciliation under sustained, burst and interrupted traffic.
- Use it to
- Use realistic message mixes, sequence gaps, reconnects, partial orders and downstream delays while measuring distributions and data integrity.
- Check the boundary
- Peak throughput alone does not prove deterministic order handling or recovery when a dependency slows or fails.
What Evidence Approves a FIX Connection for Production?
FIX production approval requires a signed interface scope, entitlement, compatible versions, certified workflows, security, monitoring, support and recovery evidence for named endpoints.
- Use it to
- Review unresolved limitations, dictionary hashes, deployment settings, contact paths, first-day controls and rollback authority before enabling live traffic.
- Check the boundary
- A reachable port, successful logon or supplier statement does not prove supported business scope or production authorization.
Primary and official references
These sources establish definitions, standards or official product behavior used across this guide. Follow the exact source and check its current version before a live implementation.