Hacker News Reader

Comment by chatmasta | Hacker News Reader

Plaid is a great idea, but the implementation worries me. My understanding is that, for most banks, you give Plaid your username and password, and Plaid scrapers on their servers log into your online banking account. Even worse, Plaid obfuscates this behavior from users by replicating their banks login window and making it appear that you are logging directly into your bank.

I'm not sure how to feel about this, because I understand that banks' lack of open API access is the central problem. But it seems irresponsible to present Plaid as a secure solution, when its login system is technically a phishing page.

I think a much cooler, probably safer, solution would be a mobile SDK that runs the scrapers directly from the user's phone, instead of on Plaid's servers.

View on HN

It always blew my mind that services like Yodlee (https://www.yodlee.com) worked that way. I can understand it from the point of view that no traditional bank was set up to allow structured access but it never felt right to me.

In the UK there is a big push around "open banking"[1] which will bring this into the 21st century and allow for proper programmatic access to data. It's still in it's infancy but the sector here is transforming around it.

[1]: (https://www.openbanking.org.uk/customers/what-is-open-bankin...)

There's also the OpenID Financial API initiative, which aims to get financial institutions to provide exactly this need using a common API: https://openid.net/wg/fapi/

There's a push in Canada for open banking as well. I work at a smaller bank here and my CEO was talking about it to us recently.

https://www.mccarthy.ca/en/insights/blogs/cyberlex/open-bank...

It's cool that governments are taking action now, but this is a chicken vs egg scenario. If services like Yodlee didn't exist to prove that there was significant demand for programmatic access to consumer financial data by building businesses around it, would governments care? And, how many more years will it take before it gets there? With Plaid/Yodlee/Whatever you can build a Fintech app _today_ in the US that supports thousands of banks. If you're an entrepreneur that's a game changer.

Open Banking and PSD2 are both complete failures. Who is in market with a decent product built on it? Nobody is. What people need to realise is that 1st party APIs are completely at odds with the incentives to maintain the status quo, i.e. they pose an intermediation threat and in the worst case relegate banks to mere utilities with zero margin. Furthermore a bank will never use it's own public API in it's own products, hence there being zero downside for exposing a shitty one. The only way this is will happen is if 3rd party companies in the market force it to.

https://www.computerworld.com.au/article/646592/australia-bi...

"The ACCC envisages that the first tranche of open banking rules will come into effect from 1 July 2019. Within 12 months, all Australian banks, including the related brands of the big four, will be brought within the scope of open banking."

Good number of companies using it already https://www.openbankproject.com/apps/ and they claim 10K developers.

That's not Open Banking. That's the Open Bank Project, a completely separate thing. They're a company that tries to sell their platform to banks and provide a FOSS sandbox.

Or you just stop using banks and build these products on something like Bitcoin. It might pressure banks to open their APIs.

mint was built off of yodlee.

Not a Plaid user, but I believe Mint works the same way. It seems to only decrypt my bank credentials with a key derived from my session password, so I suspect Plaid, if what you say is correct, do something similar.

Basically, my password is hashed to see if I can log on. Then it's passed through a PBKDF to get the decryption key for my actual accounts, then that information gets sent to the scrapers to do the actual job. They don't store the keys after the job is done. The upshot is that a full database breach doesn't result in any bank credentials leaking, at the cost of inability to update accounts without the user explicitly logging in.

So if the hashing is done correctly, if you lose your password, they are going to be happen to sign in anymore?

Mint will update transactions in the background (not only when you log in).

In order to do so, they most likely keep your banking password around in memory.

Note: Mint uses OAuth for access to Chase bank accounts, which is great. Last I checked Plaid does not.

To add an interesting layer, financial institutions are investing in these solutions. Goldman previously invested in Plaid, and Fidelity invested in Quovo which takes a similar approach.

At some point I think it's on the banks to offer OAuth APIs, then Plaid can swap out one-by-one (if it hasn't already started).

Nylas is facing the same challenge in the email space. They have oauth for gmail, but user/pass for Exchange/SMTP.

> "you give Plaid your username and password, and Plaid scrapers on their servers log into your online banking account"

So your username and password are just kept in some internal database somewhere? The scrapers probably decrypt the credentials in-memory.

Also - "scraping" data off of an undocumented API sounds risky. How can I guarantee a "scraper" won't accidentally mess something up for me?

Well Mint messes up all the time, transactions are not updated even though Mint says its up to date, transactions are listed multiple times, etc. It's mildly inconvenient, but not really "risky." Is Plaid and other bank scraping services used for anything important?

In Europe regulation forced the hands of the banks to API-ify the data and make it accessible. In the US, as with many things, it is left to industry to sort out.

Plaid's implementation was aggressive (screen scraping, etc) but many banks are blocking that now and some, like JPMorgan Chase, have created APIs based on OFX (the industry consortium for secure data exchange) to allow controlled data access.

You, the customer, should always be able to choose which targets get to receive your data. Via OAuth mechanisms you grant them access without sharing your login/pw, and you can revoke at will.

That ... sounds like it violates every bank's ToS out there, and not the abusive buried-in-fine-print part, either. Every bank could, quite reasonably, cut off your access for this.

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?

Basically, yes.

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.

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).

> 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.

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.

> I understand that banks' lack of open API access is the central problem

Banks in the US are really behind the ball on APIs, it's true. Just recently things have started to change though. I'm the cofounder of Treasury Prime (https://treasuryprime.com/) and we have a network of banks in the US who offer API access.

It doesn't solve Plaid's use case (getting data out of 1,000s of banks), but it's great if you need deep integration into a single bank, like if you're writing a fintech app for example. If anyone would like access, feel free to email me: hello@treasuryprime.com

Also, big congrats to Plaid on the fundraise!

How many banks do you have in your network? Is there a place I can see which institutions you support?

I am a user of several Plaid-powered apps, and I will say that most of my banks eventually drop out and need me to reactivate the connection (usually because a security question is required or something like that). With an API, depending on the implementation, this may never happen, so in an odd sort of way it is more secure in that you definitely won't forget about it and have it running for years. I have to actively try to keep everything activated and running.

I used plaid as a payment option at my SaaS company. Yes, it is a great idea, but the implementation is "meh".

Reply on news.ycombinator.com