Community

@Melvin H: 

That was exactly my thought, and I hadn't even thought that there were as many as 250K charities in the UK. There's no way selection of charity by the ATM user would work on a queue-based venue like ATM.

On the face of it, the best option appears to be one where donors need to simply press one out of several buttons labeled "Donate 10p", ..., "Donate 25 GBP", and not have to select the charity unless they choose to, with some agency at the backend distributing the collections to the charities. However, it won't take long for this agency to start facing charges of non-transparency, etc.

A more practical alternative could be for charities to buy display ads on the ATMs that are capable of accepting donations. In addition to the donation amount button, ATM users would simply need to press on the ad of their favorite charity and the money goes to that charity. Many charities anyway advertise on various media, ATM becomes one more and probably the one that delivers the greatest bang for their buck. 

Agreed! A couple of days ago, I'd commented on a Finextra post around social media adoption by banks. While the context was different, the same conclusion applies here: If you can't do it properly, please don't do it at all!

Having said that, my experience suggests that it might be worth investigating how it's done before giving up completely. Not being familiar with HTML coding, I'd used the intuitive design mode of Microsoft Frontpage to develop a few pages of a website. With no conscious effort on my part, these webpages 'ported' perfectly across IE, Chrome and Firefox. Whereas the other webpages developed by HTML specialists using some programming tool had all sorts of incompatibilities across different browsers!

Personally, even I'd hesitate to hand over my Internet Banking credentials to a third-party, and had stopped dead in my tracks when I reached this stage on Mint. However, Mint's success and huge exit shows that there are enough people who perceive the risk-return equation differently. The basic issue with Blippy - and I'm saying this with the benefit of hindsight - was, it didn't give as much as it took: Price comparison engines give richer pricing information but don't ask for personally identifiable information. As for the social angle of Blippy, haven't we all been through situations when we thought we got the best deal for something only to be pipped to the post by some friend who'd managed to find an even better one? Blippy would only add to our woes by making it easy for such friends to gloat over our misfortune!

Barring a few exceptions (e.g., Boku, Zong and their Gen Y Mobile Payments competitors), most open-loop mobile payments available in the market today are based on an underlying credit/debit/prepaid card. As such, they only replace the physical card as a form factor but don't supplant the basic card account. I've never tired myself of voicing this point whenever I've come across articles and blogs that seem to suggest that Mobile NFC payments sound the death knell of banks' flourishing cards business. Thanks to Quick Tap, which explicitly involves a bank card brand, this point has become obvious.

With an upper ceiling of only GBP 15 per transaction, I'd opt for no password/PIN just for Quick Tap - why go through the inconvenience when the risk of fraud / loss is so limited? While a GBP 10 credit will entice sign-ups, I'm sure we'll see other measures going forward to sustain consumer interest once the novelty factor wears off. For example, a single 'PayPal meets KeyRing' type of app with a single password that stores all credit/debit/prepaid/loyalty cards owned by the consumer. This might sound a bit adventurous. But, right now, we seem to headed towards one app for each card - and one password for each app, for those inclined to passwords - and I doubt how many consumers will stand that level of 'app fatigue' and friction in the long term - all for making a payment which was never so difficult with cash, was it! 

My car driver closely fits the profile of the driver-cum-milkman described in this post. As soon as he opened his bank account and received his ATM/Debit card, he asked me whether he could use the card for shopping. I told him yes, sure. A month later, he told me he couldn't use his card for shopping anywhere. Reason? A majority of the mom-and-pop stores that he'd shopped in didn't accept card payments. The few that did demanded a 2% surcharge for card payments.

While almost all supermarkets and department stores accept card payments, they only constitute 10% of the retail market in India, with those at the bottom-of-the-pyramid patronizing mom-and-pop-stores that make up the remaining 90%.

Changing consumer payment behavior is important. But, banks might also need to promote greater acceptance of debit card payments by merchants and enforce the no-surcharge rule that already forms a part of the merchant's agreement with card networks. 

Great model!

In addition to multichannel banking (customer can conduct all processes end-to-end on each channel), omnichannel banking (customer can hop from one channel to another while conducting a given process end-to-end), we'll now have retail stores playing the role of another channel!

However, the big question is, whether banks and the banking regulator will permit this vision to become reality in its present frictionless form. Going by the following examples, the prognosis doesn't look too good, though:

1. Retailers are permitted to hand out cash to customers paying by debit cards and manage their cash holdings better but, by insisting on charging the full merchant fees on such transactions as for sale of goods, banks have taken away the incentive for them to promote this feature at the till
2. With the forcible insertion of banks into the payment value chain, mWallets and mPayments haven't been able to attain critical mass several years after being launched. 
3. Without appreciating the intrinisically secure nature of mobile phones (viz. out-of-the-box device authentication capabilities), insisting upon two-factor authentication for mPayments has led to drop in mCommerce volumes as reported by leading etailers (e.g, ClearTrip).  

The argument is convincing, no doubt. As I'd recently blogged and commented on Finextra, banks have found lighthouse implementations of social networking in FIs like NetSpend. In theory, they should be able to forge ahead with their social media projects no longer concerned about how to overcome compliance and other hurdles.

However, in practice, if as much of 60% of retail banks have told Nielsen IAG that they have no plans to use social media, lack of awareness of its benefits can't be the sole reason behind their stand. While we can never be sure what their other impediments are, there are a few obvious clues that let us do some crystalball gazing.  

Whenever a customer / prospective customer raises a query or complaint by using the bank-prescribed channel (viz. online form, email), very few banks promise to respond in less than 24-72 hours (some don't get back even after several days, but that's another story).

Maybe banking is intrinsically complex. Maybe systems and processes in banks are sluggish. Either way, if "24-72 hours" is the fastest response banks can muster up, they are possibly better off staying away from social networks where response times are measured in seconds / minutes. They might have astutely concluded that no social media presence is perhaps better than bad social media presence!

As I'd commented on another Finextra post on a related subject around ten days ago, replacing legacy systems totally could prove too much of a budget and career buster for the stereotype of a conservative banker to risk.

Fulfillment of much of the functionality and UX required to satisfy the next generation of customers doesn't necessarily call for replacement of legacy systems. As Western Union, MoneyGram and a few other non-banking financial services providers have proved, this can be achieved more pragmatically via Mobile Apps, RIA, Web 2.0, Enterprise Portal and other state-of-the-art overlays built on top of existing backends that will inevitably include a mix of legacy and open systems for the forseeable future.

"Million dollars uploaded a month".

Either the 'million' is a typo or the Mobile RDC market is so tiny that even a company of the (large) size of PayPal has to content itself with such a (small) volume from a product that it calls a "big hit". 

Having observed a few legacy transformation initiatives up close, something tells me that real traction in this space will happen only when banks outsource these business processes and transfer much of the risk of program failure to the outsourcer. Small banks already use apps on tap. Large banks might get inspired by a few large telecom giants who have outsourced all core processes, retaining only brand building and customer acquisition functions inhouse.

Such transformations also demand very novel go to market approaches and sophisticated estimation techniques on the part of the technology vendors. A recent example of this is a leading IT services provider who attributed its winning a $$$ million deal to its offer of replacing the customer's legacy applications with a spanking new SAP solution - for no more than the AMC cost of the legacy applications.