Aging-Aware Passive-Order Timeout Frontier Slippage Playbook

2026-03-11 · finance

Aging-Aware Passive-Order Timeout Frontier Slippage Playbook

Date: 2026-03-11
Category: research
Scope: Live execution where passive posting is default, but forced completion deadlines exist


1) Why this topic matters

A common production failure is simple:

This creates a hidden slippage tax: over-wait + panic-cross.

Most routers use fixed TTL (e.g., cancel after N seconds). In reality, optimal timeout is state-dependent and should follow a dynamic frontier, not a single constant.


2) Core framing

For one passive child order, there are three competing outcomes before we decide to cross:

  1. Fill (good if markout is healthy)
  2. Adverse regime switch (quote fade / micro-trend against us)
  3. No event yet (we keep waiting)

Decision variable: timeout horizon (\tau).

Goal: choose (\tau) minimizing expected all-in execution cost, including tail risk.


3) Minimal competing-risk model

Let:

Then:

[ P_{fill}(\tau|x)=\int_0^{\tau} S(t|x)\lambda_f(t|x)dt ]

[ P_{adv}(\tau|x)=\int_0^{\tau} S(t|x)\lambda_a(t|x)dt ]

[ P_{none}(\tau|x)=S(\tau|x) ]

Expected cost of using timeout (\tau):

[ C(\tau|x)=P_{fill}C_{fill}+P_{adv}C_{adv}+P_{none}C_{cross}(\tau) ]

where:

Control objective (tail-aware):

[ \tau^* = \arg\min_{\tau \in \mathcal{T}} \left(\mathbb{E}[C(\tau|x)] + \eta,CVaR_{95}(C(\tau|x))\right) ]


4) What makes the timeout frontier move

Timeout should shorten when:

Timeout can lengthen when:

Interpretation: timeout is a function (\tau^*(x)), not a global constant.


5) Feature set (production-practical)

State vector (x) examples:

A useful split:


6) Calibration recipe

Offline (daily/weekly)

  1. Build child-order lifecycle dataset with right-censoring handled explicitly.
  2. Fit competing-risk hazards:
    • baseline: piecewise-constant hazards by age bucket,
    • advanced: Cox / gradient boosting hazard with interactions.
  3. Calibrate (C_{cross}(\tau)) from realized aggressive fills conditional on state and urgency.
  4. Validate:
    • reliability of (P_{fill}(\tau)),
    • reliability of adverse-event probability,
    • cost-quantile calibration (q90/q95).

Online (intraday)


7) Online controller policy

At each control tick (e.g., 100–300ms):

  1. Enumerate candidate (\tau) values (e.g., {150, 300, 500, 800, 1200} ms).
  2. Score expected + tail cost for each candidate.
  3. Select (\tau^*) with constraints:
    • participation cap,
    • deadline feasibility,
    • risk budget,
    • venue throttles.
  4. If current order age (\ge \tau^*), cancel/replace or cross according to urgency tier.

Urgency tiers:


8) Monitoring and kill-switches

Track continuously:

Auto fallback triggers:

Fallback mode: fixed conservative timeout + bounded aggression ladder.


9) Backtest / replay experiment design

Use event replay with true order-book event time (not bar aggregates).

Compare:

Report:

Promotion criterion: tail reduction + completion stability, not just mean IS improvement.


10) Implementation checklist


11) References


One-line takeaway

A passive order should not die at a fixed age; it should expire on a state-aware timeout frontier that balances fill odds, adverse hazard, and completion pressure in real time.