Scam Analysis

Analyze suspicious messages, screenshots, and links using AI-extracted evidence, deterministic scam-pattern matching, documented examples, and explicit uncertainty.

Comment

Scam Analysis

One-line summary

Scam Analysis extracts grounded warning signs from suspicious messages, screenshots, and links, then compares them with eight documented scam patterns.

Inspiration

Scam messages often change their wording, identity, platform, and appearance while following the same basic behavior. As a team, we wanted to see whether AI could help pull those warning signs out of messy real-world input while leaving the final classification to code we could inspect and test.

That idea shaped the whole project. The AI handles extraction, while the rest of the system checks the evidence, compares it with known patterns, and decides how strong the match is.

What it does

Scam Analysis accepts suspicious text, screenshots or images, URL strings, and optional context. It returns one of three statuses: Strong match, Possible match, or Insufficient evidence.

Each result shows the warning signs supported by the submission, immediate safety actions, a likely scam type when the evidence supports one, related documented examples, and any important uncertainty or differences.

The app never gives a "safe" label. If the evidence is too weak for a stronger conclusion, the result stays at Insufficient evidence.

Who it's for

Scam Analysis is for people who receive a suspicious message, screenshot, or link and want more context before they respond, send money, share credentials, or follow instructions from the sender. It is meant to help users inspect the warning signs in what they received and decide what to verify before taking action.

Real-world impact

Scams often rely on getting people to act quickly. Scam Analysis gives users a way to slow that process down by showing which warning signs are actually present, how they compare with documented scam patterns, and what safer next steps they can take.

The system also keeps uncertainty visible. If the evidence is weak, it returns Insufficient evidence instead of suggesting that the content is safe. This can help users avoid treating an uncertain AI response as proof that a message or link is legitimate.

How we built it

We built Scam Analysis with Next.js 16, React, and TypeScript.

A Qwen model hosted through Groq reads the submitted content and extracts observations into a schema controlled with Zod. TypeScript code then checks whether those observations are actually supported by the text, context, URL string, or visible image content.

Once the evidence is grounded, a deterministic weighted matcher compares the supported signals with eight local scam profiles. That matcher chooses the final status and attaches the relevant documented examples and predefined safety actions.

The project keeps its scam profiles, 16 documented examples, and safety actions in local JSON files. It does not use a database, vector database, RAG pipeline, multi-agent runtime, automatic URL fetching, or malware execution.

We deployed the finished app on Vercel.

Challenges we ran into

A lot of the work went into making the AI output predictable enough for the rest of the system to use. We had to constrain the model to approved signal identifiers, handle malformed output, and make sure unsupported observations did not slip into the final result.

Groq rate limits also caused a practical problem during development. Our retry logic initially risked sending duplicate requests, so we changed it to treat rate-limit responses differently from temporary server failures.

Some scam types share the same warning signs, especially urgency, money requests, identity claims, and download requests. We had to design the matching logic so those overlapping signals could still lead to a useful result.

Screenshot support created another boundary for the project. We wanted the app to analyze visible content in an image without turning it into a general-purpose file scanner or malware sandbox.

We also spent time on the Insufficient evidence state. The system needed a way to stop when the submission did not support a stronger conclusion.

Accomplishments we're proud of

  • Working analysis for text, screenshots, URL strings, and combined inputs.
  • Eight controlled scam types backed by 16 documented examples from the FTC, FBI Internet Crime Complaint Center, CISA, and GitHub Security.
  • Evidence grounding between AI extraction and deterministic classification.
  • Explicit abstention for low-evidence submissions.
  • A reproducible evaluation against rules-only and direct LLM baselines.
  • 122 automated tests across 14 files.
  • A deployed app that our team could test end to end before submission.

What we learned

The biggest lesson was that structured AI output still needs verification. A response can fit the expected schema and still contain an observation that the original submission does not support.

Separating extraction from classification made the system easier for us to debug. We could inspect the model's observations, check the grounding step, and test the matcher separately instead of treating the whole result as one opaque AI answer.

We also learned that uncertainty has to be represented directly in the product. Insufficient evidence gives the system a way to stop when the available information is weak.

The baseline comparison was useful for the same reason. Our rules-only baseline scored better on this small synthetic set, while the hybrid system performed much better than direct generic LLM classification. Keeping both results visible gave us a clearer picture of what the current system does well and where it still needs work.

What's next

We would like to test the system on a larger and more varied collection of examples, especially cases with less obvious wording.

The professional-targeted and malicious-attachment categories also need better extraction. Both were missed by the hybrid system in our current evaluation because the extractor returned no supported signals for those inputs.

We would also expand the documented-example corpus, improve grounding for image evidence, and experiment with more personalized safety guidance while keeping the safety rules themselves deterministic.

Built with

  • Next.js
  • React
  • TypeScript
  • Groq
  • Qwen
  • Zod
  • Vitest
  • Testing Library
  • Vercel

Evaluation

We evaluated the project on 16 synthetic holdout cases: 8 scam cases, 4 benign cases, and 4 ambiguous cases.

System Correct scam type Non-scam abstention Overall
Hybrid 6/8 8/8 14/16
Rules-only 8/8 8/8 16/16
Direct LLM 1/8 8/8 9/16

The hybrid system made 14 of 16 correct decisions and abstained on every benign and ambiguous case. Direct generic LLM classification made 9 of 16 correct decisions.

The rules-only baseline scored 16 of 16 on this deliberately small, keyword-clear synthetic set. The hybrid system missed the professional-targeted and malicious-attachment cases because structured extraction returned no supported signals for those two inputs.

This is a small synthetic hackathon evaluation, not a production benchmark.

Built With

Share this project:

Updates

Submission history