If some fraud was to come about as a result of someone using Teller then they would be out of pocket or has Teller got agreements with the compatible banks to overcome this situation (either by Teller reimbursing the customer or the bank)?
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.
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.
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.
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??
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.
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.
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.
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.
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
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-scr...
I'd like something like this, but I wouldn't want to give the bank details away.
...how do you know?
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.
I can't even count how many promising-looking Fintech products I had to pass over because the only auth mechanism they offered was through sharing online banking credentials.
Until bank policies regarding credentials-sharing actually change, I think it's really irresponsible for products to even ask for credentials at all, let alone offer it as the default/only auth option. Users could be unwittingly putting their entire life savings at risk.
Is this a realistic concern? I thought the point of a bank was that situations like that can be reversed 100% of the time.
I'm personally waiting for the PSD II law to be deployed (see https://blog.teller.io/2016/04/26/tauth.html) in order to have clear-cut protections & boundaries, before leveraging Bankin or similar (Teller) as a SaaS product builder.
Reverse engineering mobile APIs is a superior strategy to screen-scraping because:
- they already return structured data
- the security model for that channel is different, e.g. no need for 2FA all the time so truly unattended use cases are possible
- it's much more difficult for banks to make breaking changes. When banks do make a breaking change the old version is supported for a decent amount of time to allow their own banking app users to upgrade, we can take advantage of this window to provide a consistent level of service.
Finally, we often don't need user credentials. If there is an option to authenticate with another mechanism during registration, e.g. EMV CAP (A.K.A Barclays PINSentry etc) we use that.
Also, will your reverse-engineered use of the mobile API's have any detrimental effect on the user? I imagine the user will be the one authenticated with the API, what if the bank starts to see an influx of odd API traffic and decides to investigate it or there is some type of rate limit?
Your decision to reverse-engineer mobile API's opens the door for many important questions in my opinion.
What happens if the banks realize you're doing this and just block your IPs? What happens if they decide to go after you legally because you reverse engineered their applications and are benefiting from it commercially - you'd have a decent argument, but are you prepared to go to court with it?
Then again I guess the screen scrapers have gotten away with it for a fairly long amount of time, so maybe it's not a concern...
This is so insanely risky...
The US is a long ways away from having this.
This is the case for Barclays, for example, where in fact once the mobile app is registered, that can be used as a Pinsentry (2FA) device replacement.
The non-machine-readable german-language-only API specification consist of >800 pages spread across various PDFs[1] full of gibberish. There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.
[1]
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/FinT...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
Besides, that does not explain, why none of the other banks can get their act together. If FinTS is too difficult to implement, how come they are not offering something simpler?
Sounds just like any other API, from most REST APIs to messengers.
HBCI is a lot better designed, and a lot easier to work with than the many different messengers that exist on phones nowadays. Everything is documented, everything is specified, and you have a stable API. Try getting something like this for Facebook Messenger, Allo, Duo, WhatsApp, Signal, Riot, all at once.
HBCI is bad, but it's a rare gem. Usually, when many major corporations have similar products, they try to prevent any such APIs from being created at all.
> non-machine-readable
I'm not sure I've seen any major API that's machine readable. Most major APIs don't have any machine-readable specifications publicly available. They probably have them internally, but almost never publicly.
> german-language-only
That's not really an issue, if you're in Germany. I don't go into the US and expect their banks to provide their specifications in English either. I realize that English has become the lingua franca in IT, but that's not a good thing.
Ah the horror. Last week it was bleating that German laws are written in German, this week it's bleating that German bank documentation is written in German.
There definitely seems to be a trend for more and more proprietary protocols instead of standards.
And we all know that any kind of regulatory action is anti-freedom and job-killing so I wouldn't expect any regulation to happen.
Now that's an intro!
We have ideal for payments (https://www.ideal.nl/en/payment-service-providers/) and every bank has its mobile app that is integrating via ideal. So all payments on my phone the app just pops up, I do a finger scan and done. All apps are very decent for all normal banking business. I can't think of any use case I would need to trust a third party with my credentials.
If there was an API I could use to get these details, it would be so much more convenient. Could even build a product around it.
Simple example: I want to build a arbitrage trading bot that can automatically request my bank to wire money to some address so I can have my funds on an exchange topped up. That's not gonna be possible without an API.
At this point I'd take the enterprisey German API over nothing.
I'd love our government or the EU stepping in.
So be careful and if you want to have more insight into your finance maybe it's better to digest those apis yourself, libraries should pop out soon if they are not yet available for your bank (in europe anyway).
If not, then I think there's still some utility in a service that can normalize that stuff and provide you with a single, consistent interface.
I'm really surprised.
> the lawyers told us to stay clear (huge greyzone)
I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal.
> Stevie was elusive on pricing. I finally asked, "Look, if we paid you $1M, how many banks could we get?" He said one.
If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind.
> the banks themselves didn't want to engage with us using teller even if it sped up development time
Banks don't want to engage with you period. Nobody has heard of Token, you have zero technology and zero bank integrations.
Best of luck with it all, Steve.
I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal. At least one of you should have these emails.
If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind. You would have been paid $1m/year to provide a service. You wouldn't have given up ownership of your company, or taken a risk on stock valuations. $1m cash. Each year. Actual cash. For a startup of 1. If you don't think that's good money right out of the gate, you have serious judgment issues (and this is also reflected in your top-floating comment re security).
Nobody has heard of Token, you have zero technology and zero bank integrations. This was the first time I've heard of Teller...If Token claims they have bank customers that they're providing integration for, it's an easy matter for them to prove it; they only need to publicize one bank client to refute your claims. On the other hand, you come across as very petulant when you say nobody has heard of Token and that they have zero technology or bank integrations since that's an easily disprovable claim.
FinTech and financial services place a lot of value in judgment, since their industry is defined by risk. Right now, you're not showing much good judgment, and if you keep up like this, you have no chance in this space because you're demonstrating in many ways that you're a bad risk for them to take.
I really wish someone would come out with an API service targeted towards someone who would like to manage and query their portfolio of accounts with code. I have tried time and time again to use things like Mint or Quicken to have a consolidated view of my accounts, but invariably I find things that really suck about the service. I'd rather hack together a set of scripts and do it that way, but where to go for the actual access (aside from manually downloading .obx files).
Things are starting to not-entirely-suck in retail banking land. (in Europe, at least - not sure about elsewhere)
Teller is not a bank itself though. I believe it started as a wrapper around banks' private APIs, not sure whether that's still the case.
First is that copyright applies to written content (even short content such as tweets) and does not apply to factual data.
Second is that whatever rights may apply to the data, in the fintech scenario the users are scraping their own data.
So all kinds of copyright-specific laws, of which there are many, don't really apply in this case - and those are the laws that can easily get used against the service provider, unlike the possible ToS violation where the bank would have to against their own customers to enforce it.
That's the trick, they just put all the liability on the user for security issues. Most banks say you must never give your credentials to a third party
So these startups and fin-tech companies just slap a few clauses in their T&Cs to say it's the users problem, not theirs.
Banks benefit from certain bugs/holes in their software (e.g. shitty UI for viewing transaction history/balance -> more overdrafts -> more fees).
With copyright, why create something new when you can just sue somebody?
Privacy policy and terms are linked to from https://teller.io/developer/beta
Privacy policy: https://teller.io/developer/privacy
Terms: https://teller.io/developer/terms
Payments APIs will be signed by the developer's private key (See more about that our auth scheme here https://blog.teller.io/2016/04/26/tauth.html) and transactional APIs will use idempotency tokens to prevent double processing.
This is not a scheme to sell anything to advertisers, it's a scheme to improve the quality of financial services for the highest number of people by providing developers with API access to bank accounts that banks should have provided themselves long ago!
"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."
You don't get taken seriously in the financial space with terms like that. You need to accept responsibility for errors and carry errors and omissions insurance.
Compare Bank of America Bill Pay service terms:
When you make a bill payment using Online or Mobile Banking you can be confident that it will be processed correctly. In the unlikely event that we fail to process your payment in accordance to the payee, amount and date you specified, Bank of America will reimburse you for any late-payment-related charges incurred.
We are committed to keeping your financial information safe and making sure you can bank with us securely, which is why you are not liable for fraudulent transfers or bill pay transactions made via online or mobile when they are reported promptly.[1]
[1] https://www.bankofamerica.com/onlinebanking/online-banking-s...
There were a bunch of questions about Plaid and the difference. The obvious one is that Teller is UK only and supports the top couple banks, Plaid is US only and supports thousands of financial institutions. If you need both UK and US coverage - since we both have pretty developer friendly APIs - it seems like a nice combo! Steve/Teller have also taken a bit of an antagonistic approach and has not worked with the banks - time will see if this proves successful, but we've taken the approach to work directly with the banks (as investors, clients, data-partners etc.).
Hope that helps and if you have any other questions/comments feel free to shoot me an email at william [at] plaid.com
> Plaid... supports thousands of financial institutions.
While this is technically correct, I feel this is a little disingenuous. In the UK we have a far concentrated banking industry, at least in retail banking, in that the vast majority (I'd guess >99%) of current accounts or similar are held with maybe 6-7 well known high-street banks. We also do not yet have a shared banking API format.
In the US, there are a very large number of smaller credit unions, and many banks/credit unions support the same API format (that I believe Mint.com etc use), and have done for a long time.
So I feel this is disingenuous because a) there are fewer banks to integrate with in the UK, and b) the game of integrations here is much tougher.
Citation needed. Clearly you have a competing product. I'm surprised to see you using HN to throw shade at a competitor without context.
Either they or I don't understand what long tail means.
E.g. 80% of revenue coming from 1,000 customers. 20% of revenue coming from 100,000 customers
or
20% of revenue coming from 1,000 customers. 80% revenue coming from 100,000 customers.
The latter is more fat-tailed.
PSD2 explained: https://transferwise.com/gb/blog/what-is-psd2
More info here: https://atrium.mx.com/home
NOTE: I saw a few people mentioning Plaid and Quovo so I thought it would be appropriate to mention our product.
Is your product still going to be on the open market in 6 months time?
We do add as many data sources as possible. We can use Morningstar for example to find cusip of holdings data. We're always trying to improve too :).
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.
This includes but is not limited to loss of your income or revenue; salary, benefits, or other payments; business; profits or contracts; opportunity; anticipated savings; data; goodwill or reputation; intangible and tangible property; wasted management or office time.
No, none.
Will have to pass on it for now. Good to see a lot of growth in the FinTech industry though, with banks like Monzo popping up and all these smart investment sites like Nutmeg.
I like the idea, but i would never use this as a service on the internet.
It was my understanding back then that even when Teller does more advanced authentication with the bank, eg EMV CAP, that that does still grant them the rights to move money, even though Teller doesn't yet support it.
To me that paints a big target on Teller's back - all those juicy downstream credentials.
sjtgraham's point was that setting up new payees typically (always?) requires additional authentication. But I can think of a number of scenarios where a hacker might send all my money to all my existing payees just to mess with me/Teller/my bank... causing fees and stress.
Obviously it's going down the route that Teller won't need your full credentials, you will grant them access via something like EMV CAP, which I applaud.
But I would call on Teller to publicly commit to not integrate more 'advanced' auth methods if they don't include the ability to grant read-only access, if the user wishes!
I notice that National Australia Bank is experimenting with APIs, they have a developer portal [1], with FX rates and branch location APIs currently available. Authentication, customer details and accounts APIs are 'coming soon'.
https://community.commbank.com.au/t5/NetBank/API-access/td-p...
However, the response is not really understood by those answering the question.
There was talk of them being required by ligislation to have an api by July 2018, but not sure what the progress of that is.
https://www.itnews.com.au/news/australian-banks-told-to-buil...
What will the fees be on sending/receiving money?
Scraping data from your own bank account seems rather uninteresting to me. I assume sending/transferring is limited to domestic banks. Is this the case?
You should make it open source (to grow your bank catalog by the community) with some premium Plan (to earn money of it)
That's the only way to get it worldwide, otherwise, you will have to do MITM attack every single Bank App in order to get their APIs, with is painful and most of the times impossible without valid credentials.
Opensource + Premium is the way to go!
https://github.com/bankscrap/bankscrap
We already support major banks in Spain and we're looking forward for people who can contribute with adapters to support even more banks worldwide.
It is UK only.
> Nets is split up in two divisions: Nets, which manages the Danish market, and Teller, which handles all international markets. This means that Nets processes all Dankort transactions, while Teller processes all transactions by international cards.
http://www.epay.eu/acquirer-internet/nets-teller.asp
https://www.nets.eu/en/payments/
http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58...
Everything else would be very naiv.
Asking for credentials is no go whatever the bank is. There are ways to get some feeds even now but that requires signing some papers. Besides, I don't want to shoot down the service because this is genuinely a useful service (if it wasn't for the scrapping) but the best way to solve this problem is for banks to implement their own APIs with proper access controls that make sense in the context of the bank and the account.
