6 ms·

I used to work in banking security and I can understand the bank's concerns. If they allow a 3rd party access to customer data and that customer data is subseq

I used to work in banking security and I can understand the bank's concerns. If they allow a 3rd party access to customer data and that customer data is subsequently leaked and used for fraud, who's liable? If a law could codify an acceptable answer to that problem, I think a lot of the security/regulatory problems could go away. Banks might still try to stop the process for competitive reasons, but they might not be able to lean on the crutch of "security" to do so. In the UK this problem isn't new, there were aggregator services 15 years ago that screen-scraped banking data to provide customers with a consolidated view of their finances and they required customer's to provide their credentials for them to do that. Banks understandably weren't too pleased about the idea of 3rd parties having those credentials.

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.
tyfon 10y ago
In Norway it is quite clear who is liable, the 3rd party. Anyone that holds personal data needs to acquire a license to do so from Datatilsynet (data protection authority) and they can only use it for the purpose specified/granted in the license. Most of the banks here just provide downloadable csv/excel files after logging in with BankID (national electronic ID thing, https://www.bankid.no/en/company/ https://www.bankid.no/en/company/). If you upload that file to a 3rd party, the 3rd party still needs a license etc to keep/process it and is liable.
- lucaspiller 10y ago
  I'd argue the same would be true in the UK too - under the Data Protection Act, any company who holds personal information is required to register with a government authority [0], and the act makes it fairly clear what responsibilities and actions need to be taken regarding the handling of data. https://ico.org.uk/for-organisations/register/ https://ico.org.uk/for-organisations/register/
  - grabeh 10y ago
    It's a little bit more nuanced than that. The Act places an obligation on data controllers to register and to comply with the various obligations under the Act. This excludes data processors (with controllers then making sure they place relevant obligations on controllers contractually). Potentially a service provider might argue they're a data processor although if they're taking decisions over how the data is used they could easily fall within the data controller category. Under current law, it's the data controller who would be liable for any loss of data (although they would normally look to cover off liability contractually with the processor). In any event, liability really depends on who is taking the decisions over the use of the data. If the third party just takes a feed of the data from the bank then takes various decisions over its use, they could well be a data controller. If on the other hand a bank contracts with a third party to provide an account aggregation service to its customers and they are passing data for this very specific purpose then the service provider could well just be a processor. The above is also going to change with the new General Data Protection Regulation coming into force next year...
- 10y ago
xioxox 10y ago
In Germany, we have something called SOFORT Überweisung which logs into your bank account to do online payments. As a non-German, I'm not sure how this is allowed, but it seems to be long-standing business. I don't think most of the banks like it, though.
- deleted 10y ago
  [deleted]

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.

tyfon 10y ago

In Norway it is quite clear who is liable, the 3rd party. Anyone that holds personal data needs to acquire a license to do so from Datatilsynet (data protection authority) and they can only use it for the purpose specified/granted in the license. Most of the banks here just provide downloadable csv/excel files after logging in with BankID (national electronic ID thing, https://www.bankid.no/en/company/ https://www.bankid.no/en/company/). If you upload that file to a 3rd party, the 3rd party still needs a license etc to keep/process it and is liable.

lucaspiller 10y ago
I'd argue the same would be true in the UK too - under the Data Protection Act, any company who holds personal information is required to register with a government authority [0], and the act makes it fairly clear what responsibilities and actions need to be taken regarding the handling of data. https://ico.org.uk/for-organisations/register/ https://ico.org.uk/for-organisations/register/
- grabeh 10y ago
  It's a little bit more nuanced than that. The Act places an obligation on data controllers to register and to comply with the various obligations under the Act. This excludes data processors (with controllers then making sure they place relevant obligations on controllers contractually). Potentially a service provider might argue they're a data processor although if they're taking decisions over how the data is used they could easily fall within the data controller category. Under current law, it's the data controller who would be liable for any loss of data (although they would normally look to cover off liability contractually with the processor). In any event, liability really depends on who is taking the decisions over the use of the data. If the third party just takes a feed of the data from the bank then takes various decisions over its use, they could well be a data controller. If on the other hand a bank contracts with a third party to provide an account aggregation service to its customers and they are passing data for this very specific purpose then the service provider could well just be a processor. The above is also going to change with the new General Data Protection Regulation coming into force next year...
10y ago

xioxox 10y ago

In Germany, we have something called SOFORT Überweisung which logs into your bank account to do online payments. As a non-German, I'm not sure how this is allowed, but it seems to be long-standing business. I don't think most of the banks like it, though.

deleted 10y ago
[deleted]