Community

ICICI Bank has pushed the envelope on technology adoption, as I'd written in this and this Finextra blog post. But half its Facebook App revolves around cheque books and such 'old-age' products and the other half certainly doesn't permit P2P payments via FB. AmEx Serve's claim to uniqueness with such an offering faces no challenge from ICICI Bank! As for PayPal, I'd be happy to learn more from people who've actually tried it.

While I've always maintained that there's a huge need for banks to reduce the friction involved in their current crop of ePayment products, I've never felt that they could be disintermediated in this space by the likes of Google, Facebook or PayPal. Looks like the first purported challenger has withdrawn and the second one is urging caution. The regulatory ax has already come down on the third in India and I hope it's just a matter of time before it will be cut down to size in its primary markets like USA. I'd recently commented on Finextra that there's a difference between payments and shipping a parcel or booking a plane ticket. This announcement ought to make people realize that, while Internet Search is hard, payments isn't easy either. 

When Alliance Lite was launched in 2008, I distinctly remember reading that no hardware was required at customer premise except USB token. At the time, I used to work for a company that was - and still is - involved in selling conventional SWIFT-connectivity solutions that demanded lot more hardware and software than Alliance Lite, so I'd followed the 2008 announcement keenly. The second paragraph of this article describing the 2008 version also mentions no other hardware than USB token. I wonder if this new version is simply an attempt by SWIFT to jump into the "cloud" bandwagon. If yes, that'd be a pity: The very first time I'd heard about SWIFT some 25 years ago, it sounded as cloud-based as anything else does today, just that access to the cloud happened via dedicated leased lines rather than Internet. 

@JimM:

Interesting post. I'm not sure how Cardlytics and others will address another seemingly important factor, namely, relevance of offers with respect to the point of purchase intent ("time relevance"). 

For example, I might've spent $10 at McDonald's last month but I'm likely to respond favorably to an offer from Burger King only when I want a burger - that is, only when the Burger King offer has time relevance to me. When I do want a burger - at the point of having purchase intent - I'm more likely to Google for 'burger deliveries' and click on one of the organic or inorganic results / ads than remember seeing an offer from Burger King the last time I'd logged on to my Interenet Banking portal to (say) view my last five transactions. 

It's no secret that offers from GroupOn virtually belong to the much-maligned "spray and pray" category. But, by making heavy use of Google AdWords and other techniques, GroupOn's offers get displayed as online ads just as people signal their purchase intent by searching for something. GroupOn's high degree of time relevance might be contributing to its runaway success despite all forms of questions being raised about its business model. 

With Cardlytics and others, since their offers are personalized, they can only be shown inside 'walled gardens'. This makes them invisible on search results and takes away an important tool for them to become time relevant. Can they manage to add time relevance to their offers some other way? Or, will their offers' razor-sharp nature overcome their lack of time relevance? I'd love to hear your thoughts.

@Keith R:

Thank you for your point-wise reply. 

I meant hard-copy versions when I said that eBills / eStatements are not getting accepted for KYC. Using soft copies is a total non-starter. At least in India, while submitting copies of Proof of Identity, Proof of Address and other KYC documents, we often need to show originals of documents for verification (although we get to take them back after the verification is done). eBills / eStatements printed on black-and-white printers simply don't work! I remember a similar procedure in UK as well a couple of years ago, although things could've changed since then. 

I agree with you that addition of graphs, downloadable data file, etc., can fuel paper turn-off. However, when it comes to payments, 1-click mobile payments enabled by scanning QR codes printed on printed bills is very appealing. I believe this technology will disrupt web-based payments in the coming years, just as the latter began to disrupt brick-and-mortar payments around 5-10 years ago. Of course, such a solution can equally well be implemented on eBills also with minor modifications.

Thanks for pointing out Adobe Acrobat X - although I've come across Nuance and ABBY supporting highlighting and annotation features, I never knew about this new version of Acrobat Reader. I've already installed it and I agree that it solves one major area of friction related to highlighting and annotation.

I'm glad we're making progress, getting rid of one friction at a time!    

ROI calculations are inevitably based on the assumption that recipients of eBills / eStatements initiate "paper turn-off". From personal experience as well as from analyst reports, I know that this assumption is far from true. The percentage of people insisting on both printed bills / statements and eBills / eStatements - so-called "double-dipping" - is quite high.

eBills / eStatements still pose a lot of friction for the customer viz. (a) Insistence by some billers on passwords to open eBills / eStatements where recipient has no control over the password (in such cases, I prefer to "pull" / view eStatements when I use Internet / Mobile Banking for other reasons) (b) eStatements are not accepted as proof documents for KYC purposes (c) Inability to mark and annotate eStatements; etc.

Until a combination of business processes and technology eliminates these areas of friction, "double dipping" is bound to undermine the ROI of eBilling / eStatements technology. More details can be found on my following Finextra post and comments.

Offermatic and Cardlytics are two companies that already offer technology that enable "highly personalized offers". Offermatic is targeted at consumers and Cardlytics, at banks. Both use credit card transaction history as the primary source of spend information for creating highly-personalized offers. According to reports, the offer service recently launched by BofA uses Cardlytics. We don't have any interest in either Offermatic or Cardlytics.

However, we do have an interest in another company that offers similar technology. To comply with Finextra Community Guidelines, we won't name names nor say much more about this technology except to share our experience of pitching it to banks. We're doing this solely in response to Christoper Mc Carthy's aforementioned question,, "...why aren't more banks doing this...?".

Most banks see huge benefits with "highly personalized offers". However, a common objection we hear from them is, "We've just invested in creating a separate offers Portal / Facebook page / Twitter account. We'd like to gauge the market response before we can consider any further investments in this space." Banks readily appreciate that the type of offers we're talking about here can deliver much higher conversions than their traditional "spray and pray" style of offers. However, their "wait and watch" approach is not unjustified.

GroupOn has recently announced "Personalized Offers". Banks lack line-item spend data (e.g. My credit card  issuer knows that I spent $58 at Target last month, but it doesn't know it comprised of $10 for milk, $12 for pizza and $36 for a shirt), which severely blunts their purported ability to craft highly personalized offers. A quick glance at the sample offers displayed on Cardlytics' website will reinforce this point. At most, they can do it using spend information only from single category merchants (e.g. $58 spent at FootLocker means $58 spent on the single product category of 'shoes and sportswear'). Therefore, I'm not so sure that even the most agile among banks can outperform GroupOn and other startups in offers. 

Do we know if merchants need to sign up separately for a merchant account with an acquirer in the case of mPowa and iZettle or, like it is with Square, they can get to operate under the payment provider's "master" merchant account?

As I'd pointed out in my comment to a previous Finextra post, mPowa's fee structure a month ago made it appear as though merchants do need to sign up separately whereas iZettle's fee structure suggests that they don't. Assuming the same situation continues, iZettle addresses a major pain area for merchants.  

Payment providers are subject to regulations about whether they can sell a payment product to a certain Person A who wishes to send money to another Person B. Airlines and courier companies are largely free of such legal obligations. Therefore, much as a consumer might love to see payments become as simple as booking a flight ticket or shipping a parcel, I doubt if it would ever happen. 

Our experience has been exactly the opposite! Vendors are keen to embrace incoming ePayments. But, for one or more of the following reasons, payers are reluctant to give up making payments to vendors by checks: (a) Resistance to adopt ePayments technologies (b) Friction in ePayments (c) Loss of float with ePayments.