Community

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. 

For both developed and developing markets, in their present form of being just another channel of accessing bank accounts, most mobile payments have compelling reason to adopt only if  (a) People have enough money (b) But can't find enough banks to park their money, and (c) The local regulator permits non-banks to enter the mobile payments business.

With the exception of Nigeria, Kenya and a few countries in Africa, the confluence of these factors doesn't seem to be happening anywhere else in the world. In developed markets, (a) and (c) might be applicable but (b) is not. In developing markets, roughly the reverse is true. 

No wonder mobile money has such low adoption rates in developed and developing markets alike.

While any cash-substitute transaction initiated via a mobile phone can be treated as "mobile money", it might be reasonable to associate the term "true mobile money" only to payment methods that run end-to-end on mobile networks and entirely bypass traditional card and banking rails. While Boku, Zong and other GenY Mobile Payments fit the "true mobile money" billing, Barclays' PingIt certainly doesn't, and never will, since it uses the FPS rails, which is an interbank payment network.  

Furthermore, the current version of PingIt reportedly only works if the sender and receiver are both Barclays account holders. Even future versions are expected to permit payments between people who have an account in some bank - Barclays or otherwise - that is connected to FPS. So, "non-customers"  are unlikely to be covered by PingIt - now or ever.

The way I see it, PingIt uses the mobile phone as another form factor to make interbank payments. However, while doing so, it eliminates the friction of having to enter over 100 keystrokes by way of beneficiary name, bank name, account # and sort code. Simply enter the recipient's mobile phone #, hit submit and the payment's made - in that lies PingIt's basic allure for the consumer. It might be tempting to view PingIt more expansively as "true mobile money", "financial services to the unbanked", etc. However - and I'm saying this without intending to take away any credit from Barclays for blazing this trail - such usage scenarios are outside the purview of PingIt.

Props to VocaLink. Hopefully, the new payment app will not restrict sending of payments to those who have pre-registered for the service and will follow the PayPal strategy. As many readers might recall, when PayPal launched its ePayment service over a decade ago, it went viral by not insisting that recipients must be pre-registered with PayPal. It rightly surmised that, once they receive a "you've got money" type of message, most recipients would be far more eager to sign up for the service than signing up in advance without knowing whether they'd ever get money into their account or not. IMHO, by insisting that both sender and receiver must be pre-registered for PingIt, Barclays is missing out on the opportunity to accelerate adoption.  

@SimonJ:

Thank you for taking your time out and providing a brilliant explanation for this apparent quandary around passwords for eBills. I can easily understand the risk of my eBill going to someone else because the Biller has got my email address wrong. However, IMHO database glitch is not the only cause of this. Anyway, after hearing all this, I'm led to wonder even more about whether email is a suitable medium for bills and statements except for the nomadic set.

@SimonJ:

Nice article. Wanted to check your views around passwords used in eBills. Would customer's preference for / against passwords be a valid candidate for inclusion into the preference center / table? Or, would that be dictated more by regulatory factors? As I've pointed out in the following Finextra post, I personally hate passwords. Since my eBillers don't offer me a choice to receive eBills without them - or to change the password to one of my choice - I'm left with no recourse but to insist on printed bills.

https://www.finextra.com/blogs/fullblog.aspx?blogid=6106   

@BrettK: 

I share your suspicion. However, I won't blame banks totally for their stance for they face compliance challenges with KYC and social media. Of course, technologies - like Actiance Socialite about which I'd posted a blog on Finextra last year - are already available to overcome such challenges. But, when business case, ROI and other matters enter the picture, the scene does become quite hazy!

https://www.finextra.com/blogs/fullblog.aspx?blogid=5241

Furthermore, take the case of a random non-customer who has nothing else to do or is engaged by a competitor. Suppose they start posting negative comments - which can even be sacrilegious lies - on a bank's FB Wall. Surely a bank cannot treat such comments as an occasion to conduct dialog? Depending upon the situation, the bank might not even be able to justify the efforts of rebutting each such comment. Shouldn't the bank have some recourse in such cases - if not to delete such comments, at least to block such people from posting on its Wall?