Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe Financial Connections

stripe.com

Post reply on HN
Print view View original

251–260 of 263 posts

Re: Stripe Financial Connections

#251

Post by dakev »

seenit wrote: post #197

Hostile integrations using scripts to obtain financial data is trivial. Frameworks such as: https://github.com/teampoltergeist/poltergeist 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 tha…

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.

Re: Stripe Financial Connections

#252

Post by dakev »

edwinarbus wrote: post #55
zachperret wrote: post #29

Earlier quoted context omitted.

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 fe…

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. Our pricing is upfront: https://stripe.com/en-us/financial-connections#pricing . We’ve worked with a large beta group of…

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?

Re: Stripe Financial Connections

#253

Post by dakev »

dylan604 wrote: post #28
andy_ppp wrote: post #22

Earlier quoted context omitted.

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

Re: Stripe Financial Connections

#254

Post by andy_ppp »

dylan604 wrote: post #28
andy_ppp wrote: post #22

Earlier quoted context omitted.

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?

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.

Re: Stripe Financial Connections

#255

Post by amonroe369 »

seandoh wrote: post #239
amonroe369 wrote: post #233

Earlier quoted context omitted.

MX has the best stability and connections. Plaid tends to be better for Payments and early stage fintechs. Yodlee for investments.

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.

Re: Stripe Financial Connections

#256

Post by xtrimsky1234 »

zachperret wrote: post #29
ianstormtaylor wrote: post #10

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

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 fe…

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.

Re: Stripe Financial Connections

#257

Post by dylan604 »

andy_ppp wrote: post #254
dylan604 wrote: post #28

Earlier quoted context omitted.

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?

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 tok…

>Imagine if you had to renew your account for Facebook every 90 days, I think they would never have built a business.

You're not winning any sympathy from me with this at all.

Re: Stripe Financial Connections

#258

Post by seandoh »

amonroe369 wrote: post #255
seandoh wrote: post #239

Earlier quoted context omitted.

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.

I was more so referring to the quality of the account connections (frequency, reliability, amount of data pulled, etc.)

I don't think any of them are actually evil!

Re: Stripe Financial Connections

#259

Post by andy_ppp »

dylan604 wrote: post #257
andy_ppp wrote: post #254

Earlier quoted context omitted.

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 tok…

>Imagine if you had to renew your account for Facebook every 90 days, I think they would never have built a business. You're not winning any sympathy from me with this at all.

Ahah, but you understand the point ;-)

Re: Stripe Financial Connections

#260

Post by dgildeh »

edwinarbus wrote: post #55
zachperret wrote: post #29

Earlier quoted context omitted.

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 fe…

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. Our pricing is upfront: https://stripe.com/en-us/financial-connections#pricing . We’ve worked with a large beta group of…

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.

Post reply on HN