Request for Quote (RFQ)

Understand how a request for quote solicits pricing from makers, how a quote is accepted, and how last look decides whether the trade completes.

A request for quote (RFQ) asks makers to price a trade directly, instead of resting an order on the public order book. Use an RFQ for size, or for a multi-leg strategy without a standing book.

Takers and Makers

Who Counterparties See

Counterparties never see your user or account identifiers. Makers see an RFQ’s requester as requester_id; quotes carry the submitter as quoter_id. Both are stable opaque RFQ participant IDs, so a counterparty can recognize a repeat participant without learning their user or account ID. Your own participant ID is part of your user.

Request a Quote

An RFQ names what to price and how much:

• A published single-leg or multi-leg market by its ticker, or an ad-hoc list of legs.
• A size in whole contracts (quantity) or in dollars (cash_quantity).
• A side: the side you intend to execute, buy or sell.

An RFQ carries expires_at, the deadline by which a quote must be submitted, accepted, and confirmed.

Answer with a Quote

A maker sees the RFQs soliciting its member alongside its own. A quote is single-sided: a bid (side: buy) or an offer (side: sell) at one price and quantity. To quote both sides, create two quotes. A maker can cancel a quote while it is open or during last look.

The requester sees every quote answering its RFQ, identified by the quoter’s participant ID and without the quoter’s own correlation ID. A maker reads its own quotes from its account quotes list, filtered by rfq_id. The RFQ responses list requires access to the requesting account; a maker without that access cannot see competing quotes on the RFQ.

A quote carries expires_at; during last look it becomes the deadline for the maker’s decision.

Accept, Confirm, Execute

The taker accepts one quote by trading against it. The accept names the quote’s quote_id and rfq_id, takes the side opposite the quote (buy lifts an offer, sell hits a bid), and must match the quote’s price and quantity.

An accepted quote is not a completed trade. Acceptance opens last look, during which the maker can confirm or cancel the quote. Confirming executes the trade; canceling prevents execution. If last look times out, the quote is canceled and the trade does not execute.

Both sides can follow last look on the quote itself: it reads accepted while the window is open, then confirmed or canceled. confirmed records the maker’s decision, not the trade. Acceptance creates an order before last look; read that acceptance order by order_id: filled means the trade executed and rejected means the exchange rejected it. Both parties can also read the trade from their fills.

Measure Your Quoting

A maker can check how it answered the RFQs it was asked to quote with RFQ stats and its per-series breakdown. Both cover a window of up to 30 days, defaulting to the last 24 hours.

An RFQ counts when it was routed to your member or your member quoted it, and only your member’s quotes count as answers. You never see another maker’s activity. Figures are final about three minutes after the fact, so the newest minutes of a window are not yet included.

The summary shows submitted, quoted and unquoted counts, the answered share, accepted trades, live versus pre-game activity and the dollars requested by sell RFQs, in total and split by side and by whether the event had started. Quote latency is the time from RFQ submission to your first quote; accept latency is from the requester lifting your quote to the trade completing. Percentiles come from a histogram, so each reads as the upper edge of its bucket, never below the true value.

The per-series breakdown sorts series by unanswered RFQs, most first, and adds a timeline for each in five-minute buckets: the bucket in which you last quoted, the oldest and newest buckets holding an RFQ you did not answer, and onset_at, the bucket where the current run of unanswered RFQs began. A multi-leg RFQ counts once under each of its leg series.

Every response carries coverage. When complete is false, the exchange’s RFQ history has a gap inside the window and figures there may understate activity; a quiet window is never silently reported as no RFQs.

Quote Cancellation Reasons

A canceled quote carries cancellation_reason in REST responses and WebSocket quote frames:

Acceptance alone does not cancel competing quotes. If the chosen maker cancels or fails to confirm during last look, that outcome does not cause competing quotes to become done away. Quotes with any status other than canceled omit cancellation_reason.

Rejection Reasons

The exchange can reject an RFQ or a quote after UDX has accepted the write with 202. The rejected RFQ or quote then has a status of rejected and a rejection_reason.