phoenixy1

[I work at Plaid] I don't know if we explicitly write down in the docs that the free Development tier isn't guaranteed to have the same SLA as the production environment, but if you're not paying Plaid there is no SLA (I mean, the usual recourse for an SLA breach is a rebate, but you can't give a rebate to someone who isn't paying you in the first place). That said, in practice the differences between the free and paid tiers for a personal finance app are not really such that someone doing a hobbyist app for personal use would notice them.

[I work at Plaid] The pricing model is here: https://plaid.com/docs/account/billing/ but @jpeeler is right that for a free app like this aimed at an audience of engineers you could also set it up for your users to BYO Plaid API keys.

I know I'm biased since, um, I do customer support for Plaid (sort of), but I think Plaid's customer support is pretty good, actually? It's all in-house, the agents are all technical and it's rare that they give a wrong answer, and I see them going the extra mile all the time to solve stuff for customers. The main cases where I've seen people get annoyed at support are when the issue is on the engineering side (or, more commonly, the bank side) and support can't really do anything about it. Sorry, I just had to chime in there since support never gets enough credit.

To some of the rest of your questions -- IMO, Plaid and Stripe both have pretty good developer experiences and are fairly easy to integrate with. I can't say much about Stripe's product offerings as I'm not an expert there. It also doesn't have to be one or the other -- you can use Plaid and Stripe in the same app for different use cases, and there's even an active Plaid / Stripe partnership.

Some of the things Plaid can do for ACH:

- Verify that the account number and routing number are correct

- Provide a super tested UI that maximizes conversion

- Verify that the ownership info on the bank account matches the personal info the user gave you, reducing the risk of fraud

- Check that the account funding the transfer has sufficient balance so that the payment won't bounce

- Do other risk checks to identify the risk that the transfer will be returned, taking into account factors like account age and type

- Real time payments (this is new, we just announced it a few days ago)

- KYC compliance, if that's something you need to worry about with your use case

- NACHA-compliant UIs

I work at Plaid, and what I generally tell people is that if your use case involves a very small, select, patient, trusted, motivated, and knowledgeable userbase -- like a "friends and family" type scenario -- then Plaid might be unnecessary. If you're doing funds transfers for a wider audience and need to worry about factors like fraud, compliance, conversion, ACH returns, funds transfer speed, etc. that's where the benefits of using Plaid start to really make a difference.

Plaid Transfer (https://plaid.com/transfer/) does this.

I understand that his perspective is not consonant with Western views and that he does place some blame on Ukraine, but he literally says "I'm against war. I'm against the current Russian government." which I hardly think is fair to represent as supporting the Russian government and the war!

It's 5 by default, but you can actually connect up to 100 accounts for free if you submit a request for full development access.

If you read the linked document of student complaints, https://nyunews.com/wp-content/uploads/2022/10/Organic-Chemi... many of the complaints, especially about the level of workload, are couched in ideological language. (Others, however, such as about the lack of feedback on assignments, are more presented in a non-ideological manner.)

To be fair, equities.fyi seems to label every company as down roughly 80% from highs -- I typed in 10 random private companies I know of, none of them were fintech, and it modeled them all as having similar valuation drops. It's possible that they all are but I wonder if equities.fyi's model is just saying "drop valuation by 80% unless there is a reason to do otherwise." (I do work at Plaid but I am responding mostly in a personal capacity of being someone who's curious about where these numbers come from.)

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

[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!)

I work at Plaid. It all depends on the bank. Most data provided by Plaid is sent from banks to Plaid via API, but some isn’t. And generally Plaid connections work fine with 2fa, but some don’t depending on the 2fa method and implementation details.

That's really an excessive wait time, I'm sorry. We are working on better systematic approaches to this issue, but in the meantime, would you be willing to send me your info so I can look at what's going on with the ticket? You can DM @plaiddev on Twitter or email customer-feedback@plaid.com

Yeah, at this point the majority of API requests that Plaid fulfills are filled with data provisioned from institutions via an API. I assume that OP was only looking at named banks who we did press releases with (e.g. Chase, Wells Fargo, Capital One) but there are many more financial institutions we have API integrations with beyond that, either via Plaid Exchange or via their own APIs. [I work at Plaid]

Plaid has direct integrations with many banks too -- Silicon Valley Bank is actually a Plaid partner for ACH processing (see https://www.svb.com/news/company-news/silicon-valley-bank-an...). Not sure when your bad experience with 2fa was but Plaid's connection to SVB has improved over the past ~6 months as we've begun to work together more closely and should continue to do so. [I work at Plaid]

I have a friend who works at a science museum. He tried to reproduce this at their cocktail hour -- he had wines dyed black and asked visitors to rate their wine knowledge on a scale of 1-5 and then identify the wines as red or white. According to him, most visitors were able to get it right, and 100% of visitors who self-identified at 4/5 or 5/5 wine knowledge were able to do so correctly. I keep telling him he should re-do this study and publish it!

To clarify -- Venmo doesn't get the credentials at all, only Plaid does. Venmo then uses an API to get the specific bank account data it needs from Plaid.

I work at Plaid and I agree that using Plaid just for getting an ACH and routing number leaves a lot of value on the table. You're getting more than an ACH number and and routing number though -- you're also getting proof that the person can log in to the bank account associated with that account/routing number combo, which is really helpful for fraud reduction -- fraud in online payments is a huge problem and part of the reason many of our customers use us. (You also get, if you want it, a token that you can use directly with Stripe, Dwolla, etc. to do the funds transfer.) Another popular use case is to use the Plaid Auth API for ACH and routing number, but then also use the Plaid Identity API (again, for fraud reduction) and/or the Balance API (to help make sure that the payment won't bounce).

Unfortunately, there isn't a comprehensive list that I'm allowed to share, and even if there were we're often rolling out API access gradually because it can require implementation changes on the developer's side (for example, to support an OAuth redirect flow), so it's possible that right now a particular institution may be accessed via API in one Plaid integration but via screen-scraping in another. I think the only thing I can say here about specific institutions is that of the major US banks, Capital One, Chase, Wells Fargo, and US Bank have all issued press releases indicating that they have signed agreements with us to provide API based access.

I work at Plaid, and I responded to this on the parent, but because this is pretty highly upvoted I figured I'd respond here too for visibility: the Consumer Financial Production Bureau addressed the fact that a financial institution cannot waive liability responsibilities in a recent Compliance Aid. FAQ 4 says that institutions cannot rely on an agreement with the consumer that waives the liability protections under Regulation E if a consumer has shared their account information with a third party because those are protections provided under the Electronic Funds Transfer Act.

Source: https://www.consumerfinance.gov/compliance/compliance-resour...

Hi! I work at Plaid wanted to share that the Consumer Financial Production Bureau addressed the fact that a financial institution cannot waive liability responsibilities in a recent Compliance Aid. FAQ 4 says that instititutions cannot rely on an agreement with the consumer that waives the liability protections under Regulation E if a consumer has shared their account information with a third party because those are protections provided under the Electronic Funds Transfer Act.

Source: https://www.consumerfinance.gov/compliance/compliance-resour...

By "forward" you mean that we ask people to submit a 2FA code during login? YMMV, but I would characterize that as "supporting users who have 2FA enabled" rather than "getting around 2FA". Like I said, I'm looking forward to a world where we don't have to ask for credentials at all, but in the current world, we either support 2FA or we don't, and if we didn't, many people would probably turn off 2FA altogether. At a number of institutions, we actually add a layer of 2FA protection and require a SMS-based code if the institution doesn't prompt the user with its own 2FA.

OK, I work at Plaid and I feel like I have to jump in here -- while it's true that we've iterated on the Plaid Link UI over time and it hasn't always looked like it does now, you can see what the login screen currently looks like here: https://plaid.com/plaid-link/ and here: https://plaid.com/demo/

IMO it does clearly tell end users that they are connecting to Plaid.

Probably not? The suit was dismissed. Sorry for the paywall but I can't find a better source: https://news.bloomberglaw.com/banking-law/td-bank-plaid-sett...

[full disclosure: I work at Plaid]

I have some issues with the wording in this article (I work at Plaid and I don't think everything it says about us is accurate) but the report is a good thing. Right now we really are dependent on screen scraping at many banks and we'd much rather use API-based connections to power our services, but so many banks just don't provide APIs. I'm optimistic for an open banking future in Canada and who knows, maybe even the US some day...

I haven't read the entire report yet, but it seems like a step in the right direction (even given some of the caveats folks have pointed out). I work at Plaid and a big focus area for us is to move as much traffic to APIs as possible, with a target of 75% of traffic to be committed to APIs by EOY, and we’re hopeful that we’ll be close to a fully API based industry in the next few years. IMO anything that makes API-based connectivity and open finance standards more widespread is a win for both fintech developers and anyone with a bank account.

Hi! I work at Plaid. We’re strong advocates for API-based connectivity -- our goal is for 75% of our traffic to be committed to APIs by the end of the year. As part of that, we've actually converted our integration with Capital One to be 100% API-based and use OAuth for authentication. You can read more here: https://www.capitalone.com/about/newsroom/data-sharing-agree...

Hi! I work at Plaid. This is false. We do not do that.

Sorry you got hit by that! I work at Plaid -- most of Plaid's APIs can be used without a $500 monthly minimum contract but a few of them do require it -- we know this is a pain point and are currently looking into how can make pricing on these products friendlier to small developers.

Hi, I'm a little late to the party, but I saw this and I do work at Plaid, so I thought I might be able to help answer. First disclaimer: I am definitely not a lawyer. However, the basic premise that banks' liability guarantees are contingent on account holders never disclosing credentials is, as far as I understand it, not correct.

Basically, your rights to be protected against unauthorized transfers are provided under Regulation E, which gives customers the right to address unauthorized transactions from their accounts. Under Reg E, once a consumer properly notifies their financial institution of an unauthorized transaction within a specific amount of time, the financial institution is obligated to limit the consumer’s liability for the unauthorized transaction.

If you provide proper notice to your bank under Reg E, your bank cannot waive their liability, even if you shared account information with a third party. The Consumer Financial Protection Bureau (CFPB) made this explicit in a recently published Compliance Aid. Quoting the relevant section from their FAQ below:

"Q: If a financial institution’s agreement with a consumer includes a provision that modifies or waives certain protections granted by Regulation E, such as waiving Regulation E liability protections if a consumer has shared account information with a third party, can the institution rely on its agreement when determining whether the electronic fund transfer was unauthorized and whether related liability protections apply?

A: No. The Electronic Fund Transfer Act (EFTA) includes an anti-waiver provision stating that “[n]o writing or other agreement between a consumer and any other person may contain any provision which constitutes a waiver of any right conferred or cause of action created by [EFTA].” 15 U.S.C. § 1693l. Although there may be circumstances where a consumer has provided actual authority to a third party under Regulation E according to 12 CFR § 1005.2(m), an agreement cannot restrict a consumer’s rights beyond what is provided in the law, and any contract or agreement attempting to do so is a violation of EFTA."

Source: https://www.consumerfinance.gov/compliance/compliance-resour...