Handling Stale Quotes in Concurrent Trading Models
Summary
The document raises a real-time data consistency problem in algorithmic trading. A model derives an ETF’s implied volatility from quotes for hundreds of components, but quote updates may arrive while a full recalculation is underway. The author asks how to balance responsiveness with reliable inputs when the output cannot be updated from a single tick.
Two simple concurrency approaches are described as problematic: locking writes can delay readers under heavy tick traffic, while exposing live updates directly to the model risks inconsistent calculations. The example highlights that a derived value can combine quotes from different moments, making a trading decision unreliable. No concrete solution or empirical comparison is provided; it is a question inviting approaches to synchronization and data snapshots, so the document frames the challenge rather than prescribing a method.
Key ideas
- A component-based ETF metric may require recalculating the full model after quote changes.
- Heavy write locking can make market data readers inefficient.
- Reading live updates during calculation can mix quote states from different times.
- The document identifies consistency and latency tradeoffs but does not settle on a solution.
Tags
Full text
# Algorithmic Trading Model Calculation and Stale Data # Algorithmic Trading Model Calculation and Stale Data I'd like ask everyone a more concurrency programming but definitely quant-finance related question. How do you deal with staleness of data in market hours as quote ticks are streaming and your model is calculating its values based on previous ticks (possibly stale quotes) to make trading decisions? Concrete example, deriving the implied volatility of an ETF according to the IV of its components. In an ETF with several hundred components, quote ticks are streaming in constantly and the model needs to respond to the changing ticks. Let's assume that there is no way to derive a composite IV with a single quote tick but the model has to be re-calculated as a whole. The naive concurrent programming model of lock on write would make the app woefully inefficient as there'd be thousands of writes (quote ticks) before the app can "read" from it. The other naive approach is to make the updated quote ticks visible to your reader thread, the app thread or business logic. However, this gets complicated because it forces the algo writer to be conscious of writing good concurrent code and know the concept of atomicity and immutability (e.g., what happens if you derive a metric half way in your code based on stale quotes before it got stale, and then use that variable to make the trading decision). I'm curious how you have solved or thought about this problem. Thanks in advance for your help and much appreciated!
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.