You can track your spending automatically without giving any app access to your text messages. SMS is just one source of transaction data — your bank emails you the same alerts, and an app can read those instead. That distinction matters more than it sounds, because SMS permission on Android is not scoped to your bank: it grants the whole inbox, one-time passwords included. Google itself treats it as highly sensitive and restricts which apps may request it at all.
When a budgeting app asks for SMS access, the request in your head is “read my bank alerts.” The request the operating system grants is “read my messages.” There is no middle setting. Android does not let you approve access to texts from HDFC and withhold access to everything else, because permissions are granted per-category, not per-sender.
So the actual scope includes:
None of that is an accusation against any particular app. Most apps asking for it are doing exactly what they say. The point is narrower and harder to argue with: you are trusting a promise you have no way to verify, and the thing you are staking on it includes the codes that protect your bank accounts.
The safest permission is the one an app never needs. If a product can deliver the same automation without touching your inbox, that isn’t a marketing difference — it removes the question entirely.
This isn’t a fringe worry. Google restructured Play policy around it. Under the current rules, SMS and Call Log permissions sit in a restricted category: an app generally must be the device’s default SMS, Phone or Assistant handler to request them, use must be limited to documented core functionality essential to the app’s primary purpose, and anything outside the pre-approved list requires a declaration reviewed by Google. Apps that don’t meet the policy, or that skip the declaration, can be removed from the Play Store.
Read that back with a budgeting app in mind. A finance tracker is not your default messaging app, so the ordinary route to that permission is closed to it — it needs a specifically approved exception. Some do obtain one. But the policy exists because Google concluded that handing arbitrary apps a full message inbox was not a reasonable default, and an approved exception doesn’t shrink what the permission grants once you tap accept.
None of which means every app asking for it is acting in bad faith. If you are weighing up one that does, there is a five-step way to judge whether granting it is safe rather than guessing.
It also explains something people notice and misread: an Indian expense tracker whose automation is SMS-based has a permanent platform problem on iPhone, where the API does not exist in any form. That’s a separate argument, covered on expense trackers for iPhone in India.
If not SMS, then what? These are the realistic ways an app can learn that you spent money, and what each one costs you in access.
| Method | Automatic | What you hand over | Sees your OTPs |
|---|---|---|---|
| SMS parsing | Yes | Your entire message inbox | Yes |
| Notification reading | Yes | Every notification from every app | Often |
| Net-banking login | Yes | Bank credentials | Effectively yes |
| Account Aggregator | Yes | Regulated, revocable consent to account data | No |
| Email alerts (read-only) | Yes | Read-only access to your mail | No |
| Statement import | No | Nothing ongoing | No |
| Manual entry | No | Nothing | No |
The Account Aggregator framework deserves a fair word here: it is regulated, consent-based, revocable, and genuinely better designed than screen-scraping a login. Its trade-offs are coverage and breadth — not every institution is live on it, and the consent covers account data rather than a single alert.
Email parsing sits in a useful spot on that table. It is fully automatic, it never sees a one-time password, and it needs no credentials. What it gives up is completeness: it can only see accounts that actually email you.
TLDR Money reads the transaction alerts already in your Gmail — UPI debits, card spends, salary credits — and categorises each one automatically, backfilling three months of history the moment you connect. It does not ask for SMS permission, does not ask for your net-banking credentials, and does not see your OTPs.
Access is read-only, and that’s a structural limit rather than a policy we could quietly change: moving money, placing a trade and opening an account are not operations that exist within a mail scope. You can revoke the connection whenever you like from your Google Account permissions page, without opening our app at all.
Your financial history also isn’t warehoused on our servers — there is no central store of your spending on our side to breach or monetise, which is a design decision described on the security page. Your rights over the data, and how to exercise them, are in the privacy policy.
Yes. SMS is one source of transaction data, not the only one. Your bank and card issuer also email transaction alerts, and an app can read those instead — which gives you automatic categorisation without any access to your text messages. Other routes exist too: an Account Aggregator or bank connection, or importing statements. Only manual entry requires no data access at all, and almost nobody keeps that up.
Your entire message inbox, not just the bank alerts. That includes one-time passwords, messages from your doctor or lawyer, delivery codes, personal conversations, and anything else that arrives by text. Android has no way to grant access to only the messages from your bank. The permission is all-or-nothing, which is why the scope is so much wider than the stated purpose.
It depends entirely on the company, and you cannot verify it from the outside. Google treats SMS as highly sensitive: under Play policy an app generally must be the device’s default SMS handler, or hold an approved declared exception, to request the permission at all, and non-compliant apps can be removed from the Play Store. The permission also exposes your one-time passwords, which is the specific reason security guidance tells people to be careful with it. If an app can do its job without the permission, that is strictly safer than trusting that it will behave.
Because in India nearly every UPI debit, card spend and salary credit generates a text message, in a predictable format, from a small set of senders. That made the SMS inbox the cheapest reliable transaction feed in the country — no bank partnership, no integration, no approval needed. It is a sensible engineering choice from the app’s side. It just means the user carries the privacy cost of the shortcut.
No. TLDR Money reads transaction alerts in your Gmail with read-only access, so it never requests SMS access, never asks for your net-banking credentials, and never sees your one-time passwords. Read-only mail access also cannot move money, place a trade or open an account — those operations do not exist in a mail scope. You can revoke the connection at any time from your Google Account permissions page.
Reads your Gmail alerts, read-only. Never your texts, never your OTPs, never your bank login.
Join the waitlistWe are opening seats in batches. No spam, ever.
Platform and store-policy behaviour described here reflects Android and Google Play as of August 2026 and can change. This is an explanation of how permissions and transaction capture work, not advice about your own money.