[From NextBillion blog, 17 January 2012]
Mobile money helps people pay for things in two ways. Directly, by sending value to suppliers of goods and services; and indirectly, by getting remittances from friends and family members which can be used to pay for things. Mobile money works best when there is a coincidence of timing between sources and uses of funds, as then the transaction is immediate. But when there is separation in time between when money is available and when it needs to be paid out, mobile money has so far proved less useful.
The separation in time can occur for two main reasons: (i) if the payment needs to be made on a specified future date (e.g. rent, school fees, electricity bill, seeds for planting), or (ii) if the payment is sizable relative to income flows, such that there needs to be an accumulation of funds prior to the commitment of the expenditure (e.g. buying a motorcycle or new farming implement). These expenditures constitute spending goals, and people will use a variety of mechanisms to achieve them.
Bridging that gap is the role of the store-of-value account in a mobile money system, except that it appears that most people don't leave much value in there. That is probably to a large extent because for regulatory reasons mobile money is usually not marketed as a savings vehicle. But it could also be that people find mobile money too liquid, too easily available: like cash in the pocket, it is best gotten rid of in favor of something valuable (a chicken or a pig), lest it comes to be used for something superfluous.
Since these spending goals represent future expenditures, one could use a system of deferred payments to apply current income to these future goals (see this detailed paper, Savings as Forward Payments: Innovations on Mobile Money Platforms, written by Colin Mayer and myself). Think of these as Me2Me payments (across time), instead of the garden-variety P2P payments (across people, in real time). All it takes to create them is one additional optional field in the standard money transfer menu: the date when the transaction is to take effect. (Immediate execution could be the default, if no date is specified.)
Thus, if I had a good day and made $5 today, I'll cash in the $5, send $2 to myself for February 28 because that's when school fees are due, and another $2 to myself for June 30 because that's when I aim to buy a bicycle; the remaining $1 I'll keep in my liquid mobile money account for daily expenditures. Or if I am a farmer, I'll cash in the value of my crop at harvest time, but can then send good chunks of it to myself to those dates when I need to pay for the rent of the land for the next season, and pay for soil preparation and seeds at planting time. With the remaining value, the farmer could even create monthly payments to himself emulating a salary until the next harvest.
Me2Me payments to future dates are functionally equivalent to commitment savings sub-accounts, each of which is associated with a particular future date. Through this scheme, there is no need to pre-define or open multiple accounts. In the customer's mind, each date, and hence each sub-account, would be associated with a purpose. In this fashion, mobile money providers can create an easy-to-use commitment savings platform that maps out how people think about their needs and their money.
Most people save because they want to buy something. Applying a payments logic to savings behaviors makes it more tangible and relevant for people. It's parking money for a purpose, it's pushing it forward until you have enogh. It's reinforcing the positives (the spending goals) rather than the sacrifices (savings).
Enabling Me2Me payments is a value add for mobile money providers. But more importantly, it can help soften the brutal network effects that are inherent in the early phase of development of P2P networks. With Me2Me, mobile money may be a very useful even when few other people are on the network, because it helps people manage their own money.