Almost three years old, but https://www.eff.org/deeplinks/2019/12/mint-late-stage-adversarial-interoperability-demonstrates-what-we-had-and-what-we seems relevant, if a bit outdated.

On 2022.10.08 16:26, Jack via KMyMoney-devel wrote:
While direct connect using ONLY name/password may not be considered safe, I can think of ways to still use Direct Connect with 2FA. For example, any attempt to make such a connection triggers a text to a mobile phone, where you can reply "Y" within some limited time to authorize the connection. A variant is something that Heroku uses (owned by Salesforce, it's hosting site for web apps) which is a custom phone app. When you try to log in to their site, the app pops up and you click OK or not, to allow or block the login from a browser. Absolutely no reason to totally scrap something that has worked well for years and give various commercial entities near full access to your financial information. I largely trust my bank to do a good job protecting my data, but I'm not at all so comfortable with Intuit or Yodlee (who I never heard of until this discussion.)

I wonder if FSF and/or EFF might take any interest in the direction this is going.

Jack

On 2022.10.08 16:13, Dawid Wrobel via KMyMoney-devel wrote:
Hi,

Are there any US banks and investment
> brokers which still support OFX direct connect, and are not likely to
> follow the herd?
>

It's inevitable for all banks. OFX direct connect is not safe, with mere login/pass credentials required to log in to a financial institution. And
frankly speaking, I agree with this sentiment, login should require 2
Factor Authentication at all times. The notion that only a curated list of institutions/businesses can apply to have access to a bank's API is also reasonable, as this further strengthens the safety. Unfortunately, we get
hit with collateral damage, but it's not all lost — despite a similar
approach by the German FinTS standard, KMyMoney was still allowed to become a certified software and allows German/Austrian/Swiss banks customers to use KMyMoney to download transactions on the fly while remaining compliant
with the regulations.

So with that in mind, something definitely can still be done: in a form of an open letter to the industry/legislator/your favorite senator, bringing
awareness over the loss of control over one's funds, as well as the
companies like Intuit getting a front seat treatment to bank's APIs, the smaller proprietary software having to resort to Saltedge/Yodlee, which inherently severely affect users' privacy, and lastly over leaving the Open Source software at a complete loss. I can see how GnuCash, Skrooge, Money Manager Ex, Ledger, Firefly III et al would also want to get involved in
this.

At least they still provide an qfx file from the website. I suspect that
> may not last long.


Well, OFX Direct Connect is getting scrapped for reasons laid out above. Banks will continue to offer a statement export feature. Which, in fact, I believe could be leveraged as a workaround to the above problem with Woob.
It already supports scraping banks' websites to obtain transactional
history, but that's rather complicated and prone to frequent failures due
to websites continuously getting updated. What
I imagine that would help instead is to extend it with an ability to
simply pass
the from/to dates and download the OFX/QIF statement generated on the fly. This would make the scraping code required way smaller and, as such, more
reliable. In fact, something similar already exists (
https://dev.woob.tech/api/capabilities/bill.html), except this one is for downloading pre-generated documents. Shouldn't be too difficult to have it extended to also support downloading docs generated on the fly. Would love for Woob maintainers join the conversation here, AFIK they are subscribed
to this list.

It needs to be noted, though, that any form of automated log in to a bank's website often puts users doing so in breach of their ToS. So while we're still in power to code away something functional to replace Direct Connect with, it would inevitably be a *hacky* way around the problem — a problem which can ultimately only be solved through awareness, advocating, and
eventually a further, privacy-friendly legislation.

--
Best Regards,
Dawid Wrobel


Reply via email to