Inspiration

Fraud analysts don't need smarter algorithms — they need better tools. Most fraud detection systems output a score and leave the human to figure out why. We wanted to build the opposite: a tool where every flag comes with a plain-language explanation, and where a reviewer can move through an entire queue in minutes using only a keyboard.

What it does

Fraud Hunter ingests 1,000 credit card transactions and runs them through a 4-layer detection pipeline:

  • Layer 1 — Amount deviation: flags transactions whose amount is statistically abnormal for that specific card using a robust z-score (median + IQR).
  • Layer 2 — Temporal burst (Poisson): detects abnormal transaction velocity at the merchant level (compromised terminal) and at the card level (card testing), using Poisson probability.
  • Layer 3 — Rapid siphoning: catches micro-transaction bursts on the same card within a 10-minute window — the classic card-testing pattern before a large fraudulent purchase.
  • Layer 4 — Cross-card merchant burst: identifies when multiple distinct cards hit the same merchant in a 2-hour window, a pattern invisible when looking at cards individually.

Each flagged transaction is presented as a case file with a plain-language explanation generated by Gemini API. The reviewer navigates the queue with keyboard shortcuts (A = approve, D = dismiss, E = escalate), can undo any decision, and adjusts the sensitivity threshold with a real-time slider.

How we built it

We started by profiling each card's normal behavior — median spend, typical categories, known devices and IPs. This baseline feeds all four detection layers, which each return a score between 0 and 1. A weighted sum combines them into a final fraud score:

fraud_score = 0.30×s1 + 0.35×s2 + 0.25×s3 + 0.10×s4

The weights reflect what we observed in the data: Poisson burst detection was the strongest signal, while cross-device fraud was structurally absent in this synthetic dataset.

The frontend is built in Streamlit. Each flagged transaction renders as a dossier with the card's transaction history, the scores broken down by layer, and an AI-generated explanation. Reviewer decisions feed a session-level feedback loop that adjusts category and device weights in real time.

Challenges we ran into

Calibrating without labels. We had no ground truth during development. We had to manually identify fraud patterns in the data (two QuickPay Online bursts, card testing on card_023/038/049, gift card escalation on card_016/018/045) and use them as informal validation cases.

The threshold problem. A fixed global threshold makes no sense in production — you don't know how many frauds to expect. We replaced it with a cost-aware slider (false positive cost vs. missed fraud cost) that lets the reviewer set their own risk tolerance rather than chasing a magic number.

Layer 3 window direction. Our initial implementation used a centered ±10 minute window, which looked into the future — unrealistic in production. We corrected it to a backwards-only window before submission.

Accomplishments that we're proud of

  • A detection engine that finds real patterns in the data without any labeled training examples
  • An interface that a non-technical judge can use without instructions
  • Explainable scores that cite specific reasons per transaction, not just a number
  • A feedback loop that adapts within the session based on reviewer decisions
  • Clean, tested, documented code shipped under 24 hours

What we learned

Fraud detection is 20% algorithm and 80% product. The hardest problems were not mathematical — they were about what information to show, in what order, and how to make a decision feel confident rather than arbitrary. We also learned that calibrating detection without labels forces you to deeply understand your data rather than outsource understanding to a model.

What's next for Fraud Hunter

  • Persistent feedback loop: reviewer decisions written to a database and used to recalibrate weights at the next session launch
  • Cross-device signal: the architecture supports it; a real dataset with shared devices would activate Layer 4 fully
  • Supervised fine-tuning: once an analyst has reviewed a full queue, those labeled decisions become training data for a proper classifier
  • Real-time mode: the pipeline is stateless and could process a stream of transactions with minimal refactoring

Built With

Share this project:

Updates

Submission history