Note that this is just my gut opinion on it, imagining the nightmares I've seen in healthcare integration and contrasting that with what I see as an end user of Bank integration. I've not actually seen the business deals and effort in the backend as a developer in the latter case, but as an end user of Mint I've seen missing integrations that hint strongly at the difficulties they must experience.
I think the reason why is because it's a pretty large integration undertaking. To compete with Mint at this point, you'd have to offer similar levels of integration with banks, credit card companies, investment companies etc...
The problem is that there are literally tens of thousands of these companies, each exposing their own APIs and each with their own unique caveats as to data they require, throttling limits, back-room deals for access, hesitation to even let people access their systems etc.
For an anecdotal end-user example, I have an account with one provider who refuses to cooperate with Mint in integrating - ECSI. This is a small lending company for student loans, one of thousands of such companies. They decided for reasons that are not publicly available to not even allow Mint to integrate with them anymore, after having let them do so for the first couple of years. What sorts of negotiations were occurring in the back end between these companies, and what caused it to fall apart? The public doesn't know, but needless to say there was some level of custom integration effort for them, some level of business negotiation, and then finally something fell apart and made customers mad as a result. Now, all of this integration work and business negotiation had to happen between Mint and ECSI - and that is just one of the tens of thousands of companies out there. It is a very tall order to ask a new company to come forward and make that much upfront work in order to get on par with Mint so that it can start competing.
The real fight that would make more innovation in the field would probably have to start with getting companies to standardize and expose their APIs without (or with common and well understood) strings attached. If this happened - as has been struggling but slowly improving in the Healthcare field - it'll become more feasible for a company to realistically compete with Mint. And then you can get to those enhanced features that Mint suffers for want of. (however, at that point Mint's significant engineering force could be redirected from integration efforts to these same features, and then you'll find yourself fighting against a much larger machine now bent on feature improvement)
This is a huge factor. They started with Yodlee (basically a paid bank-scraper service with fees that might crush a small startup) and now Intuit has built something in-house.
Interesting! From that link, it sounds like they're paying a large sum of money to use someone else's integration solution. That could be an option - I wonder just how much money they are shelling out. (and whether Intuit is said integrator!)
It's hard. But it's possible, and there are significant earnings that could be realized in that space. I think that if hypothetical "BetterMint" offered excellent features and something truly innovative, people would be willing to pay for it.
I totally agree that it would be possible, but very difficult to get properly funded. I have to admit that I'm not sure that I'd pay for it either, unless it truly gave me something special that I couldn't already deduce myself from the kind of data Mint gives. I can't envision exactly what kind of feature would drive me to pay for it, but I don't doubt that there's something I'm not currently able to imagine that would motivate me as such.
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.
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.
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.
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.
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.
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.
Comments
Note that this is just my gut opinion on it, imagining the nightmares I've seen in healthcare integration and contrasting that with what I see as an end user of Bank integration. I've not actually seen the business deals and effort in the backend as a developer in the latter case, but as an end user of Mint I've seen missing integrations that hint strongly at the difficulties they must experience.
I think the reason why is because it's a pretty large integration undertaking. To compete with Mint at this point, you'd have to offer similar levels of integration with banks, credit card companies, investment companies etc...
The problem is that there are literally tens of thousands of these companies, each exposing their own APIs and each with their own unique caveats as to data they require, throttling limits, back-room deals for access, hesitation to even let people access their systems etc.
For an anecdotal end-user example, I have an account with one provider who refuses to cooperate with Mint in integrating - ECSI. This is a small lending company for student loans, one of thousands of such companies. They decided for reasons that are not publicly available to not even allow Mint to integrate with them anymore, after having let them do so for the first couple of years. What sorts of negotiations were occurring in the back end between these companies, and what caused it to fall apart? The public doesn't know, but needless to say there was some level of custom integration effort for them, some level of business negotiation, and then finally something fell apart and made customers mad as a result. Now, all of this integration work and business negotiation had to happen between Mint and ECSI - and that is just one of the tens of thousands of companies out there. It is a very tall order to ask a new company to come forward and make that much upfront work in order to get on par with Mint so that it can start competing.
The real fight that would make more innovation in the field would probably have to start with getting companies to standardize and expose their APIs without (or with common and well understood) strings attached. If this happened - as has been struggling but slowly improving in the Healthcare field - it'll become more feasible for a company to realistically compete with Mint. And then you can get to those enhanced features that Mint suffers for want of. (however, at that point Mint's significant engineering force could be redirected from integration efforts to these same features, and then you'll find yourself fighting against a much larger machine now bent on feature improvement)
This is a huge factor. They started with Yodlee (basically a paid bank-scraper service with fees that might crush a small startup) and now Intuit has built something in-house.
I'd be interested to see what partnership companies like IGG, who builds the popular iBank for Mac, have pulled off to do this (http://www.iggsoftware.com/ibankforipad/direct_access.php).
Interesting! From that link, it sounds like they're paying a large sum of money to use someone else's integration solution. That could be an option - I wonder just how much money they are shelling out. (and whether Intuit is said integrator!)
It's hard. But it's possible, and there are significant earnings that could be realized in that space. I think that if hypothetical "BetterMint" offered excellent features and something truly innovative, people would be willing to pay for it.
I totally agree that it would be possible, but very difficult to get properly funded. I have to admit that I'm not sure that I'd pay for it either, unless it truly gave me something special that I couldn't already deduce myself from the kind of data Mint gives. I can't envision exactly what kind of feature would drive me to pay for it, but I don't doubt that there's something I'm not currently able to imagine that would motivate me as such.
At least some of these providers have API's now! Mint was probably screen-scraping for awhile, and they made it.
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.
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.
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.
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.
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.
I'm not sure how thousands of companies blazing their own trail is synonymous with stopping advancement.
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.