Dentro la slice: le tattiche sui child order tra scheduler ed exchange

Una traiettoria di Almgren-Chriss ti consegna un numero: vendi 4,2 BTC nei prossimi cinque minuti. Uno schedule VWAP ti consegna lo stesso tipo di numero con una giustificazione diversa. Nessuno dei due dice nulla su cosa succede dopo — se quei 4,2 BTC colpiscono il book come un singolo ordine marketable, restano al touch a raccogliere fee da maker, si nascondono dietro un display di 0,3 BTC, oppure vengono ripreziati undici volte inseguendo una quotazione che si sposta. Questo secondo livello decisionale è il livello tattico, e sui book crypto dominati dalle fee sposta regolarmente più PnL per slice della scelta dello scheduler sovrastante. I budget d'intervallo dello scheduler differiscono tra TWAP e un Almgren-Chriss ben calibrato di pochi bps di impatto sull'intero parent order; pagare fee da taker su slice che avresti potuto far da maker, o bruciare posizione in coda con repricing incauto, costa altrettanto per ora. Questo articolo riguarda il livello che tutti eseguono e che quasi nessuno mette per iscritto: la state machine che decide come ogni child order tocca il book.

Due livelli, un'interfaccia stretta

Market Microstructure in Practice di Lehalle e Laruelle (2a ed., 2018) formalizza ciò a cui converge ogni desk di esecuzione: un livello strategico (lo scheduler) che alloca la quantità nel tempo, e un livello tattico (il microtrader) che lavora ciascuna allocazione contro il book live. La separazione non è estetica — i due livelli vivono su clock diversi e dati diversi. Lo scheduler ragiona in minuti, consuma previsioni di volatilità e volume, e risolve un problema variazionale. Il livello tattico ragiona in millisecondi-secondi, consuma delta L2 e stime di coda, e risolve una sequenza di piccoli problemi di stopping.

L'interfaccia tra i due dovrebbe essere stretta. In discesa, per slice $k$:

• budget $q_k$ — la quantità da eseguire in questo intervallo (l'$n_k$ di Almgren-Chriss, o l'incremento della curva di volume di VWAP);
• finestra $\tau_k$ — la lunghezza della slice;
• urgenza — per Almgren-Chriss, il candidato naturale è $\kappa = \sqrt{\lambda\sigma^2/\eta}$, che già comprime avversione al rischio, volatilità e liquidità in un unico tasso; per uno scheduler VWAP è di solito una distanza di banda ("siamo all'1,8% dietro la curva target").

In risalita: fill con timestamp e fee, il residuo non eseguito, e lo shortfall di esecuzione a livello di slice misurato contro il mid di arrivo dell'intervallo. Quest'ultimo punto conta: il parametro d'impatto $\eta$ dello scheduler già prezza quanto dovrebbe costare domandare liquidità al tasso $q_k/\tau_k$. La descrizione dell'intero compito del livello tattico sta in una riga: realizzare fill a un costo migliore di quello implicato da $\eta$, senza far trapelare l'esistenza del parent order. Se lo shortfall misurato per slice batte costantemente il costo modellato, l'$\eta$ calibrato può scendere, lo scheduler accelera, e l'intero stack migliora. Se non riesci a misurare lo shortfall di slice separatamente dal costo dello schedule, non puoi calibrare nessuno dei due livelli — hai un solo numero sfocato e due manopole.

Anche la policy sul residuo fa parte del contratto. Quando una slice termina con quantità non eseguita, o il livello tattico la forza a completamento (incrociando il residuo — il default sotto urgenza da deadline) oppure la restituisce allo scheduler per la riamortizzazione sulle slice rimanenti (accettabile all'inizio di uno schedule a basso $\kappa$, velenoso vicino alla deadline dove la riamortizzazione si accumula silenziosamente in una slice finale enorme).

La scala di escalation: prima passivo, aggressivo per deadline

Il risultato più antico in quest'area è Harris (1998), "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2)): per un trader di liquidità che deve completare uno scambio entro una deadline, la strategia ottimale è dinamica — stare nel book con ordini limite finché il tempo è economico, ripreziare verso il mercato man mano che la deadline si avvicina, e incrociare alla fine. Ogni motore tattico in produzione è un discendente di questa forma: posta al touch, invecchia, fa escalation, incrocia. Ciò che gli schedule di fee moderni e la dinamica di coda aggiungono è l'aritmetica di esattamente quando scatta ciascuna transizione.

Il break-even per incrociare

Lavoro per unità, prezzi relativi al mid corrente, per un acquisto. Incrociare adesso costa metà spread più la fee da taker:

Postare al bid su una finestra $\tau$ si riempie con probabilità $p$; un fill guadagna il mezzo spread e paga la fee da maker $f_m$ (negativa se è un rebate). Nessun fill significa incrociare a fine finestra dopo che il prezzo si è, in media, mosso contro di te di $\delta(\tau) = E[\,\text{movimento avverso del mid} \mid \text{nessun fill}\,] > 0$ — strettamente positivo, perché non-fill e drift avverso sono lo stesso evento: il tuo bid non viene colpito quando il mercato si allontana da esso. Costo atteso del posting:

Postare batte incrociare se e solo se

dove $\Pi$ è il premio — l'intero round-trip che catturi facendo il maker invece del taker: lo spread più il differenziale di fee. È lo stesso break-even che governa l'intera economia maker-taker dell'esecuzione, ridotta a una singola slice.

Numeri, BTCUSDT perp: mid $100.000, spread di un tick s = \0,10$, fee stile VIP0 maker 2 bps / taker 5 bps, quindi$f_m = $20$,$f_t = $50$per BTC. Il premio$\Pi = 0,10 + 50 - 20 = $30,10 \approx 3$bps — nota che lo spread contribuisce sostanzialmente a nulla; sui major crypto stretti il premio *è* il differenziale di fee. Prendi 3$\sigma_{\text{day}} = $3{.}000$) e$\delta(\tau) \approx 0,6,\sigma_{\text{day}}\sqrt{\tau/86400}$ (lo 0,6 è un haircut da adverse selection che va calibrato, non preso per buono):

• $\tau = 10$ s: \delta \approx \19$, quindi$p^* = 19/49 \approx 0,39$. Posta solo se ti aspetti almeno un fill del 39% entro 10 secondi.
• $\tau = 60$ s: \delta \approx \47$, quindi$p^* = 47/77 \approx 0,61$.
• Con un rebate maker di 1 bp invece di una fee di 2 bps (f_m = -\10$):$\Pi = $60,10$, e la soglia a 10 s scende a$p^* \approx 0,24$.

Da qui emergono due fatti strutturali. Primo, $\delta$ cresce come $\sqrt{\tau}$ mentre $\Pi$ è costante, quindi $p^\*(\tau) \to 1$: la pazienza ha una scadenza rigida, e il timer di age-out non è un'euristica ma il punto d'incrocio di due curve — la tua $p(\tau)$ stimata (concava, che satura man mano che la coda davanti a te si svuota) contro $p^\*(\tau)$ (crescente). Secondo, il fee tier su cui tradi sposta fisicamente la scala. Un upgrade di tier che taglia le fee da taker rende le tue tattiche ottimali più aggressive — un accoppiamento che molti scoprono solo quando le loro statistiche di fill cambiano dopo un ri-tier VIP.

Cont e Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 2017; arXiv 2012), rendono questo rigoroso in un solo periodo: minimizzare il costo atteso di eseguire $S$ unità suddivise tra ordini a mercato e ordini limite (su una o più venue), con una penalità per lo shortfall. La soluzione a singola venue è esplicita e ha una struttura da newsvendor: la dimensione ottimale dell'ordine limite è guidata dalla distribuzione del deflusso di coda — posta dimensioni aggressivamente quando la coda davanti è piccola rispetto al deflusso atteso, e copri il rischio di coda con ordini a mercato. La loro estensione multi-venue è risolta per approssimazione stocastica ed è il nucleo intellettuale della logica di allocazione passiva di ogni smart order router. La lettura pratica per un motore tattico: la $p$ nel break-even sopra non è una costante — è una funzione della posizione in coda e del tasso di deflusso, motivo per cui il livello tattico deve consumare lo stimatore di posizione in coda come input di prima classe.

Il parametro di urgenza comprime l'intera scala. Un $\kappa$ alto dallo scheduler significa che il tempo caratteristico $\theta = 1/\kappa$ è breve: le finestre si restringono, $p^\*$ sale, e il motore salta direttamente all'incrocio — correttamente, perché lo scheduler ha già dichiarato che il rischio d'inventario domina il risparmio sulle fee. Un $\kappa$ basso allunga la fase passiva. Il livello tattico non dovrebbe mai ri-derivare l'urgenza dalla propria visione del mercato; quello è compito dello scheduler, e duplicarlo crea due controller in disaccordo.

Ripreziare senza bruciare la posizione in coda

Una volta postata, la quotazione si sposta. Inseguirla ingenuamente — cancella, riposta al nuovo touch, ripeti — è il modo in cui i motori tattici distruggono silenziosamente proprio quella probabilità di fill che giustificava il posting. La posizione in coda è un asset con un valore in dollari misurabile (Moallemi e Yuan, 2016, le mettono un prezzo: le posizioni di front-of-queue nei book FIFO liquidi valgono una frazione significativa dello spread), e ogni decisione di repricing è uno scambio: vendi la tua posizione in coda attuale, ne compri una in fondo a un livello di prezzo diverso. Lo scambio vale la pena solo quando il valore del nuovo livello supera quello del vecchio più i costi di messaggistica. Questo richiede di sapere cosa fa esattamente l'amend di ciascuna venue al tuo posto in fila — e la risposta è estremamente non uniforme.

CME Globex documenta la semantica più pulita: ridurre la quantità dell'ordine mantiene la priorità temporale; aumentare la quantità o cambiare il prezzo ti manda in fondo alla coda. Questo è il modello di riferimento — quantità-in-giù è gratis, tutto il resto è un ri-accodamento.

Binance spot storicamente offriva solo POST /api/v3/order/cancelReplace — un cancel-più-new dall'aspetto atomico ma esplicitamente non transazionale. Due modalità: STOP_ON_FAILURE (default — se la cancellazione fallisce, nessun nuovo ordine) e ALLOW_FAILURE (piazza comunque il nuovo ordine anche se la cancellazione fallisce — ciao, doppia esposizione accidentale). L'operazione può avere successo parziale, segnalato da HTTP 409, quindi il tuo OMS deve riconciliare entrambe le gambe indipendentemente; e il nuovo ordine inizia sempre una vita di coda nuova. Poi nel 2025 Binance ha lanciato Order Amend Keep Priority (PUT /api/v3/order/amend/keepPriority): riduci la quantità sul posto, mantieni la priorità temporale, a costo zero in termini di conteggio degli ordini non eseguiti. Semantica CME, quindici anni dopo — e solo la metà quantità-in-giù.

Binance USDT-M futures ha un vero endpoint di modifica (PUT /fapi/v1/order), ma leggi le note fini: solo ordini LIMIT, sia price che quantity devono essere inviati, e "gli ordini modificati verranno riordinati nella coda di matching" — la documentazione non promette alcuna conservazione della priorità nemmeno per pure riduzioni di quantità. Tratta ogni modifica dei futures come un reset di coda che ti fa risparmiare solo un messaggio e mantenere l'ID dell'ordine. Un dettaglio tagliente da conoscere: modificare un ordine GTX (post-only) a un prezzo che incrocerebbe fa cancellare l'ordine, non lo rifiuta mantenendolo — un'implementazione di peg che non controlla questo si auto-amend fuori dall'esistenza di tanto in tanto.

OKX espone POST /api/v5/trade/amend-order (newPx, newSz, con cxlOnFail per auto-cancellare in caso di fallimento dell'amend). È un singolo messaggio, preserva l'ID dell'ordine, e conferma in modo asincrono — sCode = 0 significa "richiesta accettata", e l'esito effettivo arriva sul canale degli ordini come amendResult. Ciò che la documentazione pubblica non specifica in modo evidente è il comportamento sulla priorità di coda. Non colmare quel vuoto documentale con ottimismo. Misuralo: posta due ordini marker a un livello tranquillo, riduci la size di uno tramite amend, e osserva quale si riempie per primo su qualche centinaio di prove. Finché non hai quei dati, l'assunzione conservativa — qualsiasi cambio di prezzo ti ri-accoda ovunque, la riduzione di quantità preserva la priorità solo dove esplicitamente documentato — è l'unica difendibile.

Le conseguenze operative:

1. Isteresi, non pegging. Riprezza solo quando il touch si è spostato più di una banda $b$ tick dal tuo prezzo in attesa. Dentro la banda, il drift è rumore e la tua posizione in coda vale più di un tick di miglioramento di prezzo. Una banda di partenza sensata è 1-3 tick scalati per la vol a breve orizzonte; la banda corretta rende il reprice marginale EV-neutro: $V_{\text{new}} - V_{\text{cur}} = c_{\text{msg}}$, con $V$ il valore di coda in stile Moallemi-Yuan e $c_{\text{msg}}$ il tuo prezzo ombra del rate-limit. Le operazioni di amend/cancel-replace consumano budget di rate degli ordini su entrambe le venue Binance; un motore tattico che pegga ogni tick affamerà il resto del tuo sistema di capacità di messaggistica.
2. Amend in giù, mai cancel-repost in giù. Quando lo scheduler taglia un budget di slice a metà volo (uno scheduler POV che vede il volume prosciugarsi, un re-solve di Almgren-Chriss dopo fill parziali), usa il percorso che preserva la priorità dove esiste. Questo è l'unico pasto gratis dell'intero livello.
3. Urgenza asimmetrica nel reprice. Ripreziare verso il mercato (inseguendo) azzera la tua coda a un prezzo peggiore — dovrebbe scattare solo dalla logica di escalation, sul suo timer. Ripreziare lontano (il mercato è venuto da te) è un regalo; prendilo solo tramite la banda passiva, perché il tuo livello attuale sta comunque per riempirsi.

Iceberg, display size, e cosa fa trapelare la tua intenzione

Il display size è la terza decisione, ed è uno scambio genuinamente a doppio taglio, non un pulsante di stealth gratuito. Il record empirico:

• Frey e Sandås ("The Impact of Iceberg Orders in Limit Order Books", working paper 2009; Quarterly Journal of Finance, 2017), su dati Xetra: gli ordini iceberg portavano il 9,3% del volume sottomesso e il 15,9% del volume eseguito, giravano a 12-20x la dimensione degli ordini limite ordinari, e — la battuta finale — quando altri partecipanti rilevano un iceberg, rispondono con ordini a mercato corrispondenti. La size nascosta, una volta dedotta, attrae flusso: la ricerca di liquidità latente funziona in entrambe le direzioni.
• Bessembinder, Panayides e Venkataraman ("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets", JFE 94(3), 2009), su Euronext Paris, dove gli ordini nascosti erano il 44% del volume campione: nascondere abbassa lo shortfall di esecuzione ma abbassa anche la probabilità di esecuzione completa e allunga il tempo di completamento. L'esposizione compra fill e li paga in impatto; l'opzione viene usata esattamente come predice la teoria — gli ordini aggressivi si espongono per attirare controparti, la size paziente si nasconde.
• Esser e Mönch ("The navigation of an iceberg", Finance Research Letters 4(2), 2007) trattano la peak size come un'ottimizzazione: un display più grande si riempie più velocemente, un display più piccolo fa trapelare meno, e l'ottimo è interno.

Prima la meccanica, perché vincola l'ottimizzazione: su praticamente ogni venue che supporta iceberg nativi (Binance spot via icebergQty, OKX via i suoi ordini algo iceberg), ogni ricarica del picco visibile entra in fondo alla coda a quel prezzo. Un iceberg non è quindi "un ordine con size nascosta" — è una sequenza di piccoli ordini, ciascuno che paga per intero l'attesa in coda, sparati automaticamente. Al break-even di fee sopra, questo conta: la $p$ effettiva per picco è la probabilità di fill in fondo alla coda, non quella della tua posizione originale. Le code profonde puniscono i picchi piccoli due volte — fill più lenti e più ricariche dal valore di adverse selection.

Poi il problema del segnale. Il metodo di rilevamento di Frey e Sandås è un monito: il loro rilevatore frequentista si aggancia ai due pattern più comuni di pigrizia implementativa — dimensione costante del picco e timestamp di ricarica identici a quelli del trade in esecuzione. Qualsiasi partecipante che esegue quel rilevatore (e sulle venue crypto, molti lo fanno — i metadati di matching proprietari dell'exchange lo rendono ancora più facile per il flusso colocato) ricostruisce la tua size nascosta in una manciata di ricariche. I vettori di leak, in ordine di frequenza con cui li vedo sul campo:

1. Display size costanti o tonde (0,5 BTC, ogni volta).
2. Ricarica istantanea e deterministica dopo l'esecuzione completa di un picco — la firma dello stesso timestamp.
3. Timer di escalation deterministici: incrocia esattamente a 30 s dentro ogni slice e il tape mostra un metronomo.
4. Latenza e banda di reprice fisse — la tua cadenza di amend è un'impronta digitale identificativa quanto le dimensioni dei tuoi ordini, argomento delle impronte digitali e identificazione del trader.

Il costo di essere rilevati non è ipotetico. Van Kervel e Menkveld ("High-frequency trading around large institutional orders", Journal of Finance 74(3), 2019) mostrano che gli HFT inizialmente si appoggiano contro i metaorder istituzionali — fornendo la liquidità che le tue tattiche passive consumano — per poi passare a tradare con l'ordine una volta che la sua persistenza rivela informazione, facendo back-running del residuo e aumentando materialmente il costo del parent. Le loro istituzioni hanno risposto bilanciando profitto speculativo contro rischio di rilevamento. Il tuo livello tattico è esattamente dove quel compromesso viene implementato: randomizza il display size (un uniforme 30-70% di una base scalata sulla vol funziona bene), fai jitter su ogni timer di ±20-30%, lascia occasionalmente attendere una ricarica, e non lasciare mai che due child order condividano una size, una fase del timer e un profilo di latenza. Nulla di tutto ciò costa qualità di fill misurabile; tutto ciò alza il floor di rumore per chiunque stia calibrando un rilevatore sul tuo flusso.

Un motore tattico minimale

L'intero livello sopra si comprime in una piccola state machine per slice: IDLE → POSTED → (loop di reprice) → CROSSING → DONE, con il gate del break-even all'ingresso, una banda di isteresi mentre è postato, ed escalation da deadline. La versione sotto è deliberatamente minimale — nessun adapter di venue, nessuna gestione degli iceberg — ma è event-driven e priva di effetti collaterali, quindi si inserisce direttamente nel simulatore queue-aware di livello 4 della scala di simulazione dei fill: il simulatore chiama on_tick/on_fill, e interpreta le azioni come post → GTX/post-only, cross → IOC, cancel_replace/amend_down → la semantica della venue dalla matrice sopra.

import math
from dataclasses import dataclass
from enum import Enum, auto

class State(Enum):
    IDLE = auto(); POSTED = auto(); CROSSING = auto(); DONE = auto()

@dataclass
class Fees:
    maker: float          # $ per unit; negative = rebate
    taker: float          # $ per unit

@dataclass
class Cfg:
    tick: float
    sigma_1s: float       # $ per sqrt(second), from your live vol estimator
    adverse_frac: float = 0.6   # E[adverse move | no fill] ~ 0.6 * sigma; calibrate
    reprice_band: float = 2.0   # ticks of touch drift tolerated before repricing
    escalate_frac: float = 0.7  # cross the remainder at this fraction of the window

class SliceTactic:
    """One instance per scheduler slice. Drive it from a fill simulator or OMS."""

    def __init__(self, side: str, qty: float, window: float, fees: Fees, cfg: Cfg):
        self.side, self.qty, self.window = side, qty, window
        self.fees, self.cfg = fees, cfg
        self.filled, self.state, self.px, self.t0 = 0.0, State.IDLE, None, None

    def p_star(self, spread: float, tau: float) -> float:
        """Break-even fill probability for posting over a window tau."""
        delta = self.cfg.adverse_frac * self.cfg.sigma_1s * math.sqrt(tau)
        prize = spread + self.fees.taker - self.fees.maker
        return delta / (prize + delta)

    def p_fill(self, queue_ahead: float, drain: float, tau: float) -> float:
        """Crude queue-drain estimate; swap in your calibrated fill model."""
        if drain <= 0: return 0.0
        return min(1.0, drain * tau / max(queue_ahead + self.qty, 1e-9))

    def on_tick(self, t, bid, ask, queue_ahead, drain):
        if self.state == State.DONE: return []
        if self.t0 is None: self.t0 = t
        left = self.qty - self.filled
        elapsed, remain = t - self.t0, self.window - (t - self.t0)
        touch = bid if self.side == "buy" else ask

        if elapsed >= self.cfg.escalate_frac * self.window and left > 0:
            self.state = State.CROSSING          # deadline: pay up, finish
            return [("cross", left)]

        if self.state == State.IDLE:
            if self.p_fill(queue_ahead, drain, remain) >= self.p_star(ask - bid, remain):
                self.state, self.px = State.POSTED, touch
                return [("post", touch, left)]    # GTX / post-only
            self.state = State.CROSSING           # posting is -EV here
            return [("cross", left)]

        if self.state == State.POSTED:
            if abs(touch - self.px) / self.cfg.tick > self.cfg.reprice_band:
                self.px = touch                   # hysteresis breached:
                return [("cancel_replace", touch)]  # accept the queue reset
        return []

    def on_fill(self, t, fill_qty):
        self.filled += fill_qty
        if self.filled >= self.qty - 1e-9:
            self.state = State.DONE
            return [("slice_done", self.filled)]
        return []

    def on_budget_cut(self, new_qty):
        """Scheduler revised the slice down: amend-down keeps queue priority
        where documented (CME, Binance spot amend/keepPriority)."""
        self.qty = new_qty
        left = new_qty - self.filled
        return [("amend_down", left)] if left > 0 else [("cancel",)]

Tre avvertenze oneste. p_fill qui è un rapporto segnaposto — in produzione dovrebbe essere il modello a bucket, calibrato dal vivo, dell'articolo sulla simulazione dei fill, perché l'intero gate post/cross vale quanto quella stima. adverse_frac nasconde la quantità più difficile dell'articolo ($\delta$ dipende dal regime e schizza esattamente quando postare è più allettante); stimala dai tuoi stessi esiti di non-fill, suddivisi per regime di vol. E il motore sopra riprezza via cancel-replace incondizionatamente — una versione venue-aware dovrebbe instradare i cambi di quantità-in-giù attraverso il percorso che preserva la priorità e addebitare ogni azione contro un budget di messaggi.

Eseguilo dentro il simulatore contro un tape di replay prima di credere a qualsiasi parametro. L'esperimento che conta: fissa lo scheduler, fai uno sweep di escalate_frac e reprice_band, e traccia lo shortfall di slice contro il costo modellato implicato da $\eta$. La superficie ha un plateau — ampie fasce di parametri quasi ottimali — e due dirupi: escalation troppo tardiva (residui non eseguiti che incrociano nel momentum) e reprice troppo avventato (tutto il valore di coda bruciato). Vuoi sapere dove sono i tuoi dirupi prima che li trovi la produzione al posto tuo.

Cosa portare a casa

1. Due livelli, un contratto. Lo scheduler decide quanto e per quando; la tattica decide come. L'interfaccia è budget, finestra, urgenza in discesa; fill e shortfall di slice contro il mid di arrivo dell'intervallo in risalita. Se non riesci ad attribuire lo shortfall a un livello, non puoi calibrare nessuno dei due.
2. Il gate post/cross è aritmetica, non sensazioni. Posta se e solo se $p > \delta/(\Pi + \delta)$ con $\Pi = s + f_t - f_m$. Sui book crypto stretti il premio è il differenziale di fee, quindi il tuo fee tier fissa le tue tattiche — ricalibra la scala dopo ogni ri-tier.
3. I timer di age-out sono il punto d'incrocio di due curve — probabilità di fill che satura contro adverse selection che cresce come $\sqrt{\tau}$ — non costanti da folklore.
4. La posizione in coda è un asset; conosci la semantica di amend di ogni venue prima di spenderla. CME: la quantità-in-giù mantiene la priorità. Binance spot: cancelReplace ri-accoda sempre, l'amend-keepPriority del 2025 la preserva per i tagli di quantità. Binance futures: ogni modifica ri-accoda. OKX: non documentato — misura, e nel frattempo assumi il peggio.
5. Gli iceberg sono una sequenza di ordini in fondo alla coda, e quelli pigri sono leggibili. Picchi costanti e ricariche con lo stesso timestamp sono una firma di rilevamento pubblicata; randomizza size e timer o accetta di essere back-run.
6. Spedisci la state machine nel tuo simulatore di fill per primo. Il livello tattico è la parte dello stack dove backtest e produzione divergono di più — motivo esattamente per cui appartiene dentro il simulatore, non attaccato dopo.

Link utili

1. Harris, L. — Optimal Dynamic Order Submission Strategies in Some Stylized Trading Problems, Financial Markets, Institutions & Instruments 7(2), 1-76 (1998)
2. Cont, R., Kukanov, A. — Optimal Order Placement in Limit Order Markets, Quantitative Finance 17(1), 21-39 (2017)
3. Frey, S., Sandås, P. — The Impact of Iceberg Orders in Limit Order Books (2009)
4. Bessembinder, H., Panayides, M., Venkataraman, K. — Hidden Liquidity: An Analysis of Order Exposure Strategies in Electronic Stock Markets, Journal of Financial Economics 94(3), 361-383 (2009)
5. van Kervel, V., Menkveld, A. — High-Frequency Trading around Large Institutional Orders, Journal of Finance 74(3), 1091-1137 (2019)
6. Moallemi, C., Yuan, K. — A Model for Queue Position Valuation in a Limit Order Book (2016)
7. Lehalle, C.-A. — Market Microstructure Knowledge Needed for Controlling an Intra-Day Trading Process (2011)
8. Binance Spot API — Order Amend Keep Priority
9. Binance Spot API — Trading endpoints (cancelReplace semantics)
10. Binance USDT-M Futures API — Modify Order
11. OKX API v5 — Amend order
12. CME Group — Order Functionalities (modification and time priority)

Citazione

@article{soloviov2026childordertactics,
  author = {Soloviov, Eugen},
  title = {Inside the slice: child-order tactics between your scheduler and the exchange},
  year = {2026},
  url = {https://marketmaker.cc/blog/child-order-execution-tactics},
  description = {The tactics layer between execution schedulers and the exchange: passive-then-aggressive escalation with maker-taker break-even math, amend vs cancel-replace queue semantics across venues, iceberg anti-signaling, and a per-slice Python state machine for fill simulators.}
}