Building a budgeting service

A post-hoc analysis, part 2

07. April 2013

As I wrote in my last blog post, around 3 years ago I decided to try to build a budgeting service like mint.com for the norwegian market. After around a year, having reached the prototype stage, I decided to take a short break from further building, to think about the business details. This quickly turned into an … extended break.

In this post I’ll write out some of the reasons I stopped working on it, and finally, some lessons learned.

During the process of mocking up the prototype, I’d already considered some business models:

• lead generation for loans, savings and credit card accounts

  In other words, getting a payment from the banks in return for sending users to one of their banking services. This is the business model that mint.com used, where they would recommend you banking services that might save you money. Of these, lead generation for loans probably is the most profitable, as loans are a large part of the business model for banks, and they’re willing to pay quite a bit for leads.

• third-party solution for banks

  This would mean selling the service of scraping and categorization to the banks as a plugin service in their own online banks. This didn’t seem all that feasible to me, since a majority of banks already used a third-party service (EVRY, formerly known as EDB) to run their online banks, and these were likely to want to make it themselves instead of buying it from another third party. As I later discovered, the few banks that actually ran their own online banks, mostly the larger banks (DnB, Gjensidige, etc.), were already building budgeting services themselves.

• freemium solution (“pay for premium”-solution)

  This is not a model I gave a lot of thought, since it was unlikely that the amount of users that were willing to pay for this services in Norway was large enough.

The lead generation business model seemed less risky, so that was my main plan. However, there were a lot of problems with the business model that I never managed to solve.

Profitability

My main worry was the economic feasibility. Scraping all the different online banks demanded that we always keep the scraper up to date, which meant a lot of manual maintenance. The big question was whether the costs spent on maintenance would be balanced by profits from lead generation. This was really hard to answer since I didn’t know exactly how much maintenance was needed, or how much the banks were willing to pay for leads. In a presentation held by Aaron Patzer of mint.com, he mentioned that they had a revenue of around 30$ per user. The revenue probably would have been higher in Norway, but I was never sure how many users we’d get. Norway is after all a considerably smaller market than the US. Even though we managed to get a considerable share of the potential market size, given around 30$ per user we’d only be talking about a couple of million NOK in revenue, which is not a lot, considering maintenance costs.

Marketing costs

The second big worry was how to get people use this service. Most Norwegians have never heard of budgeting services, which means it would be a problem to get people to try it at the outset. This would be especially hard since the service asked them to log in to their bank account, something that no other service in Norway (as far as I know) asks you to do. We would have to do quite a lot of outreach to ensure that users were certain that the service was safe. The best bet would probably be to market the service through personal economy sites, such as dinepenger.no, which already had a number of economy calculators and manual budgeting tools, and somehow get them to vouch for the service. Any kind of certification, such as TRUSTe, Verisign, and RSA, would probably also help here.

Legality

Though it wasn’t strictly illegal to scrape the account statements from online banks, a lot of the banks actually had clauses in their terms of services stating that the user was not allowed to give any third parties access to their online bank accounts. Any scraping done on remote servers would of course be a breach of these terms of services. Though it was deemed unlikely that the banks actually would do any counteractions against users allowing this (it would after all be the users, not us, they would be targeting legally), there was a major risk in that they might make life hard for us (i.e. making it harder to scrape) and that they might claim our services were insecure. On our side, we might claim that the users had a right to own their own information and that the banks were just trying to stop users from finding cheaper banking services. Some people I discussed this with, suggested that the banks were unlikely to say anything publicly, as any kind of discussion around the security of the banks would be negative PR for the banks. It turned out later that “finanstilsynet” (which is Norways’ higher authority for banks) actually were willing to warn against giving up your information to these kinds of services in very negative tones, so the worry wasn’t exactly unwarranted. Given this kind of pushback, it would probably have been an uphill battle.

Altogether, these issues, especially concerns around profitability and legality, made me uncertain whether it really was worthwhile to continue with the project.

The real reason I stopped working on it, though, was that I really, really needed a break. By the time the prototype was done, I’d been working on this project in most of my spare time for a year. While the plan was to take a break from building to figure out whether the business was really profitable, I was too fatigued with the whole project, and though I thought about it from time to time, I didn’t really make a serious effort. The short break quickly grew into months, and I gradually started thinking about other projects.

So, here’s some of my lessons learned:

Lessons learned

• Figure out the business model first

  Though it’s fun building stuff and you learn a lot doing it, if you end up building something that never earns money, you’re either in the not-for-profit business or you’ve wasted your time. Earning money (at least enough to keep day-to-day operations running) is and should be priority number one for any startup, so you should focus on that as early as possible. The issues with legality and maintenance cost vs profit, are actually something that I could have figured out before I started building it.

• Involve more people at an early stage.

  Having someone to discuss with and share the stress (and victories) with, is worth way more than you might think. Other people might add knowledge or points of view you don’t have, and you’re probably likely to pick up on problems with your business model earlier, though that depends on how balanced you are as a team. In my case it would have been optimal to work with someone else that had experience with the banking business, as they could tell me more about the profitability aspects around lead generation. Including other people also meant it would have been easier to keep up motivation, or at least spin the project into something else, which partly was the reason I stopped.

Postscript

In hindsight, an automated personal budgeting service for the Norwegian market is probably unviable. Mint.com had a lot of advantages in that they were buying the transaction feeds from a third party, Yodlee, since they didn’t directly have to deal with maintenance costs or legality issues. The only way that I see such a service could be viable in Norway, is if the banks start supporting a common API to get transaction information. This would considerably lower maintenance costs and stop any legality concerns. However, this is unlikely to be initiated by the banks, so it would probably have to be enforced through some sort of regulation. There are other services based on lead generation that are viable though, and since I stopped working on my project some have turned up.

The site penger.no, which has simplified applying for loans from several banks at once, has abandoned the entire personal budgeting service and gone directly for the lead generation. Instead of getting information about users from their personal budgets, they’ve simply asked the users to punch in the details themselves. The only drawback I can think of with this, is that the leads might be less qualified (the banks get less real information about income and spending), and thus banks might pay less for the leads.

Penger.no have also solved a lot of the issues with marketing, since the service is partially owned by dinepenger.no and finn.no. Dinepenger.no is able to give it credibility and means it can reach out to exactly those users that are interested in this kind of service, while ownership by finn.no (one of the top ten sites in Norway) means that they can advertise cheaply on pages of finn.no.

Some banks, such as DnB, Skandiabanken and Storebrand, have also implemented their version of budgeting tools as part of their online banking services. I haven’t seen any that I’m really satisfied with in terms of user experience and integration, though. These tools are of course also only based on transactions from the accounts the user has in these banks, so they do not give you the complete overview of your economy that I was interested in (unless you have all finance information (stocks, loans, savings, debit account, BSU) in one bank). What would have been really interesting, is an online bank where the budgeting integration was really thought through, like what Simple seem to be building in the US. I can only hope that some banks over here (or a startup) will try to to copy what they’re doing. Meanwhile, it looks like I’ll have to resort to spreadsheets for my complete budgeting needs…

If you liked this article, you should follow me on twitter.