Guillaume’s blog

We just released the PR for BarCampBankSF2. Please re-blog, re-twit, re-send, …

Dear Innovators,

It’s been a year since we had the first BarCampBankSF at the UC Berkeley campus — and given the current state of the economy, the collapse of the stock markets, the credit crunch hitting the global markets and the issuing severe slowdown of activity — the timing couldn’t be better for a second BarCampBankSF.

BarCampBank aims at bringing together the Bay Area’s smartest technologists and industry insiders from all over the world for a great day of networking to discuss the impact of emerging technologies in the Banking and Financial Services space. BarCampBankers will present projects, confront ideas and participate in lively conversations around the innovations in the Banking and Finance world. If you are an innovator, a technology disruptor or a professional in the banking and finance industry we’d love to have you join the debate and share in the experience.

We believe that innovation happens in any economy. We’d love to hear your ideas and share how your organization or institution is doing to ease the financial mess we are in right now.

Regards,

The BarCampBankSF Team.

More info and the wiki for the event can be found at http://barcamp.org/BarCampBankSF2
Registration takes place on eventbrite: http://bcbsf2.eventbrite.com/

I’m reading the live blogging of the Bernanke hearing today, and I’m pretty shocked by the following conversation:

Bad lingo | 3:59 p.m. Emanuel Cleaver, a Democrat from Missouri, condemns the term “bad bank.” He says the term does not exactly inspire support for the program. Maybe it should be called the “Damascus Road” bank, he says, or maybe the Fed should have a linguist look into something else more appealing.

Mr. Bernanke replies that it’s officially called an “aggregator bank,” not a “bad bank.”

Mr. Cleaver says that term is unlikely to catch on, and that perhaps a three-year-old should come up with something that rolls a bit more trippingly off the tongue.

Well, what about “Good Bank”, and what about making it more than just a sweet name?

I’m convinced Americans want good, ethical banking, the kind of banking that focuses on developing healthy communities where they can live and raise their kids. Just like anyone else on this planet. More importantly, they want HOPE, and good banking IS hope.

Bruce Cahan says it very well:

What We Had

The earliest banks were built by business, civic and religious leaders to grow hometowns, in regions they knew best. Community banks and bankers exist as a minority, often still independently-owned.

What We Lost

Today, most deposits (upwards of 80%) in America’s large cities are held by banks headquartered elsewhere, accountable to no one locally, except regulators in Washington or the state capitols who are easily outmaneuvered through lobbyists, industry political donations and complex financial instrument structures that camouflage the transparency needed to see simple causes and effects.

America’s banking system has lost its roots, has lost its way. “Safety and soundness” used to mean bankers living in and knowing their home regions and the people, businesses, governments and nonprofits there. Now Wall Street financial services mega-banks and investment professionals have fractionalized underwriting, ownership and obligation to the point where hedged bets on leveraged obligations (e.g., home mortgages or corporate bonds) create a rapidly cascading morass of multiplexed risk, drying credit up for other purposes in places where the risks are less or could be underwritten more safely and simply. As rogue traders have shown, the whole house of cards can easily unravel, with the use market capitalization and Federal Reserve costs unwinding such positions entails.

What We Need: An Ethical Bank

We need more ethical banks, where decisions are made transparently, its allegiances trace back to community concern and its pricing of credit and investments is directly tied to the contribution each transaction makes to growing regional health.

I recently was very fortunate to purchase a house in San Francisco. As most home buyers, as part of the process, I had to get a loan approval  and to provide a lot of paper-based information. Unsurprisingly, I submitted this information in the form of electronically scanned print outs of various online Web services (thank Science I didn’t have to mail printed statements). This pile of information was then manually verified for accuracy and authenticity, and the relevant information was manually fed to a mortgage approval system.

Here is the information I had to provide:

1. Hazard insurance policy
2. Complete institutional statements covering most recent months + as applicable, reasonable explanation and documentation for any large deposits within the last 60 days
3. Copy of the purchase signed agreement
4. To verify salary: 1) paystubs for the last 30 days 2) last 2 years W2s
5. Landlord reference verifying payment history for the past 12 months
6. Verification of stocks/bons as stated in application
7. Evidence of residency and employment status in the US
8. Verified employment with employee through verbal conversation or electronic verification of employment
9. Verification of applicant’s identity (identification certification document signed by authorized bank representative and faxed)

I won’t talk about #9, which is simply ridiculous since I’ve applied for this loan at a bank I’ve been banking with since 1998 and who also handles my brokerage account. I don’t know how many times they have verified thoroughfully my identity. I won’t comment on #7, but needless to say that when I know very well that the INS has this information accessible in real-time. Regarding #3, it might already be possible to directly extract from a digitally signed pruchase agreement PDF form the relevant information. If not today, probably very soon.

What’s really interesting is #1, #2, #4 and #6.

#1 is information I received from my insurer, but I assume it is available from my insurance’s Web service in HTML/PDF format.

#2 and #6 (and partially for #4 since I receive my paychecks by wire transfer to my checking account) is information that can be retrieved today directly from my bank or brokerage’s firm Web service.

There are several building blocks needed to achieve this:

• Information can be extracted from content. This assumes that the HTML content is either semantically tagged using a (yet to define) microformat, or available in alternative format, say some industry XML standard like ACORD XML for insurance or OFX for banking/brokerage information.
• I can tell my bank to authorize the inquiring party that they can retrieve specific pieces of information. Also, I can specify to the inquiring party who they can inquire this information from. This is were an authentication delegation protocol like OAuth can be useful.

#4 (Landlord reference verifying payment history for the past 12 months) is interesting. My current landlord and I banking at the SAME bank, I would have enjoyed the possibility of being able to tag some of my transactions with “rent” and share it with him so that he could validate them.

I recently went through the 350 or so reviews of the BofA iPhone app. Here are my conclusions.

First of all, BofA should have called this app “ATM locator” instead of “Mobile Banking”, as the ATM locator capability is praised by most as a way to save on fees when traveling out-of-town or when in unfamiliar neighborhood, but the overwhelming majority comment on the fact that the application provides a very poor mobile banking experience on the iPhone.

What is meant by iPhone-specific experience?

iPhone-specific experience is the single most requested feature. I’m careful not to talk about implementation details here (native app versus iPhone-optimized Web app) as I still don’t have a strong opinion about which approach would ultimately bring the best user experience (native app developed in-house would require a learning curve that would certainly impact the quality of the app, while a Web app would have to be provided with JavaScript API wrappers of some of the SDK APIs like CoreLocation to provide an interesting user experience).

For most what iPhone-specific experience means is:

• More finger-friendly (avoid pinching, which is a sign that the app is not optimized for the iPhone)
• iPhone-specific styling like buttons instead of tiny text-based links
• Consistency across the whole app (not a mix of a native for ATM locator and Web for mobile banking that does not instill confidence)
• More condensed information per page using table views

Other interesting requested features

Here are the other interesting features requested:

• Add support for customers in Washington and Idaho states.
• Faster login (one suggested using a PIN instead of a long password)
• Transaction reconciliation via mobile banking
• Background download of information such as balance for quick one-click look
• Better support for credit card accounts (currenly only balance is available, not transaction list)
• Support for My Portfolio feature
• “Something like E-Trade on the BlackBerry”.

Further thoughts: personalizing the mobile banking experience

The one thought that came out of this analysis was that mobile users have fundamentally different needs in terms of the information they want to see after clicking the BofA logo on the iPhone homescreen.While most expect to be able to do everything they can do with online banking, all expect to do much faster the things they do most commonly in online banking. And that’s where the design problem of shrinking online banking into a mobile app is in my opinion. On one hand, what everyone does most commonly is very different from customer to customer. On the other hand, an intuitive interface design principle is “Human interface cognitive load is proportional to the number of clicks/keystrokes/gestures“, which means that people won’t like the user experience unless they get to do what they want to do in the least number of clicks and keystrokes. This includes login in, selecting a transaction, entering amounts, etc.

To give a few examples from the reviews: those who travel don’t care about the ATM locator. Those who travel love it. Some only have a Credit Card account with Bofand don’t care about Checking/Savings.

Which leads me to think that the future of the BofA iPhone app or any mobile banking app for that matter will be in the ability for the user to personalize their experience by providing to BofA the shortcuts to the transactions they do most.

This may include just a transaction identifier and an account identifier (ex. “view balance” “checking-1234″) or more complex shortcuts that borders on programming/querying: for instance “view transactions” “CC-8456″ “Last 10 posted transaction” or “transfer” “$100″ “to John”.

Online banking will most likely be the place where these personalizations will be programmed. Until then, getting that 5 star rating on iTunes app store and getting everyone happy might be difficult.

I searched the SXSW interactive panel picker for “banking”, “money”, “finance”, “financial”, etc. Here are the panels I found:

• Banking 2.0 – Algorithmically Fixing the Sub-Prime Mess (suggested by Christopher Hughes, PennyMac): Sub-prime debt may be causing the collapse of the worldwide economy. Speculators, investors, banks, mortgage brokers, honest home-owners have all been duped into believing that that the real estate market was a “sure thing”. Can a solution be found with a computing cluster, open source software, and a semi-complex algorithm? Yes.
• Future of Money: Life after the Fed (suggested by Blake Stephenson, Flow): Ron Paul’s presidential campaign shone a light on the impossibility of central banks to “regulate” the economy and the inherent problems with fiat money (paper money). The internet is playing and will continue to play a critical role in the creation of the future of money. What is the future of money?
• Mobile Ubiquitous Banking and the Future of Money (suggested by Kyle Outlaw, Avenue A | Razorfish): Nearly half the world’s population now has a mobile device and more than a thousand cell phones are being activated every minute. The ubiquity of mobile devices will make new services available to billions of people worldwide who have not had access to traditional banks or credit cards. In developing countries such as Kenya – where nearly 80% of the population is excluded from the formal financial sector – text messaging is being used to transfer money to friends and family living in other countries. Moreover, new forms of currency are being created – trading cell phone minutes for goods and services, for example. This panel will explore the challenges and opportunities as banks go mobile, and how the revolution in mobile financial services will change the way we think about money.
• Strategies for Establishing Social Media in B2B Relationships (Brad Garland, The Garland Group | Banktastic.com) Social media in the consumer space is clearly talked about and prevalent. What is barely getting addressed is how these technologies can be implement in the business world and what are ways to do it successfully. This panel will explore that concept and how B2B relationships can be formed using these tools.

About SXSW:

SXSW Interactive Festival features five days of exciting panel content and amazing parties. Attracting digital creatives as well as visionary technology entrepreneurs, the event celebrates the best minds and the brightest personalities of emerging technology. Whether you are a hard-core geek, a dedicated content creator, a new media entrepreneur, or just someone who likes being around an extremely creative community, SXSW Interactive is for you!

The Bankwatch had an interesting post titled Payments – the impossible dream for Banks? this week outlining the importance of payments for banks and the challenges they face in bringing about innovative and user-friendly payment solutions. Colin’s line of thought is that:

1. Banking has moved to self service
2. Self-service allows two types of financial activity … view balances, or move money.
3. Moving money is payments.
4. Payments, as currently offered by banks, are mostly hell and they cry out for innovation
5. Payments innovation is not about technology or standards (SEPA), but about customer experience

I cannot but connect this “hell” experience with one of the most interesting questions raised during the Mobile Web Wars conference last week:

Why  people are willing to pay for apps on the iPhone, but not on Facebook?
Why people are willing to pay $3 for ringtones, but not $1 for music files?

A participant was arguing that the reason was the “mobile effect” i.e. the fact the mobile is a relatively new communications channel that is so personal that people value it more than the PC channel. But at the same time, Bart Decrem, CEO of Tapulous, a social app company for the iPhone, was saying in the background: “Ease-of-use, Ease-of-use, Ease-of-use”, in other words: convenience drives customer value and their willingness to pay.

Something pretty obvious some would say, but this idea was made to me much clearer in the last few days while trying out two new services: expensure.com, a London-based bill sharing online application, and TipJoy, an online tipping (“micropayment”) service. Both services address different user problems, but they both address it very well with an extreme focus on convenience.

TipJoy for instance, does not require what you would normally call “payees” to register: you can simply donate to any URL on the Web you want. As Web site owners register and add the TipJoy button on their Web site, they essentially claim by the same token URLs and collect tips. From the payer / tipper perspective, a single click on the TipJob button is required, nothing more: the button is already configured by the payee with a pre-defined amount (in the order of 5 to 50 cents). This is convenience at its best.

Expensure solves the problem traditionally solved by complex spreadsheet. I used it to share bills between an upcoming WE trip with my friends and I was extremely satisfied with the application. It’s all in the details. For instance, I was able to set a ledger and experiment adding expenses to it without having to invite my friends to the service, something that would have refrained me from starting to use it, b/c my friends are too busy to receive unwanted invites from applications I found not worth using after a trial. In this case, I did, and ultimately send the invite to 5 friends.

Both applications touch on the problem of payments, but with an extreme focus on a relatively highly context-specific problem and a very well designed solution to the problem. Yes, I could have used my bank’s transfer service, or checks, plus a shared Google Spreadsheet, as I did in the past, but I will certainly not do so now that my social network is almost set up with Expensure. Same thing with TipJoy: while I could have used a PayPal button on my blog, I can see the value of simply providing a pre-defined amount to users willing to tip me, and will most likely go with them in the end if I ever want to be tipped for writing these articles (I’m not really and I’m doing this on the side of my day job).

What was the most interesting to me, what the following FAQ excerpt from Expensure:

Can I pay somebody back using Expensure? Soon. Right now we are focusing on making Expensure the best shared expense tracking app out there.

and from TipJoy:

Why can’t I withdraw cash from my Tipjoy account? There are legal implications to allowing this transaction which we are currently working through. We expect that you will be able to withdraw cash very soon. In the meantime, if you have a minimum of $5 in your account after removal of applicable fees, then you can do the following with your earnings: 1. Donate to any official charity you’d like 2. Purchase an Amazon gift

Both of these companies are clearly focused on providing the best customer experience first, then only will they figure a way to monetize it. They probably have listened very well to this presentation from Paul Graham on how being benevolent and focusing on solving problems is more important than thinking about making money when starting a business.

The only thing that these companies are missing is that they are not a bank or Credit Union, but as good entrepreneurs, starting a new CU or bank is probably not an option they will choose. Just like PayPal partnered with Wells Fargo, I would not be surprised to see an innovative bank or CU partnering with them to handle the back-end aspect of their solution, in particular legal compliance in each legal framework/geography they do business in.

So, when real-estate agents are asked about RE investments strategy, it’s: “Location, Location, Location”. When asked about early-stage investments, VCs talk about “People, People, People”. Perhaps, when banks are asked about their payment strategy, or their general banking strategy for that matter, bank should say: “Convenience, Convenience, Convenience”.

I wasn’t able to attend BankCampBankDallas, but Charlie over at Open Source CU wrote a nice report highlighting some of the concepts that were discussed during the camp:

• Incorporating online reputation into financial reputation: “why can’t [FIs] hook into LinkedIn and view a person’s Recommendations and process that into their credit score”
• Opening a FI’s APIs to the creativity of their customers and 3rd party developers: “could there ever be a day where an existing financial institution could let people hook into it and meaningfully tailor the infrastructure and product to their own needs?”

I think exploring the links between online reputation and financial reputation is very interesting indeed. I think leveraging public social data is a great way for banks to reduce the risk of payment default on people with less than perfect credit. I’ve talked about this before, particularly in the context of peer-to-peer lending: in the problem with banking innovation…, I explained how a loan where some of the people lending money are family members offers a different and more attractive risk profile than someone’s lending money from people they don’t know (and don’t care) about (especially when you have a huge securitization food chain). I had never thought that such data could eventually actually be part of the FICO score, and that I think that will take A LOT of time. Here is my guess at how things will evolve: I think that Experian-like services computing someone’s overall reputation (see how to compute someone’s whuffie) will develop, and as they become established brands, may end up as an input to FICO scores. Anyway, I do think FIs are fundamentally social intermediaries and can’t afford to ignore the publicly available social data. I think there is a great opportunity, especially at credit intermediaries whose goal is the benefit of the community (credit unions), to re-socialize credit relationships.

Regarding the opening of Banking Web APIs, I think also that this is a great way for FIs to smartsource innovation while ensuring the highest level of security standards. In the problem with banking innovation…, I suggested at the very end that one way to smartsource innovation could 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).”

So, I’m glad to see that these highlighted concepts are inline with some of my own ideas and probably with many other people. I really hope I can make it to the next BarCampBank near San Francisco.

PaymentNews pointed to a research paper title “Business Method Patents and U.S. Financial Services” authored by Robert M. Hunt of the Philadelphia Fed.

As any researcher in knowledge economics would know, maximizing the value of knowledge for society is a difficult problem:  on one hand, you need to provide the proper incentives for innovators to invent (typically a patent system that provides a time-limited monopole), and on the other hand you want this knowledge to be used as fast as possible by as many people. Finding the right balance is not easy. This is a subject I’m really interested in, and business method patentability is a very interesting on its own, so I went through the paper. Here are my notes.

Here is the most important part IMO from the conclusion:

There is at present very little evidence to argue that business method patents have had a significant effect on the R&D investments of financial institutions. It is possible that the availability of business method patents has encouraged more entry and R&D by start-up firms or more efficient trading of technologies. At present, however, these represent intriguing possibilities and not outcomes that have actually been measured. In short, we still cannot determine whether financial patents are creating value for the U.S. economy.
[...]
The combination of significant technological overlap among firms, elastic patent boundaries, inadequate enforcement of disclosure requirements, and weak patentability standards raises at least the theoretical possibility of perverse outcomes (Hunt 2006). In such environments, firms may obtain more patents but perform less R&D, since the fruits of such efforts would be subject to an innovation tax imposed by rival firms.

My thoughts:
I think this area of patents is still evolving and regulators are still learning how to best optimize the value of the U.S. economy of patent issuance. There is a risk that startups be issued business method patents that other FIs license only to see themselves fought to death by large FIs in court. I don’t think it will be a big problem for niche markets, but it would be interesting to see what a court would decide if consulted on the non-obviousness of a business method patent issued to a small firm and which possibly has a huge impact/potential to many large FI players.

More excerpts:

A decade after the State Street decision, more than 1,000 business method patents are granted each year. Yet only one in ten are obtained by a financial institution. Most business method patents are also software patents.

That’s 10 business methods per year coming from a FI. Wow! The remainder of the article is basically trying to explain why these numbers are so low. Probably most of banking related business method patents come from startups (ex. SmartyPig has a patent on their business method).

Financial exchanges and the central bank are more research intensive than credit intermediaries (banks and thrifts).

I don’t think that will come as a surprise to anyone. I wrote earlier about the innovation problem at banks (I should have precised credit intermediaries as I’m well-aware that innovation is thriving in the investment side of banks).

Number of financial industries rely heavily on standard setting arrangements esp. payments networks and financial exchanges.

The article seems to imply here, if my understanding is correct, that business method innovation requires multiple parties to implement it, which means it’s hard for any one party to patent it at the same time that it seeks others to use (license if it’s a patent). That’s as if you had to pay to use a standard…

Lerner (2006) finds that business method patents are litigated at a rate 27 times
higher than for patents as a whole.

The reason for this is that the legal aspects of business methods patentability is still evolving. This might be another reason why business patents are few. It’s easier to keep them as good old trade secrets when possible, than try to patent them only to have to pay an army of lawyers to litigate them.

The article also talks about the legitimacy of licensing a patent and fighting in court in validity at the same time.

This is a translation in French of an earlier post.

Il y a presque dix ans, au sommet du boom Internet, je me rappelle avoir avoir discuté avec un banquier qui me suggérait que dans le future, le rôle des banques ne se limiterait pas a garder l’argent de leur dépositaires, mais aussi à garder leur identité en ligne secrète. D’une certaine manière, cette prediction s’est concrétisée par le biais des programmes de protection contre le vol d’identité. Cela dit, si l’on définit l’identité comme la somme des informations personnelles qui distingue une personne d’une autre et qu’il est difficile voire impossible de se procurer, on voit bien qu’une grand partie de ces informations (et en particulier les secrets tels les mots de passe) sont disséminés dans un grand nombre de services en ligne (60 en moyenne, bientôt 200, d’après une étude du Yankee Group sur OpenID).

Comme chacun sait, OpenID constitue la solution non-propriétaire à ce problème, et pour les raisons présentées ci-après, il semblerait que les banques soient des candidats parfaits pour devenir fournisseurs d’OpenID:

• “Qui peut le plus peut le moins”. Le niveau de sécurité imposées par les services en ligne aux mots de passe de leurs utilisateurs ainsi que l’intérêt des utilisateurs à avoir des mots de passe difficiles, varient d’un service en ligne à un autre, mais la banque en ligne est probablement un des services ou le niveau de sécurité des mots de passe est le plus élevé. La raison est simple: il s’agit du service où les utilisateurs ont le plus à perdre si leur mot de passe se retrouve dans de mauvaises mains. Ainsi, on peut difficilement imaginer un utilisateur s’authentifier auprès de son service de banque en ligne avec son le nom d’utilisateur et mot de passe de son compte Google, mais l’inverse est beaucoup plus plausible
• Les banques ont plusieurs actifs existants relatifs à la sécurité:
  • Elles ont déjà en place une infrastructure technique assurant la sécurité de l’accès en ligne aux comptes bancaires,
  • Elles ont pour la plupart une image de marque forte en terms de sécurité, et
  • Elles ont déjà en place des programmes de protection contre le vol d’identité qui fourniraient un complément d’assurance à OpenID, et ferait de cette technologie une vraie solution/vrai produit
  • Les banques sont tenues légalement de connaître leurs clients, et ont pour cette raison probablement beaucoup plus d’information sur leurs clients (par example, documents officiels comme carte d’identité) que n’importe quel autre service en ligne (mais pour combien de temps encore?). Cela veut dire qu’elle possèdent le plus large éventail d’options d’authentification, leur permettant de supporter plusieurs niveaux d’authentification. Elles ne sont pas limitées au model d’OpenID classique de l’URL et du mot de passe: elles peuvent non seulement décider d’émettre des URLs OpenID qui soient distinctes du nom d’utilisateur, mais elles peuvent aussi et surtout utiliser une authentification multifacteurs, par exemple envoyer un numéro personnel secret par SMS à un téléphone mobile, ou demander à un utilisateur de cliquer sur un bouton pour être appelé par un centre d’appel, comme spécifié par les OpenID policy extensions.
• Enfin, il existe de très bonnes raisons économiques. Un service OpenID offert par une banque consituerait:
  • Un service à très forte valeur perçue (mot de passe unique pour potentiellement tous les services en ligne utilisés par un utilisateur) que les banques pourraient faire payer
  • Une nouvelle façon de promouvoir leur image de marque: compte tenu du fonctionnement d’OpenID (redirection vers le fournisseur OpenID pour chaque authentification) les utilisateurs verraient le logo de la banque à chaque authentification.
  • Un formidable outil marketing: les banques auraient connaissance de quand quel utilisateur utilise quel service et pourraient présenter en fonction des offres et publicités liées ou non à leurs produits lors de chaque authentification,
  • Une très bonne manière de garder leurs client: le coût de changement de fournisseur OpenID s’ajoutant aux autres coûts de transfer de comptes bancaires à une autre banque.

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?