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.
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.
I'd like something like this, but I wouldn't want to give the bank details away.
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.
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.
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.
It's also highly probable that it has happened, it just wasn't attributed properly.
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.
Well... no thanks. I (and likely many others) would only consider using such a service if I had a guarantee, both from you and my bank, up front.
from your ToS:
>"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise."
Oh geez.
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.
I'm not sure that's the case; I thought the FCA were pretty clear one intent of PSD2 is to stop the need for screen scraping.[1]
Have you had any dialogue with OpenBanking UK etc. about their strategy on API driven interactions?
1. https://www.out-law.com/en/articles/2017/february/screen-scr...
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.
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.
With that said, security is taken very seriously and most of the stuff I experienced was UI related. So hard to say...
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.
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...
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.
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.
Looks like Xero might be a viable option though.
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.
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.
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.
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.
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)
From http://blog.precipice.org/why-wesabe-lost-to-mint/
Wesabe built our own data acquisition system, first
using downloadable client programs (partially because
that was easier and partially to preserve users’
privacy)Any tools you recommend, or is it all hand-rolled?
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.
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.
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??
If that is close to explicitly as you have stated then either 1) The senior bank people you talked to are lying to you 2) the senior bank people you talked to really don't know anything about PSD2 3) They mistated to you how PSD2 changes will affect this 4) You misunderstood what they mentioned about PSD2 changes.
If a bank mentions in its clauses as per PSD2, that only authorized persons/firms are use an API and their acccess, they are authorized to negate any liability if it was given/accessed by an unauthorized party. Banks are required to make API's available (not same as accessible) to any SaaS or other developer as long as it is authorized by the bank.
Rather than relying on hearsay or in conversation on crucial regulatory changes , might I suggest this: https://www.createspace.com/5772402
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).
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.
...how do you know?
I think it is likely there has been fraud like that though. It just doesn't get reported or even found out.
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.
We are building a better front-end for any bank on top of Teller (or any other banking API) - http://bixtr.com.
I have some friends who use SVB but they all agree on needing a a much better front-end experience - so would like to help them.
I can't even count how many promising-looking Fintech products I had to pass over because the only auth mechanism they offered was through sharing online banking credentials.
Until bank policies regarding credentials-sharing actually change, I think it's really irresponsible for products to even ask for credentials at all, let alone offer it as the default/only auth option. Users could be unwittingly putting their entire life savings at risk.
Is this a realistic concern? I thought the point of a bank was that situations like that can be reversed 100% of the time.
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.
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.