A Sift Percentile Score is a number between 0 and 99.99 that indicates the riskiness of an action (what Sift refers to as an "event") among all the actions collected over a specific time period. The higher the percentile score, the more likely the event is high risk.
Sift will offer percentiles over multiple time ranges: 1 day, 5 days, 7 days, 10 days, and 30 days. You can use percentile scores through two avenues: (1) You can use percentile scores in your workflow criteria. (2) You can consume percentile scores through an API.
To gain a stable block/review/accept rate, you can look for a percentile score that meets your business metric requirements. Since each business has different considerations for the right block percentage, false positives to allow (trusted entities blocked), and fraud to catch based on automation, you'll need to evaluate the percentile score threshold and the percentile computation time period that works best for you. We're happy to help you with the right threshold.
While percentile scoring will work great if you are looking for fixed friction rates, we would like to bring to your notice some obvious risks with this usage.
Let’s assume you set a workflow to action on orders/transactions greater than the 95th percentile score and at that moment, 95th percentile translated to a score of 80. This can have two implications:
1. You could be allowing more fraud in your ecosystem. This situation is likely in case of a fraud attack. In the event of a fraud attack, let’s say that the equivalent Sift Score for 95th percentile score changes from 80 to 82. In that case, you would be accepting all the suspicious orders/transactions with a score of 81 and 82. You’d also be opening the doors to more suspiciously fraudulent transactions, causing a higher fraud rate, while maintaining a stable block rate.
On the other hand, maintaining a score threshold of 80 in your workflow will increase your block rate. But, that will help with maintaining a low fraud rate during an attack situation. It’s in the best interest that during these situations, a fraud team can decide the priority for the organization based on certain spikes using a block rate monitoring mechanism. Teams that focus on loss prevention budget tend to be more concerned about the imperative losses if a percentile-based threshold is applied. Teams focusing on insult or customer retention can leverage percentile-based mechanisms to improve accept rates while allowing additional fraud losses.
2. You could be allowing less fraud or higher blocks in your ecosystem. This situation can arise when there’s less fraud in the ecosystem. For example, let's say your 95th percentile score changes from 80 to 78. In that case, you could end up blocking additional transactions with scores of 79 and 80. This will increase the block rate. Teams focusing on insult rate/customer retention will find this approach difficult to use. This is more suitable for teams with a focus on loss mitigation.
On the other hand, maintaining a score threshold of 80 in your workflow will reduce your block rate because you would end up approving transactions with a score of 79 and 80. In this case, you could be adding more revenue and at the same time lowering your fraud rate. This mechanism will be more suitable for teams looking to improve insult rate/customer retention.