Does Quicken have more coverage for OAuth2.0-based connections on the roadmap??

molocheris

Currently, I can only use automatic synchronization with two institutions: American Express and Chase since your connection to them uses OAuth2.0. I will only do automatic synchronization with organizations who use OAuth2.0 since it's easier to revoke access and Quicken should only request read-only access.

I know the likes of Yodlee or whatever don't implement this because it doesn't give them as detailed information about the account that they can anonymize and resell.

I'm hoping Quicken will start implementing OAuth2.0 connectors more widely because it's much, much safer from a security perspective (not to mention that the terms of service with my institution's online banking features have a lot to say about aggregators that use the root username and password).

So I'm wondering, is wider coverage on the roadmap? As a security engineer, I'd really, really, really like to see that.

Boatnmaniac

Quicken and Intuit (the aggregator) are working with the Financial Data Exchange Consortium to develop and implement a new connection method based upon OAuth2.0. The Quicken/Intuit response to that is called Express Web Connect+ (for QWin) and Quicken Connect (in QMac….yes, no connection method name change for QMac…why not? I don't know.).

In Quicken, it started to roll out about a 1-1/2 yrs ago with Schwab being the 1st financial institution to adopt it. And as you noted, Amex and Chase have also already adopted it. Others that have already adopted it include, Capital One, PayPal, Bank of America, USAA, US Bank and now PNC Bank. I might have missed a few others.

While Quicken has not announced (and will not announce) a roadmap of this they have confirmed that more financial institutions will be transitioning to it. We just don't know who nor when. But if you take a look at the Consortium member list at https://www.financialdataexchange.org/FDX/FDX/The-Consortium/Members.aspx you will see the list is pretty extensive. It would be a fair assumption to make that all or a large number of these members will eventually adopt the new connection standard in Quicken.

This rollout to the new connection has been highly controversial among some Quicken users, most notably among those who use Direct Connect for downloading and for doing DC Bank Bill Pay from within Quicken because these functions go away when the new connection method cuts in. What also goes away is Quicken's QuickPay. That and the new connection method is much, much slower than DC and has been less reliable both in setting up the initial connection and for downloads. Hopefully, these issues will become less problematic as Quicken learns more about the process and what the problem triggers are.

Boatnmaniac

Quicken and Intuit (the aggregator) are working with the Financial Data Exchange Consortium to develop and implement a new connection method based upon OAuth2.0. The Quicken/Intuit response to that is called Express Web Connect+ (for QWin) and Quicken Connect (in QMac….yes, no connection method name change for QMac…why not? I don't know.).

In Quicken, it started to roll out about a 1-1/2 yrs ago with Schwab being the 1st financial institution to adopt it. And as you noted, Amex and Chase have also already adopted it. Others that have already adopted it include, Capital One, PayPal, Bank of America, USAA, US Bank and now PNC Bank. I might have missed a few others.

While Quicken has not announced (and will not announce) a roadmap of this they have confirmed that more financial institutions will be transitioning to it. We just don't know who nor when. But if you take a look at the Consortium member list at https://www.financialdataexchange.org/FDX/FDX/The-Consortium/Members.aspx you will see the list is pretty extensive. It would be a fair assumption to make that all or a large number of these members will eventually adopt the new connection standard in Quicken.

This rollout to the new connection has been highly controversial among some Quicken users, most notably among those who use Direct Connect for downloading and for doing DC Bank Bill Pay from within Quicken because these functions go away when the new connection method cuts in. What also goes away is Quicken's QuickPay. That and the new connection method is much, much slower than DC and has been less reliable both in setting up the initial connection and for downloads. Hopefully, these issues will become less problematic as Quicken learns more about the process and what the problem triggers are.

molocheris

@Boatnmaniac thank you for the detailed answer.

IIUC Express Web Connect+, where they've implemented it, will use the OAuth2.0-based system but where they haven't used the traditional encrypted username/password pair and screen scrape.

It sounds like the limiting factor is financial institutions lagging on this, not Quicken/Intuit. So if I want this implemented faster I should bug them. Thanks for informing me on that.

… has been highly controversial among some Quicken users …

… I can understand why automated bill pay features would be missed for some people but, as a security professional, it is simply not worth the risk IMHO.

That and the new connection method is much, much slower than DC and has been less reliable both in setting up the initial connection and for downloads.

… without performance numbers (which would only be released by Intuit?) I find that hard to believe. "Direct connect" which, if I'm understanding you correctly, is the method they use by which they store your username and password pair encrypted in order to sign-in to the institution's website, scrape it, parse it, extract the information, etc. As a software developer who has written software that scrapes websites and software that calls APIs, scraping will always (modulo bugs or mistakes) be much slower and less reliable (because websites change for web users not for scraping bots) than a well-supported API. A well-supported API should be more stable, support backwards compatibility, and because it's returning a payload that doesn't include noisy HTML, javascript, css, etc it should be much more performant and reliable.

OAuth2.0-based credential flows can be complicated to implement, so I imagine there might be some bumpiness for the institutions in implementing it but thus far my experience has been better using OAuth2.0 where it's supported and it hasn't been bumpy at all.

Knowing that my username and password aren't stored anywhere but my head and instead there's a revocable, read-only token granted by me to Intuit that has an expiration window gives me much more peace of mind.

Thanks a lot for your answer, it is what I was looking for.

unsatisfied

If you don't know what Direct Connect, why would you presume to comment on it? That is pretty arrogant.