Agentic Coupon Abuse Detection: A Short MVP for Explainable Fraud Triage

Coupon abuse looks simple until you try to design a system that catches it without punishing good customers.

A promotion is supposed to reduce friction. If the abuse controls are too aggressive, legitimate users get blocked and the promotion starts damaging the customer experience. If the controls are too weak, the business leaks margin through repeated accounts, reused identities, suspicious vendors, and coordinated discount behaviour.

This project was a short hackathon-style POC/MVP for that problem. The repository framed the system as ACADS, the Agentic Coupon Abuse Detection System. The goal was not to claim a production-ready fraud engine. The goal was to explore whether an agentic architecture could make the workflow easier to inspect: ingest transactions, apply explicit rules, explain suspicious cases, measure performance, and feed reviewer decisions back into future scoring.

For me, the interesting part was the boundary between agents and rules. The system should use AI where it improves interpretation, explanation, and workflow. It should not hide the fraud logic inside one unreviewable prompt.

The Problem

Coupon abuse is a pattern problem. One transaction may not be enough to prove anything.

A suspicious case might involve:

• repeated phone numbers across multiple users,
• reused names,
• known suspicious vendors,
• unusually high discount ratios,
• high base abuse probability,
• and repeated behaviour across a small time window.

Each signal can be noisy. Together, they can indicate a pattern that deserves review.

That creates a familiar trade-off. The system needs to catch enough abuse to be useful, but it also needs to avoid creating a review queue full of false positives. The business question is not just “is this fraud?” It is “is this suspicious enough to justify intervention?”

How I Thought About Solving It

The MVP used a multi-agent structure, but each agent had a narrow responsibility:

• Data Ingest Agent: validate and normalise transaction records.
• Rule Engine Agent: apply explicit coupon-abuse rules and calculate fraud scores.
• Insight Agent: turn triggered rules into human-readable explanations.
• Metrics Agent: track precision, recall, F1, latency, and cost.
• Feedback Agent: use reviewer outcomes to suggest rule-weight updates.

That separation is important. Fraud detection is not only classification. It is also data quality, analyst trust, business cost, and governance.

If one model does everything, the workflow becomes harder to debug. You do not know whether a bad outcome came from dirty input data, weak rules, a poor explanation, threshold drift, or the wrong reviewer feedback. By separating the roles, the system becomes easier to improve one layer at a time.

Why Keep Rules Explicit?

The temptation with agentic systems is to ask the model to make the full decision. For fraud work, that is usually the wrong first move.

The MVP kept the main fraud signals explicit:

• duplicate phone numbers,
• duplicate user names,
• suspicious vendor names,
• high base abuse probability,
• and repeated identity patterns.

The LLM-backed layer was useful for explanation and recommendations. It could describe why a case was risky in plain language and make the review experience more useful. But the rules remained visible.

That matters because a fraud system needs to be questioned. A reviewer should be able to ask: which rule fired, how much weight did it carry, and what evidence supports it?

What The MVP Covered

The repo included a small labelled dataset and a working Python workflow:

• 150 transaction records,
• a train/test split,
• a backend batch analysis path,
• a Streamlit frontend for transaction review,
• Google ADK and Gemini-based agent roles,
• a rule engine for abuse scoring,
• and a metrics view for evaluating the outputs.

The dataset was intentionally small, so the right interpretation is “workflow proof” rather than “model proof”. It was large enough to exercise the agent loop and demonstrate the review experience. It was not large enough to support a strong statistical claim about real-world coupon fraud.

Backtesting The Rules

The backtest for this MVP should start simple.

Given labelled historical transactions, run the pipeline over each transaction in event order and compare the predicted abuse flag against the ground truth label. Then analyse the output by signal and by business cost:

• Which rules catch the most confirmed abuse?
• Which rules create the most false positives?
• Are duplicate phone numbers genuinely predictive, or only noisy?
• Does the vendor signal dominate too much of the score?
• Does the discount-ratio signal add new information?
• How many manual reviews are required per true positive?
• What is the estimated value saved relative to review effort?

The last question is the one that makes this a business system rather than a pure modelling exercise. A fraud rule is not useful because it has a clever implementation. It is useful if it catches enough harmful behaviour without overwhelming the people who have to act on it.

For a production version, I would use time-based validation rather than random train/test splitting. Fraud behaviour changes, and random splits can make a system look better than it is by leaking similar patterns across train and test sets.

POC Boundary

This was a short-term POC/MVP. It did not include production data contracts, privacy controls, real e-commerce integration, adversarial testing, or a mature reviewer operations process.

A production-grade coupon-abuse system would need:

• larger labelled historical data,
• event-time validation,
• reviewer feedback capture,
• data lineage,
• prompt and rule versioning,
• threshold governance,
• monitoring for drift,
• and a clear policy for automated action versus manual review.

The MVP was still useful because it made the workflow visible. It showed how to move from raw transactions to scored cases, explanations, metrics, and feedback.

What I Learned

The main learning was that agentic systems are more credible when the agents are boringly specific.

The data agent should care about clean inputs. The rule agent should care about scoring. The insight agent should care about explanation. The metrics agent should care about whether the system is improving. The feedback agent should care about how reviewer decisions change future behaviour.

That structure is less flashy than a single autonomous agent, but it is much easier to test, backtest, and trust.

Repository: github.com/ThamuMnyulwa/fraud-detection-toy-problem