3 ms·

So in effect, by cornering the market and developing many layers of cruft internally to deal with the various APIS, they've effectively stopped technology advan

So in effect, by cornering the market and developing many layers of cruft internally to deal with the various APIS, they've effectively stopped technology advancement in the personal finance space. Meanwhile, quantum networks and computing is being rolled out to big institutional investors. The only way for people to regain any semblance of control (and transparency) of their financial situation, there has to be an FOSS initiative to build these tools openly, and to keep them on a license that prevents huge financial institutions from coopting public commons software. The fact that Mint can't seem to tally a month is indicative of deeply failed architecture, probably governed by business instead of engineers. If that doesn't scare you, well, perhaps you are already in debt up to your eyeballs, and as they say, if I owe you $1,000 it's my problem, if I owe you $1,000,000 it's your problem. There is NO WAY for a startup to tackle the problem and make meaningful advancements in any metric except maybe a nice zero-sum race with Mint. At least not that I can see. No one is going to fund a startup deving under GPL2 and no startup staying private with their technology will be able to out-compete Mint's headstart, because any advancement you have with the banks is Mint's for free. With a open technology is everyone's (including mints) and any advancement they make is also yours. You've effectively changed the game from managing information logistics/frameworks to customer support. You are playing a high-level game when you write financial software for profit. The only way to win the game this old, is to not play inside its rules. FOSS. The quickest and most assured way to guarantee your failure would be to accept startup funds with any strings attached, because as soon as you do, you're now subject to the rules of the game.

EdgarVerona 13y ago
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.
- AsymetricCom 13y ago
  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.
btown 13y ago
It's not just that the APIs are hard to deal with. The problem is that I'd imagine that many of these financial institutions will only allow API access and implementation details under an NDA or some equally FOSS-incompatible legal constraint. You'd think that "it's just an API, how close-minded can they get?" The answer is very. I've dealt with these types of integrations before as part of a large corporation, and I've seen API documentation from a partner prefixed by 2 full pages of legalese regarding its use - and that doesn't include the separate document about data retention and caching restrictions. And it's even more of a pipe dream to think that any party could convince these institutions to simplify or standardize their APIs - the legal fees alone for them to make sure that everything's compatible with EACH company's practices/bylaws would probably strike fear into even the most generous donor. I love the FOSS mindset, but as an engineer I have to recognize that it's not the perfect approach for every domain.
- AsymetricCom 13y ago
  The issue with banks like that is the complexity is lying outside their ability to enforce it, so they have to rely on government/law to enforce that complexity instead of software. Such banks move slowly. Are there any banks with open APIs? Yes, not many though, there probably aren't enough to start a network effect. Just because some APIS are "hard" and exist outside of an electronic network, doesn't mean that they cannot be automated in software to some extent. Makes me wonder if Obama is trying to automate the government and military so Laws and enforcement can be automated so inter-banking can be automated. Didn't follow our NDA and are using our API to lander cash? Automated drone missile at your IP interface.
JohnTHaller 13y ago
Mint didn't do anything to stop technology advancement. The thousands of companies Minte wants to connect with, all with their own unique snowflake systems, did that already.
- AsymetricCom 13y ago
  I'm not sure how thousands of companies blazing their own trail is synonymous with stopping advancement.
  - JohnTHaller 13y ago
    With all the financial institutions using antiquated technologies, all with their own little twists, that won't work with anything else and barely work with the standards they themselves set up... yeah, that basically kills any project that would like to help an individual manage their financial portfolio. Well-specced and adhered to standards can be wonderful. Thousands of entities making it up as they go and not working with each other, not so much.

EdgarVerona 13y ago

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.

AsymetricCom 13y ago
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.

btown 13y ago

It's not just that the APIs are hard to deal with. The problem is that I'd imagine that many of these financial institutions will only allow API access and implementation details under an NDA or some equally FOSS-incompatible legal constraint. You'd think that "it's just an API, how close-minded can they get?" The answer is very. I've dealt with these types of integrations before as part of a large corporation, and I've seen API documentation from a partner prefixed by 2 full pages of legalese regarding its use - and that doesn't include the separate document about data retention and caching restrictions. And it's even more of a pipe dream to think that any party could convince these institutions to simplify or standardize their APIs - the legal fees alone for them to make sure that everything's compatible with EACH company's practices/bylaws would probably strike fear into even the most generous donor. I love the FOSS mindset, but as an engineer I have to recognize that it's not the perfect approach for every domain.

AsymetricCom 13y ago
The issue with banks like that is the complexity is lying outside their ability to enforce it, so they have to rely on government/law to enforce that complexity instead of software. Such banks move slowly. Are there any banks with open APIs? Yes, not many though, there probably aren't enough to start a network effect. Just because some APIS are "hard" and exist outside of an electronic network, doesn't mean that they cannot be automated in software to some extent. Makes me wonder if Obama is trying to automate the government and military so Laws and enforcement can be automated so inter-banking can be automated. Didn't follow our NDA and are using our API to lander cash? Automated drone missile at your IP interface.

JohnTHaller 13y ago

Mint didn't do anything to stop technology advancement. The thousands of companies Minte wants to connect with, all with their own unique snowflake systems, did that already.

AsymetricCom 13y ago
I'm not sure how thousands of companies blazing their own trail is synonymous with stopping advancement.
- JohnTHaller 13y ago
  With all the financial institutions using antiquated technologies, all with their own little twists, that won't work with anything else and barely work with the standards they themselves set up... yeah, that basically kills any project that would like to help an individual manage their financial portfolio. Well-specced and adhered to standards can be wonderful. Thousands of entities making it up as they go and not working with each other, not so much.