ScamShield BD — Project Story

Inspiration

Scams in Bangladesh don't look like the scams most fraud-detection tools are built for. They don't arrive as suspicious email attachments — they arrive as a Facebook message from a "customer care" account, a WhatsApp voice note claiming to be from bKash, or a job post promising ৪০,০০০ টাকা a month for work that doesn't exist. Mobile financial services like bKash, Nagad, and Rocket have made everyday payments incredibly convenient in Bangladesh — but that same convenience has become the easiest lever for scammers, because once an OTP or a "registration fee" is sent, there's usually no way back.

We kept noticing the same pattern in every scam story we heard: someone felt something was off, but had no quick, trustworthy way to check it before it was too late. Existing scam-checking tools are built for other markets — they don't understand bKash agent numbers, don't read Bangla, and don't know what a "চাকরির অফার" scam even looks like. We wanted to build something that spoke the language — literally and culturally — of the people actually being targeted.

What it does

ScamShield BD lets someone paste in a URL, phone number, message, shop name, or social account and get back more than a yes/no verdict. It returns a 0–100 risk score, a plain-language explanation of why (in Bangla or English), a recommended action, and — if others have reported the same thing — the community history behind it. Reports feed a shared intelligence layer, so an individual report about a suspicious job posting isn't just filed away; it becomes part of a growing pattern the whole community can see.

How we built it

The core is a modular Risk Intelligence Engine: a library of independent, weighted signals — OTP requests, advance-payment demands, urgency language, unrealistic profit promises, fake-authority claims, phishing patterns, suspicious URL structure, and community report volume. Each detected signal contributes a weight, and the total is clamped into a score:

$$\text{score} = \min\left(100,\ \sum_{i \in S} w_i\right)$$

where $S$ is the set of signals detected in the submission and $w_i$ is that signal's weight. Keeping this rule-based and deterministic — rather than a black box — was a deliberate choice: it means the app can always explain itself, and it never breaks if an API key is missing.

On top of that sits an optional AI layer. If an Anthropic API key is configured, Claude turns the detected signals into a more natural, contextual explanation. If it isn't, the app falls back to the rule-based explanation instantly and silently — nobody using the tool ever hits a wall because a key wasn't set.

We also built Scam DNA: instead of treating every report as an isolated incident, reports that share a signature combination of signals — like "unrealistic promise + advance payment" — get clustered into a named, recognizable pattern (e.g. Fake Job Recruitment, OTP / Account Takeover Phishing). That's the piece we're most proud of, because it reframes the product from "a scam checker" into "a system that learns what scams in Bangladesh actually look like."

The stack is Next.js 14 with the App Router, TypeScript, and Tailwind for the frontend and API routes; MongoDB for reports, entities, and risk analyses; and JWT-based auth for a protected admin dashboard where reports can be reviewed, verified, or rejected — using neutral labels like Reported and Community Flagged rather than declaring guilt.

Challenges we ran into

Building a system that's honest about its own uncertainty. It was tempting to make the AI-assisted explanation sound more confident than it should — but a false accusation against a real shop or person is a real harm. We had to be deliberate about uncertainty-aware language everywhere, and about never letting the AI override or contradict the rule-based signals it was explaining.

Making the product bilingual by design, not as an afterthought. Translating UI copy is the easy part. What we underestimated was everything around the text — numeral formatting, dropdown option labels, error messages bubbling up from the API, and dark/light theme styling that had been written assuming one visual mode. Localization touched far more surface area of the codebase than we expected, and we're still working through the corners we missed — Bangla numerals in stats, some untranslated form options, and a theme toggle that doesn't yet reach every component.

Keeping the AI optional without making it feel like an afterthought. We wanted judges (and real users) to be able to run the whole thing with zero API keys and still get a fully functional product, not a degraded demo. That meant designing the rule-based engine first as the real product, and treating the AI layer as an enhancement layer on top — the opposite order from how most "AI-powered" tools get built.

Privacy versus usefulness in a community database. A public, searchable scam database is only useful if people can find what they're looking for — but phone numbers and personal evidence can't just be displayed openly. Deciding what to mask, what to show only to authenticated admins, and how to label unverified reports without implying guilt took more thought than the actual masking code did.

Accomplishments that we're proud of

We're proud that ScamShield BD works fully offline from AI — turn off the Anthropic key entirely and every feature still runs, still explains itself, still scores a submission. Too many "AI-powered" hackathon projects quietly stop functioning the moment a key is missing; we treated that as a hard constraint from day one rather than a fallback bolted on at the end.

We're also proud of Scam DNA. Building a rule-based clustering layer that groups reports by shared signal combinations — turning isolated complaints into a named, recognizable pattern like Fake Job Recruitment or OTP / Account Takeover Phishing — is what elevates this from a scam checker into something closer to real community threat intelligence. It's a small piece of logic,

$$ \text{pattern}(r) = { p \in P \mid \text{signals}(r) \supseteq \text{requiredSignals}(p) } $$

but it's the piece that makes the whole system feel like it's learning rather than just scoring.

Finally, we're proud that the product is bilingual from the ground up, not translated after the fact — Bangla and English share the same risk engine, the same explanations, and the same recommended actions, so no user gets a "lesser" experience depending on which language they're more comfortable in (even as we're still tightening a few corners of that localization).

What we learned

Building for a specific context — Bangladeshi mobile financial services, Bangla language, local scam vocabulary — made every generic "AI safety" and "fraud detection" pattern we knew about need rethinking. A model or a rule that works for detecting phishing in English doesn't transfer cleanly; it has to be rebuilt with the actual local signals in mind. We also came away with a much sharper appreciation for how much of a "smart" product's trustworthiness comes from being able to explain itself in plain terms — not from the score itself, but from being able to say, honestly and specifically, why.

What's next for ScamShield BD

Finish full Bangla localization — Bengali numerals throughout the UI, translated dropdown options and error messages, and a dark/light theme that actually adapts every component, not just a few. Lookalike-domain detection — catching typosquatted brand domains (e.g. a fake bKash-lookalike URL) with a distance check against known legitimate Bangladeshi service domains, extending the existing suspicious-URL signal. Screenshot OCR via Claude's vision input — letting a user upload a screenshot of a scam message and have the text auto-extracted into the analysis pipeline, instead of retyping it by hand. A feedback loop on accuracy — letting users confirm or dispute a risk assessment, and using that signal over time to retune the weight each rule contributes to the score. Scam hotspot mapping — tagging reports by division/district so patterns like a wave of fake-shop reports in a specific area become visible on a map, not just in a list. Abuse prevention — rate limiting and lightweight verification on report submission, so the community database can scale without being drowned out by spam or retaliatory false reports. A messaging-app front end — putting the same checker behind a WhatsApp or Messenger bot, since that's where most of the scams — and most of the people most at risk — already are.

Built With

Share this project:

Updates

Submission history