Community

@UriR:

Great pair of websites. Thanks for profiling them!

After a very quick and dirty test with a couple of passwords, I've jumped to the following conclusion which fellow readers might want to accept on faith or reject outright: Passwords in foreign (i.e. non-English) languages are impossible to crack, though easier to remember (in case you know only a few foreign words).

No problems @AlexanderP. You might want to correct the one next to "piece of cake" as well. 

You're probably right about the relevance of voice recognition in healthcare, government education, sports gambling and other apps. But, the functionality set currently offered in many mobile banking apps - a/c balance, last 5 transactions, mini statement, fund transfer, etc. - is so sparse that the icons are located comfortably apart on the screen, even in relatively small (2-3") screens, so fat finger is not a big problem. Of course, all that could change in the next generation of mobile banking apps and voice recognition could become important for them.

Beware: People might give your solution a piece of their mind until your solution gives them peace of mind.

Looks like Apple is testing the payments waters already: For all the examples around storing e-tickets, loyalty cards and so on, Apple demos Passbook with a payments use case (i.e. Starbucks Prepaid Card). By using a QR code in Passbook, I think Apple is signaling that it's not going to join the NFC camp, somewhat like PayPal in its new inStore app. Apps like keyring have been available for years for this use case. Apple's differentiation lies in using the lockscreen and location info to eliminate the need for the user to fire up an app and select one out of the many cards stored inside the app. Far as I know, this is not possible in any other mobile wallet. As usual, Apple is going to thump incumbent players by taking UX to unprecedented heights.

Until someone from NCR weighs in authoritatively, let me take a guess: Amount and PIN entered into NCR app on smartphone reaches NCR cloud via smartphone's data plan; NCR cloud sends said information to bank's switch via Internet or dedicated lease line; switch sends said information to ATM machine via internal LAN / WAN. If this is really how this works, the number of moving parts and the degree of convolutedness are even higher than I'd previously imagined.

@ShekharK:

When I read the line "can be used across a variety of establishments...", I was mislead into viewing openness from the merchant perspective. Here, there's really no problem even if a mobile wallet supports only one funding source since most merchants, who have tended to accept a wide variety of cards for a long time, are likely to accept this one card. No wonder, despite supporting only one card, Google Wallet can still proclaim, as it does, that the consumer can "pay with Google Wallet anywhere MasterCard PayPass is accepted", which is not a small number. 

Thank you for clarifying that you meant 'open' from the point of view of the consumer / payor. There, I agree with you that supporting only one or two funding sources - the way Google Wallet (NFC) does at present - severely limits the utility of a mobile wallet for the consumer / payor.

Having said that, a quick search for "mobile wallet" on Google Play brought up over 300 apps, many of whom are 'open'  since they claim to support a wide range of credit, debit and loyalty cards. Against that backdrop, it's interesting to observe how a 'closed' product like Google Wallet has garnered a disproportionate share of voice among mobile wallets.

Although a technology marketer, I recognize that not all technologies successfully overcome the often-conflicting priorities between cost reduction, revenue enhancement and improved customer service. HSBC India's experiement with Cheque Deposit System is a good example of a technology that (arguably) helped the bank cut costs but became a major pain area for customers. Thankfully, the bank has finally realized this and has de-commissioned all its CDSs.

This example just reinforces the need for banks to choose their technologies carefully so that they can optimize their alignment with business objectives. On this count, I'm not very gung-ho about 'open API' and such technologies: We all know how banks earn more fees and increase stickiness by being 'closed' and 'proprietary'. While the technology is very appealing, 'open' and 'API' seem to be the exact antithesis of the business model that has worked so well for banks all along and made them 'too big to fail'. Maybe some nonbank will come and disrupt the scene but I won't bet on that happening anytime soon. 

@Alexander P:

Since SQUARE is the only startup you mention, let me say:

• Its founder Jack Dorsey is not even 30! (could be wrong here but not by much)
• As I've pointed out elsewhere in my Finextra comments, SQUARE is an ally - not adversary - to banks. Before SQUARE, all those "Florida boardwalk" type of merchants were only able to accept cash from their customers. Thanks to SQUARE, a lot of their transactions now happen via bank-issued credit / debit cards, fetching banks an incremental source of interchange revenue without the incremental risk - as banks see it - of issuing acquirer accounts to such merchants. I hope the US$ 4B valuation of SQUARE factors in the risk that SQUARE takes by acting as a sort of 'master-acquirer' for all these merchants. 

@LeonO: Thank you for your response. Waterfall and Agile differ quite substantially. Much as a hybrid between the two methodologies is desirable, I'm not sure if it's feasible. At the risk of generalizing, I predict that startups will begin with agile and move towards agile as they become big, whereas large IT shops will continue with waterfall. My belief stems from, among others, my personal experience of seeing how change control process has become even more long drawn out in large banks and corporates, thanks to tighter IT budgets, greater IT savviness of end users and increasing involvement of business in reviewing and approving individual Change Requests.