Part of the Mastering Fraud Solution Implementation series. The opening article argued that fraud implementations fail on governance, operating model, and people, not technology; this one begins the preparation phase with the two questions everything else depends on: what does success mean, and who owns it?

Whenever I speak about fraud implementation, I like to open with a question that sounds almost insultingly simple: when somebody says "successful fraud solution implementation," what comes to your mind?

I have asked this in rooms of CFEs, fraud managers, architects, and executives, and the first wave of answers is always the same: on time, on budget, delivered scope. Occasionally someone adds "minimal customization." All correct. All important. From a project management perspective.

Yet they don't guarantee a successful project, do they?

Delivery metrics are the vendor's definition of success

Look at that list again: on time, on budget, on scope, minimal customization. Every item is a delivery metric. They measure the project, not the outcome.

Now notice something: these are precisely the metrics by which a vendor defines success: delivered to specification, accepted, signed off, paid, referenceable. A vendor can achieve every one of them, honestly and competently, while the client perceives the project - if not as a failure, definitely not as a success. On time, on budget, and two years later, fraud losses are exactly where they were. Both sides telling the truth about the same project.

This is the first trap of the preparation phase: adopting somebody else's definition of success because it is the easiest one to write down. If your success criteria could be copy-pasted from the vendor's statement of work, you haven't defined success. You've defined delivery.

Success is in the eye of the beholder

Move past the project-management answers and ask people inside the organization, and the picture fragments along role lines with beautiful predictability:

• The analyst wants a fast, responsive interface that shows all relevant context (transactions, history, customer interactions) without hunting through three systems. They live in that screen eight hours a day.
• Operations wants the business to run the solution without IT in the loop: build a rule, test it against recent traffic, promote it, monitor it. All in an afternoon, all without a ticket.
• The architect wants highly available, scalable, configurable, and natively fitting the approved IT landscape.
• The head of fraud wants coverage and headroom: solve today's typology, extend to the next channel and product without another procurement cycle and 12 months delivery.
• The executive wants a number: efficiency gains, faster investigations, lower losses, less customer friction. Something tangible to defend at the board.

Figure 1: The same fraud implementation is judged against many different definitions of success.

Every one of these is legitimate. Several are in quiet conflict: "fully operated by business" pulls against deep configurability; "fast, friendly UI" pulls against comprehensive context on one screen. If you never reconcile them, your project will be scored against five scorecards at once and might fail at three of them, no matter what gets delivered.

And now the harder question: who owns it?

Here is the question I encourage you to ask about your own organization, right now: who owns fraud, end to end? Not who runs the alert queue. Who owns the outcome: total fraud losses, across every product, channel, and typology?

In many organizations, the honest answer is: no one. Or more precisely, everyone owns a piece, so no one owns the outcome. InfoSec holds account takeover at the perimeter. Compliance holds the main part of the regulatory side. Finance feels the losses without holding any levers. Operations runs the queue. Product owns the customer journey, which is where some fraud actually starts, and is measured on conversion, not losses. Add the slicing within fraud itself: a card team, a separate internal fraud unit, electronic channels parked under IT, social engineering scams floating wherever nobody wanted them.

Figure 2: Your org chart is a map of your blind spots.

Draw it on a whiteboard, and you'll see what I mean when I say: your org chart is a map of your blind spots. And these are often the points where the most fraud slips through. The attacks that hurt are the ones that hop channels and products, exploiting exactly the seams between your teams or vendors, where context gets dropped, and signals don't connect.

Some projects take a village to complete. All fraud projects are like that: they cut across risk, compliance, technology, product, operations, and finance. Which produces the structural risk that precedes every other risk in this series: a program that touches everyone is, in practice, very hard to stick on a single person, so it's often owned by no one.

Take mule accounts, which live in the seam between Fraud and AML. The fraud team wants to catch a mule before it is ever used, but from the account's own activity there is often almost nothing to see: money arrives, money leaves, and each payment looks ordinary in isolation. The AML team recognizes the laundering pattern, but usually only later, once the funds have moved on. And the weak spot that let the mule in sits further upstream still, in the onboarding and customer journey the product team owns - a team measured on how smoothly customers join rather than on who they turn out to be. Three teams have a hand in that account. None owns the outcome. So it keeps working, and each one assumes the alert belongs to somebody else.

What to do about it

Three moves, none of them requiring a reorganization:

• Name one executive who owns the outcome. One name, not a function. The highest sponsor you can genuinely keep engaged. Genuinely engaged means they can tell you, without preparation, what the program is trying to achieve and what the biggest risk to it is right now.
• Make leadership announce the priority. Your organization runs twenty projects at once; every department head is quietly triaging. If the fraud program is critical(which is the case more often than not), people need to hear it from the top, by name. That sentence saves months.
• Collect success definitions from every role (analyst to executive) before the vendor conversation, and reconcile them deliberately. Conflicts discovered on a whiteboard cost hours. The same conflicts discovered at UAT cost weeks.

The first two moves deserve more than a bullet point each, and they already have it: I wrote about both at length in Importance of Leadership and Unified Priorities (a third article in this series), with the war stories that earned the advice, including the general manager who declared the fraud project the number one project in the bank, and the CEO who put a bonus behind the go-live date, vendor's team included. That article is the next stop in this series, and worth reading before your requirements conversations start.

The success of a fraud implementation starts unwinding long before any consultant arrives on site: at the moment the organization defines what it needs, and who owns the answer.

After the sponsorship stop, the series turns to requirements: how to turn those reconciled wishes into something that actually survives an implementation (measurable, ranked, owned).

Does your organization have a single name accountable for the fraud outcome? If you had to pause before answering, that pause is worth contemplation and a conversation.