The problem with banking innovation and how to fix it.

Allen Weinberg has a great report on the first day at Payments 2008 that confirms some of the thoughts I’ve had in the past few weeks: that non-banks are becoming the primary source of banking innovation, threatening to relegate banks to mere accountants.

Allen cites the difficulty for banks to hire innovative employees because their lack of coolness, and I partly agree, but I think that is a bit too imprecise. It’s a bit like saying “We failed b/c we are were not lucky”. I think smart innovative employees go to companies that have an innovative management environment and culture, and there are very practical ways to create such an environment and culture, if the top management wants to.

To me such a culture starts by embracing the facts that:

  • Committee planning does not work for innovation because most innovations fail and slight differences between similar projects can be huge key factors of success, and as a result it is impossible to predict from which team innovation will come from.
  • People with innovative ideas (ex. new online service, new investment theory) as well as execution capabilities (ex. coding, sales skills) are a company’s greatest human asset and should be given opportunities before they leave and join a company that does.

Such an innovation culture consists then in implementing a management policy where such people can submit their plans, get a green light to allocate part of their time (whatever their direct manager says) and get a bootstrap budget as necessary. Then, just like a good option portfolio manager, define progress/success metrics, and allocate more resources to those with the most traction. And finally, reward success. All of this is something Google seems to be doing very well.

Banks are now at a most critical time and their ability to innovate in sustainable business models will be key to their survival. Nouriel Roubini noted this morning that banks’ unsustainable “originate & distribute” business model of the last few years is crumbling with the broken “securitization food chain”.

Banks are social intermediaries, and as a result, social services that focus on social lending or social saving pose a major threat to them, but could also turn out to be a major opportunity if they manage to re-intermediate these relationships and combine it with their unique competitive advantage: creating money from thin air.

Think for instance about the idea of a “college car” savings account solely dedicated to buying a car and that grand-parents could contribute too knowing where the money would end. Think of the negotiating power the bank could have by aggregating all the buying power behind these savings account and exchanging secured rebate from car manufacturers with secured future sales. This is what SmartyPig does, but environment/culture aside, it seems to me much easier to do it from the inside of a bank than from the outside. John Gaskell, SmartyPig co-founder was quick to comment that they have a patent pending on this process, so banks may actually not have this option.

Think also how a bank could leverage the fact that 50% of your student loan on a peer-to-peer lending site comes from your mum and dad, and grand-parents, and how little risk it would be for a bank to lend the remaining 50%, especially if the bank gets preferred re-payment rights.

Banks have some of this social data, in a way that is most likely much more authentic than a Facebook (think about all the documents you need to provide to open a checking or brokerage account compare to what you need to provide to open a Facebook account). It is just a matter for them to put in place the right environment and culture in place to attract people.

If they cannot change their culture, their next best bet might be to do what Apple or Facebook do: expose some of this information via easy-to-use APIs in a way that is more secure than their startup competitors. Then, allocate a VC fund to fund startups using this API (which is equivalent to buy an option to invest more/buy out the most promising ventures later).

Mint.com: a perfect banking use case for OAuth

Mint.com provides a free service, which is able with your authorization, to connect to your bank(s), retrieve your bank account information and all your transactions and provide value-add services with the data. In particular, it allows you to see where you money is spent and give you hints at how you could save money. I personally think it is a superbly designed UI to the user data held at banks, which shows how much value there is to unlock, and also how much startups can be so much more efficient at delivering innovating services than banks themselves sometimes. Yodlee, a partner of Mint.com, was a dot com era example of this and Mint.com might be their Web 2.0 equivalent.

One problem is: Mint.com requires you to provide your actual username and password to the online banking service provided by your bank, which you use not just to view transactions, but also to make payments, transfers, etc.This approach has several drawbacks. One is that the user can be legitimately concerned about what would happen if this information would get compromised. Right now, Mint.com reassures its customers by saying: “We don’t store your info, Yodlee does”.

Another problem is that every time your online banking username or password changes, Mint.com stops working until you reconfigure it:

Mint.com screenshot showing: wrong username/password

Not very convenient. Add to this the fact that you can’t have any guarantee of what happens to your username/password when you want to terminate your relationship with Mint.com/Yodlee, and you may feel like you won’t use this application for now.

An implementation of OAuth protocol between Yodlee/Mint.com, the user and the bank can solve these problems at once, and would certainly further drive user adoption.

OAuth is self-described as a protocol for “secure API authentication”, but a better way to put it is that OAuth is a way for users to grant controlled access to their data hosted at online service A to another online service B. To use the car metaphor, if your data at online service A was a car, and online service B was the valet parking person, OAuth would be the way for the valet parking person to ask you for your car’s valet key, with which he can only drive a few miles and can’t open the trunk, and the way for you to give him the key. In security jargon, OAuth allows to delegate capabilities on your data to other applications, in the form of signed tokens, i.e. authorizations to do specific things with specific data that you sign with your identity. The beauty of it is: because these capabilities are signed by you, it can be presented by online service B to access your data at online service A without you having to provide your identity credentials (username/password typically) to online service B.

Coming back to the Mint.com/Yodlee use case, here is how it would work:

  • The user would go to Mint.com to request access to his data at the bank.
  • Mint.com would request his bank a token for a specific capability, for instance, retrieving transaction data
  • Upon receiving this request token, Mint.com would redirect the user to the bank’s token authorization page.
  • The user then authorizes the token (If he is not already logged in, he would do that first)
  • Mint.com can then substitutes the request token with the access token, and access the user’s data as they requested and as the user authorized, until the token is invalidated or expires.

Here are the benefits of OAuth for the user in this use case:

  • Mint.com/Yodlee never know the username/password used to log in at the bank.
  • When the user changes his username/password, Mint.com/Yodlee can still retrieves transaction data
  • When the user decides to terminate the relationship with Mint.com/Yodlee, he knows they don’t have is username/password and he knows that they can’t access his data anymore.
  • When you don’t want to use Mint.com/Yodlee anymore, you can simply invalidate

The big question is: how much work would be involved at banks and Yodlee to support OAuth, and in particular, what would they have to change?