Patent Application
20160364728
Embodiments of the invention relate to processing systems and methods.
Illicit credit card and other financial transactions are often attempted by persons or entities with a history of illicit or questionable activity. However, computer systems used for automated monitoring for such activity may not have access to sufficient data or resources to detect such activities.
According to one aspect, a merchant transaction system comprises a processor and memory. The memory holds data and instructions, and the instructions, when executed by the processor, cause the system to receive a transaction request from a customer for a card-not-present sale transaction. The sale transaction request contains information including number of an account being used in the sale transaction and other information. The instructions further cause the system to transmit over an electronic network a transaction risk request message to a transaction risk evaluator, and to receive over the electronic network a reply message from the transaction risk evaluator. The reply message indicates a level of risk associated with the sale transaction. The instructions further cause the system to decide whether to proceed with the card-not-present sale transaction based at least in part on the content of the reply message.
A more complete understanding of the present invention may be derived by referring to the detailed description of the invention and to the claims, when considered in connection with the Figures.
There are various embodiments and configurations for implementing the present invention. Generally, disclosed embodiments provide computerized systems and methods for identifying risk associated with card purchases.
In the usual arrangement, a credit card issuer bears the risk of illicit transactions conducted when a physical card is present, for example when a consumer presents a physical credit card at a merchant point of sale. In such a transaction, the merchant can proceed without risk of non-payment by the issuer.
However, in a card-not-present (CNP) transaction, for example a transaction conducted over the Internet with an online merchant, the allocation of risk is reversed. The merchant bears the risk that a transaction is fraudulent and will go unpaid. As such, online merchants may have a strong interest in improved systems and methods for identifying potentially illicit transactions such as illicit sale transactions before they are completed.
At the checkout screen, consumer 201 may enter card information, as is shown in
Referring again to
However, even if card issuer 204 sends an approval message, merchant 202 may wish for additional information about the trustworthiness of the sale transaction. Because the transaction is a card-not-present (CNP) transaction conducted over the Internet 203, merchant 202 may wish to take additional steps to learn if the transaction carries undue risk to the merchant. In addition to contacting card issuer 204 as described above, merchant 202 also sends a request message to a transaction risk evaluator 206 via electronic network 207. The request message includes some or all of the information entered by consumer 201, and preferably at least the number of the account being used in the sale transaction.
While the example arrangement of
Risk evaluator 206 maintains one or more databases containing transaction information for a number of accounts held at a number of issuing institutions, and containing information indicating past actual or suspected illicit activity (e.g. fraud relating to at least some of the accounts. For example, the one or more databases may include a list of card account numbers previously used at a point of purchase in common with one or more other card accounts reported to have been used fraudulently. This common point of purchase (CPP) determination may be made by the techniques described in application 62/174,432, previously incorporated by reference. If the card account being used in the transaction of
Because risk evaluator 206 preferably collects account information from a number of different card issuers, risk evaluator 206 may be able to discover fraud potentialities that would not be apparent to a single card issuer such as issuer 204. For example, issuer 204 may not be able to discover on its own that one of its accounts was used at a common point of purchase with an account from a different issuer later used illicitly.
Risk evaluator 206 may perform other kinds of analyses as well. In some embodiments, risk evaluator 206 may review the customer-entered information for correlations with past instances of actual or suspected illicit activity. For example, transaction risk evaluator 206 may search its databases for any indications that the billing or shipping addresses supplied by the customer were previously used in a fraudulent transaction. Similarly, the customer-entered email address or telephone number may be investigate for association with any previous fraud. Many other analyses are possible, and some are described in more detail below.
Transaction risk evaluator 206 prepares a response message based on any identified correlations, and associated with a level of risk associated with the transaction. The reply message is made available to merchant 202. For example, the response message may be transmitted directly from transaction risk evaluator 206 to merchant 202, or may be passed through an intermediary. Other methods of message delivery may be used as well.
In some embodiments, the response message may directly indicate the level of risk of the transaction as evaluated by transaction risk evaluator 206. For example, the response message may include a risk score. In other embodiments, the response message may not include a specific risk rating, but may contain information from which merchant 202 may perform its own risk evaluation. For example, the response message may include indications of whether the account being used in the transaction or any associated data (address, phone number, email address, etc) has previously been associated with fraud, or may indicate whether the account was used at a common point of purchase with other accounts reported to have been used fraudulently.
Preferably, the response message is sent in real time. That is, the response message is sent quickly enough that the merchant can use the information in the response message to decide whether to accept or decline the transaction during the “checkout” or a similar phase of the transaction. In some embodiments, transaction risk evaluator 206 can respond to a merchant request message within 1, 2, 3, 4, 5, 8, 10, 20, 30, 45, 60, 120, or another number of seconds after receiving the merchant request message. In other embodiments, the response message may not be sent in real time.
The indication of the level of risk may be presented in any of a number of ways. For example, the response message may include a transaction risk score that quantifies the cumulative risks uncovered in the analyses of the account information and other customer-supplied information. The response message may include a recommendation that the transaction be approved or denied. The response message may include supporting information, such as a number of items of information that contributed to the transaction risk score.
Upon receiving the response message, merchant 202 can decide whether to proceed with the sale transaction, to decline the sale transaction, or to take further steps to evaluate the risk of the sale transaction. For example, the merchant may require that the customer present a credit or debit card to support the sale transaction rather than conduct a card-not-present transaction, in order to shift the risk of non-payment to the card issuer. In some cases, the merchant may decide to decline the transaction based on the response message from risk evaluator 206, even though card issuer 204 may have approved the transaction. As such, the response message may be considered approval guidance for the merchant, because the information in the response message may inform the merchant's decision whether to proceed with the sale transaction or not.
Preferably, merchant 202 provides information to risk evaluator 206 as well. For example, merchant 202 may provide information to risk evaluator 206 about instances of fraud detected by merchant 202, so that the information can be incorporated into the databases maintained by transaction risk evaluator and used in future transaction risk analyses. For example, merchant 202 may provide card account numbers, billing addresses, shipping addresses, and other information associated with transactions that merchant 202 has determined to be fraudulent. In other embodiments, merchant 202 may provide the details of transactions that are not suspected of being illicit as well. Such transaction data may be provided on a batch basis if desired, rather than in real time.
Similarly, issuer 204 may provide to risk evaluator 206 information about instances of fraud of which issuer 204 may become aware. For example, issuer 204 may report to transaction risk evaluator 206 the account numbers of accounts reported to have been used illicitly, as well as the associated account holder names, billing and shipping addresses, phone numbers, email addresses, and the like. Risk evaluator 206 may use this information in future transaction risk determinations. For example, such information may assist transaction risk evaluator 206 in backtracing transaction data to determine the likely common point of purchase at which a data breach may have occurred, or may be used in other ways.
In addition, risk evaluator 206 may provide additional information to card issuer 204, for example lists of accounts that have been used at a point of purchase in common with other accounts that have been reported for fraud, or other information.
While only one merchant 202 and one card issuer 204 are depicted in
It is envisioned that in embodiments of the invention, an entity such as risk evaluator 206 may receive many thousands or even millions of merchant request messages daily.
The computer system 400 is shown comprising hardware elements that may be electrically coupled via a bus 480. The hardware elements may include one or more central processing units 410, one or more input devices 420 (e.g., a mouse, a keyboard, etc.), and one or more output devices 430 (e.g., a display device, a printer, etc.). The computer system 400 may also include one or more storage devices 440, representing remote, local, fixed, and/or removable storage devices and storage media for temporarily and/or more permanently containing computer-readable information, and one or more storage media reader(s) 450 for accessing the storage device(s) 440. By way of example, storage device(s) 440 may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable or the like.
The computer system 400 may additionally include a communications system 460 (e.g., a modem, a network card—wireless or wired, an infra-red communication device, a Bluetooth™ device, a near field communications (NFC) device, a cellular communication device, etc.) The communications system 460 may permit data to be exchanged with a network, system, computer, mobile device and/or other component as described earlier. The system 400 also includes working memory 470, which may include RAM and ROM devices as described above.
The computer system 400 may also comprise software elements, shown as being located within a working memory 470, including an operating system 474 and/or other code 478. Software code 478 may be used for implementing functions of various elements of the architecture as described herein.
It should be appreciated that alternative embodiments of a computer system 400 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Furthermore, there may be connection to other computing devices such as network input/output and data acquisition devices (not shown).
It will be recognized that embodiments of the invention improve the function of prior computer systems. For example, in the absence of transaction risk evaluator 206, a merchant 202 wishing to gain additional confidence in the viability of card-not-present sale transactions may have to contact card issuers individually for evaluations of account information and its possible correlation with past actual or suspected fraud. In embodiments of the invention, transaction risk evaluator provides a single point of contact for merchant 202, simplifying the process of obtaining a transaction risk evaluation for merchant 202. In addition, because transaction risk evaluator 206 may receive information from a number of issuers and merchants for inclusion in its database, the risk evaluation is improved. For example, without shared information, an individual issuer may not be able to determine that one of its cards was used at a point of purchase in common with a card from a different issuer reported as being used for fraud.
Many different contributors to a risk score or other determination of transaction risk are possible. Table 1 below lists a number of examples, but many others may be used as well instead of, in combination with, or in addition to any of these.
In some embodiments, the pattern of use of an account, for example its transaction history, may be analyzed to evaluate the risk of a particular transaction. For example, if a longstanding account is used for the first time to conduct an online transaction, the transaction risk score or other estimate may be raised, because a first ever online transaction is something that might happen after compromise of an account that has never been used for online purchases before. However, the effect on the transaction risk estimate may be modest, because there are other plausible explanations for why an account is being used for the first time online. For example, the account holder may only recently have decided to obtain Internet access and begin an online presence.
However, if the account that is being used for the first time ever online is also suspected of being recently compromised, the effect on the transaction risk estimate may be greatly increased, because of the otherwise-unlikely coincidence of the suspected breach and the first-ever online transaction. That is, it may be considered more likely that the transaction is being conducted by a fraudster than that the account holder decided coincidentally to begin online purchases shortly after the suspected breach.
This scenario also shows how factors that may individually affect the risk estimate may be used in combination, and the contribution of their combination to the transaction risk may be more or less than the sum of their individual effects.
Similarly, if the phone number given by the customer during the entry of an online transaction does not match the phone number on file for the account holder at the issuer, the transaction risk estimate may be increased only slightly, as there are very plausible innocuous reasons for such a discrepancy. For example, the account holder may have given a landline phone number when opening the account, but may enter his or her cell phone number during the transaction. However, if the new phone number has also been used in prior known-fraudulent transactions, this combination of factors may strongly increase the transaction risk estimate.
The data format of
In addition, the response message may include a list of one or more codes or other explanatory items that indicate reasons for the particular transaction risk estimate. For example, the response message may indicate that certain data fields entered by the customer during the transaction did not match the information on file for the account being used. Or the response message may indicate results from the analyses performed by transaction risk evaluator 206. For example, a reason code may indicate that the account has a suspicious transaction history, that the account has been reported or suspected as having been compromised, that an item of information entered by the customer has previously been associated with fraud, or may indicate other analysis results.
Table 2 below lists some possible reason codes.
Other reason codes may be used as well.
While the transaction risk score is preferably determined and provided to the requesting merchant in real time, preliminary processing may be done in order to facilitate the rapid determination of transaction risk scores from customer-entered information. For example, the common point of purchase (CPP) backtracing described in Provisional U.S. Patent Application No. 62/174,432 (previously incorporated by reference) may be performed periodically on a batch basis, so that a list of potentially-compromised accounts can be available for rapid access by simple table lookup rather than having to perform the backtracing in real time.
The analyses performed by transaction risk evaluator 206 may involve information and data from several sources, for example:
Other sources of information may be used as well. The evaluation of the risk of any particular transaction may be based on any one, any combination, or all of the available data sources and databases. Information from the various data sets may be cross referenced to increase the scope of the risk analysis. For example, purchaser information entered by the customer in initiating a transaction may be cross referenced with bank-contributed personal identifying information, so that the customer's history can be evaluated, for example to see if the customer has previously been the victim of fraud, whether other accounts associated with the customer may have negative histories, or the like. Once the customer has been identified, his or her transaction histories at multiple financial institutions may be investigated.
Besides providing analysis results such as transaction risk scores in response messages to merchants, transaction risk evaluator 206 may exchange information with issuers such as issuer 204 for various purposes, as is shown in
While a detailed description of presently preferred embodiments of the invention has been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the invention. Therefore, the above description should not be taken as limiting the scope of the invention, which is defined by the appended claims.
This application claims the benefit of Provisional U.S. Patent Application No. 62/174,432 filed Jun. 11, 2015 and titled “System and Method for Identifying Compromised Accounts”, the entire disclosure of which is hereby incorporated by reference herein for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 62174432 | Jun 2015 | US |
