The Lab

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 1.5.96

Table of Contents

Overview

Whisperer Enterprise supports all three principle forms of Quotation Negotiation trading:

  • ESP - Executable Streaming Pricing (long-lived shared subscriptions).
  • RFS - Request For Stream (short-lived tailored subscriptions).
  • RFQ - Request For Quote (single quote with finite life).


All quotes are good until replaced, expired or withdrawn. The MFSBE API supports the following four separate mechanisms for the management of tradeable prices by a Maker:

...

Some Venues allow the Maker to specify a finite time that an individual quote is available for. This is essential for one-shot RFQ models (e.g. to support dealer intervention), but may also acts be used act as a back-stop for ESP and RFS flows to ensure that the price is promptly removed from display, in the event of error scenarios and other edge cases.

Both Quote and MassQuote messages support the provison provision of an expiry time:

...

  • Quote.ValidUntilTime

...

  • MassQuote.NoQuoteSets[*].NoQuoteEntries[*].ValidUntilTime


The default ValidUntilTime value is set far into the future, so this field may be ignored for those customers wishing to adopt a simple model.

...

A quote may be withdrawn entirely. In a trading GUI this will result in the price immediately being removed from display. Quote withdrawal is often an integral part of a RFQ dealer intervention workflow, where the trader may wish to manually reprice, during the life of a 30s quote.

MassQuote messages may be withdrawn via the same mechanism.

...

In ESP pricing, a quote is rendered indicative by publication of zero quantities against prices for a given rung and side.

In addition, publication of a message without any rungs will effectively result in the complete withdrawal of the previous published ladder

QuoteType

For Quotes, QuoteType lives in the body level, and refers to the overall Quote Tradeability. Where as MassQuotes, it lives in NoQuoteEntries and it refers to the specific QuoteEntry

For a single Leg product, where BidPx is populated, but OfferPx is not.

  • Quote
    • The Body level, QuoteType.BidIsTradeable will be set to True
  • MassQuotes
    • The NoQuoteSets[1].NoQuoteEntries[X].QuoteType.BidIsTradeable will be set to True.

For Swap, Where the Near Leg OfferPx is populated, and the Far Leg BidPx is populated.

  • Quote
    • The Body level, QuoteType.BidIsTradeable will be set to True
  • MassQuotes
    • The Near Leg NoQuoteSets[1].NoQuoteEntries[X].QuoteType.OfferIsTradeable will be set to True, and the Far leg NoQuoteSets[2].NoQuoteEntries[X].QuoteType.BidIsTradeable will be set to True.

For Blocks, we always set both BidIsTradeable and OfferIsTradeable to True or Both to False

  • Quote
    • If the BLK is tradeable, both QuoteType.BidIsTradeable and QuoteType.OfferIsTradeable will be set to True, regardless of the overall side.
  • MassQuote
    • If level(X), if is Tradeable, all NoQuoteSets[ALL].NoQuoteEntries[X].QuoteType.BidIsTradeable and NoQuoteSets[ALL].NoQuoteEntries[X].QuoteType.OfferIsTradeable will be set True.
    • If level(Y) is not Tradeable, all NoQuoteSets[ALL].NoQuoteEntries[Y].QuoteType.BidIsTradeable and NoQuoteSets[ALL].NoQuoteEntries[Y].QuoteType.OfferIsTradeable will be set False.

Maker Quote Management

In ESP, Makers publish MassQuotes.  Each message is a single quote, which should contain a full snapshot of your price ladder for that symbol & price bucket.

The shape and size of their ladder can vary from tick to tick. Each MassQuote completely replaces the previous.  You may either publish a QuoteCancel to withdraw a previously published ladder, or publish a new empty MassQuote (zero rungs).

On the venue side, MarketFactory will handle the messages to make sure that the published liquidity matches your MassQuote.


ESP/RFS/RFQ State Transition Model

...

Whilst the Maker and Taker views are essentially symmetric, there are some important differences which are illustrated in the sequence diagrams. 

 

Gliffy Diagram
displayNameQuotationNegotiationSTD
nameQuotationNegotiationSTD

...

Some Maker venues may support Client acknowledgement of their deal acceptance or rejection. Accordingly, the Client is encouraged to always send an ExecutionAck message to confirm the trade result, where the Venue does not use this mechanism, Whisperer will simply drop the message.

...

  1. Venue Accepts Maker Trade - this is essentially confirming the trade has been completed successfully
  2. Venue Rejects Maker Trade -  this may happen for a variety of reasons - e.g. mandatory regulatory fields are incorrect.
  3. Venue Accepts Maker Rejection -  this is essentially a simple acknowledgment that no trade has been completed.
  4. Venue Rejects Maker Rejection - the Venue was unable to propery process therejection for some reason. This is an indication of a serious system error.

If It should be noted that there is a lot of variation in how this terminal message is used across the venues:

  • Some venues will only send 1. E.g. Bloomberg
  • Some Venues will only send 1. or 2. E.g. CboeFX.
  • Some Venues will send all variants. E.g. Currenex RFS
  • Some Venues may not use this message at all.


Info

In the absence of an ExecutionAck from the venue, Whisperer generates a synthetic ExecutionAck messages for Filled and Rejected orders.

Please note that the synthetic ExecutionAck from Whisperer does not apply to the Firm trading workflow, where the venue notifies (the maker) of the fills using ExecutionReport in response to MassQuote from the maker.

Please refer to 2025-09-16 - Post-Trade Normalisation (Execution Context) - Synthetic ExecutionAcknowledgement for more infoAt present Whisperer does not  generate synthetic ExecutionAck messages  as it is not possible to ensure uniformity, or know the actual venue state with any certainty.


Warning
titleManual Intervention Required

Should the Client receive an ExecutionAck (Rejected) message, then this is indicative of a serious condition that requires urgent rectification. The Client system should send a an urgent notification to relevant support teams that manual intervention is required.

RFQ

...

titleTODO

...

A request for a single-shot price, delivered as a Quote, with the TTL defined in the ValidUntilTime. Possible Dealer Intervention may deliver other

...

Quote(s) prior to expiry of first. Expiry

...

terminates the workflow.

RFS

Each individual Quote is good until replaced, withdrawn or ValidUntilTime expiry.  

Client as Taker

Anchor
Baskets
Baskets
Whisperer supports two Taker RFS pricing models:

  • Bilateral  - Request sent to a single Maker, receives Quote messages.
  • Basket - Request sent to multiple Makers, receives MassQuote messages aggregating the individual Maker Quote messages. This model is Venue dependent - currently offered by t360_tex and fxspotstream only.

In this model each QuoteSet represents a different Leg/value date, and each QuoteEntry for a given QuoteSet contains the Leg quote details provided by an individual LP, identified by reference to the "ExecutionVenue" EntryPassthruKey.

QuoteEntries in MassQuote are sorted by best Bid/Offer.

    • SPT, FWD and NDF are sorted by BidPx/OfferPx.
    • SWP and NDS are sorted by Swap points.
    • BLK and NDB are sorted by SpotRate.

If two QuoteEntries have the same price, they will be ordered from Oldest to Newest.

Please also see Price Representation.


In both cases, standard RFS subscription rules apply - the subscription is terminated by a deal request or a pricing duration timeout.


Gliffy Diagram
displayName4.0 RFS_QuoteRequest.04
name4.0 RFS_QuoteRequest.04

Client as Maker 

Gliffy Diagram
displayName4.0 RFS_MarketMaker_06
name4.0 RFS_MarketMaker_06

...

The standard Taker pricing message flow is illustrated in the sequence diagram below:

Gliffy Diagram
displayName4.0 ESP_QuoteRequest.03
name4.0 ESP_QuoteRequest.03

Subscription Response

Note
titleSubscription Response

The client will receive an immediate response to an invalid QuoteRequest.

However, the client may not always receive an immediate MassQuote in response to a valid QuoteRequest stream subscription:

  • There may be an interval of several minutes before the first MassQuote is received by the client.
  • The venue may never respond.

A Venue's response actually depends on the instrument being traded, time of day and venue-specific behaviour.

The client may wish to implement a timeout mechanism to unsubscribe and then either:

  • Mark the instrument as unavailable.
  • Resubscribe. Generally this is of very little value and is not recommended.

Client as Maker

The Venue will typically issue multiple requests for each currency pair, one for each configured pricing group (aka "client bucket" etc.).

...

  • Some venues are fairly unconstrained in terms of how many categories may be defined, but others (e.g. Bloomberg, CNX) have specific uniquenesses that need to be understood before decisions are made.
  • Some venues may allow or mandate that ladders are used in a VWAP manner, some may preclude this.

Gliffy Diagram
displayName4.0 ESP_MarketMaker_07
name4.0 ESP_MarketMaker_07

...

Client as Taker

Gliffy Diagram
displayNameTaker_ESP_Dealing
nameTaker_ESP_Dealing

Client as Maker

Note
titleLast-Look vs Firm Trading

The messages flows documented here illustrate illustrates a standard "Last-Look" trading model.

"Firm" trading is possible on some Venues and comprises standard MassQuote provision alongside receipt of ExecutionReport messages from the Venue notifying the maker of the fills.


Gliffy Diagram
displayNameMaker_ESP_Dealing
nameMaker_ESP_Dealing