What do I know? DoS attacks are a thing, so that's the threat model?!
> Some attacker who's targeting you that somehow got your randomly assigned username but not your password?
You are assuming the username is randomly assigned.
> In the first case, it can be resolved with a 10 minute call to the bank to get your username changed
Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds? If your suggestion is that using the username as the password somehow is supposed to protect you, I have bad news for you: You usually can't change your username, so you can not change that "password" to something the attacker doesn't know.
> (although you have bigger issues if your attacker was able to get sensitive information such as your banking username)
You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password.
> In the second case, the attacker will get ip banned/rate limited very quickly.
You have heard of this thing called a bot net, right?
Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account.
You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought?
> Sounds like a very non typical use case.
The idea that banks should only be secure for "typical use cases" primarily sounds like a very bad design principle.
> Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising.
Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison.
> Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious.
Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you. And also, regardless, the problem still remains: There definitely is no permanent login fail counter. Customers occasionally do mistype their passwords, and that does not lead to lockout. But whatever the real maximum rate of failed attempts is: The total number of possible attempts is more than the advertised supposed maximum number of attempts.
> AFAIK they're obligated by law.
They are obligated to do what? Give you back your money because you say so? Certainly not. Be able to determine with 100% accuracy whether a transaction was fraudulent? Yeah, sure?!