Trading Automatque - Contrôle des pertes

Un des problèmes lié au trading automatique, c'est que l'on n'est jamais sûr que la stratégie mise au point en backtesting va se comporter comme prévu en réel:

- Elle peut être sur-optimiser sur les données de tests
- Le comportement du marché peut avoir changer au moment de la mise en réel vs la période de test
- Il peu rester des bugs lié a des situations non vu en test qui peuvent la faire dérailler
- Même si la stratégie est profitable un temps, elle peut ne plus être adaptée au comportement de marché après quelques temps d'utilisation.
- La stratégie peut être profitable sur certaines phase de marché, et pas sur d'autres, sans qu'on ai trouvé un filtre permettant de supprimer les trades des périodes non profitable.

Pour toutes ces raisons, j'ai chercher un système de sécurité permettant de limiter la casse si l'un de ses événement arrive.
Et j'ai fini par mettre au point un système assez efficace de contrôle du drawdown sans trop impacter les performances de la stratégie.

Ce système est assez complexe à mettre en oeuvre dans la mesure ou quand il s'active, il faut pouvoir simuler les ordres pour calculer de statistiques, ce qui n'est pas forcement faisable sur toutes les plateformes, je précise que je programme sur NinjaTrader 7 (bientôt 8) en C#, et que par ce langage, il n'y a pas de limite à la complexité de ce que l'on peu programmer, NinjaTrader permettant de charger des DLL externe pour ajouter des interfaces/API/fonctionnalités.

J'ai donc écrit un simulateur d'ordre qui permet de gérer les entrée en position suivant les différent type d'ordre, les stop lost, stop suiveur et objectifs, et permet de savoir si un ordre (non prit) aurait été gagnant ou perdant, et de combien, de la même façon que si il avait été prit en réel (au différences de filling prêt), le résultats étant assez précis par rapport à l'objectif.

Ensuite la stratégie a des variables qui indique la perte maximummum avant d’enclencher le système, ainsi que d'autres variables indiquées plus bas.

Quand la perte MAX est atteinte => le système s'active, les ordres de la stratégie sont alors prit en simulation.

Le système calcul les drawdown courant, max et de combien on à remonté vs le DD max.
Quand le DD a été remonté d'une valeur RecoveryMini (pas la totalité du drawdown, enfin par forcement), alors les trades repassent en réel, et on autorise un dépassement du Max d'un DDIncrement, qui devient le nouveau DD MAX.
Si la stratégie échoue et atteins de nouveau le nouveau DD Max, on repasse ne simulation, le Recovery nécessaire pour redémarrer en réel augmente d'un incrément et on recommence le process.
Si la stratégie remonte tout le drawdown, alors les valeurs des DDMAX, incrément etc repasse aux valeurs initiales.

Ce système permet:
- Chaque fois que la stratégie échoue à redémarrer et touche sont DDMAX courant, la quantité de recovery (gain) a faire augmente, donc une stratégie qui n'arrive pas a remonter son DD et s'enfonce fini par en plus fonctionner qu'en simulation, car il est de plus en plus difficile pour la stratégie de repasser en réel.

Si la stratégie bug et encaisse des pertes a cause de ces bugs, elle ne fonctionne assez rapidement qu'en simulation.

Si une stratégie gagne pendant certaine période et perds pendant, d'autre, elle peu devenir rentable grâce a se système qui va limiter les pertes.


Sur une stratégie gagnant environ 12000$ en trois mois (600 trades) avec un DD MAX de 4000$, ce système a permis de conserver 10500$ de gains, avec une réduction du drawdown à 1200$, ceci avec des paramètres de DDMAX Initiaux/Seuils de recovery, incrément de drawdown de 400/400/400.

Il m'a aussi permis de rendre rentable des stratégie qui ont des période de gains et des période de pertes suivant le marchés, sans que je ne trouve de critère permettant de gérer les périodes de pertes au niveau de la stratégie.

Je suis bien conscient que cela est assez complexe, pas réalisable dans toutes les plateformes. En Contrepartie, couplé a un bon monnaie management, ce système est redoutable d'efficacité.

Qu'en pensez-vous, d'autres ont-ils mis en place un système similaire de contrôle des pertes ? et de qu'elle façon ?

Je suis intéresse par l’échange d’expérience et idée autour de ce thème.

Merci pour ton partage Twanaar.

Spoiler:

Une petite suggestion : au lieu de montants en devise,
ce serait plus clair si c'était des points/lot

Intéressant, tu fais cela sur qu'elle unité de temps ou peu être de ticks ?

Spoiler:

Ou en pourcentage c'est bien aussi

Merci pour ce partage
En ce qui me concerne la partie que je trouve la plus novatrice dans ton approche est cette notion de simulation qui permet ensuite, selon paramétrage, de décider de revenir au réel quand le système de trading semble mieux fonctionner dans le contexte.
Je perçois intuitivement une autre application de cette façon de procéder, qui dépendra du type de supports choisis et qui n'aurait pas pour but premier de minimiser les DD mais de maximummiser les rendements (et donc indirectement minimiser aussi les DD).

Il s'agirait d'appliquer une méthode statistique similaire pour choisir la modalité i dans un segment X.
Exemples: une modalité du choix de la paire sur le segment du Forex, une modalité de choix géographique (Allemagne, USA, France...) sur le segment des indices boursiers etc...
Le système de trading serait appliqué en simulation parallèle à toutes les modalités et le passage d'ordre en réel se ferait évidemment sur l'option la plus favorable, selon paramétrage.
Je pense que ceci serait nettement plus favorable car cela te permettrait d'éviter les phases d'attente de remontées de DD !
Car à mes yeux le système actuel, comme tu l'as souligné, a fatalement tendance à réduire les perfs en te faisant "mouliner à vide".

Pas mal comme idée.

Donc si je comprends le principe que tu met derrièer c'est d considérer que si une stratégie atteins le DD max initial (ou avec seuil) alors elle entre dans une phase de non profitabilité.

Tu as quel fenêtre de recul ? Uniquement 3 mois ou plus (genre 3 ans par exemple).

Effectivement, coder ça dans prt ... demande une certaine gymnastique

Je trouve ça très prometteur comme piste d'études - merci.
Néanmoins, ça implique de garder inchangé son algo. Du coup, difficile de dire si c'est une méthode plus efficace que les ajustements à chaque mv. Mais peut-être as-tu étudié le sujet ?

@Ano782345:

J'ai plusieurs stratégie, certaines fonctionneent en 5mn, 1min avec getion de l'entrée au tick (sur dépassement d'un prix), d'autre en graph non temporel, une version derivée du linebreak.

Le % c'ets bien certe, mais pour le moment mes stratégie fonctionne en taille de position fixe, quand mon capital aurra sufifsament augmenté, je passerai sans doute en taille dynamique de position avec le monaie management + gestion en % de divers paramêtres.

@Takapoto:

Certe, mais mes stratégies fonctionnent sur les contrats futur, et l'unité et le point qui vaut une certaine valeur.

De toute façon l'explication est pour comprendre le principe, la valeur importe peu et est a adapté a chaque stratégie/Instrument.

@Euraed:

Très juste, d'ailleurs j'utilise déjà cela d’une façon différente, mes stratégies sont sur les contrats futurs sur indices principalement, et Ninjatrader permettant de lancer plusieurs stratégies sur le même compte (du moment que chaque stratégie soit sur un instrument différents), je lance simplement plusieurs stratégies intégrant le système de contrôle de perte: ainsi les stratégies qui performent passent leurs ordres en réel, les autres en simu en attendant des jours meilleurs.

J’ai une autre utilisation que je n’ai pas encore mise en œuvre de ce système :
Pour une stratégie qui a des réglages fonctionnant mieux suivant des comportements de marché, on peut exécuter en simulation toutes les variations de réglages valides que l’on a identifiés en backtest, et exécuter en réel la version qui a les meilleurs résultats actuelement. Avec ce système on peut envisager d’exécuter une stratégie en permanence sur-optimisée à la situation actuelle, du moins si la sur-optimisation n’est pas trop extrême et reste valide quelques temps. On peut aussi de façon moins extrême utiliser ce principe pour avoir une stratégie qui s’adapte à la situation de marché via un ranges de paramètre qui fonctionnent en simulation, range de paramètres identifié lors des backtests sur diverses situation de marchés. Bref ça offre pas mal de voies de recherche, que je n’ai pas toute explorées.

Le système sur des stratégies qui ont des DD épisodiques a tendance à diminuer les gains et le DD. Sur les stratégies qui ont régulièrement des périodes de fort DD et de gains, cela réduit le DD et augmente les gain (on ne s'enfonce pas autant en DD, du coup lors de la remonté on engrange des gains supplémentaires puisqu'on a pas pris les pertes correspondantes en réel.
Ce qui marche moins bien, c’est les stratégies qui ont tendance a alterner très rapidement gains/perte, comme le système attends un gain suffisant pour repasser en réel, le gain n'est pas fait en réel, et si lors du basculement en réel on se prend un perte, on creuse le DD et on repasse en simulation (cette exemple est caricatural, mais c'est pour expliquer le principe), c'est là qu'intervient les incréments sur les valeurs de reprise en réel : à chaque échec pour éviter de perdurer dans ce cycle néfaste les conditions de reprise en réel deviennent plus drastiques, rapidement les condition de reprise en réel dépasse les gains que peux faire la stratégie et on reste en simu tant que la situation perdure.

Mes premières versions du système avaient des critères de reprise en réel constant, et échouait sur ce cette situation ce qui aggravait le DD et perte (la situation extrême étant une stratégie qui fait 1 ordre gagnant > au critères de reprise et un ordre perdant > au DD max en boucle, dans ce cas de figure on ne prend en réel que les ordres perdant avec des paramètres fixe, d'où les critères incrémentaux a chaque échecs de reprise).

@Falex:

Pour mes backtest, je dispose de data en minutes depuis 1978 à aujourd'hui sur pratiquement tout les instruments de contrats futur utilisable avec NinjaTrader et des data replay en ticks par tick depuis 2009 à aujourd'hui.

En réel, j'ai une stratégie qui fonctionne depuis un an, une autre depuis janvier 2017 et deux autres depuis un ou deux mois.

Je trouve ça très prometteur comme piste d'études - merci.
Néanmoins, ça implique de garder inchangé son algo. Du coup, difficile de dire si c'est une méthode plus efficace que les ajustements à chaque mv. Mais peut-être as-tu étudié le sujet ?

En fait non, je change et améliore aussi mes algos / paramêtres.
Aprés mon systéme me permet ou pas de reseter les stats quand je relance une stratégie, suivant si je pense que les changements d'algo justifient de ne pas utiliser les stats passés.
De toute façon modifié ou non, si le systéme est en réel et que la stratégie performe, ça reste en réel, si la stratégie ne performe pas ça va vite passer en simulation.
De même si intialement la startégie était en simualtion, si elle continue de ne pas performer elle va rester en simulation, si suite aux changements elle devient performante, elle va rapidement repasser en réel.

Donc le contrôle des pertes n'est pas du tout exclusif et peut etre combiné avec des otpimisations réguliéres (voir automatique via ce systéme, voir plus haut) de la stratégie.

pour les explications.

Good. En tout cas très intéressant comme idée.

Qu'est-ce qui t'a mené à avoir ce genre de traitement ? car l'hypothèse que le non trade est plus safe que le trade dépend pour beaucoup de la répartotoon des trades et leur ordonnancement.

Good. En tout cas très intéressant comme idée.

Qu'est-ce qui t'a mené à avoir ce genre de traitement ? car l'hypothèse que le non trade est plus safe que le trade dépend pour beaucoup de la répartotoon des trades et leur ordonnancement.

Simplement le fait que j'arrive a faire des stratégies qui gagnent beaucoup sur certaines périodes, mais qui perdent aussi beaucoup à d'autres et que par ailleurs que je ne trouvais pas de critéres qui permetterai de filtrer les trades perdants sans trop degrader les perfs.
D'ou le fait qu'a force de réfléchir au probléme, j'ai fini par aller vers cette solution indépendante de la stratégie, basé sur les résultats de la stratégie elle-même plutôt qu'un indicateur qui reste potentiellement peu fiable. En gros l'idée de base à été: le meilleurs indicateur que la stratégie performe ou pas est ses résultats, donc de fils en aiguille du fait qu'il était necessaire d'avoir un systéme de simulation qui permet de monitorer ce que fait la stratégie sans passer les ordres.

Il y a aussi le fait que je cherchait un moyen de reduire les drawdown sans pour autant reduire (beaucoup) les perfs de mes stratégies, ce que je n'arrivait pas a faire via des moyens classique (indicateurs, réglages, filtres). En fai tmême au départ, je penssais que ce systéme allait augmenter systématiquement les gains aussi, vu que la totalité du drawdown de la stratégie n'est pas prit en réel, mais la réalité à montrer que ce n'est pas toujours le cas.

De plus cela sert aussi de fillet de sécuritée, si pour une raison ou une autre une stratégie deraille, ce systéme va limiter les pertes et va éviter de cramer un compte.

J'ai tenté d'ajouter cette notion de mode simulation avec trades virtuels en parallèle des trades normaux dans mes backtests mais hélas le résultat n'est pas terrible: j'ai quasi systématiquement des résultats plus mauvais (en terme de gain moyen par trade ou de % de trades gagnants ou de ratio gain/MaxDD).
Donc ça confirme que cette technique n'est adaptée qu'à certains types de systèmes de trading.

J'ai testé 2 approches différentes : soit limiter la MaxDD à un certain seuil avant de passer en mode simulation (je ne repasse en mode normal que si la MaxDD virtuelle redevient inférieure au seuil), soit limiter le nb de trades successifs perdants.
Ca peut fonctionner sur certaines périodes (comme 2012/2017) , mais sur une longue période (2004/2017) je n'ai pas réussi.

Attention, une version simpliste du systéme provoque ce que tu dis, c'était mon premier systémle de contrôle du DrawDawn, pour que cela fonctionne
la gestion des conditions de reprise est plus delicate., je detaillerai un peu plsu tard.

OK j'ai essayé d'aller au plus simple, je n'y ai consacré que quelques heures de boulot. Sans doute un mécanisme plus évolué donnera de meilleurs résultats.

voila en simplifié (mais complet) l'algo que j'utilise, et qui devrait fonctionner sur la plupart des stratégie
il faut bien sur changer les valeurs d'init en fonction de sa stratégie (a partir de quelle valeur une perte est anormal, les incrments etc

Base de l’algo de contrôle de perte qui fonctionne :

// Inits

DrawDownMax = 400
BaseDrawDown = 400
IncrementDrawDown = 400
MinRecovery = 400
BaseRecovery = 400
CurrentDay = Horaire:CurrentDay //Lundi / mardi etc..

// avant d’aller dans la partie de la stratégie qui attend un point d’entrée, j’effectue ces tests
Si EngineIndicator:StrategyActualDrawDown == 0 alors DrawDownInitiale
Si (
// ici il s’agit de script en lua extrait de mon système)
// ça reste néanmoins facilement compréhensible pour adapter à un autre système
EngineIndicator:StrategyActualDrawDown >= @DrawDownMax &&
(
(
@CurrentDay != Horaire:CurrentDay &&
(EngineIndicator:StrategyIndicatorMaxDrawDown -EngineIndicator:StrategyIndicatorActualDrawDown >= @MinRecovery || EngineIndicator:StrategyIndicatorActualDrawDown == 0)
)
||
EngineIndicator:LastTradeResult > (@MinRecovery/2) // lasttraderesult somme les x dernier resultat des trade (chez moi typiquement les 4 derniers)
)
Alors ResetDrawDown
Si EngineIndicator:StrategyActualDrawDown <= @DrawDownMax alors NormalMode
Si EngineIndicator:StrategyActualDrawDown > @DrawDownMax alors WaitRecovery
DrawDownInitiale()
{
// restaure les params aux valeurs initales car le DD a été resorbé
DrawDownMax = @BaseDrawDown
MinRecovery = @BaseRecovery
Passage du moteur en mode réel
Go attente point d’entrée de la stratégie
}

ResetDrawDown()
{
// on augmente le DD permsi pour permettre au systéme de redémarrer
DrawDownMax = @IncrementDrawDown + EngineIndicator:StrategyActualDrawDown
// on augmente le recovery necessaire pour redemarrer si le demarrage actuel echoue et touche de nouveau le DD max
MinRecovery = @MinRecovery + @IncrementDrawDown
CurrentDay = Horaire:CurrentDay
Passage du moteur en mode réel // reprise des ordres en réel
Go attente point d’entrée de la stratégie
}
WaitRecovery()
{
// on attend qu’en simulation en gagne le recovery minimum
Passage du moteur en mode simulation
Go attente point d’entrée de la stratégie
}
NormalMode()
{
Passage du moteur en mode réel
//Go attente point d’entrée de la stratégie
}

Voici par exemple l'algo PRT de tradesurf présenté dans un post par un autre intervenant traduit avec mon systéme avec les contrôles du DD

j'ai un editeur de stratégie qui me permet de tester rapidement toutes sortes d'idées, avec le moteur d'execution qui va bien derriére.

Spoiler:

Il est un peut tard pour avoir une réflexion, mais je me demande qu'elle différents entre un signal suite a des trades virtuel et un signal sur indicateurs classique, j'ai l'impression qu'on arrive au même résultat, par contre je me souviens d'un robot grille qui prenait ça premier positions sur signal indicateurs, puis les suivantes était après un test un peu comme toi en virtuel, ci ça peut te donner une idée.