Banks' Big Upgrade: Meet Real-Time Processing 89
CWmike writes "It has been years since the banking industry made any large investments in core IT systems, but some of the largest financial services firms in the U.S. are now in the midst of rolling out multi-million dollar projects, say industry experts. About a decade ago, they began replacing decades-old Cobol-based core systems, with open, Web-enabled apps. Now, they are spending more than $100,000,000 to replace aging systems, converting to real-time mobile applications for retail services such as savings and checking accounts and lending systems. The idea behind going real-time: Grab more business — and money — from customers. 'Five of the top 20 banks are engaged in some sort of core banking replacement and we expect to see another three or four in next 12 months,' said Fiaz Sindhu, who leads Accenture's North American core banking practice. 'They're looking at those upgrades as a path to growth.'"
Apples, oranges, confusion, and enlightenment (Score:5, Informative)
I currently write financial software targeted at small and mid-sized banks. The article was ... confused, so, let me try to clear it up a bit:
In the computing world, when you say you're going to replace your core systems, you're talking about replacing either the main software or hardware that your systems run on - or both. In the banking world, when you say 'core system' (or 'host system'), you're talking about the software package being used to store your customer's account data, such as Fiserve or Miser.
The article confusingly references both types of changes and appeared to treat them interchangeably.
Similarly, the phrase 'realtime' has a loaded meaning in the banking world. Outside of the banking world, 'realtime' means 'instantaneous', such as 'realtime rendering'. Inside the banking world, realtime means that actions (such as transfers) are submitted directly against the core system, as opposed to a proxying system which determines rates ($/day, max $, etc), fees, and tries to keep track of the active balance vs. ledger balance. The alternative to 'realtime' is 'batch' - where everything is performed in one fell swoop at the end of a day - when you reconcile the day's transactions.
Some transactions - such as inter-bank account to account transfers can usually be handled in 'realtime' even if the core doesn't support it. The necessary proxy can know everything about that bank's transactions, and can guarantee the availability of funds, so it's allowed. External transfers can't be though. Thus the separation between available balance and ledger balance. You can see this on credit card systems too; your payment may show up on the site as being verified, but not yet applied. In fact, with only few exceptions, when money is sent from one location to another, the actual movement is not finalized for a day or two. Both sides make note of it, so funds are made available, but it can be cancelled or reversed at any point in time before that.
In any case in the banking world, mobile or web (or even atm and point-of-sale teller terminals) don't care much about whether the backend core is in realtime or batch mode. It has nothing to do whatsoever with that functionality. Those are just pieces of software that hook into the core - and the core (or adapters for it) must support that functionality.
Whew! It was hard to read that article with the mixing of those definitions and a base misunderstanding of their purposes.
Not quite (Score:5, Informative)
We haven't been replacing those aging COBOL-based apps - that's a massive infrastructure that is well proven and works.
When you have systems that churn through billions of daily transactions across millions of accounts, you don't just swap out the systems that do that processing if those systems are working well. It's not glamorous, but it's reliable and it works - and is not prone to new (and expensive) bugs that come with new development.
No, what happened a few years ago was that we started upgrading the hardware and building new, more modern layers to fit on top of those back end systems. But replace them? Replacement is something that is happening very, very slowly. Think of it like erosion - the edges get worn down, we shore them up here and there. And when we have NO other choice, we replace them.
We all ooh and aah over our 1000-TPS Weblogic systems - but forget that the backend COBOL applications are quietly handling all of that load and more.
Fortunately, I'm not involved in the "legacy" systems, so I can be one of those marveling over how fast our Java stack is ;)
These statements are my opinion and not representative of the beliefs or actions of my employer. etc, etc
Re:Effects of Hyper Inflation (Score:4, Informative)
Welcome to Slashdot!