Note that there are two major security flaws in Plaid when it comes to authentication:
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!).
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'.
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.
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.
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.
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'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.
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.
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).
From my experience so far, sending an email to Charley is essentially the same as finding the info online since he answers so quickly!
Great onboarding, I was really impressed!
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.
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?
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 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.
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.
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.
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.
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.
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
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.
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 :).
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!