There are a bunch of APIs, actually. Plaid is a pretty popular one. The problem is getting the banks to implement them.

But people definitely choose banks because of their apps. For example, my bank doesn't have any physical branches in my area, so I do everything through the website or app. Remote check deposit through my phone camera, for example.

It would be unwise for a bank to publish its exact fraud detection and risk management policies, otherwise they could be easily circumvented. A lot of these policies will be embodied in their internal backend services.

Someone will now inevitably mention "security by obscurity". But Kerckhoff's Principle is specifically about cryptosystems which should derive their security solely from the strength of the keys. That way, confidentiality is still ensured even when details about the cryptosystem become known to adversaries.

But non-cryptographic aspects of security benefit from asymmetric knowledge, from grey areas, from increasing risk for adversaries.

Yeah I thought you'd ask this. Basically they'll never do this, just because their attitude is "fuck you I'm a bank".

Beyond this, there's a big difference between source code and having a working system.

For very long running systems their state depends very heavily on how they were maintained, little bits of informal design decisions that get components working together, and the order stuff was loaded in, and what other services were up and running when you booted up.

None of this magic is captured by source code, and it can make even setting up a replacement server, even as part of the same infrastructure really hard.

Of course banks are moving to more modern dev methods that encourages turnkey deployment, but the fact that they still rely on a bunch of COBOL code tells you there's a lot of very old system running in "do not touch" mode

What's the advantage for the bank?