DEV Community: TEJAS _

ProofCheck: checking UPI payment screenshots against the bank statement, on your own laptop

TEJAS _ — Tue, 13 Oct 2026 19:49:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

If you've ever paid a tuition fee, a society maintenance bill or a home baker in India, you know how it goes. You pay by UPI, take a screenshot, send it on WhatsApp. Done.

Now think about the person on the other end. A tuition teacher with 40 students gets 40 screenshots a month, at random times, buried in the rest of her WhatsApp. At some point she sits down with her bank statement and ticks them off one by one, reading 12-digit reference numbers off a phone screen.

And she can't fully trust any of them. A screenshot is just a picture. It can be edited. It can be of a payment that failed. It can be last month's screenshot sent again. Fake payment screenshots are a common enough scam that banks and payment companies keep publishing guides telling shopkeepers to check their account, not the screenshot.

That check is the whole tool. ProofCheck takes a folder of payment screenshots and a bank statement export, reads the UPI reference number (the UTR) off each screenshot, and looks for it in the statement. Every screenshot ends up as one of these:

Result	What it means
Verified	The UTR is in the statement and the amount matches. The money came in.
Amount differs	The UTR is there, but the screenshot shows a different amount.
Not in statement	No such UTR. Could be fake, could be a payment that hasn't settled yet.
Duplicate	Another screenshot already used this UTR.
Outside dates	The screenshot is dated after the statement ends. Check a newer statement.
Unreadable	Couldn't find a UTR. You'll have to look at this one yourself.

You'll notice it never says "fake". I went back and forth on that. A missing UTR is suspicious, but a payment made an hour ago is missing too, and accusing a parent of fraud over a settlement delay is a good way to lose a student.

Give it a small roster as well (who owes how much, and who usually pays for them) and you get the list a teacher actually cares about on the 5th of the month: who has paid, who paid part, who only sent a screenshot, and who hasn't paid at all. Money that arrived without any screenshot still counts, because the statement is the source of truth, not WhatsApp.

So who would pay for this? Anyone collecting the same payments every month into a personal account and matching them by hand. Tuition classes are the obvious case. Housing society treasurers are another: a 120-flat society has 120 maintenance payments to match every month, often in a spreadsheet. The amounts are small, so the tool has to cost almost nothing to run, and that's a big part of why it's built on open models.

Demo

The demo data is a made-up tuition class collecting October fees. There are eight screenshots, and between them they cover every case: payments that went through, one that never arrived, a failed payment sent as proof, a screenshot where ₹200 was edited to ₹2,000, and the same screenshot sent twice for two kids.

Results show up row by row while it's still reading:

On my laptop (a GTX 1650 with 4 GB of VRAM, nothing fancy) it got all 8 screenshots and all 8 roster lines right. With the model already loaded, the run took about 94 seconds, so roughly 12 seconds a screenshot.

What that does and doesn't prove: the demo data is synthetic, so it shows the pipeline works end to end. It says nothing yet about how well it reads real screenshots from real phones.

About those demo screenshots. They come from a fake app I called "Demo Pay", with SAMPLE - NOT A REAL PAYMENT stamped across them. It felt wrong to build a tool that catches fake payment screenshots and then ship a folder of convincing fake payment screenshots with it.

If you want to run it yourself:

ollama pull gemma3:4b
cd frontend && npm ci && npm run build && cd ..
cd backend && uv sync && uv run proofcheck   # then open http://127.0.0.1:8000

Code

Surge77 / proofcheck

Check UPI payment screenshots against your bank statement with local open-weight models (Gemma + RapidOCR). Your statement never leaves your laptop.

ProofCheck

Check UPI payment screenshots against your bank statement, on your own laptop.

Tuition teachers, housing-society treasurers, home bakers and tiffin services collect payments by UPI into a personal account. The "proof" arrives as a screenshot on WhatsApp, and every month someone matches dozens of them against the bank statement by hand. Fake payment screenshots are a common scam, and they look exactly like real ones.

ProofCheck reads each screenshot with local open-weight models, finds its 12-digit UPI reference (UTR), and looks for that reference in your bank statement. It then tells you, in plain words who really paid.

Nothing is uploaded anywhere. The models run on your machine, uploads stay in memory, and your bank statement never leaves your laptop.

What it tells you

Result	Meaning
Verified	The UTR is in your statement with the same amount. The money arrived.
Amount differs	The UTR is there, but the screenshot

…

View on GitHub

How I Built It

screenshot ──► RapidOCR ─────► exact characters ─┐
     │                                           ├─► cross-check ─► receipt (high / low confidence)
     └───────► Gemma 3 4B ───► what they mean ───┘                       │
bank statement (CSV / XLS / XLSX) ──► credits with UTR, payer, UPI id ──► reconcile ─► report

The hard part is reading the screenshot. A typical payment screen has a phone number, a transaction ID, a date and the UTR all in one place, and a phone number with the 91 prefix is also 12 digits.

I ended up using two open models and making them check each other.

RapidOCR, which runs PaddleOCR's models on onnxruntime, reads the text exactly, character by character. It has no idea which number is the UTR, though.

Gemma 3 4B, running locally in Ollama, looks at the same screenshot and understands it. It can tell the UTR from the phone number, and "Payment Successful" from "Payment Failed". What it can't always do is read twelve small digits perfectly.

So neither of them gets the final say. When Gemma says "this is the UTR", ProofCheck only accepts it if OCR saw exactly the same digits:

def _fuse_utr(lines, vision_utr, issues):
    seen_by_ocr = {c.value for c in utr_candidates(lines)}
    claimed = re.sub(r"\s", "", vision_utr or "")
    if claimed in seen_by_ocr:
        return claimed, True          # both models agree
    fallback = _ocr_utr(lines)        # a single labelled OCR candidate, or nothing
    if claimed:
        issues.append("The vision model's UTR was not confirmed by OCR; please check it.")
    if fallback is None:
        issues.append("Could not tell which number is the UPI reference.")
    return fallback, False

The amount, the payment status and the payer's name go through the same kind of check. A screenshot only gets "high confidence" when both models agree and the screen itself says the payment went through. Anything else gets flagged for a person to look at, with the reason written out.

The models only read. Deciding whether something is verified, a duplicate or missing is ordinary Python with tests around it. I didn't want an LLM making the call on whether someone paid.

Bank statements were their own small adventure. There's no UTR column. Each bank stuffs it into a free-text description, and each one does it differently: SBI writes UPI/CR/<utr>/<name>/..., HDFC writes UPI-<name>-<upi id>-<ifsc>-<utr>. ProofCheck works out the bank from the header row, skips the address and account-number lines at the top, and reads CSV, XLSX and the old XLS format that some banks still hand out.

Around that sits a FastAPI backend that streams results back as they're ready, a React and Tailwind frontend, and Decimal everywhere money shows up.

Things that bit me

I'd written "nothing is written to disk" in the README before checking it, and it wasn't true. I ran a security review on the upload code, and the first finding was that FastAPI's file uploads let Starlette save anything over 1 MB to a temp file. Most screenshots and bank statements are over 1 MB. I swapped in a parser that keeps everything in memory and added a test that fails if Python's tempfile is ever touched. The review found 10 problems in total, including a DNS rebinding hole against localhost. They're all fixed now, but that first one stung.

Screenshots can carry prompt injection. Text inside an image can nudge a vision model into calling a failed payment a success. That's why the status and the payer name also have to match what OCR read, not just the UTR.

Then there was capital I versus lowercase l. Gemma read "Meera Iyer" correctly, OCR read "Meera lyer", and my strict name check threw out the right answer. I only caught it by running the whole thing on realistic data, which is a decent argument for doing that early.

Why Does Open Innovation Matter?

Without open models, this project doesn't really work.

The input is someone's bank statement plus other people's names, UPI IDs and payment history. I wouldn't upload that to a third-party API, and I don't think a tuition teacher should either. With open weights everything stays on the laptop. The OCR models come bundled inside the Python package, Gemma runs in Ollama on localhost, and ProofCheck refuses to start if the Ollama URL points at another machine.

Then there's the cost. Every screenshot goes through two models. With a paid vision API that's a charge per screenshot, every month, for a customer who's paying very little. Locally, once the models are downloaded, the next screenshot costs nothing.

The cross-check depends on it too. I can run a dedicated OCR model and a vision-language model side by side and compare their answers because both run on my machine. A single hosted endpoint would give me one answer and nothing to check it against.

And once it's set up it works offline. No API key, no rate limits, no pricing page that can change under me.

Prize Categories

Best Use of Gemma: Gemma 3 4B runs locally in Ollama and reads every payment screenshot. ProofCheck checks its answers against OCR before trusting them.

A few DEV posts I read along the way: I ran OCR in the browser so receipt images never leave the device has the same privacy instinct, How to Automate Invoice Reconciliation covers matching from the business side, and What Really Happens When You Make an Online Payment? is a good explainer on where payment references come from.

Paper Trials: a lab notebook that sends you outside to throw paper airplanes

TEJAS _ — Sun, 11 Oct 2026 07:03:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Paper Trials is a lab notebook for paper airplanes. It doesn't fold anything for you and it doesn't simulate flight. It tells you which one thing to change about your plane, predicts how far it will fly, and then asks you to close the tab and go outside.

The loop is:

Plan. Pick a change, like "wing span 20 cm → 21 cm". Only one thing changes, so you'll know what made the difference.
Predict. The app predicts the median distance with a range and saves it. It can't be edited after that, so you can't quietly move the goalposts once you've seen the result.
Fly. Build it, go outside, throw it three times the same way, and measure where it lands. A tape is nice; counting steps works.
Log. Come back, type in the distances, and add a note if something happened ("climbed, stalled, pulled left").
Learn. The model learns from every flight, and the notebook suggests the next change.

The screen is only used at the start and the end. Everything in between happens on grass.

I built it for people who like tinkering and wouldn't call it science. That covers kids, parents looking for an afternoon project, and teachers who want a reason to take a class outside. A paper plane is about the cheapest real experiment there is. It's also noisy enough to teach the habits that matter: change one variable at a time, write the prediction down first, repeat the test, and check whether your predictions were any good.

Demo

Paper Trials runs on your own machine (both models run locally), so there's no hosted demo. Setup is in the README: build the frontend, uv run papertrials, and optionally ollama pull gemma3:4b. Here's the loop in screenshots, using the built-in sample notebook.

The notebook suggests the next change. Each suggestion shows its predicted range, with your current best as a dashed line:

Test mode is the "go outside" screen. It shows exactly what to build, and the prediction is already locked in:

The Lab plots every prediction against what the plane really did:

Code

Surge77 / paper-trials

A lab notebook for paper airplanes: plan one change, fly it outside, and let TabPFN and Gemma learn from every throw.

How I Built It

The backend is FastAPI and SQLite. The frontend is React with Recharts. Two open models do the interesting work, and plain code holds them together.

TabPFN predicts the distance

The hard part of this project is the amount of data. After a weekend you might have 40 flights. Most models can't learn anything from 40 rows, and the ones that can tend to be very confident and very wrong.

TabPFN is built for exactly this. It's a model pretrained on millions of synthetic tables, and it predicts from a small table of your own data in one forward pass, without any training. Each flight is a row: the plane's design, how it was thrown, and the wind. The target is the distance. I ask it for the 10th, 50th and 90th percentiles, and those become the predicted range.

The range is the important bit. Paper planes are noisy, so "14.3 m" would be a lie, while "probably 12.9 to 15.5 m" is something you can actually check. The Lab keeps score of how often the real median lands inside the predicted range.

Until there are 4 planes and 8 flights, TabPFN doesn't run. A nearest-neighbour guess fills in, its range widens the further a new plane is from anything you've flown, and the app labels it as a rough guess.

A gotcha worth knowing: newer TabPFN versions need a browser licence login before their weights download. My first version wrapped TabPFN in a try/except that fell back to the baseline, and it worked "fine". Then I noticed every single prediction in my sample data said baseline. TabPFN had never run once. The v2 weights download without an account, so the app pins those. After the fix, the sample notebook's TabPFN predictions landed inside their range 6 times out of 8, against 2 out of 3 for the baseline, and they missed by 0.8 m on average instead of 1.5 m.

The next experiment comes from code, not a chatbot

I didn't want a language model inventing plane designs. The recommender is under 200 lines of plain Python:

Start from your best plane.
Try every single-step change to one setting: a paper clip more or less, 1 cm wider or narrower, 5° sharper or blunter. Skip anything you've already built.
Ask TabPFN about all of them at once and score each by predicted median, plus a bonus for a wide range. A plane the model is unsure about teaches it the most, so it's worth a flight even when it isn't the favourite.
If your notes keep mentioning a stall, changes known to fix stalls (a clip on the nose, less tail bend) get a bonus too.

Gemma reads your notes, and gets checked

Gemma 3 4B runs locally through Ollama and has three small jobs.

Reading flight notes. "Went up, stalled and dropped" becomes the tag stall, which the recommender can act on. Gemma returns JSON constrained to a fixed list of issues. When Ollama isn't running, keyword matching takes over.

Writing a two-sentence lab note after each experiment. This turned out to be the most interesting part, because a 4B model writing about numbers will get them wrong in creative ways. Real examples from my testing:

"The median distance increased from 14.3 m to 14.1 m."

"The flight notes indicated a stall and veer right, which caused the median distance to fall below the predicted range."

"No changes were made from the previous plane, resulting in a veer left."

Every number in those is correct, so a "did it invent numbers?" check passes all three. So the code checks more than numbers. A note is rejected if it uses a number that isn't in the facts, says the distance went up when it went down, contradicts the inside/outside verdict, mentions a problem nobody reported, or claims a cause, because three throws can't tell you why something happened. A rejected note is replaced by a plain template. Each of those checks exists because Gemma did that exact thing at least once, and each has a test with the real sentence that triggered it.

Checking a photo. Before you throw, you can show Gemma a photo and it estimates whether the wings look even and the nose looks sharp. It's labelled as an estimate with a confidence score, it's never used by the prediction model, and the photo isn't saved.

Honesty about the sample data

The app ships with a sample notebook so you can look around before folding anything. Those flights are simulated: a made-up formula plus noise. The predictions inside them are real, though. A script replays the experiments in order through the app's own recommender and models, so every sample prediction was made before its flights existed. The sample is labelled everywhere it appears and one button removes it.

Why Does Open Innovation Matter?

It runs on a laptop with nothing to sign up for. There are no API keys, no account and no bill. A teacher can install it on a school laptop and a class can use it all term for free. Gemma runs on my GTX 1650 through Ollama, and TabPFN runs on the CPU, which is plenty at this data size.

The right tool for the job was an open one. Asking a hosted chatbot "how far will this plane fly?" gets you a confident sentence. TabPFN gets you a calibrated range from 40 rows of your own data. Because the model sits inside my code, I could ask it for quantiles, batch every candidate into one call, and keep score of its accuracy.

I could see and fix what went wrong. The licence fallback, the lab note that got the direction backwards: I found both because I could run the models locally as often as I liked and read every output. A rate-limited API makes you test less.

Your data stays with you. Your flight log, your notes and photos of your kid's paper planes stay on your own computer.

It's swappable. The Gemma model is one environment variable. If a better small model comes out next month, change one line and the guard checks still apply.

Prize Categories

Best Use of TabPFN: TabPFN makes every prediction, with quantile ranges, from a dataset that starts at zero rows, and drives the experiment recommender.
Best Use of Gemma: Gemma 3 4B runs locally for flight-note tagging, grounded lab notes and photo checks, all with tested guards against the mistakes it actually made.

Built with PriorLabs-TabPFN.

OfferProof: an offline job-scam checker for my fresher friends

TEJAS _ — Fri, 02 Oct 2026 13:15:45 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

When I read "build for a friend", my first thought was that none of my friends had a problem I could fix in a weekend. Then I thought about what most of my batch is doing right now. We're all applying for our first jobs. And if you're a fresher looking for a job, you're exactly who fake job offers are aimed at.

They look something like this. I wrote this one from public fraud advisories, so it isn't a real message, but every line in it is something those advisories warn about:

From: infosys.recruitment.cell@gmail.com
Subject: Offer Letter - Infosys Ltd

Dear Candidate, congratulations! You are selected for System Engineer at Infosys, Pune.
Your interview will be on Telegram, message our HR @infosys_hr_desk.
Pay a refundable registration fee of Rs 1,999 within 2 hours to confirm your seat.

If you've seen a few of these, you'd laugh at it. But if it's the first offer you've ever got, it says Infosys, it says congratulations, and it wants an answer in two hours. ₹1,999 to lock in a job at Infosys doesn't sound like much.

So I built OfferProof. You paste the message in and it tells you which parts look like a scam, quotes the exact words it's worried about, and gives you a question to send back. Something like "can you email me from your official Infosys address?" That's an easy question for a real recruiter and a hard one for a scammer.

It runs on your own laptop with Gemma 3 4B through Ollama. Offer letters have your phone number, address and PAN on them, and I didn't want anyone pasting that into some website.

Demo

The first message is the one above: a Gmail address pretending to be Infosys, an interview on Telegram, and a "refundable" fee due in two hours. It flags all three, and the two-hour deadline too.

The second is a normal Infosys email that happens to say "Infosys never charges a registration fee". A plain keyword search would flag it for the word "fee". OfferProof doesn't. It also says Not verified, not Genuine. No message can prove an offer is real, so it never claims that.

(Gemma takes 15 to 30 seconds per message on my GTX 1650. I cut that wait out of the GIFs.)

Code

Surge77 / offerproof

Check a job offer for scam signs, locally, with an open-weight model.

OfferProof

Check a job offer for scam signs before you reply, pay, or share documents. It runs on your own computer with an open-weight model, so your offer letter, phone number and PAN never leave it.

Fake job offers mostly target people with little or no work experience. Most of them repeat a few tells a fee to "confirm your seat", an interview held over Telegram, a Gmail address claiming to be a large company. OfferProof looks for those tells and shows you the exact words that triggered each one.

$ offerproof check offer.txt
LIKELY SCAM: This message has clear signs of a job scam.

[severe] Personal email claiming to be Infosys
  "infosys.recruitment.cell@gmail.com"
  Large employers recruit from their own company domain, never from Gmail, Yahoo or Outlook.
  Ask them: Can you write to me from your official Infosys email address?

[severe] Asks you to pay money
  "Pay a refundable registration

…

View on GitHub

How I Built It

I didn't want the model deciding "scam or not". A 4B model will give you a confident answer either way, and you can't tell why it said it. So Gemma only reads the message. Plain code makes the call.

There are four parts:

Pattern rules in signals.yaml for known scam wording. They skip negated sentences, which is why the "never charges a fee" email comes through clean.
Domain checks in companies.yaml. If a message claims to be from TCS but comes from a Gmail address, or from something like tcs-careers.in, that gets flagged.
Gemma answers a few narrow questions. Does it ask for money? An OTP? Documents? How is the interview being done? Every answer has to come with a quote from the message, and if that quote isn't actually in the message, the answer gets thrown away.
A few lines of Python decide. Any severe sign means likely scam. Anything else is not verified.

Where it went wrong

I wrote 20 test messages, 12 scams and 8 genuine ones, and ran everything locally.

The first run caught all 12 scams. Looked great, until I noticed it had also flagged 3 of the 8 genuine messages.

That confused me, because I was already checking that Gemma's quotes existed in the message. They did. The problem was what it used them for. It called a "quick call" a chat-only interview. It called a rejection email a chat-only interview too. And it decided a HackerRank assessment was a task scam. Every quote was real. None of them had anything to do with the claim.

So a quote being in the message isn't enough, it has to be about the thing being claimed. Each signal now has a list of words its quote must contain. If Gemma says "interview only over chat", the quote has to mention Telegram, WhatsApp or chat:

def quote_supports(signal_id: str, quote: str) -> bool:
    """The quote must be about the claim, not just appear somewhere in the message."""
    evidence = load_signals()[signal_id].evidence
    return evidence is None or evidence.search(quote) is not None

I also spelled out in the prompt the things it kept getting wrong. Phone and video calls aren't chat-only. Coding tests aren't task scams. If a message doesn't say how the interview happens, the answer is "not mentioned".

After that:

Layer	Scams caught (of 12)	Genuine wrongly flagged (of 8)
Rules only	9	0
Model only	9	0
Combined	11	0

The one scam it still misses says the "training material costs 999". I could add a rule for it, but it's one message I wrote myself, and tuning rules until my own test set passes wouldn't prove much.

That's the real limitation right now: all 20 messages are mine. Next I want my friends to run it on messages they've actually received, and add those to the test set with names and numbers removed.

Why Does Open Innovation Matter?

For this project it's pretty practical.

I'd only trust a tool with my offer letter if the letter never leaves my laptop. That works because Gemma is open and small enough to run on my GTX 1650.

Scam scripts also change faster than one person can keep up with. The patterns are plain YAML, so if you've seen a scam OfferProof misses, adding it is a couple of lines and a test. CONTRIBUTING.md has the steps.

And you don't have to take my word for the numbers. The test messages and the script are in the repo. Run them yourself, or point OFFERPROOF_MODEL at a different model and see how it does.

Prize Categories

Best Use of Gemma. Gemma 3 4B does all the reading, locally through Ollama.

If someone has sent you one of these and you're in India: don't pay, don't share OTPs or documents, and report it at cybercrime.gov.in or call 1930.