ISO/IEC 25390:2025 — Financial Information Exchange (FIX) Simple Binary Encoding

1. Introduction to Simple Binary Encoding (SBE)

ISO/IEC 25390:2025 defines the Simple Binary Encoding (SBE) — a binary wire format originally developed by the FIX Trading Community for high-performance financial trading systems. Unlike traditional FIX tag-value encoding which uses human-readable text, SBE uses native binary datatypes to achieve dramatically lower latency and higher throughput. The standard was adopted under the ISO/IEC JTC 1 PAS (Publicly Available Specification) procedure, making it an official international standard for financial messaging.

For engineers building electronic trading systems, SBE represents the state of the art in wire format efficiency. Encoding overhead is reduced to near zero — fields are laid out in fixed positions with native binary types, allowing sub-microsecond decode times without memory allocation. This is critical when every microsecond of latency directly impacts trading profitability.

SBE is designed around several key principles:

Direct data access — Fixed positions and fixed-length fields enable random access without sequential parsing
Native binary types — No conversion between text and binary; data is stored in its natural format
Out-of-band metadata — The message schema (XML) is exchanged separately from the wire data
Fixed-length preference — Variable-length fields and repeating groups are supported but minimized

Feature	FIX Tag-Value (Traditional)	FIX SBE (ISO 25390)
Encoding	ASCII text (e.g., “35=D\|55=IBM\|54=1\|…”)	Binary (field at known byte offset)
Parsing model	Sequential scan for tag numbers	Direct memory access by offset
Memory allocation	Per-field string allocation	Zero-allocation decode possible
Decode latency	Microseconds to milliseconds	Sub-microsecond (typically less than 100 ns)
Schema	Implicit (field definitions in comments/docs)	Explicit XML schema (XSD)
Wire size	Large (verbose text)	Compact (native binary size + minimal framing)
Versioning	New tags added; old tags deprecated	Schema versioning with backward compatibility

A key engineering insight: the 4-5 orders of magnitude latency difference between tag-value and SBE is not just about binary vs. text. The critical design decision is fixed field positions. Tag-value requires scanning the entire message to find a specific tag; SBE allows direct memory access at a known offset. For a 50-field message, this is the difference between 50 sequential comparisons and one pointer arithmetic operation.

2. Wire Format and Message Structure

2.1 Field Encoding

SBE supports a comprehensive set of datatypes mapped to native binary representations:

FIX Datatype	SBE Encoding	Primitive Type	Notes
int	Integer	int8/int16/int32/int64	Configurable byte order (little/big endian)
Price/Amt	Decimal	Composite (exponent + mantissa)	Fixed-point with configurable precision
Qty	Integer or Decimal	As specified	Range attributes constrain valid values
String	Variable-length string	Length prefix + char data	Length field precedes data
Char	Fixed-length char array	Byte array (no length prefix)	For fixed-width fields
Float	Floating point	float/float64	IEEE 754, null value support
UTCTimestamp	Date/time encoding	Epoch-based (configurable unit)	Nanosecond precision available
MultipleValueValue	Multi-value choice	Bit set (bitset)	Efficient flag encoding
Boolean	Enumeration	uint8 or similar	Mapped to two-value enum

2.2 Message Framing and Structure

Each SBE message consists of three parts: a framing header (provided by the session protocol, such as the Simple Open Framing Header), an SBE message encoding header (containing schema ID, template ID, schema version, block length, and counts of repeating groups and variable-length fields), and the message body. The body is a flat sequence of fields, optionally followed by repeating groups and variable-length data.

A common implementation pitfall: the byte order attribute applies to all fields within a message template and defaults to little-endian. Mixing templates with different byte orders in the same session requires careful attention. For maximum portability, network byte order (big-endian) is recommended for multi-vendor environments.

2.3 Repeating Groups

SBE supports repeating groups with fixed-length entries, where each entry has a known block length. Groups can be nested, enabling hierarchical data structures. The group dimension encoding includes blockLength and numInGroup. Empty groups (numInGroup = 0) are compact — they simply omit the group data entirely.

3. Message Schema and Extension Mechanisms

SBE message schemas are expressed as XML documents conforming to an XSD schema defined in the standard. The schema defines data encodings (simple, composite, enumeration, multi-value choice), message templates with their field attributes, and repeating group structures.

The standard’s versioning and extension mechanism (Clause 8) is particularly elegant. Fields can be added to messages in new schema versions without breaking decoders for the old version. New fields are appended after existing fields, and decoders use the blockLength field in the message header to determine how much of the message they understand. This forward-compatible design is essential for evolving trading protocols without coordination downtime.

When designing SBE schemas, follow the principle of widening before appending. If a field might need a larger type in the future (e.g., upgrading from int32 to int64), define it as the larger type from day one. Schema evolution can add new fields but cannot change existing field types without breaking compatibility.

4. Frequently Asked Questions

Q1: Is SBE limited to FIX protocol messages?
No. While SBE originated from the FIX Trading Community, the standard explicitly states that SBE is one of the possible syntaxes for FIX messages, but not limited to FIX messages. SBE can be used for any application requiring high-performance binary encoding.

Q2: How does SBE compare to Protocol Buffers or FlatBuffers?
SBE is conceptually closest to FlatBuffers — both prefer fixed positions for direct access. However, SBE’s design is more specialized for financial messaging, with native support for decimal types, timestamps with configurable precision, and FIX-specific semantics.

Q3: What is the role of the Simple Open Framing Header?
The Simple Open Framing Header provides message boundaries at the transport level. It consists of a 64-bit message length field and is defined separately from the SBE message encoding to allow flexibility in session protocol selection.

Q4: Can SBE be used over multicast or RDMA?
Yes. SBE is transport-agnostic. It is commonly used over TCP, multicast (for market data distribution), and RDMA for the lowest possible latency. The wire format’s fixed-position design is particularly beneficial for RDMA, where data can be written directly into application memory without CPU involvement.