The Lab

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 40 Next »

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.

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

  QuotationNegotiationSTD

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:

  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 should be noted that there is a lot of variation 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.


At 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.

Manual 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 urgent notification to relevant support teams that manual intervention is required.

RFQ

TODO

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

4.0 RFS_QuoteRequest.04

Client as Maker 

4.0 RFS_MarketMaker_06

ESP

Streaming

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

Unlike RFS/RFQ, ESP Pricing will continue following any attempt to trade.

MassQuote messages will contain rungs populated according to one of two principle modes:

  • Dynamic Volume BandsSizes 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 QuoteRequest message NoBodyPassthruFields block.

Client as Taker

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

4.0 ESP_QuoteRequest.03

Client as Maker

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

For a given ccy pair, Whisperer imposes no restrictions on the ladder that you publish, although details of exactly what you publish may well vary from venue to venue.
There are two basic motivations for makers when offering liquidity:

  • Ecommerce: A 'standard' ladder of prices for standard, usually fixed, rung positions (eg 1/2/5). Bid and offer prices always published for these standard quantities, individual entries may be marked indicative (non-tradeable) or tradeable, from tick to tick. This is the traditional model for Bank ESP flows, for example.
  • Interest: The ladder is a reflection of Maker exhaust preferences, to trade down positions built up in other flows. Here the ladder will typically be presenting more liquidity on one side, and not be symmetric, i.e. pricing will be much tighter on the side where trading is preferred. The volume bands can be entirely dynamic - published rung positions, sides etc varying from tick to tick. There is less need to show indicative prices here, usually the maker is just zeroing-out previously published liquidity. It is perfectly feasible for liquidity to be published on a single side only.

 
The management of stream categories within and across venues requires, as usual, some careful consideration:

  • 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.

4.0 ESP_MarketMaker_07

Dealing

Client as Taker

Taker_ESP_Dealing

Client as Maker

Last-Look vs Firm Trading

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.


Maker_ESP_Dealing



  • No labels