10 ms·

Hi, Firstly, we don't always need a credential. Some banks provide other auth mechanisms, e.g. EMV CAP. We use this for Barclays and Nationwide. Using Teller m

Hi, Firstly, we don't always need a credential. Some banks provide other auth mechanisms, e.g. EMV CAP. We use this for Barclays and Nationwide. Using Teller might not violate your bank's terms of service, which is why we advise you to read them in conjunction with ours. Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" Secondly, we have ongoing dialogue open with every major UK bank at very senior levels, from C-level down. We want to help banks deliver these APIs. Formal agreements with banks are a key strategic objective for Teller, but they only started returning my calls once I'd broken their apps and took their APIs. The market can't wait for the banks, developers and users want new choices, apps and service now.

pricechild 9y ago
Anecdotally, I've seen banks claim the reason for $something_bad was a virus on a chromebook. Whether or not there's 'been a single case of fraud or loss attributed to "screen-scraping"', I believe most banks are more than happy to blame you by default and make it difficult/expensive to resolve.
- nailer 9y ago
  Most people don't really distinguish between viruses and worms, and there's been worms on Unix systems before (hi RTM!)
- deleted 9y ago
  [deleted]
bowersbros 9y ago
Do you have a mailing list where I can say my bank is with "Halifax let me know when you support them securely?" I'd like something like this, but I wouldn't want to give the bank details away.
Zenst 9y ago
Would be prudent and indeed consumer friendly if you where to go thru those TOS the banks have in conjunction with your own and provide a simple at a glance list of liability/impact. Reassure people that way and shows, you care and thought this thru beyond saying we recommend reading this and that as people are wary and equally might not understand it. Sure would take time and some effort, but would certainly return well for such an effort and as said, people would appreciate that greatly, so can only help you and your business.
- EpicEng 9y ago
  They'd likely be opening themselves up to huge liability if they did that though.
  - diggernet 9y ago
    Far better to leave their users open to huge liability instead, eh?
    - EpicEng 9y ago
      From a business perspective? Yes. If you go out of business it's game over, and it's unreasonable to expect them to provide legal advice. That said, I don't think the business model on display here is tenable at all and I don't think it will be successful. I certainly wouldn't sign on for this, way too risky.
      - resf 9y ago
        On the other hand, if the only way you can stay in business is by deceiving your own customers, what you are running is a scam.
        EpicEng 9y ago
        I wouldn't say they're being deceptive. I don't see them making guarantees, and their ToS is as clear as it is scary.
meredydd 9y ago
This is startup-ese for "Every single one of our users is breaking their bank's ToS, and we maintain plausible deniability by telling them to go and read complex legal documents themselves". I can totally understand the motivation (particularly with PSD2 around the corner, which will mandate banks to provide legit APIs - I'm guessing the plan is to grab market share before that happens). However, I am very skeptical of this approach when applied to finance. Any technical product whose risk profile is "break into us and steal money directly" is a really dangerous place to leave your users on the hook for liability.
- dbbk 9y ago
  To be fair I think there is still going to be a lot of appetite for a service like Teller once PSD2 launches to unify these individual bank APIs. They may not even all work the same way. It'd be much better to have one entry point than develop for multiple different banks' implementation.
  - traviscj 9y ago
    The Stripe business model, basically.
- stouset 9y ago
  Yeah. "No cases of fraud or loss due to screen-scraping" doesn't mean your service isn't going to be the one that leaks a treasure trove of banking credentials. It's also highly probable that it has happened, it just wasn't attributed properly.
  - chirau 9y ago
    Why do you assume everything has already happened? Do you also assume Gmail passwords have already been hacked? Just asking.
    - stouset 9y ago
      Why do you say I think "everything" has already happened? I think it's likely one of these screen-scraping sites that store bank passwords has been breached, and any losses as a result have simply not been attributed to it. I say this having experience in infosec and seeing how comically little companies who should care about security actually do. Often there's not even a single person with infosec experience. And they make every mistake you'd passively learn not to by casually reading HN comments. That's not to say some companies don't get it right. Some (including my current employer) do an extraordinary job. But even teams with solid infosec staff get broken in to. The odds that a site storing large numbers of bank passwords with only a handful of engineers not getting popped sooner rather than later is slim.
EpicEng 9y ago
It sounds to me like you added a lot of detail around a core message of "yes, you may be violating your bank's ToS by using our service, please verify this by reading through page upon page of legalese in your spare time." Well... no thanks. I (and likely many others) would only consider using such a service if I had a guarantee, both from you and my bank, up front. from your ToS: >"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise." Oh geez.
- djsumdog 9y ago
  Yea, unless you're developing jointly with banks, with lots of oversight and liability insurance, this is a disaster waiting to happen.
  - brango 9y ago
    It wouldn't surprise me if it wouldn't stand up in court either. Short of having a huge banner that says "WE WON'T ACCEPT ANY RESPONSIBILITY FOR ANY LOSSES IF YOU USE ARE SERVICES, TYPE 'I AGREE' TO CONTINUE" I imagine someone could probably claim that the risks weren't sufficiently highlighted. There's a reason every investment-related advert has to state that "The value of your investment may go down as well as up", etc.
- dnh44 9y ago
  At least in the U.K. Banks are starting to provide API's so bookkeeping platforms can securely download bank feeds without having to give a 3rd party login credentials.
  - EpicEng 9y ago
    Sure, and when they're in place (well, a US version I suppose) I would consider using a service like this. Until then, no way.
ErrantX 9y ago
> Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. I'm not sure that's the case; I thought the FCA were pretty clear one intent of PSD2 is to stop the need for screen scraping.[1] Have you had any dialogue with OpenBanking UK etc. about their strategy on API driven interactions? 1. https://www.out-law.com/en/articles/2017/february/screen-scraping-to-be-prohibited-under-psd2/ https://www.out-law.com/en/articles/2017/february/screen-scr...
viraptor 9y ago
> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" This response makes me angry. Every service worth attacking will have security problems at some point. You're running a store of bank credentials, which you have to have access to (as opposed to password managers for example which can store user encrypted data). Given enough time, one of these services will get hacked and "this has never happened before" is not going to be a good answer. Someone will be the first one. I'm happy your service will push more banks to provide APIs. But I'm already doing bank screen scraping for myself because I don't trust services which require my credentials. I hope people consider that risk seriously.
- djsumdog 9y ago
  This is what always worried me about services like Mint.
  - curun1r 9y ago
    Mint is probably the one you don't have to worry about. The service that stores credentials and scrapes bank sites is the same one that powers TurboTax and QuickBooks. Intuit spends a lot of money keeping that service secure and they're well aware of how catastrophic a breech would be. In short, that service is run out of private datacenters, not publicly available. You'd have to compromise not just Mint/TurboTax/QuickBooks but then the FICDS service, which only has methods that take a token representing the credentials and passes back transactions, not the actual credentials. It's the competitors to Mint who can't afford their own datacenters and don't have the many millions of dollars to put into securing their service the way Intuit does that should be much more worrisome. Disclaimer: I used to work at Intuit, though not on any of the products I mentioned. But I have had many conversations with the people that run Mint and FICDS and I know the overall architecture used. I give my bank credentials to Mint without any worry. It would probably require a state-level entity to get in, and they'd likely need to get someone hired into that group to facilitate it. The service is very secure.
    - tempestn 9y ago
objclxt 9y ago
> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" Saying "it's never happened before" doesn't in anyway mitigate the attack vector. For what it's worth, there have been cases of fraud attributed to screen scraping, but they don't tend to get publicized. It is pretty telling (no pun intended) that nowhere in your blog post does the word "security" appear, and no details about how you're storing credentials when you do need them. Why should I trust you with a credential from another party if you refuse to tell me how you're actually storing it. > "We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise. This applies if the loss or damage was foreseeable, arose in the normal course of things or you advised us that it might happen." I don't know which solicitor gave you those terms, but they will be laughed out of a court in England as unconscionable. You're not liable for any negligence, even if it's foreseeable or someone told you you were being negligent??
reviseddamage 9y ago
>it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal If that is close to explicitly as you have stated then either 1) The senior bank people you talked to are lying to you 2) the senior bank people you talked to really don't know anything about PSD2 3) They mistated to you how PSD2 changes will affect this 4) You misunderstood what they mentioned about PSD2 changes. If a bank mentions in its clauses as per PSD2, that only authorized persons/firms are use an API and their acccess, they are authorized to negate any liability if it was given/accessed by an unauthorized party. Banks are required to make API's available (not same as accessible) to any SaaS or other developer as long as it is authorized by the bank. Rather than relying on hearsay or in conversation on crucial regulatory changes , might I suggest this: https://www.createspace.com/5772402 https://www.createspace.com/5772402
- steingrd 9y ago
  Banks are not required to give access to any developer or SaaS, but to authorized third parties. Authorized in this context means that the third party obtained an authorization from their local financial authorities, and that the authorization is for the type of service they are requesting (Payment Initiation or Account Information).
PeterisP 9y ago
Credential storing is a big risk. While it may be true that there hasn't been historical fraud attributed to "screen-scraping", what has been seen historically is insider fraud - you pretty much have to expect a certain rate of incidents where your own employees, included tenured ones in high trust positions, will intentionally risk jail time and attempt to steal money; in the finance industry (despite all reasonable precautions) it's not a question of if it will happen, it's a question of how often it'll happen (i.e. if it's 1 incident per annum per 100 employees or if it's 1 incident per annum per 1000 employees), how large will be the impact (most precautions don't prevent the risk as such, but limit the amounts involved), and what are you going to do about it. E.g. the idea that your main technical administrator might sell a database of stored credentials to organized crime; (or get his/her family kidnapped in order to get access to them, that has happened as well) isn't ridiculous fiction, it's a rare but feasible scenario that's more likely to happen than e.g. a datacenter burning down, so what you're going to do in similar cases is quite relevant, not only to your own internal risk analysis but also to your customers. A bank might say "oh, we've got it covered, but if a major hack-event happens, our capital reserves and deposit insurance will still guarantee that you don't lose your savings" - an API company can't fall back on that.
madeofpalk 9y ago
> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" ...how do you know?
- richardknop 9y ago
  Key word is attributed. I guess he means no a single case proved to be caused by screen-scraping and therefor attributed to it. I think it is likely there has been fraud like that though. It just doesn't get reported or even found out.
thwarted 9y ago
We want to help banks deliver these APIs ... The market can't wait for the banks, developers and users want new choices, apps and service now. It was my understanding that the YC-backed company Standard Treasury (acquired by Silicon Valley Bank in 2015) was trying to do this. I don't know where they went with this or what happened (although I believe there was techcrunch write-up about them and the purchase by SVB). Hopefully you can make this work securely because having to navigate a shitty branded (which apparently means constantly changing) web interface to monitor and move money is increasingly frustrating.
- ldn_tech_exec1 9y ago
  The team from Standard Treasury ended up building SVB's virtual card platform.
- dharma1 9y ago
  slight tangent - anybody have a contact at SVB? We are building a better front-end for any bank on top of Teller (or any other banking API) - http://bixtr.com http://bixtr.com. I have some friends who use SVB but they all agree on needing a a much better front-end experience - so would like to help them.
  - sjtgraham 9y ago
    Hey Jouni, meeting them today. Will mention you and connect.
    - dharma1 9y ago
      Thanks Stevie! You rock.
- deleted 9y ago
  [deleted]

pricechild 9y ago

Anecdotally, I've seen banks claim the reason for $something_bad was a virus on a chromebook. Whether or not there's 'been a single case of fraud or loss attributed to "screen-scraping"', I believe most banks are more than happy to blame you by default and make it difficult/expensive to resolve.

nailer 9y ago
Most people don't really distinguish between viruses and worms, and there's been worms on Unix systems before (hi RTM!)
deleted 9y ago
[deleted]

bowersbros 9y ago

Do you have a mailing list where I can say my bank is with "Halifax let me know when you support them securely?" I'd like something like this, but I wouldn't want to give the bank details away.

Zenst 9y ago

Would be prudent and indeed consumer friendly if you where to go thru those TOS the banks have in conjunction with your own and provide a simple at a glance list of liability/impact. Reassure people that way and shows, you care and thought this thru beyond saying we recommend reading this and that as people are wary and equally might not understand it. Sure would take time and some effort, but would certainly return well for such an effort and as said, people would appreciate that greatly, so can only help you and your business.

EpicEng 9y ago
They'd likely be opening themselves up to huge liability if they did that though.
- diggernet 9y ago
  Far better to leave their users open to huge liability instead, eh?
  - EpicEng 9y ago
    From a business perspective? Yes. If you go out of business it's game over, and it's unreasonable to expect them to provide legal advice. That said, I don't think the business model on display here is tenable at all and I don't think it will be successful. I certainly wouldn't sign on for this, way too risky.
    - resf 9y ago
      On the other hand, if the only way you can stay in business is by deceiving your own customers, what you are running is a scam.
      - EpicEng 9y ago
        I wouldn't say they're being deceptive. I don't see them making guarantees, and their ToS is as clear as it is scary.

meredydd 9y ago

This is startup-ese for "Every single one of our users is breaking their bank's ToS, and we maintain plausible deniability by telling them to go and read complex legal documents themselves". I can totally understand the motivation (particularly with PSD2 around the corner, which will mandate banks to provide legit APIs - I'm guessing the plan is to grab market share before that happens). However, I am very skeptical of this approach when applied to finance. Any technical product whose risk profile is "break into us and steal money directly" is a really dangerous place to leave your users on the hook for liability.

dbbk 9y ago
To be fair I think there is still going to be a lot of appetite for a service like Teller once PSD2 launches to unify these individual bank APIs. They may not even all work the same way. It'd be much better to have one entry point than develop for multiple different banks' implementation.
- traviscj 9y ago
  The Stripe business model, basically.
stouset 9y ago
Yeah. "No cases of fraud or loss due to screen-scraping" doesn't mean your service isn't going to be the one that leaks a treasure trove of banking credentials. It's also highly probable that it has happened, it just wasn't attributed properly.
- chirau 9y ago
  Why do you assume everything has already happened? Do you also assume Gmail passwords have already been hacked? Just asking.
  - stouset 9y ago
    Why do you say I think "everything" has already happened? I think it's likely one of these screen-scraping sites that store bank passwords has been breached, and any losses as a result have simply not been attributed to it. I say this having experience in infosec and seeing how comically little companies who should care about security actually do. Often there's not even a single person with infosec experience. And they make every mistake you'd passively learn not to by casually reading HN comments. That's not to say some companies don't get it right. Some (including my current employer) do an extraordinary job. But even teams with solid infosec staff get broken in to. The odds that a site storing large numbers of bank passwords with only a handful of engineers not getting popped sooner rather than later is slim.

EpicEng 9y ago

It sounds to me like you added a lot of detail around a core message of "yes, you may be violating your bank's ToS by using our service, please verify this by reading through page upon page of legalese in your spare time." Well... no thanks. I (and likely many others) would only consider using such a service if I had a guarantee, both from you and my bank, up front. from your ToS: >"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise." Oh geez.

djsumdog 9y ago
Yea, unless you're developing jointly with banks, with lots of oversight and liability insurance, this is a disaster waiting to happen.
- brango 9y ago
  It wouldn't surprise me if it wouldn't stand up in court either. Short of having a huge banner that says "WE WON'T ACCEPT ANY RESPONSIBILITY FOR ANY LOSSES IF YOU USE ARE SERVICES, TYPE 'I AGREE' TO CONTINUE" I imagine someone could probably claim that the risks weren't sufficiently highlighted. There's a reason every investment-related advert has to state that "The value of your investment may go down as well as up", etc.
dnh44 9y ago
At least in the U.K. Banks are starting to provide API's so bookkeeping platforms can securely download bank feeds without having to give a 3rd party login credentials.
- EpicEng 9y ago
  Sure, and when they're in place (well, a US version I suppose) I would consider using a service like this. Until then, no way.

ErrantX 9y ago

> Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. I'm not sure that's the case; I thought the FCA were pretty clear one intent of PSD2 is to stop the need for screen scraping.[1] Have you had any dialogue with OpenBanking UK etc. about their strategy on API driven interactions? 1. https://www.out-law.com/en/articles/2017/february/screen-scraping-to-be-prohibited-under-psd2/ https://www.out-law.com/en/articles/2017/february/screen-scr...

viraptor 9y ago

> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" This response makes me angry. Every service worth attacking will have security problems at some point. You're running a store of bank credentials, which you have to have access to (as opposed to password managers for example which can store user encrypted data). Given enough time, one of these services will get hacked and "this has never happened before" is not going to be a good answer. Someone will be the first one. I'm happy your service will push more banks to provide APIs. But I'm already doing bank screen scraping for myself because I don't trust services which require my credentials. I hope people consider that risk seriously.

djsumdog 9y ago
This is what always worried me about services like Mint.
- curun1r 9y ago
  Mint is probably the one you don't have to worry about. The service that stores credentials and scrapes bank sites is the same one that powers TurboTax and QuickBooks. Intuit spends a lot of money keeping that service secure and they're well aware of how catastrophic a breech would be. In short, that service is run out of private datacenters, not publicly available. You'd have to compromise not just Mint/TurboTax/QuickBooks but then the FICDS service, which only has methods that take a token representing the credentials and passes back transactions, not the actual credentials. It's the competitors to Mint who can't afford their own datacenters and don't have the many millions of dollars to put into securing their service the way Intuit does that should be much more worrisome. Disclaimer: I used to work at Intuit, though not on any of the products I mentioned. But I have had many conversations with the people that run Mint and FICDS and I know the overall architecture used. I give my bank credentials to Mint without any worry. It would probably require a state-level entity to get in, and they'd likely need to get someone hired into that group to facilitate it. The service is very secure.
  - tempestn 9y ago

objclxt 9y ago

> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" Saying "it's never happened before" doesn't in anyway mitigate the attack vector. For what it's worth, there have been cases of fraud attributed to screen scraping, but they don't tend to get publicized. It is pretty telling (no pun intended) that nowhere in your blog post does the word "security" appear, and no details about how you're storing credentials when you do need them. Why should I trust you with a credential from another party if you refuse to tell me how you're actually storing it. > "We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise. This applies if the loss or damage was foreseeable, arose in the normal course of things or you advised us that it might happen." I don't know which solicitor gave you those terms, but they will be laughed out of a court in England as unconscionable. You're not liable for any negligence, even if it's foreseeable or someone told you you were being negligent??

reviseddamage 9y ago

>it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal If that is close to explicitly as you have stated then either 1) The senior bank people you talked to are lying to you 2) the senior bank people you talked to really don't know anything about PSD2 3) They mistated to you how PSD2 changes will affect this 4) You misunderstood what they mentioned about PSD2 changes. If a bank mentions in its clauses as per PSD2, that only authorized persons/firms are use an API and their acccess, they are authorized to negate any liability if it was given/accessed by an unauthorized party. Banks are required to make API's available (not same as accessible) to any SaaS or other developer as long as it is authorized by the bank. Rather than relying on hearsay or in conversation on crucial regulatory changes , might I suggest this: https://www.createspace.com/5772402 https://www.createspace.com/5772402

steingrd 9y ago
Banks are not required to give access to any developer or SaaS, but to authorized third parties. Authorized in this context means that the third party obtained an authorization from their local financial authorities, and that the authorization is for the type of service they are requesting (Payment Initiation or Account Information).

PeterisP 9y ago

Credential storing is a big risk. While it may be true that there hasn't been historical fraud attributed to "screen-scraping", what has been seen historically is insider fraud - you pretty much have to expect a certain rate of incidents where your own employees, included tenured ones in high trust positions, will intentionally risk jail time and attempt to steal money; in the finance industry (despite all reasonable precautions) it's not a question of if it will happen, it's a question of how often it'll happen (i.e. if it's 1 incident per annum per 100 employees or if it's 1 incident per annum per 1000 employees), how large will be the impact (most precautions don't prevent the risk as such, but limit the amounts involved), and what are you going to do about it. E.g. the idea that your main technical administrator might sell a database of stored credentials to organized crime; (or get his/her family kidnapped in order to get access to them, that has happened as well) isn't ridiculous fiction, it's a rare but feasible scenario that's more likely to happen than e.g. a datacenter burning down, so what you're going to do in similar cases is quite relevant, not only to your own internal risk analysis but also to your customers. A bank might say "oh, we've got it covered, but if a major hack-event happens, our capital reserves and deposit insurance will still guarantee that you don't lose your savings" - an API company can't fall back on that.

madeofpalk 9y ago

> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping" ...how do you know?

richardknop 9y ago
Key word is attributed. I guess he means no a single case proved to be caused by screen-scraping and therefor attributed to it. I think it is likely there has been fraud like that though. It just doesn't get reported or even found out.

thwarted 9y ago

We want to help banks deliver these APIs ... The market can't wait for the banks, developers and users want new choices, apps and service now. It was my understanding that the YC-backed company Standard Treasury (acquired by Silicon Valley Bank in 2015) was trying to do this. I don't know where they went with this or what happened (although I believe there was techcrunch write-up about them and the purchase by SVB). Hopefully you can make this work securely because having to navigate a shitty branded (which apparently means constantly changing) web interface to monitor and move money is increasingly frustrating.

ldn_tech_exec1 9y ago
The team from Standard Treasury ended up building SVB's virtual card platform.
dharma1 9y ago
slight tangent - anybody have a contact at SVB? We are building a better front-end for any bank on top of Teller (or any other banking API) - http://bixtr.com http://bixtr.com. I have some friends who use SVB but they all agree on needing a a much better front-end experience - so would like to help them.
- sjtgraham 9y ago
  Hey Jouni, meeting them today. Will mention you and connect.
  - dharma1 9y ago
    Thanks Stevie! You rock.
deleted 9y ago
[deleted]