Recently, Nithin Kamath, co-founder and CEO of Zerodha, said something that most Indians who use net banking had quietly felt but never clearly articulated. “I don’t use net banking apps on my phone because the mandatory permissions they ask for make no sense,” he wrote on X. “Why does a banking app need access to my SMS, phone, contacts, etc., in the name of security, when not seeking invasive device permissions is, in fact, the global benchmark for cybersecurity. This is called the Principle of Least Privilege (PoLP).“

It was a sentence that landed with the force of something that had been waiting to be said for a long time. Here was one of India’s most respected fintech founders — a man who built a brokerage trusted by millions of retail investors — publicly refusing to use Indian banking apps on his phone because the permissions they demand are not just unnecessary but, by his reading, antithetical to genuine security.

He also offered a pointed contrast: Kite, Zerodha’s own trading app, asks for zero permissions on mobile, and this is one of the big reasons why millions of people trust it. What enabled this, he noted, is SEBI’s mandatory strong two-factor authentication framework that strikes the right balance between security and privacy.

That contrast — between a fintech that asks for nothing and banks that demand everything — is the starting point for this article. But the full story is considerably more complex, more troubling, and more consequential than any single tweet can capture.

Part One — The Security Justification vs. The Privacy Reality: Are Indian Banks Using Your Data to Protect You or to Profile You?

To understand whether Indian banking apps are actually using their invasive permissions for the stated security purposes, you need to start from a place of genuine technical fairness — accepting the banks’ reasoning at face value and then examining whether it holds up.

The three most common permission justifications that Indian banking apps offer are SMS access for OTP reading, contact access for UPI payment shortcuts, and phone state access for device fingerprinting. Each of these, in isolation, sounds reasonable. OTPs are real security tools. Payment shortcuts are genuinely useful. Device fingerprinting is a legitimate fraud-prevention mechanism. The problem is not the stated purpose — it is the permissions required to achieve it.

Take SMS access first, because it is the most instructive case. When most Indian banking apps request access to your SMS inbox, they are requesting the READ_SMS permission under Android. This is problematic because this permission allows the app to read all other SMS messages, which may contain the user’s private information. It gives the banking app visibility into every message on your device — your salary credit alerts from other banks, your insurance renewal reminders, your investment platform notifications, your personal messages. The full financial and social texture of your life, delivered in plaintext, to a banking app that asked for it in the name of reading one six-digit code.

Here is what makes this technically indefensible rather than merely aggressive: the SMS Retriever API allows automatic SMS-based user verification in Android apps without requiring the user to manually type verification codes, and without requiring any extra app permissions. Google built this tool specifically to solve the OTP problem without requiring inbox access.

The SMS Retriever API is a tool provided by Android that allows your app to automatically receive verification codes sent via SMS, securely and without asking for SMS read permissions. It is not a new or experimental technology — from January 9, 2019, Google began removing apps from the Play Store with READ_SMS and CALL_LOG permissions if they could not explain the necessity, specifically because the use of those permissions for OTP verification is not secure and could expose user data.

That date is important. The privacy-respecting alternative to full SMS inbox access has been available for more than six years. The SMS Retriever API does not use READ_SMS and RECEIVE_SMS permission, safeguarding user SMS information, and increased security comes from eliminating manual OTP entry, which reduces the risk of phishing attacks and other forms of fraud. In other words, the privacy-first approach is not just less invasive — it is more secure. An app that reads only the OTP it is supposed to read cannot be exploited by malware to harvest other SMS content. An app with full READ_SMS access can be.

The documented permission requests of Indian banking apps reveal how far reality diverges from the technical minimum required. A MediaNama audit of major Indian banking apps found that all ten apps reviewed requested permission to precisely track a user via GPS, multiple apps including ICICI iMobile, Axis Mobile, State Bank Freedom, Bank of Baroda M-Connect, and Union Bank Mobile requested permission to read contacts data, several apps requested access to read call log information including phone number, duration and time of call, and HDFC’s app requested the ability to modify audio settings and pair with Bluetooth devices.

The audit also revealed something that Android’s own developer guidelines characterise with unusual candour: the record audio permission is classified by Android’s developer guide as having a “dangerous” protection level, meaning it “would give a requesting application access to private user data or control over the device that can negatively impact the user.”

The audit in question was conducted in 2016. The question that public interest demands we ask in 2026 — a full decade later — is how many of these permissions have been removed in the intervening years, given that the privacy-respecting technical alternatives have been widely available for most of that period, and given that Google Play now restricts the use of high-risk or sensitive permissions. The above pasted image describes that nothing much changed in a decade.

The absence of a comprehensive current audit of Indian banking app permissions is itself a regulatory failure, because without that data, no one — not the RBI, not the government, not the user — can make an informed assessment of whether the stated security justification actually maps to the permissions being requested.

What Nithin Kamath’s question implies, and what the technical evidence supports, is that for a significant number of the permissions Indian banking apps request, a safer alternative exists and is not being used. The question of why it is not being used — whether through inertia, incompetence, or something more deliberate — takes us directly into the second direction of this investigation.

Part Two — The Regulatory Vacuum: Why RBI Tells Banks to Be Secure But Nobody Tells Them to Be Private

India has built an increasingly sophisticated framework for banking security. The RBI’s guidelines on two-factor authentication, transaction monitoring, fraud prevention, and cybersecurity incident reporting represent years of considered policymaking. The results are visible: India’s UPI system is genuinely world-class, and the fraud prevention mechanisms built around it have kept losses far below what the transaction volumes would suggest. On security, India’s banking regulator has done serious work.

On privacy — specifically on what data a banking app is permitted to collect from a user’s device in the name of implementing that security — there is a regulatory vacuum so complete it is almost architectural. There is no RBI circular that limits which device permissions a banking app may request. There is no framework that requires a bank to demonstrate that each permission it requests is the minimum necessary to achieve a stated security function.

There is no audit requirement that compares the permissions requested by a bank’s app against the permissions that a technical reviewer would consider necessary. Security and privacy, which are presented to users as a single concern, are treated by India’s regulatory structure as completely separate domains — with one rigorously governed and the other essentially unregulated.

This asymmetry has a direct and concrete consequence for users. It means that a banking app can request READ_SMS access, justify it as necessary for OTP verification, and face no regulatory challenge — even though, as we have established, OTP verification can be performed without any SMS inbox access at all using tools that have been available for years. The user, confronted with a permission screen on their smartphone, has no way to know that the permission being requested exceeds what the security function actually requires. They click allow, because the alternative is not having access to their own bank account.

India’s data protection framework is now beginning to address this gap, but the timelines reveal the scale of the delay. India’s Ministry of Electronics and Information Technology finalised the Digital Personal Data Protection Act regulations on November 13, 2025, ending a more than two-year wait for the implementation of the country’s new data protection regime. The framework’s implementation is phased: the Data Protection Board of India was established with immediate effect from November 13, 2025, consent manager registration will open after twelve months in November 2026, and full substantive compliance — including all privacy notices, consent systems, and security safeguards — is mandatory only after eighteen months, with May 13, 2027 as the absolute deadline.

This means that as of March 18, 2026 — India’s banking apps operate in a world where the DPDP Act’s board exists but its substantive enforcement provisions are not yet in force. Banks are not yet legally obligated under the new framework to demonstrate that their data collection is minimally invasive, purpose-specific, or subject to explicit informed consent in the manner the Act will eventually require. They are, in a technical legal sense, in a compliance preparation period rather than a compliance enforcement period.

The contrast with the European framework is instructive. Under GDPR, which has been in active enforcement since May 2018, a banking app operating in the EU must justify each category of data it collects against a specific lawful basis, demonstrate that the collection is limited to what is necessary for the stated purpose — the principle of data minimisation, which maps directly onto the Principle of Least Privilege that Mr Kamath invoked — and provide genuinely granular, specific consent rather than the blanket “allow all permissions” model that Indian banking apps currently present.

An EU banking app that requested full SMS inbox access when the SMS Retriever API was available would face a legitimate challenge from a data protection authority. No equivalent challenge mechanism currently exists in India in operational form.

The DPDP Act, once fully implemented, would, perhaps, change this picture. The consent-centric framework under the DPDPA requires businesses to embed strong consent-management processes into their organisational architecture to ensure that consent obtained from data principals is free, specific, informed, unconditional, and unambiguous — pre-checked boxes or implied agreements are prohibited. Clicking “allow” on a banking app’s permissions screen, with no explanation of why each permission is needed and no ability to grant permissions selectively, is precisely the kind of blanket implied consent that the DPDP Act’s consent framework is designed to prohibit.

There is one further dimension of the regulatory picture that deserves attention. A recent PwC India survey found that only 16% of Indian consumers understand the Digital Personal Data Protection law, while more than half are unaware of their rights over personal data. The consent that Indian banking apps currently extract from users on permissions screens is not meaningful consent in any substantive sense, because it is given by people who have no framework for evaluating what they are consenting to, against an alternative of being locked out of their own finances. Informed consent requires both information and genuine choice. Indian banking app users currently have neither.

Part Three — The Convenience Trap: How Indian Banks Turned Security Theatre into a Data Harvesting Business Model

The first two parts of this investigation have dealt with what banking apps do and what the regulatory framework says about it. This part deals with the harder and more consequential question: Why, exactly, do Indian banks want this data, and what are they doing with the portion that exceeds any genuine security requirement?

To answer that question, you need to think carefully about what each category of over-collected data actually reveals. SMS access, as we have established, does far more than read an OTP. Your SMS inbox in 2026 is a near-complete financial biography. It contains alerts from every financial institution you deal with — your salary credits, your EMI deductions, your mutual fund NAV updates, your insurance renewal notices, your credit card statements. A bank with access to your SMS inbox knows your income, your liabilities, your investment behaviour, your insurance coverage, and your spending patterns at every institution other than itself. This is not a security dataset. It is a credit profiling dataset of extraordinary richness.

Contact access tells a different but equally revealing story. By tracking user activity, companies can build detailed behavioural profiles and serve more personalised ads, which significantly boosts advertising revenue. Your contact list contains your social and professional network — your employer, your family members, your business associates, the people you transact with regularly. For a bank building a credit model, your network is a significant predictor of your creditworthiness, spending patterns, and risk profile. Social network analysis has become a standard tool in alternative credit scoring, and access to a customer’s contact list provides exactly the graph data that such models require.

This matters because the value of this data is not theoretical. It is embedded in the financial products that banks cross-sell through their apps. Finance apps are full of dark patterns, more than almost any other category, and a 2024 study by ASCI Academy and design firm Parallel HQ found that 52 of India’s 53 top finance apps used at least one such tactic, with many showing five or more. The dark patterns documented include loan offers embedded alongside routine banking screens, subtle prompts toward investment products, and difficult-to-find exit routes from promotional screens.

The data harvested through invasive permissions is the informational foundation on which these dark patterns are built — it is what allows the app to know that you received a salary credit three days ago, that your mutual fund portfolio has been underperforming, and that you have three contacts who recently received loan approval notifications, all of which are triggers for a precisely timed personal loan offer presented at the moment you are most likely to accept it.

Kamath explained that this data is typically used for targeted advertising — by tracking user activity, companies can build detailed behavioural profiles and serve more personalised ads, significantly boosting advertising revenue. He went as far as to note that some apps monitor what users do across other apps, not just their own, and called this “harvesting your most personal data without your consent and selling it to companies for shady targeting purposes.”

The word “security” in this context functions as what might fairly be called an epistemic shield — a term that is socially and emotionally unchallengeable, which is precisely what makes it so useful as a justification for practices that would be questioned sharply if described honestly. Nobody argues against security. Parents want their savings account to be secure. The elderly want their pension account to be secure. First-generation digital banking users, who are disproportionately the targets of fraud and are aware of it, want to do everything possible to keep their money safe.

When a banking app says it needs access to your SMS and contacts for security, the emotional framing makes the requested permissions feel like protective measures rather than what they functionally are — data collection permissions with security as the pretext.

This framing also systematically disadvantages the user in any negotiation about consent. In a normal commercial relationship, a company that wanted to profile you for cross-selling purposes would have to ask your permission to do so explicitly, in terms that made the commercial purpose clear, and you would have a genuine choice about whether to grant it. Presented instead as a security requirement — and bundled into a permissions screen that must be approved before you can access your account — the same data collection happens without any of those safeguards. The “consent” that results is neither informed nor freely given in any meaningful sense of those words.

The contrast that Kamath’s Zerodha provides is worth dwelling on, because it demonstrates directly that security and privacy are not in tension in the way Indian banks implicitly claim. Zerodha remains the only major broker in India that doesn’t seek invasive app permissions or use user-tracking tools, with Kamath attributing this to the philosophy: “Don’t do unto others what you don’t want done unto you.” Zerodha’s security, as Kamath has explained, rests on SEBI’s robust two-factor authentication framework — which delivers genuine security outcomes without requiring any data beyond what the authentication function itself needs.

The Principle of Least Privilege, in other words, is not an obstacle to security. It is a demonstration that security and privacy can be achieved simultaneously, when the institutional will to do so exists.

What Must Happen Now — A Public Interest Call to Action

The three directions explored in this article converge on a single, uncomfortable conclusion: Indian banking apps are collecting far more data from users’ devices than any genuine security function requires, they are doing so under a regulatory framework that has so far failed to impose the privacy constraints that would force them to use less invasive technical alternatives, and the data they collect in excess of security requirements serves commercial profiling purposes that are never disclosed to users in the terms those users would recognise.

This is not a marginal or theoretical public interest concern. India had over 340 million mobile banking users as of 2025, and that number is growing rapidly as first-generation digital banking adopters in Tier-2 and Tier-3 cities come online. These are often precisely the users who are least equipped to evaluate what a banking app’s permission screen is asking them to consent to, and who face the greatest financial vulnerability if the data harvested through those permissions is misused, leaked, or sold.

The remedies are not technically complex. They are institutionally complex — which is a different and more tractable problem. The RBI should issue a circular requiring banking apps to document the security necessity of each device permission they request, and prohibiting permissions where a less invasive alternative achieves the same security function.

The DPDP Act’s enforcement provisions should be applied to banking apps as a priority sector once they come into force, given the sensitivity of financial data and the scale of the user base affected. And India’s banking customers deserve, at minimum, a publicly available audit of what permissions each major banking app requests and why — so that the next time someone clicks “allow” on a permissions screen, they are doing so with genuine knowledge of what they are agreeing to rather than the false choice between privacy and access to their own money.

Nithin Kamath’s question, asked from a position of unusual expertise and institutional credibility, deserves a serious answer from the institutions responsible for governing India’s financial system. The answer is not “security requires it.” The answer that the evidence demands is: security does not require it, a safer alternative exists, and the question of why that alternative is not being used is one that India’s 340 million mobile banking users have every right to ask — and to expect their regulators to answer.