Persistent IONQ SIP trade/bar mismatch: 2 trades and 2 shares

Alpaca Trading
1

I am trying to understand a persistent inconsistency between Alpaca’s historical SIP trades and its raw 1-minute bar for IONQ.

For the minute beginning 2025-01-08T20:42:00Z, the historical SIP trades endpoint currently returns:

Trade count: 1,713
Total size:  193,643 shares

The historical raw 1Min bar currently returns:

Trade count: 1,711
Volume:      193,641 shares

The difference is therefore exactly two trades and two shares.

I repeated the queries using:

  • single-symbol trades in ascending order, twice;
  • single-symbol trades in descending order;
  • multi-symbol trades in ascending order;
  • single-symbol raw minute bars;
  • multi-symbol raw minute bars.

All trade queries return the same 1,713 trade identities and payloads. Both bar queries return the same 1,711-trade, 193,641-share bar.

I also independently replayed the trades using Alpaca’s published minute-bar eligibility rules. The replay reproduces the provider bar’s open, high, low and close exactly, and reproduces VWAP when expressed at the provider’s six-decimal precision. It continues to produce volume of 193,643 and a trade count of 1,713.

The two-share difference can be explained by excluding any two of 190 one-share trades that contribute to volume and trade count but do not affect OHLC or VWAP. The historical trade fields do not reveal which two, leaving 17,955 indistinguishable candidate pairs.

My leading question is whether the bar reflects correction, cancellation, error or another provider-internal post-trade state that is not reflected in the historical trades response.

Could Alpaca please clarify:

  1. Were any IONQ trades in this SIP minute cancelled, errored or corrected after publication?
  2. Does the historical trades endpoint retain original prints while historical bars reflect subsequent corrections or cancellations?
  3. Is historical correction/cancel provenance available through an API, archive or support export?
  4. Is there another aggregation rule or internal state that explains the two-trade and two-share reduction?
  5. Is this expected behaviour or a historical-data defect?
2

@James Very astute catch and good questions:

1. Were any IONQ trades in this SIP minute cancelled, errored or corrected after publication?
There were two trades that were canceled later that day.

2. Does the historical trades endpoint retain original prints while historical bars reflect subsequent corrections or cancellations?
The trades endpoint includes all trades. There is a field labeled u in the JSON response which indicates if that trade was subsequently canceled or corrected. See the documentation here for more details.
canceled: indicates that the trade has been canceled
incorrect: indicates that the trade has been corrected and the given trade is no longer valid
corrected: indicates that this trade is the correction of a previous (incorrect) trade

3. Is historical correction/cancel provenance available through an API, archive or support export?
As noted above, there is a u field in the JSON response that indicates if a trade was corrected or canceled.

4. Is there another aggregation rule or internal state that explains the two-trade and two-share reduction?
Trades that are canceled or incorrect are not included in bar calculations however, they do show up as trades.

7. Is this expected behaviour or a historical-data defect?
This is the expected behavior.

Below are the two trades that are included in the trades result but are excluded from the bar calculation because the update field u is canceled.

image
image1918×112 15.8 KB

Again, good questions.

3

Thanks Dan, really helpful and appreciate the speedy response