Les ressources ont été chargées... Je charge...

Les stratégies de trading algorithmique sont testées avec succès - Partie I

Auteur:La bonté, Créé: 2019-03-20 17:00:16, mis à jour:

Cet article poursuit la série sur le trading quantitatif, qui a commencé avec le Guide du débutant et l'identification de la stratégie.

Le backtesting algorithmique nécessite la connaissance de nombreux domaines, y compris la psychologie, les mathématiques, les statistiques, le développement de logiciels et la microstructure du marché / échange. Je ne pouvais pas espérer couvrir tous ces sujets dans un seul article, alors je vais les diviser en deux ou trois parties plus petites. De quoi allons-nous discuter dans cette section? Je vais commencer par définir le backtesting et ensuite je vais décrire les bases de la façon dont il est effectué. Ensuite, je vais élucider les biais que nous avons abordés dans le Guide du débutant au trading quantitatif. Ensuite, je vais présenter une comparaison des différentes options de logiciels de backtesting disponibles.

Dans les articles suivants, nous examinerons les détails des implémentations de stratégie qui sont souvent à peine mentionnées ou ignorées. Nous examinerons également comment rendre le processus de backtesting plus réaliste en incluant les idiosyncrasies d'une bourse de négociation. Ensuite, nous discuterons des coûts de transaction et de la façon de les modéliser correctement dans un cadre de backtest. Nous terminerons par une discussion sur la performance de nos backtests et, enfin, fournir un exemple d'une stratégie quantitative commune, connue sous le nom de commerce de paires inversantes de moyenne.

Commençons par discuter de ce qu'est le backtesting et pourquoi nous devrions le mettre en œuvre dans notre trading algorithmique.

Qu'est-ce que le test de retour?

Le trading algorithmique se distingue des autres types de classes d'investissement parce que nous pouvons fournir plus fiablement des attentes sur les performances futures par rapport aux performances passées, en raison de la disponibilité abondante de données.

En termes simples, le backtesting est effectué en exposant votre algorithme de stratégie particulier à un flux de données financières historiques, ce qui conduit à un ensemble de signaux de trading. Chaque transaction (que nous désignerons ici comme un aller-retour de deux signaux) aura un profit ou une perte associé. L'accumulation de ce profit / perte au cours de la durée de votre backtest de stratégie entraînera le profit et la perte totaux (également connu sous le nom de P&L ou PnL). C'est l'essence de l'idée, bien que bien sûr le diable soit toujours dans les détails!

Quelles sont les principales raisons de backtesting une stratégie algorithmique?

  • Filtrage - Si vous vous souvenez de l'article sur l'identification de la stratégie, notre objectif au stade initial de la recherche était de mettre en place un pipeline de stratégie et de filtrer ensuite toute stratégie qui ne répondait pas à certains critères.
  • Modélisation - Le backtesting nous permet de tester (en toute sécurité!) de nouveaux modèles de certains phénomènes du marché, tels que les coûts de transaction, le routage des commandes, la latence, la liquidité ou d'autres problèmes de microstructure du marché.
  • Optimisation - Bien que l'optimisation de la stratégie soit pleine de biais, le backtesting nous permet d'augmenter la performance d'une stratégie en modifiant la quantité ou les valeurs des paramètres associés à cette stratégie et en recalculant sa performance.
  • Vérification - Nos stratégies sont souvent fournies de l'extérieur, via notre pipeline de stratégie. Le backtesting d'une stratégie garantit qu'elle n'a pas été incorrectement mise en œuvre. Bien que nous ayons rarement accès aux signaux générés par les stratégies externes, nous aurons souvent accès aux indicateurs de performance tels que le ratio de Sharpe et les caractéristiques de retrait. Nous pouvons donc les comparer à notre propre mise en œuvre.

Le backtesting offre une multitude d'avantages pour le trading algorithmique. Cependant, il n'est pas toujours possible de backtest une stratégie directement. En général, à mesure que la fréquence de la stratégie augmente, il devient plus difficile de modéliser correctement les effets de la microstructure du marché et des bourses. Cela conduit à des backtests moins fiables et donc à une évaluation plus délicate d'une stratégie choisie.

Malheureusement, le backtesting est plein de préjugés de toutes sortes.

Les biais qui affectent la stratégie

Il existe de nombreux biais qui peuvent affecter la performance d'une stratégie de backtest. Malheureusement, ces biais ont tendance à gonfler la performance plutôt qu'à la diminuer. Ainsi, vous devriez toujours considérer un backtest comme une limite supérieure idéalisée sur la performance réelle de la stratégie. Il est presque impossible d'éliminer les biais du trading algorithmique, c'est pourquoi il est de notre devoir de les minimiser du mieux possible afin de prendre des décisions éclairées sur nos stratégies algorithmiques.

Il y a quatre préjugés majeurs dont je voudrais discuter: les préjugés d'optimisation, les préjugés de prospective, les préjugés de survie et les préjugés de tolérance psychologique.

Bias d'optimisation

Il s'agit probablement du biais le plus insidieux de tous les biais de backtest. Il implique l'ajustement ou l'introduction de paramètres de trading supplémentaires jusqu'à ce que la performance de la stratégie sur l'ensemble de données de backtest soit très attrayante. Cependant, une fois en direct, la performance de la stratégie peut être nettement différente.

Le biais d'optimisation est difficile à éliminer car les stratégies algorithmiques impliquent souvent de nombreux paramètres. Les paramètres dans ce cas peuvent être les critères d'entrée/sortie, les périodes de rétrospective, les périodes de moyenne (par exemple le paramètre de lissage de la moyenne mobile) ou la fréquence de mesure de la volatilité. Le biais d'optimisation peut être minimisé en réduisant le nombre de paramètres au minimum et en augmentant la quantité de points de données dans l'ensemble de formation. En fait, il faut également faire attention à ce dernier car les anciens points de formation peuvent être soumis à un régime préalable (comme un environnement réglementaire) et peuvent donc ne pas être pertinents pour votre stratégie actuelle.

Une méthode pour aider à atténuer ce biais est d'effectuer une analyse de sensibilité. Cela signifie de varier les paramètres de manière incrémentielle et de tracer une "surface" de performance. Un raisonnement fondamental et solide pour les choix de paramètres devrait, avec tous les autres facteurs pris en compte, conduire à une surface de paramètre plus lisse. Si vous avez une surface de performance très saccadée, cela signifie souvent qu'un paramètre ne reflète pas un phénomène et est un artefact des données de test. Il existe une vaste littérature sur les algorithmes d'optimisation multidimensionnelle et c'est un domaine de recherche très actif. Je ne vais pas m'attarder là-dessus, mais gardez-le dans le fond de votre esprit lorsque vous trouvez une stratégie avec un backtest fantastique!

Le parti pris

Le biais de prospection est introduit dans un système de backtesting lorsque des données futures sont accidentellement incluses à un point de la simulation où ces données n'auraient pas été réellement disponibles. Si nous exécutons le backtest chronologiquement et que nous atteignons le point de temps N, alors le biais de prospection se produit si des données sont incluses pour n'importe quel point N + k, où k>0.

  • Bugs techniques - Les tableaux / vecteurs dans le code ont souvent des itérateurs ou des variables d'index. Des décalages incorrects de ces indices peuvent entraîner un biais de prospection en incorporant des données à N + k pour k non nul.
  • Calcul des paramètres - Un autre exemple courant de biais de prospection se produit lors du calcul des paramètres de stratégie optimaux, comme avec les régressions linéaires entre deux séries temporelles.
  • Maxima/Minimum - Certaines stratégies de trading utilisent des valeurs extrêmes dans n'importe quelle période, comme l'incorporation des prix élevés ou bas dans les données OHLC. Cependant, comme ces valeurs maximales/minimales ne peuvent être calculées qu'à la fin d'une période, un biais de prospection est introduit si ces valeurs sont utilisées -durant- la période en cours. Il est toujours nécessaire de dépasser les valeurs élevées/basses d'au moins une période dans toute stratégie de trading qui les utilise.

Comme pour le biais d'optimisation, il faut être extrêmement prudent pour éviter son introduction.

Le préjugé de la survie

Le biais de survie est un phénomène particulièrement dangereux et peut entraîner une performance significativement gonflée pour certains types de stratégie.

À titre d'exemple, envisagez de tester une stratégie sur une sélection aléatoire d'actions avant et après le krach du marché de 2001. Certaines actions technologiques ont fait faillite, tandis que d'autres ont réussi à rester à flot et même à prospérer. Si nous avions limité cette stratégie uniquement aux actions qui ont survécu à la période de baisse du marché, nous introduirions un biais de survie parce qu'elles nous ont déjà démontré leur succès. En fait, il ne s'agit que d'un autre cas spécifique de biais de prospective, car les informations futures sont incorporées dans l'analyse passée.

Il y a deux façons principales d'atténuer le biais de survie dans vos tests de stratégie:

  • Dans le cas des données d'actions, il est possible d'acheter des ensembles de données qui incluent des entités désenregistrées, bien qu'ils ne soient pas bon marché et ne soient généralement utilisés que par des entreprises institutionnelles.
  • Utiliser des données plus récentes - Dans le cas des actions, l'utilisation d'un ensemble de données plus récent atténue la possibilité que la sélection d'actions choisie soit pondérée à survivants, tout simplement parce qu'il y a moins de probabilité d'annulation globale des actions dans des périodes de temps plus courtes.

Nous allons maintenant examiner certains phénomènes psychologiques qui peuvent influencer vos performances commerciales.

Les préjugés en matière de tolérance psychologique

Ce phénomène particulier n'est pas souvent discuté dans le contexte du trading quantitatif. Cependant, il est largement discuté en ce qui concerne des méthodes de trading plus discrétionnaires. Il a différents noms, mais j'ai décidé de l'appeler "bias de tolérance psychologique" car il capte l'essence du problème. Lors de la création de backtests sur une période de 5 ans ou plus, il est facile de regarder une courbe de tendance haussière, de calculer le rendement annuel composé, le ratio Sharpe et même les caractéristiques de retrait et d'être satisfait des résultats.

Si des retraitements historiques de 25% ou plus se produisent dans les backtests, il est fort probable que vous verrez des périodes de retrait similaire dans le trading en direct. Ces périodes de retraitement sont psychologiquement difficiles à supporter. J'ai observé de première main à quoi ressemble un retraitement prolongé, dans un cadre institutionnel, et ce n'est pas agréable - même si les backtests suggèrent que de telles périodes se produiront. La raison pour laquelle je l'ai appelé un biais est que souvent une stratégie qui aurait autrement été réussie est arrêtée de négocier pendant les périodes de retraitement prolongé et conduira ainsi à une sous-performance par rapport à un backtest. Ainsi, bien que la stratégie soit de nature algorithmique, les facteurs psychologiques peuvent encore avoir une forte influence sur la rentabilité.

Packages logiciels pour le backtesting

Le paysage logiciel pour le backtesting de la stratégie est vaste. Les solutions vont du logiciel sophistiqué de niveau institutionnel entièrement intégré aux langages de programmation tels que C ++, Python et R où presque tout doit être écrit à partir de zéro (ou des plugins appropriés obtenus). En tant que traders quant nous sommes intéressés par l'équilibre de pouvoir posséder notre pile de technologie de trading par rapport à la vitesse et à la fiabilité de notre méthodologie de développement. Voici les principales considérations pour le choix du logiciel:

  • Compétences de programmation - Le choix de l'environnement dépendra en grande partie de votre capacité à programmer des logiciels. Je dirais que le contrôle de la pile totale aura un effet plus important sur votre P&L à long terme que l'externalisation autant que possible aux logiciels des fournisseurs. Cela est dû au risque négatif d'avoir des bugs externes ou des idiosyncrasies que vous ne pouvez pas corriger dans les logiciels des fournisseurs, qui seraient autrement facilement corrigés si vous aviez plus de contrôle sur votre tech stack. Vous voulez également un environnement qui atteint le bon équilibre entre la productivité, la disponibilité de la bibliothèque et la vitesse d'exécution.
  • Capacité d'exécution / Interaction avec le courtier - Certains logiciels de backtesting, tels que Tradestation, sont directement liés à un courtier. Je ne suis pas fan de cette approche car la réduction des coûts de transaction est souvent un élément important pour obtenir un ratio Sharpe plus élevé. Si vous êtes lié à un courtier particulier (et Tradestation vous force à le faire), vous aurez plus de mal à passer à un nouveau logiciel (ou à un nouveau courtier) si nécessaire.
  • Personnalisation - Un environnement comme MATLAB ou Python vous donne une grande flexibilité lors de la création de stratégies algo car ils fournissent des bibliothèques fantastiques pour presque toutes les opérations mathématiques imaginables, mais permettent également une personnalisation étendue si nécessaire.
  • Complicité de la stratégie - Certains logiciels ne sont tout simplement pas adaptés au traitement de nombres lourds ou à la complexité mathématique.
  • Minimisation des biais - Un logiciel ou une donnée particulier se prête-t-il davantage aux biais de négociation?
  • Vitesse de développement - On ne devrait pas avoir à passer des mois et des mois à implémenter un moteur de backtest. Le prototypage ne devrait prendre que quelques semaines. Assurez-vous que votre logiciel n'entrave pas vos progrès dans une large mesure, juste pour saisir quelques points de pourcentage supplémentaires de vitesse d'exécution.
  • Vitesse d'exécution - Si votre stratégie dépend entièrement de la rapidité d'exécution (comme dans HFT / UHFT), un langage tel que C ou C ++ sera nécessaire.
  • Coût - Beaucoup d'environnements logiciels avec lesquels vous pouvez programmer des stratégies de trading algorithmique sont entièrement gratuits et open source. En fait, de nombreux fonds spéculatifs utilisent des logiciels open source pour l'ensemble de leurs piles de trading.

Maintenant que nous avons énuméré les critères avec lesquels nous devons choisir notre infrastructure logicielle, je veux passer en revue certains des paquets les plus populaires et comment ils se comparent:

Remarque: je vais inclure uniquement des logiciels qui sont disponibles pour la plupart des praticiens de la vente au détail et les développeurs de logiciels, car c'est le lectorat du site.

Comparaison des logiciels de contre-test

MS Excel

Description: logiciel de feuille de calcul WYSIWYG (what-you-see-is-what-you-get). extrêmement répandu dans le secteur financier. les données et l'algorithme sont étroitement couplés.

Exécution: Oui, Excel peut être lié à la plupart des courtiers.

Personnalisation: Les macros VBA permettent des fonctionnalités plus avancées au détriment de la mise en œuvre cachée.

Complexité de la stratégie: les outils statistiques les plus avancés sont plus difficiles à mettre en œuvre que les stratégies avec des centaines d'actifs.

Minimisation du biais: le biais prospectif est facile à détecter via la fonctionnalité de mise en évidence des cellules (en supposant qu'il n'y ait pas de VBA).

Vitesse de développement: Rapide mise en œuvre des stratégies de base.

Vitesse d'exécution: vitesse d'exécution lente - ne convient qu'aux stratégies à basse fréquence.

Coût: Pas cher ou gratuit (selon la licence).

Alternatives: OpenOffice

MATLAB

Description: Environnement de programmation conçu à l'origine pour les mathématiques computationnelles, la physique et l'ingénierie. Très bien adapté aux opérations vectoriées et à celles impliquant l'algèbre linéaire numérique. Fournit un large éventail de plugins pour le trading quantique. Largement utilisé dans les hedge funds quantitatifs.

Exécution: Pas de capacité d'exécution native, MATLAB nécessite un système d'exécution séparé.

Personnalisation: énorme gamme de plugins communautaires pour presque tous les domaines des mathématiques computationnelles.

Complexité de la stratégie: de nombreuses méthodes statistiques avancées sont déjà disponibles et bien testées.

Minimisation des biais: plus difficile à détecter que les préjugés anticipés, nécessitant des tests approfondis.

Vitesse de développement: Des scripts courts peuvent facilement créer des backtests sophistiqués.

Vitesse d'exécution: en supposant un algorithme vectorié/parallélisé, MATLAB est hautement optimisé.

Coût: environ 1 000 USD pour une licence.

Des alternatives: Octave, SciLab

Python

Description: Langage de haut niveau conçu pour la vitesse de développement. Large gamme de bibliothèques pour presque toutes les tâches programmatiques imaginables. Gagner une plus grande acceptation dans la communauté des hedge funds et des banques d'investissement. Pas aussi rapide que C / C ++ pour la vitesse d'exécution.

Exécution: Les plugins Python existent pour les plus grands courtiers, tels que Interactive Brokers.

Personnalisation: Python a une communauté de développement très saine et est un langage mature.

Complexité de la stratégie: De nombreux plugins existent pour les principaux algorithmes, mais pas tout à fait une communauté quantique aussi grande qu'il existe pour MATLAB.

Minimisation des biais: les mêmes problèmes de minimisation des biais existent que pour tout langage de haut niveau.

Vitesse de développement: Le principal avantage de Python est la vitesse de développement, avec des capacités de test robustes.

Vitesse d'exécution: pas aussi rapide que C++, mais les composants informatiques scientifiques sont optimisés et Python peut communiquer avec le code natif C avec certains plugins.

Coût: gratuit ou open source

Des solutions alternatives: Ruby, Erlang, Haskell

R

Description: Environnement conçu pour les méthodes statistiques avancées et l'analyse des séries temporelles. Large gamme d'outils statistiques, économétriques et natifs.

Exécution: R possède des plugins pour certains courtiers, en particulier Interactive Brokers.

Personnalisation: R peut être personnalisé avec n'importe quel package, mais ses points forts se trouvent dans les domaines statistique/économétrique.

Complexité de la stratégie: principalement utile lors de l'exécution de stratégies économétriques, statistiques ou d'apprentissage automatique en raison des plugins disponibles.

Minimisation des biais: possibilité de biais similaire pour tout langage de haut niveau tel que Python ou C++. Il faut donc effectuer des tests.

Vitesse de développement: R est rapide pour écrire des stratégies basées sur des méthodes statistiques.

Vitesse d'exécution: R est plus lent que C++, mais reste relativement optimisé pour les opérations vectorielles (comme avec MATLAB).

Coût: gratuit ou open source

Alternatives: SPSS et Stata

C++

Description: Langage mature et de haut niveau conçu pour la vitesse d'exécution. Large gamme de finance quantitative et de bibliothèques numériques. Plus difficile à déboguer et prend souvent plus de temps à implémenter que Python ou MATLAB. Extrêmement répandu à la fois du côté de l'achat et de la vente.

Exécution: La plupart des API de courtage sont écrites en C++ et Java.

Personnalisation: C/C++ permet un accès direct à la mémoire sous-jacente, de sorte que des stratégies à très haute fréquence peuvent être mises en œuvre.

Complicité de la stratégie: C++ STL fournit un large éventail d'algorithmes optimisés.

Bias Minimisation: Le biais de prospective peut être difficile à éliminer, mais pas plus difficile que les autres langages de haut niveau.

Vitesse de développement: C++ est assez verbale par rapport à Python ou MATLAB pour le même algorithme.

Vitesse d'exécution: C/C++ a une vitesse d'exécution extrêmement rapide et peut être bien optimisée pour des architectures informatiques spécifiques.

Coût: Différents compilateurs: Linux/GCC est gratuit, MS Visual Studio dispose de licences différentes.

Des alternatives: C#, Java, Scala

Les stratégies HFT et UHFT seront écrites en C/C++ (aujourd'hui, elles sont souvent exécutées sur GPU et FPGA), tandis que les stratégies directionnelles à basse fréquence sont faciles à mettre en œuvre dans TradeStation, en raison de la nature "tout en un" du logiciel / courtage.

Ma préférence personnelle est pour Python car il fournit le bon degré de personnalisation, la vitesse de développement, la capacité de test et la vitesse d'exécution pour mes besoins et stratégies. Si j'ai besoin de quelque chose de plus rapide, je peux drop in à C++ directement à partir de mes programmes Python. Une méthode privilégiée par de nombreux traders quant est de prototyper leurs stratégies en Python et de convertir ensuite les sections d'exécution plus lentes en C++ de manière itérative.

Dans les prochains articles sur le backtesting, nous examinerons certaines questions particulières entourant la mise en œuvre d'un système de backtesting algorithmique de trading, ainsi que la façon d'incorporer les effets des bourses de trading.


Plus de