Google | Guillaume's blog

Microformats and decentralized online currencies

Most people are probably aware of the announcement by Google (following Yahoo’s announcement) that they would be supporting microformats.

What is really interesting to me is what this means for online currencies.

If you look at an hReview, what it is fundamentally is a declaration of positive (or negative) experience measured as a number betwen 1.0 and 5.0 about an item, which someone publishes on the Web anywhere he/she wants. An aggregator like Google in turns aggregates it and computes an average of the rating. The reviewer does not need the authorization of the reviewed item to publish the review.

That name typically includes a link (URL), which can be viewed as one of the identifiers of the reviewed items on the Web. It might be their own homepage for a restaurant, or it might be a description of the item on a review Web site such as Yelp (here the Yelp URI of a thai restaurant where I live).

In the payment world, there is already a payment application that allows you to donate/pay money without the other person having registered, it’s Tipjoy. The way it works is that you donate to URLs on the Web. Just like an hReview, the recipient does not have to be registered with TipJoy for others to tip them. If and when they eventually register they can claim their money by inserting a tipjoy tag with their username in the HTML of their Web page. Twollars followed a similar process but with Twitter names instead of Web URLs, but Twitter names are also URLs…

So the general pattern of Twollars, TipJoy and hReview is that you give or review a URL.

This could work for a really open monetary architecture:

People would write somewhere on the Web (typically a Web space they own) an hReview-like statement that they give a number of units of currency to someone else. For instance: Given 20 BH$ to <a class=”to fn url” href=”http://www.yelp.com/biz/blue-elephant-thai-san-francisco”>Blue Elephant restaurant</a> (Note that they could write it manually, but most likely, they will use a form that will generate it for them).
An aggregator would find this statement, either by crawling the Web, or if they are blogged via a RSS ping. The aggregator will typically compute balances (positive and negative). In a mutual credit model, people’s balances would be allowed to be negative, but in a traditional government-issued currency, they would not, they’d have to borrow it at interest.
Receivers may claim some of the URLs through a similar process than the one used by TipJoy.
Users may publish back their balances via a widget on their Web site.

What’s great with this model is that anyone can start playing, even create their own currency, very easily.

More importantly, you can have several accounting services tracking hPay statements and computing balances. You don’t need an account at a bank, your Web site is your bank account. What the accounting service does is simply authenticating that you own the space where you published transactions, and keeping tabs.

There are several issues:

Currency creation: Where do we register new currencies so that accounting services can distinguish different currencies? The ISO 4217 code is too limited to support millions of currencies. We need something like I used above: “us.ca.sf.bh”, which would allow new currencies to be easily created out of existing ones simply through forking.
Currency rules: different currencies have different rules. Some will allow negative balances of any amount, some won’t allow anything below zero, some will allow some negative balances or positive balances with limits (ex. 5,000). These rules must be encoded in a formal language, published to accounting services and participants and associated with the name of the currency. Eric Harris-Braun and Arthur Brock have already explored this topic extensively.
Refusal: how does a recipient refuses a given currency amount? (another currency rule BTW) this assumes that the recipient can be notified that their URL was mentioned. This is essentially a linkback.
Security, in particular:
- Authentication: how do we make sure that statements posted indeed come from the person owning the resource.
- Authorization/Privacy: how to we ensure that not all transactions I make are public, but available only those I transact with and possibly as few as possible trusted reputable intermediaries. OAuth could be useful here if the resources can be easily segmented and tokens can be issued to groups at once.
- Non-repudiation/Tracability: how do we prevent the effect of people deleting hPay statements.
- etc.

Quite a lot to think about. Some of these items will be the topic of future posts.

What the IT at Google Bank would look like

As I was watching the Google I/O keynote presentation, I thought about how all the development tools provided by Google (Google Gears, GData, OpenSocial, etc.) could be put to work to create a Google-powered Bank, and what the IT architecture of this Google Bank would look like.

Here is how I think it could look like:

All user interaction devices, whether it is a teller workstation, mobile phone, ATM machine, kiosk would provide access to the bank via any of the standard Web browsers (Opera, IE, Firefox, Safari).

If access to device-specific functionality is required, it would be done by Google Gears (say for instance, that I want to access the ATM’s cash dispensing functionality, or I want to access the mobile phone’s built-in GPS or accelerometer). Ideally, these devices would be running a single application that would adapt according to the services discovered on the device on on the service cloud. But realistically, they would be running variant of a single GWT Java code base that GWT would compile in JavaScript for browser-based deployment.

Contacting customer support would be done via Google Talk click-to-call buttons. Interactive Voice Response systems would be powered by 1-800-GOOG-411 voice technology.

All these user facing app would leverage a cloud of shared GData services based on Atom Publishing Protocol. These services would be used to retrieve and update any data and transaction: update accounts, customer profiles, schedule payments, withdraw money, consult account balances, etc.

These services would be available to any developer who registered for an API key to create new 3rd party applications, with online documents, code examples, tutorials, videos, etc. There would be a related developer challenge that would award prizes ranging from $25K to $100K to motivate developers to create 3rd party applications. Google Bank would monitor usage and success via the API key, and acquire the apps that can contribute the most to their bottom line or user growth. OAuth would be used to allow 3rd party apps to accesss customer data without the user having to give away their Google login/password.

OpenSocial would be leveraged by Google Bank to provide an easy framework for friends to share bills, family member to send money to one another via any device, and to loan money to friends/families or friends of friends. Google Bank would use this data to provide preferential loan rates or optimize transaction fees.

Google Bank analytics would analyze my transaction patterns, build nice spending usage pie charts for me, and suggest relevant ways to save or make more money via competitive offers aggregated in Google Shopping. Bank marketing managers would use Google Bank analytics to analyze usage patterns, create marketing campaigns and target specific demographics and customer types in Google Adsense.

And last but not least, users would be able to search all their personal data using a simple one input field user interface.

Did I miss anything?

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