[Someone1234]

> I find it hard to believe that each customer has a user account on the mainframe

Why? Do you actually have any experience in this area? I do, and I can tell you, they do exactly that. Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. Migrations are an absolute nightmare.

> Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system.

It can be, but it isn't. Thus, the problem.

Honestly this type of "hardly believe" take is what every new employee right out of college (or myself 15 years ago) when they come up with ten thousand "simple" ideas for improvement without any organization, political, or system understanding. Then they act confused when their ideas aren't instantly implemented, because they don't even understand what it is they're proposing or why it is complicated.

Banks have been trying to get off of mainframes for 30-years or more at this point, spent tens of millions of dollars, but had someone just told them to "run a web server in front of it" this could all have been avoided.

[tzs]

> Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization.

How do the multiple systems communicate with each other and with the mainframe?

[Someone1234]

Depends on the company. Web API (with or without VPN), VAN + EDI, Dial Up Modem (not joking), Scripted SSH/Insecure Terminal, FTP/SFTP/FTPS w/XML or Scripts or EDI, etc. Some communications/integrations are bleeding edge, some are older than I am. It really varies.

Then you have multiple half-measure attempts at migration away from the mainframe, so you wind up with a half-built Java layer and a half-built [Large Contractor] bespoke system.

[tzs]

Stepping back from all the details, somewhere in all their collection of assorted ancient systems, hacks and kludges from previously failed attempts to migrate to something newer, and whatever else they have, there is something that presents a public facing web site that customers can log in on for online banking. (I'm only talking about companies that offer web-based online banking, not companies that want to add online banking to a system that doesn't already have it).

There is something that handles the user's submission from that site and records somehow that the user is logged in, and directs the user's browser to some site that can somehow get their account information, balances, etc, from whatever that is stored, and can handle form submissions that request operations on those accounts such as transfers, bill pay, and such.

What I don't understand is where the difficulty would be in making it so customers do not talk directly to those web-based things, and instead talk to a web front end running on a separate, reasonably modern Unix, Unix-like, or Windows Server and that server talks those older web-based things. It could even talk to them over HTTP looking like a browser to the older components. The online banking front end would not have any direct integration with the rest of their systems. It would just go through the same interfaces they already are using to support online banking.

Heck that is essentially what Plaid does for banks that don't have a useable API. They log in to the bank's online banking site with the customer's credentials and then screen scrape to get the account balances. That has got to be a nightmare for Plaid because they have to deal with many different banks, any of which might make changes that break their scrapping with no notice.

A bank essentially doing its own Plaid that just has to work with its current online banking site should be a lot more doable.