|
|
|
|
|
by Someone1234
1392 days ago
|
|
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. |
|
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.