Nous avons démonté un backtest de marché prédictif qui avait acheté le mauvais contrat

Un backtest de marché prédictif peut utiliser un ticker qui semble correct, le bon historique de prix, mais le mauvais contrat. Cette erreur passe facilement inaperçue : les noms de marché sont courts, les pages d’événement sont mises à jour et une part YES ressemble toujours à un prix compris entre zéro et un.

Prenons un marché hypothétique intitulé « La loi sur les transports propres sera-t-elle adoptée ? » Une stratégie achète YES à 0.42 après un signal d’actualité. Plus tard, le backtest valorise la position à 1.00. Avant de croire à cette victoire, je veux savoir exactement ce que promettait le contrat : de quel projet de loi il s’agissait, ce qui comptait comme une « adoption », quelle était l’échéance et quelle source avait tranché.

Le titre : « La loi sur les transports propres sera-t-elle adoptée ? »

Un titre est une chaîne d’affichage, pas un identifiant d’instrument stable. Deux marchés peuvent avoir des formulations presque identiques tout en portant sur des sessions législatives, des projets amendés ou des échéances différents. Une plateforme peut aussi modifier un titre pour clarifier le marché sans changer les conditions sous-jacentes.

Le backtest doit donc rattacher la position à l’ID de marché ou de contrat immuable de la plateforme, puis conserver le texte intégral des règles et sa version. Si les données historiques ne contiennent qu’un titre et un ticker, impossible d’établir que la série de prix correspond bien au contrat que la stratégie comptait négocier.

Les règles : que signifie « adopté » ?

Supposons que la règle exige que le projet de loi soit adopté par la Chambre et le Sénat avant le 30 juin, puis signé par le président. Un backtest qui considère comme une réussite son adoption par l’une ou l’autre chambre a changé le pari. Même chose s’il valide un projet portant le même nom lors de la session suivante.

Lisez les critères de résolution comme des conditions exécutables. Consignez l’échéance et le fuseau horaire, l’événement requis, les exceptions éventuelles et la source de résolution nommée. L’ambiguïté compte aussi : si les règles de la plateforme laissent un scénario plausible sans réponse, ne choisissez pas discrètement l’interprétation qui correspond au résultat historique.

Une partie de ce travail est merveilleusement peu spectaculaire : sauvegarder la page des règles avant que quoi que ce soit d’intéressant ne se produise. Une page capturée seulement après la résolution peut afficher la formulation finale, alors que votre stratégie est entrée en position sous une version antérieure.

La chronologie : quand la stratégie pouvait-elle le savoir ?

Supposons maintenant que les règles soient solides et que le signal d’actualité se déclenche à 14:05 UTC. Le flux historique indique qu’une transaction a eu lieu à 14:05, au prix de 0.42. Cet horodatage ne suffit pas à savoir si l’information était disponible avant la transaction, si le prix enregistré était encore exécutable ensuite, ni si la bougie représente une cotation, une transaction ou un résumé d’intervalle.

Distinguez l’heure de disponibilité du signal de l’heure de l’événement de marché. Passez ensuite l’ordre une fois que la stratégie a pu le calculer et le soumettre. Sur un marché peu liquide, la transaction enregistrée suivante peut survenir quelques minutes plus tard ; cela ne prouve pas que votre ordre aurait été exécuté à ce prix.

Le prix : une cotation n’est pas une exécution

Un YES à 0.42 correspond à 42 cents par part, mais une série des dernières transactions masque le spread et la taille disponible. Si le meilleur prix vendeur est de 0.45 pour 20 parts, un achat simulé de 100 parts ne peut pas être entièrement exécuté à 0.42. Il pourrait parcourir le carnet, attendre ou rester sans exécution.

Les prix des marchés prédictifs incitent aussi à un raccourci comptable : considérer 0.42 comme une probabilité de 42 % et oublier que c’est également le coût d’entrée en espèces. Une position de 100 parts YES coûte $42 avant frais. Si le règlement donne $1, le produit brut est de $100 ; s’il donne $0, le produit est nul. Les frais, les exécutions partielles et les modalités de règlement propres à la plateforme doivent figurer dans le registre.

Le règlement : qu’est-ce qui clôt la transaction ?

Un backtest clôt souvent la position au dernier prix de marché. Mais un contrat conservé jusqu’à sa résolution est payé selon ses règles, et son dernier prix coté peut être périmé, assorti d’un spread important ou très éloigné du paiement final. Modélisez la résolution comme un événement distinct : le résultat, l’heure du règlement et le mouvement de trésorerie doivent provenir de l’enregistrement du contrat.

Tenez aussi compte d’un marché dont le résultat est déclaré invalide ou contesté, si les règles de la plateforme prévoient ce cas. La mise peut être remboursée, un autre montant versé ou le règlement retardé. Une hypothèse de paiement binaire ne peut pas représenter toutes les voies de résolution.

Verdict sur le backtest

Dans cet exemple, je ne validerais le gain annoncé qu’après avoir vérifié l’ID de marché immuable, la version des règles en vigueur à l’entrée, le jeton YES, l’heure de disponibilité du signal, les prix vendeurs exécutables et les tailles, les frais et le règlement enregistré. Si l’archive de prix ne permet pas ces vérifications, le résultat honnête est une fourchette de scénarios ou un résultat non vérifié.

Cela peut sembler strict pour une petite transaction. Répétez la même erreur de jointure sur des milliers de marchés et le backtest peut devenir une mesure minutieuse de contrats que votre stratégie n’a jamais négociés.