Execution algo footprints: patterns are evidence, not identity
An execution algo footprint is a repeated pattern in trades or book events that is consistent with a parent order being split into child orders. Regular timing, recurring size, one-sided pressure, or replenishment can support a hypothesis. The pattern does not identify the trader or prove which algorithm produced it.
- Observation
- Trades, quotes, depth, and order events
- Output
- A scored hypothesis with alternatives
- Main limit
- Different causes can create the same pattern
Key Takeaways
- A footprint is an inference from event patterns, not a participant label.
- Trade-only data cannot reconstruct queue position or hidden quantity.
- OrderID and MBO data improve event linkage but remain anonymous.
- A useful detector reports false-positive conditions beside the score.
Observable patterns
A detector may measure inter-trade intervals, size repetition, signed-volume persistence, price-level replenishment, participation stability, and changes around a deadline. These features can be combined, but each also has ordinary market explanations.
| Observed pattern | Execution-algo hypothesis | Other explanation |
|---|---|---|
| Regular time gaps | Time-sliced child orders | Scheduled liquidity or reporting batches |
| Stable share of volume | POV participation | A broad set of unrelated traders |
| Repeated displayed size | Iceberg replenishment | Separate orders using common lot sizes |
| Persistent one-sided delta | Parent-order pressure | News-driven directional trading |
Data changes what can be claimed
OHLCV bars can show only coarse persistence. Tick trades add timing and size. Bid and ask quotes support spread and trade-direction rules. Market by Price gives aggregate depth. Market by Order adds anonymous order identifiers and queue detail. A page or indicator should name the highest data level it actually receives.
Footprint charts may use proxy classification
TradingView documents that its volume footprint categorizes volume from intrabar price direction and may use coarser historical intrabars as data availability changes. That is a useful visualization contract, but it is not the same as exchange-provided aggressor flags or a full historical MBO feed.
Build a transparent proxy study
A NinjaScript indicator prototype can calculate explicitly named features from the data supplied by NinjaTrader. The study should expose thresholds, minimum sample sizes, missing-data behavior, and competing explanations. Pineify can generate the code, but it does not supply or license the required order-flow feed.
Specify a proxy before generating NinjaScript
Name the available feed, features, window, threshold, missing-data rule, and false-positive cases. Pineify can create an editable single-file NinjaScript Indicator or Strategy. Validate its data contract and behavior inside NinjaTrader.
Sources and verification
This page is educational and does not provide investment advice. The methods described are diagnostics or estimates, not trading signals. Results depend on data quality, sampling, market structure, and model assumptions.