Get best of the week

Comment ne pas perdre tout l'argent en quelques minutes ou la gestion des risques dans le trading algorithmique



Le contenu de l'article


introduction


Maintenant, la situation n'est pas simple à la fois dans le monde et dans le commerce des actions. De nombreux commerçants deviennent soudainement millionnaires, tandis que d'autres perdent instantanément tout leur argent. La volatilité élevée du marché offre aux traders algorithmiques une bonne opportunité de gagner. Et pour dormir paisiblement et ne pas rêver, les cygnes noirs doivent protéger leurs comptes des robots furieux et autres problèmes de trading algorithmique.

"L' Algotrader est endormi - le commerce est en cours! " - Certains commerçants aiment dire. Mais la réalité n'est pas si simple. Où pensez-vous que le trading algorithmique commence? De la connexion à l'échange ou de l'écriture d'un algorithme? Pour un participant professionnel, le trading commence par le développement de la gestion des risques .

On pense que le trading algorithmique est beaucoup plus efficace que le trading classique. Parce que les robots n'ont pas de solutions émotionnelles, ils sont prêts à travailler 24h / 24 et 7j / 7, ils savent exactement quand acheter et quand vendre, ils font des transactions à une vitesse inaccessible à une personne ordinaire. Cependant, en raison de leurs superpuissances, ils créent une classe de risques accrue.
Par exemple, un cas bien connu qui est entré dans l'histoire sous le nom de  «Vengeance de voitures» a causé des pertes de 460 millions de dollars, ou un robot cassé a causé des pertes de 4,3 millions de dollars ou des défaillances sur la Bourse de Moscouconduisant à des arrêts et des pertes pour les commerçants, etc. Un tel incident suffit et les comptes de trading peuvent être irrémédiablement endommagés. Cela est particulièrement vrai si le commerce est marginal, lorsque le prix de l'erreur augmente plusieurs fois.

Un commerçant ne peut pas savoir combien il gagnera, mais il doit savoir exactement combien il peut perdre. En fait, tout trading se résume au contrôle des risques, et le profit est une récompense pour les observer.

Dans cet article, je vais essayer de divulguer, si possible, les risques potentiels associés à l'exécution d'algorithmes de trading dans le trading réel et les mesures de protection contre les pannes du système de trading. Dans le même temps, je n'aborderai pas la gestion de l'argent , la diversification du portefeuille de trading et la logique des stratégies de trading, c'est une autre histoire.

1. Solutions architecturales


Avant de procéder à la classification des risques, je parlerai un peu des solutions standard dans la partie trading du trading algorithmique.

Des exigences à la vitesse d'exécution des applications, les robots de trading sont construits de différentes manières. Si ce HFT (par exemple, l' arbitrage ou la tenue de marché ) est sensible aux retards, alors ils essaient de minimiser le chemin d'application de l'algorithme à l'échange et le compte en retards est dépensé en microsecondes. En règle générale, ces algorithmes ont une architecture spécifique et sont optimisés pour une stratégie spécifique. Dans ce cas, la gestion des risques est directement intégrée à la stratégie.

Fondamentalement, les stratégies de trading sont en place de quelques minutes à plusieurs heures, et moins l'algorithme est en place, plus il est facile de contrôler les risques. Cependant, avec une augmentation de la fréquence des transactions, les frais de commission augmentent, ce qui réduit la rentabilité des algorithmes. Les stratégies de trading essaient donc de trouver un équilibre entre le risque et le profit.

Les algorithmes de trading sont rarement échangés un à la fois. En règle générale, il s'agit de familles entières de stratégies qui sont collectées dans des portefeuilles pour diversifier et stabiliser la courbe des actions . Dans le même temps, les données d'échange pour les algorithmes de trading peuvent provenir de diverses sources et les applications peuvent être envoyées à différents échanges. Au cœur du système commercial se trouvent les moteursqui acheminent et optimisent les données entre les algorithmes et les échanges (voir la figure 1). Habituellement, il existe d'autres moteurs, par exemple, pour travailler avec des données historiques ou des backtests, mais par souci de simplification, je ne les montre pas.


Fig. 1. Le schéma architectural du serveur de trading.

2. Classification générale des risques


  • 2.1. Risques liés aux infrastructures
  • 2.2. Problèmes de connexion à l'échange / courtier
  • 2.3. Problèmes dans la logique des stratégies de trading

2.1. Risques liés aux infrastructures


La majeure partie des problèmes de cette classe est associée aux serveurs de trading. Pour le trading algorithmique, même un PC très puissant ne convient pas pour de nombreuses raisons: équipement peu fiable, connexion Internet instable, mauvaise alimentation, etc.

Les principaux risques:

  • perte totale / partielle des performances du serveur;
  • redémarrage d'urgence du système d'exploitation;
  • défaillance du serveur physique.

La qualité de la résolution de ces problèmes dépend généralement de votre budget et des exigences de vos algorithmes de trading.

2.1.1. Options de solution


  • Colocation d'échange. Option idéale et la plus chère. Il est généralement utilisé dans des algorithmes HFT très rentables ou dans de grandes entreprises, par exemple, les banques, où cette infrastructure est réutilisée pour d'autres solutions de trading.
  • Location de serveurs virtuels / dédiés. Si vous n'êtes pas un grand hedge fund ou un commerçant privé, vous utilisez probablement cette option. Une solution simple, facilement personnalisable et évolutive. Vous pouvez toujours trouver un fournisseur qui correspond aux paramètres prix / qualité.
  • . . , / , .

2.1.2.


  • / . TIER III uptime 99,98% . .
  • . , . .
  • La réserve de marche est d' au moins 40-50% (CPU, RAM, SSD) par rapport au mode de trading habituel. En règle générale, en cas de mouvements importants du marché, la charge dans les flux de données augmente et les algorithmes commencent à exécuter activement les transactions. À ce moment crucial, il ne devrait pas y avoir de freins sur vos serveurs.

2.2. Problèmes de connectivité


Sur les bourses et les courtiers, des pannes techniques surviennent de temps à autre. Par exemple, le fonctionnement de la plate-forme de négociation de la Sberbank s'est écrasé ou était "sous-utilisé" sur la Bourse de Moscou , la bourse a été fermée pour le déjeuner , la Bourse de Moscou a suspendu ses opérations en raison d'une défaillance , etc.

Les principaux risques:

  • coupures de connexion;
  • retards importants;
  • données incorrectes;
  • perte de données partielle.


2.2.1. Rupture de connexion


Les informations de coupure de connexion peuvent être obtenues de plusieurs manières:

  • API d'événements de connecteur - Connecté , déconnecté .
  • Utilisation d'algorithmes de vérification de connexion tels que Heartbeat , qui sont généralement présents dans l'API.
  • Indirectement. Par le manque de données dans les flux de données.

Vous pouvez configurer la connexion de sorte que si la connexion est perdue / déconnectée, la bourse retire les ordres actifs ou ferme les positions. Cependant, vous devez être prudent avec cette fonctionnalité, car en cas de courtes pauses, une fermeture imprévue de positions entraînera très probablement des pertes et plus de mal que d'aide.

De plus, il arrive souvent que lorsque quelque chose se brise, il se casse complètement et les premières options d'avertissement sur les pauses ne fonctionnent pas et ne parviennent qu'indirectement à découvrir que quelque chose s'est mal passé.

2.2.2. Problèmes de données


Pour commencer, considérez les principaux types de données de stock. Selon le type de connecteur et d'échange, ces données ne varient pas beaucoup, mais fondamentalement, le plus ou le moins sont les mêmes.

Modifications entrantes:

  • Échange de lunettes / carnet de commandes
  • Offres
  • Applications
  • Éléments de campagne
  • Équilibre

Données sortantes:

  • Demandes d'inscription

Les données entrantes et sortantes peuvent provenir d'une ou de différentes connexions. Il arrive que l'un des fils puisse tomber "tranquillement", tandis que le reste fonctionnera en mode normal. Même si les données proviennent de la même source, vous devez toujours surveiller chaque flux individuellement.

Les problèmes de données sont généralement résolus en implémentant des algorithmes de suivi tels que WatchDog . Tous les threads doivent passer par ces modules. Piste

WatchDogs :

  • fréquence des mises à jour des données dans le flux;
  • retards d'horodatage des données et de l'heure actuelle;
  • sur la disponibilité des données détermine la présence de communication avec l'échange.

Si pendant un certain temps aucune donnée n'est venue du connecteur ou si les retards dépassent le maximum autorisé, les événements correspondants sont générés et des décisions sont prises sur d'autres actions.

Pour le calcul correct des retards, un système indépendant de synchronisation précise de l'heure du système doit être mis en œuvre. Par exemple, avec des serveurs NTP .

2.2.3. Options de solution


Si les problèmes ci-dessus se produisent, le système doit immédiatement déconnecter les flux de données des algorithmes et essayer de se reconnecter avec la fréquence et le nombre de tentatives donnés. Il ne faut pas oublier qu'il existe des causes de rupture totalement justifiées, jusque-là imprévues. Par exemple, en raison d'une session de négociation raccourcie les jours fériés nationaux ou d'une mise à jour inattendue de l'API et d'autres scénarios déraisonnables. Dans chaque connexion particulière, la reconnexion doit être abordée individuellement. Sinon, le nombre excessif de tentatives de reconnexion peut être perçu par l'échange comme une attaque de spam et entraîner un blocage de compte.

Après avoir reconnecté et téléchargé les données perdues, il est nécessaire d'informer les algorithmes de trading de la restauration du travail et de leur transférer les données perdues. Les algorithmes devraient analyser les changements qui ont eu lieu et décider quoi faire ensuite. Restez dans la position actuelle, changez-la ou fermez-la complètement. Cette logique doit être implémentée dans chaque stratégie de trading.

L'ordre de restauration des travaux:

  • reconnecter;
  • télécharger des données perdues;
  • notifier les algorithmes de récupération de communication;
  • transférer les données perdues vers les algorithmes;
  • changer de flux en temps réel;
  • La logique de trading des algorithmes devrait normaliser leurs positions et remplacer les ordres.

De même, en cas de données problématiques ou de perte partielle de fonctionnalité, vous devez d'abord restaurer complètement la connexion et normaliser les flux de données. Il est impossible d'échanger avec une capacité de travail partielle, il est évident que cela ne se terminera pas avec quelque chose de bon.

2.3. Problèmes dans la logique des stratégies de trading


Les problèmes les plus dangereux, insidieux et imprévisibles se cachent dans la logique programmée des stratégies de trading. Peu importe à quel point les algorithmes de trading sont réfléchis, il est impossible de prévoir tous les scénarios. Divers facteurs et leur combinaison peuvent donner lieu à un comportement inattendu. De plus, certaines erreurs peuvent se cacher pendant des années et «émerger» au moment le plus inattendu.

2.3.1. Classification des problèmes


  1. Erreurs dans les applications:
    • Prix ​​/ volume négatif;
    • Direction inverse;
    • Mauvais type, etc.
  2. Erreurs API:
    • Tous les champs ne sont pas remplis dans la transaction;
    • Utilisation d'une version obsolète de l'API;
    • ..
  3. :
    • ;
    • ;
    • ;
    • « »;
    • .
  4. :
    • ;
    • ;
    • .
  5. :
    • ;
    • .
  6. :
    • ;
    • ;
    • ;
    • .
  7. :
    • ;
    • ;
    • Un grand nombre d'applications qui n'entraînent pas de transactions.
  8. Manque de gestion des exceptions dans le code de programme des stratégies de trading

Cependant, certaines erreurs peuvent en engendrer d'autres. Par exemple, l'arrêt de l'algorithme en raison d'une erreur grossière entraînera une violation de la position et, par conséquent, une violation des limites.

2.3.2. Options de solution


La solution à ces problèmes se résume au contrôle des applications et des limites des stratégies de trading (voir section 3). De plus, toute exception dans le code du programme devrait conduire à un arrêt immédiat de l' algorithme problématique et au retrait de toutes ses applications actives.

3. Surveillance des applications et des limites des stratégies de trading


Ce sont peut-être les moyens les plus importants de gérer les risques du système commercial. Toute erreur entraînera éventuellement une déviation de la position, des candidatures et de la trésorerie. La tâche consiste à remarquer ces changements le plus rapidement possible et à agir rapidement.

Les chèques peuvent être divisés en deux types:
3.1. Vérification de base des demandes
3.2. Analyse et contrôle des limites

3.1. Vérification de base des applications


Toutes les demandes sortantes doivent être vérifiées pour:

  • erreurs grossières;
  • exactitude et suffisance des données pour l'API;
  • respect des spécifications des instruments négociés;
  • respect de la réglementation des enchères, etc.

Ces vérifications sont effectuées avant l'envoi des candidatures à la bourse. Plus tôt une erreur est trouvée, plus il sera facile d'éliminer ses conséquences. N'attendez pas que des erreurs évidentes viennent du connecteur. Il vaut mieux résoudre les problèmes avant qu'ils n'apparaissent. De plus, l'envoi de transactions erronées peut entraîner diverses sanctions de la part de la bourse.

3.2. Contrôle limite


Pour contrôler les limites, les éléments suivants sont vérifiés:
3.2.1. Changement d'équilibre et de position avant de déposer une demande
3.2.2. Variation du solde et de la position courants
3.2.3. Prix ​​et volume d'application
3.2.4. Comportement des applications

3.2.1. Analyse des changements d'équilibre et de position avant de déposer une demande


Avant de soumettre une demande d'enregistrement, un éventuel changement d'équilibre et de position en cas d'exécution de la demande est vérifié. S'il y a un dépassement de la limite pour cet algorithme, alors l'ordre n'est pas envoyé et un message d'erreur est envoyé à la stratégie de trading.

3.2.2. Analyse de l'évolution du solde et de la position actuels


Des limites sont formées sur les changements du volume et de la position négociés sur les instruments pour des périodes de temps: 15 s, 30 s, 1 min, 5 min, 15 min, 1 heure, 1 jour. Une surveillance constante des changements au fil du temps vous permettra de voir l'écart de comportement et d'arrêter le trading, jusqu'au moment où l'écart devient critique.

Il arrive que des problèmes avec l'algorithme n'apparaissent pas immédiatement. Il peut commencer à «fusionner» lentement et sans dépasser les limites pendant une courte période de temps. Vous pouvez vous réveiller le matin et trouver un rabattement important en raison d'un algorithme peu «cassé». En avons-nous besoin? Nous n'en avons pas besoin.

3.2.3. Analyse des prix et des volumes


Avant d'envoyer la demande d'enregistrement, la limite de dépassement du volume maximal et minimal dans la demande est vérifiée. Malheureusement, personne n'a annulé les erreurs arithmétiques dans les formules et les calculs.

Il est important, si possible, de vérifier l'écart entre le prix offert et le prix moyen du marché. Pour ce faire, vérifiez le prix d'autres sources pour un instrument de négociation similaire. Ces vérifications sont particulièrement pertinentes si la négociation est effectuée sur une bourse non liquide ou si une volatilité anormalement élevée est observée pour un instrument négocié.

Si les modifications dépassent les limites spécifiées, les demandes sont rejetées avant d'être envoyées au central.

3.2.4. Analyse du comportement des applications


Vérifié ici:

  • le nombre de demandes qui n'aboutissent pas à des transactions;
  • nombre d'applications actives;
  • fréquence d'application pour des périodes de 1 s, 3 s, 5 s, 15 s, 30 s, 1 min.

Les bourses ont leurs propres limites sur le nombre d'ordres actifs et la fréquence de leur soumission, si elles dépassent l'accès au trading, elles peuvent être suspendues. Et il ne sera possible de normaliser les positions que manuellement.

L'une des situations les plus dangereuses et les plus risquées est lorsqu'un robot de trading commence à acheter et à vendre de manière incontrôlable, en plaçant un grand nombre d'ordres par seconde. Avant que le robot ne prenne une grande position ou ne termine une commission, cette protection devrait fonctionner. Au minimum, elle doit donner du temps supplémentaire pour que d'autres mécanismes de protection puissent fonctionner.

Ces contrôles sont effectués à plusieurs niveaux:

1. Au niveau du connecteur.La protection des connecteurs «ralentit» les applications lorsque la fréquence d'exposition approche du maximum. Cela est nécessaire pour ne pas perdre l'accès à l'échange. Ces mesures sont extrêmes, il est donc important de calculer correctement la charge sur le connecteur à l'avance.

2. Au niveau d'une stratégie commerciale. Si l'algorithme dépasse sa limite sur la fréquence de dépôt des demandes, il est alors arrêté de force avec une erreur. Dans ce cas, toutes les demandes actives soumises précédemment sont supprimées.

4. Intégration de la gestion des risques dans la solution architecturale


L'intégration de la gestion des risques peut être divisée en deux parties principales (voir Fig.2):

  • PRE-TRADE comprend le contrôle de base des commandes, le contrôle du prix et du volume de la commande, le contrôle des changements de solde et de position avant la soumission de la commande, le comportement des commandes est également analysé ici.
  • POST-TRADE comprend des contrôles des ruptures de connexion et de l'exactitude des données du marché, un suivi constant des changements d'équilibre et des positions actuelles est effectué, le comportement des ordres est également analysé ici.



Figure. 2. Le schéma d'intégration de la gestion des risques dans la solution architecturale pour le serveur de trading.

5. Journalisation et rapports


N'oubliez pas que des situations non standard se produisent également et qu'aujourd'hui, elles ne peuvent se passer d'une intervention humaine, même dans des systèmes hautement automatisés. Par conséquent, en cas de problème, vous devez immédiatement informer toutes les parties intéressées (commerçants, développeurs, gestionnaire) en envoyant automatiquement des messages par courrier, SMS, télégrammes ou de toute autre manière pratique. Idéalement, il devrait toujours y avoir un trader en douane qui surveille les performances du système commercial.

En cas d'échec, vous devez trouver rapidement le problème, le résoudre et remettre le système de trading en marche. Pour ce faire, il est nécessaire de maintenir des journaux commerciaux et système détaillés, en particulier dans les systèmes fortement chargés avec un grand flux d'applications. Si les causes de l'échec ne sont pas trouvées, l'échec suivant peut être fatal. L'échange, en règle générale, ne pardonne pas les erreurs et punit immédiatement le rouble.

Conclusion


En règle générale, la gestion des risques pour les algorithmes de négociation commence à «se resserrer» au dernier tour, lorsque quelques incidents se sont produits et il est venu à comprendre que vous ne pouvez pas vous en passer.

Tout comme les mesures de sécurité sont écrites dans le sang, la gestion des risques dans le trading algorithmique est écrite dans les appels de marge et les comptes fusionnés.

Cependant, si vous construisez correctement un système de trading et configurez la gestion des risques, vous pouvez dormir paisiblement et être sûr que « Algotrader est endormi - le trade est en marche! » Bon trading pour

tout le monde!

More articles:


All Articles