Market data feeds: a 30-day plan to price every tick

At the end of a bad week, an operations lead studies a dashboard: feed spend is up, a strategy reports stale prices, and the incident log shows two recovery events. The headline number is packets per second. It does not show which updates mattered, what they cost, or where time was lost.

A useful review measures the cost of a decision-quality update, not just the cost of a vendor invoice. Over 30 days, the team can establish that measure, find bottlenecks and make a controlled decision about depth, delivery mode or provider.

Define what a tick costs

"Tick" can mean an exchange message, a change to a displayed price, or an update consumed by a strategy. Those are not interchangeable. One message can update several book levels. A strategy may reject an update as stale, ignore it because its instrument is inactive, or use it to change an order.

Start with an all-in monthly cost for each venue and feed path. Include exchange display and non-display fees, professional user charges, redistribution rights, vendor and connectivity charges, and the infrastructure allocated to capture, recovery and normalisation.

The exact fee model depends on the exchange, entitlements and contract. Do not assume a feed subscription includes permission to redistribute data to clients or use it in every internal system.

Then report two measures separately: cost per accepted update, and cost per strategy-used update. The first helps compare feed paths. The second shows whether the data is relevant to a particular workload. State the denominator and period in the report. A monthly average can hide a bursty market or a low-volume instrument set.

A cheap feed that arrives after the decision window is not cheap for that strategy.

For wider platform context, Trading Technology's infrastructure coverage includes the operational questions behind vendor and platform choices.

Set a baseline for latency and capacity

Before changing anything, capture the same events at the network interface, feed handler, normaliser and strategy input. Record exchange timestamps where available, local receive timestamps, sequence numbers and the instrument.

Use synchronised clocks, but keep exchange time and local processing time as separate fields. A timestamp difference is not automatically network latency.

The ranges below are typical planning ranges, not service guarantees. They vary with venue, message mix, hardware, location and measurement boundary. Bandwidth is per venue at busy periods. Added delay runs from the stated provider edge or packet receipt to the consuming handler, so compare like with like.

Use the figures as a sizing prompt, not a procurement specification. A feed can be fast on a quiet day and still fail during an opening auction or volatility burst.

Track p50, p99 and maximum delay, plus sequence gaps, recovery duration, dropped packets and queue depth. Keep separate metrics for each venue and feed handler. For additional engineering coverage, see Trading Technology.

Run the 30-day implementation

Keep the first month focused. Do not change feed, hardware and strategy settings at once, or the comparison will not explain what moved the result.

1. Days 1-5, inventory. List venues, products, feed paths, entitlements, consumers, endpoints and monthly charges. Identify duplicate subscriptions and feeds that serve no live workload. Confirm whether each use is display, non-display or redistribution.
2. Days 6-12, instrument. Add sequence-gap, packet-loss and recovery metrics. Timestamp packet receipt, decode completion, normalisation and strategy delivery. Sample messages if full capture is too costly, but retain complete counters and logs for gap events.
3. Days 13-20, measure under load. Collect a normal session and at least one busy period. Compare message rates and latency distributions with CPU, NIC drops, queue depth and garbage collection or memory pressure. Replay captured bursts in a test environment to check whether the handler catches up after a spike.
4. Days 21-26, test one alternative. Compare a vendor, a reduced-depth subscription or conflation against the current path. Use the same instruments, time window and consumer. Check update loss and strategy decisions as well as bandwidth and p99 latency.
5. Days 27-30, decide and document. Calculate monthly cost per accepted and strategy-used update. Record the operational risk, entitlement impact, rollback method and owner. Keep the existing feed until the alternative has passed recovery and failover tests.

Make the measures operational

A dashboard is useful only if it points to an action. Set thresholds from observed baselines and strategy needs, then alert on sustained degradation rather than one noisy sample. Typical checks include:

• Sequence gaps by channel, with recovery start and completion times.
• Packet drops at the NIC and application queue depth, to separate network loss from handler overload.
• Exchange-to-receive and receive-to-strategy latency, with p99 and maximum values.
• Messages received versus updates accepted and consumed, broken down by venue and instrument group.
• Entitlement or connection changes that can affect display rights, non-display use or redistribution.

Reconcile the counters. If the handler reports more accepted updates than received messages, the definitions are wrong or the instrumentation is double-counting. If the feed is quiet while packet counts remain high, check retransmission, duplicate paths and irrelevant instruments. Assign an owner to each alert and document the recovery action, including when to fail over to a secondary line.

Choose the feed against the workload

More depth is not automatically better. A short-horizon strategy may need full order-book changes and tight tail latency. A risk screen or slower execution workflow may work with top-of-book data or controlled conflation. The decision turns on whether omitted updates change an order, risk limit or client-facing price, not on a preference for the largest feed.

Price the operating burden too. Direct multicast can reduce delivery delay, but the firm owns more of the decode, sequencing, recovery and monitoring work. A managed feed can simplify integration while adding provider dependency, a different latency boundary and possible limits on custom recovery. Compare support coverage and failure behaviour alongside recurring fees.

Keep the resulting baseline with the feed inventory and review it after venue changes, strategy launches and contract renewals. For a strategy sensitive to short-lived price changes, use 5 ms as a planning reference, not a universal target. Check your own p99 feed-to-strategy delay against 5 ms.

#market data latency #market data costs #tick data #exchange data fees #multicast market data #feed handler #market data infrastructure #data feed monitoring