Indian financial SMS is a genre of writing in its own right. It has conventions, dialects, in-jokes, and bizarre exceptions. If you've ever tried to mentally scroll through a year of bank messages to estimate your spend, you already know the shape of the problem: the information is all there, but in seventy slightly-different formats, scattered across a dozen senders.
This piece is a tour of the formats themselves. Some of it will be familiar to engineers building parsers; most of it is useful to any user who wants to understand what their finance app is doing for them.
The canonical templates
Despite all the variation, there are surprisingly few kinds of financial SMS in regular use. Recognising the kind is most of the parsing battle.
| Kind | Example shape | What it actually means |
|---|---|---|
| Debit alert | "Rs.500.00 debited from a/c **1234 on 14-MAY at MERCHANT. Avl bal Rs.12,540" | Money left your account. |
| Credit alert | "Rs.50,000 credited to a/c **1234 on 30-APR by NEFT/REF-XXX. Avl bal Rs.62,540" | Money arrived in your account. |
| UPI debit | "Rs.250 paid from a/c **5678 to vpa@bank · UPI ref XXXX" | UPI outflow. |
| UPI credit | "You have received Rs.500 from VPA@bank · UPI ref XXXX" | UPI inflow. |
| Card transaction | "Card **1234 used for Rs.X at MERCHANT on DD-MMM" | Card debit (CP or CNP). |
| Auto-debit / mandate | "Rs.X auto-debited from a/c **1234 towards EMI/SIP" | Recurring outflow. |
| Refund / reversal | "Rs.X reversed to a/c **1234 ref XXX" | Counter to a previous debit. |
| OTP / informational | "OTP is 123456 — do not share." | Not a transaction. Ignore. |
The first parser layer in Trenziq is essentially a type-classifier, deciding which of these eight buckets an incoming message belongs to before any field-level extraction begins. The SMS pipeline article covers what happens after that.
Why some banks are easier to parse than others
There's a quiet hierarchy in Indian financial SMS quality. A few patterns recur:
- Older PSU banks have stable, simple templates that haven't changed in years. They parse cleanly with a single, well-tuned regex.
- Newer private banks tend to A/B-test their alerts. The same bank may send three different formats in a month — usually for the same underlying transaction kind.
- Payment apps and wallets often layer their own SMS on top of the bank's, leading to duplicate alerts that look superficially similar but report different "balances" (wallet vs. bank account).
- Cards from international issuers sometimes mix currency formats inside the same message — useful for the user, painful for parsing.
The quirks that bite
Once you start parsing tens of millions of SMS in aggregate, you start noticing edge cases that single-bank developers usually never see. A few favourites:
Currency-symbol drift
Within a single bank, you'll see Rs., Rs, INR, ₹, sometimes rs. in lowercase. The parser has to treat them all as the same currency without being fooled by edge cases (a merchant called "Rs Computers" once caused a memorable bug).
Amount formats
Indian numbering is a special challenge. 1,00,000 (one lakh) is identical in meaning to 100000, but a naive parser written for Western locales might read it as a hundred. Throw in 1.5 L, 1.5 Lakh, 1.5k and you have a real spectrum to handle.
Date ambiguity
Banks send dates in DD-MM-YY, DD/MM/YYYY, DD-MMM-YYYY, YYYY-MM-DD and the occasional "Today" / "Yesterday". Combining the SMS timestamp with the embedded date string usually disambiguates, but not always.
Merchant strings are unstructured prose
A debit at the same Big Bazaar can land as BIG BAZAAR, BIGBAZAAR, FUTUREGROUP RETAIL, or BB MUMBAI depending on the acquirer. The parser ships the raw merchant string into the categoriser, which uses fuzzy matching and per-user learning to fold them.
Balance reporting inconsistency
Some banks report "available balance" inside the SMS, some don't. Some banks include credit-card available limits in the same field used for savings balance. The reconciler (covered in the pipeline article) treats unverified balances cautiously rather than as ground truth.
Why this matters for budgeting
Almost every common budgeting failure has a root cause in either missed transactions or mis-categorised ones. A parser that handles the quirks above accurately removes most of that friction — which is why we spend disproportionate time on it. The budgeting framework piece assumes the parser is doing this work in the background.
What changes year over year
Indian financial messaging is, in 2026, in the middle of three slow transitions:
- UPI's share of total transaction SMS has crossed any reasonable threshold of "dominant" — the parser now spends most of its time on UPI shapes.
- Header-based sender IDs have largely stabilised, which makes spam-filtering at the senderID level meaningfully more reliable than five years ago.
- Templated alerts under RBI / TRAI compliance frameworks are slowly converging — the variance between large banks is, mercifully, narrower than it was.
Even with that convergence, the long tail of co-operative banks, NBFCs, regional banks and wallet providers ensures the parser will always have new cases to handle. The bet we make is that this work belongs on the device, where the user can see what's being parsed and correct it.
What this means for the user
Most users will never see any of this complexity. The Trenziq home dashboard just shows a clean list of transactions, correctly classified, with the right amounts. That's the goal — the field guide above exists so that on the day a transaction looks wrong, you have the vocabulary to understand why.
If you want the wider context for why this work is happening on the device in the first place, the fraud playbook and the 2026 financial health checklist both build on the assumption that the inbox is the highest-fidelity source of truth you have about your money — which it is, if you treat it correctly.
From the network: Trenziq is built independently by VoBot Developers, alongside work for IBULUXE (premium essentials), Plasma Biotech (pharma), the Jigyasa Foundation (NGO / CSR) and PGH (hospitality).