The major US banks created clearXchange to solve this problem, which was later sold and now rebranded to Zelle. It's near-instantaneous transfers for supported banks, and only needs a phone number or email address. (I think it's quaint in comparison that you need to give out your bank account number for other systems. Holding of account numbers is exactly the problem that modern mobile wallets worked so hard to solve with tokenization.)
The difference is, however, that you can assign a bank account a number that is unique within a given banking system.
Once you move into the realm of trying to tie an identifier you have no control over (and that has no reliable verification method for) to a place where money will go, you open yourself up to a smorgasbord of potential attack vectors, confusions and edge cases.
Bank account numbers are not unique across banks. Account number schemes aren't even uniform across banks. The only limitation is what fits within the ACH system. You need the combination of routing number (to identify the bank) and account number (to identify the individual within the bank).
Zelle associates the bank account to a email address and / or phone number. Creation of these associations is gated through the member banks. So you have all the controls you have for any other banking task.
You'll note of course that I said "banking system," and I said "you can assign a bank account a unique identifier." i.e. I can create a scheme where I can map a particular account to a globally unique number, with rules about who owns which ranges etc.
So if Alice provides Bob a globally unique identifier to their bank account, then that's where it's going.
If Alice gives Bob a token that is hopefully mapped to the account, then there's an additional layer that can go wrong.
Eve can compromise Alice's e-mail or phone number, and then try and convince their bank that their bank account should now be associated with that identifier. If it's a different bank, then presumably this request must be federated through the third party system. And hopefully the 'true' owner is not identified by sending an e-mail or SMS.
Or maybe Eve just creates a bunch of accounts and tries to associate them with a bunch of telephone numbers and e-mail addresses that she can compromise at will and waits for the money to roll in. This is obviously more likely if some people have more than one account, as it means that the mapping of account -> e-mail/phone no. can no longer be mandatory.
In your example it sounds like they've got some reasonable safeguards in place (like ensuring you have to de-register a mapping before you can register a new one), the only point I was trying to make is that yes, it can be done, but to be done safely it's much harder than just simply having an account number (including routing number/sort code/swift code etc.).
You lose the 1-1 mapping and it gives you yet another thing that you have to actively manage/remember how it's set up/remember to change when you change e-mail provider or your phone number changes.
It's a 1:1 association. When I changed banks and tried to sign up online, it kept giving me an error. I stopped by a branch, and my old bank had registered me at some point. The teller had to call support and remove my previous association before they could create the new one.
Also, the association is to receive, not to send. Sending is initiated by your bank, which obviously already knows your account number. You send from your bank account to an email or phone number, which Zelle then translates to the target bank account.
https://en.wikipedia.org/wiki/ClearXchange
I consider it a huge marketing failure that this is such a little known capability.