Pourquoi mes backtests remplacent-ils sans cesse leurs données d’options ?

Un backtest sur options peut changer sans qu’une seule ligne de code de la stratégie ait bougé. Un fournisseur corrige une cotation erronée, ajoute une transaction tardive, révise les métadonnées d’un contrat ou modifie son filtre pour les marchés croisés. Vous relancez les mêmes dates et obtenez une exécution différente, une position différente, peut-être un Sharpe différent. Ce n’est pas nécessairement un bug de la stratégie. C’est une évolution des éléments sur lesquels la stratégie a été testée.

Pour rendre un backtest sur options reproductible, traitez les données de marché comme une entrée versionnée. Notez l’instantané utilisé, conservez les observations brutes à l’origine de chaque décision et comparez les résultats qui ont changé au niveau du contrat et de l’horodatage avant de vous fier au résultat agrégé.

Pourquoi mon backtest sur options a-t-il changé alors que le code est resté identique ?

Les enregistrements d’options sont particulièrement sensibles aux corrections, car la négociabilité apparente d’un contrat dépend de plusieurs champs qui évoluent ensemble : bid, ask, quantités, prix du sous-jacent, échéance, strike, ainsi que le multiplicateur ou le livrable du contrat. Une cotation corrigée peut transformer une occasion apparente en marché croisé. Une correction des métadonnées peut modifier la signification du multiplicateur d’une position.

Imaginons une stratégie qui achète un call lorsque l’ask est inférieur à 2,00 $. Lors du premier chargement des données, la cotation de 10:14 affiche un ask à 1,95 $, un bid à 1,90 $ et une quantité de 5. Une révision ultérieure du fournisseur fait passer l’ask à 2,05 $, après rapprochement d’un message tardif de la place de marché. Une seule observation inverse le signal. Si ce contrat était l’unique transaction de la stratégie ce jour-là, une correction modeste des données peut dominer le rendement de la journée.

Le filtrage des cotations compte également. Les fournisseurs peuvent supprimer les cotations périmées, éliminer les marchés croisés ou normaliser les horodatages différemment. Ces règles peuvent être pertinentes, mais elles font partie de l’identité du jeu de données. « Options SPY, de janvier à mars » ne définit pas un historique reproductible.

Qu’est-ce qu’une version des données d’options ?

Une version des données correspond à l’ensemble exact d’observations historiques disponible pour une exécution de recherche donnée. Conservez le nom du fournisseur et du jeu de données, l’heure de récupération, la plage de dates, la version du schéma ainsi que les règles de nettoyage ou de filtrage. Si le fournisseur expose des identifiants d’instantané ou des horodatages de révision, enregistrez-les aussi.

Pour chaque décision simulée, gardez suffisamment d’informations de traçabilité pour répondre aux questions suivantes : quel contrat a été examiné, quelle cotation a été retenue, quand cette cotation a-t-elle été publiée ou reçue, et quelle règle l’a rendue admissible ? L’enregistrement brut et l’enregistrement dérivé comptent tous deux. Un NBBO nettoyé sans ses horodatages source peut masquer si une cotation était périmée ou si elle est arrivée après la décision simulée.

Comment vérifier si une révision du fournisseur a modifié mes résultats ?

Exécutez la même stratégie avec la même configuration sur les deux instantanés. Commencez par comparer le nombre d’observations et de contrats admissibles pour chaque date. Comparez ensuite les décisions et les exécutions : quels signaux sont apparus ou ont disparu, quelle cotation a changé et si le nouvel enregistrement a modifié le prix d’exécution modélisé.

Ne vous arrêtez pas au rendement total. Suivez les variations du nombre de transactions, des prix d’entrée et de sortie, des signaux rejetés et de la part du P&L provenant de transactions présentes dans une seule version. Un backtest peut conserver un Sharpe similaire alors que certaines transactions sont remplacées ; la statistique principale ne vous dira pas que l’historique sous-jacent a changé.

Pour réaliser un audit utile, gardez la stratégie, les frais et les hypothèses d’exécution inchangés. Si plusieurs éléments varient en même temps, vous ne saurez pas si l’écart vient de la correction du fournisseur ou de votre propre expérimentation.

Dois-je toujours utiliser l’historique d’options le plus récent ?

Utilisez l’historique le plus récent si votre objectif est de travailler à partir de la meilleure reconstruction actuelle du fournisseur. Conservez l’ancien instantané si vous devez reproduire un résultat antérieur ou comprendre quelles informations votre système de recherche avait à l’époque. Ces instantanés répondent à des questions différentes.

Pour une recherche point-in-time, un enregistrement corrigé peut être plus exact aujourd’hui tout en n’ayant pas été disponible à la stratégie à l’époque. Conservez si possible les heures de publication et de réception ; sinon, indiquez clairement cette limite. Une reconstruction moderne ne correspond pas automatiquement à l’ensemble d’informations historique.

Lorsqu’un backtest sur options change, la première question à poser est : « Quelles observations ont changé ? » La question « Quelle exécution est la bonne ? » vient ensuite, une fois que vous pouvez répondre à la première.

Que dois-je enregistrer avec chaque backtest ?

Enregistrez un manifeste concis à côté des résultats : fournisseur de données et instantané, heure de récupération, versions du schéma et du nettoyage, source des métadonnées des contrats, commit de la stratégie, hypothèses d’exécution et configuration du lancement. Reliez chaque transaction aux enregistrements de cotation qui l’ont justifiée.

Ce petit relevé transforme une relance mystérieuse en différences que vous pouvez examiner. L’historique des options continuera d’être corrigé. Votre processus de recherche doit rendre chaque correction visible, afin qu’une meilleure archive améliore les éléments disponibles sans réécrire discrètement l’expérience.