SYSTEM AND METHODS FOR DYNAMICALLY DETERMINED

CONTEXTUAL, USER-DEFINED, AND ADAPTIVE

AUTHENTICATION

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, U.S. Patent Application No. 16/222,780 filed on December 17, 2018. The entire disclosure of the above-referenced application is incorporated herein by reference.

BACKGROUND

The field of the invention relates generally to systems and methods for authenticating users during events that may trigger security protocols, and in particular, to user-defined, context-specific, and learned, rules and methods for engaging in authentications.

At least some known authentication procedures involve fraudulent activity. These fraudulent activities present liability issues to one or more parties involved in the transaction. For example, a visitor entering a secure area may be required to provide identification to authenticate their identity. An area which contains sensitive data, such as information related to health privacy or financial data, may require security procedures for visitors that have never been to the location before. In some cases, displaying identification or scanning access cards may be the extent of a security screening. Physical items like these may be lost or stolen and used by unauthorized individuals to gain access to restricted areas. In the event of fraudulent access, a malicious visitor of a place or malicious user of a secure system could cause irreparable harm.

Authentication procedures also apply to secure systems involving financial transactions that require multiple parties, such as an issuing bank, a merchant, a payment processing network, the user of the payment card, and an acquirer bank. As such, these parties are interested in detecting and preventing fraudulent activity. In cases of payment transactions, there exists a need to analyze the data surrounding a payment card transaction before authenticating the transaction. Analyzing the payment transaction data may be used to determine if the transaction is credible and if the transaction should proceed. Parties place themselves at risk of fraud in the absence of the ability to quickly analyze the details of the payment

transaction. For example, in online transactions through a merchant web site or “card-not-present” transactions, the merchant party in the transaction oftentimes assumes the initial liability for certain aspects of the transaction unless, for example, certain security procedures are undertaken.

Current methods of authentication are not personalized and may require actions users find inconvenient. In some cases an authentication request may be communicated to the cardholder in a way that the cardholder may not immediately receive. In addition, authentications are not situation-specific. The same

authentication types may be presented regardless of transaction amounts or proximity to a central location, such as a user residence. In addition, frequent visits to the same merchant may unnecessarily require authentications for each visit. In other situations, a visit to a place with higher potential for fraud may not require any authentication. Alerting users to heightened risks through elevated and more sophisticated authentications may potentially reduce the likelihood of users engaging in risky transactions. Instituting authentications at places associated with higher risk factors may also prevent fraud. In addition to the added convenience, a way to present users with authentication types that more accurately reflect the risk associated with certain transactions is needed.

BRIEF DESCRIPTION

In one aspect, an adaptive authentication (AA) computer device used for improved payment transaction authentication services is provided. The AA computer device comprises at least one processor in communication with at least one memory device. The AA computer device is configured to retrieve, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions. The AA computer device is also configured to generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The AA computer device is further configured to receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data

including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The AA computer device is also configured to determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The AA computer device is further configured to transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

In another aspect, a computer-implemented method for improved payment transaction authentication services is provided. The method is implemented using an adaptive authentication (AA) computer device including at least one processor in communication with at least one memory device. The method includes retrieving, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions. The method also includes generating a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The method further includes receiving pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The method further includes determining a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The method also includes transmitting to the first cardholder an authentication request of the candidate cardholder authentication type.

In a further aspect, at least one non-transitory computer-readable storage medium having computer-executable instructions for improved payment transaction authentication services is provided. When executed by an adaptive authentication (AA) computer device including at least one processor in

communication with at least one memory device, the computer executable instructions cause the AA computing device to retrieve, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder

authentication types used for each of the historical transactions. The computer executable instructions also cause the AA computing device to generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The computer executable instructions further cause the AA computing device to receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The computer executable instructions further cause the AA computing device to determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The computer executable instructions further cause the AA computing device to transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-8 show example embodiments, of the methods and systems described herein.

FIG. 1 is a schematic diagram illustrating an adaptive authentication (AA) computer system including an AA computer device in communication with a multi-party payment card processing system in accordance with one embodiment of the present disclosure.

FIG. 2 is a simplified block diagram of an example AA computer device shown in FIG. 1 in communication with example components used for AA, in accordance with one embodiment of the present disclosure.

FIG. 3 is a simplified block diagram of an example model engine for generating an output model shown in FIG. 2 for dynamically determining an authentication type, in accordance with one embodiment of the present disclosure.

FIG. 4 is a simplified block diagram of an example AA computer system using an AA computer device shown in FIG. 1.

FIG. 5 illustrates an example configuration of a client system shown in FIG. 4, in accordance with one embodiment of the present disclosure.

FIG. 6 illustrates an example configuration of a server system shown in FIG. 4, in accordance with one embodiment of the present disclosure.

FIG. 7 is a flow chart of a process for enhancing user authentication using the system shown in FIG. 1.

FIG. 8 is a diagram of components of one or more example computer devices that may be used in the system shown in FIG. 1.

DETAILED DESCRIPTION OF THE DISCLOSURE

The following detailed description illustrates embodiments of the disclosure by way of example and not by way of limitation. The description clearly enables one skilled in the art to make and use the disclosure, describes several embodiments, adaptations, variations, alternatives, and uses of the disclosure, including what is presently believed to be the best mode of carrying out the disclosure. The disclosure is described as applied to example embodiments, namely, systems and methods utilizing user configurations of authentication types and communication methods coupled with machine learning and data analysis and interpretation techniques to initiate authentication requests to cardholders using a decentralized network in real time. Systems and methods according to the disclosure herein thus provide real-time analysis of cardholder defined data, situation-specific contextual data, and adaptively learned data analysis for improved fraud prevention and cardholder convenience during transactions.

In the example embodiment, an adaptive authentication (AA) computer device for improved payment transaction authentication services is provided. The AA computer device includes at least one processor in communication with at least one memory device. The AA computer device is configured to retrieve, from a database: (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions. The AA computer device is also configured to generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data. The transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The AA computer device is further configured to receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The AA computer device is further configured to determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The AA computer device is further configured to transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

In some embodiments, the AA computer device is configured to retrieve the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

In other embodiments, each of the plurality of historical transactions is associated with the first cardholder. In yet other embodiments, each of the plurality of historical transactions is associated with a respective cardholder other than the first cardholder. In further embodiments the candidate cardholder authentication type is one of a PIN, a one-time password, a pattern code, a passcode, a digital signature, a signature capture, a biometric signature, a biometric sample, a challenge question, a low-energy infrared retinal scan, a finger vein scan, a near infrared iris scan, an optical fingerprint scan, a three-dimensional (3D) fingerprint scan, an optical palm print, a 3D facial scan, an optical facial scan, and a speech recognition sample.

In some embodiments, the AA computer device is configured to retrieve, from the database using the cardholder identifier, a preferred contact channel of the cardholder. The preferred contact channel includes at least one of a text message, an email, a telephone call, a link to a website, and a point-of-sale device. In other embodiments, the AA computer device is configured to: (i) transmit, to the cardholder associated with the cardholder identifier in response to the pending transaction data, a request to identify a preferred one of the cardholder authentication types, (ii) receive, from the cardholder, an identified one of the cardholder authentication types, (iii) update the model based on the identified cardholder

authentication type and the transaction parameters for the pending transaction, and (iv) associate the updated model in the database with the cardholder identifier.

In some embodiments, the transaction geographic location is defined relative to a cardholder’s home geographic area.

In another embodiment, a computer-implemented method for improved payment transaction authentication services is provided. The method is implemented using an adaptive authentication (AA) computer device including at least one processor in communication with at least one memory device. The computer-implemented method includes retrieving, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions. The method also includes generating a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The method further includes receiving pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The method further includes determining a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The method also includes transmitting to the first cardholder an authentication request of the candidate cardholder authentication type.

In some embodiments the method includes retrieving the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

In some embodiments, the method includes retrieving, from the database using the cardholder identifier, a preferred contact channel of the cardholder.

The preferred contact channel includes at least one of a text message, an email, a telephone call, a link to a website, and a point-of-sale device.

In other embodiments, the method includes: (i) transmitting, to the cardholder associated with the cardholder identifier in response to the pending transaction data, a request to identify a preferred one of the cardholder authentication types, (ii) receiving, lfom the cardholder, an identified one of the cardholder authentication types, (iii) updating the model based on the identified cardholder authentication type and the transaction parameters for the pending transaction, and (iv) associating the updated model in the database with the cardholder identifier.

In another embodiment, at least one non-transitory computer-readable storage medium having computer-executable instructions embodied thereon is provided. When the computer-executable instructions are executed by an adaptive authentication (AA) computer device including at least one processor in

communication with at least one memory device, the computer-executable instructions cause the at least one processor to retrieve, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder

authentication types used for each of the historical transactions. The computer executable-instructions also cause the at least one processor to generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data. The transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category. The computer executable-instructions further cause the at least one processor to receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount. The computer executable-instructions also cause the at least one processor to determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data. The computer executable-instructions further cause the at least one processor to transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

In some embodiments, the computer-executable instructions further cause the at least one processor to retrieve the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

As discussed herein, one risk-mitigating step against fraudulent payment transactions is user authentication. For example, some payment networks engage an authentication service that performs an authentication of a suspect consumer (e.g., suspect cardholder) prior to authorization of a payment transaction. The authentication service determines if the source of the payment transaction is the authorized user of the payment card and/or payment account (e.g., actual or legitimate cardholder). During such an authentication process, the suspect consumer (e.g., the person attempting to perform the payment transaction with the merchant) may be presented with an authentication request, sometimes called a“step-up challenge.”

This step-up challenge generally requires the suspect consumer to provide a password or a passcode from a second factor device (e.g., mobile phones, Smartphones, personal digital assistants (PDAs), and/or computers) before the payment transaction will be processed. For example, the step-up challenge may be provided by an authentication service such as a 3-D SECURE® protocol (3DS) (e.g., EMV® 3-D Secure by EMVCo., LLC.; Verified by Visa by Visa International Service

Association, Delaware; and MASTERCARD SECURECODE® by Mastercard International Incorporated, Purchase, New York). By obtaining this additional factor from the suspect consumer, the likelihood of the suspect consumer being a fraudulent consumer is reduced. However, this extra step presents an interruptive inconvenience, a barrier, or an interference to at least some legitimate consumers and subsequently may cause at least some consumers to abandon legitimate payment transactions.

These abandonments result in lost revenues to many parties, such as the merchant, the merchant acquirer, and the issuer. The systems and methods described herein address these problems and others described herein.

In the example embodiment, a cardholder registers with an adaptive authentication (AA) computer system for adaptive authentication services. In some

cases, this may be done by downloading an app (computer code) onto a user device and registering with the app server. In other cases, registration with the AA computer system for authentication services may be initiated by and/or at the issuing bank. In some embodiments, use of adaptive authentication services by the AA computer system may be initiated by the merchant. In some embodiments, use of certain point-of-sale (POS) devices may require and/or initiate authentication using the AA computer system. In some embodiments, registration with the AA computer system includes receiving, by the AA computer device, a cardholder identifier, cardholder preferences including preferences related to one or more authentication types used for a particular merchant location and/or a payment transaction amount. Alternatively or additionally, registration with the AA computer system may include receiving, by the AA computer device, a generalized preference for a method of contact (e.g., a contact channel) and an authentication type applicable to any payment transaction situation. For example, upon registration with the AA computer system, a user may input their personal identification information, their cardholder identifier, and authentication type preferences. Subsequent interaction with the AA computer system may allow the user to reconfigure their authentication type preferences.

In the example embodiment, the AA computer system includes at least an adaptive authentication (AA) computer device. When a cardholder executes a transaction with a merchant, the AA computer device detects the pending payment transaction across a payment processing network, assesses whether the payment transaction may be fraudulent, and determines whether the cardholder has designated a preference of an authentication type to be used for authenticating the cardholder. If the payment transaction is determined to be potentially fraudulent and the cardholder has not designated a preferred authentication type, the AA computer system may prompt the user with a request for designating an authentication type to be used in the transaction and future similar transactions (e.g., the AA computer system will send a message to the user computer device for display). Upon receiving a response, the AA computer system will initiate an authentication using the user-designated

authentication type to authenticate the cardholder and allow the payment transaction to be completed.

In some embodiments, the AA computer device determines whether an authentication is required by retrieving, from a database, historical payment transactions by the cardholder and, if an authentication occurred for the historical transaction, the respective authentication type used and the method of contact used. The AA computer device generates a model based on the historical payment transaction data. The model is then applied to the pending transaction to determine an authentication type to be used for the pending transaction.

In some embodiments, the cardholder provides preferred authentication types. For example, during registration the cardholder defines a preferred authentication type and a preferred method of contact. When a payment transaction is detected, the AA computer device generates the model based on the historical payment transaction data and modifies the model using the cardholder defined authentication type preferences. The model is then applied to pending payment transaction to determine the authentication type to use for the pending transaction.

In some embodiments, the AA computer device may prompt the cardholder to define a desired authentication type for a pending payment transaction. For example, when a payment transaction is detected, the AA computer device may cause the user device associated with the cardholder to display a dropdown menu including authentication types such as a pin number, a one-time password, or a security question. The cardholder selects, from the presented authentication types, an authentication type for the pending payment transaction. The AA computer device generates and/or refines a model including the historical data, defined cardholder authentication type preferences, and the selected authentication type. The cardholder is prompted to authenticate using the selected authentication type for the pending payment transaction and for future similar payment transactions.

In the example embodiment, if the AA computer device determines that the initial payment processing transaction is potentially fraudulent or just by merely receiving the initial payment processing transaction, the AA computing device transmits an authentication request (e.g., in the form of at least one question and/or at least a request for an authentication code) to the user computer device to authenticate the suspect cardholder to determine whether the suspect cardholder is the actual cardholder. In another embodiment, the AA computing device includes a risk-based decisioning (RBD) component or is in communication with a RBD component that evaluates the payment transaction being initiated and generates a risk score for the transaction indicating how likely the transaction is fraudulent. In one embodiment, the risk score is based, at least in part, on a history of payment transactions and whether the suspect cardholder has engaged in previous, similar transactions with the merchant. In some cases, the RBD component may score the transaction as a low fraud risk (e.g., if there is a long history of similar transactions between the merchant and suspect cardholder, etc.) in which case the AA computer device may approve the transaction without any further authentication steps. For example, the RBD component may identify one or more pieces of information about the transaction that are used to“score” the transaction for risk (e.g., potential fraud). More specifically, the RBD component may score the transaction based on several aspects including device information, account information, and characteristics of the transaction such as location, amount, and the like. In other cases, the RBD component may score the transaction as a high fraud risk, and thus, may initiate the authentication where at least one question is directed to the suspect cardholder to further authenticate.

For example, an authentication challenge may be provided by an authentication service such as a 3-D SECURE® protocol (3DS) (e.g., EMV® 3-D Secure by EMVCo., LLC.; Verified by Visa by Visa International Service

Association, Delaware; and MASTERCARD SECURECODE® by Mastercard International Incorporated, Purchase, New York). This extra step of presenting a challenge question to the suspect cardholder is to help confirm that they are the legitimate cardholder associated with the account and account number presented. The AA computing device receives input (e.g., an account identifier/number associated with the payment account, a zip code associated with the payment account, a PIN number, a password, a code transmitted to the user, etc.) via a POS, user computer device, or phone in response to the challenge. Based on the challenge response, the AA computer device determines whether the user is associated with the cardholder account and transmits an authentication response based on the determination to the merchant/issuer.

In some embodiments, device information may be evaluated such as information about the computing device used during the transaction, a unique hardware identifier, or an IP address associated with the device, etc. Account information may include information about the account being used, such as dates of use, name on the account or address associated with the account, etc. Characteristics of the transaction may include, for example, dollar amounts, a history of regular, repeated transactions between the merchant and cardholder, and a history of fraudulent transactions at the merchant and/or with the cardholder. In one

embodiment, the RBD component generates a risk score for the transaction based on

the device information, account information and/or matching information used for the transaction. The RBD component may then send the score and/or risk-based decisioning data to an issuer's access control system (ACS) for further consideration. Using this score and/or risk-based data, the issuer's ACS may then determine whether or not the suspect consumer should be further authenticated (e.g., through the 3DS “step-up” challenge) or whether the transaction can be verified without further authentication. In addition, the RBD component may provide the score to the AA computer device so it can factor it into the authentication type used for a particular transaction. In other words, if a transaction is scored as a high risk transaction by the RBD component, the AA computer device may take this score into account when determining the authentication type to be used to authenticate the cardholder. In those cases where the AA computer device authenticates the cardholder, the ACS or the issuer may not have to perform an authentication but rather may utilize the authentication process provided by the AA computer device.

In the example embodiment, a cardholder engages in a payment transaction at a merchant location. In other embodiments, the cardholder may engage in a payment transaction online, through a website, and/or through another card-not-present payment transaction. The AA computer system will receive payment transaction data for the pending payment transaction. In some embodiments, the AA computer system may monitor a payment transaction processing network for transactions being processed over the network. In some embodiments, the AA computer system may receive payment transaction data from a merchant. The payment transaction data may include a cardholder identifier for the cardholder executing the payment transaction. The payment transaction data may also include a merchant location. The payment transaction data may also include a transaction amount. In some embodiments, the payment transaction data may also include other information related to the particular product or service associated with the transaction (e.g., the product or service category, features or characteristics of the product such as the size, frequency of fraudulent transactions associated with the particular product or service, etc.).

In the example embodiment, the AA computer system builds a model using historical transaction data and the corresponding authentication types used for those historical transactions and then may modify the model based on retrieved cardholder preferences. In the example embodiment, the cardholder registers with

AA computer system and stores authentication preferences defining the authentication type to be used during a transaction. Alternatively, the cardholder may be prompted while transactions are occurring for their preferences of authentication types. The authentication type may be dependent on the type of transaction. For example, the cardholder may desire heightened authentication type(s) for transactions involving jewelry or high dollar amounts (e.g., $10,000, $50,000, $100,000, etc.). In other cases, the cardholder may desire heightened authentication types based on other factors such as payment transaction location, time of day, distance from home, and frequency of purchases at the particular merchant. In addition, the cardholder may define specific preferred authentication types for the above described scenarios (e.g., PIN, password, biometric scan, etc.). In the example embodiment, the cardholder also defines preferred methods of communication (e.g., text message, email, telephone call, a website, an app on a user device, etc.). In some embodiments, the cardholder may prefer a specific method of communication for transactions having certain variables. For example, the cardholder may prefer a telephone call for high dollar payment transactions and a text message for low dollar payment transactions. In other cases, the cardholder may prefer a telephone call based on geographical location and/or merchant type and/or category.

In some embodiments, the cardholder may not have executed any payment transactions at the particular merchant location and thus, the model may need further refining to better determine the authentication type desired by the cardholder. In such embodiments, the AA computer device may be configured to request or prompt the cardholder to provide input indicating the authentication type desired by the cardholder for a transaction at the particular merchant location by causing an input screen to be displayed on a user device of the cardholder and/or the POS. In other embodiments, the AA computer device may initiate an authentication request (e.g., request the cardholder to respond to an authentication type) using an existing cardholder preference configuration including a method of contact.

Alternatively or additionally, the authentication request may also be based on the particular transaction amount.

An alternate means of implementing the AA computer system may be to initiate an authentication request using a particular authentication type based on authentication types used by other similar cardholders at that particular merchant. In some embodiments, the particular authentication type may be dependent on the

average transaction amount at the merchant. Aggregated data may be related to cardholders by categories such as a cardholder being within a“home” district, frequency of visit, and/or average transaction amount, etc. The aggregated data may be used to determine an initial authentication type for the current cardholder awaiting authentication for the pending transaction. In some embodiments, data from other similar cardholders may be used at similar merchants at different locations. For example, a chain store in another state may use the same authentication type (e.g., one-time pass, PIN, signature, biometric, etc.) despite varying locations.

In some embodiments, the AA computer device may not have an initial cardholder’s preferred method of contact stored for the particular merchant location, payment transaction value range, and/or defined method of contact preferences. In other embodiments, the AA computer device may not have stored an initial cardholder’s preferred method of contact associated with the particular merchant location. In other embodiments, the AA computer device may not have stored an initial cardholder’s preferred method of contact associated with the particular payment amount and/or payment threshold. In these embodiments, and/or in cases where certain initial values are absent, the AA computer device may initiate an

authentication request using a default method of contact (e.g., by a telephone call, text message, and/or prompt on a user device). In some embodiments, the default method of contact may include contact information received upon registration by the cardholder to the AA computer device. For example, the AA computer device may initiate an authentication via a telephone number registered by the cardholder. In some embodiments, the default method of contact may include contact information retrieved from an issuer associated with the cardholder identifier.

In other embodiments, the AA computer device may not have stored an initial cardholder’s preference for an authentication type to be used at the particular merchant location and/or for the particular payment transaction amount. In such embodiments, and/or in cases where certain initial values are absent, the AA computer device may initiate an authentication type using a default authentication type. The default authentication type may include an authentication type based on the initial registration. The default authentication type may also be determined using authentication types used by other cardholders at the same merchant location. In some embodiments, the default authentication type may be based on an evaluation of other factors such as past fraudulent activity at the merchant location, fraudulent activity in the geographical area, fraudulent activity associated with the cardholder, fraudulent activity above and/or below certain payment amounts, fraudulent activity associated with certain products or services, cardholder convenience of authentication types, effectiveness of authentication types, cardholder convenience of methods of communication, cardholder response rates associated with specific methods of communication and/or authentication types. Additionally or alternatively, the AA computer device may be configured to request the cardholder preferences for the authentication type used for the particular payment transaction and/or future similar transactions.

In some embodiments, the history of authentication types used may be a subset of the retrieved histories of authentication types used by the cardholder. For example, the historical authentication data may be filtered to include only payment transactions for payment amounts above a threshold (e.g., payment transactions above $100, $500, $1000, etc.). In some embodiments, the history data may be organized by category (e.g., merchant type, large appliances, computers, audio equipment, groceries, restaurants, etc.). In some embodiments, the history data may be filtered by geographical location. For example, payment transactions executed within a certain radius (e.g., 20 miles) of a home or resident location associated with a cardholder. If a cardholder is engaging in purchases within a certain geographical radius of known trusted merchants, a simpler authentication type or no authentication may be preferred by the cardholder. If a cardholder is outside a certain geographical radius, heightened authentication types (e.g., biometric, telephone call, etc.) may be preferred by the cardholder. In some embodiments the cardholder may configure a“home” location defining a geographical area in which the cardholder may have a higher level of trust. The system and process described herein allows the cardholder to designate or the system determines from prior transactions the authentication type used to authenticate the suspect cardholder initiating the transaction.

In other embodiments, the historical transaction data may be organized by merchant. For example, the historical data used to generate the model may be limited to payment transactions involving authentications at a particular retail chain or particular fast food restaurant. For example, an authentication type used at a fast food establishment in one location may also be used at the same fast food establishment in different location. In another embodiment, the historical data may be limited to authentication types by other cardholders further limited by characteristics of the other cardholders (e.g., income level, frequency of transactions, history of fraudulent activity, home or resident location, etc.). For example, authentication types for individuals engaging in a high volume of transactions may use a faster form of authentication. In some embodiments, the historical data may include only authentication types selected by the cardholder in response to a prompt to select an authentication type during a transaction, or by authentication type selections by other cardholders in response to a prompt to select an authentication type at the particular merchant location.

In some embodiments, the historical data may be organized by time. For example, authentication types before a certain date may be removed or may be assigned less weight. More recently recorded authentication types may therefore be of a greater weight in subsequent analysis, for example, in a moving average. A moving average, for example, may more accurately capture changing authentication preferences by the cardholder. For example, as a cardholder becomes more familiar with a merchant, there may an increased level of trust. Subsequent transactions may therefore require only minimal authentication types such as a PIN or password, or no further authentication at all. In other cases, a cardholder may detect changes in a merchant that may warrant additional security measures. In such cases, the cardholder may desire additional and/or more secure authentication types.

WHAT IS CLAIMED IS:

1. An adaptive authentication (AA) computer device for improved payment transaction authentication services, the AA computer device comprising at least one processor in communication with at least one memory device, the AA computer device configured to:

retrieve, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions;

generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category;

receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount;

determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data; and

transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

2. The AA computer device of Claim 1, further configured to retrieve the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

3. The AA computer device of Claim 1, wherein each of the plurality of historical transactions is associated with the first cardholder.

4. The AA computer device of Claim 1 , wherein each of the plurality of historical transactions is associated with a respective cardholder other than the first cardholder.

5. The AA computer device of Claim 1, wherein the candidate cardholder authentication type is one of a PIN, a one-time password, a pattern code, a passcode, a digital signature, a signature capture, a biometric signature, a biometric sample, a challenge question, a low-energy infrared retinal scan, a finger vein scan, a near infrared iris scan, an optical fingerprint scan, a three-dimensional (3D) fingerprint scan, an optical palm print, a 3D facial scan, an optical facial scan, and a speech recognition sample.

6. The AA computer device of Claim 1, further configured to retrieve, from the database using the cardholder identifier, a preferred contact channel of the cardholder, wherein the preferred contact channel includes at least one of a text message, an email, a telephone call, a link to a website, and a point-of-sale device.

7. The AA computer device of Claim 1, further configured to: transmit, to the cardholder associated with the cardholder identifier in response to the pending transaction data, a request to identify a preferred one of the cardholder authentication types;

receive, from the cardholder, an identified one of the cardholder authentication types;

update the model based on the identified cardholder authentication type and the transaction parameters for the pending transaction; and

associate the updated model in the database with the cardholder identifier.

8. The AA computer device of Claim 1, wherein the transaction geographic location is defined relative to a cardholder home geographic area.

9. A computer-implemented method for improved payment transaction authentication services, the method implemented using an adaptive authentication (AA) computer device including at least one processor in

communication with at least one memory device, said computer-implemented method comprising:

retrieving, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions;

generating a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category;

receiving pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount;

determining a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data; and

transmitting to the first cardholder an authentication request of the candidate cardholder authentication type.

10. The computer-implemented method of Claim 9, further comprising retrieving the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

11. The computer-implemented method of Claim 9, wherein each of the plurality of historical transactions is associated with the first cardholder.

12. The computer-implemented method of Claim 9, wherein each of the plurality of historical transactions is associated with a respective cardholder other than the first cardholder.

13. The computer-implemented method of Claim 9, wherein the candidate cardholder authentication type is one of a PIN, a one-time password, a pattern code, a passcode, a digital signature, a signature capture, a biometric signature, a biometric sample, a challenge question, a low-energy infrared retinal scan, a finger vein scan, a near infrared iris scan, an optical fingerprint scan, a three-dimensional (3D) fingerprint scan, an optical palm print, a 3D facial scan, an optical facial scan, and a speech recognition sample.

14. The computer- implemented method of Claim 9, further comprising retrieving, from the database using the cardholder identifier, a preferred contact channel of the cardholder, wherein the preferred contact channel includes at least one of a text message, an email, a telephone call, a link to a website, and a point-of-sale device.

15. The computer-implemented method of Claim 9, further comprising:

transmitting, to the cardholder associated with the cardholder identifier in response to the pending transaction data, a request to identify a preferred one of the cardholder authentication types;

receiving, from the cardholder, an identified one of the cardholder authentication types;

updating the model based on the identified cardholder authentication type and the transaction parameters for the pending transaction; and

associating the updated model in the database with the cardholder identifier.

16. At least one non-transitory computer-readable storage medium having computer-executable instructions embodied thereon, wherein when executed by an adaptive authentication (AA) computer device including at least one processor

in communication with at least one memory device, the computer-executable instructions cause the at least one processor to:

retrieve, from a database, (i) historical transaction data for a plurality of historical transactions processed over a payment processing network, and (ii) a respective one of a plurality of cardholder authentication types used for each of the historical transactions;

generate a model associating each of the plurality of cardholder authentication types with a corresponding set of values for transaction parameters derived from the historical transaction data, wherein the transaction parameters include at least one of a transaction amount range, a transaction geographic location, a merchant identifier, and a merchant category;

receive pending transaction data for a pending transaction on the payment processing network, the pending transaction data including at least a cardholder identifier of a first cardholder, a pending transaction merchant identifier, and a pending transaction amount;

determine a candidate cardholder authentication type for the pending transaction by applying the model to the transaction parameters derived from the pending transaction data; and

transmit to the first cardholder an authentication request of the candidate cardholder authentication type.

17. The non-transitory computer-readable storage medium of Claim 16, wherein the computer-executable instructions further cause the at least one processor to retrieve the historical transaction data for the plurality of historical transactions for which at least one of (i) the merchant identifier of the historical transaction data matches the pending transaction merchant identifier, (ii) the merchant category of the historical transaction data matches a pending transaction merchant category, and (iii) a transaction amount of the historical transaction data and the pending transaction amount are within the same transaction amount range.

18. The non-transitory computer-readable storage medium of Claim 16, wherein each of the plurality of historical transactions is associated with the first cardholder.

19. The non-transitory computer-readable storage medium of Claim 16, wherein each of the plurality of historical transactions is associated with a respective cardholder other than the first cardholder.

20. The non-transitory computer-readable storage medium of

Claim 16, wherein the candidate cardholder authentication type is one of a PIN, a one time password, a pattern code, a passcode, a digital signature, a signature capture, a biometric signature, a biometric sample, a challenge question, a low-energy infrared retinal scan, a finger vein scan, a near infrared iris scan, an optical fingerprint scan, a three-dimensional (3D) fingerprint scan, an optical palm print, a 3D facial scan, an optical facial scan, and a speech recognition sample.