Votre backtest macro a négocié sur la base du rapport révisé sur l’emploi

Chère personne qui a conçu cette stratégie fondée sur les créations d’emplois,

Vous avez défini une règle simple : après la publication du rapport américain sur l’emploi, votre stratégie conserve un ETF actions pendant cinq séances si la hausse mensuelle des emplois salariés dépasse 175,000. Sinon, elle reste en liquidités. Vous avez programmé l’entrée après l’ouverture du marché actions, intégré les coûts de transaction et gardé le seuil fixe. Puis vous avez téléchargé une série historique sur l’emploi et l’avez utilisée pour reconstituer chaque signal.

Le problème qui vous reste, c’est le téléchargement. Une série économique historique peut contenir des estimations révisées qui n’étaient pas disponibles aux dates auxquelles votre stratégie est censée avoir négocié. Pour backtester honnêtement un signal macro, il vous faut la version disponible à chaque instant de décision. Décaler l’entrée d’une barre ne corrigera pas un chiffre publié deux mois plus tard.

Votre observation de janvier a plusieurs dates de naissance

Prenons cet historique de publications fictif. Ces dates et variations de l’emploi illustrent le mécanisme ; elles ne correspondent pas à des résultats économiques publiés.

Si votre téléchargement indique +210,000 pour janvier, votre simulation entre sur l’ETF en février. Votre véritable règle serait restée en liquidités. Tous les prix, horodatages d’ordres et commissions peuvent être corrects, alors que cette opération est entièrement fictive.

Vous ne pouvez pas supposer que cette contamination améliore les performances. Les révisions peuvent créer des opérations gagnantes ou perdantes, ou supprimer les unes comme les autres. Le défaut, c’est que votre simulation répond à une question que votre stratégie ne pouvait pas se poser à l’époque.

Et janvier n’est que la période mesurée. Ce n’est pas la date à laquelle vous avez pris connaissance de la mesure. Une ligne étiquetée 1er janvier ne vous autorise pas à négocier le 1er janvier.

Associez à chaque valeur son historique de disponibilité

Votre table de recherche doit contenir plus qu’un mois et un chiffre. Conservez la période de référence, la valeur, l’horodatage de publication, l’identifiant de version et la source. Pour une collecte continue, notez aussi à quel moment votre système a reçu la publication. Gardez les anciennes versions au lieu de mettre leurs valeurs à jour sur place.

À un instant de décision donné, sélectionnez pour chaque observation la version admissible la plus récente, dont l’horodatage de disponibilité ne dépasse pas celui de la décision. Calculez ensuite vos variables à partir de cet instantané reconstitué.

Votre période de détention de cinq séances ne rend pas ce suivi facultatif. Elle vous laisse davantage de latitude pour choisir une heure d’entrée prudente ; elle ne vous donne pas accès aux révisions avant leur publication.

Pour des recherches anciennes, vous pouvez disposer d’une preuve de l’heure de publication publique sans avoir conservé l’heure à laquelle vous l’avez reçue. Gardez cette distinction explicite. Vous pouvez modéliser l’accès à partir d’un horodatage de publication documenté, en indiquant le délai retenu. Vous ne pouvez pas présenter cette hypothèse comme une mesure historique de la livraison.

Il vous faudra aussi un horodatage tenant compte du fuseau horaire. Enregistrez l’heure locale documentée de la publication et convertissez-la correctement ; un décalage UTC fixe pour New York ne fonctionnera pas lors des changements d’heure. Votre futur vous en sera reconnaissant. Vous ne devriez pas avoir à déchiffrer la colonne nommée date_actual_final2 par votre version de mars, en septembre.

Vos variables glissantes doivent utiliser la version complète des données

Supposons que vous remplaciez le seuil fixe par « la hausse de l’emploi dépasse sa moyenne des douze derniers mois ». Vous devez alors disposer des observations précédentes telles qu’elles se présentaient à cet instant de décision, y compris les révisions déjà publiées à ce moment-là.

Utiliser pour toujours la première publication de chaque mois définit une autre variable. Ce peut être un choix valable si vous souhaitez explicitement étudier l’historique des annonces initiales. Mais cela ne reconstitue pas l’historique économique visible un matin donné, car l’information disponible ce matin-là peut déjà inclure des révisions des mois précédents.

Si vous calculez les variations mensuelles de l’emploi à partir des niveaux d’emploi, reconstituez la série des niveaux correspondant à la version pertinente avant de calculer les différences. Mélanger un niveau nouvellement publié avec le niveau du mois précédent provenant d’une version plus ancienne peut produire une variation qui ne figurait dans aucun instantané publié.

Vous devez donc préciser ce que représente votre variable : les annonces initiales, la dernière photographie économique disponible ou les révisions elles-mêmes. « Hausse de l’emploi » laisse trop de choses indéterminées.

Reconstituez une publication avant de relancer dix ans de données

Vous pouvez commencer par ALFRED, qui fournit l’historique des versions pour de nombreuses séries économiques. Vérifiez la couverture de votre série et de votre période précises. Une date de version ne suffit pas à établir la disponibilité intrajournalière ; associez-la à l’heure de publication documentée avant de l’utiliser pour un signal le jour même.

Pour votre premier audit, choisissez une publication et reconstituez-la à la main :

1. Trouvez la publication archivée et notez son horodatage de publication, son mois de référence et sa valeur initiale.
2. Reconstituez l’instantané de données que votre stratégie aurait reçu avant l’entrée.
3. Calculez le signal à la main et comparez-le à celui de votre simulation.
4. Ajoutez une révision ultérieure au stockage de données et vérifiez que la décision antérieure ne change pas.

Cette dernière vérification est particulièrement utile dans un pipeline de recherche automatisé. Fournissez à votre agent de recherche l’heure limite de l’instantané et les identifiants des versions sélectionnées avec les valeurs des variables. Vous devez disposer de suffisamment d’éléments pour relier une opération à une publication précise, même lorsque la base de données sous-jacente s’est étoffée.

Une fois cette décision reproduite, relancez l’historique et comparez les divergences de signaux avant de comparer les rendements. Comptez les entrées créées, supprimées ou décalées par la correction. Ces décisions modifiées vous apprendront davantage qu’un simple Sharpe comparé avant et après.

Votre opération de février doit tenir compte des informations disponibles en février. Laissez la révision d’avril en avril.