I don't agree with this dependency on being in good standing with Google either.
But there is a technical reason that isn't wanting to avoid using their push servers. It is about battery usage and radio bandwidth.
Keeping open an idle connection over WebSocket, long-poll HTTP or TCP/IP needs regular pings (typically 30 seconds are used), one ping per connection. Otherwise your app can't be sure to receive messages from the server in real time, as the connection can disappear into CGNAT or similar hole where it doesn't receive messages sent by the server. To an app not using pings to check, such a blackholed connection is indisinguishable from an idle connection with no pending messages.
Waking the radio every 30 seconds, times 2 (back and forth), times the number of registered applications, would be quite battery draining. It drains battery both for background CPU usage and radio processing. Those pings in aggregate can even amount to a significant amount of data usage for users on smaller plans.
So there is a battery and radio advantage in using a shared push service, which only need a single idle connection to be kept live with 30 second pings.
There's another level to this, not available to regular developers using TCP/IP, HTTP or WebSockets.
The mobile network itself has to maintain handset connection liveness to the nearest tower, at a lower level than IP pings, and this is obviously optimised for battery and radio performance, and always running.
With arrangements in place with the mobile networks (which Google and Apple have), the mobile OS can leverage that for more reliable, lower power push notifications, by either guaranteeing the network will send something technically similar to a low-level SMS when there's an outstanding message, or by guaranteeing their special push IP connection will stay live by itself (no CGNAT blackhole) or be notified if something happens to it.
This allows the mobile OS to offer a shared push service that's fairly reliable at real-time notifications, with zero continuous CPU and radio power overhead for the idle connection.
When I want to do banking I'll open the app, do my business, then close the app. A banking application does not need push notifications.
Clearly, real-time notifications are useful with many apps, notably real-time messaging, even if you don't think they have a place with bank apps.
For bank and credit card apps, I find their push notifications to be very useful. They are among the most useful notifications I get, because they tell me about things I find important, which I wouldn't notice otherwise.
They tell me things about transactions that have gone through, sometimes after a long delay, transactions that need confirmation right now or they will be blocked, balance being too low, or too high (credit cards), payments that are required today, refunds that came through after a product was returned, transfers that completed on the receiving said, payment received from a client, direct debits that are going out tomorrow so I will need to make sure there's enough in the account, customer service messages that require a response from me or they will eventually close the account, and so forth.
"Just open the app" doesn't work: All of those, except transaction confirmations, are things where I wouldn't know to open the app if I didn't get a message of some kind to tell me.
These days, in some juristictions it's also required to send real-time notification to confirm some purchases, because the phone's security is considered better than card details alone. Depending on how the purchase is made (e.g. in-person vs online, different payment terminals), you might not know the reason a transaction is blocked or held is because it's waiting for you to confirm in the app, so the notification is useful for this.
All these used to be done by SMS, and that was useful too. But SMSs are just push notificatons with a worse UI and worse visual cues.
> But SMSs are just push notificatons with a worse UI and worse visual cues.
I am too lazy to test, but did this change? Can't you just make a "fake" account and continue with your life? The phone company knows where you are, the bank knows what you purchase. Compared to that Google will know far less (ofc, if you don't activate everything)
I find it much more insane that it was possible for so long to do banking WITHOUT strong authentication (however implemented) by just providing those 3 numbers on the back of the card (strong security!)
> If you are not in good standing with Google, you cannot bank!!
> I cannot stress how inane it is, to have Google or Apple as the gatekeeping to identify verification. How not having an active, in good standing account with one of these two, means you cannot bank.
Having to register some phone number (does not need to be your main number, a sim card is quite cheap) to a "fake/unused" email address (even if as you say you are required yo) does not require you to "be in good standing with Google" and they are not gatekeepers of identity.
At this point in time I feel the banks and the mobile phone operators are much worse managers of identity, because, for example they even accept stolen identifiers to make an account in "your name" - for me that's more ridiculous, not that they require some multiple factor of authentication.
Absolute madness.
1. Revolut app stopped working so I emptied my account and opened a Wise account which is fully administer-able from their website. Revolut has subsequently started working again after a couple of app/OS updates.
Same, though I’ve never returned to Revolut.
Wise does have some quirks (e.g. they’ve blocked me from unfreezing or reissuing my cards recently for no apparent reason), but still they’re way way closer to zero-bullshit than any other neobanks I’ve tried.