4 ms·

Screen-scraping is how it's still done, even internally, within banks. I'm told it's the easiest way to get data out of systems.

by jasiek 10y ago

ethbro 10y ago
Aye. If you want to see some aged infrastructure, dig down to the bottom of banking's tech stack.
- saiya-jin 10y ago
  the reason is simple - IT is considered just annoying cost center that prevents rest of the bank to reach the stars... or something. budgeting reflects this accordingly
  - dukeluke 10y ago
    Well they've gotten by with this archaic IT infrastructure with massive profits, so maybe they're onto something.
    - branchless 10y ago
      Yes: usury to appropriate wealth. They have a monopoly on money creation.
      - simonh 10y ago
        If multiple banks can do this and they all compete with each other, and do so under governmental regulation, that really isn't a monopoly.
      - kpil 10y ago
        Actually, in EU almost anyone with a little bit of money could start a financial institute that would be able to lend money to people using real estate as security, backed by the central banks. The more complicated bank licence is needed to lend money from people. I'm not sure about U.S though.
  - cr0sh 10y ago
    I doubt that's the reason - or at least not the main reason. The main reason is legacy: Banks and other financial institutions are among the oldest users of computer systems (I would not hesitate to say that certain banks even utilized Hollerith tabulating systems; they certainly likely used tabulating and other accounting machines made by the early IBM). Code in these institutions likely consists (in a large part) of many lines of COBOL (and possibly other archaic languages - I wouldn't doubt there is some old RPG lurking around). You might ask "well, they could just translate the code or rewrite it" - but it probably isn't that simple. Over time, what we now call "technical debt" built up in a massive way. They fixed and patched and fixed some more, and probably comments don't match the code, and there likely isn't a singular design document or API description anywhere that shows what the system is actually doing (and any that does exist probably doesn't match what is actually happening). Coders came and went, most are probably dead now. But that code is the baseline for how the system works, warts and all. Heck - there's probably code in there that works around bugs in older COBOL compilers or who knows what else. They keep this around - probably emulation on top of emulation - because to refactor all of this would take a super-human level of dedication and effort, and likely introduce new bugs along the way. In fact, there are likely still a ton of "edge case" bugs lurking deep inside that have yet to be found. It may be that fixing these bugs (if found during a refactor, say) might break other working code that depends upon them existing! Even if the refactor were successful, they would still only get to the point of having a system that does everything it currently does (but still may have unknown bugs). You're right that there isn't a financial incentive to fix it. In fact, the opposite is likely, because if fixing it breaks something, in even a subtle way (and that would be worse than anything, because something like a small rounding error might go easily unnoticed until far too late) - it could end up costing the business so much money as to ruin them. I can't really blame them for being so hesitant about such a change. This kind of legacy affects all kinds of businesses and institutions, especially the ones that are quasi-considered "foundational" to society, and hence are likely to be among the oldest users of computer, transaction processing, and accounting systems. A few others I can think of would be accounting firms, logistics (especially railroads - as they were among the first to use Hollerith's systems after the 1890 census), air traffic control (we've already seen this system try to be updated - and fail), airline ticketing (arguably maybe second oldest - how old is SABRE?), insurance... None though - with the exception of the ATC systems - have the same level of repercussions to happen should a new system not perform and act the same as the old system(s) currently in place.
  - jasiek 10y ago
    There's very little appetite for building expertise in house. If it can be outsourced to one of the big four, it will be.
    - dandermotj 10y ago
      Big four employee outsourced to big bank. The lack of in-house knowledge is always troubling. Also screen scraping data and automating processes by having a program take control of the mouse/keyboard and click/type is a big seller to banks.
      - ethbro 10y ago
        My favorite lack of in-house knowledge is the mysterious but commonly used system acronym. You'd think "What does this stand for?" would be a question someone could always readily answer.
      - jasiek 10y ago
        The effect of this strategy is similar to what happens in government - you have IT directors, who actually know very little about IT, but know they have $X to spend to solve problem Y. There is a number of companies who will gladly state they will solve problem Y for approximately $X. It creates this weird, self-reinforcing relationship.
  - kpil 10y ago
    I think this has historically been the main reason. The computers where introduces to reduce the operational costs, and that mentality has stuck. But I think most banks have realized that they need to do something, lest they will end up the non-significant bill for the infrastructure but a dwindling list of services that they can make money on. Regarding third party screen-scrapers, from what I can see there are challenges both in the legal framework and technical issues like security and performance.

Screen-scraping is how it's still done, even internally, within banks. I'm told it's the easiest way to get data out of systems.

by jasiek 10y ago

Screen-scraping is how it's still done, even internally, within banks. I'm told it's the easiest way to get data out of systems.

ethbro 10y ago

Aye. If you want to see some aged infrastructure, dig down to the bottom of banking's tech stack.

saiya-jin 10y ago
the reason is simple - IT is considered just annoying cost center that prevents rest of the bank to reach the stars... or something. budgeting reflects this accordingly
- dukeluke 10y ago
  Well they've gotten by with this archaic IT infrastructure with massive profits, so maybe they're onto something.
  - branchless 10y ago
    Yes: usury to appropriate wealth. They have a monopoly on money creation.
    - simonh 10y ago
      If multiple banks can do this and they all compete with each other, and do so under governmental regulation, that really isn't a monopoly.
    - kpil 10y ago
      Actually, in EU almost anyone with a little bit of money could start a financial institute that would be able to lend money to people using real estate as security, backed by the central banks. The more complicated bank licence is needed to lend money from people. I'm not sure about U.S though.
- cr0sh 10y ago
  I doubt that's the reason - or at least not the main reason. The main reason is legacy: Banks and other financial institutions are among the oldest users of computer systems (I would not hesitate to say that certain banks even utilized Hollerith tabulating systems; they certainly likely used tabulating and other accounting machines made by the early IBM). Code in these institutions likely consists (in a large part) of many lines of COBOL (and possibly other archaic languages - I wouldn't doubt there is some old RPG lurking around). You might ask "well, they could just translate the code or rewrite it" - but it probably isn't that simple. Over time, what we now call "technical debt" built up in a massive way. They fixed and patched and fixed some more, and probably comments don't match the code, and there likely isn't a singular design document or API description anywhere that shows what the system is actually doing (and any that does exist probably doesn't match what is actually happening). Coders came and went, most are probably dead now. But that code is the baseline for how the system works, warts and all. Heck - there's probably code in there that works around bugs in older COBOL compilers or who knows what else. They keep this around - probably emulation on top of emulation - because to refactor all of this would take a super-human level of dedication and effort, and likely introduce new bugs along the way. In fact, there are likely still a ton of "edge case" bugs lurking deep inside that have yet to be found. It may be that fixing these bugs (if found during a refactor, say) might break other working code that depends upon them existing! Even if the refactor were successful, they would still only get to the point of having a system that does everything it currently does (but still may have unknown bugs). You're right that there isn't a financial incentive to fix it. In fact, the opposite is likely, because if fixing it breaks something, in even a subtle way (and that would be worse than anything, because something like a small rounding error might go easily unnoticed until far too late) - it could end up costing the business so much money as to ruin them. I can't really blame them for being so hesitant about such a change. This kind of legacy affects all kinds of businesses and institutions, especially the ones that are quasi-considered "foundational" to society, and hence are likely to be among the oldest users of computer, transaction processing, and accounting systems. A few others I can think of would be accounting firms, logistics (especially railroads - as they were among the first to use Hollerith's systems after the 1890 census), air traffic control (we've already seen this system try to be updated - and fail), airline ticketing (arguably maybe second oldest - how old is SABRE?), insurance... None though - with the exception of the ATC systems - have the same level of repercussions to happen should a new system not perform and act the same as the old system(s) currently in place.
- jasiek 10y ago
  There's very little appetite for building expertise in house. If it can be outsourced to one of the big four, it will be.
  - dandermotj 10y ago
    Big four employee outsourced to big bank. The lack of in-house knowledge is always troubling. Also screen scraping data and automating processes by having a program take control of the mouse/keyboard and click/type is a big seller to banks.
    - ethbro 10y ago
      My favorite lack of in-house knowledge is the mysterious but commonly used system acronym. You'd think "What does this stand for?" would be a question someone could always readily answer.
    - jasiek 10y ago
      The effect of this strategy is similar to what happens in government - you have IT directors, who actually know very little about IT, but know they have $X to spend to solve problem Y. There is a number of companies who will gladly state they will solve problem Y for approximately $X. It creates this weird, self-reinforcing relationship.
- kpil 10y ago
  I think this has historically been the main reason. The computers where introduces to reduce the operational costs, and that mentality has stuck. But I think most banks have realized that they need to do something, lest they will end up the non-significant bill for the infrastructure but a dwindling list of services that they can make money on. Regarding third party screen-scrapers, from what I can see there are challenges both in the legal framework and technical issues like security and performance.