CN105610865A - Method and device for authenticating identity of user based on transaction data - Google Patents

Abstract

A method and apparatus for authenticating a user's identity based on transaction data. The method includes: obtaining historical transaction data associated with the account according to the account information provided by the user, generating one or more test questions according to the historical transaction data, providing the one or more test questions to the user, and receiving The user's answers to the one or more test questions, and judging whether the user passes the authentication based on the answers.

Description

A method and device for authenticating user identity based on transaction data

technical field

Embodiments of the present invention relate to identity authentication, and in particular to methods and devices for authenticating user identities based on transaction data.

Background technique

Currently, when authenticating a user's identity, the authentication server needs to rely on pre-prepared data for authentication. These data are, for example, the password set by the user when registering with the authentication server, the registered mobile phone number, the biometric information of the user such as fingerprints, or the data used for authentication in the smart card assigned to the user.

In various scenarios, users can perform identity authentication by sending required data to the authentication server. The authentication server receives data from the user, and compares these data with pre-prepared data to determine whether the user is authenticated.

Existing technologies include the following authentication schemes:

The authentication scheme using a static password includes receiving the required data from the user end, and then comparing the received data with the pre-stored password set by the user to authenticate the user identity.

An authentication scheme using a dynamic password, which includes sending a dynamic password to the user's terminal (for example, a mobile phone), and receiving the required data from the user terminal, and then comparing the received data with the previously generated dynamic password for authentication user ID.

An authentication scheme using biometric features, which includes receiving the required biometric information (for example, face, voice, iris, fingerprint) from the user end, and then combining the received biometric information with the pre-stored biometric information obtained from the user. The feature information is compared to authenticate the user's identity.

However, the above-mentioned authentication scheme cannot perform identity authentication on users who are not registered in the authentication server.

Contents of the invention

A method for authenticating user identity based on transaction data, comprising: obtaining historical transaction data associated with the account according to account information provided by the user, generating one or more test questions according to the historical transaction data, and providing the user with the one or more test questions. or a plurality of test questions, receiving answers from the user to the one or more test questions, and judging whether the user passes the authentication according to the answers.

The authentication server for authenticating user identity based on transaction data includes: a first device for obtaining historical transaction data associated with the account according to the account information provided by the user, and a second device for generating one or more transaction data based on the historical transaction data. test questions, a third device for providing the user with the one or more test questions, a fourth device for receiving answers from the user for the one or more test questions, and a fifth device , for judging whether the user has passed the authentication according to the answer.

Other features and advantages of embodiments of the invention will also be understood when read in the following description when taken in conjunction with the accompanying drawings, illustrating by way of example the principles of embodiments of the invention.

Description of drawings

Fig. 1 is a schematic diagram of a method for authenticating user identity based on transaction data according to an embodiment of the present invention.

FIG. 2 is an example of a method for authenticating user identity based on transaction data according to an embodiment of the present invention.

Fig. 3 is an interface presenting test questions according to one embodiment of the present invention.

Fig. 4 is a schematic diagram of a system for authenticating user identity based on transaction data according to an embodiment of the present invention.

detailed description

Hereinafter, the principle of the present invention will be described with reference to the embodiments. It should be understood that the given examples are only for those skilled in the art to better understand and practice the present invention, rather than limiting the scope of the present invention. Therefore, the inclusion of many specific implementation details in this specification should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as descriptions specific to the embodiments.

Fig. 1 is a schematic diagram of a method for authenticating user identity based on transaction data according to an embodiment of the present invention. The method includes the processing in blocks 110 to 150, which may be performed at the authentication server side.

In block 110, historical transaction data associated with the account is obtained from the account information provided by the user. The account is a bank account or an online payment application account. The account information may be, for example, a bank card number or an account number of a network payment application. Historical transaction data associated with an account may be obtained from a corresponding transaction database.

In block 120, one or more test questions are generated based on the historical transaction data. In other embodiments below, the method of generating test questions and the form of test questions will be described in detail.

In block 130, the one or more test questions are provided to the user. The one or more test questions may be provided to the user by sending text information, picture information, or voice information of the one or more test questions to the user's terminal, or a combination thereof. The user's terminal may be any electronic device capable of interacting with the authentication server, such as a mobile phone, a tablet computer, a notebook computer, a self-service terminal (eg, an ATM).

In block 140, responses to the one or more test questions are received from the user.

In block 150, it is determined whether the user is authenticated according to the answer. The answer from the user is compared with the answer to the test question, and when the comparison is consistent, it is determined that the user has the same identity as the user pointed to by the historical transaction data.

An advantage of the authentication scheme according to this embodiment is that the authentication server can perform identity authentication without any pre-prepared data, because historical transaction data can be requested from the bank's background system.

Another advantage of the authentication scheme according to this embodiment is that the authentication server only needs account information to perform identity authentication, so the user does not have to worry about leaking sensitive information such as name, ID number, mobile phone number, etc., because he/she does not need to provide these information. At the same time, users do not need to carry any hardware devices equipped with smart chips. Generating test questions based on the user's historical transaction data and authenticating the user's identity according to the test questions can improve the security and convenience of the authentication process.

Another advantage of the authentication scheme according to this embodiment is that the authentication method is specific to the user's transaction behavior, so even if others know the user's account information, it is difficult to pass the authentication. Compared with the authentication schemes in the prior art, the authentication scheme according to this embodiment is more reliable. At the same time, since transaction behavior changes with time, test questions can also be randomly generated, so the authentication scheme according to this embodiment can effectively prevent replay attacks.

Another advantage of the authentication scheme according to this embodiment is that when the historical transaction data is the data generated by the bank account, the authentication server does not need any pre-prepared data to perform real-name authentication on the user, because the real-name authentication of the bank account and the user Binding of personal information.

The manner in which the test questions are generated and the form of the test questions are now described.

In one embodiment, the one or more test questions may include a multiple choice question, wherein the multiple choice question requires the user to select from a plurality of options one or more transaction events associated with the account. The multiple-choice question requires the user to select one or more transaction events associated with the account from multiple options according to one or more of the following factors: time, location, transaction amount. The plurality of options may include one or more distraction options generated from the historical transaction data.

FIG. 2 is an example of a method for authenticating user identity based on transaction data according to an embodiment of the present invention. This example shows the flow of identity authentication based on bank account information.

In block 211, bank account information is submitted from the client.

In block 221, bank account information is received at the authentication server side, and historical transaction data is searched according to the account information. The authentication server can send a request containing the bank account information to the bank background system, and then receive historical transaction data from the bank background system. The historical transaction data may be historical transaction data of a specific time period.

In block 222, a plurality of options including real trade options and noise options are generated based on the historical trade data. For example, the real transaction option is the name of a merchant included in the historical transaction data, and the noise option may be the name of a merchant similar to the merchant included in the historical transaction data.

In an example, possible transaction behaviors are obtained by analyzing the user's historical transaction data, and then interference options are generated according to the possible transaction behaviors. For example, one or more merchants indicated by possible transaction behaviors are obtained by analyzing the user's historical transaction data, and then the one or more merchants are used as interference options.

Exemplarily, the interference option can be generated in the following manner: extracting transaction behavior features from historical transaction data, including transaction type, transaction location, and merchant type. Then, according to some or all of these features, merchants not included in the historical transaction data are generated as interference options. Transaction types can include dining, travel, shopping, and more. In the catering transaction type, the merchant type may include Sichuan cuisine, Japanese cuisine, etc. If the historical transaction data shows that the user made consumption at the Japanese restaurant A merchant in location A, then the authentication server can use the Japanese restaurant B near location A as an interference item.

In block 223, a plurality of options and authentication rules are sent to the client. The plurality of options may include a real deal option and a distraction option. Authentication rules are presented to the user as part of the test questions. Here, the authentication rule requires the user to select one or more transaction events associated with the account from a plurality of options according to one or more of the following factors: time, place, transaction amount. For example, an authentication rule may require the user to select a merchant from several options in order of time when the transaction occurred. As another example, authentication rules may require the user to select from a number of options merchants who have conducted transactions at a particular location. For another example, the authentication rule may require selecting merchants who have conducted transactions with a transaction amount greater than a certain value from multiple options.

In block 212, a number of options and authentication rules are presented.

In block 213, options are selected according to authentication rules.

In block 213, the selected option is sent.

In block 224, a selected option is received from the client.

In 225, judge whether the selected option is a real transaction option, that is, judge whether the selected option conforms to the historical transaction data, when it is judged to be yes, enter frame 226, when judged to be no, enter frame 228, and the authentication is passed.

In block 226, it is judged whether the selected option complies with the authentication rule, that is, whether the selected option satisfies the conditions defined by the authentication rule. When the judgment is yes, enter block 227, the authentication is passed, and when the judgment is no, enter block 228, the authentication is passed.

FIG. 3 is an exemplary interface presenting test questions according to an embodiment of the present invention. As shown in FIG. 3 , the authentication rules (or answering rules) of the test questions require the user to select 6 merchants who have consumed in the past in chronological order. Through the analysis of historical transaction data, the authentication server finds that the user of the bank card often spends in Starbucks, Conrad Restaurant, CHANNEL store, and Carpenter Lotus, so the authentication server can generate COSTA coffee and Coach stores based on such transaction behavior or consumption habits. , Metro and other interference options. Since the user's historical transaction behavior is only known to him/her, the user can select the correct merchant according to the rules. For example, the order in which the user's actual transactions occur is: Starbucks, CHANNEL, Lotus, Conrad Restaurant, Haoledi KTV, Family Mart . The user can click on the icons on the interface to generate a sequence of options, and the sequence of options is sent to the authentication server. When the authentication server judges that the option selected by the user is real and meets the order of transaction time of the authentication rules, the identity authentication is successful; otherwise, the identity authentication fails.

In one embodiment, the one or more test questions may include a fill-in-the-blank question, wherein the fill-in-the-blank question provides the user with a transaction event associated with the account and requires the user to answer one or Multiple: time, location, transaction amount; or the fill-in-the-blank question provides the user with one or more of the following factors of a transaction event associated with the account: time, location, transaction amount, and requires the user to answer the transaction event . For example, the test question may be "please enter the date of the last consumption at merchant A" or "please enter the amount of the last consumption at merchant A". Or the test question can be "please enter the name of the merchant that made purchases at location A yesterday".

In the case of a plurality of test questions, when all answers from the user are correct, it is judged that the user has passed the authentication. Preferably, when the correct rate of answers from the user is above a predetermined value (for example, 90%), it is judged that the user has passed the authentication. As such, the user does not need to remember all transaction details.

In some embodiments, where the test question is a fill-in-the-blank question, the user's answer is judged to be correct when characters from the user's answer are contained within characters of the correct answer (i.e., a partial match), or when characters from the user's answer When the numerical value of the answer and the numerical value of the correct answer are within a certain range, it is determined that the user's answer is correct. As such, the user does not need to remember all transaction details.

In one embodiment, the one or more test questions may include true or false questions based on the transaction event and one or more of the following factors of the transaction event: time, location, transaction amount.

The various blocks shown in FIGS. 1 and 2 may be viewed as method steps, and/or as operations resulting from running computer program code, and/or as multiple coupled logic constructed to implement related functions. circuit components. Although operations are depicted in the figures in a particular order, this should not be construed as requiring that these operations be performed in the particular order shown, or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

Fig. 4 is a schematic diagram of a system for authenticating user identity based on transaction data according to an embodiment of the present invention. As shown in the figure, the system for authenticating user identities based on transaction data includes a client 410 , an authentication server 420 , and a background system 430 . The backend system 430 includes a historical transaction database 431 . In a typical embodiment, the authentication server 420 receives account information from the client 410, and extracts historical transaction data from the historical transaction database 431 of the background system 430 according to the account information. Then, the authentication server 420 generates a test question according to the extracted historical transaction data, and sends the test question to the client 410 . Then, the authentication server 420 receives the answer from the client 410, and according to the answer, authenticates whether the identity of the user at the client 410 is consistent with the identity of the user indicated by the historical transaction data. It can be understood that, when the authentication server 420 generates the test questions, it can simultaneously store the answers to the corresponding test questions, so as to quickly verify the answers from the users.

Exemplary embodiments may be implemented in hardware, software or a combination thereof. For example, some aspects of the invention may be implemented in hardware, while other aspects may be implemented in software.

In one embodiment, the authentication server for authenticating user identity based on transaction data includes:

The first device is used to obtain historical transaction data associated with the account according to the account information provided by the user,

a second means for generating one or more test questions based on the historical transaction data,

a third means for providing said one or more test questions to the user,

fourth means for receiving responses from the user to the one or more test questions,

The fifth device is configured to judge whether the user has passed the authentication according to the answer.

In another embodiment, the account is a bank account or a web payment application account. The one or more test questions generated by the second device include multiple choice questions, wherein the multiple choice questions require the user to select from a plurality of options one or more transaction events associated with the account. The multiple-choice question requires the user to select one or more transaction events associated with the account from multiple options according to one or more of the following factors: time, location, transaction amount. The plurality of options includes one or more distracting options generated from the historical transaction data.

In another embodiment, said one or more test questions generated by said second device comprise fill-in-the-blank questions, wherein the fill-in-the-blank questions provide the user with a transaction event associated with the account and require the user to answer questions related to One or more of the following factors related to the transaction event: time, place, transaction amount; or the fill-in-the-blank question provides the user with one or more of the following factors of a transaction event associated with the account: time, place, transaction amount, and the user is required to answer the transaction event.

In another embodiment, said one or more test questions generated by said second device comprise true or false questions based on a transaction event and one or more of the following factors of the transaction event: time, location ,Transaction amount.

In another embodiment, the third device provides the user with the one or more test questions by sending text information, picture information, or voice information, or a combination thereof, to the user's terminal. Multiple test questions.

In another embodiment, the fifth device is configured to judge that the user has passed the authentication when all the answers from the user are correct, or judge that the user has passed the authentication when the correct rate of the answers from the user is above a predetermined value .

Although aspects of the exemplary embodiments of the present invention may be shown and described as block diagrams, flowcharts, it is well understood that these apparatuses, or methods described herein may be implemented in a system as a non-limiting example functional module. Furthermore, the above-described arrangements should not be understood as requiring such separation in all embodiments, but rather that the described program components and systems may generally be integrated in a single software product or packaged into multiple software products .

Various modifications and alterations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts to those skilled in the relevant arts, when the foregoing specification is read in conjunction with the accompanying drawings. Therefore, the embodiments of the invention are not to be limited to the particular embodiments disclosed and modifications and other embodiments are intended to be covered within the scope of the appended claims.

Claims (10)

1. the method based on transaction data authenticated user identity, is characterized in that, comprising:

Obtain the historical trading data associated with the account according to customer-furnished accounts information,

Produce one or more test problems according to these historical trading data,

Provide described one or more test problem to this user,

Receive the answer for described one or more test problems from this user, and

Judge that according to described answer whether this user is by certification.

2. the method for claim 1, is characterized in that,

The account is bank account or network payment application account.

3. the method for claim 1, is characterized in that,

Described one or more test problem comprises multiple-choice question, and wherein this multiple-choice question requires this user from multiple optionsOne or more transaction event that middle selection is associated with the account.

4. method as claimed in claim 3, is characterized in that,

This multiple-choice question require this user from multiple options according to following factor one or more select with shouldOne or more transaction event of account association: time, place, dealing money.

5. method as claimed in claim 3, is characterized in that,

Described multiple option comprises the one or more interference options that produce from these historical trading data.

6. the certificate server based on transaction data authenticated user identity, is characterized in that, comprising:

Obtain the historical trading data associated with the account according to customer-furnished accounts information,

Produce one or more test problems according to these historical trading data,

Provide described one or more test problem to this user,

Receive the answer for described one or more test problems from this user, and

Judge that according to described answer whether this user is by certification.

7. certificate server as claimed in claim 6, is characterized in that,

The account is bank account or network payment application account.

8. certificate server as claimed in claim 6, is characterized in that,

Described one or more test problem comprises multiple-choice question, and wherein this multiple-choice question requires this user from multiple optionsOne or more transaction event that middle selection is associated with the account.

9. certificate server as claimed in claim 8, is characterized in that,

This multiple-choice question require this user from multiple options according to following factor one or more select with shouldOne or more transaction event of account association: time, place, dealing money.

10. certificate server as claimed in claim 8, is characterized in that,

Described multiple option comprises the one or more interference options that produce from these historical trading data.