JP2004524599A - Method and apparatus for assessing fraudulent transaction risk in electronic commerce - Google Patents

Abstract

A method and system for assessing fraudulent trade risk in e-commerce between a customer and a merchant over a network. E-commerce or e-purchase orders are received, the level of risk associated with each order is measured, and a risk score is returned. Data validation, highly predictive artificial intelligence pattern matching, network data synthesis and negative file checking are used to test a very large number of factors to calculate fraud risk. Other analyzes include comparing this transaction against known fraudulent transactions in the past and searching transaction history databases to identify abnormal speed patterns, first and last name changes, and known fraudsters. The scoring algorithm can also be refined periodically by a closed-loop risk modeling process that allows the services provided by the system to be fine-tuned to adapt to new or changing fraudulent trading patterns.

Description

【Technical field】
[0001]
The present invention relates generally to electronic commerce processing. More particularly, the present invention relates to a method and apparatus for assessing the risk of fraudulent transactions in electronic commerce.
[Background Art]
[0002]
Any business that accepts bank card payments will, to some extent, accept the risk that the transaction is fraudulent. But for most merchants, the benefits of a bank card outweigh any risks. In addition to traditional storefront merchants, mail-order merchants are looking to increase year-to-year business growth from bank card acceptance, supported by industry safeguards and services designed to reduce and prevent the risk of fraudulent transactions. I have been singing.
[0003]
Credit card transactions are used in various environments. In a typical environment, a customer, buyer, or other user will present a credit card to a merchant, and the merchant will verify by various means that the information is accurate. In one approach, credit card verification is used. In general, credit card verification involves contacting the credit card issuer or its agent, typically a bank or the United States Credit Card Association, and whether bank deposits are available for payment and the card number. Receiving information about whether it is valid is included. As a result of this check, a response of “issuer approval” or “issuer rejection” to the seller is automatically obtained. If a merchant receives a credit card number in a "card not shown" transaction, such as a mail order, the credit card verification service is often augmented by another system, which is an individual sale. It is the responsibility of the trader.
[0004]
For example, referring now to FIG. 1, a general credit card verification system 10 is shown. In such a system, a merchant 14 receives a credit card from a customer 12. The merchant then verifies the credit card information with an automated address verification system ("AVS") 16. Such a scheme works well for credit card transactions where the customer is facing the merchant or the merchant is actually shipping parcels or the like to the customer's address.
[0005]
The verification procedure generally involves receiving address information and identity information at the AVS system. AVS is currently useful in supporting the selection of purchases made by credit card customers at some banks in the United States. Basically, banks issuing credit cards from either of the two major brands (Visa or MasterCard) choose whether to support the AVS system. AVS checks configured to support the mail order business are typically performed in response to a bank card verification request. AVS performs additional checks, as well as verification of bank deposit and credit card status, to ensure that the address element provided by the buyer matches the address element on record by the issuing bank. . When the merchant performs the AVS check, he can receive the following response:
[0006]
AVS = Match—The first four digits of the street address and the first five digits of the ZIP code (postal code) and the credit card number match the numbers and numbers on the record at the bank.
[0007]
AVS = partial match-partial match (e.g., location numbers match but ZIP codes do not match, or ZIP codes match but location numbers do not match).
[0008]
AVS = invalid-system cannot provide a response. This result is returned if the system is down, the bank card does not support AVS, or the bank card issuer for the credit card used for the purchase is not located in the United States.
[0009]
AVS = mismatch—does not match between address elements or between ZIP code data elements.
DISCLOSURE OF THE INVENTION
[Problems to be solved by the invention]
[0010]
Most merchants will not receive an order with a resulting response of "Issue Denied" or "AVS = Mismatch", but due to the nature of automated online transactions, the merchant will be able to accept cards However, there is a need to implement policies and procedures that can handle cases where there is doubt about other data to validate transactions. In such a case, the verification response is "issuer-approved", but includes cases where the AVS response is AVS = partial match or AVS = invalid, or even AVS = match. That is, the buyer's bank can approve the transaction, but it is not clear whether the transaction is valid.
[0011]
A significant amount of legitimate sales is accompanied by an AVS response indicating that the risk level is unknown (or a purchase is made outside the United States where AVS does not apply), so a valid order with minimal potential risk Finding ways to maximize underwriting is crucial. Obviously, rejecting such orders will negatively impact sales and customer satisfaction, and blindly underwriting will increase the risk. In addition, the AVS = match response has some risk, since the stolen card and address information can trigger an AVS = match response.
[0012]
To address these issues, merchants have augmented card validation and AVS results with additional screening procedures and systems. One such additional procedure is to manually sort orders. While this approach is effective to some extent when the order is small, it is inefficient and adds operating overhead that makes business expansion impossible.
[0013]
E-commerce or online commerce is a rapidly expanding field of retail and business-to-business commerce. In electronic commerce, a buyer or buyer typically obtains tangible or digital goods or services from a seller or a seller's agent in exchange for an amount transferred from the buyer to the seller. E-commerce through public networks such as the Internet offers business opportunities equal to or greater than traditional store business, but requires special precautions to ensure secure business operations. The technological basis that facilitates electronic shopping-for example, free merchant access, anonymity, the speed and convenience of shopping-also provides new ways for thieves to commit credit card fraud.
[0014]
If the transaction involves the downloading of information from an online service or the Internet, the address and identity information is not sufficient to reliably verify that the customer purchasing the goods is in fact the owner of the credit card. For example, an individual may have both the first and last name and address of a particular credit card holder, and that information may be sufficient to authenticate such a transaction in a normal transaction. However, in Internet transactions, it is possible to obtain all the correct information about a particular credit card holder by unlawful means, and thus to carry out fraudulent transactions.
[0015]
Therefore, what is needed is a system and method that overcomes the problems associated with common verification systems for credit card transactions, particularly in the Internet or online service environment. The system should be easily implemented in existing environments and should be easily adaptable to existing technologies.
[0016]
Although not all merchants may engage in fraudulent transactions, as fraudulent transactions are strongly dependent on the nature of the product being sold, one study found that the overall risk of fraudulent transactions was limited by the underwriting criteria of the vendors. It has been found that depending on tolerance, the range of authorized transaction sales ranges between 4% and 23%. In most cases, Internet sellers are responsible for the transaction, even if the house bank authenticates the transaction, because Internet transactions are classified under the operating rules of major credit card federations as "card-free" transactions . As a result, fraudulent transactions have a direct and immediate effect on online merchants.
[0017]
Most e-commerce fraud is thought to be based on stolen identity rather than stolen cards. Generally, in fraudulent e-commerce based on stolen identities, cardholders will not be able to illegally verify their identity or credit card accounts until a legitimate cardholder has reviewed the monthly report and found the fraudulent transaction. Detect or know what is being used. In contrast, in the case of a stolen card, the cardholder will be aware that the card is not present and will usually notify the credit card company representative or law enforcement immediately. As a result, the effects of fraudulent transactions differ in the context of electronic commerce. Fraudulent transactions affect the merchant's operational efficiency, and possibly the merchant's discount rate and credit card acceptability.
[0018]
In one approach, online merchants seek to avoid the above risks by not responding to orders other than the safest order at all, or by incorporating manual screening methods. However, merchants using these approaches typically fall into a business inefficiency and reduced sales. These merchants reject a significant portion of orders that could have been converted to sales, increasing overhead and reducing the potential for business expansion. That is, either very rigorous or non-automated methods for protecting a business from fraudulent transactions and fraudulent transactions can negatively impact business operations.
[0019]
Based on the foregoing, there is a clear need for improved methods and systems for determining fraud risks associated with e-commerce.
[0020]
There is a need for a method to assist merchants in screening fraudulent internet transactions by calculating and delivering risk scores in real time.
[0021]
There is also a need for a method for detecting fraud risks associated with e-commerce, which is tailored to different types of attempts in fraudulent transactions committed by future buyers, based on criteria specific or unique to the e-commerce environment. Have been.
[0022]
There is a particular need for a method for determining fraud risk associated with e-commerce that is useful for computer-based merchant service systems.
[Means for Solving the Problems]
[0023]
The above requirements and others that will become apparent in the following description, in one aspect, include a method and apparatus for assessing fraud risk in an e-commerce transaction between a customer and a merchant over a network. This is achieved with the present invention. The merchant requests services from the system over the network using a secure, open messaging protocol. An e-commerce or purchase order is received from the merchant, the level of risk associated with each order is measured, and a risk score is returned to the merchant. In one embodiment, data verification, highly predictive artificial intelligence pattern matching, network data synthesis and negative file checking are used to test a very large number of factors for calculating fraud risk. A fraud screening system utilizes data elements submitted with the order to perform analysis, including data integrity checking and correlation analysis based on the nature of the transaction. Other analyzes include comparing this transaction against known fraudulent transactions in the past, and searching transaction history databases to identify abnormal speed patterns, first and last name changes, and known fraudsters. A risk score is generated and compared to the vendor-specific risk threshold. The result is returned to the merchant for the deposited order. In one alternative, the scoring algorithm is further refined periodically by the use of a closed-loop risk modeling process that allows fine tuning of the services provided by the system to adapt to new or changing fraudulent trading patterns. You. The legal scope of the invention is specified by the claims herein.
[0024]
In another aspect, the invention includes a computer device, a computer readable medium, and a carrier wave configured to perform the steps described above.
BEST MODE FOR CARRYING OUT THE INVENTION
[0025]
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings where like reference numerals refer to like elements.
[0026]
A method and apparatus for assessing e-commerce fraud risk is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
[0027]
[Unauthorized transaction detection method and system]
The present invention relates to a fraudulent transaction detection method, system and device for use in online service or credit card transactions through the Internet. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles of the present invention may be applied to other embodiments. Therefore, the present invention should not be limited to the embodiments shown, but should be accorded the widest scope consistent with the principles and features described herein.
[0028]
The present invention provides an integrated verification system for credit card transactions through online services or the Internet. FIG. 2 is a block diagram of a system 100 in which a verification procedure according to the present invention will be used. As in FIG. 1, system 100 includes customer 102 and merchant 104. The customer 102 presents the credit card to the merchant, and the merchant then integrates the information from the credit card with integrity, history, and other information to determine whether the credit card information is valid. To an integrated verification system ("IVS") 106, which includes various parameters provided in a configured manner. IVS 106 is typically implemented in software, for example, on a hard disk, floppy disk, or other computer-readable medium. In a typical embodiment, if customer 102 orders a particular software product that can be downloaded from merchant 104, the merchant will provide IVS 106 with a credit card number, email address, and other relevant information. Would. The integrated verification system 106 then weights various parameters to provide the merchant with a quantifiable indicator of whether the credit card transaction is fraudulent. To more clearly explain the operation of the system and method according to the present invention, the following discussion will now be made with reference to the accompanying drawings.
[0029]
FIG. 3 is a simplified block diagram for providing integrated verification of credit card transactions over the Internet. IVS 106 includes a controller 212 that receives credit information from the merchant and then sends that information to various parameters 202-208. A number of parameters operate on the information to provide an indication of whether the transaction is valid. In this embodiment, the plurality of parameters include a history check 202, a consistency check 204, an automatic verification system 206, and an Internet identity verification system (“IIDVS”) 208. The output of these parameters, ie, individual validity indicators, is provided to fraud detector 210. Fraud detector 210 combines these inputs to provide an integrated indication of whether a particular transaction is valid.
[0030]
The consistency check 204 allows the IVS 106 to determine whether the credit information matches, ie, whether the credit information matches the user and other information. The AVS system 206 provides information similar to the AVS 16 described in FIG. The core features of both the history database 222 and the Internet ID database 224 are that they are accessible and that the information in each database can be supplemented by various other merchants, and therefore their respective databases can The point is to get information from the traders.
[0031]
A history check 202 is also provided that also accesses a history database 222 that can include card numbers and email information. History check 202 will also actively determine whether a particular transaction matches historical database information in history database 222. Therefore, the Internet ID verification system 208 and the history check 202 become more useful over time. Internet ID verification system 208 comprises a system for verifying the validity of an Internet address, the details of which will be discussed later. The Internet identity verification system 208 includes a database 224 that can be added by other sellers, like the history check 202.
[0032]
In addition, the Internet identity verification system 208 accesses and communicates with a database of Internet addresses. This system will be used to verify whether the Internet address matches another Internet address being used for transactions using the credit card.
[0033]
Each of these various parameters is weighted by weighting blocks 214-220, depending on the particular credit card transaction. For example, if dollar trading is critical, it may be appropriate to weight history check 202 and AVS system 206 more strictly than other parameters. On the other hand, if the key point is the integrity of the Internet address, the integrity check and Internet identity verification system 208 may be more stringent. Accordingly, each of the verification parameters 202-208 may be weighted in various amounts, depending on their respective importance in the verification process.
[0034]
A particularly important feature of the present invention is its operation within the Internet verification system 208 and the integrated verification system 106. With the present system 208, it is possible to quickly determine whether or not the Internet identification address is being used fraudulently. To further illustrate this feature, it will now be discussed with reference to FIG.
[0035]
FIG. 4 is a flowchart of the Internet identity verification system 208. The goal of the Internet identity verification system 208 is to determine whether a physical address or the physical location of that address corresponds to a physical location previously used for a particular Internet address. Thus, in the flowchart of FIG. 4, first, step 302 results in a group of transactions processed from the database 224 using a particular Internet address. Then, according to step 304, a map of the obtained transactions is constructed based on these transactions. Finally, according to step 306, the constructed map is used to determine whether the new credit card transaction is valid. Thus, systems and methods according to the present system provide an Internet identity verification system that can quickly and easily determine whether a particular Internet address is involved in a particular credit card transaction.
[0036]
Accordingly, provided are systems and methods for accurately determining whether a particular credit card transaction is a fraudulent transaction. The integrated verification system weights various parameters to provide the merchant with quantifiable indicators of whether the credit and the transaction are fraudulent.
[0037]
[Unauthorized transaction screening and scoring system]
According to an embodiment of the present invention, there is provided an Internet fraudulent transaction screening system that tests e-commerce in real time, measures the level of risk associated with each transaction, and returns a correlated risk score to the merchant. Is done. In one embodiment, the system uses data validation, predictive artificial intelligence pattern matching, network data synthesis, and negative file checking to test a very large number of factors for calculating fraud risk. .
[0038]
According to one of the features, the system provides a closed-loop risk modeling process that allows the services provided by the system to be fine-tuned to adapt to new or changing fraudulent trading patterns. Use a scoring algorithm that is further refined periodically by the use of.
[0039]
In one particular embodiment, the merchant requests a fraud screening service from the system over the Internet using a secure, open messaging protocol. Upon receiving the request, the fraud screening system performs four levels of analysis. The first two levels utilize data elements submitted with the order and include data integrity checking and correlation analysis based on the nature of the transaction. The next two levels include a comparative analysis of the current trading profile against a profile of known fraudulent trading and a reference search of the trading database to identify abnormal speed patterns, first and last name changes and known fraudsters. . A risk score is generated and compared to the vendor-specific risk threshold. The result is returned to the merchant for the commissioned order.
[0040]
FIG. 5A is a block diagram illustrating a fraudulent transaction screening system, including situations in which the system may operate.
[0041]
Merchant 501 sends a request for service 503 to merchant service provider 502 via one or more networks 504 and receives a response 505 including a risk score for a particular transaction. In FIG. 5A, merchant 501 has one or more software associated with an online merchant, such as a computer program, web application program, CGI (Common Gateway Interface) or Perl script, etc. Wear elements can be included.
[0042]
Merchant service provider 502 is an entity that provides e-commerce services to online merchants. Such services may include, for example, payment services, tax calculation services, achievement management, delivery management, and the like. Merchant service provider 502 provides such services by or through one or more software elements that communicate over network 504. For example, the Internet Commerce Suite of CyberSource Corporation can provide such a service. The above information about the merchant service provider 502 is provided only to illustrate an example of the operation of the present invention, and does not constitute an essential element of the present invention.
[0043]
Network 504 is one or more local area networks, wide area networks, complex networks, and so on. In one embodiment, network 504 represents a worldwide packet-switched complex network aggregate known as the Internet. One merchant 501 is shown in FIG. 5A for illustrative purposes, but in an actual system any number of merchants could be included.
[0044]
Request 503 and response 505 can take a route through a secured channel between merchant 501 and merchant service provider 502. In one specific embodiment, each request 503 and response 505 conforms to CyberSource Corporation's Simple Commerce Message Protocol ("SCMP") from Mountain View, California, USA. Message.
[0045]
In one embodiment, one of the services provided by merchant service provider 502 is risk management service 506. As part of the risk management service 506, the merchant service provider provides a fraud screening and risk scoring system 507. The fraud screening and risk scoring system 507 communicates with a transaction history database 508 that maintains a record of a large number of previously completed e-commerce transactions. In this configuration, the fraudulent transaction screening and risk scoring system 507 receives the request 503 to the server, examines the transaction history database 508, performs various fraudulent screening checks, and generates a risk score for the transaction. Can be stored. Upon completion of the fraudulent transaction screening, a risk score for the transaction is returned to the merchant in response 505.
[0046]
The fraudulent transaction screening and risk scoring system 507 communicates with the credit card data source 509 having the data model creation and feedback mechanism 509A and the transaction result database 509B through the secured paths 506A and 509C. The credit card data source 509 maintains a database of information representing a large number of real credit card transactions, including both successful non-fraud transactions and transactions that resulted in a chargeback to the card-issuing bank by the transaction bank. That institution or system. In one embodiment, the credit card data source 509 is attached to one of the major U.S. credit card federations and thus comprises a huge database of credit card transaction and chargeback data.
[0047]
As discussed further herein, fraud screening and risk scoring system 507 may include one or more computer-implemented tests and mathematical algorithms for assessing fraud risk associated with a transaction. Can be used. The performance of the screening and scoring system is further refined with respect to predictability and accuracy by performing data modeling and feedback based on a comparison of the risk assessment values generated by the system with information in the transaction results database 509B. can do.
[0048]
For example, the fraudulent transaction screening and risk scoring system 507 receives the transaction information and specifies a risk score that indicates a relatively low risk of moving the transaction to completion, but in fact the transaction is a fraudulent transaction and the card holder issues a card It is assumed that a chargeback is requested from the bank to the seller 501. The chargeback request is processed by the credit card data source and a record is made in the transaction results database 509B. In this scenario, the credit card data source 509 periodically receives the transaction information and risk score via the path 506A and scrutinizes the matching information in the transaction result database 509B to improve the performance of the fraudulent transaction screening and risk scoring system 507. Can be improved. Based on the nature of the reconciliation information, the credit card data source 509 performs data model creation and feedback 509A and, via path 509C, provides the fraud screening and risk scoring system 507 with revised weighting or discrete scoring values, or Even new statistical algorithms can be provided. The fraud screening and risk scoring system 507 then uses the new information to perform a subsequent, more accurate screening evaluation.
[0049]
In this configuration, the cardholder's privacy is maintained by logically or physically isolating the merchant service provider from the credit card data source 509, as indicated by the dashed line 502A. That is, the credit card data source 509 is located at a different physical location so that the fraudulent transaction screening and risk scoring system 507 cannot directly query the transaction results database 509B or otherwise communicate with the database 509B. Can be built. In practice, database 509B is expected to be maintained with a high degree of security to protect the confidentiality of credit card numbers and purchase information in database 509B.
[0050]
FIG. 5B is a block diagram of a transaction verification system that may be used to implement the fraudulent transaction screening and risk scoring system 507.
[0051]
In general, the system of FIG. 5B can evaluate information representing one or more transactions to generate and store a score that represents the risk to the merchant with the transactions being processed. Transaction information 512, a list of good customers 512 and a list of bad customers 516, and other relevant information are received from a merchant who wants to screen transactions using this system. Transaction information 512 is a unique representation of a particular purchase transaction, such as customer name, shipping address, billing address, time of day, order, price or number of orders, payment method, card number and credit card expiration date. Contains information. Transaction information 512 can also include Internet-specific information such as customer domains, email addresses, IP addresses, and the like.
[0052]
Transaction history information 518 is also received from the merchant or maintained by the system. History information 518 includes information about past transactions processed by the system for the same seller and customer. The characteristic values in the history information 518 include the same values as described above with respect to the transaction information 512. That is, the history information 518 can include a database of records of past transactions. History information 518 is maintained in a database at the service provider processing the transaction.
[0053]
The list of good customers 514 and the list of bad customers 516 are past customers of the merchant that have been successfully paid by the merchant for the transaction ("good customers") or have been unpaid due to disputed transactions, fraudulent transactions, etc. Includes one or more tables or lists of information identifying customers who have been experienced with the "" (bad customer). Alternatively, the lists 514, 516 may include order information that has been marked as good or bad by the merchant, and in effect such a list may be a good or bad mark for the customer or the Internet identity of the customer. Will be treated.
[0054]
The transaction information 512 is first subjected to a transaction presentation test 510. The trade offer test 510 includes a plurality of computer-implemented filters, tests, calculations and other operations to determine whether the trade information 512 truly represents a good deal. For example, the trade presentation test 510 determines whether the trade information 512 is represented in an appropriate form, and the like, and provides a value representing the relative risk of whether the customer is attempting to pass a fraudulent trade order through the system. To reach. Further information regarding the trade offer test 510 is provided herein.
[0055]
If the transaction information 512 passes the transaction presentation test 510, then in a comparison operation 520, the transaction information 512 is compared to the historical information 518, resulting in one or more discrete scoring values 530 being generated and stored. . Each of the discrete scoring values 530 represents a relative risk assessment performed individually by the trade offer test 510 and the comparison operation 520. Further information regarding historical testing is provided herein.
[0056]
The discrete scores 530 are then provided to the statistical model 540, such that one or more weights and model scores are generated and stored. Statistical model 540 includes one or more weighting calculations or other computer-implemented mathematical operations that apply statistical formulas and weights to the discrete scores. The purpose of the statistical model 540 is to apply statistical analysis to the discrete scoring values 530 based on historical information 518 and other records of transactions that in fact have proven to be fraudulent.
[0057]
The discrete score 530 is also provided to a heuristic model 550 in parallel to generate a heuristic model risk rating.
[0058]
The model score obtained from the statistical model 540 and the heuristic model risk score obtained from the heuristic model 550 are blended using a score blend process 552 to generate an overall final risk score. That is, the scoring blending process 552 provides a method for combining heuristic model scoring with model scoring generated as output by the statistical model 540.
[0059]
Heuristic model 550 may also take into account one or more merchant-specific values 570. The vendor-specific value 570 may include, for example, the following:
[0060]
1. Product category information, such as a value that limits the maximum number of products in a particular category that customers can purchase online in a single transaction. Here, the product category may be specified by the transaction processing system or specified by the merchant.
[0061]
2. Sales frequency information, that is, the frequency with which a customer is allowed to buy a specific product within a specified period, for example, a reserved product that can be purchased only once a week.
[0062]
3. One or more intraday time weighting values that indicate how important the buyer's purchase time is or indicate a time period within the day that represents a reasonable time at which the buyer is expected to buy a particular product .
[0063]
4. A "risk host" weighting value that represents the amount of risk associated with the particular host where the customer's order was placed, as represented by the customer's originating IP address or the customer's assigned email domain.
[0064]
5. A gender deviation value that indicates whether a particular product is strongly expected to be associated with a particular gender buyer. Here, the risk increases if the system determines that the gender of the buyer is probably not suitable for the product.
[0065]
6. A value that represents the relative weight imposed by the merchant on the difference between the customer's billing and shipping addresses.
[0066]
7. A first "speed" value that indicates how often a buyer has made an online purchase anyway.
[0067]
8. A second "speed" value that indicates how often a buyer has made an online purchase of a particular product category from a particular seller.
[0068]
Use of vendor-specific values is optional.
[0069]
As a result of the blending of the heuristic model score and the statistical model score, a final score and one or more return code values are generated and stored, as indicated by block 560. In one embodiment, the final score is in the range of 0-100, where "0" represents a transaction that is very unlikely to be fraudulent and "100" is a transaction that is very likely fraudulent. Related to. The return code value represents a fairly special result or other function.
[0070]
In one embodiment, one of the return codes consists of one or more bytes indicating a reminder to advise the merchant to reject the transaction despite any of the merchant's other criteria. Includes score flag. For example, the score flag may indicate that the order violates one of the merchant's "speed" criteria or that a previous order for the individual who placed the current order is on the fraudulent trade list. Alternatively, a score flag may indicate that the customer placing the current order has been found in the bad customer list 516. If the customer's past orders are on the fraudulent trade list, this transaction is automatically added to the fraudulent trade list.
[0071]
The final score and return code values are returned to the merchant in one or more messages using an appropriate protocol. In one particular embodiment, the system of FIG. 5B generates an SCMP compliant message, packs the final scoring value and return code value into the SCMP message, and sends the SCMP message to the merchant over a secured channel.
[0072]
[Trade presentation test]
In one embodiment, the trade offer test 510 includes a plurality of tests selected from:
[0073]
1. The "Givarish City" test detects situations where the customer's city name value does not contain vowels, is too short, or contains three consecutive identical characters.
[0074]
2. The "Givelish surname" test detects situations where the customer's surname value does not contain vowels, is too short, or contains three consecutive identical characters.
[0075]
3. The "Givalish Name" test detects situations where the customer's name received from the merchant does not contain vowels or contains three consecutive letters.
[0076]
4. The "bad word in email" test detects a situation where the email address value received from the merchant contains a suspicious character string.
[0077]
5. The "bad word in name" test detects a situation where the name value received from the merchant contains a character string that is marked as high risk.
[0078]
6. The "bad word in surname" test detects a situation where the surname value received from the merchant includes a character string that is marked as high risk.
[0079]
7. The "bad word in city name" test detects situations where the city name value received from the merchant contains a character string that is marked as high risk.
[0080]
8. The "state change detection" test detects a situation where the past order associated with this request has a different state value with the past order.
[0081]
9. The "high credit card number" test detects situations where many different credit card numbers are associated with past orders in the past order associated with this request.
[0082]
10. The "long penalty" test detects a situation where a customer is trying to buy too many products during the long hedging period specified by the seller for this order.
[0083]
11. The "fraud list" test detects situations where information identifying the customer is found on an external fraud list.
[0084]
12. The "last name change detection" test detects a situation where a customer's last name value associated with a past order differs in a past order associated with this request.
[0085]
13. The "email / first name match" test detects a situation where the customer provided first name or last name value appears in the customer provided email address value.
[0086]
14． The "browser type penalty" test detects situations where a customer is using a web browser program that is marked as high risk.
[0087]
15. The "Browser email / email mismatch" test detects a situation where the email address stored as a configuration variable by the customer's web browser program does not match the email address provided by the customer in the order information. .
[0088]
16. The "no electronic product" test detects a situation where the order does not contain an electronic or digital product as opposed to a tangible product.
[0089]
17． The "poor telephone number length" test detects a situation where the telephone number value provided by the customer has an incorrect number of digits.
[0090]
18. The "invalid telephone number" test detects a situation where the telephone number value provided by the customer is invalid. For example, a U.S. telephone number with an area number of "555" or "111" is invalid.
[0091]
19. The "suspicious area code" test detects situations where the telephone number value provided by the customer contains a high risk area code value.
[0092]
20. The "area code / state mismatch" test detects a situation where the area code in the telephone number value is associated with a state different from the state value provided by the customer.
[0093]
21. The "Missing Area Code" test detects a situation where the area code value provided by the customer is not a valid area code or does not exist.
[0094]
22. The "free phone number" test detects a situation where the phone number value provided by the customer is a fee-free phone number.
[0095]
23. The "Foreign Domain U.S. Address" test states that the top domain portion of the email address value provided by the customer is foreign, but the shipping or billing address provided by the customer is a U.S. address. Detect the situation.
[0096]
24. The "Billing / Shipping State Mismatch" test detects a situation where the shipping state value provided for an order does not match the billing address state value in the credit card information provided with the order.
[0097]
25. The "Billing / Shipping Country Mismatch" test detects a situation where the shipping country value provided for an order does not match the billing address country value in the credit card information provided with the order.
[0098]
26. The "AVS" test determines whether the scoring value associated with the order should be adjusted based on the test results of the order information using the address verification system. An example of an address verification system is described in co-pending US patent application Ser. No. 09 / 444,530, filed Nov. 22, 1999, entitled "Method and Apparatus for Verifying Address." Has been described.
[0099]
27. The "BIN penalty" test is a penalty value because the bank identification number ("BIN") received from the customer, consisting of the first four to six digits of a regular credit card number, is marked as high risk. It is determined whether or not to apply.
[0100]
28. The "numeric / all lowercase surname" test determines whether the customer's first and last name values are all lowercase or contain numbers.
[0101]
29. The "Continuous Digit in Phone Number" test determines whether the customer's phone number value includes multiple consecutive digit strings.
[0102]
30. The “good” test determines whether matching customer information is found in the good customer list 514.
[0103]
31. An "unverifiable address" test can produce such results with international and military addresses that determine whether a customer address is unverifiable.
[0104]
32. The "City / State / ZIP Mismatch" test determines if the city, state, and ZIP code values provided by the customer are not related to each other based on data available from the United States Postal Service.
[0105]
33. The "IP Address / Host Name Mismatch" test determines whether the resolved IP address associated with the customer does not match or matches the host name portion of the email address provided by the customer.
[0106]
34. The "no hostname" test determines whether the IP address value received as part of the transaction information is not or is not resolved to a valid hostname value using the Internet's DNS (Domain Name Server) system. .
[0107]
35. The "Email in originating domain" test detects a situation where the email address value provided by the customer is in the same domain as the customer's resolved domain name.
[0108]
36. The "AOL user from non-AOL host" test indicates that the customer is an American Online user, but that the customer is communicating with the merchant from a host other than the AOL host. Detects the situation that means.
[0109]
37. The "ISP state mismatch" test detects a situation where the state value provided by the Internet Provider (ISP) as part of the resolved domain name does not match the state value provided by the customer. For example, the Microsoft network may provide state information to a customer as part of a decomposed domain name, such as "chicago-il.us.com", which may be checked against the state value provided by the customer in the transaction information. provide.
[0110]
38. The "Old Netcom Host" test detects a situation where a customer is using a shell account with Internet Service Provider Netcom (Netcom), which can be used to hide the true identity of the customer.
[0111]
39. The "Billing Country / Email Mismatch" test detects situations where the country value provided by the customer in the billing address information does not match the country value of the customer's email address.
[0112]
40. The "Billing Country / IP Host Mismatch" test is a situation where the country value provided by the customer in the billing address information does not match the country where the host indicated by the customer's IP address is located, based on disassembly using the DNS system. To detect.
[0113]
41. The "email / IP host country mismatch" test detects a situation where the country value in the customer's email does not match the country of the resolved domain name.
[0114]
42. The "While Check Mismatch" test indicates that the country associated with a customer's IP address does not match the country value of the customer's address information, according to the "Whereis" database from Network Solutions Inc. Detect the situation.
[0115]
43. The "time risk" test determines the degree of risk of trading time within a day.
[0116]
44. The "host risk" test determines the degree of risk of the internet source location where the transaction originated, based on the email address or internet domain IP address.
[0117]
45. The "gender mismatch risk" test determines whether a customer's gender is against the normative prediction for a particular product.
[0118]
46. Some “fast” tests determine the degree of risk of a buyer's behavior over time; one of these tests is more general and analyzes the overall pattern of buyer's e-commerce behavior; The test is more specific and analyzes the behavior of the buyer at a particular merchant site for a particular product category.
[0119]
47. The "gift" test determines whether any mismatch between the billing address and the shipping address is risky.
[0120]
FIG. 7A is a flowchart of a process for applying a geographic location test based on an area code.
[0121]
The geographic location test of FIG. 7A uses information in two tables. At block 702, a city orientation table is generated and stored. The city orientation table has a row corresponding to the city value of the customer's shipping address. The columns of the table store a city name, a longitude value indicating the absolute longitude of the city, and a latitude value indicating the absolute latitude of the city. At block 704, an area code bearing table is generated and stored. The area code bearing table has a row corresponding to all possible or known area code values. The columns of the table store one or more longitude and latitude values representing the boundaries of the area included in the area code. Alternatively, the area code direction table includes an area code value stored in association with a vector indicating the boundary of the area code by latitude and longitude.
[0122]
The values provided in the table can be used to test the information provided by the prospective customer. In one approach, a city value received from a customer is tested to determine whether it is within an area code value submitted by the customer. For example, the location of the center of the city indicated by the city value submitted by the customer is determined and then correlated with the values in the area code direction table. In other words, this test determines whether the area code specified by the customer actually includes the city specified by the shipping address.
[0123]
At block 706, a city value and an area code value are received from shipping address information in an order or transaction information for a customer. As indicated by the dashed line separating block 704 and block 706, actions in block 706 may occur at time intervals independent of blocks 702 and 704. Independent time intervals can be of any length. That is, blocks 702 and 704 can be considered as preparation steps, which can be performed in offline mode or at another time.
[0124]
At block 708, the latitude and longitude values associated with the received city value and the received area code value are determined. In one embodiment, the first latitude value and the first longitude value are obtained by looking up a city value in a city azimuth table, and the second latitude value and the second longitude value are obtained by an area code azimuth table. It is obtained by looking up the received area code value within.
[0125]
At block 710, the system tests whether the received city value is within the received area code value based on the latitude and longitude values. If not, a penalty value is given to the transaction, as indicated by block 712. If the city is found correctly within the boundaries of the specified area code, no penalty is given and control continues with other tests or order processing.
[0126]
FIG. 7B is a flowchart of a process for applying another geographic location test based on email address.
[0127]
In the test of FIG. 7B, a latitude value and a longitude value for each shipping address are generated and stored for all orders from the specified e-mail domain. If multiple past orders are concentrated in a particular latitude and longitude value range, and then an order is received that provides a shipping address outside the latitude or longitude value range, the later order will be high. Reported or tagged as risk.
[0128]
The database table can store latitude and longitude values and information identifying past orders or past customers. At block 714, a latitude and longitude value is generated for each shipping address of the order processed by the transaction processing system and stored in association with information indicative of the designated email domain. That is, suppose that transaction information including the customer's email address in the form of "john_custname@isp.com" and the shipping address to the customer John Custname has been received. Based on the city value of the shipping address, the system calculates the latitude and longitude values for that city value or otherwise determines (e.g., by looking up a city orientation table generated as part of FIG. 7A). I do. A record containing the domain value “isp.com”, latitude and longitude values is generated and stored in the database. The process of block 714 is performed each time a transaction is processed in the system.
[0129]
At block 716, the city value from the prospective customer's email address and the shipping address portion of the transaction information for the new order is received. That is, block 716 may be performed simultaneously with block 714, or with some delay. At block 718, a latitude and longitude value for the received city value is determined.
[0130]
At block 720, the process tests whether the received city value is too far or not too far from the domain indicated in the received email address value. For example, the process calculates a difference between a received city value and a standard calculated in block 718 where the latitude and longitude values represent the corresponding value in the database, eg, the standard deviation value for the latitude and longitude values. It can be determined whether it is too large. Using another mechanism to determine that the city value received is too far from the geographical area indicated by all other city values for other transactions that reference the same email domain. it can.
[0131]
If the test in block 720 determines that the distance is too far or the difference is too large, a penalty is applied to the trade, as shown in block 722. Otherwise, control continues with another test or process.
[0132]
This test is useful when a particular Internet Service Provider (ISP) provides a geographically aggregated customer database. In that case, if the order arrives with a shipping address that is distant outside the ISP's normal geographical service area, the system will assume that the customer is using stolen identity information or stolen credit card information. Can be assumed. Such tests can be supplemented with a human scoring of the score to ensure that the rate of false negative results ("insults") is not too high.
[0133]
FIG. 7C is a flowchart of a geographic location test based on a bank identification number (BIN).
[0134]
In FIG. 7C, the BIN value of the credit card number provided by the prospective customer is used for geographic consistency screening. At block 724, the country value of the shipping address is stored for each order processed by the system in association with the BIN value of the credit card number specified in the order. That is, block 724 includes building a table relating the BIN value of the shipping address location of the actual order. Alternatively, in the BIN value geographic consistency screening, a range of latitude and longitude values are stored in the database in association with the BIN value.
[0135]
At block 726, a country value is received from the shipping address portion of the transaction information for the new order. At block 728, the relative proximity of the current shipping address country to all other countries associated with the bank identification number specified in the order is determined. Block 728 may include, for example, a lookup of a distance or weight value in an international distance table that correlates each of all countries in the world with each of the other countries in the world. The distance value or weight value may reflect a geographic distance, a political distance, a cultural distance, and the like. For example, the value of correlating the United States to Canada would be very high, while the United States would be geographically close to Cuba but politically distant, so the United States would be Will be very low.
[0136]
At block 730, a comparison is made to determine whether the country represented by the country value of the current order is too far from the bank due to the BIN value, as indicated in the cross-country table. If too far, a penalty is applied, as shown in block 732.
[0137]
That is, if a plurality of past orders containing a specified BIN value are concentrated in a particular range of countries, and then an order is received that provides a shipping address in a country outside of that range, then a later order is received. The order is reported as high risk or tagged. This test is useful when a particular bank provides a geographically aggregated customer database. In that case, if the order arrives with a shipping address that is far away from the bank's normal geographical service area, the system will assume that the customer is using stolen identity or stolen credit card information. Can be assumed. For example, a customer presents transaction information 512 identifying a credit card number with a BIN value associated with a bank headquartered in New York, USA, but the shipping address for the order includes the country value of "Bulgaria". Suppose you have This may indicate that the order is fraudulent. Such tests can be supplemented by human scrutiny of scores to ensure that the insult rate is not too high.
[0138]
[Gibalish test]
The trade offer test 510 may include one or more values for determining whether one or more values of the trade information 512 consist of incomprehensible or meaningless text ("givalish"). Testing can be included. FIG. 6 is a block diagram of an exemplary embodiment of the Givarish test.
[0139]
At block 602, a text value is received for subject to a Givarish test. For example, the Givarish test can be applied to customer name or surname values received from a merchant for a particular customer.
[0140]
At block 604, a bigram probability table is received. In one embodiment, the bigram probability value table includes a row representing a character pair ("bigram") and a designated bigram where (a) the first character pair of the text string and (b) somewhere in the middle of the text string. Consists of a sequence representing the probabilities that will appear as a crab or (c) as the last character pair of a text string. Here, one column of the table is related to situations (a), (b) and (c).
[0141]
An example of a bigram is "DA". For this bigram, the table sets the first "80" to indicate that the character pair "DA" is likely to appear in the first ordinal position of the true name, as in "DABID" or "DANIEL". Could be in the row position. For the same bigram, the true name could have the value "20" in the second column position indicating that the character pair "DA" is unlikely to be in the middle of the name. Other numerical values can be used. In one particular embodiment, the bigram probability table is created and stored manually or automatically based on first and last name information received from a trusted source. For example, first and last name information from US census data can be used.
[0142]
At block 606, for each bigram in the text value received at block 602, a scoring value is determined based on the bigram probability table. In one embodiment, block 606 includes extracting each of the bigrams in the received text value and looking up a table for each such bigram. For each bigram, a score is generated based on the corresponding probability value found in the table. If a bigram is not found in the table, a default value can be assigned, generally representing a low probability.
[0143]
As indicated at block 608, the scoring determination at block 606 preferably ignores or excludes received text values, including acronyms. In one embodiment, the acronym is recognized when the first received text value (eg, first name) is all uppercase and the second received text value (eg, last name) is mixed case. Is done. If an acronym is detected, the scoring value determined at block 606 may be modified or set to a default value.
[0144]
As indicated at block 609, special character combinations may be considered. For example, in one embodiment, the process of block 606 seeks to determine the ethnicity associated with the received text value and, if such a determination is made, may adjust the values obtained from the table. For example, in a large number of random first and last name samples, the bigram "SZ" may be less likely to appear in the first ordinal position of the last name. However, this combination is common in surnames from Eastern Europe. Thus, if the process can determine that the received name seems to be an Eastern European name, the likelihood of another character pair appearing in the received text is increased. For example, the possibility that the character pair “CZ” appears may be increased. Accordingly, the probability values taken from the table for such character pairs can be adjusted as appropriate.
[0145]
Separate tables can be created and stored for name values and surname values. That is, block 604, block 606, block 608, and block 609 can be repeatedly executed for each of the name value and the last name value.
[0146]
Based on the scoring value determined in block 606, the process generates or generates one or more error or warning values. In one embodiment, block 606 can include a screening process in which a scoring value is generated that indicates an error only if a bigram in the received text value cannot be found anywhere in the probability table. This option can be used to reduce processing time or if only a rough check of the text value is needed.
[0147]
Alternatively, at block 610, an alert value is generated if the received text value includes a combination of bigrams determined to be unlikely to be associated with a true name or surname.
[0148]
As another alternative, a warning value is generated only if the received text value contains a very unlikely combination of bigram values. In this alternative, a warning value is chosen to indicate that the text value received is suspicious but not abnormal enough to warrant a rejection of the transaction by the merchant.
[0149]
The bigram probability table can be updated as additional information becomes available, for example, at census intervals. Another table can be created for first and last name values of foreign nationals, for example, Japanese names expressed in kana characters.
[0150]
[History test-comparison operation]
In one embodiment, the comparison operation 520 includes a comparison of the transaction information 512 with the historical information 518 to generate and store one or more discrete scores 530 as a result. Such historical testing generally includes verification that the current transaction information 512 is consistent with all of the past transactions associated with the individual.
[0151]
In one embodiment, the transaction is associated with an Internet identity. As used herein, "Internet identity" includes the unique identifier of a buyer or other individual submitting an order transaction. Internet identities can include email addresses. Such an Internet identity helps to easily get better screening results if an individual uses multiple different email addresses to place an order.
[0152]
FIG. 5C is a block diagram of an alternative embodiment of the Internet identity. The internet identity value 590A of the first embodiment comprises a combination of a hash value based on the email address, as shown in block 592, and a hash value based on the credit card BIN value, as shown in block 594. The use of a value that includes a credit card number as a building block helps to improve the accuracy of individuals using multiple credit cards for various users. In this embodiment, each Internet identity value uniquely identifies a particular combination of email address and card.
[0153]
In any of the above embodiments, the system may use a value that uniquely identifies a purchase method other than a credit card instead of a credit card number. For example, if a customer uses an electronic check or debit card to make a purchase, the check number or card identifier can be used to create an Internet identity.
[0154]
Other combinations of values can be used. Referring again to FIG. 5C, the internet identity value 590B of the second embodiment is based on a hash value based on the email address, as shown at block 592, and a credit card BIN value, as shown at block 594. It consists of a combination of a hash value and a hash value based on the shipping address, as shown in block 596. This alternative improves accuracy if different email addresses and credit card numbers are used for multiple orders, but the shipping addresses are all the same, especially for home delivery.
[0155]
Still other values could be used. For example, the first hash value of the purchaser's host IP address is combined with the second hash value of the e-mail address of the purchaser, and the third hash value of the purchaser's card bank identification number and the purchase It can be included in the Internet identity in combination with a fourth hash value based on the prospective ship-to address. As another alternative, the first hash value of the hardware device ID value of the prospective purchaser is combined with the second hash value of the prospective purchaser's email address or user ID to obtain the purchaser's card bank identification number. And a fourth hash value based on the shipping address of the prospective buyer can be included in the Internet identity. What is important is to use a value that accurately represents the identity of a particular Internet user that is repeated across multiple orders, regardless of the host or terminal that the Internet user uses to connect to the network.
[0156]
Past transactions in history information 518 associated with the Internet identity of the current transaction can be performed, for example, by issuing a database query to a database holding past transaction information and receiving a set of records as history information 518 in the response. Obtainable. Once the record has been retrieved, comparison operation 520 looks for information indicating that the comparison operation should be stopped. In one embodiment, the system skips comparison operation 520 if any of the records returned from the database for the previous order are on the fraudulent trade list. By this mechanism, unnecessary processing on orders associated with past fraudulent trading orders is skipped, since processing would undoubtedly result in a negative result if such orders were processed using comparison operation 520. Is guaranteed. Alternatively, if more than 500 history records are retrieved, the history processing is stopped and the comparison operation 520 is performed using only the retrieved 500 records. As a result, query time and total transaction processing time are reduced. In addition, Internet identities associated with test identities created by the merchant to verify operation of the system are excluded.
[0157]
In one embodiment, one of the return codes includes a score flag of one or more bytes representing a reminder to advise the merchant to reject the transaction despite any other criteria of the merchant. For example, the score flag may indicate that the order violates one of the merchant's "speed" criteria, or that a previous order for the Internet identity that placed the current order is on the fraudulent trade list. Alternatively, the score flag may indicate that the customer placing this order has been found in the bad customer list 516. If a customer's past orders are on the fraudulent trade list, this transaction will automatically be added to the fraudulent trade list.
[0158]
Since a transaction processing system of the type shown in FIG. 5B processes transactions, the transaction processing system can generate and store historical information 518. In one embodiment, the system generates and stores one or more score logs. Each record in the score log identifies a transaction and includes one or more penalty values resulting from the application of the system's other tests to the transaction submission test 510 and the transaction information 512. That is, manual or automated scrutiny of the score log can reveal how a particular transaction was processed in the system.
[0159]
Further, in one embodiment, the system includes a test scorecard, and the system updates the test scorecard values as the transaction is processed. The test scoring table includes, for each order, the result value or penalty value for each test performed on one order. In certain embodiments, the test scoring table includes a column for order numbers, email addresses, credit card numbers, and a column for each test performed as part of transaction offer test 510. The test scoring table may also include model scores provided as output from the statistical model 540, as well as final scores and return codes provided at block 560 of FIG. 5B.
[0160]
Therefore, a statistical evaluation value of the test result can be generated by using the data in the test scoring table. Further, a database query can be applied to the test scoring table to retrieve related orders in some manner. In the past, such processing required a test parse of the score log for such processing. The approach of the present invention eliminates such parsing and provides a test-based view with improved practical significance. As a result, the insult rate of a particular test can be quickly and regularly evaluated.
[0161]
Further, as a result of the transaction processing, a high fraudulent transaction score is obtained, and if the seller responds to the score and rejects the order and initiates a customer inquiry, the seller's customer service center will respond to the return code. Queries can be issued to quickly determine the exact reason for a high fraudulent transaction score. The ability to get a return code in a quick manner allows a rejected customer to call the seller and speak to the seller's computer-based fraud screening by appealing to the sentiment of the seller's customer service representative Weapons for "social work" are also offered to merchants, trying to escape skillfully and try to spin out one or more reasons that the order should be accepted. With the disclosed system, a customer service representative can quickly query the fraud screening system and receive a detailed description of why the order was rejected. Such an explanation can occur based on one or more return code values.
[0162]
[Create statistical model]
Statistical model 540 includes a plurality of calculations based on real discrete scores weighted with non-linear combinations based on probabilities of indicating real fraudulent transactions. In one embodiment, such weighting includes the identification of an order that is actually completed and that actually results in a chargeback to the issuing bank associated with the credit card identified in the order. The method generally ignores orders rejected by the fraud screening system as part of the trade submission test 510 disclosed herein.
[0163]
FIG. 9 is a block diagram of the statistical model creation process. In one embodiment, the statistical model creation comprises a data selection and sampling phase 902, a data normalization phase 904, a data partitioning phase 906, a model training phase 910, a model verification phase 912, and a model performance testing phase 918. Many of these phases can involve providing feedback to the upstream phase, as shown in FIG.
[0164]
Data selection and sampling
In general, phase 902 of the statistical model creation process consists of data selection and sampling. As used herein, the term "data" refers to transaction data marked true. "Marked true" means that the transaction record is the net result of the transaction-whether the transaction ultimately resulted in a loss, such as a chargeback or suspicious credit return, or the transaction resulted in a profitable sale- Includes a field that indicates During this phase, a modeling data source marked true is selected. If a model should provide customer protection to a single distributor, the vendor-specific data will dominate, but the modeling dataset will include similar vendors to extend the modeling infrastructure. Could also include representative data from If the model should be useful for an entire industry, the data will be chosen extensively to represent sellers in that industry. However, if the applicability of the model is widened, the range of data selection will be equally wide.
[0165]
However, the above transaction data is not used as it is for creating a statistical model. Transaction data is downsampled. Downsampling is a statistical process in which the modeler achieves an optimal balance between high-risk and low-risk transactions in the modeling dataset by biased random sampling. The modeler establishes an optimal mixing ratio based on the theoretical properties of the model to be built. For example, high-risk transactions are often rarer than low-risk transactions. If the selected data is used as it is for model building, low risk transactions may dominate and mask signals from rare high risk items. It is desirable to balance. In general, to achieve the desired ratio, all high-risk items in the selected dataset are accepted, and the low-risk items are randomly downsampled to reduce the ratio of low-risk data items to high-risk data items by 10: 1. ,can get.
[0166]
Data normalization
Statistical modelers generally respond best to numerical data with numerical behavior. Since the transaction data and test result data, in principle, include values from the full numerical range, the data may be statistical z-transform, or all data values may be in the range of -1 to +1 or less optimal. Is normalized by applying some other such transformation to fit in the range of 0 to 1. This makes the model creation work more stable and the results more robust. These functions are performed in the data normalization phase 904.
[0167]
Data partitioning
In the data partitioning phase 906, the selected and sampled data is divided into three partitions: a mutually exclusive data set: a training set, a validation set, and a test set. The ratios for these data sets are not specified, but ratios such as 50-50 and 60-40 are commonly used. For example, using a ratio of 60-40, 60% of the model creation data is randomly selected for education and verification, and the remaining 40% is reserved as test data for the model test phase. The 60% selected for model building is further divided into educational and validation data, all involved in the model building phase 908, according to another rule of thumb, such as 65-35. All of the segmentation is performed using a pseudo-random number generation algorithm.
[0168]
Model education
Once the model creation data has been selected, sampled and normalized, a model training phase 910 is performed. The first step is to select or generate candidates for the initial model architecture. For non-linear statistical models, such as neural networks or basis function networks, this involves configuring the input layer according to the dimensions of the combination of features of the model forming data, and adapting the output layer to the requirements of the model domain. Configuring and then selecting an initial number of “hidden units” or “basic function units”. If the requirements of the model domain are simply to provide a simple numerical assessment of the trading risk, a single unit output architecture is chosen. If the model domain requires categorization of transactions into multiple risk type assessments, the output layer will be tailored to the dimensions of the target category set.
[0169]
In each of the successive education cycles, the training data is provided to the model one transaction at a time, with the model providing an "optimal balance" on the entire dataset surface-the correct risk rating for low risk trades and the correct risk for high risk trades. The model weights can be self-adjusted in an attempt to achieve a balance between the evaluation values. The education cycle ends when the rate of successful weight adjustments begins to become asymptotic or becomes constant, as measured by continuous improvement in mean square error. Educating beyond that point will later, in the performance testing phase, condition the model exclusively for educational data so that it will fail to generalize the model to similar data patterns that have not been encountered before. "Overfitting" can occur. If the model cannot be educated until the criterion is reached, the modeler returns to one of the upstream phases, adjusts to prevent model creation failure in the next cycle, and reenters the model creation cycle. The most common step to get into model building is to return to the beginning of the model training process and make adjustments to the architecture, but could return to the data selection and sampling phase if necessary.
[0170]
Model validation
Either the educated model or the fully educated model is subjected to validation in a model validation phase 912. During this phase, the model behavior is checked against common sense criteria by imposing some validation data on the model. In a sense, this is a provisional form of performance testing. The difference is that as adjustments are made to the model, the validation data used to determine the nature of the required model changes becomes part of the ongoing education dataset. In general, after some disadvantages of the model have been revealed by the verification cycle, the model building process re-enters one of the upstream phases. The above cycle between the model education phase 910, the model verification phase 912, the model adjustment and the model re-education completes the general model construction phase 908.
[0171]
Model test
Upon completion of the model building cycle, the completed model is subjected to a model performance test in a test phase 918. 40-50% of the originally selected and sampled data, reserved for performance testing, is now charged to the model. This transaction data has never been given to the model. The model scores all of the remaining data, without allowing any modifications to the weights or architecture. The scoring results are analyzed. If the performance of the model has reached the standard, the model has been created and this statistical model is ready for deployment on the fraudulent production risk assessment system, where the transactions are presented to the system in real time, The transaction will be given to the model so that a numerical risk assessment is made for that transaction. The numerical risk assessment can be interpreted as a fraud probability, indicating that the transaction is likely to be bad.
[0172]
If the performance of the model has not reached the standard, the modeling process is restarted from the beginning with a new data selection and sampling cycle, as shown in FIG.
[0173]
Input, seller data
1. Data selection and downsampling
2. Discrete score calculation and normalization
3. Data segmentation into education, validation and test sets
4. Model building
5. Model performance test
6. Model deployment in production environment
7. Run-time performance analysis of the model
Output, statistical model risk evaluation value
[Heuristic model]
The heuristic model 550 includes one or more artificial intelligence calculations that compute a weighted sum based on a linear combination of the discrete scores. Heuristic calculations are performed on the results of the heuristic test. This is a very complex scoring process that takes place at each stage, resulting in a single numerical risk assessment. This risk rating then serves as a basis for the scoring value blending process 552, which establishes the risk zones that structure the blending process. This blending process is discussed in more detail in the appropriate section.
[0174]
First, the raw score total is calculated as a weighted sum of the discrete test results. There are four types of discrete test results: Boolean, quantitative, categorical, and stochastic. Boolean true-false results are given a value of zero or one. Quantitative results are given a value as a positive integer representing the arithmetic occurrence count. Categorical results indicate severity levels. A stochastic result indicates a confidence level. Each discrete test result is multiplied by the associated penalty value and the products are summed to produce a raw score total. The penalty value associated with each test can be negative or positive. Negative penalty values decrease the risk probability, and positive penalty values increase the risk probability. The obtained raw score total value indicates the face value of the transaction risk and the transaction status risk.
[0175]
Next, the heuristic model calculates a raw score multiplier. The raw score multiplier is analogous to a "gain control" device. The raw score is increased based on a combination of certain test results and the policies expressed by the vendor for those test results. If the merchant has shown a particular interest in a particular test, the results of that test are multiplied by a factor to boost or decrease the score-most often to boost it. Based on the seller's priorities for the designated tests and the results of those tests, a score multiplier is calculated and applied to the raw score total to obtain a "classical" score. The resulting classic scores range from 0 to very large numbers that can be greater than 100,000, and this upper limit is considered to be exponentially distributed.
[0176]
Finally, the classic score is scaled down and converted to a linear estimate of the trading risk probability. This heuristic model scoring value is in the range of 0 to 99 and is an evaluation value of the risk probability. This heuristic estimate is later combined with the results of the other models by a numerical fusion process described in a later section of this specification.
[0177]
Input, discrete score
8. Raw score calculation
9. Scoring multiplier calculation
10. Classic score calculation
11. Proportional reduction to appropriate range
Output, heuristic model risk evaluation value
[Risk evaluation value blend]
The risk probability estimates derived from the heuristic model 550 and the statistical model 540 are blended or fused to produce a final global risk probability estimate for the transaction-seller-card-scamper combination. This is commonly referred to as the fraudulent score, but is referred to herein as the risk rating. Blending is done in the context of the basic statistical dilemma that all discrete decision systems face. This situation is shown in FIG.
[0178]
FIG. 10 shows two frequency distributions, that is, the score distribution of good transactions and the score distribution of bad transactions. Four risk zones are established by superimposing the distribution of risk assessments recognized for truly bad transactions on the distribution of truly good transactions. Risk zone 1 begins at the minimum risk probability (risk score 0) and extends to the point where the occurrence of fraudulent transactions is no longer trivial. Risk zone 1 includes low-scored transactions that are very unlikely to be fraudulent transactions.
[0179]
Referring again to FIG. 10, risk zone 2 begins at the point where the occurrence of fraudulent transactions is no longer insignificant in the generally non-fraud trading zone and extends to the point where the good transaction frequency surface and the bad transaction frequency surface intersect. This boundary is also defined as the error minimization point (EM), the point at which the risk of type 1 error and the risk of type 2 error are balanced, and is recommended as a default discrete decision threshold. Many. Most of the transactions included in the risk zone 2 are not fraudulent transactions, but also fraudulent transactions with medium to low scores are mixed. A second type of error (also known as mistakes, false positives and mis-sells) occurs when fraudulent transaction scores are in risk zones 1 and 2, and therefore fraudulently accepts and processes fraudulent transactions.
[0180]
Risk zone 3 of FIG. 10 begins at the default error minimization point and extends to a point in the generally fraudulent trading zone where the occurrence of non-frauding is negligible. Most of the transactions included in the risk zone 3 are fraudulent transactions, but non-fraud transactions with a medium to high score are also mixed. Risk zone 4 begins at a point where the occurrence of non-fraud trades with a mid-high scoring value is insignificant and extends to the upper end of the scoring value range. Risk zone 4 includes high-scoring transactions, which are very likely to be fraudulent transactions. A first type of error (also known as false warning, false positive or false resale) is when a non-fraud transaction score is in risk zones 3 and 4 and therefore erroneously refuses to process a non-fraud transaction. Get offended.
[0181]
The scoring value (risk evaluation value) of the statistical model 540 and the heuristic scoring risk evaluation value of the heuristic model 550 are blended in the scoring value blending process 552 as follows. A blend policy is established for each of the four risk zones, and the magnitude and direction of the effect allowed for the model is defined. The policy is a function of both 1) the nature of the risk assessment algorithm that gives the score to be blended and 2) the nature of the risk zone itself. In one embodiment, a heuristic model is used as the basic scoring authority to establish the boundaries of all risk zones. In this embodiment, the purpose of the statistical model is primarily to protect non-fraud trades from accidentally accepting high risk ratings (to prevent false alarms), and most non-fraud trades are essentially The statistical model is given full responsibility for lowering the risk rating in zone 1 and limited authority to lower the risk rating in zone 2 because it falls into risk zones 1 and 2 specifically. Furthermore, in this exemplary embodiment, the purpose of the heuristic model is primarily to optimize fraud detection (and thus avoid mistakes), and most fraud is essentially zone 3 And 4, the heuristic model is given full responsibility for generating the risk rating in zone 4 and primary responsibility for generating the risk rating in risk zone 3. The statistical model is given limited authority to increase the risk table value in zone 3.
[0182]
If the heuristic model risk rating falls into risk zone 1, the statistical model generates a final risk rating. If the heuristic model risk rating falls into risk zone 4, the heuristic model generates a final risk rating. If the heuristic model score falls in Zone 2 or Zone 3, special marginal surface logic is applied as appropriate to minimize false alarms and mistakes.
[0183]
Referring now to FIG. 11, a critical surface (class 1 limit) is established below the heuristic scoring surface to help minimize the likelihood of a type 1 error, and a critical surface (second type limit). The species limit is established above the heuristic scoring plane to help minimize the possibility of type 2 errors.
[0184]
If the heuristic model risk assessment value falls into zone 2 and the statistical model risk assessment value falls between the first-class limit surface and the heuristic model surface, the statistical model risk assessment value gives the final risk assessment value for obvious non-fraud trades. Can be lowered. Otherwise, a heuristic model generates a final risk rating.
[0185]
If the heuristic model score falls in zone 3 and the statistical model score falls between the second limit surface and the heuristic model surface, the final risk assessment value can be increased by the statistical model score. Otherwise, a heuristic model generates a final risk rating.
[0186]
In general, the contribution of the side-by-side model to the final risk rating is determined during blending by considering the strengths and weaknesses of each of the models to be blended in light of the distribution characteristics of the various risk zones.
[0187]
[Hardware Overview]
FIG. 8 is a block diagram illustrating a computer system 800 on which embodiments of the present invention may be implemented. The computer 800 includes a bus 802 or another communication mechanism for information communication, and a processor 804 connected to the bus 802 for information processing. Computer system 800 also includes a main memory 806, such as a random access memory ("RAM") or other dynamic storage device, coupled to bus 802, for storing information and instructions to be executed by processor 804. Prepare. Main memory 806 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read-only memory (“ROM”) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic or optical disk, is provided for storing information and instructions, and is connected to the bus 802.
[0188]
Computer system 800 can be connected via bus 802 to a display 812, such as a cathode ray tube ("CRT"), for displaying information to a computer user. An input device 814, comprising alphanumeric keys and other keys, is connected to the bus 802 to communicate information and command selections to the processor 804. Another type of user input device is a cursor control device 816, such as a mouse, trackball or cursor movement keys, for communicating directional information and command selection to the processor 804 and for controlling cursor movement on the display 812. is there. The input device generally has two degrees of freedom in two axes, a first axis (eg, x-axis) and a second axis (eg, y-axis) that allow the device to specify a position on a plane. Having.
[0189]
The invention is related to the use of computer system 800 for assessing e-commerce fraud risks. According to one embodiment of the invention, the e-commerce fraud risk assessment is performed by processor 804 executing one or more sequences of one or more instructions held in main memory 806. Provided by the computer system 800 accordingly. Such instructions can be read into main memory 808 from another computer-readable medium, such as storage device 810. Execution of the sequences of instructions held in main memory 806 causes processor 804 to perform the process steps described herein. In an alternative embodiment, a hardwire connection circuit can be used instead of or in combination with software instructions for the practice of the present invention. That is, embodiments of the present invention are not limited to any particular combination of hardware circuitry and software.
[0190]
As used herein, “computer-readable storage medium” refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic storage, such as main memory 806. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
[0191]
Common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes or other magnetic media, CD-ROMs, any other optical media, punch cards, paper tapes, perforations Any other physical medium with a pattern, RAM, PROM (Programmable Read Only Memory), EPROM (Electrically Programmable Read Only Memory), Flash EPROM, any other memory chip or cartridge, described below Such a carrier or any other medium that can be read by a computer.
[0192]
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions can first be placed on a magnetic disk of a remote computer. The remote computer can load the instructions into the computer's dynamic storage and send the instructions over a telephone line using a modem. A local modem in computer system 800 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector receives the data transmitted in the infrared signal and appropriate circuitry can place the data on bus 802. Bus 802 sends data to main memory 806, and processor 804 retrieves and executes instructions from main memory 806. The instructions received by main memory 806 may be stored on storage device 810 before or after execution by processor 804, as appropriate.
[0193]
Computer system 800 also includes a communication interface 818 connected to bus 802. Communication interface 818 provides a two-way data communication connection to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an integrated services digital network ("ISDN") card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a LAN card to provide a data communication connection to a compatible local area network ("LAN"). Wireless links can also be implemented. In any such embodiment, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
[0194]
Network link 820 generally provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data devices operated by an Internet Service Provider (“ISP”) 826. Subsequently, ISP 826 provides data communication services over a worldwide packet data communication network, now commonly referred to as the "Internet" 828. Local network 822 and Internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. Signals through various networks that carry digital data to and from computer system 800 and signals on network link 820 and through communication interface 818 are typical forms of carrier waves that carry information.
[0195]
Computer system 800 can send messages and receive data, including program code, via network (s), network link 820, and communication interface 818. In the Internet example, server 830 could transmit the requested code for the application program via Internet 828, ISP 826, local network 822, and communication interface 818. According to the present invention, one such downloaded application provides for analysis of a layer 2 path in a switch network as described herein.
[0196]
The received code may be executed by processor 804 as it is received and / or stored in storage device 810 or other non-volatile storage for later execution. In this aspect, computer system 800 can obtain application code in the form of a carrier.
[0197]
[Alternatives and variants]
Thus, a computer-based processing method for evaluating the risk of fraudulent transactions associated with electronic commerce has been described. In the embodiments disclosed herein, such processing methods provide for the identification of potentially fraudulent transactions, while reducing false positive and false negative results.
[0198]
The use of the system disclosed herein with credit card authentication and AVS maximizes the number of active orders that are converted to sales, minimizes the risk of fraudulent transactions, and thus has the business ability to be reflected in financial results. Can be strengthened. Although it is not necessary to use card authentication and AVS within the scope of the present invention, merchants who use AVS and receive only orders where AVS = match, You will notice that the lower the number of fraudulent transactions, the higher the turnover level. Similarly, merchants who receive all authorized orders, except for AVS = mismatched orders, will continue to enjoy high levels of sales conversion with reduced fraudulent transactions with the systems disclosed herein. Would.
[0199]
In the above specification, the invention has been described with reference to specific embodiments of the invention. It will be apparent, however, that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. Therefore, the spirit of the specification and drawings should be regarded as illustrative and not restrictive. The legal scope of the invention is specified in the claims.
[Brief description of the drawings]
[0200]
FIG. 1 is a block diagram of a credit card verification system.
FIG. 2 is a block diagram of a system that can use the verification procedure of FIG.
FIG. 3 is a simplified block diagram for providing integrated verification of credit card transactions over the Internet.
FIG. 4 is a flowchart of an embodiment of the Internet identity verification system.
FIG. 5A is a block diagram of a fraudulent transaction screening system.
FIG. 5B is a block diagram showing further details of the fraudulent transaction screening system of FIG. 5A.
FIG. 5C is a block diagram of an alternative embodiment of an Internet identity value.
FIG. 6 is a flowchart of a process for detecting a gibarish
FIG. 7A is a flowchart of a process for applying a geographic location test based on an area code.
FIG. 7B is a flowchart of a process for applying another geographical location test based on an email address.
FIG. 7C is a flowchart of a process for applying another geographic location test based on a bank identification number.
FIG. 8 is a block diagram illustrating a computer system on which an embodiment can be implemented.
FIG. 9 is a block diagram of a statistical model creation process.
FIG. 10 is a diagram of a risk evaluation blending process
FIG. 11 is a diagram of a limit surface logic process.
[Explanation of symbols]
[0201]
510 Transaction presentation test
512 Transaction Information
514 Good Customer List
516 Bad customer list
518 History information
520 Compare operation
530 discrete score
540 Statistical model
550 Heuristic model
552 Scoring Blending Process
560 Final score and return code
570 Vendor specific value

Claims (26)

A computer data processing method for evaluating the risk of fraudulent transactions associated with e-commerce, wherein the method is performed by a computer.
Receiving electronic transaction information defining the electronic commerce and storing such information in a memory;
Determining a first fraudulent transaction risk scoring value associated with the e-commerce based on application of a plurality of computer data processing tests to the transaction information, and storing the scoring value in a memory; Each of the tests determining whether the transaction information appears to represent a genuine transaction based on specified criteria.
Determining a second fraudulent transaction risk scoring value associated with the electronic commerce based on a computer comparison of the transaction information with past transaction information, and storing the second fraudulent transaction risk scoring value in the memory;
Combining the first fraudulent risk score and the second fraudulent risk score using a statistical model to generate a resulting model score;
Blending the model score with one or more merchant-specific thresholds to generate a final fraud risk risk score for the transaction and store it in the memory. how to. Receiving the transaction information comprises receiving transaction information defining the e-commerce for a particular Internet identity, wherein determining a second fraudulent transaction risk score value is for another transaction involving the same Internet identity The method of claim 1, further comprising determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the transaction information to information of previous transactions. 3. The method of claim 2, wherein the Internet identity includes a first hash value of the email address of the prospective buyer in combination with a second hash value of the prospective card bank identification number. . The Internet identity combines the first hash value of the prospective buyer's email address with the second hash value of the prospective purchaser's card bank identification number and a hash value based on the prospective purchaser's shipping address. The method of claim 2, comprising: The Internet identity combines a first hash value of the prospective purchaser's host IP address with a second hash value of the prospective purchaser's email address, and a third hash of the prospective purchaser's card bank identification number. 3. The method of claim 2, including in combination with a value and a fourth hash value based on the intended buyer's shipping address. The Internet identity combines the first hash value of the prospective purchaser's hardware device ID value with a second hash value of either the prospective purchaser's email address or user ID, and provides the prospective purchaser's card bank. The method of claim 2, including combining in combination with a third hash value of an identification number and a fourth hash value based on the shipping address of the prospective purchaser. Determining said second fraudulent transaction risk score value comprises:
Retrieving one or more records of past transaction information relating to past transactions associated with said transaction information;
If one of the past transaction information records is found to contain a fraudulent transaction list tag, stopping further searching for such records;
2. The method of claim 1, comprising determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the retrieved past transaction information records only to the transaction information. . Determining said second fraudulent transaction risk score value comprises:
Retrieving one or more records of past transaction information relating to past transactions associated with said transaction information;
Searching for a specified large number of said past transaction information records and, if there are still past transaction information records to be searched, stopping further searching for such records;
2. The method of claim 1, comprising determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the retrieved past transaction information records only to the transaction information. . The step of blending the model scores may include converting the model scores to a final fraudulent transaction risk score for the transaction and one or more return codes indicating a particular risk item detected for the transaction. The method of claim 1, comprising blending with one or more merchant-specific thresholds to generate and store. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; The method of claim 1, wherein one of the tests determines whether the Internet identity in the transaction information is found in a list of parties to known past fraudulent transactions. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; The method of claim 1, wherein one of the tests determines whether the Internet identity in the transaction information is found in a list of trusted parties. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; One of the tests is to determine whether the text value in the transaction information is incomprehensible or meaningless.
Receiving the text value;
For each bigram in the text value, searching a bigram probability value table for a probability value representing the probability that the bigram is found in the true text value;
The step of generating a penalty value automatically determines if the retrieved probability value indicates that the text value comprises a combination of bigrams that are unlikely to represent a genuine text value. 2. The method according to 1. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; One of the tests for whether the first and last name values in the transaction information are incomprehensible or meaningless
Receiving the first and last name values;
For each of the bigrams in the first and last name values, retrieving from the bigram probability table a probability value representing the probability that the bigram will be found in a genuine first and last name value; Generated based on the frequency of bigram occurrences of
The step of generating a penalty value if the retrieved probability value indicates that the first name value includes a combination of unlikely bigrams representing a genuine first name value. 2. The method according to 1. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; One of the tests is to determine whether the city value in the transaction information is within the area code value of the transaction information.
Receiving the city value and the area code value as part of the transaction information;
Determining a latitude value and a longitude value representing a true position of the city identified by the city value;
Determining whether or not the city identified by the city value truly exists in the area code area identified by the area code value, based on the longitude value and the latitude value;
If the city identified by the city value is not within the area code area identified by the area code value, the transaction is automatically determined by applying a penalty to the transaction. The method of claim 1. The step of determining the first fraudulent transaction risk score comprises determining a first fraudulent transaction risk score associated with the electronic transaction based on applying a plurality of tests to the transaction information; One of the tests of is to determine whether the city value in the transaction information is in the email domain of the transaction information,
Receiving the city value and the email address value as part of the transaction information;
Determining a latitude value and a longitude value representing a true position of the city identified by the city value;
Determining a latitude value range and a longitude value range associated with an email domain portion of the email address value;
Determining whether the city identified by the city value truly exists in the email domain identified by the email address value based on the longitude value and the latitude value;
Applying a penalty to the transaction if the city identified by the city value is not within the email domain identified by the email address value. Item 1. The method according to Item 1. 14. The method of claim 13, further comprising generating and storing an e-mail domain location table including a plurality of records relating e-mail domain values to city values associated with past non-frauding shipping addresses. The described method. The step of determining whether the city identified by the city value is truly present in the email domain is performed by the electronic mail where the city value is indicated by the record in the email domain location table. 15. The method of claim 14, comprising determining whether a city value is for a city outside the domain. Determining said first fraudulent transaction risk score value comprises determining a first fraudulent transaction risk score value associated with said electronic transaction based on application of a plurality of tests to said transaction information; One of the tests is to determine whether the country value in the transaction information is closest to the bank indicated by the bank identification number of the credit card number in the transaction information.
Receiving the country value and the bank identification number of the credit card number as part of the transaction information;
Determining a relative distance between the country identified by the country value and a bank associated with the bank identification number;
Determining whether the country is too far from the bank based on the relative distance between the country and the bank;
The method of claim 1, wherein a penalty on the transaction is automatically determined if the country is too far from the bank. Generating and storing a bank location table including a plurality of records, each of the plurality of records relating a bank identification number to a country value representing a country where the head office of the bank is located. The method according to claim 18. 20. The method of claim 19, further comprising: generating and storing a bank location table including a plurality of records relating a bank identification number to a country value associated with a past non-frauding shipping address. The described method. The step of determining whether the country identified by the country value is too far from the bank is performed for a country where the country value is too far from the bank indicated by the record in the bank location table. 21. The method according to claim 20, comprising determining whether it is a country value. A method for determining an evaluation value of an e-commerce fraud risk, which is implemented by a computer.
Receiving transaction information defining the electronic commerce;
Determining a first fraudulent transaction risk score associated with the electronic transaction based on the application of a plurality of tests to the transaction information;
Including
One of the plurality of tests determines whether a first and last name value in the transaction information is incomprehensible or meaningless.
Receiving the first and last name values;
For each bigram in the first and last name values, searching the bigram probability value table for a probability value representing the probability that the bigram is found in a genuine first and last name value, wherein the bigram probability value table contains a large number of true first and last name values. Steps that are generated based on the actual bigram frequency in the sample;
Generating a penalty value automatically if the retrieved probability value indicates that the first name value includes a combination of unlikely bigrams representing a genuine first name value. A method for determining whether a text value is global for an e-commerce,
Receiving the text value as part of the e-commerce transaction information;
Identifying pairs of consecutive characters in the received text value;
For each of the identified character pairs, represents a probability that the identified character pair will be found in a genuine text value at a position equivalent to a respective position of the identified character pair in the received text value. Searching for a probability value from a probability value table;
Generating a fraudulent transaction risk penalty value for the e-commerce if the retrieved probability value indicates that the received text value is unlikely to represent a genuine text value. how to. When the instructions are executed by one or more processors on a computer readable storage medium carrying one or more sequences of instructions for assessing the fraud risk of e-commerce,
Receiving transaction information defining the electronic commerce;
Determining a first fraudulent transaction risk score associated with the electronic transaction based on the application of a plurality of tests to the transaction information, wherein each of the plurality of tests is based on a specified criterion. Determining whether the information appears to represent a genuine transaction;
Determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the transaction information to past transaction information;
Combining the first fraudulent risk score and the second fraudulent risk score using a statistical model to generate a resulting model score;
Blending the model score with one or more merchant-specific thresholds to generate and store a final fraudulent transaction risk score for the transaction as a result;
And causing the one or more processors to execute. An apparatus for evaluating the risk of fraudulent transactions in electronic commerce,
Means for receiving transaction information defining the electronic commerce,
Means for determining a first fraudulent transaction risk score value associated with the electronic transaction based on application of a plurality of tests to the transaction information, wherein each of the plurality of tests is based on a specified criterion. Means for determining whether the transaction information appears to represent a genuine transaction,
Means for determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the transaction information with past transaction information;
Means for combining the first fraudulent risk score and the second fraudulent risk score using a statistical model to generate a model score as a result;
Means for blending the model score with one or more vendor-specific thresholds to generate and store a final fraudulent transaction risk score for the transaction as a result. apparatus. An apparatus for evaluating the risk of fraudulent transactions in electronic commerce,
A processor, and one or more stored sequences of instructions, when executed by the processor,
Receiving transaction information defining the electronic commerce;
Determining a first fraudulent transaction risk score associated with the electronic transaction based on the application of a plurality of tests to the transaction information, wherein each of the plurality of tests is based on a specified criterion. Determining whether the information appears to represent a genuine transaction;
Determining a second fraudulent transaction risk score associated with the electronic transaction based on a comparison of the transaction information to past transaction information;
Combining the first fraudulent risk score and the second fraudulent risk score using a statistical model to generate a resulting model score;
Blending the model score with one or more merchant-specific thresholds to generate and store a final fraudulent transaction risk score for the transaction as a result;
A sequence of instructions for causing the processor to execute.

Images