Cash and Voucher Assistance Platforms: Why Deduplication and Reconciliation Are the Whole Build

Why cash programming is a payments engineering problem with protection consequences

A registration site under a tarpaulin in a district with no mobile data. Four enumerators with tablets, a queue that starts before dawn, and a target of 400 households before the light goes. A woman presents a token issued at a community meeting three weeks ago. Her name is written on it in one transliteration, her national identity document uses another, and the phone number she gives belongs to her brother in law because she does not own a handset. Her household had six members at the last assessment and now has eight, because two nephews arrived after a displacement. The entitlement formula depends on that number. Somewhere in the same district, another agency is registering the same household under a slightly different spelling, and neither team will know until a donor asks why two organisations paid the same family in the same month.

The tooling in this sector is real and some of it is good. RedRose covers registration through payment and has been used at scale. Last Mile Mobile Solutions, built inside World Vision, is genuinely designed for field conditions and offline enrolment. Segovia was built around payment orchestration and has real strengths in getting instruction files to operators. Each of them makes assumptions about your programme model, your identity approach and your payment partners, and those assumptions are the problem, because in cash programming the specifics are the programme.

What none of them holds cleanly is the object your operation actually turns on: a household that exists across agencies, has a composition that changes between tranches, maps to a payment instrument that may not belong to the household head, generates an entitlement under a formula tied to a minimum expenditure basket that gets revised when prices move, and produces a payment that either lands, fails, or lands twice. Across cash and voucher projects we have delivered, the recurring failures are the same three: duplicates discovered after payment, failed transactions that get reissued without a reliable idempotency check, and a donor report that cannot be traced back to named beneficiaries without a week of manual work. The first two cost money. The third costs the next grant.

Problem 1: deduplication has to work across agencies without sharing personal data

Inside one agency, deduplication is difficult. Across agencies it is a coordination problem wrapped in a data protection problem. You cannot simply pool beneficiary lists with three partner organisations, because the personal data of people in a displacement setting is exactly the data that should not be circulating in shared files. Yet the duplicate you need to catch is precisely the one that exists in someone else's list.

What a custom build does: a privacy preserving matching layer where partners exchange salted, hashed identifiers derived from a jointly agreed key set rather than raw names and numbers, plus a review queue for near matches that a human resolves. Fuzzy matching across transliteration variants is where machine assistance genuinely earns its place, generating candidate pairs across Arabic, Latin and local script renderings that a rules based comparison will miss. It generates candidates. It never auto rejects a household, because an incorrect exclusion is a protection incident, not a data quality issue. That distinction has to be built into the workflow, not left to policy.

Problem 2: entitlements change when a household changes, and the formula moves too

The transfer value is not a constant. It usually derives from a minimum expenditure basket calculated per country and revised when market prices or the exchange rate move. It scales with household size, sometimes with a cap, sometimes with a per capita taper. It may carry a top up for a household with a member who has a disability, or for a female headed household, or for a specific vulnerability category. And household composition is not stable between tranches, because people arrive, leave, and are born.

What a custom build does: entitlement rules become configuration with an effective date, so revising the basket in March does not corrupt February's records. Every payment stores the formula version, the household composition snapshot and the resulting amount. When a donor asks why one household received a different amount from its neighbour, the answer is on screen in one query rather than in a programme officer's reconstruction.

Problem 3: payment failure is the normal case, and reissue is where the money is lost

You generate an instruction file for a mobile money operator. Some proportion of transactions fail. Wrong number format. Wallet not registered. Wallet registered to a different national identity document than the one on file, which the operator blocks under its know your customer obligations. Agent has no liquidity in that district today. Network settlement delay so the status is unknown rather than failed. Now somebody has to work out which of those failures should be reissued, to what corrected instrument, and without paying anyone twice.

What a custom build does: every payment carries a deterministic idempotency key derived from beneficiary, tranche and attempt, so a resubmitted batch cannot double pay by construction. Operator responses are ingested as structured statuses, with an explicit unknown state that is never treated as a failure until reconciled. Reconciliation against the operator's own settlement report is a scheduled job, not a monthly manual exercise, and unmatched lines land in a queue with an owner. Agent liquidity by district becomes a visible constraint on when you push a batch, which is the sort of thing only teams that have been burned think to ask for.

Problem 4: enrolment happens where there is no connectivity, and the device is the risk

Field enrolment means tablets that are offline for days, sometimes in settings where the device itself is a hazard if it falls into the wrong hands. Holding a full beneficiary list with names, locations, phone numbers and vulnerability categories on a device that travels through checkpoints is a protection decision, not a technical convenience.

What a custom build does: devices hold only the caseload assigned to that enumerator for that period, encrypted at rest with a key that is not recoverable from the device alone. Sync is one way for new registrations and scoped for updates. Remote revocation exists and has been tested. Conflict resolution is explicit, so a household edited by a supervisor in the office and by an enumerator in the field produces a review rather than a silent overwrite. And enrolment captures the evidence that supports the entitlement, meaning documents and consent, with a defined retention period rather than an indefinite archive.

Problem 5: the audit trail is the deliverable, and screening is not optional

Donors do not fund a payment. They fund a tranche with conditions attached, and they audit the chain from selection criteria through registration, verification, entitlement, payment and post distribution monitoring. If any link is a spreadsheet, the audit finds it. Sanctions screening against consolidated lists is a real obligation for organisations moving funds, and the practical difficulty is that screening produces false positives on common names in almost every context you work in, so the workflow around a hit matters more than the screening itself.

What a custom build does: an append only event log across the whole lifecycle, so nothing is edited silently and the report is generated rather than assembled. Screening runs at registration and again before each payment run, with hits routed to a named reviewer, an evidence record and a documented decision, because the auditable artefact is the decision and not the alert. Grievance and feedback cases attach to the household record, which is how you find out that payments in one district are being intercepted before the pattern becomes a scandal. Confirm your specific screening and know your customer obligations with your legal and compliance function, since they vary by donor, by jurisdiction and by payment partner.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape for this category. A first release covering offline household registration, versioned composition, entitlement calculation, deduplication with a partner matching layer, and payment instruction generation with reconciliation runs $90,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding multi country configuration, vulnerability scoring, e-voucher redemption at contracted vendors, grievance handling, sanctions screening workflow and donor tranche reporting runs $250,000 to $600,000 phased over 9 to 15 months.

What drives the cost up specifically in cash programming: the number of payment partners, because every mobile money operator and bank has its own file format, its own status codes and its own settlement rhythm, and each one is weeks rather than days. Multi country deployment, since the entitlement model, the identity documents and the regulatory position all change. Biometric identity, which we would ask you to justify hard before building, because the protection risk and the operational failure modes are severe and there is often a token or card based alternative that is safer. And offline capability at real scale, which is genuinely more engineering than a connected application.

What keeps the cost down: one country, one payment partner, one programme model in the first release, with the partner matching layer designed in from the start because retrofitting deduplication is far more expensive than building it.

Build versus buy, and when buying is the right call

Buy if you are running a single response with fewer than about 5,000 households, one payment partner, and no cross agency deduplication requirement. RedRose or Last Mile Mobile Solutions will get you registering and paying quickly, and building your own for that would delay assistance to reach a feature set you do not need. Speed matters more than fit at that size, and a slow build in an acute response is a failure whatever the code quality.

Build when two or more of these are true. You operate across multiple partners or a consortium and duplicates are a live disagreement rather than a theoretical one. You run in more than one country with different baskets and identity regimes. Your payment reconciliation currently happens by exporting operator statements into Excel. Your entitlement formula has been revised more than once and you cannot reproduce which version paid which tranche. Or a donor has already raised a finding on traceability.

Our position: the two features that justify a build in this sector are idempotent payment handling and cross agency matching. Everything else is configuration. If a vendor demonstration spends forty minutes on dashboards and four on what happens when a batch is resubmitted after a partial failure, you are watching the wrong demonstration.

How to choose a developer for cash and voucher assistance software

Ask them what happens when a payment batch is resubmitted after a partial failure. The correct answer involves a deterministic idempotency key and an explicit unknown status, and it should come immediately. If the answer is that they would check for existing payments before sending, they have not built a payments system and your money is at risk.

Ask how they think about protection risk in the design, specifically device data scope, retention and the consequence of a false match. A developer who treats a wrongly excluded household as a bug rather than as harm to a person is not ready for this work.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. In humanitarian work, where funding is annual and teams rotate, a vendor holding your repository is an operational risk to the people you serve.