B3 Binary APIs in 2026: optional adoption, mandatory interface work

B3’s market-data update of 14 July 2026 for the B3 PUMA Trading System draws a useful boundary around the word mandatory. Binary Unified Market Data Feed (UMDF) schema version 17 and template 2.3.1 are backwards compatible, so B3 does not require every existing consumer to install them. The update matters for participants that need the new functions: a settlDate field, and market-data identification for the new cash-settled stock, exchange-traded fund and Brazilian Depositary Receipt options B3 is launching alongside it. The update also matters to anyone who reads settlement prices, because B3’s roadmap lists February 2027 for ending publication of openCloseSettlFlag.

That distinction extends across B3’s wider binary programme. B3 Binary UMDF and B3 Binary Order Entry (Binary EntryPoint) remain optional alternatives to the existing FIX-based interfaces. Once a firm selects an interface, its obligations depend on the function, channel and production stage involved. Connectivity architects should map obligations by interface and channel, because no single migration deadline governs them.

There is no single B3 binary mandate

B3’s current Binary Trading Gateway roadmap labels the project optional and states that FIX will remain available to participants that do not switch to Simple Binary Encoding (SBE). The B3 Binary Market Data roadmap also labels B3 Binary UMDF optional.

The last row matters. B3 completed a mandatory transition from position-based to price-and-OrderID book management for Binary UMDF in 2025, then introduced the equivalent mandatory change for FIX/FAST UMDF and UMDF Conflated, with position-based support ending in tranches through 8 June 2026. A mandatory change to one interface’s functionality doesn’t force adoption of that interface.

Schema 17 changes business meaning as well as message length

External Communication 040/2026-VNC introduces Binary UMDF 2.3.1 and schema version 17. It adds the optional settlDate field, tag 64, to the SettlementPrice message and increases that message from 36 to 40 bytes. B3 marks the existing openCloseSettlFlag, tag 286, as deprecated and optional from version 17. Once settlDate is active, it identifies the settlement-price reference date, replacing the previous estimation from openCloseSettlFlag and tradeDate. B3’s roadmap lists February 2027 for ending openCloseSettlFlag publication on the Binary UMDF, FIX/FAST and Conflated feeds, leaving settlDate as the only reference for the settlement-price date.

The update also repurposes OptPayoutType value 2 from the unused CAPPED label to VANILLA_CASH_SETTLEMENT, supporting the cash-settled stock, ETF and BDR options B3 is launching alongside the update. In a separate change, it renames TradingSessionSubID value 18 from Forbidden to Pre-Close and value 21 from Reserved to Pre-Open, to align with the Order Entry specification. A longer root block tests decoder compatibility; a repurposed enumeration and a new date field test downstream business logic, storage and reconciliation.

SBE encodes the application messages here. Each interface defines its own transport and recovery. Binary UMDF distributes SBE messages over UDP multicast. Binary EntryPoint carries SBE business messages within a FIX Performance Session Layer (FIXP) session over TCP. Treating both as “the B3 binary API” conceals different state boundaries and failure modes.

A staged channel rollout requires version-aware decoding

B3’s technology roadmap set certification from 3 August 2026 and a mock session on 22 August, then scheduled the move to template 2.3.1 (schema 17) in three channel waves:

1. 24 August: channels 68, 70, 90, 94 and 98.
2. 31 August: channels 74, 76, 80, 86 and 92.
3. 8 September: channels 72, 78, 82, 84 and 88, the last group.

settlDate itself becomes active in production on 16 November 2026, per B3’s roadmap.

The engineering consequence is version coexistence. Across the waves, a multi-channel consumer could meet schema 16 and schema 17 at the same time, and captures and replays from before a channel’s switch stay on schema 16. B3’s 29 November 2025 mock-session notice identifies template 2.2.0 as schema version 16. The OnixS handler decodes B3’s SBE messages in both schema 16 and schema 17 and delivers them as typed callbacks, so you do not write or maintain a decoder.

Testing should cover both schemas, the 36-byte and 40-byte SettlementPrice layouts, and absence and presence of settlDate. Test wire value 2 under both schemas to confirm no component reports the obsolete CAPPED meaning for a cash-settled option. Verify the result at the decoded event, book, storage and reconciliation boundaries.

B3 Binary UMDF recovery is part of correctness

B3’s current Binary UMDF Messaging Specification Guidelines, version 2.3.1.2, define three streams: incremental, instrument-definition and snapshot recovery. A main feed (Feed A) carries every stream, and a secondary feed (Feed B) duplicates the incremental stream so clients can arbitrate between arrivals.

For a late join or larger loss, B3 recommends queuing live incrementals while building current state from the looping snapshot stream, then discarding duplicates and applying the remaining queued events. Version 2.3.1.1 added one exception: SecurityGroupPhase messages are not instrument-based, so the consumer must not discard them from the queued incrementals. For each security group, it compares the transactTime of the snapshot and incremental copies and uses the phase from the more recent one. The OnixS handler runs the snapshot recovery and incremental queuing for you, and applies the SecurityGroupPhase exception.

That process restores current state. It does not replay a complete history of intermediate statistics and trades. Binary UMDF also lacks the TCP recovery service (the UMDF TCP Replayer) available on the legacy FIX/FAST UMDF feed. Decoding alone does not prove market-data correctness. Your tests still need forced packet loss, A/B feed arbitration and snapshot recovery, even where the SDK implements them.

Binary EntryPoint makes session state and certification explicit

B3’s current Binary EntryPoint Messaging Specification Guidelines, version 8.4.2.1, define SBE application messages over FIXP. Negotiate authenticates and identifies the logical session; Establish binds a physical connection to sequence state. B3 resets inbound and outbound sequence numbers to 1 at the start of each trading day.

The gateway does not carry recovery responsibility alone. A NotApplied message reports a gap in the client-to-B3 idempotent flow, leaving the client to determine the correct business-level action. Retransmission applies only to the current trading session; B3 caps outstanding requests at 1,000 messages, and exceeding that limit terminates the session. On first gateway failure, the client switches to the backup and sends Negotiate, retaining the same sessionVerID as B3 recommends; a second failure only needs an Establish. The OnixS handler implements the session mechanics and retransmission handling, so they need no code of your own. The business response to a NotApplied gap and the backup-gateway plan stay with your application.

B3’s certification process is a separate obligation from these session mechanics: Circular 015/2024-PRE states that certification is mandatory for systems that will use the binary gateway in production. Adoption of Binary EntryPoint is optional; production use is certification-gated.

Turn the venue programme into an acceptance plan

A useful delivery plan separates obligations before allocating engineering work:

This ties engineering effort to the requirements B3 has confirmed for each interface.

Where OnixS fits

The OnixS SDKs already implement most of the interface mechanics described above. The two tables below separate what each SDK does from what your application still has to do, and each row links to the matching page of the OnixS programming guides.

For market data, the OnixS directConnect: B3 Binary Unified Market Data Feed (UMDF) SBE Market Data Handler SDK - C++ implementation implements feed handling, A/B arbitration, gap detection, snapshot recovery and book building, including support for the Binary UMDF 2.3.1 schema update covered above. The C++ B3 Binary UMDF Market Data Handler programming guide documents each area.

For order entry, the OnixS directConnect: B3 Binary EntryPoint (BOE) Order Entry Handler SDK - C++ implementation implements the FIXP session, sequence numbering, gap detection, retransmission and persistence. The C++ B3 BOE Binary Order Entry Handler programming guide documents each area.

The market-data evaluation should decode both UMDF schemas and recover a book after forced packet loss. The order-entry evaluation should restore sessionVerID, sequence state and persisted order state after a restart, then reproduce the certification flows above on the target platform.

Match the work to the requirement, not the announcement

B3’s binary interfaces affect long-term latency and connectivity costs, but current sources do not establish a universal FIX or FIX/FAST retirement. For Binary UMDF consumers that need the new functions or read settlement prices, the engineering work is narrower and more concrete: handle template 2.3.1 on every channel you consume, move to settlDate before openCloseSettlFlag publication ends in February 2027, and prove recovery for the channels selected. Binary EntryPoint adopters carry their own session-recovery obligation, and production use of either interface is certification-gated.

OnixS provides C++ SDK support for both B3 Binary UMDF and B3 Binary Order Entry, including reference implementation source code samples built for rapid B3 PUMA Trading System platform DMA development and deployment. Request a free 30-day evaluation of either SDK to test schema 17 handling and session recovery against your own architecture before committing to a production date.