The Problem
The statement “we have identified fraud as a use case” contains no more actionable information than the statement “we have identified illness as a medical condition.” Both are categories. Neither identifies the underlying cause, the point of intervention, or the appropriate treatment.
Fraud detection is not a use case. It is an umbrella term covering dozens of distinct problems with different loss profiles, different signal sets, and different design requirements. A use case describes a specific decision, in a defined operational context, targeting a measurable outcome. Fraud, as a label, provides none of that.
The consequence of treating fraud as a use case is not a failed project. It is a project that produces something technically functional but commercially adrift, designed without sufficient specificity to know whether the right problem was solved, or to measure whether it was solved at all.
Why Fraud Vectors Are Defined Before Detection
Here is the important technical reality that the “just pick a fraud use case” approach ignores: fraud does not announce its type.
A transaction does not arrive labelled “APP scam” or “card-not-present fraud.” It arrives as a set of signals. An unusual payee. A new device. A velocity anomaly. A session that began with a suspicious login. A customer who contacted support the previous day. The fraud system observes those signals and produces a risk assessment. The vector is not something fraud reveals. It is a design construct the organisation defines before the system is built.
This is why vector definition happens in discovery, not detection. Before a model can be trained, someone has to decide which vectors the system is designed to detect. That decision determines which signals are collected, how features are engineered, which model architectures are appropriate, and how thresholds are calibrated. A system built without that decision is built around an incomplete specification.
But the vector alone does not define the use case. The use case emerges when the vector is mapped to a specific business decision. APP fraud becomes a use case when the objective is to improve the decision to release or delay an outbound payment. Account takeover becomes a use case when the objective is to improve the decision to trust or challenge a login session. Synthetic identity fraud becomes a use case when the objective is to improve the decision to approve or decline an account application. The vector identifies what kind of fraud. The decision identifies where AI intervenes. Both are required before anything useful can be built.
How the Architecture Reflects This
The detection platform is where vector and decision definitions become structural reality. Many modern fraud platforms implement multiple vector-specific detection components within a single deployment, scoring the same transaction or event across several paths simultaneously rather than routing it to a single model. A card authorisation event might be assessed against an ATO model focused on session behaviour, a CNP model focused on transaction patterns, and a velocity-based model focused on card-testing signals, all contributing to a combined risk score. Some institutions use a single ensemble model with vector-aware features; others use hybrid architectures. The specific implementation varies.
What does not vary is the design requirement upstream of all of it. Whether the platform runs one model or several, someone has to define which vectors it is designed to detect, which signals those vectors require, and which decisions those scores will inform. That work cannot happen at runtime. It has to happen in discovery, before any model is trained or any platform is configured.
Why Stopping at the Category Breaks Everything
The absence of defined target vectors and decisions creates problems that compound at every stage of an AI initiative.
Without defined vectors, signals cannot be prioritised. The signals relevant to APP fraud are not the same as those relevant to synthetic identity. Building a feature set without knowing which vectors you are targeting produces either an undifferentiated model that handles nothing precisely, or a model that accidentally performs on one vector while appearing to serve a broader mandate it was never equipped to fulfil.
Without a defined decision, the use case has no boundary. APP fraud is a vector. It describes a fraud type. The use case is the decision to release or delay an outbound payment, informed by signals relevant to APP scam patterns. Without naming the decision, there is no way to establish the operational context, the latency requirement, the data available at that specific point in the process, or what a better outcome looks like.
Without both, economic impact cannot be quantified. Fraud losses in aggregate hide more than they reveal. The economic case for AI investment requires knowing how much loss is attributable to a specific decision failure on a specific vector, at what volume, and what a realistic improvement would be worth.
Without both, success cannot be measured. A model that reduces release of mule-account payments by a defined percentage is a quantifiable result. A model that “improves fraud detection” has no baseline, no defined outcome, and no means of demonstrating commercial return.
What Good Discovery Produces
A rigorous fraud AI discovery engagement does not begin with platform selection or model discussion. It begins with a systematic inventory of the vectors the organisation actually faces, and for each vector, the specific decision that AI would improve.
For each identified vector, discovery asks: what decision is being made at the point where this fraud occurs? What is the operational context of that decision? What data is available at that point? What latency does the decision require? How is it being made today, and where is it failing? The answer to those questions is the use case. Not the vector. The vector is the path to it.
Economic sizing happens at the decision level. Decisions are where economic impact is measured. Losses do not occur at the category level. They occur because specific decisions are made incorrectly, too slowly, or without sufficient information. The business case for fraud AI is not “reduce fraud losses”; it is “improve this decision, at this volume, by this margin, producing this return.” Each needs its own quantification. Each depends on understanding the volume of the specific decision, the loss attributable to its current failure rate, and the realistic improvement a model can deliver given available data.
The output of discovery is a prioritised use case register defined at the decision level: each entry names a target vector, the specific decision being improved, the signals available to support it, the economic opportunity, and a data readiness assessment. From that register follows a sequenced roadmap. Without it, platform selection and model development proceed against a specification that is incomplete by definition.
The mistake many organisations make is believing that fraud, vectors, and use cases are interchangeable terms. They are not. Fraud defines the category of loss. The vector defines the mechanism through which that loss occurs. The decision defines the point at which intervention is possible. AI is ultimately applied at the decision layer, because decisions are where outcomes change and economic value is created.
The Diagnosis Determines the Treatment
In medicine, symptoms do not determine treatment. Diagnosis determines treatment. And diagnosis alone does not determine treatment either; the clinician still has to identify the intervention point and choose the appropriate tool.
Fraud is the symptom. The fraud vector is the diagnosis. The business decision is the intervention point. The model, the rules, and the features are the tools. Each layer is necessary. None is sufficient on its own.
A fraud use case that fails to identify a single fraud vector is not a use case. But a fraud vector without a defined decision is still not a use case. The use case exists at the intersection of the two: the specific fraud type, mapped to the specific decision it degrades, in the specific operational context where AI can improve it.
Category. Vector. Decision. That is the framework that turns a fraud conversation into a fraud initiative. Everything before the decision is context. Everything after it is implementation. Discovery is the work of getting there, and skipping it is why so many fraud AI programmes produce something technically functional and commercially indistinct.
