By "hardening the API server" I mean fixing actual security vulnerabilities and improving the security posture of the API gateway, not going for further obfuscation layers or attempting to prevent third-party clients. Those are a waste of time. My position is that there's no point trying to prevent the user's access to his own data - but there is a point in enforcing e.g. access controls so customers can't access data for accounts they don't own or spend money they don't have.
When you talk about "breaking" banks in the US space, are you referring to gaining access to the API and reversing it (which has always been Teller's MO, no?) - or finding vulnerabilities with the API endpoints with actual financial implications for the institution?
> Also disagree with insinuations that these banks don't have good, modern stacks
I'm aware of your thoughts on this, though I respectfully disagree with the "modern" characterisation you have applied to legacy banks based on the sorts of tech I've seen and how it e.g. coped when faced with such exotic things as non-ASCII characters.
Monzo have at least never wasted time on obfuscating the fuck out of their API comms, nor forcibly preventing me from accessing my transactions on my rooted device or running their app under a debugger.