Slashdot Mirror
Is Old Tech Putting Banks Under Threat Of Extinction? (bbc.co.uk)
Matthew Wall from the BBC has written a fascinating piece detailing our reliance on banks in today's connected and ever-changing world of technology. The premise: "You put your card in the cash machine but nothing comes out. The bank's IT systems have crashed again. But you need money fast, so what do you do? It's an unsettling scenario that is likely to become more common over the next few years as the big banks try to upgrade their IT systems, experts are warning."
Bruce66423 writes: In the old days everything was batch programs and reconciled once a day. Now, online access and the expectation that money will be immediately available makes the old systems obsolete, but impossible to replace because there are layers upon layers of complexity...
Bruce66423 writes: In the old days everything was batch programs and reconciled once a day. Now, online access and the expectation that money will be immediately available makes the old systems obsolete, but impossible to replace because there are layers upon layers of complexity...
It's killing the branch offices but the central offices are still doing pretty well.
Banks makes money on lending money to people and collecting interest on that money. They actually don't want you to mortgage the loans you take but they accept it as it is also lowering the risk for them.
Personnel and offices - that's what costs banks money so therefore they want to centralize. Online banking is cheap for the banks. But a fast-changing economy is requiring system updates on a frequent basis and when the old classic systems are written in Cobol there are a massive number of things that can go wrong if the changes made aren't tested thoroughly. Cobol is a bit dated when it comes to coding strategies and even though there are object oriented variants they aren't easy to integrate into the minds of people that have been coding Cobol for the last 40 or more years. But coding Cobol is actually pretty well-paid since not many are good at Cobol today and it has even created a market for retired people to come back and code.
What the current banks shall fear is new upcoming banks that have thrown off the old Cobol yoke and started to look at modern languages with strong typing and strict bounds checks.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Actually pretty much most of the large banking computer network crashes the BBC are refering to in this article can be traced to the backoffice and maintenance of the systems being outsourced to India from the UK less than 8 months or so earlier and the whole way its been approached (to save money by offshoring skilled labour to where its percieved to be cheaper).
So banking, long term systems with ultra stable operation, outsourced maintenance, fire all the people who know the systems, dont get reasonable knowledge transfer because of the scummy way it has been managed, and 6 months later find your core business reliant on that infrastructure goes to shit. Sending inter bank transfers on a schedule into swift has little to do with this and is just a excuse being trotted out to cover up the whole shitstorm created by mis-management.
Disclaimer, I work in large corporate areas in the UK and have had a birds eye view of the farce.
Handling cash and running branches is expensive and something banks have actively been discouraging here. Withdrawing larger sums (not talking 5 figures here) requires an appointment, and depositing cash comes with a charge even if you use an ATM for it. They have also funded several large campaigns to get shopkeepers to adopt debit card terminals (credit cards are hardly used for day-to-day transactions here). Banks *love* a cashless society.
With that said, our banks seem to have handled the transition to instant transactions just fine already. On a holiday in Tel Aviv, I used my debit card to pay for something but the machine didn't ask for a PIN. I wanted to make sure the shop got their money, even though the clerk assured me everything was ok. Sure enough, my phone showed the transaction right there, seconds later. The reverse happened when I bought an expensive second hand car. I transfered the money to the guys account from his living room; he used his computer to see the money arriving at the same moment. The latter was only possible because the guy was with the same bank; transactions between banks still dake 1-2 days to complete, but it would appear that the banks have had their internal accounting stuff modernised already.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Working for a bank's IT department, I can definitely state that most of their software is expected to be cheap and delivered fast with quality being a very distant 5th place. Only the accounts themselves are required to be reliable (or reliable enough that the customers don't catch on). So forget about all the yammering about fancy languages and frameworks. The must-be-reliable programs are almost always COBOL dinosaurs. Not because COBOL is better for that, but simply because the core account operations were written back when that was about the only choice around.
Banks also don't care about making 99% or more of the customers happy. As in most businesses, only about 1% of their customers are worth the effort. The rest of you guys can please wait for the next available representative.