FIX 4.4 vs FIX Latest (and FIX 5.0): Broker Integration Guide
A practical explanation of supported FIX versions, FIXT, extension packs, rules of engagement, session behavior, certification, and migration decisions.
Direct answer
FIX 4.4 remains a supported legacy application version, while FIX Latest is the incrementally enhanced successor to the numbered FIX 5.0 line. FIX Trading Community says FIX Latest is cumulative and recommends it for new functionality; it also maintains supported FIX 4.2 and 4.4 repositories. The right connection is the version and profile both counterparties actually support for the required workflow. A version name alone is insufficient: agree the session layer, message types, fields, extensions, identifiers, recovery, security, environments, certification cases, operations, and change policy.
Understand version terminology before selecting
FIX Trading Community describes FIX as a layered, modular family in which fields form reusable components and messages represent business events. Traditional releases included FIX 4.4 and FIX 5.0 Service Packs. The standards body introduced extension packs so functionality could evolve without waiting for another monolithic version. FIX Latest is now the official successor label and accumulates those extension packs.
As of the official supported-versions guidance published in 2026, FIX 4.2 and FIX 4.4 remain supported legacy versions, while FIX Latest is actively enhanced. FIX 5.0 Service Pack 2 moved to the unsupported list even though implementations may continue to use it. "Unsupported" in this standards-maintenance context does not mean a connection instantly stops; it changes where corrections and new standard functionality are maintained.
FIX 5.0 also separated the application version from the session layer through FIXT 1.1. Consequently, BeginString identifies the session protocol rather than necessarily naming the application version. Teams that compare only "4.4 versus 5.0" can miss session and application negotiation. Obtain the official specifications and the counterparty's current rules of engagement rather than relying on a tag list copied from another integration.
| Option | Standards status | Practical implication |
|---|---|---|
| FIX 4.4 | Supported legacy version | Stable defined scope; extensions and counterparty dialects still require governance |
| FIX 5.0 / SP2 | Numbered line now outside supported versions | Existing implementations may remain, but new corrections target FIX Latest |
| FIX Latest | Cumulative application standard enhanced by extension packs | Access to maintained functionality with an explicit extension-pack baseline |
| FIXT 1.1 | Transport-independent session protocol associated with post-4.4 application versions | Session BeginString and application version must be understood separately |
Choose from business workflows, not version prestige
Inventory the required flows: reference data, market data, quote request and response, order entry, cancel and replace, execution reports, trade capture, allocations, positions, collateral, confirmations, regulatory reporting, and drop copy. Identify products, venues, legal entities, clients, sessions, peak rates, and recovery needs. Map each business event to the candidate standard and the counterparty's implemented subset.
A mature FIX 4.4 connection may be more appropriate than an aspirational newer version if it covers the required workflow, counterparties operate it reliably, and extensions are governed. Conversely, new functionality may be represented more consistently in FIX Latest than through many private tags. Evaluate operational evidence, maintenance, and portability—not the numerical version as a proxy for quality.
Avoid declaring one version universally faster or more secure. Performance depends on encoding, message size, engine, hardware, network, queueing, persistence, validation, logging, and counterparty behavior. Security depends on transport, network design, identity, certificates or keys, access, patching, monitoring, and operating procedures. The application dictionary alone supplies neither outcome.
Create a bilateral rules-of-engagement document
Record sender and target identifiers, network endpoints, environments, session schedule, time zone, authentication, encryption, certificate lifecycle, sequence-number policy, heartbeat, test request, logout, reset, resend, gap fill, persistence, duplicate handling, and disaster-recovery endpoints. Define planned maintenance, support contacts, severity, escalation, and authorized production changes.
For every message, identify direction, business trigger, required and conditional fields, enumerations, components, repeating groups, identifiers, precision, timestamps, custom fields, and reject behavior. Explain semantic choices: whether quantity is original, remaining, or executed; how average price is calculated; how corrections or trade cancels appear; and how partial fills affect order state. Examples should accompany normative rules, not replace them.
Use standard fields or components from maintained extension packs where they meet the need before inventing a private field. If custom tags are unavoidable, register ownership internally, document type and semantics, prevent collisions, version changes, and test portability. A technically valid message can still be commercially ambiguous if its business meaning is not agreed.
Treat session recovery as a financial control
Sequence numbers help identify missing or duplicate messages, but recovery policy must be agreed. Define whether and when sequence resets occur, how resend requests are handled, which administrative or application messages may be gap-filled, how PossDupFlag and original sending time are used, and how long messages remain available. A careless reset can hide an execution; indiscriminate replay can duplicate a business action.
Separate transport delivery from business idempotency. An order identifier, client order identifier, execution identifier, trade identifier, and message sequence number serve different purposes. Persist enough state to recognize retransmission after restart and to reconcile a business event independently of its session envelope. Define what happens when one side loses state or restores an older backup.
Monitor logout, heartbeat loss, latency, sequence gaps, rejects, business rejects, throttling, queue depth, store failures, and clock drift. Alerts should route to people who understand both session and trading impact. A connected session can still carry invalid business messages; a disconnected session can still leave live or executed orders at the counterparty. Runbooks must cover both.
Build certification from stateful scenarios
Create a traceability matrix from business requirements and rules of engagement to test cases. Include normal order flows, every supported order type and time-in-force, partial and multiple fills, cancel during fill, cancel reject, replace, venue reject, session loss, resend, duplicate, out-of-order event, stale message, counterparty restart, local restart, and uncertain status. Verify positions, risk, client state, and ledger effects, not only FIX acknowledgements.
Use deterministic reference data and record raw inbound and outbound messages with sensitive-field controls. Assert required fields, values, timestamps, identifiers, state transitions, and response timing under the agreed test environment. Negative tests should demonstrate that invalid symbols, precision, size, price, session, and unauthorized activity fail safely with useful reason codes.
Load and soak tests must reflect price traffic, order bursts, recovery replay, logging, and downstream processing. Record percentiles, backlog, throttling, drops, engine restarts, and data-store behavior. Certification in a vendor lab establishes only the tested version and cases; production rollout still needs network, credentials, operations, limits, monitoring, and a controlled first-trade plan.
Plan migration without a flag-day assumption
Document the motivation: counterparty requirement, new product, reduced custom fields, standards maintenance, engine support, or operational simplification. Compare current and target dictionaries, rules of engagement, custom extensions, message volumes, session topology, certification, monitoring, storage, downstream parsers, reports, and archived-message tools. A protocol change can affect every consumer of trading events.
Use parallel environments and, where feasible, shadow validation that does not create duplicate live orders. Compare normalized business events rather than raw messages alone. Plan identifier continuity, open orders, positions, sequence numbers, session cutover, rollback, and the period during which both versions need support. Counterparties and internal owners must agree the exact transition.
Preserve historical interpretability. Store the dictionary, extension-pack baseline, rules-of-engagement version, application release, and mappings used at each time. A future investigation must decode a message according to the version then in force, not today's parser. Test archive retrieval and replay without sending unintended production actions.
Decision checklist
- Business workflows and counterparties define the application-version choice
- Session layer and application layer are documented separately where applicable
- Exact FIX Latest extension-pack baseline or legacy specification is pinned
- Rules of engagement define messages, semantics, extensions, session, and recovery
- Identifiers and idempotency survive replay, reconnect, and component restart
- Certification covers stateful failures and downstream positions and accounting
- Monitoring distinguishes session availability from business correctness
- Migration, rollback, archival dictionaries, and counterparty change control are agreed
Verify vendor claims at the connection level
When a platform or bridge says it supports FIX 4.4, 5.0, or FIX Latest, ask which business roles, message categories, fields, extension packs, encodings, and session options are implemented. Request current dictionaries and sample rules of engagement. Confirm whether the interface is for liquidity connectivity, client order entry, drop copy, reporting, administration, or another purpose; "FIX API" does not define the use case.
Identify licensing, certification, onboarding, network, hosting, message, support, and professional-services scope. Determine who maintains counterparty mappings and custom tags, how quickly changes are delivered, and whether the brokerage can retrieve raw messages. A connector name on an integration list is not evidence of compatibility with a specific counterparty account and workflow.
RTX5 publishes FIX 4.4 and FIX 5.0 commercial options. Standard includes FIX for the agreed scope; Entry lists protocol-specific add-ons. Define the application version, session count, counterparties and market-data versus order scope in writing. Require rules of engagement, certification where applicable, security review and load/recovery tests; a published protocol label alone does not establish interoperability.
Primary sources and evidence boundary
Sources are listed to support specific definitions, public vendor statements, and regulatory frameworks. They do not endorse Orrnn, prove that a product meets a requirement, or replace a current proposal, contract, legal opinion, technical test, or regulator decision.
The original source review was completed on 21 September 2026. RTX5 pricing and plan references were updated on 26 September 2026; the dated note below identifies that product source. Recheck time-sensitive requirements and commercial terms before relying on them.
- RTX5 broker pricing and plan inclusions
RTX5 / Orrnn
Product pricing reviewed 26 September 2026. Vendor-published commercial scope, not independent proof of performance, compatibility or regulatory approval. Inclusions vary by plan.
- FIX Protocol
FIX Trading Community
Primary overview and specification entry point for FIX Latest and supported legacy materials.
- Supported Versions of the FIX Protocol
FIX Trading Community
Official 2026 explanation of FIX Latest, FIX 4.2 and 4.4 support, FIX 5.0 SP2 status, and FIXT version identification.
- FIX Standards
FIX Trading Community
Official catalogue for the broader FIX family of application, encoding, and machine-readable standards.
- FIX 4.4 Specification Release Notes
FIX Trading Community
Primary release material for the legacy FIX 4.4 specification; implementers should use the complete official specification package.
Related reading and next steps
Liquidity bridge evaluation
Apply protocol choices to connectivity, routing, recovery, and reconciliation.
ReadBroker technology stack
Place FIX engines and connections within owned services and data flows.
ReadA-Book vs B-Book vs hybrid
Separate the execution and risk model from the transport protocol used.
ReadYour next step
Explore an RTX5 configuration for your business.
Compare the published platform plans, then share the account capacity, client workflows and connectivity your business needs. A requirements discussion can establish the demonstration scope, quote and implementation dependencies. Module inclusions vary by plan.