Fill-Hazard + Markout Coupled Slippage Controller Playbook

2026-02-25 · finance

Fill-Hazard + Markout Coupled Slippage Controller Playbook

Date: 2026-02-25
Category: research (quant execution)

TL;DR

Most execution stacks model impact and fill probability separately, then wonder why live slippage tails explode.
Use a coupled controller: estimate (1) queue fill hazard, (2) adverse markout risk after fill, and (3) delay/opportunity cost if not filled, then choose passive vs aggressive action under a shared tail-budget.


1) Why this matters in production

For a buy order, passive quotes can look cheap in backtests but become expensive when:

If we optimize for spread capture alone, we buy false comfort.


2) Core decomposition

At decision time (t), for action (a_t):

[ \mathbb{E}[C_t(a_t)] = C^{impact}_t(a_t) + p^{fill}_t(a_t),C^{markout}_t(a_t) + (1-p^{fill}_t(a_t)),C^{delay}_t(a_t) ]

Where:

Risk-aware execution objective:

[ \min_{a_t}; \mathbb{E}[C_t(a_t)] + \lambda,\mathrm{Var}(C_t(a_t)) \quad \text{s.t.} \quad \Pr(C_t(a_t)>B_t) \le \delta_t ]


3) Modeling block A — Fill hazard

Model queue fill as survival/hazard process:

[ h_t = \Pr(\text{fill in }[t,t+dt] \mid \text{not yet filled}, x_t) ]

Useful features:

Practical implementation:


4) Modeling block B — Adverse markout

Estimate expected adverse move conditional on fill:

[ M_{t,h} = \mathbb{E}[\text{sign}(side)\cdot (mid_{t+h}-fill_t) \mid \text{fill at }t, x_t] ]

Horizon set (h): 5s / 30s / 120s (or strategy-specific).

Feature candidates:

Heavy-tail handling:


5) Modeling block C — Delay/opportunity cost

When passive order misses, the parent schedule may become urgent.

Approximate delay cost:

[ C^{delay}_t \approx \alpha_t,\Delta t + \beta_t,\Delta POV + \gamma_t,\sigma_t\sqrt{\Delta t} ]

Interpretation:

This prevents the classic error: “passive now, panic later”.


6) Decision policy (passive ↔ aggressive switch)

Compute two candidate costs each cycle:

Switch if:

[ J^{passive}_t - J^{aggr}_t > \theta_t ]

Dynamic threshold (\theta_t) should tighten when:

Recommended action space (small but effective):

  1. Passive join (price = best bid/ask)
  2. Passive improve by 1 tick (limited)
  3. Partial marketable + residual passive
  4. Full marketable slice with hard cap

7) Regime state machine

Use a 4-state controller:

State transitions from composite signal:

In Red:


8) Vellab/KIS deployment blueprint

Data plane

Model services

Storage / observability

Must-have guards


9) Validation protocol (before real capital scaling)

Do not ship from average bps improvements alone.

Track at least:

A/B setup:

Success condition (practical):


10) Failure modes to watch

  1. Queue position mismeasurement → fake fill probabilities
  2. Label leakage in markout model → backtest mirage
  3. No latency accounting → stale control actions
  4. Tail budget ignored near close → forced panic execution
  5. Overcomplex policy → hard-to-debug behavior under stress

Keep policy interpretable; complexity should be in modeling, not hidden branching logic.


11) 10-day rollout plan


References (starting points)

The practical edge is coupling: fill hazard + markout + delay cost in one control loop. That is where slippage tails usually hide.