Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
The Almighty Buck Businesses Cloud Databases Government Network Operating Systems Programming Social Networks Software The Internet Wireless Networking IT Technology Build

Is Old Tech Putting Banks Under Threat Of Extinction? (bbc.co.uk) 208

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...
This discussion has been archived. No new comments can be posted.

Is Old Tech Putting Banks Under Threat Of Extinction?

Comments Filter:
  • is Killing banks faster.
    • Re:the War on Cash (Score:5, Interesting)

      by Z00L00K ( 682162 ) on Saturday March 26, 2016 @04:41AM (#51781271) Homepage Journal

      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.

      • Re:the War on Cash (Score:5, Insightful)

        by arth1 ( 260657 ) on Saturday March 26, 2016 @07:56AM (#51781587) Homepage Journal

        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.

        • by Z00L00K ( 682162 )

          Ada is at least object oriented from the beginning, so that language may still be useful.

          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.

          • by arth1 ( 260657 )

            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.

            • Learning the language is not the problem, it's the framework. Think about J2EE. Java is easy to learn if you already understood OOP. But J2EE is very difficult to learn because of all the frameworks that can be and must be used with it. COBOL is the same way today but it's far worse because each company over decades created their own way of building solutions to the same problems. Then you have the MF itself and all the tools that are either custom made or bastardized versions of vendor crap. Learning COBOL
        • Re: (Score:2, Interesting)

          by Anonymous Coward

          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 we

          • That's why I switched to a Credit Union. They are happy to see me, everything is updated in real time, and open when I need them.

        • by sjames ( 1099 )

          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.

          • by arth1 ( 260657 )

            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.

            One word: Cambio

            If you know you can put in a big transaction before a new exchange rate goes into effect, you can make or save millions. Much like knowing you can get a last bid in before a bourse closes. The people at the other end are not going to give you old rates or reopen a bourse because someone ran a tough query at your end which delayed your transaction.
            Fast is good, guaranteed is better.

            • If you know you can put in a big transaction before a new exchange rate goes into effect, you can make or save millions.

              Make or save *millions* ... thanks. Good advice for all of us here on /. :-)

            • by sjames ( 1099 )

              That's actually a good argument for introducing random delays in transaction systems.

      • Re:the War on Cash (Score:5, Insightful)

        by BitZtream ( 692029 ) on Saturday March 26, 2016 @08:38AM (#51781717)

        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.

        • Spot on with your comments. And in a modern DevOps environment, you dont need to treat the Mainframe Developers (and their associated Ops colleagues) any different to the Java (or similar) guys. Put them all together and get them collaborating and treat the Mainframe like any other Server (albeit with a bit more care). There are enough people out there looking for jobs that you can get a code academy to train some junior COBOL devs for you or x-train some of the Java guys. The offshore guys in Eastern Euro
      • "Banks makes money on lending money to people and collecting interest on that money."

        In the past that was their primary income stream. Nowadays it is, very roughly, split about 50/50 between interest income and non-interest income. The latter would include transaction fees, penalty fees, insured devices, safety deposit boxes, etc.

        http://seekingalpha.com/article/1568752-bank-chart-of-the-week-how-important-is-fee-income-to-banks
        https://chicagofed.org/~/media/publications/economic-perspectives/2004/ep-4qtr200

    • Re:the War on Cash (Score:5, Interesting)

      by JaredOfEuropa ( 526365 ) on Saturday March 26, 2016 @04:50AM (#51781289) Journal
      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.
    • A bank is simply an IT business with ridiculously high usage fees. The 'war on cash' is another way for banks to skim money off every transaction.
  • unlike what is implied here, main business of banks is extending credit (iow loaning money)at interest. money obtained through variety of means, mainly deposits.
    and loaning money can be only partially subjected to automation, and usually require lot of human interactions and long term relationships, and lots of specific customization. that is why small banks and banks branches still continue to exist .

    that is also why technology wont make banks obsolete anytime soon. if bank lose deposit taking due to tech

  • bollocks (Score:5, Interesting)

    by Anonymous Coward on Saturday March 26, 2016 @04:46AM (#51781283)

    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.

  • by Archtech ( 159117 ) on Saturday March 26, 2016 @05:46AM (#51781357)

    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/... [wikipedia.org] 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,

    • by cyber-vandal ( 148830 ) on Saturday March 26, 2016 @06:28AM (#51781409) Homepage

      The Microsoft Azure cloud comment did make me laugh but if you think bank systems are well designed I've got a bridge to sell you.

      IBM's architecture is solid but the banks have 40-50 years of terrible ideas and shit code held together with duct tape and chewing gum.

      As it gets harder to find COBOL developers because people like me were discarded for having the nerve to want to be paid well we're going to start seeing some serious banking problems as a lack of staff forces system upgrades.

      Either that or the banks will need to offer us huge incentives to come back much like they had to when the Y2K bug could no longer be ignored and they'd "rightsized" too many people.

      • by Archtech ( 159117 ) on Saturday March 26, 2016 @07:07AM (#51781497)

        IBM's architecture is solid but the banks have 40-50 years of terrible ideas and shit code held together with duct tape and chewing gum.

        Fair enough; I admit my knowledge is more of the systems and software than of the applications the banks have written. But Wall had nothing to say about the bank applications and their quality. I addressed the issues he did seem to touch on.

        As it gets harder to find COBOL developers because people like me were discarded for having the nerve to want to be paid well we're going to start seeing some serious banking problems as a lack of staff forces system upgrades.

        Yes, I can well believe that. The technical problems are rarely insoluble - whether it's a banking system or the Space Shuttle. It's the failure of executives and other decision-makers the understand computing that causes most of the trouble. I once met an IT recruitment company CEO who, quite seriously, told me that programmers were "like bricklayers". In other words, the difficult part was done by analysts and the like, and the programmers simply had to "code up" their designs. I managed to refrain from assaulting him, although it was difficult. FWIW, in my opinion it's more accurate to compare programmers to lawyers (at a coarse level, in terms of the difficulty, level of abstraction and appropriate pay level). But then lawyers are paid to obfuscate and confuse matters, whereas programmers do the opposite. No contest.

      • Re: (Score:3, Insightful)

        by Archtech ( 159117 )

        Either that or the banks will need to offer us huge incentives to come back much like they had to when the Y2K bug could no longer be ignored and they'd "rightsized" too many people.

        But the difficulties of completely redesigning and reimplementing all those systems would make the Y2K bug look like just that - a tiny bug. When writing about that issue in about 1998 I asked Jerry Weinberg when he had first come across it. He replied that he had been warning management about the Y2K issue from the 1970s on.

        If businesses were to focus on a core competency - the way Unix software tools are supposed to - their IT problems would automatically be greatly reduced. And if banks went back to bein

        • the difficulties of completely redesigning and reimplementing all those systems would make the Y2K bug look like just that - a tiny bug.

          Probably correct - or more organisations would have taken the "build a new one that's shiny with stripes" option.

      • As it gets harder to find COBOL developers because people like me were discarded for having the nerve to want to be paid well we're going to start seeing some serious banking problems as a lack of staff forces system upgrades.

        Either that or the banks will need to offer us huge incentives to come back much like they had to when the Y2K bug could no longer be ignored and they'd "rightsized" too many people.

        Don't worry. A quick call to TCS and the bank will be assured that they have many fine developers skilled in COBOL that can do the needful.

    • If they've been chugging along for 60 years they must be slow, or they'd have finished by now!

    • is two fold. First, the Indians know Java, and most of the mainframe code is Cobol. if you want cheap programmers you have to start moving it to Java. Plus the old Cobol programmers are dying/retiring and companies in America are loath to train. Half the reason they want the Indians is their trained overseas for peanuts on their own dime.

      The other problem is they were built and their software written when space was at an absolute premium. Some of the systems can't handle the really large transactions ba
      • by KGIII ( 973947 )

        I can't be the last old-guy here. I've seen it throughout the thread so you're not alone. It's COBOL. It stands for something like COmmon Business Oriented Language. Something like that, at any rate. I played with it years and years ago - actually after I'd played with BASIC. I want to say that I played with it in about 1987 or 1988.

        I don't remember what it was about it that I didn't like but the fact remains that I didn't like it. I think it was that it was tough to read, as a human, that made me dislike i

    • by KGIII ( 973947 )

      Oh, and Matthew - "The definition of 'a legacy system' is one that works".

      That, that right there was beautiful. I'm going to say, "for some definition of works." However, that's a topic for another day.

      I love a good novella - more so when it's one that is spot on and written by someone other than I.

    • by dhaen ( 892570 )
      Interestingly the article links to two startups, who presumably will have got a lot of hits.
  • No. (Score:3, Insightful)

    by Required Snark ( 1702878 ) on Saturday March 26, 2016 @06:02AM (#51781385)
    Next question?
  • >"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?"

    You wait until it is back up in a few hours or try tomorrow because you are not stupid enough to run COMPLETELY out of cash before going to get more. It is called "responsibility".

  • The bigger problem with the banks right now is that it is nearly impossible to get a savings account (or CD) that has an interest rate above the inflation rate. If the banks can't provide an incentive for people to keep their money there, then why would people do it? Sure a lot of people don't want to carry large amounts of money on them regularly, but most people don't need a large amount of money on them at any given time. They can keep the rest under the mattress and do just as well.
    • Why borrow from depositors at interest rates that are higher than the central banks will loan? If I have to pay Joe Average 3% on his money that I'm using (and I can't use all of it, anyway), but only 0.25% on money I can get from the central bank (and can use all of it), why pay Joe? In fact, I'll pay him a pittance just to keep him around (it's better than nothing, right?) because maybe I can sell him a credit card account or mortgage and make some more money off of him - after all, I'm awash in the nea
  • by flopsquad ( 3518045 ) on Saturday March 26, 2016 @07:42AM (#51781563)

    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.

  • by maple_shaft ( 1046302 ) on Saturday March 26, 2016 @09:23AM (#51781865)
    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.
    • Certainly in the UK, a awful lot of good people do contracting rather than sticking with one company. Your superb dissection of what's wrong helps me understand why! I hope your escape tunnel building is going well; by the sounds of it you need it.
    • No, I think the reason these projects almost always fail the bank is the architects of such systems don't understand basic grammar, like the use of paragraphs.
  • is use one of the 5 other Credit Cards I have that have lines of credit available that route through a different network. Worst case scenario I pay an extra 2% to borrow the cash for a few days. I'm also going to plan my purchases and bill payments around bank systems crashing and occasionally argue with customer service to get a late fee waived when they couldn't automatically bill my bank account and I didn't notice until I got a text message & and email telling me I'm over due. And because I'm a good
  • Here's to hoping those bastions of evil go extinct!
  • Legacy hardware is really hard to move from. It can feel impossible at times. But survival is a powerful motivator.

    It's really, really expensive to move off old hardware, but it's not impossible. If it becomes a matter of life or death of the organization, things will get done. If they don't, the organization dies, and someone else steps in to fill the void. In that case, death was inevitable and necessary. The world does not end.

  • I've occasionally gone to an ATM that wasn't working. I've occasionally tried to log on to my bank's Web site, to find that the site was down. These events were annoying, but not catastrophic. I found another ATM, and waited a few minutes for the site to come back up.

    There is little evidence that things are getting worse. Quoting some guy at Accenture saying that it's getting worse, doesn't make it so. My experience is just the opposite--electronic and ATM transactions seem to be getting easier and mor

  • But you need money fast, so what do you do?

    Um... don't live your life so close to the edge of an empty wallet? Carry a credit card? Any number of things, really, except relying on your bank's ATM to be your personal ATM - so to speak.

  • And it's already happening.

    They'll either fund or spin off new "hip and modern" banks targeted at urban millennials. These banks won't have branches. Everything will be done online. If you need cash, they'll have a relationship with the ATM networks that serve credit unions*, so as to cut down on the fees. But you won't want to use cash. You'll use your card for everything, because you'll get points and you'll automagically track all of your expenses into categories and budgets via their iPhone app. A

Genius is ten percent inspiration and fifty percent capital gains.

Working...