Community

Kudos to FNB for launching this feature. At first glance, the usage scenario does appear bizarre. However, we see so many blog posts and comments on Finextra that would seem to suggest that banks are very slow to innovate even when the use case is very powerful. Against that backdrop, if a bank has taken action, I'd give it the benefit of doubt as regards the relevance of the  usage scenario.  

Even assuming that the PIN is only 4 digit and that no other information is required to be entered, the chances of an urchin helping himself to someone else's money are quite slim, as the following calculation would show: 

4 digit => 9,999 combinations

Assuming it would take an urchin at least 5 seconds per PIN attempt, he'd get thru' 360 attempts (1800/5) in 30 minutes (1800 seconds). 

Probability of one of these attempts being right = 360 / 9999 = 0.036 i.e. 3.6%.

Besides, unlike in developed countries where they're literally "holes in the wall" (ex: the ATM in South Quay tube station in London), ATMs in Africa, India and most other emerging markets are placed in well-guarded premises, leaving very little scope for an urchin to even be permitted to enter the ATM room, let alone use an ATM for 30 minutes at a stretch. Even if that happens, the people in the queue behind the urchin are highly unlikely to permit a single person to hog the ATM for 30 minutes. So, unauthorized withdrawals shouldn't be a major concern.

Cross border small business payments is an area where banks could really add a lot of value. More than being a tool to complete a transaction, payments could actually make or break a transaction, especially when it comes to low value high volume products and services. With regulators in certain parts of the world (ex: India) clipping the wings of PayPal and other alternative payment providers - for all the right reasons IMO - this is an area that offers an excellent opportunity for transaction banking businesses of banks to step in and acquire a new revenue stream. 

As far as I remember PSD directives around Mandate Management of SEPA Direct Debit, every SDD transaction MUST be accompanied by an invoice - whether paper-based or electronic. So, I really don't see Direct Debit and eInvoice as mutually exclusive. 

SMS doesn't automatically mean one-way interactions, as ClairMail bi-directional SMS Alerts have shown. Personally, I find their SMS-based offerings across Account Management, Fraud and Payments to be one of the most pragmatic and appealing mobile banking offerings in the market today. ClairMail's recognition by analysts, mass adoption by banks and consumers alike, and, above all, phenomenal revenue growth even during the Great Recession perhaps suggests that I'm not alone in my belief.

Although the website has a contemporary look-and-feel, I got a bit perplexed when I saw a page (http://www.bankwest.com.au/forms) full of forms to be downloaded and snail-mailed to the given address.  

A quick chat session confirmed that the portal did not support online issuance of any product - they need a branch visit to apparently verify the applican't identity. They don't seem to be using one of the online identity verification web services available in Australia. I'm not sure if they've even drawn enough inspiration from their local banking competitors, let alone online shopping portals! 

The harsh reality for a corporate, as Phil A points out, is this: checks are free, ePayments are often not. So, justifying a migration solely on the basis of issues around the process end-point - i.e. instrument - will likely remain challenging. At the same time, the end-to-end order-to-cash and procure-to-pay processes stand to derive several collateral benefits from a migration to ePayments. Besides, as someone from Intuit recently said during the launch of its Intuit Payment Network, it might be more effective to focus the solution on the guy who gets paid (i.e. supplier) since s/he's likely to be far more enthusiastic about it than the guy who pays (i.e. buyer)! 

The Indian example suggests that it often takes a regulator to make banks cooperate for the benefit of the customer. Previously, home bank ATM cash withdrawals were free but alien bank ones attracted INR 25 (around 0.6 US$) fee. RBI, the banking regulator of India, stepped in a few months ago and stipulated that the latter should be free as well (to customers), with the cost being recovered by the alien bank from the home bank. Of course, it's another question whether and when regulators should intervene... 

The findings of this study resonate well with the ground reality found in many banking software development and testing engagements. Vendors think it's the bank's responsibility to mask customer information before handing it over to them (i.e. vendors) whereas this study raises an interesting point about the responsibility for masking data lying with vendors. Tight deadlines, ignorance of this issue among project staff, and other contributing factors will likely continue, as will the non-involvement of non-project experts. Looks like a viable solution to the problem is unlikely to come from inside banks or vendors. 

As a previous thread of Finextra blogs and comments pointed out, there's a lot of opaqueness around how the beneficiary will be able to utilize the funds received on their Visa card a/c - viz. pay down future debit balances, transfer to bank a/c, withdraw as cash, and so on, and the charges for doing so. Hope FiServ / CashEdge throw some light. 

If payment will happen only later in the year, it's only logical that the credit card should be valid at the time. How else will the card issuer collect the money in case the card isn't renewed? Wonder why the payment can't be taken out right away from the credit card account - after all, that's the same as asking people to use the alternative mode of prepaid card.

Not sure if I'm missing anything but, to me, this sounds more like a cross-selling campaign for Visa Prepaid rather than a processing glitch in credit card!