Building the M-PESA charges bot
This post was written by Kimenye and originally appeared on Ongair’s publication Let’s Ongair. Ongair is a service for businesses to connect to their customers through Messaging apps. To learn more about their work please check out their website.
Enjoy!
The promise of conversational interfaces is a simple, convenient way to access services and interact with the connected world in much the same way we humans communicate. At Ongair we’re re-inventing customer service and business to consumer communication using messaging as a medium and Artificial Intelligence to help businesses provide faster and better responses to their customers. We recently put this to test by tackling one of the pain points experienced by M-PESA users everyday — discovery of the charges associated with using this convenient money transfer service (M-PESA is a Kenyan payment service where customers can send money and pay for goods and services through their phones).
The Back Story
Caro needs exactly 1,000 sh (~ 10USD) to pay for something and asks her brother Mato for help. He wants to send her 1,000 sh but remembers that when Caro withdraws the money from her mobile wallet to cash, she will be charged a withdrawal fee — in this case 27sh. So he needs to send 1,027 sh. He is also going to be charged a fee to send the money in the first place. How much money does Mato need in his M-PESA wallet to be able to complete this transaction?
The above calculation is one which many Kenyans have been making for years, mentally keeping track of the sending and withdrawal fees for different amounts (See the rates table online here). It has even spawned a Kenyan saying — “Tuma na ya Kutoa” which is roughly translated to “Include the withdrawal fees when you send me money”.
Mapping the Problem
Our first step in looking at this problem, was to focus on the user (Mato in this case) and what options were available to him. For small amounts, which make the bulk of peer to peer payments, most people have memorized the withdrawal fees for certain bands. For example, 100–2,500sh costs 27sh to withdraw. Another key data source is the tariffs as displayed prominently at M-PESA agents.
The above image shows what an M-PESA user would see before transacting at an outlet. If Mato wasn’t at an outlet and had an internet connected device, his likely next option would be to go to Google. Google search trends reveal strong interest especially around withdrawal charges.
Designing the Solution
We distilled this problem to the the question :
‘How much do I need to send 1,000 shillings and cater for the withdrawal fees?’
The system would then respond with the following output:
You need to send 1,027ksh incl. withdrawal fees of 27ksh. This will cost you 25ksh. You need a total of 1,052ksh
Here’s our working. Take the input amount, add the withdrawal fees then calculate how much it would take to send the aggregate amount. In this case, catering for the withdrawal fees moves the sending amount from the 501–1,000sh band which costs 15sh to the 1,001–1,500sh which costs 25sh.
Prototyping
Once we had a clear problem defined and our solution, our next step was figuring out what was the best way to deploy this solution. There were already some interesting existing approaches to solving this. Here’s a few we reviewed.
- Twitter user Elvis has built an interesting utility that helps you optimize your transactions for the lowest charges.
- M-Ledger an app acquired by Safaricom provides several utilities to calculate this. The recently launched M-PESA app by Safaricom available on smartphones also shows you the transaction fee before you send, but doesn’t provide a simple way of figuring out how much the withdrawal fee is.
- Eventually we were guided by the Google search trends and our aim to make it a one step process of entering the input and getting a quick result. We decided to build a chat-bot that could handle such enquiries in natural language.
Introducing the M-PESA Fees Bot
The bot is available today on Telegram. Our choice for Telegram was really about convenience and speed of deployment. We quickly launched this on Twitter by asking people to help us test it out and were overwhelmed by users, making it our most popular bot by far.
How it works
The bot is deceptively simple in its operation. Its input is the phrase with the user’s question. Here are the steps:
- Classify the enquiry (Intent discovery)
- Extract the amounts involved
- Calculate the fees
- Response to the user.
The challenging, and quite interesting part for us was the many permutations that Kenyans could use to provide the input. This varied from grammatically correct English, Swahili, Sheng (slang) to some people just sending the amount. We also needed to be able to handle the various ways people referred to money (1000KES, 1000ksh, 1000 kes, 1k, a thousand e.t.c.)
This was a problem that lent itself to both machine learning and rule based approaches. Both applications are presented in some detail below.
Intent Discovery
This answers the question — What is the intent expressed in the user’s message. Are they asking about withdrawal fees or just sending fees. This allows us to handle only enquiries that match our intent. It was tempting to being with a keyword based approach like fuzzy matching for keywords such as Withdraw and Send but quickly discarded this approach as the different permutations increased.
We settled on a supervised learning approach that compared similarity of input text to a set a sample enquiries. This is further weighted by the presence of particular entities (in this case the amount).
Here a some of the training examples used:
- I want to send 1000 ksh (English)
- How much to send 3k (English)
- Ni how much kutuma thao (Slang — How much to send 1,000 shillings)
- Nataka kutuma elfu tatu (Swahili — I want to send 3,000 shillings)
At the beginning a lot of valid phrases were not being matched by our classifier. We begun with 15 training examples, and quickly devised a system where frequently unmatched examples were reviewed and added to the training set.
Entity Extraction
This is the process of resolving the transaction amount involved given a phrase. We were quite surprised by the various ways to describe amounts in Shillings. Here’s just a few examples for 1,000 shillings:
- one thousand shillings
- 1k, a k, a gee
- a thao,ngiri — slang
- 1,000
- 1,000sh / 1000shs
- 1000kes
- 1000ksh / 1000kshs.
- elfu moja — swahili
It gets a lot more interesting when looking at multiples of amounts, for example, 5,050 shillings. Here’s are real world interaction.
To overcome this challenge we used a ML based slot filling approach and a rule based approach for some of the numerical formats. We ended up building a training model for local currency detection that we will open source shortly.
Lessons Learnt
Perhaps the biggest lesson we’ve learnt is to launch early and get it in-front of real users. Not only were we able to crowdsource our training data especially for the currency detection, but we were also able to uncover new intents by looking at user behavior. For example, at launch we did not explicitly cater for people who just wanted to know what the withdrawal fees — but quickly looking at the user data we were able to see that this was in demand and implemented this. Our roadmap for this bot is now governed by what questions users are asking.
We are looking for contributors:
We are looking at building a community of people solving problems using design in Kenya willing to share their stories. Interested in publishing here? Reach out to us on our social media channels Twitter, Facebook. We will publish the contribution guideline in the course of this week but don’t let that hold you back. Thanks Kimenye for being the first contributor!
