Business license routes TickType.Trade to the FMV channel: live TradeBars are modeled fair-value with zero volume, not traded prices

[AlexCatarino]

Summary

The Polygon live data adapter delivers opening-bar Trade ticks with non-standard trade conditions (opening-auction prints, FINRA/ATS off-exchange ticks) that are not filtered in the real-time pipeline, causing live consolidated bars to differ significantly from the historical (AlgoSeek-based) bars for the same period.

This produces incorrect opening-range readings in live algorithms — the live bar's High/Low reflect off-exchange or auction prints that the offline bar builder excludes via the Excluded/Suspicious Ticks filter.

Behaviour observed

• Symbol: SNDK
• Date: 2026-07-31
• Resolution: 1-minute / 5-minute bars
• 09:30–09:35 bar received live: Low 1321.25, High 1354.40
• Actual regular-session range: ~1365–1405
• Data provider: PolygonDataProvider (Business license), streamed via WebSocket (FMV.SNDK topic)
• Polygon license: Business (confirmed in syslog: Using license type = 'Business')

The gap between the live bar's High (1354.40) and the regular-session Low (1365) indicates the live bar incorporated prints from before or outside the regular-session open — most likely opening-auction fills or FINRA/dark-pool prints without a valid primary-exchange code.

The historical bar for this period shows the correct range (backtest re-run is clean), confirming the discrepancy is a live filtering gap, not a vendor data error.

Related

Intercom conversation ID: 215475307209088

This is a specific instance of the known gap documented in the US Equities Suspicious Ticks section:
https://www.quantconnect.com/docs/v2/cloud-platform/datasets/quantconnect/us-equities#05-Suspicious-Ticks

The offline bar builder applies the Excluded Ticks and Suspicious Ticks filters; the Polygon real-time adapter's PolygonDataProvider does not yet apply the equivalent filter for the T (trade) WebSocket channel — so auction/FINRA prints pass through to the live consolidator.

Proposed fix

Apply the same trade-condition exclusion logic used by the offline AlgoSeek bar builder to the Polygon WebSocket trade message handler. Specifically, exclude ticks whose c (conditions) array contains codes mapped to off-exchange or auction-only trade conditions before passing them to the consolidator.

Reference: Polygon trade-conditions dictionary — https://polygon.io/docs/stocks/get_v3_reference_conditions

[AlexCatarino]

Correction from the filer — the diagnosis in the original report above is wrong. Please disregard it.

The report claimed live Trade bars were being contaminated by unfiltered auction/FINRA prints. That cannot be what happened, and the reporter's own numbers falsify it: extra unfiltered ticks can only widen a bar (add a lower low or a higher high) — they can never delete the true high or lift the true low. In the observed case the live bar's high (1354.40) is below the traded low (1365); the ranges do not overlap at all. So the bar contained no regular-session trades whatsoever. Nothing leaked in — the real prints never arrived.

What is actually happening

On a Business license, TickType.Trade is routed to the FMV channel and returns immediately, never subscribing to T or A/AM, with no fallback — PolygonWebSocketClientWrapper.GetSubscriptionEventType():

// TickType.Trade
if (licenseType == LicenseType.Business) { yield return EventType.FMV; yield break; }
yield return EventType.T;
if (resolution > Resolution.Tick) { yield return EventType.A; ... }

FMV is the vendor's "proprietary algorithm to generate a real-time … fair market value" — an algorithmically derived estimate, not a traded price. PolygonDataProvider.OnMessage then injects it as a trade tick, with size defaulting to 0m:

case "FMV":
    var fmv = parsedMessage.ToObject<FairMarketValueMessage>()!;
    ProcessTrade(fmv.Symbol, Time.UnixNanosecondTimeStampToDateTime(fmv.Timestamp), fmv.FairMarketValue);
    break;

private void ProcessTrade(string brokerageSymbol, DateTime timestamp, decimal price,
                          decimal size = 0m, string exchange = "")

So on a Business license every consolidated TradeBar is a smoothed model output carrying zero volume, presented to the algorithm as if it were the traded price. Around a fast open the model lags the tape and the entire bar can sit outside the traded range.

Observed in a live deploy: the subscription is logged as | Trade but the websocket line reads Subscribed to FMV.<TICKER>, and all 315 subscriptions in the deploy are FMV.* — zero T., A., AM., Q.. The TickType 'Quote' is not supported for license type 'Business' error comes from the same license-gating path.

This is not opening-bar-specific or symbol-specific: it affects every symbol, every bar, every session on a Business license. The open is just where the divergence is most visible.

The question this issue should be asking

Is the Business→FMV mapping intentional — a licensing workaround, since raw consolidated-tape redistribution requires exchange agreements that FMV sidesteps — or a bug?

• If a bug: channel selection should use T/AM for Business licenses.
• If intentional: it needs to be documented prominently, and FMV should not be surfaced to algorithms as an ordinary TradeBar. Opening-range, VWAP, volume-based and execution-sensitive logic are all silently invalid when the price series is a model output with zero volume.

I'll retitle this issue to match. Apologies for the noise on the original report.