02 · MBP, MBO et niveaux de données¶
Une stratégie d'order flow ne vaut que ce que vaut son flux de données. Ce chapitre décrit précisément ce que chaque niveau contient, ce qu'il permet de calculer, et ce qu'il rend impossible.
Les quatre niveaux¶
| Niveau | Nom courant | Contenu | Ce qu'il permet |
|---|---|---|---|
| L1 | Top of book | Meilleur bid/ask + tailles, dernières transactions | Delta, CVD, footprint |
| L2 (MBP) | Market by price | Volume agrégé par prix, sur N niveaux | Déséquilibre du carnet, murs |
| L3 (MBO) | Market by order | Chaque ordre individuel, avec son rang dans la file | Position en file, taille des ordres, détection d'itération |
| Trades | Time & sales | Prix, taille, horodatage, côté agresseur | Classification exacte de l'agressivité |
Intuition
MBP, c'est savoir qu'il y a 400 contrats à 5000,00. MBO, c'est savoir que ces 400 contrats sont 4 ordres de 100, ou 200 ordres de 2 — deux situations radicalement différentes. Dans le premier cas, quatre acteurs peuvent annuler et faire disparaître le niveau instantanément.
Ce que MBO ajouté concrètement¶
Rithmic annonce fournir un flux MBO réel pour les futures CME, avec profondeur illimitée, les types d'ordres exécutés et la possibilité de connaître sa propre place dans la file (EdgeClear, Bookmap). Les trois apports décisifs :
- Position en file. On sait combien de contrats sont devant le sien. Sans cela, une stratégie de fourniture de liquidité est impossible à évaluer sérieusement — on ne sait pas si l'on aurait été exécuté.
- Distribution des tailles. Un niveau composé de gros ordres se comporte différemment d'un niveau granulaire. C'est un descripteur de la nature des participants présents.
- Suivi du cycle de vie. Ajout, modification, annulation, exécution : on distingue un niveau qui s'évapore (annulations) d'un niveau qui est consommé (exécutions). C'est la différence entre un support qui recule et un support qui absorbe.
Limite importante
Le MBO du CME est anonyme. Aucun identifiant de participant n'est transmis. Les récits du type « on voit l'institutionnel entrer » sont une interprétation, pas une donnée. On observe des tailles et des motifs, pas des acteurs.
Ce que le retail peut réellement obtenir¶
C'est là que la théorie et la pratique divergent, et le point mérite d'être posé franchement avant de choisir une architecture.
| Voie d'accès | L1 | L2 (MBP) | MBO (L3) | API programmable |
|---|---|---|---|---|
| Rithmic via broker classique (AMP, Optimus, EdgeClear, Ironbeam) | oui | oui | oui | oui, après conformance |
| Rithmic via prop firm | oui | oui | souvent en option payante | variable, souvent restreint |
| TopstepX / ProjectX | oui | partiel | non | oui (API officielle) |
| Tradovate via prop firm | oui | oui | non | limité |
| Databento (données seules) | oui | oui | oui, historique complet | oui, mais aucune exécution |
Chez Ironbeam, la donnée L1 non-professionnelle démarre à 3,00 $/mois par bourse, le bundle L2 CME complet est affiché à 41,00 $/mois, et les données tick historiques remontent à décembre 2011 (Ironbeam). Chez certains courtiers, le MBO est inclus avec le package Level 1 ; chez d'autres c'est un supplément. Il faut vérifier auprès de l'entité qui ouvre le compte, pas auprès de Rithmic.
Le piège du niveau de données inutile¶
Un réflexe fréquent consiste à réclamer le MBO parce que c'est « le plus détaillé ». C'est souvent un mauvais arbitrage pour un bot retail :
- Les stratégies décrites dans ce rapport (absorption, imbalances empilées, sweep) se calculent entièrement à partir de L1 + trades horodatés avec agresseur. Le MBO n'y ajoute qu'un filtre marginal.
- Le MBO ne devient indispensable que pour les stratégies passives — se placer dans la file et être exécuté — c'est-à-dire précisément le domaine où la latence retail est disqualifiante.
- Le volume de messages MBO sur ES en séance est très supérieur à celui de L1. Le traiter en Python sans architecture adaptée conduit à un retard croissant du bot par rapport au marché.
À retenir
Commencez en L1 + trades. Passez au L2 si un filtre de contexte le justifie. N'allez au MBO que si votre stratégie dépend explicitement de la position en file — et sachez alors que vous entrez dans un jeu où votre latence vous désavantage structurellement.
Horodatage¶
La qualité de l'horodatage détermine la validité de tout ce qu'on construit au-dessus. Trois horloges différentes existent :
| Horodatage | Origine | Usage |
|---|---|---|
| exchange send | CME, au moment de la publication | Référence pour l'analyse |
| gateway receive | Rithmic, à la réception | Mesure de la latence amont |
| client receive | votre machine | Mesure de la latence totale |
Rithmic annonce des horodatages à granularité microseconde sur R|API+ (Ironbeam). Databento publie jusqu'à quatre horodatages par événement, synchronisés PTP, avec une précision sub-microseconde (Databento).
Pour un backtest honnête, c'est l'horodatage bourse qui ordonne les événements, et l'horodatage client qui détermine ce que le bot pouvait savoir à un instant donné. Confondre les deux produit un backtest qui voit l'avenir.
Erreur fréquente
Utiliser l'heure locale de la machine pour ordonner les événements. Une dérive d'horloge de quelques millisecondes suffit à inverser l'ordre de deux événements et à créer un signal fantôme parfaitement reproductible… et parfaitement faux.
Résumé¶
- L1 + trades avec côté agresseur suffit à construire delta, footprint et la majorité des signaux d'order flow retail.
- Le MBO apporte la position en file et la distribution des tailles ; il est décisif pour les stratégies passives, marginal pour les stratégies agressives.
- L'accès effectif au MBO dépend du courtier ou de la prop firm, pas de Rithmic.
- L'horodatage bourse ordonne, l'horodatage client contraint.
Chapitre précédent : Le carnet d'ordres · Chapitre suivant : Delta, footprint et CVD