What is the riskScore?

The riskScore field ranges from 0 to 100, to help give a clearer, percentage-based idea of how risky a given order may be. For example, an order with a score of 20 has a 20% likelihood of being fraudulent.

The score field runs off of a predetermined formula (found here ), while the riskScore takes into account more specific details of the transaction. For example, rather than giving all country mismatches a score of 2.5, the riskScore looks at the specific mismatch and compares that to millions of past transactions, to see how risky, historically, such an order is. This way, a mismatch between the US and Canada is given a lower score than a mismatch between the US and Nigeria, even aside from the high risk country scores.

Much like finding the right cutoff number for the original score field, finding the right number for your riskScore cutoff will take a little bit of work. We recommend watching your numbers on legitimate and fraudulent transactions to help get an idea of how each are scoring.

The recommended migration path is to begin by enabling minFraud version 1.1 and to begin collecting the new output fields, while continuing to use the original output variables as before. For manual review of all orders, you can begin using the riskScore right away, and the riskScore should be given higher weight than the original score. For automated screening, we generally recommend that you migrate over to automatically screening orders where the percentage likelihood of fraud, as indicated by riskScore, is high enough so that the extra screening costs would be less than the estimated loss from fraud multiplied the new riskScore, divided by 100. In other words:

Of course, every merchant's risk profile is different - for example, if you block free e-mail addresses, the riskScore does not weigh a free e-mail as being as high risk as the original score did, so you will have to adjust the riskScore to make it higher if the e-mail is a free domain.

Please do note that if you have made modifications to the formula, these will not have an effect on the riskScore field. If you experience a certain type of fraud and want to focus on that, we recommend using both the score and riskScore fields together. The score field will remain in the outputs for this purpose, as well as for backwards compatibility.

The explanation field is a brief summary of why a given order received the score it did. Please note that this is linked to the score field, not the riskScore.

The explanation field is linked with the score, not the riskScore. It is entirely possible that the order had, for example, a free email address and a country mismatch of US and GB, as well as a large distance. The score would rate this order as something around a 7 (2.5 for free email + 2.5 for country mismatch + ~2 for distance), and the explanation field would explain why. The riskScore, however, might look at that order more closely and realize that while the domain is free, it is not one for which we see a lot of fraud, and a country mismatch between US and GB isn't especially risky (less than 5% of all orders we see with a mismatch between the US and GB are fraudulent). Further, the riskScore looks at the distance and the ISP, since distance matters more with some ISPs than with others. For example, Comcast is one we are very good at locating through GeoIP, and also one that tends to be home users, so a large distance with that ISP is more suspicious than it is with an AOL IP address, since the way AOL routes their traffic makes IP location on a city level impossible, which in turn means that it regularly gives large distances, regardless of whether or not the order is fraudulent.

Just go here and select version 1.1. This link also lets you revert back to version 1.0, in case you do have any troubles.

Unless you have custom code calling our minFraud service, everything will continue to work just fine. If you do have custom code, you will just need to update it to parse the two new fields.