Because banks are financial institutions and every decision they make is based in that. If the cost of insurance is less than the cost to actually secure the system, they will choose that every time.
Banks and payment processors have some of the worst technical debt. For example, a lot of transactions are processed using the ISO8583 standard, a binary bitmap-based protocol from the 80s. The way cryptography was bolted onto this was the minimum required to meet auditing standards: specific fields are encrypted but 99% of the message is left plaintext without even an HMAC.
I don't work at a bank, but I do work in fintech, and this strikes me as excessively cynical. The reason banks are slow about this stuff is not necessarily because "it's cheaper" (though maybe it is), but because the complexity of any change is simply off the charts: money-related logic must work correctly, to a far higher standard than almost any tech company. It makes you conservative, in the same way that demanding 99.999% uptime is exponentially harder than demanding 99%, and makes moving quickly essentially impossible.
(Also, of course, they're probably working on COBOL stacks that were written in 1978.)
For a bank, pile on top of that mountains of (often conflicting) regulatory review, such that just about any change sounds the alarm for armies of nearby lawyers to swarm upon you and bury you in paper. All it takes 0.1% of annoyed users filing complaints that they can't access their accounts, and you might well be looking at a steep fine, a class-action lawsuit, or worse.
Banks and payment processors have some of the worst technical debt. For example, a lot of transactions are processed using the ISO8583 standard, a binary bitmap-based protocol from the 80s. The way cryptography was bolted onto this was the minimum required to meet auditing standards: specific fields are encrypted but 99% of the message is left plaintext without even an HMAC.