[sjtgraham]

Hi,

Firstly, we don't always need a credential. Some banks provide other auth mechanisms, e.g. EMV CAP. We use this for Barclays and Nationwide. Using Teller might not violate your bank's terms of service, which is why we advise you to read them in conjunction with ours. Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping"

Secondly, we have ongoing dialogue open with every major UK bank at very senior levels, from C-level down. We want to help banks deliver these APIs. Formal agreements with banks are a key strategic objective for Teller, but they only started returning my calls once I'd broken their apps and took their APIs. The market can't wait for the banks, developers and users want new choices, apps and service now.

[viraptor]

> 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.

[BrandiATMuhkuh]

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

[djsumdog]

This is what always worried me about services like Mint.

[curun1r]

Mint is probably the one you don't have to worry about. The service that stores credentials and scrapes bank sites is the same one that powers TurboTax and QuickBooks. Intuit spends a lot of money keeping that service secure and they're well aware of how catastrophic a breech would be.

In short, that service is run out of private datacenters, not publicly available. You'd have to compromise not just Mint/TurboTax/QuickBooks but then the FICDS service, which only has methods that take a token representing the credentials and passes back transactions, not the actual credentials.

It's the competitors to Mint who can't afford their own datacenters and don't have the many millions of dollars to put into securing their service the way Intuit does that should be much more worrisome.

Disclaimer: I used to work at Intuit, though not on any of the products I mentioned. But I have had many conversations with the people that run Mint and FICDS and I know the overall architecture used. I give my bank credentials to Mint without any worry. It would probably require a state-level entity to get in, and they'd likely need to get someone hired into that group to facilitate it. The service is very secure.

[tempestn]

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.

[curun1r]

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.

[tempestn]

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...

[pbreit]

what is FICDS? What does it mean "quickbooks online is decades old"?

[dugmartin]

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.

[curun1r]

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.

[mfrye0]

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...

[fweespeech]

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)

[d0while]

Me too.

[gregable]

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).

[thwarted]

I believe Wesabe had an implementation that did this.

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)

[viraptor]

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.

[echion]

> I'm already doing bank screen scraping for myself

Any tools you recommend, or is it all hand-rolled?

[viraptor]

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.

[mkurz]

Looking forward to that blog post since we need to solve something similar.

[deejbee]

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.

[smichael]

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.

[meredydd]

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.

[stouset]

Yeah. "No cases of fraud or loss due to screen-scraping" doesn't mean your service isn't going to be the one that leaks a treasure trove of banking credentials.

It's also highly probable that it has happened, it just wasn't attributed properly.

[chirau]

Why do you assume everything has already happened? Do you also assume Gmail passwords have already been hacked? Just asking.

[stouset]

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.

[lazyasciiart]

Define 'hacked'. http://money.cnn.com/2014/09/10/technology/security/gmail-ha...

[dbbk]

To be fair I think there is still going to be a lot of appetite for a service like Teller once PSD2 launches to unify these individual bank APIs. They may not even all work the same way. It'd be much better to have one entry point than develop for multiple different banks' implementation.

[traviscj]

The Stripe business model, basically.

[objclxt]

> 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??

[EpicEng]

It sounds to me like you added a lot of detail around a core message of "yes, you may be violating your bank's ToS by using our service, please verify this by reading through page upon page of legalese in your spare time."

Well... no thanks. I (and likely many others) would only consider using such a service if I had a guarantee, both from you and my bank, up front.

from your ToS:

>"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise."

Oh geez.

[djsumdog]

Yea, unless you're developing jointly with banks, with lots of oversight and liability insurance, this is a disaster waiting to happen.

[brango]

It wouldn't surprise me if it wouldn't stand up in court either. Short of having a huge banner that says "WE WON'T ACCEPT ANY RESPONSIBILITY FOR ANY LOSSES IF YOU USE ARE SERVICES, TYPE 'I AGREE' TO CONTINUE" I imagine someone could probably claim that the risks weren't sufficiently highlighted.

There's a reason every investment-related advert has to state that "The value of your investment may go down as well as up", etc.

[dnh44]

At least in the U.K. Banks are starting to provide API's so bookkeeping platforms can securely download bank feeds without having to give a 3rd party login credentials.

[EpicEng]

Sure, and when they're in place (well, a US version I suppose) I would consider using a service like this. Until then, no way.

[Zenst]

Would be prudent and indeed consumer friendly if you where to go thru those TOS the banks have in conjunction with your own and provide a simple at a glance list of liability/impact. Reassure people that way and shows, you care and thought this thru beyond saying we recommend reading this and that as people are wary and equally might not understand it.

Sure would take time and some effort, but would certainly return well for such an effort and as said, people would appreciate that greatly, so can only help you and your business.

[EpicEng]

They'd likely be opening themselves up to huge liability if they did that though.

[diggernet]

Far better to leave their users open to huge liability instead, eh?

[EpicEng]

From a business perspective? Yes. If you go out of business it's game over, and it's unreasonable to expect them to provide legal advice.

That said, I don't think the business model on display here is tenable at all and I don't think it will be successful. I certainly wouldn't sign on for this, way too risky.

[resf]

On the other hand, if the only way you can stay in business is by deceiving your own customers, what you are running is a scam.

[EpicEng]

I wouldn't say they're being deceptive. I don't see them making guarantees, and their ToS is as clear as it is scary.

[ddalex]

But they wrote in their TOS that they are not liable....

[PeterisP]

Credential storing is a big risk.

While it may be true that there hasn't been historical fraud attributed to "screen-scraping", what has been seen historically is insider fraud - you pretty much have to expect a certain rate of incidents where your own employees, included tenured ones in high trust positions, will intentionally risk jail time and attempt to steal money; in the finance industry (despite all reasonable precautions) it's not a question of if it will happen, it's a question of how often it'll happen (i.e. if it's 1 incident per annum per 100 employees or if it's 1 incident per annum per 1000 employees), how large will be the impact (most precautions don't prevent the risk as such, but limit the amounts involved), and what are you going to do about it.

E.g. the idea that your main technical administrator might sell a database of stored credentials to organized crime; (or get his/her family kidnapped in order to get access to them, that has happened as well) isn't ridiculous fiction, it's a rare but feasible scenario that's more likely to happen than e.g. a datacenter burning down, so what you're going to do in similar cases is quite relevant, not only to your own internal risk analysis but also to your customers. A bank might say "oh, we've got it covered, but if a major hack-event happens, our capital reserves and deposit insurance will still guarantee that you don't lose your savings" - an API company can't fall back on that.

[pricechild]

Anecdotally, I've seen banks claim the reason for $something_bad was a virus on a chromebook.

Whether or not there's 'been a single case of fraud or loss attributed to "screen-scraping"', I believe most banks are more than happy to blame you by default and make it difficult/expensive to resolve.

[nailer]

Most people don't really distinguish between viruses and worms, and there's been worms on Unix systems before (hi RTM!)

[reviseddamage]

>it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal

If that is close to explicitly as you have stated then either 1) The senior bank people you talked to are lying to you 2) the senior bank people you talked to really don't know anything about PSD2 3) They mistated to you how PSD2 changes will affect this 4) You misunderstood what they mentioned about PSD2 changes.

If a bank mentions in its clauses as per PSD2, that only authorized persons/firms are use an API and their acccess, they are authorized to negate any liability if it was given/accessed by an unauthorized party. Banks are required to make API's available (not same as accessible) to any SaaS or other developer as long as it is authorized by the bank.

Rather than relying on hearsay or in conversation on crucial regulatory changes , might I suggest this: https://www.createspace.com/5772402

[steingrd]

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).

[ErrantX]

> Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal.

I'm not sure that's the case; I thought the FCA were pretty clear one intent of PSD2 is to stop the need for screen scraping.[1]

Have you had any dialogue with OpenBanking UK etc. about their strategy on API driven interactions?

1. https://www.out-law.com/en/articles/2017/february/screen-scr...

[bowersbros]

Do you have a mailing list where I can say my bank is with "Halifax let me know when you support them securely?"

I'd like something like this, but I wouldn't want to give the bank details away.

[madeofpalk]

> It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping"

...how do you know?

[richardknop]

Key word is attributed. I guess he means no a single case proved to be caused by screen-scraping and therefor attributed to it.

I think it is likely there has been fraud like that though. It just doesn't get reported or even found out.

[thwarted]

We want to help banks deliver these APIs ... The market can't wait for the banks, developers and users want new choices, apps and service now.

It was my understanding that the YC-backed company Standard Treasury (acquired by Silicon Valley Bank in 2015) was trying to do this. I don't know where they went with this or what happened (although I believe there was techcrunch write-up about them and the purchase by SVB). Hopefully you can make this work securely because having to navigate a shitty branded (which apparently means constantly changing) web interface to monitor and move money is increasingly frustrating.

[ldn_tech_exec1]

The team from Standard Treasury ended up building SVB's virtual card platform.

[dharma1]

slight tangent - anybody have a contact at SVB?

We are building a better front-end for any bank on top of Teller (or any other banking API) - http://bixtr.com.

I have some friends who use SVB but they all agree on needing a a much better front-end experience - so would like to help them.

[sjtgraham]

Hey Jouni, meeting them today. Will mention you and connect.

[dharma1]

Thanks Stevie! You rock.