Market-data bugs often start with one vague word: price. A quote, trade, aggregate close, midpoint, snapshot value, and model mark can all be called a price inside an app, but they answer different questions.
Use this guide to label market-data fields clearly in dashboards, scanners, research notebooks, alerts, and backtests.
Read this page with Quotes, Trades, Aggregates, Option Quote and Trade Conditions, and Backtesting Execution Realism.
Quick answer
Quotes show advertised bid and ask markets. Trades show executed prints. Aggregates summarize qualifying trades into bars. Snapshots combine latest state fields for convenience. A reliable application labels which object produced each value and avoids using one object as a silent substitute for another.
The core objects
| Object | Answers | Good for | Risk if misused |
|---|---|---|---|
| Quote | What bid and ask were shown at a timestamp? | Spread checks, executable context, quote-aware fills, scanner liquidity filters. | Can change quickly and can be wide, crossed, locked, stale, or missing. |
| Trade | What actually printed? | Tape review, volume, last-sale state, event study, aggregate construction. | Last trade can be stale and may not be executable now. |
| Aggregate | What did qualifying trades do over an interval? | Charts, indicators, compact backfills, daily reports. | Bar highs and lows are not guaranteed fill prices. |
| Snapshot | What is the latest convenient state bundle? | Detail pages, watchlists, current chain views. | Snapshot fields may mix quote, trade, reference, and derived values. |
| Reference | What instrument is this? | Symbol validation, contract identity, ticker search. | Reference is not market state. |
Quotes are not trades
A trade is evidence that two parties executed at a price. A quote is evidence that a market was advertised at a bid and ask. Both can be correct while appearing to disagree. In options, the last trade can be minutes or hours old, while the quote has moved with the underlying.
For scanner pages, keep this distinction visible beside Options Chain API, Historical Options Data API, Options Flow False Positives, and Why Option Quotes Matter More Than Last Price. That prevents last-price risk from leaking into chain rankings, alerts, or backtest fills.
If a UI uses last trade as a display value, label it as last trade. If a strategy uses bid/ask context for entries, store the quote row, quote timestamp, bid, ask, midpoint, spread, and any reject reason. Do not rewrite those as a generic price without metadata.
Aggregates are context, not fill proof
Aggregates compress many trade rows into open, high, low, close, volume, VWAP, and trade count fields. They are not proof that an order could have filled at the bar high or low. For backtests, use completed bars to create signals and quote evidence to model fills after the signal timestamp.
Sparse options contracts make this especially important. A one-minute bar with one qualifying trade is different from a one-minute bar with hundreds of trades. Store the trade count and volume alongside the OHLC values.
Snapshot values need source context
Snapshots are convenient because a single response can include latest quote, latest trade, Greeks, implied volatility, underlying context, and reference fields. That convenience is also the trap. When a downstream job consumes a snapshot, it needs to know which nested field it used and what timestamp belongs to that field.
For example, an options scanner might rank by implied volatility, filter by open interest, reject contracts with wide quotes, and display last trade. Those are four different concepts. The saved scanner result needs to preserve each source field separately.
Naming pattern
Prefer explicit names in storage and UI:
| Generic name to avoid | Better names |
|---|---|
price | last_trade_price, bid_price, ask_price, midpoint_price, bar_close, mark_price |
time | quote_timestamp, trade_timestamp, bar_start, request_timestamp |
volume | trade_size, bar_volume, session_volume, open_interest |
ticker | underlying_ticker, option_ticker, contract_ticker |
Common implementation checks
- Store quote and trade rows in separate tables or with explicit object type.
- Preserve row-level timestamps alongside request timestamps.
- Keep
request_idwith the job or artifact that used the data. - Record whether the data was live, delayed, or historical.
- For backtests, store why a fill was accepted or rejected.
- For charts, document whether missing intervals mean no qualifying trades or a fetch gap.
Related CuteMarkets docs
- Data Sources and OPRA
- Market Data SIPs and Direct Feeds
- Stock Trades and Quotes
- Quotes
- Trades
- Aggregates
Semantics implementation notes
Keep the three objects separate in storage. Quotes describe bid and ask markets, trades describe prints, and aggregates describe completed intervals. A product can display all three in one panel, but the backend should not collapse them into "price" without preserving source type, timestamp, condition fields, and request window.
For backtesting, use Quotes for fill realism, Trades for last-sale context, and Aggregates for charts and bar-based signals. A quote-aware fill can reference a midpoint, but it still needs bid, ask, size, quote age, and side. A trade-aware alert can reference a print, but it still needs quote context before claiming tradability.