Wells Fargo's Bid to Vanquish Screen Scraping

This is good to hear, but also rings a bit hollow given the industry's history with trying to keep data locked up. There are very simple things the industry could have done long ago to make their users more secure and they've done none of it. For instance, banks could have let users create read-only credentials to give to aggregators greatly reducing the potential for fraud. They could've created application-specific passwords, similar to what Google has done, that would allow more intelligent application of MFA and such...every time I log into Mint, I get a text message from Vanguard telling me that an unrecognized device is attempting to log in, requiring me to fix the account in Mint. Instead, they've basically adopted a "let's make it as difficult to scrape as possible" mentality which has contributed to the insecure and buggy situation we have today.

APIs are good, as are OAuth-style permissions requests where users get to at least know what data a service is asking for. But they shouldn't be used as a way to kill off screen scraping. They should be a better option that allows screen scraping to die off normally. The aggregation industry that scrapes hates it even more than the banks do. It costs them a ton of man power to keep it working and each integration needs to be done as a one-off. If the banks provide a better solution, it will get used. Better yet, if they can come up with a single standard API that will work with most/all banks, that would be even better. But if the banks also take measures to prevent scraping, it is going to cause problems and not be a good thing for account holders.

A more informative title for the article probably would have been "Wells Fargo to publish API". It's about damn time too. Government, take note.

Retail banking is a classic case of diametrically opposed incentives. Banks rely on the opacity of their products, apathy and the fear that the majority of people have of simply opening their bank statement, to inflict punitive charges on their customers. You want to keep your money, banks want to take it away from you.

Banks also depend on cast-iron control of the channel to cross-sell other products and services. The thing about 1st party bank APIs is they completely undermine all of this and that is why they haven't happened.

The end-of-days scenario for retail banking is a 3rd party coming along to build a superior banking experience atop of their APIs. The 3rd party starting from a market share of 0 has no choice but to align their incentives with the user in order to grow. This will manifest in apps that proactively warn users before their account incurs charges, notifies users when they do, and present products and services that compete with the banks but are better value for the user. A 3rd party will de facto end up owning the most important banking channel and this will ultimately devastate the bank's revenues. All of this is terrible for the bank but great for the user.

When you decompose things into underlying incentives it becomes clear why things have or have not happened and will or will not happen.

There are various initiatives to compel banks to provide open APIs, e.g. PSDII in Europe. However considering the aforementioned incentives it seems obvious that banks will not act in good faith and will find any excuse (vague hand-waving to security, fraud, etc) to subvert the UX of the API such that any service built on top of it is awful to use. A concrete example of this is the gestating RBS API, they require a 2FA SMS code before moving money over £30. This is something they do not do and will never do in their own private APIs that power their own mobile apps because users will not stand for it, but they can do this with a public API that has no users to speak of very easily.

Considering the current incentives 1st-party banking APIs (at least the ones we would wish to see) will not happen. The only way that can change that is through market forces, i.e. one bank has to provide the APIs that cause material customer churn at other banks. Given this it's clear screen-scraping is going nowhere anytime soon, in fact it will evolve, by directly hooking in to the private APIs that power the banks own APIs for more robust, and fully transactional APIs, i.e. payments and transfers.

Disclaimer: I have started a company that does this - https://teller.io/

There is one thing that often goes unnoticed: most banks they already have APIs, they're public (accesible by anyone) but not documented. I'm talking about the APIs that provide data to their official mobile apps (is there any bank without a mobile app in 2016?).

For this very reason we've created Bankscrap, a Ruby gem to unlock those undocumented APIs. The main difference with the services behind apps like Mint is that:

A) We do not use screen scrapping.

B) It's all open source! Check it out:

https://github.com/bankscrap/bankscrap

What took these assholes so long?

We've been typing usernames and passwords for our very important _banking_ accounts into third parties like Mint (instead of using OAuth) for several years now.

Thought that the article was going to go in a totally different direction before reading it. Instead of solely trying to block screenscrapers, Wells Fargo is actually providing a better alternative. If only everything worked that way

Oh, how much do I like the German HBCI standard... nice to see that at least some non-German players decide to follow the API trend.

However, it is disappointing that this is just a single bank and not a group of banks developing this - and especially, that a battle-tested standard was not adopted.

edit: in Germany, actually, there's for commercial use the DTA standard (https://de.wikipedia.org/wiki/Datentr%C3%A4geraustauschverfa...) since 1976 (!), which has been replaced only recently by SEPA/ISO20022. Meanwhile, US banks decide to follow xkcd #927 (https://xkcd.com/927/)...

Do most banks not have an API? If you use software (e.g. something from Intuit) that accesses your banking info, is it likely screen-scraping?

Forget about existing banking interchange formats which (from personal experience) wells fargo both doesnt supportOFX or implements poorly QFX, they should definitley define a new API and be a leading stakeholder.

While reading this article, I remembered an article posted to HN about the introduction of TAuth from teller.io that might be relevant to this discussion.

https://news.ycombinator.com/item?id=11636847

Perhaps Wells Fargo should finish implementing their website first. They’re missing basic services like letting you make a wire transfer online. Our company is in the middle of switching banks because dealing with them is such a hassle.

It would be nice if an industry standard developed around Oauth for financial data. It would be far easier for data aggregators to use, and far safer for customers as well.