What's the difference between this and Plaid.io?
Also, Plaid offers additional data points (such as location), which this does not.
SimpleFIN Bridge – Securely provide your bank transaction data to apps
21–30 of 35 posts
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#22Looks 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 th…
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.
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)
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#231. 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.
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…
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.
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#24This 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.
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#251. 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 c…
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/
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#26Since 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?
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#27This 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 gett…
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.
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#28How is this different than Yodlee?
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#29How is this different than Yodlee?
No setup fees and an access API with only one endpoint (so, very simple).
Re: SimpleFIN Bridge – Securely provide your bank transaction data to apps
#301. 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 c…
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/
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.