While it is somewhat complex, it is rather easy to make one phone send an instruction to move money from one account to another and for another phone to receive confirmation of the transaction having completed. Any
competent student fresh out of university can probably get such a system working in a week or two. This is why the mobile payment industry is blessed with so many pilots and concept deployments. This is why industry veterans are frequently confronted by some company that "can do it at a much lower price-point". (Obviously without appropriate experience.)
It is only after a fair amount of subscribers and some transactions are being delivered that organisations typically realise the necessity of relevant and robust back-office support. I call this the backlash of back-office. To only realise the need for sophisticated back-office systems (at exactly the wrong time)... when the solution starts picking up traction. It is often then too late.
Mobile money systems should be designed and constructed with back-office support central to the architecture. The low cost, small value environment requires a decisive and efficient back-office... very much different in design and process than existing banking systems. These systems must be able to cater for on-line subscriber queries and requests, while at the same time monitoring large volumes of transactions. The back-office must be able to cater for
unavailability of certain components and enabling call
centre staff to manage adverse (and sometimes unpredictable) situations. The pressure on support staff and the demands from clients lead to complex business
imperatives that can only be supported with extremely sophisticated and specialised back-office systems.