Category: online banking

The future of the BofA iPhone app: besides better iPhone support, personalization?

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.

A bank’s payment strategy in 3 words: Convenience, Convenience, Convenience

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

Les banques devrait-elles devenir des fournisseurs d’OpenID?

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.

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?

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

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