I am afraid this is yet another case of US financial institution dropping support for OFX Direct Connect standard. From the looks of it, Schwab is now offering a completely different set of APIs, ones that cannot be supported by KMyMoney – not only because of we rely on OFX standard to handle the transactions downloading, but also because KMyMoney has no legal entity in the first place, so we couldn't register with them as a financial product anyway. 

Some more discussion here: https://infinitekind.tenderapp.com/discussions/online-banking/17158-online-banking-appears-to-have-halted-for-schwab-bank

Just to add to the context: 

"Schwab have signed an agreement with Yodlee to provide data via their API to Yodlee as an aggregator."

https://pressroom.aboutschwab.com/press-releases/press-release/2020/Charles-Schwab-Reinforces-Its-Commitment-to-Customer-Data-Protection/default.aspx

So what is the solution here? If US financial institutions keep abandoning ofx, then kmymoney won't have any way to download transactions and the only solution would be to download a csv file from their website every time to import transactions?

Is there a fundamental flaw in ofx in that it does not use two-factor authentication?

Honestly, I don't know what the solution is. The industry is undergoing a revolution of sorts, triggered by EU's PSD2 directive, which the FDX initiative (https://financialdataexchange.org) seems to follow in the US. 

The problem is not really of technical nature and the increased authentication requirements, which dictate that 2 of the 3 components described as knowledge, possession and inherence need to be used to authenticate. The big issue is that these new regulations require the financial software to be registered with financial institutions[1]. In the US, it effectively means that only the big players like Intuit and Quicken Inc can afford and have legal entity to become authorized by each financial institution separately. 

That is, unless as a developer you're willing to outsource this to an aggregator (Yodlee, Plaid) and pay them to handle it on your behalf, which also exposes your users' privacy, but that's a whole different story and still out of question for open sources projects like this. For what it's worth, it has been discussed by our team before here: https://invent.kde.org/office/kmymoney/-/issues/21

Additionally, from the MoneyDance forum I listed above, it seems that Schwab did not actually remove OFX support just yet, but they limited it to specific products only (TurboTax, H&R Block and Quicken). I am guessing once said products fully implement Schwab's new API, OFX will be shut down completely.

For the record, Discover did the same thing earlier this year, except the shut down OFX entirely and do not even offer any open API to register with, only letting Quicken customers access the data, which at least in theory sounds illegal.

Although KMyMoney is not a legal entity, the KDE e.V. is.  (See https://ev.kde.org/)  I really don't know whether or not it would be appropriate, and whether or not they would be willing to register KMM (and other KDE financial apps,) but it might we something to consider.

@Jack, indeed, this is something I thought about already before and the only potential solution going forward.

The problem here, however, is that *even* if we had e.V. willing to work with us on that, only the binary distributables could offer this functionality. This is because when registering with 3rd party financial institutions, you need to provide them with a set of crypto keys, which they in turn use to confirm the authenticity of the client software accessing their APIs. Such requirement is mandated by the PSD2 and quite surely FDX, given how this is effectively the only sane way to restrict the bad actors from attempting to exploit their APIs' inevitable vulnerabilities.

Now, such signing would obviously not be otherwise possible for any free (as in speech) Linux distribution that only provides packages built by themselves (e.g. Debian), since they would naturally have no access to KDE e.V.'s unique keys to sign their own binaries with. For any other distribution, KDE-provided binaries would automatically land in the "Non-free" repository.

So, in conclusion, this full functionality would only be offered by the pre-compiled KMyMoney distributables, which may or may not go against the KDE foundation's core principles. I can see, however, how offering a financial software offering a privacy-protection *and* the ownership of ones financial data also fulfills foundation's core manifesto. So this case could fall under the "necessary evil", especially that the heightened requirements imposed by the financial regulations are no-nonsense and designed with security in mind.

I missed a paragraph after the second one:

"KDE e.V. would use the same set of keys to sign the binaries in order for the latter to be able to authenticate with the APIs, as required by the specification."

(In reply to Dawid Wróbel from comment #7)
> @Jack, indeed, this is something I thought about already before and the only
> potential solution going forward.
> 
> The problem here, however, is that *even* if we had e.V. willing to work
> with us on that, only the binary distributables could offer this
> functionality. This is because when registering with 3rd party financial
> institutions, you need to provide them with a set of crypto keys, which they
> in turn use to confirm the authenticity of the client software accessing
> their APIs. Such requirement is mandated by the PSD2 and quite surely FDX,
> given how this is effectively the only sane way to restrict the bad actors
> from attempting to exploit their APIs' inevitable vulnerabilities.
> 
> Now, such signing would obviously not be otherwise possible for any free (as
> in speech) Linux distribution that only provides packages built by
> themselves (e.g. Debian), since they would naturally have no access to KDE
> e.V.'s unique keys to sign their own binaries with. For any other
> distribution, KDE-provided binaries would automatically land in the
> "Non-free" repository.
> 
> So, in conclusion, this full functionality would only be offered by the
> pre-compiled KMyMoney distributables, which may or may not go against the
> KDE foundation's core principles. I can see, however, how offering a
> financial software offering a privacy-protection *and* the ownership of ones
> financial data also fulfills foundation's core manifesto. So this case could
> fall under the "necessary evil", especially that the heightened requirements
> imposed by the financial regulations are no-nonsense and designed with
> security in mind.

Thanks for the explanation.  So can this bug be kept open until this is resolved or is there a more appropriate place (forum or another bug ticket?) to follow the status of offering a crypto key signed kmymoney binary?