Dans la tranche : les tactiques d'ordres enfants entre votre scheduler et l'exchange

Une trajectoire Almgren-Chriss vous donne un chiffre : vendre 4,2 BTC dans les cinq prochaines minutes. Un schedule VWAP vous donne le même type de chiffre avec une justification différente. Aucun des deux ne dit quoi que ce soit sur ce qui se passe ensuite — si ces 4,2 BTC arrivent sur le book comme un seul ordre marketable, restent au touch à collecter des frais maker, se cachent derrière un affichage de 0,3 BTC, ou sont repricés onze fois en chassant une cotation qui dérive. Cette seconde couche de décision est la couche tactique, et sur des books crypto dominés par les frais, elle déplace régulièrement plus de PnL par tranche que le choix du scheduler qui la surplombe. Les budgets d'intervalle du scheduler diffèrent entre TWAP et un Almgren-Chriss bien calibré de quelques points de base d'impact sur l'ensemble de l'ordre parent ; payer des frais taker sur des tranches que vous auriez pu faire en maker, ou saigner sa position dans la file par un repricing négligent, coûte autant par heure. Cet article porte sur la couche que tout le monde fait tourner et que presque personne ne documente : la machine à états qui décide comment chaque ordre enfant touche le book.

Deux couches, une interface étroite

Lehalle et Laruelle, dans Market Microstructure in Practice (2e éd., 2018), formalisent ce vers quoi convergent tous les desks d'exécution : une couche stratégique (le scheduler) qui alloue la quantité dans le temps, et une couche tactique (le microtrader) qui travaille chaque allocation contre le book en temps réel. La séparation n'est pas esthétique — les deux couches vivent sur des horloges et des données différentes. Le scheduler pense en minutes, consomme des prévisions de volatilité et de volume, et résout un problème variationnel. La couche tactique pense en millisecondes-à-secondes, consomme des deltas L2 et des estimations de file d'attente, et résout une séquence de petits problèmes d'arrêt optimal.

L'interface entre elles doit être étroite. Vers le bas, par tranche $k$ :

• budget $q_k$ — la quantité à exécuter sur cet intervalle (le $n_k$ d'Almgren-Chriss, ou l'incrément de la courbe de volume du VWAP) ;
• fenêtre $\tau_k$ — la durée de la tranche ;
• urgence — pour Almgren-Chriss, le candidat naturel est $\kappa = \sqrt{\lambda\sigma^2/\eta}$, qui compresse déjà l'aversion au risque, la volatilité et la liquidité en un seul taux ; pour un scheduler VWAP, il s'agit généralement d'une distance à la bande ("nous sommes 1,8 % en retard sur la courbe cible").

Vers le haut : les exécutions avec horodatage et frais, le reliquat non exécuté, et le shortfall d'implémentation au niveau de la tranche, mesuré par rapport au mid d'arrivée de l'intervalle. Ce dernier point compte : le paramètre d'impact $\eta$ du scheduler tarife déjà ce que demander de la liquidité au taux $q_k/\tau_k$ devrait coûter. Le travail de la couche tactique tient en une ligne : réaliser des exécutions à un coût meilleur que celui impliqué par $\eta$, sans révéler l'existence de l'ordre parent. Si votre shortfall de tranche mesuré bat systématiquement le coût du modèle, votre $\eta$ calibré peut baisser, le scheduler accélère, et toute la pile s'améliore. Si vous ne pouvez pas mesurer le shortfall de tranche séparément du coût du schedule, vous ne pouvez calibrer ni l'une ni l'autre couche — vous n'avez qu'un chiffre flou et deux boutons.

La politique de reliquat fait aussi partie du contrat. Quand une tranche se termine avec une quantité non exécutée, soit la couche tactique force la complétion (croiser le reliquat — le comportement par défaut sous urgence de deadline), soit elle le renvoie au scheduler pour réamortissement sur les tranches restantes (acceptable en début de schedule à faible $\kappa$, toxique près de la deadline où le réamortissement se compose silencieusement en une tranche finale massive).

L'échelle d'escalade : passif d'abord, agressif par la deadline

Le plus ancien résultat de ce domaine est Harris (1998), "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2)) : pour un trader de liquidité qui doit compléter un trade avant une deadline, la stratégie optimale est dynamique — rester dans le book avec des ordres limites tant que le temps est bon marché, se repricer vers le marché à mesure que la deadline approche, et croiser à la fin. Chaque moteur tactique de production descend de cette forme : poster au touch, laisser vieillir, escalader, croiser. Ce que les grilles de frais modernes et la dynamique des files d'attente ajoutent, c'est l'arithmétique précise de quand chaque transition se déclenche.

Le seuil de rentabilité pour croiser

Travail par unité, prix relatifs au mid actuel, pour un achat. Croiser maintenant coûte la moitié du spread plus le frais taker :

Poster au bid sur une fenêtre $\tau$ s'exécute avec une probabilité $p$ ; une exécution rapporte le demi-spread et paie le frais maker $f_m$ (négatif s'il s'agit d'un rebate). Pas d'exécution signifie croiser en fin de fenêtre après que le prix a, en moyenne, évolué contre vous de $\delta(\tau) = E[\,\text{mouvement mid adverse} \mid \text{pas d'exécution}\,] > 0$ — strictement positif, car non-exécution et dérive adverse sont le même événement : votre bid n'est pas touché quand le marché s'envole loin de lui. Coût de posting attendu :

Poster bat croiser ssi

où $\Pi$ est le gain — l'aller-retour complet que vous captez en faisant du maker plutôt que du taker : le spread plus le différentiel de frais. C'est exactement le même seuil de rentabilité qui régit toute l'économie maker-taker de l'exécution, condensé à une seule tranche.

Chiffres, perp BTCUSDT : mid 100 000 $, spread d'un tick$s = 0,10$$, frais type VIP0 maker 2 bps / taker 5 bps, donc$f_m = 20$$,$f_t = 50$$par BTC. Le gain$\Pi = 0,10 + 50 - 20 = 30,10$ \approx 3$bps — notez que le spread ne contribue essentiellement à rien ; sur les majors crypto au spread serré, le gain *est* le différentiel de frais. Prenez 3$\sigma_{\text{jour}} = 3,000$$) et$\delta(\tau) \approx 0,6,\sigma_{\text{jour}}\sqrt{\tau/86400}$ (le 0,6 est une décote d'antisélection à calibrer, pas à croire aveuglément) :

• $\tau = 10$ s : \delta \approx 19\$$, donc p^* = 19/49 \approx 0,39$. Ne postez que si vous attendez au moins 39 % d'exécution en 10 secondes.
• $\tau = 60$ s : \delta \approx 47\$$, donc p^* = 47/77 \approx 0,61$.
• Avec un rebate maker de 1 bp au lieu d'un frais de 2 bps (f_m = -10\$$) : \Pi = 60,10$$, et le seuil à 10 s tombe à$p^* \approx 0,24$.

Deux faits structurels en découlent. Premièrement, $\delta$ croît comme $\sqrt{\tau}$ tandis que $\Pi$ est constant, donc $p^\*(\tau) \to 1$ : la patience a une expiration ferme, et le timer d'age-out n'est pas une heuristique mais le point de croisement de deux courbes — votre $p(\tau)$ estimé (concave, saturant à mesure que la file devant vous se vide) contre $p^\*(\tau)$ (croissant). Deuxièmement, le palier de frais sur lequel vous tradez déplace physiquement l'échelle. Un upgrade de palier qui réduit les frais taker rend vos tactiques optimales plus agressives — un couplage que la plupart des gens découvrent seulement quand leurs statistiques d'exécution changent après un re-tiering VIP.

Cont et Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 2017 ; arXiv 2012), rendent cela rigoureux sur une période : minimiser le coût attendu d'exécution de $S$ unités réparties entre ordres marché et ordres limite (sur une ou plusieurs venues), avec une pénalité pour le shortfall. La solution mono-venue est explicite et a une structure de type newsvendor : la taille optimale de l'ordre limite est pilotée par la distribution de l'outflow de la file — poster une taille agressive quand la file devant est petite par rapport à l'outflow attendu, et couvrir le risque de queue avec des ordres marché. Leur extension multi-venue se résout par approximation stochastique et constitue le cœur intellectuel de la logique d'allocation passive de tout smart order router. La lecture pratique pour un moteur tactique : le $p$ du seuil de rentabilité ci-dessus n'est pas une constante — c'est une fonction de la position dans la file et du taux de vidage, ce qui explique pourquoi la couche tactique doit consommer l'estimateur de position dans la file comme entrée de premier ordre.

Le paramètre d'urgence condense toute cette échelle. Un $\kappa$ élevé venant du scheduler signifie que le temps caractéristique $\theta = 1/\kappa$ est court : les fenêtres se réduisent, $p^\*$ augmente, et le moteur passe directement au croisement — à raison, car le scheduler a déjà déclaré que le risque d'inventaire domine les économies de frais. Un $\kappa$ faible étire la phase passive. La couche tactique ne devrait jamais redériver l'urgence de sa propre vision du marché ; c'est le travail du scheduler, et le dupliquer crée deux contrôleurs en désaccord.

Repricer sans brûler sa position dans la file

Une fois posté, la cotation dérive. La chasser naïvement — annuler, reposter au nouveau touch, répéter — est la façon dont les moteurs tactiques détruisent silencieusement la probabilité d'exécution même qui justifiait le posting. La position dans la file est un actif à valeur monétaire mesurable (Moallemi et Yuan, 2016, y mettent un prix : les positions en tête de file dans des books FIFO liquides valent une fraction significative du spread), et chaque décision de repricing est un trade : vendre votre position actuelle dans la file, en acheter une à l'arrière d'un niveau de prix différent. Le trade ne vaut la peine que lorsque la valeur du nouveau niveau dépasse celle de l'ancien plus les coûts de messagerie. Cela exige de savoir ce que l'amend de chaque venue fait réellement à votre place dans la file — et la réponse est extrêmement non uniforme.

CME Globex documente la sémantique la plus propre : réduire la quantité de l'ordre conserve la priorité temporelle ; augmenter la quantité ou changer le prix vous envoie à l'arrière de la file. C'est le modèle de référence — la baisse de quantité est gratuite, tout le reste est une remise en file.

Binance spot n'offrait historiquement que POST /api/v3/order/cancelReplace — un cancel-plus-new d'apparence atomique mais explicitement non transactionnel. Deux modes : STOP_ON_FAILURE (par défaut — si l'annulation échoue, pas de nouvel ordre) et ALLOW_FAILURE (placer le nouvel ordre même si l'annulation échoue — bonjour l'exposition double accidentelle). L'opération peut réussir partiellement, signalé par un HTTP 409, donc votre OMS doit réconcilier les deux jambes indépendamment ; et le nouvel ordre démarre toujours une file de vie neuve. Puis en 2025, Binance a déployé Order Amend Keep Priority (PUT /api/v3/order/amend/keepPriority) : réduire la quantité sur place, conserver la priorité temporelle, à coût nul en nombre d'ordres non exécutés. La sémantique CME, quinze ans plus tard — et seulement pour la moitié baisse de quantité.

Binance USDT-M futures dispose d'un véritable endpoint de modification (PUT /fapi/v1/order), mais lisez les petites lignes : uniquement les ordres LIMIT, price et quantity doivent tous deux être envoyés, et "les ordres modifiés seront réordonnés dans la file de matching" — la doc ne promet aucune conservation de priorité, même pour de pures réductions de quantité. Traitez chaque modify de futures comme une remise à zéro de file qui a le mérite de vous économiser un message et de conserver l'ID de l'ordre. Un point délicat à connaître : modifier un ordre GTX (post-only) vers un prix qui croiserait le book fait annuler l'ordre, et non rejeter-en-conservant — une implémentation de peg qui ne vérifie pas cela s'auto-amendera occasionnellement jusqu'à l'extinction.

OKX expose POST /api/v5/trade/amend-order (newPx, newSz, avec cxlOnFail pour auto-annuler en cas d'échec de l'amend). C'est un message unique, il préserve l'ID de l'ordre, et confirme de manière asynchrone — sCode = 0 signifie "requête acceptée", et le résultat réel arrive sur le canal des ordres sous forme d'amendResult. Ce que la doc publique ne spécifie pas du tout, c'est le comportement de priorité dans la file. Ne comblez pas ce vide documentaire par de l'optimisme. Mesurez-le : postez deux ordres marqueurs à un niveau calme, amendez la taille de l'un à la baisse, et observez lequel s'exécute en premier sur quelques centaines d'essais. Tant que vous n'avez pas cette donnée, l'hypothèse conservatrice — tout changement de prix vous remet en file partout, la baisse de quantité ne préserve la priorité que là où c'est explicitement documenté — est la seule défendable.

Les conséquences en termes de politique :

1. Hystérésis, pas pegging. Ne repricer que lorsque le touch a dérivé de plus d'une bande $b$ ticks par rapport à votre prix résiduel. À l'intérieur de la bande, la dérive est du bruit et votre position dans la file vaut plus qu'un tick d'amélioration de prix. Une bande de départ raisonnable est de 1 à 3 ticks mise à l'échelle par la vol de court horizon ; la bonne bande rend le repricing marginal neutre en EV : $V_{\text{nouveau}} - V_{\text{actuel}} = c_{\text{msg}}$, avec $V$ la valeur de file façon Moallemi-Yuan et $c_{\text{msg}}$ votre prix fantôme de limite de débit. Les opérations amend/cancel-replace consomment un budget de débit d'ordres sur les deux venues Binance ; un moteur tactique qui pegue chaque tick affamera le reste de votre système en capacité de messages.
2. Amender à la baisse, jamais cancel-repost à la baisse. Quand le scheduler coupe un budget de tranche en vol (un scheduler POV voyant le volume se tarir, un re-solve Almgren-Chriss après exécutions partielles), utilisez le chemin préservant la priorité là où il existe. C'est le seul repas gratuit de toute la couche.
3. Urgence asymétrique sur le repricing. Repricer vers le marché (chasser) réinitialise votre file à un prix moins bon — cela ne devrait se déclencher que depuis la logique d'escalade, sur son propre timer. Repricer à l'écart (le marché est venu à vous) est un cadeau, à ne prendre que via la bande passive, car votre niveau actuel est sur le point de s'exécuter de toute façon.

Iceberg orders, taille d'affichage, et ce qui révèle votre intention

La taille d'affichage est la troisième décision, et c'est un véritable arbitrage à double tranchant, pas un bouton furtif gratuit. Le constat empirique :

• Frey et Sandås ("The Impact of Iceberg Orders in Limit Order Books", working paper 2009 ; Quarterly Journal of Finance, 2017), sur des données Xetra : les iceberg orders portaient 9,3 % du volume soumis et 15,9 % du volume exécuté, étaient 12 à 20 fois plus gros que les ordres limite ordinaires, et — la chute — quand d'autres participants détectent un iceberg, ils répondent par des ordres marché correspondants. La taille cachée, une fois inférée, attire du flux : la recherche de liquidité latente fonctionne dans les deux sens.
• Bessembinder, Panayides et Venkataraman ("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets", JFE 94(3), 2009), sur Euronext Paris, où les ordres cachés représentaient 44 % du volume de l'échantillon : cacher réduit le shortfall d'implémentation mais réduit aussi la probabilité d'exécution complète et allonge le temps de complétion. L'exposition achète des exécutions et les paie en impact ; l'option est utilisée exactement comme la théorie le prédit — les ordres agressifs s'exposent pour attirer des contreparties, la taille patiente se cache.
• Esser et Mönch ("The navigation of an iceberg", Finance Research Letters 4(2), 2007) traitent la taille de pic comme une optimisation : un affichage plus grand s'exécute plus vite, un affichage plus petit fuit moins, et l'optimum est intérieur.

La mécanique d'abord, car elle contraint l'optimisation : sur pratiquement toutes les venues qui supportent les iceberg orders natifs (Binance spot via icebergQty, OKX via ses ordres algo iceberg), chaque réapprovisionnement du pic visible entre à l'arrière de la file à ce prix. Un iceberg n'est donc pas "un ordre avec une taille cachée" — c'est une séquence de petits ordres, chacun payant l'attente complète en file, tirés automatiquement. Au seuil de rentabilité des frais ci-dessus, cela compte : le $p$ effectif par pic est la probabilité d'exécution à l'arrière de la file, pas celle de votre position d'origine. Les files profondes pénalisent doublement les petits pics — exécutions plus lentes et davantage d'antisélection à chaque réapprovisionnement.

Puis le problème de signalisation. La propre méthode de détection de Frey et Sandås est l'histoire édifiante : leur détecteur fréquentiste s'appuie sur les deux motifs de paresse d'implémentation les plus courants — taille de pic constante et horodatages de réapprovisionnement identiques à l'horodatage du trade exécutant. Tout participant faisant tourner ce détecteur (et sur les venues crypto, beaucoup le font — les métadonnées de matching propres à l'exchange le rendent encore plus facile pour le flux colocalisé) reconstruit votre taille cachée en une poignée de réapprovisionnements. Les vecteurs de fuite, classés par fréquence d'observation sur le terrain :

1. Tailles d'affichage constantes ou rondes (0,5 BTC, à chaque fois).
2. Réapprovisionnement instantané et déterministe après exécution complète d'un pic — la signature au même horodatage.
3. Timers d'escalade déterministes : croiser exactement 30 s dans chaque tranche et le tape ressemble à un métronome.
4. Latence et bande de repricing fixes — votre cadence d'amend est une empreinte digitale tout aussi identifiante que la taille de vos ordres, sujet des empreintes digitales et de l'identification des traders.

Le coût d'être détecté n'est pas hypothétique. Van Kervel et Menkveld ("High-frequency trading around large institutional orders", Journal of Finance 74(3), 2019) montrent que les HFT penchent d'abord contre les métaorders institutionnels — fournissant la liquidité que vos tactiques passives consomment — puis basculent à trader avec l'ordre une fois que sa persistance révèle de l'information, en back-runnant le reliquat et en augmentant sensiblement le coût du parent. Leurs institutions ont réagi en arbitrant entre profit spéculatif et risque de détection. Votre couche tactique est exactement l'endroit où cet arbitrage s'implémente : randomisez la taille d'affichage (uniforme 30-70 % d'une base mise à l'échelle par la vol fonctionne bien), jitterez chaque timer de ±20-30 %, laissez occasionnellement un réapprovisionnement attendre, et ne laissez jamais deux ordres enfants partager une taille, une phase de timer et un profil de latence. Rien de tout cela ne coûte de qualité d'exécution mesurable ; tout cela relève le plancher de bruit pour quiconque tente d'ajuster un détecteur sur votre flux.

Un moteur tactique minimal

Toute la couche ci-dessus se condense en une petite machine à états par tranche : IDLE → POSTED → (boucle de repricing) → CROSSING → DONE, avec la porte du seuil de rentabilité à l'entrée, une bande d'hystérésis pendant le posting, et l'escalade de deadline. La version ci-dessous est délibérément minimale — pas d'adaptateurs de venue, pas de gestion d'iceberg — mais elle est pilotée par événements et sans effet de bord, donc elle s'insère directement dans le simulateur queue-aware de rang 4 de l'échelle de simulation d'exécution : le simulateur appelle on_tick/on_fill, et interprète les actions comme post → GTX/post-only, cross → IOC, cancel_replace/amend_down → la sémantique de la venue tirée de la matrice ci-dessus.

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

Trois mises en garde honnêtes. p_fill ici est un ratio-placeholder — en production, ce devrait être le modèle en buckets, calibré en direct, de l'article sur la simulation d'exécution, car toute la porte post/cross ne vaut que ce que vaut cette estimation. adverse_frac cache la quantité la plus difficile de l'article ($\delta$ dépend du régime et pique exactement quand poster est le plus tentant) ; estimez-la à partir de vos propres résultats de non-exécution, en buckets par régime de vol. Et le moteur ci-dessus repricee via cancel-replace sans condition — une version consciente des venues devrait router les changements de baisse de quantité via le chemin préservant la priorité et facturer chaque action contre un budget de messages.

Faites-le tourner dans le simulateur contre une bande de replay avant de croire à l'un quelconque des paramètres. L'expérience qui compte : fixez le scheduler, balayez escalate_frac et reprice_band, et tracez le shortfall de tranche contre le coût de modèle impliqué par $\eta$. La surface a un plateau — de larges bandes de paramètres quasi optimaux — et deux falaises : escalader trop tard (des reliquats non exécutés croisant dans du momentum) et repricer trop avidement (toute la valeur de file brûlée). Vous voulez connaître l'emplacement de vos falaises avant que la production ne les trouve pour vous.

Ce qu'il faut retenir

1. Deux couches, un seul contrat. Le scheduler décide combien et pour quand ; la tactique décide comment. L'interface est budget, fenêtre, urgence vers le bas ; exécutions et shortfall de tranche vs mid d'arrivée de l'intervalle vers le haut. Si vous ne pouvez pas attribuer le shortfall à une couche, vous ne pouvez calibrer ni l'une ni l'autre.
2. La porte post/cross est de l'arithmétique, pas du feeling. Postez ssi $p > \delta/(\Pi + \delta)$ avec $\Pi = s + f_t - f_m$. Sur des books crypto serrés, le gain est le différentiel de frais, donc votre palier de frais fixe vos tactiques — recalibrez l'échelle après chaque re-tiering.
3. Les timers d'age-out sont le point de croisement de deux courbes — probabilité d'exécution saturante contre antisélection croissant en $\sqrt{\tau}$ — pas des constantes de folklore.
4. La position dans la file est un actif ; connaissez la sémantique d'amend de chaque venue avant de la dépenser. CME : la baisse de quantité conserve la priorité. Binance spot : cancelReplace remet toujours en file, l'amend-keepPriority de 2025 la préserve pour les baisses de quantité. Binance futures : chaque modify remet en file. OKX : non documenté — mesurez, et supposez le pire en attendant.
5. Les iceberg orders sont une séquence d'ordres à l'arrière de la file, et les paresseux sont lisibles. Les pics constants et les réapprovisionnements au même horodatage constituent une signature de détection publiée ; randomisez tailles et timers ou acceptez d'être back-runné.
6. Envoyez la machine à états dans votre simulateur d'exécution en premier. La couche tactique est l'endroit de la pile où le backtest et la production divergent le plus fort — ce qui est exactement pourquoi elle appartient à l'intérieur du simulateur, et non greffée après coup.

Liens utiles

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)

Citation

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