Connectivity Gaps with Modern Financial Institutions – Is Quicken’s Aggregation Strategy Evolving?

@xriley75 Those are fair questions to be wondering about as a longtime Quicken user. Unfortunately, I have never seen a Quicken executive above the level of a product manager post on this forum, and I have never seen anyone share long-term product strategy here.

As you likely know, Quicken was the original product at the founding of Intuit some 43 years ago, but grew to be an ever-smaller and more niche piece of the company after the turn of the century, suffering from benign neglect, until it was sold off in 2016. But the stand-alone Quicken company was still tightly tied to Intuit's connectivity processes, and the code in Quicken's legacy and newer products are built around it. It might be possible to yank out Intuit connectivity to replace it with Plaid or another aggregation partner, but I suspect that would be a massive undertaking (especially with parts of the Quicken Windows code that date back 3+ decades, and even Quicken Mac's connectivity code approaching 20 years old. But even if Quicken is quietly working on a strategy to switch away from Intuit for connectivity, I just cannot imagine that being discussed publicly until that was a done deal and they're ready to launch the new direction.

That's mostly about your first and second questions. Your last question is how Quicken is adapting as financial institutions move away from older Direct Connect, I think we have been watching that process over the past few years. Quicken developed the back-end systems to handle the newer FDX/OAuth API token-driven API, and more and more financial institutions have made the change. Some have had little o no announcement or fanfare, and have worked pretty much seamlessly. My bank is an example: I was told to follow a process to login via the bank's website, and within minutes, I was smoothly up and running on the new connectivity. And we've also seen financial institutions stumble badly due to errors in design, coding and/or testing; Fidelity's woes since the fall are the most recent large-scale example of that. But the answer to your question is that Quicken has adapted to support the change to FDX.

Your third question is the one it might be possible for a product manager to comment on if they are so inclined. Quicken Mac has long had a very limited CSV import — going back to the start of the modern Quicken Mac in 2014 — which was built to provide a migration path for people interested in switching from Mint.com. That limited import benefited Quicken because it brought in new customers. Only in the past year did Quicken officially embrace CSV import as a documented, supported method of data import — but they didn't expend any development effort to make it more flexible, more user-friendly, more broadly usable. (Heck, they didn't even both the take the Mint name off the menu command for CSV imports, even though Mint shut down two years ago.) There certainly is the potential for them to create a field-mapping UI to make it easier for users who want/need to import CSV data. But I don't know if they want to, since many users could really mess up their data by mangling CSV imports, and then complain to Quicken Support to fix their problems. Again, I'm doubtful anyone from Quicken management will talk about their future plans for this, simply because they don't talk about their future plans for any features.

(and to be clear, I'd love to be proven wrong if some senior Quicken employee posts here to address your questions about their future directions! 😀)

I'm curious about how having multiple aggregator providers works. First, I imagine there's a substantial cost for the added provider. But assuming Quicken could absorb that cost and do the development work to integrate another data provider, how would Quicken determine which provider to use for each of the 10,000+ financial institutions they use? Someone manually selecting which provider for each institution? Does the existing FIDIR.txt file come from Quicken of Intuit, and if the latter, how would a list of financial institutions from an aggregator like Plaid be integrated? And would this be transparent to the user? That is, if someone or some process determined that Intuit's connection to XYZ Financial is not working but Plaid's is, could Quicken just switch, temporarily or long-term, behind the scenes? Does the OAUTH token for connectivity to XYZ Financial work independent of which aggregator is connecting, or would the user have to disconnect and reconnect their account(s)? Are the same error codes returned by each data provider, or would Quicken have to build new error messaging if it's different?

The way I have seen it done in other products is the user selects at the time of setting up the online connection.

@Chris_QPW So from that statement, if my connection to XYZ Financial goes out, I'd have to disconnect and re-connect using the alternative aggregator, going through the OAUTH login process. I think that would be confusing to a lot of users.

What I thought @xriley75 was suggesting is that a proper implementation would somehow allow on-the-fly switching, behind the scenes, if one aggregator can't connect but another can. If the user would be responsible for making the switch, on an FI by FI basis, and Quicken is just providing the infrastructure to do so, I see that as more resilient but more complex for users.

This is definitely not a trivial task, and frankly one I doubt Quicken Inc will ever take on.

Some comments about connectivity to specific FIs which Simplifi is doing successfully while the Classic products are not seemed to indicate they may already be doing this to some extent. Specifically:

In the Simplifi community forum [moderator Natalie] seems to have solved the connection to Bilt 2.0 via Plaid.

Maybe they are using Simplifi as the proving ground for new technology, since it's a newer code base and can be quickly iterated on the fly to fix problems without needing to release repeated product updates for users to install?