Community

With recent events like Google renaming "Android Market" to "Play Store", the term "play" itself might begin to have serious connotations, which is good for "gamification of banking".

The MyMoneyAppUp contest being run by US Treasury has surfaced many gamified financial apps. While some of them seem like glorified calculators, apps like BankUp, Buying Happiness and MOOLAH certainly illustrate the power of gamification to alter consumer behavior. 

I agree that "Banking, in itself, is something that no person wants to do.  It’s tedious and for most people quite stressful." To that extent, gamification of banking products and services seems to be the right way to go. 

However, it might face the same challenge as bank-sponsored PFMs have viz. reluctance of customers to divulge to one bank (the game- or PFM-sponsoring one) details of their overall financial holdings across multiple banks (e.g. checking accounts, term deposits), financial institutions (e.g. mutual funds) and insurance companies (e.g. life insurance). IMO, the key is to select the appropriate scope of coverage for a gamified offering that sidesteps this challenge. 

On a lighter note, banks adopting gamification would have to do something to ensure that customers don't make the transition from "gamification of banking" to "playing with money" too seamlessly!

Like other industries, superior UX has always been a key imperative for the BFSI sector. However, unlike most other verticals, BFSI is replete with a vast landscape of heterogenous applications, which has posed an inherent limitation on enhancing UX. 

Advances in technology - Web 2.0, RIA, HTML5, and so on - certainly help enhance UX of individual applications. For example, I know of a large bank's Trade Finance System, which was very rich and responsive in its client-server avatar. The bank couldn't migrate this application to the web during the days of Web 1.0, which wasn't sufficiently rich and responsive. However, it successfully undertook this migration when RIA / AJAX platforms came along.

However, when we take systems that need to interact bidirectionally with a plethora of existing systems ranging from mainframe to Web 2.0 (e.g. Global Liquidity Management), can you throw some light on what technology - or set of technologies - are available to enhance their UX?

And this wasn't possible using WebEx, Go To Meeting and literally scores of other web conferencing solutions that have been around for 10+ years? Before ASB Bank / FaceMe point to "without the need for downloading additional software" as the secret sauce of their system, they'd have to pardon my skepticism: Many vendors have made the same claim in the past. But, when the rubber hits the road just minutes before the conference is due to start, they all ask you to install a "plugin", "framework" or something else that's not "software" to them but, to you, they're no different.

Not sure why the MNO consortium has chosen to rent space on the SIM card and, as Google Wallet found out to its dismay, risk limited adoption by consumers. On the other hand, even when GW moved to the cloud recently to enable consumers to add any card of their choice as the funding mechanism, the need to store one card on the phone hasn't gone away. As we've seen here, this card can't be a credit card earning much higher interchange fees for Google. Makes me wonder if NFC - as against QR code - based mobile wallets face certain fundamental technology / business model constraints viz. (a) Force the payment service provider to store at least one card inside the phone, and (b) Not permit consumers to add their preferred cards to the phone in the non-cloud implementation.

Dumb or not, banking rails for processing card transactions have been the source of a lot of revenues and profits for retail and corporate banks for many decades. With Google making a majority of its revenues and virtually all of its profits from just one product (AdWords), it's hard to believe that it hadn't originally conceived of Google Wallet as a source of additional revenues and profits by simply doing payments. When it became clear that it couldn't bypass banking rails, it appears that Google has chosen to pivot GW as a rich source of consumer data instead of shutting it down for failing to accomplish its primary goal. Only time will tell whether this approach has any legs. Having said that, in the conventional card value chain, no single party among merchants, acquirers and issuers has access to the entire consumer data set. It can't be denied that only mobile wallets own the consumer's identity, SKU-wise purchase qty. and value, and total ticket size. But, this is true for ISIS, PayPal, SQUARE and all mobile wallets, not just GW.

Unlike automobile, furniture or even computer hardware, computer software doesn't suffer from wear-and-tear. In fact, it could be argued that, with progressive bug fixing cycles, software actually becomes more robust with years. So, a 2+ decade old software is not necessarily more prone to failure compared to a brand-new one. Sub-optimal documentation is arguably the culprit for the IT meltdown in RBS and has been a sore point in IT for a long time. With audio-visual content creation tools being available on the cloud, it's finally becoming possible for users and vendors alike to create better quality documentation faster, better and cheaper than ever before. Hopefully, incidents like RBS will prove to be the tipping point in banks - and their technology vendors - placing greater focus on this oft-neglected area and the future won't be as bleak as @Finextra Verdict predicts.

After initial finger-pointing at someone from RBS Chennai, I note that RBS has acknowledged that "the mangled software upgrade was managed and operated by a team based in Edinburgh". At the same time, Hester is right in setting up an "independent investigation" to examine the "the impact on business resilience of any cost saving measures". 

Obama 2008 reputedly used website A/B testing techniques to target donors better. Now, by using Payvia, Obama 2012 seems to be collecting from donors better!

Bill Pay via QR codes printed on bills virtually eliminates all friction associated with online bill payments. This is a great move by NACHA. While the paper talks using QR codes only to set up a biller or a payment, I'm sure this will eventually culminate in 1-tap bill payment.

Okay, TY for the RedLaser clarification.

Yes, I'm familiar with recommendation engines and retargeted ads described by you. But, as far as I know, (a) Their outputs are not called 'digital coupons' and (b) Since retargeted ads use Flash technology, they don't even get displayed properly on mobile web, let alone be capable of being sent to a specific smartphone. Which is why, when I read "digital coupon" and "a tailored offer can be sent directly to a potential customer’s phone...", I assumed it meant email or some other form of communication needing PII.