79% vs 51%: Independent Neobanks Lag on App Security

Neobanks underperform traditional banks on mobile app security in our 2026 study. For independent neobanks, the margin is substantial: 79.3% of their apps carry at least one high or critical finding, against 51.2% of traditional-bank apps. That is a gap of 28.1 percentage points.

The banks built around an app should have every reason to get that app right. Yet independent neobanks ship embedded credentials more than twice as often as traditional banks, even while leading them on passkeys and app attestation. Modern security features coexist with basic weaknesses.

Those are findings from Ostorlab's Mobile Banking App Security Report 2026, covering 2,686 apps from 487 banks in 64 countries. The sharpest divide is between independent neobanks and everyone else.

The gap is 28 points. Ownership matters.

Grouping all neobanks together hides the story. Across both types, 61.1% of neobank apps have a high or critical finding. Split them by ownership and two very different pictures emerge:

Bank-owned neobanks look much like their parent institutions. Independent neobanks account for the gap.

The independent group is small: 29 apps from 10 banks, with roughly a third of the apps from one bank. The report finds that the gap persists when each bank is weighted equally and when accounting for the platform mix, but its size remains indicative. The difference is in high-severity findings; critical findings occur at similar rates across the three groups. These are scanner findings in shipped apps, not measured breach rates.

More passkeys. More exposed secrets.

Independent neobanks are ahead on some of the controls security teams want banks to adopt. 37.9% integrate a passkey API, against 4.6% of traditional-bank apps. 48.3% use app or device attestation, against 19.9%.

Yet 48.3% embed credentials beyond Google API keys, compared with 19.8% of traditional-bank apps. High or critical OAuth account-takeover findings appear in 24.1%, against 6.1%: nearly four times as often.

A passkey can protect a login from phishing. It cannot remove a private key bundled into the app or repair a separate OAuth flow. Adding a strong control does not cancel out a weakness elsewhere. For a bank's security team, the useful question is whether the whole path from login to payment holds up.

Traditional banks have little room to celebrate

The better-performing group still has serious findings in roughly half its apps. Across the full sample, 51.5% carry a high or critical finding, 20.3% embed a credential that should be secret, and 41.1% ship a third-party component with a published vulnerability.

The credentials include private keys, cloud keys and service tokens. An app is distributed to customers' devices; anything packaged inside it can be extracted. A secret needed to protect the bank's services should not depend on remaining hidden there.

Google API keys are counted separately. Many are meant to ship with Maps or Firebase, so finding one does not establish a leak. Their risk depends on restrictions, which this study did not test. None of the credentials found was tried.

The bank's own app can become the attacker's tool

Recent campaigns show why app integrity matters. GoldFactory patches genuine banking apps. Gigabud clones them into a hidden work profile. Hirudo replaces the real app with a patched copy. The trusted interface can remain while the code underneath serves the attacker.

Yet 79.8% of apps show no app or device attestation, and only 22.3% of Android apps detect the remote-control tools used to commit fraud from a victim's phone. App attestation can help identify a tampered copy, but it only helps the bank if the server acts on the result. That enforcement cannot be verified from the app alone.

Biometrics need the same scrutiny. The scanner flagged bypassable biometric login flows in 35.1% of Android apps. A fingerprint prompt is only as strong as the operation it protects: a flow that merely checks a yes-or-no result can be skipped. Sensitive actions need to require the cryptographic key unlocked by the biometric check.

The financial stakes are already visible. Mobile banking carried £301.8 million, or 52%, of UK authorised push-payment scam losses in 2025, according to UK Finance. Those losses are separate evidence of the stakes, not losses attributed to the findings in this study.

What should change before the next release

For bank leaders, the comparison calls for evidence that protections work together. For engineering and security teams, start with these checks, drawn from the report's recommendations and mapped there to OWASP MASVS:

1. Remove secrets from the shipped app. Keep private keys and service credentials on the server. Give the app short-lived tokens with limited access.
2. Close known holes in dependencies. Keep a software bill of materials for every release and a deadline for fixing critical components.
3. Test the route from login to payment. Bind sensitive actions to hardware-backed keys, check OAuth flows, and offer passkeys. Test whether a control can be bypassed, not just whether its API appears in the code.
4. Make app integrity a server decision. Validate Play Integrity or App Attest verdicts on the server and act on failures. Test runtime defences against current attacker tooling on real devices.
5. Use device risk at the moment it matters. Check patch levels at login and restrict high-risk actions on unpatched devices. Detect remote-control tools before they can turn a legitimate session into fraud.

The question for the next release review is concrete: can the team demonstrate that an attacker cannot skip the checks protecting an account or a payment?

Read the full report for the bank-type comparison, country tables, four attack case studies and all eight recommended actions. Test your own app against these controls with Ostorlab for banking.

What the study measured

Between 28 October and 5 November 2026, we collected 2,841 banking app listings and analysed 2,686 apps across Android, iOS and HarmonyOS. The sample covers 487 banks, including 29 global systemically important banks, and is five times the size of our 2025 edition. The sample and method changed, so the editions are not a year-on-year trend.

Each app underwent static analysis, an automated fast scan and sixteen authentication and payment control checks, alongside a review of public bank data. A finding is a scanner rule match in the shipped package, not proof of exploitability. No app was attacked, no login was tested and no discovered credential was used. Server-side protections may be invisible to this method. Checks requiring readable code exclude packed apps: overall passkey results use 2,586 apps and attestation results use 2,602. Results are aggregate; no bank or app is named.