phoenixy1

This rule of thumb, when used correctly, is supposed to refer to womens' dress straight sizes. As in, for an average height woman, losing 10 lbs is roughly equivalent to going from a size 8 to a size 6. It doesn't refer to clothing that is sized as "medium", "large", etc. (I did not read the article; it seems from the quote that the author was using this rule of thumb inappropriately and out of context.)

These are really good changes for your overall health, but what I hear anecdotally is that a lot of the young adults diagnosed with colon cancer don't have traditional colon cancer diet/lifestyle risk factors. There's even a theory that healthy activities like long distance running might be contributing to cancer risk.

Yes, Anthropic, OpenAI, and Cloudflare, among others.

I think what you're missing is that prior to the acquisition, Anthropic was a customer of Stainless. They did not need to "rummage through [their] data and workflows" to understand the quality of their product.

The front page of Hacker News was not exactly the place where I was expecting to discover that you were changing jobs, but congrats, Tim!

You totally could, but the purpose of the OpenAI/Plaid integration is to help you analyze your spending and finances with OpenAI (using it as a budgeting/financial planning app), so if your spending isn't actually in the account you connected, it's not going to give you any value.

This is a common belief, but the CFPB has stated your bank is still legally required to make you whole in the event of fraud even if you handed over your username and password to a third party, and that any bank TOS stating otherwise are not valid. This is covered on the CFPB Electronic Fund Transfers FAQ, under the Error Resolution: Unauthorized EFTs, Question 8: https://www.consumerfinance.gov/compliance/compliance-resour...

We just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, I posted some details below.

Actually, as part of publicizing our new hobbyist-friendly onboarding, we're looking to work with hobbyists who have created Plaid-powered apps and would be interested in making a short video about their app and their Plaid experience to potentially be featured on the Plaid blog -- if you're interested, shoot me an email at ahoffer@plaid.com and I can send you the details.

So you don't have to be a business to use Plaid, but you do have to be a business to buy Plaid via the Sales channel rather than via the self-serve channel. Admittedly, when folks reach out to Sales and ask to buy Plaid and are told they're not eligible because they're not a business, this nuance is sometimes not communicated very well (or at all). We're working on it. :-)

In fact, we actually just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, so try checking it out -- after you go to dashboard.plaid.com and create an account, you should see a "Free trial" button show up on the homepage with a link to use the hobbyist onboarding flow.

Plaid has a pay-as-you-go option that's only about $2/month for this use case. (I believe the current rack rate PAYG pricing is 30 cents per month per connected bank login).

Thanks for the details! Glad to hear you've got full Production access -- if any of the security attestation requirements seem unreasonable for your use case, feel free to reach out to us directly (you can email me at ahoffer@plaid.com and let me know you're the person in this thread) so we can look into it.

You do need to set up Link, but it's pretty easy. The Tiny Quickstart(https://github.com/plaid/tiny-quickstart) has a bunch of minimal examples. If that's too much we have a super-minimal, no-code set of instructions for making API calls in the Postman Quickstart (https://github.com/plaid/plaid-postman?tab=readme-ov-file#ma...).

Plaid does support personal use (including personal use access for Chase). I'd actually be interested in seeing where you saw that it doesn't support Chase for personal access so I can make sure our messaging is clear and consistent on that front!

It's true that the current onboarding flow is not designed for personal use cases; we're currently in the middle of revamping it to make it less onerous for non-business users. In the meantime, I recommend you just fill out the questionnaire as well as you can. We know that some of the questions don't really make sense in a personal use context -- just try to answer them to the best of your ability and you should be fine.

Plaid does have products that do request bank credentials, but those products are not used for age verification. It's very common that a given customer-facing flow will use multiple Plaid products together to handle multiple different customer needs, so it's likely that the flow you were working with was using multiple Plaid products and requesting bank credentials, but for a different reason than to perform age verification (for example, KYC + bank account ownership verification or KYC + bank account validity verification).

I work at Plaid. Plaid's KYC product doesn't ask for bank login credentials. (EDIT: I originally had a line in here saying "nor do any of our competitors' KYC products, that I know of." but then someone in this thread linked to Stripe documentation saying that Stripe does use this method of age verification in Australia, so TIL.)

My heuristic is that if your interlocutor asks follow-up questions like that with no indication of why (like “why do you want to do X?” rather than “why do you want to do X? If the answer is Y, then X is a bad approach because Q, you should try Z instead”) then they are never going to give you a helpful answer.

I work at Plaid, so this got me curious about who their provider was -- per Wikipedia, Mint used Intuit's internal account aggregation tools from ~2010-2024. It's possible that Mint swapped out to some other third party provider and Wikipedia doesn't know about it, but based on both internal and external records, I'm pretty sure it wasn't Plaid. (Intuit's Credit Karma, which was marketed to Mint customers as a replacement after Mint shut down, does use Plaid.)

TD Bank has signed a data sharing agreement with Plaid: https://stories.td.com/ca/en/news/2023-12-14-td-bank-group-a...

From the article, it's not clear that the prevailing reasonable meaning was Connected Parties. In fact, it sounds like the author thought the meaning was connected parties -- otherwise he would not have bothered to disclose the relationships of the two shareholders who were connected parties (lowercase) but not Connected Parties (uppercase).

These were popular at my workplace maybe seven years ago, and while I was into the idea at first, IMO it was impractical most of the time. Turns out it's a pretty unreasonable burden to place on people that they should read and follow instructions in a document in order to communicate with someone and to personalize their work approach for every person they interact with.

The main context these make sense in is when written by a manager (or maaybe by a direct report for their manager). They can be useful to establish expectations for a team around things like "is it ok to message me on the weekend" and "here's what you should have prepared for our 1:1s".

The context isn't fully spelled out, but Powell is describing the inspiration for "The Interrogative Mood: A Novel?" Those lines are the beginning of his novel and the novel itself is entirely in the form of questions.

I can't speak to the Plaid/Square integration specifically and why transaction history is requested in that case, but in general, a common reason Plaid would want transaction history for an ACH transfer is to do risk assessment for ACH returns. The product marketing page for Signal explains what the merchant is getting out of it: https://plaid.com/products/signal/

It's not. But an article explaining the real reasons why your resume was immediately thrown out (you have none of the required qualifications; you live in Australia and the job is only open to US applicants; you applied for the same position a month ago and were rejected then) would be too boring, I guess.

I work at Plaid. The basic, non-discounted rate for the Transactions API is like 30 cents per connected account per month (or 45 cents per month if you're buying some optional add-ons to go with it), and any customer the size of Intuit would definitely be getting some kind of huge volume discount. I can't speak for other companies in this space, but I assume they have similar pricing.

I work at Plaid and I think that pricing info is a bit off — assuming we’re talking about just the APIs for transactions data (which is what the budgeting apps typically use) and these prices are in USD, even customers who don’t qualify for any volume discounts are paying closer to 30-45 cents per month per connected account. (Volume discounts then can start to kick in starting at a total API spend of $300 / month -- the higher the monthly API spend, the greater the discount percentage.)

All banks work in the free Development environment, but for banks on OAuth, including Chase, you need to go through the Production approval vetting as a pre-requisite. Once you've been approved for Production (and if applicable for the given bank, gotten your security questionnaire approved as well -- I think Chase requires this) you can then access those banks in Development for free.

[I work at Plaid]

I will say that while annoying (especially for Chase, which has the most paperwork-type requirements for developers) this process should be totally doable for solo developers. You can put your own name as the legal entity name if you don't have a company. The Master Services Agreement (MSA) sounds scary but is just the contract between you and Plaid -- the legalese laying out what you're paying for, what Plaid is providing, and the rights and obligations of both parties. And when it comes to the security questionnaire, fill it out as accurately as you can, but you don't need to stress over it -- Plaid doesn't expect a solo hobbyist to have the same security measures as, like, a publicly traded company.

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