> bank could, quite reasonably, cut off your access for this.

It's worse than that. Sharing passwords with third-parties typically "voids the warranty." If money is stolen from your account, the bank can deny reimbursing you because giving a third-party your password voids their zero-liability guarant guarantee.

This is actually false in many jurisdictions, including the entirety of Europe.

Can you link to some information about that? I know at least one of my banks (I'm in the UK) has that in their ToS. Is that invalid? If so, how?

Re-read your bank ToS. If you're in Europe, it won't be in there. Such provisions are not compliant with PSD2.

It does, but it still allows large businesses to be built on this rather fragile approach, see for example (european) SOFORT that got sold to Klarna. The only thing they did was allow you to pay directly with your bank account in online-stores that used them although banks (mostly) didn't cooperate with SOFORT (they also conveniently checked you account balance and any prior failed transactions).

They could, but they won't (barring a change in the ecosystem). Basically everyone does exactly this when a bank doesn't have a federated login system. Take, for example, Personal Capital.

So all these services are storing plaintext passwords for the banks?

Yup. When done as-correctly-as-possible those passwords should be encrypted on a per-user basis and keys should not be stored in the same datastore as the ciphertext. That's what we ultimately did for a project circa 2013; I assume that most folks do similarly.

Basically, yes.

When you sign up, you grant the service the limited power of attorney to login as you. Typically a POA needs to be witnessed and/or notarized. I'm not sure how they're getting around that.