Streaming OTC Quotes: Where the Flow Breaks and What the Desk Loses
Streaming OTC quotes are a continuous stream of prices that the desk delivers to clients and internal systems: a market maker publishes two-way rates, an aggregator consolidates them into a single book, and the risk loop recalculates limits on every update.
As long as everything is in sync, the desk earns on the spread and turnover. As soon as one of the participants falls behind by seconds, the OTC desk starts trading at a price that no longer exists in the market.
The most expensive failure is a desync of quotes between the source and the consumer.
The market maker has already shifted the rate after a move in the underlying asset, while the client gateway is still holding the previous one: the trade executes at a stale rate, and the desk covers the difference out of its own margin.
The second most frequent is a break in the channel between the aggregator and the risk module: limits are calculated from the last snapshot that arrived, exposure grows unnoticed, and it is only discovered during reconciliation.
The third class of failures is degradation of the price stream itself: thinning of updates under load, loss of packet sequence, duplicates after reconnection.
On the surface the system is alive, quotes are flowing, but their frequency drops severalfold — and arbitrage counterparties are the first to pull liquidity from the desk, leaving it with the worst side of the spread.
Clock desync between nodes deserves separate mention: timestamps diverge, and it is no longer possible to reconstruct the real order of events from the logs.
The cost of each such failure is measurable: widened spread, breached limits, manual trade investigations, and lost engineer hours on reconciliation. Below we break down how this gets closed — from the architecture of the stream to control over its integrity.
Stream Architecture: Broadcast Modes and Their Constraints
Broadcast Stream
Maintains a single shared quote feed for all connected desks: an instrument is published once, then distributed to all subscribers. This is the cheapest mode in terms of load — the source delivers data once, not N times according to the number of recipients.
The limitation is that each desk receives the entire stream in full: if out of a hundred instruments it needs five, the other ninety-five still pass through the channel and the client application.
On a narrow channel this introduces latency, and during peak market movements — queue growth and quote staleness by the time it reaches the screen.
Targeted Quotes
Here the stream is assembled for a specific recipient: the desk subscribes to its own instruments, and the source maintains a separate selection for each.
Latency on the recipient side drops because the channel is not clogged with excess — in practice this is the difference between "the quote arrived at the moment of publication" and "it arrived lagging by several updates." The price is complexity on the source side: subscriptions must be managed, their lifecycle tracked, and correctly removed on connection loss, otherwise the source will continue counting load for a disconnected desk.
Hybrid Model
In practice, the choice is not "either-or" but a combination: a broadcast stream as the primary channel and targeted subscriptions for instruments with a high update rate. This provides predictable load on the source and low latency where it is critical.
Stream resilience rests on three things: sequence integrity control (a missed update must be visible, not swallowed), automatic reconnection with backfill of what was missed, and access control at the subscription level — a desk sees only what it has access to.
| Variant | When it fits | Constraints |
|---|---|---|
| Broadcast | Many desks, a broad set of instruments, low update rate | Excess traffic to the recipient, latency on a narrow channel |
| Targeted | Few recipients, a narrow set of instruments, high rate | Complex subscription management, load grows with the number of desks |
| Hybrid | Heterogeneous desks and differing latency requirements | Requires explicit stream separation and unified reconnection logic |
FIX Protocol defines the message format and subscription rules, but does not dictate the delivery topology — it is chosen according to the load profile of a specific desk.
How we build the flow: from channel audit to handover to the desk
Streaming OTC quotes are not about "connecting an exchange API" but about assembling several heterogeneous sources into a single predictable stream, where the desk has no right to pause: while routing is thinking, the quote goes stale, and the trade goes with it. That is why we start not with code, but with a survey of what the client already has.
- Audit of quote sources. We break down each channel: exchange venues, aggregators, market makers, internal prices. We record the update frequency, the format (FIX, WebSocket, REST polling), the behavior on a disconnect, and how the source flags stale data. The output is a map of sources with their strengths and weaknesses.
- Flow design. We design the path of a quote from entry to the desk: format normalization, a unified instrument model, buffering for spikes. The design is agreed upon before development begins — so that "surprises" like different time bases across venues do not surface during the build phase.
- Setting up quote routing. We define priorities: which source is considered primary, which one takes over during degradation, and by which rule the best price is selected. We describe the routing rules explicitly, not "by default" — otherwise, during a failure, the desk receives a stream that is formally alive but unusable for trades.
- Load testing. We run the stream at peak volumes and in disconnection scenarios: we watch how the buffer behaves, how long a quote lives before delivery, and what happens when two sources fail simultaneously. The goal is not "it passed," but an understanding of the boundaries beyond which the system degrades predictably.
- Handover to the desk. We deliver the working stream together with documentation: the routing design, the source-switching procedure, and the diagnostics instructions. The desk must be able to service the stream on its own, without calling a developer for every disconnect.
Each stage ends with an artifact that can be verified: a map of sources, a design, routing rules, a load report, documentation. Describe your sources and requirements for the stream — we will come back with an estimate and a work plan.
How does targeted distribution differ from broadcast distribution?
The broadcast model is a single shared stream that all connected counterparties receive, regardless of their role, limits, and subscriptions. The desk publishes a quote to the bus, and then each participant sees the entire set of instruments, including those they do not trade.
It is simple to implement, but delivery latency grows linearly with the number of subscribers: the wider the fan-out, the more time is spent on filtering and routing on the recipient's side, and counterparty limits have to be checked after the stream is received — that is, filtering out the excess after the fact.
Targeted distribution is built the opposite way: each counterparty has a profile of subscriptions and limits, and the router sends it only those quotes it is entitled to execute.
This is more expensive at the input — a registry of rules and state for each participant is required — but delivery latency stops depending on the total number connected: the counterparty receives a narrow stream rather than the entire market.
Counterparty limits are checked before sending, so a quote that is clearly unexecutable never enters the channel.
The choice of model is dictated by the task. Broadcast distribution is appropriate at the launch stage, when there are few counterparties and it is more important to quickly connect everyone with a single integration.
Targeted distribution becomes mandatory when there are dozens or more participants, each with their own limits and set of instruments, and the difference in latency between a fast and a slow recipient begins to affect execution quality.
In practice, the models are combined: the broadcast layer carries reference data and general indicators, while the targeted layer carries the streaming otc quotes themselves, taking limits into account.
Such a hybrid provides predictable delivery latency for active counterparties and does not force the desk to maintain a separate channel for each small participant.
Case study: how a quote stream stopped lagging behind the market
An OTC desk traded on streaming quotes that were collected from several sources and consolidated manually.
The gap between the display and actual execution accumulated into tens of seconds: the market maker set a price based on a stale snapshot, while the trade closed at a different one.
Each such case was investigated after the fact — the order log was compared against the quote log, and the step where the data diverged was traced.
What it was before
The stream was collected on a schedule: the aggregator polled the sources, put the snapshot into a cache, and the desk pulled it in full.
Several seconds passed between the poll and its arrival in the display, and another few seconds went to manual reconciliation whenever there was a deviation. The desk could not see which source had "fallen behind" and could not cut off a stale quote before execution. The result was desynchronization that was caught only at the trade.
What was changed
Collection was moved to an event-driven model: each price update arrives as a separate message rather than as a batch on a timer. A source timestamp and a cutoff rule were introduced — a quote older than a given window does not reach the display.
Divergence control was added: if the source price and the aggregated price diverge beyond a threshold, the stream flags the instrument as unstable and removes it from publication until it levels out.
What it became
| Desk metric | Before | After |
|---|---|---|
| Display latency | seconds, floating | consistently within the window |
| Manual recalculations per day | regular | isolated, for anomalies |
| Failure class "trade at a stale price" | recurring | eliminated by the cutoff policy |
| Incident investigation | manual log reconciliation | automatic source tagging |
Desynchronization stopped being an incident that is investigated after the fact: it is visible in the stream the moment it occurs.
The desk gained a stable quote stream and a predictable display — the market maker sets a price based on the current snapshot, not on whatever managed to arrive.
The cutoff and divergence control logic was built on stream event processing — Apache Kafka as the transport and custom validation rules on the desk side.
Doubts before implementation: compatibility, rollback, access
Before launching streaming OTC quotes, customers most often ask the same thing: will the new environment break the channels already in operation, can we return to the previous scheme, and what access rights will our team need to be granted.
We answer to the point, because it is precisely these three questions that determine whether the implementation will be manageable.
What will happen to the current channels? The streaming environment is connected in parallel to the existing ones: broker bridges, FIX sessions, and manual channels remain operational, while routing is switched at the gateway level.
First, the stream runs in comparison mode — new quotes are calculated but not published, and you see the discrepancy with the current source before anything changes in production.
How do we roll back? The rollback plan is fixed before the start: returning routing to the previous source is a configuration switch, not a code rewrite, so it takes minutes.
The state of order books and client subscriptions is restored from the journal, so a gap in quotes does not go unnoticed.
Do we need to give your team access to production?
No. We work in a separate environment with a replica of market data and deploy the build ourselves; access to production goes only through your approval procedures, with limited rights and logging of actions. Rights are revoked upon completion of the stage.
What if we have a non-standard stack? We check compatibility with the current channels during the scoping stage: we support common quote delivery protocols and message formats, and we describe non-standard adapters separately with an estimate of the effort involved.
The customer receives:
- gateway configurations and quote routing rules;
- a data flow diagram with failure points and their handling;
- an access policy and a role-based rights matrix;
- a rollback regulation with a step-by-step scenario;
- a description of message formats and adapters;
- logs comparing the stream with the current source;
- documentation on operation and shift handover.
Describe your task — we will come back with an estimate and a plan tailored to your environment.
Timeline for implementing the quote feed by stages
We break down the implementation of the quote feed for the OTC desk into stages with a fixed sequence: each subsequent step relies on the result of the previous one, so you cannot "shift right" one block without reassembling the rest.
The approximate timelines below are the duration of work, not calendar dates: the plan remains relevant regardless of the start moment, and the client sees exactly where the project stands and what happens at each interval.
In parallel with the core, we handle the integration part — this is the most common source of delays, because the formats of receiving systems rarely match the feed model.
Pilot operation runs on real data, but without shutting down the current channel: discrepancies are analyzed before the new feed becomes the primary one.
The final implementation schedule depends on the number of connected sources and consumer systems — after discovery, we provide a timeline for your specific environment, not an average market one.