Arc Finance Highlights our Raison D’être

October 27th, 2009 by host Leave a reply »

arc_logoThe nonprofit, Arc Finance, is looking into ways to expand access to financing for modern energy, clean water, and other basic needs globally, and is interested to see how mobile payment systems are being used currently to make payments/remittances possible in rural settings. In the email below, Mike MacHarg of Arc Finance highlights some of the issues facing one NGO making mobile payments to farmers in Kenya.

Dear XXXX,

Got some interesting feedback from the group XXXX, that uses Safaricom’s MPesa system to pay its tree farmers (they pay farmers quarterly in Kenya, India and Tanzania for tree planting – through funds raised on the voluntary carbon market).

How it works:

XXXX has small groups of 8-12 farmers each. XXXX makes quarterly payments to the small group, to a single Safaricom (in Kenya) SIM card held by the group. There is a checks and balance system built in, as at least three farmers from the small group have to show up at the meeting when the transfer is made, and one has the SIM card, another the PIN number for MPesa collection, and a third has the voucher for the payment (voucher is issued beforehand when it is confirmed the trees were actually planted?).

Issues and challenges:

safaricom1) Transaction fees are high relative to the small payments to the farmers. One issue has been that the transfer fees within Safaricom/MPesa are high relative to the small payments being made to the group. Either XXXX has to absorb that cost, or pass it onto the farmers. In Safaricom’s case, it does not pay to make very small payments.

2) SIM card deactivation over time: In the small group model, the SIM card is only used quarterly by the group for the money transfer, and for no other purpose. Unfortunately, Safaricom deactivates SIM cards that are dormant for long periods (like 3mo) – so XXXX has faced the issue of having to reactivate all of their small group SIM cards prior to each money transfer. Causes major delay in transfer, and can cause farmer payment meetings to take up to 6 hours.

Deactivation may be different with different vendors (MTN, Orange), but something to consider. XXXX is trying to determine other ways to keep cards active, such as sending a negligible amount of airtime, say 1 Ksh (there is no fee for transferring air time) – so that the SIMs stay active.

3) SIM card registration: this may play into the regulatory environments for mobile payment systems, but XXXX has recently found out that it is “illegal” to register the SIM cards to small groups – and not to an actual business or individual. This probably has to do with “know your customer” regulations that have to do with banking – that are being carried over to mobile money transfer operations. Another thing to consider if you use the small group model.

mpesa_news_main4) Transfer time: XXXX brings its small groups together on a certain day, and meets with them physically to do the mobile money transfer. While you might think it would be easier to just pay out cash in this setting – there is enough of a security issue that the mobile payments still make more sense. But transfers are not often instantaneous – and intermittent cell phone connections in rural areas can drag out the transfer process for up to 3-4 hours, as each transfer has to be uploaded to MPesa, and then farmers will wait to verify the payment has indeed made it back to their SIM card.

5) SIM credit limits: XXXX has to use up to 4 of their own SIM cards to make the payments from, since there are limits (with Safaricom) as to how much credit any individual SIM card can hold at one time. So to make $400 in payments, XXXX might use four SIM cards that have a limit of $100 each.

6) Record keeping: To date, Safaricom has been resistant to providing XXXX with records of their individual transfers to each of the small group’s SIM cards. Obviously valuable data for XXXX to have to keep track of payments to farmers, and for now they are reliant on paper based records to keep track of data that Safaricom is already keeping. Safaricom has said that they are looking into making such data available, but has resisted in helping XXXX to date (as it sees no great profit incentive to supply such data).

Individual and organization names have been redacted for privacy purposes. The email author, Mike MacHarg, is available for comment and can be reached at
mike.macharg “AT” gmail.com.

Bookmark and Share
Advertisement

4 comments

  1. Chrissy says:

    Can you expand on how FrontlineSMS Credit will solve these problems?

  2. Ben Lyon says:

    Hi, Chrissy. We’re about to update the “About” tab to answer just that, but here’s a preview =)

    Now that we have FrontlineSMS reading USSD (a common format for mobile payments), we can send/receive/track mobile payments through FrontlineSMS, which can then be automatically attached to a user’s phone number and accompanying profile. That will provide a clear client/employee transaction history which will meet the data need.

    By building an SMS mail merge function in to the current FrontlineSMS group message feature (e.g. [pay][insert number from list][amount of value][PIN code]), the group in this example will be able to pay hundreds of clients/employees with one command instead of spending all day to manually enter and document each payment from a single handset.

    FrontlineSMS can currently run multiple SIM cards simultaneously. By programming FrontlineSMS to automatically switch to the next SIM card when the value of a SIM’s mobile wallet equals zero, the group above will be able to continue exceeding daily transaction limits.

    We’ll post more information soon. Thanks for your question – it forced me to start putting these ideas in ink! Feel free to contact me at ben@credit.frontlinesms.com for any additional questions or comments.

    Cheers,
    Ben

  3. simon cavill says:

    Hi Ben,
    Working in this space for almost 5 years, the idea of being able to automatically switch to another SIM to exceed daily transaction limits is rather scary from a fraud management point of view….

    What are you doing to handle potential fraud in this way?

    Best regards,

    Simon

  4. Ben Lyon says:

    Hi Simon,

    Thanks for your comment! I’m definitely keen to discuss this further. Would you mind emailing me at ben@credit.frontlinesms.com?

    Cheers,
    Ben

Leave a Reply