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.
> 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.
I like how Jude solved the problem of the password. They do all the scraping on the phone. So no password is stored on their servers. https://blog.jude.io
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.
I don't know, if the general level of bug-ridden-ness of their products is any indication, I wouldn't put much stock in their security. There are glaring bugs in Quickbooks for example that persist year after year, having been reported repeatedly, even as they continue to release a new version every single year with various visual tweaks and seemingly not much else.
QuickBooks, even the online version, are decades old and have major issues that prevent the teams from getting much done. They took a year to do clean-up and basically didn't introduce any new features. Not much got done just due to the complexity of changing anything without causing problems.
FICDS, on the other hand, was spun up more recently and is in much better shape. I wouldn't look at an application like QBO and see much that would inform a behind the scenes service like FICDS.
The more interesting product, to me, is TurboTax. The seasonality of it allows Intuit to basically rebuild it from the ground up every year. It's really a different mindset on the San Diego campus (where TT is developed) and in Mountain View (where QBO is developed). San Diego is much more willing to take (non-security) risks with the product because small changes can add up to big wins. I remember a talk by one of the guys in charge of A/B testing on TT who said that a tenth of a percentage point increase in conversion rate was good for tens of millions in added profit.
Contrast that with QuickBooks, where the difficulty to use is actually a feature. Accountants spend years learning the app and learning the work arounds for those bugs you mentioned. That knowledge and experience becomes a barrier to entry into the field and a job skill that they're compensated for. The result is that QB/QBO is aimed at accountants with years of experience in the product. Their livelihood depends on it and they don't like change. So the teams there do as little as possible that can cause problems and know that they'll still get good reviews if the get almost nothing done so long as they don't cause problems.
It's deeply disfunctional and yet explains why you can put a lot of trust in FICDS. They too have had bugs for years. For example, they don't save cookies between scraping sessions and so are always an untrusted browser to the banks. I have at least two accounts that constantly send me 2FA tokens whenever Mint tries (and fails) to sync. But no one gets fired for not fixing bugs. You get fired for compromising the security or stability of the service, and the easiest way to not do that is to push as little possibly vulnerable code to prod. It's the anti-Zuckerberg environment...move slow and don't break things.
I suppose you could have a point about the fact that (good) accountants know the work-arounds. And many of the bugs are annoyances and UI things rather than critical stuff. There are some that will really bite you (meaning, result in incorrect accounting) if you're not familiar with them. For example, the home currency adjustment in the multi-currency mode skips accounts with a current balance of 0 in foreign currency, even if the balance in home currency is non-zero, and so an adjustment is needed. If you know that, you can go in and do those ones manually (although it's a PITA), but if you don't, your taxes will be off. That seems like something that should not be allowed to persist in accounting software. It's the most glaring example I can think of, but there are others.
Ha, actually, one more - the only way to change the date format in invoices (from mm/dd/yy to YYYY-mm-dd for instance) is to change the overall Windows OS setting. That's crazy enough, but what's worse is, when you do that, it screws up the dates of many pre-existing, closed transactions in your company files. Fortunately in my case (iirc) it reset those dates way in the future, so I was able to find and fix them manually. But I mean, seriously...
Heh...you're talking QBD. That's the true dysfunction of Intuit. It's the product Intuit doesn't want you to use. They want customers to transition to QBO and only "maintain" Desktop because many customers refuse to "upgrade" to Online. I never met a single employee who was currently working on QBD. A product that accounts for more that 1/4 of their revenue and they had literally no engineers participating in company events, or at least disclosing what product they worked on. Hell, I met the entire Quicken for Mac team at one point.
My favorite WTF for QBD: The data upload was literally just using the replication feature of the embedded Sybase database. One of the Distinguished Engineers that I worked with, "I worked on that feature and I probably know more about how it works than anyone and I can't get it to work reliably.
Yeah, I don't love the idea of trying to run accounting software in a browser; doesn't seem like it could possibly have the performance of a desktop app. Also, last I checked, QBD includes features I use that QBO doesn't. I can't recall what they were though, so that may no longer be the case.
So, does this mean QBD is basically the living dead, and inevitably I'll have to find an alternative? It looks like everyone's doing online these days.. :/
Edit: Yeah, looks like it doesn't have inventory tracking. Conflicting reports on multi-currency support too.
> So, does this mean QBD is basically the living dead
That was the impression I got when I was there. They're putting a ton of effort into getting people to migrate. But there's still a ton of die-hards that won't and they were continually having to push back their sunsetting plans. I've been gone more than a year now, so I can't say what the current situation is.
It sounds like you're a lot more familiar with the long-tail features of QuickBooks, so I may be recommending something that's missing a lot of what you need, but my favorite competitor product was Wave. They seemed to be the only one that was actually trying to make an intuitive product that wasn't unpleasant to use. It's online though and I don't really know much about the desktop alternatives, so if you're set on running on-prem software, it won't work for you. The accounting stuff is free, though, if you want to play with it.
But Xero is also online only, right? I was pretty negative on them, considering they basically started from scratch in an era where the result should have been much better than Quickbooks considering it didn't have all the baggage that Quickbooks has to deal with. And yet they came up with something that's arguably just as frustrating to use.
Yeah, Xero is online too. It was just the only one that appeared to check all the boxes I need. (Most were missing one of payroll, inventory management, or multi-currency support.)
Financial Institution something something Service. It's the internal initialism name for the service that communicates with financial institutions on behalf of the applications that need to pull transactions and other information.
> What does it mean "quickbooks online is decades old"?
The project was started in the late 90s. It's as messy a codebase as you'd expect to find when you've got close to 20 years of commits.
The level of bugs and slowness in Quicken is mind bending. I've been using Quicken since it ran in MS-DOS and I've watched it get slower and buggier every year.
My latest version (Quicken 2016) literally takes seconds to tab between fields and often does not keep a correct tally balance until I close the check register view. I only have a year of data in it (I thought the slowness might have been due to importing my old data so I restarted fresh).
Since I've been getting bombarded with upgrade ads that I can't seem to disable each time I start Quicken I'm thinking of moving to another app like Moneydance. It feel like an end of an era.
First, Quicken was sold to a private equity firm at the beginning of last year, so you can't really blame Intuit for it anymore.
Second, even before it was sold, it was like Intuit's vestigial tail. It was an important part of the evolution of the company, but it didn't fit into what Intuit was trying to do and was largely ignored inside the company. Even before they announced plans to sell it, it felt like the kitchen table they keep at headquarters...something that's there to remind people of Intuit's past but feels really out of place with its present.
Agreed. I used to work for a division of Intuit (not financial stuff) and a lot of the dev work I saw was pretty shoddy. Lots of weird bugs constantly.
With that said, security is taken very seriously and most of the stuff I experienced was UI related. So hard to say...
Tbh, its only worth considering for pure "credit card" services where its essentially read-only already and any damage can be attributed to fraud you can perform a chargeback against.
That being said, if you run all your spending through your credit cards except obvious notables you update manually you are golden. (i.e. Rent/Mortgage)
It would be interesting if there were a way to run a local client that holds your credentials and does the screen scraping to send back to this API (or others).
Wesabe built our own data acquisition system, first
using downloadable client programs (partially because
that was easier and partially to preserve users’
privacy)
Technically, they could provide a self-hosted version. But that may not be a very profitable business. Also, screen scraping needs continuous updating as the bank's interface changes.
The best option I found (for read-only access) was chromedriver > download CSV statement > process that into your own database.
Using minimal standard screen scraping will be hard because most bank apps are a complicated mess of client and server side processing using ancient tech. After many tries, I just used python+chromedriver and that's doable in ~100 loc per bank.
CSV statements because OFX and others are a complete mess in most cases. I haven't seen a single compliant and correct file so far. (This may be AU specific)
Own database / spreadsheet so you have a local copy you can easily filter on. Obtaining specific date range from a bank may be an interesting challenge. I default to importing last 30 days every day with duplicates detected using a hash(date-description-amount-idx) where idx increases for every date-desc-amount duplicate.
So far I'm happy. Actually I'm in the process of writing a post about it - will submit sometime next week most likely.
Coming from a slightly different angle but it may be of use, I wrote a chrome browser extension that automates logging into banks and other financial sites. It also scrapes the balances once logged in to provide a net worth total. It currently works on around 25 banks (mainly UK). You can also build your own logins and all passwords/private data are stored encrypted in the browser.
I wrote it as I just spend too much time digging out passwords all the time and the usual crowd like LastPass are a) stored online and b) fail to login automatically to complex input sequences like banks.
I hand-rolled a wells fargo scraper recently using the haskell webdriver package and Selenium. It was working fairly well until they started requiring a captcha - something I've never seen as a human user. I'm not quite sure what triggered that or how to get around it.
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.
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.
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.
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.
> 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??
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."
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.
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.
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.
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.
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.
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.
>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.
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).
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.
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.
Yodlee not only wants your credentials but at one point updated their customer agreement to grant them Power of Attorney with each institution they managed on your behalf. I don't know about you but PoA, a binding arbitration clause and their marketing your data to boot is well beyond my comfort level.
That reversal is not instantaneous, and by no means is it a guarantee that you'll ever get the whole amount back when overdraft fees, third-party bounced check fees, and all of the other non-monetary impacts are taken into account.
Depending on the scope of your accounts with the financial company that you're banking with it's possible that beyond your day-to-day operating funds and your mid-term savings accounts that you may also have access to your investments and other long-term stores of value. They aren't as liquid, and it would be harder for a thief to shift them into something that can be transferred out of your account, but it certainly is possible for it to happen if sales of stocks/bonds/etc. are conducted without your knowledge and then the funds are wired out.
In this particular case, yes, because banks tend to deny all liability for fraudulent transactions that result from credentials sharing, so the user is entirely liable for whatever loss that occurs.
It's a realistic concern. For example, a lot of elderly people are targeted for scams because they A.) Are often little easier to trick and B.) Tend to have more money. Comes up in the news a lot. They don't get it back.
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.
It’s better because going through the same process as the official banking apps means that you should end up using tokens etc rather than actually storing the original credentials.
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).
My understanding is that the EU PSD2 regulation indeed is supposed to make banks adhere to a standardised API. That being said, I wouldn't expect a super easy to use REST api with documentation powered by readme.io.
If you read the legislation (?) you will see that they are actually very vague in how the banks will provide access. I think it is already a great success that they (fingers crossed) will manage to force the banks to provide access to the data in any form and gave them little wiggle room for justifications to get out of it.
There are however some inititives for open API standards that might be accepted by a majority of the banks.
No, they're just told to implement the technical means so that the user can decide what to do with their personal data. This probably means some kind of API but any bank is allowed to implement them in any way they like.
That's obviously and opportunity for Teller, Figo.io and other players, they can perform legit aggregation just swapping out their scraping for bona fide API access.
But the situation is more complex... even banks can become aggregators for other banks if their customers want... These are interesting times.
Nope. They just need to provide "an API". Got a hundred banks? That's potentially 100 integrations you'll need to do - the barriers remain in place an everyone is happy.
On the positive side, someone could provide a library which covers these but doesn't require going through a third party. i.e. that library could provide a "single api" with none of the risks of picking an unknown third party. If that were done as an OSS offering you'd also be able to easily confirm there was nothing lurking in the library under the covers.
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.
Enterprisey APIs with adoption beat nicely designed APIs without adoption anytime.
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?
Your conflation of "bad" with "enterprisey" is unfortunate. Also, is it really adoption if different banks only support specific features/versions?
> If FinTS is too difficult to implement, how come they are not offering something simpler?
Well banks aren't really in the business of APIs, are they? Nobody is graduating #2 in their class at Stanford with a CS degree and going to work for a bank as a web developer.
Banks aren't in the business of offering APIs because there's little incentive to do so. Even if there were a lack of talented technology-based employees, that likely wouldn't prevent APIs from being developed.
The issue of incentive boils down to the fact that business clients, being the main source of revenue for retail banks, simply aren't making enough noise about their desire for APIs.
> There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.
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.
What do you mean English being the lingua franca is not a good thing? Do you mean it's bad, or it just is what it is? I think there's benefit to having a universal language, but it doesn't have to be English...
A lingua franca's ideal should be to be easy to learn, able to express lots of things. English is easy to start with, but hard to master, and its expressiveness isn't ideal either, often having to import words from other languages where english has no word for a concept itself.
I'm betting on a symbolic referential language as becoming the defacto standard for programming binary machines. From my cursory glance at Mandarin, I see a lot of similarities with expressing code.
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.
English is the working language of software development, so it does make a degree of sense to bemoan the fact that the API documentation is only available in German.
A significant amount of software development in Germany is done in German only, especially if you solve Germany-specific problems with your software (such as accessing banks). English far from being a general working language for software development here.
The software I use at work is developed by a German-speaking team based on German documentation. I think the code is mostly English although they often use German identifiers when there is no straightforward translation[0]. It's highly specific to the German legal environment and of absolutely no use abroad anyway. Translating everything twice just introduces more errors.
This is not true at all. There's plenty of code written with comments relevant to the country in question. It's not for you to decide what other developers should make their working language. I'd like to see you go to China and ask them all to stop commenting their code in Mandarin.
Not really in Germany. Lots of documentation is German only, in some german games (most notably the Anno series) even the scripting languages’ keywords were German ("wenn" instead of "if", "solange" instead of "while", etc).
And even in huge codebases such as SAP, most comments are still German.
Yes, modern codebases are often written in english, but that’s not everywhere.
German isn't "gibberish" to some of us, so I would not describe it that way. It's a German banking API after all. A functional API that is being used is better than no API at all.
Nobody said it was. They said it was a german-only specification that was full of gibberish, you could just as easily have an english-only specification that was full of gibberish (as most are to be honest).
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.
I used to use MS Money and it was really great while it worked. Then slowly banks dropped their support and at the moment there is really no easy way to get all your accounts into one database (especially one that you own yourself) other than giving all your password to something like Mint.
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.
Mint is readonly, but the possibilities explode when you are given RW and event processing access to your money. You could already do some cool things of you buffer your accounts between 2 cards. But you can't straight up sent transactions with code, or you're own "automated" savings plans, or social graph triggers/input based on transactions. So many cool possibilities, banks need to step up or collaborate on an engineering effort to produce a secure ApI system and infrastructure.
Concur. My credit union recently switched the backend processor for their credit card. Now, the only option for transaction download is csv or xls. Welcome back to the 90s.
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.
Although I agree that this criticism of Canadian banks is probably broadly true, note that the banks did manage to coordinate on Interac, a quite serviceable standard for sending money electronically between private parties.
Canadian banks have been quietly dropping the Interac network in favour of co-badged cards that use the VISA network behind the scenes. Your interact card says Visa on it now, because the debit transaction might be routed through Visa's network instead.
I'm guessing the benefit to banks is lower fees or perhaps even monetization through transaction data sharing with Visa?
This of course breaks Interac features like Interac online.
Last time I opened a bank account and got a co-badged Interac card I immediately asked them if I could get an "Interac Only" card. At first they had no idea what I was talking about, but a few phone calls to head office later, and they were able to re-issue new debit cards without the Visa co-badge. Interac online works, and I feel better not sharing purchase data with Visa.
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!
"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]
Thanks for your feedback. We developed TAuth to provide attribution and non-repudiation for exactly this kind of situation. I personally take security very seriously such that launching our product has taken longer because designing and implementing a system worthy of performing financial transactions on behalf of others is a serious undertaking.
Our terms are comparable to the incumbent "screen-scrapers" in the market, e.g. Yodlee and Plaid. FWIW it is not currently possible for users to move money with Teller. I'm open to revisiting the terms when it is, and I'm always open and listening to feedback such as this.
Respectfully, your users don't care about technical security if you get compromised - they care about their financial security. Please do reconsider your stance on liability, I found myself wincing while reading that disclaimer.
It pains me to say it as a techie but insurance is more important than security in this case. It'd be great if you were iron clad against all hacks ever but it'd sit more easily if there was insurance backing it up. What if you get a rogue employee dumping out all the credentials for example, not all attacks come from outside.
If you don't trust your security enough to assume liability, why should your users?
> FWIW it is not currently possible for users to move money with Teller
I don't believe it's so much a compromised service or API that's concerning, it's your credential storage. The data you hold does allow users to move money if compromised.
Having picked fault with your service enough, it does look like a great service and I'd love to use it one day. Best of luck!
The problem isn't what an attacker can do with Teller credentials. The problem is what an attacker can do with the banking credentials you ask users for. The risk profile is similar here to a breach in an online password manager -- if you used an online password manager to store your banking credentials, are you perfectly comfortable with an attacker gaining access to your credentials since the password manager implements no banking functionality?
Oh my, I have thought about this a lot, and I firmly believe that there is. Sorry for the ensuing wall of text!
Right now I pay for several online services, a gym membership, insurance, a student loan, a mortgage, and an auto loan. Every one of these companies has authorization to pull money from my account each month. They all pay their payment processor a significant sum of money in exchange for the processor running the payments and shouldering the risk of the bank not honoring them.
With an API, I could stop relying on this "pull" model and start using a "push" model instead. Companies get my money only when I explicitly send it to them. I could schedule a payment to go out every month for services I want instead of allowing arbitrary vendors to charge my card (banks do have a partial stab at this in the form of bill-pay, but it tends to be pretty bad).
Presumably since the risk of fraud is lower since I authorized the payment with my RSA key, merchants could pay lower fees to their payment processors.
Now, I'm a little atypical, because I know how to program so I could use the API without help. But I know many people who would certainly take advantages of services built on top of an API like this.
Think of all the people in your life who have accidentally continued paying for something they no longer wanted due to the vendor "mistakenly" continuing to charge their card. Or scummy negative-option marketing companies which loudly tout a free product or service and then continue to charge your card thanks to some tiny section in their terms of service.
The possibilities get better too. You could have budgeting apps that don't let you spend more than $X per month for video games, but still allow you to buy groceries. You could give your children an authorized card with a per-month maximum but still allow them to pay for an Uber home if it's after 9 pm.
I really think this sort of thing would be a massive boon to people and society, and it's unfortunate that banks (in America) are fighting so hard to prevent it.
Bank of America's assets total over 2 trillion dollars. I would imagine it's easier for large financial institutions to create such strong guarantees for its users.
Marc came to our office at midnight and read the letter I’d written to our community about the Airbnb Guarantee, and the two changes he made changed the company forever. I’d said we guarantee five thousand dollars for property damage, and he added a zero, which seemed crazy.”
That's kind of the point - if you have large assets, that might be some assurance of your liquidity if e.g. a $100 million bad event happens; but if you do not and can't pledge large amounts of capital as pretty much a collateral, then you'd be expected or even required to buy insurance for very large amounts.
You're not wrong; but please don't ignore OP's excitement to garner your attention, those things matter to little people like us in a socially conscious culture of 2017.
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.
It seems you boys can settle your dispute the old fashioned way: by providing support for your claims.
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.
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
First I've heard about Plaid and Quovo. These services seem to be targeted at a developer interested in developing products for others.
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).
Thanks. I'll give it a shot. Any useful scripts you'd care to share?
One thing I ran into quickly when parsing my own bank's OFX was the truncation of the payee field, which made it extremely difficult to identify certain transactions. For example, I might get coffee at a Starbucks, but it would show up in the bank export as "STORE93423 CA LA STAR". I never determined if this was a limitation of the bank's software or simply that OFX didn't allow for enough characters. It'll be interesting to see if Plaid solves this.
Personal Capital is pretty good - their investment service is pretty overpriced, but their free portfolio management tools work most of the time, provide great graphing, and seem to handle all my accounts easily across a variety of banks.
Teller is for UK, whereas both of these are in US.
As GP points out Plaid currently does not have any brokerage data (beyond simple account balances) - only yodlee and Quovo do.
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.
Another dutch person here. I can think of plenty of use cases. I'd like to keep track of where my money goes, and have played with programs like GnuCash and Ledger before. The big problem is getting data into them. I have a decent system where I download the CSVs, feed them to a script, and everything gets imported. However this requires me to think about downloading that CSV every month. And my administration lags behind by a month. It's also inconvenient if my system can't automatically identify the receiver, since then I'll have to help it out. Hard to do that when I have to recall where I spent $15 a month ago.
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.
Ehhh, you totally seem to miss the point. It's not about making a single payment, but automating that without any user interaction in between.
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.
For me, an American guy, my thought was the same. Normal people don't think about APIs. I gather the target audience here is service providers, but the copy is confusing because it seems to be speaking directly to consumers?
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.
But monzo card is still just prepaid debit card. You don't get a current account.
That might change later this year when they roll out current accounts but for now it's just simple prepaid/travel debit card with mobile app.
Also not sure they have switched from WireCard yet? Last time I heard they have not switched all of their existing users to their own platform but perhaps they managed the transition already?
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?
There are two main differences between screen-scraping content and screen-scraping transactions.
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.
> How are these companies able to mitigate through the banking companies TOU and such?
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.
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.
Not only does this sound potentially illegal but how can you be confident that you will recognize the breaking changes in time to fix them? What if you begin supporting a large number of banks and you can't keep up?
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.
The EU Computer Programs Directive 2009 provides an exemption for reverse-engineering for the purposes of creating inter-operable systems. This directive has been harmonized into UK law (where Teller is domiciled and operates) and Teller satisfies the requirements to be protected by the exemption. We have also developed many novel techniques that do not meet the UK legal definition of reverse-engineering so we have that angle too. This issue has also been looked at by expensive lawyers.
In terms of stability. It actually takes 6-12 months for a bank to get something into production. We are not talking about fast moving organisations here. We have not had a breakage with a supported integration in two years of beta testing.
We take many steps to ensure our traffic does not stand out to banks eager to actively interfere with Teller. Our clients perfectly emulate (100% API compatibility with their own) and make the same API calls in the same order etc. We also only make API calls as a result of user action, i.e. Teller does not poll or cause atypical traffic patterns. Finally have 100s of IP addresses and assign an IP address to a user for a period of time. All of this compounds to make Teller traffic look indistinguishable from their own mobile app traffic. The objective is to make it more likely they will block their own app traffic than block Teller as a string incentive to not interfere their customers' choice to use Teller enabled services.
Hey Stevie, I was at the HN London where you gave a very memorable demo on reverse-engineering mobile banking apps. Stoked to see to how far you've come and congratulations on the Teller beta launch!
Even back then you had caught the attention of banks. I'm sure they've threatened you many times. But now that banks are taking you more seriously and returning your calls, how are you going to convince them to work with you instead of against you?
And what happens when, if they haven't begun already, try and legally DoS you?
I hope banks will realise that open APIs are a good thing, and if they don't start getting their shit together, they'll be left behind. Our whole financial infrastructure is so needlessly complicated. Why can't it all be JSON APIs?
I've used similar to scrape real estate data. Reverse engineering mobile APIs is often the most consistent way to get programmatic data access these days. Just grabbing a bit of data as a user this isn't a big deal - but I wouldn't want to base my business around it, it seems like there are too many opportunities for that to blow up in your face.
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...
Sure they might find out an App Update was issued in the App Store... but they cannot possibly know what API changes were made without reverse-engineering the API's all over again.
Not to mention, once they discover what changed, now this service has to go make the changes on their system... meanwhile that bank doesn't work with this service anymore.
So the App is broken for some undefined period of time.
The bank has to deploy their client code to all of their users before they can depreciate the old API. That should give them plenty of buffer time to reverse engineer the changes.
"All" of their client code is a bunch of apps, that mostly auto-update. My bank (small town credit union) has a banking app that refuses to work at all unless it's the most recent version of the App. I see no reason why this would be a challenge for the bank - it's only a challenge for this service.
That doesn't stop them from deploying new APIs to their client software deactivated. Then "flip" a switch to cause it to behave differently all at once.
Sure, but they've got plenty of buffer time since their app doesn't break when the new version is released, it breaks when the old API is actually depreciated. Just because you release a new version on the App Store doesn't make clients with old versions of the app disappear.
Consider that e.g. Barclays randomly breaks their own mobile app for substantial subsets of their own customers. Over the last 4 years or so, the app has been broken for me more than 2 of them because they apparently consider it acceptable to whitelist phones based on their own whim (if you have one of the big brand phones, presumably it usually works, but e.g. even users of relatively well known brands like Huawei can often find their new phones won't work with Barclays for several months before it gets whitelisted).
In other words, many of the big banks have such a dysfunctional relationship to internet banking that customers of many of them have learned to deal with not being able to use the apps for long periods of time - it's hard to imagine that a third party will be perceptibly worse.
Apps won't be updated instantaneously on devices, though. There'll have to be some backwards compatibility for a good while if the banks want to change their APIs drastically. You can't just shut down access to your customers apps.
> You can't just shut down access to your customers apps
Yes you can, and banks already do this. Even the E-Trade app refuses to work unless it's on the most current version. When you control the apps and the API, you can pretty much do as you please.
It's takes banks 6-12 months to get anything into production. Also breaking APIs to thwart me has to compete with delivering new features to users. When they do change the contract, we know about it. We watch for new app releases, and proactively check.
How do you guarantee SLA uptime with that model? You won't know of any breaking changes until it hits production and when it does you will have to fix it. This may be an easy 30 minute fix and you pause transactions, or it may be a 24 hour fix and your world is broken for "forever" in api standards where 99.9X% is generally standard uptime requirements.
It seems to be that any service that consumes private APIs is going to be inherently unstable, although I agree on the slow pace of work in the finance world.
Also, once they figure out your consuming their APIs there will be an arms race and possibly legal action.
I'm not sure you need to guarantee an SLA for this to be attractive. E.g. I've badly wanted to get automated access to my statements for ages, but not had the time to work out an approach. I'm used to my bank (Barclays) being so insanely backwards, that if Teller's API suddenly tells me "sorry, broken because your bank are morons" and the API is down for a couple of days while they work around it, I'll blame my bank, not Teller.
For comparison: I've been unable to use Barclays own mobile app for about half of the last 4 years in chunks because their app seems to whitelist phones as they decide it's worth it. On a relatively random subset of my phones over the last 4 years, it just shuts down. No error, no nothing. Their support insists nothing is wrong. Nobody at Barclays appears to give a shit that they lock customers out. The Play store is full of thousands of one star reviews from people affected. My current phone took 6 months before it suddenly started working.
In other words: If you bank with Barclays, either you accept that you'll need to have a pinsentry device on standby when you get a new phone, or you'll stand a good chance of being unable to use their service for months on end.
When I signed up for Xero for my business account, I had to provide them with a document that they had to fax to Barclays to get them to pass on transaction info. It took about 10 days to get it enabled. If only I could get my personal statements electronically as easily (maybe Teller can finally solve that).
The banks have made sure peoples expectations of them is so low that any third party service that's remotely transparent is likely to find customers are very tolerant of bank problems.
I mean, the only reason I'm still with Barclays given the above is that most of the alternatives are shitty too, and I have locked in a mortgage rate with them that I "can't afford" to give up as long as the Bank of England rate is as low as it is (tracker rate that means I pay well below inflation).
It uses the internal APIs mobile banks use afiak. For what it's worth the open API laws aren't in power yet in Europe and tbh I imagine nearly all banks will fail to implement by the deadline. Or if they do, the APIs will be fairly crippled.
So does Europe. Open Banking Ltd in the UK is attempting to develop these standards, but they are working with tens of stakeholders across impossible deadlines - which means they cut scope and quality. And since banks in the UK are sponsoring the show, it is beyond certain that no disruptive moves will be taken, and interests of the incumbents will remain preserved.
Many do, but the key is that the mobile apps generally only require access to 2FA for registration, so if they implement the mobile app interface they can get away with having users use the 2FA device once.
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.
I'm in no position to answer authoritatively, but for what its worth the three accounts I have left in the UK, with different banks, can all be accessed without a 2 factor device.
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.)
My hypothesis is that PSD2 will not be the golden opportunity everyone hopes. Banks are an oligopoly and unfettered open access to their customers via open APIs is potentially a disaster for them. They have little to gain and everything to lose. When you consider this and then expect incumbent banks to act in their self-interest it follows that they will act to subvert the impact of PSD2, e.g. by fragmentation, lobbying for onerous requirements in order to consume them, etc. All of this is already happening, which is why I think there is an opportunity for Teller by truly aligning with developers and users.
Removing roaming fees for all European telecom operators was also a something that they had little to gain and everything to lose. But, here we are.
From my understanding SEPA is getting implemented. I could see PSD2 following the same path. Some banks will drag their feet, but it is a pandora box situation, as the banks that will implement PSD2 first might get all the apps attention and love, potentially driving new customers.
Let's see next year how PSD2 adoption pans out...
Current roaming regulations in the EU are designed with the biggest, transnational players in mind. By subsidizing operations in a less lucrative market using proceeds from other countries, they can bleed smaller national telecoms. They will then proceed to buy them for pennies on the dollar. This will result in less competition down the road, and higher prices for the end user.
http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SW... - see page 32 (ARRPU). Operators in different countries have different profits per user (obvious). If you have someone like T-Mobile or Orange, they'll use the proceeds from say... France, to finance their operations in say... Poland. This will put pressure on other national operators to further lower prices. Lower prices mean lower profit margins, mean lower dividends, lower company valuation, being less attractive to investors, etc. After a while their value will decline by so much, they'll be willing to sell themselves at the current going price of their infrastructure. Orange buys them, and kills off competition.
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.
Once you have access to someones banking account you can typically make small transfers (up to ~£200) without second-factor authentication. So if your service get's breached attackers will have potentially the means to extract real cash through mules or wreck havoc.
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.
This is annoying, I got all excited and then realising this is for a handful of UK banks. Would be great if it were tagged as a UK thing more prominently.
I had he exact opposite reaction: expecting it to be US-exclusive and got to the last paragraph where it said they don't support any US banks. Big ole' :-( face.
Does anyone have any insight into a PSD2-style effort in Australia?
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'.
Bunq already has a native api [0], only if you pay sadly, many other functions are free. I like Bunq but their app devellopment is slow, I still can't share iDeal (is iDeal only Dutch? I wonder...) requests through anything other than email and sms. Everybody is waiting for general sharing on Android/iOS.
> Transfer money between accounts, make external payments using Faster Payments, and manage your payees, standing orders, and Direct Debits all through the Teller API.
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?
Teller allows developers to build applications on top of their users' bank accounts, not just your own. Read more about TAuth and how it works here: https://blog.teller.io/2016/04/26/tauth.html
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.
MX is not owned by any bank. It's still privately owned startup. We are long term in that we have many 5-7 year contracts with big name banks and add more each quarter. We offer mobile banking solutions, data categorization and budgeting tools to banks, so we Atrium is a product to sell access to the services we built to power our other products. So yes, our product will definitely be on the market for years to come.
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 :).
Knowing the founder personally and his level of competency writing code gets me very warm down below. If I still lived in the UK, I would build something around Teller trying to give users a feeling close to what Monzo-bank is/does. Some kind of a hybrid zombie child, but beautiful!
A bank account is usually only part of the financial equation. What would really be useful is an API for a service like Mint. I'd even be willing to pay a low fee for someone to make available all the aggregate data from all the financial institutions via API for me.
Maybe every Bank should provide its own, well documented API. Third Party is not an option imho. Also this reminds me of that root Bank i saw here in HN some time ago... https://root.co.za/
While we make every effort to ensure our services are available, secure, accurate, complete, and free from defects we provide no guarantees, conditions, or warranties of this, express or implied.
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.
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.
Sorry for the newb question but a quick google didn't yield the results I was looking for. What is the attack vector here that "screen scraping" would exploit?
I wouldn't hope for this being useable in the US anytime soon!
"Teller is available today for Santander UK, Barclays, Natwest, Nationwide, RBS, Isle of Man Bank, and Ulster Bank."
Mint is readonly.
PSD2 and reverse engineered api is not.
Also Mint exposes you to the very threat mentioned in top comment, while PSD2 protects you here.
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)?