If Stripe can leverage their banking relationships to leapfrog Plaid by integrating directly with bank's APIs instead of doing screen scraping... that would be massive! It seems like Plaid's biggest weakness is the flakiness of their connections, which creates so much frustration/churn downstream.
Plaid's other weakness is their opaque, enterprise-style pricing, which is seems like Stripe is doing away with. Hopefully they can bring the price down, because lots of consumer-facing use cases aren't viable due to the high monthly price per connection.
I hope they add support for investment account holdings—it seems like Plaid is the only one that does this well.
—
Edit: digging deeper, it looks like Stripe proxies to Plaid-like "service providers" under the covers—at least for institutions without OAuth flows. [1][2][3] Presumably they'll build in-house connections over time, but it dents my hope that their connectivity will be better than Plaid's. Either way, transparent pricing and more competition in the space is still welcome!
Plaid founder here. Stripe does not integrate with any bank API's directly (AFAICT). They wrap two aggregators, MX and Finicity to build this product. (Also, not sure what MX products they are using, but MX itself is an aggregator of aggregators, including others such as Yodlee.)
On pricing, Stripe's listed rates are 30-200% higher than Plaid rates (perhaps due to high vendor costs). That said, if anyone does have feedback on where Plaid pricing is prohibiting new use cases, we'd love to hear! I'm zach at plaid if folks would like to discuss.
Edwin from Stripe here. Stripe does integrate directly with banks. In our beta period, most volume we’ve seen has been over bank APIs. Some banks do not have APIs—we use financial partners to connect with them, and we’re talking with many banks in hopes that they will enable direct API access soon.
The pricing looks higher than Plaid. $1.50 is way more than the $0.30 per linked bank Plaid charges.
However if your customer/sales support is superior you could win just on that. Plaids is terrible. Support tickets go weeks without responses, I need to speak to a sales guy just to enable UK/Canadian connections and still haven’t heard back after weeks of chasing. Other tickets can get left for similar amount of time too.
Plaid should get out of the way and make it fully self service to enable countries/features when you’re getting started, or fix their support/sales team so users aren’t waiting weeks to hear back from them just to enable a couple of countries they already support or confirm pricing.
With regards to pricing they also make it difficult as they don’t really explain the pricing well when you enable production either. They talk about “accounts” when their API talks about “items”. After enabling production my first bill confirmed (as no sales person ever responded to me on my question) that account was item, and not accounts the institution holds which would be extremely expensive! They don’t provide any examples on how the pricing works either, so you kind of have to figure it out after you enable production. AWS docs give a pricing example to help users understand how it works. Plaid should do the same or (again) improve their sales/support to answer questions on it promptly and not leave users hanging for weeks.
Anyway glad to see some competition here, if Stripe can match the $0.30 pricing, add UK/Canada and provide faster/better support they can win this market if Plaid doesn’t sort out support/sales quickly.
I am a very happy Bunq customer for 4+ years, and as a user of other Dutch banks (for a mortgage - ABN amro, in the past UK banks like FD), their overall service levels great - if I chat via the app I have always been helped quickly, flexibility with accounts, cards, automation via the APIs etc is absolutely worth the price hike. These are things I am happy to pay a few extra cups of coffee a month for as they make my life with an extended family much easier to manage day to day.
Good service levels will be a real USP, I expect. In the Netherlands where physical banks are a dying breed (especially those that deal with money. Aforementioned ABN Amro doesn't let you change a 100 Euro bill into 2 fifty bills, for instance). Especially the elderly are lost in the digital world and need guidance. For my parents for instance, every website is like a completely different app they need to learn how to use and with layouts changing all the time this is an enormous struggle to them.
I hate the fact that physical banks (and cash) are disappearing. I don't have complicated needs as to the digital services I consume, same as many other people. Then online banks become indistinguishable from the next, and it is ability to contact real people that sets them apart.
The cost-cutting wrt physical bank branches is just ridiculous. You can't even deposit or withdraw coinage at ABN AMRO branches anymore; they outsourced that to home improvement stores instead (yes, really).
Yes, I experienced that too. Acted surprised and look at me exasperated and what seemed with slight disgust when I came with actual cash to their office. "We don't deal with money, sir".
The situation with cash is overall very bad. Try to pay with a 100 Euro note in smaller cities. Almost no one will accept it, including banks. I regularly see very frustated tourists who with cash in hand are left out in the cold.
Unfortunately I did something wrong with a Betterment connection last week that caused them to lock my account for hacking attempts, until I call them, and their EST support hours are only in times I'm in meetings in PST so far…
but at least I don't use their checking feature, which they're oddly excited about despite it having no advantage over other banks and no possible way it ever could have an advantage.
I got blocked as fraudulent and banned before I could even transfer my savings in to Betterment. (No problems with Wealthfront, and now a happyish customer).
Different aggregators will have different connections established based on relationships and also the priority of the bank. I've seen a ton of different options based on the fintechs apps I use from Plaid, MX, Finicity, etc. Long story short, it's usually the big banks. Different aggregators have different priorities around the amount of traffic they send over these connections though. Candidly I don't know why that is, but I have some hypotheses. Ultimately though you can assume all of the above names will have accounts like Chase, Wells, Citi, Cap One, BOA, US Bank etc.
MX and Finicity both have OAuths to like 80+% of the top 20 financial institutions. There's a reason Plaid doesn't want people switching to them and it's hella sus
Plaid used oauth for Bank of America circa 2019 when I tried, and currently uses Capital One's oauth when I try to log into it. I'm sure they use it when it's convenience (or maybe when the financial institution mandates it).
So, I got very excited about this, but it seems that banks are expecting "bank integrator" aka companies, and not giving access to end users :( If any knows of a bank that has API access in the US do share!
You might find luck using companies targeting algo trading. A lot of companies allow use of the account more like a checking account (eg interactive brokers). They have an API and also allow different logins to have different authorizations.
There are ~10k depository institutions in the US. Maybe 20 of the largest offer OAuth connections (look at the list of FDX members for a good proxy).
Plaid, Finicity, and Yodlee all purport to support both those direct connections with big banks and the long tail of smaller banks and credit unions. It reads like Stripe has built some direct connections (where possible) and is wrapping other providers for everyone else. That is also, as I understand it, what MX does.
I'm confused here. So from my understanding, Stripe plugs into the APIs of banks who already have them (like every other aggregator), then relies on existing aggregators for the 95% of banks who don't. In addition, your pricing is "in line" with "the market".
My question then, is: what is the upside here, then? As a hypothetical fintech developer, why do I choose Stripe for my use case over the established competition? Why would I want my end-user's credentials in transit between multiple companies, for the same price as the rest of the market, with no improvement in performance or uptime?
@zach this is what I find very frustrating about the current players. We recently got pricing from you and obviously being under NDA won’t share the figures but I’m not seeing the discount you quote above compared to stripe.
Further there are significant platform minimums and platform fees that add large costs initially.
How do you reconcile the above comments from our interaction?
It sounds like the issue noted above is less the actual pricing, and more that it's difficult to find out what the pricing is.
This matches up with my personal experience - I had to get in touch with an actual human and ask them for the pricing just to see if a project would be viable. I did get a relatively fast response that made the pricing very clear, but because it didn't come with any caveats (e.g. volume-based pricing or "we need to negotiate pricing on a per-client basis") it almost made the experience more frustrating.
Basically if your pricing is simple and universal enough that you could post it directly to the pricing page, you should post it to the pricing page. Especially for developer-focused products, hiding the pricing can lead to a serious reduction in conversion.
My use case is transaction data so the pricing for Stripe's competing product isn't posted yet, but if I was choosing between the two products and only one had pricing clearly posted on the website I'd immediately go with that one unless the pricing was so ridiculous that it wasn't affordable. And if the pricing was ridiculous, I'd probably assume that Plaid's pricing was just as bad.
Basically, I should be able to evaluate your product and its pricing without engaging with any of your employees wherever possible. I routinely remove companies from consideration because I can't plug them into a spreadsheet of prices without going back and forth with a sales team whose time I'll just be wasting anyway.
Plaid doesn't have publicly listed pricing at all. Might as well be infinite.
If a startup can use Stripe, who they're already integrating with, or integrate with a new provider with hidden pricing that requires them to contact a sales person, I wonder who they're going to choose. Good luck.
> That said, if anyone does have feedback on where Plaid pricing is prohibiting new use cases,
I remember in a previous company we migrated out of Plaid into SynapseFI because Plaid started charging a high price on a per connection request service (like, requesting a new bank connection for a new customer was quite expensive).
It seemed Plaid was focusing on the Mint like use cases: low number of users, allowing them to setup a Plaid connection one time to be used extensively subsequently. While our use case was more akin to: lots of users/authentications doing one time connections that may not be reused. (kind of what might be used for credit risk analysis, although the company was not doing that).
Unlike Plaid, Finicity and Yodlee have direct integrations with some banks. Example: Silicon Valley Bank has direct integration with Finicity. SVB through Plaid breaks quickly (because they require some weird 2fa policy).
Let me know if I'm missing something but if Stripe is A) providing reliable connection to common banks Plaid misses and B) saving it's users from all the headaches of integrating with old school services like Finicity/Yodlee, then charging a premium sounds like fair game.
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]
Hate to argue, but I agree that Plaid's connection to SVB is indeed unusuable. I've been trying to use them for over a year and we ended up dropping SVB just this month. Chase is on OAuth and WAY better if you need TXN data.
A partnership for ACH is more related to importing stable routing and account numbers, then enabling initiating ACH transfers. Scraping transaction data is a completely different integration that seems to have been forgotten.
Sadly, I'd even wager SVB-Plaid data won't improve any time soon. Remember that SVB doesn't even yet allow external bank transfers on their own bank portal.
Thanks for the reply! I came to that same conclusion about their use of "service providers" after reading through their support docs (and added an edit above), definitely a bummer.
We all wish more banks had API's! Our team is actively working with many more banks to launch them soon, but alas -- legacy infrastructure is slow to move!
As a developer I love the idea of plaid, but the pricing is scary. The 100 first banks is great, but the pay as you go does not give me any ideas of the pricing.
I love how Stripe presented the pricing page, 1.5$ per account, 10cents per fetch balance. Very clear. I still have no idea how much plaid will cost me.
I'm very familiar with both Finicity and MX. I know that MX isn't an aggregator of aggregators. Stop lying bro. Tell people about how you abuse credentials and take some responsibility rather than trying to constantly pass the buck and blame others.
Hey - can you please make your substantive points without personal attacks or swipes? We ban accounts that do those things—especially new accounts showing up to fight shit out like this. Not cool, no matter how right you are or feel you are.
Also, it's not in your interest to post like this to HN anyhow. The audience will only side against you if you fulminate and call names. If you want to win readers over, you should drop all that and instead provide specific, concrete information and say what's important about it.
(Before anyone misinterprets the above: I have no idea which side you're on. I haven't looked at any of the comments you've replied to. All I know is that, whichever side you're arguing for, you're going about it in the wrong way for HN. If you'd please review https://news.ycombinator.com/newsguidelines.html and fix that, we'd appreciate it.)
You seem pretty clueless about your competitors and you are talking poorly, very openly about them here Zach. That is not a good look in any way and reflective of a poor corporate culture.
If MX and Finicity are aggregators of aggregators, that would still mean Plaid would benefit, right? Maybe you (and your sales team) do not know your competition.
Publicly airing grievances as well against Stripe, who you could potentially partner with in the future, reflects an underlying toxic corporate culture at Plaid. I do not think Stripe will likely ever want to do business with you after this and prevent others from doing the same. I have never worked at Plaid, but I am not inclined to want to work with you based on what we are seeing here. Plaidsettlment.com
Plaid and their lawyers should have hashed it out with Stripe then in RFP. I work for a big bank. If we send out RFP's for a project there's language in there that most providers never look at. It basically says "I can do whatever I want with information in the RFP except give it to your company's competitors."
So if I am working for a top 10 bank, and I see value in a solution, if I cannot get it cheaper than it would cost me to develop it and time is not that big of a factor, I build it myself. If there are no time constraints and vendor can deliver solution at roughly the same cost I can build it for, I built it myself.
My guess as not being part of the stripe/plaid conversations or RFP. Zach's lawyers did not redline or challenge language around processes or IP with Stripe in RFP Agreements and that was likely the biggest downfall.
Plaid does have great litigation attorney's, I mean their class action settlement was only $58 million. So likely, Plaid might get something if there is IP that was protected. It will come out in discovery if a lawsuit gets legs.
fair criticism. My points remain. Having talked to Plaid's sales team, not bad people. I just don't trust providers that openly talk poorly of competitors and plaids sales team did that and the CEO of the company is doing it in public.
Do you know why Fidelity Investments plaid connection doesn’t work most of the time?
It’s something I hit often and have to do the old microdeposit thing (if I can even figure out how to trick the service into allowing me to do that at all).
Does fidelity just have some sort of broken setup?
Not sure when you were testing, but we do call out some instability on the Fidelity Institution Status page in the Developer Dashboard.
> To maintain system stability, Fidelity currently limits access during high-volume windows. As a result, please expect unavailability between 9-10:30am and 3-4:30pm ET. We recommend end users link Fidelity accounts between 5pm - 9am ET.
We've found that Plaid only leverages around 3-4 Direct API connections for some reason, why other aggregators like MX, Finicity, Yodlee all have 10+. It seems suspect to me because Plaid doesn't seem to be prioritizing the protection of user credentials the same way others are.
In this thread you've accused the founder of Plaid multiple times of lying, without evidence, and most importantly, your account was made only 1 hour ago.
You've said "Stop lying bro.", "hella sus", "This is 100% a lie", "seems suspect", all without evidence.
You seem to have some ulterior motive here that you haven't disclosed. Maybe you're right about everything, but it comes across poorly.
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 actually doesn't do investment account holdings well. My team tried using them for an app and ended up building our own API to address the problem https://realizefi.com/.
We provide real-time holdings, transactions, orders, historical performance (Plaid doesn't provide this at all), and balances.
Hey! Looks interesting. The two things that would hold me back from using it are (a) not enough institution support, for big places like Vanguard and Fidelity where many people have investments, and (b) no clear pricing structure listed that I could see, so I assume it’s going to be more expensive than Plaid.
Thanks! We're currently releasing Fidelity and will have IBKR & Vanguard released within the next 2 months.
Sorry for the lack of a pricing page - we're going to add that in. We have graduated pricing starting at $1/mo per linked account and decreasing at different levels of scale. That fee includes unlimited API calls. We're also offering discounted pricing to companies that integrate within the next 60 days.
Feel free to email me whenever at sean@realizefi.com
If they do this it would indeed be huge. Screen scraping and the like to get around a proper API sucks. In the EU we have PSD2 but the APIs aren’t all amazing.
Yeah getting a license with bafin is tough but a VC backed fintech can do it or partner or use the api of a fintech that already has a license and build off of that.
Also every 90 days you have to do some weird dance to keep the apps receiving your data, it never seems to work right and you forget. I would think building a business on such flakey APIs is dubious at best!
To fight that flakey situation of bad APIs, one decides to build a business based on flakey screen scraping instead? With financial information? What could possibly go wrong?
What's the alternative? 95% of banks in the US don't have a dedicated API. If there was no screen scraping whatsoever in the industry, then the fintech market would be much smaller. Any fintech company whose product is centered their users' financial information (and that's most of them) would see their potential customer base, and thus growth potential, sliced in half. On the consumer side of it, if you're Susan and you bank with Northeast Minnesota's Credit Union for Educators, then without screen scraping you are essentially cut off from being able to use the majority of fintech applications out there.
Screen scraping is a terrible compromise for sure, but without it, fintech, and the everyday consumer's ability to more effectively engage with their finances, would be severely neutered. One day, we'll have a rich financial ecosystem where financial institutions, fintechs, and consumers all talk with eachother exclusively through secure, reliable APIs, but until then, the only other alternative is to cripple this entire industry. Or have Congress pass a sweeping PSD2-esque bill, but good luck with that lol
I like the APIs but every 90 days is too many lost users I bet. I think it would be nice if the renewal worked like this -> 1st permissions -> 90 days, 2nd authorisation 180 days, 3rd 365 days and then every renewal after that is a year. Would reduce churn from this by probably 75%...
Even better it would be best if it just emailed you every 90 days asking if you wanted to remove/continue with permissions and did token rolling automatically without the user being involved.
Imagine if you had to renew your account for Facebook every 90 days, I think they would never have built a business.
EDIT: The accused person has denied these allegations, claiming that Plaid reached out to Stripe (not the other way around) and that the RFPs were because Stripe invited Plaid to be part of the product: https://pbs.twimg.com/media/FR8FjJ9VsAAMY_k?format=jpg&name=...
> Wow! Jay, you took interviews with Plaid & asked probing questions multiple times over the past few years, and your team sent repeated RFP's (under NDA!) to us asking for tons of detailed data. I wish y'all the best with these products, but surprising to see the methods.
I don't know. Talking with a company shouldn't disqualify you from ever working on a competing product. Sending an RFP doesn't mean you can never build your own product.
The Plaid CEO is trying to anchor the conversation around malicious intent, but it's not hard to imagine a scenario where this product-minded person legitimately explored working with Plaid, legitimately explored partnership opportunities at Stripe, and walked away believing it would be better for Strip and for himself to build a competing solution at Stripe.
Plaid's product isn't entirely novel. In my experience as a consumer it has failed at least 3/4 times I've tried to use it with my financial institutions. I'm frankly more surprised that it took this long for anyone to enter their space to compete against Plaid.
yeah, Stripe has a totally reasonable defense for this:
1. Obviously this is a product we'd want to build because our customers want it
2. We contacted Plaid to see if they wanted to be part of it
3. Plaids pricing didn't work for us so we built it ourselves / went with other providers
Not sure what you'd even get from talking to the team at Plaid that couldn't be learned in an afternoon or two using product that use Plaid and hacking on banking API's.
Right, but that doesn't imply malicious intent and it doesn't disqualify them from building their own.
Talking to companies about their product and then later deciding you'd rather build your own isn't really surprising. Plaid was definitely aware that Stripe was a potential competitor going into those meetings.
Plaid CEO mentioned "interview" but intentionally left out "8 fucking years ago, and it was a job interview".
Plaid CEO also got the RFP, so they have been aware that Stripe is building this because Stripe wanted to depend on MX, Plaid, and etc. But Plaid CEO acted surprised to this launch.
It sounds like Plaid CEO maliciously misled people. Does this guy have any ethics left?
I'd wait for the emails to come out. One side is probably hoping that won't happen.
In my view, ethics go out the window when the mantra is to eat the world. The kind of ultra-fast, ultra-huge growth that Stripes pitches to investors and also to its employees comes at great cost. We've seen this with prior tech giants like Facebook, Microsoft and Google who also invested heavily into developer PR.
> Wow! Jay, you took interviews with Plaid & asked probing questions multiple times over the past few years, and your team sent repeated RFP's (under NDA!) to us asking for tons of detailed data. I wish y'all the best with these products, but surprising to see the methods.
> Zach, sorry you feel this way, but this isn’t true and I think you know that. You reached out to me repeatedly—I never reached out to you for information. Stripe did an RFP because we work with partners for this product, and we had hoped to include Plaid.
A couple years ago Stripe reached out to me saying they like my background and that they want to discuss potential roles. I was working on a payments product at a FAANG company at that moment and was starting to think it’s time to do something else. So I said I am interested. Stripe scheduled an interview with Q… J… (Eng Director at Stripe). After a few generic questions about my past experiences, Stripe’s Q… J… asked a series of very specific questions about vendors/partners, API integration details, txn costs, etc. at my current company. I politely declined to answer these questions citing my employment agreement and NDA. I never heard back from Stripe again.
I’m surprised they had this information so easily at hand. How did they even know that? They saw the tweet and the first thing that comes to mind is to query all the people they’ve interviewed?
Interesting. I'm much less sympathetic, then. I would imagine that kind of situation would be far more formal, with lawyers from both sides present, and, to be frank, this kind of information gathering an expectation. It would be pure naivety for it not to be - these are multibillion dollar companies talking to each other!
On the other hand, if I, a random hypothetical engineer, were interviewing someone for a team, in a 1-1 situation, and they asked about what I worked I'm, I'm naturally going to be less guarded nor really prepared to sufficiently redact my answers.
I'm genuinely worried for that guy. He's exposing powerful connected people and I can't really see that end well. It's not like people retweeting and liking his tweets have any sort of power like what is alleged.
I wonder how this compares to Column, since the founder of Column also cofounded Plaid. I see both founders' comments in this thread it looks like but the Column founder doesn't seem too happy about it [0].
There also seems to be some vindication by the Bolt founder, based on his Twitter thread about how Stripe handles corporate development [1][2], it really reminds me of Paul Graham's essay not to talk to them, lest the same thing happen to you [3].
I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accounts for instant account verification and as a fraud signal for ACH payments. However, we definitely can’t do a better job than Stripe could at risk analysis, provided they had access to metadata on the bank account when processing the payment and could provide insights from their entire platform. Now they do.
I’d guess the big benefit here, besides taking some of Plaid’s existing customers, is what’s possible now that Connections lives alongside the other things Stripe offers like ACH, loans, and identity verification.
The limit to only daily pulls and up to 180 days of historical data is pretty disappointing. Would expect Stripe to push the envelope here and move down to near-instant updates and full historical data. This is basically a knockoff of existing solutions done at par or worse which is surprising to see from a company like Stripe. Maybe they've lost a bit of their magic or focus. Will be interesting to see how everyone adapts and improves to this announcement.
since they are heavily based on existing aggregators, they are limited by the lowest common denominator (if a good chunk of e.g. Yodlee-scraped credit unions only support 180 days, then that's a limiting factor for everyone).
I would expect they will gradually improve and cut out other aggregators and replace with direct connections that have more & better data as they go along.
Or maybe not, because with Oauth they then become at the mercy of the bank that issues the token (banks can revoke tokens or attach individual conditions on what data is accessed and how much).
Seems like a shiny repackaging of Finicity/MX.com with little value added. I don't see any reason to recommend this product to anyone. Or maybe they're targeting a different market. This solves exactly none of the issues I've had working with almost every bank aggregation API on the planet (Yodlee, Plaid, Finicity, Tink, Nordigen, Belvo). And boy, do they have issues.
As the founder at Fintable.io (personal/SMB finance plugin), I deal with bank connection issues on a daily basis.
- Screen scraping is 1. flaky and 2. insecure because it requires saving credentials and is 3. not realtime and 4. doesn't work with 2FA. Account balances can be out of date within minutes, and cannot be refreshed without another auth
- 95% of banks on the planet don't have OAuth APIs. The 5% that do have APIs that often don't serve customer needs because they provide the absolute minimum amount of data to meet the requirement. For example CapitalOne's API only provides access to 90 days of data. American Express does not provide access to invoice metadata, which makes reconciliation hard. Who can provide dedicated direct screen-scraping connections to banks with all the data that users want?
- When building a generic fintech product (as I do), global bank coverage is essential. The least bit of innovation Stripe could have done was save me the trouble of having to integrate 5 different APIs to get access to US, European, Latin American and Australian banks.
- In the same vein, connection to 90% of accounts is useless for many users if they can't access the other 10%. The number one need for financial planning software is "to see all my accounts in one place". Most people have at least one account with some obscure institution or overseas bank. If they can't see all their accounts in one place, this isn't solving the problem.
- This is just an API without a GUI dashboard. Another common complaint I've heard from my leads that Plaid/Finicity is only for programmers, or companies that have programming expertise. What if you're a marketing firm with need for no-code bank data visibility?
- Only 180 days of transaction data and no statements? This is much worse than Plaid and Finicity.
I guess it's nice if you can verify ACH details faster, but even then the coverage is worse than Plaid, and so I don't see any reason to recommend this product to anyone. Zero innovation and objectively worse than the current offering? Who is the target market here?
The target market (for now) is probably their existing customers looking for better risk management by checking balance data through an authentic bank connection before initiating transactions through other Stripe products they already use.
I’m sure Stripe’s hope is that this becomes a full-blown Plaid killer, but as you mentioned that’s certainly not yet the case
I meant that today is a different day from yesterday, and the day before..
It's a common English idiom.
I don't have the reference links handy but the TL;DR is that Stripe has played dirty lots of times before. The formula is:
1. Pretend they want to acquire a company with a product they like
2. Then, once they waste enough of the competitors time (buying buffer enabling them to figure out the secret sauce)
3. Clone stamp the competitors product, fucking them over royally. Also leverage the tremendous public reach, visibility, and clout of Stripe itself to promote their clone.
It's a very ugly and distasteful way of doing business. It aligns with the values of the Farenghi on Star Trek.
It's naiive on the victims part, sure, but Stripe is dishonest and shan't be trusted.
Does it collect your bank username and password, or work directly with banking APIs? Every time I see some service trying to do this via Plaid I cringe.
How much longer are we just going to keep eating up whatever the Stripe PR machine churns out? They did a great job with payments but a lot of their auxiliary products are just worse versions of other businesses.
I have been an advocate of Stripe but today I am quite disappointed with Stripe. Is this what happens when a company becomes big with thousands of employees? Copying smaller companies' product(s) while having a "partnership" with them? I wish they released an actual competing product, not a copy.
Although, from reading the docs, a lot of the products that I'm interested are still "Coming Soon" (confusingly a different verbiage but identical in meaning to "Private Beta"?):
- Transactions
- Other data-powered products
Ah, is your Stripe account live (i.e. in livemode with payments activated)? We'll look into make this smoother, but right now you'll have to leave testmode to continue.
Very excited for this. One of the major issues with Plaid is their poor support for commercial banks -- for instance, SVB. If Stripe can provide more reliable connections to commercial banks, this will be an extremely valuable alternative.
is an excellent example of such a framework. Implementing "bank drivers" using such frameworks would not be difficult.
Plaid and others seem to have done an awesome job scaling the hostile integration pattern. However, the idea that Stripe decided to build this in-house rather than rely on Plaid is perfectly reasonable.
After all, the tools to implement such a product are well known.
I agree that building in-house integrations is superior to relying on a 3rd party - it's always better for the end user when their sensitive information doesn't have to jump between multiple companies. However, by their own admission (https://support.stripe.com/questions/what-is-the-relationshi...), Stripe did not build any scraping integrations in-house. They in fact, do rely on third parties.
According to one of their PMs, Edwin, elsewhere in this thread, they supposedly integrate directly with banks that already have existing APIs - but for the 95% of banks that don't, it appears this product is just a wrapper for existing aggregators MX and Fincity.
Well,it's not always trivial. I'm not even able to log in to anything important without multifactor authentication that is either a hardware OTP of some sort, or using a private key stored in my SIM-card that is accessed with a pin.
It's doable if you really want to, but it's much more of a hassle that just running a script. Definetly not doable at scale, for better or for worse.
Finicity has a subpar UX compared to Plaid, especially considering reliability of the connections. Unless Stripe builds its own screen scraping, this imo is a worse product.
It's interesting to compare this comment with one of the other top comments on HN right now, an explanation of how Google's culture of promoting users for solving "hard problems" is ultimately a terrible, terrible strategy for their users and their company. https://news.ycombinator.com/item?id=31262428
As engineers, we should to step away from our egos and our desire to do something "interesting" and focus on where our solutions actually solve real problems, like Stripe's products (often, not always!) do. Whether something is "middleware" or "not interesting" has nothing to do with how useful or valuable it is.
I'm sure there are plenty of people working at Plaid who are really interested and dedicated in working on the kind of middleware that their co-founder is denigrating here. It's a shame they have to work for a company where that kind of polish is pushed aside in favor of ambiguous "innovation". As an engineer and a customer, I know which kinds of companies and engineers I want on the other side of the table when considering business partners, and—going solely from your comment—it sounds like Plaid isn't one of those companies.
Yeah, have to say, the level of knee jerk defensiveness here and on Twitter from cofounder level figures from Plaid does not exactly evoke confidence in their ability to outcompete.
It's probably financially optimal to put a nice veneer on an existing solution than to make something whole-cloth. They're running a business, not a charity, and besides -- as the consumer, why would you care? All you see is the facade anyways; unless you're making a point that the API's are actually leaky abstractions and the facade isn't that good (and I would respect that argument, if it were the case).
lots of respect for what you and the team have built at Plaid, but this is exactly the opportunity. As a developer who's worked at multiple fintechs and integrated with Plaid more times than I care to remember, it's an incredibly frustrating experience.
Ask any fintech and they'll tell you - Plaid is simultaneously the best and worst vendor they use. Best because there's no real alternative, but worst because it causes so, so, so many headaches with how unreliable the product is. The time spent building product workarounds at every company to account for Plaid issues is tremendous.
If Stripe thinks they can build something better, then I'd really love them to try.
Edit: William (co-founder of Plaid) seems to have deleted his comment, but it was basically accusing Stripe of repeatedly copying other companies.
Yodlee is the lesser evil here... it still disconnects accounts frequently and data is only pulled every ~12 hours.
I'm the co-founder of Realize (https://realizefi.com/), we tried using all of these APIs for our first app and found them to be super broken. Our API uses a mix of brokerages public and private APIs, which allows us to provide reliable connections and pull data in real time.
Yodlee is not the lesser evil. I have read through privacy and contracts from Yodlee, Plaid, and MX in the past.
MX as a company, are the real good guys. There is no packaging of data for third party use that has ever occurred. In fact, I'm looking through due diligence packages from MX right now and I can confirm what I am saying.
Yodlee was caught. Plaid was caught. I do not yet know about Finicity.
GP clearly retracted his statement. Regardless of whether it's right or wrong, what I'm much more sure of is people will be far too careful in expressing thoughts if the moment it's out there it will be forever imprinted into the internet and associated with themselves. I wonder if it's possible for truly ephemeral messaging wiped-clean when you would like, given the issues with someone just writing it down physically.
If Stripe knows how to pay developers appropriate salaries (this is the under-discussed reason for SV companies being the only ones who can make good APIs - BoA is never going to pay their web team more than they pay their web team's department head, that is not possible for their culture) to develop appropriate interfaces on things, then more power to them if they can do very simple things to profit in the context of the oversights of other companies.
I've wondered why Stripe and Square are more successful than their older competitors, considering they don't have a moat and there's nothing particularly special in the space for them to invent. It seems like it is just that the older companies aren't willing to try to improve.
> With the authentication flow, your user logs into their bank either through an OAuth (bank-hosted) or non-OAuth flow to authenticate access to their accounts.
> Stripe generally defaults the authentication flow to OAuth if available at the financial institution. Your integration doesn’t need to treat OAuth accounts differently than non-OAuth accounts.
No they didn't. November 2021 was not that long ago.
"You may be a Class Member if you are a United States resident and you connected a financial account to an app between January 1, 2013 and November 19, 2021....
"This class action alleges Plaid took certain improper actions in connection with this process. The allegations include that Plaid: (1) obtained more financial data than was needed by a user's app"
Citing a settlement date range with language like "may be a class member if you connected a financial account to an app" doesn't really refute my point.
If I put up a captcha on my OLB/MB login portal, I can stop most plaid traffic because it appears as RPA activity, which would be screen scraping. AND we have one of those Bank API's built that those Plaid shills are talking about.
Theres only two reasons Plaid would keep screen scraping. 1) They are still selling data to third parties or providing insights on data to third parties. 2) it is cheaper for Plaid to screen scrape than API.
Plaid CTO here. This is not accurate. On 1. We do not (and have never) sell data to third parties. On 2. We have been a proponent of open authentication standards like OAuth and App2App and today, a majority of our bank connections run via bank APIs - in fact, as Zach pointed out, we’ve helped many financial institutions move towards OAuth. We don’t want to handle credentials in the long-term. However it will take years for a full transition to APIs to happen with more than 11k banks in the United States and we feel that it's important to support the tens of millions of Americans who bank at those institutions.
Considering everything, Zach and Plaid had to walk back all of your BS about Stripe stealing everything. Under the hood, Plaid lost to MX and Finicity with Stripe, and then accused Stripe of impropriety. Stripe isn't a moral leader in this world by any means. Plaid though? You are even worse because you act smug as an organization.
There were whistle blowers in 2018 who said Plaid did sell data and I am not sure anything came of it. Why collect more information than necessary in your screen scraping? Something is not adding up.
This is bad. Stripe doesn't have to provide the best service here. A lot of companies already use Stripe making the barrier to trying this out very low. Likewise for startups, if you're already trying out Stripe billing for your MVP you're more likely to use another Stripe product than to try out Plaid.
I'd agree. A startup looking to use Stripe Atlas now has access to this for standing up their services? Plaid is basically disqualified from the start, given how cohesive the Stripe platform is.
i think it actually does. Connectivity is important, and if connections break often, then fintech will look elsewhere. It's not a matter of which color is a button, users get pissed off and leave. So the connectivity better be good.
Competition is healthy. Whether it's good or bad, we'll see. No one can divine that, but I get the sense that Plaid's product team is a bit worried right now.
I think this is the biggest thing here. User credentials need to be protected and hopefully this type of open-market approach brings about more democratization of data.
One possible reason is that ACH payments are MUCH more user friendly if they can be initiated by an end-user authorizing their bank account (compared to digging up their account #, routing #, etc and entering the info manually).
ACH payments are essentially free to process (or a very small flat fee). This is very different from credit card transactions that charge a % of the entire transaction.
If ACH / direct payments from bank accounts became more common through services like Plaid and Stripe's new service, it could mean less fees (less revenue) for Stripe to collect. Which could explain why it's not something Stripe jumped into earlier.
TLDR: if I had to guess, there's more money in processing credit card payments, and much less money in facilitating ACH transactions.
Curious that they translated it to German based on my phone settings for a product that only supports US banks? (I don’t mind that it is US banks, just… why did they pay a human to translate it?)
if you've ever used Yodlee or a similar "verify your bank" service, change your bank account password and you'll start seeing a surge in "suspicious login attempts" alerts (if your bank notifies you of such things) as these data scraping services are constantly trying to check-in on your personal financial activity
I hope they plan to leverage the "Consumer Data Right" Open Banking APIs in Australia... so far the roll-out has been disappointing, there aren't any decent PFMs in Australia that use APIs rather than crappy Yodlee screen scraping, and I'd like to program against a decent API to pull my own bank data thanks.
Anyone here know how fast ACH transfers are from one account to another?
Is it same day 3 business days?
I'm in Canada but I can use this to build something for my US clients. But if it's not same or next day, I can seem my clients not wanting to use it.
Isn't OpenBanking only UK-specific? But I agree with you, settling for a global standard would be a perfect solution. Success of SWIFT clearly shows that.
Is this logic right or wrong: All of these fintech companies allow for more convenient movement of money and integration with applications etc however they are adding additional costs to all transactions. I.e. were trading convenience for cost?
Yes, you could. You would be limited to 180 days of history on initial pull and your data would always be up to 1 day behind. Otherwise, yes, you could. It doesn't really feel like this product is aimed towards aggregators or dashboard and more for underwriting and bank account validation.
I wish more countries would be supported, like in PayPal. For example, Asian and Middle Eastern banks largely aren't supported. Same you could tell about African banks.
I honestly can't believe that there's enough people dumb enough to give their bank username/password combo to strangers to make services like this work.
Nope nope nope.
As a user, I'd never use any service that is plaid based, I don't even care that "they have proper api access now". Even though I've been fan of other stripe offerings I'd never use this either. It's beyond shady.
Friends don't let friends give out their banking creds.
If your bank supports Oauth it won't share your credentials:
>Stripe generally defaults the authentication flow to OAuth if available at the financial institution....OAuth is an open standard authorization protocol that allows users to let applications (for example, Stripe) access their information within other applications (for example, bank apps) without having to share their login credentials.
But for banks without Oauth you DO give your credentials to Stripe:
> For these banks, end users provide credentials to Stripe or one of our trusted partners.
Question: are US banking really this dysfunctional? Where I'm from, a bank consortium already provided unified login services (while banks still have their own websites, as a merchant you only need to integrate the consortium-provided APIs rather than using Plaid) simplifying things.
That is the case in most of Europe as well (under SEPA Direct Debit), and has been for many years now.
I've not had to dispute an ACH debit yet, but at least at most German banks, it's literally a single click and the money is back in your account – up to 8 weeks after the payment (any reason, no questions asked), and up to 13 months in case of fraud ("no mandate").
Part fraud controls (which don't necessarily work), part being able to undo transactions.
Being able to undo mistakes means far more than anything else; it means it's permanently superior to all ""web3"" tech no matter how much fancier they may make that look.
A check needs a signature and has some security feature built-in. You might argue that it's not sufficient, but it's the same deal as paper money for example. The cost/benefit ratio is too low for counterfeiting checks to be useful, most of the time.
The routing and account numbers are printed on every paper check in the US. Those are all that you need to process an ACH. The onus is on the ACH originator to make sure the numbers are not stolen.
I believe you need a specific bank authorization to do ACH withdrawal using only routing and Account#. Plus, your beneficiary bank does screen for such services given out to clients very closely. No random joe schmo can do auto ach debit
Unless you are referring to passing forged checks, I'm not sure what you mean by this.
My understanding is that in the US to pay your rent you either send a literal paper check, which had no serious authorisation at all, or your land lord reaches into your account using your bank account number and debits it, without you having to approve.
If not - why do people protect their bank account numbers in the US? In the UK mine is printed on my bank card - anyone can read it off.
It’s like social security numbers in the US - they became passwords when they weren’t supposed to be.
Quite interesting. In Poland a lot of places have their bank number just on their website if you want to donate something, I don't think you can place a debit like that.
"I believe you need a specific bank authorization to do ACH withdrawal using only routing and Account#"
No. All you need is an account number and routing number (which are printed on paper checks). The ACH originator is responsible for ensuring the numbers are owned by the payer.
Maybe they pointed out as an indication that some financial institutions in the US are not modern technologically speaking, and that may be a cause for lacking better APIs?
That was probably the intention but I think that isn't a core reason. It's more about business/tech incentives around these APIs. The industry is more risk-averse, and frankly there isn't necessarily a great business case for doing integrations if you're a big bank because you don't want to be commoditized into "pipes" and then have to compete on low-margin products all the while the middle companies have better margins and skim off the top of you. At least on the consumer side. There's this meme that banks are technologically backwards and all that, and I don't think that is true or a good frame of reference to have. The scale, complexity, regulatory environment, and risk-aversion when something bad happens are far and away more relevant factors than technology is.
For some systems, this is arguably a feature. Banks are rightly cautious about touching core transaction processing systems, systems that cost millions per minute when down.
But the use of COBOL generally doesn’t extend to the consumer facing product, or the APIs that support those consumer facing experiences.
Banks may be backwards, but the use of older languages is not one of the primary reasons.
What they run on their backend doesn't really matter. If they can provide a website with username/password login, they can have an OAuth layer as well. It isn't a technical problem but a business/priorities one.
I remember about 4 years ago I read online that most bank passwords did not even check for upper case or lowercase characters. I didn't believe it, but to my surprise I entered my password with RaNDoM cASe letters and it unbelievably logged me in. This was Chase bank, and I believe it has been fixed since then. But just goes to show how far behind banking systems have been.
Plaid's other weakness is their opaque, enterprise-style pricing, which is seems like Stripe is doing away with. Hopefully they can bring the price down, because lots of consumer-facing use cases aren't viable due to the high monthly price per connection.
I hope they add support for investment account holdings—it seems like Plaid is the only one that does this well.
—
Edit: digging deeper, it looks like Stripe proxies to Plaid-like "service providers" under the covers—at least for institutions without OAuth flows. [1][2][3] Presumably they'll build in-house connections over time, but it dents my hope that their connectivity will be better than Plaid's. Either way, transparent pricing and more competition in the space is still welcome!
[1]: https://support.stripe.com/questions/what-is-the-relationshi...
[2]: https://support.stripe.com/questions/how-does-stripe-limit-d...
[3]: https://support.stripe.com/questions/who-will-obtain-my-fina...