Slashdot Mirror
Banks' Big Upgrade: Meet Real-Time Processing
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.'"
... with Bitcoin.
http://consumerist.com/2011/07/bank-of-america-gives-same-account-number-to-two-customers-deposits-30k-in-social-security-payments.html
http://consumerist.com/2011/06/bank-of-america-threatens-to-foreclose-on-homeowner-if-he-doesnt-pay-000-asap.html
http://consumerist.com/2011/07/chase-regrets-to-inform-you-and-the-credit-bureaus-that-you-are-dead.html
http://consumerist.com/2011/07/bank-of-america-closes-customers-accounts-after-nearly-3-million-in-mysterious-overdrafts.html
None of this should be taken as meaning they should not modernize. It is just that they have taken this long to realize that they might make more money by being fast than by being slow. I expect they have figured out how to be either, depending on how it benefits them.
If you have to borrow money for a car, you are spending too much on that car.
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.
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
Deposits? Pneumatic tube to the abacus room.
Nope. The current state for most banks run process on a overnight cycle.
So if you transfer $1 from checking to savings it will happen overnight.
If you buy something at a retail store with a check, what normally happens is that
1. the retail store closes it's book at the end of the day and sends the data to their bank.
2. The retailer's bank sends the data to your bank overnight.
3. Your bank processes the data on their overnight cycle.
So the next time you buy something with your check card see how long it takes to show up in your account. (Mind you, most of the time a provisonal transaction will be entered reducing the amount of cash in your checking account to make sure you don't overdraw - but that is just provisional). Normally 2, 3 days. In "real time" you would see the debit right away.
So, this is not so much to combat hyperinflation, it is to squeeze "float" out of the system. If you are old enough you can remember writting a check and waiting days for the check to clear. Durrning that time one could earn intrest [remeber those days?], or heck, not even have the money. [It's illegal to do so, but a lot of people did it to get a short term intrest free loan until there next pay check.
I'm not ashamed to ask questions in areas of knowledge that I lack. I understand basic economic theory, but I'm not an accountant. Real-Time banking is new concept to me, which is why I asked and provided and example that may or may not be applicable. Alexander responded with excellent clarification.
If only more people would start asking questions rather then provide arrogant and snarky remarks such as yours, this forum would be a better place to read.
Life is not for the lazy.
It's not because the money is actually available. It still needs to snake it's way through the Federal ACH. The bank trusts the that the check is good and the $300 you leave with is more like a loan. Try to do that with a larger amount and you may have a problem. For example, my bank will let me walk out with a few hundred after depositing a check but I once had to wait almost a week for a $2500 check from an insurance company to clear before they would let me use that money.
Welcome to Slashdot!
If you disagree with me on social issues, then it's pretty clear that you are a narrow-minded bigot.