I suspect the answer is "no" but I want to believe...
FWIW I have run several banking apps on GrapheneOS without any issues whatsoever, never had any blocks or compatibility issues. Might just be luck of the draw but just to say you probably do have options.
If you don't like their requirements, you need to take the liability yourself. You could use PayPal or a stablecoin to store your money.
Your money is far more at risk with scams and phishing than it is with whatever boogeyman spyware you may try to think of that does not exist in real life.
Banks have plenty of money. They don't need to be up your ass to keep liability down.
We're in this funny situation where the hacked and outdated device is considered more "secure" by Google because Google controls it
OEM support is a step toward passing integrity, and that's what those apps are looking for.
They can fund the development and support work for attesting GrapheneOS along with funding support for compatibility with the os. The more users that GrapheneOS has the less money they'll need to pay to fund such a project.
Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
> GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
The issue is more that GrapheneOS still allows apps to view OS attestation information[0], which is similar how Play Integrity API attempts to prevent you from running on your own OS. The specific feature I'm referring to which is the problem is the Play Protect API which allows apps to inspect the host system bootloader/TPM state essentially. The problems with giving any apps(even webapps) access to this sort of attestation information are well documented[1] as it encourages app developers to lock out legitimate users who want to run unofficial operating systems. Effectively breaking this app verification capability is what is needed to prevent app developers from enforcing arbitrary security requirements on the host OS. Essentially GrapheneOS just wants app developers to trust their keys in the same way Google wants you to trust theirs(using the Play Integrity API).
[0] https://grapheneos.org/articles/attestation-compatibility-gu...
[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity#Rece...
This would of course be contigent on GrapheneOS growing their market- and mind-share in the general public, while also taking several years to impact the least move-fast-and-break-things industry (consumer banking).
But still, a man can dream.
But being certified by Google of course precludes not preinstalling or sandboxing their GMS apps.
> Google Play Integrity
Essentially a Google API that App Developers integrate that checks if the device runs an Operating System signed by Google as "Play Certified". This can go as far as being backed by a hardware trusted platform module. I doubt Google will certify GrapheneOS given their modifications towards sandboxing the play services. This can be faked to a degree but GrapheneOS choses not to do it and to fake the TPM part you need leaked keys. For more details on how to fake it look at this thread: https://xdaforums.com/t/guide-how-to-pass-strong-integrity-o...
> Fingerprinting the Device OS
This can very from app to app and just tries to fingerprint the device in many ways to see if it's running a custom rom of some kind. This does things like check to see if the bootloader is unlocked or if root is installed. I think this is something an official grapheneos phone might fix since the phone vendor could allow grapheneos to sign their releases as native equivalent
> Banning GrapheneOS by Name
Some Apps Developers literally ban GrapheneOS by name.
> Failures due to Google Play Sandboxing
Since GrapheneOS sandboxes Google Play Services there might be compatibility issues that prevent the app from working right. This would likely be unaffected by a GrapheneOS Phone.
> Failures due to Advanced Security Features
Some Apps just don't "like" the advanced security features like the hardened malloc and other protections and just fail. This can be disabled most of the time