Fintech Firm Plaid Raises $44M
wsj.com
wsj.com
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!
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...
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.
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.
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.
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.
But the other commenters are correct - the first 100 additions to the api are free.
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.
Seems like a startup-y Mint.
[1] - https://plaid.com/
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/
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'm working for a Canadian fintech startup that would truly benefit from a service like yours.
I will definitely keep a close eye on your service. Here's hoping it comes soon to non-US bank accounts.
Cool discovery: if you search for a financial institution, they return logos as Base64.
Super rad.
But I guess banks will be banks :-/
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
Though I'll admit, I'm quite biased!
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.
It's also interesting that Intuit runs their own massive aggregation effort that they haven't attempted to product-ize...