In addition to the current Sift score, we will be providing customers with percentile scores for multiple historic time intervals. With this enhancement, we will not be changing the current meaning of Sift score, but will augment the score with percentile data that helps workflow decisions, transactional traffic routing, prioritizing manual reviews, and metrics monitoring. Essentially, customers will be receiving scores as they are today, along with an additional data point in the form of percentile that will provide some interpretability to the score.
Percentile score indicates the proportion of scores that fall below a particular value in a given set of data over a certain time interval. If a risk score has a percentile value of 95, for example, it means that 95% of the scores in the data set are lower than the given score, and using this threshold would result in a 5% block rate. 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 offers percentiles over multiple time ranges: 1 day, 5 days, 7 days, and 10 days.
Customers can evaluate percentile Scores in workflows, and ingest percentile scores via API.
At the application stage, customers can select an appropriate percentile threshold as each business employs distinct standards to determine the optimal block/review/accept rates using automation. Customers can use the percentile score criteria to route/decision traffic at constant rates to operate at a more predictable revenue model.
How to Set a Percentile Score in Workflow
Although Percentile Scoring can be useful in achieving stable friction rates, we would like to draw your attention to some potential risks associated with its usage.
Suppose you establish a workflow that triggers for orders or transactions exceeding the 95th percentile score, and let's say that at that time, the 95th percentile corresponds to a score of 80. This situation could have two implications:
1. You could be allowing more approvals or higher risky events in your ecosystem.
This situation is likely in case of a fraud attack. Suppose a fraud attack occurs, and the Sift Score equivalent of the 95th percentile score changes from 80 to 82. In such a scenario, orders or transactions with a score of 81 and 82, which are potentially suspicious, would be approved. This could lead to an increase in fraudulent transactions, resulting in a higher fraud rate, while still maintaining a stable block rate.
Conversely, setting a score threshold of 80 in your workflow could potentially increase your block rate. However, in the event of an attack situation, this could aid in maintaining a low fraud rate. During such circumstances, it is advisable for the fraud team to prioritize the organization's needs by utilizing a block rate monitoring mechanism that identifies certain spikes. Teams that focus on loss prevention budget may express more concern regarding the losses if a percentile-based threshold is applied. Meanwhile, teams focusing on customer retention or minimizing insult rate can leverage percentile-based mechanisms to enhance accept rates while accommodating a certain level of fraud losses.
2. You could be allowing higher friction or lower risky events in your ecosystem.
This situation is likely when there is less fraud in the ecosystem. As an illustration, suppose that your 95th percentile score drops from 80 to 78. Consequently, there is a possibility that more transactions with scores of 79 and 80 might be rejected, resulting in an increased block rate. Teams prioritizing customer retention and minimizing insult rate may find this method challenging to implement, while it is better suited for teams focusing on mitigating losses.
On the contrary, setting a score threshold of 80 in your workflow could potentially decrease your block rate as transactions with a score of 79 and 80 would be approved. This approach has the potential to increase revenue and simultaneously lower their fraud rate. Such a mechanism is particularly useful for teams focused on improving customer retention and reducing insult rate.
In summary, to balance friction rates and approval rates for the above two use cases, we recommend that customers utilize both - percentile score and raw score in their workflows to prevent fraud attacks. We recommend that customers use a baseline high risk score as a threshold for a lower route in the hierarchy as a fallback to capture any fraud attacks. This route can be placed at the bottom, so that it can act as a safetynet for attacks bypassed by the percentile threshold.
We would be delighted to collaborate with you, and understand your specific use case in order to determine the most suitable approach.