ICE Binary Order Entry (BOE) is now live as a supported order-routing interface for futures, options and strategy markets across ICE’s derivatives exchanges. ICE introduced Binary as an alternative to FIX, says FIX stays available for the foreseeable future, and has committed to nine to twelve months’ notice before retiring it. A firm that adopts BOE still needs prior sponsorship approval and conformance-tested software before it can trade in production, and its implementation has to preserve session continuity, recover message state, and satisfy the audit and identification rules of whichever ICE exchange it trades on.
For a trading-system architect, accountability through discovery, disconnection, recovery and reconciliation outweighs SBE’s latency numbers.
ICE keeps Binary optional
ICE Futures Europe Circular 25/075, published on 16 July 2025, introduced Binary as an option alongside FIX and targeted launches of 31 October 2025 in Basildon and 20 February 2026 in Chicago. Both launches went live on schedule, and Binary is now a supported, production interface in both silos alongside FIX: the ICE Technology ISV page lists both Binary and FIX for ICE Futures markets, and the Supported Market Types across ICE APIs matrix (version 10.59, dated 2 July 2026) records Binary Gateway and FIX Order Server availability by market type. Binary users still need prior approval and conforming software before ICE grants production access.
ICE’s stated design goals for Binary are better load balancing and resource use, reduced and more consistent latency, and removal of the third-party load balancer that FIX order routing depends on. SBE should not get credit for every performance gain a firm observes: encoding, session design and routing architecture each need separate measurement before anyone attributes a latency result to the wire format alone.
The connection begins before the order gateway
|
Layer |
ICE BOE role |
Client responsibility |
|
Application |
Order, cancellation and execution workflows |
Preserve business intent, identifiers and order state |
|
Encoding and framing |
SBE messages with a Simple Open Framing Header |
Decode the supported schema and reject incompatible input safely |
|
Session |
BUS discovery, BGW logon, heartbeat, sequencing and recovery |
Retain discovery and session state, detect gaps, and reconnect without corrupting continuity |
|
Transport and topology |
TCP connections to regionally assigned gateways |
Manage connection retries, endpoint changes and network monitoring |
The OnixS C++ ICE BOE programming guide, currently at version 1.1.2, documents a two-step connection that matches ICE’s own technical specification. A client first connects to the Binary Utility Service (BUS) and requests the IP address, port and session token for a Gateway ID, then opens its Binary Gateway (BGW) session using those details. The token is valid only for the current exchange trading day. ICE runs three exchange silos: ICE and ENDEX both sit in Chicago, alongside LIFFE in Basildon, and the 20 February 2026 Chicago go-live covered both the ICE and ENDEX silos together.
This design creates an operational dependency before order entry starts. A production client needs controlled storage of the daily token, a retry policy for BUS and BGW failures, monitoring that separates a discovery failure from a gateway rejection, and a plan for endpoint reassignment. BUS assigns connections by round robin with exponential backoff, though a client can opt into a sticky-session token to keep reconnecting to the same gateway. Caching yesterday’s route doesn’t help after a failed reconnect: the client has to go back to BUS for a fresh assignment instead of retrying the old one.
Reconnection does not erase sequence history
Each BGW session keeps two independent counters: the sequence ICE assigns to messages it sends the client, and the sequence the client puts on its own requests. Only the first matters for gap detection. It resets to 1 at the start of each new trading session, during the exchange maintenance window, and carries forward across any reconnect within that session; a client cannot force a mid-session reset. ICE ignores a client’s own outbound sequence numbers unless a message fails to decode, in which case it returns an Error tagged with that sequence number. A client that restarts with a stale expected value can request the wrong range, accept a duplicate, or lose an execution. One that treats a reconnect as a new business session risks a different failure: losing the link between venue responses and the orders it still believes are working.
Disconnection changes more than the sequence count. A TCP drop, a LogoutRequest or a TraderLogoutRequest cancels every open order except GTC and GTD orders, with cancel notices arriving on the next logon, before the LogonReport. This is default, non-configurable behaviour, identical to FIX OS. GTC and GTD orders follow a separate path: on trader logon, ICE resends trade and cancel activity from while the trader was logged out, plus a snapshot of every open GTC/GTD order, but ICE retains that logged-out activity for two business days only. ICE may not send expiry-driven cancels between sessions, so check expiry dates for any order that does not reappear after logon. These orders also flip between “Active” and “Inactive” as markets close and reopen, a transition the working-order model needs to track on its own.
Message recovery and order recovery are related but distinct problems, and good-till orders make the distinction matter because their lifetime can outlast a single connection or trading day. A ResendRequest names a start and end sequence number, where zero as the end value means “everything up to now.” The resulting ResendReport can come back as full success, partial success or failure, so the requesting application has to handle partial replay as well as a clean one. A SequenceReset, carrying a gap-fill flag, skips administrative messages such as logons and heartbeats, which ICE never retransmits.
Conformance is necessary, but recovery needs forced-failure testing
ICE requires prior approval and conformance testing before granting Binary production access, and its Technology ISV guidance states that passing ICE’s own test does not replace a firm’s independent testing. Conformance proves a client can speak the protocol within the scope ICE tested. It does not prove the trading system preserves accountable state under a production failure.
A production acceptance test should force state transitions a clean connection never exercises:
- Obtain a current BUS token and connect to the assigned BGW.
- Submit orders and record the application, session and audit identifiers needed to trace them.
- Force a mid-session disconnect with orders and responses in flight.
- Reconnect without assuming the server sequence has reset.
- Trigger a ResendRequest across a deliberate gap and handle both a partial-success and a clean ResendReport.
- Reconcile executions, rejects, cancellations and Active/Inactive transitions against the local order model.
- Confirm the system neither loses nor duplicates any event, including across a process restart.
- Where the test environment allows it, repeat the sequence during an endpoint reassignment, in AP1 or Demo1, and against the firm’s intended persistence, network and concurrency settings.
A latency comparison should wait until after these checks. The measurement boundary needs to include whatever persistence, risk and recovery work the production architecture performs; a decoder-only benchmark says little about the order path’s tail behaviour or the cost of a failure.
Trader identification and audit fields are part of the interface contract
Binary migration reshapes how regulated records are populated and mapped, well beyond the gateway code. The ICE Futures U.S. Trader Identification FAQ applies Binary-specific provisions from 23 February 2026, covering FIX or Binary API User IDs, Authorized Trader IDs, the person responsible for an External Connection User ID, and registration in the exchange’s Authorized Trader Management System.
ICE Futures U.S. Rule 4 applies its audit-trail requirements to Binary from the same date and requires five years of retention, with the most recent two years accessible. ICE Futures Europe applies a longer window: Circular 25/119 requires at least seven years and states that ClOrdID must be unique within a FIX or Binary session for a trading day, a rule the protocol itself enforces (numeric, non-zero first digit, one to twelve digits, no repeats for the same market and company in a trading day).
These obligations vary by exchange, so a shared Binary client cannot assume identical identifier population, retention and evidence requirements across ICE venues. Audit data has to be reproducible on request in unencoded ASCII, field by field, with composite fields broken into their individual elements. Test the audit trail from order creation through venue response, including timestamp quality, user attribution, and every modification and cancellation, and confirm that replayed messages do not create gaps or duplicate records. BGW transactions still flow through the existing FIX Private Order Feed, so drop-copy and back-office wiring built on FIX does not need a Binary-specific replacement for that one workflow.
Migrate by market, workflow and failure boundary
The supported-market matrix shows why a single estate-wide protocol label does not work for planning. It records Binary Gateway and FIX Order Server support by market type, while FIX Private Order Feed, FIX Trade Capture and iMpact Multicast continue to serve their own distinct workflows. Treating all of these as one migration unit because they run on the same trading stack hides real gaps.
Build the inventory around each market and order workflow, then record its current FIX route, target Binary capability, Gateway ID, silo, conformance scope, recovery dependency and audit owner. That inventory will surface partial states, such as Binary order routing running while FIX Private Order Feed, FIX Trade Capture or iMpact market data stays unchanged.
Parallel running needs an explicit rule, and ICE has set one: a Gateway ID can log on concurrently to FIX OS and BGW in the same silo, but a Trader ID cannot log into both at once. That forces a trader-level decision about which interface each trader uses during migration, plus a clear answer for which system owns working-order state while both routes stay active.
Where OnixS fits
OnixS publishes the OnixS directConnect: ICE Binary Order Entry (BOE) Handler SDK - C++ implementation, currently at programming-guide version 1.1.2, covering the BUS and BGW connection sequence, SBE message handling, independent sequence state, gap detection, retransmission, persistent session storage and reconnection. OnixS completed ICE’s mandatory Functional Conformance Testing for this SDK on 25 November 2025, and backs it with a service-level commitment to track ICE’s schema and specification updates, logged in OnixS’s public release notes.
None of that removes a firm’s own work, but it does change the starting point. Having completed ICE’s own BOE certification, OnixS can support a firm doing the same, with reference source code samples built around the disconnect-and-recovery sequence above and engineers who carry direct, first-hand experience of ICE’s conformance process. Building on a certified SDK beats a bare protocol implementation: less code to write and test from first principles, and a foundation already exercised against ICE’s own requirements. A client still has to reconcile business state, implement its own controls, secure ICE approval, and test its actual deployment. Before relying on the SDK for a production decision, force the disconnect-and-recovery sequence described above, restart the application with working orders in place, and confirm a complete audit trail on the intended operating system, network and persistence configuration.
Make continuity the production gate
ICE BOE demands more than smaller message sizes, and current ICE sources still frame it as optional rather than a compulsory FIX replacement. Its real weight sits in the responsibilities that come with production use: discovery precedes gateway access, sequence state has to survive an intraday reconnect, recovered messages must reconcile with working orders, and audit obligations differ by exchange.
Pick one representative market and order workflow. Get the current ICE specifications and conformance scope for it, then run a forced-failure acceptance test against it. Do not approve a production migration until the client can prove message continuity, business-state reconciliation and audit completeness through a disconnect and restart.
The OnixS directConnect: ICE Binary Order Entry (BOE) Handler SDK gives a team a certified starting point for that test. It does not replace running it. Request a free 30-day evaluation of the ICE BOE Handler SDK and run the disconnect, recovery and reconciliation sequence above against your own architecture before committing to a production migration date.
