M-Pesa Success Factors And What It Can Mean For UK’s Request To Pay

24 March 2021

In this article, we’re looking at the success factors in growing a two-sided market, using M-Pesa as a reference for the UK’s Request to Pay ecosystem.  The link may not be obvious, but whilst the technology is different, the fundamentals are very similar; just as the M-Pesa platform requires a scaled agent network and a customer network, the Request to Pay system also requires a scaled biller network and a payer network.  Both services are also explicitly designed to serve the financially vulnerable, but as seen with the M-Pesa network, they can have mass-market appeal and adoption.

Scale

One of the major success factors in Kenya was the sheer size of the network operator Safaricom. They had at the time ~80% share of the mobile market so driving the adoption of M-Pesa was quicker than it was in Tanzania where Vodacom had perhaps ~25% share of the market.

Looking at Request to Pay in the UK then, Pay.UK is playing the Safaricom role.  In terms of scale, they move £7 trillion every year through the BACs and faster payments networks so they do have the opportunity to exert a similar influence on the UK market and ensure the success of Request to Pay.  A major difference though is that they don’t have their own retail network so they can’t push the service out themselves to catalyse the market which leads to the next point.

Big rewards for early adopters

Taking the M-Pesa agent network as an example, for those early adopters there was a leap of faith to initially join the service as they had to buy M-Pesa float with capital that may have otherwise been spent on buying more supplies for their shops.  However, those that took that risk were able to build long-lasting customer networks that not only helped them generate more profit through M-Pesa but the additional footfall allowed them to sell more of their core goods.

The parallel here is the applications needed to provide a customer interface in RtP e.g. retail banking mobile apps, personal finance managers or digital wallets.  For these providers, there is a real opportunity to gain new customers and solidify their position as the primary customer interface for consumer finance whilst the system is low on competition.  Once a customer has selected your app to manage their bill payments, they’re going to be much less likely to churn.  Furthermore, as with the M-Pesa example, that increased engagement provides an opportunity to sell more of your core services with the increased RtP data allowing better targeting.

Financially viable for both sides of the ecosystem

The sustainability of the ecosystem is key to its ongoing success.  Too few customers and the agents don’t make enough money to sustain their interest in M-Pesa.  Equally too many customers and the customers themselves get upset as the quality of service in-store will deteriorate.  The golden ratio was about 700 customers to one M-Pesa agent so the M-Pesa teams would very carefully manage the agent network to avoid too many or too few in a given location.

If we stick with the payer application representing the agent in RtP then we can see that for an application provider to build and maintain that service there will be a golden number of customers to ensure that it is viable.  We are yet to discover what this number is (and it’s likely to be different for each business) but we can look to reduce this number by using services like the ones offered by Answer Pay to help reduce the costs in joining the ecosystem.

The additional dynamic with RtP is that there is also the biller network to consider as customers need to have billers to interact with in order for them to be motivated to adopt the solution.  The early signs are really positive here but don’t take my word for it, listen to James Stanley from Anglian Water and get his take on it.

Designed with the user in mind

I mentioned at the outset that M-Pesa was initially envisaged as a service for the underbanked.  It, therefore, needed to be readily accessible by those users who predominantly used feature phones. This then drove the technology solutions to ensure that payments would be possible via SMS or USSD channels.

The Pay.UK solution to this is really rather neat.  As it is an API first approach the payer application providers can define their own experiences and payment methods that serve their communities the best.  Want to pay your bills by bank transfer?  Then receive your bill payment request to your mobile banking app or Open Banking provider.

Thinking about financial vulnerability though, being able to pay with cash could be key to some key customer segments.  In which case I could envisage a Paypoint terminal (newer models are available) acting as the “app” with customers being able to pay with cash.  That the service can be so adaptable will ensure that it can both appeal to the mass market but also address some really interesting niches where people need it most.

M-Pesa has over 40M active customers sending money person to person, person to business, business to person and business to business.  It is embedded into daily life.  Is it too much of a stretch to believe that Request to Pay could do the same in the UK?  Perhaps if we’d had this conversation last year I might think that way.  However I do think that the pandemic has changed things and has no doubt accelerated the adoption of bill payment as demonstrated by the adoption of bill payment in the US.