Page History
| Table of Contents |
|---|
Overview
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:
- Quote Condition (ESP, RFS)
- Quote Expiry/TTL (ESP, RFS)
- Quote Withdrawal (ESP, RFS)
- Liquidity Management (ESP only)
Quote Condition
Some Venues allow the Maker to specify whether a given quote is indicative, or tradeable. Depending on the Venue, indicative quotes may be displayed in the trading GUI as non-tradeable ("greyed out"), or may result in the quote being removed from display entirely, as if it has been withdrawn.
Indicative pricing is particularly important when Making to those Venues which offer composite trading grids that all Takers to compare multiple providers at a glance.
Quote Expiry
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 also acts 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 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.
For those venues which mandate time-to-live rather than an absolute date/time, WH-E will reference the MFSBE message sendingTime in order to determine the duration.
Quote Withdrawal
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.
Liquidity Management
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.
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
The following State Transition Diagram outlines the model for traditional eCommerce ESP and RFS quotation negotiation workflows for both Maker and Taker clients.
...
| Gliffy Diagram | ||
|---|---|---|
|
ExecutionAck Messages
Client as Taker
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.
Client as Maker
Typically the Venue will send some sort of message Ack-ing or Nack-ing the Maker response to the originating order. Any of the following are possible:
...
| Warning | ||
|---|---|---|
| ||
Should the Client receive an |
RFQ
| Note | ||
|---|---|---|
| ||
| Single shot quote, ValidUntilTime. Possible Dealer Intervention may deliver other quote(s) prior to expiry of first. Expiry terminiates the workflow. |
RFS
Each individual Quote is good until replaced, withdrawn or ValidUntilTime expiry.
Client as Taker
| Gliffy Diagram | ||
|---|---|---|
|
Client as Maker
| Gliffy Diagram | ||
|---|---|---|
|
ESP
Streaming
Each individual MassQuote is good until replaced, withdrawn or ValidUntilTime expiry.
...
- Dynamic Volume Bands - Sizes are not pre-configured, the Maker will dynamically determine the sizes for which Market Data is published. The number and location of rungs for Bid and Offer being independent.
- Preset Amounts in Request - Where supported by the Venue, the size of each individual rung may be specified in the
QuoteRequestmessageNoBodyPassthruFieldsblock.
Client as Taker
The standard Taker pricing message flow is illustrated in the sequence diagram below:
| Gliffy Diagram | ||
|---|---|---|
|
Client as Maker
The Venue will typically issue multiple requests for each currency pair, one for each configured pricing group (aka "client bucket" etc.).
...
| Gliffy Diagram | ||
|---|---|---|
|
Dealing
Client as Taker
| Gliffy Diagram | ||
|---|---|---|
|
Client as Maker
| Note | ||
|---|---|---|
| ||
The messages flows documented here illustrate 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. |
...
Overview
Content Tools