Community

With products like iPod, iPhone and iOS Passbook app, Apple has proved time and again that it can disrupt the status quo by taking UX to the next level. While SRI is not Apple, it does power Apple Siri. It'd be interesting to watch if Siri++ Lola manages to do a similar thing to the Jenns, Asks, Shaks and Jos deployed as virtual assistants by Alaska Airlines, Yorkshire Business Society and Milton Keyes Council among other websites. 

@KeithA:

Thanks. It's clear that, even under steady state, narrations used by payers is the sole method by which you / a "merchant" can reconcile receipts. That highlights one of the fundamental hurdles to mainstream adoption of ePayments and reinforces my personal view that cheques won't go away in a hurry: While you can impress upon your customers to use full narrations like the ones you've indicated, what happens if some of their banks don't support long enough field lengths for them to be able to do so? I faced exactly this problem when my HSBC UK ePayment form didn't allow me to enter the full narration required by my building management company for rent payment. It was 4-5 years ago but I remember that I had to enter something like "MCS MERIDIAN CLIENT ACCOUNT A62" but all the form allowed me was "MCS MER CLT AC". With such a cryptic reference, I feared that I'd have to spend a lot of time proving to the company that I'd made the payment. As a result, I actually gave up on ePayments in that instance and started using cheques - on the back of which I could write lot more than the minimum transaction details required by the company.

@KeithA:

Thank you for explaining. I was previously under the impression that RBS, by itself, was somehow able to convey to you the payer's name (which seems possible although most banks don't do it) and your invoice # (which did appear a bit magical!). I now understand that, at 'steady state', RBS was merely faithfully conveying to you what each payor had entered in the reference field of their respective e-payment instructions. And, in the present turbulent phase, RBS is not even doing that, and is instead substituting individual payor-entered narrations with a standard wildcard. That's surely a disaster! Best wishes with your reconciliation! One question: Under steady state, if a certain payor(s) had failed to enter any Personally Identifiable Information in their reference field(s), how were you reconciling their receipt(s)?

@KeithA: 

Am I right in concluding that, when all was well, you were actually able to make out your customer's name and your invoice number for all electronic receipts? I've never managed this with any of my banks and I've heard several companies complain that remittance information supplied by most banks is too meager to satisfy the needs of their AR recon systems / people. It may not be the best of times to say this, but it does appears that, until it was hit by its present crisis a week ago, RBS was doing better than many other banks in this department. I'm a bit curious to know what narration RBS uses normally - obviously something other than the wildcard  “RBS TRANS 220612” - that delivers such rich information. You can take your time replying in case you're busy sorting out your "here and now" recon problems.

Agreed - I know one bank in the UK which did the "mother of all business transformations" in the case of SEPA Direct Debit: Retire all internal systems and outsource processing to one of its major competitors!

Even if IT budgets of traditional Tier-1 banks get slashed by 10-20% in these tough times, they'll still have many hundreds of millions to spend. So, they're a far cry from startups, most of whom have to manage with a few millions or even less. Besides, there's enough evidence to support the claim that, when traditional banks implement technology right, they can gain massive business benefits. This is unlike startups where only 2 out of 10 are truly innovative / successful. Therefore, MVP / Lean are almost indispensable for startups whereas tried-and-tested methodologies that are fully compatible with their organizational DNA make more sense for traditional banks. 

Maybe it's only me, but I find it difficult to understand typical mobile P2P payment use cases such as "pay a friend back for lunch" and "dividing a round of drinks between friends". If everyone in a group has an m-wallet, isn't it more natural for each of them to pay their respective tab directly to the restauranteur or bar owner? Why should the current practice of one person paying the whole bill by plastic and claiming back individual shares from the others even arise?

@Jan-OlofB+1.

Not saying that businesses should reconcile themselves to fraud but, as the famous saying goes, "No risk, no gain". End of the day, the Cost of Anti-Fraud Systems + Revenue Loss due to False Positives + Revenue Loss due to Friction-Caused Abandonment shouldn't exceed the Amount of Fraud Prevented.

Good stuff for bulk payments. Does anyone know of something similar for on-demand, one-off payments? With many banks, it's quite cumbersome to set up beneficiaries and initiate instructions separately for each payment method like RTGS and ACH. 

"Lean" and "MVP" are perhaps ideal for startups. I'm sure many nonbanking FSPs already follow them. But, it's not clear if they're fundamentally compatible with the basic DNA of decades-old traditional banks.