Le modèle de slippage de votre backtest doit être volontairement faux

Le modèle de slippage le plus honnête est souvent volontairement faux. Un backtest qui annonce un coût d’exécution précis à partir de données historiques grossières avance une affirmation que ces données ne peuvent pas étayer.

On pourrait croire que cela plaide pour des hypothèses rudimentaires. C’est tout le contraire : utilisez un modèle simple que vous pouvez expliquer, puis faites-le se contredire. Si une stratégie ne fonctionne qu’avec une estimation d’exécution avantageuse et bien commode, l’incertitude fait partie du résultat.

Pourquoi une estimation précise du slippage peut-elle induire en erreur ?

Supposons que vous disposiez de barres OHLCV d’une minute et que vous passiez un ordre au marché de 2,000 actions. La barre indique la fourchette de prix et le volume total sur une minute. Elle ne vous dit pas quels étaient le bid et l’ask à l’arrivée de votre ordre, quelle était la file d’attente devant vous, comment le volume se répartissait pendant la minute, ni quelle part votre ordre aurait absorbée.

Vous pouvez tout de même attribuer une valeur au slippage. Vous pouvez supposer une exécution à l’ouverture de la barre suivante, majorée d’un coût fixe en points de base, ou faire varier le coût en fonction du rapport entre la taille de l’ordre et le volume de la barre. Ce sont des approximations utiles. Ce ne sont pas des observations. Présenter le résultat sous la forme « slippage : 3.2 points de base » fait passer un choix de modèle pour une mesure.

Prenons un exemple concret : une stratégie passe des ordres de $20,000 sur une action dont le volume de la barre suivante est de $400,000. Son taux de participation est de 5%. Un modèle qui facture 2 points de base coûte $4 par ordre ; un modèle qui en facture 10 coûte $20. Sur 500 allers-retours, l’écart atteint $16,000, hors commissions. Si le bénéfice brut du backtest est de $18,000, l’hypothèse d’exécution pèse presque autant que le signal.

Construisez une fourchette adaptée à ce que vos données permettent d’observer

Commencez par une référence adaptée au type d’ordre de la stratégie et à la résolution des données. Un ordre au marché nécessite de prendre en compte le spread et l’impact. Pour un ordre limite, il faut définir une règle qui détermine s’il est exécuté ou non ; supposer que chaque prix touché donne lieu à une exécution constitue une autre erreur de modélisation.

Faites ensuite tourner le même backtest avec un petit nombre de cas explicitement définis. Gardez le signal, le dimensionnement et les horodatages fixes afin de pouvoir attribuer les variations à l’exécution :

Ce ne sont pas des intervalles de confiance, sauf si vous les avez calibrés statistiquement. Ce sont des tests de scénarios. Précisez leur signification dans le rapport, et ne faites pas leur moyenne pour produire un « slippage attendu » fictif sans données justifiant les probabilités.

Faites réagir le modèle à l’ordre

Un coût fixe en points de base peut constituer une première approximation raisonnable pour les petits ordres. Cette approche devient peu crédible lorsque le taux de participation augmente. Au minimum, consignez le notionnel de l’ordre, le volume disponible sur la barre et le taux de participation. Si la stratégie traite des contrats à terme, consignez la valeur du contrat et les unités de volume pertinentes ; si elle traite des cryptos au comptant, précisez la devise de cotation et la plateforme.

Une courbe d’impact simple peut révéler les contraintes de capacité sans prétendre reproduire un carnet d’ordres. Par exemple, définissez le coût comme la somme d’un coût de spread de référence et d’un terme d’impact qui augmente avec la racine carrée du taux de participation. N’ajustez ses paramètres que si vous disposez de données d’exécution adaptées. Sinon, faites varier ces paramètres et montrez à quelle vitesse le résultat se dégrade.

Veillez aussi à ce que le modèle d’exécution ne sauve pas la stratégie en douce. Un signal acheteur émis après une forte hausse ne devrait pas être exécuté au plus bas de la barre simplement parce que ce prix se trouve dans la bougie. Utilisez une convention d’exécution causale, puis dégradez le prix et ajoutez un délai. Si l’ordre retardé manque le mouvement, c’est un résultat lié à l’exécution, pas un désagrément à lisser.

Utilisez le trading simulé pour affiner la fourchette

Le trading simulé ne révèle pas l’exécution que vous auriez obtenue sur un moteur d’appariement en conditions réelles. Il peut toutefois indiquer si le flux d’ordres du backtest ressemble aux décisions réelles du système : quand les ordres sont générés, quelle est leur taille et combien de temps ils restent exécutables.

Comparez le prix simulé de l’ordre aux cotations contemporaines ou aux données de marché enregistrées par votre système de trading simulé. Suivez l’écart par instrument, heure de la journée, taille d’ordre et type d’ordre. Ces observations peuvent affiner les hypothèses pour cette configuration. Elles ne s’appliquent pas automatiquement à une autre plateforme, à un autre régime de marché ou à un ordre plus important.

Les critiques ont raison de dire que les scénarios pessimistes peuvent être arbitraires. Un modèle délibérément sévère peut écarter une stratégie viable, tout comme un modèle favorable peut enjoliver une stratégie faible. Ne prenez donc pas le scénario le plus sévère pour la vérité. Publiez les hypothèses, montrez la sensibilité et collectez les données nécessaires pour remplacer les suppositions par des estimations calibrées.

Un backtest ne peut pas connaître la position historique dans la file d’attente à partir d’une bougie. Il peut montrer si l’idée reste cohérente lorsque les conditions d’exécution se dégradent d’une manière que vos données ne permettent pas d’exclure. C’est une réponse plus utile qu’une décimale.