L'article est adapté à ceux qui commencent le trading quantitatif ainsi qu'à ceux qui ont une certaine expérience dans ce domaine.
Il examine également les différents types de mécanismes de backtesting ainsi que le paysage logiciel qui implémente ces approches.
Enfin, nous discutons des tenants et aboutissants d'un système de backtesting basé sur des événements, un sujet que j'ai souvent abordé sur QuantStart dans des articles précédents.
Un backtest est l'application de règles de stratégie de négociation à un ensemble de données historiques sur les prix. Autrement dit, si nous définissons un ensemble de mécanismes d'entrée et de sortie d'un portefeuille d'actifs, et appliquons ces règles aux données historiques de prix de ces actifs, nous pouvons tenter de comprendre le rendement de cette "stratégie de négociation" qui aurait pu être atteinte dans le passé.
Il a été dit une fois que
Les backtests nous aident finalement à décider s'il vaut la peine de négocier en direct un ensemble de règles de stratégie. Il nous donne une idée de la façon dont une stratégie aurait pu fonctionner dans le passé.
Il est facile de générer des backtests. Malheureusement, les résultats des backtests ne sont pas des résultats de trading en direct. Ils sont plutôt un modèle de la réalité. Un modèle qui contient généralement de nombreuses hypothèses.
Il existe deux principaux types de backtest de logiciels: les systèmes
Lors de la conception de logiciels de backtesting, il existe toujours un compromis entre la précision et la complexité de la mise en œuvre.
Il existe de nombreux pièges associés au backtesting. Ils concernent tous le fait qu'un backtest est juste un modèle de la réalité.
Il y a des problèmes plus subtils avec le backtesting qui ne sont pas discutés aussi souvent, mais qui sont encore extrêmement importants à considérer.
Tucker Balch et Ernie Chan ont tous deux examiné les problèmes en détail.
Un For-Loop Backtester est le type le plus simple de système de backtesting et la variante la plus souvent vue dans les articles de blog quant, purement pour sa simplicité et sa transparence.
Essentiellement, le système For-Loop itère sur chaque jour de négociation (ou barre OHLC), effectue un calcul lié au prix des actifs, comme une moyenne mobile de la clôture, puis va long ou court sur un actif particulier (souvent au même prix de clôture, mais parfois le lendemain).
Voici le pseudo-code d'un tel algorithme:
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
Comme vous pouvez le voir, la conception d'un tel système est incroyablement simple.
Les backtesters For-Loop sont faciles à mettre en œuvre dans presque tous les langages de programmation et sont très rapides à exécuter.
Le principal inconvénient des backtests For-Loop est qu'ils sont assez irréalistes. Ils n'ont souvent aucune capacité de coût de transaction à moins d'être spécifiquement ajoutés. Les ordres sont généralement remplis immédiatement au marché avec le prix du point médian.
Il y a une réutilisation minimale du code entre le système de backtesting et le système de trading en direct.
Les backtesters For-Loop sont sujets aux biais Look-Ahead, en raison de bugs avec l'indexation. Par exemple, auriez-vous dû utiliser
Les backtesters For-Loop devraient vraiment être utilisés uniquement comme un mécanisme de filtration. Vous pouvez les utiliser pour éliminer les stratégies évidemment mauvaises, mais vous devriez rester sceptique sur les performances fortes. Des recherches supplémentaires sont souvent nécessaires. Les stratégies fonctionnent rarement mieux dans le trading en direct que dans les backtests!
Les backtesters basés sur les événements se situent à l'autre extrémité du spectre. Ils sont beaucoup plus proches des implémentations d'infrastructures de trading en direct.
Ces systèmes sont exécutés dans une grande boucle qui recherche continuellement des événements de différents types dans la file d'attente.
Lorsqu'un événement particulier est identifié, il est acheminé vers les modules appropriés de l'infrastructure, qui gèrent l'événement et génèrent ensuite potentiellement de nouveaux événements qui retournent à la file d'attente.
Le pseudo-code pour un système de backtesting basé sur des événements est le suivant:
while event_queue_isnt_empty():
event = get_latest_event_from_queue();
if event.type == "tick":
strategy.calculate_trading_signals(event);
else if event.type == "signal":
portfolio.handle_signal(event);
else if event.type == "order":
portfolio.handle_order(event);
else if event.type == "fill":
portfolio.handle_fill(event)
sleep(600); # Sleep for, say, 10 minsPythonCopy
Comme vous pouvez le voir, il y a une forte dépendance au module gestionnaire de portefeuille.
Il y a de nombreux avantages à utiliser un backtester Event-Driven:
Bien que les avantages soient évidents, l'utilisation d'un système aussi complexe présente également de sérieux inconvénients:
Dans cette section, nous examinerons les logiciels (à la fois open source et commerciaux) qui existent pour les systèmes For-Loop et Event-Driven.
Pour les backtesters For-Loop, les principaux langages de programmation/logiciels utilisés sont Python (avec la bibliothèque Pandas), R (et la bibliothèque quantmod) et MatLab.
Le marché des systèmes basés sur les événements est beaucoup plus vaste, car les clients/utilisateurs souhaitent souvent que le logiciel soit capable à la fois de backtesting et de trading en direct dans un seul package.
Les offres commerciales coûteuses incluent Deltix et QuantHouse.
Quantpian est un exemple d'une configuration Web mature pour le backtesting et le trading en direct.
Les quants institutionnels construisent souvent leur propre logiciel en interne, ce qui est dû à une combinaison de contraintes réglementaires, de relations avec les investisseurs/d'établissement de rapports et d'audit.
Les détaillants ont le choix entre l'utilisation de l'approche
En termes de logiciels open source, il existe de nombreuses bibliothèques disponibles. Elles sont principalement écrites en Python (pour des raisons que je détaillerai ci-dessous) et comprennent Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) et QSTrader (le propre backtester de QuantStart
L'un des aspects les plus importants, cependant, est que peu importe le logiciel que vous utilisez en fin de compte, il doit être associé à une source de données financières tout aussi solide.
Bien que le logiciel s'occupe des détails pour nous, il nous cache de nombreux détails d'implémentation qui sont souvent cruciaux lorsque nous souhaitons étendre la complexité de notre stratégie de trading.
Malgré mes antécédents de développeur de logiciels quantitatifs, je ne suis pas personnellement intéressé par les "guerres linguistiques".
Nous ne devrions nous intéresser qu'à ce qui fonctionne.
Python est un langage de programmation extrêmement facile à apprendre et est souvent le premier langage auquel les individus entrent en contact lorsqu'ils décident d'apprendre à programmer.
Il possède des bibliothèques d'apprentissage automatique (ML) exceptionnelles dans NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 et Statsmodels.
Il est idéal pour la construction de systèmes de backtesting à la fois For-Loop et Event-Driven. En fait, c'est peut-être l'un des seuls langages qui permet directement la recherche de bout en bout, le backtesting, le déploiement, le trading en direct, les rapports et la surveillance.
Peut-être son plus grand inconvénient est-il qu'il est assez lent à exécuter par rapport à d'autres langages tels que C ++. Cependant, des travaux sont en cours pour améliorer ce problème et au fil du temps Python devient plus rapide.
R est un environnement de programmation statistique, plutôt qu'un "langage de programmation de première classe" à part entière (bien que certains puissent argumenter le contraire!).
Il est largement utilisé pour le backtesting For-Loop, souvent via la bibliothèque quantmod, mais n'est pas particulièrement bien adapté aux systèmes Event-Driven ou au trading en direct.
C++ a la réputation d'être extrêmement rapide. Presque tous les calculs scientifiques à haute performance sont effectués en Fortran ou en C++. C'est son principal avantage. Par conséquent, si vous envisagez de négocier à haute fréquence ou de travailler sur des systèmes hérités dans de grandes organisations, alors C++ est probablement une nécessité.
Malheureusement, il est douloureux pour mener des recherches stratégiques.
Malgré son âge relatif, il a récemment été considérablement modernisé avec l'introduction de C++11/C++14 et d'autres améliorations des normes.
Vous voudrez peut-être également jeter un coup d'œil à Java, Scala, C #, Julia et à de nombreux langages fonctionnels.
Réponse: Oui!
C'est une grande expérience d'apprentissage d'écrire votre propre système de backtesting Event-Driven. Premièrement, il vous oblige à considérer tous les aspects de votre infrastructure de trading, pas seulement passer des heures à bricoler sur une stratégie particulière.
Même si vous ne finissez pas par utiliser le système pour le trading en direct, il vous fournira un grand nombre de questions que vous devriez poser à vos fournisseurs de backtesting commerciaux ou FOSS.
Par exemple: en quoi votre système en direct actuel diffère de votre simulation de backtest en termes de:
Bien que les systèmes basés sur des événements ne soient ni rapides ni faciles à écrire, l'expérience vous rapportera des dividendes éducatifs énormes plus tard dans votre carrière de trader quantique.
Comment écrire un tel système?
La meilleure façon de commencer est de télécharger simplement Zipline, QSTrader, PyAlgoTrade, PySystemTrade, etc. et d'essayer de lire la documentation et le code. Ils sont tous écrits en Python (en raison des raisons que j'ai décrites ci-dessus) et heureusement Python est très similaire à la lecture de pseudo-code. C'est-à-dire qu'il est très facile à suivre.
J'ai également écrit de nombreux articles sur la conception de backtests basés sur des événements, que vous pouvez trouver ici, qui vous guident à travers le développement de chaque module du système.
N'oubliez pas que vous n'avez pas besoin d'être un expert le premier jour. Vous pouvez le faire lentement, jour après jour, module par module. Si vous avez besoin d'aide, vous pouvez toujours me contacter ou d'autres blogueurs quant. Voir la fin de l'article pour mon email de contact.
Je vais maintenant discuter des modules que l'on trouve souvent dans de nombreux systèmes de backtesting basés sur des événements.
C'est ici que sont stockées toutes les données de prix historiques, ainsi que votre historique de trading, une fois en ligne.
Au lieu de cela, nous utilisons une base de données ou un système de fichiers de première classe, tels que PostgreSQL, MySQL, SQL Server ou HDF5.
Dans l'idéal, nous voulons obtenir et stocker des données de niveau de tick car cela nous donne une idée des spreads de trading.
Nous devrions toujours être conscients de la gestion des actions d'entreprise (comme les scissions d'actions et les dividendes), le biais de survie (suppression de la cotation des actions) ainsi que le suivi des différences de fuseau horaire entre les différents échanges.
Les entreprises individuelles/de détail peuvent y concurrencer, car de nombreuses technologies de base de données de qualité de production sont matures, gratuites et open source.
Il y a encore beaucoup de marchés et de stratégies qui sont trop petits pour que les grands fonds s'y intéressent.
Le module de stratégie de négociation dans un système basé sur des événements exécute généralement une sorte de mécanisme de prédiction ou de filtration sur les nouvelles données du marché.
Il reçoit des données bar ou tick, puis utilise ces mécanismes pour produire un signal de trading pour long ou short d'un actif.
95% de la discussion sur le blog quant tourne généralement autour des stratégies de trading. Personnellement, je pense qu'il devrait être plus proche de 20%. C'est parce que je pense qu'il est beaucoup plus facile d'augmenter les rendements attendus en réduisant les coûts grâce à une bonne gestion des risques et à la dimensionnement des positions, plutôt que de poursuivre des stratégies avec
Le cœur d'un backtester basé sur les événements est le système de gestion de portefeuille et de commandes.
L'objectif de ce système est de passer du portefeuille actuel au portefeuille souhaité, tout en minimisant les risques et en réduisant les coûts de transaction.
Le module relie les capacités de stratégie, de risque, de dimensionnement des positions et d'exécution des ordres du système.
L'avantage principal de l'utilisation d'un système aussi complexe est qu'il permet de gérer une variété d'instruments financiers dans un seul portefeuille.
La séparation de la gestion des risques dans son propre module peut être extrêmement avantageuse. Le module peut modifier, ajouter ou opposer son veto aux ordres envoyés depuis le portefeuille.
En particulier, le module de risque peut ajouter des couvertures pour maintenir la neutralité du marché. Il peut réduire la taille des commandes en raison de l'exposition du secteur ou des limites ADV. Il peut complètement opposer son veto à une transaction si l'écart est trop large ou si les frais sont trop élevés par rapport à la taille de la transaction.
Un module de dimensionnement des positions séparé peut implémenter des règles d'estimation de la volatilité et de dimensionnement des positions telles que le levier Kelly.
Ces sujets ne sont pas bien représentés dans la blogosphère quant. Cependant, c'est probablement la plus grande différence entre la façon dont les institutions et certains traders de détail pensent à leur trading.
Dans la vie réelle, on ne peut jamais garantir un marché plein à mi-chemin.
Nous devons prendre en compte les problèmes de transaction tels que la capacité, le spread, les frais, les glissements, l'impact sur le marché et d'autres préoccupations d'exécution algorithmique, sinon nos rendements de backtesting sont susceptibles d'être largement surestimés.
L'approche modulaire d'un système Event-Driven nous permet de remplacer facilement le BacktestExecutionHandler par le LiveExecutionHandler et de le déployer sur le serveur distant.
Nous pouvons également facilement ajouter plusieurs courtiers en utilisant le concept OOP de
Il existe de nombreux modules qui facilitent la communication avec les courtiers, mais il est nécessaire d'effectuer vos propres tests. Assurez-vous que vous êtes complètement satisfait de ces bibliothèques avant de vous engager sur un capital important, sinon vous pourriez perdre beaucoup d'argent simplement en raison de bugs dans ces modules.
Les clients de détail peuvent et doivent emprunter les techniques de reporting sophistiquées utilisées par les clients institutionnels. Ces outils comprennent des tableaux de bord en direct du portefeuille et des risques correspondants, une différence ou un delta entre les fonds propres en cours de test et les fonds propres en cours de test, ainsi que toutes les mesures habituelles telles que les coûts par transaction, la distribution des rendements, la marge d'eau élevée (HWM), le tirage maximal, la latence moyenne des transactions ainsi que l'alpha/bêta par rapport à un indice de référence.
Il faut améliorer progressivement l'infrastructure. Cela peut vraiment améliorer les rendements à long terme, simplement en éliminant les bugs et en améliorant les problèmes tels que la latence des échanges.
Le WGS finira par s'éroder en raison de la désintégration de l'alpha. D'autres finissent par découvrir l'avantage et vont arbitrager les rendements. Cependant, une infrastructure de trading robuste, un pipeline de recherche stratégique solide et un apprentissage continu sont d'excellents moyens d'éviter ce sort.
L'optimisation de l'infrastructure peut être plus "ennuyeuse" que l'élaboration de stratégies, mais elle devient nettement moins ennuyeuse lorsque vos rendements sont améliorés!
Le déploiement sur un serveur distant, ainsi qu'une surveillance approfondie de ce système distant, sont absolument cruciaux pour les systèmes institutionnels.
Un système robuste doit être déployé à distance dans le cloud ou co-loqué à proximité d'un échange. Le haut débit à domicile, les alimentations électriques et d'autres facteurs signifient que l'utilisation d'un ordinateur de bureau / ordinateur portable à domicile est trop peu fiable.
Les principaux enjeux lors de l'examen d'un déploiement à distance comprennent: le matériel de surveillance, tel que le processeur, la RAM/swap, les entrées/sorties de disque et de réseau, la haute disponibilité et la redondance des systèmes, un plan de sauvegarde et de restauration bien pensé, une comptabilisation approfondie de tous les aspects du système ainsi que l'intégration continue, les tests unitaires et le contrôle des versions.
Rappelez-vous la loi de Murphy - Si cela peut échouer, cela échouera.
Il existe de nombreux fournisseurs qui offrent des déploiements cloud relativement simples, notamment Amazon Web Services, Microsoft Azure, Google et Rackspace.
Malheureusement, il n'y a pas de solution rapide dans le commerce quantitatif.
L'un des principaux obstacles pour les débutants (et certains intermédiaires!) est peut-être qu'ils se concentrent trop sur la meilleure
Il vaut également la peine d'investir beaucoup de temps dans votre infrastructure commerciale. Passez du temps sur des questions telles que le déploiement et la surveillance. Essayez toujours de réduire les coûts de transaction, car la rentabilité consiste autant à réduire les coûts que de gagner des revenus commerciaux.
Je recommande d'écrire votre propre système de backtesting simplement pour apprendre. Vous pouvez soit l'utiliser et l'améliorer continuellement ou vous pouvez trouver un fournisseur et leur poser toutes les questions que vous avez découvertes lorsque vous avez construit le vôtre. Cela vous rendra certainement conscient des limites des systèmes disponibles dans le commerce.
Il existe une multitude de manuels, de revues professionnelles, de revues académiques, de blogs quantitatifs, de forums et de magazines qui discutent de tous les aspects du trading.