nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Banks/Brokerages with OAuth updates and TOTP logins?

SomebodyInGNV

I'm becoming concerned about the exposure created by providing my user ID and password to sync banks and brokerages with Quicken. I'm comfortable syncing where the third-party aggregator is required to authenicate through the bank during setup and don't store my password.

Can anyone tell me which banks and, especially, brokerages, offer Time-based One-Time Passwords (TOTP, e.g., Authy or Symantec VIP) for user login to the web, and require third part aggregators to connect by way of OAuth or some other read-only method? Fidelity offers Symantec VIP for TOTP but implementing that will break Quicken updates, and they (Fidelity) don't require Quicken to use OAuth for data updates.

Find more posts tagged with

Accepted answers

Chris_QPW

In this world of aggregators/companies/financial institutions that don't have any standards for doing this and no transparency, I can't say anything for sure, only guess.

The only protocol that Quicken uses that is transparent is Direct Connect/OFX. Here are some of its attributes.

Usernames and passwords are kept in the data file in the password vault, the password vault is encrypted. The usernames and password aren't stored anywhere else except at the financial institution.
The connections are made with https, so they are secure.
Quicken logs both sides of the OXF conversation (send/receive) in the log file for me to view (Help -> Log Files -> OFX Log).
Some financial institutions use a "username"/password that isn't the same as the one used at their financial institution, but it isn't constantly changing like you would find with OAuth2.
Some financial institution treat the Quicken data file as a "device" so that you have to authorize use for each one.
The only part that Intuit provides to the conversation is the URL to contact the financial institution's OFX server.

With Express Web Connect, here is what is published.

The connection is, Quicken syncs with Quicken's "Quicken Connection Service (QCS), which stores transactions in a cloud data set", this in turn connects to the Intuit server, the Intuit server connects to the financial institution's website and gets the transactions.
The sync between Quicken and QCS is the same one done for sync to Mobile/Web. The only difference is that if you haven't turned on sync to Mobile/Web then those GUIs can't display what is synced.
For the connection between Intuit's servers and the financial institution, the only thing that is stated about it is in fact inaccurate. They state that nightly it goes out and gets the transactions and stores them on its servers for Quicken to retrieve. This is proven to be somewhat inaccurate because in some cases it is much more interactive (even though it still does seem to do the nightly retrieval). Getting transactions that were just posted, sending multiple factory authentication requests, and such.
The logging seems to be done in the Cloud Sync log (Help -> Log Files -> Cloud Sync Log). Unlike the OFX log where there is a set protocol, the Cloud Sync log is more like a developer's log for debugging.

To me the bottom line is this.
With Direct Connect, you need to ensure that your machine isn't hacked. It would be very nice if OAuth2 was used, but Quicken can't impose that on the financial institutions.

With Express Web Connect, it varies with the financial institution, and unless you can get the financial institution to tell you the process they use or guess it from what you have to do to connect to them, there is no telling exactly what they are doing.

Getting the username/password out of the aggregator is a good step, but it isn't really that secure unless you have rotating tokens. And note that this is more about the aggregators than Direct Connect/OFX. Charles Schwab stated that then have 4 plus aggregators wanting to get at transactions. They lumped Quicken into that, but it is quite different. With the others the username/password were being stored on the aggregator's servers, but with Quicken they are stored on your machine. So, by changing over to their own API for the connection to Intuit, they have forced Quicken to use Express Web Connect/Intuit/an aggregator. Clearly for the other connections/aggregator storing a "token" is more secure than storing the usernames and passwords of the financial institution, but it is very debatable for the case of dropping Direct Connect/OFX.

All comments

Chris_QPW

I have never seen anything that would allow the user to identify what the exact system that is being used for Express Web Connect, only Direct Connect/OFX.

Intuit (Which Quicken Inc pays for these connection services) never states any details on how they do it other than we know they have an "agreement" with the financial institution (or the third party they use for this connection), and that it isn't the "the same for all".

Even with the new switch for Charles Schwab, Charles Schwab has stated that their API doesn't use the website username/password, and uses a "token" instead, they have not actually stated that they are using OAuth. It might be, it might not be.

As of now only 4 financial institutions downloading investment accounts use Express Web Connect/aggregation, Charles Schwab being the latest the rest use Direct Connect/OFX. In the case of non-investment accounts most financial institutions use Express Web Connect, only about 2,500 out 15,000 provide Direct Connect.

Note that even though one could use OAuth2 to connect with Direct Connect/OFX I haven't seen any that do, and doubt that Quicken knows how to do OAuth2.

SomebodyInGNV

IIRC, creating some connections requires Quicken to spawn a window to authenticate this the bank. I surmise that the bank is issuing an identifier to Quicken and my user ID/password is not stored in the aggregator's system. Or am I confusing my experience with YNAB with that of Quicken?

Chris_QPW

Usernames and passwords are kept in the data file in the password vault, the password vault is encrypted. The usernames and password aren't stored anywhere else except at the financial institution.
The connections are made with https, so they are secure.
Quicken logs both sides of the OXF conversation (send/receive) in the log file for me to view (Help -> Log Files -> OFX Log).
Some financial institutions use a "username"/password that isn't the same as the one used at their financial institution, but it isn't constantly changing like you would find with OAuth2.
Some financial institution treat the Quicken data file as a "device" so that you have to authorize use for each one.
The only part that Intuit provides to the conversation is the URL to contact the financial institution's OFX server.

With Express Web Connect, here is what is published.

The connection is, Quicken syncs with Quicken's "Quicken Connection Service (QCS), which stores transactions in a cloud data set", this in turn connects to the Intuit server, the Intuit server connects to the financial institution's website and gets the transactions.
The sync between Quicken and QCS is the same one done for sync to Mobile/Web. The only difference is that if you haven't turned on sync to Mobile/Web then those GUIs can't display what is synced.
For the connection between Intuit's servers and the financial institution, the only thing that is stated about it is in fact inaccurate. They state that nightly it goes out and gets the transactions and stores them on its servers for Quicken to retrieve. This is proven to be somewhat inaccurate because in some cases it is much more interactive (even though it still does seem to do the nightly retrieval). Getting transactions that were just posted, sending multiple factory authentication requests, and such.
The logging seems to be done in the Cloud Sync log (Help -> Log Files -> Cloud Sync Log). Unlike the OFX log where there is a set protocol, the Cloud Sync log is more like a developer's log for debugging.