Open the SMS app on almost any phone in India and scroll. There is a near-complete record of your money sitting in there — every UPI debit, every salary credit, every EMI auto-debit, every refund. The information is already on your device. The hard problem is not collecting it, it is understanding it without violating the trust of the person whose phone it lives on.
That is the problem Trenziq set out to solve: take the messy, half-structured, sender-fragmented stream of financial SMS that arrives on a typical Indian smartphone, and produce a clean, queryable, encrypted ledger — entirely on-device. No proxy server. No "anonymous telemetry". No cloud parser. Just CPU cycles and storage that already belong to you.
This piece walks through how that pipeline actually works. If you are an engineer evaluating an offline-first architecture, or a user who wants to understand what happens between the moment a transaction SMS arrives and the moment it shows up on the dashboard, this is the map.
Why bank SMS is the right primary signal
You could build a personal-finance app around screen-scraping bank portals. You could ask for net-banking credentials. You could integrate with account-aggregator APIs. We thought about all of them. Each one trades a tiny amount of convenience for a large amount of attack surface.
SMS, by contrast, has three properties that make it uniquely well-suited to a privacy-first finance app:
- It is already on the device. Banks and PSPs have spent two decades pushing transaction alerts over SMS because regulators effectively mandated it. The data is local, the moment it lands.
- It is read-only at the bank's end. The app never gains the ability to move money. It only observes alerts after the fact.
- It is opt-in. On modern Android, SMS permissions are a deliberate, scary-looking dialog. There is no surprise here — if you grant access, you know you did.
So the design constraint becomes clear: read the SMS inbox locally, do everything else locally, and persist only the structured ledger — never the raw, decrypted message — in a place an attacker cannot read.
Layer one: the parser engine
Indian financial SMS is, charitably, an oral tradition. Every bank — and every payment gateway, and every NBFC — has its own templating system, its own preferred currency formatting, its own conventions for masking account numbers. There is no standard, only a series of strong defaults that you discover by reading a few thousand of them.
Trenziq's parser is a hand-tuned cascade of regular expressions grouped by intent: debit alerts, credit alerts, OTPs to ignore, EMI reminders, balance enquiries, refund notifications, and so on. Each pattern is paired with a small extractor: a function that, once a match is confirmed, pulls out the amount, currency, masked account suffix, merchant or counterparty hint, reference number, timestamp, and the "direction" of the transaction.
Two design notes are worth pulling out:
- Patterns are versioned. When a bank changes its template (and they do, quietly, every quarter), we don't lose old transactions. We add the new pattern alongside the old one.
- The parser is a pure function. The raw SMS goes in, a structured candidate transaction comes out. No I/O. No network. No analytics. This makes it trivially testable — and trivially auditable.
Layer two: heuristic correction
If you only ran regex, you would catch maybe 80% of transactions cleanly and produce confidently wrong answers on the rest. That is not good enough for a ledger you are meant to trust.
The second layer is a set of small, deterministic heuristics that look at the candidate transaction in context and quietly fix the obvious mistakes. A few examples:
- If the parser extracted an amount but missed the currency, but the previous five messages from the same sender all used
INR, the heuristic infersINR. - If a UPI handle looks like a merchant code we have seen labelled in the last 90 days, we propagate the better label.
- If a debit is followed within 30 seconds by a credit of the exact same amount on the same account, the heuristic flags it as a likely reversal — not two transactions.
These rules are intentionally boring. They are not a model. They are not "AI". They are the kind of common-sense corrections a careful human would do, codified once and re-run for free. If you want to understand the philosophy behind keeping the smart parts dumb, the companion piece on why offline-first finance apps matter in 2026 goes deeper.
Layer three: confidence scoring
Every candidate transaction leaves layer two with a score in the interval [0.0, 1.0]. The score is built additively from a handful of signals: did the pattern match cleanly? Was the amount extracted unambiguously? Did the currency, account suffix and counterparty all show up where we expected? Did any heuristic have to correct a value, and if so by how much?
Transactions above a high threshold (currently 0.85) are persisted directly. Transactions in the middle band (0.60–0.85) are persisted but tagged for soft review — they will show up in the app, but with a small "verify" affordance. Anything below 0.60 is held in a triage queue that you can open from the settings screen.
Why we don't ship an LLM in the app
The temptation to bolt a small language model onto SMS parsing is real, but the cost-benefit is brutal: every megabyte of model weights bloats the install, every inference burns battery, and every "fix" the model makes is harder to audit than a regex. For the 99% case, careful pattern engineering still beats neural sprinkles — and it stays explainable.
Layer four: the self-healing ledger
SMS is not a reliable transport. Messages get lost during cell-tower switches, get delayed for hours, sometimes arrive out of order. A ledger that assumed otherwise would slowly drift away from reality.
So Trenziq's final layer is a reconciler. It walks the ordered chain of transactions per account, watches the running balance the bank itself reports inside the SMS, and flags any discontinuity. If your last alert said the balance was ₹12,540, the next alert reports a ₹500 debit, and the new balance is ₹11,040 — that is a missing ₹1,000 transaction. The reconciler doesn't fabricate it; it tells the UI to ask you whether you remember anything that fits that gap.
This is the part of the system most users will never consciously notice, and that is exactly the goal: a ledger that quietly notices its own holes is a ledger you can rely on for budgeting. We dig into the SMS formats themselves in the UPI / card / bank SMS field guide.
Where the data actually lives
Every parsed transaction lands in a SQLCipher-encrypted SQLite database. The encryption key is held in the Android Keystore — a hardware-backed secret store on modern devices. The raw SMS body is processed in memory and discarded; what is persisted is the structured row, and even that row is encrypted at rest.
If somebody steals your unlocked phone they can, of course, open the app and see your ledger. We are not pretending otherwise. But anybody who pulls the database file off a locked device gets ciphertext with no usable key. That is a meaningfully different threat model from a cloud finance app, where a single backend breach exposes a million ledgers at once. The fraud-detection playbook builds on this — local data + fast alerts is a surprisingly strong combination.
What we deliberately don't do
It is sometimes easier to describe a system by what it refuses. Trenziq's SMS pipeline:
- Never uploads SMS — raw, hashed, summarised or otherwise.
- Never sends "anonymous" parser-failure samples back to a server, because there is no server.
- Never reads non-financial SMS. Marketing, OTPs, two-factor codes and personal messages are filtered out at the senderID level before parsing even begins.
- Never asks for INTERNET permission for its core flow. Optional encrypted backup is a separate, explicit, off-by-default feature.
What this buys you, in practice
You get a finance app that boots in under a second, works on a flight, doesn't degrade when your network is patchy, and cannot leak your salary to an ad network because it has nowhere to send it. The trade-off is honest: the parsing is good but not magical, occasionally you will help label a low-confidence transaction, and the very first sync (when the app reads your historical inbox) takes a moment.
That trade-off, for us, is the entire point. A finance app you do not have to trust is a much better finance app than one you are forced to.
Try it yourself
Trenziq is free on the Play Store — no subscriptions, no upsell, no account required for core features. The whole pipeline above runs the moment you grant SMS permission. Install on Android →
A note on the team behind this
Trenziq is built by VoBot Developers, an independent product studio that also ships work for partners across categories — premium lifestyle goods at IBULUXE, healthcare with Plasma Biotech, education and social-impact programs through the Jigyasa Foundation, and hospitality at PGH. The same engineering values — minimise the data you collect, ship things that work offline, treat the user as the customer — run through all of them.