The following sections outline the key Technology changes introduced with Whisperer Enterprise with respect to Whisperer Classic.

Organisational

The close coupling that previously existed between Client API and server backend is removed.
Message and field naming conventions - migrated to usage of FIX terminology.

Config Service

Less reliance on static config than previously. Venue account/username/etc details are the responsibility of the Customer and always passed through the API.
The remaining config requirements will utilise a non-essential config service:
- The FH will cache data locally and can then start/run even if service is down.
- Will allow run-time modification of config, pushed to FH.

Session Handling

Sequence Numbering - Consistent handling per venue.
All messages are sequenced.
Resendable messages to be persisted only until delivery. Single resend only.
Message gaps resolved on Logon.
Uniform support of TestRequest/Heartbeat message exchange.

Message Validation

Venue

We intend to drop the existing practice of utilizing data dictionaries to strictly validate inbound Venue FIX messages:

Overly restrictive.
Use of an out of date data dictionary breaks inherent FIX backward compatibility, thus
Support/Engineering overhead/risk.

Instead our inbound FIX message parser will follow a rules-based parsing model (for now at least). Parser validation includes the following session-level checks:

Target/Sender CompID match configuration
Inbound sequence numbers increment correctly, no gaps.
Message is well formed:
- Validity - comprised entirely of <tagnum>=<value>[SOH] tuples
- BodyLength[9] matches reality
- CheckSum[10] - matches computed value.

NOTE: No requirement to validate inbound BeginString[8].

Whisperer

Inbound messages must be validated as per specified mappings.

Venue Capabilities

Accurately reported via MarketDefinition messages on Logon.
Venue User Events now handled independently of global or per-instrument trading status changes.
Session transparency - all Venue connectivity initiated by the client via UserRequest.

Market Data

Batching : MF abstraction layer implementing a batched model of market data dissemination has been deprecated in favour of utilising a flag in the MarketDataIncrementalRefresh message indicating whether the update represents the last in the time-slice, or not.
No longer used for dissemination of Bank Quotes (as is the case in Classic) - so mkt data components are now deprecated.

Price/Quantity Representation

All prices and quantities are passed to the client to the precision provided by the Venue rather than via the fixed precision 9dp MFFloat used in Whisperer Classic.

Instrument Identification

The MF Market ID is now deprecated.
Provision of Symbol, Product Type and Tenor/Value Date are now passed explicitly and individually throughout the trading lifecycle.
SecurityDefinition message now delivers details of the Fwd Pts precision for given FX currency pair/venue. No longer does it return separate precision details for each product type/tenor.
Precision details provided in human-friendly arithmetic form.
SecurityDefinition message now contains clear human friendly representation of Symbol, to assist usage of non-ISO ccy pairs (eg crypto) and Futures codes.

Order State

Full Order details now echoed back in ExecutionReports, as opposed to the minimum set of fill details, including:

OrdType
TimeInForce

Order Fill status now maintained on a per-leg basis: LegOrderQty*, LegLastQty, LegCumQty*, LegLeavesQty. * - Newly added.

Rejections

All rejection text details provided by Venues will now be mapped through to the variable length (untruncated) Text data element of the corresponding SBE message.

Arbitrary and brittle categorization into Reason enumerations has been discarded.

Errors

Erroneous SBE messages and Venue Reject/BusinessMessageReject messages now reported via ErrorReport messages.

Acknowledgements

In new API we can Ack any type of ExecRept - not just fills (cf TradeCaptureAckMessage). To consider: Venues all handle this differently, no Acks, vs Acks of fills only, vs Acks of both Fills & Rekjections, vs Nacks of these also. Need to decide what to do here from a normalisation perspective. Do we guarantee a single, standard message flow, and 'fill-in' for venues where such messages are not supported, or leave things loose - in which case Customers will need to know the venue capabilities....

REMOVED

Sticky Subscriptions

Sticky Subscriptions are no longer supported. Whisperer Enterprise longer makes instrument subscriptions on the Client's behalf - the Client is now responsible for managing it's own subscriptions. This means:

If a venue goes down with active subscriptions then these are implicitly terminated and will need to be re-established when the connection is back up.
Clients cannot assume that connections have been made on their behalf, should their FH connection be down.

Historic Tick Streamer

Historic Market Data will be delivered via a new mechanism.