Two misconceptions exist regarding the utilisation of USSD for mobile banking.The first is that it is possible to deploy bank-grade security mobile banking solutions with USSD. All bank-grade electronic banking solutions assume that a certificate based secure token be injected by the Transaction Input Device (POS, ATM, etc.). Typically the bank (or an organisation trusted by the bank) would want to control this input device - this is especially true when transactions are trusted from other banking sources (which is for sure a mobile banking objective). The only way that this is possible in mobile banking is if the bank supply the application on the Transaction Input Device (i.e. on the mobile phone). This can only be achieved by a Java or SIM-based architecture.
This does not mean that USSD can not be utilised to provide mobile banking of an acceptable level of security. By making use of dual factor security, limitation of functionality, limits etc. it is possible to deploy USSD solutions that are quite safe for the consumer.
The other common mis-conception is that USSD is free or not expensive. Whereas it is true that it is difficult to bill for USSD and mobile operators often provide the service for free, it is intrinsically quite expensive to deliver (compared to SMS for instance). The cost to the consumer is a function of what mobile operators bill and this range from free to quite expensive from one market to another. Because USSD is a session based technology and would tie up expensive infrastructure when mobile banking takes off, mobile operators may be forced to charge for it at relatively high levels.
In summary: USSD is a good solution for mobile banking if deployed wisely, but is not the ultimate panacea.
No comments:
Post a Comment