An AI Safety Net for India’s Borrowers

An AI solution which checks the lender against RBI’s records, flags predatory red flags and re-skinned clones, and tells you in your own language whether it’s safe to borrow.

The problem — A trap built for the people who can least afford it

Across India, millions of college students and young low-wage workers need small sums of money at short notice — a semester fee, a month’s rent, a medical bill, a family event — and have nowhere formal to get it. With no credit history and no collateral, banks turn them away. Into that gap steps a flood of slick lending apps promising the opposite: instant cash, no documents, approved in minutes.

Many of those apps are not lenders at all. They are data-harvesting and extortion operations wearing a lender’s clothes. The real product isn’t the loan — it’s the access. Before disbursing anything they demand permission to read the borrower’s contacts, messages and photos, and often an upfront “processing fee” that simply disappears. Then, on the smallest delay in repayment, the operators turn the borrower’s own phone against them: calling and messaging everyone in their contact list, shaming them publicly, and in documented cases circulating morphed obscene images to force payment.

The people hit hardest are precisely those least equipped to spot the trap — first-time borrowers, students, gig workers reaching for quick relief, often unaware that a real lender must be registered with the regulator and would never behave this way. The consequences run far past money. In the worst cases, the relentless harassment has driven people to take their own lives.

Why it persists — So hard to stop

India has cracked down hard, and since July 2025 the RBI even publishes a public directory of the apps that genuinely belong to regulated lenders — so a careful person can check. But three things keep the trap working.

4,700+ apps — Illegal lending apps removed from the Play Store over two years — with another 87 blocked in a single month at the end of 2025. Yet new ones keep appearing, because banning an app and stopping its operators are not the same thing.

First, speed beats caution — nobody cross-references a registry at 9:47 pm with a sudden expense to pay for. Second, the apps re-skin: ban one and the same operators relaunch it next week under a new name and logo, so any list of bad names is always out of date. Third, the tell-tale signs are subtle — a fake “RBI approved” badge, an upfront fee, one permission too many — easy to miss if you don’t know exactly what a legitimate lender looks like. The gap isn’t enforcement. It’s the ten seconds before the tap.

The Idea — A second opinion, before you borrow

The solution does one thing well: you check the loan offer or upload its screenshot/T&C, and it tells you — calmly, in Hindi, Marathi or English — whether this looks like a regulated lender or a likely trap, and exactly what to do next. It has a second mode for people already caught: a calm, ordered set of steps to stop the bleeding and report the operators. And it never just says “scam” — it shows why, so a person can act on the explanation instead of trusting a verdict blindly. The solution offers the following :-

• Reads a loan offer from a typed message or a screenshot
• Works in English, Hindi and Marathi — with spoken input and read-aloud output for low-literacy users
• Verifies the lender against RBI’s Digital Lending Apps directory, with a live web-search fallback for new entries
• Flags predatory red flags — fake “RBI approved” claims, upfront fees, excessive permissions
• Catches re-skinned clones of banned apps by their behaviour, even under a brand-new name
• Gives an explainable verdict — looks regulated, be careful, or likely illegal — with the reasons spelled out
• Tells you exactly what to do next
• Has a harassment-help mode: an ordered escape plan and the official report channels (1930, cybercrime.gov.in, RBI Sachet)

App Interface

Here are a few screenshots showing the main flows — checking an app, a verdict, and the harassment-help mode.

Verifying a regulated lender

A user asking for help on facing harassment with a scam lending app

A promotion message received to a user from a scam lending app

Under the hood — How it works

When an offer comes in, it runs through four stages: a quick read to pull out the facts, two checks against what we already know, and a final judgement that weighs everything together.

The first stage is pure reading. Because Gemini is multimodal, the offer can arrive as a forwarded message, a typed description, or a screenshot of an app listing — and most people will photograph the scary screen rather than retype it. Gemini turns whatever it’s given into a structured set of facts: the claimed lender, fees, permissions, promises, and how the app was distributed.

Multimodal AI — An AI that understands images as well as text. That’s why a borrower can simply screenshot the suspicious app and the tool still reads it.

Those facts become a fingerprint — a description of how the offer behaves, not what it’s called. That distinction is the heart of clone detection, so the fingerprint is built deliberately from behaviour, never the name:

// Describe the offer by its behaviour, not its name
function buildFingerprint(d) {
  return [
    "Loan app offer.",
    `Claimed lender: ${d.claimed_lender}.`,
    `Promises: ${d.promises.join("; ")}.`,
    `Fees before disbursal: ${d.fees_mentioned}.`,
    `Permissions requested: ${d.permissions.join(", ")}.`,
    `Distribution: ${d.distribution}.`
  ].join(" ");
}

The first check is clone detection. Since predatory apps re-skin constantly, matching on the name is useless. Instead the tool embeds the fingerprint and compares it, by meaning, against a store of known predatory patterns. A new name with the old DNA still gets caught:

Embeddings & similarity

An embedding turns text into a list of numbers that captures its meaning. Two offers with similar meaning sit close together, so you can measure how alike they are even when the words and names are completely different — exactly how you catch a renamed clone.

// Turn the fingerprint into a meaning-vector, then measure closeness
const offer = await embed(ai, buildFingerprint(details));

const best = knownBadPatterns
  .map(p => ({ label: p.label, score: cosine(offer, p.vector) }))
  .sort((a, b) => b.score - a.score)[0];

// A high score means "behaves like a trap we already know"
if (best.score >= CLONE_THRESHOLD) {
  flag("clone_match", `Resembles "${best.label}" (similarity ${best.score})`);
}

The second check is the registry lookup. RBI’s directory of regulated lenders is cached locally, so the tool verifies the claimed lender against the official record instantly — first by exact name, then by meaning for spelling variants. This is retrieval-augmented generation: the verdict rests on real records, not the model’s memory.

RAG — Instead of trusting the AI to remember facts, you keep the real facts in a database, look up the relevant ones, and hand them to the AI to reason over. More accurate, and you can cite the source. Here the database is RBI’s own list of regulated lenders.

// 1) fast and certain: exact name match against RBI's cached list
for (const e of registry) {
  if (namesMatch(details.claimed_lender, e)) return { found: true, via: "exact", entity: e };
}
// 2) fuzzy fallback: match by meaning, for spelling variants
const top = nearestByEmbedding(details, registry);
if (top.score >= FUZZY_THRESHOLD) return { found: true, via: "fuzzy", entity: top.entity };

return { found: false };

Only if the cache can’t confirm the lender does the tool reach for live web grounding. That keeps the common case fast and reproducible, and pays for a real-time search only when it’s genuinely needed:

Grounding — Letting the AI check live sources on the web before answering, and cite them — so it isn’t guessing from old training data. Useful for a lender added to RBI’s list only last week

// Only pay for a live web search when the cache can't confirm the lender
const useGrounding = !(registry.ready && registry.found);

const config = { temperature: 0.2 };
if (useGrounding) config.tools = [{ googleSearch: {} }];   // grounding on demand

Finally, the assessment stage hands everything — the extracted facts, the clone result, the registry result — back to Gemini along with a compliance rulebook, and asks for one explainable verdict: looks regulated, be careful, or likely illegal, with the reasons spelled out.

The trade-offs

Every interesting decision here was a trade-off, and a build story is more useful when it admits them.

Pipeline over agent - An autonomous agent could be more thorough, but it’s slower and less predictable — bad qualities for a safety tool people lean on in a hurry. A fixed pipeline runs the same way every time and is far easier to test and trust. I traded peak capability for consistency, on purpose.

Cached registry over always-live - Checking RBI’s records live on every request is always current, but slow and non-deterministic. Caching makes the common case fast and reproducible, at the cost of a refresh job and a live-search fallback for brand-new entries.

A rulebook over a trained classifier - I could have trained a model to label apps good or bad, but that needs a large, clean, labelled dataset I don’t have — and a trained model can’t easily explain itself. A written rulebook the AI reasons over is both more accurate at this scale and fully explainable, which matters enormously when a wrong verdict could unfairly tar a real business:

// The compliance "rulebook" the AI reasons over — explainable, versionable
const RED_FLAGS = [
  { id: "fake_rbi_approval",     weight: 3, label: "Claims 'RBI approved' — RBI does not license loan apps." },
  { id: "upfront_fee",           weight: 3, label: "Demands a fee before disbursing the loan." },
  { id: "excessive_permissions", weight: 3, label: "Wants contacts, SMS or photos it does not need." },
  { id: "clone_match",           weight: 3, label: "Matches a known predatory pattern — likely a re-skin." }
  // ...full list lives in rubric.js, version-controlled and unit-testable
];

Risk language, never accusation - The tool describes risk and names red flags; it never declares a named app legally “illegal.” That restraint is both ethically right and legally safer, and it shaped how every verdict is worded.

Did this even need AI?

Honestly, not all of it — and I think saying so out loud makes the whole thing more credible.

Take the most important step: checking whether a lender is actually registered with the RBI. That’s just a database lookup. And it should stay that way — you want a hard, citable fact there, not a model’s hunch. The red-flag checks are similar. Spotting an upfront fee, or a fake “RBI approved” badge, or an app that wants your entire contact list — that’s rules, not magic.

So where does AI actually earn its keep? Three places. Reading a messy, half-Hindi message or a screenshot and pulling out what matters. Catching a banned app that’s been relaunched under a new name, by recognising how it behaves rather than what it’s called. And explaining the verdict back in plain words, in the language the person actually reads.

Take those three away and you’ve built a tool for someone calm, literate, and comfortable in English — someone who’ll happily type an app name into a form. But that’s not who this is for. This is for the person holding a screenshot at 9:47 pm, with a wedding to pay for and a bad feeling they can’t quite name.

That’s the line I’d draw for any project: use AI where rules genuinely fall short, and let a plain database do the part that should never be a guess. It’s less flashy than “powered by AI” — and a much better answer when someone asks why.

Closing thoughts

Enforcement will always be a step behind operators who can relaunch in a week. The one place this fight can actually be won is in the borrower’s hand, in the moment before the tap — and that’s a moment where a fast, multilingual, explainable second opinion can change the outcome. That’s the whole point: not to replace the regulator, but to stand next to the potential victim and say, gently, don’t tap yes.

The prototype proves the idea; a few things would make it real. A scheduled ingestion job to keep the cached RBI directory genuinely fresh, and a proper vector database in place of the in-memory store, so it scales past a demo. A continuously-updated feed of banned-app fingerprints, so clone detection learns from every new takedown. A real-time mode that listens to a recovery-agent call and warns the borrower mid-conversation. And careful calibration of the matching thresholds against real labelled data, with a feedback loop so wrong calls make the next call better.

To my readers, If you’re building something similar to solve for this problem statement , I hope the breakdown above — what genuinely needed AI, what didn’t, and the trade-offs in between — is useful. I’d love to hear how you’d approach it differently.

The code is open source. You can find the full project — backend, clone detection, the cached RBI registry, and the UI — on my GitHub: **github.com/sarthaksx**. Clone it, run it with your own Gemini key, and tell me what breaks.

The stack — built on Google AI

• Gemini 3.5 Flash — multimodal reading of messages and screenshots, and the final reasoned verdict.
• Google Search grounding — live verification of lenders against official sources, on a cache miss.
• Gemini Embeddings — the fingerprints behind clone detection and the cached registry lookup.
• Google AI Studio — where every prompt was prototyped before it became code.

Guidance only — the tool describes risk, not legal fact, and is not affiliated with RBI or any bank. If you’re being harassed by a loan app in India, you can report it at cybercrime.gov.in or call 1930.