Community

As you rightly point out, banks and FIs are severely limiting the potential of the mobile channel by treating it as just another form factor for online banking. While this notion isn't wrong, it misses the fact that a smartphone comes with camera, GPS, accelerometer, navigation and many other features that PCs don't. These accessories enable mobile to support several compelling use cases, which are outside the purview of PC-based online banking viz. Mobile RDC, Turn-by-Turn Navigation (even if it's for doing uncool things like visiting a branch and depositing a check!), Tap-to-Pay, and so on.

Maybe she was so much better at fraud detection, which caught her own fraud...

TY for clarifying. I hadn't thought of outsourced payment execution solutions. Can you cite a few opex-only, zero-capex solutions?

Impressive as these figures are, they only account for the "benefit" of migrating from checks to ePayments. Unless I'm missing something, there are no figures for migration "costs" in terms of new software, changes to existing software, ACH charges, manpower retraining, etc. Since ROI = (Benefit-Cost)/Cost*100%, how can we infer anything about ROI in the absence of cost? On the other hand, I know of a midsized online university in the USA which carried out a detailed business case for migrating from checks to ACH and gave up on the migration when the payback period worked out to over 8 years.

When banks' own employees can get duped by phishing attacks, merely educating their customers to watch out for dodgy emails and URLs is not going to work in this day and age, as I'd pointed out here. Thankfully, technology is available to solve this problem reliably, cost-effectively and, most importantly, without "false positives".

As I recall, SCT went live with ISO20022 a couple of months before UKFP did on ISO8583. So, ISO20022 was fit for purpose for a high-volume payment system even back in 2008. But, SCT was a T+1 system. Four years later, the situation could be different, but this backdrop makes me wonder if the richness of ISO20022 somehow imposes high processing overheads, thereby ruling it out as the format of choice for near / real time payment systems. 

I've generally thought of mobile payments to be a solution chasing a problem. By pointing out its "auto authentication" capability, you've highlighted a very different - and valuable - side of mobile payments. Props for doing that!

However, I've a feeling that only the mobile POS use case of mobile payments - a la SQUARE and iZettle - can provide EMV-equivalent authentication. In the mobile wallet use case, 'who you are' (i.e. IMEI #) and 'what you have' (i.e. card details) both reside on a single device (i.e. smartphone). The loss of this device can pose a far bigger security hazard than losing an EMV card where only the cardholder knows the PIN (this assumes that smartphone users generally don't set a lockscreen password). 

Even in the first use case (mobile POS), you've pointed out correctly that EMV only enjoys the support of four companies. But, the problem is, these four companies enjoy the status of judge + jury + executioner when it comes to the card rails. So, as long as mobile POS services use card rails, their providers will forever be at the mercy of these four companies. Haven't we already seen a glimpse of their hegemony when Visa banned iZettle from accepting Visa cards (if I'm not mistaken, for violating EMV device connection rules)?

On the one hand, real estate and employee costs are compelling banks to pare down their branch network. On the other hand, branches will remain relevant even for mundane transactions, for reasons I'd pointed out here. HSBC's innovative move should help resolve the conundrum banks face as regards their branch channel.

Not sure about the message format but the ACH and RTGS in India both run on the same rails. All differentiation in terms of settlement cycles, delivery time, fees and frontends happen outside the rails. Some banks use up the full T+2d SLA for delivery whereas others provide instant credit for NEFT. At the time the ePayment system was commissioned some 8-10 years ago, some questioned the service provider's judgement of using common rails for ACH and RTGS, which seemed to neglect certain basic differences between the two systems. Articles like this and the drift of CHAPS volumes to FPS in the UK vindicate the Indian ePayment architecture, even if only upon hindsight.

Nice post. In most cases, the gain from the nefarious activity far exceeds the punishment. While reporting the measly $M fine handed over to a leading US food company for price-fixing in a series of transactions that netted the company $$$M, the FORTUNE magazine commented, "This not only proves that crime does pay, but it's also just the cost of doing business". For once, we've a situation where the penalty exceeds the gain - i.e. avoiding the investment required to prevent it! Just thought of adding that Network Access Control (NAC) technology is especially suited for detecting and preventing security breaches committed by those "inside the firewall" i.e. employees.