Login Page - Create Account

Support Board


Date/Time: Tue, 17 Mar 2026 19:59:21 +0000



Post From: Remove ADFN orders from chart

[2026-02-14 09:41:19]
funbun - Posts: 94
The reason Sierra Cannot filter ADFN orders is now clear and nothing can change it -

The FINRA ADFN is identified by the Market Center Originator ID code "D" NASDAQ in both the CTA (Tapes A & B) and UTP (Tape C) consolidated data streams. This is the single most reliable field to identify an ADFN order. Every trade disseminated through the SIP carries an exchange/participant identifier — if that code is D, it originated from the ADF.

In Sierra Chart's data, this would appear in whatever field carries the exchange identifier for each trade record. The problem is whether Sierra Chart's Denali feed exposes this field to you at the ACSIL level — and that's where the friction likely is.


The DTC Protocol Doesn't Carry Trade Condition or Exchange Fields
Looking at the MARKET_DATA_UPDATE_TRADE message structure, the fields are:

SymbolID
AtBidOrAsk (enum: bid, ask, or no value)
Price
Volume
DateTime
UnbundledTradeIndicator (only for CME trade unbundling)

That's it. There is no field for sale condition codes (Z, U, L, T) and no field for market center / exchange originator ID (the "D" code that identifies ADFN). The DTC protocol was designed primarily for futures markets where this isn't an issue — CME trades all come from one venue and don't have the consolidated tape complexity of US equities.
The Data is Lost Before It Reaches You
The information pipeline looks like this:
SIP (CTA/UTP) → has full trade conditions + market center codes → Sierra Chart's Denali backend → strips these fields when normalizing → DTC protocol → no fields to carry them → ACSIL s_TimeAndSales → you only see Price, Volume, DateTime, Type, UnbundledTradeIndicator
The filtering metadata you need is discarded at Sierra Chart's feed handler level, before the data is ever encoded into DTC messages. So no — even though the data passes through DTC, there's no way to access these fields because they were never placed into the protocol in the first place.

Unless Sierra gives us access to data streams such as DataBento this is almost impossible to fix