Turning a fraud conversation into a platform analysts open every morning

The problem

Fraud across a payments ecosystem doesn’t announce itself. It hides in merchant transaction patterns, mobile-money flows and card activity — and the people responsible for catching it were finding it one complaint at a time, after a customer had already been hurt. The ask from stakeholders was a sentence, not a spec: we need to find the suspicious transactions ourselves — before the next customer gets defrauded.

My role

I owned the journey from that sentence to a production system. I interrogated the transaction data to turn “bad transactions” into precise, testable definitions; built the prototype that made the idea tangible for stakeholders; wrote the PRD and the rule specifications; and led the cross-functional build with engineers — validating every stage against production data rather than assumptions.

What the data shaped

• Anomaly rules grounded in each merchant’s own behavioral baseline, not one-size thresholds — what’s normal for a supermarket is suspicious for a kiosk.
• Separate rule families for merchant, mobile-money and card activity, because each channel misbehaves differently.
• The hold-or-sweep split itself: only patterns where the risk justifies friction — like a dormant account suddenly transacting at speed — hold a live transaction for review; everything else is detected after the fact, so fraud control never strangles legitimate payments.
• A case workflow designed with the analysts who would live in it: detection, review, escalation with evidence attached, resolution — so a flag becomes an action, not a report.

What shipped

A fraud monitoring platform that works in two layers. Live: for targeted high-risk patterns — the classic being a dormant account that suddenly wakes up and moves money at speed — the transaction is held in flight until an officer reviews and releases it, so the loss never happens. Post-transaction: the rule families sweep completed transactions for suspicious patterns, queue flagged cases with the triggering rule and evidence attached, and analysts investigate and act — blocking an initiator before they can strike again. Detection, review, escalation and resolution tracked end to end; roughly 25 fraud and risk analysts work in it daily.

What I learned

Involve the end analysts even earlier. The rules were data-sound from day one; some of the case-handling flow still had to be reshaped after launch around how reviewers actually work. The data tells you what to detect — only the users tell you how a detection should become a decision.