DEV Community: ICF Market LTD

NinjaTrader Tick Replay: What Historical Order Flow Really Contains

ICF Market LTD — Sat, 31 Oct 2026 11:55:43 +0000

An order-flow indicator can behave correctly on a live NinjaTrader chart yet produce a different-looking historical delta. Sometimes the script never processed historical trade events; sometimes the events were present but the historical quote context was incomplete.

Tick Replay can help with the first problem. It does not automatically solve the second.

In brief: Tick Replay rebuilds historical bars using stored trade ticks and replays Last events. It does not provide a complete history of changing bid/ask quotes or depth, and it does not make historical strategy fills equivalent to live execution.

What Tick Replay changes

In a normal historical calculation, an indicator commonly works from completed bars. Setting Calculate = Calculate.OnEachTick by itself does not create intrabar events from data that is not available.

With supported historical tick data and Tick Replay enabled, NinjaTrader reconstructs historical bars from stored trade events. A script designed for Tick Replay can receive historical OnBarUpdate() and OnMarketData() calls.

Two event paths matter:

OnBarUpdate() follows the indicator's Calculate mode, such as OnEachTick, OnPriceChange, or OnBarClose.
OnMarketData() receives historical MarketDataType.Last events under Tick Replay, including the event's price, volume, and associated best bid/ask prices.

NinjaTrader documents that, for the replayed sequence, the relevant OnBarUpdate() runs before its corresponding OnMarketData() event. This matters when you group per-trade volume into bars: the bar boundary and the first Last event of the new bar are not interchangeable callbacks.

The key limitation: Last events are not full quote history

Historical Tick Replay preserves the best bid and ask prices associated with a stored Last event. It does not replay the independent stream of historical bid/ask changes or bid/ask volume events. Nor does it reconstruct historical Level II depth.

Even the trade-time bid/ask context deserves scrutiny: NinjaTrader documents that when the source data lacks those values, the platform may substitute bid/ask prices. A classifier can still return a side, but the result is not proof of genuine historical aggressor-side data.

This distinction is easy to miss when historical charts look convincingly complete.

A minimal NinjaScript Last-event example

This is an excerpt for an indicator class, not a complete copy-and-compile NinjaScript indicator. It demonstrates where the replayed trade's size and quote context come from; it deliberately leaves session boundaries and data-provenance validation to the surrounding implementation.

// Fields declared inside an indicator class
private long buyVolume = 0;
private long sellVolume = 0;
private long unknownVolume = 0;

protected override void OnMarketData(MarketDataEventArgs e)
{
    if (e.MarketDataType != MarketDataType.Last || e.Volume <= 0)
        return;

    // A sane spread is not proof that quotes are historical originals.
    if (e.Bid <= 0 || e.Ask <= 0 || e.Bid >= e.Ask)
    {
        unknownVolume += e.Volume;
        return;
    }

    if (e.Price >= e.Ask)
        buyVolume += e.Volume;
    else if (e.Price <= e.Bid)
        sellVolume += e.Volume;
    else
        unknownVolume += e.Volume; // Inside the spread
}

Notice the use of e.Volume, the size of this Last event. Using Volume[0] as though it were the size of an individual print can double-count volume: it represents bar-series volume, not necessarily the current trade's volume.

These counters are running totals. A bar-level footprint needs additional keys for the instrument, bar/session identity, and integer price level, plus explicit commit/reset logic.

Three traps that distort historical delta

1. Using real-time bid/ask helpers for historical trades

GetCurrentBid() and GetCurrentAsk() are real-time-oriented. NinjaTrader documents that historical calls can return the evaluated bar's close instead. For replayed historical Last events, use the MarketDataEventArgs.Bid and .Ask associated with OnMarketData()—while still checking their provenance.

2. Confusing calculation frequency with data availability

Calculate.OnEachTick controls a calculation path; it does not manufacture missing historical ticks. Conversely, an implementation centered on OnMarketData() does not always need an expensive OnEachTick calculation in OnBarUpdate().

Design for the events actually used, then measure performance with your instrument and provider.

3. Treating reconstructed data as backtest-quality execution data

Tick Replay is designed for historical data-event processing, not precise historical order-fill simulation. Missing quote information, event ordering assumptions, and unsupported bar types can all affect the result.

NinjaTrader also notes compatibility limits for some multi-time-frame/multi-instrument scripts and certain bar types, including built-in Renko and Line Break variants. Test those combinations rather than assuming support.

A practical checklist before you trust a chart

Confirm the provider supplies the required historical Last tick data for the requested dates.
Inspect how the provider and platform handle missing trade-time bid/ask context.
Log several OnBarUpdate() / OnMarketData() sequences near a bar boundary.
Confirm that the sum of event sizes matches the volume accounting in your aggregation.
Test the historical-to-realtime transition and compare with recorded live data where possible.
Benchmark the actual dataset; avoid universal claims about Tick Replay loading time.

At ICF Market, our free volume and order-flow education series explains the trading concepts behind delta and volume-at-price. This article focuses on the NinjaScript data mechanics required to represent those concepts honestly.

Key takeaways

Tick Replay replays historical Last events, not an independent historical quote-change stream.
OnMarketData() is the appropriate source for trade-event price, size, and associated best bid/ask values.
Quote availability, bar boundaries, and execution-fidelity limits still need explicit tests.

Discussion: When you build historical delta in NinjaScript, how do you indicate that bid/ask context was missing or substituted by the provider?

Official NinjaTrader references

Disclosure: This article was prepared with AI assistance and reviewed against NinjaTrader's published documentation. The code excerpt was not compile-tested in NinjaTrader 8/8.1 during this editorial review. Educational content only; not trading advice.

Classifying Aggressor Side in Order Flow: Quote Rule vs. Tick Rule

ICF Market LTD — Sat, 31 Oct 2026 11:21:18 +0000

A footprint chart may show buy volume, sell volume, and delta down to the price level. But a trade print alone does not necessarily tell you which side initiated the trade. Every classification method relies on some combination of exchange flags, quote context, or a price-change heuristic.

The engineering challenge is not simply to label every print. It is to keep the classification auditable when the data is incomplete.

In brief: Prefer a documented, time-aligned aggressor flag or quote context when available. Treat tick-rule results as estimates, and track trades you cannot classify instead of quietly forcing them into buy or sell volume.

What an aggressor-side label actually means

Every executed trade has a buyer and a seller. A buyer-initiated trade generally means an incoming order executed against resting sell liquidity; a seller-initiated trade executed against resting buy liquidity.

Neither label predicts what price will do next. It describes the likely mechanism of execution, not a trading signal.

Some feeds supply aggressor-side flags directly. Others expose prints and inside quotes from which a label must be inferred. Before combining data sources, check what each feed promises about quote timestamps, ordering, and venue coverage.

Two common classification methods

1. Quote rule: compare the trade with the spread

Given an appropriate bid/ask snapshot from the time of the trade:

Trade at or above the ask → buyer-initiated candidate.
Trade at or below the bid → seller-initiated candidate.
Trade inside the spread → uncertain under this rule.

The word appropriate matters. A quote received just before a trade is not necessarily the quote that applied when it executed. Trade and quote messages can arrive on different channels or out of order.

Reject invalid, locked, crossed, or stale quotes according to a documented feed policy. In particular, if both comparisons could be true, do not let the order of your if statements decide the trade's side.

2. Tick rule: infer from the previous trade price

If trustworthy quote context is missing, the tick rule provides a cheaper fallback:

Price above the previous print → buy candidate.
Price below the previous print → sell candidate.
Unchanged price → use an explicit zero-tick policy or mark unknown.

One common zero-tick policy carries forward the last nonzero price-change direction. That is still a heuristic. A wider spread, sparse trading, or incorrectly ordered prints can make it diverge from a quote-based label.

C# example: preserve an Unknown state

The following excerpt illustrates a conservative classification policy. It is application-level C#, not a complete NinjaScript indicator. It assumes trade and quote timestamps have already been normalized to a comparable clock.

enum AggressorSide { Buy, Sell, Unknown }

sealed class TradePrint
{
    public double Price;
    public DateTime TimeUtc;
}

sealed class QuoteSnapshot
{
    public double Bid;
    public double Ask;
    public DateTime TimeUtc;
}

static AggressorSide Classify(
    TradePrint trade,
    QuoteSnapshot quote,
    double? previousPrice,
    AggressorSide lastNonzeroTickSide,
    TimeSpan maxQuoteAge)
{
    bool usableQuote = quote != null
        && quote.Bid > 0
        && quote.Ask > quote.Bid
        && trade.TimeUtc >= quote.TimeUtc
        && trade.TimeUtc - quote.TimeUtc <= maxQuoteAge;

    if (usableQuote)
    {
        if (trade.Price >= quote.Ask) return AggressorSide.Buy;
        if (trade.Price <= quote.Bid) return AggressorSide.Sell;
        return AggressorSide.Unknown; // Inside the spread
    }

    // Fallback only when quote context is unavailable.
    if (!previousPrice.HasValue) return AggressorSide.Unknown;
    if (trade.Price > previousPrice.Value) return AggressorSide.Buy;
    if (trade.Price < previousPrice.Value) return AggressorSide.Sell;
    return lastNonzeroTickSide; // Explicit zero-tick policy
}

The maxQuoteAge threshold is an application policy, not a universal constant. This example also does not prove that two timestamps from different feeds refer to the same clock or that the quote was valid at execution time.

For production code, normalize prices to integer tick indices where appropriate, record the method used for each label, and test how the zero-tick state survives repeated prices and session boundaries.

What should happen to unknown volume?

Maintain three buckets rather than quietly assigning every print to a side:

classified_delta  = buy_volume - sell_volume
classified_volume = buy_volume + sell_volume
total_volume      = classified_volume + unknown_volume

A delta calculated from classified trades may still be useful. It should simply not be presented as though all traded volume was classified with equal certainty.

An unclassified-volume percentage is a useful quality metric: if it spikes on one instrument, session, or provider, that can reveal a quote-data problem before the histogram misleads someone.

Test the data pipeline, not just the chart

A compact regression fixture should include:

Trades at bid and ask with valid, synchronized quotes.
A print inside the spread and a locked or crossed quote.
A stale quote, out-of-order timestamps, and the first print of a session.
Multiple consecutive trades at the same price.
A conservation check: buy + sell + unknown == total.

Keep ingestion, classification, aggregation, and rendering separate. That makes it possible to compare two classification policies against the same recorded data without changing the footprint renderer.

For background on tape reading and delta, I work with ICF Market, whose free volume and order-flow education series covers the underlying concepts. The C# policy above is an educational illustration, not a claim about ICF Market's internal implementation.

Key takeaways

An aggressor-side label is a statement about execution, not market direction.
Quote-rule and tick-rule labels are only as reliable as their inputs and documented assumptions.
Recording Unknown protects volume accounting and makes feed-quality problems visible.

Discussion: If your feed supplies an aggressor flag and synchronized bid/ask quotes, do you trust one as authoritative, or do you log disagreements for later analysis?

Disclosure: This article was prepared with AI assistance. The C# excerpt is illustrative and was not tested against a live market-data feed. Educational content only; not trading advice.

Building a Volume Profile Indicator From Raw Market Data in C#

ICF Market LTD — Wed, 30 Sep 2026 16:46:35 +0000

Building a High-Performance Volume Profile in C

Most charting platforms display volume as a single bar beneath each candle, showing how much trading activity occurred during a given time interval.

A Volume Profile asks a different question:

How much volume traded at each price?

Instead of grouping volume by time, a Volume Profile groups it by price. The result is a histogram that highlights the price levels where the market concentrated most of its activity, as well as the areas through which price moved relatively quickly.

The basic idea is simple.

Building a Volume Profile correctly from raw trade data — while keeping it efficient enough for real-time updates — is a much more interesting engineering problem.

This article presents a practical architecture for implementing one in C#, with a focus on:

Price indexing
Trade classification
Point of Control (POC)
Value Area calculation
Incremental updates
Rendering performance

Represent Prices as Integer Ticks

A first implementation might use a dictionary like this:

Dictionary<double, long> volumeByPrice;

This is convenient, but using floating-point prices as identity keys is unnecessary and can introduce subtle problems.

Suppose an instrument has a minimum price increment, or tick size, of 0.25. Prices such as:

already belong to a discrete integer grid.

Instead of storing the price itself, convert each price to a tick index:

static long PriceToTick(double price, double tickSize)
{
    return checked(
        (long)Math.Round(
            price / tickSize,
            MidpointRounding.AwayFromZero
        )
    );
}

The price is now represented by an integer.

For example, with a tick size of 0.25:

5234.00 -> 20936
5234.25 -> 20937
5234.50 -> 20938

In production code, if the trading platform provides its own canonical price-rounding utilities, use those instead of introducing a separate rounding convention.

The important principle is that price identity should be based on ticks rather than floating-point equality.

Start with Correctness Before Optimizing Storage

Once prices are represented as integer ticks, a dictionary becomes a much safer and clearer starting point.

First, define the possible aggressor sides:

enum AggressorSide
{
    Buy,
    Sell,
    Unknown
}

Then define the information stored at each price level:

sealed class ProfileLevel
{
    public long TotalVolume;
    public long BuyVolume;
    public long SellVolume;
    public long UnknownVolume;
    public int TradeCount;
}

The profile can initially be stored as:

readonly Dictionary<long, ProfileLevel> levels = new();

Updating the profile for each incoming trade is straightforward:

void OnTrade(
    double price,
    long volume,
    AggressorSide side,
    double tickSize)
{
    long tick = PriceToTick(price, tickSize);

    if (!levels.TryGetValue(tick, out ProfileLevel? level))
    {
        level = new ProfileLevel();
        levels[tick] = level;
    }

    level.TotalVolume += volume;
    level.TradeCount++;

    switch (side)
    {
        case AggressorSide.Buy:
            level.BuyVolume += volume;
            break;

        case AggressorSide.Sell:
            level.SellVolume += volume;
            break;

        default:
            level.UnknownVolume += volume;
            break;
    }
}

A Dictionary<long, ProfileLevel> is a good correctness-first implementation.

If profiling later shows that dictionary lookup overhead is significant, the storage layer can be replaced with an offset array, chunked array, or another contiguous structure without changing the rest of the profile logic.

That decision should come from measurement rather than assumption.

Where Do `BuyVolume` and `SellVolume` Come From?

This is an important detail.

A trade does not universally arrive with a perfect buyer-initiated or seller-initiated label. Depending on the data feed and trading platform, the aggressor side may need to be inferred from market context.

A common approach is to compare the execution price with the current bid and ask.

A trade executing at or near the ask can be classified as buyer-aggressed, while a trade executing at or near the bid can be classified as seller-aggressed.

Trades occurring between the quotes may require a fallback rule or may simply remain classified as Unknown.

The exact classification method is feed- and platform-dependent.

For this reason, the Volume Profile itself and the buy/sell classification logic should be treated as separate concerns.

Total volume can still be calculated correctly even when aggressor classification is unavailable.

Point of Control

Once volume has been accumulated by price, calculating the Point of Control (POC) is conceptually simple.

The POC is the price level with the highest accumulated volume.

A full implementation could calculate it by scanning every level:

POC = level with maximum TotalVolume

However, a live profile usually does not need to scan the entire histogram after every trade.

When a trade updates one price level, compare that level's new volume with the currently cached POC volume.

If the updated level becomes larger, update the cached POC.

This makes normal POC maintenance effectively constant-time per trade update.

Define Tie-Breaking Explicitly

One small detail matters: ties.

If two price levels contain exactly the same volume, the implementation should use a deterministic tie-breaking rule.

Possible approaches include selecting:

The lower price
The higher price
The level closest to another reference point

The specific choice is less important than defining the behavior explicitly.

Undefined tie behavior can cause the POC to appear to jump unpredictably between price levels.

Value Area Is More Complicated

The Value Area is typically defined as a contiguous region around the POC containing a configurable fraction of the profile's total volume — commonly around 70%.

However, there is an important implementation detail:

Different platforms may use slightly different Value Area expansion conventions.

Some implementations compare one price level at a time. Others compare groups or pairs of levels. Tie-handling rules may also differ.

If the objective is exact parity with another trading platform, its documented Value Area convention should be reproduced exactly.

For this example, we will use a simple contiguous one-level expansion rule.

The process is:

Start at the POC.
Look at the next available price level above and below the current Value Area.
Compare their volumes.
Add whichever level contains more volume.
Continue until the target percentage of total volume has been reached.

First, define a helper method:

static long VolumeAt(
    IReadOnlyDictionary<long, ProfileLevel> levels,
    long tick)
{
    return levels.TryGetValue(tick, out ProfileLevel? level)
        ? level.TotalVolume
        : 0L;
}

Then calculate the Value Area:

static (long Low, long High) ComputeValueArea(
    IReadOnlyDictionary<long, ProfileLevel> levels,
    long pocTick,
    long minTick,
    long maxTick,
    long totalVolume,
    double valueAreaFraction = 0.70)
{
    double targetVolume = totalVolume * valueAreaFraction;

    long low = pocTick;
    long high = pocTick;

    long accumulated = VolumeAt(levels, pocTick);

    while (accumulated < targetVolume &&
           (low > minTick || high < maxTick))
    {
        long volumeAbove =
            high < maxTick
                ? VolumeAt(levels, high + 1)
                : -1;

        long volumeBelow =
            low > minTick
                ? VolumeAt(levels, low - 1)
                : -1;

        if (volumeAbove >= volumeBelow)
        {
            high++;

            if (volumeAbove > 0)
                accumulated += volumeAbove;
        }
        else
        {
            low--;

            if (volumeBelow > 0)
                accumulated += volumeBelow;
        }
    }

    return (low, high);
}

This algorithm is intentionally simple.

It produces a contiguous Value Area, but it should not be treated as a universal market-profile standard.

The important engineering decision is to define the chosen convention explicitly and test it against known profiles.

Implementation Note: Sparse Profiles and Zero-Volume Ties

An important edge case arises in sparse volume profiles, where adjacent price levels may contain no traded volume.

In the simplified implementation above, the condition volumeAbove >= volumeBelow favors upward expansion whenever both sides have equal volume, including when both are zero. As a result, the Value Area boundaries can depend on the tie-breaking convention rather than solely on the distribution of traded volume.

For example, consider a profile with 1,000 contracts at tick 100 (POC), 500 at tick 98, 40 at tick 103, and 460 at tick 90. With a 70% target, the current implementation produces a Value Area from ticks 98 to 103, while a downward tie-breaking preference produces ticks 98 to 100.

Neither convention should be assumed to represent a universal standard. Production implementations should explicitly document their expansion and tie-breaking rules, consider alternatives such as look-ahead to the nearest non-empty levels, and validate the resulting VAH and VAL against sparse-profile test cases and the target platform's calculation convention.

The Real Performance Problem: Value Area Updates

The POC is relatively easy to maintain incrementally.

Value Area is different.

Every trade changes the total profile volume, and any change to a price bucket can potentially affect where the Value Area boundaries should be located.

Therefore, the following optimization is unsafe:

Only recompute Value Area when the POC changes.

The POC can remain at exactly the same price while changes in the surrounding volume distribution cause the Value Area High (VAH) or Value Area Low (VAL) to move.

A more practical architecture is to mark the Value Area as dirty whenever the profile changes.

bool valueAreaDirty = false;

void OnProfileChanged()
{
    valueAreaDirty = true;
}

Instead of recalculating the Value Area after every individual trade, recompute it at a controlled cadence.

For example:

Trade arrives
    |
    +--> Update price bucket
    |
    +--> Update cached POC if necessary
    |
    +--> Mark Value Area dirty


Every 100–250 ms
    |
    +--> If Value Area is dirty
            |
            +--> Recompute VAH / VAL
            |
            +--> Clear dirty flag

The exact interval depends on the application.

A research tool, historical-profile calculator, execution interface, and visual chart indicator may all have very different latency requirements.

The important distinction is between:

Data accuracy

and

Visual refresh frequency

The underlying volume buckets can update on every incoming trade, while more expensive derived values are refreshed at a controlled cadence.

A final full recomputation can also be performed when a session or profile is finalized.

Dictionary or Array?

Once the implementation is working correctly, the storage layer can be benchmarked.

A dictionary offers several advantages:

It handles expanding price ranges naturally.
It requires relatively little memory-management code.
It is easy to reason about.
It avoids allocating storage for unused price levels.

For many instruments, the number of active price levels within a single profile is modest enough that a dictionary is perfectly acceptable.

If profiling shows that dictionary lookup overhead is actually significant, an offset array can eliminate hashing entirely.

Conceptually:

arrayIndex = tickIndex - baseTick

The main challenge is expansion in both directions.

Repeatedly reallocating and copying a large array whenever the session reaches a new high or low can eliminate much of the theoretical performance benefit.

Two possible alternatives are:

Over-allocating storage in blocks
Using a chunked or page-based layout, with each block containing a fixed number of price levels

Again, the correct choice depends on measurement.

The fastest data structure on paper is not necessarily the fastest overall system once resizing, memory allocation, cache behavior, and implementation complexity are taken into account.

Keep Computation Separate from Rendering

The profile engine should understand:

Price ticks
Volume
Trade count
Aggressor classification
POC
Value Area

It should know nothing about pixels.

Rendering is a separate problem.

A renderer needs to determine:

Which price levels are currently visible
How much horizontal space is available
How volume maps to bar width
When the viewport has changed

Keeping computation and rendering separate provides several benefits.

The same profile model can support:

A classic horizontal Volume Profile histogram
A heatmap
A footprint-style visualization
A non-visual analytics component

This separation also prevents expensive visual operations from creeping into the market-data processing path.

If market-data processing and rendering occur on different execution contexts or threads, expose a stable snapshot of the profile state or use a short, well-defined synchronization strategy.

The renderer should not iterate over mutable profile state while that state is simultaneously being updated.

Measure Before Optimizing

For a live indicator, useful performance metrics include:

Average processing time per trade
Worst-case processing time
Allocations per update
Value Area recomputations per second
Number of active price levels
Render time per frame
Time spent waiting on synchronization

Without measurements, it is easy to spend hours replacing a dictionary that was never the actual bottleneck.

In many real-time charting systems, the larger performance problems come from:

Rendering overhead
Unnecessary object allocation
Excessive synchronization
Repeated calculation of derived values

These can create more performance problems than the initial volume accumulation itself.

A useful engineering order is:

Correctness first.

Instrumentation second.

Optimization third.

Final Architecture

A clean implementation naturally separates into three distinct layers.

1. Ingestion Layer

The ingestion layer receives trades and is responsible for:

Normalizing prices to integer ticks
Classifying aggressor side where possible
Updating the appropriate volume buckets

2. Profile Layer

The profile layer manages derived state, including:

Point of Control
Total profile volume
Value Area High
Value Area Low
Periodic Value Area recomputation

3. Rendering Layer

The rendering layer consumes a stable representation of the profile state and converts it into pixels.

It handles visual concerns such as:

Visible price ranges
Histogram dimensions
Bar scaling
Viewport changes
Frame rendering

Keeping these three layers separate makes the system easier to:

Test
Benchmark
Maintain
Optimize
Extend

It also allows the underlying profile engine to remain independent of any particular visualization method.

Discussion

If you've built a live Volume Profile or a similar market-microstructure tool, how do you handle Value Area recomputation?

Do you periodically recompute it from the full profile, maintain a more sophisticated incremental structure, or use another approach entirely?

I'm particularly interested in implementations that keep the data model simple while still performing well under high message rates.

DEV Community: ICF Market LTD

NinjaTrader Tick Replay: What Historical Order Flow Really Contains

What Tick Replay changes

The key limitation: Last events are not full quote history

A minimal NinjaScript Last-event example

Three traps that distort historical delta

1. Using real-time bid/ask helpers for historical trades

2. Confusing calculation frequency with data availability

3. Treating reconstructed data as backtest-quality execution data

A practical checklist before you trust a chart

Key takeaways

Official NinjaTrader references

Classifying Aggressor Side in Order Flow: Quote Rule vs. Tick Rule

What an aggressor-side label actually means

Two common classification methods

1. Quote rule: compare the trade with the spread

2. Tick rule: infer from the previous trade price

C# example: preserve an Unknown state

What should happen to unknown volume?

Test the data pipeline, not just the chart

Key takeaways

Building a Volume Profile Indicator From Raw Market Data in C#

Building a High-Performance Volume Profile in C

Represent Prices as Integer Ticks

Start with Correctness Before Optimizing Storage

Where Do BuyVolume and SellVolume Come From?

Point of Control

Define Tie-Breaking Explicitly

Value Area Is More Complicated

Implementation Note: Sparse Profiles and Zero-Volume Ties

The Real Performance Problem: Value Area Updates

Dictionary or Array?

Keep Computation Separate from Rendering

Measure Before Optimizing

Final Architecture

1. Ingestion Layer

2. Profile Layer

3. Rendering Layer

Discussion

Where Do `BuyVolume` and `SellVolume` Come From?