Salle de marchés - Définition

Relations avec le back-office

La réglementation bancaire édicte, dans la plupart des pays, le principe d'indépendance entre front-office et back-office : une opération négociée par la salle des marchés doit être validée par le back-office pour être ensuite confirmée à la contrepartie, être réglée, et comptabilisée. Ces services doivent être rattachés à des directions indépendantes l'une de l'autre jusqu'au niveau le plus élevé possible dans la hiérarchie.

En Allemagne, la réglementation va plus loin, le « principe des quatre yeux » exigeant que toute négociation conclue par un opérateur de marché soit vue par un autre opérateur avant d'être soumise au back-office.

En Europe continentale, les établissements mettent l'accent, dès le début des années 1990, sur le Straight Through Processing (STP), c'est-à-dire l'automatisation de la transmission des opérations vers le back-office. Leur objectif est d'améliorer la productivité des agents du back-office, en remplaçant une ressaisie des opérations par une validation.

Les éditeurs du risk-management ou de la gestion de portefeuille répondent à cette attente soit en ajoutant dans leur système les fonctionnalités back-office, soit en y développant la connectivité, pour faciliter l'intégration des opérations dans un progiciel dédié au back-office. Les anglo-saxons, moins réticents à la création de postes dans les back-office, sont moins sensibles au critère de la productivité, et développent leurs interfaces avec quelques années d'écart. Sur les marchés des titres, les réformes de Place visant à réduire le délai de règlement-livraison, généralement de 3 jours ouvrés, à 1 voire 0 jour, constituent un aiguillon pour l'automatisation des flux.

Tant que les systèmes de front-office et de back-office sont séparés, les opérateurs les plus réticents à saisir eux-mêmes leurs transactions dans le système front-office, qu'ils trouvent naturellement plus contraignant que leur tableur, sont tentés de se défausser sur un assistant trader ou un agent du middle-office. Une politique de STP est alors aussi un moyen détourné pour les contraindre à saisir eux-mêmes. Du reste, l'enregistrement informatique des transactions, et dans le délai le plus bref à partir de la négociation, relève d'une « bonne pratique », voire d'une obligation réglementaire.

La réglementation tend à priver la salle des marchés du pouvoir de valorisation des positions. Cependant, les agents du back-office ne sont pas nécessairement en situation de pouvoir critiquer les prix proposés par le front-office pour des instruments complexes ou peu liquides, et qu'aucune source indépendante, telle Bloomberg, ne publie.

L'équipement logiciel

Dès la fin des années 1980, les feuilles de calcul ont rapidement proliféré sur les postes des traders tandis que le chef de salle, lui, n'avait pas de vision consolidée des positions qui soit à la fois exacte et en temps réel. L'hétérogénéité des règles de valorisation, la fragilité des feuilles de calcul susceptible d'entraîner des pertes de données critiques, les médiocres temps de réponse des PC pour assurer des calculs lourds, le manque de visibilité sur l'activité des traders, ont très vite suscité le besoin d'un système d'information partagé. Cependant, les établissements éprouvent d'autres besoins, selon que leur métier est le trading ou l'investissement.

Le risk-management

Le premier type d'application dédiée aux risques à s'introduire dans une salle de marchés, à la fin des années 1970, porte sur le contrôle global de limites d'engagement par contrepartie. Risk Exposure Management (RXM), développé par GE Information Services, et Global Limits Control System, commercialisé par Reuters, mettent à jour en temps réel les utilisations de limites de crédit et de règlement provenant des transactions négociées dans quelque salle des marchés que la banque ait dans le monde. Ces applications ne traitent alors que les opérations de change et les prêts interbancaires, et imposent une saisie sur un poste dédié, mais elles incarnent une architecture informatique sophistiquée pour l'époque.

Avec la multiplication des instruments traités par la salle, la direction des opérations de marché souhaite mettre en œuvre des processus collaboratifs entre desks, tels que :

– la couverture du risque de change comptant issu des positions de swaps de change ou de change à terme ;

– le refinancement par le desk interbancaire des positions de trading restant en portage en fin de journée ;

– la couverture des positions obligataires par des contrats ou options de taux d'intérêt.

Ces mécanismes nécessitent une mutualisation des données entre desks.

C'est ainsi que sont apparus, entre 1990 et 1993, Infinity, Summit, Kondor+, Finance Kit, Front Arena, Murex et (en)Sophis Risque, rapidement mis sur le marché et placés sous la bannière du "risk-management", un terme valorisant mais sans doute moins exact que celui de « tenue de position ».

Bien qu'Infinity disparaisse, en 1996, avec le rêve brisé du toolkit censé traiter toutes les innovations de l'ingénierie financière, les autres systèmes sont encore bien vivants dans les salles de marché.

Ces produits ont généralement pour caractéristiques une architecture trois tiers, dont la partie back-end tourne sur une plateforme Unix, une base de données relationnelle (Sybase ou Oracle), un mécanisme d'acquisition en temps réel de données distribuées par le système RMDS de Reuters, et une interface utilisateur graphique et écrite en anglais, puisque leurs clients sont des salles de marchés situées n'importe où dans le monde. Saisie des transactions par les opérateurs, tenue de position, mesure des risques de marché (taux et change), calcul du P&L, par desk ou opérateur de marché, contrôle des limites fixées par contrepartie, sont les principaux services rendus par ces logiciels.

L'utilisation de ces fonctionnalités sera rendue obligatoire ultérieurement : en France, elles sont définies en 1997 dans une instruction de la Commission Bancaire relative au contrôle interne.

Le trading électronique

Le téléphone, utilisé sur les marchés de gré à gré, est source de malentendus. Les deux parties s'étant mal comprises sur un des termes de la négociation, il est quelquefois trop tard pour redresser une opération quand la confirmation est reçue et révèle une anomalie.

Le premier marché à découvrir le trading électronique est le marché des changes. Reuters crée son Reuter Monitor Dealing Service en 1981. Les contreparties se repèrent par écran interposé et conviennent d'une transaction en mode vidéotex, où les données sont encore peu structurées. Son successeur, Dealing 2000, porté sous Windows, est lancé en 1989. Comme (en)EBS, qui le concurrence à partir de 1997, il traite essentiellement le change comptant.

Les États-Unis voient ensuite apparaitre plusieurs offres, Bloomberg, BrokerTec, TradeWeb, notamment, dans le domaine des valeurs mobilières, tandis que dans les salles des marchés européennes apparaissent l'italien MTS et le français Web-Bonds ; bien que les obligations (mais pas les bons du Trésor) soient cotées en bourse, 90 % des transactions obligataires sont négociées en gré à gré, d'où la pertinence de ces outils.

Plus récemment sont apparus des produits spécialisés, comme Swapswire, pour négocier les swaps de taux, Secfinex et Equilend pour le prêt/emprunt de titres (c'est l'emprunteur qui paie l'abonnement au service).

Cependant, ces outils souffrent généralement d'un manque de liquidité. Contrairement à une prédiction maintes fois annoncée, le trading électronique n'a pas fait disparaitre le courtage traditionnel. Du reste, les opérateurs préfèrent panacher les deux modes : l'écran, pour la découverte des prix, et la voix, pour traiter les grosses transactions.

Carnet d'ordre et routage

Pour les produits des marchés organisés, les processus sont différents : les ordres de la clientèle doivent être rassemblés, le cas échéant exécutés en interne, quand ils peuvent être appariés, avant d'être transmis à un broker, un système multilatéral de négociation, ou directement en bourse, si la valeur est domestique, la liquidité du titre suffisamment importante et la taille de l'ordre pas trop élevée. Les ordres sont ensuite exécutés partiellement ou en totalité, puis dépouillés, c'est-à-dire imputés sur le compte de chaque donneur d'ordre. La multiplication des instruments traités et des circuits de transmission ont alors rendu nécessaire l'informatisation de ce carnet d'ordres.

Les marchés organisés (bourses et marchés à terme) proposent chacun leur poste de saisie et transmission d'ordres, voire une interface de programmation, pour permettre à l'établissement de se connecter à partir d'un système de gestion d'ordres développé en interne. Mais des éditeurs proposent aussi aux salles des marchés des progiciels qui prennent en charge les différents protocoles de communication à ces marchés, notamment Fidessa, très présent à Londres, Sungard Global Trading et le suédois Orc Software.

Le program trading

Dans le program trading, les ordres sont générés par un programme informatique, au lieu de procéder d'une décision d'un opérateur de marché. On parle également de trading algorithmique. Il ne s'applique qu'aux marchés organisés, pour lesquels la transaction ne dépend pas d'une négociation avec une contrepartie en particulier.

Une application classique du program trading consiste à générer des ordres d'achat ou de vente d'une action dès que son prix franchit un certain seuil, à la hausse ou à la baisse. Une vague de ventes sur prix stop a été ainsi largement incriminée, lors de la crise financière de 1987, comme la cause de l'accélération de la chute des cours en bourse. Depuis lors, cependant, le program trading n'a cessé de prendre de l'importance, notamment avec la multiplication des ETF, OPCVM répliquant un indice boursier, et le développement de la gestion structurée. Un ETF répliquant le CAC 40, par exemple, passe 40 d'ordres d'achat, ou 40 ordres de vente, selon que le fonds enregistre, du jour au lendemain, un flux net de souscriptions ou de rachats ; on appelle généralement panier la série d'ordres répliquant l'indice. De plus, une modification du poids des actions dans un indice, sous l'effet par exemple d'une augmentation de capital de l'une d'entre elles, nécessite de passer autant d'ordres d'achat ou de vente pour que la composition du fonds continue à refléter fidèlement celle de l'indice. Si un programme permet de générer plus rapidement un gros volume d'ordres qu'un trader, il peut cependant nécessiter la surveillance d'un ingénieur financier, qui le cas échéant y apporte ses retouches.

La multiplicité des programmes de trading, dont certains appliquent les mêmes règles de gestion, amène leurs concepteurs à chercher un avantage compétitif grâce à la technique, en jouant sur la puissance des serveurs de flux boursier ou le multi-threading de façon à s'assurer que les ordres parviennent dans le carnet d'ordres central avant ceux des concurrents. La réussite d'un algorithme peut ainsi se jouer au millième de seconde. Ce type de program trading, qu'on appelle généralement high-frequency trading, est cependant contraire au principe d'équité de traitement entre donneurs d'ordre, et plusieurs régulateurs envisagent de l'interdire.

La gestion de portefeuille

Au retour d'exécution d'un ordre, le gérant d'OPCVM comme le trader d'une banque d'investissement doivent mettre à jour leurs positions. Cependant, le gérant n'a pas besoin de valoriser ses positions en temps réel : à la différence du trader dont l'horizon est la journée, le gérant se place dans une perspective de moyen-long terme. En revanche, il a besoin d'un contrôle de provision et d'une confrontation de son portefeuille à son benchmark, voire d'un traitement de rebalancing (rééquilibrage), qui génère les ordres nécessaires pour que le portefeuille revienne à la composition de référence.

Une autre famille de progiciels, de gestion de portefeuille, assure ce type de besoins. Bloomberg, Decalog, Apollo, Triple A, Sophis Value, (en)Simcorp, en sont les principaux représentants.