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 evaluation
OBSERVE / t₀REVISIT / t₀ + hHORIZONInitial depth at fixed pricesThe initial cohort, later
The arrival questionConceptual illustration

My 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.
Research architecture Conceptual illustration
  1. 01Observe

    Read-only public feeds

  2. 02Reconstruct

    Deterministic replay + validity checks

  3. 03Measure

    Initial quantity at fixed prices

  4. 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.

Available-on-Arrival Depth · Laith Masri EngTech TMIET