Fraud Detection: Data & Approach Note

Advisory Note · Data & Analytics · 19 February 2026

Initiative: Fraud Detection Author: P. Sharma

To: Marcus Kim (CIO), David Chen (CFO)
From: Dr. Priya Sharma, Head of Data & Analytics

Marcus asked for my honest read on how we deliver the fraud capability the Board funded. Here it is, plainly.

Recommendation: buy, don't build

I do not recommend my team build a fraud model. A credible third-party fraud platform is more practical for us, and I'd expect a sensible vendor to be integrated and live in three to six months. Building our own would take far longer, would require us to chase a moving target (fraud patterns shift constantly), and would tie up the same four data scientists I need for demand forecasting and personalisation.

Note: "Buy" is the right call and the data-science team should not own the running of this. Fraud detection is an operational, always-on control. It belongs with Risk/Operations with vendor support, not in an analytics backlog.

Is our data good enough? Yes, for a vendor

Our Shopify Plus order data is clean and well-structured: order value, device and IP signals, billing/shipping mismatch, customer tenure, payment method. That is more than adequate to feed a mature vendor model. The legacy POS and inventory systems are poor, but in-store card-present fraud is a smaller exposure, so the data gap there is not blocking. We do not have enough labelled fraud history to train a competitive model ourselves, another reason buy wins.

Where the real risk lives

The hard part of this project is not the algorithm. It is threshold tuning and vendor oversight. Any fraud system makes two kinds of mistake, and they pull in opposite directions:

Error type	What happens	Cost
False positive	A legitimate customer is blocked or held	Lost sale, angry customer, reputational harm, and we rarely even measure it
False negative	Genuine fraud slips through	Chargeback, lost goods, fees

Tighten the threshold to catch more fraud and you block more good customers; loosen it and fraud rises. There is no single "correct" setting; it is a business trade-off about how much legitimate revenue we are willing to risk to avoid a dollar of fraud. That decision must be owned by us, not delegated to a vendor's default.

Risk: Any vendor benchmark quoting a single accuracy figure is hiding this trade-off. Before signing anything, insist on the false-positive rate at the threshold they'd actually run us at, measured on data like ours, not a headline number.

What I'd ask the team to own

Defining and instrumenting the false-positive rate so we can actually see it.
Setting and reviewing thresholds with Finance and Customer Service in the room.
Ongoing oversight of vendor performance, not building the model.

Dr. Priya Sharma, Head of Data & Analytics