TODO

• Venue "AlwaysOn" Flag

Technology Changes

Organisational

• The close coupling between Client API and server backend is FINALLY broken.
• Message and field naming conventions - migrated to usage of FIX terminology.

Config Service

• Non-essential. FH cache 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.
• Sequenced 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 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].

MFSBE4

Inboud 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.

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 Text field of the corresponding SBE message.

Arbitrary and brittle categorization into Reason enumerations has been discarded, replaced by a simple Origin - currently either MF or Venue only. No more "NOTAPPLICABLE".

Acknowledgements

Business Changes

Organisational

• Maker/Taker-agnostic: The Venue always dictates the supported message flow, the API does not make any assumptions about counterparty roles, eliminating the need for separate Maker and Taker Whisperer APIs/builds/installations.

Market Data

• Explicit identification of "Pre-Open" status (to assist allowing for backwardated prices)
• LotSize

Product Types

All FX product types supported:

• FX Spot
• FX Forward
• FX Non-Deliverable Forward - Fixing date and reference now supported.
• FX Swap
• FX Non-Deliverable Swap
• FX Block
• Future

Full Regulatory field pass-through - all explicitly supported at Body, Leg and Allocation levels, for all message types through the trade lifecycle. Market Mid Price, LEIs, flags, regulatory trade IDs etc for:

• SEF
• EMIR
• MiFID II

Counterparties

• Counterparty Firm/LEI/Trader details now provided via Parties block.

Quotation Trading Models

Full support for ESP and RFQ/RFS models:

• Pre-trade allocations.
• Order messages linked with QuoteReqID to assist supportability.
• Indicative/Tradeable QuoteType (aka Quote condition) now supported, to allow Maker ESP/RFS quote withdrawal.

Orders

Additional Time In Force support:

• GTD (Good 'til Date) - timestamp of desired order expiry (within current trading day).
• GFT (Good For Time) - number of seconds before order expiry

Additional Order types:

• Iceberg
• Pegged
• Discretion
• Trailing Stop (to double check).

Cancel/replace now allows for provision of MinQty and StopPx.

REMOVED

Software Limit Monitor

Whilst the SLM remains a component of Whisperer 3.13/14, in MFSBE4 SLM API support is now deprecated in favour of our clients using Reflector, or at least using the same notification interface as used by Reflector (WHSPRR-1676):

• TradeLimitDataMessage 
• LockUserMessage
• LockResponseMessage

Sticky Subscriptions

Sticky Subscriptions are no longer supported. in MFSBE4, we no longer make instrument subscriptions on the Client's behalf - the API 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.