Editor’s Note: The following is a guest post. Interested in collaborating on Product School’s blog? Email Gabriela Araujo at gaby(at)productschool.com
About Lewis Mills
Lewis Mills is Head of Product: Payments, Fraud, Compliance, Pricing & Friction at WorldRemit in London. Experienced in FinTech, he also held a Product Manager position at Judopay, working on Anti-Money Laundering, Counter Terrorist Financing, Anti-Bribery & Corruption, and Data protection.
Building Products for Fraudsters
I’ve been working on fraud prevention products for years, but this line of work often feels like a weird cousin to typical product management.
Often, fraud prevention products are still focused on the user—understanding their needs (then frustrating them) and their problems (then trying to compound them). But despite that inversion of a standard approach, solid product principles hold true.
In this post I’ll cover some of the pitfalls of launching fraud prevention products and how traditional product skills can be adapted to meet them.
A user like any other
Imagine the ideal user of your product. They’ve likely got a few characteristics in common:
- Highly engaged with the service.
- Can’t wait to try out new features.
- A strong intent to convert.
- A product evangelist who helps spread the word.
All of those traits are equally true of the serial fraudster—it’s only the intention that differs.
Earlier in my career, I worked with a company to help curb their fraud rates. They were able to spot networks of fraudulent transactions, but each time they identified a new network and acted to stomp out the activity the network would go dark, only to appear again in a slightly different pattern that skirted their controls (think whack-a-mole.) It all happened too fast to be coincidental. Within hours (sometimes minutes) of the company acting, the fraudsters would change up their pattern.
Here’s what was happening: If you made a purchase, the company would first check their blacklist. If your data points weren’t on the list, the system would then run a fraud model to score your transaction. The model took time to respond. A few seconds, but noticeable to the user (“Please do not refresh. Do not click back”). The blacklist, in contrast, produced near-instant rejections. The fraudsters noticed the time lag at this second stage and figured out that, if their transactions were instantly rejected, something had been blacklisted. They would then factory reset their devices (generating a new Device ID), switch up IP addresses and try again.
How did we figure this out? I wish I could say it was cutting-edge analysis and artificially extending the blacklist response time to simulate the model, but it was in fact just the trusted product skill of user research: I read reviews. These reviews were posted on a dark web forum rather than Trustpilot, but the outcome was the same. A whole thread buzzing with these six or seven posters (who had created thousands of accounts), discussing the new controls they’d observed on the platform and how to avoid them.
That might be a bit extreme – I’m not suggesting you need to go dark web scraping too (though tools like Flashpoint have made it easy and safe), but rather to remind product managers that humans are on the other end of every interaction (even if it’s a bot, it’s a human who set it up). Understanding the user’s drivers and problems is always at the root of the solutions you’re trying to deliver, no matter who your user is. Fraud prevention goes wrong when people view it as levers and dials to turn up and down. Fraud prevention at its best leaves room for the humans.
MVP for mass appeal
When taking a product to market we’ve all learned lessons on being ruthless about MVP scope creep. You don’t expect to set the world alight, but you want to attract enough prototypical users to generate insights and allow you to iterate. The same is true when you’re starting to build fraud prevention controls, but how do you define your prototypical fraudster?
The ‘80/20’ rule you’ll hear about as a standard product manager applies equally to how you should approach fraud prevention. 80% of your fraudsters are likely low-level unsophisticated people with limited physical devices, plenty of time and a stack of stolen card numbers. The other 20% are a bit savvier, capable of writing scripts and willing to pay a bit more for time and information. Within that 20% there’s another 80/20 split and so on and so on until you reach organised crime levels of sophistication.
Our fraud-inverted goal is to churn that 80% with minimal effort. Luckily the 80% are often not all that difficult to spot, and there’s a good reason for that: fraudsters will only work as hard as you make them, and if you don’t make them work at all they will follow a standard pattern based on minimising effort. A good example is to look at velocity: how frequently your customers interact with your product. No matter what a regular transaction frequency is for your legitimate customer base (once a day, once a month), it’s highly likely there is a chunk of your 80% who don’t have the patience to try and slip into those rhythms. Instead they’ll try and cram as many transactions through a single account as they can in as short a period as possible before someone finally takes notice.
If you understand this almost fundamental need of your ‘80%’ fraudster – to be able to commit fraud as easily and quickly as possible – you can see how introducing greater friction for customers that deviate from normal patterns can start to give you the right kind of churn. Make a fraudster work for it, make them create a new account for every transaction to avoid your detection, take up that extra two minutes of their time per transaction and some of your 80% will soon start to look for softer targets elsewhere. Like all product launches, start broad, go for the low hanging fruit and start adding instant value.
When I first started working in fraud prevention the company I was working for at the time had just experienced a large loss due to fraud and hired a consultant to assist us in future-proofing against similar incidents. The consultant, let’s call him John, was chatting to me in a break and he said something that stuck with me: “Everything is spoofable. Any data the customer enters is bunk. You can’t trust it. But how they enter the data, that is much harder to fake.”
What he meant was that in an age of data breaches, data is meaningless, so you need to counter-act it… with more data. We started exploring behavioural data shortly after that, how data was entered – Was it copy-and-pasted? Was the form filled in five times faster than a normal customer? Was it all caps locked? It unlocked another lens on how we viewed our users: a user that looked legitimate based on the data they entered alone would suddenly be revealed as a blatant 80% fraudster when we put them under the behavioural data microscope. It was a deeper understanding of the user that allowed us to look beyond superficial conclusions, all because we doubted what we saw.
Years later someone forwarded me a Daily Mail article. It was about John. John, it turned out, was a fraudster himself. On a massive scale. He’d been working with huge financial companies pretending to have this illustrious background (I remember a claim that he was one of the founders of Visa’s FALCON programme) only to defraud them. For millions. And not just companies either. He had a string of wives that knew him by other names. When they finally caught up to John he was dressed in full army uniform, pretending to be an intelligence officer. That was the picture they used in the article. Everything is spoofable. This idea, when you think about it, is one of the most fundamental principles of product: the ability to doubt, second-guess, thinking around the edges of a problem, propose solutions and then hold them up to scrutiny so you can improve and iterate for an increasingly better product offering. Building products for fraudsters demands that of you like no other discipline. Fraudsters demand it of you. They demand you be at your best and stay one step ahead. In a way, isn’t that the ideal user a product manager could want?