As a general rule, do banks and similar financial institutions write their own ‘in house’ e-banking systems, or do they use a third party?
Given the complexity of the task, and the obvious big BIG bucks at stake, I assume they hire out. But, although that would (presumably) ensure they have a good system, wouldn’t it open up its own security issues? First among them, I assume, is that the key to the mint would lie outside the bank’s control. In other words, they would be depending on, and have to trust, outsiders. Second, a hack on one institution would be a hack on all. Third, I would guess that customization for any specific bank would then also have to be done by outsiders (if not, the providers of the core program would have their hands full with compatibility issues), and that would leave things even more outside of the bank’s control.
OTOH, if banks have an IT division of their own that is sufficiently skilled to create, implement, and troubleshoot such systems, it would require a large, highly skilled, and necessarily trusted workforce. If nothing else that would a huge and ongoing expense.
So, I ask, as a rule do financial institutions custom design their own e-banking systems or do they get a third party to do it?
I used to work for a company that made credit / debit card processing and ATM / POS driving software. We would often write software that interacted with bank’s backend accounting systems.
In all cases it was a third party software package, and for the most part our interaction was not customized for specific banks.
That said, we mostly dealt with small and mid sized banks (or third party processors for small banks). I’m not sure if the same holds for the huge national banks.
As a rule, big banks have theirs customized by an external designer, while smaller banks buy standard designs. You’d want a standard product as much as possible, for easier after-sales service, and automatic benchmarking in the industry.
To answer your questions (just my observations) it doesn’t really make sense to keep a team of programmers capable of making one’s “backbone system” from scratch. How often do they have to make a new one? You keep enough of those guys to install, secure, and maintain the system you acquired.
I used to have an MBNA credit card until Bank of America bought them out. I think that buyout happened in 2005.
When I go to pay my formerly-MBNA card, I log in to the BOA system (the same system for all my other BOA accounts) and click the “pay now” button for my formerly-MBNA card, and I get sent to the very same ex-MBNA payment portal as I did when I first was paying the card online in 2001 or whatever from the MBNA site.
I’m not sure how relevant that is to this thread, but I think it’s fascinating that in 10 years one of the biggest banking institutions in America hasn’t had the time or manpower to properly move one faction of their cardholders over to their branded interface.
My credit union, for what it’s worth, conducts all their banking at like “mybank.somebankingsystem.com” - totally not in-house at all.
Oh, I think I misunderstood the question, and you’re talking about the consuming facing banking website. That said, I’m pretty sure the answer is similar. In fact, my previous company built that software too, although I didn’t have first hand experience on that side.
I’m with one of the huge banks you’ve heard of. Our “IT department” employs somewhere around 25,000 people, so we have the talent needed to design, implement, support and secure our own systems.
Most of our systems are home-grown with judicious use of commercially available modules. It’s been my experience that most “off the shelf” financial stuff is simply overwhelmed by our needs.
A hell of a lot of these “e-banking” systems are running on mainframes, possibly IMS or CICS or similar. If your transaction/banking info is presented to you in all caps th n it’s probably coming from a mainframe. They pretty much spin their own web interface to let you interact with it via a web browser.
Where I worked, a pretty large Chicago bank, we did both. We started with our own IT dept programmers doing everything, but shortly after 2001 or so we outsourced to a third-party company that agreed to hire pretty much all of our programmers. Our IT dept shrunk to tech support, and shrunk again when phone support was outsourced to the Phillipines.
When e-banking came along, we bought a pre-existing solution and gave it to the company that hired all our programmers to integrate it, coordinated by a project manager with the company.
As far as security, the opinion of our programmers was that every new option made it tougher, understandably. People accessing solely thru a website we controlled was easier than adding phone apps and other crap. When we added check cashing to the phone app, it was a huge hassle making sure a customer couldn’t deposit the same check via ATM, teller, or somesuch too quickly for the other systems to catch it while still crediting the customer as quickly as the competition.
to speak to non-USA, it used to be a practice to develop own systems, but I would say for 15 years or more it is not really done, now one goes to standard companies specialized in the area. So this is similar to what epbrown writes.
[QUOTE=jz78817]
A hell of a lot of these “e-banking” systems are running on mainframes, possibly IMS or CICS or similar.
[/QUOTE]
Yep. CICS for us.
Before anyone thinks CICS on a z-Series mainframe is dusty old tech, CICS directly supports new things like EJB (Enterprise Java Beans) and Websphere web server middleware. New is a relative concept when the system is nearly 50 years old.
I was about to say that the big banks probably have unique needs, and probably are still running on COBOL systems, since after a certain point, you financially have the tiger by the tail in a sense. By that, I mean that the amount to rip out the old system and replace it with something more modern starts to become enormous if the product lifecycle gets too long.
So yeah, when that happens, you pretty much HAVE to have an IT dept that can maintain something so enormous, and to modify it in such a way to keep up with current business needs.
That said, they probably farm out stuff like websites, and just build interfaces to their existing system.
It isn’t that the don’t have the time or manpower to do this – they just don’t see any advantage (= profit).
Existing customers (like you) are satisfied to continue using the same system they’re used to – indeed, they’d probably complain if they had to change (customers are notoriously resistant to change). And they would require training & increased support costs for the bank. All without any increased profit from those customers.
And changing wouldn’t bring in any new customers – new ones go onto the standard BoA online system, rather than the old MNBA one.
It will probably stay this way for many years; until the costs to support the old system get too high, compared to the number of customers on it. Most likely this happens when some new feature comes along that requires a major re-write of the MNBA system to add it. And at that time, there are few enough customers still using the MNBA system (or few enough profits being made from those customers) that they decide it isn’t worthwhile to do that. So old MNBA customers don’t get that feature. If they want it, the bank just issues them a new BoA card, and switches them to the new system.
Eventually, enough customers will switch (or die off) that the bank decides that supporting the old system costs too much, co they will force all thise customers to switch to the new one. (But it won’t be announced like that – they will send out a letter about the exciting new credit card they are offering to special, long-time customers.)
Obviously, that time hasn’t come for the MNBA customers yet. Support costs for the old MNBA system are still below profits from it.
Possibly, that has something to do with banking – there aren’t really many exciting new features in the banking system. And government regulators tend to look askance at them, too, thus delaying them.
My brother was a free-lance “systems analyst” (his name for it). Since he died in 1999, all this information is from the 90s and earlier. He worked about three days a week for a medium-sized NY bank (there were medium-sized banks in those days). The biggest thing he did was set up a secure line between the bank and the Federal Reserve bank. Since he was ultra-careful I assume this was ultra-secure. But he did other programming for them. A side note: He would not use an ATM.
So he was not in-house, although he had an office in their building.
