FR2890205A1

FR2890205A1 - Gestion d'ordres non acceptes par la bourse au niveau d'un serveur d'ordre

Info

Publication number: FR2890205A1
Application number: FR0508915A
Authority: FR
Inventors: Eric Auribault
Original assignee: GL Trade SA
Current assignee: FIS FINANCIAL SYSTEMS (FRANCE), FR
Priority date: 2005-08-31
Filing date: 2005-08-31
Publication date: 2007-03-02
Also published as: US20070055614A1

Abstract

L'invention se rapporte à un procédé de passage d'ordre depuis un poste client (3) vers une bourse (1) à l'aide d'un serveur d'ordre (2) relié à la bourse (1) et à une application (4) de gestion d'ordre reliée au serveur d'ordre (2), l'application de gestion d'ordre (4) étant apte à traiter un ensemble de règles associés à des ordres, le procédé comprenant les étapes consistant à :- pour le poste client (3), envoyer vers le serveur d'ordre (2), un ordre ainsi qu'une règle associée à l'ordre ;- envoyer de façon sélective, l'ordre ainsi que la règle associée à l'ordre au niveau de l'application (4) de gestion d'ordre ;- pour l'application (4) de gestion d'ordre, appliquer ladite règle sur l'ordre ;- renvoyer le résultat de l'application de la règle au niveau serveur d'ordre (2) ;- pour le serveur d'ordre (2), envoyer ledit résultat à la bourse (1).

Description

GESTION D'ORDRES NON ACCEPTÉS PAR LA BOURSE AU NIVEAU D'UN

SERVEUR D'ORDRE La présente invention se rapporte au domaine des 5 méthodes de passage d'ordres vers une bourse.

Dans une architecture connue telle qu'illustrée figure 1, lorsqu'un client 3 passe des ordres vers une institution boursière 1, l'ordre est au moins archivé et routée vers la bourse au niveau d'un serveur de passage d'ordre et/ou de contenu 2.

Il est également connu de passer des ordres selon certaines règles. Un exemple connu d'une telle règle est un ordre dit STOP utilisé pour limiter une perte ou assurer un profit. L'ordre STOP est un ordre pour lequel l'utilisateur spécifie un niveau de prix de déclenchement. C'est-à-dire que cet ordre ne sera envoyé au marché que lorsque ce niveau de prix aura été atteint, offert ou demandé sur le marché.

Cependant, les bourses n'acceptent pas toutes ces conditions sur les ordres, et il est parfois impossible de générer des règles spécifiques en étant sûr qu'elles seront traitées par la bourse.

Par ailleurs, certaines modalités d'ordres sont intéressantes pour les traders et ne sont supportées par aucune bourse.

La présente invention entend donc remédier aux inconvénients de l'art antérieur en fournissant un moyen aux traders de passer des ordres à une bourse selon une certaine modalité ou règle, et ce, même si la bourse n'accepte pas le traitement de ces règles.

Pour ce faire, la présente invention se rapporte à un procédé de passage d'ordre depuis un poste client 3 vers une bourse 1 à l'aide d'un serveur d'ordre 2 relié à la bourse 1 et à une application 4 de gestion d'ordre reliée au serveur d'ordre 2, l'application de gestion d'ordre 4 étant apte à traiter un ensemble de règles associés à des ordres, le procédé comprenant les étapes consistant à : pour le poste client 3, envoyer vers le serveur d'ordre 2, un ordre ainsi qu'une règle associée à l'ordre; envoyer de façon sélective, l'ordre ainsi que la règle associée à l'ordre au niveau de l'application 4 de gestion d'ordre; pour l'application 4 de gestion d'ordre, appliquer ladite règle sur l'ordre; renvoyer le résultat de l'application de la règle au niveau serveur d'ordre 2; pour le serveur d'ordre 2, envoyer ledit résultat à la bourse 1.

Selon un premier mode de réalisation, afin de rendre le procédé transparent pour l'utilisateur et que celui-ci puisse passer ses ordres munis de règles quelque soit la bourse, le procédé comprend en outre une étape préalable consistant à renseigner au niveau du serveur d'ordre, l'ensemble des règles sur les ordres supportées par la bourse, et pour l'application de gestion d'ordre, renseigner au niveau du serveur d'ordre, l'ensemble des règles sur les ordres supportées par elle, et l'envoi sélectif de l'ordre ainsi que la règle associée à l'ordre au niveau de l'application de gestion d'ordre est réalisé seulement si la règle associée à l'ordre n'est pas supportée par la bourse mais l'est par l'application de gestion d'ordre.

Selon un second mode de réalisation, l'envoi sélectif de l'ordre ainsi que la règle associée à l'ordre au niveau de l'application de gestion d'ordre dépend d'un paramètre généré au niveau du poste client spécifiant si l'ordre ainsi que la règle associe à l'ordre doivent être envoyé à l'application de gestion d'ordre ou directement à la bourse.

Cette possibilité n'est offerte à l'utilisateur que dans le cas où la règle qu'il souhaite appliquer à son ordre est à la fois supportée par la Bourse et par l'application de gestion d'ordre.

On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées où : - la figure 1 illustre un exemple d'architecture de 20 passage d'ordre connu selon l'art antérieur; la figure 2 un exemple d'architecture de passage d'ordre simulant la gestion des ordres et des règles selon l'invention; la figure 3 est un exemple de procédé mis en oeuvre 25 selon la présente invention.

Illustré figure 2, l'architecture selon l'invention comprend en outre du poste client 3, relié à la bourse 1 par l'intermédiaire d'un serveur d'ordre et/ou de contenu 2, une application de gestion des ordres 4 reliée au serveur d'ordre et/ou de contenu 2.

Aux fins de la présente demande, il est entendu que le serveur 2 peut être un serveur d'ordre uniquement, qui est apte à recevoir les ordres des clients, à les archiver et à les transmettre à la bourse. Il est également apte à recevoir les acquittements ou les rejets depuis la bourse 1 et à retransmettre ces informations au poste client 3.

Il peut aussi comprendre les fonctions de serveur de contenu en recevant les données publiques issues de la 10 bourse.

Le serveur 2 est donc constitué d'une ou plusieurs unités de traitement et d'archivage aptes à gérer les ordres et/ou le contenu public.

Aux fins de la présente demande, le terme bourse désigne tout type de marché boursier apte à transmettre des données boursières à destination des clients du marché.

Au sein de l'application de gestion des ordres 4, on a implémenté un ensemble de règles de traitement des ordres. L'avantage de cette implémentation réside dans le fait que ces règles ne sont pas nécessairement supportées par la bourse destinataire de l'ordre, ou par aucune bourse du marché.

On décrit ici plusieurs types de règles associées à des ordres pouvant être traités par l'application 4.

Selon un premier exemple, un ordre n'est exécuté que sous certaines conditions dépendant du contenu issu de la bourse.

Dans ce cas, les règles sont envoyées au niveau de l'application 4, qui reçoit également les données de la bourse, éventuellement via un serveur de contenu intégré ou non au serveur 2.

En fonction des données reçues, l'application de gestion d'ordre applique alors la règle, par exemple en déclenchant l'ordre selon le contenu. Dans ce cas, l'ordre est transmis au serveur d'ordre 2, qui le route vers la bourse 1.

Un exemple d'une telle stratégie d'ordre est par

exemple un ordre dit

STOP pour lequel on attend qu'un certain niveau de prix soit coté, offert ou demandé sur le 15 marché pour l'envoyer au marché.

Un deuxième type de règle correspond à une modification de l'ordre au cours du temps. Dans ce cas, l'ordre est envoyé au marché directement mais il est susceptible d'être modifié de manière automatique en fonction de l'évolution du marché. Pour un ordre PEG par exemple, le prix limite de l'ordre s'ajuste automatiquement en fonction d'un prix de référence. C'est-à-dire que chaque fois que le prix qui sert de référence évolue, le prix limite de l'ordre PEG est modifié de façon proportionnelle.

Selon un troisième mode de réalisation, on utilise seulement les données privées contenues dans le serveur d'ordre pour appliquer des règles. Un exemple d'une telle tactique de passage d'ordre est l'ordre ICEBERG dans lequel un ordre portant sur une certaine quantité est découpé automatiquement en une pluralité d'ordre par l'application 4.

Selon ce mode de réalisation, l'application 4 détecte d'abord un type d'ordre ICEBERG et découpe l'ordre selon une pluralité de sousquantités déterminées. A l'acquittement des différentes sous quantités, reçue par le serveur d'ordre 2, l'application de gestion d'ordre 4 déclenche alors l'envoi de la sous-quantité suivante.

On comprend dans ce cas que l'application de gestion d'ordre ne prend en paramètre que des données du serveur d'ordre, sans nécessiter d'information d'un serveur de flux représentant les données publiques du marché.

Selon un premier mode de réalisation, les fonctionnalités de l'application de gestion d'ordre sont implémentées de façon transparente pour l'utilisateur qui, lorsqu'il passe son ordre associé à des règles, ne sait pas si celles-ci ont été appliquées par la bourse 1 directement, ou par l'application de gestion d'ordre 4.

Pour ce faire, on entre au niveau du serveur d'ordre 2, l'ensemble des règles sur les ordres supportées par la bourse. On stocke également l'ensemble des règles supportées par l'application de gestion d'ordre 4.

Illustré schématiquement figure 3, lorsqu'un ordre 10 muni de règles 11 arrive 12 au serveur 2, celui-ci teste 13 si ces règles sont supportées ou non par la bourse. Si les règles sont supportées par la bourse, l'ordre et les règles sont transmis directement 14 à celle-ci pour exécution. Si les règles ne sont pas supportées par la bourse, le serveur 2 teste si elles sont supportées par l'application de gestion des ordres 4. Si ce n'est pas le cas, une notification d'erreur sera renvoyée vers le poste client. Si les règles sont supportées par l'application 4, le serveur 2 envoie 15 l'ordre ainsi que les règles vers l'application 4, celle-ci applique les règles sur l'ordre, éventuellement en fonction d'un contenu reçu de la bourse, et renvoie 16 le résultat de l'application des règles 17 vers le serveur d'ordre 4.

Celui-ci transmet alors 18 l'ordre résultat vers la bourse pour exécution.

Selon un second mode de réalisation, l'utilisateur peut, au niveau de la station client, spécifier s'il désire ou non utiliser l'application de gestion d'ordre 4 ou bien passer l'ordre directement par la bourse.

Ceci est par exemple mis en oeuvre par une interface au 20 niveau du logiciel de passage d'ordre de la station cliente du type: Désirez-vous utiliser une application de gestion d'ordre ? L'interface utilisateur peut par exemple proposer différentes stratégies d'ordre supportées par l'application de gestion 4, ainsi que les différents paramètres associés à la stratégie sélectionnée. L'homme du métier est apte à mettre en uvre une telle interface en fonction de stratégies et des règles supportées par l'application de gestion d'ordre 4.

L'utilisation de l'application 4 est avantageuse puisqu'elle est très évolutive et que selon les besoins des traders, les règles ou les stratégies sur les ordres peuvent être implémentés, sans être contraint par les limitations de traitement de la bourse.

Claims

REVENDICATIONS

1. Procédé de passage d'ordre depuis un poste client (3) vers une bourse (1) à l'aide d'un serveur d'ordre (2) relié à la bourse (1) et à une application (4) de gestion d'ordre reliée au serveur d'ordre (2), l'application de gestion d'ordre (4) étant apte à traiter un ensemble de règles associés à des ordres, le procédé comprenant les étapes consistant à : - pour le poste client (3), envoyer vers le serveur d'ordre (2), un ordre ainsi qu'une règle associée à l'ordre; envoyer de façon sélective, l'ordre ainsi que la règle associée à l'ordre au niveau de l'application (4) de 15 gestion d'ordre; pour l'application (4) de gestion d'ordre, appliquer ladite règle sur l'ordre; renvoyer le résultat de l'application de la règle au niveau serveur d'ordre (2) ; - pour le serveur d'ordre (2), envoyer ledit résultat à la bourse (1).

2. Procédé de passage d'ordre selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape préalable consistant à renseigner au niveau du serveur d'ordre (2), l'ensemble des règles sur les ordres supportées par la bourse, et pour l'application de gestion d'ordre, renseigner au niveau du serveur d'ordre, l'ensemble des règles sur les ordres qu'elle supporte, et en ce que l'envoi sélectif de l'ordre ainsi que de la règle associée à l'ordre au niveau de l'application de gestion d'ordre est réalisé seulement si la règle associée à l'ordre n'est pas supportée par la bourse, mais l'est par l'application de gestion d'ordre.

3. Procédé de passage d'ordre selon la revendication 1, caractérisé en ce que l'envoi sélectif de l'ordre ainsi que de la règle associée à l'ordre au niveau de l'application de gestion d'ordre dépend d'un paramètre généré au niveau du poste client spécifiant si l'ordre ainsi que la règle associe à l'ordre doivent être envoyé à l'application de gestion d'ordre ou directement à la bourse.

4. Procédé de passage d'ordre selon la revendication 1, caractérisé en ce que l'envoi sélectif de l'ordre ainsi que de la règle associée à l'ordre au niveau de l'application de gestion d'ordre dépend du contenu public du marché au niveau de la bourse.

5. Procédé de passage d'ordre selon la revendication 1, caractérisé en ce que l'envoi sélectif de l'ordre ainsi que de la règle associée à l'ordre au niveau de l'application de gestion d'ordre dépend de l'état des ordres au niveau du serveur d'ordre (2).