What your banking app collects in the background

Open your banking app’s permission list sometime and actually read it. Camera, location, contacts, phone state, sometimes notification access. Most people tap “allow” once during setup and never think about it again, which is a reasonable response to a dialog box that pops up while you’re just trying to check a balance. But it’s worth understanding what’s happening underneath, because a banking app is one of the few things on your phone that’s simultaneously trying to stop fraud and running the same kind of SDK stack you’d find in a mobile game.

Neither of those things is a conspiracy on its own. Fraud detection genuinely needs signal, and banks have concrete incentives, chargebacks, regulatory exposure, account takeover losses, to collect it. But “we need this to catch fraud” and “we’re also handing pieces of this to a handful of analytics and marketing vendors” aren’t mutually exclusive, and the app rarely tells you which request belongs to which goal.

Device fingerprinting is the foundation

Before your banking app asks for a single permission, it’s already building a profile of the device you’re using. This isn’t hidden or exotic. It’s standard mobile engineering: OS version, screen resolution, time zone, battery state, installed fonts, sensor list, and whether the device shows signs of being rooted (Android) or jailbroken (iOS). Apple’s DeviceCheck and Google’s Play Integrity API exist specifically so apps like this can ask the OS, “is this a real, unmodified device, or an emulator someone’s using to automate fraud,” and get a cryptographically backed answer.

That check runs every time you open the app, often before you’ve logged in. It’s the reason banking apps tend to refuse to run on rooted phones or in emulators at all. From a fraud standpoint this makes sense: automated account takeover attacks are frequently run from emulator farms, and a rooted device is easier to tamper with at runtime. The tradeoff is that the same fingerprint data that flags a fraud ring is also, structurally, the same kind of data an ad SDK would want for attribution. The bank isn’t necessarily selling it, but the signal exists in a form that’s reusable.

The permissions you already granted

Each permission request usually has a legible, functional reason, even if the app doesn’t explain it:

• Camera. is for check deposit and document capture during identity verification (photographing your ID for KYC checks).
• Contacts. is almost always for peer-to-peer transfers, so the app can suggest “send money to [name]” instead of making you type an account number.
• Location. is used to cross-reference a card swipe or app login against where your phone physically is. A purchase in a city where your phone isn’t present is a classic fraud signal.
• SMS read. (historically more common on Android before Google tightened this permission category) let apps auto-fill one-time passcodes instead of you switching apps to copy a code.

The functional justification is real. The problem is granularity. iOS’s App Tracking Transparency prompt and Android’s runtime permission model both give you a binary choice, allow or deny, without distinguishing “use my location to verify this login” from “use my location for marketing analytics.” Some banking apps ask for “always allow” location rather than “only while using the app,” which is a meaningfully bigger grant than fraud detection requires, since fraud checks only need location at the moment of a transaction, not continuously.

Behavioral biometrics: the part nobody explains

This is the layer most people have never heard of, and it doesn’t show up as a permission at all. Many banking apps, particularly ones from larger institutions, continuously sample how you interact with the screen: typing rhythm, how hard and where you tap, scroll speed, and how you physically hold the phone, measured through the accelerometer and gyroscope that are already active for normal app orientation.

This is called behavioral biometrics, and it works because your typing cadence and hand tremor are surprisingly consistent and hard for someone else to replicate, even if they’ve stolen your password. The app builds a baseline of “this is how Xavier holds and types on this phone” and flags sessions that deviate from it, sometimes triggering a step-up authentication challenge without ever telling you why. Functionally, this is closer to a lock than to surveillance in the marketing sense, it exists to catch account takeover, not to profile you for ads. But it’s still continuous data collection running whenever the app is open, using sensors you never explicitly granted permission for, because motion sensors on both major mobile OSes generally don’t require a permission prompt the way camera or location do.

Third-party SDKs riding along

Here’s where the “fraud prevention” justification gets thinner. Almost every banking app is built on top of a stack of third-party software development kits: crash reporting (so engineers know when the app breaks), analytics (so product teams know which screens people use), and sometimes marketing attribution SDKs that measure whether an ad campaign led to someone downloading and opening the app.

These SDKs run inside the app with the same access the app itself has, unless the developer has explicitly sandboxed them, which most consumer apps don’t bother to do. A crash reporting SDK doesn’t need your transaction history, but it’s technically capable of seeing whatever the app process can see if it’s not carefully scoped. This is less “your bank is spying on you” and more “modern app development relies on outside vendors, and each one is a separate destination for whatever data flows through it.” The bank’s own privacy policy covers what the bank does with your data. It rarely gives you a clear, current list of every SDK vendor bundled into the build, and that list changes between app versions without you being notified.

Certificate pinning cuts both ways

One more piece worth understanding: most banking apps use certificate pinning, a technique where the app only trusts a specific, hardcoded certificate for its own servers rather than trusting any certificate your device considers valid. This is a genuinely good security practice. It stops a whole class of attack where someone intercepts your connection using a fraudulent certificate, including attacks that would otherwise work over compromised public WiFi.

The side effect is that it also makes it much harder for you to inspect your own app’s network traffic, the same technique researchers use to audit what an app is actually sending. Pinning isn’t there to hide data collection from you specifically, but it does mean that verifying what your own banking app transmits, and to whom, isn’t something you can casually check the way you could with a website in a browser.

Fraud prevention or monetization: usually both, unevenly

It’s tempting to pick a side here, either “this is all necessary security” or “this is all surveillance capitalism wearing a fraud badge.” Neither framing survives contact with how these systems are actually built. Fraud teams and growth or marketing teams inside the same bank often use overlapping infrastructure, because building separate data pipelines for each is expensive, and a device fingerprint or app-open event is useful to both. The honest description is that the same signal frequently serves two masters, and the ratio between them isn’t something the app discloses.

What’s actually reasonable to do about it

There’s no setting that makes a banking app collect nothing, and that’s not really the goal, since some of this collection is what keeps your account from getting drained by someone else. A few things are worth doing anyway:

Review permissions after setup, not just during it. On both iOS and Android you can downgrade location from “always” to “while using the app” for banking apps specifically, which limits collection to moments you’re actually interacting with your account rather than continuously.

Keep the app itself, and your OS, updated. A meaningful share of what banking apps ask for, root and jailbreak detection especially, exists to catch outdated or tampered environments, and staying current reduces false flags against your own account.

Don’t assume a VPN or a privacy browser changes anything here. Banking apps run their own encrypted, pinned connections regardless of your network, and behavioral or device-level collection happens on the device itself, not in transit. No single tool sits between you and this data collection; it’s built into how the app functions.

If a specific data flow bothers you, your bank’s privacy policy is the actual authoritative source on what they do with what they collect, and it’s worth reading the section on “service providers” or “third parties” rather than the marketing summary at the top.

None of this is about hiding from your bank. They need enough of your data to actually serve you and to make good on fraud protection promises that benefit you directly. The more useful question isn’t “how do I stop this app from collecting anything,” it’s “which of these requests are doing something for me, and which ones are just along for the ride.”

If you want more breakdowns like this, on what apps actually do with the access you grant them, you can find the rest of our explainers on the homepage.