Hacker News Reader

Comment by MaxGabriel | Hacker News Reader

> We're doing all we can, and working with other financial service providers to make this transition as smooth as possible.

The biggest thing for us would be if you could support Plaid's Identity product by returning names and emails when someone links a Brex account with Plaid.

When someone links an account using Plaid, having this data available means we can compare that to the names/emails we have on file and have verified. If it's a match, this makes it _dramatically_ less likely someone is trying to commit ACH fraud against a Brex customer.

This makes it safer for us to offer higher ACH pull limits to that customer. Even for customers who never switch away from Brex, this would significantly increase protection from ACH fraud.

- Max T, CTO Mercury

View on HN

I just wanted to say that I absolutely understand why you prefer users to use Plaid's identity product (the startup I work at does this as well), but I HATE that it's becoming the standard way to link checking accounts. Both from a data sharing perspective, and from a training users to enter login information into random forms perspective.

There has got to be a better way for us to accomplish this.

> There has got to be a better way for us to accomplish this.

One path forward is Oauth, which several major institutions use on Plaid (Capital One, Wells, Chase are ones I know of).

This definitely solves “entering login information into random forms”.

I’m pretty sure I have seen these institutions offer you some control over what data you share when you link, but it was minimal control, and didn’t work well. Ideally that would be more fleshed out.

You’d still be sharing balance and transaction data with Plaid though, that part isn’t solved by Oauth. I think to solve that you need to have a European style standard banking API that makes direct bank-to-bank data sharing tenable?

There should be a law for this. The EU as an open banking API law, that requires banks to make this data available electronically over an API.

The US needs an open banking law. This should not be an optional feature for banks to offer. It should be an absolute requirement.

I think it's insane to enter your credentials into Plaid. Almost every banking agreement I've ever seen disclaims liability if your account is breached because you shared your password. So, if you share your password with Plaid, and Plaid is breached, and someone uses your banking credentials to drain your account, I think a bank could wash their hands of it and walk away in that situation.

I'm sure the Plaid engineers are great, and that their data is stored securely (and maybe they don't store the password at all in there systems). But I'm not willing to bet my entire bank account on them being perfect.

Plaid is almost 10 years old and I think there are probably several verbatim comments on HN since the introduction of Plaid. Unfortunately I don't think we will ever see a such a law; the landscape has changed from 10 years ago and:

1. Plaid has been pretty much been blessed by the largest player in the space (the , now blocked, acquisition from Visa).

2. The banks are glad to outsource development of banking apis to one single customer. Even CapitalOne who seemed horrified at the integration built an Oauth endpoint.

3. The queue of banking regulations is a mile long and is deeply politically controversial among those who vote.

4. Our geriatrics in congress will never see this as an important issue.

It's just easier to not use Plaid.

Oh, yes, I would absolutely never use Plaid, or any service that requires it in the meantime.

But, there are many services that should exist, that could be safely used, if such an API mandate existed.

I actually think it’s a matter of time. Eventually the current state of affairs will lead to a crisis. Someone operating like Plaid (a centralized nexus of banking passwords) will be breached, funds will be drained, and banks will shrug.

At that point, the API law becomes much more likely. Banking regulations have a way of moving very slowly until a crisis erupts.

Another path is, once most of the bigger banks develop their own APIs, they will probably push for the regulation as a path to making it harder for smaller banks to compete.

> if you share your password with Plaid, and Plaid is breached, and someone uses your banking credentials to drain your account, I think a bank could wash their hands of it and walk away in that situation.

is "Plaid is breached" necessary? Or is it enough for bank to be aware that you used Plaid?

I don’t know, I’m not a lawyer, just a concerned bank customer that read my TOS.

My guess would be that your bank account being compromised would need to flow in some way from you sharing your password. But, it might be a matter of “who has the resources to make a claim in court”, which could be a challenge for most people if they just lost their bank account (hell, it would be hard for most people even with access to their savings)

From what I remember from reading my bank contract: they claim that any password sharing and blatantly insecure behavior waive bank responsibility.

It may not be enforceable, but in my case any use of Plaid or Plaid-like tool would allow bank to claim that they are no longer responsible for any fraud.

(for reference - I am from Poland, never encountered any nonscam asking me for my bank account, though banks have different variety of problems)

[I work at Plaid] Not to get into too much of this, but the Consumer Financial Protection Bureau has issued guidance that banks are still required to comply with the consumer protection measures provided by Reg E (and thus cannot fully disclaim liability) even when a fraudulent transfer is the result of password sharing. More info at https://www.consumerfinance.gov/compliance/compliance-resour...

Though this is still obviously not a replacement for open banking and would I still love open banking laws in the US (and hopefully better implemented / constructed than the open banking laws in Europe!)

Can you provide more specifics on this?

I reviewed the register https://www.federalregister.gov/documents/2011/12/27/2011-31... and the link you provided.

I don't see anything that would extend the coverage to a service that is providing a read-only view into the account, or anything that mentions password sharing. I _think_ I could see what you're describing in maybe the description of the transitive nature of Regulation E to cover "non-bank payment providers", but I don't see anything that would protect me if I shared my bank password with Mint via Plaid?

I'd love to know more, and as a lay person I'm having a hard time working my way through all the language of Regulation E.

Sure. The most relevant section would be the "Error Resolution: Unauthorized EFTs" FAQ section in the link in my previous post, especially FAQs 4-8.

(Also, just to clarify how Plaid works, Plaid does not share account credentials with Plaid's customers, so you wouldn't be sharing your password with Mint via Plaid. Instead, Plaid provides token-based access to data via an API.)

Thanks! That was very helpful!

After looking at those answers and reviewing the relevant parts of Regulation E that it cites, I do feel like the regulation pretty-comprehensively disallows banks to impose liability on the consumer for sharing their password. Answer 8 especially that notes that no waiver of Regulation E is allowed makes me feel more comfortable.

I'd still support an open-banking API law, but your citations here have really turned down the urgency for me on that issue.

(And, yep I'm familiar that Plaid does not share the password beyond itself and the relevant bank it's authenticating with)

Plaid is a menace. My checking account was synced on Venmo just fine using the small transfer method for years until plaid was introduced. I redid the old school verification 3 times before giving up and linking via Chase. I changed the password afterwards but of course that unlinked me again. Can’t wait until some regulatory agency comes after them.

It really annoys me how some service/startup gets build around the large "infrastructure" (in a broader sense) deficiencies in the US. Because of the size of the US market and the amount of VC funding they then become big and move into markets that have had perfectly functioning solutions (like the EU in this case). Because they are so flush with cash (and much conversation/advertising online is very US centric) they then become dominant even in markets which had a perfectly functioning system that never needed they solution.

Uber is an example of this (taxis had issues in Europe/Australia as well, but by far not as problematic)

Question for ya,

Why can’t a Mercury wire or ach successfully clear to Circle?

As a Mercury customer what I know is that not a single one I’ve tried has worked resulting in days locked funds.

Iirc, with our current partner bank Evolve + technology provider Synapse, ACHs and wires have “Synapse” as the sender name on a certain field, instead of your business name.

This is (as far as I understand) wrong. Fortunately it usually doesn’t break anything, but Circle is more strict about this saying the business name.

We have a new partner bank we just launched where we have full control of the ACH stack, where we’ve resolved this. Also trying to fix the issue with the existing partner.

Caveat that I didn’t check this answer with anyone, since it’s early.

We use to be with Synapse and Evolve too - have thankfully moved on ;) We went through the same pain with Synapse that it's their name and not the customer's name on the wire. I thought at Mercury's scale you could get them to change this by now.

That is correct. If you are open to a Mercury competitor that works with Circle and is more web3 friendly try https://every.io/

Mercury rejected our LLC when we applied there yesterday so not sure where to go now (and no idea why we were rejected). Is there any reason not to go with Bluevine?

Hey, we looked into this. It looks like you registered in Rhode Island in 2016, but Rhode Island later revoked your business registration:

http://business.sos.ri.gov/CorpWeb/CorpSearch/CorpSearchRedi...

https://opencorporates.com/filings/1091852658

Does this sound correct to you / if so can you remedy it with Rhode Island? (edit: our onboarding team says you specifically want a Certificate of Good Standing from the state)

That said, this should have been communicated as a clear rejection reason—we'll work on that.

Yeah we are waiting on accountant to finish taxes (which are on extension) for 2021 so we can submit and get a statement of good standing with RI so we can renew our registration. Mail forwarding failed to forward our annual statement document for 2021 so we won't be in good standing with RI until that happens. I got in touch with accountant today to see if they can escelate but they are still a few weeks out.

update: I have been in touch with RI. Should be a month or so and we will get a certificate.

We accept LLCs at Every.io, which is a Mercury alternative: https://every.io/

Every.io sounds interesting. Except I have never heard of the company, there are misspellings on the webiste and the address is a mail drop in San Francisco. And nobody else ever heard of the company with zero links or information anywhere online. So they pay 4% APY but its a company nobody ever heard of.

Reply on news.ycombinator.com