Community

Finally HSBC UK does it!

HSBC India issued RSA tokens for One Time Password (OTP) generation for Internet Banking access more than six years ago. I didn't have to visit the branch to collect the token which came to my home address by post. It got activated upon first use. Losing the token, battery running dry and all other standard concerns around this technology have somehow spared me so far, and I've been a satisfied user of this security method. 

Around four years ago, I visited the HSBC branch in Canary Wharf to open a bank a/c. After finishing the entry of the basic particulars into her PC, the manager who was doing this on my behalf asked me to come over to her side of the table and enter a static password for Internet Banking access on her computer.  

Given my elegant, self-service experience with HSBC India, I was surprised to come across a somewhat old-fashioned process in HSBC UK - and that too at the branch right below its global HQ!

When I pointed this out, the manager admitted that, unfortunately, all system enhancements in UK were put on hold pending a multi-year core replacement. Looks like this has finally happened!

This experience taught me a lot about how legacy systems stymie progress in one part of a bank whereas their absence infuses agility into its other parts, however remote they may be from the headquarters.  

Props to Mitek Systems for coming up with yet another innovative product based on its patented mobile phone scanning technology. If it works as promised - I couldn't spot it on the App Store, so can't comment first hand - Mobile ACH Enrollment will eliminate a key source of friction in the ACH enrollment process.

However, unlike its other products related to Receipts, Fax, and Bill Payment, Mitek might face a couple of challenges with Mobile ACH Enrollment:

(1) As it is, consumers in the US might be wary of divulging their bank account details with mobile payments companies, many of whom are startups. How willing will they be to share it with another party like Mitek Systems? (It's far more common to give out bank a/c details in Europe, but checks from which to scan a/c # and sort code are rare there!)

(2) An average American might need to enroll not more than 1-3 bank accounts with not more than 2-3 mobile payments providers. That means this product will be used for a maximum of 2 to 9 occasions through the user's whole lifetime. Does such light usage justify the trouble of downloading and installing yet another app - even assuming it's free?

How well Mitek Systems surmounts these challenges will determine the adoption of Mobile ACH Enrollment.

@Anonymous of 03/03/2011 12:15:46:

Answer: Sorry, I meant Matt White.

PS: I'll take this as another example of how the newly-turned "anonymous" Finextra "specialized walled garden" community can foster expert and prolific Q&A! 

@Mark:

Am glad to hear that Finextra intends to stay focused on an industry and be selective about its membership profile. It struck me that, by adding "anonymity" to its intrinsic nature of being a "specialized walled-garden", Finextra may not only end up enriching its blogging platform but also be in a position to germinate a value-added Q&A property for the fintech industry - somewhat akin to Quora for the startup / VC industry.

Having just watched a Gartner+SmartStream Sponsored Video webcast on Finextra about Intraday Liquidity Management, the first question that came to my mind was "Can treasurers in the Finextra community share their experiences of live implementations of intraday liquidity management technology solutions?"

The specialized nature of the Finextra community will guarantee quality of responses, and the new ability to submit them anonymously will ensure that there are enough responses to the make the Q&A thread interesting. 

Is this the first step towards eventually opening up Finextra to unregistered comments? Something that many blogs do probably to add SEO juice and gain a few positions on search engine results.  

@John: Although I'd commented on a different Finextra item today seeking more details of the withdrawal process, I hadn't dreamt of such a diabolical scenario as you've outlined. Good catch! But hope it doesn't come true. 

While the article doesn't explicitly say so, I'm assuming it refers to cross-border money transfer, since domestic transfers via credit cards have been in vogue in many countries (including India) for a few years now.

It would be instructive to get more details around the "last mile" and security of the transaction: Can the receiver opt to keep the received funds in his/her credit card account forever and offset it against other spends on the card? If not, how does s/he transfer it to their bank accounts? Hopefully the receiver needs to only divulge his/her credit card number to the sender, for few will be comfortable disclosing Name on Card, Expiry Date and CVV?

Without debating about the merits and demerits of EMV - and I believe there are plenty of them - I wanted to touch upon the subject of business case for the typical American merchant who seems to be getting pushed in several directions to deploy Contactless, EMV and several other new technologies. Maybe there could a quid pro quo built into Durbin Amendment and other proposed regulation to reduce interchange fees in return for EMV / NFC deployment?

Last year, I received my IT refund from HMRC by electronic transfer to my bank account. It reached me by BACS and not FPS, for which I've to blame my bank for not having enabled FPS-reachability on the said sort code. At the time, I'd blogged about how we sometimes rush to blame the government for errors of omission and commission caused by others. 

At the same time, I think HMRC still uses only snail-mail for all communications involving Personally Identifiable Information (PII). Does appear a bit uncool under the circumstances.

Since the subject of promoting FPS has cropped up, I've contributed a few comments to another Finextra post in this subject and, coming to think of it, I'm not sure if the man on the street really needs any more promotion or education about backbone payment methods.

IMO, the best service that banks can provide to their customers is to make the whole backbone transparent: Simply ask the payer to provide the amount, and the beneficiary bank details, then use an automated engine to work out the various options available for putting through the given payment at the given time based on reachability, hours of operations, and any other considerations viz. 3 days at GBP 0 (BACS) OR 2 hours at GBP 5 (FPS) OR Instantly at GBP 35 (CHAPS). The customer should be asked to simply choose the option that best meets her timescale / cost considerations. The present method of asking the customer to select a payment method, then add payee valid only for that payment method, select another payment method, add the same payee again, etc. etc. is fraught with too much friction, and I wonder if any amount of promotion / education will bolster adoption of FPS (or ePayments in general) significantly. 

By making a comparison with checks, NRF raises a valid point in questioning why debit card payments should attract 1-2% transaction processing fees. 

However, I wonder how NRF plans to respond to the 30-40% fees that merchants have to cough up in the case of "GenY Mobile" Payments (ex: Boku, Zong) and "Walled Garden" Payments (ex: Apple AppStore).