Community

Unlike card-based mobile wallets, this method of payment provides a compelling reason for adoption at least for merchants. If their mindset has changed since two years ago when I'd written my below post, they should respond favorably to it.

Do Retailers Want To Have Their Cake And Eat It Too?

Questionable UX for the customer. Possibly longer queue for the merchant since it will likely take longer than plastic to (a) fire up an app, enter the merchant's email address / mobile phone # and amount; and (b) wait for authorization (while FPS is Near Real Time, I'm not sure if it delivers card-like response time of 5-10 seconds). Problem (a) will go away after the first payment in the case of Starbucks and other frequently-used merchants since I'd expect the app to store email / mobile of previously-paid merchants and let users select them from a list. Problem (b) might be a tougher nut to crack. For the bank, loss of interchange revenue. Apart from these, a workable concept.

It's all fine for third-parties to ask such questions. I myself have a long list of them, with my personal - nothing to do with my background :) - favorite being "Osama bin Laden is a terrorist everywhere, so why should each bank in each country have a separate sanctions screening system to block payments to ObL?" However, in actual practice, virtually each large bank does. That's because, in all these things, the questions that really matter are the ones that face the key stakeholders of the transaction viz. "What's in it for me? What're the risks? How do I mitigate them?" for the Bank; "Why should I risk exposing my sensitive banking credentials for everday nonbanking transactions?" for the User; and, "How much will it cost me to reuse banking credentials? Which bank's credentials? In the event a customer files a claim of fraud, will the bank take responsibility? After all, it's claiming that its authentication system is more robust than mine, is tested for AML, blah blah blah" for the Merchant. If and when these questions are answered to the satisfaction of all primary parties, I'm sure banking credentials will find reuse for third-party services.

But, at this point, I'd place my bet on social signon - the reuse of social media logon credentials. It already has a solid headstart in this space; it's free and convenient for everyone; the merchant won't face the equivalent of the "which bank?" question because between Facebook, Twitter and LinkedIn,  social signon covers more people than all banks combined; and, because almost no one is sure how exactly the info collected will be used and shared, nearly everyone assumes that all's well until they discover otherwise.

With the digerati threatening that tech giants and nonbanking startups are going to disintermediate banks soon, I won't blame banks if they're too busy pondering over basic existential questions rather than finding answers to philosphical ones! 

While I can't talk of the specific app from Bank of the West, "Remember me" doesn't necessarily mean "permanently connected" in the context of a generic mobile app. I know from mobile apps developed by my company that it's possible to use mobile OS-specific technology (absent on PCs) to move information like account balance only "on demand" i.e. without the need for the frontend and the backend to be connected with each other all the time. Therefore, if done right, Mint / BillGuard / Yodlee will continue to work fine even if this feature is activated.

Zite is a popular mobile app that seems to use such technology because it's able to serve news articles customized for each user on demand. In fact, it doesn't even need registration, let alone temporary or permanent logon.

In a larger context, this harkens back to my oft-expressed view that mobile banking shouldn't be seen as an extension of Internet Banking and that it will achieve mainstream adoption only if it's designed to support features that use GPS, camera, accelerometer and other features found on smartphones but not on PCs.

Thanks but I'm fairly familiar with such services and their process flow, especially SVP payments authorized via banking credentials. It's technically true that the merchant does not receive nor store my banking credentials but it's not easy to convince an average customer of that. I've highlighted the anxiety faced by a typical user with services like that in this Finextra post about MyBank. Two years later, despite the provider of this service being a trusted bank-consortium, MyBank's adoption has been lukewarm, suggesting that the anxiety hasn't gone away. 

Besides, in the example quoted to illustrate the process flow, the transaction is happening between a bank and a customer using a mobile banking ID, there's no third-party merchant, nor third-party credential. Unless mobile ID refers to an ID issued by the MNO, in which case the question is, why not use the banking credential for such a straightforward transaction between a bank and a customer, especially when we're talking about using banking credentials even for nonbanking transactions. 

@DanielS:

Just as I'd insist on 2FA for carrying out high-risk transactions like the ones mentioned by you, I'd be comfortable with 0FA or 1FA for account balances and the few other transactions I've mentioned earlier. 

Many people - including me - hardly bother to read EULAs and TOCs appearing on our PC or smartphone screens before we click / tap the "I Agree" button while installing an app. Banks shouldn't have any problem in burying any amount of CYA fineprint while activating such features.

While on this subject, I just did a quick test: I fired up my Mobile Banking app on my smartphone, supplied my login credentials and surfed the app. While I was still logged on, I tried accessing the same bank's Internet Banking website. Once I submitted my credentials and clicked the Submit button, I was blocked from going further with a message saying that another session was already on and I couldn't get into Internet Banking until the other session was closed. Therefore, while the mobile app "remembers me", it's possible to ensure that no one else - not even me - can access my account from anywhere else. This validates my previous point about the risk of access being limited to my smartphone in my possession.

So, there, there are many nonbanking services who reuse banking credentials. Therefore, I'm not sure if the basic premise of this blog post is valid any longer. Now that there's at least one bank that finds a compelling reason to lend its credentials infrastructure to third party services, others should find a strong enough business case to follow suit. Time will tell how many customers will feel comfortable about (i) sharing their banking credentials with nonbanks (ii) being forcibly logged out of third party services after a few minutes of inactivity just because banking regulators often impose short expiry period of banking credentials on banking websites.

@ChandrashekarG:

Knowing how slowly banks introduce new features, I'm sure this bank has thought about the audit angle before introducing this feature but, even it hasn't, (a) As a customer, I'm only interested in the feature I get (b) When I trust my bank with my money, I'll easily trust that, if the said feature failed audit, my bank would withdraw it. 

Interesting that you mention FFIEC. This body mandated 2FA for Internet Banking transactions for US banks in 2005, issued a revised guideline last year, but there are still so many banks in USA that have not yet implemented 2FA as is evident from Mint, BillGuard and other startups being able to access over 10M people's bank accounts using only a username and password. Eight years later, I'm not aware of a single bank being taken to court over this (The 3:2 tally of courtroom verdicts I'd referred to in my previous comment was for lawsuits arising from fraudulent fund transfers, not non-conformance with FFIEC). So, let's forget about regulation and courtrooms - all this regulatory bogey is coming from third-party security pundits. In any case, I'm sure that banks know how to deal with regulation.

Convenience versus friction is a matter of personal choice. I'd rather not go thru' the hassle of entering a password while on a smartphone if I simply wanted to access my account balance - or forex rates or last few transactions or credit card outstanding amount. Since the smartphone is in my possession, the analogy of open door is flawed. If my smartphone falls into the wrong hands, someone getting to see my bank balance will be the least of my worries and, I can imagine, lowest on that someone's to-do list either. I don't need to read any article or book to know this. As a bank customer, I'll always opt for convenience and only deal with entities who I trust know enough about how to provide it without compromising security.

When I last checked, doing what has proven to be effective - whether it's old or new - was a good business strategy. I personally doubt if saving taxpayer money provides any direct benefit for any bank but I could be wrong. As long as banks see a strong business case in doing so, most banks I know would jump at it.

Agreed but, in the perpetual conflict between the quest for efficiency versus effectiveness, I tend to side with the latter even if the ways to achieve it might appear stupid and wasteful at times. Certain countries have enjoyed a basic level of public-private partnership for a long enough time for loftier goals like greater alignment of the partnership make sense. However, in other countries where the expression is almost an oxymoron, public services are better run by the government - in any case, there's no commercial incentive for banks to do so. While citizen ID projects undertaken by the government might have failed in other countries, its success in India proves that there's nothing fundamentally wrong with the model, just that its implementation must be gotten right.