FR2892211A1

FR2892211A1 - Procede d'echange de donnees relatives a une transaction bancaire, systeme mettant en oeuvre ce procede et dispositif formant un element d'une chaine monetique

Info

Publication number: FR2892211A1
Application number: FR0510459A
Authority: FR
Inventors: La Forest Divonne Aymeric De; Patrick Leroy
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2005-10-13
Filing date: 2005-10-13
Publication date: 2007-04-20
Also published as: WO2007042737A1

Abstract

Ce procédé permet l'échange de données relatives à une transaction bancaire entre au moins deux éléments (10, 12, 14) d'une chaîne monétique. Le procédé comprend :- une étape de rédaction, conformément à un protocole spécifique à la transaction bancaire, d'un message, comprenant les données relatives à la transaction bancaire, destiné à être échangé entre les deux éléments (10, 12, 14) de la chaîne monétique,- une étape d'extraction de données du message, et- une étape d'exécution d'au moins un test relatif aux données extraites,La rédaction du message est réalisée en langage de description de données, l'étape d'exécution de test étant précédée d'une étape d'extraction dudit test d'un fichier de définition de la structure de données du message, dans lequel est défini le test.

Description

-1- La présente invention concerne un procédé d'échange de données

relatives à une transaction bancaire, un système mettant en ceuvre ce procédé et un dispositif formant un élément d'une chaîne monétique. Elle concerne plus particulièrement les transactions bancaires réalisées par des moyens électroniques et informatiques, comme les transactions entre, d'une part, un lecteur de carte bancaire ou un distributeur automatique de billets et, d'autre part, des serveurs bancaires (tels qu'un serveur d'autorisation, un serveur de télécollecte ou un serveur de téléchargement), les paiements par voie électronique (par exemple, par Internet), les transferts interbancaires, etc.

Dans ce qui suit, on appellera chaîne monétique un ensemble comportant des éléments formant des dispositifs, tels que ceux évoqués ci-dessus, aptes à réaliser des transactions bancaires. On connaît déjà, dans l'état de la technique, un procédé d'échange de données relatives à une transaction bancaire entre au moins deux éléments d'une chaîne monétique, le procédé étant du type comprenant : une étape de rédaction, conformément à un protocole spécifique à la transaction bancaire, d'un message, comprenant les données relatives à la transaction bancaire, destiné à être échangé entre les deux éléments de la chaîne monétique, - une étape d'extraction de données du message, et - une étape d'exécution d'au moins un test relatif aux données extraites. Habituellement, la rédaction du message est réalisée par un premier élément de la chaîne monétique sous la forme d'une trame binaire. Cette trame est construite conformément à un protocole spécifique aux transactions bancaires, par exemple un protocole respectant la norme ISO 8583 (norme de référence pour les transactions bancaires) ou une autre norme habituelle (par exemple RCB ou CB2A) dérivée d'ISO 8583. Puis, le message est émis vers un second élément de la chaîne monétique dans lequel est implanté un programme d'analyse du message.

Ce programme réalise les étapes d'extraction de données de la trame binaire et d'exécution des tests relatifs aux données extraites. Ces tests sont destinés à vérifier la conformité du message à l'égard de règles relevant du protocole spécifique utilisé pour la transaction bancaire concernée. Les tests sont prédéfinis dans le programme d'analyse, si bien qu'en cas de modification du protocole spécifique il est nécessaire de modifier le programme d'analyse. En effet, généralement, une modification du protocole spécifique affecte la syntaxe du -2- message en trame binaire (emplacement différent des données dans la trame, etc.) et, par conséquent, affecte le programme d'analyse de ces données. De même, l'utilisation d'un nouveau protocole requiert la création d'un nouveau programme d'analyse du message construit selon ce nouveau protocole.

Or, toute modification ou création d'un programme d'analyse pose des problèmes : d'implantation de ce programme modifié ou nouvellement créé sur l'élément de la chaîne monétique auquel il est destiné et - de compatibilité de ce programme avec les différents éléments de cette chaîne monétique.

L'invention a notamment pour but de faciliter la modification ou la création de protocoles spécifiques aux transactions bancaires, ceci sans avoir autant que possible à mettre à jour les programmes d'analyse implantés dans les éléments concernés de la chaîne monétique. A cet effet, l'invention a pour objet un procédé d'échange de données relatives à une transaction bancaire entre au moins deux éléments d'une chaîne monétique, le procédé étant du type précité, caractérisé en ce que la rédaction du message est réalisée en langage de description de données, l'étape d'exécution de test étant précédée d'une étape d'extraction dudit test d'un fichier de définition de la structure de données du message, dans lequel le test est défini.

Ainsi, en cas de modification du protocole utilisé, il n'est pas nécessaire de modifier le programme d'analyse du message implanté dans un élément concerné de la chaîne monétique. En effet, les tests réalisés par le programme d'analyse ne sont pas définis dans ce programme d'analyse mais dans le fichier de définition. Le programme d'analyse traite donc les données extraites du message en les soumettant aux tests extraits du fichier de définition. Pour prendre en compte une modification du protocole utilisé, il suffit de modifier la définition des tests dans le message de définition, sans qu'il soit nécessaire de modifier le programme d'analyse implanté sur un élément de la chaîne monétique. De même un nouveau protocole peut être conçu sans qu'il soit nécessaire de modifier ou créer un programme d'analyse implanté sur un élément de la chaîne monétique. En effet, les tests du nouveau protocole sont définis dans un nouveau message de définition. Avantageusement, le langage de description de données est le langage XML (conformément à l'acronyme anglo-saxon de eXtensible Markup Language) et la structure de données du message est définie, dans le fichier de définition, à l'aide des formats de description XMLSchema et Schematron. On notera que le fichier de définition est lui- même un fichier en langage XML. -3- L'analyse d'un fichier en langage XML est réalisée classiquement par un programme appelé habituellement parseur valideur (ou analyseur) formant avantageusement le programme d'analyse. Conformément à un fonctionnement classique, le parseur valideur extrait les données du message (en langage XML), extrait les tests des fichiers de définition (également en langage XML) et traite les données extraites du message en les soumettant aux tests extraits du fichier de définition. De plus, le langage XML est compatible avec la majorité des bases de données. Dans un mode de réalisation particulier, la structure de données du message comprend : - un champ d'identifiant du type du message, au moins un champ de présence indiquant la présence d'autres champs du message, dits champs de données , et les champs de données, comportant des données propres à la transaction. Avantageusement, l'étape de rédaction en langage de description de données comporte une étape de traduction d'une trame binaire, comprenant les données relatives à la transaction bancaire, en langage de description de données. De préférence, le procédé comprend de plus une étape de traduction en trame binaire du message en langage de description de données. Ainsi, certains éléments de la chaîne monétique, qui n'utilisent pas un langage de description de données, peuvent communiquer avec d'autres éléments de la chaîne monétique qui utilisent un langage de description de données pour réaliser un échange de données conformément au procédé selon l'invention. Grâce à l'invention, on peut introduire progressivement dans une chaîne monétique les nouveaux éléments utilisant un langage de description de données pour réaliser un échange de données conformément au procédé selon l'invention, ceci tout en conservant dans la chaîne monétique des éléments classiques qui n'utilisent pas un langage de description de données. En effet, un nouvel élément d'une chaîne monétique, utilisant un langage de description de données pour réaliser un échange de données conformément au procédé selon l'invention, est susceptible de traduire un message dans le sens trame binaire vers langage de description de données ou inversement, afin de permettre un échange de données avec un élément classique de la chaîne monétique qui n'utilise pas de langage de description de données. La mise en ceuvre du procédé selon l'invention ne nécessite donc pas un remplacement simultané de tous les éléments classiques d'un chaîne monétique. -4- Optionnellement, au moins un élément de la chaîne monétique, dit élément en réseau , étant relié à un serveur par un réseau, le procédé comprend une étape de téléchargement du fichier de définition depuis le serveur vers l'élément en réseau. Ainsi, l'élément en réseau de la chaîne monétique peut lire un message rédigé conformément à un protocole jusque là inconnu de cet élément en réseau, dès lors que le fichier de définition correspondant est disponible sur le serveur auquel peut accéder l'élément en réseau. Le téléchargement permet donc, le cas échéant, d'ajouter facilement, dans l'élément en réseau, un nouveau fichier de définition ou de remplacer facilement, dans cet élément en réseau, une ancienne version de fichier de définition par une nouvelle version de ce fichier de définition. Le procédé selon l'invention permet donc aux divers éléments d'une chaîne monétique de s'adapter facilement aux modifications des protocoles spécifiques aux transactions bancaires.

Avantageusement, l'étape de téléchargement du fichier de définition est déclenchée par l'analyse du champ de l'identifiant du type du message défini par ce fichier de définition. L'invention a également pour objet un système comprenant une chaîne monétique comportant au moins deux éléments destinés à échanger des données relatives à une transaction bancaire conformément à un procédé tel que défini ci-dessus, un premier élément de la chaîne étant destiné à émettre un message établi conformément à un protocole spécifique à la transaction bancaire, caractérisé en ce qu'un second élément de la chaîne, destiné à recevoir le message, comprend des moyens d'extraction des données du message, des moyens de stockage du fichier de définition de la structure de données du message, des moyens d'extraction de test relatifs aux données dudit fichier et des moyens d'exécution de test. Avantageusement, au moins un des éléments de la chaîne comprend des moyens de traduction du message dans le sens trame binaire vers langage de description de données ou inversement.

Dans un mode de réalisation particulier, l'élément comprenant les moyens de traduction du message est un élément constituant un routeur par lequel les messages sont acheminés, distinct des premier et deuxième éléments. L'invention a également pour objet un dispositif formant un élément d'une chaîne monétique, caractérisé en ce que la chaîne appartient à un système tel que défini ci-35 dessus. Un tel dispositif peut comprendre : -5- des moyens de rédaction d'un message en langage de description, notamment XML, et des moyens d'émission d'un message à destination d'un autre élément de la chaîne monétique ; des moyens de réception d'un message en provenance d'un autre élément, des moyens d'extraction de la chaîne monétique des données d'un message, des moyens de stockage d'un fichier de définition, des moyens d'extraction d'un test relatif aux données du fichier de définition et des moyens d'exécution de ce test. L'invention a également pour objet un programme d'ordinateur, apte à rédiger le 10 message en langage de description de données. L'invention a également pour objet un programme d'ordinateur, apte à extraire les données du message et au moins un test relatif aux données du fichier de définition et à exécuter ledit test . L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée 15 uniquement à titre d'exemple et faite en se référant aux dessins dans lesquels : - la figure 1 est un schéma illustrant la structure générale d'un système selon un mode de réalisation particulier de l'invention ; la figure 2 est un organigramme représentant des étapes d'un procédé d'échange de données relatives à une transaction bancaire selon un mode de 20 réalisation particulier de l'invention, mis en oeuvre dans le système de la figure 1, la figure 3 est un schéma illustrant la structure de données d'un message rédigé conformément à un protocole spécifique à une transaction bancaire ; - la figure 4 est un organigramme représentant d'autres étapes du procédé 25 d'échange de données mis en oeuvre dans le système de la figure 1 ; la figure 5 est un schéma illustrant une variante du système représenté sur la figure 1 On a représenté sur la figure 1 un système selon l'invention comprenant une chaîne monétique comportant au moins deux éléments 10, 12, 14 destinés à échanger des 30 données relatives à des transactions bancaires. Ces éléments 10, 12, 14, par exemple au nombre de trois comme cela est représenté sur la figure 1, forment des dispositifs aptes à réaliser les transactions bancaires. Les éléments 10, 12, 14, reliés entre eux par un réseau 16, sont destinés à échanger des messages comportant des données relatives aux transactions bancaires. 35 Ces messages sont rédigés conformément à des protocoles spécifiques à ces transactions bancaires.5 -6- Un serveur 18 est également raccordé au réseau 16. En variante, les éléments 10, 12, 14 et le serveur 18 pourraient ne pas être reliés entre eux par un seul et même réseau 16. Les premier 10 et deuxième 12 éléments sont configurés pour utiliser un langage de description de données tel que XML et pour réaliser un échange de données conformément au procédé selon l'invention qui sera décrit ci-dessous. Le troisième élément 14, de type classique, n'est pas configuré pour utiliser un langage de description de données tel que XML. Dans ce mode de réalisation, les données éventuellement transmises par le premier élément 10 vers les deux autres éléments 12, 14 ne sont pas forcément identiques ni transmises simultanément respectivement aux deuxième et troisième éléments 12, 14. Le premier élément 10 peut être constitué par un dispositif complexe ou un simple TPE (acronyme de Terminal de Paiement Electronique). Le second élément 12 est par exemple constitué d'un serveur de télécollecte et le troisième élément 14, par un serveur d'autorisation. On va maintenant décrire, en référence aux figures 2 à 4, un procédé d'échange de données selon un mode particulier de réalisation de l'invention, ce procédé étant mis en oeuvre par le système illustré sur la figure 1 ou la variante de ce système illustrée sur la figure 5.

On a représenté plus particulièrement, sur la figure 2, des étapes du procédé concernant un échange de données essentiellement entre les premier 10 et deuxième 12 éléments de la chaîne monétique, et, sur la figure 4, des étapes du procédé concernant un échange de données entre les trois éléments de la chaîne monétique. Comme cela est représenté sur la figure 2, le procédé selon l'invention comprend une étape 20 de rédaction d'un message, conformément à un protocole spécifique à des transactions bancaires, destiné à être échangé entre les premier 10 et deuxième 12 éléments de la chaîne monétique. Le message comprend des données relatives à une transaction bancaire. Cette étape 20 est mise en oeuvre par des moyens 21 de rédaction, implantés sur le premier élément 10. Ces moyens 21 comportent par exemple des moyens d'extraction de valeurs de champ d'une base de données et des moyens de génération, à partir de ces valeurs, d'un message en langage de description de données. Ces moyens 21 sont constitués par un programme d'ordinateur. Dans l'exemple décrit, le protocole spécifique utilisé par les deux éléments 10, 12 est un protocole respectant la norme ISO 8583. -7- La rédaction du message est réalisée en langage de description de données, de préférence en XML, selon une structure de données 22 spécifique à la transaction bancaire. La structure de données 22 du message est par exemple la structure représentée sur la figure 3 qui est conforme à un protocole spécifique aux transactions bancaires respectant la norme ISO 8583. La structure de données 22, conforme à l'exemple de la figure 3, comprend un champ 24 d'identifiant du type du message, au moins un champ de présence 26 indiquant la présence d'autres champs du message, dits champs de données , et ces champs de données 28, 30, 32, comportant des données propres à la transaction. Le champ de présence 26 définit également la présence ou l'absence d'un autre champ de présence, optionnel, non représenté sur la figure 3. Ces champs de présence ainsi que le champ d'identifiant comportent des données propres à la structure du message.

Les données considérées comme propres à la transaction ( champs de données ) sont par exemple une date et une heure de la transaction, un montant débité ou crédité, un numéro de compte participant à la transaction, un nom de bénéficiaire, etc. Certains champs de données, tel que le champ de données 28, comportent au moins un paramètre 34, 36, 38, indiquant la valeur d'une donnée correspondante.

D'autres champs de données, tel que le champ de données 30, comportent un paramètre 40, indiquant la valeur d'une donnée et un paramètre 42, indiquant la longueur de cette donnée. Des champs de données dits champs à élément , tel que le champ 32, comportent un paramètre 44 indiquant la longueur de ce champ 32 et au moins un élément 46 comportant des données propres à la transaction. Chaque élément 46 d'un champ à élément 32 comporte un paramètre 48 indiquant le type de cet élément, un paramètre 50 indiquant la valeur de la donnée associée à cet élément et un paramètre 52 indiquant la longueur de la donnée associée à cet élément. En variante, d'autres structures de données que celle décrite ci-dessus peuvent être utilisées, notamment des structures de données conformes à d'autres protocoles d'échange de données relatives à des transactions bancaires. Par ailleurs, des tests, destinés à vérifier la conformité du message à l'égard de règles relevant du protocole spécifique utilisé pour la transaction bancaire concernée, sont définis dans un fichier de définition de la structure de données 22. Dans ce fichier de définition, en langage XML, les tests sont définis à l'aide des formats classiques de description XMLSchema et Schematron. -8- Les tests concernent notamment la vérification de la conformité du type des données (numérique, booléen, chaîne de caractères, etc.), de la valeur d'une donnée particulière par rapport à une plage de valeurs ou par rapport à d'autres données de référence, de la longueur d'une donnée, etc.

Ainsi, les tests vérifient, par exemple, qu'une donnée jour , représentant le jour de la transaction, est de type numérique, de longueur compatible avec un nombre à deux chiffres et a une valeur comprise entre 1 et 31, compatible avec des données mois et année représentant les mois et année de la transaction. On notera que les tests les plus complexes sont plus particulièrement définis à l'aide du format de description Schematron qui permet, notamment, de gérer des liens entre les valeurs de deux données, conformément à l'exemple concernant un test de correspondance jour-mois : Contexte d'utilisation Tout champ comprenant des données "mois" et "jour" Description : Vérification de la cohérence entre la valeur donnée pour le jour et celle donnée pour le mois Tests effectués : • Relève une erreur si le jour est supérieur à 30 pour les mois de avril, juin, septembre, novembre • Relève une erreur si le jour est supérieur à 28 pour le mois de février (années bissextiles non prises en compte) Source : <sch : rule context>"//month [../day]" > <sch : report test=" (.=04 or .=06 or .=09 or .=11) and

/day>30" it is not possible to have a day greater than 30 in such a month </sch.report <sch : report test =".=02 and ../day>28" the month is february you can not have more than 28 days unless you are in a bissextile year </sch : rule> Les tests définis dans le fichier de définition vérifient également la cohérence des données propres à la structure du message, comme la cohérence des valeurs des champs de présence 26 avec les champs de données 28, 30, 32 effectivement présents. Dans l'exemple décrit, le deuxième élément 12 comprend des moyens classiques 23, par exemple un disque dur, pour le stockage d'au moins un fichier de définition de la 20 structure de données 22 du message. Le fichier de définition peut également être stocké sur le serveur 18. L'étape de rédaction 20, qui est réalisée dans cet exemple par le premier élément 10, est suivie d'une étape 53 d'émission du message par ce premier élément 10 vers le deuxième élément 12, via le réseau 16. Cette étape 53 est mise en oeuvre par des 25 moyens 54 classiques d'émission d'un message. Le cas échéant, on peut prévoir de faire réaliser par le premier élément 10 une étape de traduction en trame binaire du message initialement en langage de description -9- de données. Le message traduit en trame binaire peut ainsi être émis vers le troisième élément 14 qui n'est pas configuré pour utiliser un langage de description de données tel que XML. Cette étape de traduction peut être réalisée à l'aide de moyens de traduction 55 implémentés sur le premier élément 10, ou, comme représenté en variante sur la figure 5, un autre élément de la chaîne, par exemple un élément constituant un routeur R, par lequel les messages sont acheminés avant qu'ils ne parviennent au second élément 12. Ces moyens 55 peuvent comprendre des moyens d'extraction de la structure de données 22 et des moyens d'incorporation de ces données dans la trame binaire...DTD: L'étape d'émission 53 est suivie d'une étape 56 de réception du message par le deuxième élément 12, mise en oeuvre par des moyens 57 classiques de réception, puis d'une étape 58 d'extraction des données de ce message. Cette étape 58 est réalisée par des moyens 59 d'extraction des données du message. Les moyens 59 comprennent un programme d'analyse classique, généralement appelé parseur valideur ( parser en anglais), implanté dans le deuxième élément 12. Dans l'exemple décrit, ce programme d'analyse analyse également, au cours de l'étape 58, le champ 24 d'identifiant du type du message. L'analyse de ce champ 24 permet d'identifier la structure de données 22 du message contenant le champ 24. L'étape d'extraction 58 est suivie par une étape 60 de récupération d'un fichier de définition correspondant à la structure de données 22 identifiée à partir du champ 24. Le fichier de définition correspondant à la structure de données 22 identifiée à partir du champ 24 est de préférence récupéré dans les moyens de stockage 23 du deuxième élément 12. Toutefois, si aucun fichier de définition stocké dans les moyens de stockage 23 ne correspond à la structure de données 22 identifiée à partir du champ 24, la récupération du fichier de définition correspondant à cette structure est réalisée de préférence par téléchargement de ce fichier, via le réseau 16, depuis le serveur 18 vers le deuxième élément 12. Après récupération du fichier de définition, le programme d'analyse extrait les tests de ce fichier de définition au cours d'une étape 64 puis exécute ces tests au cours d'une étape 66. Ce programme d'analyse est inclus dans des moyens 62 d'extraction d'un test du fichier de définition et des moyens 63 d'exécution de ces tests. Au cours de cette étape 66, mise en oeuvre par le deuxième élément 12, le programme d'analyse met en relation les données du message et les tests associés à ces données définis dans le fichier de définition précédemment décrit . -10- Cette mise en relation est effectuée à l'aide d'un indicateur (balise XML), dans le message, du contenu de chaque donnée, définissant la structure de données 22 du message. Cet indicateur est également associé, dans le fichier de définition, aux tests auxquels est soumise la donnée correspondante.

Une fois la mise en relation effectuée, les tests sont exécutés par le programme d'analyse, ce qui permet de vérifier la conformité du message à l'égard du protocole d'échange. Après l'étape 66 d'exécution des tests, si le message est non valide, le procédé se poursuit par une étape 68 de génération, par le deuxième élément 12, d'un rapport d'erreur. Si, au contraire, le message est valide, le procédé se poursuit par une étape 70 de traitement, par le deuxième élément 12, des données du message, par exemple pour les stocker dans une base de données. Un message en réponse est ensuite éventuellement établi à partir des données extraites ou du rapport d'erreur puis émis vers le premier élément 10 conformément à des étapes similaires à celles précédemment décrites. On va maintenant décrire, en référence à la figure 4, des étapes du procédé concernant un échange de données entre les trois éléments 10, 12, 14 de la chaîne monétique. Dans ce mode de réalisation, le premier élément 10 est par exemple un serveur d'autorisation, le second élément 12 est par exemple un serveur de télécollecte et le troisième élément 14 est par exemple un TPE (Terminal de Paiement Electronique). Comme cela est représenté sur la figure 4, le procédé d'échange de données comprend une étape 72 d'établissement, par le troisième élément 14, d'un message initial comportant des données relatives à une transaction bancaire. Ce message initial est une trame binaire classique. En effet, le troisième élément 14 n'est pas configuré pour utiliser un langage de description de données tel que XML. Le procédé se poursuit par une étape 74 d'émission du message par l'élément 14 mise en oeuvre par des moyens 54 classiques suivie d'une étape 76 de réception du message par le deuxième élément 12, mise en oeuvre par des moyens 57 classiques Le deuxième élément 12 peut souhaiter transférer des données du message initial au premier élément 10. Dans ce cas, l'échange de données se poursuit par une étape 78 de rédaction, par le deuxième élément 12, d'un message de transfert à l'attention du premier élément 10, afin de transmettre à cet élément 10 des données du message initial. On prévoit dans ce cas, dans l'étape de rédaction 78, une étape 80 de traduction en langage de description de données de la trame binaire extraite du message initial. Ainsi le -11- message de transfert forme un message, comprenant des données relatives à la transaction bancaire, conforme à un protocole spécifique à une transaction bancaire. L'étape 80 de traduction est réalisée par le second élément 12 à l'aide de moyens 82 de traduction en langage de description de données d'une trame binaire. Ces moyens 82 sont implémentés dans le deuxième élément 12 ou dans un autre élément de la chaîne monétique, par exemple, comme représenté en variante sur la figure 5, un élément constituant un routeur R , par lequel les messages sont acheminés avant qu'ils ne parviennent au premier élément 10. Ces moyens 82 peuvent comprendre des moyens d'extraction des données de la trame binaire et des moyens d'incorporation de ces données dans la structure de données 22 spécifique au type du message.

Claims

REVENDICATIONS

1. Procédé d'échange de données relatives à une transaction bancaire entre au moins deux éléments (10, 12, 14) d'une chaîne monétique, le procédé étant du type 5 comprenant : - une étape (20, 78) de rédaction, conformément à un protocole spécifique à la transaction bancaire, d'un message, comprenant les données relatives à la transaction bancaire, destiné à être échangé entre les deux éléments (10, 12, 14) de la chaîne monétique, 10 - une étape (58) d'extraction de données du message, et une étape (66) d'exécution d'au moins un test relatif aux données extraites, caractérisé en ce que la rédaction du message est réalisée en langage de description de données, l'étape (66) d'exécution de test étant précédée d'une étape (64) d'extraction de dudit test d'un fichier de définition de la structure de données (22) du message, dans 15 lequel est défini le test.

2. Procédé d'échange de données selon la revendication 1, dans lequel le langage de description de données est le langage XML, la structure de données (22) du message étant définie, dans le fichier de définition, à l'aide des formats de description XMLSchema et Schematron. 20

3. Procédé d'échange de données selon la revendication 2, dans lequel la structure de données (22) du message comprend : - un champ (24) d'identifiant du type du message, au moins un champ de présence (26) indiquant la présence d'autres champs du message, dits champs de données , et 25 les champs (28,30,32) de données, comportant des données propres à la transaction.

4. Procédé d'échange de données selon l'une quelconque des revendications précédentes, dans lequel l'étape (78) de rédaction en langage de description de données comporte une étape (80) de traduction d'une trame binaire, comprenant les données 30 relatives à la transaction bancaire, en langage de description de données.

5. Procédé d'échange de données selon l'une quelconque des revendications précédentes, comprenant en outre une étape de traduction en trame binaire du message en langage de description de données.

6. Procédé d'échange de données selon l'une quelconque des revendications 35 précédentes, dans lequel au moins un élément (12) de la chaîne monétique, dit élément en réseau , étant relié à un serveur (18) par un réseau (16), le procédé comprend une-13- étape (60) de téléchargement du fichier de définition depuis le serveur (18) vers l'élément (12) en réseau.

7. Procédé d'échange de données selon la revendication 6, dans lequel l'étape (60) de téléchargement du fichier de définition est déclenchée par une analyse du champ (24) de l'identifiant du type du message défini par ce fichier de définition.

8. Système comprenant une chaîne monétique comportant au moins deux éléments (10, 12, 14) destinés à échanger des données relatives à une transaction bancaire conformément à un procédé selon l'une quelconque des revendications précédentes, un premier élément (10) de la chaîne étant destiné à émettre un message établi conformément à un protocole spécifique à la transaction bancaire, caractérisé en ce qu'un second élément (12) de la chaîne, destiné à recevoir le message, comprend des moyens (59) d'extraction des données du message, des moyens (23) de stockage du fichier de définition de la structure de données (22) du message, des moyens d'extraction (62) de test relatifs aux données dudit fichier, et des moyens d'exécution (63) de test.

9. Système selon la revendication 8, dans lequel au moins un des éléments (10, 12, R) de la chaîne comprend des moyens (55, 82) de traduction du message dans le sens trame binaire vers langage de description de données ou inversement.

10. Système selon la revendication 9, dans lequel l'élément comprenant les moyens (55, 82) de traduction du message est un élément constituant un routeur (R), par lequel les messages sont acheminés, distinct des premiers (10) et deuxième (12) éléments.

11. Dispositif formant un élément d'une chaîne monétique, caractérisé en ce que la chaîne appartient à un système selon l'une quelconque des revendications 8 à 10.

12. Dispositif selon la revendication 11, formant un élément (10) d'une chaîne monétique, comprenant des moyens (21) de rédaction d'un message en langage de description, notamment XML, et des moyens (54) d'émission d'un message à destination d'un autre élément (12) de la chaîne monétique.

13. Dispositif selon la revendication 11, formant un élément (12) de la chaîne monétique, comprenant des moyens (57) de réception d'un message en provenance d'un autre élément (10) de la chaîne monétique, des moyens (59) d'extraction des données d'un message, des moyens (23) de stockage d'un fichier de définition, des moyens (62) d'extraction d'un test relatif aux données du fichier de définition, et des moyens (63) d'exécution de ce test.

14. Programme pour un ordinateur formant un dispositif selon la revendication 12, caractérisé en ce qu'il rédige le message en langage de description de données.-14-

15. Programme pour un ordinateur formant un dispositif selon la revendication 13, caractérisé en ce qu'il extrait les données du message et le test relatif aux données du fichier de définition et en ce qu'il exécute le test .