Skip to main content

RFQ

Overview

This document describes how Request for Quote (RFQ) workflows are implemented in Deltix products.

Concept

The RFQ workflow includes the following components:

  1. Quotes: These are personalized quotes generator specifically for the requestor. They are short-lived, typically lasting only a few minutes.
  2. QuoteRequest, Quotes, and QuoteCancel messages: These messages are exchanged via a TimeBase stream. Each RFQ Provider or RFQ aggregator algorithm has a dedicated stream. The QuoteRequest message is sent by the requestor to initiate the RFQ process. Quotes are then generated by the RFQ Provider or aggregator algorithm and sent back to the requestor. If necessary, the QuoteCancel message can be used to cancel or expire the quotes.
  3. The Deltix Order Entry API: Used to trade quotes using OrderNewRequest messages that reference the Quote ID. The order-related message flow uses Ember channels instead of a TimeBase stream.

RFQ Flow

Limitations

The current version of the RFQ implementation has the following limitations:

  1. Limited support for tradable quoting models: The system primarily targets the indicative quoting model. This means that the quotes provided through the RFQ workflow may not be directly tradable. They serve as indicative prices to assist in decision-making. For more information on indicative versus tradable quoting models, you can refer to the FIX 4.4 Protocol Specification, Volume 3: Request for Quotes workflows.
  2. Lack of Support for Special contract types: The current RFQ implementation does not support special contract types, such as FX Swaps.

RFQ Data Model

The following diagram illustrates the RFQ messages that are exchanged between the RFQ Client and RFQ Provider via TimeBase:

RFQ UML

Source and Destination

Each RFQ message has a source and destination, in line with the Order Entry and Market Data API used by Deltix. The source of a QuoteRequest message corresponds to the destination of the Quotes transmitted in response to that request. Similarly, Quotes have their source set according to the destination of the original QuoteRequest.

Quote Stream Identity

To establish the connection between a QuoteRequest and its corresponding Quotes, use the QuoteRequestID field. This ID serves as a unique identifier to correlate the request and response. In the case of a Request for Stream (RFS), there may be multiple quotes associated with a single QuoteRequest.

note

The QuoteRequestID provided in the QuoteRequest message must be unique within the scope of a single source.

Quote Identity

Quotes are identified by the QuoteID set by an RFQ Provider. Previously quoted orders reference this ID.

Connection Loss

If the Deltix infrastructure loses connectivity to the Quote Provider, all quotes usually become cancelled and invalid. The ConnectionStatusChangeMessage in the stream is used to indicate the connectivity status.

RFQ Flow with disconnect

note

In some cases, you cannot rely on the infrastructure to accurately notify you of connection loss. For example, the Docker instance hosting the RFQ Provider may suddenly terminate without writing a ConnectionStatusChangeMessage to notify of the connectivity loss.

It is the responsibility of the RFQ Client to resend a QuoteRequest when the connection with the RFQ Provider is restored.

One-Sided Quotes

In some cases, the RFQ Provider may broadcast one-sided Quotes. For example, the RFQ Provider may send a Quote message containing only the Bid side of the market. In such cases, the AskSize property of the Quote message is set to NULL. Deltix uses Decimal64 encoding for quote sizes, and NULL is a special constant reserved for situations where a value is unavailable.

A one-sided Quote is different from a Quote containing only one side of the market when the other side is not available. For example, if there are no offers for a given instrument in the market, the AskSize property of the Quote message is set to zero.

Quote Cancellation

QuoteCancel Message

The QuoteCancel message can be sent by either the RFQ Client or the RFQ Provider, and is bidirectional.

The RFQ Client can cancel the quote stream by sending a QuoteCancel message that references the QuoteRequestID of the original QuoteRequest.

Similarly, the RFQ Provider can cancel the quote stream by sending a QuoteCancel message that references the QuoteRequestID of the original QuoteRequest. The RFQ Provider can also cancel the last issued quote using this method, in which case the QuoteCancel should specify the QuoteID.

Cancel on Disconnect

As mentioned in the previous section, if the RFQ Provider disconnects, it may result in the cancellation of the quote request.

Quote Expiration

Each quote may have an expiration time (e.g., 1 minute). In the event of an expired quote, it is the responsibility of either the RFQ Provider or the Deltix RFQ Connector to issue a QuoteCancel message. However, when the RFQ Connector terminates or loses connectivity to the RFQ Provider, which normally provides this message, the receipt of the QuoteCancel message cannot be guaranteed.

In other words, the RFQ Provider will make reasonable efforts to issue a QuoteCancel message for an expired quote, but the delivery of this message cannot be not guaranteed. It is important to note that orders for expired quotes are rejected.

Cancellation of One Side of the Market

A Quote message can indicate that one side of the market is no longer available. For example, when the AskSize in a Quote message is set to zero, it can signal a lack of offers on the market. This can be used to effectively cancel just one side of the quote. If both the AskSize and BidSize are both set to zero, it cancels both sides of the quote.

note

When the bid or ask size of the quote is zero, the corresponding price may be undefined. It could be the previously published price, zero, or NULL.

note

A Quote message that communicates zero size for one or both sides of the market may use the last known QuoteID or assign a new QuoteID.

Supported Settlement Types

Settlement TypeNotationExample
Spot00
Today11
Tomorrow22
Days - n Trading days in the futureDn (where n is number of days)D3
Weeks – n weeks in the futureWn (where n is number of weeks)W2
Months – n months in the futureMn (where n is number of months)M3
Years – n years in the futureYn (where n is number of years)Y1
IMM – n International Monetary Market daysIMMnIIMM3
B – Broken dateB (we expect settlementDate to contain the date)B