It's Almost Never the Technology

This article opens the Mastering Fraud Solution Implementation series: a journey through the three phases of a fraud solution implementation and the specific way each one destroys value.

Let me start with a story.

A bank decides to get serious about fraud. Best-in-class technology, a disciplined eighteen-month program, an experienced vendor, a senior sponsor in the room. Everything by the book.

Two years after go-live, someone pulls the numbers. Fraud losses are no lower than the day the program started. A review is commissioned, and when the report lands, one line stands out:

"The technology was never the problem."

I have heard that sentence, in one form or another, multiple times over nearly two decades of delivering projects, specifically fraud and financial crime solutions. And it is usually true. Which is exactly why it is so unhelpful. If the technology wasn't the problem, what was? The reviews rarely say. The file gets closed, the loss gets absorbed, and eighteen months later, someone proposes a new program with a different vendor or slightly different approach, but heading towards a very similar outcome due to the same blind spots.

In June, I had the pleasure of speaking about exactly this at an ACFE Kazakhstan webinar: a topic, I noted there, that not many vendors are keen to talk about. This series of posts is the same argument, in writing, with more room to breathe.

The chart that makes people give up, and the one that should stop them

If you want to feel demoralized about our industry, let me try this graph. Put the fraud losses reported to the FBI's IC3 over the last five years next to the industry's estimated spend on fraud technology over the same period(both US-only figures to ensure we compare apples to apples - sort of). Spending has roughly doubled. Losses have roughly quadrupled. Whatever we throw at the problem, it seems to grow faster than our investment. Futility, right?

Figure 1: IC3 reported losses vs. fraud technology spend in last five years.

Not so fast. Look at the second picture. Take card fraud, one of the oldest and most mature fraud domains we have, and normalize the losses: how many cents of every $100 spent on cards are lost to fraud? The number is small, around six cents. And the trend points down. Even as volumes explode, the proportion lost to fraud in the card domain continues to fall.

Figure 2: Card fraud losses per $100 of card spend.

Why the difference? Because cards are where the industry has had decades to mature: where organizations, schemes, and regulators deployed countermeasures properly and kept iterating. The lesson is not "fraud always wins." The lesson is: investment in fraud technology pays off when, and only when, implementation converts capability into operational reality.

The gap between those two charts is not a technology gap. It is a delivery gap.

My premise, and everything hangs on it

Fraud solution failure is not a technology problem. It is a governance problem, an operating model problem, and a people problem.

And the good news hidden inside that sentence: governance, operating models, and people are things you control. These failures are choices, which means they are predictable, and if they are predictable, they are preventable.

Three phases, three ways to fail

Every fraud implementation (new platform, new channel, or elevating an existing capability) moves through three phases, and each has its own signature way of destroying value.

• Preparation. Fail here and you implement the wrong thing, possibly very well. Wrong objectives, unranked requirements, no owner, data that can't support what you asked for.
• Implementation. Fail here, and you implement the right thing badly: blurred responsibilities, governance that quietly fades, scope that bends the solution out of shape.
• Post-go-live. Fail here, and you implemented the right thing well, yet watch the value evaporate because the team never changed how it works, capacity was never planned, nothing was measured, and nobody owns the solution anymore.

Figure 3: Three steps - three ways to fail delivering value.

Most attention (vendor, steering committee, and industry) goes to phase two. Deliberately, this series won't follow that habit. The heaviest risk sits in preparation. But the value sits at the end: the objective of a fraud program is not go-live. It is a solution in a steady operational state, doing the heavy lifting day after day, adapting as the fraudsters adapt. Everything before that is set up.

Across all three phases, the same three villains keep reappearing in different costumes: ownership (a program that touches everyone is owned by no one), readiness (buying capability the organization cannot yet operate), and the operating model (the tool changes, the way people work doesn't).

Where this series goes

Over the coming posts I'll walk through the journey phase by phase:

• what "success" even means and who actually owns fraud;
• how to write requirements that can be measured, ranked, and owned;
• the "I want it all" trap;
• what AI genuinely requires before it can help you;
• how to choose a partner without buying the demo;
• the division of labor that keeps implementations healthy and the long middle where governance quietly fades;
• and the post-go-live disciplines: the noisy first ninety days, the capacity trap, and the question almost nobody can answer: did it actually work?

One spoiler, because it frames everything: the organizations that win are not the ones with the most sophisticated technology. They are the ones with the clearest ownership, the most honest assessment of their own readiness, and the discipline to change the way they work, not just the tools they use.

None of that requires advanced algorithms. Which is exactly why it is so often skipped.

First stop on the journey: what does a successful implementation actually mean? The answer, it turns out, depends on who you ask.

If the opening story felt uncomfortably familiar, you're the person I'm writing this series for. And if your program is showing these patterns right now, it is almost never too late to course-correct, but the window narrows as implementation progresses. Get in touch: I'm always glad to compare notes :)