FR 2794263 A1 20001201 FR 9906911 A 19990527 Procédé et système pour traiter, de gré à gré, des ordres d'achat et de vente portant sur des instruments financiers standards et/ou spécifiques. La présente invention concerne les procédés et les systèmes permettant de soumettre et/ou d'optimiser et/ou de réaliser et/ou d'exécuter des ordres d'achat et de vente sur des instruments, principalement financiers, traités de gré à gré. Les instruments concernés sont des instruments standards et/ou des instruments spécifiques. Instruments standards. Au sens de la présente invention, des instruments standards sont des instruments dont les caractéristiques sont constantes, non modifiables par les utilisateurs, et préenregistrées dans le système. A titre d'exemple d'instrument standard, on citera le cas d'un dépôt à six mois en devise USD (dollars US) , démarrant en date de valeur du jour, c'est-à-dire deux jours ouvrés après la date du jour. Instruments spécifiques ou non-standards Au sens de la présente invention, on désigne par instruments spécifiques (ou non-standards) tous les autres instruments. Il s'agit d'instruments dont les caractéristiques sont définies et introduites par un utilisateur dans le système. Par définition, ils n'existent pas dans la gamme des instruments standards. A titre d'exemple d'instrument spécifique, on citera le cas d'un dépôt à six mois en devise USD, démarrant dans 126 jours ouvrés, ou bien encore le cas d'un dépôt à six mois avec amortissement du capital mensuel. Dans le cas des instruments standards comme dans le cas des instruments spécifiques, le procédé et le système selon l'invention permettent d'organiser un appel aux "enchères" à l'achat et à la vente en temps réel, parmi les utilisateurs connectés aux systèmes. Le procédé et le système selon l'invention remplissent et fournissent les services suivants, que les instruments soient standards ou spécifiques. Le procédé pour traiter, de gré à gré entre des utilisateurs disposant de terminaux informatiques, des ordres d'achat et de vente portant sur des instruments financiers standards et/ou spécifiques ; ledit procédé comprend au moins l'une des étapes ci-après mentionnées. a. On collecte en temps réel ou pseudo-réel des ordres d'achat et de vente passés par des utilisateurs. b. On compile et on agrège par prix les ordres. c. On distribue les ordres aux utilisateurs. d. On marie les ordres lorsqu'ils sont compatibles. e. On réalise une transaction lorsque deux ordres ont été mariés. Avantageusement, le procédé selon l'invention comporte en outre l'étape de traiter les ordres et les instruments financiers associés - en gérant * les conditions d'existence de l'ordre, notamment liées à des conditions internes et/ou externes, par exemple la valeur du CAC40, et/ou * les paramètres de l'ordre, notamment en fonction de paramètres internes et/ou externes, par exemple le prix en fonction de la date, et/ou - en groupant les ordres et en passant des ordres groupés, et/ou - en recherchant des instruments financiers synthétiques améliorant la réalisation des ordres passés, et/ou - en recherchant des instruments financiers synthétiques permettant à un groupe désigné d'utilisateurs de négocier un maximum d'ordres avec au moins un autre utilisateur. De préférence, pour collecter en temps réel ou pseudo-réel des ordres d'achat et de vente passés par des utilisateurs, on utilise un navicrateur internet. De préférence également, pour compiler et agréger par prix des ordres soumis à des conditions de validité, on gère lesdites conditions de telle sorte que seuls les ordres valides soient pris en compte. Ainsi, on obtient une distribution d'intérêts de marché optimisée et homogène, et une profondeur de marché facilement lisible. De préférence également, pour marier les ordres, on sélectionne les utilisateurs qui peuvent négocier entre eux et/ou qui ne peuvent négocier que certains instruments et/ou qui ne peuvent négocier que des opérations d'un certain montant. De préférence également, pour réaliser une transaction lorsque deux ordres ont été mariés, on procède de manière automatique en adressant des confirmations, notamment par fax, par mel ou par télex, à chacun des utilisateurs concernés. La présente invention concerne également un système pour traiter, de gré à gré entre des utilisateurs disposant de terminaux informatiques, des ordres d'achat et de vente portant sur des instruments financiers standards et/ou spécifiques. Le système selon l'invention comprend au moins un centre serveur. Chaque centre serveur comprend : - des moyens de collecte et de mémorisation pour collecter, en temps réel ou pseudo-réel, des ordres d'achat et de vente passés par des utilisateurs, - des moyens de traitement informatique pour compiler et agréger par prix les ordres. Ledit centre serveur est connecté, via un réseau de communication informatique, notamment du type internet, auxdits terminaux informatiques. Ainsi, les utilisateurs reçoivent les ordres et les informations diffusées par le centre serveur. Les moyens de traitement informatique dudit centre serveur comprennent en outre des moyens d'analyse pour marier les ordres compatibles et constater qu'une transaction peut intervenir entre les utilisateurs ayant passés les ordres concernés. Avantageusement, lesdits moyens de traitement informatique traitent les ordres et les instruments financiers associés - en gérant * les conditions d'existence desdits ordres, notamment liées à des conditions internes et/ou externes, par exemple la valeur du CAC40, et/ou les paramètres desdits ordres, notamment en fonction de paramètres internes et/ou externes, par exemple le prix en fonction de la date, et/ou - en groupant les ordres et en passant des ordres groupés, et/ou - en recherchant des instruments financiers synthétiques améliorant la réalisation des ordres passés, et/ou - en recherchant des instruments financiers synthétiques permettant à un groupe désigné d'utilisateurs de négocier un maximum d'ordres avec au moins un autre utilisateur. De préférence également, les moyens de collecte comportent un navigateur internet. De préférence également, pour compiler et agréger par prix des ordres soumis à des conditions de validité, les moyens de traitement informatique comportent des moyens de gestion pour gérer lesdites conditions de telle sorte que seuls les ordres valides soient pris en compte. Ainsi, on obtient une distribution d'intérêts de marché optimisée et homogène, et une profondeur de marché facilement lisible. De préférence également, pour marier les ordres compatibles et constater qu'une transaction peut intervenir entre les utilisateurs ayant passé les ordres concernés, lesdits moyens d'analyse comportent des moyens de sélection pour sélectionner les utilisateurs qui peuvent négocier entre eux b et/ou qui ne peuvent négocier que certains instruments et/ou qui ne peuvent négocier que des opérations d'un certain montant. De préférence également, lesdits moyens d'analyse pour marier les ordres compatibles et constater qu'une transaction peut intervenir comprennent des moyens de transmission, notamment par fax, par me] ou par télex, pour confirmer la transaction à chacun des utilisateurs concernés. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description de variantes de réalisation de l'invention, données à titre d'exemple indicatif et non limitatif, et de : - les figures la et lb présentant de manière schématique divers systèmes actuellement employés manuellement pour permettre la réalisation de transactions entre les opérateurs de marché (opérations connues sous le nom d'opérations de "trading"), - la figure 2 présentant le système selon l'invention. On va maintenant décrire, en se référant aux figures la et lb, la configuration des divers systèmes actuellement employés manuellement pour permettre la réalisation de transactions entre les opérateurs de marché. Les marchés financiers reposent sur des échanges d'instruments. Ces échanges s'effectuent entre divers acteurs ou groupes d'acteurs en suivant certains canaux de distribution et de communication. L'architecture de ces canaux tient compte des rôles de chaque type d'acteurs, et inversement, la fonction de chaque acteur ou groupe d'acteurs définit implicitement la nature des liens qui les relient entre eux. La figure I.a représente une vue schématique de l'organisation de ces liens, en schématisant au plus simple les groupes d'acteurs en présence. Cette figure représente une salle de marché 1 d'une banque située dans une ville donnée (Banque A à Paris) pour laquelle deux tables de marché (autrement appelées "desks" en langue anglaise) ont été montrées. A ces tables sont présents deux grandes catégories d'opérateurs de marché : les vendeurs (table La) et les coteurs-gestionnaires des risques et positions (table 11). Il faut noter que le vendeur n'est pas nécessairement dans la même pièce que le coteur : il peut être dans une agence de province, ou dans une autre salle. Certains vendeurs Lc gèrent la relation avec les entreprises clientes 10 (par exemple PEUGEOT), en lui communiquant informations, prix, conseils. Un autre vendeur Ld peut être chargé de suivre les relations de marchés non pas avec des entreprises, mais avec des banques (vendeur interbancaire). Le vendeur tire sa valeur ajoutée des marges qu'il dégage entre les prix traités avec le client, et le prix auquel la banque se couvre dans le marché par l'intermédiaire du coteur. Des départements internes peuvent être amenés à solliciter les opérateurs d'une salle de marché : par exemple, la direction financière 9 peut avoir besoin d'effectuer des couvertures de risques sur les marchés pour couvrir ses risques de bilan. Elle s'adresse à la "salle" en général par téléphone. L'échange de ces données, notamment les demandes de prix, est répétitif, a se fait en général par téléphone, interphone, voire fax, mel. Il est donc entièrement manuel. Parfois, les coteurs diffusent leurs conditions d'achat et de vente sur des pages internes d'information électronique (à l'instar d'un guichet de change sur les Champs-Elysées qui indique en permanence à quel prix il achète et vend ses devises). A la table des coteurs, on distinguera la présence de différents types de coteurs/gestionnaires de risques, répartis par classe de marché ou d'instrument, ces opérateurs gèrent : - les cotations et risques de change le, - les obligations Américaines Ig, - des produits dérivés de taux lh, des produits de prêt et d'emprunt (trésorerie) 1 i, etc.. Dans les grandes banques, une table de marché ne contient que des opérateurs d'une même classe. Entre eux, les coteurs sont aussi amenés à communiquer et traiter : par exemple, l'opérateur Ig en charge des obligations Américaines peut être amené à se défaire d'un risque de change en Dollar Américain résiduel sur ses positions obligataires en traitant une opération de Dollar Américain contre Euro avec l'opérateur de change le. Dans ce cas, l'opérateur Ig s'apparente à un vendeur, ou plutôt à un client vis-à-vis de l'opérateur le. Tous ces échanges sont administrés par téléphone, interphone, fax, terminal électronique conversationnel de type Reuter 2000, E-Mail, ... Ces échanges sont donc manuels et du type "un-contre-un". Une salle 2 de même nature que la salle 1 peut se retrouver dans la même banque A mais dans une autre localité (par exemple à New York), ou dans d'un autre établissement bancaire B à Paris 3 ou à New York 4, ou dans d'autres banques C 6, D 7. L'ensemble de ces "nodules" constitue le marché financier 5. La zone 5 représente symboliquement la multitude des banques, clients, ou autres acteurs, qui peuvent entrer en contact avec la banque A. Afin de réguler et faciliter les échanges entre les banques, les courtiers 8, véritables intermédiaires pour les transactions entre banques, sont reliés chacun à un grand nombre de banques. Ils sont aussi parfois reliés à d'autres courtiers. Leur métier est de marier les intérêts de marchés de banques qui leur sont reliées. Ils se rémunèrent à la commission sur chaque opération effectuée par leur intermédiaire. Ces courtiers communiquent le plus souvent par téléphone avec leurs clients (qui sont des coteurs en général ou gestionnaires de positions). Ils communiquent aussi par terminal conversationnel électronique Reuter Dealing 2000. Ils utilisent peu ou prou les mêmes moyens de communication qu'entre les vendeurs et les coteurs d'une même banque. La figure lb représente une vue de face d'une disposition classique d'écrans telle que l'on peut la trouver chez un opérateur chargé d'effectuer des cotations et de gérer des portefeuilles de transactions à risque (opérations autrement appelées "Desk Trading" ou "Desk Trader" en langue anglaise). La référence 20 désigne une platine téléphonique, comprenant une dizaine de lignes ouvertes en permanence vers certains interlocuteurs (en général des courtiers), ainsi qu'un grand nombre de lignes téléphoniques traditionnelles. Les lignes ouvertes permettent en général de s'adresser aux interlocuteurs choisis par l'intermédiaire d'un ou plusieurs microphones. La référence 21 désigne les sorties haut-parleur des lignes téléphoniques ouvertes. La référence 22 désigne un écran de visualisation des informations du marché. La référence 23 désigne une fenêtre de l'écran 22 diffusant des informations Reuter, notamment des nouvelles économiques, financières, spécialisées, à la carte, sous forme de menu défilant. La référence 24 désigne une sous-fenêtre de la fenêtre Reuter 23, diffusant, notamment des prix, des informations sur les sociétés, le suivi des cours et des analyses relatifs à une entreprise particulière, ou à une zone économique particulière. La référence 25 désigne une fenêtre de l'écran 22 utilisée pour l'affichage du cours de change USD/EURD. La référence 26 désigne une fenêtre de l'écran 22 utilisée pour l'affichage de nouvelles de marché. La référence 27 désigne une fenêtre de l'écran 22 sur lequel s'affiche entre autres l'indice Dow Jones et des nouvelles de l'ASSIOCATED PRESS. La référence 31 désigne un deuxième écran de visualisation. La référence 28 désigne une fenêtre de l'écran 31 montrant sous forme graphique l'historique des taux d'intérêts. La référence 29 désigne une fenêtre de l'écran 31 permettant l'affichage de la messagerie Bloomberg (système de messagerie électronique disponible à partir d'un accès à un réseau d'informations et d'analyse appartenant à la société Bloomberg). La référence 30 désigne une fenêtre de l'écran 31 permettant de mettre en oeuvre le système Reuter Dealing (Système de conversation électronique, relié aux autres opérateurs (Traders) des banques). La référence 32 désigne un écran Reuter 2002 qui est un courtier électronique interbancaire, intégré au terminal conversationnel Reuter Dealing, permettant d'effectuer des opérations de change au comptant standard entre banques. La référence 33 désigne un écran permettant de mettre en oeuvre un système de courtage électronique (autrement appelé "Electronic Broking System" en langue anglaise du nom d'une société fournissant des prestations de courtier électronique interbancaire, à l'image du système Reuter 2002 décrit ci-dessus). La référence 34 désigne un écran de visualisation dédié à la saisie des transactions, la visualisation des positions et risques de marché, etc. ... (Gestion de position (Front Office . La référence 35 désigne une fenêtre de l'écran 34. Cette fenêtre est dédiée à la saisie des opérations (Entrée Deals ). La référence 36 désigne une fenêtre de l'écran 34. Cette fenêtre affiche les profits et pertes du jour. La référence 37 désigne une fenêtre de l'écran 34. Cette fenêtre permet d'afficher les positions (Stocks). La référence 39 désigne une fenêtre de l'écran 34. Cette fenêtre permet d'afficher les lignes de crédit. On va maintenant décrire le système selon l'invention, en se référant à la figure 2 qui représente de manière schématique une variante de réalisation. L'architecture relie les mêmes acteurs que ceux de la figure la. Les liens traditionnels tels que téléphone, fax, interphone, etc. sont dans le cas de l'invention tous remplacés par un mode unique de transmission de données : des connexions informatiques, en général du type TCP/IP (Transmission Control Protocol/Internet Protocol) 46. Les utilisateurs agissent tous par l'intermédiaire d'un terminal, possédant une interface Homme-Machine programmée en langage objet (JAVA, C++,..) qui communique avec le réseau par l'intermédiaire d'un navigateur internet 51. Un organe central à chaque banque, composé d'un ou plusieurs serveurs d'application 45 et de base de données relationnelles ou non 42, gère la collecte, la compilation et la redistribution des prix ou cotations. Il gère également le processus transactionnel qui permet de conclure une opération à partir de deux intérêts de mêmes caractéristiques mais de sens opposés (un acheteur, un vendeur, même instrument, montants compatibles, prix compatibles, contreparties compatibles entre elles). Les utilisateurs disposent de terminaux informatiques connectés au serveur 45, 45'(dans la suite du texte on désignera par la même référence numérique l'utilisateur considéré et le terminal informatique dont il dispose). Considérons les utilisateurs amenés à traiter des opérations dans le cadre de la banque A. Certains utilisateurs (type coteur 48) alimentent le serveur 45 en cotations, d'autres passent des ordres fermes (par exemple les vendeurs 47, ou un client PEUGEOT 40, ou la direction financière 50, ou la branche de New York de la banque A 43). Les accès au serveur 45 sont variés. On peut utiliser des connections directes : - sur un réseau interne informatique appelé LAN (Local Area Network) ou WAN (Wide Area Network) selon la taille, et/ou - par lignes téléphoniques 49, On peut aussi utiliser des connections par le réseau internet 44. Le protocole de communication est de type TCPîIP (voir ci-dessus), sécurisé. Le mode peut être : - connecté (type I.I.O.P Internet Inter ORB Protocol, ORB Object Request Broker) 52, et/ou - déconnecté (type HTTP : HyperText Transfert Protocol) Les transmissions de données sont cryptées par des moyens standards, l'authentification des utilisateurs est assurée par la présence de certificats de serveurs qui reconnaissent les signatures électroniques de chaque personne entrant en connection sur la plate-forme. Un tel organe central, complété par les divers moyens d'accès qui permettent de l'alimenter constitue une plate-forme électronique transactionnelle 53 interne à une même banque (plate-forme intrabancaire). La banque B est elle aussi munie d'une plate-forme électronique 54, de configuration similaire à celle de la banque A. La plate-forme électronique 54 comprend : le serveur d'application 45' de la banque B de Paris, le serveur de données 42' de la banque B de Paris, le navigateur internet 5 l' de la Banque B de Paris, les terminaux 47' de la banque B de Paris, les terminaux 50' direction financière de la Banque B de Paris, les terminaux 43' de la banque B de New York. Ces deux plates-formes 53 et 54 peuvent communiquer entre elles soit directement, soit par le réseau internet 44. Le système peut aussi comprendre une plate-forme 55 des plates-formes interbancaires, capable de communiquer soit avec une plate-forme intrabancaire du type 53 ou 54, soit avec un seul utilisateur connecté directement à elle. Cet utilisateur directement connecté peut être un coteur dans une banque de plus petite taille. Celle-ci n'a donc pas la nécessité de s'équiper d'une plate-forme interne électronique. Ainsi, on constitue un réseau interconnecté permettant potentiellement de collecter l'ensemble des intérêts de tous les opérateurs de marchés de toutes les banques. Des règles du jeu (ou règles de compatibilité) sont définies afin de limiter l'accès de chacun à ce réseau, selon des critères divers et variés (barrage sélectif 41). Le système intègre une définition de paramètres de compatibilité propre à chaque utilisateur, aboutissant au dessin d'un profil comportemental individuel. Les prix visibles par chaque utilisateur sont donc fermes à chaque instant : il n'est pas nécessaire de les vérifier. A. Collecte des ordres d'achat et de vente en temps réel ou pseudo-réel. En fait la connexion 44, 46, 49, 52 entre les terminaux 40, 43, 47, 48, 50, 43', 47', 50' et le serveur 45, 45' ne reste pas nécessairement ouverte en permanence (mode temps réel) pour des raisons de sécurité. Il s'agit plutôt de séquences très rapprochées d'aller et de retour uniques (mode pseudo réel). Dans la suite de la description les notions de "temps réel" ou de "temps pseudo-réel" auront le sens ci-après défini. Ainsi, par exemple, dans le cas d'un transfert aller et retour entre A et B, le transfert est effectué en temps réel si la porte de sortie de A entre A et B est ouverte en permanence, de même que celle de B entre B et A. Une donnée peut donc librement s'échapper de A pour aller vers B et réciproquement. Pendant qu'elle transite, les portes restent ouvertes. Ce mode est dit connecté. Dans le cas d'un transfert en temps pseudo-réel, le processus de transit est différent. La porte de A vers B s'ouvre, la donnée peut transiter vers B. La porte de A se ferme aussitôt après. La porte de B s'ouvre à l'arrivée de la donnée. La porte de B se referme aussitôt la donnée rentrée. De même dans l'autre sens. Ce mode est qualifié de pseudo-connecté. Dans la pratique, l'ouverture des portes A et B est séquencée à intervalles réguliers (toutes les 1/2 secondes, ou toutes les secondes, ou plus), de sorte que la mise à jour ne s'effectue qu'à intervalles fixes, donnant l'impression d'être en temps réel lorsque les séquences sont très rapprochées. La plate-forme 53, 54, 55 offre aux utilisateurs 40, 43, 47, 48, 50, 43', 47', 50' la possibilité d'adresser au serveur central 45, 45' un ou plusieurs ordres d'achat ou de vente, pour une quantité choisie, d'un instrument donné standard ou spécifique. Cette introduction se fait à partir d'un navigateur internet 51, 5l'. L'ordre est "manuel" si l'utilisateur introduit tous les paramètres de cet ordre (instrument, prix, quantité, sens, conditions de validité, ...), ou semi- automatique lorsque certains de ces paramètres sont pilotés par une contribution automatique externe, qui les met alors à jour à chaque fois qu'ils changent. B. Compilation et distribution de ces ordres. Le serveur 45, 45' optimise l'ensemble de ces ordres manuels ou semi- automatiques de façon objective et systématique. Il les compile et les agrège par prix, fabriquant ainsi une distribution homogène. Ces ordres étant soumis à certaines conditions de validité, le serveur c'ère ces conditions de telle sorte que seuls les ordres valides soient pris en compte. Dans la suite de la description les notions "d'optimisation", "de compilation", "d'agrégation" ou "d'offre homogène" auront le sens ci- après défini. Optimisation L'optimisation de l'ensemble des ordres manuels ou semi-automatiques consiste à trouver automatiquement la solution optimale à une requête. Par exemple, la requête peut être du genre : "Parmi toutes les possibilités offertes par les combinaisons d'instruments entre eux, quelle est la meilleure combinaison pour procurer un emprunt en USD à 6 mois le moins cher possible T'. Diverses solutions sont envisageables - E y a une offre (d'un prêteur) qui convient directement dans le système. - En empruntant pour 3 mois à un prêteur existant dans le système, et en réempruntant dans 3 mois pour 3 mois (à partir d'une autre offre existante), on obtient synthétiquement un emprunt à 6 mois constitué de 2 opérations, et le taux résultant est inférieur à celui proposé pour un emprunt à 6 mois directement dans le système." Autre exemple, la requête peut être du genre : "Parmi tous les ordres présents dans le système provenant d'utilisateurs de la banque, quelle est l'opération qu'il conviendrait de faire avec par exemple un client de façon à satisfaire au mieux et de la façon la plus approchante l'ensemble de ses intérêts présents ; autrement dit quelle est l'opération à exécuter de manière à réduire au mieux les risques globaux de la banque. Compilation Une base d'ordre existe pour chaque classe d'instruments. Ces ordres sont - soit fixes, c'est-à-dire qu'ils comportent des caractéristiques qui ne varient pas, ni en prix, ni en montant, - soit dépendants de conditions externes, le prix de l'ordre peut être fonction d'un autre marché. Par exemple, le prix d'emprunt à 6 mois en dépôt USD peut être égal au prix de prêt à 3 mois moins 0,56 pct. Ou encore la validité de l'ordre peut dépendre du niveau du CAC40, par exemple : l'ordre est valable tant que le CAC40 est au-dessus de 4035. A chaque fois qu'un ordre fixe entre dans la base, ou qu'un ordre variable est modifié, ou que sa validité change, la base des ordres s'en trouve modifiée. La base doit donc être compilée par le serveur 45, 45'. Afin de permettre un suivi correct du marché par les utilisateurs, il est nécessaire de reclasser ces ordres pour chaque instrument, par prix, selon les règles de compatibilité de chacun, en agrégeant les montants de plusieurs ordres qui seraient inscrits à un même prix, etc..... Ce calcul effectué par le serveur 45, 45' est la compilation du marché, en une " grille " lisible simplement. La compilation intègre donc à chaque instant les ordres fixes, et les ordres qui dépendent d'autres paramètres. Dans ce cas, pour effectuer la compilation, le système génère au préalable un ordre qu'il intègre dans la base des ordres fixes. Ensuite, le système classe cet ordre et l'agrège. Agrégation Ainsi que cela vient d'être exposé, l'agrégation consiste à additionner les montants de plusieurs ordres dont les caractéristiques sont identiques (même sens, même instrument, même prix). Plutôt que d'afficher, lors de la compilation, uniquement le montant de l'un d'entre eux, il est nécessaire d'additionner l'ensemble des montants de ces ordres de fayon à ce que l'utilisateur voit le montant total disponible à l'achat ou à la vente pour le niveau de prix considéré. C'est ce que l'on appelle agréger les ordres d'un même instrument par niveau de prix. Distribution homogène Pour illustrer la notion de distribution homogène des prix et des montants d'une base d'ordres compilée et agrégée, à l'achat d'une part, et à la vente d'autre part, pour chaque instrument., prenons un exemple. Par exemple, prenons un instrument X. Supposons que les ordres à l'achat, dans leur ordre d'arrivée, soient les suivants. INSTRUMENT X INSTRUMENTY Montant Prix 1 150 4,55 Meilleur prix acheteur : 6,36 2. 35 4,56 3. 45 4,55 4, 60 4,51 5. 500 4,56 6. 100 Meilleur prix acheteur de Instrument Y moins 1,80 en millions de francs. Dans la phase de compilation, le serveur 45, 45' calcule les caractéristiques de chaque ordre, pour aboutir, à un instant t, à la série d'ordres : REF INSTRUMENT X INSTRUMENT Y Montant Prix 1 A 150 4,55 Meilleur prix acheteur : 6,36 2. B 35 4,56 3. C 45 4,55 4. D 60 4,51 5. E 500 4,56 6. F 100 4,56 Puis le serveur 45, 45' classe les ordres par prix REF INSTRUMENT X INSTRUMENT Y Montant Prix 1 B 35 4,56 Meilleur prix acheteur: 6,36 2. E 500 4,56 3. F 100 4,56 4. A 150 4,55 5. C 45 4,55 6. D 60 4,51 A ce stade de l'opération, la distribution de l'offre n'est pas homogène. Le serveur 45, 45' agrège les montants, pour avoir un affichage REF INSTRUMENT X INSTRUMENT Y Montant Prix 1 B+E+F 635 4,56 Meilleur prix acheteur: 6,36 2. A+C 195 4,55 3. D 60 4,51 On dispose ainsi d'une distribution homogène. Au moment de traiter un ordre de vente qui arriverait à 4.56, un ordre de priorité est respecté pour les acheteurs présents à 4,56. L'ordre de priorité sera: premier acheteur arrivé chronologiquement, premier servi. Le serveur se charge de marier les ordres qui peuvent donner lieu à une transaction, de façon sélective, en tenant compte des critères de validité de chaque ordre, et des critères de comptabilité entre deux ordres (certains utilisateurs ne peuvent conclure fermement une transaction avec d'autres utilisateurs, ou ne peuvent traiter certains types d'instruments, ou ne peuvent traiter des opérations de plus d'un certain montant, ou bien avoir d'autres critères de sélection sur les opérations qu'ils peuvent traiter ou non : cela représente les critères de validité et de comptabilité). Mariage Pour expliciter la notion de mariage, reprenons l'exemple précédent. L'ordre de vente suivant arrive : "vendre 580 millions de francs d'instruments X (580MM) à 4,56 francs par instrument". Dans ce cas, le mariage consiste pour le serveur 45, 45' à identifier les ordres d'achat, par ordre de priorité, c'est-à-dire par ordre d'arrivée dans la base, qui sont éligibles pour être mis en face du nouvel ordre de vente dans le but éventuel de conclure une transaction. En l'occurrence, le mariage implique : Ordre B dans son intégralité 35 MM à 4,56 Ordre E dans son intégralité 500 MM à 4,56 Ordre F partiellement 45 MM à 4,56 (restera 55 MM à 4,56 pour l'ordre F) Soit au total : 580 MM à marier aux 580 MM de l'ordre de vente Ces ordres sont supposés être compatibles. Dans le cas de l'intrabancaire, il n'y a pas de différence entre le mariage et la transaction, car aucune vérification n'est nécessaire pour autoriser la transaction. Dans le cas de l'interbancaire, une fois que le nom ou les noms à marier apparaissent, il faut effectuer une recherche pour savoir si, à l'instant précis, les autorisations de crédit sont valides. On dit qu'on procède au "Checking" (ou contrôle) des noms de contreparties. On notera que des opérations mariées peuvent ne pas être conclues. Le serveur remplit une fonction de distributeur. Le serveur se charge d'indiquer à chaque utilisateur l'état du marché, c'est-à-dire qu'il indique par le biais de l'affichage à l'écran en permanence pour les instruments standards ou spécifiques quelles sont les conditions d'achat ou de vente optimales en fonction des critères de compatibilité introduits pour chaque utilisateur. Il en découle que chaque utilisateur ne "voit" pas le même marché. Dans la suite de la description les notions "de distribution" ou "de conditions d'achat ou de vente optimale" auront le sens ci-après défini. Distribution. Le serveur 45, 45' reçoit des ordres des marchés en provenance des divers terminaux des utilisateurs 40, 43, 47, 48, 50, 43', 47', 50' connectés. E renvoie l'affichage de la distribution homogène de chaque instrument à chaque terminal de chaque utilisateur en fonction de ses critères de compatibilité propres. L'opération d'affichage est gérée par le programme présent dans chaque terminal. Elle consiste à placer sur l'écran, de manière connue en soi, les données caractérisant la distribution homogène. Dans l'exemple décrit, le serveur reçoit les ordres suivants dans l'ordre REF INSTRUMENT X INSTRUMENT Y Montant Prix Meilleur prix acheteur : 6,36 1 150 4,55 2. 35 4,56 3. 45 4,55 4, 60 4,51 5. 500 4,56 6. 100 Meilleur prix acheteur de Instrument Y Moins 1,80 Il renvoie la distribution homogène suivante - en supposant les règles de compatibilité vérifiées. REF INSTRUMENT X Montant Prix 1. 635 4,56 2. 195 4,55 3. 60 4,51 L'interface homme-machine visualise sur l'écran de l'utilisateur 40, 43, 47, 48, 50, 43', 47', 50' qui la reçoit cette distribution homogène. Conditions d'achat ou de vente optimale. Il s'agit, pour un instrument donné, du meilleur prix d'achat et de vente disponible en fonction de ses propres critères de compatibilité. Si dans l'exemple précédent, les ordres B, C et E sont incompatibles, la distribution optimale sera celle qui exclut ces trois ordres. Une fois compilée et agrégée par le serveur 45, 45' la distribution optimale sera REF INSTRUMENT X Montant Prix 1. 100 4,56 2. 150 4,55 3. 60 4,51 C'est par un processus itératif de soumission/envoi d'ordres, d'affichages, de modification de l'ordre initial, etc. ... que net la négociation en temps réel ou pseudo-réel. Processus itératif La négociation à proprement parler entre un acheteur W et un vendeur Z va se traduire, autour d'un même instrument, par la modification par chacun des deux acteurs de leurs conditions d'achat pour W et de vente pour Z. W va chercher à faire baisser le prix de Z, et inversement pour Z. W pourra bluffer en retirant son ordre en faisant croire qu'un autre vendeur lui a vendu l'instrument, ou modifier le montant de l'ordre. C'est au travers de ces actions de modification de prix et de montant qu'un processus interactif et itératif de négociation se met en marche. L'itération se poursuit jusqu'à ce que les prix de W et de Z soient égaux. En réalité, plusieurs acheteurs et vendeurs se retrouvent autour d'un instrument, de telle sorte que le jeu de négociation devient interactif. C. Réalisation de transactions Le serveur lorsqu'il a pu marier deux ordres compatibles, génère automatiquement une transaction. Il peut être amené à demander une confirmation à chacune des contreparties avant de boucler définitivement la transaction dans le vas où un accord "manuel" d'engagement de crédit doit être établi entre les acteurs. Dans les autres cas, le processus est entièrement automatisé. S'ensuit alors l'envoi automatique de confirmations par mels, fax, ou télex, à chacune des deux contreparties. D. Particularités intelligentes du système, avec exemples. Le serveur peut administrer certaines fonctions d'optimisation e Existence de conditions de validité liées à un ordre. Un ordre peut voir sa validité ou ses paramètres dépendre de conditions externes telles que : * les paramètres de l'ordre tels que prix, montant, sont des fonctions d'autres paramètres externes (date, cours du dollar, température extérieure, ... ) ou internes (paramètres appartenant à d'autres ordres présents dans le système). Ex : "le prix de mon ordre est égal au prix d'un autre ordre moins 2 francs", ou "le montant de mon offre est égal à 100 multiplié par le cours du dollar". * l'existence, donc la validité de l'ordre, dépend de conditions externes ou internes. Ex "j'achète tel instrument à 3 francs tant que le CAC40 est au-dessus de 4000", ou "je suis acheteur pour 500 millions mais je ne veux que des transactions d'au moins 100 millions à la fois", ou "mon ordre est valable chaque jour entre l4h et 17h3O". a Passage d'ordres groupés liés les uns aux autres. A titre d'exemple d'ordres groupés, on peut citer l'ordre suivant CTachète le produit A à 3 FFR si je peux vendre le produit B à 5 FFR". Combiné avec la fonction précédente, on obtient le cas général d'un passage d'ordres groupés dont la validité est dépendante de conditions externes. Par exemple : "J'achète le produit A à 3 FFR, si je peux vendre le produit B à 5 FFR et ce tant que le CAC40 est au-dessus de 4000". e Recherche d'un prix optimal. Le serveur, à la demande d'un utilisateur, recherche tous les moyens synthétiques d'exécuter son ordre de manière à en améliorer les conditions d'exécution. * Détection d'arbitrage automatique Dans ce cas, le serveur recherche seul, pour le compte de chaque utilisateur, en fonction de ses propres paramètres de validité, comptabilité, des couples d'opérations synthétiques fabriquées à partir de composants différents, mais aboutissant à un instrument aux mêmes caractéristiques, de telle sorte que l'une puisse être achetée moins chère que l'autre, et donc ainsi dégager un profit de d'arbitrage. Ex : je peux emprunter 10 millions de USD pour six mois à 4%. Par ailleurs, je peux vendre 10 millions de USD au comptant contre des FFR, et prêter les FFR pendant six mois, et vendre à terme dans six mois le capital et les intérêts générés en FFR contre des USD. Cette dernière opération revient de façon synthétique à prêter 10 millions de USD. Si ce deuxième groupe d'opérations me permet d'effectuer un prêt synthétique à 4, 07 %, je gagne sans risque 0, 07% sur le montant notionnel. C'est cela un arbitrage pur. * Optimisation d'un ordre par recherche préalable de tous les arbitrages possibles. Par exemple , si je cherche à prêter 10 millions de USD à six mois, je peux soit effecteur la chaîne d'opérations décrite dans le cas précédent, et donc obtenir un prêt synthétique à 4, 07%, soit prêter directement à 4% en tant que dépôt à six mois. * Recherche d'opérations à effectuer de façon à permettre à un groupe désigné d'utilisateurs de se "déstocker" de leurs ordres. Autrement dit, si plusieurs utilisateurs affichent un intérêt sur divers instruments, il s'agit de fabriquer un instrument synthétique qui sera proposé à un autre utilisateur de telle sorte qu'en effectuant la transaction, un maximum d'intérêts de départ disparaissent. Différence entre détection d'arbitrage et optimisation par arbitrage La détection d'arbitrage automatique consiste à déclencher automatiquement une chaîne d'opérations lorsque certaines conditions sont remplies. Par exemple, dans l'exemple de l'arbitrage du dépôt à 6 mois, le système a repéré la possibilité d'emprunter 10 MM de Dollars à 4,00 pct directement, et conjointement la possibilité de les vendre au comptant et les acheter à terme dans 6 mois contre des FFR. et de prêter les francs ainsi obtenus pendant six mois. Ainsi le système a repéré que les flux en francs s'annulent deux à deux, et que les flux d'entrée des USD dans 6 mois, provenant du rachat à terme des USD, génèrent un prêt synthétique en USD à 4,07 pct. Dans ce cas de détection automatique d'arbitrage, le système engage automatiquement cette série d'opérations conjointes de manière à gagner au bout du compte la différence entre 4,07 pct et 4,00 pct. L'optimisation par arbitrage consiste à chercher parmi les moyens synthétiques, la chaîne d'opérations optimale qui diminue au maximum mon prix d'emprunt de ces DOLLARS pour 6 mois. Il n'y a pas dans ce cas une chaîne d'opérations totalement bouclée. Revendications 1. Système pour traiter, de gré à gré entre des utilisateurs disposant de C ZD terminaux informatiques (40, 43, 47, 48, 50, 43', 47', 50'), des ordres d'achat et de vente portant sur des instruments financiers standards et/ou spécifiques ; ledit système étant tel qu'il comprend au moins un centre serveur (45, 42, 45', 42') comprenant # des moyens de collecte et de mémorisation pour collecter en temps réel ou pseudo-réel des ordres d'achat et de vente passés par des utilisateurs, # des moyens de traitement informatique pour compiler et agréger par prix les ordres, C CD ledit centre serveur (45, 42, 45', 42') étant connecté via un réseau de communication (44, 46, 49, 52) informatique, notamment du type internet, auxdits terminaux informatiques, de sorte que les utilisateurs reçoivent les ordres et les informations diffusées par le centre serveur, les moyens de traitement informatiques dudit centre serveur (45, 42, 45', 42') comprenant des moyens d'analyse pour marier les ordres compatibles et constater qu'une transaction peut intervenir entre les utilisateurs ayant passé les ordres concernés. 2. Système selon la revendication 1 tel que lesdits moyens de traitement informatique traitent les ordres et les instruments financiers associés - en cérant les conditions d'existence desdits ordres, notamment liées à des conditions internes et/ou externes, par exemple la valeur du CAC40, et/ou les paramètres desdits ordres, notamment en fonction de paramètres internes et/ou externes, par exemple le prix en fonction de la date, et/ou - en groupant les ordres et en passant des ordres groupés, et/ou - en recherchant des instruments financiers synthétiques améliorant la réalisation des ordres passés, et/ou - en recherchant des instruments financiers synthétiques permettant à un groupe désigné d'utilisateurs de négocier un maximum d'ordres avec au moins un autre utilisateur. 3. Système selon l'une quelconque des revendications 1 ou 2 tel que les moyens de collecte comportent un navigateur internet (51, 5l'). 4. Système selon l'une quelconque des revendications 1 à 3 tel que, pour compiler et agréger par prix des ordres soumis à des conditions de validité, les moyens de traitement informatique comportent des moyens de gestion pour gérer lesdites conditions de telle sorte que seuls les ordres valides soient pris en compte. de sorte que l'on obtient ainsi une offre optimisée et homogène. 5. Système selon l'une quelconque des revendications 1 à 4 tel que, pour marier les ordres compatibles et constater qu'une transaction peut intervenir entre les utilisateurs ayant passé les ordres concernés, lesdits moyens d'analyse comportent des moyens de sélection pour sélectionner les utilisateurs qui peuvent négocier entre eux et/ou qui ne peuvent négocier que certains instruments et/ou qui ne peuvent négocier que des opérations d'un certain montant. 6. Système selon l'une quelconque des revendications 1 à 5 tel que lesdits moyens d'analyse pour marier les ordres compatibles et constater qu'une transaction peut intervenir comprennent des moyens de transmission, notamment par fax, par mel ou par télex, pour confirmer la transaction à chacun des utilisateurs concernés.