Guillaume’s blog

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?

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:

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?