Journal de NightOnEarth - Trading auto

Bonjour à tous,

J'inaugure mon journal par une petite présentation de ma démarche dans le trading. Pour quelques infos supplémentaires sur moi-même et notamment mon profil psychologique, vous pouvez vous réferer à ma présentation.

Je pratique de l'intraday sur les crypto-monnaies. Leur volatilité et leur liquidité me semblent constituer des atouts par rapport à mon stye de trading.

Ma motivation première est ludique. j'ai toujours aimé les défis intellectuels, et le fait de trouver une ou des stratégies de trading gagnantes constitue un défi de taille et extrêmement stimulant. Il y a également une motivation secondaire, qui serait de m'acheter du temps, au cas où je parviendrais à avoir des gains substantiels. Je ne suis pas matérialiste et l'argent m'intéresse peu ; par contre, le temps est une ressource qui m'est très précieuse, et si je pouvais un jour travailler moins grâce à des revenus secondaires, ce serait un très grand bénéfice à mes yeux.

Je suis professionnel de l'informatique, passionné par ce domaine depuis plus de 30 ans. Je me suis spécialisé au fil des années dans les systèmes logiciels complexes, très gros logiciels, temps réel, avec quelques incursions également dans le domaine de l'intelligence artificielle. Je ne dis pas ça pour étaler mon "CV", mais pour justifier un minimum de mon expérience car je vais, dans les posts suivants, développer certaines idées vont un peu à l'encontre du Consensus qu'on rencontre habituellement dans la préparation d'un algorithme de trading automatique.

Je vais avoir une approche chronologique, en présentant dans un premier temps la première stratégie que j'ai développée et testée (en réel) cet hiver, analyser la raison de son échec et des possibilités de la rendre plus efficace. Dans un second temps je présenterai mes travaux actuels et c'est là que je développerai les idées qui me semblent différentes.

Pourquoi je crée ce journal ? Parce que le développement de ce logiciel de trading automatique me prend beaucoup de temps et que j'aimerais par l'expérience et le retour des lecteurs, m'éviter si possible de perdre du temps dans des "culs de sac algorithmiques". Voire, de trouver des conseils ou de nouvelles idées pour améliorer mon logiciel. En retour, j'espère que les lecteurs trouveront un intérêt dans ma démarche et mes essais, et, qui sait, de l'inspiration sur des choses à faire... ou à ne pas faire...

Bienvenue

salut !

Bonjour et merci pour l'accueil

Je vais parler dans ce message de la première stratégie que j'avais implémentée, de l'arbitrage triangulaire entre trois paires de devises.

Après des simulations à gros grain très positives, j'ai décidé d'affiner mes calculs pour avoir plus de précision. Les API qui renvoient uniquement le prix sont peu fiables car elles ne permettent pas d'anticiper le slippage. Je ne prenais pas non plus en compte les frais de transactions.

Il s'est avéré que l'implémentation d'un algorithme exact était beaucoup plus difficile que ce que j'avais pensé initialement. J'ai dû créer un Carnet d'ordres local, alimenté à 100ms, plus toute l'infrastructure technique (je vous passe les détails). Quant à l'algorithme en lui-même, il doit prendre en compte le Carnet d'ordres pour déterminer la quantité qui donne le meilleur profit. Si par exemple au meilleur prix, avec une quantité 1, on a un profit de 3%, mais qu'avec une quantité 100 on a un profit de 1%, c'est la dernière quantité qui fournit le meilleur gain.

Le calcul de ces quantités est complexe, il faut simuler le calcul entre les 3 paires et revenir en arrière lorsqu'on a trouvé une quantité, et itérer pour calculer toutes les quantités qui correspondent à une ligne du Carnet d'ordres, pour l'une des paires. Sans compter que la paire peut être dans le bon ordre (par ex : B/A, C/B, A/C) ou dans n'importe quel ordre (A/B, C/B, A/C), ce qui complexifie encore les calculs.

J'ai également dû prendre en compte les filtres sur les ordres (step sur les quantités, etc.). Enfin, pour avoir une estimation correcte du rendement, il faut faire des conversions de devises lorsque les frais sont comptés dans la devise de la paire (sur Binance, la plateforme que j'utilise, ce n'est pas toujours le cas, on peut payer les frais en BNB, mais j'ai fait des tests avec les deux solutions, bien que les frais soient moindres en BNB).

Tant qu'à partir sur un algorithme complexe, j'en ai profité pour l'implémenter avec un nombre de paires arbitraires. J'ai nommé cet algo arbitrage multi-niveau.

Pour que les transactions soient instantanées, l'algo passe des ordres au marché, mais puisque j'ai un carnet d'ordre local, je suis censé connaître précisément le prix auquel l'ordre va être déclenché.

Mon logiciel est capable d'observer des dizaines de trio de paires simultanément. Dans les faits, lors de mes essais en réel, j'en observais entre 10 et 20.

Une fois l'algorithme au point, j'ai assez rapidement décidé de passer en réel. L'avantage de cet algorithme est que les pertes sur un trade sont faibles puisque les transactions sont très rapides.

Le bilan de ces tests a été négatif. Sur quelques centaines de trades, avec une mise maxi de 100 euros, j'ai perdu entre 30 et 40 euros, avec très peu de trades gagnants.

J'ai essayé de comprendre pour quelle raison ça n'avait pas fonctionné. Après analyse des traces, je pense que mon algorithme est correct et n'a pas de bugs. Ce qu'il se passe, c'est qu'il y a toujours une paire dont le prix change entre le moment où je réalise les calculs et le moment où je passe les ordres.

Le temps d'exécution des ordres tourne autour des 3 secondes (une seconde par ordre), et j'ai remarqué, sauf erreur, que ce n'est jamais le premier ordre qui ne correspond pas au prix de la simulation utilisé par l'algo.

Je suppose donc que des ordres sont passés avant les miens. Je suspecte que je ne suis pas le seul à utiliser cette technique et que mes "concurrents" sont capables de passer des ordres plus rapidement que les miens.

Je pensais avoir des moyens techniques d'augmenter la rapidité de mes trades, mais après vérification, ce n'est pas le cas malheureusement. La seule solution serait de disposer à l'avance d'un montant équivalent sur les 3 devises, mais cela demande plus de capital, et limiterait le nombre de trios de paires que je peux observer simultanément.

En ce qui concerne l'arbitrage sur plus de 3 paires, je l'ai testé de manière moins approfondie car les premières simulations étaient beaucoup moins bonnes qu'avec l'arbitrage triangulaire. Je suppose, sans certitude, que plus on ajoute de paires de devises, plus on introduit la possibilité d'une correction négative sur le gain potentiel de l'arbitrage. Je n'ai jamais tradé en réel avec plus de trois paires.

Après cet échec, j'ai donc décidé d'arrêter de travailler sur cet algo et, fatigué par l'effort important que j'y avais consacré, j'ai fait une pause durant quelques semaines. J'ai quand même appris énormément, sur les API, sur la logique générale des algorithmes (la prise en compte du "sens" de la paire, i.e. A/B ou B/A rend les calculs beaucoup plus complexes que ce qu'on pourrait croire au premier abord), etc. J'ai aussi mis en place une architecture qui est utilisable pour d'autres stratégies avec la capacité d'en faire tourner un grand nombre simultanément.

Si vous avez des retours sur ces essais et sur la raison possible de l'échec de cette stratégie, je les lirai avec intérêt

hello, possiblement il s’agit d’une erreur fondamentale : croire qu’on peut mettre le marché dans une boîte noire. Des Hedge Fund pilotés par des prix Nobel ont payé cher pour apprendre que non.
Je conseille de raisonner beaucoup plus simplement et avec énormément moins de lignes de code.
Je pense qu’il faut imaginer le marché comme une boule qui roule de manière imprévisible dans un espace dont en plus on connaît mal les limites.
A l’intérieur de cet espace, on peut mettre des pièges-trous dans lequel le marché va donner du cash s’il passe par hasard dedans. Impossible d’en connaître la fréquence. Mais tout le travail c’est d’être sur que s’il passe par là, le réel soit conforme à ce qui est attendu.

Bonjour Trappiste, merci pour ton message. Je ne comprends pas bien ton analogie avec une boite noire.

Pour moi elle signigie qu'on ne regarde que les entrées / sorties d'un système, sans connaître son fonctionnement interne. Dans le cas de l'algorithme que je viens de détailler, ça ne me semble pas être le cas, puisqu'il travaille avec les données les plus précises qu'on puisse avoir, le Carnet d'ordres (raffraichi toutes les 100 ms). Mais sans doute que ce n'est pas ce que tu veux dire par boite noire ? Le seul élément qui n'est pas accessible, ce sont les opérations déclenchées par les autres traders, et c'est justement ce qui semble avoir fait faillir cette stratégie. Mais je ne vois pas ce qu'on peut y faire...

Je ne suis pas trop d'accord avec ton conseil de raisonner plus simplement, en tout cas dans le cas de l'arbitrage de paires de devises. Cette stratégie demande au contraire beaucoup de précision pour déterminer s'il y a un gain potentiel (car il est par nature toujours assez faible). Sans cette précision, elle ne peut pas fonctionner.

Sur le nombre de lignes de code, là non plus je ne te suis pas trop. Si on veut pouvoir surveiller beaucoup de devises en même temps, ça demande une architecture "scalable" (qui continue à fonctionner correctement lorsqu'on augmente le volume de données traitées), avec de faibles latences (temps de traitement) pour réagir au plus vite aux changements du marché. Et pour faire ça correctement, ça demande pas mal de lignes de code.

Autre aspect : la sécurisation. Ce n'est pas le cas pour l'arbitrage, mais d'autres stratégies plus classiques de trading sur paires de devises nécessitent beaucoup de code pour s'assurer de la cohérence de l'état du logiciel à tout moment, et pour gérer les circonstances anormales (déconnexion par exemple), afin d'éviter des drames Sans parler de la sécurisation par SL et TP, du money management, qui demandent là encore pas mal de code si on veut faire ça correctement (i.e., de façon fiable y compris en cas de situations anormales).

Je suis certain que les logiciels développés par des sociétés de trading sont également très volumineux (bien plus que le mien). Je ne vois pas comment on peut faire autrement si on veut respecter ces contraintes (scalabilité, réactivité et sécurité).

Mais si tu as un autre avis, ça m'intéresse que tu développes !

pour le partage des tes idées qui sont très intéressantes.

Ce qui m'interpelle, c'est je ne vois pas l'intérêt d'avoir un carnet d'ordre à 100ms si le passage d'un ordre prend 3 secondes.

Cela rend fausse ta phrase "l'algo passe des ordres au marché, mais puisque j'ai un carnet d'ordre local, je suis censé connaître précisément le prix auquel l'ordre va être déclenché"

Et ça revient à s'en remettre peu ou prou au hasard.

Je pense que le préalable à un bon système de trading automatique est d'avoir une plateforme beaucoup plus réactive.

Je reste assez sceptique sur ton approche. Ce qui pourrait me faire changer d’avis : qu’elle soit gagnante ! D’ici là…

Bonjour NightOnEarth,
J'ai l'impression que tu essayais de faire un arbitrage de latence entre 3 paires de devises ?
Le livre Flash Boys de Michael Lewis donne une idée des moyens déployés par les big players de la haute fréquence. Je pense qu'ils font déjà ce genre d'arbitrage.
Nous ne sommes pas compétitifs en latence. Il faut trouver des stratégies ou la latence n'est pas l'aspect principal. Car nos robots auront toujours quelques centaines de millisecondes de retard sur ceux des hedge funds.

Bonjour à tous,

(je vois qu'on ne peut pas citer les messages, je trouve que c'est pratique pour répondre à plusieurs personnes à la fois, tant pis !)

@takapoto,
merci pour ton intérêt. A mon sens, la grande réactivité en trading auto est surtout nécessaire si on fait du scalping, ou de l'arbitrage triangulaire, sinon une moindre réactivité n'est pas grave. Et encore... Je pense qu'on ne peut pas vraiment dire quelle est la latence minimum qu'on doit avoir, car ça dépend de la liquidité. Sur des paires peu liquides, il n'est vraiment pas utile d'avoir une latence de 10ms.

Binance propose également quelques flux en temps réel, mais dans le cas de ma stratégie, de toute façon, la latence à 100ms n'est pas le problème puisqu'elle est 30 fois inférieure au temps qu'il faut pour faire les 3 transactions. C'est là qu'est le véritable problème.

@macgarden,
oui tu as bien compris. Je suis bien d'accord avec toi et c'est pour ça que j'ai décidé de passer à autre chose. J'avais supposé, semble-t-il à tort, que l'échange de crypto-monnaies était encore suffisamment récent pour qu'il n'y ait pas de gros systèmes à très faible latence. Voire même que l'arbitrage triangulaire y était encore suffisamment rare pour pouvoir en profiter. Il semble que mes hypothèses étaient fausses

La nouvelle stratégie sur laquelle je travaille ne repose donc pas sur la latence.

@trappiste,
tu as bien sûr raison d'être sceptique et d'ailleurs comme indiqué, ça n'a pas fonctionné en définitive (même si je ne suis pas sûr de bien comprendre sur quel(s) point(s) en particulier tu es sceptique). Je n'ai certes pas la prétention de débarquer et de mieux savoir que tout le monde comment faire pour avoir une stratégie gagnante
Mais j'essaie d'avoir un regard un peu différent sur les possibilités qui s'offrent à nous dans le cadre du trading auto. Plus à ce sujet prochainement...

Bonne journée.

Le carnet d'ordre ne représente pas les ordres au marché.
Et si je ne me trompe ce sont les ordres au marché qui font les cours, ceci expliquant cela.

@plasticboy Je ne suis pas sûr de te suivre. Si tu veux dire que les ordres au marché ne sont pas inscrits dans le Carnet d'ordres on est d'accord. Par contre, sauf erreur, pour honorer un ordre au marché, c'est bien dans le Carnet d'ordres que la plateforme va chercher non ? En tout cas je crois que c'est comme ça sur Binance.

Pour moi ce qui fait les cours, ce sont les transactions. Mais effectivement ça me semble logique que dans la plupart des cas elles soient déclenchées par un ordre au marché (ça paraît bizarre par exemple de placer un ordre limite qui peut être immédiatement honoré dans le Carnet d'ordres). Les ordres qui peuvent être immédiatement honorés par une transaction avec le Carnet d'ordres sont des ordres taker (par opposition aux ordres maker qui créent le marché) et sont souvent plus taxés que ces derniers qui contribuent à créer le marché et apporter de la liquidité.

Donc je ne comprends pas ce que tu veux dire et en quoi ça explique les problèmes que j'ai rencontrés avec l'arbitrage triangulaire.

Les ordres au marché vont taper dans le carnet d'ordre mais tu ne peux pas prévoir dans quel sens.
Comme l'ont dit mes collègues avec 1sec d'exécution tu n'es déjà plus au cours indiqué par le CO.

Ah ok, on est tous d'accord alors