US20160078444A1 - Systems and methods for providing fraud indicator data within an authentication protocol - Google Patents

Abstract

A computing device for providing fraud indicator data within an authentication system including an authentication protocol is provided herein. The computing device includes a processor communicatively coupled to a memory. The computing device is programmed to identify fraud feature data associated with a payment card transaction. The transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder. The computing device is further programmed to compute a first risk score for the transaction based at least in part on the fraud feature data. The computing device is also programmed to generate a message in the authentication protocol, the message including at least one extension field. The first risk score is included within the extension field. The computing device is still further programmed to transmit the message with the first risk score to a party associated with the transaction for use during authentication of the transaction.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims priority to U.S. Provisional Patent Application Ser. No. 62/051,150, filed Sep. 16, 2014, which is incorporated herein by reference in its entirety.
BACKGROUND OF THE DISCLOSURE
• This invention relates generally to risk and fraud associated with payment card transactions and, more particularly, to network-based systems and methods for providing risk analysis and decision-making services for a merchant while processing payment card transactions.
• At least some known credit/debit card purchases involve fraudulent activity. These fraudulent transactions present liability issues to one or more parties involved in the transaction, such as an issuing bank, a merchant, a payment processing network, or an acquirer bank. As such, these parties are interested in fraud detection, or the ability to analyze the data surrounding a payment card transaction before authorizing the transaction. Accordingly, a technical solution is desirable that provides a risk-based evaluation and a decisioning service to one or more of the parties during a payment card transaction.
BRIEF DESCRIPTION OF THE DISCLOSURE
• In one aspect, a computing device for providing fraud indicator data within an authentication system including an authentication protocol is provided. The computing device includes a processor communicatively coupled to a memory. The computing device is programmed to identify fraud feature data associated with a payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder. The computing device is further programmed to compute a first risk score for the payment card transaction based at least in part on the fraud feature data. The computing device is also programmed to generate a message in the authentication protocol, the message including at least one extension field. The first risk score is included within the at least one extension field. The computing device is still further programmed to transmit the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.
• In another aspect, a computer-based method for providing fraud indicator data within an authentication system including an authentication protocol is provided. The method is implemented using a computer device including a processor and a memory. The method includes identifying fraud feature data associated with a payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder. The method also includes computing a first risk score for the payment card transaction based at least in part on the fraud feature data. The method further includes generating a message in the authentication protocol, the message including at least one extension field. The first risk score is included within the at least one extension field. The method still further includes transmitting the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.
• In yet another aspect, at least one non-transitory computer-readable storage media having computer-executable instructions embodied thereon is provided. When executed by at least one processor, the computer-executable instructions cause the processor to identify fraud feature data associated with a payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder. The computer-executable instructions further cause the processor to compute a first risk score for the payment card transaction based at least in part on the fraud feature data. The computer-executable instructions also cause the processor to generate a message in the authentication protocol, the message including at least one extension field. The first risk score is included within the at least one extension field. The computer-executable instructions still further cause the processor to transmit the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIGS. 1-14 show example embodiments of the methods and systems described herein.
• FIG. 1 is a schematic diagram illustrating an example multi-party transaction card industry system for authorizing payment card transactions and, more specifically, for providing fraud scoring services for card-not-present transactions during user authentication and/or payment authorization of a payment-by-card transaction (e.g., online transactions involving a digital wallet).
• FIG. 2 is a simplified block diagram of an example transaction processing system (TPS) for providing risk-based decisioning services using a risk-based decisioning (RBD) system to merchants and/or merchant acquirers in payment network.
• FIG. 3 is an expanded block diagram of an example embodiment of a server architecture of a transaction processing network including a TPS, an RBD system, and an authentication service, that may be used to perform various authentication services for a payment card transaction.
• FIG. 4 illustrates an example configuration of a user system operated by a user such as the cardholder shown inFIG. 1.
• FIG. 5 illustrates an example configuration of a server system such as the server system shown inFIGS. 2 and 3.
• FIG. 6 is a diagram of an example digital wallet of a cardholder.
• FIG. 7 is a data flow diagram of an example risk-based decisioning (RBD) module which generates a risk result (“risk score”) for a transaction involving a digital wallet such as digital wallet.
• FIG. 8 is a process diagram of an example process for computing risk result for a digital-wallet based payment card transaction such as the transaction shown inFIG. 7.
• FIG. 9 is a diagram of an example payment network in which a transaction processing system (TPS) facilitates risk-based decisioning of a card-not-present (CNP) payment card transaction (the “suspect transaction” or “subject transaction”) between a suspect consumer and a merchant.
• FIG. 10 is swimlane diagram illustrating an exemplary portion of an authentication request process that includes providing authentication data to an issuer during transaction authentication.
• FIG. 11 is an example method for risk-based analysis of a payment card transaction using, for example, the risk-based decisioning (RBD) system shown inFIGS. 7-9 in the example environment shown inFIG. 1.
• FIG. 12 is an example method for providing risk-based decisioning to a merchant during payment card transactions in the example environment shown inFIG. 1.
• FIG. 13 is an example method for providing fraud data within an authentication system including an authentication protocol.
• FIG. 14 shows an example configuration of a database within a computing device, along with other related computing components, that may be used to analyze of a payment card transaction for risk, to provide risk-based decisioning to a merchant during payment card transactions, and/or to provide fraud data within an authentication system including an authentication protocol.
• Like numbers in the Figures indicate the same or functionally similar components.
DETAILED DESCRIPTION OF THE DISCLOSURE
• Systems and methods are described herein for evaluating payment card transactions for fraud. In one aspect, systems and methods are provided for performing risk-based decisioning for payment card transactions involving a digital wallet and associated data. In another aspect, systems and methods are provided for providing risk-based decisioning to merchants and/or merchant acquirers. In still another aspect, systems and methods are provided for sharing risk-based decisioning data with an issuer through use of extensions to an authentication protocol.
• Risk-based decisioning for payment card transactions involves evaluating data included within a prior authorization message of a payment card transaction. At least some known credit/debit card purchases involve the exchange of a number of payment card network messages between the merchant, acquirer, and issuer parties of a four-party interchange model. Such messages may include authorizations, advices, reversals, account status inquiry presentments, purchase returns, and chargebacks. The credit or debit card payment transaction messages may include several transaction attributes, such as, for example, primary account number (either real or virtual), transaction amount, merchant identifier, acquirer identifier (the combination of which with above uniquely identifies a merchant), transaction date-time, and address verification.
• In some situations such as in-store credit card purchases, the issuer of the credit card typically assumes liability for certain aspects of the transaction, such as chargebacks. In other situations, such as online transactions through a merchant web site, the merchant party in the transaction assumes initial liability for certain aspects of the transaction unless, for example, certain risk-mitigating steps are taken, such as an authentication step. For example, some known payment networks engage an authentication service such as a 3-D Secure® (Visa International Service Association, Delaware) (3DS) protocol (e.g., MasterCard SecureCode® (MasterCard International Incorporated, Purchase, N.Y.)) that performs an authentication of a suspect consumer prior to authorization of the transaction. During some known 3-D Secure transactions, the suspect consumer (i.e., the consumer attempting to perform the payment card transaction with the merchant) is presented with an authentication challenge, 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 user device, before the transaction will be processed. This extra step presents an interruptive inconvenience, barrier, or an interference to at least some legitimate consumers, and subsequently causes at least some consumers to abandon legitimate transactions. These abandonments results in lost revenues to both the merchant and the issuer.
• One risk-based decisioning (RBD) system described herein evaluates payment card transactions involving digital wallets. During a payment card transaction, such as an online transaction on a merchant web site, the suspect consumer uses a computing device such as a smart phone or personal computer device to login to a digital wallet. The suspect consumer selects a payment card from the digital wallet for use in the transaction, and the merchant or digital wallet provider initiates an authentication process (i.e., to gauge whether or not the suspect consumer is a privileged cardholder associated with the payment card).
• The RBD system identifies one or more pieces of information about the payment card transaction that are used to “score” the transaction for risk (e.g., potential fraud). More specifically, the RBD system scores the payment card transaction based on three aspects: device information, payment card information, and digital wallet information. Device information may include information about the computing device used during the transaction, such as a unique hardware identifier, or an IP address associated with the device. Payment card information may include information about the payment card or the privileged cardholder, such as an expiration date of the payment card or a name or a home address of the privileged cardholder. Digital wallet information may include information about the digital wallet used during the transaction, such as how the suspect consumer was authenticated into the digital wallet, whether the digital wallet has historically been used with the current computing device, or whether the shipping address of the current transaction is a shipping address previously used with the digital wallet.
• In one embodiment, the RBD system generates a device score from the device information and a digital wallet score from the digital wallet information and combines these scores into a session trust level. The session trust level generally indicates a confidence as to whether or not the user of the device and wallet is the privileged cardholder. This level may be a level such as, for example, one of “basic”, “good”, “excellent”, and “trusted.” The RBD system also generates a payment card score from the payment card information and combines the payment card score with the session trust level to generate an overall transaction risk level for the payment card transaction. From this overall transaction risk level, the RBD system generates a baseline recommendation.
• In some embodiments, parties to the transaction (e.g., issuers) may provide to the RBD system certain transaction limits, such as a transaction amount limit for individual payment cards, a daily spend limit, or a number of transactions limit. Further, these limits may be customized based at least in part on the overall transaction risk level. For example, transactions that the RBD system scores as less risky (e.g., “excellent” or “trusted” overall risk level) may have higher thresholds (e.g., higher transaction amount limit) than transactions that the RBD system scores as more risky.
• In some embodiments, the RBD system may be provided as a service to issuing banks. In other words, the RBD system may provide scores to an issuer's access control system (ACS), and the ACS may make decisions based at least in part on the risk scores or risk data available from the RBD system.
• In another aspect described herein, the RBD system sends risk-based decisioning data to the issuer's ACS via an extension message to the 3DS protocol. For example, the RBD system may score the payment card transaction and provide an overall score and/or an overall recommendation to the issuer's ACS by embedding an XML-formatted message as a 3DS extension during the authentication process. The RBD system may send other “sub-scores” within the 3DS extension message, such as the device score, the digital wallet score, or the payment card score. In some embodiments, the RBD system may share individual risk-based data elements such as the method the suspect consumer authenticated into the digital wallet, or how long the digital wallet has been in service. Using this risk-based data, the issuer's ACS determines whether or not the suspect consumer should be further authenticated (e.g., through a 3DS “step-up” challenge).
• In yet another aspect described herein, the RBD system is presented for use by a merchant, a merchant acquirer, and/or a merchant service provider in card-not-present (CNP) transactions, such as online transactions. One risk-mitigating step for some issuers and large merchants is to perform their own risk-based decisioning on the transaction prior to authorization, such as described above. These parties may establish a custom fraud analysis system to analyze transactions for fraud. However, these systems can be resource-intensive and, as such, not feasible for smaller entities, such as small- or medium-sized merchants.
• In an example embodiment, a transaction processing system (TPS) provides merchants and/or acquiring banks an option to perform risk-based decisioning on payment card transactions prior to the normal authorization process. For certain types of transactions, merchants may retain liability for the transaction. As such, merchants may desire additional risk mitigation by analyzing transactions for potential fraud prior to accepting liability. In one embodiment, an acquiring bank may offer or provide this risk-based decisioning process to one or more of their associated merchants, and thus may engage the TPS of the payment network to perform this process for those merchant transactions. In other words, the payment network provides this service on behalf of the acquiring banks to the merchants. In another embodiment, merchants may directly engage the payment network to perform this process on behalf of the merchant. In yet another embodiment, a third-party processing service performs this process on behalf of the merchant.
• One TPS described herein engages an RBD system on behalf of the merchant, or the acquiring bank, during a payment card transaction. More specifically, at the time a transaction is initiated, the TPS receives transaction data from the merchant and/or merchant acquirer. The TPS may also identify additional data associated with the subject transaction, such as, for example, one or more of (1) information about a computing device used to conduct the subject transaction (“device information”, e.g., geo-location data of the device Internet protocol (IP) address), (2) additional payment card information not included in the transaction data (“payment card information”), (3) information about a digital wallet used to conduct the subject transaction (“digital wallet information”, e.g., whether and/or how often this particular device has been used in conjunction with this digital wallet), and (4) cart data associated with the subject transaction (“cart data”). This additional data may also be individually or collectively referred to as infrastructure data, because it refers to the infrastructure used by the TPS to process a transaction, and/or as fraud feature data because, as described below, at least some of this data may be used as part of a fraud- or risk-scoring process.
• The TPS transmits the transaction data and infrastructure data to the RBD system for scoring. The RBD system is configured to score the riskiness of the subject transaction and determine whether or not additional authentication should be initiated. More specifically, the RBD system scores the subject transaction based at least in part on the transaction data and the infrastructure data. If the score is below the pre-defined threshold (i.e., “less risky”), then the transaction will be approved at this stage and subsequently will continue through to authorization without additional authentication of the suspect consumer. If the score is above a pre-defined threshold (i.e., “more risky”), then the transaction will undergo additional, direct authentication of the suspect consumer (e.g., a 3DS “step-up” challenge). In the former case, the merchant may maintain liability for the subject transaction, but under the knowledge that the RBD system has analyzed the transaction for fraud prior to completion. In the latter case, the suspect consumer is challenged during the transaction, thus providing additional authentication of the suspect consumer in those situations where the transaction seems most risky.
• At least one of the technical problems addressed by this system includes: (i) high network load based at least in part on step-up challenging most or all card-not-present transactions which results in network delays and reduced bandwidth; (ii) allowing fraudulent transactions to be successfully processed if there is no step-up challenge of a card-not-present transaction; (iii) consumer inconvenience during card-not-present transactions based at least in part on having to answer an additional authentication challenge during a transaction; (iv) abandonment of transactions by consumers when faced with a step-up challenge, thus leading to lost sales for merchants and lost processing fees for the other network parties based on those abandoned transactions; (v) unavailability of customizable fraud-related services to merchants and/or merchant acquirers; (vi) increased risk with merchant liability for fraudulent transactions; (vii) digital wallet-related fraud; (viii) issuers having limited access to some data that may be used to fraud-score transactions.
• A technical effect of the systems and processes described herein is achieved by performing at least one of the following steps: (i) identifying fraud feature data associated with a payment card transaction, the payment card transaction including a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder; (ii) computing a first risk score for the payment card transaction based at least in part on the fraud feature data; (iii) generating a message in the authentication protocol, the message including at least one extension field, wherein the first risk score is included within the at least one extension field; and (iv) transmitting the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.
• The technical effect achieved by this system is at least one of: (i) reducing the amount of network and computing resources needed to reduce the number of fraudulent transactions processed by the payment network; (ii) reducing the number of fraudulent transactions being processed; (iii) reducing consumer inconvenience during card-not-present transactions; (iv) reducing the number of transactions that are abandoned by consumers when faced with an additional authentication challenge, and thus reducing lost sales for the merchant and reducing lost fees for the other network parties based on those abandoned transactions; (v) enabling liability shift to issuing banks for some transactions; (vi) providing additional fraud-related data to issuers during authentication and/or authorization of transactions; (vii) including digital wallet-related data in fraud scoring of transactions; (vii) providing a risk-based decisioning service to issuers that includes digital wallet-related data; (viii) providing a risk-based decisioning service to merchants and/or merchant acquirers when issuers are not participating; (ix) enabling merchants and/or issuers to customize how their transactions are risk-scored and authenticated. For example, network resources and computing resources are reduced by reducing the number of step-up challenges being performed, and thus the number of messages transmitted and processed across the network. Instead of requiring a step-up challenge on each and every card-not-present transaction, the present system intelligently determines which transactions require the step-up challenge and which do not. One or more of the parties to the transaction are benefited by the system by, for example, less burden on the consumer to further authenticate themselves during the transaction, and fewer abandoned transactions for the merchant (e.g., lost sales), and for the acquiring bank, network, and issuer (e.g., lost transaction processing fees).
• As used herein, the term “authentication” (or an “authentication process”) is used generally to refer to a process conducted on a payment transaction prior to the “authorization” of a transaction (or an “authorization process”). At least one purpose of the authentication process is to evaluate whether or not the person conducting the transaction (the “suspect consumer”) is actually a person privileged to use the payment card presented in the transaction (the “privileged cardholder”). For example, issuers may want to authenticate an online transaction to evaluate whether or not the user of a computing device conducting the online transaction is really the privileged cardholder. An authentication process may be used to reduce fraudulent transactions, and thus protect one or more parties to the transaction (e.g., the merchant, or the issuer of the subject payment card).
• As used herein, a processor may include any programmable system including systems using micro-controllers, reduced instruction set circuits (RISC), application specific integrated circuits (ASICs), logic circuits, and any other circuit or processor capable of executing the functions described herein. The above examples are example only, and are thus not intended to limit in any way the definition and/or meaning of the term “processor.”
• As used herein, the terms “software” and “firmware” are interchangeable, and include any computer program stored in memory for execution by a processor, including RAM memory, ROM memory, EPROM memory, EEPROM memory, and non-volatile RAM (NVRAM) memory. The above memory types are example only, and are thus not limiting as to the types of memory usable for storage of a computer program.
• In one embodiment, a computer program is provided, and the program is embodied on a computer readable medium. In an example embodiment, the system is executed on a single computer system, without requiring a connection to a sever computer. In a further embodiment, the system is being run in a Windows® environment (Windows is a registered trademark of Microsoft Corporation, Redmond, Wash.). In yet another embodiment, the system is run on a mainframe environment and a UNIX® server environment (UNIX is a registered trademark of X/Open Company Limited located in Reading, Berkshire, United Kingdom). The application is flexible and designed to run in various different environments without compromising any major functionality. In some embodiments, the system includes multiple components distributed among a plurality of computing devices. One or more components may be in the form of computer-executable instructions embodied in a computer-readable medium. The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process can also be used in combination with other assembly packages and processes.
• As used herein, the terms “transaction card,” “financial transaction card,” and “payment card” refer to any suitable transaction card, such as a credit card, a debit card, a prepaid card, a charge card, a membership card, a promotional card, a frequent flyer card, an identification card, a prepaid card, a gift card, and/or any other device that may hold payment account information, such as mobile phones, Smartphones, personal digital assistants (PDAs), key fobs, digital wallets, and/or computers. Each type of transactions card can be used as a method of payment for performing a transaction. As used herein, the term “payment account” is used generally to refer to the underlying account with the transaction card. In addition, cardholder card account behavior can include but is not limited to purchases, management activities (e.g., balance checking), bill payments, achievement of targets (meeting account balance goals, paying bills on time), and/or product registrations (e.g., mobile application downloads).
• The following detailed description illustrates embodiments of the disclosure by way of example and not by way of limitation. It is contemplated that the disclosure has general application to processing financial transaction data by a third party in industrial, commercial, and residential applications.
• As used herein, an element or step recited in the singular and proceeded with the word “a” or “an” should be understood as not excluding plural elements or steps, unless such exclusion is explicitly recited. Furthermore, references to “example embodiment” or “one embodiment” of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.
• FIG. 1 is a schematic diagram illustrating an example multi-party transactioncard industry system20 for authorizing payment card transactions and, more specifically, for providing fraud scoring services for card-not-present transactions during user authentication and/or payment authorization of a payment-by-card transaction (e.g., online transactions involving a digital wallet). Embodiments described herein may relate to a transaction card system, such as a credit card payment system using the MasterCard® interchange network. The MasterCard® interchange network is a set of proprietary communications standards promulgated by MasterCard International Incorporated® for the exchange of financial transaction data and the settlement of funds between financial institutions that are members of MasterCard International Incorporated®. (MasterCard is a registered trademark of MasterCard International Incorporated located in Purchase, N.Y.).
• In a typical transaction card system, a financial institution called the “issuer” issues a transaction card, such as a credit card, to a consumer orcardholder22, who uses the transaction card to tender payment for a purchase from amerchant24. To accept payment with the transaction card,merchant24 must normally establish an account with a financial institution that is part of the financial payment system. This financial institution is usually called the “merchant bank,” the “acquiring bank,” or the “acquirer.” Whencardholder22 tenders payment for a purchase with a transaction card,merchant24 requests authorization from amerchant bank26 for the amount of the purchase. The request may be performed over the telephone, but is usually performed through the use of a point-of-sale terminal, which reads cardholder's22 account information from a magnetic stripe, a chip, or embossed characters on the transaction card and communicates electronically with the transaction processing computers ofmerchant bank26. Alternatively,merchant bank26 may authorize a third party to perform transaction processing on its behalf. In this case, the point-of-sale terminal will be configured to communicate with the third party. Such a third party is usually called a “merchant processor,” an “acquiring processor,” or a “third party processor.”
• Using aninterchange network28, computers ofmerchant bank26 or merchant processor will communicate with computers of anissuer bank30 to determine whether cardholder's22account32 is in good standing and whether the purchase is covered by cardholder's22 available credit line. Based on these determinations, the request for authorization will be declined or accepted. If the request is accepted, an authorization code is issued tomerchant24.
• When a request for authorization is accepted, the available credit line of cardholder's22account32 is decreased. Normally, a charge for a payment card transaction is not posted immediately to cardholder's22account32 because bankcard associations, such as MasterCard International Incorporated®, have promulgated rules that do not allowmerchant24 to charge, or “capture,” a transaction until goods are shipped or services are delivered. However, with respect to at least some debit card transactions, a charge may be posted at the time of the transaction. Whenmerchant24 ships or delivers the goods or services,merchant24 captures the transaction by, for example, appropriate data entry procedures on the point-of-sale terminal. This may include bundling of approved transactions daily for standard retail purchases. Ifcardholder22 cancels a transaction before it is captured, a “void” is generated. Ifcardholder22 returns goods after the transaction has been captured, a “credit” is generated.Interchange network28 and/orissuer bank30 stores the transaction card information, such as a type of merchant, amount of purchase, date of purchase, in a database120 (shown inFIG. 2).
• After a purchase has been made, a clearing process occurs to transfer additional transaction data related to the purchase among the parties to the transaction, such asmerchant bank26,interchange network28, andissuer bank30. More specifically, during and/or after the clearing process, additional data, such as a time of purchase, a merchant name, a type of merchant, purchase information, cardholder account information, a type of transaction, savings information, itinerary information, information regarding the purchased item and/or service, and/or other suitable information, is associated with a transaction and transmitted between parties to the transaction as transaction data, and may be stored by any of the parties to the transaction.
• After a transaction is authorized and cleared, the transaction is settled amongmerchant24,merchant bank26, andissuer bank30. Settlement refers to the transfer of financial data or funds among merchant's24 account,merchant bank26, andissuer bank30 related to the transaction. Usually, transactions are captured and accumulated into a “batch,” which is settled as a group. More specifically, a transaction is typically settled betweenissuer bank30 andinterchange network28, and then betweeninterchange network28 andmerchant bank26, and then betweenmerchant bank26 andmerchant24.
• In some embodiments, the payment card transaction is a card-not-present transaction conducted, for example, with a payment card in a digital wallet.Network28 includes a risk-based decisioning (RBD) module (not separately shown inFIG. 1) that is configured to analyze various data associated with the payment card transaction and provide various services to one or more parties involved in the payment card transaction, such asmerchant24 andissuer30. In one embodiment, during an authentication process for the payment card transaction, the RBD module generates a risk score for the payment card transaction using payment card data, device information, and digital wallet information used during the transaction. In another embodiment, the RBD module generates and transmits extension messages to an issuer in a 3DS protocol for use by the issuer to determine, using their own risk-based decisioning system, whether or not to prompt the cardholder for a further verification (e.g., issue a step-up challenge). The messages include elements of data from one or more of the payment card data, the device information data, and the digital wallet information. In yet another embodiment, the RBD module scores the payment card transaction on behalf of the merchant and provides notification to the merchant regarding transaction risk.
• FIG. 2 is a simplified block diagram of an example transaction processing system (TPS)101 for providing risk-based decisioning services using anRBD system121 to merchants and/or merchant acquirers inpayment network100. In some embodiments,network100 is similar to payment network20 (shown inFIG. 1). In the example embodiment,network100 includes a plurality of computer devices connected in communication in accordance with the present disclosure.Network100 includes aserver system112 ofTPS101 in communication with a point-of-sale (POS) terminal118 at a merchant location24 (shown inFIG. 1), and/orother client systems114 associated with merchants, merchant banks, payment networks, and/or issuer banks.
• More specifically, in the example embodiment,TPS101 includes aserver system112 of, for example, apayment processing network28, in communication with a point-of-sale (POS) terminal118 at amerchant location24, and/orother client systems114 associated with merchants, merchant banks, payment networks, and/or issuerbanks Server system112 is also in communication with a plurality of client sub-systems, also referred to asclient systems114. In one embodiment,client systems114 are computers including a web browser, such thatserver system112 is accessible toclient systems114 using the Internet.Client systems114 are interconnected to the Internet through many interfaces including anetwork115, such as a local area network (LAN) or a wide area network (WAN), dial-in-connections, cable modems, special high-speed Integrated Services Digital Network (ISDN) lines, and RDT networks.Client systems114 could be any device capable of interconnecting to the Internet including a web-based phone, PDA, or other web-based connectable equipment.
• In the example embodiment,TPS101 also includesPOS terminals118, which may be connected toclient systems114 and may be connected toserver system112.POS terminals118 may be interconnected to the Internet (or any other network that allows thePOS terminals118 to communicate as described herein) through many interfaces including a network, such as a local area network (LAN) or a wide area network (WAN), dial-in-connections, cable modems, wireless modems, and special high-speed ISDN lines.POS terminals118 could be any device capable of interconnecting to the Internet and including an input device capable of reading information from a cardholder's financial transaction card. In some embodiments,POS terminal118 may be a cardholder's personal computer, such as when conducting an online purchase through the Internet. As used herein, the terms POS device, POS terminal, and point of interaction device are used broadly, generally, and interchangeably to refer to any device in which a cardholder interacts with a merchant to complete a payment card transaction.
• Adatabase server116 is connected todatabase120, which contains information on a variety of matters, as described below in greater detail. In one embodiment,centralized database120 is stored onserver system112 and can be accessed by potential users at one ofclient systems114 by logging ontoserver system112 through one ofclient systems114. In an alternative embodiment,database120 is stored remotely fromserver system112 and may be non-centralized.
• Database120 may include a single database having separated sections or partitions or may include multiple databases, each being separate from each other.Database120 may store transaction data generated as part of sales activities and savings activities conducted over the processing network including data relating to merchants, account holders or customers, issuers, acquirers, savings amounts, savings account information, and/or purchases made.Database120 may also store account data including at least one of a cardholder name, a cardholder address, an account number, and other account identifier.Database120 may also store merchant data including a merchant identifier that identifies each merchant registered to use the network, and instructions for settling transactions including merchant bank account information.Database120 may also store purchase data associated with items being purchased by a cardholder from a merchant, and authorization request data.Database120 may also store digital wallet information, device information, payment card information, scoring rules, risk thresholds, and other data involved with providing risk-based decisioning to one or more parties to the transaction.
• In the example embodiment, one ofclient systems114 may be associated with acquirer bank26 (shown inFIG. 1) while another one ofclient systems114 may be associated with issuer bank30 (shown inFIG. 1).POS terminal118 may be associated with a participating merchant24 (shown inFIG. 1) or may be a computer system and/or mobile system used by a cardholder making an on-line purchase or payment.Server system112 may be associated withinterchange network28 or a payment processor. In the example embodiment,server system112 is associated with a network interchange, such asinterchange network28, and may be referred to as an interchange computer system or a payment processing computing device.Server system112 may be used for processing transaction data. In addition,client systems114 and/orPOS terminal118 may include a computer system associated with at least one of an online bank, a bill payment outsourcer, an acquirer bank, an acquirer processor, an issuer bank associated with a transaction card, an issuer processor, a remote payment system, a token requestor, a token provider, and/or a biller.
• In some embodiments,TPS101 is in communication withRBD system121 and anauthentication service123. In some embodiments,RBD system121 and/orauthentication service123 are third-party systems. In other embodiments, one or more ofRBD system121 and/orauthentication service123 may be a part ofTPS101. In some embodiments,RBD system121 and/orauthentication service123 are in communication with each other and may directly interact during the processing of payment card transactions. In the example embodiment,RBD system121 performs fraud scoring on payment card transactions, andauthentication service123 provides additional authentication services for suspect consumers during the payment card transaction ifRBD system121 generates a score above a pre-defined threshold (i.e., indicating that the transaction is of greater risk from a fraud perspective). In some embodiments,RBD system121 and/orauthentication service122 are also in communication with a merchant system and/or an issuer system (e.g., computer114) and/orPOS terminal118 of the merchant.
• FIG. 3 is an expanded block diagram of an example embodiment of a server architecture of atransaction processing network122 including a transaction processing system (TPS)101, anRBD system121, and anauthentication service123, that may be used to perform various authentication services for a payment card transaction. Components insystem122, identical to components of system100 (shown inFIG. 2), are identified inFIG. 3 using the same reference numerals as used inFIG. 2.Transaction processing system122 includesserver system112,client systems114, andPOS terminals118.Server system112 further includesdatabase server116, atransaction server124, aweb server126, a fax server128, a directory server130, and a mail server132. Astorage device134 is coupled todatabase server116 and directory server130.Servers116,124,126,128,130, and132 are coupled in a local area network (LAN)136. In addition, anissuer bank workstation138, anacquirer bank workstation140, and a thirdparty processor workstation142 may be coupled to LAN136. In the example embodiment,issuer bank workstation138,acquirer bank workstation140, and thirdparty processor workstation142 are coupled to LAN136 usingnetwork connection115.Workstations138,140, and142 are coupled to LAN136 using an Internet link or are connected through an Intranet.
• Eachworkstation138,140, and142 is a personal computer having a web browser. Although the functions performed at the workstations typically are illustrated as being performed atrespective workstations138,140, and142, such functions can be performed at one of many personal computers coupled to LAN136.Workstations138,140, and142 are illustrated as being associated with separate functions only to facilitate an understanding of the different types of functions that can be performed by individuals having access to LAN136.
• Server system112 is configured to be communicatively coupled to various individuals, includingemployees144 and to third parties, e.g., account holders, customers, auditors, developers, cardholders (i.e., consumers), merchants, acquirers, issuers, etc.,146 using an ISP Internet connection148. The communication in the example embodiment is illustrated as being performed using the Internet, however, any other wide area network (WAN) type communication can be utilized in other embodiments, i.e., the systems and processes are not limited to being practiced using the Internet. In addition, and rather thanWAN150, local area network136 could be used in place ofWAN150.
• In the example embodiment, any authorized individual having aworkstation154 can accesssystem122. At least one of the client systems includes amanager workstation156 located at a remote location.Workstations154 and156 are personal computers having a web browser. Also,workstations154 and156 are configured to communicate withserver system112. Furthermore, fax server128 communicates with remotely located client systems, including aclient system156 using a telephone link. Fax server128 is configured to communicate withother client systems138,140, and142 as well.
• FIG. 4 illustrates an example configuration of auser system202 operated by auser201, such as cardholder22 (shown inFIG. 1). In some embodiments,user system202 is a merchant system and/or a merchant POS device. In the example embodiment,user system202 includes aprocessor205 for executing instructions. In some embodiments, executable instructions are stored in amemory area210.Processor205 may include one or more processing units, for example, a multi-core configuration.Memory area210 is any device allowing information such as executable instructions and/or written works to be stored and retrieved.Memory area210 may include one or more computer readable media.
• User system202 also includes at least onemedia output component215 for presenting information touser201.Media output component215 is any component capable of conveying information touser201. In some embodiments,media output component215 includes an output adapter such as a video adapter and/or an audio adapter. An output adapter is operatively coupled toprocessor205 and operatively couplable to an output device such as a display device, a liquid crystal display (LCD), organic light emitting diode (OLED) display, or “electronic ink” display, or an audio output device, a speaker or headphones.
• In some embodiments,user system202 includes aninput device220 for receiving input fromuser201.Input device220 may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel, a touch pad, a touch screen, a gyroscope, an accelerometer, a position detector, or an audio input device. A single component such as a touch screen may function as both an output device ofmedia output component215 andinput device220.User system202 may also include acommunication interface225, which is communicatively couplable to a remote device such asserver system112.Communication interface225 may include, for example, a wired or wireless network adapter or a wireless data transceiver for use with a mobile phone network, Global System for Mobile communications (GSM),3G, or other mobile data network or Worldwide Interoperability for Microwave Access (WIMAX).
• Stored inmemory area210 are, for example, computer readable instructions for providing a user interface touser201 viamedia output component215 and, optionally, receiving and processing input frominput device220. A user interface may include, among other possibilities, a web browser and client application. Web browsers enable users, such asuser201, to display and interact with media and other information typically embedded on a web page or a website fromserver system112. A client application allowsuser201 to interact with a server application fromserver system112.
• In the example embodiment,computing device202 is a user computing device from whichuser201 engages with a digital wallet (not shown inFIG. 3), an online merchant (e.g.,merchant24, shown inFIG. 1), a network (e.g.,network28, shown inFIG. 1), and an issuer of a payment card (e.g.,issuer30, shown inFIG. 1) to perform a transaction which undergoes a user authentication process.
• FIG. 5 illustrates an example configuration of aserver system301 such as server system112 (shown inFIGS. 2 and 3).Server system301 may include, but is not limited to,database server116,web server126,application server124,RBD system121,TPS101, and/orauthentication service123.
• Server system301 includes aprocessor305 for executing instructions. Instructions may be stored in amemory area310, for example.Processor305 may include one or more processing units (e.g., in a multi-core configuration) for executing instructions. The instructions may be executed within a variety of different operating systems on theserver system301, such as UNIX, LINUX, Microsoft Windows®, etc. It should also be appreciated that upon initiation of a computer-based method, various instructions may be executed during initialization. Some operations may be required in order to perform one or more processes described herein, while other operations may be more general and/or specific to a particular programming language (e.g., C, C#, C++, Java, or other suitable programming languages, etc.).
• Processor305 is operatively coupled to acommunication interface315 such thatserver system301 is capable of communicating with a remote device such as user system202 (shown inFIG. 4) or anotherserver system301. For example,communication interface315 may receive requests fromuser system114 via the Internet, as illustrated inFIGS. 2 and 3.
• Processor305 may also be operatively coupled to astorage device134.Storage device134 is any computer-operated hardware suitable for storing and/or retrieving data. In some embodiments,storage device134 is integrated inserver system301. For example,server system301 may include one or more hard disk drives asstorage device134. In other embodiments,storage device134 is external toserver system301 and may be accessed by a plurality ofserver systems301. For example,storage device134 may include multiple storage units such as hard disks or solid state disks in a redundant array of inexpensive disks (RAID) configuration.Storage device134 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
• In some embodiments,processor305 is operatively coupled tostorage device134 via astorage interface320.Storage interface320 is any component capable of providingprocessor305 with access tostorage device134.Storage interface320 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or anycomponent providing processor305 with access tostorage device134.
• Memory area310 may include, but are not limited to, random access memory (RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (NVRAM). The above memory types are exemplary only, and are thus not limiting as to the types of memory usable for storage of a computer program.
• In the example embodiment,server system301 is a risk-based decisioning (RBD) system in communication with one or more ofissuer30 andmerchant24 during a payment card transaction involving a digital wallet of a user.RBD system301 performs risk analysis of the payment card transaction and provides one or more authentication-related services during the transaction.
• FIG. 6 is a diagram of an exampledigital wallet600 of acardholder602. During a payment card transaction, a suspect consumer (not shown) presents apayment card620 fromdigital wallet600 to a merchant (e.g.,merchant24, shown inFIG. 1) to purchase goods or services. A risk-based decisioning (RBD) module (not shown inFIG. 6) uses various data aboutdigital wallet600 to perform one or more authentication services associated with the payment card transaction. In other words, the RBD module will help determine whether or not the suspect consumer (i.e., the person usingdigital wallet600 during this transaction) is the privileged cardholder (e.g.,cardholder602, “A. Smith”).
• In the example embodiment,digital wallet600 includesdevices data610,payment cards data620,loyalty cards data630, andpersonal data640.Digital wallet600 may also include access method data, biometric data, and behavioral information. Some or all of this data may be stored in a centralized database (e.g.,database120, shown inFIG. 2), on a user's device (e.g., device612), atnetwork28,merchant24, and/or issuer30 (all shown inFIG. 1). This data may also be individually or collectively referred to as infrastructure data, because it refers to the infrastructure used by the TPS to process a transaction, and/or as fraud feature data because, as described below, at least some of this data may be used as part of a fraud- or risk-scoring process.
• Device data610 includes data about devices somehow associated withdigital wallet600.Device data610 may include data associated with one ormore devices612,614,616 that have historically been used during past payment card transactions. Further,device data610 may include data about a device currently being used for a present payment card transaction. For example,devices data610 may include an Internet Protocol (IP) address, a media access control (MAC) address, or other identifier that may be used to identifyparticular devices612,614,618. In some embodiments,device data610 may include a fraudulent device status (e.g., whether the device has been involved in past fraudulent transactions).
• Digital wallet600, in the example embodiment, also includespayment cards data620 for one ormore payment cards622. During the life of a digital wallet,cardholder602 may enter one ormore payment cards622 intodigital wallet600 for use in payment card transactions.Payment cards data620 may include, for example, payment card authorization numbers (PANs), expiration dates, issuing bank names, associated security codes (e.g., a CVC2 code), cardholder name, tokens representing or otherwise associated with payment cards, and other data associated withpayment cards622.
• In some embodiments,payment cards data620 includes whichpayment cards622 were used with whichdevices612. Further, in some embodiments,payment cards data620 includes an age ofpayment card622 withindigital wallet600. In other words,digital wallet600 tracks how long eachpayment card622 has been loaded intodigital wallet600. Further, in some embodiments,payment cards data620 includes a history of card authentications forpayment cards622. For example, one payment card may have been successfully or unsuccessfully 3DS-authenticated, or secure-code authenticated, several times in the past. For example, if a payment card is used fromdigital wallet600 for a past legitimate transaction (e.g., one not associated with a chargeback) then, controlling for all other variables, a subsequent transaction with that payment card/digital wallet may be scored in such a way indicating that the subsequent transaction is less risky from a fraud perspective. Similarly, if there are fraudulent transactions and/or transactions that result in a chargeback, then the subsequent transaction with that payment card/digital wallet may be scored in such a way indicating that the subsequent transaction is risker from a fraud perspective. Such data may be tied to a particular payment card, a particular digital wallet, and/or a particular device.
• In some embodiments,payment cards data620 includes data indicating howpayment cards622 were loaded into digital wallet600 (e.g., manually entered by a user, loaded by the issuing bank or the digital wallet provider). In some embodiments,payment cards data620 includes status data for payment cards622 (e.g., whether a card is “blacklisted”, has a prior history of fraudulent transactions, has a clean prior history). In some embodiments,payment cards data620 includes transaction amount limits, daily spending limits, weekly spending limits, and/or a number of transactions limit associated withpayment card622. In some embodiments,payment cards data620 includes the number of wallets into which aparticular payment card622 has been loaded, and/or a number of merchant sites into which the particular payment card has been loaded.
• In some embodiments,device data610 and/orpayment card data620 may include a recognized secure element such as, for example, a token associated with a particular device and/or payment card (e.g., as with MasterCard® Digital Enablement Service (MDES), or Digital Secure Remote Payments (DSRP)). In some embodiments, this secure element may be provided by a piece of hardware such as a separate computing device that is separated from the device being used in the payment card transaction. For example, during a prior payment card transaction involvingdigital wallet600, the secure element is generated and/or validated as a part of the transaction, and subsequently associated with digital wallet600 (e.g., as a part ofdevice data610 or payment card data620). Then during a later transaction, a current secure element provided as a part of the transaction (e.g., by a mobile phone accessingdigital wallet600 for the transaction) may be compared to the prior secure element indevice data610 and/orpayment card data620. If the current secure element is recognized as previously used, the current transaction may be scored “less risky” than the alternative. As such, this may also result in an improved cardholder experience, as it may decrease the likelihood of a step-up challenge to the cardholder.
• In the example embodiment,digital wallet600 also includesloyalty cards data630 for one or more loyalty programs. Some merchants provide loyalty (“rewards”) programs for their regular customers, such as to incentivize more purchases by the accountholder (e.g., cardholder302). Some digital wallets, including the exampledigital wallet600, enablecardholders602 to loadloyalty cards632 into the digital wallet (in addition to payment cards622). As such,loyalty cards data630 includes data such as an account number (i.e., unique identifier identifying the cardholder's account), a merchant name, and a cardholder name.
• Digital wallet600, in the example embodiment, also includespersonal data640 associated withcardholder602.Digital wallet600 and/ormerchants24 may store personal information that is regularly used in payment card transactions so that, for example,cardholder602 can more easily populate data into a payment card transaction rather than have to remember and/or manually enter such data. For example,personal data640 may includeaddresses642 ofcardholder602, such as a home address and a work address, which may be regularly reused as mailing addresses for digital wallet purchases.
• In some embodiments,personal data640 may also include (1) information aboutdigital wallet600 such as, for example, (a) an account age for digital wallet600 (e.g., how long digital wallet has been open and/or active), and (b) a provider ofdigital wallet600. In some embodiments,personal data640 includes (2) one or more email addresses and/or phone numbers associated withcardholder602. In some embodiments,personal data640 may include (3) information associated with a plurality ofprivileged cardholders602, such as spouses.
• Additionally, in some embodiments,personal data640 may include transaction data associated with the present transaction, such as a transaction type of the present transaction. The transaction type may include E-Commerce, mobile payment using QR code, mobile payment using near-field communication (NFC), mobile payment using Bluetooth low energy (BLE), and/or mobile payment using another technology. Further, the transaction type may also include an application programming interface (API) designation used by the merchant. For example, some merchants may use a particular checkout type that utilizes a risk-based decisioning system (e.g., as described below), while other merchants may utilize data stored in the digital wallet, paired with the merchant, and then requested by the merchant at the time of the transaction.
• Further, in the example embodiment, cardholder602 (or the suspect consumer) accessesdigital wallet600 through one ormore access methods650. At least some digital wallets provide multiple avenues of access, or methods of authenticating into the digital wallet. In some embodiments,cardholder602 may authenticate intodigital wallet600 through the wallet provider. For example, the wallet provider may be an issuing bank, and may provide a user name and password to cardholder602, andcardholder602 may subsequently use that user name and password as anaccess method650. In some embodiments,cardholder602 may authenticate intodigital wallet600 through a merchant site (e.g., using a merchant-provided account). For example,cardholder602 may have a user name and password with a merchant's web site. During an online shopping experience,cardholder602 may login to the merchant's web site, select items for purchase, and selectdigital wallet600 for use in completing payment.Digital wallet600 may associate cardholder's602 merchant login account withcardholder602 and, as such, may “trust” the merchant login authentication as a successful authentication (and access method) intodigital wallet600. In some embodiments, the digital wallet provider may require an additional authentication intodigital wallet600 using the digital wallet provider's authentication service prior to “trusting” the merchant login as authentication intodigital wallet600. In some embodiments,cardholder602 may authenticate intodigital wallet600 through a payment network such asnetwork28. For example,network28 may provide a user authentication mechanism for authenticatingcardholder602 and, as such,cardholder602 may be authenticated intodigital wallet600 through this access method.
• In some embodiments,digital wallet600 also includes biometric data associated withcardholder602,payment cards622,loyalty cards632, and/ordevices612. Such biometric data may include, for example, biometric reference samples such as cardholder's602 registered (authentic) fingerprint or iris image that may be used to authenticate a suspect consumer during a payment card transaction. Further, in some embodiments,digital wallet600 includes behavioral information associated withcardholder602,digital wallet600,devices612,payment cards622,loyalty cards632, and/orpersonal data640. For example,digital wallet600 may include past use data, behavioral information, transaction history, or other behavioral data for each of these elements.
• FIG. 7 is a data flow diagram700 of an example risk-based decisioning (RBD)module750 which generates a risk result752 (“risk score”) for atransaction710 involving a digital wallet such asdigital wallet600. In some embodiments,RBD module750 is similar to RBD system121 (shown inFIGS. 2 and 3). In the example embodiment, a suspect consumer702 engages intransaction710 withmerchant24 usingdigital wallet600. For example, suspect consumer702 may usecomputing device704 to login to a website ofmerchant24 and selectdigital wallet600 for use in completingtransaction710. More specifically, suspect consumer702 may select aspecific bank card712 withindigital wallet600 to completetransaction710.RBD module750 is configured to determine if suspect consumer702 is the privileged user ofdigital wallet600 and/or payment card712 (e.g., cardholder602).
• In the example embodiment,RBD module750 generatesrisk result752 based at least in part on one or more sources of information abouttransaction710.RBD module750 is configured to consider fraud feature data such asdevice information720,digital wallet information730, andpayment card information740 when evaluating risk associated withtransaction710. In some embodiments,historical data760 andscoring rules770 may also be considered. Further, in some embodiments,risk result752 includes one or more of (1) a numerical risk value computed fortransaction710 as a whole, and (2) a risk level indicator fortransaction710 as a whole, (3) one or more risk level indicators and/or numerical risk values for one or more of (a) a device score (e.g., for device704), (b) a digital wallet score (e.g., for digital wallet600), and (c) a payment card score (e.g., for payment card712).
• In some embodiments, some or all ofdevice information720 may be received from one or more sources such as, for example, a merchant system, an issuer system, a digital wallet provider system, a third party device scoring system, and/or the suspect consumer's702device704. Additionally, in some embodiments, some or all ofdigital wallet information730 may be received byRBD module750 from one or more sources such as, for example, a payment transaction processing system such as described in reference toFIG. 10 and a third party system such as a digital wallet provider system, and/orRBD module750 may have direct access to some or all ofdigital wallet information730. Further, some or all ofpayment card information740 may be received byRBD module750 from a third party system such as a payment network system, the payment transaction processing system described in reference toFIG. 10, a merchant system, and an issuer system, and/orRBD module750 may have direct access to some or all ofpayment card information740.
• FIG. 8 is a process diagram of anexample process800 for computingrisk result752 for a digital-wallet based payment card transaction such as transaction710 (shown inFIG. 7). In the example embodiment, risk-based decisioning (RBD)module750 performsprocess800 on a computing device such as server112 (shown inFIG. 2) while in communication withnetwork28. In some embodiments,RBD module750 is in communication with one or more additional computing systems such as a merchant system, an issuer system, or one or more third-party systems.
• In the example embodiment,RBD module750 determines a device score atstep810 using atleast device information720. The device score represents one factor of risk-based evaluation, where the device score focuses on the computing device being used in the transaction (e.g.,computing device704, shown inFIG. 7). In other words, the device score relates to how much more or less likely the transaction is to be risky (e.g., fraudulent) based on information about the suspect consumer's computing device (i.e., whether or not the device is trustworthy). In the example embodiment, the device score is a level determined from the tiered set of “Basic/Can't Tell”, “Good”, and “Excellent”. In some embodiments,RBD module750 may communicate with a third party system for at least some device scoring.RBD module750 may provide at least somedevice information720,digital wallet information730, and/orpayment card information740 to the third party system.
• RBD module750, in the example embodiment, also determines an access method score atstep820 using at leastdigital wallet information730. The access method score represents a factor of risk-based evaluation, where the access method score focuses on data involving the digital wallet being used in the transaction (e.g.,digital wallet600, shown inFIGS. 6 and 7). In other words, the access method score relates to how much more or less likely the transaction is to be risky (e.g., fraudulent) based on information about the suspect consumer's digital wallet (i.e., whether or not the use of the digital wallet, or particular aspects of the digital wallet, is trustworthy).
• In the example embodiment, the access method score is a level determined from the tiered set of “None”, “Basic”, “Good”, “Excellent”, and “Trusted”.RBD module750 determines an access method score based at least in part on the access method that the suspect consumer used to authenticate into the digital wallet in use during the subject transaction. Several different avenues of access, oraccess methods650, are described above in reference toFIG. 6.RBD module750 determines the particular access method used by suspect consumer702 to authenticate withdigital wallet600 duringtransaction710 and assigns a particular level based at least in part on that access method. For example, if suspect consumer702 authenticated by providing a biometric image that was subsequently confirmed as authentic, thenRBD module750 may assign an “Excellent” level to the access method score. For another example, if suspect consumer702 authenticated with a login name and password directly with the digital wallet provider, thenRBD module750 may assign a “good” level to the access method score. This may be lower (i.e., considered “more risky” from a fraud perspective) than other levels because, for example, some login-based authentication methods may be compromised more easily than some biometric authentication methods (e.g., stolen login names and passwords, easily guessed passwords). For another example, if suspect consumer702 is cross-authenticated or “trusted” into the digital wallet based on a merchant login, thenRBD module750 may assign a “basic” level to the access method score. This may be lower (i.e., considered “more risky” from a fraud perspective) than other levels because, for example, some merchant sites may have less rigorous standards for authentication into their site (e.g., lax password strength standards, indefinite account lifetimes, longer password expiration times).
• In some embodiments,RBD module750 includes one or more additional digital wallet-based risk factors when determining the access method score. For example, in one embodiment,RBD module750 examineshistorical data760 involving past authentication results involving one or more of the subject payment card (e.g., payment card712), the subject digital wallet (e.g., digital wallet600), and/or the subject device (e.g., computing device704) and alters the access method score based on this historical data. For example,RBD module750 may adjust the access method score to indicate an increased risk of fraud if the subject payment card was used in a prior recent transaction in which an address verification system (AVS) check or a 3DS step-up was conducted but failed. In some embodiments,RBD module750 may adjust the access method score based on how recent transactions with this payment card were authenticated. For example, a recent 3DS verification success may indicate less risk for the current transaction than a recent AVS check, or than a non-verified transaction. As such,RBD module750 may raise or lower the access method score based on such historical verification data. In some embodiments,RBD module750 may examine how just the most recent transaction was authenticated, and the associated results.
• In another embodiment,RBD module750 examines past devices used during transactions involving the subject digital wallet. For example, if the subject device (e.g., computing device704) has been used several times in past, non-fraudulent transactions, then it is more likely that the subject transaction is non-fraudulent than if, for example, the subject device has never been used with, or otherwise associated to, the subject digital wallet. As such,RBD module750 may risk-score the subject transaction higher or lower based on perceived risk associated with prior-used devices.
• In yet another embodiment,RBD module750 examines how long the subject digital wallet has been in active service (e.g., how old account is), and/or the transaction volume associated with the subject digital wallet (e.g., how many total transactions have been completed, or how much total has been spent), and/or how many times the user has authenticated into the subject digital wallet. For example, if the subject digital wallet has been recently created and/or has a low volume of transactions, thenRBD module750 may risk-score the subject transaction indicating an increased risk of fraud than if the digital wallet had a long lifetime and/or a high volume of transactions.
• In still another embodiment,RBD module750 examines how long the subject payment card (e.g., payment card740) has been loaded into the subject digital wallet, and/or how the subject payment card was loaded into the wallet. For example, if the subject payment card was recently loaded into the digital wallet, and/or manually loaded into the wallet (e.g., by hand, by suspect consumer702), thenRBD module750 may risk-score the subject transaction indicating an increased risk of fraud than if the subject payment card was loaded into the wallet long ago, and/or loaded in by a more secure manner (e.g., by an issuer, or by the wallet provider).
• In another embodiment,RBD module750 examines how many cards are loaded into the subject digital wallet, and/or information comparison between multiple cards in the wallet. For example, if the subject digital wallet includes dozens ofpayment cards622, and/or the payment cards share differing names or billing addresses, thenRBD module750 may risk-score the subject transaction indicating an increased risk of fraud than if the subject digital wallet only included a few payment cards, and/or the payment cards within the wallet all shared similar names or billing addresses.
• In yet another embodiment,RBD module750 compares a shipping address of the subject transaction to shipping addresses of past transactions associated with the digital wallet. If, for example, the subject shipping address matches a shipping address previously used, and perhaps regularly used, thenRBD module750 may risk-score the subject transaction indicating a reduced risk of fraud than if the subject shipping address were one never used in past digital wallet transactions or otherwise not associated with the subject digital wallet.
• Further, in some embodiments,RBD module750 may combine one or more of the above digital-wallet-based behavioral items for risk-scoring purposes. For example,RBD module750 may examine how many times a particular payment card has been used from a particular device within this digital wallet's history.RBD module750 may risk-score the subject transaction lower risk if the subject payment card and the subject device have been used together in numerous past transactions, or may risk-score the transaction higher risk if, for example, the subject device had never been used with the subject payment card.
• In some embodiments, the device score may be determined810 using one or more data elements fromdigital wallet information730 and/orpayment card information770. Further, in some embodiments, the access method score may be determined820 using one or more data elements fromdevice information720 and/or payment card information.
• Referring now toFIG. 8, once a device score and an access method score have been determined,RBD module750 combines the device score and the access method score to generate a session trust level atstep830. In the example embodiment, as described above, the device score may be one of “Basic/Can't Tell”, “Good”, and “Excellent”, and the access method score may be one of “None”, “Basic”, “Good”, “Excellent”, and “Trusted”.RBD module750 generates a session trust level that is one of “Basic”, “Good”, “Excellent”, and “Trusted.” More specifically, the following table indicates the resultant session trust level from the two variables of device score (“Device”, vertical axis) and access method score (“Access”, horizontal axis):

• TABLE 1
  Session Trust Level

  Device
  Excellent	Good	Good	Excellent	Excellent	Trusted
  Good	Basic	Good	Good	Excellent	Excellent
  Basic	Basic	Basic	Good	Good	Excellent
  	None	Basic	Good	Excellent	Trusted	Access
  						Method

  
  where the cross-referenced value (i.e., the value within the cell having the identified device score and access score) is the session trust level for the subject transaction.
• In the example embodiment,RBD module750 determines840 a card verification score using at leastpayment card information740. In some embodiments, card verification score may be determined840 using one or more data elements fromdigital wallet information730 and/ordevice information720. The card verification score represents a factor of risk-based evaluation, where the card verification score focuses on the payment card being used in the transaction (e.g.,computing device704, shown inFIG. 7). In other words, the device score relates to how much more or less likely the transaction is to be risky (e.g., fraudulent) based on information about the payment card being presented, account details for the subject payment card, and accompanying transaction data of the subject transaction. In the example embodiment, the card verification score is a level determined from the tiered set of “Neutral/Can't Tell”, “Good”, “Excellent”, and “Trusted”. In some embodiments,RBD module750 may communicate with another system for at least some card verification scoring. The card verification score may be based on factors such as, for example, address information provided by the suspect consumer, how the payment card was loaded or added to the digital wallet, and whether the subject payment card has been used with the subject merchant.
• OnceRBD module750 has asession trust level830 and has determined840 a card verification score,RBD module750 combines these two scores into atransaction risk level850. In the example embodiment,RBD module750 uses the following table to determinetransaction risk level850 from the two variables of session trust level830 (“Session”, vertical axis) and the card verification score (“Card”, horizontal axis):

• TABLE 2
  Transaction Risk Level

  Session
  Trusted	Basic	Excellent	Trusted	Trusted
  Excellent	Basic	Good	Excellent	Trusted
  Good	Basic	Good	Good	Excellent
  Basic	Basic	Basic	Basic	Basic
  	Neutral	Good	Excellent	Trusted	Card

  
  where the cross-referenced value (i.e., the value within the cell having the identifiedsession trust level830 and the card verification score) is the overall transaction risk level for the subject transaction. Thus,transaction risk level850 represents a combination of device score, a digital wallet/access method score, and a card verification score.
• In the example embodiment,transaction risk level850 represents abaseline recommendation860 generated byRBD module750. In other words, if no other considerations were included,RBD module750 would providebaseline recommendation860 asrisk result752. However, in the example embodiment,RBD module750 additionally applies870 one or more overrides and/or risk limits before generating afinal risk result752. In some embodiments,RBD module750 may provide a default set of rules that are used to generaterisk result752. In the example embodiment,RBD module750 enables issuer-specific risk limits. In other words, each particular issuing bank may provide its own custom set of rules to be applied byRBD module750 to generaterisk result752. For example, in one specific embodiment, an issuer customizes the following table of risk limits:

• TABLE 3
  Issuer Risk Limits

  	Transaction	Daily	Weekly
  Transaction	Amount	Spending	Spending	# Transactions
  Risk Level	Limit	Limit	Limit	Limit
  Trusted	no limit	no limit	no limit	no limit
  Excellent	$1,000	$2,000	$10,000	no limit
  Good	$250	$1,000	$3,000	10
  Neutral	$100	$200	$500	5
  Negative	all	all	all	all

  
  Each column of the table represents a particular aspect or characteristic associated with the transaction, the privileged cardholder, or the payment card account (referred to herein as a “transaction aspects”). Each cell within the table may be configured with a threshold level, and each cell may also be associated with a corresponding transaction risk level (e.g., transaction risk level850). Based on the determinedtransaction risk level850, if one or more of the threshold levels is exceeded,RBD module750 will recommend an additional authentication of the suspect consumer (e.g., 3DS step-up authentication). The threshold levels shown in Table 3 are merely one example. Issuers may elect to use any number of these or other limits atstep870, or none at all.
• In the example embodiment, for the subject payment card,RBD module750 determines a set of risk limits (e.g., table of risk limits) for the subject transaction (e.g., either issuer-specified limits, or default limits). Each set of risk limits may include one or more transaction aspects (e.g., “transaction amount limit”, “daily spending limit”).RBD module750 cross-references each transaction aspect with the determinedtransaction risk level850 for the subject transaction to determine an associated threshold limit (e.g., a cell of Table 3).RBD module750, in the example embodiment, then identifies a reference value associated with each transaction aspect. The reference value is the value thatRBD module750 compares to the threshold value to determine whether or not the transaction aspect has been exceeded.RBD module750 examines each transaction aspect independently atstep870.
• For example, presume an issuer of the subject payment card adopts Table 3, as described above, as their set of risk limits, and presumetransaction risk level850 for the subject transaction is “Good”. “Transaction amount limit” is related only to the subject transaction and, more specifically, to the amount of the subject transaction (e.g., in U.S. dollars). As such, the reference value for the “transaction amount limit” is the payment amount identified in the transaction (e.g., presume the subject transaction is for $44.95).RBD module750 identifies the reference value (e.g., fromtransaction710 data), compares the payment amount, $44.95, to the threshold limit for the “Good” risk level, $250, and determines that the subject transaction is below the threshold level. As such,RBD module750 would not recommend additional user authentication based only on the “transaction amount limit” transaction aspect.
• Continuing the same example, presume that the subject payment card has already incurred $975 in purchases earlier on the day of the subject transaction.RBD module750 evaluates the “daily spending limit” transaction aspect. “Daily spending limit” is related to the subject payment card and, more specifically, to the total amount that has been spent using the subject transaction card on the same day, including the amount of the current transaction. As such, the reference value for the “daily spending limit” is a daily total of transaction amounts for the subject payment card, $975, plus the current amount, $44.95, for a total reference value of $1,019.95.RBD module750 identifies the reference value (e.g., fromhistorical data760 andtransaction710 data), compares the reference value of $1,019.95 to the threshold limit for the “Good” risk level, $1,000, and determines that the subject transaction is above the threshold level. As such,RBD module750 would recommend additional user authentication based only on the “transaction amount limit” transaction aspect.
• Similarly,RBD module750 examines each transaction aspect included in the identified set of risk limits. In the example embodiment, if the subject transaction exceeds any transaction aspect threshold, thenRBD module750 includes a recommendation for additional user authentication inrisk result752. In other embodiments, more than one transaction aspects above threshold are required before a recommendation for additional user authentication is provided inrisk result752.
• In some embodiments, issuers may define limits based on payment card account numbers. For example, in one specific embodiment, issuers may define a single set of risk limits (e.g., Table 3) for a specific bank identification number (BIN) range. In some embodiments, a single issuer may have several different sets of risk limits for non-overlapping BIN ranges.
• It should be understood that using Tables 1 and 2 for determining session trust level from a device score and an access method score is merely exemplary, and other combinations of scores are possible. Further, in other embodiments,RBD module750 generates numeric values for one or more of device score, access method score, card verification score, session trust level, and transaction risk level include numeric values rather than, or in addition to, the tiered levels described in the example embodiment above.
• In some embodiments,RBD module750 may enable the “liable parties” (e.g.,issuers28 and/or merchants24) to customize scoring for their associated transactions. In other words, the liable parties may providescoring rules770 that influence one or more ofdevice score810,method score820,verification score840,session trust level830, and/ortransaction risk level850. For example, one liable party may believe that the device score is a better indicator of fraud than access method or card verifications scores and, as such, may elect to weight the device score more relative to access method score and card verification score. In one embodiment,RBD module750 may implement a customized Table 1 and/or a customized Table 2 to affect such weighting. In another embodiment, liable parties may weight specific, more granular aspects of each score (i.e., weight the components of each score as to how heavily they contribute to that score). For example,RBD module750 may enable liable parties to weight the access method used to access a digital wallet relative to how long a payment card has been loaded into a digital wallet. As such,RBD module750 may provide greater granularity of control to the liable parties, thereby allowing them to influence the risk determination.
• FIG. 9 is a diagram of anexample payment network900 in which a transaction processing system (TPS)910 facilitates risk-based decisioning of a card-not-present (CNP) payment card transaction (the “suspect transaction” or “subject transaction”) between asuspect consumer902 and amerchant24. In some embodiments,payment network900 may be similar to multi-party transaction card industry system20 (shown inFIG. 1),suspect consumer902 may be similar tocardholder602 and/or suspect consumer702, andTPS910 may be similar to TPS122 (shown inFIGS. 2 and 3). In the example embodiment,suspect consumer902 performs an online payment card transaction withmerchant24 and, during this subject transaction, a transaction authentication request is generated and sent toTPS910. In some embodiments,TPS910 is associated with an interchange network such asnetwork28. In other embodiments,TPS910 is associated with a third-party processing service such as, for example, a 3-D Secure (3DS) authentication service.
• In the example embodiment,TPS910 transmits a scoring request to a risk-based decisioning (RBD)system920 for fraud analysis and scoring. In some embodiments,RBD system920 is a third-party fraud screening service. In other embodiments,RBD system920 is provided bynetwork28 or issuer30 (shown inFIG. 1). In some embodiments,RBD system920 is similar to RBD system121 (shown inFIGS. 2 and 3) and/or RBD module750 (shown inFIGS. 7 and 8). In the example embodiment, the scoring request toRBD system920 includes infrastructure data such as one or more of transaction data, information about a computing device used to conduct the subject transaction (“device information”, e.g., geo-location data of the device Internet protocol (IP) address), additional payment card information not included in the transaction data (“payment card information”), information about a digital wallet used to conduct the subject transaction (“digital wallet information”, e.g., whether and/or how often this particular device has been used in conjunction with this digital wallet), and cart data associated with the subject transaction (“cart data”).
• RBD system920, in the example embodiment, scores the subject transaction for fraud using at least some of the provided data. More specifically, under Verified Checkout,RBD system920 generates a risk result922 (e.g., a risk score) for the transaction. In some embodiments,risk result922 is similar to risk result752 (shown inFIGS. 7 and 8). As such, atstep924, if risk result922 does not include a recommendation to perform additional authentication (e.g., less risky transaction), such as described above with respect toFIG. 8, then no additional authentication ofsuspect consumer902 is performed (e.g., no “step-up”). In other embodiments,risk result922 may be a risk score. As such, atstep924, if the risk score satisfies a first pre-defined threshold (i.e., the risk score indicates that the transaction is less risky), then no additional authentication ofsuspect consumer902 is performed (e.g., no “step-up”).TPS910 thus confirms that the transaction risk is acceptable (e.g., no step-up required) atstep926, noauthentication data928 is included in the post-back tomerchant24, and the merchant is informed and subsequently proceeds to authorization of the payment card transaction. Further, in some embodiments,TPS910 and/orRBD system920 may enablemerchant24 and/orissuer30 to customize authentication scoring as described in reference toFIGS. 6-8.
• In the example embodiment, if risk result922 includes a recommendation for additional authentication ofsuspect consumer902, or if the risk score satisfies a second pre-defined threshold, which may be the same as or different from the first pre-defined threshold (i.e., the risk sore indicates that the transaction is more risky), then additional authentication ofsuspect consumer902 will be performed. More specifically,TPS910 initiates (e.g., transmits) a request to anadditional authentication service930, and theauthentication service930 performs anauthentication challenge932 ofsuspect consumer902. In some embodiments under Verified Checkout,TPS910 may include additional extension data when initiating the request toadditional authentication service930, as described in reference toFIGS. 10 and 11. In the example embodiment,additional authentication service930 is a 3-D Secure provider that performs a step-up challenge ofsuspect consumer902. In some embodiments,authentication service930 is similar to authentication service123 (shown inFIGS. 2 and 3). After a successful step-up challenge, authentication data934 (e.g., 3DS values) is populated in the post-back tomerchant24, andmerchant24 proceeds to authorization of the suspect transaction.
• In some embodiments,TPS910 offers toindividual merchants24 and/ormerchant banks26 three options fortransaction authentication906 of CNP payment card transactions: (1) Basic Checkout; (2) Verified Checkout; and (3) Advanced Checkout. Basic Checkout offers a limited level of transaction authentication that does not include an option for additional authentication challenge of suspect consumer902 (e.g., no 3DS step-up challenge), and thus no liability shift (i.e., the merchant retains liability for the subject transaction). Advanced Checkout, on the other hand, includes liability shift from the merchant, but may also prompt additional authentication challenge ofsuspect consumer902. Verified Checkout is a middle ground between Basic and Advanced, in which suspectconsumer902 is only subject to additional authentication challenge if the subject transaction exceeds a certain risk threshold.
• In the example embodiment,TPS910 provides merchants and/or merchant acquiring banks three different check-out choices, along with tiers of risk scoring options. Different merchants may desire different liability responsibilities and/or different consumer experiences for their customers. For example, for some small merchants who conduct small numbers of transactions, every single transaction is important. Such a merchant may desire liability shift to issuers on most or all transactions. On the other hand, large merchants who conduct large numbers of transactions may accept a certain risk of fraudulent transactions in exchange for the expected benefit of not losing the abandoned transactions. As such,TPS910 provides merchant value in the form of enabling merchants to balance between consumer experience and liability protection. In some embodiments, merchants may select Basic, Advanced, or Verified Checkout for different types of transactions. Merchant may configure a settings profile dictating what types of transactions are processed with which method.
• In some embodiments, under Basic Checkout,TPS910 does not provide additional a consumer authentication challenge option, and no liability shift to issuer is possible (e.g., liability stays with merchant). In such embodiments,RBD920 may collect data, but may not score, or may only partially score the subject transaction (e.g., device-data only scoring). In some embodiments, a flag “NOTIFY” is provided as a part of the subject transaction, and serves as an indicator, toTPS910 and/orRBD920, what check-out choice the merchant has elected for this transaction. In some embodiments, NOTIFY prompts RBD920 to record risk data (e.g., what card and/or device combination has been used) for future use and not score or only partially score the subject transaction. Thus,RBD920 may not providerisk result922 tomerchant24.
• In some embodiments, under Verify Checkout,TPS910 invokesRBD920 to calculaterisk result922.RBD920 may provide risk scoring as described above similar to RBD750 (shown inFIGS. 7 and 8). In some embodiments,RBD920 may provide scoring with default scoring rules (e.g., one or more default scoring rules stored in a memory of RBD920), or may apply issuer- or merchant-specific settings (e.g., one or more fraud scoring configuration parameters received from a merchant or an issuer). If, at924,risk result922 exceeds a pre-determined threshold, then a step-upchallenge932 may be presented tosuspect consumer902. As such, under Verified Checkout, liability shift from merchant to issuer may not necessarily occur.
• In some embodiments, under Advanced Checkout,TPS910 ensures liability shift to the issuer.TPS910 invokesRBD920 to score the subject transaction.Suspect consumer902 may or may not be challenged932. If the issuer does not participate in scoring by RBD920 (e.g., as explained above in reference toFIG. 8), then step-up924 withadditional authentication service930 may always be performed. If the issuer does participate in scoring by RBD920 (e.g., by providing toRBD920 one or more fraud scoring configuration parameters), or performs their own risk-based decisioning to determine whether or not to step-up924 to challengesuspect consumer902, then suspectconsumer902 may or may not get challenged932, based on the results of, for example,risk result922.
• In some embodiments, at least one ofTPS910 andRBD920 is configured to store an indication of the party liable for the transaction, such that if a dispute arises about the transaction, the indication of liability may be recalled. For example, under Basic Checkout, as described above, the merchant may assume liability. At least one ofTPS910 andRBD920 may store an indication of merchant liability for each transaction. Under Advanced Checkout, as described above, liability may shift to the issuer. At least one ofTPS910 andRBD920 may store an indication of issuer liability for each transaction. Under Verified Checkout, as described above, the liability may remain with the merchant for certain (less risky) transactions, for which an indication of merchant liability may be stored, and liability may shift to the issuer for certain (riskier) transaction, for which an indication of issuer liability may be stored.
• FIG. 10 is a swimlane diagram illustrating an example portion of anauthentication request process1000 that includes providing authentication data to an issuer during transaction authentication. In the example embodiment, an online transaction involving a digital wallet, such as transaction710 (shown inFIG. 7) involvingdigital wallet600, is processed by an interchange network such as transaction environment20 (shown inFIG. 1).
• During the example transaction, atstep1010, suspect consumer702 commences an online purchase with merchant24 (e.g., selects a button on the merchant's web site indicating that the user is ready to check out). Suspect consumer702 selects, for example,digital wallet600 provided by awallet provider1002. Atstep1015, the transaction proceeds to wallet provider1002 (e.g., after suspect consumer702 logs into digital wallet600). Atstep1020,wallet provider1002 notifiesmerchant24 of the login, and may provide data associated with digital wallet600 (e.g., a selection of payment cards present available to suspect consumer702 through digital wallet600). Merchant24 (e.g., via the merchant's web site) displays data associated withdigital wallet600 to suspect consumer702 (e.g., confirming login to wallet, and/or payment card selection information). Suspect consumer702 selects a particular payment card (the “subject payment card”) to use with this transaction, and submits the transaction for processing.
• Atstep1030a, in the example embodiment, the transaction is sent towallet provider1002 who, atstep1035, transmits transaction information (e.g., payment information) and other information (e.g., digital wallet information730) to a merchant plug-in (MPI)system1004. In other embodiments, such as when a digital wallet is not used, the transaction is sent (e.g.,step1030b) directly toMPI1004 along with at least transaction information.
• MPI1004 initiates an authentication process associated with the subject transaction. More specifically, in the example embodiment,MPI1004 gathers various data associated with the transaction and initiates an authentication transaction for authenticating suspect consumer702. In some embodiments,MPI1004 is similar to transaction processing system910 (shown inFIG. 9). In other embodiments,MPI1004 is similar to RBD750 (shown inFIGS. 7 and 8). In some embodiments,MPI1004 is a part ofnetwork28. In the example embodiment,MPI1004 gathers data including one or more ofdevice information720,digital wallet information730, and payment card information740 (as shown and described in reference toFIGS. 7 and 8). Further,MPI1004 also identifies one or more ofdevice score810,access method score820,card verification score840,session trust level830,transaction risk level850,baseline recommendation860, and/or risk result752 (all shown and described in reference toFIGS. 7 and 8). For example, in one embodiment,MPI1004 computesrisk result752 similar toRBD750.
• Steps1040,1045,1050, and1055 represent anexample authentication transaction1042 under the 3DS protocol. In some embodiments,authentication transaction1042 is similar to transaction authentication906 (shown inFIG. 9). In the example embodiment,MPI1004 provides fraud-related data during a verification process to the issuing bank associated with the subject payment card (e.g., issuer30) and/or an access control server (ACS)1006 associated withissuer30. More specifically,MPI1004 provides fraud-related data toACS1006 using extension messages in the 3DS protocol within, for example, an enrollment check (VeReq, or “verification request”)message1044. The fraud-related data incorporated intoVeReq message1044 is described in greater detail below.
• In the example embodiment, as a part of 3DS enrollment check,MPI1004,network28, andACS1006 utilize a non-critical extension to a3DS VeReq message1044 to pass fraud-related information toissuer30 and/orACS1006. Atstep1040,MPI1004 generatesVeReq message1044 to include fraud-related data in an extension, and transmitsVeReq message1044 to adirectory server1008 associated withnetwork28.Directory server1008 identifiesissuer30 andACS1006 by a primary account number (PAN) of the subject payment card and transmitsVeReq message1004 toACS1006.Issuer30 and/orACS1006 extracts the fraud-related data (e.g., the extensions) fromVeReq message1044 for consideration when determining how to respond (e.g., the status given in a VeRes response message (not shown)).
• Issuer30, orACS1006 on behalf ofissuer30, may use the fraud-related data for many uses such as, for example, implementing their own risk-based decisioning system similar toRBD750,920.ACS1006 determines a result of the enrollment check and, atsteps1050 and155, responds with that result todirectory server1008 and back toMPI1004. Based on the given result, the payment card transaction may be, for example, failed (e.g., if the subject payment card is ineligible for 3DS step-up authentication) or authenticated (e.g., receiving an AUTHENTICATION_COMPLETE message indicates that the issuer has sufficient data to authenticate the suspect consumer without any further interaction with the cardholder) or as requiring a challenge (e.g., receiving a CHALLENGE_REQUIRED message indicates that the issuer ACS has determined that the suspect consumer has to be challenged before proceeding with the transaction). In the example embodiment, a VeRes message (not shown inFIG. 10) includes an extension including an <authenticationAction> section including one of AUTHENTICATION_COMPLETE or CHALLENGE_REQUIRED that serves as a determination whether or not to further authenticate the suspect consumer702 (e.g., the step-up924 conditional shown inFIG. 9).
• In the example embodiment, the extension toVeReq message1044 is an extended markup language (XML) section nested into (e.g., added into) a base VeReq message as defined by the 3DS protocol. The extension section is started with a “<Extension>” start-tag and ended with a “</Extension>” end-tag. For example, consider the following example:

• TABLE 4
  Example VeReq Message with Extensions

  Line#	Message Text
  (01)	<ThreeDSecure><Message id=“vDNoqT3xtC7ShMIot2Z0”>
  	<VeReq><version>1.0.2</version>
  	<pan>521729******3800</pan>
  	<Merchant><acqBIN>123456</acqBIN>
  (05)	<merID>123456789012</merID>
  	<name>Acme Bank Credit Card</name>
  	<country>826</country>
  	<url>http://www.bankurl.com/</url>
  	</Merchant>
  (10)	<Browser><deviceCategory>0</deviceCategory></Browser>
  	<Purchase><xid>1a2b3c4d5e6f7g8h9i0j=</xid>
  	<date>20140101 22:00:00</date>
  	<amount>&#163;1,067.78</amount>
  	<purchAmount>106778</purchAmount>
  (15)	<currency>826</currency>
  	<exponent>2</exponent>
  	</Purchase>
  	<Extension id=“TrustedThirdParty” critical=“false”>
  	<version>1.0</version>
  (20)	<RiskDetermination>
  	<transactionID>xxyyzz</transactionID>
  	<provider>01</provider>
  	<score min=“0” max=“1000”>980</score>
  	</RiskDetermination>
  (25)	<Wallet>
  	<provider>Wallet Provider Co.</provider>
  	<authenticationSessionID>aslkjslk4jlks889wuxxuo</authenticationSessionID>
  	<authenticationValidationSupport>false</authenticationValidationSupport>
  	<transactionRefNumber>wrozorkl2251skjo0oiu</transactionRefNumber>
  (30)	<userProfileID>abcxyz</userProfileID>
  	<userAuthenticationStrength>Excellent</userAuthenticationStrength>
  	<userAccountAge>565</userAccountAge>
  	<userConfidenceScore min=“” max=“”></userConfidenceScore>
  	<paymentCardAge></paymentCardAge>
  (35)	<paymentCardValidationMethod></paymentCardValidationMethod>
  	<deviceConfidencelevel></deviceConfidencelevel>
  	</Wallet>
  	</Extension>
  	</VeReq></Message></ThreeDSecure>

• The example VeReq message shown in Table 4 includes several fields that provide transaction data associated with the subject transaction, such as a primary account number at line (3), merchant information at lines (4) to (9) (e.g., a merchant ID, an acquirer BIN), and purchase information at lines (11) to (17) (e.g., a purchase amount and date). Further, the example VeReq message includes an extension section at lines (18) to (37). This extension section contains one or more elements of fraud-related information.
• In the example embodiment, the extension section includes one or more sub-sections, or sections within the extension section. In the example shown in Table 4, the extension section includes two sub-sections: a <RiskDetermination> section from lines (20) to (24) (terminated by </RiskDetermination>) and a <Wallet> section from lines (25) to (37) (terminated by </Wallet>). Each of these sections embeds information associated with one or more aspects of risk scoring of the subject transaction. Each sub-section of the extension section is referred to herein by the extension sub-section's start-tag, for convenience. Further, it should be understood that the exact sub-section tag names used as examples herein are merely example tag names, and these tag name may vary within the scope of this disclosure.
• In the example embodiment, the <RiskDetermination> section is directed to providing an overall risk score provided by a risk-based decisioning service such asRBD750 or920 (e.g.,baseline recommendation860 and/orrisk result752, both shown inFIG. 8). In the example shown in Table 4, <RiskDetermination> includes a <transactionID> (e.g., line (21)), a <provider> (e.g., line (22)), and a <score> (e.g., line (23)). <provider> is an identifier specifying the provider of the risk score (e.g., the party associated withRBD750 or920). <transactionID> is a unique ID for the subject transaction that may be used to identify this particular transaction at a later date. <score> is a value that represents the overall score assigned to this transaction (e.g., by <provider>). In this example, the <provider> has generated a score of “980” for this transaction (on a scale between “0” and “1,000”). In some embodiments, <RiskDetermination> may also include a <recommendation> sub-section. <recommendation> represents a recommended course of action based on <score>. In one embodiment, <recommendation> is an enumerated data type consisting of either “Good” or “Bad”, which may be used byissuer30 orACS1006 to determine whether or not to allow the transaction to process without further authentication (e.g., without 3DS step-up challenge932 (shown inFIG. 9)).
• In the example embodiment, the <Wallet> section is directed to providing information associated with a digital wallet (e.g.,digital wallet information730 fordigital wallet600, both shown inFIG. 7). In the example shown in Table 4, <Wallet> includes a <provider> section representing the provider of the digital wallet (e.g., “Wallet Provider Co.”) and, in some embodiments, may include sub-sections for the provider's name and/or identifier. <Wallet> also includes a <authenticationSessionID> section representing a unique identifier (e.g., “aslkjslk4jlks889wuxxuo”) associated with an authentication session of the subject transaction with the subject digital wallet. <Wallet> further includes a <authenticationValidationSupport> section indicating whether validation support is included in the digital wallet.
• In the example embodiment, the <Wallet> section also includes a <transactionRefNumber> section representing a unique identifier (e.g., “wrozork12251skjo0oiu”) associated with the transaction and the wallet. <Wallet> also includes a <userProfileID> section representing a unique identifier (e.g., “abcxyz”) associated with the user account of the wallet. <Wallet> further includes a <userAuthenticationStrength> section representing an enumerated value indicating the login strength (e.g., “Excellent”) associated with the suspect consumer's authentication or login to the subject digital wallet. In some embodiments, this enumerated list includes “fraud”, “basic”, “good”, “excellent”, and “trusted”.
• In the example embodiment, <Wallet> also includes a <userAccountAge> section representing a length of time (e.g., 565 days) the subject digital wallet has been active. <Wallet> further includes a <userConfidenceScore> representing a score or sub-score associated with how the suspect consumer authenticated with the subject digital wallet during this transaction and/or past transactions.
• Further, in the example embodiment, <Wallet>=also includes a <paymentCardAge> section representing a length of time the subject payment card has been associated with the subject digital wallet. <Wallet> also includes a <paymentCardValidationMethod> section. <Wallet> also includes a <deviceConfidencelevel> section representing a score or sub-score associated with the device accessing the subject wallet during the subject transaction (e.g., in some embodiments, device score810).
• In some embodiments, <Wallet> may also include a <score> section representing an overall transaction trust level score based on digital wallet information associated with the subject digital wallet as used in the subject transaction. For example, <score> may be anaccess method score820 generated byRBD750 usingdigital wallet information730 as described and shown in relation toFIGS. 7 and 8. In some embodiments, <score> may be provided by the digital wallet provider. In some embodiments, this score may be provided in addition to, or in lieu of, <transactionTrustLevel>. Alternatively, this “wallet score” may be provided as a subsection of <RiskDetermination>. In other embodiments, otherdigital wallet information730 may be included as sub-sections of <wallet>.
• In some embodiments, the <RiskDetermination> section also includes a <deviceTrustLevel> section that represents a score associated with the subject device used during the subject transaction. In some embodiments, the <deviceTrustLevel> includes one of an enumerated list that includes “fraud”, “basic”, “good”, “excellent”, and “trusted”. In some embodiments, the <deviceTrustLevel> is similar to device score810 (shown inFIG. 8). In some embodiments, the <deviceTrustLevel> is determined based at least in part on device information720 (shown inFIGS. 7 and 8).
• Further, in some embodiments, the <RiskDetermination> section also includes a <sessionTrustLevel> section that represents a score associated with a trustworthiness of the login session associated with the subject payment card transaction. In some embodiments, <sessionTrustLevel> includes one of an enumerated list that includes “basic”, “good”, “excellent”, and “trusted”. In some embodiments, <sessionTrustLevel> is similar to session trust level830 (shown inFIG. 8).
• FIG. 11 is anexample method1000 for risk-based analysis of a payment card transaction using, for example, the risk-based decisioning (RBD)system750,910 shown inFIGS. 7-9 in theexample environment100 shown inFIG. 1. In the example embodiment,method1000 is performed by a computing system such as server112 (shown inFIG. 2), transaction processing system122 (shown inFIGS. 3 and 6), RBD module750 (shown inFIGS. 7 and 8), or RBD system920 (shown inFIG. 9). In the example embodiment,method1100 includes receiving1102 a request for authentication of the payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder.Method1100 further includes identifying1104 fraud feature data from the digital wallet.Method1100 also includes computing1106 a fraud score for the payment card transaction based at least in part on the fraud feature data.Method1100 further includes providing1108 the fraud score for use during authentication of the suspect consumer.
• FIG. 12 is anexample method1200 for providing risk-based decisioning to a merchant during payment card transactions in theexample environment100 shown inFIG. 1. In the example embodiment,method1200 is performed by a computing system such as server112 (shown inFIG. 2), transaction processing system122 (shown inFIGS. 3 and 6), RBD module750 (shown inFIGS. 7 and 8), or RBD system920 (shown inFIG. 9). In the example embodiment,method1200 includes receiving1202, from the merchant, transaction data associated with a payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder.Method1200 further includes computing1204 a risk score for the payment card transaction based at least in part on the transaction data and infrastructure data associated with the payment card transaction.Method1200 also includes transmitting1206 an indication of acceptable risk to the merchant if the risk score satisfies a first pre-defined threshold. Thereby, the merchant may continue processing the payment card transaction without liability shifting away from the merchant.Method1200 further includes initiating1208 an authentication challenge of the suspect consumer if the risk score satisfies a second pre-defined threshold. Thereby, liability may shift away from the merchant.
• FIG. 13 is anexample method1300 for providing fraud data within an authentication system including an authentication protocol. In the example embodiment,method1300 is performed by a computing system such as server112 (shown inFIG. 2), transaction processing system122 (shown inFIGS. 3 and 6), RBD module750 (shown inFIGS. 7 and 8), or RBD system920 (shown inFIG. 9). In the example embodiment,method1300 includes identifying1302 fraud feature data associated with a payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder.Method1300 also includes computing1304 a first risk score for the payment card transaction based at least in part on the fraud feature data.Method1300 further includes generating1306 a message in the authentication protocol, the message including at least one extension field. The first risk score is included within the at least one extension field.Method1300 also includes transmitting1308 the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.
• FIG. 14 shows anexample configuration1400 of adatabase1420 within acomputing device1410, along with other related computing components, that may be used to analyze of a payment card transaction for risk, to provide risk-based decisioning to a merchant during payment card transactions, and/or to provide fraud data within an authentication system including an authentication protocol. In some embodiments,computing device1410 is similar to server112 (shown inFIG. 2), transaction processing system122 (shown inFIGS. 3 and 6), RBD module750 (shown inFIGS. 7 and 8), RBD system920 (shown inFIG. 9), and/or server system301 (shown inFIG. 5).Database1420 is coupled to several separate components withincomputing device1410, which perform specific tasks.
• In the example embodiment,database1420 includesdigital wallet data1422,transaction data1424, and device andpayment card data1426. In some embodiments,database1420 is similar to database120 (shown inFIG. 2).Digital wallet data1422 includes information associated with a cardholder's digital wallet, such as digital wallet600 (shown inFIG. 6).Transaction data1424 includes information associated with payment card transactions. Device andpayment card data1426 includes data associated with device(s) used to conduct payment card transactions and payment card data used in those transactions.
• Computing device1410 includes thedatabase1420, as well asdata storage devices1430.Computing device1410 also includes afraud scoring component1440 for computing fraud scores (e.g., risk result752).Computing device1410 also includes an authentication component1450 (e.g.,authentication service930, shown inFIG. 9) for performing aspects of cardholder authentication. Atransaction component1460 is also included for performing aspects of payment card transaction processing. Acommunications component1470 is also included for communicating data between components associated with the payment card transaction process. A processing component1480 assists with execution of computer-executable instructions associated with the system.
• As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect is a flexible system for various aspects of fraud analysis of payment card transactions. Any such resulting program, having computer-readable code means, may be embodied or provided within one or more computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed embodiments of the disclosure. The computer-readable media may be, for example, but is not limited to, a fixed (hard) drive, diskette, optical disk, magnetic tape, semiconductor memory such as read-only memory (ROM), and/or any transmitting/receiving medium such as the Internet or other communication network or link. The article of manufacture containing the computer code may be made and/or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.
• These computer programs (also known as programs, software, software applications, “apps”, or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The “machine-readable medium” and “computer-readable medium,” however, do not include transitory signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
• This written description uses examples to disclose the disclosure, including the best mode, and also to enable any person skilled in the art to practice the disclosure, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the disclosure is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.

Claims (21)

What is claimed is:

1. A computing device for providing fraud indicator data within an authentication system including an authentication protocol, said computing device comprising a processor communicatively coupled to a memory, said computing device programmed to:

identify fraud feature data associated with a payment card transaction, wherein the payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder;

compute a first risk score for the payment card transaction based at least in part on the fraud feature data;

generate a message in the authentication protocol, the message including at least one extension field, wherein the first risk score is included within the at least one extension field; and

transmit the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.

2. The computing device ofclaim 1 further programmed to compute the first risk score based at least in part on card authentication data wherein the card authentication data relates to a process by which the payment card was previously loaded into the digital wallet.

3. The computing device ofclaim 1 further programmed to compute the first risk score based at least in part on device data associated with a computing device used by the suspect consumer with the digital wallet to perform the payment card transaction.

4. The computing device ofclaim 1 further programmed to compute the first risk score based at least in part on digital wallet authentication data, wherein the digital wallet authentication data relates to a process used by the digital wallet to authenticate the suspect consumer as the privileged cardholder.

5. The computing device ofclaim 1 further programmed to generate the message as an extension section of a request message in 3-D Secure® protocol.

6. The computing device ofclaim 1 further programmed to generate the message including a second extension field that includes therein a first element of the fraud feature data.

7. The computing device ofclaim 1 further programmed to:

generate an authorization recommendation based at least in part on the first risk score; and

generate the message further including the authorization recommendation.

8. A computer-based method for providing fraud indicator data within an authentication system including an authentication protocol, the method implemented using a computer device including a processor and a memory, said method comprising:

identifying fraud feature data associated with a payment card transaction, wherein the payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder;

computing a first risk score for the payment card transaction based at least in part on the fraud feature data;

generating a message in the authentication protocol, the message including at least one extension field, wherein the first risk score is included within the at least one extension field; and

transmitting the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.

9. The method ofclaim 8, wherein computing a first risk score further includes computing the first risk score based at least in part on card authentication data wherein the card authentication data relates to a process by which the payment card was previously loaded into the digital wallet.

10. The method ofclaim 8, wherein computing a first risk score further includes computing the first risk score based at least in part on device data associated with a computing device used by the suspect consumer with the digital wallet to perform the payment card transaction.

11. The method ofclaim 8, wherein computing a first risk score further includes computing the first risk score based at least in part on digital wallet authentication data, wherein the digital wallet authentication data relates to a process used by the digital wallet to authenticate the suspect consumer as the privileged cardholder.

12. The method ofclaim 8 further comprising generating the message as an extension section of a request message in 3-D Secure® protocol.

13. The method ofclaim 8, wherein generating a message further includes generating the message including a second extension field that includes therein a first element of the fraud feature data.

14. The method ofclaim 8 further comprising generating an authorization recommendation based at least in part on the first risk score, wherein generating a message further includes generating the message further including the authorization recommendation.

15. At least one non-transitory computer-readable storage media having computer-executable instructions embodied thereon, wherein when executed by at least one processor, the computer-executable instructions cause the processor to:

identify fraud feature data associated with a payment card transaction, wherein the payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder;

compute a first risk score for the payment card transaction based at least in part on the fraud feature data;

generate a message in the authentication protocol, the message including at least one extension field, wherein the first risk score is included within the at least one extension field; and

transmit the message with the first risk score included within the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction.

16. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to compute the first risk score based at least in part on card authentication data wherein the card authentication data relates to a process by which the payment card was previously loaded into the digital wallet.

17. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to compute the first risk score based at least in part on device data associated with a computing device used by the suspect consumer with the digital wallet to perform the payment card transaction.

18. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to compute the first risk score based at least in part on digital wallet authentication data, wherein the digital wallet authentication data relates to a process used by the digital wallet to authenticate the suspect consumer as the privileged cardholder.

19. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to generate the message as an extension section of a request message in 3-D Secure® protocol.

20. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to generate the message including a second extension field that includes therein a first element of the fraud feature data.

21. The computer-readable storage media ofclaim 15, wherein the computer-executable instructions further cause the processor to:

generate an authorization recommendation based at least in part on the first risk score; and

generate the message further including the authorization recommendation.

Images