Community

If, by B2C payments, you're referring to consumer to business payments in the biller-direct model, only if the consumer chooses "NetBanking Transfer" as the method of payment does the bank's portal enter the picture. Many people - including me - choose card payment and never log on to the bank's portal. While there's no universally-agreed rigorous definition of mobile payment v. mobile banking, I don't think C2B Card or NetBanking transactions of the above nature would qualify as either mobile payment or mobile banking. On the other hand, if a consumer accesses a bank via mobile web or native mobile app and makes a P2P or bill payment, that could qualify as both mobile payment and mobile banking.

Judging success of a service like mobile banking also requires certain realistic baselines: 15 years after Amazon pioneered ecommerce, online sales only accounts for 5-7% of retail sales in the USA. While this is a tiny %, people still think ecommerce is successful.

The real debate arises when the digerati claim death of the store or bank branch when moden digital channels, while quite successful by themselves, are nowhere near uprooting the traditional physical channel.

Maybe I've misunderstood it but much of this article seems to be about mobile payments, not mobile banking. I was recently talking to a customer living in Santa Clara and working in Mountain View, the absolute technology Meccas of the world. In the last 2 years, he says he hasn't seen even 10 instances of the use of mobile payments in supermarkets. So, the poor uptake of mobile payments is not restricted to India.

Talking of mobile banking, most offerings currently view it as a mobile variant of Internet Banking. People don't do banking so often that they really need a mobile appendage for it. More than anything else, this explains the low adoption of mobile banking. I expect mobile banking adoption to soar if it exploits camera, microphone, GPS, accelerometer and other powerful features of a smartphone to deliver use cases that are not possible on PC-based Internet Banking e.g. Mobile RDC.

@AdvaitR:

Phew, thanks for pointing the fraud ramification of CTS-2010! I never thought of it. Depending on which report or FAQ you read, you'd reach various conclusions ranging from "no need to change cheques" and "there's only one difference between the old and new cheques" to "you must surrender your old cheque books before getting the new ones" and "there are five differences between the old and new cheques". The only things I'm certain about are (a) I've received new cheque books from two banks without surrendering the old cheque books and (b) I won't be able to distinguish between the old and new cheque leaves.

Let alone rural and non-English speaking population, in this case, even urban and English-speaking people with fair amount of knowledge about banking - like me - need to be on the guard against the likelihood of fraud. Although it's another hoop to jump, I agree that bank verification of cheque validity will become a necessary step before contracts can be concluded in the CTS-2010 regime. 

Just tried it out. Was a bit disappointed not to see the wish on my FB newsfeed immediately. Apparently, the goal is not processed in realtime. Apart from this lack of instant gratification, works as advertised.

You've hit the nail on the head. I always have a good laugh when SQUARE-and-Clone fans wax eloquent about how they can pay their babysitters, plumbers, et al by credit cards - as though these "merchants" were just waiting on the technology so that they could ditch cash.

Talking about taxis, you pay a cabbie by cash, he gets the money immediately. You pay him by credit card, a 1-on-1 transaction gets corporatized, goes through bureaucracy at the taxi dispatch company, takes 2-3 days before it reaches the cabbie and, when it does, there's a deduction applied on the amount on account of MDF. At the same time, the daily fee that the cabbie owes to the dispatch company is still due in cash and by the end of each day. Which cabbie in his right mind would accept card payments as readily as cash? Under the prevailing business model, I don't blame them. This has nothing to do with payment methods.

Having said that, it's quite possible that tax avoidance, misconception, old habits, etc. could explain why some other businesses like daycare or plumbers tend to refuse cards.

Adding business value to a compliance initiative is always a powerful value proposition to nudge corporates along but isn't it a big stretch for them to expect fraud and bad debt related benefits from SEPA when most of their revenues are not from EUR?

A portal can be designed to provide access with a shared secret as much as a biller / regulator may force a password on a PDF attachment. In this day and age of social media, I find it difficult to believe that there's any shared secret question the answer to which is known only to the said customer and the biller - although I remain open minded about this and, in my previous comment, I've sought out a specific example of one that is at once easy to decipher, yet difficult to guess by third parties. Therefore, I treat password or shared secret as simply ways to "gate" content. Since the onset of the Internet, people are naturally used to facing gates on portals and not facing them on emails, which is why the latter poses unnatural change in consumer behavior, even if the former does result in some grief. But, this grief in the case of portals is "shared grief" since people access portals for viewing balances, making payments and many other things, so there's no separate grief caused by eBills and eStatements. Whereas, with PUSH-based technology, there's "yet another" password / shared secret and, therefore, incremental grief, caused only by eBills and eStatements.

Unfortunately, since I've experienced being on both sides of the fence, eAdoption rates don't mean much in isolation: As I'd pointed out in another post, I know billers who have used techniques to achieve 100% eAdoption on Day 1, let alone 40% in Month 1. While the biller and their eBilling technology provider can pat themselves for this achievement, their "early win" also turned out to be short-lived when (a) their TransPromos rates started dropping, and (b) some of their customers - including me - left them because they hated the questionable practices used by them to ram eAdoption down their throats. I continue to believe that the best way to boost eAdoption is by providing more value to the customer without increasing friction - something that is technologically feasible yet missing from live eImplementations I've come across so far.

When I said that roughly half my eBills and eStatements received by PUSH or PULL contained passwords, the implication was that the other half did not. The biller implements - or does not implement - passwords for reasons related to the fidelity of their contact management system. This decision is technology-agnostic and I don't know any PUSH-based eBilling technology that insists upon passwords (or shared secrets, for that matter).

Talking about shared secrets, in this post, I'd cited the following example: 

"Your password is a combination of first 3 letters of your name followed by last 5 digits of your registered alternate mobile number."

While the biller had called it a password, it could actually qualify to be a shared secret. So, if it's easy to remember, it's difficult to decipher. This is true of many shared secrets that I've set up. This is the exact opposite of passwords. While I'm open to other examples of shared secrets, I don't see a major difference between passwords and shared secrets at this point.

PULL or PUSH, roughly half the eBills I receive still contain passwords, which I, like the 61%, find very painful, so I continue to belong to the 37% group of Forrester. It's almost a year ago that I learned about the power of AcrobatX on these pages. During this period, I've managed to figure out how to highlight certain sections of the eBill using this software. Hopefully, I'll find enough time and energy in the future to master it such that I can annotate my eBills with notes of the type mentioned by MichaelK and simultaneously get my accountant and auditor to install AcrobatX on their computers so that they can read my notes. Maybe it's a stretch but I'll endeavor to do all this before my service providers tell me that PUSH / PULL have become passé and pitch the next best technology - social media, maybe? - for bill distribution. As for using eBills to fulfill perennial KYC requirements, I can't win 'em all, can I?

Let alone the common man, it looks like even attendees of an august mobile technology event like Mobile World Congress are unlikely to have NFC-enabled smartphones in large enough quantities for the bank to justify developing a mobile wallet app. This doesn't bode too well for the prospects of NFC-based mobile payments.