Im Innern des Slice: Child-Order-Taktiken zwischen Scheduler und Börse

Eine Almgren-Chriss-Trajektorie gibt dir eine Zahl vor: Verkaufe 4,2 BTC in den nächsten fünf Minuten. Ein VWAP-Schedule gibt dir dieselbe Art von Zahl mit anderer Begründung. Keines von beiden sagt etwas darüber, was als Nächstes passiert — ob diese 4,2 BTC als eine marktfähige Order ins Buch treffen, am Touch liegen bleiben und Maker-Fees einsammeln, sich hinter einer 0,3-BTC-Anzeige verstecken oder elfmal umgepreist werden, während sie einer driftenden Quote hinterherjagen. Diese zweite Entscheidungsschicht ist die Taktik-Schicht, und auf gebührendominierten Krypto-Büchern bewegt sie routinemäßig mehr PnL pro Slice als die Wahl des darüberliegenden Schedulers. Die Intervallbudgets des Schedulers unterscheiden sich zwischen TWAP und einem gut kalibrierten Almgren-Chriss um wenige Basispunkte an Impact über die gesamte Parent-Order hinweg; Taker-Fees auf Slices zu zahlen, die man hätte machen können, oder Queue-Position durch nachlässiges Repricing zu verbrennen, kostet so viel pro Stunde. Dieser Artikel handelt von der Schicht, die jeder betreibt und die fast niemand schriftlich festhält: die Zustandsmaschine, die entscheidet, wie jede Child-Order das Buch berührt.

Zwei Schichten, eine schmale Schnittstelle

Lehalle und Laruelles Market Microstructure in Practice (2. Aufl., 2018) formalisiert, worauf jedes Execution-Desk zusteuert: eine strategische Schicht (der Scheduler), die Menge über die Zeit verteilt, und eine taktische Schicht (der Mikrotrader), die jede Zuteilung gegen das lebende Buch abarbeitet. Die Trennung ist nicht ästhetisch — die beiden Schichten leben auf unterschiedlichen Uhren und mit unterschiedlichen Daten. Der Scheduler denkt in Minuten, verarbeitet Volatilitäts- und Volumenprognosen und löst ein Variationsproblem. Die Taktik-Schicht denkt in Millisekunden bis Sekunden, verarbeitet L2-Deltas und Queue-Schätzungen und löst eine Sequenz kleiner Stopping-Probleme.

Die Schnittstelle zwischen ihnen sollte schmal sein. Nach unten, pro Slice $k$:

• Budget $q_k$ — die in diesem Intervall auszuführende Menge (das $n_k$ von Almgren-Chriss, oder das Volumenkurven-Increment von VWAP);
• Fenster $\tau_k$ — die Slice-Länge;
• Dringlichkeit — bei Almgren-Chriss ist der natürliche Kandidat $\kappa = \sqrt{\lambda\sigma^2/\eta}$, das bereits Risikoaversion, Volatilität und Liquidität zu einer Rate verdichtet; bei einem VWAP-Scheduler ist es meist ein Band-Abstand ("wir liegen 1,8% hinter der Zielkurve").

Nach oben: Fills mit Zeitstempeln und Fees, die unausgeführte Restmenge und der Slice-Level-Implementation-Shortfall gemessen gegen den Intervall-Arrival-Mid. Das Letztere ist entscheidend: Der Impact-Parameter $\eta$ des Schedulers bepreist bereits, was das Fordern von Liquidität zur Rate $q_k/\tau_k$ kosten sollte. Die gesamte Jobbeschreibung der Taktik-Schicht ist ein Satz: Fills zu besseren Kosten als dem $\eta$-implizierten Wert realisieren, ohne die Existenz der Parent-Order zu verraten. Wenn dein gemessener Slice-Shortfall die Modellkosten konsequent unterbietet, kann dein kalibriertes $\eta$ sinken, der Scheduler beschleunigt, und der gesamte Stack verbessert sich. Wenn du Slice-Shortfall nicht getrennt von den Schedule-Kosten messen kannst, kannst du keine der beiden Schichten justieren — du hast eine unscharfe Zahl und zwei Stellschrauben.

Auch die Restmengen-Policy gehört zum Vertrag. Wenn ein Slice mit unausgeführter Menge endet, vervollständigt entweder die Taktik-Schicht zwangsweise (die Restmenge kreuzen — Standard bei Deadline-Dringlichkeit) oder gibt sie an den Scheduler zur Neu-Amortisierung über die verbleibenden Slices zurück (akzeptabel früh in einem Low-$\kappa$-Schedule, giftig nahe der Deadline, wo Neu-Amortisierung sich still zu einem massiven letzten Slice aufsummiert).

Die Eskalationsleiter: erst passiv, dann aggressiv per Deadline

Das älteste Ergebnis in diesem Bereich ist Harris (1998), "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2)): Für einen Liquiditätshändler, der einen Trade bis zu einer Deadline abschließen muss, ist die optimale Strategie dynamisch — im Buch mit Limit-Orders stehen, solange Zeit billig ist, sich mit näherndem Deadline Richtung Markt umpreisen und am Ende kreuzen. Jede Production-Taktik-Engine ist ein Nachfahre dieser Form: am Touch posten, auslaufen lassen, eskalieren, kreuzen. Was moderne Gebührenstrukturen und Queue-Dynamiken hinzufügen, ist die Arithmetik dafür, genau wann jeder Übergang feuert.

Der Break-even fürs Kreuzen

Arbeit pro Einheit, Preise relativ zum aktuellen Mid, für einen Kauf. Sofort kreuzen kostet den halben Spread plus die Taker-Fee:

Am Bid über ein Fenster $\tau$ zu posten füllt mit Wahrscheinlichkeit $p$; ein Fill verdient den halben Spread und zahlt die Maker-Fee $f_m$ (negativ bei einem Rebate). Kein Fill bedeutet, am Fensterende zu kreuzen, nachdem sich der Preis im Schnitt um $\delta(\tau) = E[\,\text{ungünstige Mid-Bewegung} \mid \text{kein Fill}\,] > 0$ gegen dich bewegt hat — strikt positiv, weil Nicht-Fill und ungünstige Drift dasselbe Ereignis sind: Dein Bid wird nicht getroffen, wenn der Markt davon wegzieht. Erwartete Posting-Kosten:

Posten schlägt Kreuzen genau dann, wenn

wobei $\Pi$ der Preis ist — der volle Round-Trip, den du durch Machen statt Nehmen einfängst: der Spread plus das Fee-Differential. Das ist derselbe Break-even, der die gesamte Maker-Taker-Ökonomie der Ausführung beherrscht, hier komprimiert auf einen einzelnen Slice.

Zahlen, BTCUSDT-Perp: Mid $100.000, Spread ein Tick s = \0,10$, VIP0-ähnliche Fees Maker 2 bps / Taker 5 bps, also$f_m = $20$,$f_t = $50$pro BTC. Der Preis$\Pi = 0,10 + 50 - 20 = $30,10 \approx 3$bps — man beachte, dass der Spread praktisch nichts beiträgt; auf engen Krypto-Majors *ist* der Preis das Fee-Differential. Nimm 3$\sigma_{\text{day}} = $3.000$) und$\delta(\tau) \approx 0,6,\sigma_{\text{day}}\sqrt{\tau/86400}$ (die 0,6 ist ein Adverse-Selection-Abschlag, den du kalibrieren, nicht blind übernehmen solltest):

• $\tau = 10$ s: \delta \approx \19$, also$p^* = 19/49 \approx 0,39$. Poste nur, wenn du mindestens eine 39%ige Fill-Wahrscheinlichkeit innerhalb von 10 Sekunden erwartest.
• $\tau = 60$ s: \delta \approx \47$, also$p^* = 47/77 \approx 0,61$.
• Mit einem Maker-Rebate von 1 bp statt einer 2-bp-Fee (f_m = -\10$):$\Pi = $60,10$, und die 10-s-Schwelle sinkt auf$p^* \approx 0,24$.

Zwei strukturelle Tatsachen fallen dabei heraus. Erstens wächst $\delta$ wie $\sqrt{\tau}$, während $\Pi$ konstant ist, sodass $p^\*(\tau) \to 1$: Geduld hat ein hartes Verfallsdatum, und der Age-out-Timer ist keine Heuristik, sondern der Schnittpunkt zweier Kurven — deine geschätzte $p(\tau)$ (konkav, sättigend, während die Queue vor dir abläuft) gegen $p^\*(\tau)$ (steigend). Zweitens verschiebt die Gebührenstufe, auf der du handelst, die Leiter physisch. Ein Tier-Upgrade, das Taker-Fees senkt, macht deine optimale Taktik aggressiver — eine Kopplung, die die meisten erst entdecken, wenn sich ihre Fill-Statistik nach einem VIP-Re-Tiering verschiebt.

Cont und Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 2017; arXiv 2012), machen das für eine Periode rigoros: Minimiere die erwarteten Kosten der Ausführung von $S$ Einheiten, aufgeteilt zwischen Market- und Limit-Orders (über eine oder mehrere Venues), mit einer Strafe für Shortfall. Die Single-Venue-Lösung ist explizit und hat Newsvendor-Struktur: Die optimale Limit-Order-Größe wird von der Verteilung des Queue-Abflusses bestimmt — poste aggressiv große Größen, wenn die Queue vor dir klein relativ zum erwarteten Abfluss ist, und decke das Tail-Risiko mit Market-Orders ab. Ihre Multi-Venue-Erweiterung wird per stochastischer Approximation gelöst und bildet den intellektuellen Kern der passiven Zuteilungslogik jedes Smart Order Routers. Die praktische Lesart für eine Taktik-Engine: $p$ im obigen Break-even ist keine Konstante — es ist eine Funktion von Queue-Position und Abflussrate, weshalb die Taktik-Schicht den Queue-Position-Schätzer als erstklassigen Input konsumieren muss.

Der Dringlichkeitsparameter komprimiert diese gesamte Leiter. Ein hohes $\kappa$ vom Scheduler bedeutet, dass die charakteristische Zeit $\theta = 1/\kappa$ kurz ist: Fenster schrumpfen, $p^\*$ steigt, und die Engine springt direkt zum Kreuzen — korrekterweise, weil der Scheduler bereits erklärt hat, dass Inventarrisiko die Gebühreneinsparung dominiert. Ein niedriges $\kappa$ dehnt die passive Phase. Die Taktik-Schicht sollte Dringlichkeit niemals aus ihrer eigenen Marktsicht neu ableiten; das ist Aufgabe des Schedulers, und eine Duplizierung erzeugt zwei uneinige Controller.

Repricing, ohne die Queue-Position zu verbrennen

Sobald gepostet, driftet die Quote. Ihr naiv hinterherzujagen — canceln, am neuen Touch neu posten, wiederholen — ist die Art, wie Taktik-Engines still genau die Fill-Wahrscheinlichkeit zerstören, die das Posten überhaupt gerechtfertigt hat. Queue-Position ist ein Asset mit messbarem Dollarwert (Moallemi und Yuan, 2016, beziffern ihn: Front-of-Queue-Positionen in liquiden FIFO-Büchern sind einen erheblichen Bruchteil des Spreads wert), und jede Repricing-Entscheidung ist ein Trade: Verkaufe deine aktuelle Queue-Position, kaufe eine am Ende eines anderen Preislevels. Der Trade lohnt sich nur, wenn der Wert des neuen Levels den des alten plus die Messaging-Kosten übersteigt. Das erfordert zu wissen, was das Amend jeder Venue tatsächlich mit deinem Platz in der Reihe macht — und die Antwort ist extrem uneinheitlich.

CME Globex dokumentiert die sauberste Semantik: eine Reduzierung der Ordermenge behält die Zeitpriorität; eine Erhöhung der Menge oder eine Preisänderung schickt dich ans Ende der Queue. Das ist das Referenzmodell — Quantity-down ist kostenlos, alles andere ist ein Re-Queue.

Binance Spot bot historisch nur POST /api/v3/order/cancelReplace — ein atomar wirkendes, explizit nicht-transaktionales Cancel-plus-New. Zwei Modi: STOP_ON_FAILURE (Standard — schlägt das Cancel fehl, kommt keine neue Order) und ALLOW_FAILURE (die neue Order wird auch platziert, wenn das Cancel fehlschlägt — hallo, versehentliche doppelte Exposure). Die Operation kann teilweise gelingen, signalisiert durch HTTP 409, sodass dein OMS beide Beine unabhängig voneinander abgleichen muss; und die neue Order beginnt immer ein frisches Queue-Leben. Dann brachte Binance 2025 Order Amend Keep Priority (PUT /api/v3/order/amend/keepPriority): Menge in-place reduzieren, Zeitpriorität behalten, zu null Kosten an unerfüllter Orderzahl. CME-Semantik, fünfzehn Jahre später — und nur die Quantity-down-Hälfte davon.

Binance USDT-M Futures hat einen echten Modify-Endpunkt (PUT /fapi/v1/order), aber lies das Kleingedruckte: Nur LIMIT-Orders, sowohl price als auch quantity müssen gesendet werden, und "modified orders will be reordered in the match queue" — die Docs versprechen keine Prioritätserhaltung, auch nicht bei reinen Mengenreduzierungen. Behandle jedes Futures-Modify als einen Queue-Reset, der zufällig eine Nachricht spart und die Order-ID behält. Eine scharfe Kante, die man kennen sollte: Ein GTX-(Post-only-)Order auf einen Preis zu modifizieren, der kreuzen würde, führt dazu, dass die Order gecancelt wird, nicht abgelehnt-und-behalten — eine Peg-Implementierung, die das nicht prüft, wird sich gelegentlich selbst aus der Existenz amenden.

OKX exponiert POST /api/v5/trade/amend-order (newPx, newSz, mit cxlOnFail zum automatischen Canceln bei Amend-Fehlschlag). Es ist eine einzelne Nachricht, erhält die Order-ID und bestätigt asynchron — sCode = 0 bedeutet "Anfrage akzeptiert", und das tatsächliche Ergebnis kommt über den Orders-Channel als amendResult. Was die öffentlichen Docs auffällig nicht spezifizieren, ist das Queue-Priority-Verhalten. Fülle diese Dokumentationslücke nicht mit Optimismus. Miss es: Poste zwei Marker-Orders auf einem ruhigen Level, amende die Größe einer davon nach unten, und beobachte über einige hundert Versuche, welche zuerst füllt. Bis du diese Daten hast, ist die konservative Annahme — jede Preisänderung requeued dich überall, Quantity-down erhält Priorität nur dort, wo explizit dokumentiert — die einzig vertretbare.

Die Policy-Konsequenzen:

1. Hysterese, nicht Pegging. Repricing nur, wenn der Touch mehr als ein Band $b$ Ticks von deinem ruhenden Preis abgedriftet ist. Innerhalb des Bandes ist Drift Rauschen, und deine Queue-Position ist mehr wert als ein Tick Preisverbesserung. Ein sinnvolles Startband sind 1–3 Ticks, skaliert nach kurzfristiger Vol; das korrekte Band macht das marginale Repricing EV-neutral: $V_{\text{new}} - V_{\text{cur}} = c_{\text{msg}}$, mit $V$ als Moallemi-Yuan-artigem Queue-Wert und $c_{\text{msg}}$ als deinem Rate-Limit-Schattenpreis. Amend/Cancel-Replace-Operationen verbrauchen Order-Rate-Budget bei beiden Binance-Venues; eine Taktik-Engine, die jeden Tick pegged, wird den Rest deines Systems an Nachrichtenkapazität aushungern.
2. Amend down, niemals Cancel-Repost down. Wenn der Scheduler ein Slice-Budget mitten im Flug kürzt (ein POV-Scheduler, der versiegendes Volumen sieht, ein Almgren-Chriss-Neulöser nach Teilausführungen), nutze den prioritätserhaltenden Pfad, wo er existiert. Das ist das einzige Free Lunch der gesamten Schicht.
3. Asymmetrische Dringlichkeit beim Repricing. Repricing Richtung Markt (Chasing) setzt deine Queue zu einem schlechteren Preis zurück — es sollte nur aus der Eskalationslogik heraus feuern, auf ihrem Timer. Repricing weg (der Markt ist zu dir gekommen) ist ein Geschenk; nimm es nur über das passive Band an, weil dein aktuelles Level sowieso gleich füllt.

Icebergs, Display-Größe und was deine Absicht verrät

Die Display-Größe ist die dritte Entscheidung, und sie ist ein echter zweiseitiger Trade, kein kostenloser Stealth-Button. Die empirische Befundlage:

• Frey und Sandås ("The Impact of Iceberg Orders in Limit Order Books", 2009 Working Paper; Quarterly Journal of Finance, 2017), auf Xetra-Daten: Iceberg-Orders trugen 9,3% des eingereichten und 15,9% des ausgeführten Volumens, waren 12–20x so groß wie gewöhnliche Limit-Orders, und — die Pointe — wenn andere Teilnehmer einen Iceberg entdecken, reagieren sie mit passenden Market-Orders. Versteckte Größe zieht, einmal erschlossen, Flow an: Die Suche nach latenter Liquidität funktioniert in beide Richtungen.
• Bessembinder, Panayides und Venkataraman ("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets", JFE 94(3), 2009), auf Euronext Paris, wo versteckte Orders 44% des Stichprobenvolumens ausmachten: Verstecken senkt den Implementation Shortfall, senkt aber auch die Wahrscheinlichkeit vollständiger Ausführung und verlängert die Time-to-Completion. Exposure kauft Fills und bezahlt dafür mit Impact; die Option wird genau so genutzt, wie die Theorie es vorhersagt — aggressive Orders exponieren sich, um Gegenparteien anzuziehen, geduldige Größe versteckt sich.
• Esser und Mönch ("The navigation of an iceberg", Finance Research Letters 4(2), 2007) behandeln die Peak-Größe als Optimierung: größeres Display füllt schneller, kleineres Display verrät weniger, und das Optimum liegt innen.

Erst die Mechanik, weil sie die Optimierung bindet: Bei praktisch jeder Venue, die native Icebergs unterstützt (Binance Spot via icebergQty, OKX via seine Iceberg-Algo-Orders), tritt jeder Refill des sichtbaren Peaks am Ende der Queue zu diesem Preis ein. Ein Iceberg ist daher nicht "eine Order mit versteckter Größe" — er ist eine Sequenz kleiner Orders, jede zahlt die volle Queue-Wartezeit, automatisch abgefeuert. Beim obigen Fee-Break-even ist das relevant: Das effektive $p$ pro Peak ist die Back-of-Queue-Fill-Wahrscheinlichkeit, nicht die deiner ursprünglichen Position. Tiefe Queues bestrafen kleine Peaks doppelt — langsamere Fills und mehr Refills' Anteil an Adverse Selection.

Dann das Signaling-Problem. Frey und Sandås' eigene Erkennungsmethode ist die Warnung: Ihr frequentistischer Detektor setzt auf die beiden häufigsten Implementierungs-Nachlässigkeitsmuster — konstante Peak-Größe und Refill-Zeitstempel identisch mit dem Zeitstempel des ausführenden Trades. Jeder Teilnehmer, der diesen Detektor betreibt (und auf Krypto-Venues tun das viele — die exchange-eigenen Matching-Metadaten machen es für kolokierte Flows noch leichter), rekonstruiert deine versteckte Größe in einer Handvoll Refills. Die Leak-Vektoren, geordnet danach, wie oft ich sie in der Praxis sehe:

1. Konstante oder runde Display-Größen (0,5 BTC, jedes Mal).
2. Sofortiger, deterministischer Refill nach einer vollständigen Peak-Ausführung — die Signatur mit identischem Zeitstempel.
3. Deterministische Eskalationstimer: exakt 30 s in jeden Slice kreuzen, und der Tape zeigt ein Metronom.
4. Feste Repricing-Latenz und -Band — deine Amend-Kadenz ist ein Fingerabdruck, genauso identifizierend wie deine Ordergrößen, was das Thema von digitalen Fingerabdrücken und Trader-Identifikation ist.

Die Kosten des Entdecktwerdens sind nicht hypothetisch. Van Kervel und Menkveld ("High-frequency trading around large institutional orders", Journal of Finance 74(3), 2019) zeigen, dass HFTs sich zunächst gegen institutionelle Metaorders lehnen — sie liefern die Liquidität, die deine passive Taktik konsumiert — und dann umschwenken, mit der Order zu handeln, sobald ihre Persistenz Information preisgibt, den Rest back-runnen und die Kosten der Parent-Order erheblich erhöhen. Ihre Institutionen reagierten, indem sie spekulativen Profit gegen Entdeckungsrisiko abwägten. Genau dort, wo dieser Trade-off implementiert wird, sitzt deine Taktik-Schicht: randomisiere die Display-Größe (uniform 30–70% einer vol-skalierten Basis funktioniert gut), jitter jeden Timer um ±20–30%, lass einen Refill gelegentlich warten, und lass niemals zwei Child-Orders eine Größe, eine Timer-Phase und ein Latenzprofil teilen. Nichts davon kostet messbare Fill-Qualität; alles davon hebt den Rauschboden für jeden, der einen Detektor auf deinen Flow anpasst.

Eine minimale Taktik-Engine

Die gesamte obige Schicht komprimiert sich zu einer kleinen Zustandsmaschine pro Slice: IDLE → POSTED → (Reprice-Loop) → CROSSING → DONE, mit dem Break-even-Gate beim Eintritt, einem Hysterese-Band während des Postings und Deadline-Eskalation. Die Version unten ist bewusst minimal — keine Venue-Adapter, kein Iceberg-Management — aber sie ist event-driven und ohne Seiteneffekte, sodass sie direkt in den Rung-4-queue-aware-Simulator aus der Fill-Simulations-Leiter passt: Der Simulator ruft on_tick/on_fill auf und interpretiert Actions als post → GTX/Post-only, cross → IOC, cancel_replace/amend_down → die Venue-Semantik aus der obigen Matrix.

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",)]

Drei ehrliche Vorbehalte. p_fill ist hier ein Platzhalter-Verhältnis — in Production sollte es das gebucketete, live kalibrierte Modell aus dem Fill-Simulations-Artikel sein, denn das gesamte Post/Cross-Gate ist nur so gut wie diese Schätzung. adverse_frac versteckt die schwierigste Größe des Artikels ($\delta$ ist regimeabhängig und schnellt genau dann hoch, wenn Posten am verlockendsten ist); schätze es aus deinen eigenen No-Fill-Ergebnissen, gebucketet nach Vol-Regime. Und die Engine oben repriced bedingungslos via Cancel-Replace — eine venue-bewusste Version sollte Quantity-down-Änderungen über den prioritätserhaltenden Pfad routen und jede Aktion gegen ein Nachrichtenbudget verrechnen.

Lass sie im Simulator gegen ein Replay-Tape laufen, bevor du irgendeinem der Parameter glaubst. Das entscheidende Experiment: Fixiere den Scheduler, fahre escalate_frac und reprice_band durch, und plotte den Slice-Shortfall gegen die $\eta$-implizierten Modellkosten. Die Fläche hat ein Plateau — breite Bänder nahezu optimaler Parameter — und zwei Klippen: zu spät eskalieren (unausgeführte Restmengen kreuzen in Momentum hinein) und zu eifrig repricen (aller Queue-Wert verbrannt). Du willst wissen, wo deine Klippen liegen, bevor Production sie für dich findet.

Was mitzunehmen ist

1. Zwei Schichten, ein Vertrag. Der Scheduler entscheidet, wie viel und bis wann; die Taktik entscheidet, wie. Die Schnittstelle ist Budget, Fenster, Dringlichkeit nach unten; Fills und Slice-Shortfall gegen Intervall-Arrival nach oben. Wenn du Shortfall keiner Schicht zuordnen kannst, kannst du keine der beiden justieren.
2. Das Post/Cross-Gate ist Arithmetik, kein Bauchgefühl. Poste genau dann, wenn $p > \delta/(\Pi + \delta)$ mit $\Pi = s + f_t - f_m$. Auf engen Krypto-Büchern ist der Preis das Fee-Differential, also legt deine Gebührenstufe deine Taktik fest — justiere die Leiter nach jedem Re-Tiering neu.
3. Age-out-Timer sind der Schnittpunkt zweier Kurven — sättigende Fill-Wahrscheinlichkeit gegen mit $\sqrt{\tau}$ wachsende Adverse Selection — keine folkloristischen Konstanten.
4. Queue-Position ist ein Asset; kenne die Amend-Semantik jeder Venue, bevor du sie ausgibst. CME: Quantity-down behält Priorität. Binance Spot: cancelReplace requeued immer, das amend-keepPriority von 2025 erhält sie bei Mengenkürzungen. Binance Futures: jedes Modify requeued. OKX: undokumentiert — messen, und in der Zwischenzeit das Schlimmste annehmen.
5. Icebergs sind eine Sequenz von Back-of-Queue-Orders, und nachlässige sind lesbar. Konstante Peaks und Refills mit identischem Zeitstempel sind eine veröffentlichte Erkennungssignatur; randomisiere Größen und Timer, oder akzeptiere, back-gerunnt zu werden.
6. Bringe die Zustandsmaschine zuerst in deinen Fill-Simulator. Die Taktik-Schicht ist der Teil des Stacks, wo Backtest und Production am stärksten auseinanderdriften — genau deshalb gehört sie in den Simulator, nicht nachträglich angeflanscht.

Nützliche Links

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)

Zitat

@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.}
}