UK banks don't accept any liability if you give your online banking credentials to a third party.
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.
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.
It's the same in France, yet some aggregators (e.g. Bankin) are using those credentials directly (and afaik the risk is handled via some sort of insurance).
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.
Somebody told me that 2018 is the deadline for EU banks to provide API access. If that's the case then going through any server side layer managed by somebody is unnecessary and people in general should think twice about every single bank transaction being stored somewhere "there". It gives out a lot of information from your internet provider to your child's creche, holidays habits, income (duh), loan repayments and whether you like on mondays this new sandwich at pret a manger with a coffee for take-away or eat-in - can be inferred as well.
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).
FYI Open Banking API was announced to have personal customer transaction data on a read-only basis at the beginning of 2018, and the full scope, including business, customer and transactional data, reached by 2019.
As a German it is hard to believe that such things do not exist yet in other countries. We have a standardized protocol called FinTS which is implemented by most banks. This results in a huge amount of desktop and mobile applications for banking.
FinTS (formerly known as HBCI) is horrible and serves as a great example of how not to design a API.
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.
As an American who founded a software company in the online banking sector 20 years ago I can tell you that my experience at that time was that banks here had no interest in making it easier for 3rd parties to get between their customers and their own branded offerings. Microsoft and Intuit tried to promote a standard "API" for banking back then (OFC/OFX) that got very little support from institutions at the time and since. I think basically the only way this would come to pass in the U.S. is through regulatory action, which seems unlikely in the current political environment.
You should come visit Canada, the level of service we get from our oligopoly of banks would make you cry. They would NEVER support a service like this as it would possibly make their customers happy.
Not seeing terms of service or a privacy policy. Who's responsible when there's an error, or a transaction is processed twice or zero times? Is this really a scheme to obtain user data and sell it to advertisers?
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!
Early on at Token, we looked Teller as a possible solution to getting to market quickly. We found two things: 1) the lawyers told us to stay clear (huge greyzone) and 2) the banks themselves didn't want to engage with us using teller even if it sped up development time. We even brought stevie in talk to our lawyers to make his case. He failed to convince them. Finally, we inquired about the price. Stevie was elusive on pricing. I finally asked, "Look, if we paid you $1M, how many banks could we get?" He said one. So at that point, we were so far apart on all issues, so we pulled out. Token will be doing something similar to teller in terms of "one API for all banks" (aggregating banks' PSD2 interface with Token acting as a PISP/AISP). But we are also providing the PSD2 interface for other banks. We have raised plenty of money to do it right ($18.5M Series A to start with), but our pricing to developers will be ridiculously inexpensive. Also, we need to hire developers very quickly, so if you are interested in helping us do it right (no shared secrets, all end-to-end secure protocols, secure central PII storage (where the decryption keys are only available at endpoints), please let us know. We don't have a lot of time left to do this right. We are located in London and San Francisco.
> 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.
Do you know what reasons the lawyers gave for steering clear? i.e. The arguments for your scenario as a potential competitor may not apply to other potential users. Also some lawyers just give "steer clear" as default advise, since that way they themselves are in the clear / there's no benefit to them to tell you to go for it, so the incentive is for them to be overly cautious.
There already exists a company called Teller in Europe which is dealing with payment solutions.
> 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.
Hey all - co-founder of Plaid[0]. Congrats to Steve - great to see some innovation across the pond!
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.
There will be early adopters who take on this new tech and show the rest of us the possibilities. Just because someone reads HN doesn't mean they need to jump on the band wagon
You think? For me as a Dutch guy my only though was "literally never".
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.
I've got a yearly angry tweet that it's totally ridiculous that in $YEAR we do not have an easy, maybe just read-only, way to access our transaction data from banks. (This is for the Netherlands.)
At this point I'd take the enterprisey German API over nothing.
Long tail doesn't necessarily mean that the tail makes up most of the distribution. A long tail can make up a majority, or minority, of the total distribution.
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.
Its a weirdly phrased sentence, but what he means is that he will have a long tail of minimal revenue users and also a few users that will make up the bulk of the revenue, and he wants to open it up to the public in order to find these users.
Unfortunately the Bunq API requires a fixed IP address which means I can't use it with my non-cloud banking software from my (dynamic IP) home connection.
Can someone explain to me this dichotomy I see with the almost thermo-nuclear war when it comes to copyright protection of total drivel, but when it comes to fin-tech there is literally a flourishing industry of screen scraping typing companies and well-publicized plays like Mint and it's just like a big shrug? How are these companies able to mitigate through the banking companies TOU and such?
It works by using the same private APIs that the bank's own mobile app. We reverse engineer their app, work out the API contract, implement our client, and normalize the data.
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.
I emailed a bit with sjtgraham on this a while back.
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!
Incidentally, if Teller start to get an appreciable proportion of the UK population (remember, users will be using Teller without realising, through other apps and platforms), they should expect a call from the regulators, who will want to be sure that they can't cause any systemic instability (eg by getting hacked.)
I wonder how many of the use cases for a retail banking API would be simply satisfied by just allowing customers to request a weekly email with a CSV transaction file attached in a sensible format?
Banks should most definitely do this. Or maybe provide a link to a CSV file behind a login-wall (so the details passed over email can't be poached as easily)
Is there a test / mock instance, allowing you to call services connecting to dummy bank accounts? i.e. Some people may be concerned about trying out the API on their own accounts during the early stages, or if any update services are added in future. Also it enables those not banking with a supported bank to develop against the service.
[+] [-] alexbilbie|8 years ago|reply
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)?
[+] [-] sjtgraham|8 years ago|reply
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.
[+] [-] lewisl9029|8 years ago|reply
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.
[+] [-] thibaut_barrere|8 years ago|reply
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.
[+] [-] mirekrusin|8 years ago|reply
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).
[+] [-] kevincennis|8 years ago|reply
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.
[+] [-] reledi|8 years ago|reply
[+] [-] foxylion|8 years ago|reply
[+] [-] sparkling|8 years ago|reply
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...
[+] [-] markbnj|8 years ago|reply
[+] [-] mistermann|8 years ago|reply
[+] [-] Animats|8 years ago|reply
[+] [-] sjtgraham|8 years ago|reply
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!
[+] [-] skirsch|8 years ago|reply
[+] [-] sjtgraham|8 years ago|reply
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.
[+] [-] johnlbevan2|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] eriknstr|8 years ago|reply
> 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...
https://my.teller.com/login
[+] [-] whockey|8 years ago|reply
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
[0] https://plaid.com
[+] [-] danpalmer|8 years ago|reply
> 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.
[+] [-] Peroni|8 years ago|reply
Citation needed. Clearly you have a competing product. I'm surprised to see you using HN to throw shade at a competitor without context.
[+] [-] cikey|8 years ago|reply
I like the idea, but i would never use this as a service on the internet.
[+] [-] cbcoutinho|8 years ago|reply
[+] [-] foodstances|8 years ago|reply
[+] [-] JohnnyMneunomic|8 years ago|reply
[+] [-] smaili|8 years ago|reply
Now that's an intro!
[+] [-] bastijn|8 years ago|reply
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.
[+] [-] aerique|8 years ago|reply
At this point I'd take the enterprisey German API over nothing.
I'd love our government or the EU stepping in.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] heneryville|8 years ago|reply
Either they or I don't understand what long tail means.
[+] [-] whitepoplar|8 years ago|reply
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.
[+] [-] phaed|8 years ago|reply
[+] [-] skrebbel|8 years ago|reply
Things are starting to not-entirely-suck in retail banking land. (in Europe, at least - not sure about elsewhere)
[+] [-] reledi|8 years ago|reply
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.
[+] [-] germanier|8 years ago|reply
[+] [-] Scottymeuk|8 years ago|reply
[+] [-] pjwal|8 years ago|reply
[+] [-] lookingfj|8 years ago|reply
[+] [-] sjtgraham|8 years ago|reply
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.
[+] [-] amb23|8 years ago|reply
The US is a long ways away from having this.
[+] [-] alexbilbie|8 years ago|reply
[+] [-] dabeeeenster|8 years ago|reply
[+] [-] insomniacity|8 years ago|reply
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!
[+] [-] insomniacity|8 years ago|reply
[+] [-] IshKebab|8 years ago|reply
[+] [-] jsk2600|8 years ago|reply
[+] [-] jimmcslim|8 years ago|reply
[+] [-] StarlaAtNight|8 years ago|reply
[+] [-] johnlbevan2|8 years ago|reply
[+] [-] sjtgraham|8 years ago|reply