The Pixel 10 Pro flashed fine. Chase didn’t

The install itself is the easy part. GrapheneOS’s web installer detects the Pixel 10 Pro (codename frankel) the moment you plug it into a USB-C port, unlocks the bootloader over fastboot, writes the factory image, and locks the bootloader back down with the GrapheneOS verified-boot key. Ten minutes, no terminal required. Then you boot into a clean AOSP-derived system, sideload the Play Store through GrapheneOS’s sandboxed Google Play compatibility layer, and log into your bank.

That’s where the Pixel 10 Pro experience goes sideways. Chase Mobile opens, shows a splash screen, then throws a generic “This device doesn’t meet our security requirements” message and quits. Capital One gets as far as the login form, accepts my credentials, and then silently fails the post-auth handshake. Revolut refuses to run at all. Meanwhile Wise, Monzo, and American Express work without complaint. If you’ve landed here because your own grapheneos pixel 10 banking apps situation is half-broken in exactly this way, the pattern is not random — it maps directly onto which Play Integrity verdicts each bank actually enforces.

Why banking apps care what ROM you’re running

The short version: Android hands developers a signed attestation about the device, and banking apps are some of the most aggressive consumers of that attestation. The long version is in the Play Integrity API verdicts documentation, which defines three verdict fields an app can query: MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY, and MEETS_STRONG_INTEGRITY. GrapheneOS on a Pixel 10 Pro passes two of those and fails one, and the one it fails is the one that trips banking apps.

MEETS_BASIC_INTEGRITY is the loosest check. It just wants to know the device isn’t obviously tampered with and is running an Android-compatible system. GrapheneOS passes this trivially because it is an Android-compatible system — it ships the same AOSP framework APIs, the same SELinux policies, and actually stricter sandboxing than stock Pixel firmware. MEETS_DEVICE_INTEGRITY is stricter: the bootloader state, the verified-boot key, and the system image all have to match something Google recognizes. This is the verdict that used to block GrapheneOS universally, and it’s the one that the Pixel 8, Pixel 9, and Pixel 10 lines now pass cleanly because the Titan M2 security chip signs an attestation that validates against Google’s hardware-backed key attestation root, regardless of which AOSP-derived OS is booting.

MEETS_STRONG_INTEGRITY is where it falls apart. Strong integrity requires not just hardware-backed attestation but also that the running OS be specifically “Google Play certified” — meaning the OS vendor has gone through Google’s CTS process and signed a commercial agreement. GrapheneOS has not and will not. Strong integrity is the verdict that currently-broken banking apps are demanding, and there is no software fix for it on the user side. The GrapheneOS team covers this distinction in detail on their attestation compatibility guide, which is the single most useful document for understanding what’s actually happening when an app rejects your device.

The April 2026 state of play, bank by bank

Support for GrapheneOS on banking apps shifts every few months as apps update their Play Integrity calls. Here’s roughly where things sit on a Pixel 10 Pro running the April 2026 GrapheneOS stable release.

Works without intervention: Wise, Revolut (on recent GrapheneOS builds, after the February 2026 change on Revolut’s end), N26, Monzo, Starling, American Express, PayPal, Venmo, Cash App, Zelle standalone, most credit union apps built on Alkami or Q2, and Google Wallet for NFC payments (yes, really — Google Wallet works because it queries a different attestation path than third-party apps do).

Requires the “exploit protection compatibility mode” toggle: Barclays, HSBC UK, Santander, and a handful of regional US banks built on the NCR Voyix platform. GrapheneOS ships a per-app toggle in Settings → Apps → [app name] → “Exploit protection compatibility mode” that relaxes hardened malloc and a couple of other memory protections for apps that crash under them. This isn’t a Play Integrity fix — it’s a separate incompatibility where GrapheneOS’s hardened allocator triggers crashes in apps that do unusual memory tricks.

Broken on strong integrity: Chase, Bank of America, Wells Fargo, US Bank, Truist, Citibank’s consumer app, and the Robinhood and Coinbase apps. These apps call Play Integrity, require MEETS_STRONG_INTEGRITY, and refuse to run otherwise. No toggle on the GrapheneOS side will flip this. The device is passing every other check the Play Integrity API can ask for; it’s failing the specific requirement that the OS itself be commercially Google-certified.

What actually changed on the Pixel 10 Pro

The Pixel 10 Pro is not the cause of the banking-app regression. If you previously ran GrapheneOS on a Pixel 8 Pro or Pixel 9 Pro, Chase was broken there too. The difference is that some apps that used to work via a looser MEETS_DEVICE_INTEGRITY path have tightened their checks in late 2025 and early 2026, coinciding with Google rolling out the “classic” Play Integrity API deprecation and nudging developers toward the standard API tier that exposes strong integrity more prominently. A number of US retail banks used the deprecation window to upgrade their checks, and GrapheneOS users found that apps which worked in September broke in November.

The Pixel 10 Pro adds Tensor G5 and a refreshed Titan M2 chip, and both of those hardware changes are fine from GrapheneOS’s perspective. The device support FAQ lists the Pixel 10, 10 Pro, and 10 Pro XL as officially supported, with hardware-backed attestation working through the standard keystore path. Nothing about the phone itself is the problem. What you’re running into is a policy decision by individual app publishers.

Confirming which verdict your bank actually enforces

Before you give up and conclude your bank has hard-blocked GrapheneOS, it helps to know what’s actually being checked. The TrickyStore and Play Integrity Fix modules do this by logging attestation calls, but those are Magisk-side tools and they don’t apply to GrapheneOS. On GrapheneOS you don’t need them — the cleaner approach is to install the open-source Android SafetyNet Attestation Checker or any similar Play Integrity verdict viewer from F-Droid, run it alongside the failing banking app, and watch which verdict field the banking app queries in logcat.

To do that you need ADB enabled under Settings → System → Developer options → USB debugging, then from a separate machine:

adb logcat -s PlayCore:V PlayIntegrity:V | grep -i integrity

Open the failing banking app while the log is streaming and watch for lines like verdict: MEETS_DEVICE_INTEGRITY or requested: STRONG. If you see a line referencing strong integrity and then a crash or exit, you have confirmed the bank is demanding a verdict GrapheneOS cannot return on any Android device, certified or not, that isn’t running the stock shipped ROM. There is no user-space workaround for that, full stop.

Practical workarounds, ranked by how much they compromise

The least bad option for most people is dual-profile. GrapheneOS has excellent multi-user support — much better than stock Android — and you can run a secondary user profile dedicated to banking. The secondary profile still runs GrapheneOS, so it still fails strong integrity, but keeping banking apps isolated from your main profile at least limits what they can see. For Chase and the other strong-integrity holdouts, this doesn’t actually get them running; it just contains them when they do.

The next option is a cheap stock Pixel kept on a shelf for banking. A used Pixel 6a running stock Android on a travel SIM or a data-only profile is enough to log in, move money, and walk away. This is the workflow a significant chunk of the GrapheneOS community actually uses. It looks absurd until you price out the alternative: giving up either the hardened OS or the bank that refuses to cooperate, neither of which is a good trade.

A third option is using your bank’s website in Vanadium (GrapheneOS’s hardened Chromium fork). Most US retail banks still support full account management through their desktop site, and Chase’s site works fine on Vanadium on a Pixel 10 Pro. You lose mobile check deposit and tap-to-pay through the app, but you keep account access. For banks that disabled their responsive web experience to force app-only workflows — Truist and a few credit unions are the common offenders — this doesn’t help.

The option I would not recommend, despite seeing it suggested in community threads, is installing any of the Play Integrity spoofing modules. They’re designed for rooted stock Android, they don’t integrate cleanly with GrapheneOS’s sandboxed Play Services, and more importantly they make the banking app think it’s running on a device that meets strong integrity when it isn’t. Your bank’s terms of service almost certainly prohibit that, and if a fraud event happens on an account accessed from a spoofed device, you have handed them a ready-made reason to deny the claim.

Why the GrapheneOS team can’t just “fix” it

The reason this gets debated on forums forever is that people keep asking why GrapheneOS doesn’t sign a Google Play certification agreement and pass strong integrity like every other OEM. The GrapheneOS project has explained the answer publicly: strong integrity certification requires Google’s approval and, effectively, a commercial relationship that would compromise the project’s independence and its threat model. Google does not certify third-party Android forks as a matter of practice. The project’s position is documented in their banking apps usage guide, which is worth reading in full before forming an opinion about whose “fault” this situation is.

The better question is why US banks in particular treat strong integrity as a hard requirement when European and UK banks do not. Monzo, Starling, and Revolut all use Play Integrity; they just don’t demand the strong verdict. They accept hardware-backed device integrity, which is the verdict that proves the device has a genuine Titan M2 or equivalent signing key and hasn’t been tampered with — which is the verdict that actually measures security risk. Strong integrity measures commercial certification, which is a different thing. A GrapheneOS Pixel 10 Pro is strictly harder to compromise than a stock Pixel 10 Pro, because it runs the same hardware with stricter software, and every bank’s fraud team knows this. The strong integrity requirement is a liability-shifting exercise, not a security measurement.

What to do if you just bought the phone

If you just unboxed a Pixel 10 Pro and you’re deciding whether to flash GrapheneOS, here’s the concrete decision tree. List the banking and financial apps you actually depend on day to day. Install each one on the stock OS first and confirm it works. Then flash GrapheneOS, reinstall the same apps through the sandboxed Play Store, and test them again in a fresh session with network traffic on. The ones that fail will fail immediately — there is no slow-burn incompatibility. If your critical-path list survives the test, you’re fine. If Chase, Bank of America, or Robinhood are on that list and you can’t switch, either keep the stock ROM or plan for a dual-device setup before you flash.

The honest takeaway is that GrapheneOS on the Pixel 10 Pro is the best hardened mobile OS available in 2026 and it breaks a specific subset of US banking apps that have chosen to enforce strong integrity. You cannot fix the banks and the GrapheneOS team cannot either. What you can do is decide, with eyes open, which side of that trade matters more for your actual threat model — and for a surprising number of people, the answer is that the dedicated second device is worth it.