I agree - though I don't know which solution would be better (standardization of industry APIs as I propose, or a FOSS project to build and maintain a system that could hit all of these systems).
I think a mix of both would be best, though both are also wrought with many more difficulties than we have gone into here. For example, just a couple that come up off the top of my head:
* API Standardization issues
- Many of these companies likely have custom sets of data that they expect, validation rules, their own auth procedures that they'd be hesitant to let go of etc...
- Smaller companies (such as in my ECSI example) would likely shy away from the costs of creating such an API for their own services, thus still resulting in the need for custom solutions
- Larger companies would also hesitate to change - either due to their own org/system complexity, or just a desire to not spend money on something that doesn't feel core to their business. Healthcare integration standardization is severely hampered by this, for example.
- Many of these companies may actually be charging for access to their data backend, which would still thwart the use of standardized APIs even after they were adopted.
* FOSS System Issues
- To create the integrations, companies would have to actually both expose it to you and allow you access. The creators of the FOSS system would have to somehow convince these companies to essentially open up their systems to the world. That would be fantastic I think, but it would be very tough to convince companies.
- You'd need a large number of dedicated people to the cause - and not just developers to create and maintain the integrations, but also people with the skills needed to negotiate with the businesses for whatever kinds of back-end deals have to occur to keep the integration online and functional on the financial institution's side. So far, we've been good at finding an army of excellent developers to drive FOSS - for this kind of integration pursuit, the FOSS movement would also need to be good at finding an army of excellent businessmen, lawyers, etc... that would be as dedicated and available as the software development force (I'd be all for such an expansion of scope in the Open Source movement)
- The "charging for access" issue above would still be a problem here.
Now, none of these are reasons not to do it - merely a statement of risks and a peek into the scope and effort needed for such an approach. It's not something I'd ever have the time or energy to lead the charge on personally, but kudos to whoever could rally the army (and the political will) needed to make it happen.
I'm not really sure how charging for API access would break your ability to out-maneuver Mint. Technology moves faster than regulation so today regulation comes after power of technology. All a framework does is abstract way complexity, which makes the banks that fall under it subject to a more-pure market and its effects. Banks with premium services can compete on price while working on the same customer data easier. Access to extended data can be bidded on by banks for those willing to give up personal information for better services. I don't comprehend why the banks would need to "open up" anything, or even agree to standardize their API. The framework can be a sanity check on banks as well. (we deposited $100, only $95 is reported, flag., handle flag by docking bank "determinism ranking"), banks that don't rate highly as handling the framework calls in a deterministic manner are not officially supported and lose mainstream customers. Consumers can regain control of their personal information, bringing a new market for personal data that isn't owned by someone other than that person.
Comments
I agree - though I don't know which solution would be better (standardization of industry APIs as I propose, or a FOSS project to build and maintain a system that could hit all of these systems).
I think a mix of both would be best, though both are also wrought with many more difficulties than we have gone into here. For example, just a couple that come up off the top of my head:
* API Standardization issues
- Many of these companies likely have custom sets of data that they expect, validation rules, their own auth procedures that they'd be hesitant to let go of etc... - Smaller companies (such as in my ECSI example) would likely shy away from the costs of creating such an API for their own services, thus still resulting in the need for custom solutions - Larger companies would also hesitate to change - either due to their own org/system complexity, or just a desire to not spend money on something that doesn't feel core to their business. Healthcare integration standardization is severely hampered by this, for example. - Many of these companies may actually be charging for access to their data backend, which would still thwart the use of standardized APIs even after they were adopted.
* FOSS System Issues
- To create the integrations, companies would have to actually both expose it to you and allow you access. The creators of the FOSS system would have to somehow convince these companies to essentially open up their systems to the world. That would be fantastic I think, but it would be very tough to convince companies. - You'd need a large number of dedicated people to the cause - and not just developers to create and maintain the integrations, but also people with the skills needed to negotiate with the businesses for whatever kinds of back-end deals have to occur to keep the integration online and functional on the financial institution's side. So far, we've been good at finding an army of excellent developers to drive FOSS - for this kind of integration pursuit, the FOSS movement would also need to be good at finding an army of excellent businessmen, lawyers, etc... that would be as dedicated and available as the software development force (I'd be all for such an expansion of scope in the Open Source movement) - The "charging for access" issue above would still be a problem here.
Now, none of these are reasons not to do it - merely a statement of risks and a peek into the scope and effort needed for such an approach. It's not something I'd ever have the time or energy to lead the charge on personally, but kudos to whoever could rally the army (and the political will) needed to make it happen.
I'm not really sure how charging for API access would break your ability to out-maneuver Mint. Technology moves faster than regulation so today regulation comes after power of technology. All a framework does is abstract way complexity, which makes the banks that fall under it subject to a more-pure market and its effects. Banks with premium services can compete on price while working on the same customer data easier. Access to extended data can be bidded on by banks for those willing to give up personal information for better services. I don't comprehend why the banks would need to "open up" anything, or even agree to standardize their API. The framework can be a sanity check on banks as well. (we deposited $100, only $95 is reported, flag., handle flag by docking bank "determinism ranking"), banks that don't rate highly as handling the framework calls in a deterministic manner are not officially supported and lose mainstream customers. Consumers can regain control of their personal information, bringing a new market for personal data that isn't owned by someone other than that person.