The problem

Stopping credit card fraud

The company wanted to reduce fraudulent purchases from stolen credit cards. Typically, stolen credit cards were being used by new accounts created via the browser. The new user would make 1-3 fraudulent purchases and abandon the account. From analysing IP data and other browser signals, the company determined that much of the fraud was being done by users who already had multiple accounts with their service, and often had made fraudulent purchases in the past.

The company had built a sophisticated anti-fraud system that took into account a visitor’s device, IP address, and browser fingerprint to flag suspicious purchases, however some fraudulent purchases were still falling through the cracks. The company found that the accuracy of their current fingerprinting solution was too low to catch all fraudulent activity, resulting in chargebacks, lost revenue, and a threat to their seller reputation.

Their anti-fraud system was also causing a number of false positives - transactions that were flagged as suspicious but were later found to be legitimate. Flagged transactions were blocked automatically within the web application only in extreme circumstances - typically flagged purchases were sent to an internal fraud analysis team to review. These additional false positives were taking up valuable time for the fraud department to review and dismiss.

The company wanted to add another high accuracy browser identifier to their anti-fraud technology stack that would reduce fraud by improving the overall accuracy of identification, and save their fraud department time.

Cleaning up anti-fraud rulesets from legacy products

From using multiple anti-fraud vendors, the logic to determine which purchases were suspicious and required review had become very complicated. The level of complexity made it difficult for the risk team to troubleshoot their own system and make changes.

The company started an internal rule management project to map out all of their individual rule triggers, and simplify the logic based on historical fraud data. If they were going to add an additional service to their anti-fraud tech stack, it needed to be easily integrated and unopinionated, allowing them to use their own rules logic and avoid introducing additional complexity.

Why Fingerprint?

As the company had already been working with several vendors for device identification, Fingerprint had come up in their research into an additional accurate identifier that could be incorporated into their existing solution.

Successful pilot that improved accuracy of existing solution, improved confidence in credit

After comparing Fingerprint Pro with their existing browser identifiers, the company found that Fingerprint Pro’s visitorIDs were more accurate and made fewer false positives, which allowed them to improve their credit card anti-fraud workflows significantly.

Ease of incorporation into existing workflows

As the company was cleaning up their existing anti-fraud rule logic, they found Fingerprint Pro’s API and webhooks made it easy to incorporate high accuracy identification without having to adopt another opinionated anti-fraud service.

Fingerprint Pro’s Javascript snippet also had minimal impact to browser performance, keeping the customer experience speedy and unhindered by new anti-fraud measures.