Market Data And Feeds

A trade means execution. A quote means a displayed market state. That distinction sounds obvious until you hit real feed plumbing: providers send “tick” messages, “quote” messages, and sometimes “update” messages that bundle multiple concepts. If your code treats a quote update as if it were a trade, you will update your position and P&L from a state change that never executed. If your code treats a trade as if it were a quote snapshot, you will overwrite your best bid/ask with stale or incomplete context.

The failure mode gets worse when you add event time and ordering. Feeds usually include multiple timestamps (for example, exchange time and receive time). If you compare “last trade” to “current best bid/ask” using inconsistent clocks, you will compute spreads and slippage from mismatched horizons. A backtest can still look smooth, because your logic stays internally consistent, but it becomes wrong relative to the actual sequence of information the market published.

This is where the Tick-Quote Taxonomy Map earns its keep. You will use it as a vocabulary bridge: map each microstructure term to the exact feed message class that can represent it, then enforce the mapping in your parser and state manager. When you do that, your downstream logic stops guessing. It stops making “reasonable assumptions” and instead follows rules you can test with replay logs.

Concrete example: suppose your strategy triggers when the “price crosses the bid.” If you read “price” as “last traded price” but your feed parser occasionally labels quote updates as trades, your trigger fires at quote refresh boundaries. You then place orders and measure fills against the wrong reference price. That turns a crossing rule into a timer-driven rule. You might not notice until you compare your fills to an exchange-level audit trail.

How It Works: The Tick-Quote Taxonomy Map for real feed messages

The core technique is simple: you define a strict classification for every incoming message, then you maintain two separate state objects - one for executions (trades) and one for market display (quotes). The Tick-Quote Taxonomy Map gives you the mapping rules from common microstructure terms to feed message types.

Use these classification rules in your parser. Treat them as hard gates, not “best effort” guesses.

1. Classify “trade-like” messages as executions - A “trade” (or “last trade”) updates execution state: executed price, executed size, and trade direction (if provided). - In the feed, you typically recognize these by fields like price + size (or quantity) that represent an actual match, along with a trade identifier or execution sequence number. - Expected outcome: your execution state updates only when you receive a message that asserts a match occurred.

2. Classify “quote-like” messages as displayed order book state - A “quote” (or “best bid/ask”) updates display state: bid price/size and ask price/size at a specific level, usually top-of-book for “best.” - In the feed, you typically recognize these by fields like bid_price/bid_size and ask_price/ask_size, or a side plus price/size that explicitly denotes quote changes rather than executions. - Expected outcome: your best bid/ask state updates only when you receive a message that describes order book display, not a match.

3. Treat “tick” as a transport label, not a meaning - Providers often call many message types “ticks.” Your code must not equate “tick” with “trade.” - Expected outcome: your logic never branches on the message name alone; it branches on the fields and the provider’s message schema.

4. Bind each state update to a single event time - Pick one timestamp for sequencing and one timestamp for latency metrics, and use them consistently. - For example: use exchange_timestamp (or equivalent) to order events within the market timeline, and use receive_timestamp to compute feed delay. - Expected outcome: your spread calculations use bid/ask from the same time basis as your comparisons, and your backtest doesn’t “borrow” future information.

To make this concrete, Riya Patel’s buy-side data pipeline usually has two downstream consumers: a signal engine and a fill simulator. She keeps ExecutionState and TopOfBookState separate. When a message arrives, her parser runs the taxonomy rules and updates only one of those objects. The signal engine reads TopOfBookState for spread and touch conditions; the fill simulator reads ExecutionState for last-trade-based features and for verifying whether a fill should occur.

Here’s the mapping you enforce in code using the taxonomy vocabulary:

• Term: “Last traded price” Map to: execution state update from a trade-like message Never map to: quote-like message updates

• Term: “Best bid” / “Best ask” Map to: top-of-book quote-like message updates Never map to: trade-like message updates

• Term: “Bid-ask spread” Map to: computed from quote-like state (best bid and best ask) Never compute from: only last traded price or from mixed timestamps

• Term: “Touch” (price at the inside) Map to: comparisons against quote-like best bid/ask state at the message’s event time Never compare against: execution price without also checking quote state recency

The payoff is that your system stops conflating “market changed its display” with “market executed a trade.” That single correction makes your downstream logic stable when you switch providers, because the taxonomy rules ride on schema fields rather than on naming conventions.

Putting It Into Practice: Apply the taxonomy to a realistic feed and verify outcomes

Riya Patel runs a replayable market data service feeding a signal engine and a backtesting fill simulator. She gets raw feed messages from a vendor, normalizes them, stores them for replay, and then runs a daily consistency check. Her workflow works because she tests the taxonomy mapping, not because she “trusts the labels.”

Assume her vendor sends two message types: TradeUpdate and QuoteUpdate, but she still validates fields because some vendors reuse naming. She also stores both exchange time and receive time.

Steps with expected outcomes

1. Parse and classify every message using the taxonomy map - For TradeUpdate, confirm you find execution fields: price and size that represent a match. - For QuoteUpdate, confirm you find displayed fields: bid_price/bid_size and ask_price/ask_size (or equivalent). - Expected outcome: every message ends up in exactly one bucket: execution-like or quote-like.

2. Update only the matching state object - On trade-like: update ExecutionState.last_price, ExecutionState.last_size, and append to an execution ring buffer keyed by event time. - On quote-like: update TopOfBookState.best_bid, TopOfBookState.best_ask, and append to a quote ring buffer keyed by event time. - Expected outcome: TopOfBookState never changes on trade-like messages; ExecutionState never changes on quote-like messages.

3. Compute derived values from the correct state - Compute spread only from TopOfBookState.best_ask - TopOfBookState.best_bid. - Compute “price crossed bid/ask” triggers by comparing the last execution price to the inside quotes at the same event time basis (or with an explicit recency rule you document). - Expected outcome: your triggers fire only when the market display and execution sequence support the condition.

4. Run a tight replay test against your stored raw messages - Pick a short replay window (for example, 60 seconds around a known high-activity period) and log every classification decision. - Expected outcome: you can point to specific timestamps where your system updated executions vs updated quotes, and you can confirm your fill simulator used the right input.

Quick checklist

• Confirm each message class contains the fields your taxonomy requires (execution fields for trade-like, displayed bid/ask fields for quote-like). - Enforce exactly-one classification per message. - Keep ExecutionState and TopOfBookState separate and update them independently. - Use one event time basis for sequencing and comparisons; use receive time only for latency metrics. - Log classification decisions during replay so you can audit misclassifications quickly.

If you do this on a live system, you still run the same checks, just continuously. You want your alerting to trigger on taxonomy violations: a message that looks trade-like but updates quote state, or a message that lacks required fields.

What to Watch For: Mistakes that break fills and spreads (and how to fix them)

Even solid teams run into the same edge cases. The taxonomy map helps, but you still need guardrails.

Misreading “tick” as “trade” Do this: Treat “tick” as a transport name. Classify by schema fields and message semantics, then update ExecutionState or TopOfBookState accordingly. Not this: Branch on the provider’s “tick” label and assume it always means execution. You will eventually mis-handle quote updates that arrive with tick-like naming, and your backtest will start “printing” fills from quote refreshes.

Mixing timestamps across state Do this: Compare and compute using a consistent event time basis. If you order events by exchange time, order both trade-like and quote-like state updates by exchange time, then apply your recency rules explicitly. Not this: Use exchange time for one feature and receive time for another. Your spread and trigger logic will drift under load, and you will see the drift only when the feed delay varies.

Overwriting inside quotes with executions Do this: Lock TopOfBookState updates to quote-like messages only. If you want “last price” features, store them in ExecutionState and keep them separate. Not this: Update best bid/ask from last traded price when you think the order book “should” align. The inside can move without an execution at the inside, and the last trade can occur at a level away from best when liquidity shifts.

These fixes all point back to the same discipline: definitions must map cleanly to message types, and your code must enforce that mapping at ingest time. Once you do that, you can trust the rest of your pipeline - signal logic, fill simulation, spread computation, and audit logs - because they all sit on top of the same grounded state model.

That trust becomes the foundation for the next step in building reliable feeds: validating data quality with measurable invariants, so you detect when the provider’s stream violates your assumptions before you ship trading behavior.

End of chapter one. 7 more chapters and about 15,357 words in the full book.