For firms connecting to B3’s PUMA trading environment, the introduction of binary market data and order entry APIs raises a practical implementation question: what is the most controlled way to adopt them?
The B3 Binary Unified Market Data Feed (B3 Binary UMDF) and the B3 Binary Order Entry (BE BOE) API, both built on FIX Simple Binary Encoding (SBE), have been operating in parallel with the existing FIX/FAST-based market data feed and FIX 4.4 order entry interfaces since mid-2023. There is currently no mandated decommissioning timeline for the legacy APIs. That coexistence gives firms flexibility, but it also places responsibility for sequencing squarely on the participant.
For trading firms evaluating adoption - whether existing B3 members considering migration or new participants onboarding to the exchange - experience suggests that the order in which these components are introduced has a material impact on execution risk and integration stability.
In practice, firms tend to begin with the B3 Binary UMDF market data feed. The objective at this stage is not execution, but control. Integrating binary market data involves handling security static data, implementing symbol and channel filtering, and constructing a full depth order book from the SBE-encoded feed.
B3 provides PCAP samples that support deterministic replay of captured market data. These captures are primarily intended for technical validation rather than full historical backtesting, but they allow development teams to validate decoding logic, sequencing and book construction in isolation from live exchange connectivity. By resolving market data handling first, firms can confirm that their internal representation of the order book behaves exactly as expected before any trading logic is activated.
Once market data decoding and order book construction are functioning correctly, attention shifts to infrastructure.
Deployment into a sandbox or controlled test environment allows firms to validate network configuration, NIC behaviour, operating system tuning and memory management under realistic load conditions. While SBE reduces encoding and decoding overhead compared with FIX/FAST, realised performance is determined by the full deployment stack. CPU architecture, interrupt handling and kernel configuration all contribute to latency characteristics.
For this reason, performance assumptions should be verified in the firm’s own environment. Benchmark results observed elsewhere, whether from vendors or peers, are less relevant than measurements taken on the actual production hardware and network configuration.
At this stage, the B3 production market data feed can provide full central limit order book visibility for target instruments, but the system remains in observation mode.
With stable production data flowing through the binary handler, strategy development and calibration become the primary focus.
This phase is often more substantial than anticipated. Even where a firm is migrating from FIX rather than onboarding from scratch, differences in message structure and internal processing paths can affect timing assumptions and signal behaviour. Production data is therefore used to feed trading logic, generate signals and validate expected behaviour without routing live orders to the exchange.
Only once strategy outputs are consistent and infrastructure characteristics are well understood does it make sense to proceed further. In many cases, this phase becomes iterative, with refinements made to both infrastructure and strategy logic based on observed market behaviour.
Integration of the B3 Binary Order Entry (B3 BOE) API typically follows only after the upstream components have been proven stable. Order entry integration introduces session management, message construction, sequencing and the incorporation of pre-trade risk controls. At this stage, firms conduct internal validation cycles to confirm correct order and trade handling, while also undergoing B3’s mandatory manual certification process for order entry connectivity within the PUMA environment. Both are required and distinct, and together they become central before production deployment.
Because this stage carries direct execution exposure, firms often approach initial deployment conservatively. Controlled trades with limited risk are used to confirm end-to-end behaviour before scaling activity. Further optimisation, whether in infrastructure tuning or strategy parameters, may follow early production experience.
For firms adopting B3’s binary APIs, the quality of the integration tooling can influence both development speed and risk containment.
OnixS provides SDK support for both the B3 Binary UMDF and B3 Binary Order Entry APIs, including reference implementation source code samples designed to accelerate initial integration. These fast-start examples cover common functional requirements such as order book construction, session handling and message processing, allowing development teams to focus on strategy and infrastructure optimisation rather than building connectivity frameworks from first principles.
The SDK distribution also includes benchmark samples that enable firms to measure send, receive and round-trip characteristics within their own deployment environment. Given that performance outcomes are inherently hardware- and configuration-dependent, the ability to validate behaviour directly on target infrastructure supports the staged approach outlined above.
In addition, forward migration provisions within licensing agreements help reduce friction as venue APIs evolve, turning what might otherwise be disruptive migrations into routine operational updates. When combined with production-grade support and defined service level commitments, these elements are designed to support firms that view binary API adoption as a structured engineering programme rather than a tactical protocol switch.