Community

Our HEATMAP360 application provides realtime sentiments extracted from tweets and can be used to safeguard reputation although it doesn't do any event detection or prediction and is of not much use toward market surveillance and online retail banking and brokerage.

IMHO, it's not as though banks don't want to embrace innovation, it's just that they take so much time that it's almost obsolete by that time, raising questions whether they should be adopting it at all now that it's almost obsolete. Their snail's pace at adopting innovation is understandable because innovation causes change, which somewhat goes against the need for constancy and trust that's part of the  overall image they need to maintain with their customers.  

At the same time, it would be wrong to conclude that they never change: For every leading bank still on the Central Line, there's one you'd need to take the Jubilee Line or DLR to visit in recent years!

A couple of years ago, I was very impressed with Mint's value proposition and decided to register myself for it. I stopped right in my tracks when I realized that I had to hand over the logon credentials to all my Internet Banking accounts if I were to get any useful advice from Mint. By sharing my credentials, my thinking went at the time, not only would I be ignoring my banks' constant advice to never share passwords and other confidential information with anyone, but also be putting a lot of faith on a startup to safeguard all that data from hackers. Rudder's data loss example proves that it's really asking a startup for too much in an area where even leading banks and payments processors can't boast of a stellar track record.

First Kublax, then WeSabe, and now, Rudder - their failures don't bode too well for the prospects of the scores of other PFMs out there.

Wonder if Google suddenly realized that PayPal has added more and more functionality to its platform without making much noise - like I did when when I was recently trying to enable my company GTM360's website to accept credit card payments - and decided on a "if you can't beat 'em, join 'em" approach. 

From my past knowledge of PayPal, for a merchant to accept PayPal always meant that the payer had to have a PayPal account, which obviously limits its adoption. Only during my recent exercise did I learn that this is not the case. When I heard this, I stopped my search for a suitable merchant account provider and opted for PayPal instead. While PayPal might be costlier and provide less than exemplary service, it was an easy choice to make. If my behavior is representative of the average consumer's, it surely makes it that much more difficult for PayPal's competitors to make much headway against it.    

If they became as simple as writing a cheque, e-payments will automatically see a lot more adoption by the man on the street - there's no need for any government subsidies.

When many EU governments - Social Security in Germany, HM Revenue in the UK, to name a few - insist on using snail-mail for any letter that contains Personally Identificable Information (PII), I don't see why I should be slapped a penalty if I don't want to accept bills and invoices electronically.  

SEPA for cross-border is fine. But, I hope regulators seriously rethink their plans to mandate SEPA for domestic payments. There's already talk of making UK's Faster Payments available on mobile phones in a simplified manner in which Immediate Mobile Payments can be made using just the mobile number of the beneficiary. In this day and age, isn't it a bit retrograde to ask consumers to move from the already tedious 10-12 digit account numbers and 6-8 digit sort codes to an even more cumbersome SEPA regime that asks them to enter 20+ character IBAN numbers and 8+ character BIC codes for domestic payments?

Ironic as it might sound in the backdrop of all the chatter from banks about the adverse impact of regulation, the fact is retail banks are being protected from disintermediation by regulation - at least in India.

In the case of Nokia Money in India, fact is banks - or a specific one called YES Bank - is an integral part of the process flow. No YES Bank, no Nokia Money - it's as simple as that. According to India's banking regulator, at least one of the two parties in a Nokia Money transaction - sender or receiver - must have a YES Bank account, for non-banks are barred by law from taking deposits in India.

It could be argued that such regulation is stifling innovation, but the fact is, they're protecting disintermediation of banks from the retail banking market. It could be predicted that regulators in emerging countries will become more liberal over time, which would accelerate the disintermediation of banks. That's somewhat unlikely because most of them are publicly applauded for insulating their economies from the Great Recession by following conservative policies.

Hope this outsourcing service from SWIFT is mindful of non-English names containing acute, grav, umlaut and other accent symbols, and provides not only an original version of the name that retains the accent symbol but also a pure-English equivalent wherein the accents are substituted with their correct alternatives. For example, it should list Mu(umlaut)ller in the original German form and the pure-English equivalent of Mueller. If this crucial step is left outside the scope of the outsourcing system, banks having systems with English-only capabilities will tend to omit the umlaut symbol altogether, thus incorrectly converting the name to Muller, which could result in a True Negative (posing compliance risks) or a False Positive (leading to lost revenue and customer dissatisfaction).

Given that IBAN+BIC required for SEPA contains more than twice the number of characters when compared to BBAN+SortCode required under legacy systems, it appears that SEPA for domestic payments would entail an explosion in field lengths of bank account related fields. It would be interesting to know if this study contains any data around the field lengths currently supported by typical corporate payment processing applications. If they are not easily extensible to the larger sizes demanded by SEPA, we could be looking at a migration exercise that could rival Y2K in its scope and cost.

I agree with much of what Keith says. At the same time, virtually all issues applicable to SEPA were equally well applicable to EURO and yet so many countries adopted the single currency. I think what's principally different with SEPA is the added complexity - ex: such a long IBAN account number - which poses almost-insurmountable hurdles to its everyday use for local payments.