Research / Quant / Software · Research in progress
Available-on-Arrival Depth
Research software for studying how displayed liquidity changes between observation and a later arrival horizon.
- My role
- Independent researcher and developer
- Period
- 2026 – present
- Source
- Private implementation · public overview
The question
How much of the depth visible now is still there when an order might arrive?
Python · Market microstructure · Event replay · Statistical evaluationMy contribution
Built the research pipeline connecting public-feed reconstruction, conservative depth accounting, point-in-time features, and chronological evaluation.
01 / problem
Displayed depth at arrival
A displayed order book describes what can be observed at a moment in time. The quantity at a price can change before a hypothetical order arrives. AOAD asks a deliberately narrower question than whether a trade would fill: what remains of an initial depth cohort at the same prices?
The research investigates whether recent activity on another venue adds predictive information after accounting for the local book and common conditions.
02 / role
My contribution
I developed the software and evaluation workflow around that question: reconstruct observations, define the target, build features using information available at the time, and compare models under explicit chronological boundaries. This is independent research in progress.
03 / architecture
Research pipeline
- Read-only public-feed collection and normalization preserve the distinction between raw observations and derived events.
- Deterministic replay reconstructs the book and marks intervals that cannot support a valid comparison.
- Cohort accounting follows initial quantity at fixed prices; later additions do not replenish that initial cohort.
- Point-in-time features feed chronological model comparisons, followed by evaluation, diagnostic checks, and traceable reports.
- 01Observe
Read-only public feeds
- 02Reconstruct
Deterministic replay + validity checks
- 03Measure
Initial quantity at fixed prices
- 04Compare
Point-in-time features + chronological evaluation
Software checks establish accounting and timing behaviour. Market inference requires a separate, valid empirical evaluation.
04 / decisions
Reconstruction and target definition
The project separates exchange-specific message handling from the research calculation. A change in feed interpretation should be visible at that boundary, rather than silently changing a result downstream. Invalid reconstruction intervals are excluded instead of being treated as usable observations.
The availability target also stays separate from an explanation of why depth disappeared. Public level-2 data cannot reveal an individual order's identity or prove whether a removal was cancellation, execution, or something else.
05 / evaluation
Testing and evaluation
Synthetic experiments provide controlled conditions in which to inspect accounting, timing, model comparison, and placebo behavior. The repository also includes unit, property, integration, and hand-audited replay checks. Those are evidence about the software's behavior, with a different scope from evidence about a market effect.
Bounded public-feed validation exercises collection, reconstruction, and the time horizons the observations can support. Chronological separation and placebo checks are part of the research design; they do not turn synthetic recovery or a short capture into a demonstrated live-market advantage.
06 / limitations
Limitations
- Displayed depth-cohort availability is not individual-order survival, queue position, or a counterfactual fill.
- Collector receipt timing is not physical transmission latency or proof that exchange clocks are synchronized.
- Predictive association does not establish structural causality, provider intent, profitability, or a production routing policy.
07 / next
Next steps
The next step is broader, independently separated public-data evaluation under a fixed procedure, with timing eligibility and data provenance kept explicit. The useful outcome may be a better bound on what the available data can support, even if a proposed signal does not survive those tests.
Private implementation
Source code and research data are private. This case study is the public overview.
Public overview reviewed 8 September 2026.