A Programme Born in an Emergency
When the COVID-19 pandemic reached The Gambia, with the first case recorded in March 2020, the impact on poor households was immediate and severe. Markets shrank, informal jobs disappeared, remittances slowed, and the country's already thin social safety net came under enormous pressure. The Government of The Gambia, with support from the World Bank's Social Safety Net Project, responded by launching Nafa Quick — an emergency cash transfer programme designed to put money into the hands of about 83,000 of the most vulnerable households in the country, fast.
"Fast" is the word that defined everything about Nafa Quick. Cash transfers, when done well, are not simple. They require a verified list of beneficiaries, a way to pay them, a way to track whether they actually received the money, and a way to reconcile every transaction with the financial institutions that move the funds. Building that machinery normally takes a year or more. Nafa Quick had weeks.
2M Corp was brought in to design and deliver the operational backbone of the programme: a management information system capable of registering beneficiaries, generating payrolls, coordinating with the payment service provider, and reconciling disbursements at scale. The result was Kaarange — the MIS that would go on to underpin not only the emergency response but, eventually, the much larger Nafa Project that followed.
This is the story of how it was built, the unusual problems it had to solve, and what we learned along the way.
What We Were Asked to Do
The terms of reference were broad in scope but narrow in time. Working with the National Nutrition Agency (NaNA) and the World Bank team, we were asked to deliver a system that could carry the full operational lifecycle of an emergency cash transfer programme. That meant covering beneficiary registration and enrolment, the assignment of beneficiaries to programme components and payment cycles, automated payroll generation, integration with the payment service provider contracted to disburse the cash, mobile-device support for field-level verification and disbursement in areas with limited connectivity, finance reconciliation tools for tracking successes and failures, and a reporting layer to give programme managers and donors a real-time picture of what was happening.
Alongside building the system, we were asked to take on the data cleaning work that no one else had time for. The National Disaster Management Agency (NDMA) had assembled datasets covering roughly 83,000 households, gathered during the nationwide distribution of basic foodstuffs (rice, sugar, and vegetable oil) immediately after the first COVID-19 cases. Before any of those names could become beneficiaries, the data had to be reconciled into a single, trustworthy registry. Finally, we were responsible for training the government staff who would actually run the system once it was live.
It was, in short, the entire operational stack — software, data, and people — and it had to work the first time.
The Unique Challenges
Every project has its difficulties, but Nafa Quick presented a particular cluster of problems that, taken together, made the work unusual. Two of them stand out in retrospect.
The first was the absence of a reliable household list by settlement. The programme target was large and urgent, but the underlying records were not ready for direct use in payment operations. Settlement naming differences, duplicated records, and incomplete fields made it risky to move straight into disbursement. Before any payment flow could be trusted, the registry had to be cleaned and standardised so each settlement and household could be handled consistently.
The second challenge was payment operations in a cash-only model. The payment service provider (PSP) was paying out in cash and did not have time to set up its own MIS or payment platform. That meant there was no direct system-to-system integration path for recording payments at source. We had to design a practical operational flow that could still produce a verifiable, auditable record of who was paid.
How We Approached the Data Problem
The data work happened in parallel with the system build, not before it, because we did not have the luxury of a sequential workflow. The team treated the NDMA data as a single combined registry from day one, building deduplication and standardisation routines that operated across the whole population rather than within each file.
The deduplication logic combined deterministic and probabilistic matching. Where phone numbers, names, and settlements aligned exactly, records were merged automatically. Where matches were partial — a slightly different spelling, a transposed digit in a phone number, a household head listed under different names in two datasets — the records were flagged for human review rather than silently merged or silently kept apart. We were acutely aware that every false merge could exclude a genuine household, and every missed match could double-pay another. Erring in either direction was costly, so the design favoured surfacing ambiguity to a human rather than guessing.
Settlement standardisation was the most laborious piece. The Gambia Bureau of Statistics (GBoS) maintains a recognised settlement list that serves as the standard reference for nationally representative work. The NDMA datasets did not map cleanly onto it. Each unique settlement string was matched, where possible, to a GBoS-recognised settlement using phonetic matching and manual review. The 161 unmatched settlements were investigated one by one with GBoS and NaNA staff and, where genuine, added to a programme-specific extension of the GBoS list with proper documentation. The result was that every beneficiary in the final registry was anchored to a recognised geography — a quiet but important contribution to the credibility of the programme.
The cleaned registry then became the foundation for verification and payment operations, rather than just a reporting asset. In a cash programme, that operational reliability matters as much as technical correctness.
How We Approached Verification and Cash Disbursement
Because the PSP could not integrate with Kaarange directly, and because no reliable per-settlement household list existed at the outset, the operational flow had to be designed from scratch around the constraints rather than against them.
To address both issues, we designed a two-tool KoboToolbox flow: one tool for verification and one for payment confirmation. The verification tool was preloaded with households from the cleaned dataset, and each household received a printed voucher containing a QR code. A few days before disbursement in each settlement, NaNA teams distributed vouchers to household heads.
At the cash transfer venue, each household head first went through NaNA verification. Staff scanned the voucher QR code in KoboToolbox and checked the person's valid ID against the household details on the tool. If the details matched, the voucher was stamped and signed, and the person proceeded to the PSP cashier.
The PSP cashier then checked for the NaNA stamp and signature, scanned the same voucher in the payment KoboToolbox tool, paid the beneficiary in cash, and confirmed payment in the tool. 2M Corp later reconciled the verification and payment datasets and entered reconciled records into Kaarange. Two payment rounds were completed over about four months; each round took nearly six weeks and covered all regions except the Greater Banjul Region.
What We Learned
By the time the emergency phase of Nafa Quick was complete, the MIS had supported payments to vulnerable households at national scale, the registry was clean enough to serve as the foundation for further work, and a small team inside NaNA had been trained to operate the system day to day. Kaarange went on to be adopted as the operational platform for the larger, USD 31 million Nafa Project that followed — a quiet but important sign that what had been built under pandemic pressure had been built well enough to last.
A few lessons from that experience have shaped how we have approached every cash-transfer and registry project since.
The first is that data cleaning is not preparatory work — it is the project. The temptation, when timelines are short, is to push data quality into the background and focus on the visible system. The Nafa Quick experience suggests the opposite: investing early and seriously in deduplication, standardisation, and reconciliation against authoritative reference lists pays back many times over, because every downstream operation rests on it.
The second is that systems for moving public money have to be built around reconciliation, not around payment generation. The interesting question is never "did we send the file?" — it is "do we know, line by line, what happened to the money?" Building that visibility into the core of the platform, rather than bolting it on later, changes how a finance team experiences the work.
The third is that emergency programmes deserve the same engineering discipline as long-running ones. It is tempting, when the timeline is short, to cut corners and tell yourself you will tidy up afterwards. In our experience, the systems built under that mindset rarely survive past the emergency. Kaarange did, because the team treated it from the start as infrastructure rather than a stopgap. That mindset is, in the end, the most important thing we took from Nafa Quick.