|
Trading Electronique Professionnel
|
Écrit par Nicolas Vitale
|
|
Mon précédent post portant sur l'agrégation du Forex avec la présentation d'une plateforme de la société StreamBase n'étant pas tombée dans l'oreille d'un sourd, j'ai eu droit à une conférence privée de StreamBase (que je remercie d'ailleurs) qui m'a présentée ses systèmes. Les plateformes de Streambase ne se limitent d'ailleurs pas au Forex et permettent de réaliser l'ensemble des opérations d'une société de trading allant de l'acquisition des données à la programmation d'automates de trading en passant par l'analyse et la sauvegarde des données, leur représentation, les backtests, etc. L'échange a été très intéressant et a terminé sur une question classique du domaine... vaut-il mieux construire ses applications de trading de zéro ou en acheter les bases pour n'avoir à développer que la partie métier (comme les algorithmes de trading, les indicateurs des traders, etc)? Les clients de StreamBase et d'autres sociétés du même genre étant des banques d'investissement et des hedge funds, ils y ont forcément vu un intérêt à ne pas avoir à réinventer la roue. Ces sociétés proposent en effet des plateformes "ouvertes", c'est à dire qui autorisent à leur client de développer, via les APIs proposés, leurs propres opérateurs, analyseurs, indicateurs, algorithmes, etc. Pour ce qui concerne StreamBase, l'environnement de développement classique et utilise la fameuse plateforme pour le développement Java Eclipse. Mais rassurez vous, il est possible de programmer en utilisant les langages classiques autre que le Java comme le C++ par exemple. Le principe est simple: c'est du cliquer et déposer graphique. On sélectionne un opérateur parmi la multitude proposée (somme, moyenne mobile, etc) puis on le pose sur nos diagrammes. A l'entrée du diagramme on retrouve bien sûr les données du marché et en sortie, des indicateurs à afficher, des ordres de trading, etc. Cette programmation graphique m'a clairement rappelée celle utilisée par le logiciel Labview que vous connaissez probablement si vous êtes ingénieur... Évidemment, le client peut développer lui même ses propres opérateurs, lui laissant une grande liberté d'action dans son métier. Ces plateformes peuvent être aussi pilotées et contrôlées par les équipes de support des clients, tout comme des plateformes maison. Les intégrer dans son propre système, en gérant ensuite de son coté, par exemple, les systèmes de gestion de risque semble être une solution intéressante. Il y a donc évidemment un grand intérêt à utiliser de tels logiciels qui nécessiteraient en interne de nombreuses années de développement et de recherche. Ces plateformes sont même déjà optimisées pour avoir une latence minimum dans les passations d'ordres et les traitements. Mais, car il y a toujours un "mais", en faisant abstraction du prix d'achat par rapport au coût d'un développement interne, il reste un point que j'aimerais aborder. Dans le contexte actuel, où le marché devient de plus en plus technique, on s'aperçoit que la différence se fait souvent au détail. Par exemple, le premier arrivant sur le marché saisit l'opportunité d'arbitrage, ce qui explique cette course effrénée à la vitesse de traitement et d'exécution d'ordre que se livrent les diverses banques d'investissement et les hedge funds. Dans un tel marché, ce n'est plus l'aspect "économique" qui fait gagner de l'argent, mais bien l'aspect technologique. Le métier des banques d'investissement historiquement économique passe donc de plus en plus au domaine technologique. Et dans ces conditions, est ce bien raisonnable de sous traiter son cœur de métier? Certes cela risque de représenter un investissement financier initial important, mais puisque c'est ce qui doit nous donner un avantage compétitif sur nos concurrents, il ne faut pas voire à court terme...
|
|
|
Au cours de ces trente dernières années, la technologie a transformé l'investissement et le trading. Les marchés sont devenus des réseaux informatiques, les courtiers sont "désintermédiarisés" par les accès directs et le trading algorithmique. De même, les journalistes sont désintermédiarisés car les investisseurs ont accès à des sources primaires, en même temps qu'eux. Une vue de plus en plus exploitable de l'activité économique peut être obtenue sur le web. Le Dr. Leinweber apporte une analyse intéressante de cette évolution et ses questions, tant du point de vue vendeur qu'acheteur. Conférencier: David Leinweber David Leinweber est " Haas Fellow" en finance. Ses intérêts professionnels sont focalisés sur la manière dont les technologies de l'information sont les mieux appliquées dans le trading et l'investissement. En tant que fondateur de deux sociétés de technologie financière, et manager d'un fond d'investissement quantitatif, il est un participant actif dans le contexte actuel de transformation des marchés. Il est un conseiller aux entreprises d'investissement, aux bourses, aux maisons de courtage et aux entreprises technologiques dans des domaines liés aux marchés financiers. Il est aussi un conférencier et auteur d'ouvrages sur ces sujets. Son livre, "Nerds à Wall Street" a été publié par Wiley en 2008.
Il est diplômé du MIT, en physique et en informatique et a aussi un doctorat en mathématiques appliquées à Harvard.
|
|
Voici la traduction d'un post de Tito Ingargiola du blog "Hack the market" dont des articles ont déjà été traduits sur le site (cf la série intitulée le miroir aux alouettes de l'optimisation). Tito Ingargiola a décidé de quitter en 2005 sa position de spécialiste en technologie a Wall Street pour créer Puppetmaster Trading et poursuivre ainsi à temps plein son intérêt croissant pour le trading algorithmique. Article Original : Putting the pieces together J'ai parcouru lors de mes derniers posts un ensemble important de choses liées au trading algorithmique. Jugeant par l'expression faciale de quelques professionnels très intelligents et expérimentés de Wall Street lorsque j'ai évoqué les mêmes sujet, tout ceci ne doit pas être évident. Commençons avec la stratégie de trading. Qu'est ce qu'un contexte de trading algorithmique. Conceptuellement, c'est une chose assez simple. C'est quelque chose qui peut étudier les données du marché et peut manager des positions. C'est réellement ça. Ses "yeux " surveillent une ou plusieurs sources de données de marché et ses "mains" s'occupent d'un Système de Management des Ordres (OMS Order Management System). Il y a un potentiel évident de complexité avec cette simple définition et nous passons même au dessus d'éléments importants, mais nous nous tiendrons à ça pour le moment. Les données de marché peuvent être un simple flux de "barres" ou "bougies" représentant des données Open-High-Low-Close-Volume (OHLCV). Ca peut être un flux de ticks datés et peut aussi inclure des informations sur la profondeur du marché ou le carnet d'ordre. Cela peut être de nombreux flux de données compréssées ou des flux directs. Le flux peut comprendre les nouvelles ainsi qu'une sorte de couche, un moteur de traitement des évènements complexes (Complex Event Processing engine - CEP), qui aide à donner du sens aux flux lors de leur arrivée. Qu'importe. La stratégie reçoit un ou plusieurs flux de données. Comment elle utilise ces données (pour annoter un modèle financier complexe de l'univers, ou simplement créer une graine de générateur de nombres aléatoires qui lance une pièce virtuelle pour acheter, vendre, garder ou se délester) n'est pas important ici. Quand la stratégie déclencher une action, elle interagit avec son Système de Management des Ordres (OMS). Du coté vendeur, un OMS peut être un système de serveurs qui écoute les ordres des clients et les route vers les divers marchés ou contre-parties et ensuite en acquitte les résultats (exécution, annulation, etc). J'ai construit et travaillé autours de réels monstres, et ils peuvent être complexes et intéressants mais ce n'est pas réellement le sujet de notre discution. Nous sommes plus concernés par l'aspect acheteur des OMS qui siègent typiquement sur la station de travail du trader et leur procure un accès à un ou plusieurs marchés, un carnet de trading et plusieurs fonctions incluant le management de portefeuilles, du management des risques, du reporting,de la régulation et encore beaucoup d'autres. Mais la fonction basique de l'OMS est de procurer des moyens de manager ses positions: entrée, annulation et modification des ordres et création et mise à jour des positions à la réception des rapports d'exécution. Ce coté client des OMS ont typiquement un interface graphique (GUI) qui est assez sophistiqué et peut inclure toutes sortes d'alarmes. Petit à petit, les OMS s'ouvrent eux mêmes à des interactions de programmation aux travers des APIs propriétaires ou des standards communs comme le protcole FIX. C'est de cette manière que la stratégie de trading électronique peut interagir avec l'OMS (au travers des APIs). C'est aussi petit à petit la manière avec laquelle il interagira avec les données de marché. Il s'abonnera typiquement à un ensemble de données et recevra passivement des notifications de changement. Une stratégie de trading aura donc au moins une relation avec le service de données de marché basé sur l'abonnement et un fonctionnement étroit avec un OMS. Il aura peut être beaucoup d'autres relations, mais ces deux sont le minimum nécessaire. Il est important de noter que cet environnement de base pour le trading algorithmique est aussi requis pour un trader manuel. En effet, dans tous les cas on a besoin de savoir où les marchés que l'on trade se trouvent et être capable de placer des ordres et de recevoir des réponses. Commes les OMS se sont ouverts à une l'intéraction de programmation, une nouvelle sorte de logiciel a émergé: l'Exectution Management System (EMS). Les EMS sont très variables mais ils sont importants dans notre cas car uns stratégie de trading automatique a besoin d'une place ou d'un conteneur dans lequel travailler. Cette place est l'EMS. La ligne de séparation entre l'OMS et l'EMS est floue, mais l'OMS procure les fonctionnalités de base (et peut être beaucoup plus) tandis que l'EMS reposera sur l'OMS et procurera certaines fonctionnalités spécifiques. C'est pourquoi, dans ce sens, la plupart des produits de trading algorithmique sont des EMS. [...] Traduction: Nicolas Vitale
|
|
Face à la quantité de flux disponibles sur le Forex et à la dispersion des liquidités, il est très difficile d'avoir une bonne visibilité du marché. La conséquence est généralement une augmentation du nombre de trades pour de petits volumes, ce qui augmente les couts d'exécution. Les organisations qui sont actives sur le Forex ont donc besoin d'outils qui permettent d'aggréger les diverses sources et leur carnet d'ordres. Des outils permettent alors d'aggréger les carnets d'ordre, de trouver des opportunités d'arbitrage parmi les diverses sources Forex et d'envoyer des ordres en sélectionnant le flux offrant le meilleur spread. Voici à ce propos une présentation d'une plateforme développée par la société StreamBase et réalisant tout cela. Le point de vue est surement commercial, mais il est intéressant de voir ce que propose ces outils. La vidéo est disponible à l'origine sur la page Forex Aggregation de Streambase.
|
|
Écrit par Nicolas Vitale
|
|
De nombreux protocoles ont été développés dans l'industrie financière pour permettre l'échange d'informations financières. Une entreprise doit donc mettre en oeuvre de nombreux protocoles pour pouvoir faire fonctionner ses systèmes de trading, management des risques ainsi que tous ses systèmes de back office au sens large. Certains sont basés sur le standard XML et d'autres non. Voici une liste non exhaustive des protocoles basés sur le XML : - Financial Information Exchange (FIX)/FAST/FIXML: FIXML est la version XML de FIX.
- FpML: Financial Products Markup Language.
- Swift/SwiftML: SwiftML is the XML version of Swift.
- RIXML: Research Information Exchange Markup Language.
- MDDL: Market Data Definition Language;
- FinXML.
- SFXL: Securities Financing Extensible Markup Language.
- OFX: Open Financial Exchange.
- XBRL: Extensible Business Reporting Language.
- IFX: Interactive Financial Exchange.
- IRML: Investment Research Markup Language.
- XFRML: Extensible Financial Research Markup Language.
- MDML: Market Data Markup Language.
- WeatherML: Weather Markup Language.
- STPML: Straight Through Processing Markup Language.
Un des standards le plus utilisé n'est cependant pas basé sur le XML. C'est le protocole FIX promu par Protocol, Ltd. (FPL). Les institutions financières utilisent le protocole FIX pour communiquer rapidement les trades (et les informations s'y rapportant) de manière électronique entre les Bourses et les Contre Parties. Le protocole a d'ailleurs été adopté par la majorité des places boursières actions, Futures, Obligations, etc, ainsi que par les entreprise y traitant. Le protocole FIX est donc désormais un incontournable du secteur du trading en temps réel et fait donc partie intégrante des systèmes de trading. L'un des avantages de FIX, en plus du fait qu'il soit totalement ouvert et gratuit, est qu'il possède une grosse communauté commerciale et qu'il est donc possible de le mettre en place sans vraiment comprendre de quoi il est fait. Il suffit alors d'acheter une license d'un logiciel mettant en place le moteur FIX (FIX engine). Un moteur FIX est un bloc de logiciel qui permet de générer les messages FIX sortants et de lire les messages FIX rentrants et s'utilise donc pour connecter vos applications au monde exterieur. Le moteur FIX permets de gérer à la fois les couches sessions et applicatives de vos applications de trading ou de management. Le niveau session a pour mission d’assurer la bonne réception des données quand le niveau applicatif définit le contenu relatif aux échanges commerciaux. Pour les entreprise préférant mettres les mains dans le code, il existe (au moins) un moteur FIX Open Source (QuickFIX) compatible avec la plupart des systèmes d'exploitation Windows, Linux, Solaris, FreeBSD et Mac OS X. Les API sont disponibles pour le C++, Java, .NET, Python et Ruby. Construire un Système de Management des Ordres (OMS System Management Order) est un énorme travail à la fois en terme de planification et design qu'en terme d'investissement financier en logiciel et hardware. D'après Benjamin Van Vliet et son livre "Building Automated Trading Systems", utiliser le protocol FIX dans un tel cadre à une petite échelle peut ne pas être très cher (quelques milliers d'euros), par contre avec une implémentation complète à grande échelle les prix flambent rapidement pour atteindre le million de dollars.
|
|
|
<< Début < Précédent 1 2 3 4 5 Suivant > Fin >>
|
|
Page 5 sur 5 |
|