[notwhoyouthink]

This is really neat; having just signed up I'm yet to see how useful it actually turns out to be. I'm really happy to see startups using Plaid.

I tinkered with building a budgeting app (think Simple's Goals feature but for any bank) and used Plaid. They were a super helpful bunch and the service "just works."

Along those same lines, I think it's great you're using Cordova. Sometimes people feel the need to do everything "the right way" because otherwise they won't get funding / their app won't take off / etc. In reality, there is no right way and you should use the tool that will do the best job for you. Sounds like Cordova was the right move here.

Congratulations on a really awesome product! I'm jealous I didn't think of it first :)

[notwhoyouthink]

If anyone from Penny is still around, I have a question. In using the app an error occurred and Penny apologized and said someone would look at it shortly.

About 15 minutes later I got an email from an engineer saying my request got caught right in the middle of an upgrade and that's why it failed.

Great service and a fast response time, but I'm curious how much information is shared with the engineer when that happens? Considering that happened automatically without me requesting help, I'd hope extremely limited information (and absolutely no financial information) is given to the engineer assigned to the ticket.

How much information can an employee see about a particular user? How about when an error occurs? Is it possible for someone at Penny to see financial data, and if so what is the process for an employee querying that information about a user?

[dontmitch]

Still around!

Sorry about the bug. We've been deploying all day and made the mistake of pushing something that received new server content before the updated clients themselves had time to propagate. I'm guessing that's what you ran into.

A bit about our process: we catch all errors (server and client) using Bugsnag and pipe them to Slack. Those errors are basically stack traces that hopefully give us enough context to reproduce and fix the bug. If the error was user facing (e.g. interrupted your conversation), we also open a ticket in Enchant that links back to the Bugsnag error. That way we track if/when a user hits a bug and can reach out to let them know when it's been fixed, or collect more info on the context surrounding the bug.

Like most customer support portals, Enchant can be populated with information about the person's account. In our case, we can see things like your first name (that's all we collect from you), when you joined, your phone platform, your app version, and which bank types you've attempted to link.

Does that answer your question?

As for financial data: we don't store your credentials, ever (thanks to Plaid's API, we don't have to). We do store your transactions so that we can serve them to you in-app (hopefully that's not a surprise?), along with the bank type and balance information that you see in your accounts tab. Since they're in our DB, engineers on the team can query that information. We do that on a need-to-know basis only; for example, if someone has asked us to investigate a bug they ran into, or why their numbers look off.

Hope that helps!

[notwhoyouthink]

Thanks, that was the answer I was looking for. I appreciate the openness!

In a perfect world engineers would have to request elevated permissions from a manager/team lead to query tables holding financial information, but in our un-perfect world that's usually not feasible.

[erichurkman]

Box does this well; there's a button you click inside their admin portal to allow access.

[dontmitch]

Appreciate it!

And just because we're working on this idea doesn't mean you can't too. It all comes down to execution. A little competition is healthy for everyone :)

[tommynicholas]

If you like Simple's goals feature and want it as a standalone, I use Qapital for that and love it.