I think it is pretty clear that mobile money has become a way of live for Kenyans. It is inconceivable to think of a world without mPesa and Zap in Kenya. The impact on the economy and the financial services landscape has been well researched and documented.
It may not be well-known, but the Kenyan telecommunication authority have licensed four operators to offer mobile telecommunications services in the country: Safaricom (with almost 80% marketshare and 40% Vodafone shareholding), Airtel (previously Zain) (with 13% marketshare and 80% Airtel shareholding), Orange (with 4% marketshare) and Yu Essar (with around 3%).
What I have found interesting is the activities of the other three operators. For (relatively) small operators, these companies are spending a lot of effort to launch new features and compete with their mobile wallets. Orange recently launched Orangemoney and Yu are trying their best to induce mPesa agents to switch to Yucash. Airtel's Zap has been waging a war on mPesa for longer than a year using features and price as weapons. It is interesting to observe the energy of the smaller players in this market.
It seems that a time will come in most emerging markets when having a mobile money solution will be a minimum requirement to play as is the case in Kenya.
Friday, November 19, 2010
Wednesday, November 17, 2010
iPhone, Google and NFC
It would be irresponsible for a mobile banking blog not to have an opinion on iPhone, Google and NFC. It is impossible to ignore the amount of excitement in the formal and social media about the instance when Eric Schmidt tapped his Nexus S on a proximity reader recently (Read here). With this small action, Schmidt signalled an intend from Google than just cannot be ignored.
I did write about the rumours related to Apple's venture into the the NFC space some weeks ago (Read here). I did highlight some of the challenges related to solving a few process and liability problems related to the secure element and personalisation then, so will not dwell on it again. Suffice to just re-emphasise that this whole mobile payment thing is much more complex and difficult to do than other digital stuff - far more difficult.
It is far more interesting to speculate on the strategic intend and approach of Apple and Google with this drive. (I enjoyed a post on technology and financial services with reference to this question a lot. (Read here)). The fundamental question is how these two giants intend integrating into the existing payment eco-system, how they intend changing it and what is in it for them. The complexity of payments is that it is tightly integrated and dependant on many other players. (Just think of the importance of banks (deposit-taking and settlement), regulators (compliance and risk-mitigation), card associations (inter-operability) and retailers (acquiring of payments), to name but a few. It is inconceivable to deploy a payment system without considering the role of these players (and many others).
Many questions remain unanswered: Do Google and Apple intend integrating into this eco-system? Working with the banks or card associations? Who will be their biggest friends and who should be scared of them? By delivering phones with NFC chips in them, what do they think will be the impact of it? Will this enable more people to transact and in when? Where will they make money? and who will loose revenue, because Apple and Google will steal it?
No matter how I dissect these questions, I only get to one conclusion: It is all about iTunes and Google accounts. The plan is that the phones will ultimately become an extension of the on-line experience. This is why Jim Balsillie (CEO of RIM) comment is so interesting: "We'd be fools not to have NFC in the near term ". (Read here).
I did write about the rumours related to Apple's venture into the the NFC space some weeks ago (Read here). I did highlight some of the challenges related to solving a few process and liability problems related to the secure element and personalisation then, so will not dwell on it again. Suffice to just re-emphasise that this whole mobile payment thing is much more complex and difficult to do than other digital stuff - far more difficult.
It is far more interesting to speculate on the strategic intend and approach of Apple and Google with this drive. (I enjoyed a post on technology and financial services with reference to this question a lot. (Read here)). The fundamental question is how these two giants intend integrating into the existing payment eco-system, how they intend changing it and what is in it for them. The complexity of payments is that it is tightly integrated and dependant on many other players. (Just think of the importance of banks (deposit-taking and settlement), regulators (compliance and risk-mitigation), card associations (inter-operability) and retailers (acquiring of payments), to name but a few. It is inconceivable to deploy a payment system without considering the role of these players (and many others).
Many questions remain unanswered: Do Google and Apple intend integrating into this eco-system? Working with the banks or card associations? Who will be their biggest friends and who should be scared of them? By delivering phones with NFC chips in them, what do they think will be the impact of it? Will this enable more people to transact and in when? Where will they make money? and who will loose revenue, because Apple and Google will steal it?
No matter how I dissect these questions, I only get to one conclusion: It is all about iTunes and Google accounts. The plan is that the phones will ultimately become an extension of the on-line experience. This is why Jim Balsillie (CEO of RIM) comment is so interesting: "We'd be fools not to have NFC in the near term ". (Read here).
Thursday, November 11, 2010
The illusive hyper-growth position
Why is it that some mobile money deployments grow spectacularly and others just chug along without any dramatic growth? In only twelve months, some deployments grow to a penetration of 15% of their total target market, while others barely grow to more than a few percentage points.
I refer to this high growth situation as the illusive hyper-growth position. In observing what drives these deployments, I am of the opinion it is a combination of three things:
I refer to this high growth situation as the illusive hyper-growth position. In observing what drives these deployments, I am of the opinion it is a combination of three things:
- Getting pricing wrong will kill take-up. It is important to get the fees right - not too low and not too high. Too high prices will chase prospective clients away - often for-ever. Too low prices may lead to transaction volumes that cannot be supported by the platform installed.
- Ensuring that the distribution network are built in line with the roll-out of the product is essential.It is of no use that agents are appointed, but not properly trained. The distribution network must be carefully selected and appropriately equipped.
- The mechanism and content of promotion is very important. The media used and the message will dictate if this is a success or not. It is no of no use to offer a service and then not to tell anybody of it.
Tuesday, November 02, 2010
The saga of the NFC-enabled SIM
Turkey has often taken the lead in the deployment of advanced mobile banking applications. The deployment of digital signatures (and the application in banking) is by far more advanced than anything in the rest of the world. Garanti Bank recently announced (in conjunction with Avea (a new Turkish mobile operator)) that they have launched a NFC-enabled SIM. (Read here) This is in my view, one of the most important announcements in the mobile banking industry this year. The possibilities created by this advance is huge and should be evaluated further.
The biggest challenge faced in rolling out mobile enabled NFC (waving the phone in front of a reader) solutions is that very few phones actually ship with a proximity radio. This is an essential part of the NFC eco-system. Without this little piece of hardware, it is impossible to develop NFC solutions. (No advances in software can compensate for the lack of this piece of hardware). Placing the proximity radio on the SIM card has been considered as a possibility many times, but was always discarded because of one big challenge: the radio's antennae. The SIM card is too small to also carry a big enough antennae and furthermore, the SIM card is often hidden inside the phone, sometimes behind the battery. Even if the antennae were to reside on the SIM, it would be very ineffective and different from one phone to another.
It is not clear how this problem has been solved, but it seems to have been solved. This innovation (if replicable on other networks), would allow any phone to be NFC ready by just swapping the SIM card. Other pilots have utilised the memory slots available in phones and have used proximity radios installed on microSD cards. I am of the opinion that these pilots are now doomed as it is a much more plausible solution to place the radio on a SIM card.
The biggest challenge faced in rolling out mobile enabled NFC (waving the phone in front of a reader) solutions is that very few phones actually ship with a proximity radio. This is an essential part of the NFC eco-system. Without this little piece of hardware, it is impossible to develop NFC solutions. (No advances in software can compensate for the lack of this piece of hardware). Placing the proximity radio on the SIM card has been considered as a possibility many times, but was always discarded because of one big challenge: the radio's antennae. The SIM card is too small to also carry a big enough antennae and furthermore, the SIM card is often hidden inside the phone, sometimes behind the battery. Even if the antennae were to reside on the SIM, it would be very ineffective and different from one phone to another.
It is not clear how this problem has been solved, but it seems to have been solved. This innovation (if replicable on other networks), would allow any phone to be NFC ready by just swapping the SIM card. Other pilots have utilised the memory slots available in phones and have used proximity radios installed on microSD cards. I am of the opinion that these pilots are now doomed as it is a much more plausible solution to place the radio on a SIM card.
Why is mobile banking different to online banking?
Four years ago, I wrote a blog arguing why mobile banking is not at all like Internet banking (Read here). Most (if not all) of the arguments are still very much applicable today. The biggest being that through mobile banking it is now possible to reach a large percentage of the world's population that do not have access to banking infrastructure. This in itself is a major revolution.
However, with the massive advances in mobile phone technology and the convergence of smart phones with tablet PC's and desktops, is it still possible to distinguish between mobile banking and online banking? How is it possible to distinguish between an Internet banking session originating from an iPhone browser, a iPad's browser or a MAC? The answer is that it is not possible. It is therefor possible to perform online (read browser-based) banking from a phone. Also, it is quite conceivable that a mobile banking app (written for the iPhone) can now be run on a iPad. Is this mobile banking or tablet banking?
What is needed, possibly, is to redefine online and mobile banking in different terms and utilise new terms to distinguish between the two. I would propose still using online banking, but rather refer to mobile banking as transactional (or message-based) banking. Mobile banking (designed correctly) have utilised the phone characteristics of being able to work with messages better and also support real time push capabilities. This functionality is of course now also available on PC's and can/should be utilised by banks for this form-factor too. Transactional banking would typically focus on payment transactions (bill payments, ad hoc person to person payments, cheque-related payments etc.) whereas, online banking offer much more sophisticated reporting and information representation capabilities.
The most important difference in my mind is recognising the difference in requirements in back office systems. Online banking and Transactional banking have very different scaling challenges and the design for the one (concurrent sessions), would be very different to the other (queue management). Also the security paradigm and risk management and mitigation are also very different.
It is clear that the boundaries between online and transactional banking are busy blurring, but by making this distinction, it is possible to design better banking applications.
However, with the massive advances in mobile phone technology and the convergence of smart phones with tablet PC's and desktops, is it still possible to distinguish between mobile banking and online banking? How is it possible to distinguish between an Internet banking session originating from an iPhone browser, a iPad's browser or a MAC? The answer is that it is not possible. It is therefor possible to perform online (read browser-based) banking from a phone. Also, it is quite conceivable that a mobile banking app (written for the iPhone) can now be run on a iPad. Is this mobile banking or tablet banking?
What is needed, possibly, is to redefine online and mobile banking in different terms and utilise new terms to distinguish between the two. I would propose still using online banking, but rather refer to mobile banking as transactional (or message-based) banking. Mobile banking (designed correctly) have utilised the phone characteristics of being able to work with messages better and also support real time push capabilities. This functionality is of course now also available on PC's and can/should be utilised by banks for this form-factor too. Transactional banking would typically focus on payment transactions (bill payments, ad hoc person to person payments, cheque-related payments etc.) whereas, online banking offer much more sophisticated reporting and information representation capabilities.
The most important difference in my mind is recognising the difference in requirements in back office systems. Online banking and Transactional banking have very different scaling challenges and the design for the one (concurrent sessions), would be very different to the other (queue management). Also the security paradigm and risk management and mitigation are also very different.
It is clear that the boundaries between online and transactional banking are busy blurring, but by making this distinction, it is possible to design better banking applications.
Businesses would welcome mobile banking
What a surprise! Fundtech in conjucntion with Aite recently found conclusively that Executives would use and embrace mobile banking if it were to be provided by commercial banks. Why did we think differently and why was it necessary to research this. (Read more about this report here)?
The notion that mobile banking is not secure and safe as is the case with Internet banking exists. How is it possible to deliver a secure service on such a small piece of equipment and what will happen if an executive's Blackberry is stolen in a pub? I am sure that this is the only concern that executives could have for not using mobile banking in their business. The fact is that it is much easier to ensure a secure (and a much better auditable) system on a personal device. The industry has failed in some ways not projecting this fact.
The notion that mobile banking is not secure and safe as is the case with Internet banking exists. How is it possible to deliver a secure service on such a small piece of equipment and what will happen if an executive's Blackberry is stolen in a pub? I am sure that this is the only concern that executives could have for not using mobile banking in their business. The fact is that it is much easier to ensure a secure (and a much better auditable) system on a personal device. The industry has failed in some ways not projecting this fact.
The implications of using mobile payments in a retail environment
Most of the spectacular successes of mobile money initiatives were built on person to person (P2P) payments. This is a transaction were money is "pushed" from one wallet to another in an instant. The recipient of the money is informed immediately that he/she received a payment. Of course, nothing stops one utilising this kind of transaction in a retail environment. One may as well just send money to a shopkeeper's mobile phone to complete a payment.
So what is the relevance of the recent mPesa announcement that mPesa can now also be used in supermarkets? (Read here). Well, it is because using mobile payments in supermarkets (or formal retail environments) are much more complex and difficult. Much more have to be catered for that does not just exist in P2P payments. Below is a sample of some of the things that one has to consider:
So what is the relevance of the recent mPesa announcement that mPesa can now also be used in supermarkets? (Read here). Well, it is because using mobile payments in supermarkets (or formal retail environments) are much more complex and difficult. Much more have to be catered for that does not just exist in P2P payments. Below is a sample of some of the things that one has to consider:
- The system will have to cater for multiple roles in relationship to a retail account. For instance, one would not want the receiver of funds (the till operator) to also have the ability to pay from this account. Some roles will have more functions while others may have to restricted.
- In order to support the way that a retailer works (and when fully integrated with the store automation), one may want the system to support a "pull" payment, rather than a "push" payment as is the case with P2P. This is much more complex to implement.
- The system will have to cater for other types of transactions, like for instance: refund or reversal transactions.
- The owner of the supermarket typically requires more comprehensive management information and the data stored and displayed will have to be developed in such a way that the information available caters for the need of the retailer. For instance, data may have to carry information related to the types of goods purchased.
- Furthermore, if the system is really advanced and architected well, it would already position the automation for future functionality like NFC for instance.
Subscribe to:
Posts (Atom)