Chase moves to Open Banking API

[Jack]

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
>