3 ms·
Hostile integrations using scripts to obtain financial data is trivial. Frameworks such as: https://github.com/teampoltergeist/poltergeist https://github.com/
by seenit 4y ago
Hostile integrations using scripts to obtain financial data is trivial. Frameworks such as:
https://github.com/teampoltergeist/poltergeist 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 than rely on Plaid is perfectly reasonable.
After all, the tools to implement such a product are well known.
- NorwegianDude 4y agoWell,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.
- dakev 4y agoI 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-relationship-between-stripe-and-stripe-s-service-providers 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.