Fintech Firm Plaid Raises $44M(wsj.com)
wsj.com
Fintech Firm Plaid Raises $44M
http://www.wsj.com/articles/fintech-firm-plaid-raises-44-million-1466377808
67 comments
The lack of secure auth mechanisms is exactly why companies like Plaid (and Yodlee, and Dwolla, and Intuit) exist. Take away that constraint, and this is easy enough to package as a library and not a product.
Many "disruptive" industries like this "API on top of legacy systems" segment are merely arbitrage schemes; they profit from entrenched players' greed and apathy. Luckily, banks are starting to wake up.
As such, it's not really Plaid's responsibility to "fix" this problem, it's the banks'.
- http://www.americanbanker.com/bankthink/a-neobanks-prognosis... - http://www.americanbanker.com/news/bank-technology/wells-far...
Many "disruptive" industries like this "API on top of legacy systems" segment are merely arbitrage schemes; they profit from entrenched players' greed and apathy. Luckily, banks are starting to wake up.
As such, it's not really Plaid's responsibility to "fix" this problem, it's the banks'.
- http://www.americanbanker.com/bankthink/a-neobanks-prognosis... - http://www.americanbanker.com/news/bank-technology/wells-far...
But this isn't helping matters in any way, is it?
Just because this is the reason for Plaid's existence doesn't mean you should make a product where security cannot be guaranteed for the user. Some things just shouldn't be done, because they're not possible yet. Not possible because support from the banks is lacking.
Just because this is the reason for Plaid's existence doesn't mean you should make a product where security cannot be guaranteed for the user. Some things just shouldn't be done, because they're not possible yet. Not possible because support from the banks is lacking.
You're asking Plaid to leave $44 million on the table and walk away in the name of best practices. This is noble but unrealistic.
The security flaws boil down to the requirement that the end user must place their trust in Plaid. Plaid considers themselves trustworthy and competent enough to act on the customer's behalf with their credentials. If Plaid were to suffer a breach, their customers would not purchase their services. It is in everyone's best interest to avoid security breaches.
The web product is indeed worrisome, but it's also in Plaid's best interest to avoid dealing with fraudsters.
The unfortunate part here is that the banks have zero liability in the case that their customers lose money due to a breach of their online banking credentials. This could be solved via legislation, and I'm willing to bet that would light a fire under the industry to start embracing options such as OAuth and restricted-access credentials.
The security flaws boil down to the requirement that the end user must place their trust in Plaid. Plaid considers themselves trustworthy and competent enough to act on the customer's behalf with their credentials. If Plaid were to suffer a breach, their customers would not purchase their services. It is in everyone's best interest to avoid security breaches.
The web product is indeed worrisome, but it's also in Plaid's best interest to avoid dealing with fraudsters.
The unfortunate part here is that the banks have zero liability in the case that their customers lose money due to a breach of their online banking credentials. This could be solved via legislation, and I'm willing to bet that would light a fire under the industry to start embracing options such as OAuth and restricted-access credentials.
I've worked on integrating Plaid into a project recently. Before getting access to the production version (more than 100 users), there's a pretty thorough security questionnaire (hopefully followed by some fact-checking on Plaid's part) for the client.
They are doing their best to weed out bad (or security-ignorant) actors, but there's only so much you can do with banks directly, like you mentioned.
They are doing their best to weed out bad (or security-ignorant) actors, but there's only so much you can do with banks directly, like you mentioned.
I agree - the user should be redirected to Plaid at the very least.
I'm going to be really rude here (forgive me) but I feel like every time a security question comes up you dodge the question really hard.
I want to know one thing: If I log into your service with my bank credentials. Do you store these as plaintext files (or "encrypted" files of which you have the encryption key)? Yes/No.
Furthermore, congratulations! I've been trying to start something up like this in Europe but I feel like there are way more restrictions in Europe on banking data and this kind of third-party aggregation. Sorry for being so rude.
I want to know one thing: If I log into your service with my bank credentials. Do you store these as plaintext files (or "encrypted" files of which you have the encryption key)? Yes/No.
Furthermore, congratulations! I've been trying to start something up like this in Europe but I feel like there are way more restrictions in Europe on banking data and this kind of third-party aggregation. Sorry for being so rude.
Played around with the API a little bit.
Cool discovery: if you search for a financial institution, they return logos as Base64.
Super rad.
Cool discovery: if you search for a financial institution, they return logos as Base64.
Super rad.
Awesome news! Does anyone have a detailed and unbiased pros/cons of Plaid vs. Yodlee - thinking about integrating with one for my startup.
I think the one area I'm most interested to learn about is the data quality / depth / breadth - do they offer the same? Which one is better? Why?
regarding data quality, i've run into a few issues using Plaid for pulling my own financial data. I've had instances where the API returns duplicate charges that I confirmed were not duplicate on my bank/credit card accounts. I've also had issues with their unique id's too. When a pending charge is returned by the API they give it a unique id, but when the charge is approved they generate a new unique id for the approved charge rather than updating the existing id. They provide a field that lists the pending charge id for you to match up but i've had instances where those id's don't match up. I also run into issues where the access token for some of the institutions i have connected expire or suddenly don't work anymore so I need to re-authenticate.
I've emailed them about these issues and they've been pretty helpful in getting them resolved, but it made me reconsider building a consumer facing product on their API. I still use the API for personal use however
I've emailed them about these issues and they've been pretty helpful in getting them resolved, but it made me reconsider building a consumer facing product on their API. I still use the API for personal use however
Totally understand on the duplicate issue - its a hard problem to solve with the inconstancies from the end financial institution, and it definitely caused issues for us in the past. That being said - we've spent the past couple months making some huge improvements - I definitely encourage you to give it another shot.
Though I'll admit, I'm quite biased!
Though I'll admit, I'm quite biased!
I can offer an (obviously biased) opinion :), feel free to shoot me an email charley@plaid if ya want!
Would you be willing to share your opinion here so everyone can learn? biased or unbiased :) info is info
Sure! Here's my super biased opinion :)
A lot of the comparison is also dependent upon the use case, but I usually bring up coverage, performance, and simplicity.
Coverage - Custom integrations with the largest banks in the US that's also supplemented by "longtail" providers to give comprehensive coverage across the US.
Performance & Quality - 12 seconds or less to connect a user's bank account and begin to pull down data, which is particularly important for a mobile experience. We've also completely optimized our drop-in module used for onboarding bank accounts! (I think it looks pretty sweet: plaid.com/docs/quickstart)
Simplicity - Check out the docs yourself! (plaid.com/docs/api) usually takes only a few days to integrate, rather than a few months.
A lot of the comparison is also dependent upon the use case, but I usually bring up coverage, performance, and simplicity.
Coverage - Custom integrations with the largest banks in the US that's also supplemented by "longtail" providers to give comprehensive coverage across the US.
Performance & Quality - 12 seconds or less to connect a user's bank account and begin to pull down data, which is particularly important for a mobile experience. We've also completely optimized our drop-in module used for onboarding bank accounts! (I think it looks pretty sweet: plaid.com/docs/quickstart)
Simplicity - Check out the docs yourself! (plaid.com/docs/api) usually takes only a few days to integrate, rather than a few months.
Hey Plaid, interested user here! I'm curious why you don't have any pricing on your web page. I'm just trying to do a back of the envelope calculation on how much it would cost to use your service.
Hi Sunny - Feel free to email me (charley@plaid) and I can get you set up and share more deets! We're working on getting pricing up on the website soon :).
[deleted]
[deleted]
Does Plaid have billing data? Ostensibly, that was the motivation for Intuit's Check acquisition.
It's also interesting that Intuit runs their own massive aggregation effort that they haven't attempted to product-ize...
It's also interesting that Intuit runs their own massive aggregation effort that they haven't attempted to product-ize...
You've heard of Mint (https://www.mint.com/) right?
Badass team and product - I don't think people realize how difficult what they're doing is. Super pumped for them!
What do they do? The article doesn't make it clear. It just discusses them finding alternatives to screen-scraping customers bank accounts after being given the credentials.
Seems like a startup-y Mint.
Seems like a startup-y Mint.
Co-founder of Plaid[1] here. We build an API for developers to connect to their users bank accounts. All the 'startup-y Mints' are our clients.
[1] - https://plaid.com/
[1] - https://plaid.com/
This API looks really shiny and well documented, kudos!
Do you only screen scrape or have backend/backoffice/negotiated integrations with various banks? How do you deal with enduser bank credential storage (both technically and legally when dealing with bank ToS)?
Also, in your experience, have any standards like OFX actually achieved critical mass for adoption amongst banks, and has that made your team's lives any easier?
Do you only screen scrape or have backend/backoffice/negotiated integrations with various banks? How do you deal with enduser bank credential storage (both technically and legally when dealing with bank ToS)?
Also, in your experience, have any standards like OFX actually achieved critical mass for adoption amongst banks, and has that made your team's lives any easier?
Thanks for the kind words :)
For the top 14 banks we work closely with the banks to build connections - however for the smaller and mid-size banks we work and connect with a variety of vendors that serve those banks.
I personally sit on the OFX consortium (and a couple other financial standards committees) and I'm not overly bullish. I'll just leave this link here.... https://xkcd.com/927/
For the top 14 banks we work closely with the banks to build connections - however for the smaller and mid-size banks we work and connect with a variety of vendors that serve those banks.
I personally sit on the OFX consortium (and a couple other financial standards committees) and I'm not overly bullish. I'll just leave this link here.... https://xkcd.com/927/
That XKCD strip is very true for financial standards. :(
I think you missed a question (unless it was intentional :), but how do you deal with enduser bank credential storage (both technically and legally when dealing with bank ToS)?
For example, on the technical side, do you store the credentials themselves or just session tokens/cookies?
I think you missed a question (unless it was intentional :), but how do you deal with enduser bank credential storage (both technically and legally when dealing with bank ToS)?
For example, on the technical side, do you store the credentials themselves or just session tokens/cookies?
As ancient engineering wisdom says: 'The nice thing about standards is that we have so many of them'.
I believe some of the data aggregation is done by reverse engineering APIs of mobile banking apps. You can easily do that by setting up MITM proxy to intercept requests. In some cases, you may need to decompile app binaries to decipher password encryption algorithms.
Congratulations on the WSJ && HN feature. Great API, we use it in our product.
Awesome job btw. I love the site redesign, but it has always been quite good aesthetically. If I could hijack this comment briefly, I would like to ask how you see yourself vs. Stripe, who has a lot of advantages in the payments information space, having their own payment infrastructure and the banks recently fighting aggragators including yodlee.
They're an awesome client of ours! We also partnered with them on their ACH product[1].
[1] - https://blog.plaid.com/plaid-and-stripe/
[1] - https://blog.plaid.com/plaid-and-stripe/
Why is are the windows in the top banner moving? It is kind of trippy.
What countries do you have support for?
I'm working for a Canadian fintech startup that would truly benefit from a service like yours.
I'm working for a Canadian fintech startup that would truly benefit from a service like yours.
We're focusing on the US market right now - we'll definitely reach out when we move into the international markets. Stay tuned :)
Thanks.
I will definitely keep a close eye on your service. Here's hoping it comes soon to non-US bank accounts.
I will definitely keep a close eye on your service. Here's hoping it comes soon to non-US bank accounts.
More like a startup-y Yodlee since it's mainly back-end. Mint was initially primarily a front-end service that later made it's back-end available.
As a future consumer of your services, I'm excited to hear this, congrats!
This is really good news. Plaid has an amazing API, it makes it very easy to get your own financial data. I'm trying to analyze my own spending habits / make a budget-allocator using my own patterns, so it's been insanely helpful. My big fear with all small SaaS's if they just suddenly shutter, so a new round of fundraising is always good news :)
Also good news because they are currently being sued by Yodlee for patent infringement. Shameful anti-competitive bullshit on the part of Yodlee, who let their product get so bad it opened up the door for Plaid. Now Yodlee are trying to litigate instead of compete.
it's good to see Yodlee have some competition, hopefully they can choose to compete as well.
I can use them to just get information for my personal financial data? I would love that!
For free?
For free?
Yep - we're free for the first 100 users!
What should I do to get my personal financial info? I signed up but the interface presented is one of an app maker not for end user
That is exactly what Plaid is... a tool for developers. Savvy users can use the Plaid API to build apps that use their users' financial data.
It's free to use if you have less than 100 users, so you could easily build your own tool to manage your personal data for free.
It's free to use if you have less than 100 users, so you could easily build your own tool to manage your personal data for free.
Neat! Def gonna check it out.
Wait, you just got $44 million in funding and you don't have 100 users yet?
Assuming this isn't a joke, he means if you were to build something with their api, it is free to you up to your 100th user.
Oh, right, now I understand.
I believe that would 100 users for the service that you would write using their api. See bottom of this page: https://plaid.com/products/ (playing around with the api to help make a self-use budgeting app - under the current terms, this use case would be free).
I think we may have set a record if that was the case...
But the other commenters are correct - the first 100 additions to the api are free.
But the other commenters are correct - the first 100 additions to the api are free.
For those interested in a European perspective, the Revised Payment Services Directive (aka PSD2) will in a similar fashion to Plaid's API, force banks to offer APIs for not only client information but payment. If implemented it will probably create radical change and opportunity in FinTech across the EU.
If anyone is interested in working on a PSD2-based project drop me a line: [email protected].
Seems like the auth flow doesn't redirect to the bank's website. Does that mean that my bank credentials are sent to Plaid?
Yes. That's how Mint, Digit, and all the other "connect your bank account" apps tend to do it. I've yet to find a major US bank that has anything resembling an OAuth style flow - the closest I've seen is Wells Fargo offering generation of read-only credentials.
[deleted]
Then how is Plaid more secure than Mint, Digit etc?
Banks don't make this easy. There isn't a secure way of doing it in the vast majority of cases. Companies like Digit use Plaid to offload the risk of storing these credentials (like how most startups offload PCI/credit-card to Stripe). Intuit's big enough to have their own solution for Mint.
From this [1], they are a provider for these.
1: https://news.ycombinator.com/item?id=11939425
1: https://news.ycombinator.com/item?id=11939425
So, they're just punting the liability to another 3rd party (Plaid)? Given all the excitement in this thread, I was hoping that Plaid had miraculously cajoled the banks into an OAuth integration.
But I guess banks will be banks :-/
But I guess banks will be banks :-/
I'm sure something of the sort is in the works; it's hard to build momentum with a ton of huge legacy systems to bring along.
[deleted]
Was just looking at Plaid this weekend, seems really slick. The only thing that gave me brief pause was no public pricing (or indication of order of magnitude).
Hey Matt - Working on getting that up on the website! In the meantime, feel free to email me (charley@plaid) and I can send over details.
Congrats Plaid! Opening up banking data via API is a great enabler for fintech startups to create valuable apps. I interviewed them a couple months back: https://medium.com/get-put-post/how-plaid-s-api-brings-finan...
Since banks don't provide secure mechanisms for third-party authentication and authorization, e.g. OAuth, Plaid receives you credentials in plain text and will then use them to communicate with the bank. So you really have to trust Plaid.
The second weakness is even more dangerous: Apps implementing the Plaid authentication flow will show the Plaid "login page" with bank selection in an overlay on their own sites. Since this is not a redirect again, you don't even see whether your credentials are transferred to Plaid or the third-party app. That is, you have to trust your bank (sure!), Plaid (okay!) and the app using the auth flow (dangerous!).
You should fix this!