|
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. |