SMS permission is not scoped to bank messages. Granting it gives an app the ability to read every text that arrives, including one-time passwords, personal messages and anything else sent to that number — because Android grants access to the message store, not to a sender list. Google has narrowed who may request it. The practical question is no longer whether an app can ask, but whether it needs to at all.
The mental model most people have is wrong in a specific way. Granting SMS access to a budgeting app feels like showing a colleague one page of a notebook. It is closer to handing over the notebook.
Android permissions are granted per capability, not per counterparty. There is no mechanism by which you can grant read access to messages from your bank and withhold it from everything else. The app receives the ability to read the message store, and what it chooses to do inside that store is its own decision. An app that only ever parses bank alerts and an app that reads everything request identical permission and produce an identical prompt.
What sits in that store on a typical Indian phone: bank and card alerts, one-time passwords for banking, payments, email and government services, delivery and travel codes, and personal messages. The OTPs are the part worth pausing on, because they are the second factor protecting accounts whose first factor is a password that may have leaked elsewhere.
The risk is not that a budgeting app will drain your account. It is that a capability with no upper bound has been granted for a benefit with a narrow one — and that the same result is obtainable another way.
Google Play's policy on SMS and Call Log permission groups restricts those permissions to apps that are the user's default handler for SMS, phone or assistant, and limits their use to functionality that is core to the app's stated purpose. Android's developer documentation on default handlers describes the same constraint from the engineering side.
An expense tracker is not a messaging app. It does not become your default SMS handler, so under the current policy it does not meet the bar for requesting the permission at all. Google's broader guidance on permissions and APIs that access sensitive information sets out the same principle generally: request the narrowest access that supports the feature, and use a less permissioned alternative where one exists.
For the common case of reading a single verification code, Google provides exactly that alternative — the SMS Retriever API, which hands the app one matching message without granting access to the inbox. Its existence is the clearest statement of intent available: the platform considers full inbox access unjustified even for the use case that most obviously seems to need it.
Assume the goal is a complete monthly spending record across two cards and one bank account. Assume every one of those institutions sends both SMS and email alerts, which is typical. Compare what each route requires against what it returns.
| Method | Access granted | Blast radius if misused | Result |
|---|---|---|---|
| SMS inbox parsing | Every message on the device | OTPs, personal messages, all senders | Complete record |
| Bank login sharing | Credentials to the account itself | Full account access | Complete record |
| Email alert parsing, read-only | Messages in one mailbox, revocable | Mail contents; no ability to move money | Complete record |
| Manual entry | None | None | Incomplete in practice |
The first three rows produce the same output. They differ only in what was surrendered to get it. When two methods deliver an identical result and one requires materially less access, the more permissive one is not a trade-off — it is simply the worse option.
Email access is not zero-risk, and it would be dishonest to present it that way. A mailbox contains a great deal beyond bank alerts. The relevant differences are that it is read-only rather than transactional, scoped to one account rather than the whole device, revocable from your own account settings at any moment, and it never contains the second factor protecting your bank, because banks send OTPs by SMS.
One clarification, because the two get conflated: an app displaying a notification you received is not the same as an app reading your message store. Notification access is its own separate permission with its own separate prompt, and neither implies the other.
Is it safe? The capability is broad enough that the answer depends entirely on the operator, and you cannot verify an operator's conduct from a store listing. That would be an uncomfortable position if the permission were necessary. It is not. Every alert an expense app wants from SMS also arrives by email, where access is read-only, revocable, and does not include the codes protecting your accounts — which is the reasoning behind automatic expense tracking that never asks for SMS, and it works identically on an iPhone, where the SMS route does not exist at all.
Yes. The permission is granted per message store, not per sender, so an app holding it can read every message that arrives — including one-time passwords from banks, payment services and any other account that verifies by SMS. This is the single strongest reason to treat the request seriously. It does not mean a given app abuses it, but the capability is there whether the app uses it or not.
It means it passed review, which is a lower bar than an audit. Google requires a declaration explaining why the permission is needed and restricts it to apps that are the default SMS, phone or assistant handler with the use tied to core functionality. Review checks the stated justification against policy. It does not continuously verify what the app does with the data afterwards.
Ask what the app would lose without it, whether the business model depends on data rather than a fee, and whether the same result is available another way. If tracking is possible from email alerts, SMS access buys convenience rather than capability. An app that cannot explain why the alternative does not work is asking for more access than its function requires.
On Android, open Settings, then Privacy or Security, then Permission manager, and select SMS to see every app currently holding it. Access can be revoked there per app. Revoking stops future reads but does not delete anything already collected, so for an app you no longer trust, request deletion of your data and remove the app rather than only withdrawing the permission.
Forwarding is narrower than SMS access but worse than read-only mail access. A forwarding rule sends copies of matching mail to an address someone else controls, and those copies sit outside your account permanently. Read-only access to your own mailbox leaves the mail where it is and can be revoked from your account settings at any time, which forwarding to a third party cannot.
TLDR Money reads transaction alerts from Gmail with read-only access you can revoke from your Google account at any time. No SMS permission, no bank login, no credentials to hand over.
Join the waitlistNo spam, ever.
This is an explanation, not advice about your money. TLDR Money is not a registered investment adviser and earns no commission on any product mentioned. Figures are illustrative; your own numbers, taxes and circumstances will differ.