EP4074005A1

EP4074005A1 - Transaction authentication method, server and system using two communication channels

Info

Publication number: EP4074005A1
Application number: EP20845185.6A
Authority: EP
Inventors: David Naccache; Marc Beunardeau; Aisling CONNOLLY; Rémi GERAUD; Hiba KOUDOUSSI
Original assignee: Banks and Acquirers International Holding SAS
Current assignee: Banks and Acquirers International Holding SAS
Priority date: 2019-12-13
Filing date: 2020-12-11
Publication date: 2022-10-19
Also published as: FR3104760B1; FR3104760A1; CA3161325A1; US20230009385A1; WO2021116627A1

Abstract

The invention relates to a transaction method for a user 1 using a first and a second terminal 2 and connected to a server 4 via a first and a second communication channel, respectively. The first terminal 2 sends 304 a transaction amount TA to the server 4. The server 4 establishes 502 to 504 a verification code AC a length L of which is dependent on the amount of the transaction TA, and then sends 505 and 506 a request Req to the first terminal 2 and the verification code AC to the second terminal 5. The user returns 310 said request filled in with a copied code AC' to the server 4 using the first terminal 2. The server 4 compares 508 the verification code AC with the copied code AC' and sends 510, 512 a transaction validation or invalidation message to the first terminal 2 depending on the comparison.

Description

Title of the invention: TRANSACTION AUTHENTICATION PROCESS, SERVER AND SYSTEM USING TWO COMMUNICATION CHANNELS

[0001] Technical field

The present invention relates to a transaction authentication method using two communication channels as well as to a server and a bank transaction system implementing the method. More particularly, the invention relates to the use of a second communication channel to secure a transaction carried out from a first communication channel.

[0003] Technological Background

[0004] The electronic payment transactions which are the subject of this document relate to payment transactions carried out online. An online payment is made when selling or purchasing goods or services, whether by businesses, households, individuals, governments or other organizations, public or private, over interconnected networks of computers, such as the internet. Goods and services are ordered over these networks, but payment and final delivery of the good or service can be made online or offline. In addition, bank customers regularly carry out wire transfer payment transactions using Internet banking services. More and more consumers are using electronic commerce, to find and purchase goods and services over electronic networks such as, for example, the Internet. Payment is generally made by entering a debit and / or credit card number, or bank card, or using other financial information in the respective fields of a form on the merchant's site. line. Transactions can also be made using online or mobile payment service providers, such as those offered, for example, by PayPal, Inc., of San José, California. To ensure better security, electronic payment systems often use agglomerated security solutions such as those identified by the “3Dsecure”, “Verified by Visa”, or other brands. Such payment services and payment security solutions can make transactions easier and / or more secure for the parties involved. Buying with the help of a payment service provider from a portable mobile device is one of the main reasons why online and mobile shopping is growing so rapidly.

[0005] Traditional online payment systems expose users to security risks. For example, typing numbers from a credit card ID into a field on an online payment form exposes a user to theft of that number by a third party looking at their screen, by a keylogging computer virus. , etc. While the storage of credit card numbers by an online retailer may avoid requiring the user to manually enter information with each purchase during the payment transaction, it exposes the online retailer to their own risk and security responsibilities. Credit card information can also be captured by simple means, for example, by taking a photo of an inadvertently exposed card, not to mention that credit cards can be lost or stolen, which allows a person malicious to misuse it.

[0006] Therefore, modern electronic payment systems, such as online banking and e-commerce, often use a so-called two-factor security authentication procedure, hereinafter referred to as 2FA, to authenticate securely. a customer holding a bank card during the payment transaction. Two-factor authentication procedures are well known to those skilled in the art. One of the oldest forms of two-factor security authentication, typically used by banks for Internet banking transactions, is issuing cardholder customers, along with the bank card, a numbered list of bank numbers. transaction authentication, commonly known as TAN (from English Transaction Authentication Numbers), so that after entering card information in a payment request form on a site Web of a bank, in a second step of the transaction, the bank asks the user to manually enter the TAN value corresponding to a number chosen randomly by the bank from the TAN list.

[0007] The drawbacks and the limited security of the aforementioned 2FA solution lead to more advanced forms of two-factor authentication procedures which may require, nowadays, that a customer has, in addition to the payment card and / or other identity information of the customer and a PIN code (from English Personal Identification Number), of a second personal device, registered by the payment system or by the bank with this customer, said personal device being used as the second factor of customer authentication during payment transactions. Generally, such a device is a mobile phone or a secure token connected to the Internet or to another network and which is issued by the bank or any other payment solution provider. In the case of a 2FA procedure, during a payment transaction, a customer uses a device, usually internet-enabled, to select goods, services or other forms of payment transaction on the merchant's website. or online banking, and performs a first step of the payment transaction by completing the forms provided by said websites with required payment information, such as card and / or bank account number, name and address. 'cardholder's address, etc. After the form is submitted, a bank, payment solution provider, or credit card issuer sends a one-time transaction authentication code to a second cardholder device. In a second step, the authentication code is entered manually by the cardholder and then sent via the network to the bank, to the payment solution provider or to the credit card issuer, so that the code can be compared with the code. authentication issued. If the comparison is correct, the payment transaction will be successful, otherwise the payment transaction will be refused, possibly with notification to the cardholder.

[0008] Although this two-factor authentication procedure increases the overall security of electronic payment transactions, it also increases the transaction and shopping cart abandonment time. Indeed, the Entering the passcode manually not only takes extra time, but more importantly, is error-prone, creating a bad user experience that can result in the transaction being aborted at this point.

[0009] An authentication code is generally an alphanumeric string of a certain length. The length of the chain is defined a priori by a payment scheme and is the same for all transactions.

Today, two-factor scheme implementations face the following dilemma: either the authentication code is short, which is better for the user experience, but its security is poor because the shortcodes can be easily guessed; or the code is long, which is preferable for the security of the payment system, but increases the risk of error for the user.

[0010] The present invention aims to remedy the inconveniences mentioned above when using an authentication code in a two-factor security procedure.

[0011] Summary of the Invention

[0012] The invention proposes to improve the aforementioned two-factor authentication system by adapting the complexity of the authentication code, in particular its length, to the amount paid during the transaction.

According to one embodiment, the invention provides a transaction authentication method using two data communication channels for a user using a first terminal connected to at least one bank transaction server via a first communication channel and a second terminal connected to the at least one bank transaction server via a second communication channel at least logically distinct from the first communication channel. The process includes:

a first step during which the first terminal sends to the at least one bank transaction server transaction information comprising at least one transaction amount, and an identification of an account and / or of a bank card to debit, - a second step during which the bank transaction server establishes a verification code whose length depends on the amount of the transaction, determines the second terminal according to the identification of the account and / or the bank card to be debited , then sends, on the one hand, a confirmation request requesting the verification code to the first terminal via the first communication channel and, on the other hand, the verification code to the second terminal via the second communication channel,

a third step during which the user copies the verification code received on the second terminal in the confirmation request received by the first terminal and returns said request thus filled with the code copied to the bank transaction server using from the first terminal via the first communication channel,

a fourth step during which the bank transaction server receives the copied code from the first terminal, and compares the verification code with the copied code and sends to the first terminal a transaction validation message if the codes are identical or a message transaction invalidation if the codes are different.

[0014] Thus, the length of the verification code can increase when the amount of the transaction increases. Short authentication codes can be assigned to transactions involving small payment amounts, while longer and more complex codes, i.e. more difficult for malicious people to guess, can be assigned to payment amounts. larger payments. Preferably, the length of the verification code can be between a minimum value and a maximum value.

The user experience during electronic payment transactions is improved in two ways. First of all, and especially for small amount transactions, the work of manually copying the authentication code from one device to another is lightened, which is faster and reduces the risk of error for the user. . For transactions involving larger sums, longer and more complex authentication codes allow the user to appreciate that second factor authentication, even if it weighs down and slows down the transaction, it increases the security of the transaction, thus playing a reassuring role.

[0016] As a variant, the transaction information can include identification information of the account holder and at least one redundant information related to the identification of the bank account to be debited. The second step may include a preliminary step which verifies a concordance between the identification of the bank account to be debited, the identification information of the holder and the at least one redundant information. The second step can only be performed if the match is established.

Considering that a risk factor during the transaction may depend on other parameters than the amount of the transaction, the length of the verification code may also depend on a risk factor determined using one or more parameters included among: the time of the transaction, the date of the transaction, information relating to the card holder, the number of transactions carried out in a predetermined period preceding the transaction.

According to a second embodiment, the invention provides a bank transaction server comprising a processing unit, a program memory, at least one communication interface capable of communicating via a first communication channel and via a second channel. communication at least logically distinct from the first communication channel. The program memory contains instructions cooperating with the processing unit so that the server is configured for:

- on receipt from the first communication channel of a transaction request comprising at least one transaction amount and an identification of a bank account to be debited, calculating a length of a verification code as a function of the amount of the transaction , determine the verification code from the calculated code length, determine a second communication channel according to the identification of the bank account to be debited, send a confirmation request requesting the verification code via the first communication channel, and send the verification code via the second communication channel, - on receipt of a code received via the first communication channel in response to the confirmation request, compare said received code with the verification code and send via the first communication channel a transaction validation message if said codes are identical or a transaction invalidation message if said codes are different.

According to another embodiment, the invention provides a bank transaction system comprising at least one bank transaction server, a first terminal of a user connected to the at least one bank transaction server via a first channel communication, and a second terminal of an account holder and / or a bank card connected to the at least one bank transaction server via a second communication channel at least logically distinct from the first communication channel. The first terminal is configured to send, at the user's request, to the at least one bank transaction server, a transaction request comprising at least one transaction amount, and an identification of the account and / or of the card. banking. The bank transaction server is configured to, upon receipt of the transaction request, establish a verification code whose length depends on the amount of the transaction, determine the second terminal according to the identification of the bank account to be debited, then send, on the one hand, a confirmation request requesting the verification code to the first terminal via the first communication channel and, on the other hand, the verification code to the second terminal via the second communication channel. The second terminal is configured to display, to the holder of the bank account, the verification code sent by the bank transaction server. The first terminal is configured to send back to the bank transaction server a code copied by the user from the verification code displayed on the second terminal. The bank transaction server is configured to, upon receipt of the copied code, compare with the verification code with the copied code and send to the first terminal a transaction validation message if the codes are identical or a transaction invalidation message if the codes are different.

Brief Description of the Figures The invention will be better understood and other characteristics and advantages thereof will appear on reading the following description of particular embodiments of the invention, given by way of illustrative and non-limiting examples, and with reference to the accompanying drawings, among which:

[0022] [Fig.1] shows a two-factor authentication bank transaction system,

[0023] [Fig.2] shows a commercial transaction system on an open network with two authentication factors,

[0024] [Fig.3] illustrates a transaction on the system of Figure 1 according to the invention,

[0025] [Fig.4] illustrates a transaction on the system of Figure 2 according to the invention,

[0026] [Fig.5] shows an operating flowchart of an authentication server according to the invention,

[0027] Detailed description

[0028] Figures 1 and 2 show two transaction systems performed through an open network, such as the internet, for example, using two-factor authentication. In these two figures, the same references correspond to the same elements or to similar elements. These two figures correspond to two-factor security transaction schemes as used in the prior art and according to the invention.

By "open network", it is necessary to understand a communication network allowing interconnections between one or more computer machines accessible to any person wishing to do so. This type of network can be the Internet but could correspond to other types of networks as long as the connection remains open to everyone. Open networks have the advantage of making it easier to connect people, thereby increasing the possibilities for business transactions between people connected to the network. A downside of open networks is the risk of interacting with machines owned by malicious people.

FIG. 1 corresponds to a banking transaction system allowing a user to carry out transaction operations with his bank, such as for example to make a bank transfer or to purchase securities online or any other type of operation for which the user transfers money from his bank account. In this figure 1, the user 1 interacts with a first terminal 2 connected to an open network 3, such as for example the Internet, in order to communicate with a banking services server 4 to carry out an operation corresponding to a banking transaction that is that is, a money transfer from a bank account.

The first terminal 2 is for example a fixed or portable personal computer, a tablet or a smartphone having a processing unit, at least one volatile and / or non-volatile memory, a communication interface. making it possible to connect to the open network 3, a man-machine interface making it possible to view and enter information, such as for example a display screen, a touch screen, a keyboard, a mouse or the like. Among the programs stored in its memory, the first terminal has an open network navigation program 3, allowing it to connect to and interact with websites, in particular to consult web pages or to complete and send. forms corresponding to transaction requests. Alternatively, the first terminal 2 can have a specific program allowing it to connect through the open network 3 to the banking services server 4.

The banking services server 4 is for example a computer having one or more processing units, at least one volatile and mass memory, and at least one communication interface allowing it to connect to the open network 3. The mass memory stores, among other things, a database containing all the information relating to the bank accounts of the customers of the bank to which it belongs. The banking services server 4 comprises programs stored in memory allowing it to make available to terminals connected, through the open network 3, searchable web pages which make it possible to interact with users via forms contained in said web pages. The forms, once completed and returned by the user, are then processed by the processing unit for validation. When a transaction is desired by a user 1, the latter uses the first terminal 2 to connect to the banking services server 4. A web page is then transmitted to the first terminal 2 by the banking services server 4. The web page can include information to be displayed on the first terminal 2, as well as commands to be executed as a function of the choice made by the user via the man-machine interface. Among the choices offered to user 1, a transaction, for example a bank transfer, can be carried out. By choosing to make a transfer, a transaction form is presented to user 1, the form being able to be included in the web page or transmitted by the banking services server 4 after receipt of a message indicating the user's choice. 1 from the first terminal 2. The user 1 then fills out the form with the information necessary for the transaction which may include the identification of the bank account to be credited, the identification of the bank account to be debited, the amount of the transaction. A lot of other information may also be required, such as redundant identifiers of the user and / or of the bank account or of its holder, a secret known only to the bank and the holder, a transaction identifier or any other information that is in connection with the transaction. Once the form has been completed, user 1 sends the completed form to the banking services server 4 via the first terminal 2. The form can be accompanied by the time and date of sending and also identifiers specific to the first one. terminal 2.

Having received the completed transaction form, the banking services server 4 verifies the information contained in the form and in particular whether the requested transaction can be authorized or not. To this end, the banking services server 4 queries its database to check whether the account to be debited is still in service and whether the credit of the account to be debited can make it possible to authorize the transaction. Optionally, the server can verify the correctness of redundant identifiers or information on the holder of the bank account. This first check corresponds to a first safety factor. However, the transaction was transmitted by the open network 3 and, despite this first check, it is possible that this transaction came from a misappropriation of the form and / or information relating to the bank account by a malicious third party.

Indeed, the communications on the open network 3 can be intercepted and possibly replayed in a modified manner. In order to guarantee a minimum of security, it is known practice to encrypt sensitive messages between two machines, such as for example the terminal 2 and the banking services server 4, using session keys or specific keys. However, any encrypted message can be decrypted after a certain period of time, making it possible to retrieve an exchanged form and reuse the information it contains. In addition, the fact that the network is open allows malicious people to spread viruses on the machines connected to it and in particular the first terminal 2. Among the viruses, some can intercept the information exchanged on the man-machine interfaces. and send them back to another machine, also rendering the confidentiality of encrypted messages inoperative. In order to add a level of security, a second security factor can be added by using a second communication channel to send a one-time code. To this end, the banking services server 4 has a second communication interface capable of communicating via the second communication channel with a second terminal 5 which belongs to a bank account holder. The second terminal 5 is identified in the database of the banking services server 4 in relation to the bank account to be debited. The second terminal 5 can be, conventionally, a mobile telephone of the holder of the bank account, but can also be any other type of device connected to a communication network, such as, for example, a box connected to a supplied mobile telephone network. by the bank or even a tablet or a computer connected to the Internet. The important thing is that the second communication channel is at least logically distinct from the first communication channel used for sending the transaction form.

After having made the first verification, the banking services server 4 retrieves, in its database, the identifier of the second terminal 5 to send it a one-time verification code. The identifier of the second terminal 5 is, for example, a mobile telephone number and the message is, for example, sent by a short message of the SMS type (English Short Message Service). The message can also indicate the amount of the transaction and / or the beneficiary of the transaction, so that the account holder can verify that the current transaction conforms to a desired transaction.

In parallel, the banking services server 4 sends to the first terminal 2 a confirmation request requesting the single-use code. User 1, if he corresponds to the holder of the bank account, can then read the one-time code on the second terminal 5 and copy it into a response form attached to the confirmation request in order to send it back to the service server. banking 4.

On receipt of the response form, the banking services server 4 compares the code present in the form with the one-time code sent to the second terminal 5. If the two codes are identical, then the banking services server 4 validates the transaction and sends a message to the first terminal 2 to inform it of the acceptance of the transaction. If the two codes are different, then the transaction is refused and the banking services server 4 sends a message to the first terminal indicating that the transaction is refused. Optionally, the banking service server 4 can reiterate the sending of a new one-time verification code to the second terminal 5 and a request to the first terminal 2.

FIG. 2 corresponds to a commercial transaction system allowing a user 1 to make a purchase on a merchant site 6. The merchant site 6 is a server-type computer which is connected to the open network 3 in order to provide web pages which offer products and / or services to users connecting to them using an appropriate terminal. The user 1 connects to the merchant site 6 using the first terminal 2 via the open network 3. Once a choice of products or services has been made by the user 1, the merchant site 6 sends a transaction form to the first terminal 2. The transaction form is pre-filled by the merchant site 6 with the identification of the seller, his bank account and the amount of the transaction. The transaction form is presented to user 1 by the first terminal 2, asking the latter to complete with an account or bank card identification. Other information may also be required, such as, for example, the supplier of the bank card, the code CW (standing for Cardholder Verification Value) which constitutes a redundant identifier of the card, the identification of the holder of the card. credit card or any other redundant information relating to the card or its holder. Once the form has been completed, user 1 sends the form to the merchant site 6 via the first terminal 2. The form can be accompanied by the time and date of sending and also identifiers specific to the first terminal 2 such that, for example, its address on the open network 3.

The merchant site 6 receives the form and transmits it to an acquirer service server 7 which corresponds to its bank. The acquirer services server 7 is a computer having one or more processing units, at least one volatile and mass memory, at least one communication interface allowing it to connect with the merchant site 6 and 'at least one communication interface for connecting to a secure network dedicated to banking services. The communication interface communicating with the merchant site 6 can correspond to a specific secure link or to an open network implementing encrypted communication.

The acquirer services server 7 then transmits the transaction form, via the secure network, to a debtor services server 4 ’which corresponds to the issuer of the bank card. Debit service server 4 "is similar to bank service server 4. Debit service server 4" can be the cardholder's bank server or the server of a credit card issuer.

On receipt of the transaction form, the debtor service server 4 'checks the information contained in the form and, in particular, whether the requested transaction can be authorized or not. To this end, the debtor services server 4 'queries its database to check whether the account or the bank card is still in service, if any redundant information is in conformity with the card or the bank account and if the amount of the payment. transaction corresponds to an authorized amount. This first level of security verification having been carried out, the debtor services server 4 'carries out a verification according to a second security level similar to that described in relation to FIG. 1 with some differences.

The debtor service server 4 'identifies in its database the second terminal 5 in relation to the card or the bank account to be debited and a second communication channel distinct, at least logically, from the communication channel with the first terminal 2. The debtor services server 4 ′ sends a message comprising a one-time verification code to the second terminal 5. The message can also indicate the amount of the transaction and / or the beneficiary of the transaction, so that the holder of the account can verify that the current transaction conforms to a desired transaction.

In parallel, the debtor service server 4 ’sends to the first terminal 2 a confirmation request requesting the one-time code. This request can be sent to the first terminal 2 via the acquirer service server 7 and the merchant site 6 via the open network 3 or directly by the debtor service server 4 ′ via the open network 3. The user 1, if it corresponds to the card or bank account holder can then read the single-use code on the second terminal 5 and copy it into a response form attached to the confirmation request, in order to send it back to the debtor services server 4 'using the same communication channel.

On receipt of the response form, the debtor service server 4 'compares the code present in the form with the one-time code sent to the second terminal 5. If the two codes are identical, then the banking services server 4 validates the transaction and sends a message to the acquirer services server 7 which records the transaction and transmits a validated payment message to the merchant site 6. The merchant site 6 then informs the first terminal 2 that the payment is accepted and delivers the service or initiates a procedure for delivering product (s) which will not be detailed in this document. If the two codes are different, then the transaction is refused and the debtor service server 4 'sends a message to the acquirer service server 7 which is retransmitted to the merchant site 6, then to the first terminal 2 indicating that the transaction is refused and therefore not completed. Optionally, the debtor services server 4 ′ can reiterate the sending of a new one-time verification code to the second terminal 5 and of a new request to the first terminal 2 via one of the paths indicated above.

The invention aims to improve transaction verifications using two security factors as indicated above and in particular using a second communication channel with the holder of the account or of the bank card. To this end, FIGS. 3 and 4 illustrate the steps of the transaction methods carried out according to the invention respectively on the transaction systems described in relation to FIGS. 1 and 2. The flowchart of FIG. 5 details the steps of the processing method. transaction verification performed according to the invention by the banking services server 4 or the debtor services server 4 'during the exchanges carried out in accordance with FIG. 3 or FIG. 4. The steps common between FIGS. 3, 4 and 5 bear the same references and the description of FIG. 5 is made in conjunction with the descriptions of FIGS. 3 and 4. In order to emphasize the invention, the steps prior to a choice of transaction by user 1 are not detailed in Figures 3 and 4 which begin after a transaction decision, corresponding to the making of a payment, has been validated by the user 1 of the first terminal 2.

In Figure 3, the choice of the transaction having been made by user 1, the banking services server 4 sends to the first terminal 2 a transaction form corresponding to the choice of user 1 in a first step 301 of the transaction process. In a second step 302 of the transaction method, the user 1 takes note of the form received by the first terminal 2, for example using a display screen of the first terminal 2. The user fills in the form with the information requested during a third step 303 of the transaction method, for example using a keyboard of the first terminal 2. Once the form has been completed, the user validates the form in order to send it.

A fourth step 304 of the transaction method corresponds to the sending of the form by the first terminal 2 to the banking services server 4 via the open network 3. This fourth step 304 of the transaction method corresponds to a first verification step 501 of the banking services server 4. The banking services server 4 receives an incoming message R1 arriving via the first communication channel. The incoming message R1 contains credentials ID of a bank account and a transaction amount TA. The identification information ID includes at a minimum the bank account number, but may include redundant information such as, for example, one or more of: a password, a PIN code, one or more information of the identity of the user. Bank account owner. The identification information ID can also include parameters specific to the transaction, such as for example the time, date or place where the first terminal 2 is located, as well as an identifier of said first terminal 2.

In a second verification step 502, the banking services server 4 verifies that the bank account exists and that it is not blocked. Optionally, other checks can be performed to verify that any redundant information complies with that corresponding to the bank account. Further, the banking service server 4 can also verify that the amount to be debited is consistent with an authorized debit from the bank account.

This preliminary bank account verification performed, the banking services server 4 then calculates a length L of verification code in a third verification step 503 where the length L corresponds to a number of digits of said code. Preferably, the length L is determined as a function of the amount of the transaction TA, so that the verification code takes into account the amount of the transaction as a risk factor. As a simple example, the following formula can be used:

[0052] [Math 1]

[0053] L = A * TA + B

The parameters A and B can be set arbitrarily by the bank according to an acceptance of risk. If A = 0.1 and B = 2 with the result L rounded to the nearest integer, a payment of one euro will result in an L code of two very simple digits to copy for a sum representing a minimal risk. With these same parameters, a payment of ten euros corresponds to a three-digit code and a payment of one hundred euros corresponds to a code of twelve digits.

[0055] Preferably, identification information ID can be taken into account in determining the number of digits. By way of example, the parameters A and B can be stored in the database of the bank service server 4 and accessed using the identification of the account number. Thus, it is possible to define the parameters A and B according to a risk accepted by the user or by his account manager, B corresponding to a minimum number of digits and A being determined according to an amount for which a financial risk seems acceptable. In order to avoid having too long codes, it is also possible to set a maximum number of digits.

[0056] As a variant, it is also possible to have a non-linear growth in the number of digits in order to avoid having to limit the number of digits. As an example, the following formula can also be used:

[0057] [Math 2]

[0058] L = A * log ₁₀ (TA) + B

The use of a logarithmic function makes it possible to have an increase in the length L of the verification code proportional to the number of digits of the amount of the transaction. For example, if A = 0.3 and B = 3, an amount of less than ten euros produces a verification code length of three digits, an amount of one hundred euros corresponds to a code length of six digits and an amount of one thousand euros corresponds to a code length of nine digits.

The verification code length L being determined, the banking service server 4 then calculates a verification code AC during a fourth verification step 504. The verification code AC can be generated in different ways, preferably using a random or pseudo-random number generated by the processing unit of the banking service server 4. A As a simple example, the following formula can be used to determine the verification code:

[0061] [Math 3]

[0062] AC = Seed mod L

With Seed corresponding to a random or pseudo-random number generated by the processing unit of the banking services server 4, mod to the modulo function and L to the code length calculated during the third verification step 503. From very many variations are possible by integrating the amount of the transaction TA and one or more information identifying the transaction ID, such as for example the time or the date of the transaction. As an example, the following formula can also be used:

[0064] [Math 4]

[0065] AC = H (Seed, TA, ID) mod L

[0066] with H corresponding to a cryptographic hash function, for example a SHA-3, performed on the concatenation of the random number Seed, the amount of the transaction TA and one or more identification information IDs.

The verification code AC being calculated, a fifth verification step 505 is performed by the banking services server 4. The fifth verification step 505 consists in sending an outgoing message S1, by the first communication channel, to the destination from the first terminal 2, the outgoing message containing a Req request asking the user 1 of the first terminal 2 to return a verification code in a response form.

In parallel with the fifth verification step 505, that is to say before or after this fifth step 505, the banking services server 4 performs a sixth verification step 506. The sixth verification step 506 consists of send an outgoing message S2 by the second communication channel to the second terminal 5. The second terminal 5 is, prior to sending, identified in the database of the banking services server 4 in association with the bank account to be debited. The outgoing message S2 contains the verification code AC calculated during the fourth verification step.

The fifth verification step 505 corresponds to a fifth step 305 of the transaction method and the sixth verification step 506 corresponds to a sixth step 306 of the transaction method.

The first terminal 2 having received the request Req, it is presented to the user 1 during a seventh step 307 of the transaction method, the response form being to be completed by the user 1. At the same time in the seventh step 307, that is to say before or after this seventh step 307, an eighth step 308 of the transaction method consists in the presentation of the verification code AC by the second terminal 5 to the user 1.

User 1, having the verification code AC, fills out the response form by copying the verification code AC into the form during a ninth step 309 of the transaction process. The copied verification code AC ′ is sent to the banking services server 4 in a tenth step 310 of the transaction process. The tenth step 310 of the transaction method corresponds to a seventh verification step 507 carried out by the banking services server 4. The banking services server 4 receives an incoming message R1 arriving from the first communication channel having for content the copied code AC ' . An eighth verification step 508 then consists in comparing the copied code AC ’with the verification code AC calculated during the fourth verification step 504.

If the copied verification code AC ′ is identical to the verification code AC, then the banking services server 4 performs a ninth verification step 509 during which it validates and records the completion of the transaction. Then, a tenth verification step 510 is carried out to send an outgoing message S1 via the first communication channel to the first terminal 2 to indicate that the transaction has been carried out.

If the copied verification code AC 'is not identical to the verification code AC, then the banking services server 4 performs an eleventh step 511 during which it cancels the transaction. If, during the second verification step 502, the banking services server 4 has not found the bank account or has found the bank account but that it is blocked or even if other verifications have shown that any redundant information is not not in accordance with those corresponding to the bank account, the second verification step 502 can lead directly to the eleventh verification step 511 and also cancel the transaction. After the eleventh verification step 511, a twelfth verification step 512 is performed to send an outgoing message S1 via the first communication channel to the first terminal 2 to indicate that the transaction is canceled.

The tenth verification step 510 or the twelfth verification step 512 corresponds to an eleventh step 311 of the transaction method in which the first terminal 2 receives the outgoing message S1 to display it to the user 1 during a twelfth step 312 of the transaction method. Thus, user 1 is informed of the completion or cancellation of the requested transaction.

Figure 4 discloses a transaction process carried out from the merchant site 6. After the user has chosen to make a purchase, the merchant site 6 sends to the first terminal 2 a transaction form in a first step 401 of the transaction process. In a second step 402 of the transaction method, the user 1 takes note of the form received by the first terminal 2. The user 1 fills in the form with the information requested during a third step 403 of the transaction method. The form contains ID credentials of a card or bank account and a TA transaction amount. The identification information ID includes at a minimum the number of card or bank account but can include redundant information such as, for example, one or more elements among: a password, a PIN code, a CW code, one or more. several identity information of the account holder. The identification information ID can also include parameters specific to the transaction such as, for example, the time, date or place where the first terminal 2 is located or else an identifier of said first terminal 2. Once the form completed, user 1 validates the form to send it. A fourth step 404 of the transaction method corresponds to the sending of the form by the first terminal 2 to the merchant site 6 via the open network 3. The merchant site 6 retransmits the form to the acquirer service server 7 during a fifth step 405 of the transaction method. From the identification information ID of the card or of the bank account, the acquirer service server 7 determines a corresponding debit service server 4 ′, in order to retransmit the form to it during a sixth step 406 of the transaction method. .

This sixth step 406 of the transaction method corresponds to the first verification step 501, performed by the debtor service server 4 ′, corresponding to the reception of the incoming message R1 arriving from the first communication channel. The debtor services server 4 ′ then performs the second verification step 502, in order to verify that the account or the bank card exists and that it is not blocked. Optionally, other checks can be carried out to verify that any redundant information complies with that corresponding to the account or the bank card. In addition, the debtor service server 4 ’can also verify that the amount to be debited complies with an authorized debit from the account or bank card.

The debtor service server 4 ’performs the third verification step 503 and calculates a length L of verification code AC corresponding to a number of digits of said code. The length L is determined as a function of the amount of the transaction TA so that the verification code AC takes into account the amount of the transaction as a risk factor as previously described.

In addition, the transaction being carried out on a merchant site and not on a bank server, the risk is found to be greater. The length L of the verification code may also incorporate other risk factors such as a transaction hour and / or a number of recently completed transactions. For example, such an integration can result in the following formula:

[0080] [Math 5] L = A * log ₂ (Nb) * R (T) * log ₁₀ (TA) + B

With Nb representing the number of transactions carried out in the last twenty-four hours with the same account number or the same bank card, T representing the time of the transaction and R (T) being a risk coefficient depending on the time T, the coefficient R (T) being for example read in a correspondence table produced from statistics on the time of execution of fraudulent transactions.

The debtor services server 4 ’then calculates the verification code AC during the fourth verification step 504 as previously described. The fifth and sixth verification steps 505 and 506 are then performed in parallel. The fifth verification step 505 consists in sending an outgoing message S1 via the first communication channel to the first terminal 2 which contains a confirmation request Req asking the user 1 of the first terminal 2 to send back a verification code in a response form. The sixth verification step 506 consists in sending an outgoing message S2 via the second communication channel, to the second terminal 5, the second terminal 5 having been previously identified from the database of the debtor services server 4 'in association with the account or bank card to be debited. The outgoing message S2 contains the verification code AC calculated during the fourth verification step 504.

The fifth verification step 505 corresponds to a seventh step 407 of the transaction method. During the seventh step 407, the debtor service server 4 ′ transfers an outgoing message containing the request S1 (Req) to the acquirer service server 7. The acquirer service server 7 transfers this message to the merchant site 6 during the process. an eighth step 408 of the transaction method. The merchant site 6 then retransmits the request to the first terminal 2 in a ninth step 409 of the transaction method.

The sixth verification step 506 corresponds to a tenth step 410 of the transaction method during which the second terminal 5 receives the verification code AC. The first terminal 2 having received the request Req, it is presented to the user 1 during an eleventh step 411 of the transaction method, the response form being to be completed by the user 1. At the same time in the eleventh step 411, a twelfth step 412 of the transaction method consists in the presentation of the verification code AC, by the second terminal 5, to the user 1.

User 1, having the verification code AC, fills out the response form by copying the verification code AC into the response form during a thirteenth step 413 of the transaction process. The copied verification code AC ′ is sent to the merchant site 6 in a fourteenth step 414 of the transaction process. During a fifteenth step 415 of the transaction method, the merchant site 6 transmits the response form to the acquirer service server 7. In a sixteenth step 416 of the transaction method, the acquirer service server 7 transmits the completed form to the debtor services server 4 '.

The sixteenth step 416 of the transaction method corresponds to the seventh verification step 507 performed by the debtor services server 4 ′. The debtor services server 4 ’receives an incoming message R1 arriving by the first channel, having for content the copied code AC’. During the eighth verification step 508, the debtor service server 4 "compares the copied code AC" with the verification code AC calculated during the fourth verification step 504.

If the copied verification code AC ′ is identical to the verification code AC, then the debtor service server 4 ’performs the ninth step 509 during which it validates and records the completion of the transaction. Then, the tenth verification step 510 is carried out to send an outgoing message S1 via the first communication channel, to the first terminal 2, to indicate that the transaction has been carried out.

If the copied verification code AC ′ is not identical to the verification code AC, then the debtor service server 4 ′ performs the eleventh step 511 during which it cancels the transaction. If, during the second verification step 502, the debtor services server 4 'has noted that the account or the bank card is blocked or if other verifications have shown that any redundant information does not comply with that corresponding to the account or the bank card, the second verification step 502 can lead directly to the eleventh verification step 511 and also cancel the transaction. After the eleventh verification step 511, a twelfth verification step 512 is performed to send an outgoing message S1, via the first communication channel, to the first terminal 2 to indicate that the transaction is canceled.

The tenth verification step 510 or the twelfth verification step 512 correspond to a seventeenth step 417 of the transaction method in which the acquiring service server 7 receives the outgoing message S1. The acquirer service server 7 records the completion or cancellation of the transaction and transmits the outgoing message to the merchant site 6 during an eighteenth step 418 of the transaction process. The merchant site 6 notes the validation or cancellation of the transaction. If the transaction is validated, the merchant site 6 delivers the service or triggers the delivery of the purchased product. During a nineteenth step 419, the merchant site 6 sends a transaction confirmation or cancellation message to the first terminal 2. The first terminal 2 displays the confirmation message to the user 1 during a transaction. twentieth step 420 of the transaction process. Thus, user 1 is informed of the completion or cancellation of the purchase made.

Many variant embodiments are possible while remaining in compliance with the verification method forming the subject of the invention. By way of example, the seventh to ninth steps 407 to 409 of the transaction method described in relation to FIG. 4 can be replaced by a first alternative step 421 which directly transmits the request for a confirmation code from the debtor services server 4 ′ to the first terminal 2 via the open network 3. Also, a second alternative step 422 can replace the fourteenth to sixteenth steps 414 to 416 of the transaction method to directly transmit the verification code copied AC 'from the first terminal 2 to the debtor services server 4 '. In the present document, the first terminal 2 is a computer connected to the Internet and the second terminal 5 is a mobile telephone. As indicated previously in the description, the first and second terminals 2 and 5 can be any type of connected device which can exchange data with a remote server. According to one variant, the first and second terminals 2 and 5 can be one and the same physical terminal. The important thing is that the first and second communication channels are at least logically separated from each other so that malicious interception of the first channel does not automatically lead to malicious interception of the second channel.

By way of example, the first and second terminals can be one and the same personal computer with a first communication channel comprising internet browsing software and a second communication channel comprising messaging software, the identification of the second communication channel using an email address. In this example, the first and second communication channels are logically distinct from each other, although the physical connection of the terminals uses the same communication interface, namely the same network connection card. However, the verification code sent by the second channel is not directly accessible by the navigation software and it is necessary for the user to act on a man-machine interface of the personal computer to view and copy said code. Thus, only software that intercepts actions performed on the human-machine interface can intercept the verification code. However, this type of interception can also be achieved when the two communication channels are physically distinct and therefore the logical differentiation constitutes the same level of security as a physical differentiation of the communication channels.

Referring to Figures 2 and 4, there is described a debtor service server 4 'and an acquirer service server 7. Typically, an electronic transaction is carried out between two bank accounts belonging to two different holders who have two banks. different each having their own server. However, it is possible that the seller and the buyer have a bank account in the same bank. In this case, the debtor 4 ′ and acquirer 7 service servers form one and the same server, which makes it possible to reduce the number of exchanges.

Conversely, one or more intermediary service providers can also be interposed between the debtor 4 ’and acquirer service servers 7. This is particularly the case when credit cards are used. The link is not made directly from bank to bank, but goes through a card provider who can replace the cardholder's bank or simply act as an intermediary in an online transaction. Likewise, the banking service servers 4, debtors 4 ’and acquirers 7 can be distributed servers. Given the volume of banking data and the number of transaction requests, several independent computers connected to a network can perform the role of each of the banking services 4, debtors 4 'and acquirers 7 servers. Each computer constituting one of the servers can perform all the operations of a transaction or only a part, the different transaction operations being performed on different computers.

Claims

[Claim 1] transaction authentication method using two data communication channels for a user (1) using a first terminal (2) connected to at least one bank transaction server (4, 4 ') via a first communication channel. communication and a second terminal (5) connected to the at least one bank transaction server (4, 4 ') via a second communication channel at least logically distinct from the first communication channel, characterized in that the method comprises:

- a first step (304, 404, 405, 406, 501) during which the first terminal (2) sends to at least one bank transaction server (4, 4 ') transaction information comprising at least one amount of the transaction (TA), and an identification (ID) of an account and / or a bank card to be debited,

- a second step (502 to 506) during which the bank transaction server (4, 4 ') establishes a verification code (AC) whose length (L) depends on the amount of the transaction (TA), determines the second terminal according to the identification (ID) of the account and / or the bank card to be debited, then sends, on the one hand, a confirmation request (505) requesting the verification code to the first terminal (2) via the first communication channel and, on the other hand, the verification code (506) to the second terminal (5) via the second communication channel,

- a third step (307, 308, 309, 411, 412, 413) during which the user (1) copies the verification code (AC) received on the second terminal (5) in the confirmation request received by the first terminal (2) and sends (309, 413) said request thus filled with the copied code (AC ') to the bank transaction server (4, 4') using the first terminal (2) via the first channel Communication,

- a fourth step (507 to 512) during which the bank transaction server (4, 4 ') receives (507) from the first terminal (2) the copied code (AC'), and compares (508) the code of verification (AC) with the copied code (AC ') and sends (510, 512) to the first terminal (2) a message of transaction validation if the codes are identical or a transaction invalidation message if the codes are different.

[Claim 2] A method according to the preceding claim, in which the transaction information further comprises identification information of the account holder and at least one redundant information related to the identification of the bank account to be debited, in which, the second step (502 to 506) comprises a preliminary step (502) which verifies a match between the identification of the bank account to be debited, the identification information of the holder and the at least one redundant information and in which the second step is not performed only if the match is established.

[Claim 3] Method according to one of the preceding claims, in which the length (L) of the verification code (AC) also depends on a risk factor determined using one or more parameters included among: l time of the transaction, the date of the transaction, information relating to the card holder, the number of transactions carried out in a predetermined period preceding the transaction.

[Claim 4] Method according to one of the preceding claims, in which the length (L) of the verification code (AC) increases as the amount (TA) of the transaction increases.

[Claim 5] Method according to one of the preceding claims, in which the length (L) of the verification code (AC) is between a minimum value and a maximum value.

[Claim 6] Bank transaction server (4, 4 ') comprising a processing unit, a program memory, at least one communication interface able to communicate via a first communication channel and via a second communication channel at least logically distinct from the first communication channel characterized in that the program memory comprises instructions cooperating with the processing unit so that the server is configured for:

- upon receipt (501) from the first communication channel of a transaction request comprising at least one transaction amount (TA) and an identification (ID) of a bank account to be debited, calculate (503) a length (L) of a verification code (AC) according to the amount of the transaction (TA), determine the verification code (AC) from the calculated code length (L), determine a second communication channel in function of the identification (ID) of the bank account to be debited, send (505) a confirmation request (Req) requesting the verification code via the first communication channel, and send (506) the verification code (AC) via the second communication channel,

- on reception (507) of a received code (AC ') via the first communication channel in response to the confirmation request, compare said received code (AC') with the verification code (AC) and send via the first communication channel a transaction validation message (510) if said codes are identical or a transaction invalidation message (512) if said codes are different.

[Claim 7] Bank transaction system comprising at least one bank transaction server (4, 4 '), a first terminal (2) of a user (1) connected to the at least one bank transaction server (4, 4 ') via a first communication channel, and a second terminal (5) of an account holder and / or of a bank card connected to at least one bank transaction server (4, 4') via a second communication channel at least logically distinct from the first communication channel characterized in that:

- the first terminal (2) is configured to send (304, 404, 405, 406), at the request of the user (1), to at least one bank transaction server (4, 4 '), a request transaction comprising at least one transaction amount (TA), and an identification (ID) of the account and / or of the bank card,

- the bank transaction server (4, 4 ’) is configured to, upon receipt (501) of the transaction request, establish (503, 504) a verification code

(AC) whose length (L) depends on the amount of the transaction (TA), determine the second terminal (5) according to the identification of the bank account to be debited, then send, on the one hand, a request ( 505) confirmation requesting the verification code from the first terminal (2) via the first communication channel and, on the other hand, the verification code (506) to the second terminal (5) via the second communication channel

- the second terminal (5) is configured to display, to the holder (1) of the bank account, the verification code sent by the bank transaction server (4, 4 '), - the first terminal (2) is configured to resend (309, 413) to the bank transaction server (4, 4 ') a code copied (AC') by the user (1) from the verification code (AC) displayed on the second terminal (5),

- the bank transaction server (4, 4 ') is configured to, on receipt (507) of the copied code (AC'), compare (508) with the verification code (AC) with the copied code (AC ') and send to the first terminal a transaction validation message (510) if the codes are identical or a transaction invalidation message (512) if the codes are different.