Technical Specification
Version 1.0 with Errata – Technical Standard – July 27, 2018
THIS DOCUMENT IS THE FINAL VERSION OF A FIX TECHNICAL STANDARD. THIS VERSION HAS BEEN
APPROVED BY THE GLOBAL TECHNICAL COMMITTEE AS THE FINAL STEP IN CREATING A NEW FIX
TECHNICAL STANDARD OR A NEW VERSION OF AN EXISTING FIX TECHNICAL STANDARD. POTENTIAL
ADOPTERS ARE STRONGLY ENCOURAGED TO USE ONLY THE FINAL VERSION. EXISTING ADOPTERS ARE
STRONGLY ENCOURAGED TO UPGRADE TO THE FINAL VERSION.
FIX Simple Binary Encoding (SBE) targets high performance trading systems. It is optimized for low latency of encoding and decoding while keeping bandwidth utilization reasonably small. For compatibility, it is intended to represent all FIX semantics.
This encoding specification describes the wire protocol for messages. Thus, it provides a standard for interoperability between communicating parties. Users are free to implement the standard in a way that best suits their needs.
The encoding standard is complimentary to other FIX standards for session protocol and application level behavior.
The Technical Specification is split into the following sections:
In order to support traditional FIX semantics, all the documented field types are supported. However, instead of printable character representations of tag-value encoding, the type system binds to native binary data types, and defines derived types as needed.
The binary type system has been enhanced in these ways:
Provides a means to specify precision of decimal numbers and timestamps, as well as valid ranges of numbers.
Differentiates fixed-length character arrays from variable-length strings. Allows a way to specify the minimum and maximum length of strings that an application can accept.
Provides a consistent system of enumerations, Boolean switches and multiple-choice fields.
The message design strives for direct data access without complex transformations or conditional logic. This is achieved by:
Usage of native binary data types and simple types derived from native binaries, such as prices and timestamps.
Preference for fixed positions and fixed length fields, supporting direct access to data and avoiding the need for management of heaps of variable-length elements which must be sequentially processed.
This standard describes how fields are encoded and the general structure of messages. The content of a message type is specified by a message schema. A message schema tells which fields belong to a message and their location within a message. Additionally, the metadata describes valid value ranges and information that need not be sent on the wire, such as constant values.
Message schemas may be based on standard FIX message specifications, or may be customized as needed by agreement between counterparties.
Data type - A field type with its associated encoding attributes, including backing primitive types and valid values or range. Some types have additional attributes, e.g. epoch of a date.
Encoding - a message format for interchange. The term is commonly used to mean the conversion of one data format to another, such as text to binary. However, Simple Binary Encoding strives to use native binary data types in order to make conversion unnecessary, or at least trivial. Encoding also refers to the act of formatting a message, as opposed to decoding.
Message schema - metadata that specifies messages and their data types and identifiers. Message schemas may be disseminated out of band. For Simple Binary Encoding, message schemas are expressed as an XML document that conforms to an XML schema that is published as part of this standard.
Message template - metadata that specifies the fields that belong to one particular message type. A message template is contained by a message schema.
Session protocol - a protocol concerned with the reliable delivery of messages over a transport. FIX protocol makes a distinction between session protocol and the encoding of a message payload, as described by this document. See the specifications section of FIX protocol web site for supported protocols. The original FIX session protocol is known as FIXT.
XML schema - defines the elements and attributes that may appear in an XML document. The SBE message schema is defined in W3C (XSD) schema language since it is the most widely adopted format for XML schemas.
This document explains:
The binary type system for field encoding
Message structure, including field arrangement, repeating groups, and relationship to a message header that may be provided by a session protocol.
The Simple Binary Encoding message schema.
These key words in this document are to be interpreted as described in Internet Engineering Task Force RFC2119. These terms indicate an absolute requirement for implementations of the standard: “must”, or “required”.
This term indicates an absolute prohibition: “must not”.
These terms indicate that a feature is allowed by the standard but not required: “may”, “optional”. An implementation that does not provide an optional feature must be prepared to interoperate with one that does.
These terms give guidance, recommendation or best practices: “should” or “recommended”. A recommended choice among alternatives is described as “preferred”.
These terms give guidance that a practice is not recommended: “should not” or “not recommended”.
In this document, these formats are used for technical specifications and data examples.
This is a sample encoding specification
<type name="short" primitiveType="int16" semanticType="int" />
This is sample data as it would be transmitted on the wire
10270000
Simple Open Framing Header, FIX Protocol, Limited. Version 1.0 Draft Standard specification has been published at http://www.fixtradingcommunity.org/
For FIX semantics, see the current FIX message specification, which is currently FIX 5.0 Service Pack 2 with Extension Packs.
SBE is dependent on several industry standards. Implementations must conform to these standards to interoperate. Therefore, they are normative for SBE.
IEEE 754-2008 A Standard for Binary Floating-Point Arithmetic
ISO 639-1:2002 Codes for the representation of names of languages - Part 1: Alpha-2 code
ISO 3166-1:2013 Codes for the representation of names of countries and their subdivisions - Part 1: Country codes
ISO 4217:2015 Codes for the representation of currencies and funds
ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times
ISO 10383:2012 Securities and related financial instruments - Codes for exchanges and market identification (MIC)
XML 1.1 schema standards are located here W3C XML Schema
A field is a unit of data contained by a FIX message. Every field has the following aspects: semantic data type, encoding, and metadata. They will be specified in more detail in the sections on data type encoding and message schema but are introduced here as an overview.
The FIX semantic data type of a field tells a data domain in a broad sense, for example, whether it is numeric or character data, or whether it represents a time or price. Simple Binary Encoding represents all of the semantic data types that FIX protocol has defined across all encodings. In message specifications, FIX data type is declared with attribute semanticType. See the section 2.2 below for a listing of those FIX types.
Encoding tells how a field of a specific data type is encoded on the wire. An encoding maps a FIX data type to either a simple, primitive data type, such as a 32 bit signed integer, or to a composite type. A composite type is composed of two or more simple primitive types. For example, the FIX data type Price is encoded as a decimal, a composite type containing a mantissa and an exponent. Note that many fields may share a data type and an encoding. The sections that follow explain the valid encodings for each data type.
Field metadata, part of a message schema, describes a field to application developers. Elements of field metadata are:
Field ID, also known as FIX tag, is a unique identifier of a field for semantic purposes. For example, tag 55 identifies the Symbol field of an instrument.
Field name, as it is known in FIX specifications
The FIX semantic data type and encoding type that it maps to
Valid values or data range accepted
Documentation
Metadata is normally not sent on the wire with Simple Binary Encoding messages. It is necessary to possess the message schema that was used to encode a message in order to decode it. In other words, Simple Binary Encoding messages are not self-describing. Rather, message schemas are typically exchanged out-of-band between counterparties.
See section 4 below for a detailed message schema specification.
By default, fields are assumed to be required in a message. However, fields may be specified as optional. To indicate that a value is not set, a special null indicator value is sent on the wire. The null value varies according to data type and encoding. Global defaults for null value may be overridden in a message schema by explicitly specifying the value that indicates nullness.
Alternatively, fields may be specified as constant. In which case, the data is not sent on the wire, but may be treated as constants by applications.
Default value handling is not specified by the encoding layer. A null value of an optional field does not necessarily imply that a default value should be applied. Rather, default handling is left to application layer specifications.
FIX semantic types are mapped to binary field encodings as follows. See sections below for more detail about each type.
Schema attributes may restrict the range of valid values for a field. See Common field schema attributes below.
The FIX semantic types listed above are spelled and capitalized exactly as they are in the FIX repository from which official FIX documents and references are derived.
Schema attributes alter the range of valid values for a field. Attributes are optional unless specified otherwise.
The attributes listed above apply to a field element or its encoding (wire format). Any attributes specified on an encoding are inherited by fields that use that encoding.
Encodings may be added to SBE messages that do not correspond to listed FIX data types. In that case, the encoding and fields that use the encoding will not have a semanticType attribute.
Integer encodings should be used for cardinal or ordinal number fields. Signed integers are encoded in a two’s complement binary format.
Numeric data types may be specified by range and signed or unsigned attribute. Integer types are intended to convey common platform primitive data types as they reside in memory. An integer type should be selected to hold the maximum range of values that a field is expected to hold.
The default data ranges and null indicator are listed below for each integer encoding.
A message schema may optionally specify a more restricted range of valid values for a field.
For optional fields, a special null value is used to indicate that a field value is not set. The default null indicator may also be overridden by a message schema.
Required and optional fields of the same primitive type have the same data range. The null value must not be set for a required field.
The byte order of integer fields, and for derived types that use integer components, is specified globally in a message schema. Little-Endian order is the default encoding, meaning that the least significant byte is serialized first on the wire.
See section 4.3.1 for specification of message schema attributes, including byteOrder. Message schema designers should specify the byte order most appropriate to their system architecture and that of their counterparties.
By nature, integers map to simple encodings. These are valid encoding specifications for each of the integer primitive types.
<type name="int8" primitiveType="int8" /> +<type name="int16" primitiveType="int16" /> +<type name="int32" primitiveType="int32" /> +<type name="int64" primitiveType="int64" /> +<type name="uint8" primitiveType="uint8" /> +<type name="uint16" primitiveType="uint16" /> +<type name="uint32" primitiveType="uint32" /> +<type name="uint64" primitiveType="uint64" />
Examples show example schemas and encoded bytes on the wire as hexadecimal digits in Little-Endian byte order.
Example integer field specification
<field type="uint32" name="ListSeqNo" id="67" semanticType="int" + description="Order number within the list" />
Value on the wire - uint32 value decimal 10,000, hexadecimal 2710.
Optional field with a valid range 0-6
<type name="range06" primitiveType="uint8" maxValue="6" + presence="optional" nullValue="255" /> +<field type="range06" name="MaxPriceLevels" id="1090" + semanticType="int"/>
Wire format of uint8 value decimal 3.
03
Sequence number field with integer encoding
<field type="uint64" name="MsgSeqNum" id="34" + semanticType="SeqNum" />
Wire format of uint64 value decimal 100,000,000,000, hexadecimal 174876E800.
00e8764817000000
Wire format of uint16 value decimal 10000, hexadecimal 2710.
1027
Wire format of uint32 null value 232 - 1
ffffffff
Decimal encodings should be used for prices and related monetary data types like PriceOffset and Amt.
FIX specifies Qty as a float type to support fractional quantities. However, decimal encoding may be constrained to integer values if that is appropriate to the application or market.
Prices are encoded as a scaled decimal, consisting of a signed integer mantissa and signed exponent. For example, a mantissa of 123456 and exponent of -4 represents the decimal number 12.3456.
Mantissa represents the significant digits of a decimal number. Mantissa is a commonly used term in computing, but it is properly known in mathematics as significand or coefficient.
Exponent represents scale of a decimal number as a power of 10.
A floating-point decimal transmits the exponent on the wire while a fixed-point decimal specifies a fixed exponent in a message schema. A constant negative exponent specifies a number of assumed decimal places to the right of the decimal point.
Implementations should support both 32 bit and 64 bit mantissa. The usage depends on the data range that must be represented for a particular application. It is expected that an 8 bit exponent should be sufficient for all FIX uses.
Optionally, implementations may support any other signed integer types for mantissa and exponent.
The default data ranges and null indicator are listed below for each decimal encoding.
A message schema may optionally specify a more restricted range of valid values for a field. For optional fields, a special mantissa value is used to indicate that a field value is null.
Decimal encodings are composite types, consisting of two subfields, mantissa and exponent. The exponent may either be serialized on the wire or may be set to constant. A constant exponent is a way to specify an assumed number of decimal places.
Decimal encoding specifications that an implementation must support
<composite name="decimal" > + <type name="mantissa" primitiveType="int64" /> + <type name="exponent" primitiveType="int8" /> +</composite> + +<composite name="decimal32" > + <type name="mantissa" primitiveType="int32" /> + <type name="exponent" primitiveType="int8" + presence="constant">-2</type> +</composite> + +<composite name="decimal64"> + <type name="mantissa" primitiveType="int64" /> + <type name="exponent" primitiveType="int8" + presence="constant">-2</type> +</composite>
When both mantissa and exponent are sent on the wire for a decimal, the elements are packed by default. However, byte alignment may be controlled by specifying offset of the exponent within the composite encoding. See section 4.4.4.3 below.
Examples show encoded bytes on the wire as hexadecimal digits, little-endian.
FIX Qty data type is a float type, but a decimal may be constrained to integer values by setting exponent to zero.
<composite name="intQty32" semanticType="Qty"> + <type name="mantissa" primitiveType="int32" /> + <type name="exponent" primitiveType="int8" + presence="constant">0</type> +</composite>
Field inherits semanticType from encoding
<field type="intQty32" name="OrderQty" id="38" + description="Total number of shares" />
Wire format of decimal 123.45 with 2 significant decimal places.
3930000000000000fe
Wire format of decimal64 123.45 with 2 significant decimal places. Schema attribute exponent = -2
3930000000000000
Wire format of decimal32 123.45 with 2 significant decimal places. Schema attribute exponent = -2
39300000
Binary floating point encodings are compatible with IEEE Standard for Floating-Point Arithmetic (IEEE 754-2008). They should be used for floating point numeric fields that do not represent prices or monetary amounts. Examples include interest rates, volatility and dimensionless quantities such as ratios. On the other hand, decimal prices should be encoded as decimals; see section 2.5 above.
Both single and double precision encodings are supported as primitive data types. See the IEEE 754-2008 standard for ranges and details of the encodings.
For both float and double precision encodings, null value of an optional field is represented by the Not-a-Number format (NaN) of the standard encoding. Technically, it indicated by the so-called quiet NaN.
Like integer encodings, floating point encodings follow the byte order specified by message schema. See section 4.3.1 for specification of message schema attributes, including byteOrder.
These are valid encoding specifications for each of the floating point primitive types.
<type name="float" primitiveType="float" /> +<type name="double" primitiveType="double" />
A single precision ratio
<type name="ratio" primitiveType="float" /> + +<field type="ratio" name="CurrencyRatio" id="1382" + semanticType="float"/>
Wire format of float 255.678
91ad7f43
Wire format of double 255.678
04560e2db2f56f40
Character data may either be of fixed size or variable size. In Simple Binary Encoding, fixed-length fields are recommended in order to support direct access to data. Variable-length encoding should be reserved for character strings that cannot be constrained to a specific size. It may also be used for non-ASCII encoded strings.
Character fields hold a single character. They are most commonly used for field with character code enumerations. See section 2.12 below for discussion of enum fields.
Valid values of a char field are printable characters of the US-ASCII character set (codes 20 to 7E hex.) The implicit nullValue is the NUL control character (code 0).
This is the standard encoding for char type.
<type name="char" primitiveType="char" semanticType="char" />
Wire format of char encoding of “A” (ASCII value 65, hexadecimal 41)
41
Character arrays are allocated a fixed space in a message, supporting direct access to fields. A fixed size character array is distinguished from a variable length string by the presence of a length schema attribute or a constant attribute.
A length attribute set to zero indicates variable length. See section 2.7.3 below for variable-length data encoding.
A fixed-length character array encoding must specify primitiveType=“char” and a length attribute is required.
Range attributes minValue and maxValue do not apply to fixed-length character arrays.
US-ASCII is the default encoding of character arrays to conform to usual FIX values. The characterEncoding attribute may be specified to override encoding.
A typical string encoding specification
<type name="string6" primitiveType="char" semanticType="String" + length="6" /> + +<field type="string6" name="Symbol" id="55" />
Wire format of a character array in character and hexadecimal formats
M S F T
4d5346540000
A character array constant specification
<type name="EurexMarketID" semanticType="Exchange" + primitiveType="char" length="4" description="MIC code" + presence="constant">XEUR</type> + +<field type="EurexMarketID" name="MarketID" id="1301" />
Variable-length string encoding is used for variable length ASCII strings or embedded non-ASCII character data (like EncodedText field). A separate length field coveys the size of the field.
On the wire, length immediately precedes the data.
The length subfield may not be null, but may be set to zero for an empty string. In that case, no space is reserved for the data. No distinction is made at an encoding layer between an empty string and a null string. Semantics of an empty variable-length string should be specified at an application layer.
Optionally, implementations may support any other unsigned integer types for length.
If the Length element has minValue and maxValue attributes, it specifies the minimum and maximum length of the variable-length data.
Range attributes minValue , maxValue, and nullValue do not apply to the data element.
If a field is required, both the Length and data fields must be set to a “required” attribute.
Variable length string is encoded as a composite type, consisting of a length sub field and data subfield. The length attribute of the varData element is set to zero in the XML message schema as special value to indicate that the character data is of variable length.
To map an SBE data field specification to traditional FIX, the field ID of a data field is used. Its associated length is implicitly contained by the composite type rather than specified as a separate field.
Encoding specification for variable length data up to 65535 octets
<composite name="varString" description="Variable-length string"> + <type name="length" primitiveType="uint16" semanticType="Length"/> + <type name="data" length="0" primitiveType="uint8" + semanticType="data" characterEncoding="UTF-16"/> +</composite> + +<data name="SecurityDesc" id="107" type="varString"/>
The characterEncoding attribute tells which variable-sized encoding is used if the data field represents encoded text. UTF-8 is the recommended encoding, but there is no default in the XML schema
Example shows encoded bytes on the wire.
Wire format of variable-length String in character and hexadecimal formats, preceded by uint16 length of 4 octets in little-endian byte order
04004d534654
Raw data is opaque to SBE. In other words, it is not constrained by any value range or structure known to the messaging layer other than length. Data fields simply convey arrays of octets.
Data may either be of fixed-length or variable-length. In Simple Binary Encoding, fixed-length data encoding may be used for data of predetermined length, even though it does not represent a FIX data type. Variable-length encoding should be reserved for raw data when its length is not known until run-time.
Data arrays are allocated as a fixed space in a message, supporting direct access to fields. A fixed size array is distinguished from a variable length data by the presence of a length schema attribute rather than sending length on the wire.
A fixed-length octet array encoding should specify primitiveType=“uint8” and a length attribute is required.
Data range attributes minValue and maxValue do not apply.
Since raw data is not constrained to a character set, characterEncoding attribute should not be specified.
A fixed-length data encoding specification for a binary user ID
<type name="uuid" primitiveType="uint8" length="16" description="RFC 4122 compliant UUID"/> + +<field type="uuid" name="Username" id="553" />
Variable-length data is used for variable length non-character data (such as RawData). A separate length field conveys the size of the field. On the wire, length immediately precedes the data.
The length subfield may not be null, but it may be set to zero. In that case, no space is reserved for the data. Semantics of an empty variable-length data element should be specified at an application layer.
If the Length field has minValue and maxValue attributes, it specifies the minimum and maximum length of the variable-length data. Data range attributes minValue , maxValue, and nullValue do not apply to a data field.
Variable length data is encoded as composite type, consisting of a length sub field and data subfield.
<composite name="DATA" description="Variable-length data"> + <type name="length" primitiveType="uint16" semanticType="Length"/> + <type name="data" length="0" primitiveType="uint8" semanticType="data" /> +</composite> + +<data name="RawData" id="96" type="DATA"/>
Wire format of data in character and hexadecimal formats, preceded by uint16 length of 4 octets in little-endian byte order
MonthYear encoding contains four subfields representing respectively year, month, and optionally day or week. A field of this type is not constrained to one date format. One message may contain only year and month while another contains year, month and day in the same field, for example.
Values are distinguished by position in the field. Year and month must always be populated for a non-null field. Day and week are set to special value indicating null if not present. If Year is set to the null value, then the entire field is considered null.
The four subfields of MonthYear are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section 4.4.4.3 below.
MonthYear data type is based on a composite encoding that carries its required and optional elements.
The standard encoding specification for MonthYear
<composite name="monthYear" semanticType="MonthYear"> + <type name="year" primitiveType="uint16" presence="optional" + nullValue="65536" /> + <type name="month" primitiveType="uint8" minValue="1" maxValue="12" /> + <type name="day" primitiveType="uint8" minValue="1" maxValue="31" + presence="optional" nullValue="255" /> + <type name="week" description="week of month" primitiveType="uint8" + minValue="1" maxValue="5" presence="optional" nullValue="255" /> +</composite>
Example MonthYear field specification
Wire format of MonthYear 2014 June week 3 as hexadecimal
de0706ff03
Dates and times represent Coordinated Universal Time (UTC). This is the preferred date/time format, except where regulations require local time with time zone to be reported (see time zone encoding below).
Each time type has an epoch, or start of a time period to count values. For timestamp and date, the standard epoch is the UNIX epoch, midnight January 1, 1970 UTC.
A time-only value may be thought of as a time with an epoch of midnight of the current day. Like current time, the epoch is also referenced as UTC.
Time unit tells the precision at which times can be collected. Time unit may be serialized on the wire if timestamps are of mixed precision. On the other hand, if all timestamps have the same precision, then time unit may be set to a constant in the message schema. Then it need not be sent on the wire.
Time specifications use an enumeration of time units. See section 2.13 below for a fuller explanation of enumerations.
Enumeration of time units:
<enum name="TimeUnit" encodingType="uint8"> + <validValue name="second">0</validValue> + <validValue name="millisecond">3</validValue> + <validValue name="microsecond">6</validValue> + <validValue name="nanosecond">9</validValue> +</enum>
Timestamp with variable time units:
<composite name="UTCTimestamp" description="UTC timestamp with precision on the wire" semanticType="UTCTimestamp" > + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" /> +</composite>
Timestamp with constant time unit:
<composite name="UTCTimestampNanos" description="UTC timestamp with nanosecond precision" semanticType="UTCTimestamp" > + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.nanosecond" /> +</composite>
Time only with variable time units:
<composite name="UTCTime" description="Time of day with precision on the wire" semanticType="UTCTimeOnly" > + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" /> +</composite>
Time only with constant time unit:
<composite name="UTCTimeNanos" description="Time of day with millisecond precision" semanticType="UTCTimeOnly" > + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.millisecond" /> +</composite>
Date only specification:
<type name="date" primitiveType="uint16" semanticType="UTCDateOnly" />
timestamp 14:17:22 Friday, October 4, 2024 UTC (20,000 days and 14 hours, 17 minutes and 22 seconds since the UNIX epoch) with default schema attributes
<composite name="UTCTimestampNanos" description="UTC timestamp with nanosecond precision" semanticType="UTCTimestamp" > +<type name="time" primitiveType="uint64" /> +<type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.nanosecond" /> +</composite>
Wire format of UTCTimestamp with constant time unit in little-Endian byte order
4047baa145fb17
time 10:24:39.123456000 (37,479 seconds and 123456000 nanoseconds since midnight UTC) with default schema attributes
<composite name="UTCTimeOnlyNanos" description="UTC time of day with nanosecond precision" semanticType="UTCTimeOnly" > + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.nanosecond" /> +</composite>
Wire format of UTCTimeOnly
10d74916220000
date Friday, October 4, 2024 (20,000 days since UNIX epoch) with default schema attributes
Wire format of UTCDateOnly
204e
Local date is encoded the same as UTCDateOnly, but it represents local time at the market instead of UTC time.
The standard encoding specification for LocalMktDate
<type name="localMktDate" primitiveType="uint16" semanticType="LocalMktDate" />
Time with time zone encoding should only be used when required by market regulations. Otherwise, use UTC time encoding (see above).
Time zone is represented as an offset from UTC in the ISO 8601:2004 format ±hhmm.
A binary UTCTimestamp followed by a number representing the time zone indicator as defined in ISO 8601:2004.
The subfields of TZTimestamp are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section 4.4.4.3 below.
Standard TZTimestamp encoding specification
<composite name="tzTimestamp" semanticType="TZTimestamp"> + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" /> + <!-- Sign of timezone offset is on hour subfield --> + <type name="timezoneHour" primitiveType="int8" minValue="-12" maxValue="14" /> + <type name="timezoneMinute" primitiveType="uint8" maxValue="59" /> +</composite>
Wire format of TZTimestamp 8:30 17 September 2013 with Chicago time zone offset (-6:00)
0050d489fea22413fa00
A binary UTCTimeOnly followed by a number representing the time zone indicator as defined in ISO 8601:2004.
The time zone hour offset tells the number of hours different to UTC time. The time zone minute tells the number of minutes different to UTC. The sign telling ahead or behind UTC is on the hour subfield.
The subfields of TZTimeOnly are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section 4.4.4.3 below.
Standard TZTimeOnly encoding specification
<composite name="tzTimeOnly" semanticType="TZTimeOnly"> + <type name="time" primitiveType="uint64" /> + <type name="unit" primitiveType="uint8" /> + <!-- Sign of timezone offset is on hour subfield --> + <type name="timezoneHour" primitiveType="int8" + minValue="-12" maxValue="14" /> + <type name="timezoneMinute" primitiveType="uint8" minValue="0" + maxValue="59" /> +</composite>
Wire format of TZTimeOnly 8:30 with Chicago time zone offset (-6:00)
006c5ebe76000000fa00
An enumeration conveys a single choice of mutually exclusive valid values.
An unsigned integer or character primitive type is selected to contain the number of choices. Implementations must support char and uint8 types. They may additionally support other unsigned integer types to allow more choices.
If a field is of FIX data type char, then its valid values are restricted to US-ASCII printable characters. See section 2.7.1 above.
If the field is of FIX data type int, then a primitive integer data type should be selected that can contain the number of choices. For most cases, an 8 bit integer will be sufficient, allowing 255 possible values.
Enumerations of other data types, such as String valid values specified in FIX, should be mapped to an integer wire format in SBE.
In a message schema, the choices are specified a <validValue> members of an <enum>. An <enum> specification must contain at least one <validValue>.
<validValue>
<enum>
The name and value of a validValue element must be unique within an enumeration.
An <enum> element must have an encodingType attribute to specify the type of its values. Two formats of encodingType are acceptable:
In-line style: the value of encodingType is its primitive data type.
Reference style: the value of encodingType is the name of a <type> element that specifies the wire format.
<type>
The length of a <type> associated to an enumeration must be 1. That is, enumerations should only be backed by scalar types, not arrays.
These examples use a char field for enumerated code values.
Example enum lists acceptable values and gives the underlying encoding, which in this case is char (in-line style)
<enum name="SideEnum" encodingType="char"> + <validValue name="Buy">1</validValue> + <validValue name="Sell">2</validValue> + <validValue name="SellShort">5</validValue> + <validValue name="SellShortExempt">6</validValue> + <!-- not all FIX values shown --> +</enum>
Reference to type: This specification is equivalent to the one above.
<type name="charEnumType" primitiveType="char"/> + <enum name="SideEnum" encodingType="charEnumType"> + <!-- valid values as above --> +</enum>
Side field specification references the enumeration type
<field name="Side" type="SideEnum" id="54" />
Wire format of Side “Buy” code as hexadecimal
01
A constant field may be specified as a value of an enumeration. The attribute valueRef is a cross-reference to validValue entry by symbolic name.
Example of a char field using a constant enum value
<enum name="PartyIDSourceEnum" encodingType="char"> + <validValue name="BIC">B</validValue> + <validValue name="GeneralIdentifier">C</validValue> + <validValue name="Proprietary">D</validValue> +</enum> + +<field type="PartyIDSourceEnum" name="PartyIDSource" id="447" + description="Party ID source is fixed" presence="constant" + valueRef="PartyIDSourceEnum.GeneralIdentifier" />
A Boolean field is a special enumeration with predefined valid values: true and false. Like a standard enumeration, an optional Boolean field may have nullValue that indicates that the field is null (or not applicable).
Standard encoding specifications for required and optional Boolean fields
<enum name="booleanEnum" encodingType="uint8" semanticType="Boolean"> + <validValue name="false">0</validValue> + <validValue name="true">1</validValue> +</enum> + +<enum name="optionalBoolean" encodingType="uint8" semanticType="Boolean"> + <validValue name="false">0</validValue> + <validValue name="true">1</validValue> + <validValue name="nullValue">255</validValue> +</enum>
Example optional Boolean field
<field type="optionalBoolean" name="SolicitedFlag" id="377" />
Wire format of true value as hexadecimal
Wire format of false value as hexadecimal
00
Wire format of null Boolean (or N/A) value as hexadecimal
ff
A multi-value field conveys a choice of zero or more non-exclusive valid values.
The binary encoding uses a bitset (a fixed-size sequence of bits, also known as bitmap, bit array or bit vector) to represent up to 64 possible choices. The encoding is backed by an unsigned integer. The smallest unsigned primitive type should be selected that can contain the number of valid choices.
Like other integer-backed encodings, multi-value encodings follow the byte order specified by message schema when serializing to the wire. See section 4.3.1 for specification of message schema attributes, including byteOrder.
Each choice is assigned a bit of the primitive integer encoding, starting with the least significant bit. For each choice the value is selected or not, depending on whether it corresponding bit is set or cleared.
Any remaining unassigned bits in an octet should be cleared.
There is no explicit null value for multi-value choice encoding other than to set all bits off when no choices are selected.
In a message schema, the choices are specified as <choice> members of an <set> element. Choices are assigned values as an ordinal of bits in the bit set. The first Choice “0” is assigned the least significant bit; choice “1” is the second bit, and so forth.
<choice>
<set>
The name and value (bit position) must be unique for element of a set.
A <set> element must have an encodingType attribute to specify the wire format of its values. Two formats of encodingType are recognized :
The length of a <type> associated to an bitset must be 1. That is, bitsets should not be specified as arrays.
Example of a multi-value choice (was MultipleCharValue in tag-value encoding) Encoding type is in-line style.
<set name="FinancialStatusEnum" encodingType="uint8"> + <choice name="Bankrupt">0</choice> + <choice name="Pending delisting">1</choice> + <choice name="Restricted">2</choice> +</set>
Reference to type. This is equivalent to the example above.
<type name="u8Bitset" primitiveType="uint8"/> + +<set name="FinancialStatusEnum" encodingType="u8Bitset"> +<!--choices as above --> +</set>
A field using the multi-choice encoding
<field type="FinancialStatus" name="FinancialStatusEnum" + id="291" semanticType="MultipleCharValue"/>
Wire format of choices “Bankrupt” + “Pending delisting” (first and second bits set)
These validations apply to message field values.
If a value violation is detected on a received message, the message should be rejected back to the counterparty in a way appropriate to the session protocol.
SBE messages have no defined message delimiter. Version 2.0 of SBE makes it possible to walk the elements of a message to determine its limit, even when the message has been extended. Nevertheless, since internal framing depends on a correct starting point and not encountering malformed messages, it may be desirable to use an external framing protocol when used with transports that do not preserve message boundaries, such as when they are transmitted on a streaming session protocol or when persisting messages in storage.
FIX Protocol Ltd. offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats, such as Simple Binary Encoding.
The framing header provides two features:
An overall message size including headers to support framing
An identifier of the encoding used in the message payload. This supports selecting the correct decoder in the case where multiple message encodings are used on a session. It also aids tooling such as protocol analyzers to identify message protocols contained in network packets.
While the Simple Open Framing Header specification is normative, the following is an interpretation of that standard as an SBE encoding. Note that the framing standard specifies that the framing header will always be encoded in big-endian byte order, also known as network byte order.
Simple Open Framing Header as an SBE composite encoding (big-endian)
<composite name="framingHeader"/> + <type name="messageLength" primitiveType="uint32" /> + <type name="encodingType" primitiveType="uint16" /> +</composite>
The values of encodingType used to indicate SBE payloads are currently defined as:
The Simple Open Framing Header specification also lists values for other wire formats.
The purpose of the message encoding header is to tell which message template was used to encode the message and to give information about the size of the message body to aid in decoding, even when a message template has been extended in a later version. See section 5 below for an explanation of the schema extension mechanism.
The fields of the SBE message header are:
Block length of the message root - the total space reserved for the root level of the message not counting any repeating groups or variable-length fields.
Template ID - identifier of the message template
Schema ID - identifier of the message schema that contains the template
Schema version - the version of the message schema in which the message is defined
Group count - the number of repeating groups in the root level of the message
Variable-length field count - the number of variable-length fields in the root level of the message
Block length is specified in a message schema, but it is also serialized on the wire. By default, block length is set to the sum of the sizes of body fields in the message. However, it may be increased to force padding at the end of block. See section 3.3.3.3 below.
The header fields precede the message body of every message in a fixed position as shown below. Each of these fields must be encoded as an unsigned integer type. The encoding must carry the name “messageHeader”.
The message header is encoded in the same byte order as the message body, as specified in a message schema. See section 4.3.1.
Recommended message header encoding
<composite name="messageHeader" description="Template ID and length of message root"> + <type name="blockLength" primitiveType="uint16"/> + <type name="templateId" primitiveType="uint16"/> + <type name="schemaId" primitiveType="uint16"/> + <type name="version" primitiveType="uint16"/> + <type name="numGroups" primitiveType="uint16" /> + <type name="numVarDataFields" primitiveType="uint16" /> +</composite>
The recommended header encoding is 12 octets.
Optionally, implementations may support any other unsigned integer types for blockLength.
The total space reserved for the root level of the message not counting any repeating groups or variable-length fields. (Repeating groups have their own block length; see section 3.4 below. Length of a variable-length Data field is given by its corresponding Length field; see section 2.7.3 above.) Block length only represents message body fields; it does not include the length of the message header itself, which is a fixed size.
The block size must be at least the sum of lengths of all fields at the root level of the message, and that is its default value. However, it may be set larger to reserve more space to effect alignment of blocks. This is specified by setting the blockLength attribute in a message schema.
The identifier of a message type in a message schema. See section 4.5.2 below for schema attributes of a message.
The identifier of a message schema. See section 4.3.1 below for schema attributes.
The version number of the message schema that was used to encode a message. See section 4.3.1 below for schema attributes.
A count of repeating groups at the root level of the message. The count does not include nested repeating groups.
A count of the variable-length fields at the root level of the message. The count does not include variable-length fields within repeating groups.
The message body conveys the business information of the message.
In SBE, fields of a message occupy proximate space without delimiters or metadata, such as tags.
Access to data is positional, guided by a message schema that specifies a message type.
Data fields in the message body correspond to message schema fields; they are arranged in the same sequence. The first data field has the type and size specified by the first message schema field, the second data field is described by the second message schema field, and so forth. Since a message decoder follows the field descriptions in the schema for position, it is not necessary to send field tags on the wire.
In the simplest case, a message is flat record with a fixed length. Based on the sequence of field data types, the offset to a given data field is constant for a message type. This offset may be computed in advance, based on a message schema. Decoding a field consists of accessing the data at this fixed location.
By default, there is no padding between fields. In other words, a field value is packed against values of its preceding and following fields. No consideration is given to byte boundary alignment.
By default, the position of a field in a message is determined by the sum of the sizes of prior fields, as they are defined by the message schema.
<field name="ClOrdID" id="11" type="string14" + semanticType="String"/> +<field name="Side" id="54" type="char" semanticType="char"/> +<field name="OrderQty" id="38" type="intQty32" + semanticType="Qty"/> +<field name="Symbol" id="55" type="string8" semanticType="String"/>
If a message designer wishes to introduce padding or control byte boundary alignment or map to an existing data structure, field offset may optionally be specified in a message schema. Field offset is the number of octets from the start of the message body or group to the first octet of the field. Offset is a zero-based index.
If specified, field offset must be greater than or equal to the sum of the sizes of prior fields. In other words, an offset is invalid if it would cause fields to overlap.
Extra octets specified for padding should never be interpreted as business data. They should be filled with binary zeros.
Example of fields with specified offsets
<field name="ClOrdID" id="11" type="string14" offset="0" + semanticType="String"/> +<field name="Side" id="54" type="char" offset="14" + semanticType="char"/> +<field name="OrderQty" id="38" type="intQty32" offset="16" + semanticType="Qty"/> +<field name="Symbol" id="55" type="string8" offset="20" + semanticType="String"/>
In order to force messages or groups to align on byte boundaries or map to an existing data structure, they may optionally be specified to occupy a certain space with a blockLength attribute in the message schema. The extra space is padded at the end of the message or group. If specified, blockLength must be greater than or equal to the sum of the sizes of all fields in the message or group.
The blockLength attribute applies only to the portion of message that contains fix-length fields; it does not apply to variable-length data elements of a message.
Extra octets specified for padding should be filled with binary zeros.
Example of blockLength specification for 24 octets
<message name="ListOrder" id="2" blockLength="24">
A repeating group is a message structure that contains a variable number of entries. Each entry contains fields specified by a message schema.
The order and data types of the fields are the same for each entry in a group. That is, the entries are homogeneous. Position of a given field within any entry is fixed, with the exception of variable-length fields.
A message may have no groups or an unlimited number of repeating groups specified in its schema.
A repeating group is defined in a message schema by adding a <group> element to a message template. An unlimited number of <field> elements may be added to a group, but a group must contain at least one field.
<group>
<field>
Example repeating group encoding specification
<group name="Parties" id="1012" blockLength="16"> + <field name="PartyID" id="448" type="string14" + semanticType="String"/> + <field name="PartyIDSource" id="447" type="char" + semanticType="char"/> + <field name="PartyRole" id="452" type="uint8" semanticType="int"/> +</group>
The blockLength part of a group dimension represents total space reserved for each group entry, not counting any nested repeating groups or variable-length fields. (Length of a variable-length Data field is given by its corresponding Length field.) Block length only represents message body fields; it does not include the length of the group dimension itself, which is a fixed size.
By default, the space reserved for an entry is the sum of a group’s field lengths, as defined by a message schema, without regard to byte alignment.
The space reserved for an entry may optionally be increased to effect alignment of entries or to plan for future growth. This is specified by adding the group attribute blockLength to reserve a specified number of octets per entry. If specified, the extra space is padded at the end of each entry and should be set to zeroes by encoders. The blockLength value does not include the group dimensions itself.
Note that padding will only result in deterministic alignment if the repeating group contains no variable-length fields.
Each group is associated with a required counter field of semantic data type NumInGroup to tell how many entries are contained by a message. The value of the counter is a non-negative integer. See “Encoding of repeating group dimensions” section below for encoding of that counter.
The space reserved for all entries of a group is the product of the space reserved for each entry times the value of the associated NumInGroup counter. If the counter field is set to zero, then no entries are sent in the message, and no space is reserved for entries. The group dimensions including the zero-value counter is still transmitted, however.
A message may contain multiple repeating groups at the same level.
Example of encoding specification with multiple repeating groups
<message name="ExecutionReport" id="8"> + <group name="ContraGrp" id="2012"> + <!-- ContraGrp group fields --> + </group> + <group name="PreAllocGrp" id="2026"> + <!-- PreAllocGrp group fields --> + </group> +</message>
Repeating groups may be nested to an arbitrary depth. That is, a <group> in a message schema may contain one or more <group> child elements, each associated with their own counter fields.
The encoding specification of nested repeating groups is in the same format as groups at the root level of a message in a recursive procedure.
Example of nested repeating group specification
<group name="ListOrdGrp" id="2030"> + <field name="ClOrdID" id="11" type="string14" semanticType="String"/> + <field name="ListSeqNo" id="67" type="uint32" semanticType="int"/> + <field name="Symbol" id="55" type="string8" semanticType="String"/> + <field name="Side" id="54" type="char" semanticType="char"/> + <field name="OrderQty" id="38" type="intQty32" semanticType="Qty"/> + <group name="Parties" id="1012"> + <field name="PartyID" id="448" type="string14" semanticType="String"/> + <field name="PartyRole" id="452" type="int" semanticType="int"/> + </group> +</group>
Nested repeating groups are encoded on the wire by a depth-first walk of the data hierarchy. For example, all inner entries under the first outer entry must be encoded before encoding outer entry 2. (This is the same element order as FIX tag=value encoding.)
On decoding, nested repeating groups do no support direct access to fields. It is necessary to walk all elements in sequence to discover the number of entries in each repeating group.
If a group contains nested repeating groups, then a NumInGroup counter of zero implies that both that group and its child groups are empty. In that case, no NumInGroup is encoded on the wire for the child groups.
Every repeating group must be immediately preceded on the wire by its dimensions. The two dimensions are the count of entries in a repeating group and the space reserved for each entry of the group.
Implementations should support uint8 and uint16 types for repeating group entry counts. Optionally, implementations may support any other unsigned integer types.
By default, the minimum number of entries is zero, and the maximum number is the largest value of the primitiveType of the counter.
The number of entries may be restricted to a specific range; see “Restricting repeating group entries” below.
Conventionally in FIX, a NumInGroup field conveys the number of entries in a repeating group. In SBE, the encoding conveys two dimensions: the number of entries and the length of each entry in number octets. Therefore, the encoding is a composite of those two elements. Block length and entry count subfields must be encoded as unsigned integer types.
By default, the name of the group dimension encoding is groupSizeEncoding. This name may be overridden by setting the dimensionType attribute of a <group> element.
Recommended encoding of repeating group dimensions
<composite name="groupSizeEncoding"> + <type name="blockLength" primitiveType="uint16"/> + <type name="numInGroup" primitiveType="uint16" semanticType="NumInGroup"/> + <type name="numGroups" primitiveType="uint16" /> + <type name="numVarDataFields" primitiveType="uint16" /> +</composite>
The total space reserved for the fixed-length fields of this repeating group, not counting any repeating groups or variable-length fields.
The number of entries in this repeating group, called NumInGroup in FIX.
A count nested repeating groups in this repeating group.
A count of the variable-length fields in this repeating group.
Wire format of NumInGroup with block length 55 octets by 3 entries, containing one nested group and two variable-length fields.
3700030001000200
The occurrences of a repeating group may be restricted to a specific range by modifying the numInGroup member of the group dimension encoding. The minValue attribute controls the minimum number of entries, overriding the default of zero, and the maxValue attribute restricts the maximum entry count to something less than the maximum corresponding to its primitiveType. Either or both attributes may be specified.
Example of a restricted group encoding
<type name="numInGroup" primitiveType="uint16" semanticType="NumInGroup" minValue="1" maxValue="10" />
To maximize deterministic field positions, message schemas must be specified with this sequence of message body elements:
Fixed-length fields that reside at the root level of the message (that is, not members of repeating groups), including any of the following, in the order specified by the message schema::
Fixed-length scalar fields, such as integers
Fixed-length character arrays
Fixed-length composite types, such as MonthYear
Repeating groups, if any.
Data fields, including raw data and variable-length strings, if any.
Repeating group entries are recursively organized in the same fashion as the root level: fixed-length fields, then nested repeating groups, and finally, variable-length data fields.
Aside from message schema validations (see section 4.8 below), these validations apply to message structure.
If a message structure violation is detected on a received message, the message should be rejected back to the counterparty in a way appropriate to the session protocol.
See sbe.xsd for the normative XML Schema Definition (XSD) for SBE.
The Simple Binary Encoding XML schema is identified by this URL [tentative]:
xmlns:sbe=http://fixprotocol.io/2017/sbe
Conventionally, the URI of the XML schema is aliased by the prefix “sbe”.
Caution: Users should treat the SBE XML namespace as a URI (unique identifier), not as a URL (physical resource locator). Firms should not depend on access to the FIX Trading Community web site to validate XML schemas at run-time
All symbolic names in a message schema are restricted to alphanumeric characters plus underscore without spaces. This is the same restriction applied to all names in FIX specifications.
The value of a field’s semanticType attribute is a FIX data type. In this document, FIX types are capitalized exactly as in the FIX repository, from which all official FIX documentation and references are derived. Since the capitalization is somewhat inconsistent, however, it is recommended that matching of type names should be case insensitive in schema parsers.
semanticType
The root element of the XML document is <messageSchema>.
<messageSchema>
The root element provides basic identification of a schema.
The byteOrder attribute controls the byte order of integer encodings within the schema. It is a global setting for all specified messages and their encodings.
byteOrder
Changes to a message schema may be tracked by its version attribute. A version of a schema is a snapshot in time. All elements in a given generation of the schema share the same version number. That is, elements are not versioned individually. By convention, the initial version of a schema is version zero, and subsequent changes increment the version number.
version
The package attribute should remain constant between versions, if it is supplied.
package
The <types> element contains one or more sets of data encodings used for messages within the schema.
<types>
Within each set, an unbound number of encodings will be listed in any sequence:
Element <type> defines a simple encoding
Element <composite> defines a composite encoding
<composite>
Element <enum> defines an enumeration
Element <set> defines a multi-value choice bitset encoding
The namespace for encoding names is global across all encodings included in a schema, including simple, composite and enumeration types. That is, the name must be unique among all encoding instances.
All symbolic names should be alphanumeric without spaces.
A suggested usage is to import common encodings that are used across message schemas as one set while defining custom encodings that are particular to a schema in another set.
Example of XML include usage to import common encoding types
<!-- included XML contains a <types> element --> +<xi:include href="sbe-builtins.xml"/>
A simple encoding is backed by either a scalar type or an array of scalars, such as a character array. One or more simple encodings may be defined, each specified by a <type> element.
If the element has a value, it is used to indicate a special value of the encoding.
The element value represents a constant if attribute presence="constant". In this case, the value is conditionally required.
presence="constant"
The attribute semanticType must be specified on either a field or on its corresponding type encoding. It need not be specified in both places, but if it is, the two values must match.
Simple type examples
<type name="FLOAT" primitiveType="double" + semanticType="float"/> +<type name="TIMESTAMP" primitiveType="uint64" + semanticType="UTCTimestamp"/> +<type name="GeneralIdentifier" primitiveType="char" + description="Identifies class or source + of the PartyID" presence="constant">C</type>
Composite encoding types are composed of two or more simple types.
A <composite> composite encoding element may be composed of any combination of types, including <type> simple encoding, <enum> enumeration, <set> bitset, and nested composite type. The elements that compose a composite type carry the same XML attributes as stand-alone types.
Composite type example
In this example, a Price is encoded as 32 bit integer mantissa and a constant exponent, which is not sent on the wire.
<composite name="decimal32" semanticType="Price"> + <type name="mantissa" primitiveType="int32" /> + <type name="exponent" primitiveType="int8" + presence="constant">-4</type> +</composite>
If a message designer wishes to control byte boundary alignment or map to an existing data structure, element offset may optionally be specified on a simple type, enum or bitset within a composite type. Offset is the number of octets from the start of the composite; it is a zero-based index.
If specified, offset must be greater than or equal to the sum of the sizes of prior elements. In other words, an offset is invalid if it would cause elements to overlap.
For a composite type, nullness is indicated by the value of its first element. For example, if a price field is optional, a null value in its mantissa element indicates that the price is null.
A composite type often has its elements defined in-line within the <composite> XML element as shown in the example above. Alternatively, a common type may be defined once on its own, and then referred to by name with the composite type using a <ref> element.
<ref>
Reference to an enum
In this example, a futuresPrice is encoded as 64 bit integer mantissa, 8 bit exponent, and a reused enum type.
<enum name="booleanEnum" encodingType="uint8" semanticType="Boolean"> + <validValue name="false">0</validValue> + <validValue name="true">1</validValue> +</enum> + +<composite name="futuresPrice"> + <type name="mantissa" primitiveType="int64" /> + <type name="exponent" primitiveType="int8" /> + <ref name="isSettlement" type="boolEnum" /> +</composite>
Reference to a composite type
In this example, a nested composite is formed by using a reference to another composite type. It supports the expresson of a monetary amount with its currency, such as USD150.45. Note that a reference may carry an offset within the composite encoding that contains it.
<composite name="price"> + <type name="mantissa" primitiveType="int64" /> + <type name="exponent" primitiveType="int8" /> +</composite> + +<composite name="money"> + <type name="currencyCode" primitiveType="char" length="3" semanticType="Currency" /> + <ref name="amount" type="price" semanticType="Price" offset="3" /> +</composite>
An enumeration explicitly lists the valid values of a data domain. Any number of fields may share the same enumeration.
Each enumeration is represented by an <enum> element. It contains any number of <validValue> elements.
The encodingType attribute refers to a simple encoding of scalar type. The encoding of an enumeration may be char or any unsigned integer type.
encodingType
The name attribute of the <validValue> uniquely identifies it.
The element is required to carry a value, which is the valid value as a string. The string value in XML must be convertible to the data type of the encoding, such as an integer.
<enum> and <validValue> elements
Enumeration example (not all valid values listed)
This enumeration is encoded as an 8 bit unsigned integer value. Others are encoded as char codes.
<type name="intEnum" primitiveType="uint8" /> + +<enum name="PartyRole" encodingType="intEnum"> + <validValue name="ExecutingFirm">1</validValue> + <validValue name="BrokerOfCredit">2</validValue> + <validValue name="ClientID">3</validValue> + <validValue name="ClearingFirm">4</validValue> +</enum>
An enumeration explicitly lists the valid values of a data domain. Any number of fields may share the same set of choices.
Each multi-value choice is represented by a <set> element. It may contain a number of <choice> elements up to the number of bits in the primitive encoding type. The largest number possible is 64 choices in a uint64 encoding.
The encodingType attribute refers to a simple encoding of scalar type. The encoding of a bitset should be an unsigned integer type.
The name attribute of the <choice> uniquely identifies it.
name
< choice >
The element is required to carry a value, which is an unsigned integer representing a zero-based index to a bit within a bitset. Zero is the least significant bit.
<set> and <choice> XML elements
Multi-value choice example, The choice is encoded as a bitset.
<type name="bitset" primitiveType="uint8" /> + +<set name="Scope" encodingType="bitset" > + <choice name="LocalMarket">0</choice> + <choice name="National">1</choice> + <choice name="Global">2</choice> +</set>
To define a message type, add a <message> element to the root element of the XML document, <messageSchema>.
<message>
The name and id attributes are required. The first is a display name for a message, while the latter is a unique numeric identifier, commonly called template ID.
id
By default, message size is the sum of its field lengths. However, a larger size may be reserved by setting blockLength, either to allow for future growth or for desired byte alignment. If so, the extra reserved space should be filled with zeros by message encoders.
A <message> element contains its field definitions in three categories, which must appear in this sequence:
Element <field> defines a fixed-length field
Element <group> defines a repeating group
Element <data> defines a variable-length field, such as raw data
<data>
The number of members of each type is unbound.
The order that fields are listed in the message schema governs the order that they are encoded on the wire.
<message> element attributes
Note that there need not be a one-to-one relationship between message template (identified by id attribute) and semanticType attribute. You might design multiple templates for the same FIX MsgType to optimize different scenarios.
Example <message> element
<sbe:message name="NewOrderSingle" id="2" semanticType="D">
Fields are added to a <message> element as child elements. See Field Encoding section above for a listing of all field types.
These are the common attributes of all field types.
Example field schemas
Field that uses a composite encoding
<composite name="intQty32" semanticType="Qty"> + <type name="mantissa" primitiveType="int32" /> + <type name="exponent" primitiveType="int8" + presence="constant">0\</type> +</composite> + +<field type="intQty32" name="OrderQty" id="38" offset="16" + description="Shares: Total number of shares" />
A <group> has the same attributes as a <message> element since they both inherit attributes from the blockType XML type. A group has the same child members as a message, and they must appear in the same order:
Element <group> defines a repeating group. Groups may be nested to any level.
<group> element inherits attributes of blockType. See <message> above.
Example group schema with default dimension encoding
<composite name="groupSizeEncoding"> + <type name="blockLength" primitiveType="uint16"/> + <type name="numInGroup" primitiveType="uint16" + semanticType="NumInGroup"/> +</composite> + +<group name="Parties" id="1012" > + <field type="string14" name="PartyID" id="448" /> + <field type="partyRoleEnum" name="PartyRole" id="452" /> +</group>
The first level of schema validation is enforced by XML schema validation tools to make sure that a schema is well-formed according to XSD schema rules. Well-formed XML is necessary but insufficient to prove that a schema is correct according to FIX Simple Binary Encoding rules.
Additional conditions that render a schema invalid include the following.
<message name="ListOrder" id="2" description="Simplified + NewOrderList. Demonstrates repeating group"> + <field name="ListID" id="66" type="string14" semanticType="String"/> + <field name="BidType" id="394" type="uint8" semanticType="int"/> + <group name="ListOrdGrp" id="2030" > + <field name="ClOrdID" id="11" type="string14" semanticType="String"/> + <field name="ListSeqNo" id="67" type="uint32" semanticType="int"/> + <field name="Symbol" id="55" type="string8" semanticType="String"/> + <field name="Side" id="54" type="char" semanticType="char"/> + <field name="OrderQty" id="38" type="intQty32" semanticType="Qty"/> + </group> +</message>
<message name="UserRequest" id="4" description="Demonstrates raw data usage"> + <field name="UserRequestId" id="923" type="string14" semanticType="String"/> + <field name="UserRequestType" id="924" type="uint8" semanticType="int"/> + <field name="UserName" id="553" type="string14" semanticType="String"/> + <field name="Password" id="554" type="string14" semanticType="String"/> + <field name="NewPassword" id="925" type="string14" semanticType="String"/> + <field name="EncryptedPasswordMethod" id="1400" type="uint8" description="This should be an enum but values undefined." + semanticType="int"/> + <field name="EncryptedPasswordLen" id="1401" type="uint8" semanticType="Length"/> + <field name="EncryptedNewPasswordLen" id="1403" type="uint8" semanticType="Length"/> + <field name="RawDataLength" id="95" type="uint8" semanticType="Length"/> + <data name="EncryptedPassword" id="1402" type="rawData" semanticType="data"/> + <data name="EncryptedNewPassword" id="1404" type="rawData" semanticType="data"/> + <data name="RawData" id="96" type="rawData" semanticType="data"/> +</message>
It is not always practical to update all message publishers and consumers simultaneously. Within certain constraints, message schemas and wire formats can be extended in a controlled way. Consumers using an older version of a schema should be compatible if interpretation of added fields or messages is not required for business processing.
This specification only details compatibility at the presentation layer. It does not relieve application developers of any responsibility for carefully planning a migration strategy and for handling exceptions at the application layer.
Compatibility is only ensured under these conditions:
Fields may be added to either the root of a message or to a repeating group, but in each case, they must be appended to end of a block.
Existing fields cannot change data type or move within a message.
A repeating group may be added after existing groups at the root level or nested within another repeating group.
A variable-length data field may be added after existing variable-length data at the root level or within a repeating group.
Message header encoding cannot change.
In general, metadata changes such as name or description corrections do not break compatibility so long as wire format does not change.
Changes that break those constraints require consumers to update to the current schema used by publishers. An message template that has changed in an incompatible way must be assinged a new template “id” attribute.
The <messageSchema> root element contains a version number attribute. By default, version is zero, the initial version of a message schema. Each time a message schema is changed, the version number is incremented.
Version applies to the schema as a whole, not to individual elements. Version is sent in the message header so the consumer can determine which version of the message schema was used to encode the message.
See section 4.3.1 above for schema attributes.
When a new field, enumeration value, group or message is added to a message schema, the extension may be documented by adding a sinceVersion attribute to the element. The sinceVersion attribute tells in which schema version the element was added. This attribute remains the same for that element for the lifetime of the schema. This attribute is for documentation purposes only, it is not sent on the wire.
Over time, multiple extensions may be added to a message schema. New fields must be appended following earlier extensions. By documenting when each element was added, it possible to verify that extensions were appended in proper order.
The length of the root level of the message may optionally be documented on a <message> element in the schema using the blockLength attribute. See section 4.5.3 above for message attributes. If not set in the schema, block length of the message root is the sum of its field lengths. Whether it is set in the schema or not, the block length is sent on the wire to consumers.
Likewise, a repeating group has a blockLength attribute to tell how much space is reserved for group entries, and the value is sent on the wire. It is encoded in the schema as part of the NumInGroup field encoding. See section 3.4.8.2 above.
A message schema may document obsolete elements, such as messages, fields, and valid values of enumerations with deprecated attribute. Updated applications should not publish deprecated messages or values, but declarations may remain in the message schema during a staged migration to replacement message layouts.
The length of the root level of the message is sent on the wire in the SBE message header. See section 3.2.2 above. Therefore, if new fields were appended in a later version of the schema, the consumer would still know how many octets to consume to find the next message element, such as repeating group or variable-length Data field. Without the current schema version, the consumer cannot interpret the new fields, but it does not break parsing of earlier fields.
Likewise, block size of a repeating group is conveyed in the NumInGroup encoding.
Message headers and repeating group dimensions carry a count of the number of repeating groups and a count of variable-length data fields on the wire. This supports a walk by a decoder of all the elements of a message, even when the decoder was built with an older version of a schema. As for added fixed-length fields, new repeating groups cannot be interpreted by the decoder, but it still can process the ones it knows, and it can correctly reach the end of a message.
This suggested strategy is non-normative.
A message decoder compares the schema version in a received message header to the version that the decoder was built with.
If the received version is equal to the decoder’s version, then all fields known to the decoder may be parsed, and no further analysis is required.
If the received version is greater than the decoder’s version (that is, the producer’s encoder is newer than the consumer’s decoder), then all fields known to the decoder may be parsed but it will be unable to parse added fields.
Also, an old decoder may encounter unexpected enumeration values. The application layer determines whether an unexpected value is a fatal error. Probably so for a required field since the business meaning is unknown, but it may choose to allow an unknown value of an optional field to pass through. For example, if OrdType value J=“Market If Touched” is added to a schema, and the consumer does not recognize it, then the application returns an order rejection with reason “order type not supported”, even if it does not know what “J” represents. Note that this is not strictly a versioning problem, however. This exception handling is indistinguishable from the case where “J” was never added to the enum but was simply sent in error.
If the received version is less than the decoder’s version (that is, the producer’s encoder is older than the consumer’s decoder), then only the fields of the older version may be parsed. This information is available through metadata as “sinceVersion” attribute of a field. If sinceVersion is greater than received schema version, then the field is not available. How a decoder signals an application that a field is unavailable is an implementation detail. One strategy is for an application to provide a default value for unavailable fields.
Initial version of a message schema
<messageSchema package="FIXBinaryTest" byteOrder="littleEndian"> + <types> + <type name="int8" primitiveType="int8"/> + </types> + +<message name="FIX Binary Message1" id="1" blockLength="4"> + <field name="Field1" id="1" type="int8" semanticType="int"/> +</message> + +</messageSchema>
Second version - a new message is added
<messageSchema package="FIXBinaryTest" byteOrder="littleEndian" + version="1"> + +<types> + <type name="int8" primitiveType="int8"/> + <type name="int16" primitiveType="int16" + sinceVersion="1"/> +</types> + +<message name="FIX Binary Message1" id="1" blockLength="4"> + <field name="Field1" id="1" type="int8" semanticType="int"/> +</message> + +<!-- New message added in this version--> +<message name="FIX Binary Message2" id="2" blockLength="4" + sinceVersion="1"> + <field name="Field2" id="2" type="int16" semanticType="int"/> +</message> +</messageSchema>
Third version - a field is added
<messageSchema package="FIXBinaryTest" byteOrder="littleEndian" + version="2"> + +<types> + <type name="int8" primitiveType="int8"/> + <type name="int16" primitiveType="int16" + sinceVersion="1"/> + <type name="int32" primitiveType="int32" + sinceVersion="2"/> +</types> + +<message name="FIX Binary Message1" id="1" blockLength="8"> + <field name="Field1" id="1" type="int8" semanticType="int"/> + <field name="Field11" id="11" type="int32" semanticType="int" + sinceVersion="2"/> +</message> + +<message name="FIX Binary Message2" id="2" blockLength="4" + sinceVersion="1"> + <field name="Field2" id="2" type="int16" semanticType="int"/> +</message> +</messageSchema>
FIX specifies request and entity identifiers as String type. Common practice is to specify an identifier field as fixed-length character of a certain size.
Optionally, a message schema may restrict such identifiers to numeric encodings.
Example of an identifier field with character encoding
<type name="idString" primitiveType="char" length="16" /> + +<field name="QuoteReqId" id="131" type="idString" + semanticType="String"/>
Example of an identifier field with numeric encoding
<type name="uint64" primitiveType="uint64" /> + +<field name="QuoteReqId" id="131" type="uint64" + semanticType="String"/>
The example messages are preceded by Simple Open Framing Header. Note that SOFH encoding is always big-endian, regardless of the byte order of the SBE message body. See that FIX standard for details.
Not all FIX enumeration values are listed in the samples.
This is an example of a simple, flat order message without repeating groups or variable-length data.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> + +<sbe:messageSchema + xmlns:sbe="http://fixprotocol.io/2016/sbe" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + package="Examples" id="100" + description="Test dictionary" + byteOrder="littleEndian" + xsi:schemaLocation="http://fixprotocol.io/2016/sbe sbe.xsd"> + +<types> + <type name="enumEncoding" primitiveType="char"/> + <type name="idString" length="8" primitiveType="char" semanticType="String"/> + <type name="timestampEncoding" primitiveType="uint64" semanticType="UTCTimestamp"/> + + <composite name="messageHeader"> + <type name="blockLength" primitiveType="uint16"/> + <type name="templateId" primitiveType="uint16"/> + <type name="schemaId" primitiveType="uint16"/> + <type name="version" primitiveType="uint16"/> + </composite> + + <composite name="optionalDecimalEncoding" + description="Optional decimal with constant exponent"> + <type name="mantissa" presence="optional" primitiveType="int64"/> + <type name="exponent" presence="constant" primitiveType="int8">-3</type> + </composite> + + <composite name="qtyEncoding" description="Decimal constrained to integers"> + <type name="mantissa" primitiveType="int32"/> + <type name="exponent" presence="constant" primitiveType="int8">0</type> + </composite> + + <enum name="ordTypeEnum" encodingType="enumEncoding"> + <validValue name="Market" description="Market">1</validValue> + <validValue name="Limit" description="Limit">2</validValue> + <validValue name="Stop" description="Stop Loss">3</validValue> + <validValue name="StopLimit" description="Stop Limit">4</validValue> + </enum> + + <enum name="sideEnum" encodingType="enumEncoding"> + <validValue name="Buy" description="Buy">1</validValue> + <validValue name="Sell" description="Sell">2</validValue> + </enum> + +</types> + +<sbe:message name="NewOrderSingle" id="99" blockLength="54" +semanticType="D"> + <field name="ClOrdID" id="11" type="idString" description="Customer Order ID" + offset="0" semanticType="String"/> + <field name="Account" id="1" type="idString" description="Account mnemonic" + offset="8" semanticType="String"/> + <field name="Symbol" id="55" type="idString" description="Security ID" + offset="16" semanticType="String"/> + <field name="Side" id="54" type="sideEnum" description="Side" offset="24" + semanticType="char"/> + <field name="TransactTime" id="60" type="timestampEncoding" + description="Order entry time" offset="25" semanticType="UTCTimestamp"/> + <field name="OrderQty" id="38" type="qtyEncoding" description="Order quantity" + offset="33" semanticType="Qty"/> + <field name="OrdType" id="40" type="ordTypeEnum" description="Order type" + offset="37" semanticType="char"/> + <field name="Price" id="44" type="optionalDecimalEncoding" + description="Limit price" offset="38" semanticType="Price"/> + <field name="StopPx" id="99" type="optionalDecimalEncoding" + description="Stop price" offset="46" semanticType="Price"/> +</sbe:message> + +</sbe:messageSchema>
Notes on the message schema
In this case, there is a lot of verbiage for one message, but in practice, a schema would define a set of messages. The same encodings within the <types> element would be used for a whole collection of messages. For example, a price encoding need only be defined once but can be used in any number of messages in a schema. Many of the attributes, such as description, offset, and semanticType, are optional but are shown here for a full illustration.
All character fields in the message are fixed-length. Values may be shorter than the specified field length, but not longer. Since all fields are fixed-length, they are always in a fixed position, supporting direct access to data.
An enumeration gives the valid values of a field. Both enumerations in the example use character encoding, but note that some enumerations in FIX are of integer type.
There are two decimal encodings. The one used for quantity sets the exponent to constant zero. In effect there is no fractional part and only the mantissa is sent on the wire, acting as an integer. However, FIX defines Qty as a float type since certain asset classes may use fractional shares.
The other decimal encoding is used for prices. The exponent is constant -3. In essence, each price is transmitted as an integer on the wire with assumed three decimal places. Each of the prices in the message is conditionally required. If OrdType=Limit, then Price field required. If OrdType=Stop then StopPx is required. Otherwise, if OrdType=Market, then neither price is required. Therefore, the price takes an optional encoding. To indicate that it is null, a special value is sent on the wire. See the table in section 2.4.2 above for the null value of the int64 mantissa.
In this example, all fields are packed without special byte alignment. Performance testing may prove better results with a different arrangement of the fields or adjustments to field offsets. However, those sorts of optimizations are platform dependent.
Hexadecimal and ASCII representations (little-endian byte order):
00 00 00 44 eb 50 36 00 63 00 5b 00 00 00 4f 52 : D P6 c [ OR +44 30 30 30 30 31 41 43 43 54 30 31 00 00 47 45 :D00001ACCT01 GE +4d 34 00 00 00 00 31 80 16 b3 3b 13 65 29 15 07 :M4 1 ; e) +00 00 00 32 1a 85 01 00 00 00 00 00 00 00 00 00 : 2 +00 00 00 80
Interpretation
00000044
eb50
3600
6300
5b00
0000
4f52443030303031
4143435430310000
47454d3400000000
31
8016b33b13652915
07000000
32
1a85010000000000
0000000000000080
This is an example of a message with a repeating group.
Add this encoding types element to those in the previous example.
<types> + <type name="date" primitiveType="uint16" semanticType="LocalMktDate"/> + <composite name="MONTH_YEAR" semanticType="MonthYear"> + <type name="year" primitiveType="uint16"/> + <type name="month" primitiveType="uint8"/> + <type name="day" primitiveType="uint8"/> + <type name="week" primitiveType="uint8"/> + </composite> + + <composite name="groupSizeEncoding" description="Repeating group dimensions"> + <type name="blockLength" primitiveType="uint16" + semanticType="Length"/> + <type name="numInGroup" primitiveType="uint16" + semanticType="NumInGroup"/> + </composite> + + <enum name="execTypeEnum" encodingType="enumEncoding"> + <validValue name="New" description="New">0</validValue> + <validValue name="DoneForDay" description="Done for day">3</validValue> + <validValue name="Canceled" description="Canceled">4</validValue> + <validValue name="Replaced" description="Replaced">5</validValue> + <validValue name="PendingCancel">6</validValue> + <validValue name="Rejected" description="Rejected">8</validValue> + <validValue name="PendingNew" description="Pending New">A</validValue> + <validValue name="Trade" description="partial fill or fill">F</validValue> + </enum> + + <enum name="ordStatusEnum" encodingType="enumEncoding"> + <validValue name="New" description="New">0</validValue> + <validValue name="PartialFilled">1</validValue> + <validValue name="Filled" description="Filled">2</validValue> + <validValue name="DoneForDay" description="Done for day">3</validValue> + <validValue name="Canceled" description="Canceled">4</validValue> + <validValue name="PendingCancel">6</validValue> + <validValue name="Rejected" description="Rejected">8</validValue> + <validValue name="PendingNew" description="Pending New">A</validValue> + <validValue name="PendingReplace" >E</validValue> + </enum> + +</types> + +<sbe:message name="ExecutionReport" id="98" blockLength="42" +semanticType="8"> + <field name="OrderID" id="37" type="idString" description="Order ID" + offset="0" semanticType="String"/> + <field name="ExecID" id="17" type="idString" description="Execution ID" + offset="8" semanticType="String"/> + <field name="ExecType" id="150" type="execTypeEnum" + description="Execution type" offset="16" semanticType="char"/> + <field name="OrdStatus" id="39" type="ordStatusEnum" + description="Order status" offset="17" semanticType="char"/> + <field name="Symbol" id="55" type="idString" description="Security ID" + offset="18" semanticType="String"/> + <field name="MaturityMonthYear" id="200" type="MONTH_YEAR" + description="Expiration" offset="26" semanticType="MonthYear"/> + <field name="Side" id="54" type="sideEnum" description="Side" offset="31" + semanticType="char"/> + <field name="LeavesQty" id="151" type="qtyEncoding" + description="Quantity open" offset="32" semanticType="Qty"/> + <field name="CumQty" id="14" type="qtyEncoding" + description="Executed quantity" offset="36" semanticType="Qty"/> + <field name="TradeDate" id="75" type="date" + description="Trade date" offset="40" semanticType="LocalMktDate"/> + <group name="FillsGrp" id="2112" description="Partial fills" + blockLength="12" dimensionType="groupSizeEncoding"> + <field name="FillPx" id="1364" type="optionalDecimalEncoding" + description="Price of partial fill" offset="0" semanticType="Price"/> + <field name="FillQty" id="1365" type="qtyEncoding" + description="Executed quantity" offset="8" semanticType="Qty"/> + </group> +</sbe:message>
The message contains a MonthYear field. It is encoded as a composite type with year, month, day and week subfields.
This message layout contains a repeating group containing a collection of partial fills for an execution report. The <group> XML tag enclosed the fields within a group entry. The dimensions of the repeating group are encoding as a composite type called groupSizeEncoding.
00 00 00 54 eb 50 2a 00 62 00 5b 00 00 00 4f 30 : T P* b [ O0 +30 30 30 30 30 31 45 58 45 43 30 30 30 30 46 31 :000001EXEC0000F1 +47 45 4d 34 00 00 00 00 de 07 06 ff ff 31 01 00 :GEM4 1 +00 00 06 00 00 00 75 3e 0c 00 02 00 1a 85 01 00 : u> +00 00 00 00 02 00 00 00 24 85 01 00 00 00 00 00 : $ +04 00 00 00 :
Offset is from beginning of block.
00000054
2a00
6200
4558454330303030
30
de0706ffff
01000000
06000000
753e
0c000200
02000000
2485010000000000
04000000
+<types> + <type name="intEnumEncoding" primitiveType="uint8"/> + + <composite name="DATA" description="Variable-length data"> + <type name="length" primitiveType="uint16" /> + <type name="varData" length="0" primitiveType="uint8"> + </composite> + + <enum name="businessRejectReasonEnum" encodingType="intEnumEncoding">> + <validValue name="Other" 0</validValue> + <validValue name="UnknownID" 1</validValue> + <validValue name="UnknownSecurity" >2</validValue> + <validValue name="ApplicationNotAvailable" >4</validValue> + <validValue name="NotAuthorized" >6</validValue> + </enum> + +</types> + + <sbe:message name="BusinessMessageReject" id="97" + blockLength="9" semanticType="j"> + <field name="BusinesRejectRefId" id="379" type="idString" + offset="0" semanticType="String" /> + <field name="BusinessRejectReason" id="380" type="businessRejectReasonEnum" + offset="8" semanticType="int" /> + <data name="Text" id="58" type="DATA" semanticType="data" /> + </sbe:message>
00 00 00 40 eb 50 09 00 61 00 5b 00 00 00 4f 52 : @ P a [ OR +44 30 30 30 30 31 06 27 00 4e 6f 74 20 61 75 74 :D00001 ' Not aut +68 6f 72 69 7a 65 64 20 74 6f 20 74 72 61 64 65 :horized to trade +20 74 68 61 74 20 69 6e 73 74 72 75 6d 65 6e 74 : that instrument
00000040
0900
6100
06
4e6f74206175...
Version 1.0 with Errata – Technical Standard – November 2020
The Financial Information eXchange Simple Binary Encoding (SBE) targets high performance trading systems. It is optimized for low latency of encoding and decoding while keeping bandwidth utilization reasonably small. For compatibility, it is intended to represent all FIX semantics.
In order to support traditional FIX semantics, all the documented field types are supported. However, instead of printable character representations of tag-value encoding, the type system binds to native binary datatypes, and defines derived types as needed.
Usage of native binary datatypes and simple types derived from native binaries, such as prices and timestamps.
Message schemas may be based on standard FIX message specifications or may be customized as needed by agreement between counterparties.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
— IETF RFC 2119 – Key words for use in RFCs to Indicate Requirement Levels March 1997
Simple Open Framing Header, technical specification of a message framing standard for FIX messages.
FIX Latest, normative specification of the application layer of the FIX Protocol.
ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
datatype - A field type with its associated encoding attributes, including backing primitive types and valid values or range. Some types have additional attributes, e.g. epoch of a date.
Encoding - a message format for interchange. The term is commonly used to mean the conversion of one data format to another, such as text to binary. However, Simple Binary Encoding strives to use native binary datatypes in order to make conversion unnecessary, or at least trivial. Encoding also refers to the act of formatting a message, as opposed to decoding.
Session protocol - a protocol concerned with the reliable delivery of messages over a transport. FIX protocol makes a distinction between session protocol and the encoding of a message payload, as described by this document. See the specifications section of the FIX protocol web site for supported protocols.
A field is a unit of data contained by a FIX message. Every field has the following aspects: semantic datatype, encoding, and metadata. They will be specified in more detail in the sections on datatype encoding and message schema but are introduced here as an overview.
The FIX semantic datatype of a field tells a data domain in a broad sense, for example, whether it is numeric or character data, or whether it represents a time or price. Simple Binary Encoding represents all of the semantic datatypes that FIX protocol has defined across all encodings. In message specifications, FIX datatype is declared with attribute semanticType. See the section FIX datatype summary for details.
A datatype is defined as a combination of a value space and a lexical space. Value space is the range of its possible values while lexical space is how those values are represented in a message encoding, in this case SBE. Value space of datatypes is defined using the vocabulary in ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD). That standard defines types independently of platform and programming language.
Encoding tells how a field of a specific datatype is encoded on the wire. An encoding maps a FIX datatype to either a simple, primitive datatype, such as a 32-bit signed integer, or to a composite type. A composite type is composed of two or more simple primitive types. For example, the FIX datatype Price is encoded as a decimal, a composite type containing a mantissa and an exponent. Note that many fields may share a datatype and an encoding. The sections that follow explain the valid encodings for each datatype.
The FIX semantic datatype and encoding type that it maps to
See section Message Schema for details.
By default, fields are assumed to be required in a message. However, fields may be specified as optional. To indicate that a value is not set, a special null indicator value is sent on the wire. The null value varies according to datatype and encoding. Global defaults for null value may be overridden in a message schema by explicitly specifying the value that indicates nullness.
Schema attributes may restrict the range of valid values for a field. See section Common field schema attributes for details.
Encodings may be added to SBE messages that do not correspond to listed FIX datatypes. In that case, the encoding and fields that use the encoding will not have a semanticType attribute.
Numeric datatypes may be specified by range and signed or unsigned attribute. Integer types are intended to convey common platform primitive datatypes as they reside in memory. An integer type should be selected to hold the maximum range of values that a field is expected to hold.
The default data range and null indicator are listed below for each integer encoding.
See section Message schema attributes for the specification, including byteOrder. Message schema designers should specify the byte order most appropriate to their system architecture and that of their counterparties.
Implementations should support both 32-bit and 64-bit mantissa. The usage depends on the data range that must be represented for a particular application. It is expected that an 8-bit exponent should be sufficient for all FIX uses.
When both mantissa and exponent are sent on the wire for a decimal, the elements are packed by default. However, byte alignment may be controlled by specifying offset of the exponent within the composite encoding. See section Element offset within a composite type for details.
FIX Qty datatype is a float type, but a decimal may be constrained to integer values by setting exponent to zero.
Binary floating point encodings are compatible with IEEE Standard for Floating-Point Arithmetic (IEEE 754-2008). They should be used for floating point numeric fields that do not represent prices or monetary amounts. Examples include interest rates, volatility and dimensionless quantities such as ratios. On the other hand, decimal prices should be encoded as decimals; see section Decimal encoding for details.
Both single and double precision encodings are supported as primitive datatypes. See the IEEE 754-2008 standard for ranges and details of the encodings.
Like integer encodings, floating point encodings follow the byte order specified by message schema. See section Message schema attributes for the specification, including byteOrder.
Character fields hold a single character. They are most commonly used for field with character code enumerations. See section Enumeration encoding for details.
A length attribute set to zero indicates variable length. See section Variable-length string encoding for details.
Data may either be of fixed-length or variable-length. In Simple Binary Encoding, fixed-length data encoding may be used for data of predetermined length, even though it does not represent a FIX datatype. Variable-length encoding should be reserved for raw data when its length is not known until run-time.
The four subfields of MonthYear are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section Element offset within a composite type for details.
MonthYear datatype is based on a composite encoding that carries its required and optional elements.
Time specifications use an enumeration of time units. See section Enumeration encoding for details.
004047baa145fb17
0010d74916220000
The subfields of TZTimestamp are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section Element offset within a composite type for details.
Wire format of TZTimestamp 8:30 17 September 2013 with Chicago time zone offset (-6:00) and nanosecond timeunit
0050d489fea2241309fa00
The subfields of TZTimeOnly are packed at an octet level by default. However, byte alignment may be controlled by specifying offset of the elements within the composite encoding. See section Element offset within a composite type for details.
If a field is of FIX datatype char, then its valid values are restricted to US-ASCII printable characters. See section Character for details.
If the field is of FIX datatype int, then a primitive integer datatype should be selected that can contain the number of choices. For most cases, an 8-bit integer will be sufficient, allowing 255 possible values.
Enumerations of other datatypes, such as String valid values specified in FIX, should be mapped to an integer wire format in SBE.
In-line style: the value of encodingType is its primitive datatype.
Like other integer-backed encodings, multi-value encodings follow the byte order specified by message schema when serializing to the wire. See section Message schema attributes for the specification, including byteOrder.
The purpose of the message encoding header is to tell which message template was used to encode the message and to give information about the size of the message body to aid in decoding, even when a message template has been extended in a later version. See section Schema Extension Mechanism for details.
Block length is specified in a message schema, but it is also serialized on the wire. By default, block length is set to the sum of the sizes of body fields in the message. However, it may be increased to force padding at the end of block. See section Padding at end of a message or group for details.
The message header is encoded in the same byte order as the message body, as specified in a message schema. See section Message schema attributes for the specification.
The total space reserved for the root level of the message not counting any repeating groups or variable-length fields. (Repeating groups have their own block length; see section Repeating groups for details. Length of a variable-length Data field is given by its corresponding Length field; see section Variable-length string encoding for details.) Block length only represents message body fields; it does not include the length of the message header itself, which is a fixed size.
The identifier of a message type in a message schema. See section Message schema attributes for the specification.
The identifier of a message schema. See section Message schema attributes for the specification.
The version number of the message schema that was used to encode a message. See section Message schema attributes for the specification.
Each group is associated with a required counter field of semantic data type NumInGroup to tell how many entries are contained by a message. The value of the counter is a non-negative integer. See section Encoding of repeating group dimensions for details.
The number of entries may be restricted to a specific range; see section Restricting repeating group entries for details.
Aside from message schema validations (see section Schema validation), these validations apply to message structure.
The byteOrder attribute controls the byte order of integer and float encodings within the schema. It is a global setting for all specified messages and their encodings.
In this example, a Price is encoded as 32-bit integer mantissa and a constant exponent, which is not sent on the wire.
In this example, a futuresPrice is encoded as 64-bit integer mantissa, 8-bit exponent, and a reused enum type.
This enumeration is encoded as an 8-bit unsigned integer value. Others are encoded as char codes.
Multi-value choice example, the choice is encoded as a bitset.
Fields are added to a <message> element as child elements. See section Field Encoding for a listing of all field types.
<group> element inherits attributes of blockType. See <message> element above.
See section Message schema attributes for the specification.
The length of the root level of the message may optionally be documented on a <message> element in the schema using the blockLength attribute. See section Message element attributes for details. If not set in the schema, block length of the message root is the sum of its field lengths. Whether it is set in the schema or not, the block length is sent on the wire to consumers.
Likewise, a repeating group has a blockLength attribute to tell how much space is reserved for group entries, and the value is sent on the wire. It is encoded in the schema as part of the NumInGroup field encoding. See section Encoding of repeating group dimensions for details.
The length of the root level of the message is sent on the wire in the SBE message header. See section Root block length for details. Therefore, if new fields were appended in a later version of the schema, the consumer would still know how many octets to consume to find the next message element, such as repeating group or variable-length Data field. Without the current schema version, the consumer cannot interpret the new fields, but it does not break parsing of earlier fields.
Also, an old decoder may encounter unexpected enumeration values. The application layer determines whether an unexpected value is a fatal error. Probably so for a required field since the business meaning is unknown, but it may choose to allow an unknown value of an optional field to pass through. For example, if OrdType(40)=J (Market If Touched (MIT)) is added to a schema, and the consumer does not recognize it, then the application returns an order rejection with reason “order type not supported”, even if it does not know what “J” represents. Note that this is not strictly a versioning problem, however. This exception handling is indistinguishable from the case where “J” was never added to the enum but was simply sent in error.
The other decimal encoding is used for prices. The exponent is constant -3. In essence, each price is transmitted as an integer on the wire with assumed three decimal places. Each of the prices in the message is conditionally required. If OrdType(40)=2 (Limit), then the field Price(44) is required. If OrdType(40)=3 (Stop/Stop Loss) then StopPx(99) is required. Otherwise, if OrdType(40)=1 (Market), then neither price is required. Therefore, the price fields take an optional encoding. To indicate that it is null, a special value is sent on the wire. See the table in section Range attributes for integer fields for the null value of the int64 mantissa.
00b863e7343d2a15
+<types> + <type name="intEnumEncoding" primitiveType="uint8"/> + + <composite name="DATA" description="Variable-length data"> + <type name="length" primitiveType="uint16" /> + <type name="varData" length="0" primitiveType="uint8"> + </composite> + + <enum name="businessRejectReasonEnum" encodingType="intEnumEncoding">> + <validValue name="Other">0</validValue> + <validValue name="UnknownID">1</validValue> + <validValue name="UnknownSecurity">2</validValue> + <validValue name="ApplicationNotAvailable">4</validValue> + <validValue name="NotAuthorized">6</validValue> + </enum> + +</types> + + <sbe:message name="BusinessMessageReject" id="97" + blockLength="9" semanticType="j"> + <field name="BusinessRejectRefID" id="379" type="idString" + offset="0" semanticType="String" /> + <field name="BusinessRejectReason" id="380" type="businessRejectReasonEnum" + offset="8" semanticType="int" /> + <data name="Text" id="58" type="DATA" semanticType="String" /> + </sbe:message>
-FIX Simple Binary Encoding by [FIX Protocol Ltd.](http://www.fixtradingcommunity.org/) is licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/).
-Based on a work at