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...
no banks do lend the money they get from deposits.
creation of money happens when this process continues-
X deposits $100. bank after keeping (say) $10 due to statutory requirements, lend $90 of that. Y who got it(either from bank or after transactions from persons who got it from bank) then deposits $90 in another bank. that bank keeping $9 for statutory requirements lend $81. and this goes on. so from that $100 banking system create another $800(if statutory requirement is 10%). that is what is meant by creating money by banks.
This article is just about what I would expect from the BBC. Apparently the writer has no domain knowledge or experience of his own, so he relies entirely on what a number of different people (some of them self-seeking) see fit to tell him. Then he tries to fit the pieces together, like a rather slow child attempting a jigsaw puzzle.
1. The title "Is old tech putting banks under threat of extinction?" is precisely the wrong way round. As we can all see, "old tech" has stood the banks in good stead and enabled them to run continuously and fairly reliably for 60 years or more. It's the addition of "new tech", and changes in the business, that add the risks.
2. '"For the next five years - and we're talking globally - every incumbent banking player who's been around for a while will have an increased risk of outages," says Julian Skan, managing director of financial services at consultancy Accenture'. The journalist adds no comment or criticism, because Accenture is entirely authoritative and reliable. For anyone who remembers that far back, "Accenture began as the business and technology consulting division of accounting firm Arthur Andersen". https://en.wikipedia.org/wiki/... The new name, as far as I know, was deemed necessary to escape from the appalling connotations of "Arthur Andersen". The interesting thing about the quotation is that it gives no reason for the alleged increased risk of outages.
3. Next, under the heading "Legacy issue", we are informed that 'The problem is that the old mainframe computers - the workhorses of the global banking industry - have been chugging away keeping tabs on all our transactions for decades now. They're slow and reliable'. There are only two glaring, outrageous mistakes in this. First, the "old mainframe computers" themselves do not pose any problem at all. Second, they are very reliable but absolutely not slow. No doubt Matthew Wall has some dim idea that the same mainframes have been chugging away for 60 years, but surprise! IBM and others have continually upgraded their mainframes, and those of today are among the fastest and most powerful computers on the market. The IBM guideline for mainframe response time used to be half a second - with up to 1 or even 2 seconds allowed where the mainframe was remote (in one case, users in Australia were getting a 2-second response time from a mainframe in London). As today's mainframes are much more powerful, and comms are quicker, I can't see that this response time expectation should have changed much. In fact, it is Windows machines and even Unix servers that are much slower and less consistent in the response time they give. Since mainframes were designed, along with their tightly integrated software such as IMS and CICS, to handle transactions at the fastest possible rate, they are far more efficient at this kind of work than any other computers - which is why the predictions, starting before 1990, of the mainframe's demise have never materialized. Oh, and Matthew - "The definition of 'a legacy system' is one that works".
4. "But the world has changed. We've gone mobile and online. We expect real-time transactions and access to financial services around the clock". And mainframes obviously provide the best possible back-end support for those requirements (which aren't really new anyway - 24-hour ATMs have been around for decades, and going "mobile" doesn't make any difference to banking systems).
5. "The new computer systems and programming languages designed to cope with this fundamental shift in our behaviour don't interact well with the old, slower back-office systems". This sentence is so wholly and inherently wrong that's it's quite hard to pick out the individual wrong ideas from the overall mess. The "new systems and programming languages" (whatever they may be - we are not told) were not designed to cope with "going mobile and online". They were partly designed to make computing (and especially software development) cheaper and more flexible,
I am sure that there are many other solipsists out there.
Luckily various governments thought of that and guarantee deposits up to a certain amount.
Let me know when bitcoin can handle 2000 transactions per second, which is just equivalent to VISA average.
makes the old systems obsolete, but impossible to replace
No. It may be (difficult | expensive | unprofitable | complex | a pain in the ass | a (herculean | sisyphean | Korean | Crimean | many eon | diahrrea'in) task), perhaps.
But impossible? No.
Nothing posted to
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.
No, I think what both banks and customers should fear are banks switching from old flow-oriented languages to modern languages that abstract everything in dozens of layers and black box libraries outside your control, making it near impossible to troubleshoot what's actually happening.
And when they switch from real time systems, which are slow but you're guaranteed a result by a deadline, to the best effort systems that are all that modern programmers know.
What banks need is certainly modernization, but not to the popular programming methods of today. They need full transparency, strict operating deadlines, atomic operations, containment, a focus on worst case, and testing algorithms more than runtime.
Perhaps replacements for COBOL, Ada and Fortran are needed, but I think it needs to be engineered by someone who understands what's different, and why.
It's not good enough for a bank to make 99% of customers happier. If software causes problems for 1%, they risk losing major customers or licenses to operate.
This MEME really needs to die. Old Cobol code isn't an issue any more than old ASM is an issue to Windows.
Banks didn't update their backend cobol systems for this shit, they put new front ends in front of it. Haven't done some brief contracting for a couple who essentially write everything in C# and have literally one guy that knows Cobol and 'the mainframe' that helps them interface to it with VERY MINIMAL IF ANY code changes at all. You make the new front-end interoperate with the back-end and you leave the back-end the fuck alone until its completely replaced.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager