Suppose your platform reports 96,000 trades in a session the exchange counted at 480,000, and nothing is broken. Between the matching engine and your chart sits a distributor that is allowed to collapse many updates into one, and on many retail tiers that is exactly what happens during the fastest minutes of the day. The practice is called conflation, the firms that do it document it in public, and it is rarely explained to the retail subscribers it affects.
Conflation is the practice of combining multiple rapid updates for one instrument into a single later message, so a subscriber receives the most recent state at the end of an interval rather than every intermediate event. Distributors apply it because during bursts the message rate can exceed what a downstream link or client application can consume, and the main alternative is queuing, which keeps every event but arrives progressively later. Conflation preserves the price path, so chart and swing traders are essentially unaffected, but it samples the event stream, so tick bars, footprint imbalance, delta and any trade-count metric are computed on a fraction of the real activity.
What is conflation, exactly?
Conflation is the combining of data in multiple messages to form one single message. Intercontinental Exchange defines it in those terms and states the purpose without euphemism: the intention is to control and throttle the distribution of data. At the end of each conflation interval you receive the latest state of the instrument. What the instrument did between the start and the end of that interval is never sent.
Conflation is not compression, because nothing is recoverable. It is not aggregation into bars, because no bucket boundary is recorded. It answers "where is this market now" instead of "what did this market do". ICE's stated rationale is that a desktop user can only observe data flashing by at 100 to 150 milliseconds per interval, and anything faster is invisible to the human eye. That reasoning is sound for a discretionary chart trader and false for anything that counts events.
ICE names distinct modes, and the differences decide whether your strategy survives.
| Mode | What is collapsed | What survives | Effect on order flow |
|---|---|---|---|
| None (tick by tick) | Nothing | Every quote and trade event | Intact |
| Intervalized | Quotes and trades, to the latest state per interval | Current price and book state | Trade stream sampled |
| Trade-safe | Quote information only | Individual trade prints | Largely preserved |
| Just-in-time | Trade-safe rules, applied only during stress | Tick by tick in normal conditions | Degrades during dislocation |
Intervalized conflation fixes the interval in advance, one second for example, updating quote and trade information to the latest changes at that mark. Trade-safe conflation collapses only quote-related information, so clients are not likely to miss a trade. That distinction decides whether an order-flow strategy is viable, which makes "is your conflation trade-safe or intervalized" the most useful question you can put to a vendor.
Just-in-time conflation applies trade-safe rules only during market dislocation or when data spikes mean the receiving application cannot keep up, engaging when backpressure is detected and reverting to tick-by-tick data once the edge device determines the dislocation event has passed. ICE also states that the client is notified when JIT conflation goes into effect and again when it is removed, and that the rate is continuously and dynamically adjusted while it is on. Two things follow. A feed can be complete for most of the session and thin out precisely during the minutes you actually trade. And whether you learn that happened depends on the notification reaching you, since a downstream platform is under no obligation to surface it.
Why would a distributor throw data away?
Because the alternative is worse for most subscribers. ICE states the condition plainly in its description of JIT conflation: it protects a client's connection when their bandwidth or application CPU would otherwise be unable to keep up. When the inbound rate exceeds what the link and the client can consume, two broad behaviours remain, and both lose something.
Conflation keeps you current by making you incomplete, and queuing keeps you complete by making you late.
The arithmetic explains why vendors pick conflation for retail tiers. Take an illustrative burst of 20,000 messages per second on one heavily traded instrument's full-depth stream, at an encoded 60 bytes per message. That is 20,000 x 60 = 1,200,000 bytes per second, or 1,200,000 x 8 = 9,600,000 bits per second: 9.6 Mbps sustained for one contract, before the client application has parsed a single field. Apply a 100 ms cap and the delivered rate falls to 1000 / 100 = 10 updates per second, which is 10 x 60 = 600 bytes per second, a reduction of 1,200,000 / 600 = 2000 times. The message rate and wire size here are illustrative and vary by exchange, product and encoding, so confirm actual figures with your vendor. That ratio is the honest reason conflation exists.
Picture the split at the distributor edge. One inbound stream of discrete events leaves the exchange matching engine and reaches a distributor whose downstream socket cannot carry the rate. From that one node two outbound paths are possible: the queuing path, where every event survives into the client application but arrival drifts further behind a growing backlog until the trader is watching a correct market from thirty seconds ago, and the conflating path, where one state update per interval reaches the client on time and the intermediate events fall out entirely. Same input, same node, two different things broken.
One structural detail decides how much this hurts you, and it splits by conflation type. A fixed intervalized cap is applied per instrument, so one update per instrument per interval binds just as hard on a trader watching a single contract as on a desk watching four hundred, and trimming your symbol list does not raise that ceiling. Backpressure-driven conflation behaves differently, because it triggers on aggregate load: ICE describes JIT conflation as engaging when backpressure is detected and lifting when the dislocation passes, so a lighter subscription genuinely can keep it from engaging at all. Establish which type you are on before pruning symbols, because on one of them that work does nothing.
How much of the stream actually disappears?
Enough to change the sign of a metric, not just its magnitude. Take a feed conflating to a maximum of one update per instrument per 100 ms. In one 100 ms window the market genuinely prints 40 distinct trades. The client receives 1 state update. Delivered events = 1 of 40 = 2.5 percent. Discarded = 39 of 40 = 97.5 percent. Extend that burst to a full second and the ratio is unchanged: 1000 / 100 = 10 windows, so 10 x 40 = 400 real trades against 10 delivered updates.
Now the part that ruins statistics rather than merely degrading them. Under the same 100 ms cap, a quiet period printing 2 trades per window is sampled at 1 / 2 = 50 percent. A burst printing 40 trades per window is sampled at 1 / 40 = 2.5 percent. The sampling rate drops by 50 / 2.5 = 20 times exactly when activity rises. That sampling is neither random nor stationary, so the bias moves with market state and no constant scaling factor repairs it after the fact.
Why tick bars quietly become time bars
A hard update cap turns a tick bar into a clock. Suppose a feed caps updates at one per instrument per 250 ms, giving a maximum delivered rate of 1000 / 250 = 4 updates per second, and a trader uses 500-tick bars where the platform increments the tick count once per delivered update. Whenever real activity exceeds the cap, the bar closes after 500 / 4 = 125 seconds, which is exactly 2 minutes and 5 seconds, every time.
Compare two of those bars. In the quiet case the market prints 3 trades per 250 ms window, so 500 windows contain 500 x 3 = 1500 real trades. In the burst case it prints 50 trades per window, so the same 500 windows contain 500 x 50 = 25,000 real trades. Both render as one 500-tick bar of identical duration, yet the burst bar holds 25,000 / 1500 = 16.67 times more real activity. Tick bars exist to expand when activity expands. Under a cap they do the opposite, during the exact conditions they were chosen for.
Footprint imbalance fails harder, because it fails directionally. Inside one 250 ms window at a single price level the market truly prints 30 buy-side trades totalling 210 contracts and 12 sell-side trades totalling 90 contracts. True trade-count imbalance = 30 / 12 = 2.5 to 1, true volume imbalance = 210 / 90 = 2.33 to 1, total window volume = 210 + 90 = 300 contracts. The conflated feed emits one update. If the platform derives the print from the last state, it records one print on one side and the 2.5 to 1 imbalance collapses to 1 to 0, which is not a ratio. If the update carries total volume with no bid and ask split, all 300 contracts land on whichever side printed last, converting a 2.33 to 1 imbalance into 300 to 0 or 0 to 300 by chance. That is a sign error, not a rounding error. Our walkthrough of order flow and the DOM covers what each cell is supposed to represent before conflation gets to it.
Why volume reconciles while trade count does not
Volume is a running total and survives conflation; trade count is a count of events and does not. That holds where the feed carries a session cumulative volume field and forwards it in every interval update, which is the common design, so the latest state holds the correct total however many prints were skipped. It does not hold universally: if a feed carries per-message trade volume and your platform sums those messages, conflation eats volume too, though at least it then fails loudly. Establish which of the two you have before trusting the tie-out.
Put numbers on the common case. A contract trades 1,200,000 contracts across 480,000 trade prints in a session, an average of 1,200,000 / 480,000 = 2.5 contracts per print. The conflated feed delivers 96,000 updates. End-of-session volume on the platform reads 1,200,000 and ties to the exchange exactly. Reported trade count reads 96,000 against 480,000 actual, which is 96,000 / 480,000 = 0.20, exactly 20 percent, understated by a factor of 480,000 / 96,000 = 5. The volume check passes cleanly on a feed that discarded 384,000 events. The reconciliation most traders run instinctively is the one measurement conflation is least likely to break.
How snapshot recovery deletes events with no error
A second loss path has nothing to do with throttling and leaves even less evidence. Feeds are commonly delivered as an initial full snapshot followed by sequence-numbered incremental updates, and when a client detects a sequence gap it has two possible remedies that are not equivalent. A retransmission or replay path resends the actual missed messages and recovers the history; many exchange-native feeds provide one. A snapshot recovery path hands the client a fresh picture of current state, restoring a correct book and nothing else, because restoring state and reconstructing history are different guarantees. Which path your platform takes is seldom spelled out in the retail-facing manual.
Follow the timeline on the snapshot path. Incremental messages flow into the client. The client falls behind during a burst, a gap is detected, the incremental path is cut, and the recovery loop pushes a fresh snapshot that overwrites the book. The client's last successfully processed message was sequence 4,182,006. The replacement snapshot reflects state as of sequence 4,182,431. Messages never delivered = 4,182,431 - 4,182,006 = 425. The book is correct the instant the snapshot lands and the chart shows nothing wrong, yet those 425 events entered no counter, no footprint cell and no delta calculation. Let that happen four times in a session and 4 x 425 = 1700 events are absent from a file the trader will later call tick data.
A snapshot re-sync makes your book right again and your event history permanently wrong, with no warning on the chart. Any recording made through a re-syncing session has holes that no downstream tool can see.
Two other places the event stream dies
Conflation happens downstream at the distributor, and it is not the only reducer in the chain. Sierra Chart documents the source-side one: due to increased trading volumes, exchanges routinely bundle, roll up or combine trades together, so one trade received may actually be many trades. A perfectly unconflated feed can still deliver one message representing several counterparty fills. The two effects stack, and only one of them is your vendor's decision.
The same page names a data provider intentionally sending less data to minimize bandwidth usage as a cause of differences between platforms, and notes that EUREX has different data feeds where one provides every trade and another does not. Completeness is a purchasable product tier, not a property of the instrument, so two traders quoting different trade counts for the same contract can both be reading their software correctly.
The third reducer sits inside your own machine. Sierra Chart's tick by tick data configuration guide states that a tick means 1 trade, and that the intraday data storage time unit must be set to 1 tick for maximum accuracy in the studies that depend on trade-level detail. Store a complete feed into a one-second bucket and the platform aggregates the trades itself. The feed was fine, the recorder destroyed the stream, and the resulting file is indistinguishable from a conflated one at a glance.
How do you detect conflation on your own feed?
Log inter-update timestamps and look for a ceiling, because a cap has a shape the market does not. Record update times for one instrument across a violent 10-second move. A 250 ms cap permits at most 10 x (1000 / 250) = 40 updates in that span; a 100 ms cap permits at most 10 x (1000 / 100) = 100. The signature is not a number you see twice, it is a number you never exceed. If your busiest ten seconds of the year lands on exactly 40 updates, every other fast window lands on 40 as well, and quiet windows sit well below, you are measuring a 4 per second ceiling rather than a market. Sorted inter-update gaps show the same thing: an unconflated feed gives a wide ragged spread, a conflated feed piles them on the interval.
Two confirmations follow. Run two feeds on the same instrument over the same window and compare trade counts rather than volume. Then check the shape of your order-flow metrics: if delta and imbalance look smoother in high volatility than in quiet periods, that is backwards, and it is the classic conflation signature.
Sierra Chart states that daily volume may include trades such as spread and strategy trades in futures, or special trades in equities, that are not included in intraday charts, so comparing exchange daily volume to the sum of intraday volume bars is not a valid comparison. Compare trade counts across two feeds instead.
Who is affected and who is not
Whether conflation matters to you depends on one question: does your signal consume individual events, or only the price path?
| Trader | Signal source | Impact |
|---|---|---|
| Swing and chart traders | Price path and structure | Essentially none |
| Indicator and moving-average systems | Closes, highs and lows | Essentially none |
| Tick-bar and volume-bar traders | Delivered update count | Severe, bar period distorts |
| Footprint, delta and absorption traders | Individual prints and sides | Severe, sign errors possible |
| Copier users, for execution | Fills reported on an account | Essentially none |
Chart traders escape for a mechanical reason rather than a lucky one: each interval update carries the latest state, so the sequence of prices reached still registers and extremes generally survive into the bar. Say "essentially unaffected" rather than "unaffected", though, because a spike reached and fully retraced inside a single conflation window can vanish from top-of-book. If you are weighing data tiers, our comparison of Level 1 and Level 2 market data is the place to start.
Copier users are insulated for execution because a copier reacts to a fill reported on the leader account, not to a counted market tick. A leader fills 3 ES contracts at 5500.00 and the follower fills at 5500.25. E-mini S&P 500 futures are quoted at $50 per index point with a 0.25 point minimum tick, so one tick is 0.25 x $50 = $12.50 per contract and the slippage is 0.25 x $50 x 3 = $37.50 total. Contract specifications do change, so verify the current multiplier and tick size with CME Group. Nothing in that chain read a tick count, which is why feed completeness and replication accuracy are separate problems.
Why a conflated recording is not a tick backtest
A backtest run on a conflated recording is not a tick-level backtest, whatever the filename says. The error survives review precisely because the price path is intact, so equity curves on path-based strategies look plausible and the file passes every eyeball check. The damage is confined to strategies that consume individual events: tick-count bars, trade-count order-flow metrics, footprint imbalance, delta divergence and absorption logic.
Two consequences follow. A strategy that tests well on a conflated recording and fails live has not necessarily been overfitted; it may have been fitted to a stream that no longer exists at execution time. And walk-forward analysis will not catch it, because every window in the file is conflated the same way. The full argument about what tick data buys and where bar data is sufficient is in our piece on tick data versus bar data for backtesting, and conflation is the failure mode that makes an expensive tick dataset behave like a cheap one.
Is an unconflated feed worth the money?
For most traders, no, and that is the honest answer rather than a hedge. Unconflated full-depth and order-level feeds cost more in exchange fees, vendor fees, bandwidth and client-side processing, and they require a client that can consume the burst rate without queuing, which reintroduces the latency you paid to avoid. Fee schedules change, so verify current market data costs with CME Group and your vendor. If your strategy reads only the price path, that spend buys precision you never read.
The upgrade is worth it when your signal is the event stream itself, and worth it in a specific order: confirm the feed is conflated using the interval-logging test, confirm your storage unit is not aggregating the trades, then buy the tier. Traders regularly pay for full depth while recording it into a one-second bucket, which spends money to fix a problem they still have.
One limit cuts against the obvious upsell. A trade copier does not fix a degraded feed. If your entry signal is derived from conflated order flow, replicating it faster and to more accounts distributes a worse signal at scale. Copier latency and feed completeness are orthogonal problems. Fix the sample where it breaks, at the vendor tier and the recorder, then worry about how fast you can duplicate the decision.
Frequently asked questions
What is conflation in market data?
Conflation is the combining of several rapid updates for one instrument into a single message, so the subscriber receives the most recent state at the end of an interval instead of every intermediate event. Intercontinental Exchange describes the purpose as controlling and throttling the distribution of data. The current price stays accurate while the count of individual events is reduced.
Does conflation mean my broker is hiding data from me?
No, conflation is a documented engineering choice rather than misconduct. Intercontinental Exchange publishes definitions of intervalized, trade-safe and just-in-time conflation, and describes just-in-time conflation as protecting a client's connection when their bandwidth or application CPU would otherwise be unable to keep up. The behaviour is disclosed by the firms that apply it, it is simply never taught to retail traders.
How can I tell if my data feed is conflated?
Log the timestamps of every update for one instrument during a violent move and look for a ceiling your update count never exceeds, typically at a round interval such as 100 ms or 250 ms. The signature is a fast market pinned to a constant rate while quiet periods sit well below it, which is a cap rather than a market. Running two feeds on the same instrument and comparing trade counts is the most direct confirmation.
Why does my platform's volume match the exchange while the trade count does not?
Volume is a running total that survives conflation, while trade count is a count of events that does not. Feeds commonly carry a session cumulative volume field forward in every interval update, so the total ties out exactly even when the feed delivered a fraction of the prints. That only holds for cumulative volume fields; a feed carrying per-message trade volume that your platform sums will under-report volume as well.
Can I compare my chart volume against exchange daily volume to check my feed?
No, that comparison is not valid. Sierra Chart documents that daily volume may include trades such as spread and strategy trades in futures, or special trades in equities, that are not included in intraday charts, so the two figures are not measuring the same thing. Compare trade counts between two feeds over the same window instead.
Does conflation affect tick charts?
Yes, and it affects them in the worst possible way. When the delivered update rate is capped, a tick bar closes on a fixed clock during bursts, so a 500-tick bar on a feed capped at four updates per second closes every 125 seconds regardless of real activity. The tick bar degenerates into a time bar during exactly the conditions tick bars exist to capture.
Is snapshot recovery the same thing as conflation?
No, they are separate loss paths that can produce a similar outcome. Feeds are commonly delivered as an initial snapshot plus incremental updates, and a client that detects a sequence gap can either request a retransmission, which resends the missed messages and preserves the history, or take a fresh snapshot of current state. The snapshot path restores a correct book but does not replay the missed messages, so those events never reach any counter.
Does conflation affect trade copiers?
Not for execution purposes, because a copier reacts to a fill reported on the leader account rather than to a counted market tick. The trigger is an account event, so the replication result is unchanged by how many market updates the feed delivered. It does matter indirectly if the leader's entry signal is itself built on conflated order flow, since the copier will then distribute a degraded signal to more accounts.
What is trade-safe conflation and why does it matter?
Trade-safe conflation collapses only quote-related information for a pre-determined interval, so clients receive conflated quote data but are not likely to miss a trade, according to ICE. That distinction preserves the exact stream order-flow traders consume, which intervalized conflation does not. Asking a vendor whether their conflation is trade-safe or intervalized is the single most informative question about feed quality.
Do I need to pay for an unconflated full-depth feed?
Only if your strategy consumes individual events rather than the price path. Unconflated feeds cost more in exchange fees, vendor fees, bandwidth and client CPU, and they need a client that can consume the burst rate without falling behind, so verify current pricing with CME Group and your vendor. Check first that your own platform is storing data at a one-tick interval, since a complete feed recorded into a one-second bucket is no longer tick data.