RFQ system development: where the manual request flow breaks down
When there are ten price requests a day, the flow lives in chat. A client writes in a messenger, a dealer goes through counterparties one by one, the response is assembled manually in a spreadsheet — and not every request reaches a trade.
As it grows to several dozen requests per day and a dedicated set of counterparties for each asset, the scheme hits the physical time limit of one person.
The bottleneck here is not liquidity but response latency. While a quote travels through three disparate channels, the price on a volatile asset moves, and the client goes to whoever responds first.
A difference of minutes in negotiations turns into lost volume and a habit of asking someone other than you.
Manual quote collection also introduces pricing errors. An outdated row in the spreadsheet, the wrong quote copied, a lot size that ignores counterparty fees — and the trade closes at a price at which no one is ready to execute. Such discrepancies surface later, during reconciliation, when there is nothing left to redo.
Next, we break down how this is addressed: where an RFQ system removes latency by polling counterparties simultaneously, where risk and limit control is needed, and where automation will deliver nothing without normalized instrument data.
What changes in the trading loop after launch
A launch should be evaluated not by the fact of implementation but by the metrics of the trading loop. When developing an RFQ system, we record a baseline measurement before the start and then surface the same metrics in production — otherwise there is no way to prove the effect.
Request processing speed
Before launch, a request went through chat and a spreadsheet: while the side and size were being agreed, the price moved, and some requests were closed with a rejection.
In the new loop, a request enters a priority queue, the engine selects the best quotes from the liquidity pool, and returns a response in fractions of a second.
Throughput grows not by adding people: one loop handles hundreds of simultaneous requests, and response time remains steady at volatility peaks.
The median response time and the share of requests served within a given threshold are displayed on a dashboard separately for each asset and counterparty.
Share of automatic quotes without manual involvement
The key effect is quotes that go to the client without a trader. Pricing rules, counterparty limits, and spread are described in configuration: the system decides on its own what to quote, what to reject, and where escalation to a human is needed.
Manual handling remains for deliberate exceptions — large volume, a non-standard asset, a new counterparty with no trade history. Their share is measured and decreases as rules expand, rather than being estimated by eye.
We separately count eliminated rejections: requests that previously were lost to timeouts, data mismatches between chat and the trade, or an incorrect account balance. Now each has a status and reason — this statistics immediately shows where a bottleneck remains.
RFQ execution methods: pool, market maker, hybrid
A request for quote is fulfilled in three ways, and the choice between them is a choice between price control and execution guarantee.
A liquidity pool gives best-price calculation to an algorithm, a market maker to a specific counterparty, and a hybrid splits the volume between both. The difference shows during sharp market moves, when indicative quotes diverge from the actual trade price.
| Option | When it fits | Limitations |
|---|---|---|
| Liquidity pool | Regular trades in liquid pairs, volume within pool depth | Firm quote is not guaranteed: price depends on slippage |
| Market maker | Large or non-standard volume, OTC instruments | Counterparty dependency: limits, rejection during a sharp market move |
| Hybrid | Volume greater than pool depth, need a risk cap per counterparty | More complex routing and accounting of partial fills |
How to choose based on liquidity
The key parameter is the ratio of order volume to pool depth. As long as the volume fits within the depth, the request goes to the pool: a market maker will give a worse quote at that size.
When the volume exceeds it, the pool starts moving the price — then indicative quotes are collected from market makers, and firm quotes are locked for a limited period.
Mixed schemes
Hybrid execution allows filling most of the volume in the pool and covering the remainder with a market maker without disclosing the order in full.
Priority rules matter: which source receives volume first, how a partial fill is split, and what happens if a firm quote is withdrawn before the trade. These rules are set by system configuration, not by a verbal policy.
Implementation stages: audit, design, configuration, handover
The order of work is the same whether the system is built from scratch or replaces manual price negotiation in chat. Each stage is closed with an artifact — a design, a configuration, a reconciliation report — that you accept before the next one starts. At the final stage, it does not turn out that the calculation logic diverges from accounting.
- Process audit — we analyze how requests are currently collected, who approves the price, where limits are recorded, and what discrepancies already arise.
- Flow design — we describe the route of a quote request from client to trade confirmation, including rejection, partial fill, and expiration.
- Role model — we break down permissions: client, dealer, risk control, settlement operator; each role has its own set of actions and limits.
- Quoting configuration — price selection rules, quote lifetime, restrictions by counterparty, instrument, and volume.
- Calculation verification in a test environment — running scenarios with a known result in advance and reconciling with manual calculation.
- Acceptance — demonstration on your data, recording of comments, and re-running problematic scenarios.
- Documentation handover — configurations, operating procedures, instructions for dealers and support.
Flow design approval
We approve the design before configuration: it shows where a request may get stuck, how the system behaves during a partial fill, and what happens to a quote after expiration. Changes at this step cost hours; after launch, they cost weeks of reworking accounting.
Calculation verification in a test environment
The test environment replicates production rules but with separate data and accounts. We run scenarios with a known answer, reconcile the results with an independent calculation, and only after they match do we move the settings to the production environment.
Handover package: configurations, designs, roles, procedures
After the RFQ system launches, the customer retains not only the production environment but also a complete set of artifacts — with no “black boxes” that only the contractor can maintain.
The repository with configurations and descriptions is handed over to the customer’s team, and it evolves the system on its own.
- Environment configurations: limits by instrument, maximum quote response time, margin calculation rules.
- Integration designs: data flows between the interface, quoting service, risk module, and counterparties.
- Access policies: role matrix describing permitted data and actions.
- Procedures: update rollout, rollback plan, on-call actions during quoting degradation.
- Audit logs: record format, retention periods, export procedure to external storage.
- Set of automated checks: quote calculation, limit triggering, trade execution.
Access policies
Roles are described declaratively and stored in the repository alongside code, not only in the admin panel. A market maker sees its own quotes, a dealer is limited by a counterparty limit, an auditor reads data without the right to modify it.
Changes to the role matrix undergo review and are recorded in the log — privilege expansion does not go unnoticed.
Audit logs
Every significant action — a quote request, trade confirmation, limit or role change — is recorded with a user ID and an immutable timestamp. Records are exported to external storage, integrity is confirmed by a hash chain, so a retroactive change cannot be made. This layer allows passing counterparty checks without manual reconciliation of exports.
Case study: how request throughput grew
We built the first phase of the RFQ system for the OTC desk at Aurum Markets: large trade orders were consolidated manually, the trader collected quotes in a spreadsheet and confirmed each pair by voice.
Already at a peak of 300 requests per hour, the queue grew faster than traders could respond, and some orders went to other counterparties.
Measurements were taken on the same order volume before release and after two months of operation. Average request processing time fell from 40–50 seconds to 6. The share of rejections due to exceeding the waiting time dropped from 8% to 0.4%. The system now handles peak load without degradation — 1200 requests per hour versus 300 before it.
“At peak, we lost orders simply because we calculated the price longer than the client was willing to wait,” — head of trading.
“The bottleneck was not in quoting but in approval: every step waited for a human,” — lead project engineer.
What was left outside the first phase
The second phase covered automatic hedging on exchange venues, options support, and allocation of limits between counterparties. The first phase covered the order flow, pricing rules, and full trade audit — this was enough to relieve peak load and remove manual confirmations.
How an indicative quote differs from a firm quote
An indicative quote is a reference, not an obligation: a market maker shows an estimate at which it is ready to discuss a trade but reserves the right to revise it before confirmation.
This mode is appropriate during pre-trade evaluation, when the client is sizing up the amount and instrument and the venue needs to avoid revealing real interest in the asset too early.
A firm quote is an obligation to execute at the specified price within the quote lifetime.
The term is set in the request itself or in the instrument profile: short for volatile pairs, where the risk of revaluation is high, and long for large sizes that the market maker can manage to close with a hedge.
Price disclosure separates the modes even further. Indicative quotes are often provided with a partially hidden size — so that interest does not leak into the order book and move the market before the trade.
A firm quote is disclosed on a targeted basis and in full: the counterparty sees the price, volume, and term because it signs execution under exactly these terms.
When prices diverge by the time of the trade, a state model is used. A quote lives as an object with a timer: when the term expires, it transitions to an inactive state, and it can no longer be signed.
If the price moves within the term — either the market maker executes at its own price and bears the revaluation risk, or re-confirmation is triggered and the quote returns to indicative mode.
Therefore, in an RFQ system, the lifetime, disclosure rules, and price fixing moment are set in the data model rather than left to the discretion of participants.
Then the question “which price was current” is resolved by the quote state log, not by correspondence between the parties.
Technical concerns: access, limits, reliability
Before starting RFQ system development, the customer usually checks several technical points: how market maker access is segregated, what happens during a connection failure, and whether the trading picture can later be restored. Below are answers to the questions that most often come up during the evaluation stage.
Segregation of market maker permissions
Each market maker is issued a separate role with its own set of instruments and volume limits. It sees only requests addressed to it and cannot place a quote above the agreed corridor.
Limits are set per asset pair and can be changed without stopping trading, and all actions of the role are recorded in the trade log.
How is access issued to market makers and who revokes it?
Access is issued for a specific role, not “per person”: keys have a limited lifetime and are revoked with a single administrator action. Revocation takes effect immediately — active sessions are closed on the service side.
What happens during a connection failure or node outage?
The system is deployed across multiple nodes, and traffic switches automatically. Incomplete requests are restored from the log — the quote is not lost at the moment of failure.
How is it verified that a trade was executed under the stated terms?
Each trade is reconciled against the log and an independent price source. A discrepancy is visible immediately and investigated before end of day.
Can volume be limited for an individual market maker?
Yes — limits are set per role and per asset pair, separately by number of requests and by volume. When the limit is exhausted, the market maker receives a rejection, and other participants’ trading is unaffected.
How is testing conducted before launch?
First, shadow mode: the request flow runs, quotes are calculated, but trades are not concluded. This makes it possible to verify system behavior and log records before production launch.
Let’s discuss the task and come back with an estimate and plan
To come back with an estimate and plan, rather than a queue of clarifying questions, some inputs should be collected in advance. Below is what actually affects the RFQ system architecture, effort, and order of work; our engineers will clarify the rest themselves.
- Request composition: what fields a quote request contains — asset, volume, direction, price lifetime — and who responds to it: a single liquidity provider or a pool.
- List of integrations: price sources, custody provider, accounting or client system, notification channels. Note where a ready software interface already exists and where exchange is manual.
- Roles and access: which employees see others’ quotes, who confirms the trade, how the action history is recorded, and what of this the client sees.
- Procedures and limits: restrictions by volume and asset, request rejection rules, security service requirements for storing signature keys.
- Current process: how trades happen now — spreadsheets, chat, terminal. This immediately shows what will be automated first.
- Reporting: which exports and logs are needed, with what frequency, and in what format they are expected at the output.
From this set, we assemble a stage-by-stage timeline estimate, an implementation plan with intermediate acceptance points, and a list of dependencies on the customer side. Send the data in parts — what has already been collected is enough to begin analyzing the task.