Can financial services providers do good and make good money at it?

Brad Garland’s latest post raises an interesting question:

If a company’s employees passion for their company’s product or service is ultimately what transpires in their brand and what drives customer to buy their products/services – think Google (“Don’t be evil”), REI or Apple, is it possible to have financial services providers’ employees being passionate about their products/services, and if so how?

As I was reading this post, I could not but think about Paul Graham comments in this presentation about the necessity for startups to be benevolent. His theory goes like this: if a startup focuses first on making the life of its users truly better, it will help employees stay motivated in the most difficult times, and will help in attracting the best geeks, who are usually idealists; once you have enough happy users, they will be happy to contribute financial support.

There many startup examples that have followed this pattern. eBay is a good example. According to Wikipedia’s entry on Pierre Omidyar:

The service was free at first, but started charging in order to cover Internet service provider costs.

REI, Brad’s example, is not a startup, but actually follows this benevolence pattern. They are actually a particular kind of business since they are a cooperative and as an REI member you get a yearly dividend (about 9% of the money you spend there), which you can redeem for REI products.

To go back to Brad’s question, and adapt it based on Paul’s suggestion: Can financial services providers do good and make money at it?

Of course they can.

Here are a few examples:

  • The disruptive contenders such as p2p lenders are effectively freeing loan seekers from bank loans and re-creating a more human and direct relation between lenders and debtors.
  • Large incumbent banks can leverage their operational infrastructure to create independent brands dedicated to specific communities or values (ex. using local deposits to finance local, sustainable developments, “green banks”). After all, different people have different ideas about what “don’t be evil” involves. In general, it is my opinion that banks can do good and be perceived as such by leveraging Web technologies to reveal the social links loans represent, rather than abstract/hide them. For instance, they could provide visibility into where the money in my CD account goes and provide me with the option to express my preferences. Ideally, I should be able to say that I want my money to be only used to help finance sustainable farming in a 50 miles radius around where I live.

Just my quick thoughts!

Should banks bank on OpenID?

Almost a decade ago, at the height of the Internet boom, I remember talking to a banker telling me that in the future, banks would not just keep your money safe, but also your identity. To some extent, this has materialized with identity protection programs offering insurance against the risk of identity theft. That said, if you view the identity as the collection of hard- or impossible-to-obtain information about a person that uniquely distinguishes her from others, you would certainly admit that a big part of this information (in particular secrets such as passwords) are spread around in a variety of online services (60 on average, growing to 200 according to a Yankee report on OpenID).

OpenID, as everyone knows, is the open solution to this problem, and banks seem to be excellent potential OpenID providers for the following reasons:

  • “He who can do more can do less”. Password strength requirements and password strength user incentives are not equal among online services, but online banking is probably one of the services where password strength is highest, simply because this is where for most people the loss would be the highest if their password was to fall in the wrong hands. So, users won’t use an easy-to-remember Gmail username/password or blog commenting account to login at their bank, even if the bank trusts Google’s security, but they would probably not mind the reverse.
  • Existing security-related assets:
    • Banks already have the security infrastructure in place to secure financial accounts,
    • Most banks are already trusted brands in terms of security, and
    • Banks already have identity theft protection program in place that would complement OpenID, which is just a technology
    • Banks are required by anti-money laundering laws to know their customer, and have probably more identity-related information about their customers (ex. government-issued documents) than any other online service. This means they have the widest range of authentication options, allowing them to support multiple levels of authentications. They are not constrained to a public URL/private password model: they can not only decide to issue a OpenID URL that is distinct from the existing username, but also use multi-factor authentication for instance by sending a PIN by SMS to a phone or requesting the user to click and get a call from a call center agent, as requested by OpenID policy extensions.
  • Last but not least, compelling business reasons. A highly secure OpenID would be:
    • A value-add service that the bank could charge a premium fee for
    • A great way for banks to promote their brands (you’d see their logo everytime you authenticate), get to know their customers’ online usage patterns (which service you are using and when) and present new offers/ads (banking-related or not),
    • A great way to retain customers.

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).

twauth: mobile authentication with OpenID and Twitter

I stumbled upon Ian McKellar‘s twauth prototype: a Twitter and OpenID based mobile authentication solution.

The idea behind twauth is to address the usability issues of current mobile OpenID-based authentication workflows.

The particular issue that Ian’s twauth addresses it the effort place on the user to enter alphanumeric passwords.

Twauth addresses this issue by replacing the alphanumeric password entry by a digits-only 5-digit one-time code sent to the mobile phone via Twitter/SMS, that the user then enters on the openid authentication page.

Here are some screenshots of the complete workflow:

1. Entering the twauth mobile OpenID URL at the mobile ma.gnolia.com (m.gnolia.com) http://twauth.ianloic.com/twitteruserid:

Ma.gnolia.com mobile login page

2. Instructing the OpenID server to send a direct (private) Twitter message with a 5-digit code (ignore the garbage):

Direct message selection

3. The mobile phone that is linked to the Twitter account linked with the twauth OpenID URL is sent a message with a 5-digit code (18010 – screenshot not available)

4. User enters the one-time 5-digit code:

Entering the one-time 5-digit code

5. You are authentic!

You are authentic

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?

Bank of America Online Banking’s user-friendly password strength indicator

Like many Web services, Bank of America Online Banking provides you with real-time feedback about the strength of your password when changing your password. What’s great with their implementation is that it does it via a thumb up indicator for each security rule your password must comply with that gets updated as the user fills out the password. This technique is the best I’ve seen so far at guiding the user into providing a secure password into a short amount of time, thus improving an experience that is generally frustrating given the generally low perceived value by users of these increasing security requirements (just like with anything security-related, users don’t value it until something bad happens to them).

This is a nice evolution from indicators that merely tell you whether the password is low strength or high strength, or even worse: password management systems like P-synch that only tell you what’s wrong with your new password after you have hit the reset button, requiring you to enter multiple time the password and hit the rest button.

Before the new password is provided, only 2 rules out of 4 are thumb up (one might argue that they should be disabled until the user starts to type)

Password strength indicators prior to passcode change

As the new password is typed, the thumps up turn green or red, until all are green and the user knows he can hit the reset button without fearing that the new password will be rejected.

Password strength indicators during passcode change

Hosting your very own OpenID with phpMyID

Why hosting your own OpenID? for me, it’s a way to stay committed to a fully decentralized Web.

phpMyID is very simple standalone, single user, OpenID Identity Provider developed by CJ Niemira. It does not require access to a database as everything is stored in the .php file.

It is absolutely perfect for a personal Web site.

Installation only took me about 30 minutes by following the very detailed installation instructions. My OpenID is http://lebleu.org/openid (I am going to move it to https as soon as Laughin Squid enables SSL on my site).

I already tried my new very own OpenID with SourceForget.net and OpenIdDirectory.com (to add a vote for phpMyID) and it works great. SourceForge.net just recently (May 5) added support for OpenID. If you already have an account with SF, you will bind your OpenID to your existing account by logging in with your OpenID and then logging in again with your existing account name/password. I found that logging with OpenID on SF takes a bit more time than with username/password, but I guess this will improve over time, and it is a minor pain compared to the convenience of having a single registration and sign-on facility that I control 100%.

Impressive JavaScript Interactive Graphics Library: processing.js

For fans of interactive graphics programming and data visualization out there (like me):  Processing.js is a 10kb JavaScript implementation of the open source Processing interactive graphics programming language. It is a side project of John Resig (jQuery).

Start your Firefox 3 latest beta and look at the bottom of the Processing.js page for demonstrations that will give you an idea of the potential of this.

To open source or not? or to do both? Open source as market segmentation tool.

Several years ago, I found myself confronted with the decision of whether to open source or not the software of a company I co-founded. While I could find considerable literature on the strategic benefits of open-source freeware as an enabler modern version of the razor and blade strategy (giveaway the client or development tool or razor, sell the server or the runtime or the blades), our software was not lending itself very well to such a separation.

My question was rather: if we have to choose between open sourcing blades and razors or nothing, what model would maximize our revenues, given our target market?

By elaborating on the simple notion of “why giveaway something you can charge for”, I developed the chart below to help me discuss the decision with my colleagues. The idea is to not view open source as an all or nothing strategy, but rather as a marketing technique to segment your market and maximize revenue, except that in the open source case, the revenue is mostly intangible.

Diagram of different segment of customers depending on their budget size and perceived value of the software

According to traditional marketing segmentation strategies, customers with large budgets and who have a high perceived value of our software should be charged for it fully and get all the features and rights; and customers with small budgets and who have a lower perceived value of our software should be charged less for a slimmed-down version of the software.

What’s new here is the category of users who don’t have large budgets themselves (the boss of their boss may have as it is the case of developers) but who see a lot of value in the software. These guys may not be able to sign a check, but they are able to bring more eyeballs to fix bugs, post feature requirements that are common to all users whether they have a checkbook or not, or simply spread the word about your software at the fraction of the cost and in a much better way than any PR firm. That’s not direct revenue, but certainly contribute to higher margins by reducing the costs of goods sold.

In most cases, the distribution of target customers (as it was the case for us) is such that a single model (commercial or open source) will dominate:

Diagrams representing 3 common cases of the distribution of customers according to their budget size and perceived value of the software offered

But if the distribution of customer types is such that a single model does not dominate, this model can actually be implemented using dual licensing, where one category of customers is segmented from another and charged differently, by offering both a commercial license and an open-source, usually GPL-like license. What’s even better is that customers are let to choose which category they belong to (actually their lawyers tell them).

Designing a successful Web API

Designing the most widely adopted Web API for a particular functional domain does not merely take to offer the best and most specialized functionality at the best price, as reading Adam Smith would suggest.

It takes two additional things:

  1. reducing the cognitive load on the developer using the Web API, and
  2. reducing his risks of using the Web API.

Reducing the cognitive load includes:

  • Making it easy to find on search engines
  • Not requiring registration for an API key to get access to a version of the API that is not production grade (for instance,  a version that is much slower than the production version)
  • Providing multiple representations (XML, XHTML, JSON, plain text, binary, etc.) for messages and multiple language bindings for the most popular languages in the target developer community
  • Good documentation, including a step-by-step tutorial
  • Examples with source code
  • On-line test tools that allow developers to test the functionality prior to coding
  • Building upon what target developers already know. Depending on the target developer community, this may mean starting with a REST/WOA API or a SOAP/SOA API.
  • Building upon what API users have already learnt so far about the API: learning one functionality should make the next one easier to learn. This includes using precise semantics and re-using them consistently, defining and sticking to naming and message structure conventions.
  • A variety of one-to-many medias (wiki, archived mailing lists, chat channels, etc.) for user-generated support and documentation.

Reducing the risks involves:

  • Being very clear upfront about what the API does and does not and how it compares with others (to reduce the perceived risk that the developer will spend time on something only to discover down the road that it does not address his requirements).
  • Ensuring the highest quality, up-time, availability and performance for the production version, and providing evidence of your commitment to these goals by using long betas (1-2 years) for new versions.
  • Ensuring backward-compatibility: code written for the 1.0 should still work when the 3.0 version of the API is out. This means that your application should support 1.0 to 3.0 concurrently until no one uses 1.0 any more, and that versions should be explicit in URLs (ex. http://mycompany.com/webapi/1.0/…).
  • Providing evidence that the Web API will be around for some time, because it is backed by a sound business model that can sustain its growth, maintenance and developments.