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

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

Regulatory Fields

In order to ensure that MarketFactory does not impede the exchange of regulatory information between trading counterparties and intermediaries (ECNs), we are ensuring that all regulatory fields that are specified in a Venue API are supported in the Whisperer API, and mapped.

Rather than provide a loose, generic (i.e. obfuscated) mechanism to convey these fields, we are making separate explicit provision for SEF, EMIR and MIFID requirements - each with explicit provision for every field, across the trading lifecycle and through the deal/leg/allocation trade structure. As such, market Mid Price, LEIs, flags, regulatory trade IDs etc are supported for:

• SEF
• EMIR
• MiFID II

It needs to be understood that there is significant variation in the interpretation and implementation of all regulatory requirements across the FX market. By ensuring that all variants are accommodated, it follows that the Whisperer Enterprise SBE Schema offers a clear view of market best practice, and the potential impact to Customers intending to integrate with a wide range of Venues.

Another very important implication is that just because a regulatory field is specified in the schema for a particular message and product type does not mean that it will be populated or supported by every Venue. Similarly, it may well be that our Customers have differing views of their regulatory obligations, such that they do not all need to publish particular fields to a given Venue, or use the regulatory details provided by the Venue, internally.

In order to accommodate this variation, the Whisperer API behaviour will be as follows:

• If a regulatory field on an inbound message is not populated, then it is because the Venue does not provide it.
• If a regulatory field is populated on an outbound message, but the Venue does not support it, then it will be ignored.
• Reporting obligations bilaterally agreed between Customer and Venue may vary between Maker and Taker roles. The Whisperer API will be agnostic to this.

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, along with QuoteTTL and 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