What is RFQ (Request for Quote)?

Introduction

RFQ (Request for Quote) is a trading workflow in which a participant asks one or more counterparties for a price on a specific trade, then decides whether to execute against the responses. It matters because many trades are awkward to place directly into a public order book: the size may be too large, the instrument may trade infrequently, or revealing intent too early may move the market against the trader.

That is the puzzle RFQ solves. In a central limit order book, transparency is the point: orders are displayed, ranked, and matched by rule. But transparency has a cost. If you need to trade a meaningful size, publishing your interest can invite adverse price movement, information leakage, or simply no natural counterparty at the quantity you need. RFQ changes the sequence. Instead of posting interest to the whole market first and discovering whether it can trade, the participant asks for prices privately or semi-privately and then chooses whether to accept.

At first glance this can seem like a small interface difference. It is not. An RFQ market has a different informational structure, different execution logic, and different fairness questions from an order book. The core idea is simple, though: RFQ separates price discovery for a particular trade from public order display. Once that clicks, the rest of the mechanics make sense.

What does 'ask first, trade second' mean in an RFQ?

In the simplest form, an RFQ has three actors: the requestor who wants to trade, the responders or liquidity providers who can price that trade, and the venue or protocol that carries messages and enforces rules. The requestor sends a message saying, in effect, I want to buy or sell this instrument, in this size, under these conditions; what will you quote me? Responders send back prices and quantities. The requestor may then accept one or more of those quotes.

What makes this different from an order book is not just privacy. It is directed competition. In an order book, everyone competes by posting standing interest into a common queue. In RFQ, competition begins only after a specific trading interest appears. A dealer or market maker does not need to maintain a public quote continuously for everyone. It can decide, case by case, whether to respond, how much size to show, and at what price.

Regulatory definitions in Europe capture this neatly: an RFQ trading system is one where quotes are provided in response to a request, and those quotes are executable exclusively by the requesting participant. That exclusivity is the structural difference. A quote in an RFQ session is not, at that moment, a general invitation to the whole market. It is a response to a particular requestor.

That exclusivity is why RFQ is common in markets where inventory risk matters and liquidity is uneven. A dealer asked to price a large bond trade, an ETF block, or a less-liquid derivative is being asked to warehouse risk or offset it. The quote reflects not only a mid-market level, but also balance-sheet usage, inventory, hedging cost, urgency, and confidence about being “picked off.” RFQ gives the responder a chance to price those realities explicitly.

Why use RFQ instead of posting a public limit order?

The economic problem behind RFQ is price impact under uncertainty. If you post a large buy order into a public book, others learn that someone wants size. Some may raise offers. Some may pull liquidity. Some may infer information you did not mean to reveal. Even if no one behaves strategically, the visible depth may simply be too thin.

RFQ addresses this by narrowing who sees the interest and by turning the interaction into a quote competition. The requestor can ask several dealers at once, compare executable responses, and avoid advertising the full order to the whole market. Exchanges and dealer platforms use different names and implementations, but the same mechanism appears repeatedly. MarketAxess describes disclosed RFQ as an investor asking multiple dealers simultaneously for competing executable bids or offers, then executing with the chosen dealer. Borsa Italiana describes RFQ for large-in-scale bond trades as an on-exchange but off-book way to find counterparties and receive price-and-quantity proposals on a dedicated channel.

This is also why RFQ often appears in markets that are not naturally deep at every moment. In very liquid futures or large-cap equities, a central order book can absorb a lot of flow. In many bonds, structured products, options series, and bespoke risk transfers, continuous public quoting is harder. Dealers may be willing to make a price when asked, but not to leave a firm quote resting for everyone at all times. RFQ is a compromise between no transparency and full displayed-book trading.

The cost of that compromise is equally important. RFQ can reduce information leakage to the broad market, but it can concentrate information in the hands of responders. If several dealers learn that a client is seeking size, they may infer something about demand, urgency, or valuation. That is one reason RFQ design is never just a user-interface choice; it is market structure.

How does an RFQ workflow work step‑by‑step?

Under the surface, RFQ is a tightly defined message exchange. The exact field names differ across venues, but the lifecycle is remarkably consistent.

A requestor first sends an RFQ containing the essential terms: the instrument, side, quantity, and often additional constraints such as minimum acceptable quantity, lifetime, account information, or whether the request is anonymous or visible. Some venues require these fields explicitly and reject incomplete messages. Nasdaq Oslo’s RFQ procedures, for example, require information such as series designation, side, volume, RFQ lifetime, trader identity, trading capacity, and account details, with automatic validation by the system.

The venue then routes or exposes the RFQ to eligible responders. On Euronext’s Optiq system, the matching engine notifies RFQ liquidity providers after receiving the issuer’s quote request. On other systems, the RFQ may be directed to a selected set of dealers rather than a whole responder community. The important point is that the requestor is not posting a standard limit order into the public queue; it is initiating a temporary micro-auction among invited or eligible responders.

Responders answer with quotes or quote-linked orders that explicitly reference the RFQ identifier. This reference matters because the venue has to know which responses belong to which request. In Euronext’s implementation, an RFQ answer is submitted as a limit order that includes the quote request ID. On Nasdaq Oslo, responders provide Directed Quote Responses, or DQRs, which are executable only by the original requestor. Some FIX-based implementations represent the same idea through QuoteRequest, Quote, QuoteCancel, QuoteStatusReport, and related messages.

Then comes the decision point. The requestor can accept a quote, accept multiple quotes if the venue allows splitting, cancel the RFQ, or let it expire. Nasdaq Oslo uses a Directed Quote Accept message to conclude the trade. Euronext uses a confirmation message structured as an average-price order with immediate-or-cancel semantics. Different encoding, same idea: the requestor is no longer asking what would you quote? but execute now against these responses under these limits.

That distinction matters because a quote is not yet a trade. The system must still validate the acceptance, enforce quantity and price constraints, and apply matching rules if more than one response or book order can participate.

Example: how RFQ handles a large bond block vs an order book

Imagine an asset manager wants to buy a large block of a corporate bond. The public market in that bond may show only small displayed sizes, and lifting those offers one by one could push the price up before the full position is completed. Instead of exposing a buy order publicly, the manager sends an RFQ to several dealers for the bond, specifying the side and desired amount.

Each dealer now faces a specific question: Would I commit capital for this size, and at what level? One dealer may already have inventory and quote aggressively. Another may need to hedge elsewhere and quote wider. A third may decline to respond at all. The requestor sees a set of executable responses tailored to that exact trade, rather than a generic top-of-book snapshot.

Suppose two dealers respond with enough size and another responds for only part of the amount. Depending on the venue, the requestor may choose the single best quote, may split across multiple responses, or may send a confirmation constrained by an average price. If the venue supports interaction with the central order book as well as RFQ responses, the engine may combine both sources of liquidity under a defined priority rule.

Notice what happened economically. The market did not first discover the trader’s intent by watching a large order rest in public. Instead, select liquidity providers discovered it and competed to internalize or offset it. That is why RFQ can reduce broad market impact while still producing competition. But it is also why the requestor must trust the venue’s rules and the responders’ conduct.

What real‑time calculations does a venue perform during an RFQ?

An RFQ platform is not just relaying chat-like messages. It often computes, updates, and enforces execution conditions dynamically.

Euronext’s specification is unusually clear about this. The RFQ issuer receives a matching-status message containing three pieces of information: Potential Matching Quantity (PMQ), Potential Matching Price (PMP), and the number of responding liquidity providers. PMQ is the maximum volume that could be matched if the request were confirmed. PMP is the weighted average price associated with that potential match. These values update when liquidity providers answer and also on a timer when the central order book changes.

This tells you something deep about RFQ mechanics on hybrid venues. The requestor is not operating in a vacuum. The venue may be continuously estimating, if you hit confirm right now, how much could execute, and at what average price? That is more than message transport. It is a temporary execution engine built around one request.

There are also explicit time limits. On Euronext, an RFQ expires after 180 seconds if it is neither confirmed nor cancelled, after which the system sends kill messages to the issuer and to all responding LP orders. Time windows like this are not incidental. They keep stale interest from lingering and prevent responders from being tied to a quote indefinitely while market conditions move.

In other venues, the timing logic appears in different form. NGM’s protocol describes QuoteRequest messages that require market makers to update or cancel quotes within a predefined timeout, otherwise the quote is cancelled. The system needs deadlines because RFQ quotes are valuable only if they are current enough to be executable.

How does matching and execution work after accepting an RFQ quote?

A common misunderstanding is that RFQ ends when the requestor sees the best quote. In practice, the hard part often begins at acceptance.

Once the requestor accepts, the venue has to answer a constrained optimization problem: which available liquidity should be used, in what order, and under what average-price or minimum-size conditions? The answer depends on the venue’s rules.

Euronext’s matching logic makes the mechanism explicit. On confirmation, the engine tries to maximize matched quantity while keeping the resulting average execution price within the issuer’s average-price limit. If several sources of liquidity are available, candidate executions are prioritized in a defined order: first lit LP orders, then dark LP orders, then lit central order book interest, then dark book interest. At equal price, further tie-breakers apply based on transparency, size constraints, and time.

This is important for two reasons. First, RFQ does not necessarily mean “trade only against dealer quotes.” On some venues, RFQ interacts with the existing order book and becomes a special path through available liquidity. Second, the relevant price constraint may not be the best individual fill, but the average price of the entire bundle of fills. That is how a requestor can trade a larger amount while capping total execution quality deterioration.

Euronext also gives LP answers priority over regular central order book orders at the same price. That design choice reveals the venue’s intent: if liquidity providers responded specifically to the RFQ, their commitment is treated as more relevant to the request than generic resting liquidity at the same level.

Not every venue implements this exact hybrid model. Some RFQ systems are more purely bilateral: the requestor accepts a specific quote from a specific respondent, and that acceptance itself concludes the transaction. MarketAxess’s disclosed RFQ, for example, is fundamentally bilateral between investor and dealer, even though the system allows simultaneous competition across multiple dealers.

Are RFQ requests and responses private or will they be published?

People often talk about RFQ as if it were simply private trading. That is too crude. The real question is which parts are private, to whom, and for how long?

The initial request is often not broadly published. Euronext states that the RFQ itself is private and never published. Borsa Italiana offers anonymous and visible RFQ modes for institutional clients. MarketAxess distinguishes disclosed RFQ, where counterparties know each other, from anonymous Open Trading protocols that use matched-principal intermediation.

But privacy at the start does not mean opacity forever. Under the EU’s RTS 1 definition, quotes in an RFQ system are provided in response to a request and are executable only by the requestor, yet submitted quotes may be published no later than when they become executable. ESMA’s guidance goes further: if a quote or actionable indication of interest contains enough information to agree a trade, it should be made pre-trade transparent no later than when it becomes actionable, and in any event before the transaction is concluded.

That guidance clarifies a subtle but important boundary. RFQ is allowed to direct executable quotes to a requesting participant, but it is not a license to disguise a fully negotiated private trade as a venue process while avoiding transparency requirements. ESMA explicitly rejects the idea that an RFQ session can include a hidden bilateral negotiation phase needed to finalize the deal; if final terms still need private negotiation, that is outside the RFQ session.

So the practical reality is mixed. RFQ reduces broad exposure of trading interest, but venues may still publish responses, cancelled responses, or executed trades on a regulated timetable. Nasdaq Oslo, for instance, states that all DQRs in response to an RFQ are published no later than when they become executable, and cancelled or unaccepted DQRs are also published.

How does RFQ differ from quote‑driven and order‑book markets?

It helps to place RFQ next to its neighboring market structures.

A continuous auction order book matches buy and sell orders continuously by algorithm, based on the best available price. Interest is pooled into a common book, and transparency typically focuses on displayed depth. A quote-driven market relies on market makers maintaining continuously available firm quotes for participants. Those quotes are always there, not only after someone asks.

RFQ sits between these. It is not a standing public queue, and it is not continuous market-making for all participants at all moments. Instead, it is event-driven quoting: the request creates the quoting event. That design is especially useful when maintaining continuous public firm quotes would be expensive or unrealistic, but where traders still want venue-governed competition rather than fully manual bilateral negotiation.

This is also why RFQ is tightly connected to OTC trading. In many OTC markets, the standard execution pattern is exactly this: a buy-side firm solicits quotes from several dealers rather than hitting a public book. Electronic RFQ platforms formalize and automate that pattern. They do not eliminate OTC-style intermediation; they digitize it and, depending on venue rules, add more structured competition, auditability, and transparency.

What assumptions must hold for RFQ to work well?

RFQ works well only if several assumptions hold, and each assumption can fail.

The first assumption is that responders will actually compete. If only one or two dealers are willing to answer, the requestor may get convenience but not much price tension. The second is that quotes are meaningful and current. That is why venues enforce lifetimes, validation rules, and cancellation behavior. A stale quote in an RFQ system is worse than a stale top-of-book display because it may be tailored to a specific large trade.

The third assumption is about conduct. Responders learn something when they receive an RFQ: someone wants to trade this instrument, in this size, now. That information can help them price risk responsibly, but it can also create conflicts. The best-known example is pre-hedging; trading in the same or related instruments after learning of an anticipated client trade but before the client has agreed terms, ostensibly to manage risk. IOSCO defines pre-hedging in this principal-trading sense and notes both potential benefits and risks. It may aid price discovery and let dealers compete on large trades, but it can also misuse client information or worsen the client’s execution.

That debate is especially sharp in competitive multi-dealer RFQ. If several dealers react to the same inquiry, their combined hedging activity can itself move the market. Some stakeholders argue this helps smaller dealers quote competitively; others argue it amplifies adverse impact on the client. There is no honest explanation of RFQ that can ignore this tension.

Another assumption is that the venue’s matching and publication design aligns incentives properly. Give responders too little protection, and they will quote wide or not at all. Give requestors too much opacity, and the venue can become a way to avoid fair transparency. Give responders too much information or too much execution priority, and requestors may face subtle disadvantages. RFQ design is therefore a balancing act, not a universally superior method.

Which markets and assets commonly use RFQ and why?

The details change by market, but the recurring pattern is easy to see.

On a cash-equity exchange such as Euronext, RFQ can be a feature embedded in the main trading system, with central matching-engine logic, precise timer behavior, and interaction with lit and dark book liquidity. On a commodities or derivatives venue such as Nasdaq Oslo, RFQ may appear as a requestor-responder workflow with directed responses and acceptance messages. On dealer-to-client credit platforms such as MarketAxess, RFQ is the main competitive protocol through which investors solicit executable dealer prices. On bond markets such as Borsa Italiana, RFQ is explicitly positioned for large-in-scale trades that are better handled off-book than through visible order display.

Those are not surface differences. They show that RFQ is not tied to one asset class or one blockchain-like architecture of market design. It is a general answer to the same structural problem: how do you create competition for a trade that is too large, too illiquid, too sensitive, or too context-dependent for simple displayed-book execution?

The protocol elements vary (quote request IDs, quote notifications, average-price confirmations, quote status reports, accept messages, expiry timers) but all of them support the same core transaction: a trader asks for executable liquidity before publicly committing the trade.

What do people often misunderstand about RFQ?

The most common mistake is to think RFQ is merely “asking around for a price.” In institutional markets, an RFQ quote is usually not casual or indicative. It is often an executable response inside a governed venue process with defined timing, fields, and consequences.

A second mistake is to assume RFQ means no matching rules. In reality, some RFQ systems are highly mechanized. Euronext’s use of PMQ, PMP, collars, average-price limits, and explicit execution priority rules shows that once the requestor confirms, the process can be as rule-bound as order-book matching.

A third mistake is to think RFQ is always dark. It often starts with restricted visibility, but many venues publish quotes or transactions on a timetable tied to executability or execution. Privacy in RFQ is usually about who sees the interest first, not necessarily about permanent invisibility.

A final mistake is to see RFQ as always better for large trades. Often it is better, but only if the responder set is competitive and the information leakage to that set is worth the reduction in public book impact. If the market is already deep and anonymous enough, a public book may be simpler and cheaper.

Conclusion

RFQ is a market design for trading before displaying. Instead of placing an order into a public queue and hoping the market can absorb it, a trader asks selected counterparties for executable prices, compares the responses, and then chooses whether to trade.

That structure exists because large or sensitive trades behave differently from small, continuous-flow trades. RFQ can reduce visible market impact and create focused competition, but it also shifts information, discretion, and responsibility toward responders and venue rules. If you remember one thing, remember this: RFQ is not just a different interface for the same market; it is a different way of organizing who learns about a trade, when they learn it, and how execution is allowed to happen.

How do you place an RFQ (Request for Quote)?

Place an RFQ on Cube by requesting executable quotes for a specific instrument and size; Cube routes the request to eligible liquidity providers and returns time‑limited responses you can accept. Review the responses within the RFQ lifetime, then accept the quote that meets your price and size needs to execute on Cube.

1. Fund your Cube account with fiat or a supported crypto transfer.
2. Open Cube’s RFQ request flow, enter the instrument, side, quantity, and set an RFQ lifetime (e.g., 30–180s) and any minimum acceptable size.
3. Submit the RFQ; Cube will route it to eligible liquidity providers and collect time‑limited, executable responses.
4. Compare quoted price, available size, and expiry, then accept the best quote to execute (or split across multiple quotes if the RFQ flow allows).