Quelle latence faut-il ajouter à un backtest ? Nous avons mesuré chaque milliseconde de notre système

Quatre chiffres, tous mesurés sur notre propre système de paper trading, une stratégie, des signaux perpétuels BTCUSDT en 1 minute, 31 jours et 1,418 ordres. Temps médian entre la clôture de la bougie et l’accusé de réception de l’ordre par l’exchange : 195 ms. 99e percentile : 2,970 ms. Médiane pour le 1 % des minutes présentant la volatilité réalisée la plus élevée : 840 ms. Et la constante de latence qui figurait dans la configuration du backtest pendant la majeure partie de l’année précédente : 0.

Trois de ces chiffres sont ennuyeux. Tout le monde sait que zéro est faux, tout le monde finit par le remplacer par autre chose, et cette autre valeur est presque toujours une constante choisie au doigt mouillé. 100 ms, 250 ms, « soyons prudents, 500 ». Le chiffre qui compte vraiment est 840, car il montre que votre latence dépend de l’état du marché, et que les états de marché où elle s’envole sont les mêmes que ceux où votre signal croit avoir détecté une opportunité.

Où passent les 195 millisecondes

Voici le budget complet, mesuré étape par étape avec des horodatages d’horloge monotone consignés à chaque étape. La machine est une instance AWS dans ap-northeast-1, dans la même région que les points de terminaison de la plateforme, ce qui est à peu près le mieux qu’on puisse faire avec une configuration de particulier sans colocation.

Deux points à relever avant d’aborder le sujet intéressant. D’abord, les médianes ne s’additionnent pas : 128 + 3 + 11 + 47 = 189, alors que la médiane mesurée de bout en bout est de 195. Les percentiles ne sont pas additifs ; si vous estimez la latence en additionnant les p99 de chaque étape, vous obtiendrez 3,128 ms alors que le vrai p99 est de 2,970. C’est assez proche ici, mais l’écart peut être énorme lorsque les étapes sont corrélées dans l’autre sens. Mesurez le parcours complet.

Ensuite, regardez la première ligne. Les deux tiers du budget médian sont consacrés à attendre que l’exchange vous indique que la bougie est clôturée. Ce n’est ni le réseau, ni votre code, ni le routage des ordres. La plateforme agrège les transactions dans une kline, décide que la minute est terminée, puis envoie l’événement. Cet envoi passe par une file d’attente, partagée avec tous les autres abonnés à ce flux.

Le chiffre de 840

Répartissez chacun de ces 1,418 ordres selon la volatilité réalisée de la minute qui a généré le signal, et la distribution se disloque.

Toutes les étapes se dégradent simultanément, ce qui amplifie le problème. La charge du moteur d’appariement alimente l’agrégation et la file de diffusion de la plateforme : une minute comptant 11,000 transactions est donc diffusée plus tard qu’une minute qui en compte 600. Votre propre processus traite davantage de mises à jour de profondeur et de transactions pendant cette même période ; la mise à jour des caractéristiques qui prend habituellement 3 ms en prend alors 28. Le chemin des ordres REST doit composer avec la panique de tous les autres, et vous commencez à voir des erreurs 503 suivies de nouvelles tentatives, qui vous coûtent à elles seules une seconde entière. Dans notre échantillon, le coefficient de corrélation entre le nombre de transactions de la bougie du signal et la latence de bout en bout était de 0.41. Ce n’est pas énorme. C’est suffisant pour rendre une constante inutilisable.

Et les stratégies qui passent un premier filtre sont, dans leur immense majorité, celles qui négocient les cassures, les retournements, les décrochages et les cascades de liquidations. Elles se déclenchent précisément dans la tranche où la latence est la pire. Un signal de momentum qui ne se déclenche que lorsque la minute a bougé de 40 bps est un signal qui, par construction, sera toujours servi par la version la plus lente de votre système.

Nous avons un jour passé une journée à traquer une valeur aberrante de 3.6 secondes, qui apparaissait à peu près à la même heure chaque nuit. En cause : logrotate, qui copiait puis tronquait un fichier de 2 GB sur le même volume EBS que celui utilisé par le processus pour écrire, bloquant ainsi la boucle d’événements. Le marché n’y était pour rien. Mesurez d’abord, puis accusez la microstructure.

Conséquences sur l’exécution

Le prix évolue pendant que vous attendez. Sur une minute prise au hasard, le mouvement adverse moyen pendant nos 195 ms de latence médiane était d’environ 1.1 bps par rapport au sens du signal. Sur les minutes du quartile supérieur, à 312 ms, il était de 5.8 bps. Pour les minutes du top 1 %, à 840 ms, la dérive adverse atteignait environ 14 bps avant même que l’ordre n’arrive dans le carnet.

Sur les contrats perpétuels BTC, le spread joue à peine dans cette histoire : un tick sur une cotation à 84,000 représente 0.012 bps, les dégâts viennent donc de la dérive adverse plutôt que du coût de franchissement du spread. Transposez la même stratégie sur un contrat perpétuel de capitalisation moyenne, et le second facteur se réveille : dans notre échantillon, le spread au meilleur prix est passé de 1.4 bps pendant les minutes calmes à 6.2 bps dans le quartile supérieur, tandis que la profondeur à ce niveau a diminué de plus de moitié. Vous payez à la fois la dérive, le spread plus large et la profondeur réduite, le tout pour une même raison.

En rejouant les mêmes 31 jours avec une latence conditionnelle par bougie au lieu d’un délai uniforme de 200 ms, le prix d’entrée moyen du backtest s’est dégradé de 3.1 bps, presque entièrement concentrés sur 9 % des transactions. L’écart entre les prix d’entrée du backtest et du paper trading est passé de 4.2 bps à 0.9 bps. Le Sharpe IS de cette stratégie est passé de 1.7 à 1.1 : c’est le chiffre honnête, et ça l’a toujours été.

Alors, que faut-il mettre dans la configuration ?

Pas un scalaire. Voici ce que nous utilisons maintenant :

1. Échantillonnez, ne fixez pas. Pour chaque ordre simulé, tirez la latence à partir d’une distribution empirique conditionnée par l’activité de la bougie : le nombre de transactions et le rendement absolu suffisent, et figurent déjà dans une kline standard. Ajustez le modèle une fois par plateforme et par type d’ordre, puis réajustez-le chaque mois.
2. Conservez la queue de distribution. N’ajustez pas une loi lognormale en considérant le travail terminé : le p99 dépend des tempêtes de nouvelles tentatives et des pauses du GC qu’aucune distribution lisse ne reproduit. Nous utilisons les quantiles empiriques et rééchantillonnons la queue au-delà du p95.
3. La latence s’applique aussi aux annulations. Le remplacement d’un stop ou l’annulation d’une couverture subit le même délai ; sur les marchés rapides, votre annulation fait la course contre une exécution. Si votre simulateur annule instantanément, votre modèle de risque est fictif.
4. Ajoutez un garde-fou contre les signaux périmés et simulez-le. Notre système écarte tout signal dont la bougie date de plus de 1.5 seconde à son arrivée. C’est un comportement réel, avec un coût réel : il supprime des transactions sans bruit, et le backtest doit supprimer les mêmes.
5. Réétalonnez à partir du paper trading. C’est le paper trading qui vous donne la vérité terrain. Consignez les horodatages des quatre étapes pour chaque ordre et comparez chaque semaine les distributions à celles supposées par le simulateur.

L’erreur générale consiste à traiter un paramètre d’exécution comme une constante indépendante, alors qu’il dépend de la même variable d’état que celle qui pilote votre signal. Les frais se comportent bien ; le funding aussi ; la latence, non. Si vous ne retenez qu’un chiffre, retenez ce ratio : notre p99 vaut quinze fois notre médiane, et notre signal arrive de façon disproportionnée près du p99.

Instrumentez les quatre étapes. Cela représente un après-midi de travail et vous en apprendra davantage sur votre stratégie qu’une semaine supplémentaire de recherche de paramètres.