Yea, and that is consistent with downloads breaking after you stop paying. I’m pretty sure this is a departure from the earlier model where Quicken would download directly from banks. At least that’s how I thought it worked. I didn’t think “back in thuh day” that cloud proxy servers were required, and you could keep doing direct Bank > Mac downloads long after your support expired.
Cloud-based proxy solutions are invaluable for many software services. I build them for a living. They solve many problems: proxying adds an essential security boundary. The proxy / gateway can also handle NAT traversal, IPv6 / IPv4 translation, DOS mitigation, traffic aggregation, and lots of other things. It also factors bank-specific logic out of the desktop code, making the software solution more modular and maintainable.
So in some ways, this is me playing my own devil’s advocate, and explaining the value of Quicken’s fees. But forcing users into that model if it’s not essential is not ideal.
I’d have to better understand the technical and business considerations to really evaluate this well. But given that:
- to download from your bank, you already have to supply your credentials for each bank within Quicken, and
- your bank already lets you download transactions directly from their web site if you prefer to do it outside Quicken
I see no reason why the “old model” of direct downloads from Bank > Desktop couldn’t work using Quicken desktop software as the tool (no Cloud involved). But Quicken has little incentive to maintain the “direct” feature when the “indirect/proxy” solution is both more elegant from a maintainability point of view and also ensures a recurring revenue stream for them.