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

...

Prices and Quantities are represented by PriceNULL and DecimalQtyNULL composites which comprise an int64 mantissa, and an int8 exponent.

Warning
These datatypes differ from the equivalents defined in The Whisperer Classic SBE3 Schema, which defines fixed scalings for each.

Whisperer honours Whisperer Enterprise honours the implied precision of all prices and quantities passed between Client and Venue.This is achieved , and Clients should match the decimal precision provided by the Venue for both, by setting mantissa and exponent values for the relevant SBE datatypes  (DecimalQtyNULL and PriceNULL) such that the original value representation is preserved.

...

title	Negative values

Note
title Fractional Trailing Zeros
A feature of FIX protocol interfaces (vs binary APIs) is that they involve an integer to string conversion when constructing the message. The way this is performed varies not only across venues, but also across individual fields or message types. The net result is that trailing zeros for a fractional component may not always be published, so that a price could move between "1.1999" and "1.2", vs the "1.2000") that would be most consistent.

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:

• Negative quantities are used in pre-trade allocations to denote the opposite allocation direction vs the net direction for the leg as a whole.
• Negative prices are used to represent negative Forward Points, where appropriate.

Examples

Examples below:

...

Taker Considerations - Orders

In PreviouslyQuoted sessions, it is important that the client takes care to provide both of the following in their NewOrderMultileg messages:

• Spot rate - tag 44/Price
• All-In rate for each leg - tag 566/LegPrice

Maker Considerations - Prices

There is a surprising amount of variation across Venues regarding Maker pricing -  not not just the required precisions that prices must be published to, but also how much looseness they allow across individual components. In order to guarantee a uniform interface, MarketFactory Whisperer essentially has to adopt, and enforce, the strictest rules.  

To assist this, the Whisperer Enterprise SBE Schema requires that forward points be expressed in a pip-based (scaled) form, rather than arithmetically (unscaled) - this enables run-time inference of the location of the pip to ensure that Fwd Pts are always correctly converted to/from scaled and unscaled forms as necessary to meet specific Venue API requirements.

...

In the context of the SBE schema, this means that attention must paid to the Exponent of the individual PriceNULL fields, since when necessary, Pip location is determined by reference to the difference between All-in and Fwd Pts exponents.  In particular, it is very important to ensure that quoted all-in rates are to the correct all-in precision.

Worked Example for EUR/USD - Pip location is the fourth decimal place:

Another example (correct):

Versus (wrong, as it implies pip is at the fifth decimal place):