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, MIFID and SFTR 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.1

Message Structure

Regulatory timestamps are populated in the message TransactTime, when available.

Clients may reference or populate all other regulatory fields for appropriate messages via the use of dedicated repeating groups containing key/value pairs, at the appropriate level within the message structure:

RegulatoryBodies

This field in the main message body provides an explicit indication whether or not SEF, EMIR or MiFID fields are populated elsewhere in the message structure and provides the message reader - either Whisperer or the Client with an explicit means of deciding whether or not this request/trade requires further regulatory processing.

If the Client believes that they are submitting a trade on MTF (an NDF for example), then they should set the flag for MiFID.

Flags are ordered SEF EMIR MiFID SFTR. If connecting via FIX Protocol, this would be represented as : "N N Y N"

Regulatory Fields

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

ISINs

For swaps, ISINs are maintained at the Leg level in the API.

Product-level ISINs are sometimes still supported, but most of the venues have completely moved away from that now, due to regulatory clarifications provided, as per MiFID II and FX Swaps June2017.pdf.

A Body-Level PackageID should (but usually isn't) be provided to link the two legs together.

Should we receive a single top-level ISIN only for a swap, we will populate this in both Legs for consistency of reference. Should we receive three ISINs (both legs and a single top-level one), the per-leg ones will be used and the top-level one delivered as a passthru-field, just in case.

For more detail reference the SBE Schema.

Venue-Specific Details

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

Additional Material

Further detail is provided in the following page(s):