Strings

String values will either be the size of the fixed length field or NULL (\0) terminated, if shorter.

Reading

• If the string is smaller than the field length then it will end with NULL.
• If the string is the same length as the field length then there is no terminator.

Writing

• If the string is smaller than the field length, it needs to be terminated with at least one NULL. it is not necessary to ensure that the remainder of the field is all NULL values (although this will work).
• If the string is the same length as the field length then no terminator is used.

Timestamps

Whisperer's SBE timestamp datatypes (UTCTimestamp and ValidUntilTime) are both of nanosecond precision., but the actual values sent/received to the venue will depend on the precision that the venue supports.

• Client to Venue - Clients should ideally always ensure that all published timestamps are at the greatest precision that they can support. For fields that will be mapped through to an equivalent field on the outbound venue message (such as TransactTime, ValidUntilTime, EffectiveTime, ExpireTime, etc), Whisperer will always utilise the full precision supported by the venue, with the client value being truncated as necessary.
• Venue to Client - Whisperer will always publish the full precision available in any timestamp received from the venue. Typically FIX venues provide millisecond values, but some fields may be second, or microsecond precision. Binary APIs will typically offer microsecond or nanosecond precisions.

Prices and Quantities

Overview

...

Nullness

The SBE Technical Specification contains the definition of nullness for composite types, such as PriceNULL and DecimalQtyNULL:

4.5.4.4 Null value of a composite type

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.

The MF API additionally offers a nullable exponent to offer convenience support for integer types, when needed:

• There is no need to differentiate between exponent = 0 and exponent = NULL.
• A NULL exponent with a valid mantissa is treated exactly the same as exponent = 0. Therefore, when the mantissa is present (i.e., not NULL), an exponent value of 0 should always be treated as a valid exponent (i.e., scale = 10⁰).

Key Rules

• Mantissa determines nullness of the price
• If mantissa = -9223372036854775808, the entire price is NULL
• Exponent should not drive null logic
• Even though its encoded nullValue is 0, it should not be interpreted as “missing” when mantissa is valid
• No caching should be applied based on exponent = 0
• Exponent = 0 must be treated as a real value, not a signal to reuse a previous value

Scaling Considerations

The maximum mantissa value is  2^{^63} - 1 = 9,223,372,036,854,775,807

This is because a 64-bit signed integer uses one bit for the sign (positive or negative) and the remaining 63 bits for the value.

When decimal arithmetic is performed, the new mantissa value is first calculated, and then scaled according to the combined exponents. Inappropriately set precisions may cause problems, especially when multiplications are performed (as is the case when ExecutionReport LegCalculatedCcyQty and LegAllocCalculatedCcyQty values are calculated). For example:

• LegAllocQty = 1,000,000.000000000 = 1,000,000,000,000,000 * 10^-9
• LastPx = 1.047400 = 1,047,400 * 10^-6
• LegCalculatedCcyQty = (1,000,000,000,000,000 * 1,047,400) * 10^-9-6 = 1,047,400,000,000,000,000,000 * 10^-15 = 1047400.000000000000000
• 1,047,400,000,000,000,000,000 > 9,223,372,036,854,775,807 and is thus not representable.

Such problems are easily avoided by ensuring that Quantities in particular are always scaled appropriately. 

Negative Values

DecimalQtyNULL and PriceNULL may both be used to represent negative values:

...

Examples below:

...