Part of the Mastering Fraud Solution Implementation series, in the preparation phase. With success defined and requirements measured, ranked and owned, the next trap is scope: wanting everything in phase one.

Nobody sinks a fraud program by asking for too little.

There is a moment in almost every preparation phase when the consolidated requirements document lands on the table, and it has several hundred rows. Every department contributed. Every conference takeaway, every peer bank's feature, every vendor webinar promise made it in. The organization, having finally decided to get serious about fraud, wants it all. In phase one.

I understand the impulse completely. Budget windows open rarely; when yours is open, you stuff everything through it. But "I want it all" is one of the most reliable program-killers there is, and the one we face every single time.

The superset is not the scope

Let me be precise about the trap, because collecting broad requirements is not the mistake. A superset of every capability anyone can imagine is genuinely useful: for comparing vendors, for understanding the landscape, for building the multi-year roadmap, for knowing where our maturity level stands. Collect away.

The trap is converting the superset directly into the delivery scope. The moment those hundreds of rows become "phase one," three consequences become increasingly likely:

• the timeline stretches beyond any date the organization can credibly defend;
• the priorities flatten until everything is treated as equally important; and
• the organization commits itself to a leap it may not be equipped to land.

A step, not a leap

Here is the image I keep coming back to, because after nearly two decades of fraud implementations it still fits: make a step you can make, rather than a leap, because when you leap, you can fall. And the further the leap, the higher the chance you slip.

And here is the counterintuitive part: the vendor is rarely the constraint. The technical capabilities of established fraud platforms very rarely fall behind a customer's requirements: the top-tier solutions are, functionality-wise, more alike than different, and most can technically deliver most of a broad enterprise list. Genuine differences do exist, and in a tightly scoped program they may matter enormously; there, choosing for fit rather than breadth is exactly the right instinct. Which platform suits which program is a subject for later in this series.

The constraint is you. The maturity and skills to operate what you asked for. The supporting functions (data engineering, IT operations, analytics, investigation capacity) that every advanced capability quietly depends on. Buy the most sophisticated option on the market while those foundations are missing, and you will pay for capability you cannot use, wait longer for a go-live that delivers less, and (the part that is rarely considered) demoralize the very team the tool was meant to empower.

The organizations that understand this treat ambition as a sequence, not a scope. A step now, on current maturity; the next step from the higher ground the first one wins. Nothing is dropped: it is ordered. And when the pressure arrives to fold the next step back into this one, which it will, that is the same trade I wrote about in Don't trade the go-live date for more functionality: the date is the thing holding the sequence together.

Here is a small one, small enough that nobody flagged it as a risk. A customer wanted device fingerprinting live from day one, in the same phase as the new fraud solution, to tackle ATO. Reasonable on its own, and the platform supported it. But the device events had to reach us through the middleware team. That integration was not ready, and we waited three months with a finished fraud platform sitting idle. Going live without it was not an option either: by then the rules and profiles had been written to use those events, so the solution's own logic depended on data that was not arriving yet. The mistake was not wanting device fingerprinting; it was allowing one desirable capability to become a dependency for the entire first release. One capability, added to phase one because it seemed natural to add it, ended up setting the go-live date for everything else.

The part that still bothers me is what came after. Those rules were fine-tuned during the weeks following the delayed go-live, the way rules always are. We delayed the entire release for events feeding logic that was never going to be settled on day one in any case.

One caution in the opposite direction, because the rule is not universal. Where you are replacing a mature solution rather than adding a capability you never had, sequencing carries a cost of its own: the operation runs two systems for as long as the migration takes, with data accumulating on both sides and a reconciliation waiting at the end of it. Stretched over eighteen months or two years, that can cost more than a single, heavily rehearsed cutover. The judgment is never phased good, big bang bad. It is which intermediate state your operation can actually live in, and for how long.

Customization is a symptom, not a feature

When an oversized phase-one scope meets a product that does not support every requirement exactly as written, customization becomes the mechanism used to preserve the wish list. It is how the scope trap moves from the requirements document into the solution itself.

Start with a distinction, because "customization" gets used for two quite different things. At one end it means fitting the platform to your specific inputs: your data structures, your event formats, the events themselves. At the other it means development on the platform: functionality that is not in the product today and has to be built. The first is often unavoidable and usually modest. The second is a product change wearing a project's clothes.

The shade changes the effort, not the category. Product-supported configuration and parametrization are what the platform was built to let you do; they generally carry a lower testing, maintenance and upgrade burden. Customer-specific code or product modification transfers much more of that burden to you. Everything past the supported configuration line, in either shade, is an add-on that you must be prepared to regression test, maintain, and defend through future upgrades.

Figure 1: Customization is delivered once, but its consequences are owned for the life of the platform.

Which is why the most useful reflex you can build for the preparation phase is this one. Whenever a discussion arrives at "this will require customization" (whether you raised it or the vendor did), stop and ask, honestly:

Why does this need to be custom? Is the way we do this really so different from everyone else, and if so, is our way actually better?

Mature fraud platforms often encode lessons accumulated across hundreds of implementations. When your requirement doesn't map to any out-of-the-box function of a mature solution, that is information. Sometimes, genuinely, you have a local regulatory quirk the vendor hasn't met, and the customization is justified. But far more often, one of two things is true:

1. You are about to pay to replicate a workaround. The "requirement" encodes how you cope with a legacy limitation, not what the business needs. You are bending a new platform into the shape of your old problem.
2. You are papering over a gap on your own side, in your data or your processes, by having the vendor absorb it into custom code. That does not close the gap. It moves the cost somewhere less visible, and onto a team that cannot fix its cause.

Double-check, triple-check, and only then customize. Customization is not automatically a red flag, but it is always a prompt for the question.

One caution in the opposite direction, for balance: an organization so committed to zero customization that it bends itself to the tool's default design is making the mirror-image mistake. The tool should not be bent to mimic your legacy quirks, and you should not be bent to mimic the demo. Where that line sits is a judgment call, made deliberately, requirement by requirement.

The quiet payoff

There is a payoff to the step-not-leap discipline that only reveals itself later: phasing gives you a place to put things. When the mid-project surprise arrives (and in fraud programs it always arrives), an organization with phased delivery calmly moves the new discovery to the next phase's backlog. An organization that committed to the leap has nowhere to put anything, so every surprise becomes a crisis. That is a subject for the implementation phase, later in this series.

Phasing does not reduce ambition. It gives ambition somewhere to go without turning every discovery into a threat to the current release. Some rows on the list will also turn out to assume data you do not have. That question is bigger than scope because it determines what the solution can detect at all, and it is the next stop in this series-along with the version of this trap that arrives wearing an AI badge: we want machine learning, and we want it to find fraud automatically.

Take the phase one you are about to commit to and ask what would have to be true for all of it to go live on the date you have promised. Everything on that list of conditions is either work you have not scoped or a leap you are hoping to land.