Overview

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

Rather than provide a loose, generic (i.e. obfuscated) mechanism to convey these fields, Whisperer Enterprise makes explicit provision for SEF, EMIR and MIFID requirements as different categories, each with explicit provision for every field, across the trading lifecycle and through the deal/leg/allocation trade structure, as detailed in Message Structure below.

It needs to be understood that there is significant variation in the interpretation and implementation of all regulatory requirements across the market. By ensuring that all variants are accommodated, it follows that the Whisperer API 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 Whisperer API 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, Whisperer Enterprise behaves as follows:

• If a regulatory field on an inbound Venue message is not populated, then it is because the Venue does not provide it.
• If a regulatory field is populated on an outbound SBE message from the Client , 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 is agnostic to this.

Message Structure

MarketFactory allows clients to reference or populate these regulatory fields for appropriate messages via the use of dedicated repeating groups containing key/value pairs, at the appropriate level within the message structure:

The message body contains the RegulatoryBodies field, which provides an explicit indication whether or not SEF, EMIR or MiFID fields are populated elsewhere in the message structure.

NoBodyRegulatoryFields, NoLegRegulatoryFields and NoAllocRegulatoryFields groups contain sequences of key/value pairs, with keys of type BodyRegulatoryKey, LegRegulatoryKey and AllocRegulatoryKey, respectively.

For more detail reference the SBE Schema.

Venue-Specific Details

The table below sets out what Regulatory keys are supported by Venue and Message