Community

Cash or Currency involve physical exchange. Money is a legal tender of exchange and is involved even when the exchange happens electronically e.g. Money Transfer Operator, Fund Transfer, etc. 

Far as I know, M3 is updated at country / city level when currency notes move from one country / city to another.

The problem with "checking account", "mobile payments" and other popular terms is that, well, they're popular! Even if they might appear ill-defined in hindsight, they're so well entrenched in the popular lexicon that individual service providers might find it unviable to correct their definitions. Even the mighty Facebook had to reconcile itself with this harsh reality recently: Explaining its rationale for shutting down "Facebook Credits", Facebook admitted that people have such deeply entrenched notions about the term "money" that it wasn't worth its while to try and educate them about an alternative medium of exchange called "Facebook Credits".

Open-loop mobile payments like Google Wallet and M-PESA use banking or MNO rails, both of which already enjoy reasonable amount of trust of the average consumer. If we take closed-loop mobile payments, only consumers who trust the merchant's basic product (e.g. Coffee) will even visit the store and try out the merchant's mobile payment product (e.g. Starbucks Prepaid Card). Trust is a given under this situation. Against this backdrop, unless "trust" and "security" are used interchangeably, I don't know what more trust mobile payments need to cultivate with consumers. (I accept that trust is a far more important issue in a merchant's acceptance of a certain payment method versus another e.g. If PayPal keeps freezing a merchant's account for no apparent reason, I expect that merchant to lose trust in PayPal and refuse to sign up for accepting its PayPal Here mobile payment product. But, I'm unable to link this context of trust with secure element or secure identity). 

Even leaving aside "soft" issues like perception, consumer behavior and communication strategy, the fundamental point is this: Any given entity can have different representations under different frames of references. This doesn't make one of those representations wrong. A mobile payment does result in increments and decrements of a certain number at the database level but it undeniably involves transfer of what everybody accepts as money / consideration in the real-world level. I see a place for both representations of mobile payments, depending on the frame of reference used in a given context. As a matter of fact, even banknotes are numbers in a central bank's money supply ("M3") databases. If I were to stuff some currency notes in an envelope and send it to someone, there's a decrement in one M3 database and an increment in another M3 database. This doesn't take away the fact that banknotes are a form of money. 

Oh yes, IBM has done it. While I can't recall the name, there was a hedge fund that based its entire trading philosophy on the basis of Twitter sentiment of underlying securities. 

This payment method not only bypasses banking rails but also seems to disintermediate Boku, Zong and other providers of GenY / MNO-Billing Mobile Payments. It would be interesting to watch how many other MNOs spurn Boku, Zong, et al, and follow in Telefonica's footsteps.

Sorry Nationwide, a 26% week-on-week rise in account openings by itself doesn't prove that "Customers are clearly unhappy with recent events and are opting to vote with their feet." Tens of millions of people have been affected by the events at RBS, NatWest and Barclays. Only if Nationwide's account openings last week and this week are of similar order of magnitude does it follow that many people outraged by their existing banks really switched to Nationwide from last week to this week. In the absence of absolute figures for account openings, a 26% week-on-week rise really doesn't mean much.

Decoupled debit pioneer Tempo Payments shut down a year or two ago following a losing battle to enter the mainstream. Google Wallet and other mobile payments are struggling to gain mainstream adoption. When you combine the two, you surely get a patent but only time will tell whether commercial success will follow.

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.