Testing a new blockchain-based solution for addressing the beneficiary de-duplication problem

Samer Haffar
Frontier Tech Hub
Published in
7 min readMay 9, 2022
Beneficiaries registering and getting humanitarian aid.

The beneficiary duplication problem is a known issue facing humanitarian organizations. In very simple terms, the duplication problem is when a beneficiary receives humanitarian aid intended to meet the same need(s) multiple times either from the same organization, or from several different organizations. Beneficiary duplication is a big issue because it limits the impact of humanitarian aid because the number of beneficiaries that end up getting the aid is less than planned. As of 2020, it was reported that around 16% of all humanitarian aid was being given to duplicate beneficiaries (WFP, 2021), reaching up to 40% in some areas. The situation gets even more complex, when more than one NGO is working in the same location, delivering several types of aid.

Aid agencies (i.e., NGOs and UN agencies) are aware of the duplication issue and its impact; therefore, agencies regularly try to coordinate their work and operations to prevent duplications. However, many challenges face humanitarian organizations as they try to reduce duplicates; the main challenge is in having to share sensitive beneficiary information to crossmatch beneficiaries and ensure no duplicates are found. Another challenge is the time and effort it takes to coordinate deployment of aid and match and compare beneficiary lists to detect duplicates. Further, doing this manually makes the entire process subject to human errors; so often, aagencies are faced with the difficult decision to deprive vulnerable community members from the aid they need the most when there’s a risk that the beneficiary was flagged as a duplicate by mistake. The challenge becomes even more difficult in emergency responses, where aid needs to be decided and deployed fast, so having an efficient approach to the duplication problem is important for the overall success of the response.

Piloting a blockchain-based de-duplication tool in Nigeria

In this project, we are piloting a technology solution (more on that later) that leverages the incredible features and properties of blockchain technology to address the duplication problem in Nigeria. The solution was piloted in Syria in 2021, where four organizations utilized the solution to detect duplicates in their location of operation. The pilot was very successful and was able to detect 113 duplicates in a set of 7000 registered beneficiaries, in real-time, while maintaining the security and privacy of the beneficiary data, eliminating the need for sharing beneficiary information among organizations, and automating the entire process for an efficient detection and flagging of duplicates.

The purpose of this pilot is to test the applicability and usability of the same solution in Nigeria. We also want to learn about the specific requirements and needs of the Nigerian context for the solution to be usable and detect duplications efficiently. We will be drawing from the successful Syria pilot and applying the lessons and experiences we learned there to contribute to the success of the pilot in Nigeria.

During the pilot, we will be raising awareness about the solution and the technology behind it, invite several NGOs and UN agencies to participate in the pilot, learn about their needs and specific requirements, then pilot the use of the technology with participating organizations and help them detect duplicate beneficiaries in their ongoing projects. Additionally, we will be exploring the requirements, and the options available, for using the solution on a larger scale.

About the solution

The de-duplication solution is an application, built on the blockchain, that processes beneficiary registrations and allows flagging duplicates in real-time. The solution is a part of the GeniusChain initiative, which aims to bring the incredible power of blockchain technology to humanitarian work, as well as providing several tools and applications that address most pressing issues facing humanitarian organizations (more on GeniusChain here).

By using the solution, aid organizations can automate the entire de-duplication process, which eliminates the need for any human intervention and provides real-time detection with reliable results. Further, because the checks for duplications happen on the blockchain, organizations do not need to share sensitive beneficiary information with each other, (or even with GeniusTags). This also means that all duplication checks are publicly accessible, which ensures the transparency of the entire operation.

The solution works by generating a universal unique identifier (UUID) for each beneficiary based on several data end points and then using that UUID to check for duplicate registrations on the blockchain. Setting up the solution and activating it for use is as easy as the following simple four steps: 1) configure the system on the web portal by creating accounts for organizations and their field teams, 2) install the GeniusChain mobile app on the tablets/smart phones used for beneficiary registration, 3) adjusting data collection surveys for storing UUIDs and duplication check results; then, 4) organizations can start detecting duplicates immediately and in rea-time.

Organizations do not need to make any changes to their existing data management and collection policies and workflows, because the solution integrates with their existing infrastructure and tools used for data collection and processing, making it super easy and quick to install and activate the solution for duplication detection.

What we did

In the first sprint, we wanted to raise awareness about the solution for aid organizations working in Nigeria and select 3–5 organizations to participate. We also wanted to make sure that the solution complies with the local data privacy and protection laws regulations. Our approach to this was that we reached out to the Cash Working Group of Nigeria to ask for their help on the pilot. Also, we wanted to invite them to collaborate with us and provide their support throughout the entire pilot. The CWG is the entity responsible for coordinating cash assistance efforts in Nigeria, so they are very familiar with the context, the challenges, and can provide great insights into what works and what doesn’t. Further, the CWG is very well connected with the NGOs and UN agencies working in Nigeria. So we believe that getting them on board would have a huge impact on the value of the pilot and the learning we want to get out of it.

We reached out to the CWG team and pitched the pilot to them; the team was very excited and offered to provide us with all the support we need to execute the pilot. This, of course, was great news for us and was a very promising accomplishment in the pilot.

To raise awareness, we wanted to invite NGOs and UN agencies to an introductory meeting to introduce the solution and the pilot, then hold several meetings and workshops with the NGOs to learn about their needs, requirements, what works and what doesn’t, as well as what changes, if any, need to be made to the solution to make it usable in the Nigerian context.

Knowing the challenges associated with the duplication issue, and from our experience in the Syrian pilot, we knew that aid organizations would be reluctant to participate in the pilot for one key reason: they have a responsibility to protect sensitive beneficiary information so they’d be very cautious about participating in an initiative that might involve sharing beneficiary data. Also, the fact that this solution works across multiple organizations, and utilizes a fairly new technology (i.e., blockchain) makes humanitarian organizations even more careful about joining such an initiative.

To address that, we wanted to be very prepared for the first meeting and gather enough momentum and excitement from the NGOs and UN agencies to get them to attend and be interested in the pilot. For that, we decided to put together some key messages that briefly explain what the solution is, how it works, what it addresses and how, as well as addressing some of the key concerns they might have. We came up with two drafts, one that explains what the pilot is and its different stages, and another that provides in detail what the solution is, how it works, and how it maintains the security and privacy of beneficiary information and eliminates the need for sharing that information.

Although the first drafts were comprehensive in covering all there is to know about the pilot and the solution, they needed work on their language and formatting to make them appeal to the audience we’re targeting. Also, the documents needed to be short, concise, and straight to the point so that anyone reading them would quickly understand the intended messages effortlessly.

After a lot of back and forth, and several rounds of discussions, revisions, feedback, and input from different people, we arrived at the final version, which is a three-pager written in a “question and answer” format that addresses most of the key questions about the pilot, the solution, how it works, concerns about data privacy and protection, and the requirements for participating in the pilot.

Challenges and learning

The main challenge so far has been the time constraint. When we first started sprinting, the plan was to finish the entire awareness stage in the first sprint. However, due to having many moving parts and the many parties involved, it was difficult to finish on time. Among the time challenges was that a part of the planned sprint time happened to be during holidays (Easter and Eid), so many of the expected attendees would be taking time off during this time.

Another time challenge was the document containing key messages; it took much more time than expected, but the fact that we knew how important it is to get it right for gathering momentum and interest from aid organizations led us to give it as much time as it takes to arrive at the most suitable version, which we did. The main learning point in this sprint is to be mindful of the many moving parts and factors in the experiments we plan to test in each sprint. One way of doing so is perhaps having several experiments that aren’t dependent on each other so that multiple experiments could, perhaps, be started in parallel.

--

--