Blog

121 Platform increases scale and quality of Cash-Based Humanitarian Aid in Kenya

Posted Diderik van Wingerden

From 2019 until 2022 at The Netherlands Red Cross my team and I have been developing the 121 Platform: a digital platform to make cash-based humanitarian aid programs easier, safer and faster.

This post is a cross-post of the Case Study “Next Level Integration with Financial Service Providers in Kenya and the Netherlands” which appeared on the Cash Hub, which studies how the 121 Platform increased the scale and quality of Cash & Voucher Assistance Programs in Kenya and The Netherlands.

Next Level Integration with Financial Service
Providers in Kenya and The Netherlands

When collaborating with Financial Service Providers (FSP) it might be challenging to oversee the process, especially when having to scale up. By using software-based integrations, often with the use of Application Programming Interfaces (APIs), NGOs can now provide Cash-Based Aid, otherwiseknown as Cash based Voucher Assistance (CVA), more efficiently and at scale. Setting up an integrated system with a FSP through the use of APIs for cash support has its challenges. It can be difficult to grasp the overall picture from a technical perspective. Moreover, when providing cash support, it can be strenuous to contemplate the maze of regulation. Finally, from a management standpoint, it can be demanding to oversee the entire process, to know what is required and when it is required.

This case study will get into setting up next level integration with service providers by using two pilots of 510, the data and digital initiative of the Netherlands Red Cross (NLRC), to demonstrate the potential of FSP integrations. In both pilots, the 121 platform, a CVA program management tool, build with Human Centered Design, was directly linked up with Financial Service Providers:

  1. In Kenya, M-Pesa was distributed to 350 households in Isiolo through an integration with Africa’s Talking and Safaricom.
  2. In the Netherlands, a continuing program assists 500 people every week through an integration with Intersolve, an e-voucher platform.

Alongside a description of these two pilots, this article will get into 510’s experience with the contractual requirements that make such set-ups possible. In case you are interested in more information, please email .

One system, two pilots

Before getting into the details, this case study will give a brief summary of the story behind the 121 platform. Although the 121 platform plays a central role in this case study, the types of integrations that will be covered may also be established with other existing case management systems (however not with Microsoft Excel).

121 Platform

The development of the 121 platform started in March 2019. The 121 Platform began as a software solution to help humanitarian organizations provide CVA in a fast, fair, and safe manner. It had a compelling innovative side, including research into setting up digital identities, transparency of the funding chain, and integrations with FSPs. However, following several strategic pivots, the objective of the platform was steered away from digital identities. The 121 platform now focuses on ease of use and is comprised of two interfaces:

  1. 121 PA App: People Affected (PA) can directly register in an app to decrease uncertainty and assist them in getting back on their feet as quickly as possible.
  1. 121 HO Portal: Humanitarian Organizations (HO) have a portal from which they can manage the registration and inclusion of people affected. Moreover, they can send messages (SMS/WhatsApp) through the portal to people affected about the status of their application. On top of this, using role-
    based access, humanitarian organizations can also do distributions with the click of a button.
  2. 121 AW App: An app for aid workers (AW) in the field to validate registrations. It has been developed but is not yet in use.

When setting up a system that enables semi-automated distributions, technical integration with FSPs is crucial. What is described in the following paragraphs are the technical blueprints for these kinds of integrations. These integrations are allowed by the use of APIs.

Application Programming Interfaces (API’s)

An API is a software interface that allows two applications to communicate with each other. Thus, through the use of APIs, organizations can open up their applications’ data and functionality to external organizations. For example:

  1. To retrieve information, a system (for example the 121 Platform) makes an API call, also known as a request.
  2. The API makes a call to another system (for example the platform of Twilio) through an API endpoint (it is already part of the Twilio system, but if not, can often be created) after receiving a valid request.
  3. The (Twilio) server responds to the API with the data that was requested.
  4. The requested data is returned to the original requesting system (the 121 Platform) via the API (through the API endpoint of the 121 Platform).

Assumptions for this case study

Important to note is that for the remainder of this article it is assumed that the selection decision of people affected has already been made and that the 121 platform (or similar management systems) hold specific types of information:

  • Personal information: a minimal dataset that is used to base the selection decision on.
  • Program design: transfer values, frequency, duration, etc.
  • Payment information: minimal dataset needed by the FSP to perform a payment.

Pilot with Africa’s Talking – Kenya

In Kenya a pilot was conducted where the 121 platform was integrated with Kenya’s mobile money ecosystem: M-PESA. The following four systems were connected through API’s:

  1. 121 Platform: cash based aid platform
  2. Twilio: for mass messaging with SMS
  3. Africa’s Talking: integration layer connecting to several FSP’s
  4. Safaricom/M-PESA: Mobile Money provider

All of the people affected were registered with their phone numbers. For all of the numbers a request is sent from the 121 Platform to Africa’s Talking through an API to check if the number has a registered M-PESA account. The 121 platform received a callback if the number is not able to receive mobile money. Local aid workers can then establish contact with the people in question to correct the numbers.

After the completed registration, the 121 Platform calls on Africa’s Talking through an API with a request to send money to a specific phone number or multiple numbers.

Africa’s Talking calls on Safaricom, a mobile money provider to transfer money to the people affected. The people affected then receive an M-PESA code that can be used to withdraw cash from a local agent.

Reconciliation made easy

The setup allowed Kenya Red Cross to redo the payments for the numbers that failed initially, from the same platform they were managing the cash program. It works as follows, when the distribution is started up, an API call is made to Africa’s Talking. When the payout fails the 121 Platform receives a callback from Africa’s Talking stating that there is an error and what type of error. For each person affected payment-success is visualized enabling Kenya Red Cross to easily resolve the issue and retry the payment.

Pilot with Intersolve – Netherlands

The setup in the Netherlands differs slightly from the one in Kenya. APIs are used to connect the following systems:

  1. 121 Platform: cash based aid platform
  2. Twilio: for mass messaging with SMS and WhatsApp
  3. Intersolve: FSP for e-vouchers with existing vendors

This pilot has now evolved into a running CVA program for immediate food and hygiene needs. People affected are selected by partners of the Netherlands Red Cross and receive an invitation to register. Upon
registration and validation the 121 Platform calls on Intersolve’s API with the number of vouchers needed and the amount of cash assistance for which they should be generated.

A voucher is generated by Intersolve, the relevant information including the due date, PIN, amount, and barcode is sent back to the 121 Platform. This barcode, along with the other data, is subsequently converted to a PDF by the 121 platform. This PDF is stored on the 121 platform and linked to the people affected.

The 121 Platform sends the PDF to Twilio’s API endpoint. The PDF is then sent via WhatsApp through Twilio.

To protect people from getting spam, WhatsApp requires people to engage with the NLRC WhatsApp for Business account first before the PDF can be sent. The standard message people receive is: “Please reply yes to get access for the voucher”. If people answer yes, the voucher is automatically sent.

After receiving the e-voucher, the people affected can use it at the contracted vendor (in this case supermarkets), with their existing cash register infrastructure. The setup allows the Netherlands Red Cross to see if messages and vouchers have been received.

Requesting the balance of the voucher and canceling a voucher

The NLRC can request the balance of a voucher. When a voucher is created Intersolve sends the barcode and PIN back through the API. The balance can be checked by sending a request to Intersolve through an API with the PIN and the barcode of the voucher(s). Intersolve responds through the API by sending the balance connected to the voucher(s). It is not possible to see what e-vouchers are spent on.

Humanitarian organizations can also cancel vouchers if they are not being used. The 121 platform sends an automated request to Intersolve to “cancel voucher” if the person affected does not reply “yes” to receiving the voucher after a certain period in time.

Procuring a Financial Service Provider (FSP) for technical integration

510 understands that contracting FSPs involves many challenges, other than the technical presented below. When exploring the prospects of technical integration, the focus should lie on asking the FSP the right questions. Three notes of caution:

  1. When choosing a FSP do not focus on their technological capabilities alone, ensure that the FSP can service the target communities.
  2. Ensure that the FSP can guarantee that the data of those affected will be protected and that this data will be not be used for commercial purposes.
  3. Avoid FSPs that require the supply of more information than is minimally necessary to process payments.

According to the 510 experience in supporting Kenya Red Cross and Netherlands Red Cross the first question to ask is whether the FSP has an API set-up and whether they can share API documentation and a test-environment. This can often be done in advance of any contractual obligations, but sometimes requires a non-disclosure agreement. Second, one should assess what flexibility there is at the FSP side. They may have technical capacity but that does not mean they want to allocate it to the account of a humanitarian organization. You will need a technical focal point within the FSP. Third, ask the FSP when you can start with technical integration. This may sound obvious but it maybe some bureaucratic red-tape blocking you while there is a technical green-light. Fourth, make sure that local legislation is understood and that the use of this technical integration is allowed for the targeted communities. Finally, make sure your finance team is on-board and understands the process if you work with a new FSP and digitize the distribution.

Learnings

Learnings can be categorized as technical and
programmatic learnings.

Technical

  • Start early, start simple. This will give confidence and understanding of the future possibilities. FSPs are also developing their systems and add new functionalities.
  • Test, test, test. Load testing (think about potential scale of your next program), integration testing and even test the production environment.
  • Ensure callback statuses are appropriately configured, so you can monitor whether integrations are running smoothly.

Programmatic

  • Focus on the online and offline process from the perspective of a person affected and staff. So you know what the system covers and what not.
  • Willingness of a FSP to make changes on their end can be influenced by seasonality and the size of your program. For example supermarkets are not keen on changing systems before holiday season and for some FSPs cash programs may not give them much business value.
  • Do a legal evaluation to assess what you are allowed to do to avoid surprises.
  • Set out the finance flow from the beginning. Think, for example, of what is needed for the invoices to be smoothly passed through the organization and paid. Decide who is accountable for what and what kind of reporting is needed. Also, involve finance teams early in the process; if the payment process is digitized but the finance department insists on a paper list, it may prolong the process.

Conclusion

It is possible! It can help digitize and increase the scale of CVA programs while still focusing on providing quality because it can reduce administrative burdens.

The longer a cash-program is anticipated to run and the more cash-programs a National Society is expected to do, the more it makes sense to look for these optimizations.

It is, however, not without challenges. This is why it is important to start the integration process as soon as possible and test, test, test. A legal analyses should be carried right from the beginning to identify what is allowed. Working in an agile manner is essential; start with the basics and add new features as they become available. If the aforementioned conditions are taken into account, the result is a system integration that ensures that cash support can be done in a fast, easy and safe manner.

What is next?

NLRC is continuing the use of the system in 2022. Two other NGO’s are starting the use of 121 platform (Lebanon and Ethiopia) and integration with FSP’s during Q1 2022. If you are interested in the FSP integrations in general, please reach out to or scan below for WhatsApp.

Organization: 510, an initiative of the Netherlands Red Cross
Author(s): Saskia Tdlohreg