Brevet FR3091945A1 — publié le 20200724

Description Titre de l'invention : Procédé de transaction avec une devise différente, et dispositif correspondant Domaine technique [0001] L'invention se rapporte au domaine général des dispositifs électroniques configurés pour mettre en oeuvre des transactions de paiement. L'invention concerne en particulier les dispositifs électroniques configurés pour mettre en oeuvre des transactions de paiement. [0002] L'invention trouve application de manière non exclusive dans les cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme ISO 7816. L'invention concerne tout particulièrement les cartes à puce qui mettent en oeuvre des transactions de paiement, par exemple selon le standard EMV (« Europay Mastercard Visa », par exemple dans sa version 4.3) et/ou la spécification EMV Contactless (par exemple dans sa version 3.0). Technique antérieure [0003] Le standard EMV, bien connu de l'homme du métier, est utilisé pour sécuriser des transactions réalisées par des cartes à puce, en particulier des transactions bancaires de paiement. D'autres transactions peuvent également être mises en oeuvre par ces cartes à puce, par exemple des transactions de transfert, de consultation, ou encore d'authentification. [0004] Ce standard permet de sécuriser les transactions et de limiter les fraudes. A cet effet, il implique l'utilisation de cryptogrammes ou encore de codes secrets (généralement désignés par l'acronyme anglo-saxon :« PIN : Personal Identification Number »). [0005] Les cartes existantes sont généralement associées à une devise. Typiquement, une carte émise par une banque d'un pays de la zone euro sera associée à l'euro. Il reste cependant possible de mettre en oeuvre des transactions dans d'autres devises. Les mécanismes de sécurité ou d'évaluation du risque de la carte, pour valider la transaction, vont alors convertir le montant de la transaction vers la devise associée à la carte pour ensuite utiliser ces mécanismes de sécurité ou d'évaluation du risque. [0006] L'homme du métier désigne généralement ces mécanismes de sécurité ou d'évaluation du risque par l'acronyme anglo-saxon « CRM :Card Risk Management ». Le CRM comprend par exemple une comparaison entre une valeur limite de montant de transaction et le montant de la transaction en cours. [0007] Dès lors, on comprend que les opérations de CRM ne peuvent être effectuées cor- rectement que si la carte peut. convertir la valeur du montant de la transaction en cours. [0008] Les cartes comprennent donc typiquement une table dans lesquelles on peut lire, pour 2 une devise (désignée par un code), un taux de conversion. Tel est notamment le cas pour les cartes qui implémentent la norme « Common Payment Application - EMV - Version 1.0 -Décembre 2015 ». [0009] Généralement, les taux de conversion sont enregistrés dans les cartes au cours d'une phase de personnalisation bien connue de l'homme du métier. [0010] Cette solution présente plusieurs problèmes. Tout d'abord, si certains taux de conversion sont fixes (tel est le cas entre le franc CFA et l'Ouro), d'autres sont dits flottants. Ces taux flottants peuvent donc être obsolètes et ne pas permettre de mettre en oeuvre les opérations de CRM dc manière satisfaisante. [0011] Aussi, si un taux nécessaire est absent de la carte, certaines cartes peuvent accepter les transactions sans avoir pu faire les vérifications du CRM. [0012] L'invention vise notamment à pallier ces inconvénients. Exposé de l'invention [0013] A cet effet, l'invention propose un procédé de contrôle mis en oeuvre par un dispositif électronique au cours d'une transaction de paiement, la transaction de paiement étant associée à une devise, le procédé comprenant une vérification de la pertinence d'un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique. [0014] Ainsi, dans l'invention, on va vérifier la pertinence du taux et tenir compte de cette information pour la suite de la transaction. [0015] On pourra notamment mettre en oeuvre un traitement qui tient compte de la pertinence ou de la non-pertinence du taux. Par exemple, cc traitement peut aboutir au refus de la transaction si le taux n'est plus pertinent. [0016] On peut noter que la pertinence d'un taux peut être vérifiée par des comparaisons à des valeurs de seuil enregistrées dans le dispositif électronique. [0017] Par exemple, un taux est pertinent si sa valeur est peu éloignée de celle réelle, ou au moins s'il est probable que la valeur du taux soit peu éloignée de celle réelle. [0018] L'invention permet donc d'améliorer la sécurité des transactions, car la pertinence d'un taux est une information utile pour améliorer la sécurité de la transaction. [0019] Selon un mode de réalisation particulier, le procédé comprend une vérification préalable de la présence dudit taux de conversion dans une mémoire non volatile du dispositif électronique. [0020] Le procédé poun-a comprendre un traitement supplémentaire tenant compte de l'absence du taux dans une mémoire non volatile du dispositif électronique. Par exemple, le traitement supplémentaire peut être un refus de la transaction. [0021] On peut noter qu'un taux présent est enregistré. La vérification de sa présence peut utiliser un code qui désigne le taux. 3 [0022] Selon un mode de mise en oeuvre particulier, le dispositif électronique émet une demande de taux de conversion si ledit taux de conversion n'est pas présent dans une mémoire non volatile du dispositif électronique. [0023] On peut noter que cette émission d'une demande de taux peut être réalisée dans le cadre d'une transaction dans un mode dit en ligne (« online » en anglais). [0024] Aussi, s'il a été déterminé que le taux n'est pas présent, le dispositif électronique peut forcer un mode en ligne pour la transaction. On peut noter que le mode en ligne peut également être forcé s'il est déterminé que le taux n'est pas pertinent. [0025] Dans le cadre d'une transaction en ligne, il est possible, pour un dispositif élec- tronique qui met en oeuvre une transaction avec un lecteur configure pour communiquer avec le dispositif électronique, d'émettre des informations au lecteur qui pourra les retransmettre à un tiers, typiquement à une entité émettrice du dispositif électronique (par exemple une banque si le dispositif électronique est une carte bancaire). [0026] Selon un mode de mise en oeuvre particulier, ladite vérification de la pertinence du taux est mise en oeuvre au moyen d'au moins une information parmi une date de mise à jour du taux, un indicateur de volatilité du taux, et un type de taux. On pourra aussi utiliser toute combinaison de ces trois informations. [0027] Les inventeurs de la présente invention ont observé que la date de mise à jour d'un taux est une information qui permet de vérifier si un taux est pertinent. Typiquement si la durée (par exemple en nombre de jours) entre la date de mise à jour et la date actuelle est supérieur à un seuil prédéterminé, alors on considère que le taux n'est pas pertinent. [0028] Un indicateur de volatilité peut indiquer la variation maximale possible d'un taux sur une base de temps. Typiquement, on pourra déterminer si la variation du taux depuis sa dernière mise à jour dépasse un seuil prédéterminé. Si tel est le cas le taux n'est pas pertinent. [0029] En outre, le type de taux peut indiquer si le taux est un taux fixe ou un taux flottant. Si le taux est un taux fixe alors il est considéré comme pertinent. Si le taux est flottant alors des vérifications supplémentaires peuvent être mises en oeuvre, éventuellement au moyen de la date de mise à jour du taux ou d'un indicateur de volatilité du taux. [0030] Selon un mode de mise en oeuvre particulier, si le taux de conversion de la devise associée à la transaction n'est pas pertinent alors on met à jour ledit taux de conversion. [0031] Selon un mode de mise en oeuvre particulier, la mise à jour dudit taux de conversion comprend l'émission d'une demande de taux de conversion. [0032] Par exemple, l'émission de cette demande peut être réalisée au cours d'une transaction en ligne. Préférentiellement, si le taux n'est pas pertinent alors la transaction se poursuit dans un mode en ligne. [0033] Selon un mode de mise en oeuvre particulier, on convertit un montant associé à ladite transaction en utilisant ledit taux de conversion ou ledit taux de conversion mis à jour. [0034] L'obtention de cc montant converti est particulièrement utile pour que la carte puisse déterminer si cette transaction peut être autorisée, par exemple. [0035] Selon un mode de mise en oeuvre particulier, ladite conversion comprend la déter- mination d'une plage de valeurs de montants convertis possibles en utilisant un indicateur de volatilité du taux. [0036] Ce mode particulier de mise en oeuvre peut en outre utiliser une date de mise à jour du taux. [0037] La plage correspond à la variation croissante ou décroissante possible du taux à partir de son ancienne valeur. [0038] Selon un mode de mise en oeuvre particulier, on met en oeuvre un traitement gestion du risque (c'est-à-dire un CRM) sur la base du montant converti ou sur la base de ladite plage de valeurs. [0039] Si l'on utilise ladite plage de valeurs, on pourra par exemple tenir compte de la valeur maximale et/ou de la valeur minimale de la plage de valeurs pour le CRM. [0040] Selon un mode de mise en oeuvre particulier, la transaction est une transaction selon la norme EMV (Version 4.3, ou une version ultérieure), ou encore une transaction selon la norme EMV Contactless (Version 3.0, ou une version ultérieure). [0041] L'invention propose également un dispositif électronique configuré pour mettre en oeuvre une transaction de paiement associée à une devise, comprenant un module de vérification de la pertinence d'un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique. [0042] Ce dispositif électronique peut être configuré pour la mise en oeuvre de chacun des modes de mise en oeuvre du procédé décrit ci-avant. [0043] Selon un mode de réalisation particulier, le dispositif électronique comprend une carte à puce. [0044] En particulier, la carte à puce peut être une carte à puce selon la norme ISO 7816 (version de 1999 ou ultérieure). Par exemple, la carte à puce peut être une carte bancaire. [0045] L'invention propose également un programme d'ordinateur comportant des ins- tructions pour l'exécution des étapes d'un procédé tel que défini ci-avant lorsque ledit programme est exécuté par un ordinateur. [0046] A noter que les programmes d'ordinateur mentionnés dans le présent exposé peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. 100471 L'invention propose également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé tel que défini ci-avant. [0048] Les supports d'enregistrement (ou d'information) mentionnés dans le présent exposé peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. [0049] D'autre part, les supports d'enregistrement peuvent correspondre à un support trans- missible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0050] Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins [0051] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [0052] [fig.1] La figure 1 illustre de manière schématique les étapes d'un procédé de transaction selon un exemple. [0053] [fig.2] La figure 2 illustre de manière schématique les étapes d'un CRM selon un exemple. [0054] [fig.3] La figure 3 illustre de manière schématique les étapes d'un CRM selon un exemple. [0055] [fig.4] La figure 4 est un schéma d'un exemple de dispositif électronique. Description des modes de réalisation 100561 On va maintenant décrire un procédé de transaction de paiement mis en oeuvre par un dispositif électronique selon un exemple d'implémentation de l'invention. 100571 Dans cet exemple, le dispositif électronique est une carte à puce selon la nonne ISO 7816. Cette carte à puce peut être capable de mettre en oeuvre des transactions de paiement selon la norme EMV (Europay Mastercard Visa) dans sa version 4.3 et notamment au moyen d'applications, par exemple selon la norme d'implémentation d'applications « Common Payment Application - EMV - Version 1.0 - Décembre 6 2015 » (ou une version ultérieure). Cette carte à puce est ici une carte bancaire. [0058] Dans l'exemple qui suit, la carte bancaire est munie d'une mémoire non-volatile qui comporte des informations qui vont faciliter la mise en oeuvre du procédé. [0059] Dans les cartes bancaires selon la technique antérieure on peut mémoriser uniquement des codes identifiant des taux de conversion, plusieurs taux associés à une même devise et chacun à une application respective , ainsi que des indicateurs qui indiquent la présence ou l'absence de chaque taux, et éventuellement des exposants de conversion (un nombre signé qui indique la puissance de 10 utilisée pour multiplier le taux de conversion mémorisé et obtenir une approximation du vrai taux). Ici, on mémorise davantage d'informations et notamment des informations choisies parmi : - plusieurs taux associés à une même devise et chacun à un type de transaction effectuée sur la carte (paiement, retrait de liquide, paiement différé, remboursement, annulation ...), - les dates de dernière mise à jour des taux ; - des indicateurs de volatilité pour chaque taux ; - les types de chaque taux (fixe, flottant) ; - un ou plusieurs seuils de comparaison pour vérifier si un taux n'est plus pertinent ; et - un ou plusieurs seuils de comparaison pour vérifier si un taux de conversion n'est pas acceptable pour une transaction. [0060] Avec une telle carte à puce, on peut mettre en oeuvre des transactions de paiement telle que celle représentée sur la figure I. Sur cette figure, on a représenté une transaction EMV. [0061] Une transaction EMV peut commencer par la réception d'une commande de sélection d'application (étape select_app_RX). Cette commande est émise par un lecteur, par exemple un lecteur de carte bancaire d'un automate de distributeur de billets ou un terminal de paiement dans un magasin. [0062] Au cours d'échanges avec le lecteur, la carte reçoit des informations relatives à la transaction et en particulier un montant et une devise (par exemple sous la forme d'un code qui désigne la devise) ; cette devise associée à la transaction peut être différente de la devise associée à la carte. [0063] Ultérieurement et éventuellement après plusieurs échanges avec le lecteur, une commande de génération de cryptogramme, connue en soi dans une transaction EMV, est reçue au cours de l'étape generate_acl_RX. Il s'agit de la première demande de génération de cryptogramme, qui va notamment permettre de déterminer si la transaction doit se poursuivre dans un mode en ligne ou dans un mode hors ligne. [0064] A cet effet, on met en oeuvre une étape de gestion du risque CRM_1 (typiquement un CRNI), mais dans laquelle on met en oeuvre une étape verif_l de vérification de la 7 pertinence d'un taux de conversion. En fonction des résultats de cette étape, la carte va élaborer un cryptogramme en réponse à la demande de l'étape gencrate acl RX. Cette élaboration est donc mise en oeuvre après l'étape CRM 1. [0065] Ultérieurement et au cours de la même transaction, la carte à puce reçoit une deuxième demande dc génération de cryptogramme dans l'étape generate ac2 RX. Il s'agit de la deuxième demande de génération de cryptogramme, qui va notamment permettre de déterminer si la transaction est refusée ou acceptée. [0066] A cet effet, on met en oeuvre une étape de gestion du risque CRM 2 (typiquement un CRM), mais dans laquelle on met en oeuvre une étape vcrif 2 de vérification dc la pertinence d'un taux de conversion. En fonction des résultats de cette étape, la carte va élaborer un cryptogramme en réponse à la demande de l'étape gencrate ac2 RX. Cette élaboration est donc mise en oeuvre après l'étape CRM 2. [0067] Les étapes CRM 1 et CRM 2 et leurs sous-étapes vcrif 1 et vcrif 2 vont être décrites plus en détail ci-après en référence aux figures 2 et 3. [0068] Sur la figure 2, on a représenté des étapes qui peuvent être mises en oeuvre dans le cadre du procédé de la figure 1, par exemple au cours dc l'étape CRM 1 : la première étape de gestion du risque. [0069] Dans une première étape S01, on vérifie si un taux de conversion permettant de passer de la devise associée à la transaction à la devise associée à la carte a été préalablement enregistré dans une mémoire non volatile de la carte. Un tel enregistrement peut avoir été fait au cours d'une phase de personnalisation. Par exemple, une table qui met en correspondance des codes associés aux devises et des taux peut être enregistrée dans la mémoire non volatile, et on peut consulter cette table au cours de l'étape SOL [0070] Si le taux n'est pas présent, on met en oeuvre l'étape SO2 dans laquelle la carte émet une demande de taux de conversion. L'étape SO2 peut comprendre le passage dans un mode en ligne pour la transaction. [0071] Par exemple, la demande peut être émise à travers le lecteur à une entité émettrice de la carte, par exemple une banque. [0072] Pour cette demande de mise à jour, la carte peut utiliser des informations de la carte qui vont indiquer l'application de paiement utilisée, ainsi que les informations relatives à l'absence de taux (et en particulier un identifiant du taux). Par exemple, on pourra utiliser les données connues de l'homme du métier sous l'acronyme anglo saxon IDD : Issuer Discretionary Data » ou encore les données « CVR : Card Verification Result » (qui informent l'émetteur de la carte des conditions d'exception survenues lors de la transaction). Ces données sont typiquement stockées dans une partie appelée IAD : Issuer Application Data ». [0073] La table mentionnée ci-avant est ainsi complétée avec des informations reçues. On peut noter que la date de mise à jour du taux est également modifiée. 8 [0074] En outre, au cours de l'étape 502, on peut demander d'autres taux de conversion, par exemple d'autres taux qui ont été considérés comme non pertinents. A cet effet, dans une variante, on vérifie la pertinence de tout ou partie des taux de conversion mémorisés. Dans une autre variante, les autres taux ont été considérés comme non-pertinents au cours d'une transaction précédente (par exemple une transaction pour laquelle le mode en ligne n'était pas disponible). [0075] Dans l'étape 503, on vérifie la pertinence du taux. On peut noter que si un taux a été reçu à l'étape 502, ce taux est considéré comme pertinent et la mise en oeuvre de l'étape 503 est alors optionnelle.. [0076] Selon une première variante, l'étape S03 comprend une détermination de la durée entre la date de mise à jour du taux et la date de la transaction en cours. Si cette durée est inférieure à un seuil de durée prédéterminé alors le taux de conversion est considéré comme pertinent.Selon une deuxième variante, l'étape S03 comprend la détermination d'une valeur possible maximale M A max pour le montant associé à la transaction et d'une valeur possible minimale M A min pour le montant associé à la transaction. [0077] En fait, M A max et M A min peuvent être déterminés à partir d'un indicateur de volatilité du taux qui peut être exprimé en pourcentage de variation sur une durée prédéterminée (par exemple 30 jours), de la date de mise à jour, du montant de la transaction en cours exprimé dans la devise associée à la transaction, et le taux correspondant enregistré. [0078] Par exemple, M_A_max = (1-FVOL*DEUBT)*M_X*T_XA, avec VOL l'indicateur de volatilité, DEL la durée entre la date de mise à jour et la date de transaction, BT la base de temps (typiquement 30 jours, M_X le montant exprimé dans la devise de la transaction en cours et T_XA le taux pour passer de la devise de la transaction en cours à la devise associée à la carte. Aussi, par exemple, M_A_min = (1-VOL*DEL/BT)*M_X*T_XA. [0079] Si on a M_A_max-M_A_min>SEUILl, avec SEUIL1 un seuil prédéfini, alors on considère qu'il y a trop d'incertitude sur le montant converti et le taux n'est pas pertinent. [0080] Selon une troisième variante, si VOL*DEL/BT>SEUIL2, avec SEUIL2 un seuil prédéfini, alors on considère que la volatilité est trop grande et que le taux n'est pas pertinent. [0081] D'autres variantes peuvent être conçues sur la base des valeurs VOL, DEL, etc. [0082] On notera que dans l'étape S03, on peut également vérifier le type de taux. S'il est fixe, il est considéré comme pertinent. [0083] S'il est déterminé que le taux n'est pas pertinent, alors on émet une demande de mise à jour du taux au cours dans l'étape SO4. L'étape SO4 peut comprendre le passage dans un mode en ligne pour la transaction. L'émission de cette demande est analogue à celle 9 de l'étape SO2 décrite ci-avant. [0084] Au cours de l'étape 504, on peut demander d'autres taux de conversion, par exemple d'autres taux qui ont été considérés comme non pertinents. A cet effet, dans une variante, on vérifie la pertinence de tout ou partie des taux de conversion mémorisés. Dans une autre variante, les autres taux ont été considérés comme non-pertinents au cours d'une transaction précédente (par exemple une transaction pour laquelle le mode en ligne n'était pas disponible). [0085] On peut noter que si une table est utilisée, alors la modification de cette table peut utiliser des commandes généralement désignées comme des « commandes de script » par l'homme du métier (dans la norme EMV, on parle de « Issuer Script Commands »). Cette commande peut identifier la table au moyen d'un identifiant, puis identifier le taux à mettre à jour par son identifiant. On peut également concevoir que si le taux à écrire (par exemple dans le cadre de l'étape 502) n'est pas présent dans la table, on peut écraser une autre valeur de taux (typiquement celle qui est la plus obsolète c'est-à-dire qui a la date de mise à jour la plus ancienne). [0086] On met ensuite en oeuvre l'étape SO5 de conversion du montant de la transaction vers la devise. [0087] Selon une première variante, on détermine une plage de valeurs de montants convertis possibles comprises entre M A max et M A min. [0088] Selon une deuxième variante, on calcule directement un montant M A= M_X*T_XA. [0089] On peut ensuite mettre en oeuvre l'étape S06 dans laquelle on met en oeuvre un traitement de gestion du risque qui utilise les montants déterminés à l'étape 505. [0090] Plusieurs vérifications peuvent être mises en oeuvre. En particulier, si un seul montant M_A a été déterminé, on peut mettre à jour la valeur d'un accumulateur ACCU de montants de transactions réalisées avec la carte (On peut noter que différents accumulateurs de ce type peuvent être utilisés, par exemple un pour les transactions domestiques, un pour les transactions internationales, un pour les transactions de retrait, etc.). Si ACCU>LIMIT_UPPER, LIMIT_UPPER étant une limite supérieure alors on considère que cette vérification échoue et on en tient compte ensuite dans la réponse de la carte (généralement lors de la commande qui génère le cryptogramme). On peut aussi utiliser une limite inférieure LIMIT_LOWER et vérifier si ACCU>LIMIT_LOWER. De la même manière, on tient compte de l'échec de cette vérification dans la réponse de la carte. [0091] Des comportements différents peuvent être associés au dépassement de LIMIT_LOWER et de LIMIT_UPPER, avec, comme on le conçoit, LIMIT_LOWER LIMIT UPPER et si ACCU2>LEVIIT LOWER. On obtient ainsi une vérification plus précise qu'avec un unique accumulateur, qui tient compte de la volatilité du taux. [0094] Dans une deuxième variante, on peut mettre en oeuvre quatre vérifications : - ACCU1>LIMIT UPPER - ACCU1>LIMIT LOWER - ACCU2>LIMIT UPPER - ACCU2>LIMIT LOWER [0095] Cette variante est plus précise que la première variante, et elle permet de prévoir des comportements différents en fonction de chaque dépassement détecté. [0096] En outre, pour des applications, on peut avoir plusieurs limites inférieures et su- périeures. Dans une troisième variante, les limites sont propres à chaque accumulateur, ce qui offre davantage de flexibilité. [0097] L'initialisation des accumulateurs peut être effectuée durant la fabrication des cartes pendant une phase de personnalisation. [0098] La réinitialisation de tout ou partie de ces accumulateurs peut se faire lors de la détection d'un évènement prédéterminé, par exemple la réception de la commande gencrate ac2 RX décrite ci-avant (avec un paramètre spécifique), ou encore par des commandes de script telles qu'évoquées ci-avant. [0099] La carte peut ensuite élaborer un cryptogramme, qui est le premier cryptogramme. Ce cryptogramme peut être élaboré à ce stade (c'est-à-dire après la mise en oeuvre de l'étape 506), ou de manière alternative après la mise en oeuvre de l'étape SO2 ou de l'étape 504. [0100] Sur la figure 3, on a représenté des étapes qui peuvent être mises en oeuvre dans le cadre du procédé de la figure 1, par exemple au cours de l'étape CRM_2 : la deuxième étape de gestion du risque. [0101] Ici, une première étape SIO est mise en oeuvre de manière analogue à l'étape SO1 décrite en référence à la figure 1. Si le taux est présent on met en oeuvre l'étape S12 de vérification de la pertinence du taux (analogue à l'étape S03). [0102] Par contre, si le taux n'est pas présent ou s'il n'est pas pertinent, on met en oeuvre l'étape SII de traitement de sécurité. Ce traitement peut comprendre : - le refus de la transaction, car la banque considère que la transaction est trop risquée ; ou - l'incrémentation d'un compteur de transactions pour lesquelles le taux est absent ou non pertinent. [0103] L'utilisation du compteur de transactions pour lesquelles le taux est absent ou non 11 pertinent permet de ne pas bloquer une transaction (cc qui a un impact sur l'utilisateur). Typiquement, dans un environnement où les transactions en ligne sont impossibles (par exemple un avion), on peut mettre en oeuvre des transactions avec un taux qui n'est pas présent dans la carte mais le nombre de ces transactions peut être limité au moyen du compteur. [0104] On met ensuite en oeuvre les étapes S13 et S14 respectivement analogues aux étapes 505 et 506 de la figure 2. [0105] Ici, le deuxième cryptogramme peut être élaboré à cc stade (c'est-à-dire après la mise en oeuvre de l'étape 514), ou de manière alternative après la mise en oeuvre de l'étape 511 [0106] Sur la figure 4, on a représenté un dispositif électronique 100 de type carte bancaire. Le dispositif électronique 100 comprend notamment un processeur 101 (de manière alternative, plusieurs processeurs peuvent être utilisés), des moyens de communication 102 (comprenant typiquement des contacts selon la norme ISO 7816 et/ou une antenne radiofréquence pour une communication sans contact telle que détaillée dans la norme ISO/ILC 14443 ou NFC/ISO 15693), et une mémoire non volatile 103. [0107] Dans la mémoire non volatile 103, des instructions de programme d'ordinateur INST sont mémorisées. Ces instructions permettent de mettre en oeuvre les procédés tels que décrits ci-avant. En particulier, les instructions INST comprennent des instructions 104 pour vérifier la pertinence d'un taux de conversion au cours d'une transaction, ces instructions forment avec le processeur 101 un module de vérification de la pertinence d'un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique. [0108] Le dispositif électronique comprend en outre une table 105 dans laquelle sont mémorisés des identifiants ou indicateurs de devises et des taux de conversion entre ces devises et la devise associée à la carte. En particulier, dans la table 105, on peut trouver une ou plusieurs informations choisies parmis : - plusieurs taux associés à une même devise et chacun à un type de transaction effectuée sur la carte (paiement, retrait de liquide, paiement différé, remboursement, annulation ...), - les dates de dernière mise à jour des taux ; - des indicateurs de volatilité pour chaque taux ; - les types de chaque taux (fixe, flottant) ; - un ou plusieurs seuils de comparaison pour vérifier si un taux n'est plus pertinent ; et - un ou plusieurs seuils de comparaison pour vérifier si un taux de conversion n'est pas acceptable pour une transaction. 12 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11]