FR2969880A1 - Procede de traitement de donnees pour la gestion de transactions. - Google Patents

Abstract

L'invention concerne un procédé de gestion de transactions générées par un moyen de paiement faisant l'objet d'un contrôle de code de sécurité, et pour lequel une demande d'autorisation peut avoir lieu, caractérisé en ce qu'il comprend les étapes suivantes : - analyse des données associées à une demande d'autorisation pour déterminer si ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité, - sécurisation de ladite transaction par application, à ladite demande d'autorisation, de paramétrages de sécurisation (204, 206) différents selon que ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité. Elle concerne également un système (200) mettant en œuvre ce procédé.

Description

« Procédé de traitement de données pour la gestion de transactions »

La présente invention concerne un procédé de traitement de données numériques pour la gestion de transactions. Elle concerne également un 5 système mettant en oeuvre un tel procédé.

Le domaine de l'invention est le domaine informatique, et plus particulièrement le domaine informatique appliqué à la gestion de transactions commerciales ou bancaires, réalisées à l'aide d'un moyen de 10 paiement auquel est associé un code de sécurité, tels qu'une carte bancaire, une carte privative, une carte à puce, une carte à piste, une carte sans contact, un téléphone NFC avec application de paiement, ou encore un moyen de paiement virtuel telle qu'un e-wallet.

15 Actuellement, il existe des procédés de gestion de transactions avec un moyen de paiement en vue de s'assurer que les transactions réalisées correspondent bien aux transactions réellement demandées ou initiées par le porteur du moyen de paiement. Ces procédés ont pour but général d'éviter que le moyen de paiement, ou une réplique du moyen de paiement, soit 20 utilisé par une personne autre que le porteur du moyen de paiement, éventuellement par une personne mal intentionnée, pour initier des transactions sans que le porteur du moyen de paiement soit au courant. Ces procédés consistent principalement en des procédures d'authentification du porteur auprès de l'émetteur du moyen de paiement. 25 Parmi les procédés et systèmes de gestion de transactions existants, certains prévoient un envoi d'information sur un appareil du porteur du moyen de paiement, par exemple un téléphone portable, à chaque fois qu'une transaction est générée. Or, ces procédés et systèmes informent le 30 porteur de la carte après la transaction et ne permettent pas d'empêcher la transaction. D'autres procédés et système connus prévoient que le moyen de paiement soit constamment désactivé. Ainsi, lorsque le porteur du moyen de paiement désire réaliser une transaction, il active le moyen de paiement et 2969880 -2- réalise la transaction. Après la transaction le moyen de paiement est désactivé, soit automatiquement, soit par le porteur du moyen de paiement. Un tel procédé permet effectivement d'éviter l'utilisation du moyen de paiement par une personne autre que le porteur du moyen de paiement.

Enfin, certains procédés et systèmes de gestion de transaction permettent de demander une confirmation au porteur du moyen de paiement grâce à un message envoyé par exemple sur un téléphone portable du porteur du moyen de paiement. Ces procédés et systèmes permettent d'éviter des fraudes mais restent lourds, parfois impossibles à mettre en place de façon efficace pour l'émetteur du moyen de paiement et à utiliser pour le porteur du moyen de paiement. En effet, la gestion des délais sur un réseau d'autorisation bancaire empêche l'exploitation de cette solution, qui elle-même devrait savoir distinguer les typologies de transactions. En outre, les transactions passent toujours en échec si le porteur ne peut être joint ou si l'acheminement du message à ce dernier prend trop de temps.

Un but de la présente invention est de remédier aux inconvénients précités. Un autre but de la présente invention est de proposer un procédé et un système de gestion de transactions moins lourds à mettre en oeuvre tout en étant au moins aussi efficaces que les procédés et systèmes actuels. Un autre but de l'invention est de proposer un procédé et un système de gestion de transactions permettant de réaliser une gestion plus adaptée aux transactions réalisées avec un moyen de paiement.

Enfin, un autre but de la présente invention est de proposer un procédé et un système de gestion de transactions plus simple à gérer pour le porteur d'un moyen de paiement.

L'invention propose d'atteindre les buts précités par un procédé de gestion de transactions générées par un moyen de paiement faisant l'objet d'un contrôle de code de sécurité, et pour lequel une demande d'autorisation peut avoir lieu. Le procédé selon l'invention comprend les étapes suivantes : 2969880 -3- - analyse des données associées à une demande d'autorisation pour déterminer si ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité, et - sécurisation de ladite transaction par application, à ladite demande 5 d'autorisation, de paramétrages de sécurisation différents selon que ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité. Par moyen de paiement on entend, tout moyen de paiement auquel un code de sécurité, par exemple un code confidentiel, est attaché ou peut être 10 attaché, tel que les cartes bancaires physiques ou virtuelles, des cartes de paiement privatives, des cartes de paiement à puce et/ou à piste, des ewallets, des cartes sans contact et téléphones NFC. Le procédé selon l'invention permet de réaliser une discrimination des transactions selon que la transaction a été initiée avec ou sans code de 15 sécurité, et d'appliquer un paramétrage de sécurisation aux transactions initiées avec saisie de code de sécurité différent d'un paramétrage de sécurisation appliqué aux transactions initiées sans saisie de code de sécurité. Ainsi, le procédé selon l'invention permet d'appliquer un premier 20 paramétrage de sécurisation lorsque la transaction est générée sans saisie de code de sécurité, et un deuxième paramétrage de sécurisation lorsque la transaction est générée avec saisie de code de sécurité. Il est ainsi possible avec le procédé selon l'invention de prévoir un paramétrage de sécurisation qui est par exemple plus strict pour les 25 transactions initiées sans saisie de code de sécurité comparé au paramétrage de sécurisation pour les transactions initiées avec saisie de code de sécurité. Ainsi, le procédé selon l'invention permet de réaliser un traitement différent des demandes d'autorisation selon que le code de sécurité à été saisi ou non lors de la génération de la transaction et d'adapter le degré de 30 sécurisation en fonction. Le procédé selon l'invention est donc moins lourd à mettre en oeuvre que les procédés de l'état de la technique qui prévoient d'appliquer le même paramétrage de sécurisation à toutes les demandes d'autorisation, tout en procurant une sécurisation au moins aussi efficace. 2969880 -4- Par ailleurs, la gestion de transactions grâce au procédé selon l'invention est plus simple pour le porteur d'un moyen de paiement car il peut décider un paramétrage ne nécessitant pas d'intervention de sa part pour toutes les transactions réalisées avec saisie de code de sécurité par 5 exemple. Ce qui lui permet de ne pas avoir à activer le moyen de paiement ou de confirmer la transaction pour toutes les transactions qu'il réalise avec saisie de code de sécurité. En outre, le procédé de gestion de transactions selon l'invention permet de réaliser une gestion plus adaptée aux transactions puisqu'elle 10 permet d'appliquer différents paramétrages de sécurisation en fonction du type de chacune des transactions.

Lorsque les données de demande d'autorisation se présentent sous la forme d'une trame comportant plusieurs champs, l'étape d'analyse des 15 données de demande d'autorisation peut comprendre une analyse des données pertinentes de la demande d'autorisation pour déterminer s'il y a eu saisie du code de sécurité. Les données pertinentes, peuvent comprendre un champ de la trame indiquant : - une saisie ou non du code de sécurité, 20 - s'il était demandé au porteur de saisir le code de sécurité. En effet, dans certains lieux de transactions, tels que par exemple les péages d'autoroutes, les transactions sont automatiquement réalisées sans demande de saisie de code de sécurité, - un champ renseignant le pays dans lequel la transaction est réalisée, 25 et/ou - un certificat.

Avantageusement, le paramétrage de sécurisation appliquée à une demande d'autorisation sans saisie de code de sécurité peut comprendre une 30 émission d'une requête de confirmation de ladite autorisation vers un appareil de télécommunications au travers d'un réseau de communications. Ainsi, pour toutes les opérations réalisées sans saisie de code de sécurité, une confirmation que la transaction est réalisée par le porteur légitime sera demandée avant la transaction. Si l'autorisation est refusée la transaction 2969880 -5- sera annulée. La transaction ne pourra être finalisée que si l'autorisation est accordée. L'appareil de télécommunications peut être un téléphone portable, un Smartphone, une tablette Internet, un ordinateur ou tout autre appareil avec 5 lequel il est possible de communiquer au travers d'un réseau de communication, tel le réseau Internet ou le réseau de téléphonie mobile.

Lorsque les données de demande d'autorisation se présentent sous la forme d'une trame comportant plusieurs champs, le paramétrage de 10 sécurisation appliqué à une demande d'autorisation sans saisie de code de sécurité peut comprendre un blocage/refus de ladite autorisation lorsque ladite trame comporte, pour au moins un champ préalablement spécifié, une valeur différente d'au moins une valeur préalablement spécifiée pour ledit champ. 15 Par exemple, le paramétrage de sécurisation peut comprendre une liste de pays autorisés. Lorsque la transaction a été initiée sans saisie de code de sécurité dans un pays qui n'est pas spécifié pas dans la liste des pays autorisés, alors la demande d'autorisation est directement refusée. Dans ce cas, le procédé selon l'invention peut comprendre une consultation 20 du champ préalablement spécifié dans la trame, par exemple le champ « pays », et une comparaison de la valeur de ce champ avec une ou plusieurs valeurs prédéterminées pour ce champ. La ou les valeurs préalablement renseignées pour le champ préalablement spécifié peuvent être des valeurs autorisées ou des valeurs 25 interdites. Le ou les champs spécifiés peuvent être relatifs, au pays de la transaction, au montant, à un des acteurs de la transaction, au circuit de la transaction, à la date, l'heure, la devise, etc.

30 Selon une particularité avantageuse du procédé selon l'invention, le paramétrage de sécurisation appliqué à une demande d'autorisation avec saisie de code de sécurité peut comprendre une émission d'une requête de confirmation de ladite autorisation vers un appareil de télécommunications 2969880 - b - au travers d'un réseau de communications, si le montant de la transaction est supérieur à une valeur préalablement déterminée. Cette caractéristique est particulièrement avantageuse, lorsque le porteur de la carte est une personne qui n'est pas majeure, par exemple un 5 adolescent, et dont les transactions commerciales sont surveillées par son tuteur, par exemple un de ses parents. Ainsi, il est possible pour une deuxième personne de surveiller les dépenses réalisées par le porteur du moyen de paiement.

10 Par ailleurs, le paramétrage de sécurisation appliqué à une demande d'autorisation sans saisie de code de sécurité et/ou le paramétrage de sécurisation appliqué à une demande d'autorisation avec saisie de code de sécurité peut être modifiable à distance au travers d'un réseau de communication, tel qu'un réseau de téléphonie ou le réseau Internet. 15 Le procédé selon l'invention peut en outre comprendre une désactivation/activation à distance d'un paramétrage de sécurisation, par exemple pour un période donnée limitée ou non.

20 De telles modifications, activations ou désactivations peuvent être réalisées avec une application mobile, un serveur vocal, par message courts dits « sms », sur un site internet sécurisé, etc.

Avantageusement, la modification, l'activation et/ou la désactivation à 25 distance d'un paramétrage de sécurisation, ou d'un paramètre en particulier, peut être réalisée au moyen d'une connexion sécurisée.

Le procédé selon l'invention peut en outre comprendre un archivage d'au moins une modification réalisée par un porteur du moyen de paiement 30 sur au moins un paramétrage de sécurisation afin d'assurer la traçabilité de toutes les actions et la gestion du risque.

Le procédé peut en outre comprendre la notification à l'utilisateur que sa demande de modification a bien été prise en compte. 2969880 -7 En outre, le procédé selon l'invention peut également comprendre une génération d'un journal d'autorisations relatives au moyen de paiement concerné. Un tel journal peut comprendre une catégorisation des demandes 5 d'autorisation dans des catégories telles que « transaction autorisée », « transaction refusée/bloquée », etc. et peut être mis à jour instantanément.

Le procédé selon l'invention peut être mis en oeuvre pour la gestion de transactions de proximité, par exemple dans une situation de paiement en 10 face à face c'est-à-dire avec présence du porteur sur le lieu de vente, dans une situation de retrait sur un DAB, un GAB ou un DAC (Distributeur Automatique de Billets, Guichet Automatique Bancaire, Distributeur Automatique de Carburant), et/ou pour la gestion de transactions réalisées à distance au travers d'un réseau de communication, par exemple les 15 transactions réalisées par Internet ou par téléphone.

Dans un mode de réalisation particulier, le procédé selon l'invention peut être mis en oeuvre en aval, en amont d'un serveur d'autorisation ou intégré à un serveur d'autorisation d'un établissement émetteur du moyen 20 de paiement.

Selon un autre aspect de l'invention il est proposé un programme informatique comprenant des instructions exécutables sur un appareil informatique pour mettre en oeuvre les étapes du procédé selon l'invention. 25 Selon encore un autre aspect de l'invention il est proposé un système de gestion de transactions générées par un moyen de paiement faisant l'objet d'un contrôle de code de sécurité et pour lequel une demande d'autorisation peut avoir lieu. Le système selon l'invention est caractérisé en 30 ce qu'il comprend : - des moyens d'analyse de données associées à une demande d'autorisation pour déterminer si ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité, et 2969880 -8- - des moyens de sécurisation de ladite transaction programmés pour appliquer à ladite demande d'autorisation des paramétrages de sécurisation différents selon que ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité. Le système selon l'invention peut comprendre un module d'émission d'une requête de confirmation de l'autorisation à un appareil de télécommunication distant.

10 Le système selon l'invention peut en outre comprendre une interface utilisateur agencée pour modifier, activer ou désactiver à distance un paramétrage de sécurisation au moyen d'une connexion sécurisée.

15 D'autres avantages et caractéristiques apparaîtront à l'examen de la description détaillée d'un mode de réalisation nullement limitatif, et des dessins annexés sur lesquels : - la figure 1 est une représentation sous la forme d'un diagramme d'un procédé selon l'invention, 20 - la figure 2 est une représentation schématique d'un système selon l'invention, et - les figures 3-5 sont plusieurs configurations dans lesquels le procédé et le système selon l'invention peuvent être mis en oeuvre.

25 Sur les figures et dans la suite de la description, les éléments communs à plusieurs figures conservent la même référence.

La figure 1 est une représentation schématique des étapes d'un exemple d'un procédé 100 selon l'invention sous la forme d'un diagramme. 30 Le procédé 100 comprend une première étape 102 de réception d'une demande d'autorisation d'une transaction réalisée avec un moyen de paiement auquel un code de sécurité est associé (mais pas forcément utilisé pour la transaction). La demande d'autorisation comprend une trame (non représentée) de plusieurs champs de données, et notamment un ou plusieurs 5 2969880 -9- champs renseignant sur la saisie ou non d'un code de sécurité associé au moyen de paiement. A l'étape 104, la trame de données est analysée pour déterminer si la transaction pour laquelle la demande d'autorisation a été générée avec ou 5 sans saisie de code. Le type de la transaction est donc déterminé à cette étape, à savoir : « avec saisie de code de sécurité » ou « sans saisie de code de sécurité ». Si la transaction est réalisée avec saisie de code de sécurité c'est le paramétrage sécurisation, dit paramétrage souple, appliqué à ce type de 10 transaction qui est chargé lors d'une étape 106. Si la transaction est réalisée sans de code de sécurité c'est le paramétrage de sécurisation, dit paramétrage strict, appliqué à ce type de transaction qui est chargé lors d'une étape 108. En fonction du paramétrage de sécurisation une étape 110 de 15 traitement de la demande d'autorisation est réalisée pour déterminer une donnée d'autorisation, à savoir une donnée d'autorisation accordée, telle que « OK » ou une donnée d'autorisation refusée telle que « KO ». Le traitement peut comprend : - une comparaison de la valeur d'un ou plusieurs champs de la trame de 20 la demande d'autorisation, préalablement spécifiés dans le paramétrage de sécurisation, à une ou plusieurs conditions associées à ces champs, - émission d'une ou plusieurs requêtes de confirmation vers un appareil distant préalablement spécifié dans le paramétrage de sécurisation, et 25 attente de la réponse à cette ou ces requêtes, - etc. En fonction des données d'autorisation déterminées lors de l'étape de traitement, la demande d'autorisation est soit acceptée soit refusée, lors d'une étape 112, par exemple par l'envoi d'une donnée d'acceptation de type 30 « OK » ou par l'envoi d'une donnée de refus de type « KO ». Le procédé 100 peut en outre comprendre une étape 114 d'archivage, dans des moyens de mémorisation, des demandes de transactions en association avec les données d'autorisation ainsi que le moyen de paiement concerné par les transactions. 2969880 -10- Des modifications des paramétrages de sécurisation peuvent également être archivées dans les moyens de mémorisation. Enfin, le procédé 100 comprend une étape 116 de routage de la demande d'autorisation enrichie de la donnée d'acceptation vers le serveur 5 d'autorisation de l'émetteur du moyen de paiement, qui peut finalement accepter ou refuser la transaction en fonction d'autres critères tels qu'un plafond de paiement autorisé atteint, fond insuffisant sur le compte concerné, etc.

10 La figure 2 est une représentation schématique d'un exemple de réalisation d'un système 200 selon l'invention. Le système 200 comprend une interface utilisateur 202 permettant à un porteur d'un moyen de paiement de configurer un paramétrage de sécurisation souple 204 utilisé pour la gestion de transactions initiées avec 15 saisie d'un code de sécurité associé au moyen de paiement, et un paramétrage de sécurisation strict 206 pour la gestion de transactions initiées sans saisie du code de sécurité associé au moyen de paiement. La configuration des paramétrages de sécurisations 204 et 206 peut être réalisée au travers d'un réseau de communication, par exemple le 20 réseau Internet 208, grâce à une connexion sécurisée 210, par exemple de type SSL. La configuration peut être réalisée grâce à une application mobile 212 installée sur un appareil mobile, tel qu'un Smartphone 214. Le système 200 comprend en outre une interface bancaire ou avec les 25 réseaux d'autorisation 216 permettant de recevoir des demandes d'autorisation depuis un réseau bancaire (non représenté) et d'émettre des données d'autorisation vers le réseau bancaire/d'autorisation grâce à une connexion 218, par exemple de type VPN (de l'anglais Virtual Private Network ou en français Réseau Privé Virtuel). 30 Le système 200 comprend en outre un module d'analyse 220 permettant de réaliser une analyse d'une demande d'autorisation et plus précisément d'une trame TR de champs transmise avec la demande d'autorisation. 2969880 -11- Le module d'analyse 220 permet de déterminer le type TY de la transaction pour laquelle une demande d'autorisation a été reçue, à savoir, une transaction avec ou sans saisie de code. Le module d'analyse 220 transfère le type TY de la transaction ainsi 5 que la trame TR à un module de traitement 222. Le module de traitement 222 charge ou consulte le paramétrage de sécurité associé au type TY de la transaction, à savoir soit le paramétrage souple 204 soit le paramétrage strict 206. Si besoin le module de traitement 222 demandera à un module de 10 communication 224 d'émettre une ou plusieurs requêtes de confirmation vers l'appareil mobile 214. Le module de traitement 222 émet une donnée d'autorisation, accordant ou refusant la transaction. Cette donnée sera communiquée au réseau bancaire/d'autorisation au travers de l'interface de connexion 216. 15 Le système 200 comprend en outre des moyens de mémorisation 226 dans lesquels sont mémorisés la demande d'autorisation, la donnée d'autorisation ainsi que le moyen de paiement concerné par la transaction. Les moyens de mémorisation 226 mémorisent également les modifications des paramétrages de sécurisation 204 et 206. 20 Les figures 3-5 sont plusieurs configurations dans lesquels le procédé et le système selon l'invention peuvent être mis en oeuvre. Dans les configurations représentées sur les figures 3 à 5, la transaction est initiée chez un marchand 302 et transmise à la banque de 25 l'acquéreur 304 au travers d'une connexion sécurisée. La banque acquéreur 304 transmet une demande d'autorisation 306 vers la banque émettrice 308 du moyen de paiement au travers d'un réseau bancaire ou d'un réseau privatif 310. En réponse à la donnée d'autorisation, une donnée d'autorisation 312 par exemple « OK » ou « KO », est déterminée par le 30 système 200 de la figure 2. Cette donnée d'autorisation 312 est ensuite transmise par la banque émettrice 308 à la banque acquéreur 304 au travers du réseau bancaire ou privatif 310. Le procédé selon l'invention ne se substitue pas aux serveurs d'autorisation de l'émetteur. Ainsi, si le procédé indique qu'une transaction 2969880 -12- est OK, l'établissement émetteur peut tout à fait décider de refuser la demande d'autorisation sur d'autres critères (plafond de paiement atteint, etc.). Ainsi, le procédé selon l'invention marque les demandes d'autorisation de transaction pour qu'elles soient traitées ensuite chez l'émetteur en 5 connaissance des paramètres surveillés par le procédé. Dans la configuration 300 de la figure 3, le système 200 selon l'invention est situé à distance de la banque émettrice 308 et est connecté à la banque émettrice au travers d'une connexion 218 sécurisée de type VPN. La demande d'autorisation 306 est transmise au système 200 par la banque 10 émettrice 308 et la donnée d'autorisation déterminée par le système 200 est transmise à la banque émettrice 308 qui l'envoie à la banque acquéreur 304. Autrement dit, le système 200 se trouve en dehors des infrastructures d'autorisations de l'organisme émetteur du moyen de paiement, avec lesquelles elle est cependant interfacée via un réseau sécurisée. 15 Dans la configuration 400 représentée sur la figure 4, le système 200 selon l'invention est situé dans la banque émettrice 308, c'est-à-dire au sein même des infrastructures d'autorisations de l'organisme émetteur du moyen de paiement. 20 Dans la configuration 500 représentée sur la figure 5, le système 200 selon l'invention est situé entre la banque acquéreur 304 et la banque émettrice 308. Autrement dit, le système 200 selon l'invention se trouve au sein des infrastructures de transport du fournisseur de services de routage 25 sécurisé et le procédé constitue un service à valeur ajouté pour l'établissement émetteur destinataire de la demande d'autorisation « enrichie » par le système 200. L'information complémentaire transmise par le procédé constitue une sorte de scoring supplémentaire venant s'ajouter aux autres éléments de décision du serveur d'autorisation de l'établissement 30 émetteur.

Nous allons maintenant décrire un exemple de paramétrage strict, pour les transactions ayant été réalisées sans saisie du code personnel. Le paramétrage strict comprend : 2969880 -13- - a) montant plafond à 1000, et - b) devise autorisée : Euro, et - c) confirmation nécessaire par le porteur. Ainsi, une demande d'autorisation pour une transaction d'un montant 5 supérieur à 1000 sera refusée, ou plus précisément sera enrichie d'une information indiquant à l'établissement émetteur que le porteur refuse cette transaction. Il en serait de même pour une transaction de 10$, où le critère devise sera suffisant pour rejeter cette transaction. Dans le cas où, les conditions a) et b) sont respectées, et que le 10 porteur, sollicité sur son mobile, ne répond pas alors la transaction sera rejetée.

Nous allons maintenant décrire un exemple de paramétrage souple, pour les transactions ayant été réalisées avec saisie du code personnel. Le 15 paramétrage souple pourrait relever des mêmes règles a) et b) mais pas de la règle c). Dans ce cas, si les conditions a) et b) sont respectées, et que le porteur ne répond pas suite à une première sollicitation sur le mobile, le système indique que la transaction devra être traitée de façon standard par l'établissement émetteur. 20 Nous allons maintenant donner un exemple de trame d'une demande d'autorisation française respectant des normes ISO (8583) utilisées dans d'autres pays que la France.

25 X: Obligatoire C: Conditionnel F: Facultatif .: Champ non traité S: Valeur spécifique au message 30 Q: Valeur comme la question QI: Valeur comme la question initiale RI: Valeur comme la réponse initiale A: Demande d'autorisation: 0100 B: Réponse à demande d'autorisation : 0110 10 15 20 25 30 35 40 -14- N° Définition A B 1 Présence deuxième bit map C(1) C(1) 2 Numéro de porteur >:S:i 3 Code de traitement X XQ 4 Montant de la transaction XS X 7 Date et heure de transmission XS: XS: 11 Numéro d'audit XS :Xi 12 Heure locale de la transaction XS FQ 13 Date locale de la transaction XS (.` 14 Date d'expiration `S 15 Date de règlement C(6) 18 Code activité de l'accepteur XS F 22 Mode de lecture du système d'acceptation XS Q 25 Conditions de la transaction au point de service X _= 27 Longueur du numéro d'autorisation C(7).

32 Identification de l'organisme acquéreur XS XQ 33 Identification de l'organisme transmetteur C(21) FQ 37 Numéro de référence d'archivage F FQ 38 Autorisation, réponse d'identification C(10) 39 Code réponse XS 41 Identification du système d'acceptation ?S 42 Identification de l'accepteur de carte xS x 43 Nom et adresse de l'accepteur de carte -S _= 44 Données complémentaires de réponse C(2) AA Champ erroné C(69) AB Erreur de sécurité C(12) AC Conversion de champ AF Code activation service BB Numéro de téléphone BC Message à destination de l'initiateur de la transaction CA Informations relatives au traitement du CVV/CVC C(12) CB Informations relatives au contrôle du cryptogramme C(12) 47 Données complémentaires nationales C(2) C(2) 08 Type de site C(63) '«` 24 Numéro de dossier C(110) C(110) 95 Données de réseau C(6) 96 SIRET C(63) 97 IDPA C(63) AO IDSA C(63) FQ 49 Code monnaie de la transaction XS XQ 53 Informations liées à la sécurité XS XS 10 15 20 25 30 2969880 -15- Code fonction C(98) Code raison du message XS Année de la transaction XS CQ(95) Environnement règlementaire et technique de la transaction XS F'Q ITP (Identifiant de l'application Terminal) XS Numéro de contrat accepteur X Q 0203 Numéro logique du système d'acceptation XS FQ 0204 Numéro logique du point d'acceptation C(22) F 0205 Code pays du système d'acceptation 0207 Montant cumulé par porteur X _= 020B Type d'applicatif du système d'acceptation (TASA) X _= 0210 Référence client 1 C(109) 0211 Référence client 2 C(109) 0212 Numéro de marché C(109) 0213 Montant de TVA C(109) 0300 Cryptogramme visuel 0301 Informations relatives au contrôle du cryptogramme visuel C(12) 0400 Identifiant transaction fourni par l'accepteur C(99) 0401 Cryptogramme commerce électronique C(99) 0407 Type de sécurisation de transaction de commerce électronique C(5) 0409 Informations relatives au traitement du cryptogramme commerce électronique C(12) 0410 Méthode d'authentification porteur utilisée par l'émetteur C(6) 0411 Méthode de calcul du cryptogramme de commerce électronique C(101) 0412 Résultat de l'utilisation de l'architecture de paiement sécurisé VADS C(102) 0413 Mode de sécurisation de la transaction modifié C(6) 0800 Type de facture / procédure C(13) CQ(13). Bien entendu, l'invention n'est pas limitée aux exemples qui viennent d'être décrits.

59 Données nationales C(2) C(2) 0100 0101 0102 0200 0201 0202

Claims (15)

1. REVENDICATIONS1. Procédé de gestion de transactions générées par un moyen de paiement faisant l'objet d'un contrôle de code de sécurité, et pour lequel une demande d'autorisation (306) peut avoir lieu, caractérisé en ce qu'il comprend les étapes suivantes : - analyse (104) des données associées à une demande d'autorisation (306) pour déterminer si ladite demande d'autorisation (306) est générée avec ou sans saisie de code de sécurité, - sécurisation de ladite transaction par application (110), à ladite demande d'autorisation (306), de paramétrages de sécurisation (204, 206) différents selon que ladite demande d'autorisation (306) est générée avec ou sans saisie de code de sécurité.
2. 2. Procédé selon la revendication 1, caractérisé en ce que les données de demande d'autorisation se présentent sous la forme d'une trame comportant plusieurs champs, l'étape d'analyse (104) des données de demande d'autorisation (306) comprenant une analyse des données pertinentes de la demande d'autorisation pour déterminer s'il y a eu saisie du code de sécurité.
3. 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le paramétrage de sécurisation (206) appliquée à une demande d'autorisation (306) sans saisie de code de sécurité comprend une émission d'une requête de confirmation de ladite autorisation vers un appareil (214) de télécommunications au travers d'un réseau (208) de communications.
4. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données de demande d'autorisation se présentent sous la forme d'une trame comportant plusieurs champs, et en ce que le paramétrage de sécurisation (204) appliqué à une demande d'autorisation (306) sans saisie de code de sécurité comprend un blocage/refus de ladite autorisation lorsque ladite trame comporte, pour au moins un champ 2969880 -17- préalablement spécifié, une valeur différente d'au moins une valeur préalablement spécifiée pour ledit champ.
5. 5. Procédé selon l'une quelconque des revendications précédentes, 5 caractérisé en ce que le paramétrage de sécurisation (204) appliqué à une demande d'autorisation (306) avec saisie de code de sécurité comprend une émission d'une requête de confirmation de ladite autorisation vers un appareil (214) de télécommunications au travers d'un réseau (208) de communications, si le montant de la transaction est supérieur à une valeur 10 préalablement déterminée.
6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le paramétrage de sécurisation (206) appliqué à une demande d'autorisation (306) sans saisie de code de sécurité et/ou le 15 paramétrage de sécurisation (204) appliqué à une demande d'autorisation (306) avec saisie de code de sécurité est modifiable à distance au travers d'un réseau (208) de communication.
7. 7. Procédé selon l'une quelconque des revendications précédentes, 20 caractérisé en ce qu'il comprend en outre une désactivation/activation à distance d'un paramétrage de sécurisation (204, 206)7
8. 8. Procédé selon l'une quelconque des revendications 6 ou 7, caractérisé en ce qu'il comprend un archivage d'au moins une modification réalisée par un 25 porteur du moyen de paiement sur au moins un paramétrage de sécurisation.
9. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une génération d'un journal 30 d'autorisations relatives au moyen de paiement concerné.
10. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est mis en couvre pour la gestion de transactions de 2969880 -18- proximité, sur automates ou de transactions réalisées à distance au travers d'un réseau de communication.
11. 11. Procédé selon l'une quelconque des revendications précédentes, 5 caractérisé en ce qu'il est mis en ceuvre en aval, en amont ou intégré à un serveur d'autorisation d'un établissement émetteur du moyen de paiement.
12. 12. Programme informatique comprenant des instructions exécutables sur un appareil informatique pour mettre en oeuvre les étapes du procédé selon 10 l'une quelconque des revendications précédentes.
13. 13. Système (200) de gestion de transactions générées par un moyen de paiement faisant l'objet d'un contrôle de code de sécurité et pour lequel une demande d'autorisation (306) peut avoir lieu, caractérisé en ce qu'il 15 comprend : - des moyens (220) d'analyse des données associées à une demande d'autorisation (306) pour déterminer si ladite demande d'autorisation est générée avec ou sans saisie de code de sécurité, - des moyens (222, 224, 204, 206) de sécurisation de ladite 20 transaction programmés pour appliquer à ladite demande d'autorisation (306) des paramétrages de sécurisation (204, 206) différents selon que ladite demande d'autorisation (306) est générée avec ou sans saisie de code de sécurité. 25
14. 14. Système selon la revendication 13, caractérisé en ce qu'il comprend un module (224) d'émission d'une requête de confirmation de l'autorisation à un appareil (214) de télécommunication distant.
15. 15. Système selon l'une quelconque des revendications 13 ou 14, 30 caractérisé en ce qu'il comprend une interface (202) utilisateur agencée pour modifier, activer ou désactiver à distance un paramétrage de sécurisation (204, 206) au moyen d'une connexion (210) sécurisée.