WO2003012703A2 - Procede de securisation de transactions - Google Patents

Procede de securisation de transactions Download PDF

Info

Publication number
WO2003012703A2
WO2003012703A2 PCT/FR2002/002671 FR0202671W WO03012703A2 WO 2003012703 A2 WO2003012703 A2 WO 2003012703A2 FR 0202671 W FR0202671 W FR 0202671W WO 03012703 A2 WO03012703 A2 WO 03012703A2
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
holder
transactions
support
authorization
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2002/002671
Other languages
English (en)
Other versions
WO2003012703A3 (fr
Inventor
Yves Eonnet
Evrard Guelton
Vincent Rigal
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Smart Design
Original Assignee
Smart Design
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Smart Design filed Critical Smart Design
Priority to AU2002341013A priority Critical patent/AU2002341013A1/en
Publication of WO2003012703A2 publication Critical patent/WO2003012703A2/fr
Publication of WO2003012703A3 publication Critical patent/WO2003012703A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means

Definitions

  • the invention relates to a method for securing financial transactions carried out by means of media such as bank cards or the like.
  • this transaction can be described, as regards its payment, by an identification of a card. payment (card number, called PAN, and expiration date), an amount, the identity of the merchant, or even the identity of the buyer. It is also characterized by a set of information on the technical terms of the transaction, contained in fields of computer messages which pass through the financial networks.
  • the merchant sends this transaction to his bank or to an intermediary gateway, such as a remote collection center or a telepayment gateway, in the form of an authorization request.
  • an intermediary gateway such as a remote collection center or a telepayment gateway, in the form of an authorization request. This is sent to the buyer's bank, which has a few seconds to check the status of the card and its limits, before authorizing or rejecting the transaction.
  • the merchant then ships the goods and submits a payment request. This follows the same route as the authorization request, passing through a possible gateway, the merchant's bank, generally the interbank networks and arriving at the buyer's bank.
  • This system can be ineffective in distance selling, while this type of sale is particularly conducive to fraud, because it may be too slow to allow a rejection of the authorization, and therefore cannot prevent the transaction from being concluded and the goods delivered, even when the card holder is warning the system that fraud is in progress.
  • the location of the mobile telephone can only be legally obtained with the agreement of its holder. The latter will only give it to the extent that he sees an interest in it.
  • cases of fraud detectable by the system although financially very penalizing, are little known to the general public who are not aware of it.
  • the document EP-A-0745961 describes a process which only involves special means on the buyer side.
  • This method includes a mechanism for interception of authorization requests by the issuing bank. Upon receipt of these requests, the bank sends a message to the buyer, typically by telephone. The buyer can thus oppose the transaction, leading the bank to send a refusal of authorization to the merchant. According to the embodiments, this refusal is sent on dispute by the buyer or on lack of response on his part within a given period.
  • virtual card In which a particular card number is issued for remote transactions. This eliminates the risk that this number, obtained by a fraudster, will be used for other transactions, since it is only valid for one transaction before being neutralized.
  • this system also has limits in terms of security, since it does not prevent a fraudster from using the real card number for remote transactions.
  • This virtual card system also carries a significant risk of error by the holder, who may in particular forget to request a virtual number and order with his real number.
  • the present invention aims to provide a simple and effective solution to these problems. To this end, it proposes a method of
  • this process consisting in associating, in a protected database, each medium and a means of communication with the holder of the medium , and have an merchant terminal send an authorization or payment request to an authorization or payment server, this request comprising information relating to the transaction and the methods of reading information on the medium used by the buyer, characterized in that it also consists of:
  • this process also consists in asking the holder if he is indeed the author of the transaction in order to possibly put the card in opposition or to stop the shipment of the goods. We can also offer the holder to refuse the transaction and ask the bank to re-credit his account for the amount of the transaction.
  • the invention comprises means only on the side of the buyer and his bank. This avoids the disadvantages due to the constraint of double equipment.
  • the invention is part of the existing electronic payment rules, which it does not require any modification. In particular, it does not imply any intervention on the functioning of the authorization servers of banks: the system according to the invention can be satisfied with receiving, in slight delay, a copy of the authorizations granted by the bank. This point is particularly important, because these servers are often extremely complex machines, the result of dozens of successive modifications, and whose operation is critical: any interruption results in ' an impossibility of payment for the bank's customers.
  • the invention allows an extremely fast and inexpensive implementation, practically without material investment (neither for the bank, nor for the buyer, nor for the merchant) and without computer modification within the bank or at the merchant.
  • the invention does not allow the buyer to block the transaction at the time of the authorization request. However, it allows very rapid opposition, preventing the fraudster from reusing a card. The invention therefore allows a very significant limitation of fraud.
  • two main mechanisms for identifying risky transactions are proposed and can be used separately or in combination.
  • the first mechanism uses information describing the regulatory conditions of the transaction.
  • the second mechanism uses the information describing the technical methods of reading information from the medium used by the wearer.
  • the first is the entry of the confidential code, indicated by field 22 (“reading mode of the acceptance system”, second sub-field “code entry capacity”). Indeed, in current systems, entering the code requires a physical presence of the wearer. Exceptions can be treated using the field "mode of reading the carrier number" (first sub-field of field 22. In fact, there is currently no distance selling system with both input code and track playback.
  • This second mechanism is a very effective filter for remote transactions. However, some of them will remain poorly identified. Mail order purchases paid for using readers available to the holder (CyberComm, GSM double slot) are in this case. To identify them correctly, the second mechanism (entering the code, reading the chip) and the first (distance selling) must be combined.
  • Transactions in the physical presence of the holder without reading the track or the chip and without control of the confidential code may be treated either as risky transactions (if for example they come from countries or merchants where the level of control of the identity of the bearer and mechanisms such as the hologram are deficient), or as secure transactions. In general, it will be beneficial to distinguish, in the process of selecting risky transactions, the countries of origin of the transactions.
  • the virtual number (therefore the virtual number, recognizable by the value of its first digits). This can also be done at the bank level.
  • the virtual number may have been replaced by the real number, but the mention of the origin (for example the machine having made this substitution) makes it possible to identify that the original transaction used a virtual number.
  • alerts are sent to the card holder, or more generally to a person with the right to control over the expenses made with this card. It can be the bearer himself, the father or the mother in the case of a minor child, a purchasing manager in the case of acquisition cards for companies. This person is designated in the following as the holder.
  • this communication device is a portable telephone, for example a telephone with the GSM standard or a similar standard.
  • messaging devices pagers
  • communicating personal assistants are used.
  • a landline telephone is used, for example the holder's personal telephone or business telephone, or a fax machine.
  • electronic mail is used, the communication device then being the holder's computer.
  • the constitution of a correspondence list between payment card numbers and telephone numbers of the holder is an essential element of the process according to the invention. It must be avoided that a fraudster can build or modify such a list, for example by assigning a valid card number his own telephone number. This is why this list is made up by the banks of the holders.
  • Each line in the list is guaranteed by the bank. This guarantee can take several forms: digital certificate for each card, using a public key algorithm and a bank key; protected deposit in the confirmation site; deposit of the list and global protection by a certificate with public key of the site.
  • the bank certifies the link between a card number, represented by a subscriber number, and the mobile phone number of the buyer (or of the person who is responsible for controlling his purchases: supervisor or parent for example).
  • the list is made up and guaranteed by a telephone operator (mobile or fixed), which has the contact details of its subscribers.
  • the card number, PAN is made up of three fields: UN (bank identification), AAN (card identifier) and a CC check digit.
  • UN bank identification
  • AAN card identifier
  • CC check digit a CC check digit.
  • UN bank identification
  • AAN card identifier
  • CC check digit a CC check digit.
  • f without collision for example the RSA algorithm, whose private key has been destroyed.
  • This function is applied to the PAN and the result is concatenated with the UN field to form a subscriber number.
  • an identifier such as for example the telephone number of the holder's mobile telephone.
  • we can form a couple comprising the subscriber number and the telephone call number and apply to the two elements of this couple a private encryption key from the bank, to generate a certificate.
  • the preferred alert mode is the mobile phone message.
  • This message can be written or voice. It is advantageously in accordance with the GSM standard (SMS message, MMS, WAP push).
  • SMS message, MMS, WAP push A variant is the message written on a messaging device.
  • Another variant is, for carriers who have such a service, the use of instant messaging, which will automatically choose the mode of transport of the message best suited to the circumstances.
  • This alert mode can, for certain cardholders, be replaced by a message on a landline telephone, the personal number or the professional number of the card holder.
  • We can provide voice messages, but also written messages (which will be transformed into voice messages, or delivered in written form on the screens of phones that have this option).
  • This variant will benefit from future intelligent mailbox services, capable of distinguishing members of the same family so as to deliver messages only to the right recipients.
  • the alert message includes the main information available allowing the bearer to identify the transaction.
  • the form of the message is advantageously adapted to the alert mode and to the communication channel.
  • An example of such a message, designed for the SMS alert mode on GSM is as follows:
  • the telephone number indicated allows customer support. We will assist him to verify that he dispute the transaction, and that it is not an error on his part. He will eventually be advised to put his card in opposition.
  • the preferred alert mode is advantageously supplemented by one or more emergency alert modes, to compensate for cases of failure (change of telephone number, mobile phone off or outside the coverage area, network failure, etc.).
  • emergency alert modes we will find another telephone number (landline or mobile), an electronic message, a fax machine.
  • An example of a rescue message is as follows:
  • a transaction made with a virtual card number may not be sufficiently secure, for example in the case where this number can be used several times.
  • a variant then consists in sending an alert which mentions the virtual card.
  • An example of such a message for the SMS channel is as follows:
  • the method according to one invention provides several modes of response by the carrier.
  • the first response mode is SMS response or, more closely, the use of a two-way messaging device.
  • the message includes the necessary information (how, or even to whom to respond to confirm or reject the transaction). This answer should be as simple as possible. It will advantageously hold on a single letter (in the example above, ⁇ A 'or ⁇ S'). It must take into account predictive input mechanisms (on some mobile phones, R 'is thus automatically translated into ⁇ S').
  • Another response mode is voice response, to a number indicated in the message or made available to the carrier by other means.
  • Some telephones allow, for simplicity, the call to a number mentioned in the message and recognized automatically.
  • the third response mode is the written response, particularly for alerts sent by email or fax.
  • transmitters / telephone numbers are advantageously used cyclically.
  • the system has a sufficient number of transmitters / telephone numbers to manage the remote purchases of the vast majority of carriers for a sufficient period of time.
  • transmitters can be physical transmitters or virtual transmitters.
  • MO Mobile Originated messages
  • MO Mobile Originated messages
  • a rejection of a transaction by the holder can lead to the implementation of the reimbursement mechanisms provided by the banking systems.
  • the consequences of fraud must be limited.
  • the method according to the invention comprises several modes of limiting fraud.
  • a first method consists of identifying the merchant whose sale is disputed and alerting him immediately. If the alert was issued quickly enough, and if the holder responded without long delay, the merchant has the option of not sending the goods. He can also deliver it while keeping it under surveillance in order to catch fraudsters.
  • the merchant is known thanks to the information appearing in electronic messages which are merchant identification information (for example fields 42 and 43 of ISO 8583), but also the terminal number (field 41).
  • merchant identification information for example fields 42 and 43 of ISO 8583
  • terminal number for example fields 42 and 43 of ISO 8583
  • a second mode of limiting fraud complementary to the first, the future use of the card is limited. In traditional methods, this takes the form of opposing, then destroying the card. This method is well suited to classic cases of card duplication fraud, but it is cumbersome and costly in cases of fraud using the card number.
  • the second method of limiting fraud avoids this drawback and consists in refusing all authorizations containing the card number in question, since it may be a sale in the absence of the physical card.
  • the authorization server is used. As soon as an authorization request including the card number is detected, it is checked whether it is a distance sale using one of the identification methods described above. If so, the authorization request is refused, and an alert is sent on the one hand to the holder to verify that he is not the author of the transaction, on the other hand to the bank to report the continuation of the fraud.
  • a blocking algorithm is implemented in the authorization server of the bank.
  • a diversion mechanism is often used in authorization servers. This mechanism consults a list of card numbers integrated into the server. Each authorization request for a card that is part of the list is diverted to a second machine, which may or may not block the request. This second embodiment makes it possible to set up the blocking mechanism without software modification on most authorization servers.
  • there is a dedicated server in the interbank network It is he who can detect authorization requests, and collect those which must be blocked.
  • This method of limiting fraud will advantageously be supplemented by intervention at the level of the payment server. Indeed, certain transactions are not the subject of an authorization request, and the merchant also has the possibility of requesting a payment even when the authorization to make the transaction has been refused. To do this, we include in the payment algorithms a systematic rejection of any remote payment made with a blocked card. You can also use a payment card of the "first franc authorization request" type.
  • the holder who wishes to make a purchase by mail informs his bank in advance.
  • the latter can then lift the blocking mechanism for a limited period (for example 2 hours), or for certain merchants.
  • a message is sent to the bearer in the event of an authorization request if the card has not been unlocked, in order to allow him to repair a possible oversight.
  • the holder who wishes to make a purchase by correspondence will first seek, for example on the website of his bank, a temporary card number. It uses this number, called virtual number, instead of the real number.
  • the authorization request is thus directed to a particular server, called a virtual card server, which replaces the virtual number with the real number, checks that the use of the first conforms to the rules which limit its use, then retransmits the authorization request for acceptance to the bank's server.
  • the authorization request arrives at the bank with the real number, as well as information that shows that it was originally issued with a virtual number. This neutralizes the locking mechanism.
  • an alert message is sent to the bearer even if the transaction has been blocked. It indicates the reason for the rejection, and the possibility of using a virtual number.
  • An example of such a message for the SMS channel is as follows:
  • This virtual card server can be the recipient of all authorization requests from the bank, or can only process the numbers corresponding to virtual cards.
  • the virtual card server is also the network server provided in the third embodiment of the fraud limitation mode.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procédé de sécurisation de transactions effectuées au moyen de supports tels que des cartes bancaires et analogues, ce procédé consistant à faire envoyer par un marchand une demande d'autorisation ou de paiement à un serveur, cette demande comportant des informations relatives à la transaction et aux modalités de lecture d'informations sur le support utilisé, le procédé consistant également : à associer à chaque support un moyen de communication avec le titulaire du support, à utiliser les informations incluses dans la demande d'autorisation ou de paiement pour determiner les transactions a risque, et à envoyer au titulaire un message lui signalant une transaction à risque, apres autorisation de la transaction par la banque.

Description

Procédé de sécurisation de transactions
L'invention concerne un procédé de sécurisation de transactions financières effectuées au moyen de supports tels que des cartes bancaires ou analogues.
Dans la technique actuelle, lorsqu'un marchand et un acheteur ont défini une transaction, par exemple en vente à distance ou via le réseau internet, cette transaction peut être décrite, en ce qui concerne son paiement, par une identification d'une carte de paiement (numéro de carte, appelé PAN, et date d'expiration), un montant, l'identité du marchand, voire l'identité de l'acheteur. Elle est également caractérisée par un ensemble d'informations sur les modalités techniques de la transaction, contenues dans des champs des messages informatiques qui transitent dans les réseaux financiers .
Généralement, le marchand envoie cette transaction à sa banque ou à une passerelle intermédiaire, comme un centre de télécollecte ou une passerelle de télépaiement, sous la forme d'une demande d'autorisation. Celle-ci est dirigée vers la banque de l'acheteur qui dispose de quelques secondes pour vérifier le statut de la carte et ses plafonds, avant d'autoriser ou de rejeter la transaction.
Le marchand expédie ensuite la marchandise et présente une demande de paiement. Celle-ci suit le même trajet que la demande d'autorisation, passant par une éventuelle passerelle, la banque du marchand, généralement les réseaux interbancaires et arrivant à la banque de l'acheteur.
La plupart des systèmes de transactions sécurisées demandent un double équipement, tant du marchand que de l'acheteur, nécessaire pour sécuriser la transaction. Un exemple est celui du système de cartes à puce, généralisé en France en 1993, avec ses cartes et ses terminaux de paiement, qui utilisent un lecteur de cartes à puce sur le micro-ordinateur de l'acheteur en ligne, ainsi qu'une passerelle de paiement sécurisé du coté du marchand. Les systèmes utilisant des téléphones portables à double fente imposent la modification du téléphone de l'acheteur, ainsi qu'une passerelle de paiement spécifique coté marchand.
Cette contrainte de double équipement rend le déploiement de telles solutions extrêmement difficile. En effet, le marchand n'a intérêt à investir que si un nombre suffisant de ses clients sont équipés, et réciproquement. De plus, l'acheteur n'est en sécurité que- quand tous les marchands sont équipés, faute de quoi un fraudeur tentera des paiements auprès des vendeurs non sécurisés. Les documents EP-A-0745961 et FR-A-2 792 143 décrivent des systèmes de sécurisation qui ne présentent pas ces deux défauts, car ils ne nécessitent des moyens particuliers que du côté acheteur ou du côté client. Ce procédé décrit par le document FR-A-2 792 143 comprend l'émission de demandes d'autorisation par les marchands. Quand une telle demande est reçue, le téléphone portable de l'acheteur est localisé, on compare les localisations du téléphone et du point de vente, et on demande confirmation à l'acheteur si les deux localisations sont différentes. Ce système peut être inopérant en vente à distance, alors que ce type de vente est particulièrement propice à la fraude, car il risque d'être trop lent pour permettre un rejet de l'autorisation, et donc ne peut empêcher la transaction d'être conclue et la marchandise livrée, alors même que le titulaire de la carte est en train de prévenir le système qu'une fraude est en cours. De plus, on ne peut légalement obtenir la localisation du téléphone portable qu'avec l'accord de son titulaire. Celui-ci ne le donnera que dans la mesure où il y voit un intérêt. Or les cas de fraudes détectables par le système, quoique financièrement très pénalisants, sont peu connus du grand public qui n'y est pas sensibilisé.
Le document EP-A-0745961 décrit un procédé qui ne fait intervenir de moyens particuliers que coté acheteur. Ce procédé comprend un mécanisme d'interception des demandes d'autorisation par la banque émettrice. A la réception de ces demandes, la banque envoie un message vers l'acheteur, typiquement par un moyen téléphonique. L'acheteur peut ainsi s'opposer à la transaction, conduisant la banque à envoyer un refus d'autorisation vers le marchand. Selon les modes de réalisation, ce refus est envoyé sur contestation par l'acheteur ou sur absence de réponse de sa part dans un délai donné.
Ce système est en fait inopérant. En effet, les réseaux monetique comporte un règle essentielle, qui impose aux serveurs d'autorisation un temps de réponse très bref (de quelques secondes) . Il est en pratique impossible dans un tel laps de temps d'envoyer un message au client et d'obtenir sa réponse et le système décrit par le document EP-A- 0745961 produirait donc un rejet systématique. Il ne pourrait fonctionner pratiquement que si cette règle était modifiée. Or une telle modification est très difficile à envisager, pour des raisons techniques (elle est incluse dans l'ensemble des réseaux bancaires et dans l'ensemble des serveurs d'autorisation du monde) et pour des raisons fonctionnelles (cette règle est essentielle pour la fluidité du trafic monetique et pour la rapidité des passages des clients aux caisses) .
On connaît également un système de sécurisation des transactions appelé carte virtuelle, dans lequel un numéro de carte particulier est délivré pour les transactions à distance. Ceci élimine le risque que ce numéro, obtenu par un fraudeur, soit utilisé pour d'autres transactions, car il n'est valable que pour une seule transaction avant d'être neutralisé.
Mais ce système présente lui aussi des limites sur le plan de la sécurité, car il n'empêche pas un fraudeur d'utiliser le numéro de carte réel pour des transactions à distance. On pourrait prévoir d'interdire systématiquement l'usage de ce numéro en vente à distance, mais cette solution apparaît très pénalisante tant pour les banques (elle apparaît comme une limitation au commerce) que pour les porteurs qui, en pratique, ne pourraient plus utiliser un paiement par carte sur les sites de vente à distance traditionnels, car la fourniture des numéros de carte virtuels n'est commode que sur un réseau du type internet .
Ce système de carte virtuelle comporte également un risque important d'erreur par le porteur, qui peut notamment oublier de demander un numéro virtuel et commander avec son numéro réel.
La présente invention a pour but d'apporter une solution simple et efficace à ces problèmes. Elle propose à cet effet un procédé de
sécurisation de transactions effectuées entre des marchands et des acheteurs au moyen de supports d'informations tels que des cartes bancaires et analogues, ce procédé consistant à associer, dans une banque de données protégée, chaque support et un moyen de communication avec le titulaire du support, et à faire envoyer par un terminal marchand une demande d'autorisation ou de paiement à un serveur d'autorisation ou de paiement, cette demande comportant des informations relatives à la transaction et aux modalités de lecture d'informations sur le support utilisé par l'acheteur, caractérisé en ce qu'il consiste également :
- à utiliser lesdites informations incluses dans la demande d'autorisation de transaction ou de paiement pour déterminer si la transaction est à risque ou non, - si oui, à envoyer au titulaire du support, par le moyen de communication, un message d'alerte lui signalant la transaction à risque, une fois l'autorisation accordée par le banque. Avantageusement, ce procédé consiste également à demander au titulaire s'il est bien l'auteur de la transaction afin éventuellement de mettre la carte en opposition ou de stopper l'expédition de la marchandise. On peut aussi proposer au titulaire de refuser la transaction et de demander à la banque de recréditer son compte du montant de la transaction.
L'invention ne comporte de moyens que du côté de l'acheteur et de sa banque. On évite ainsi les inconvénients dus à la contrainte de double équipement. L'invention s'inscrit dans le cadre des règles monétiques existantes, dont elle ne suppose aucune modification. En particulier, elle ne suppose aucune intervention sur le fonctionnement des serveurs d'autorisation des banques : le système selon l'invention peut se contenter de recevoir, en léger différé, copie des autorisations accordées par la banque. Ce point est particulièrement important, car ces serveurs sont souvent des machines extrêmement complexes, résultats de dizaines de modifications successives, et dont le fonctionnement est critique : toute interruption se traduit par' une impossibilité de paiement pour les clients de la banque. D'une manière générale, l'invention permet une mise en œuvre extrêmement rapide et peu coûteuse, pratiquement sans investissement matériel (ni pour la banque, ni pour l'acheteur, ni pour le marchand) et sans modification informatique au sein de la banque ou chez le marchand.
En contrepartie de ces avantages, l'invention ne permet pas à l'acheteur de bloquer la transaction au moment de la demande d'autorisation. En revanche, elle permet une mise en opposition très rapide, interdisant au fraudeur de réutiliser une carte. L'invention permet donc une limitation très importante de la fraude .
Selon une autre caractéristique de l'invention, deux mécanismes principaux d'identification des transactions à risque sont proposés et peuvent être utilisés séparément ou en combinaison.
Le premier mécanisme utilise les informations décrivant les conditions réglementaires de la transaction.
Les messages monétiques contiennent un ensemble d'informations utilisables pour ce faire, mais dont aucune n'est suffisante. Le champ 25 des demandes d'autorisation (norme ISO 8583, « conditions de la transaction au point de service ») donne normalement l'information de vente à distance. En pratique, il n'est pas toujours renseigné de manière fiable, notamment en France. Il doit donc être complété par le champ 59 (données nationales) type 200
(environnement technique et réglementaire) pour les transactions françaises au moins. Si ce champ comporte une valeur entre 20 et 23, entre 30 et 33 ou vaut 35, il s'agit d'une vente à distance non sécurisée. S'il vaut 24 ou 34, on se reportera au champ 59 type 407, qui donne des indications sur le niveau de sécurité.
Dans le cas des messages venant des réseaux VISA, la procédure est analogue. Dans le cas des messages venant des réseaux
Europay/Mastercard, il convient également de considérer le champ 25, car le seul champ 59 n'est pas renseigné de manière fiable.
Ce procédé indique avec une bonne probabilité les transactions en vente à distance, et de manière fiable celles qui sont sécurisées. Mais il n'est pas totalement suffisant, car certaines transactions peuvent avoir été libellées comme PDP (Présence Du Porteur) par erreur, voire frauduleusement. Le second mécanisme utilise les informations décrivant les modalités techniques de lecture des informations du support utilisé par le porteur. La première est la saisie du code confidentiel, indiqué par le champ 22 (« mode de lecture du système d'acceptation », second sous-champ « capacité de saisie du code ») . En effet, dans les systèmes courants, la saisie du code impose une présence physique du porteur. Les exceptions peuvent être traitées en utilisant le champ « mode de lecture du numéro de porteur » (premier sous-champ du champ 22. En effet, il n'y a pas aujourd'hui de système de vente à distance avec à la fois saisie de code et lecture de la piste.
Ce second mécanisme est un filtre très performant des transactions à distance. Toutefois, certaines d'entre elles resteront mal identifiées. Les achats par correspondance payés en utilisant des lecteurs à disposition du porteur (CyberComm, GSM double fente) sont dans ce cas. Pour les identifier correctement, il faut coupler le second mécanisme (saisie du code, lecture de la puce) et le premier (vente à distance) .
Les transactions en présence physique du porteur sans lecture de la piste ou de la puce et sans contrôle du code confidentiel pourront être traitées soit comme des transactions à risque (si par exemple elles viennent de pays ou de marchands où le niveau de contrôle de l'identité du porteur et des mécanismes comme l'hologramme sont déficients), soit comme des transactions sûres. En général, on aura intérêt à distinguer, dans le procédé de sélection des transactions à risque, les pays d'origine des transactions .
Enfin, il sera utile d'identifier les transactions issues d'une carte virtuelle dynamique, et de les exclure des mécanismes d'alerte. Ceci peut se faire soit directement, sur le • réseau ou sur le serveur de carte virtuelle, qui disposent tous deux du numéro avec lequel la transaction a été faite
(donc le numéro virtuel, reconnaissable par la valeur de ses premiers chiffres) . Ceci peut également se faire au niveau de la banque. Dans ce cas, le numéro virtuel peut avoir été remplacé par le numéro réel, mais la mention de l'origine (par exemple la machine ayant fait cette substitution) permet d'identifier que la transaction originelle utilisait un numéro virtuel .
Ces mécanismes de détection s'appliquent lorsque la transaction a fait l'objet d'une demande d'autorisation, ce qui est le cas de la majorité des transactions en vente à distance. En revanche, certaines de ces transactions, soit parce qu'elles sont de montant trop 'faible, s.oit plus généralement parce que le marchand n'a pas souhaité faire une telle demande, passent directement au stade du paiement. Dans ce cas, le procédé ici décrit utilise les messages qui parviennent au gestionnaire de paiement de la banque émettrice, qui contiennent essentiellement les mêmes informations que celles utilisées en cas de demande d'autorisation. Bien évidemment, on prévoit de rapprocher les demandes d'autorisation des demandes de paiement, afin qu'une même transaction ne fasse pas l'objet de deux alertes, ce rapprochement étant effectué au moyen des informations de montant et de devise, de pays, de date et, quand ils sont disponibles, de numéro d'autorisation, de marchand, de terminal, etc..
En cas de transactions à risque, les alertes sont envoyées au porteur de la carte, ou plus généralement à une personne ayant un droit de contrôle sur les dépenses faites avec cette carte. Ce peut être le porteur lui-même, le père ou la mère dans le cas d'un enfant mineur, un chef de service achat dans le cas de cartes d'achat pour les entreprises . Cette personne est désignée dans la suite comme le titulaire.
Les alertes sont envoyées sur un appareil de communication accessible au titulaire. Dans un mode préféré de réalisation de l'invention, cet appareil de communication est un téléphone portable, par exemple un téléphone à la norme GSM ou à une norme similaire. Dans une variante, on utilise des appareils de messagerie (pagers) ou des assistants personnels communicants. Dans une autre variante, on utilise un téléphone fixe, par exemple le téléphone personnel ou le téléphone professionnel du titulaire, ou un télécopieur. Dans une troisième variante, on utilise le courrier électronique, l'appareil de communication étant alors l'ordinateur du titulaire. Dans ce qui suit, on ne décrira que l'usage d'un téléphone portable, à titre d'exemple, en référence au dessin annexé qui représente schématiquement les principales étapes du procédé selon l'invention.
La constitution d'une liste de correspondance entre numéros de cartes de paiement et numéros de téléphone du titulaire (respectivement de son numéro de messagerie, de son adresse électronique pour les assistants personnels et les courriers électroniques) est un élément essentiel du procédé selon l'invention. Il faut en effet éviter qu'un fraudeur puisse constituer ou modifier une telle liste, par exemple en attribuant à un numéro de carte valide son propre numéro de téléphone . C ' est pourquoi cette liste est constituée par les banques des porteurs. Chaque ligne de la liste fait l'objet d'une garantie par la banque. Cette garantie peut prendre plusieurs formes : certificat numérique pour chaque carte, utilisant un algorithme à clef publique et une clef de la banque; dépôt protégé dans le site de confirmation; dépôt de la liste et protection globale par un certificat à clef publique du site. La banque certifie le lien entre un numéro de carte, représenté par un numéro d'abonné, et le numéro de téléphone portable de l'acheteur (ou de la personne qui est chargée de contrôler ses achats : supérieur hiérarchique ou parent par exemple) .
Dans une variante, la liste est constituée et garantie par un opérateur de téléphonie (mobile ou fixe), qui dispose des coordonnées de ses abonnés.
Pour des raisons de sécurité, on préfère stocker les numéros de cartes sous ' une forme cryptée, avantageusement avec un algorithme de cryptage irréversible. Dans un exemple de fonction de conversion, le numéro de carte, le PAN, est constitué de trois champs : UN (identification de la banque) , AAN (identifiant de la carte) et un chiffre de contrôle CC. On choisit une fonction f irréversible sans collision (par exemple l'algorithme RSA, dont la clef privée a été détruite) . Cette fonction est appliquée au PAN et le résultat est concaténé avec le champ UN pour former un numéro d'abonné. Ensuite, on peut procéder à une certification du numéro d'abonné par sa correspondance avec un identifiant, tel par exemple que le numéro d'appel du téléphone mobile du titulaire. Pour cela, on peut former un couple comportant le numéro d'abonné et le numéro d'appel du téléphone et appliquer aux deux éléments de ce couple une clé de cryptage privée de la banque, pour générer un certificat.
Le mode d'alerte préféré est le message sur téléphone mobile. Ce message peut être écrit ou vocal. Il est avantageusement conforme à la norme GSM (message SMS, MMS, WAP push) . Une variante est le message écrit sur appareil de messagerie. Une autre variante est, pour les porteurs qui disposent d'un tel service, l'utilisation d'une messagerie instantanée, qui choisira automatiquement- le mode de transport du message le mieux adapté aux circonstances .
Ce mode d'alerte peut, pour certains porteurs, être remplacé par un message sur téléphone fixe, au numéro personnel ou au numéro professionnel du porteur de carte. On peut prévoir des messages vocaux, mais aussi des messages écrits (qui seront transformés en messages vocaux, ou livrés sous forme écrite sur les écrans des téléphones qui disposent de cette option) . Cette variante bénéficiera des futurs services de boites vocales intelligentes, capables de distinguer les membres d'une même famille pour ne livrer les messages qu'aux bons destinataires.
Le message d'alerte comprend les principales informations disponibles permettant au porteur d'identifier la transaction. La forme du message est avantageusement adaptée au mode d'alerte et au canal de communication. Un exemple d'un tel message, conçu pour le mode d'alerte SMS sur GSM est le suivant :
Alerte sécurité paiement Achat a distance 347F 10/03 carte perso. En cas de fraude tel au '0800 123456' .
Le numéro de téléphone indiqué permet une prise en charge du client. On l'assistera pour vérifier qu'il conteste bien la transaction, et qu'il ne s'agit pas d'une erreur de sa part. On lui conseillera éventuellement la mise en opposition de sa carte.
Le mode d'alerte préféré est avantageusement complété par un ou des modes d'alerte de secours, pour pallier les cas de défaillance (changement de numéro de téléphone, portable éteint ou hors zone de couverture, défaillance du réseau...) . Parmi ces modes de secours on trouvera un autre numéro de téléphone (fixe ou mobile) , un message électronique, un télécopieur. Un exemple d'un message de secours est le suivant :
De : service XXX
Objet : achat par carte bancaire non sécurisé Date : ....
Mr/Mme/Mlle
Nous vous avons alerté, sur votre téléphone portable (numéro 06 XXXX XXXX) , après avoir détecté une transaction à distance non sécurisée d'un montant de 347FF faite avec votre carte professionnelle le 10/03/01 (numéro de transaction xxxxxxxxxxxx, abonné yyyyyyyyyy) . N'ayant pas reçu de réponse de votre part, nous nous permettons de vous faire parvenir le présent message.
S'il s'agit d'une transaction frauduleuse, nous vous prions de renvoyer le présent message en mentionnant comme objet 'rejet', puis de remplir le formulaire joint et de l'envoyer, signé, à notre adresse. Ceci nous permettra de traiter votre rejet avec votre banque, et de demander l'ouverture d'une enquête.
Si vous souhaitez faire opposition à votre carte, appelez le 0800 123456. Si votre numéro de GSM est erroné, veuillez vous connecter au site http://www.mabanque.fr et le modifier.
Vous pourrez disposer d'une assistance téléphonique au 0800 123456 (2FF par minute)
Dans le cas d'une transaction faite par un porteur abonné à un service de carte virtuelle et ayant utilisé son numéro de carte réel, on aura avantage à utiliser un message mentionnant cette possibilité et ses avantages. Cette variante est particulièrement avantageuse si la transaction se prête bien à cette technologie, par exemple si elle est identifiée comme une transaction sur Internet (par exemple si le champ 59 type 200 vaut 24) .
Une transaction faite avec un numéro de carte virtuelle peut ne pas être suffisamment sûre, par exemple dans le cas où ce numéro est utilisable plusieurs fois. Une variante consiste alors à envoyer une alerte qui mentionne la carte virtuelle. Un exemple d'un tel message pour le canal SMS est le suivant :
Alerte sécurité paiement Achat internet 347F 10/03 carte perso virtuelle. Pour une fraude aller sur www.mabanque.fr ou tel « 0800 123456 » Le procédé selon 1 ' invention prévoit plusieurs modes de réponse par le porteur. Le premier mode de réponse est la réponse SMS ou, de manière proche, l'utilisation d'un appareil de messagerie à deux voies. Le message comporte les indications nécessaires (comment, voire vers qui répondre pour confirmer ou rejeter la transaction) . Cette réponse doit être aussi simple que possible. Elle tiendra avantageusement sur une seule lettre (dans l'exemple ci-dessus, ΛA' ou λS'). Elle doit tenir compte des mécanismes de saisie prédictive (sur certains téléphones portables, R' est ainsi automatiquement traduit en Λ S' ) .
Un autre mode de réponse est la réponse vocale, à un numéro indiqué dans le message ou mis à disposition du porteur par d'autres moyens. Certains téléphones permettent, dans un but de simplicité, l'appel à un numéro mentionné dans le message et reconnu automatiquement.
Le troisième mode de réponse est la réponse écrite, notamment pour les alertes envoyées par courrier électronique ou par télécopieur.
Dans tous les modes de réponse, il faut pouvoir identifier la transaction concernée. En effet, le porteur aura peut-être reçu plusieurs alertes, dont seulement une ou un petit nombre doit être rejetée. Le procédé permet au porteur, en particulier dans les modes de réponse vocaux ou écrits, de donner des précisions sur le transaction pertinente. On prévoit également, en option, de gérer plusieurs émetteurs des messages ou plusieurs numéros de téléphone d'assistance, chaque alerte étant envoyée par un émetteur différent ou mentionnant un numéro d'assistance différent, qui recevra seulement la réponse correspondant à l'alerte qu'il a émise.
Ces émetteurs/numéros de téléphone sont avantageusement utilisés de manière cyclique. Le système dispose d'un nombre suffisant d' émetteurs/numéros de téléphone pour gérer les achats à distance de la grande majorité des porteurs pendant une durée suffisante. Ces émetteurs peuvent être des émetteurs physiques ou des émetteurs virtuels. Dans le cas des messages GSM, on trouvera naturellement le premier cas si les messages sont envoyés par radio (messages dits MO, Mobile Originated) . On dispose alors d'une batterie de modems GSM, chacun identifié par un numéro de téléphone, qui sont gérés de manière cyclique pour chaque titulaire.
Il est avantageux également de prévoir un mode de réponse authentifié par l'acheteur. On peut pour cela demander à l'acheteur, quand il confirme ou quand il conteste la transaction, de saisir un code confidentiel. Ce code peut avantageusement être inscrit dans la carte ou le module SIM inséré dans son téléphone portable. On peut également demander à l'acheteur de répondre via un serveur téléphonique, auquel il indiquera • la transaction concernée et donnera son code .
Un rejet d'une transaction par le porteur peut conduire à la mise en œuvre des mécanismes de remboursement prévus par les systèmes bancaires . Par ailleurs, il faut limiter les conséquences de la fraude. Le procédé selon l'invention comporte plusieurs modes de limitation de la fraude. Un premier mode consiste à identifier le marchand dont la vente est contestée et à l'alerter immédiatement. Si l'alerte a été émise suffisamment rapidement, et si le titulaire a répondu sans délai long, le marchand a la possibilité de ne pas expédier la marchandise. Il pourra également la livrer tout en la maintenant sous surveillance afin de prendre les fraudeurs sur le fait .
Dans ce mode de limitation de la fraude, le marchand est connu grâce aux informations figurant dans les messages monétiques qui sont des informations d'identification du marchand (par exemple les champs 42 et 43 de la norme ISO 8583) , mais également le numéro de terminal (champ 41) . On dispose d'une base de données des marchands (ou au moins de certains d'entre eux, dont l'importance dans l'ensemble des ventes à distance est significative), de leurs identifiants, ainsi que des adresses auxquelles envoyer une alerte. Un avantage de ce mode de limitation de la fraude est qu'il ne nécessite aucune modification du système monetique ou de l'informatique des marchands.
Dans un second mode de limitation de la fraude, complémentaire du premier, on limite l'usage futur de la carte. Dans les procédés traditionnels, ceci prend la forme d'une mise en opposition, puis d'une destruction de la carte. Cette méthode est bien adaptée aux cas classiques de fraude par duplication de carte, mais elle est lourde et coûteuse dans les cas de fraude par utilisation du numéro de carte. Le second mode de limitation de la fraude évite cet inconvénient et consiste à refuser toutes les autorisations comportant le numéro de carte en cause, dès lors qu'il peut s'agir d'une vente en l'absence de la carte physique.
Dans ce mode de limitation de la fraude, on utilise le serveur d'autorisation. Dès qu'une demande d'autorisation comportant le numéro de carte est détectée, on vérifie s'il s'agit d'une vente à distance en utilisant l'un des modes d'identification décrits plus haut. Dans l'affirmative, la demande d'autorisation est refusée, et une alerte est envoyée d'une part au titulaire pour vérifier qu'il n'est pas l'auteur de la transaction, d'autre part à la banque pour signaler la poursuite de la fraude.
Dans une première réalisation de ce mode de limitation de la fraude, un algorithme de blocage est implanté dans le serveur d'autorisation de la banque. Dans une seconde réalisation, on utilise un mécanisme de déroutement souvent présent dans les serveurs d'autorisation. Ce mécanisme consulte un liste de numéros de cartes intégrée au serveur. Chaque demande d'autorisation concernant une carte qui fait partie de la liste est déroutée vers une seconde machine, qui peut bloquer ou non la demande. Cette seconde réalisation permet de mettre en place le mécanisme de blocage sans modification logicielle sur la plupart des serveurs d'autorisation. Dans une troisième réalisation, on dispose d'un serveur dédié dans le réseau interbancaire. C'est lui qui peut détecter les demandes d'autorisation, et prélever celles qui doivent être bloquées.
Ce mode de limitation de la fraude sera avantageusement complété par une intervention au niveau du serveur de paiement. En effet, certaines transactions ne font pas l'objet d'une demande d'autorisation, et le marchand a par ailleurs la possibilité de demander un paiement alors même que l'autorisation de faire la transaction lui a été refusée. Pour ce faire, on inclut dans les algorithmes de paiement un rejet systématique de tout paiement à distance fait avec une carte bloquée. On peut également utiliser une carte de paiement de type "demande d'autorisation au premier franc".
Ceci suppose que le porteur ait formellement indiqué sa volonté de rejeter toute transaction à distance avec son numéro de carte, pour des raisons légales. On pourra avantageusement compléter le rejet systématique par le serveur de paiement par une diffusion d'une liste de numéros de carte bloqués à destination des vendeurs à distance, analogue à une liste de cartes en opposition. Dans ces trois réalisations, on peut avantageusement prévoir un mécanisme temporaire d'achat avec un numéro de carte normalement bloqué. Ce mécanisme peut être réalisé de deux manières.
Dans la première réalisation du mécanisme de déblocage temporaire, le porteur qui souhaite faire un achat par correspondance prévient au préalable sa banque. Celle-ci peut alors lever le mécanisme de blocage pendant une durée limitée (par exemple 2 heures), ou pour certains marchands. Dans cette réalisation, un message est envoyé au porteur en cas de demande d'autorisation si la carte n'a pas été débloquée, afin de lui permettre de réparer un éventuel oubli.
Dans la seconde réalisation du mécanisme de blocage temporaire, le porteur qui souhaite faire un achat par correspondance va au préalable chercher, par exemple sur le site internet de sa banque, un numéro de carte temporaire. Il utilise ce numéro, appelé numéro virtuel, en lieu et place du numéro réel. La demande d'autorisation se voit ainsi dirigée vers un serveur particulier, dit serveur de cartes virtuelles, qui remplace le numéro virtuel par le numéro réel, contrôle que l'usage du premier est conforme aux règles qui en limitent l'usage, puis retransmet la demande d'autorisation pour acceptation au serveur de la banque. La demande d'autorisation arrive à la banque munie du numéro réel, ainsi que d'une information qui montre qu'elle a été originellement émise avec un numéro virtuel. Ceci permet de neutraliser le mécanisme de blocage.
Dans cette réalisation, un message d'alerte est envoyé au porteur même si la transaction a été bloquée. Il indique le motif du rejet, et la possibilité d'utiliser un numéro virtuel. Un exemple d'un tel message pour le canal SMS est le suivant :
Alerte sécurité paiement Achat a distance 347F 10/03 carte perso refusé. Recommencez l'achat avec numéro virtuel
Ce serveur de cartes virtuelles peut être destinataire de toutes les demandes d'autorisation de la banque, ou ne traiter que les numéros correspondant à des cartes virtuelles. Dans le premier cas, on peut avantageusement prévoir que le serveur de cartes virtuelles est également le serveur de réseau prévu dans La troisième réalisation du mode de limitation de fraude.

Claims

REVENDICATIONS
1 - Procédé de sécurisation de transactions effectuées entre des marchands et des acheteurs au moyen de supports d'informations tels que des cartes bancaires et analogues, ce procédé consistant à associer, dans une banque de données protégée, chaque support et un moyen de communication avec le titulaire du support, ce moyen de communication comprenant un téléphone fixe ou mobile ou un appareil analogue, et à faire envoyer par un terminal marchand une demande d'autorisation de transaction ou de paiement à un serveur d'autorisation ou de paiement, cette demande comportant des informations relatives à la transaction et aux modalités de lecture d'informations sur le support utilisé par 1.' acheteur, caractérisé en ce qu'il consiste également :
- . à utiliser lesdites informations incluses dans la demande d'autorisation de transaction ou de paiement pour déterminer si la transaction est à risque ou non,
- si oui, à envoyer au titulaire du support, par le moyen de communication, un message d'alerte lui signalant la transaction à risque, une fois l'autorisation accordée par le banque.
2 - Procédé selon la revendication 1, caractérisé en ce qu'on propose au titulaire du support de mettre le support en opposition.
3 - Procédé selon la revendication 1, caractérisé en ce qu'on propose au titulaire du support de refuser la transaction, et de demander à la banque de recréditer son compte du montant de la transaction. 4 - Procédé selon l'une des revendications 1 à
3, caractérisé en ce que les transactions qui apparaissent comme ' des ventes à distance sont des transactions à risque.
5 - Procédé selon la revendication 4, caractérisé en ce que les transactions de vente à distance sont identifiées par contrôle des informations définissant les conditions techniques de la transaction telles que le mode de lecture du numéro de support ou le contrôle d'un code confidentiel .
6 - Procédé selon la revendication 4 ou 5, caractérisé en ce que les transactions de vente à distance sont identifiées par contrôle des conditions réglementaires ainsi que par corrélation avec la disponibilité du résultat de la lecture de la piste magnétique ou de la puce du support. 7 - Procédé selon l'une des revendications 4 à
6, caractérisé en ce que dans la détection des ventes à distance, on prend en compte le pays d'origine de la transaction.
8 - Procédé selon l'une des revendications 1 à 7, caractérisé en ce que le moyen de communication avec le titulaire du support est un téléphone fixe ou mobile ou un appareil de messagerie ou un assistant personnel communicant, ou un courrier électronique.
9 - Procédé selon l'une des revendications 1 à 8, caractérisé en ce que le message d'alerte est un message écrit ou vocal . 10 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le moyen de communication comporte une voie principale et au moins une voie secondaire utilisée en cas de défaillance ou de délai dans la voie principale.
11 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le message d'alerte comporte des indications données au titulaire sur la manière de répondre. 12 - Procédé selon l'une des revendications précédentes, caractérisé en ce que les messages d'alerte sur les transactions par un même titulaire sont envoyées par des émetteurs différents qui reçoivent uniquement les réponses aux messages qu'ils ont émis.
13 - Procédé selon la revendication 8, caractérisé en ce que la réponse tient en un seul caractère, non modifiable par l'algorithme de saisie prédictif d'un téléphone mobile. 14 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le rejet d'une transaction par le titulaire déclenche un blocage par un serveur d'autorisation des transactions à distance ultérieures utilisant le même support. 15 - Procédé selon la revendication 14, caractérisé en ce que le serveur d'autorisation comporte un algorithme de blocage .
16 - Procédé selon la revendication 14, caractérisé en ce que le serveur d'autorisation déroute les demandes dont le support appartient à une liste vers une seconde machine qui les bloque.
17 - Procédé selon l'une des revendications 14 à 16, caractérisé en ce que le serveur d'autorisation qui bloque les transactions est dans le réseau interbancaire .
18 - Procédé selon l'une des revendications 14 à 16, caractérisé en ce que le blocage des transactions à distance est temporairement desactivable par une action volontaire du titulaire du support.
19 - Procédé selon l'une des revendications 14 à 16, caractérisé en ce que le blocage des transactions à distance peut être contourné en utilisant un numéro de support virtuel, que le mécanisme de blocage ne reconnaît pas, et qui est ensuite remplacé par le numéro réel du support .
20 - Procédé selon la revendication 19, caractérisé en ce qu'une transaction à distance faite avec un numéro de support virtuel déclenche l'émission d'un message spécifique vers le titulaire du support .
21 - Procédé selon la revendication 19, caractérisé en ce que le mécanisme de blocage et le mécanisme de cartes virtuelles sont gérés par les mêmes machines.
22 - Procédé selon l'une des revendications 14 à
21, caractérisé en ce que le mécanisme de blocage est également réalisé dans le serveur de paiement. 23 - Procédé selon l'une des revendications 14 à
22, caractérisé en ce qu'une liste des numéros de supports bloqués est diffusée à un ensemble de sites de vente à distance.
24 - Procédé selon l'une des revendications 14 à 23, caractérisé en ce qu'il existe une base de données de marchands par correspondance et de leurs identifiants dans les transactions monétiques, et en ce que tout rejet par le titulaire d'une transaction comportant un de ces identifiants fait l'objet d'une information rapide du marchand, avant finalisation de la livraison.
25 - Procédé selon l'une des revendications 18 à 24, caractérisé en ce qu'une transaction à distance faite avec un support bloqué déclenche l'émission d'un message vers le titulaire du support, lui recommandant d'utiliser un numéro de support virtuel à la place du numéro réel du support .
PCT/FR2002/002671 2001-07-27 2002-07-25 Procede de securisation de transactions Ceased WO2003012703A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002341013A AU2002341013A1 (en) 2001-07-27 2002-07-25 Method for making transactions secure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0110138A FR2827982B1 (fr) 2001-07-27 2001-07-27 Procede de securisation de transactions
FR01/10138 2001-07-27

Publications (2)

Publication Number Publication Date
WO2003012703A2 true WO2003012703A2 (fr) 2003-02-13
WO2003012703A3 WO2003012703A3 (fr) 2003-11-20

Family

ID=8866041

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/002671 Ceased WO2003012703A2 (fr) 2001-07-27 2002-07-25 Procede de securisation de transactions

Country Status (3)

Country Link
AU (1) AU2002341013A1 (fr)
FR (1) FR2827982B1 (fr)
WO (1) WO2003012703A2 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708422A (en) * 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
AU3977597A (en) * 1996-08-08 1998-02-25 Robert Richard Bock Financial transaction, authorization, notification and security apparatus
AU9362498A (en) * 1997-09-17 1999-04-05 Akos Andrasev Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account
US6636833B1 (en) * 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method

Also Published As

Publication number Publication date
WO2003012703A3 (fr) 2003-11-20
FR2827982A1 (fr) 2003-01-31
FR2827982B1 (fr) 2005-02-18
AU2002341013A1 (en) 2003-02-17

Similar Documents

Publication Publication Date Title
EP0820620B1 (fr) Procede de paiement electronique permettant d'effectuer des transactions liees a l'achat de biens sur un reseau informatique
US10713661B2 (en) Identity verification system
Hutchings et al. A crime script analysis of the online stolen data market
JP7737305B2 (ja) ユーザー間の取引を促進する方法
EP1014317B1 (fr) Procédé de paiement sécurisé
Sakharova Payment card fraud: Challenges and solutions
MX2011002067A (es) Sistema y metodo de transacciones de pago seguras.
EP1899950B1 (fr) Procede de securisation d'une transaction avec une carte de paiement et serveur d'activation pour la mise en oeuvre de ce procede
EP1110186B1 (fr) Procede de paiement electronique
EP1299838A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
Alfuraih et al. Using trusted email to prevent credit card frauds in multimedia products
CA3161325A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
EP1428183A2 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite
WO2003012703A2 (fr) Procede de securisation de transactions
FR2823882A1 (fr) Procede et systeme de validation de paiement
EP1978479A1 (fr) Cryptogramme dynamique
KR102684452B1 (ko) 암호화폐 p2p 안전거래 방법 및 시스템
FR2819662A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
FR2827448A1 (fr) Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
WO2002046984A1 (fr) Procede securise de transaction entre un acheteur et un vendeur
BE1019350A3 (fr) Usage d'une carte d'identite electronique en tant que carte d'affiliation.
FR2828966A1 (fr) Procede pour communiquer de facon securisee des donnees d'identification d'une carte de paiement
FR2819127A1 (fr) Procede et installation de securisation de transactions a distance par confirmation de transaction
Sui et al. TRUSTED EMAIL-A Proposed Approach to Prevent Credit Card Fraud in Soft-Products E-Commerce

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VN YU ZA ZM

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP