Tick Bars: Build Candles from an Exact Trade Count

Practical promise. Build and audit bars that close after exactly N eligible trade records, including deterministic ordering, session resets, and partial-tail handling.

Tick bars replace the clock with an event counter. A complete 12-tick bar contains 12 accepted trade records whether those records arrived in one second or several minutes. This can make record count uniform across bars, but it does not make volume, liquidity, volatility, or information uniform.

The central engineering question is simple to state and easy to implement incorrectly:

Has the current session-local bar accumulated exactly the configured number of eligible trade records?

The word eligible carries most of the production risk. A correction counted as a fresh execution, a duplicate record, an undocumented odd-lot filter, or an unstable tie order changes every later boundary.

What counts as one tick?

In this package, one tick means one pre-cleaned execution record accepted by an upstream policy. It does not mean one share or one price change. A 10-share record and a 10,000-share record each add one to the bar count if both are eligible.

Before calling the constructor, the pipeline must have:

• resolved cancels and corrections according to the source protocol;
• removed duplicates while retaining an audit trail;
• applied a documented sale-condition and odd-lot policy;
• ordered equal timestamps using the source sequence rule;
• assigned an explicit session key.

This separation is intentional. FINRA's reporting guidance treats execution time, quantity, and cancel/correction reporting as distinct concerns; a generic bar function cannot safely infer all of those rules (FINRA Trade Reporting FAQ). NYSE Daily TAQ likewise exposes timestamp and sequence information and documents historical timestamp-precision changes (NYSE Daily TAQ v4.3, sections 1.5.3–1.5.5).

The exact contract

The constructor receives one symbol and one currency in authoritative array order. Timestamps must be valid UTC strings and globally nondecreasing. Equal timestamps are allowed because the caller has already applied the source sequence rule; the constructor preserves their order and never sorts.

Two configuration fields control membership:

Session keys are explicit. When a key changes, the current bar is emitted as session_end or discarded, then state resets before the first trade of the new session. A session may not disappear and later reappear in the same call.

The output includes OHLC, total quantity, exact reported notional, trade count, session, first/last trade IDs, and one of three closure reasons: threshold, session_end, or stream_end.

Mathematics: equality is the rule

For open bar B_j, count the admitted records:

$$T_j=\sum_{i\in B_j}1.$$

Close when:

$$T_j=N,$$

where N is the positive integer targetTicks.

There is no threshold overshoot in this algorithm. Every accepted record increases the state by exactly one, so a valid counter reaches N exactly. The record that makes T_j=N closes the current bar; the following record opens the next one.

After membership is fixed:

$$O=p_1,\quad H=\max_i p_i,\quad L=\min_i p_i,\quad C=p_T,$$ $$V=\sum_i v_i,\qquad D=\sum_i p_i v_i.$$

D is summed record by record. It is not reconstructed from a rounded average price.

Work the boundary by hand

Use targetTicks=3 and closePartial=true:

Bar 0 is O/H/L/C = 100/101/99/99, volume is 45, and dollar value is:

$$100(10)+101(20)+99(15)=4{,}505.$$

Bar 1 is 100/102/100/101, volume is 65, and dollar value is 6,550. E07 becomes a one-record stream_end bar with dollar value 515. With closePartial=false, E07 produces no output.

The diagram shows the key dependency: decide membership first, then calculate OHLCV.

Causal construction sequence

Only the current and earlier records affect a closure. Execution time validates ordering and labels bounds; arrival and availability times are separate dimensions that a live point-in-time system should preserve.

The static boundary visual isolates the three policies most likely to drift:

Notice that a session boundary never carries an unfinished count into the next session.

Implementation walkthrough

The Python implementation and TypeScript implementation follow the same sequence:

1. Validate targetTicks as a positive integer and closePartial as a boolean.
2. Validate required fields, finite positive numbers, unique IDs, one instrument/currency, chronological time, and contiguous sessions.
3. Preserve the supplied order; never sort tied timestamps.
4. Flush or discard a session tail, then reset.
5. Append one whole record and close only when count equals the target.
6. Flush or discard the stream tail.

Both implementations are O(n) in the number of trades. The readable version stores at most one open bar, so working memory is O(N). A streaming production version can retain scalar accumulators while preserving first/last lineage.

Explore the 240-trade lab

Open the Tick Bars interactive playground. Its deterministic synthetic tape contains 240 trades across two sessions—enough to reveal repeated boundaries, activity changes, and session behavior without redistributing licensed transaction data.

Use it in this order:

1. Inspect the complete 12-trade canonical bar shown on load.
2. Step backward and forward across its equality boundary.
3. Change targetTicks and watch all membership recompute from trade one.
4. Filter to either session and verify the reset.
5. Run to the end with a target that does not divide 120 and inspect stream_end.

The NYSE specification states that historical Daily TAQ access is licensed and subject to product agreements, so a named historical trade tape is not included here without verified redistribution rights (NYSE Daily TAQ v4.3, preface and section 1). Synthetic data is the safer evidence choice for this mechanical lesson.

Tests that expose policy drift

The shared 240-trade fixture produces 20 complete bars at targetTicks=12: ten per session. Python and TypeScript must match the same stored expected output exactly.

Additional tests cover:

• the seven-record worked example with partial tails emitted and dropped;
• integer-only threshold validation;
• NaN, infinity, nonpositive numbers, and reversed timestamps;
• duplicates and mixed instruments;
• stable input order for equal timestamps;
• rejection of a session that reappears;
• session-end partial closure and reset.

These checks establish definition-level correctness. They do not establish that 12 is a useful market parameter or that any downstream strategy is profitable.

Common failure modes

Tick bars versus nearby clocks

Choose the clock whose invariant matches the downstream question. Greater complexity does not imply greater validity.

Summary and next topic

A reliable tick bar is defined as much by its data contract as by its counter. Specify eligibility, preserve source order, close at exact equality, reset by session, and make the partial-tail decision visible. Keep lineage in the output so every candle can be reconstructed.

Continue with Volume Bars, where a crossing trade can overshoot the target and forces a different boundary discussion.

Primary references and source roles

Source versions, jurisdictions, supported claims, and limitations are recorded in REFERENCES.md. The canonical factual and algorithmic contract is README.md.