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.
Banks don't lend the money you deposit. That's YOUR money, not the bank's. Banks create the money they lend (out of nothing).
No that is what central banks do. Banks do lend you money from deposits, but guess what the people who you pay that lent money to do with it? They deposit it again. In a bank. Which means the bank can lend it out again, and again, and again.
It's really quite ingeniously stupid:
1. In an area there are three houses, and three people - Alice, Bob and Mary. Mary owns her house, which she bought for $100k with a $10k deposit. The rest just rent.
2. Bob and Alice both want to buy a house. They go to the bank, and the bank says because they are a responsible bank they will only lend up to 90% of the price of the house. They look at the value of sales in the area and determine that houses are worth $100k based on Mary's original purchase. They are prepared to lend each one $90k. At the auction, Bob is able to outbid Alice because he has saved a bigger deposit. He ends up paying $110k for the house. The bank is fine with the price being higher than market value because it knows it can recover the $90k loan by selling the house for $100k if Bob defaults.
3. Mary receives the $110k from Bob, uses it to pay down her mortgage of $90k, and deposits the remaining $20k with the bank. She thinks she did pretty well making $10k off her housing investment.
4. A little while later Mary changes her mind and decides that she wants to buy her house again. Now both her and Alice are in the market for a house. They go to the bank, and the bank says because they are a responsible bank they will only lend up to 90% of the price of the house. They look at the value of sales in the area and determine that houses are now worth $110k, based on Bob's purchase price. They are prepared to lend each one $99k. At the auction, however, Alice is now desperate for a house. Even though Mary has the money she made from the previous house, Alice has saved hard and is able to scrape together enough for a $120k bid. She wins the auction and buys the house. The bank is fine with the price being higher than market value because it knows it can recover the $99k loan by selling the house for $110k if Alice defaults.
4. Bob is overjoyed. He just made $10k from his housing investment. Alice raises the mortage, and pays Bob. He pays down his $90k mortgage and puts his $30k into the bank.
5. Bob then tells Mary she needs to just get into the market and buy because prices are going up so fast. Mary has already made money from housing, so she agrees. Alice hears how much Bob and Mary have made in the housing market, so she looks at buying an investment property. They all go off to the bank again...
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.
Next question?
Why is Snark Required?
Luckily various governments thought of that and guarantee deposits up to a certain amount.
When someone says "technology is killing banks" what you really mean "bitcoin, the new technology for decentralization and cryptography is killing banks". Because that is what is already happening. It's real. Banks already know. Media is obsolete and is crumbling as well. They are not able to even grasp what is going on right now in the fintech world.
The most common reaction when a big change is coming is deny it. It is just what is happening now. Most people deny what is happening.
So bitcoin is here and it is moving forward everyday. A decentralized system of trust that lets people send cheap assets through out the world just with no more than a nokia 1100 in your hands.
Calm down there, Skippy. You're getting quite ahead of yourself. The average human still doesn't even know what a bitcoin is, let alone why it exists.
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.
Well, I can't pay my taxes with US dollars, since I live in Europe. But they still have their use from time to time. The same goes for bitcoins, which I use quite often.
"There's someone in my head but it's not me." - Pink Floyd, Dark Side of the Moon
Generally transactions are (almost) immediately listed as pending transactions. They may not finalize for a day or two. In my experience, they are reflected in the available balance, but not the actual balance for an account. It may show up right away, but the transaction almost certainly hasn't finalized at that time.
You are probably American, or from another country that uses payee-initiated transfers and/or still supports cheques.
In much of the world, banking is instantaneous now, with no "clearing" (payee-initiated systems) or "float" (payer-initiated systems) periods.
In "modern"[*] systems, when I transfer a sum to your account, it is immediately unavailable to me and available for withdrawal in your account as fast as the handshake can fly over the wires.
[*]: I say "modern", because the giro system for payer-initiated transfers between different banks is from the 1960s, but the abolition of "float" where each bank would hold on to the money for a business day (night time batch processing) went away in the 80s and 90s.
So, although you have the money and have been paid, the bank gets to hit you with fee's only because of the way they line up the batch processing. If they were to process deposits first (As many credit unions do) it cuts down the number of NSF fees they can collect by more than half.
No bank worth their salt does it that way anymore.
It might have been true years ago, but it isn't true today.
I bank with Bank of America. All their "big bank" issues aside, they don't do what you describe. They provide a "pending balance" for anything credited and only charge fees if you go over your balance at the end of the day and haven't made it up.
If by chance you DO have a bank doing that, then leave, that is stupid.
So far I just pointed out that it was a problem running Cobol in the long run due to the problem of programmers fluent in that are dying off.
The good side is that it's an easy language to learn.
What's hard about it is changing the mindset. You truly can't think modern programming and translate it into your head into COBOL; you have to attack the problems from a COBOL point of view.
I hate COBOL[*], but it lends itself to K.I.S.S. and easy debugging.
[*]: To be fair, I hate all programming languages. The more abstracted, the more I hate them.
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.
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
As an architect designing a distributed horizontally scalable solution with commodity hardware to replace a legacy mainframe based system at a major US bank, I can attest to the near impossibility of such a feat. The problem is one of reprehensible management that silo themselves into little fiefdoms in there ever present quest to backstabbing their way up the corporate ladder. The culture in management is so hostile that positions for middle management are opening up and being offered to technical people like myself who are turning it down because who wants to eat shit and be in meetings for 70 hours a week for what, 10k more per year? No thanks, I actually like spending time with my family. Further still decades of offshoring and outsourcing have sufficiently hollowed out these organizations to the point where nobody knows, cares, or values doing the right thing. Most of the time they are substandard technical talent at best. Management couldn't buy a clue though they sure try. Everything some consultant comes in to look at stuff and offer advice, they are basically just put in charge of doing actual management. Literally you don't get much more hollow than making the consultant a bona fide manager. Really? You just wrote the vendor a blank check! Of course his management discretion will be to buy more and more products and services from his company, and bring more and more of his buddies into this gravy train. Then when it falls apart, consultant is kicked out and blamed for all the problems, then they cycle in the next company with a flashy PowerPoint and sales guys with a good golf swing. Then we have the problem of them not understanding IT in the slightest because they have been out of the technical game so long or they are an MBA suit. They don't understand how a successful project is run, what people are talented and which are good pretenders, and throw in buzz words they hear at a conference like, "Scrum" and "Agile" but then set it all up for failure by insisting on projects that are Fixed Date AND Fixed Scope! Seriously, when has that ever worked? Clearly not anytime in recent memory judging on maybe the single digits project success rate that you boast as an organization. Some messed up part of their mind believes that people work harder when you set a hard deadline and whip them. OK, I am not challenging the veracity of this, merely that hard work is what makes an IT project successful. No, careful methodical planning and diligent project management make an IT project successful. If we had all the answers and I had 10 really smart guys and full participation of interface teams, we could knock this out in 3 months. To get there requires a lot of analysis, design and planning though. Last I checked the project isn't failing because we don't have enough warm bodies banging on keyboards, it's because we can't get 40 teams to coordinate, we can't get the business to commit to scope, and requirements suck because you have been treating analysts like replaceable cogs for decades. No, the real goal isn't the project, it is to grow a team bigger than your colleague and have more face time with executives because ultimately that is what gives you advancement. This is the reason whyou these projects are seemingly impossible and almost always fail at the bank.
Why do you hate Rust????
The real question is, "Why does Rust hate America?"
Just cruising through this digital world at 33 1/3 rpm...
If you're going to troll, at least try to be a little less blatant.
Agreed. As if we couldn't see with our own eyes that "Rust" and "Trump" have almost the exact same letters.
Coincidence? I think not!
Just cruising through this digital world at 33 1/3 rpm...
Actually, banks have no use for hard real time. What they need is bullet proof transactions and audit trails. Does it ACTUALLY matter if the ATM transaction that is allowed 11.2 seconds takes 11.3 to complete? What does matter is that the debit to the account happens without fail if and only if cash is dispensed. AND they need to be able to prove it through audit logs.
[*]: I say "modern", because the giro system for payer-initiated transfers between different banks is from the 1960s, but the abolition of "float" where each bank would hold on to the money for a business day (night time batch processing) went away in the 80s and 90s.
Try transfering money internationally across banks on different electronic systems. The float still exists.