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.
I was going to ask, why do you need to give third parties read access to your account? I've never done so in my life, and can't see the use case.
Then I see further down: it's for the FUBAR tax return system in the US.
Here's a solution for you: fix your damned tax return system first (and watch Intuit go out of business in the process). Then you've solved many big problems, not just a small one.
Round here (Norway), your bank already does this analysis part. When I log into my bank's app or webpage, I get an instant overview of how much I spent last month on the mortgage, food, gas, insurance, clothes etc. And I can define custom categories, as well as change how the system sorts transactions into different categories.
The budgets for the next 12 months my wife and I keep in a shared Google Docs spreadsheet. Planning requires thought, so I'm skeptical that you can automate a budget and then have people follow it (unless it's a very lenient budget).
My bank (Netherlands) offers something like what you describe, and I would still prefer to be able to use services like Mint.
> Planning requires thought, so I'm skeptical that you can automate a budget and then have people follow it (unless it's a very lenient budget).
I agree with your point - your budget is specific to your situation, so you will still need to plan it yourself. But - once the budget is set up - don't you see some value in not having to update your spreadsheet and compare it to your bank statements? Or getting a notification on your phone that you are approaching the limit of your entertainment budget this month, because the system has tallied up how much you spent in the coffee shop?
It's a separation of concerns thing. Sure, you can use your bank for analysis, but there's better options out there. Banks are for storing money, not financial analysis.
i think if my bank offered advice, i'd strongly consider doing the exact opposite of whatever they suggested. i'd rank it up there w/ listening to jiffy lube's recommendation to refill the blinker fluid.
Actually, banks are for aggregating capital. There is no institution in the Western financial system where you can just store money. The best you can do is put physical cash in a safe deposit box.
AFAICT, it actually isn't in the general case (it may be when done with certain intent or effect), but most US banks now have a blanket prohibition on foreign or US currency in the agreement they require when you rent a safe deposit box.
The flipside of this is that I want to trust as few entities as possible with my financial data. I see some are questioning advice given by the bank (and I agree with that), but objective analysis != advice.
It's hypocrisy from banks/brokerages in general since they actually promote aggregation on their own websites. Vanguard has one, for instance - they're probably using Yodlee.
They also charge absurd prices ($10/month) for OFX access. OFX access + very simple read-only passwords would solve this whole mess of screen scraping.
OFX is great. I mean, it's not great if you have to implement it, but if you just want to use it (ie, with Quicken or GNUCash or some other piece of software), it Just Works™. The only problem with it is that not all banks support it, and when they do, many charge prohibitive fees for it.
>banks could have let users create read-only credentials
I am Australian and at least one bank here does this. We used it for a book keeper in a former company. It was helpful for the book keeper to have the ability to access our financial data to do their job without having to hassle us for data exports or whatever. At the same time the don't want to be in possession of a big collection of bank log in details that could be used to steal money.
It let them log in, export the data they needed and that was all.
Which bank are you talking about ? I'd love to have a bank account like that for nonstandard transactions. As far as I can tell, this is only possible paid.
Pretty sure it was bank of queensland but this was quite some time ago.
If you go to http://www.boq.com.au/ and go through to their log in screen this is why there are three text boxes instead of the usual two (a clunky solution to needing different login details from different people).
Certainly not CBA, but allegedly Westpac and NAB both allow "view only" access for third parties. (I cannot confirm this, but have seen it mentioned on the CBA's uservoice request for this feature[1])
I think part of the problem is people dont complain to their bank about the lack of these features, and don't ask about them when shopping around for a new bank.
Call your bank.
Ask for these features.
What have you got to lose? They'll probably ignore you, but we have to start somewhere and asking them certainly won't make things worse.
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/
1. What Wells Fargo is providing is a limited feed, to a single customer (Xero), that services SME customers and not consumers. Wells Fargo has chosen not to make the API open access at this point too. I do not see that this currently conflicts with their business model.
2. Not that I am aware of. I expect that is because the largest provider of screen-scraping feeds is prohibitively expensive (requires large up front fees and minimum commitments).
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:
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.
Correct. Most banks are running back end infrastructure from the 80s with lots of manual or semi-manual processes (e.g. overnight interbank batch reconciliation, at least in Australia). From an outsider's perspective, it appears that retail bank management is completely technically illiterate.
Which unfortunately also makes them the perfect marks for being sold inappropriate tech solutions (see: blockchain mania).
Oh yeah, don't get me started on exchanges. I'm astounded at how bad their technical processes are. The ASX (Australian Stock Exchange) has something like a 3 day time to settlement. And I'm told it's one of the more 'modern' exchanges (I guess the other ones are still using stock tickers and abacuses).
Unfortunately 2 days now. I appreciate the time to settlement because I could buy my shares and pay 2 days later. Sometimes it takes time to get funds from other accounts, and I wanted to buy (or sell) today, for example, when the quarterly just came out.
Part of me wants to sneer in disgust, but part of me considers that we live and work in a tech industry that truly, honestly believes that "move fast and break things" is a great design principle, and maybe we don't want those people in charge of the foundation of the global economy.
Apache Fineract (\’fīn-,ә-,rakt\) is an open source
system for core banking as a platform. Fineract
provides a reliable, robust, and affordable solution
for entrepreneurs, financial institutions, and service
providers to offer financial services to the world’s
2 billion underbanked and unbanked.
Not entirely. Mint only used Yodlee at the beginning, before Intuit acquired them, and that was a while ago. Even before the acquisition, they had a secret project to create a backup scraping platform because they worried that Yodlee would cut them off when the acquisition was announced.
Mint now uses an internal service (called FICDS, IIRC, but I'm no longer at Intuit) that still scrapes. That service also handles bank interactions for Quickbooks, TurboTax and Quicken, though the latter was sold off, so may be moving to something else. Additionally, that service allows the use of tokenization, which greatly reduces the chances that account credentials would leak based on a vulnerability in Mint or a rogue employee, since that team is pretty locked down and Mint, TurboTax and Quickbooks never store banking credentials.
As an aside, I wonder why Wells picked Xero to trial their API. It could have been a lot more impactful by doing a trial with Intuit, especially if they could have had it ready by tax season.
Also, here's a fun fact: For a number of years, Mint employees at Intuit could not see their own employee stock plans in Mint. Morgan Stanley's site was a Flash monstrosity that couldn't be scraped correctly. Asking them about it earned you a well-practiced eye roll.
Have suspected this for a while. Its amazingly brittle if so (coming from someone that has done ALOT of scraping). I suppose Bank UIs change slower than the likes of amazon or retail but still. Pretty pathetic
To do my own personal and business accounting I used the iOS APIs that I discovered by using Charles. I don't remember if I had to disable certificate pinning. But that's one way of getting your bank account information fed to a data source.
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.
OFX isn't great and a PITA to implelent but it's ubiquitous thanks to Quicken.
Banks move at speeds that make most glaciers jealous and Intuit has some financial incentives to keep the spec complicated so it's really no surprise we've been stuck with it so long.
A new open standard would have been nice, but I wouldn't hold my breath on other banks implementing it, so I can't really blame WF for going it alone here.
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.
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.
The process for getting approved as a startup to even use CEO was convoluted, required multiple sign-offs for no reason, and we were denied twice. It took emailing someones boss off of LinkedIn to actually get in. And the best part is that CEO Portal is terribad. The RSA tokens they send you will often go "out-of-sync" and you're SOL until they FedEx you a new one. The features list is great but the struggle with actually using the tool makes it painful.
FWIW, we switched to Bank of America and can't complain. I can send wire transfers online without issue.
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.
One huge reason there's a war going on over this is that aggregate transactional (not even itemized receipt) data is a goldmine of near-real-time consumer behavior analytics. Hedge funds love this data and companies like Yodlee (and couple of startups) are stomping over one another to sell it. A couple of startups was on HN recently
Judging by some recent statements by Jamie Dimon and others, the banks would much rather provide this information via secure APIs than allow screen scraping to continue.
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.