
SimpleFIN Bridge – Securely provide your bank transaction data to apps - iffycan
https://bridge.simplefin.org
======
tptacek
1\. What are you actually doing to secure this? Are you encrypting persistent
data? What data do you retain and for how long?

2\. Who's in charge of your application security? Do you have a full-time
security person on staff? Can we see who they are?

3\. Have you retained a security consultancy to review your code? Are you
doing it on a regular basis, or as a one-shot thing?

4\. Do you have a security page somewhere we can see? What's your policy with
regards to outsiders/strangers testing your application for vulnerabilities?
Have you provided permission to do that?

5\. What stack are you running on? A PHP site would be more worrisome than a
Rails site, which is in turn more worrisome than a microframework Java site or
Scala site.

6\. If you were compromised tomorrow, how quickly would you be able to
ascertain exactly which users had their data compromised?

7\. What provisions do you have to lock down your system (sacrificing
availability for security) in the event of a confirmed compromise where you
don't know the vector the attacker used?

8\. Do you have administrative applications of any sort? Do admins access your
server by SSH'ing into them? How are administrative channels exposed to the
Internet? How many people are on your staff, and how many of them have any
access to admin functionality?

9\. Are all of your internal applications and system access (VPN, SSH, Github,
&c) two-factor enabled, and all your users audited to ensure they're actually
using two-factor?

10\. Where do you get your email? Is everyone on your team two-factor enabled
for their mail accounts? A sizable chunk of all compromised go [random
app]->[employee email]->[password reset]->[whole system].

Hopefully this is helpful; this is the off- the- top- of- my- head list of
questions I'd want to be able to answer if I was doing something that had the
words "secure" and "financial" in its headline.

~~~
AdieuToLogic
Most of these questions can be rolled up into:

Where is their proof of PCI Data Security Compliance[1]?

The fact that the submitter responded to your detailed and relevant questions
with "This is helpful; I'll get you a good response when I have a good moment"
is reason enough to run as far away as possible from this.

1 -
[https://www.pcisecuritystandards.org/financial_institutions/](https://www.pcisecuritystandards.org/financial_institutions/)

~~~
iffycan
I'm sorry I haven't had time to respond. I meant "this is helpful" to respond
to his hope that his questions were helpful, rather than mean spirited, for
instance.

We currently have no proof of PCI compliance, yes, but we will. I personally
have worked in the PCI space for the last decade and understand how important
it is. What's lacking in this service isn't good security, but public
documentation of that security. We will work on that.

------
evolve2k
I think this is a problem worth solving. The image on the developer page with
the bank vault and with a window in in it asking the question 'why give them
the keys when they just need to look in the window' is the perfect analogy.

Slightly confusing is that the homepage says the service is $1.50/month but
the developer page says 'nothing to pay' and links out to an out of context
refenerce to the Wikipedia page on QFX the common Quicken financial data
format.

The consumer demo is an admirable conclusion, but after running the wizard my
takeaway is that the consumers bank would need to support this standard and
that they are aiming for something like auth tokens, envisioning a similar UI
to Auth tokens on GitHub.

I think what's missing is the blog post explaining the the why of what is
needed for this to be mass-adopted and why also this is the best solution to
the problem.

~~~
iffycan
You make great points. We'll publish such a blog post, but the gist is this:

SimpleFIN Bridge is a "bridge" between where we are today (no banks implement
SimpleFIN) to where we want to be (every bank implements SimpleFIN). It costs
money because of the ridiculous work involved to map all banks to a common
API. Once banks do it themselves, then the Bridge goes away.

Previous versions of the page included: "The goal of this service is to not
exist."

------
Animats
1\. Does this mean providing your transaction data to SimpleFin?

2\. How do we know you're not snooping on transaction data?

3\. Do you accept responsibility for any financial losses caused by your
errors?

4\. Has any member of your management ever been convicted of a criminal
offense?

5\. Who is your bonding company?

I'm suspicious of startups that want to insert themselves into a money stream.

~~~
iffycan
I'm glad you're suspicious. There should be more poeple with questions like
the ones you've asked. We are still very early-stage, but here's my best quick
answers:

1\. Yes, unfortunately. See my answer to evolve2k

2\. We ought to publish our privacy policy, but as a principle, we have no
interest in selling or mining data.

3\. Losses caused by misreporting?

4\. No

5\. None yet

Sorry those are probably unsatisfactory, but they're honest.

~~~
Animats
You're creating a central point of security failure. Like LastPass, the
"master password" remote service that was compromised a few days ago. You're
an obvious target for attacks. This means you have to be really good at
security, accept responsibility for your failures, and have insurance to back
you up.

------
wolframarnold
This is pretty interesting. Aside from the security questions already asked,
and assuming they can be addressed satisfactorily, I have this
question/suggestion:

Financial institutions all differ in their online offerings and most live in
the stone age (i.e. no useful API's), such that accessing transaction data
relies largely on screen scraping. One of the biggest make or break moments
for services like yours is getting critical mass in coverage of financial
institutions. I use two services, Mvelopes and FileThis and have connected
dozens of accounts to either, everything from large credit card providers like
Chase to obscure credit unions and mortgage lenders. Neither service covers
all my institutions. I've offered my help to build scrapers but have not been
taken up on that.

I think what could really revolutionize this is creating an open source
marketplace for these scrapers that anyone can contribute to. The scrapers
would implement a standard API to return data in some common format and would
call a number of standard methods to access login credentials, etc. You'd have
to develop the framework that these scrapers get plugged in to (also open
source) and a test framework. The calling/consuming code of your service can
be closed source.

In the long term hopefully this would inspire banks to implement the required
API's natively such that scraping is no longer necessary.

~~~
AdieuToLogic
There are reasons why FI's do not provide API's for accessing transaction
data:

* They are on the hook for PCI compliance (which providing access to entities other than ISO's would clearly violate).

* There is little to no business incentive to entertain integration of this sort.

* Transaction data is very much considered "proprietary information" owned by the FI (in the minds of institutions I have worked with) and is not shared.

* FI's view their clients in the transactional world as being either the Merchant (which is already provided transaction information through settlement and reporting processes), ISO's/VAR's (also already provided with their operational data), or Account Holders. The latter is allowed access to their transaction history via a browser due to market demands and cost saving concerns.

In short, there is no way in the foreseeable future that financial
institutions will implement API's which imply consent to use Account Holder
transaction data without onerous vetting of the service consuming this
information.

EDIT: made the bullet point list more legible.

------
vhodges
Looks interesting. I tried to do the same thing. I built an OAuth2 service
that FI's could implement for building apps and I built a PFM that they could
send data to (in realtime using Push/Webhook). I even have a client, but I've
kind of given up on the idea of making a living doing this. I have zero
sale/marketing skills, not to mention the fact that the competition is now way
ahead, though mine still does a few things theirs doesn't.

~~~
iffycan
Did you have success getting any FIs to actually implement it?

For bank interaction beyond read-only, I would love for FIs to implement
OAuth2. SimpleFIN is intended as the smallest possible pill for a FI to
swallow -- it really is easy to implement, but I'll be the first to admit that
it's not a final solution.

~~~
vhodges
I too sold them on the fact that it was not only readonly but push from their
side, so my software never accesses their core system directly. I did get one
FI to implement it, a tiny one branch credit union here in Canada. Though they
are tiny they're quite forward thinking. I sit on their board now.

I've recently reimplemented (though not deployed for my client yet) the OAuth
service in Go and called it Bouncer. It's open source
[https://github.com/sourdoughlabs/bouncer](https://github.com/sourdoughlabs/bouncer)
There's a Omniauth provider for it too
[https://github.com/sourdoughlabs/omniauth-
bouncer](https://github.com/sourdoughlabs/omniauth-bouncer)

I image a backend for Bouncer that uses OFXConnect would be quite easy to
do....

(Both are MIT licensed)

------
AdieuToLogic
Since this offering appears to be heavily based on OAuth 2.0, if not
completely compliant with it, how have you addressed the concerns set forth in
RFC-6819 "OAuth 2.0 Threat Model and Security Considerations"[1]?

And what reparations are SimpleFIN agreeing to provide in the event of
customer information being compromised?

1 - [http://tools.ietf.org/html/rfc6819](http://tools.ietf.org/html/rfc6819)

~~~
iffycan
It actually isn't based on OAuth2. For instance, consumers of the read only
SimpleFIN protocol don't have to establish a relationship with the server --
they need only provide credentials. Also, the SimpleFIN Server does not
redirect a client back to another server -- it is left to the user to deliver
the credentials to the party(ies) of their choosing.

As far as reparations, we haven't yet published that policy, but we will.

~~~
AdieuToLogic
> It actually isn't based on OAuth2.

Well, your spec requires use of the HTTP Bearer token[1], which is described
in the Introduction section of RFC 6750 as being:

"This specification defines the use of bearer tokens over HTTP/1.1 [RFC2616]
using Transport Layer Security (TLS) [RFC5246] to access protected resources."

So I hope you can understand my impression.

And there are legitimate criticisms of using Bearer tokens[1]. With the
offering you are considering, these are very significant.

FWIW, you may think I'm being adversarial/hyper-critical/a-dick (or any
combination therein). I can definitively say that in my mind I am not (in this
particular case) _and_ that the questions/statements I've posted on this forum
are "kindergarten level with mittens on" compared to what the eCommerce
banking community will hit you with.

If, as you said in a separate reply, you have worked in the PCI space for the
last decade, then the scrutiny you will be exposed to will not be a surprise.

1 - [http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-
a-t...](http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-
idea/)

------
cdcarter
This looks brilliant, but it's giving application errors (overloaded?).

Are you guys "blessed" by the banks you offer connections to? What's the
chance of this stopping working out of the blue when a bank changes a
protocol?

~~~
iffycan
Yes, it's overloaded.

The service is "blessed" by some of the bigger banks (e.g. they notify about
upcoming changes), but some smaller ones require speedy manual work.

------
Johnie
What's the difference between this and Plaid.io?

~~~
iffycan
As we understand it, Plaid Connect offers connections to a limited number of
banks. We (will) offer connections for tens of thousands.

Also, consumers of the SimpleFIN protocol (apps, your own scripts, etc) do not
need to register with SimpleFIN Bridge (or any other provider of the protocol,
for that matter) before consuming the data feed. In this way, it's a bit like
key-secured RSS.

------
kitwalker12
this is a nice service.

btw. what do you use to get that 'screenshot' when an application error occurs

~~~
iffycan
The screenshot is literally a screenshot we took before putting it in
maintenance mode :)

We're working on getting it back up right now.

~~~
kitwalker12
I see. I thought it was trick to get a screenshot of the page before the error
happened.

------
oneyellowbrick
How is this different than Yodlee?

~~~
iffycan
No setup fees and an access API with only one endpoint (so, very simple).

