Inspiration
Fraud Killer was inspired by a simple problem: most fraud monitoring systems look at transactions one row at a time, but fraud rings hide in relationships. In the Track 02 Fraud Watch benchmark, the suspicious accounts stayed below traditional alert thresholds, moved money in small amounts, and blended into normal activity. The insight was that the fraud was not in any single transaction. It was in the graph.
We wanted to build a tool for an analyst who only has a few minutes per case: find the suspicious ring, explain why it matters, answer follow-up questions, and produce a case pack that can be escalated.
What it does
Fraud Killer detects coordinated fraud rings from transaction data by modeling accounts, transfers, devices, and timing as a graph. It surfaces suspicious clusters that threshold rules miss, ranks them by risk, and explains the evidence in plain English.
The app shows a ranked fraud case queue, a graph visualization of the ring, structural evidence such as circular flows and shared devices, an investigator Q&A interface, and a downloadable SAR-style case pack.
The core risk score is an explainable weighted blend of graph signals:
$$ \text{Risk} = w_1C + w_2S + w_3T + w_4M + w_5H + w_6I $$
where $C$ is circular flow, $S$ is cluster size, $T$ is sub-threshold structuring, $M$ is mule routing, $H$ is hub centrality, and $I$ is shared identity evidence.
How we built it
We built Fraud Killer as a four-agent pipeline:
- Grapher ingests the CSV and builds the account-to-account money-flow graph.
- Ring Detective computes structural fraud patterns such as cycles, coordinated clusters, shared devices, off-hours sub-threshold transfers, and routing hubs.
- Investigator answers analyst questions using only graph-grounded evidence.
- Case Reporter generates a downloadable Markdown/HTML case pack for escalation.
The backend uses Python, FastAPI, NetworkX, and a shared memory bus so each agent reads the previous agent's output and writes its own findings. The frontend is a lightweight single-page app with a ranked queue, case details, graph view, Q&A, decision controls, and download actions.
We also added an optional Cognee/GraphRAG path for inspectable knowledge graph memory, while keeping the local bus deterministic so the demo works without API keys or network access.
Challenges we ran into
The biggest challenge was making the detection explainable rather than just “AI says suspicious.” Every score needed to trace back to real graph evidence: exact accounts, transfers, timestamps, devices, and patterns.
Another challenge was avoiding overfitting to the benchmark. Instead of hardcoding ring members, we built general graph patterns that work from the transaction topology itself.
We also had to balance the hackathon requirements with a usable product experience. The system needed multiple real agent handoffs, visible reasoning, downloadable output, and a cold-start demo that judges could understand quickly.
Accomplishments that we're proud of
We are proud that Fraud Killer catches the kind of ring a simple threshold rule misses. In the benchmark, the suspicious transfers stay under the usual alert line, but the graph structure reveals coordinated behavior.
We are also proud of the end-to-end workflow: detection, ranking, explanation, analyst Q&A, decision logging, and downloadable case reporting all live in one product surface.
Most importantly, the system does not just flag accounts. It tells a story an investigator can follow.
What we learned
We learned that graph structure is a powerful fraud signal. Fraud rings can hide from row-level rules, but it is much harder for them to hide cycles, hubs, synchronized timing, shared devices, and coordinated onboarding.
We also learned that explainability has to be designed into the system from the beginning. If every agent writes structured evidence, the final report becomes much stronger because it can re-walk the full chain of reasoning.
Finally, we learned that multi-agent systems are most useful when agents have distinct jobs and real handoffs, not when they are just repeated LLM calls.
What's next for Fraud Killer
Next, we want to expand Fraud Killer from a hackathon prototype into a more production-ready investigation assistant. That means supporting larger datasets, richer identity signals, real-time ingestion, stronger graph search, and better analyst feedback loops.
We also want to improve the case pack into a full compliance workflow: reviewer comments, audit history, SAR export, and integration with existing fraud operations tools.
Built With
- fastapi
- python
Log in or sign up for Devpost to join the conversation.