#63 - Why sophisticated fraud defenses fail more often

I've spent 16 years watching fraud teams overcomplicate their jobs.

And I get it. The work itself is complex.

You're juggling multiple attack vectors, multiple domains (ops, data, tech), multiple vendors, and not to mention, multiple stakeholders with competing priorities.

Just reading that last sentence gives me a headache.

But here's the thing: the fact that your problem is complex doesn’t mean that your solution should be as well.

In fact, the opposite is true. Simple solutions are easier to validate, easier to explain, easier to monitor, and easier to tweak when they inevitably need adjusting.

Yet often I encounter fraud teams that build systems that look elegant and sophisticated, but not necessarily effective.

Today, I’d like to share two specific patterns I usually see that tell me fraud teams are getting in their own way.

Don’t get me wrong—I recognize these patterns as I myself fell into them many times before. It’s likely that I still do…

One rule to rule them all

The first pattern that tells me a team is overcomplicating things is simple to spot: their solutions are over-engineered.

I'm talking about rules that check for five different fraud patterns in one go. Workflows that branch into ten different paths depending on user type, product, region, and risk score.

When I point that out, often I hear back the argument: "Why maintain five rules when I can have one smart rule that handles all these cases?"

I get it. That’s my personal vice as well. The more complex your solution is, the better you show the depth of your own sophistication, right?

But in 99% of the cases, it’s the wrong way to go about it.

Yes, on the surface of it you only have one rule or workflow to monitor and manage. But at the same time, you just create a single point of failure.

Every time you see a change in your population (which is often), you need to change the same single artifact. And these frequent changes are increasing its chance to break down eventually.

And when it breaks down, the damage would not be constrained to a specific segment. It will affect all of your population.

This happens when we try to capture too many fraud patterns in the same rule. Eventually, as fraud evolves, they would move away from each other and start to create more false positives.

When managing workflows, the risk is even higher, as they are usually more complex. It’s easier to change the wrong branch or the wrong node and create a cascading mistake that quickly gets out of proportion.

I recently saw a client going for exactly such a solution. They had one workflow with five multi-step, parallel branches with similar but not identical rule sets in each one.

Their theory of scaling was to just add more branches as they grow and require more segmentation. The risk of breaking it all by tweaking a ruleset was off the charts.

Side note: This is exactly the reason why modern engineering teams are moving away from monolith code repositories and toward microservices architectures. It reduces risk and streamlines manageability.

The “fraudsters can break it” fallacy

This pattern is probably even more tragic, and it goes like this:

A team recognizes a hole in their defenses: let’s say they are missing proper device ID tracking. So what do they do? They look for solutions.

They run an RFI, pick a vendor, and get the contract.

And then someone, maybe a techie from the security team, looks at the solution specs and says: “Yeah, but are we going to pay all this money for something I could bypass easily?”

Everything grinds to a halt. The leadership team now hesitates to sign the contract, the fraud leader can’t really argue against it, and the deal falls apart.

Only for that same team to experience a fraud attack six months down the line, which they could have easily avoided with that solution.

I’ve seen it happen a few times.

But here’s the thing: no fraud prevention system is failproof.

Fraudsters will always be able to bypass your defenses. As long as you let users act on your platform, fraudsters would find a way too.

Internalizing this truth is the first step in understanding that the fact that “fraudsters can break this” is not a good enough reason for not deploying a solution.

Yes, some fraudsters would not be stopped by that device ID tracking.

But most would be too lazy or too inexperienced to solve that. They would just try what worked for them so far on a different target.

A few more would know how to bypass it, but would decide it’s easier for them (meaning, better ROI) to attack someone else.

And you know who that “someone else” is? Yes, that team that was too sophisticated for their own good.

Simple always beats sophisticated

Let me go back to what we started with—our job requires a truckload of sophistication. 

In understanding the environment, problem, tools, and conflicting goals we need to manage.

The way to translate this sophistication into solutions is not by making them complex or unbeatable. It’s by translating it into simple, effective, and manageable solutions.

Here are two practical ways you can make sure you’re keeping it simple:

1. If your boss cannot keep track of the system and easily manage it when you’re on vacation, it is too complex. Break it down to smaller pieces. Document them properly. Set up easy-to-follow monitoring and alerting.

2. If you’re unsure whether a solution would be temporary as fraudsters would work out how to bypass it—don’t. Unless it’s incredibly expensive, you should implement it. Some fraudsters would bypass it, and they would require a separate, additional solution.

Simply put, your fraud prevention system should look boring. It should be obvious what each piece does. Your newest analyst should be able to explain it.

If it requires an architecture diagram and a 30-minute explanation, you've overcomplicated it.

Have you seen monolithic risk prevention systems that withstood the test of time? I’m very curious if someone had the opposite experience. Hit the reply button and share your war stories.

In the meantime, that’s all for this week.

See you next Saturday.

P.S. If you feel like you're running out of time and need some expert advice with getting your fraud strategy on track, here's how I can help you:

Free Discovery Call - Unsure where to start or have a specific need? Schedule a 15-min call with me to assess if and how I can be of value.
​Schedule a Discovery Call Now »​

Consultation Call - Need expert advice on fraud? Meet with me for a 1-hour consultation call to gain the clarity you need. Guaranteed.
​Book a Consultation Call Now »​

Fraud Strategy Action Plan - Is your Fintech struggling with balancing fraud prevention and growth? Are you thinking about adding new fraud vendors or even offering your own fraud product? Sign up for this 2-week program to get your tailored, high-ROI fraud strategy action plan so that you know exactly what to do next. ​
Sign-up Now »

Enjoyed this and want to read more? Sign up to my newsletter to get fresh, practical insights weekly!

<