Community

There are at least two challenges of mining messages from the entire universe of social media networks: (1) Mind-boggling volume (2) Lack of structure that makes accurate sentiment analysis all but impossible. That explains why there's renewed interest in tools that focus exclusively on Twitter messages and deliver adequate throughput at high accuracy levels.

Most buildings are designed to withstand either an earthquake or a hurricane but not both at the same time. Likewise, I'd think that an FD&P system designed for either the card being compromised or the phone getting lost but not both at the same time, is good enough! I agree that there are risks around using a mobile phone in this context. But in this day and age of using mobile phones for actually making payments, I guess most cardholders will feel safe enough about using them for responding to fraud alerts. 2-way SMS Alerts can be generated only after the transaction is authorized - so there are really no technical issues around holding the transaction. When I'd written "block a fraudulent transaction" in my post, I meant that the transaction will not be settled even though it has been authorized. But, that's a matter of detail since it makes no difference to a cardholder who has effectively been insulated from a fraudulent transaction.

Guards from Switzerland. Now, a cards processor from Switzerland. Maybe it's time the EU accepted that 'what happens in Vatican stays in Vatican'! 

Agreed but when they're combined with 2-way SMS Alerts of the type I'd described in this Finextra post, FD&P systems can go a long way from their present approach, which is largely to "throw the baby out with the bath water". I also think that half the challenge with lowering false-positives arises out of poor problem definitionL Even in this day and age of online shopping, we keep hearing flawed examples of fraud like "John Doe was in City A, his card was charged in City B". Isn't it high time that all concerned stakeholders came to terms with how Card-Not-Present transactions work? 

Many articles on B2B eInvoicing would make one believe that that buyers are just waiting to make payments but are delayed in doing so only because of the inefficiencies caused by paper invoices submitted by suppliers. Kudos for pointing out that "...no efficiency (gains) can be achieved by moving from manual to electronic". With their reliance on passwords, incompatibility with multilevel payment authorization procedures followed by most businesses, and so on, it's debatable whether eInvoices even make the end-to-end procure-to-pay process more efficient.

With the repealing of the "no surcharge" rule post Frank-Dodd-Durbin Amendment, US retailers are permitted to levy surcharge for accepting credit card payments. According to recent news reports, some of them are actually planning to do so. This will likely result in increased use of cash for retail payments even in an economy like the USA that has traditionally seen widespread use of credit cards.

In India, banks and / or retailers are also partially to blame for potentially boosting the use of cash by steadily lowering the redemption value of credit card rewards. Just to cite my personal experience, five years ago, 1000 reward points from a leading bank used to get me a gift voucher of close to INR 700 from a leading retailer. Today, the same 1000 points from the same bank gets me only INR 100 from the same retailer. In the past, just for the sake of convenience, I used to pay by credit card even when the merchant levied a 1.5-2% surcharge. Today, with a near 7X drop in redemption value, I strictly pay by cash whenever a merchant levies surcharge for credit card payments.

@KyleT: Internet Banking, Mobile Banking, eTrading - Applications like these, and many more, have been around for ages and involve wrappers around legacy systems. Keen to know if you've any other type of wrapper in mind.

To continue with the railway analogy, the light at the end of the tunnel is perhaps yet another train. Compared to realtime systems like FPS and TARGET2, SEPA should be child's play. Having worked with a payments vendor that enabled a Top 5 UK Bank go live on SCT on the first deadline in Jan. 2008, I'm sure that technical solutions for SEPA have been around for several years now. Relatively poor offtake of SEPA is likely the result of the lack of business case for a system designed around cross-border EURO payments against a reality where over 80% of payments traffic is still domestic. Not surprisingly, the aforementioned Top 5 UK Bank, which was an SCT leader in 2008, opted to outsource SDD to another bank. 

One thing I always hope to see in articles like these is what I call the "perfection requirement" that banks are uniquely subject to. Before shipping a car, the auto manufacturer can inspect all the units coming out of the shop floor, conduct QC, reject the subpar quality cars and prevent them from going out the door. This luxury is available to almost all industries except banking where high transaction speed precludes any inline QC. Despite that, when they work, most banking systems deliver 100% accurate results. This poses a very different pressure on maintenance of existing banking systems that few other industries face and perhaps makes it inevitable for banks to spend so much of their IT budgets on RTB activities.

From anecdotal evidence about and personal experience with overzealous fraud detection and prevention systems, let me add "minimization - if not elimination - of false positives" as another ingredient of a great FD&P system. Above all, the system and its practitioners shouldn't forget that any business has to take calculated risks and exists only to enable, not block, transactions.