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?
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.
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."
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.
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.
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.
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.
> 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.
PHP I can totally understand being worried about. But why rails? It has one of the best track records in bug resolution and advocating for best practices out of the box among the major frameworks. To say that a microframework java site, or a scala site is somehow magically going to be better... well I guess I'd like to know what your reasonings are, because I'm just not seeing it.
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.
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.
I don't think PCI is anywhere near the minimum that is needed. In the JP Morgan hack: did their PCI compliance help their status? In the Target breach: did their PCI compliance help prevent their attack? How about the Global Payments breach of a couple of years ago?
So with respect to Most of these questions can be rolled up into, i would post a Strong Disagree.
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.
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.
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.
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.
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.
We have attempted to try the open source bank access model you've described [1], but I'm not confident that such a system would ever be dependable without the cooperation of the FIs themselves, for the reasons AdieuToLogic gives.
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?
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.
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.
34 comments
[ 1.9 ms ] story [ 94.2 ms ] threadAre 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?
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.
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.
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."
btw. what do you use to get that 'screenshot' when an application error occurs
We're working on getting it back up right now.
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.
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.
https://en.wikipedia.org/wiki/Nagle%27s_algorithm
if there is unconfirmed data still in the pipe
What does "unconfirmed" mean in this context?
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.
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.
PHP I can totally understand being worried about. But why rails? It has one of the best track records in bug resolution and advocating for best practices out of the box among the major frameworks. To say that a microframework java site, or a scala site is somehow magically going to be better... well I guess I'd like to know what your reasonings are, because I'm just not seeing it.
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/
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.
So with respect to Most of these questions can be rolled up into, i would post a Strong Disagree.
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.
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 There's a Omniauth provider for it too 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)
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.
* 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.
[1] https://github.com/simplefin/bank-access
And what reparations are SimpleFIN agreeing to provide in the event of customer information being compromised?
1 - http://tools.ietf.org/html/rfc6819
As far as reparations, we haven't yet published that policy, but we will.
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...