Hope, Hiding in Plain Sight: The Open-Source Cash Platform the Sector Is Not Evaluating

Most of what I have written in this newsletter over the last six months has been a record of things falling apart. The funding architecture coming undone. The Strait of Hormuz closure. The jet fuel cliff. The Iran war. Readers know the arc.

This piece is different. I want to write about something hopeful for once. Not because the underlying problems have eased. They have not. But because in the middle of a sector losing control of its own procurement, there is one specific place where the sector still has agency, and is not using it.

Last week I shared Giulio Coppi Reinventing Humanitarian Aid Procurement for the Age of AI, published by Access Now. It is, in my view, the most important diagnostic piece written on humanitarian digital procurement in the last several years. Coppi's argument is that the "ethical buyer" theory of change has failed. Tech is no longer arriving only through procurement. It is arriving through cloud updates, supplier-pushed features, free-tier accounts and AI-assisted code in systems the agency thought it already owned. The sector has lost the ability to discipline its own technology choices.

That diagnosis is correct, and it is bleak. The piece you are reading now is the constructive counterpart. If Coppi has named what has been lost, this piece is about one specific place where the sector still has a real choice to make, with infrastructure that already exists, code that is already public, and a procurement decision that is genuinely still open.

The hopeful thing is hiding in plain sight. It is on a public website. It is open source. It has been evaluated as a verified Digital Public Good. It is already running at scale across thirty-three countries. And almost no one outside UNICEF-led implementations is treating it as deployable sector infrastructure.

It is called HOPE. UNICEF describes it as the Humanitarian cash Operations and Programme Ecosystem. That name is more accurate than calling it a cash transfer system. HOPE handles registration, deduplication, target population management, payment-list workflows, financial service provider integration, reconciliation, grievances and reporting. It is the operational spine underneath cash and basic-needs programmes, not just the bit that moves money. The name is also a coincidence that has become slightly inconvenient in this piece, because I want to talk about both the system and the thing it represents. Bear with me.

There is a fuller working paper behind this blog. It gives the sources, the limitations, the Ukraine evidence, the Sudan and Somalia examples, and the procurement argument in a more formal register. This piece is the short version.

https://www.researchgate.net/publication/404720980_Hope_Hiding_in_Plain_Sight_A_Practitioner_Perspective_on_UNICEF_HOPE_and_Humanitarian_Cash_Management_Infrastructure

What HOPE actually is

HOPE is the boring backbone of cash programming. The unglamorous part. The bit nobody writes a glossy report about because it does not photograph well.

When an aid agency runs a cash programme, there is a visible front end, the families who receive the money, and an invisible back end that does the work of making sure the right families get the right amount on the right day without being paid twice and without their data leaking.

The invisible back end is where most of the cost sits, and where most of the failures sit. Duplicate payments. Beneficiaries who fall through the cracks. Reconciliation nightmares with financial service providers. Grievances that go nowhere.

HOPE is the software that does that invisible work. It registers families and individuals. It supports deduplication against the existing population. It creates target populations. It produces payment lists. It sends those lists to financial service providers. It reconciles them when they come back. It handles grievances and feedback. It enforces role-based access, so that not everyone can see or do everything. It produces reporting on the programme.

None of that is glamorous. But every cash and basic-needs programme above a minimal scale needs to do those things, every time. Many still do them with some combination of Excel, ageing bespoke databases, generic CRMs and expensive vendor platforms that lock the agency in for years.

HOPE has been running since 2021. UNICEF's own published figures say it is serving 25 million people in 33 countries. The Digital Public Goods Alliance profile lists it as a verified Digital Public Good, with the main platform licensed under AGPL-3.0. UNICEF's GitHub repository is public. The documentation is public. The installation guide is public. The source-code reference lists the main HOPE repository, the Deduplication Engine, the Payment Gateway and the Country Report component.

In 2022 I worked as a Social Protection and Humanitarian Consultant for UNICEF on the Ukraine response, contributing to inter-agency deduplication systems across Ukraine, Moldova, Poland and Slovakia. I watched HOPE take live load through some of the hardest weeks of my career. The system held. Anyone who has launched a registration platform in the first weeks of a major emergency knows what that means.

The hidden bit that matters

There is a specific capability inside HOPE that deserves its own conversation. It is not just the payment list. It is the population layer underneath the payment list.

The phrase for this is usually integrated beneficiary registry, or IBR. That makes it sound more complicated than it is. In plain English, it means one operational record for a household inside the response, with the assistance, payments, grievances, follow-up and programme history attached to that record.

It is important not to overclaim this. A humanitarian IBR is not a social registry. A social registry is the population-wide dataset that some governments maintain to assess households for social protection programmes. Türkiye has a strong integrated social assistance system. Ukraine has national social protection infrastructure. Sudan and Somalia do not have equivalent population-wide systems that a humanitarian response can simply plug into.

So an IBR cannot tell you who has received nothing if the response has never registered that household. It cannot magically solve the denominator problem. It cannot replace needs analysis, displacement tracking, IDP enumeration or household surveys.

What it can do is tell you what is happening inside the registered caseload. That matters more than it sounds.

If the same registered household has received cash from one agency, food from another, a hygiene kit from a third and a shelter item from a fourth, the registry can show that as one household with four linked assistance records. If another registered household in the same location has only received cash, the registry can show that too. What the registry cannot show is the household no one has reached and no one has registered. That household does not exist in the data. But the thing most responses do not have is a reliable view of what is happening inside the registered caseload they do know about.

The full paper goes into the IBR and social-registry distinction in more detail. The simple version is this: an IBR does not see the whole population, but it lets the response see itself.

The architecture that cash broke

The humanitarian reporting system is still built around what OCHA now calls the 5W: who is doing what, where, when and for whom. The fifth W, for whom, is the part that matters here. It tries to capture targeted and reached beneficiaries alongside the activity. In practice the for-whom data is reported in aggregate. Number of women reached. Number of children reached. Number of households in a district. Not household-level records.

Each cluster reports its own work. Food distributions go into the Food Security Cluster's reporting. Hygiene kits go into WASH. Shelter materials and non-food items go into Shelter/NFI. Health activities go into Health. Protection activities go into Protection. Cash and voucher assistance usually goes into the Cash Working Group.

That structure made sense when most assistance was in kind. If you gave a household a food kit, that was food assistance. If you gave a household a hygiene kit, that was WASH assistance. The modality and the sector were the same thing.

Cash breaks that assumption.

A household that receives multi-purpose cash may spend it on food, rent, debt, medicine, transport, school fees, water, hygiene items or all of those at once. The transfer is reported through the Cash Working Group, but the needs it helps meet sit across every cluster.

This does not mean the Food Security Cluster can simply count every cash recipient as food coverage. It cannot. Post-distribution monitoring can estimate expenditure patterns, but it cannot turn unrestricted cash into exact sector outputs at household level. The real problem is deeper. Cash makes sectoral attribution structurally ambiguous.

So the Humanitarian Coordinator can ask a simple question: how many households in Khartoum North received both food support and hygiene support this month?

The architecture cannot answer.

Food Security can say how many households it reached with food activities. WASH can say how many households it reached with hygiene activities. The Cash Working Group can say how many households received cash. But if the data has already been aggregated by cluster, modality, location and month, no one can say whether those are the same households or different households.

That is not a data hygiene problem. It is a design problem.

There are two ways to fix it. One is structural. The other is technical. The honest answer is that the sector needs both.

The structural fix is visible in some UNHCR-led refugee responses. It is called the Basic Needs Working Group, or BNWG. A BNWG does not abolish sector coordination, and it does not solve every information problem. But it creates a forum where cash, assistance baskets and household basic-needs outcomes can be discussed across modalities, rather than treating cash as a parallel lane beside food, WASH, shelter and other sectors. Jordan, Türkiye, Egypt and Moldova all have versions of this model. The OCHA-led IDP side has been slower to adopt anything equivalent because cluster coordination is harder to restructure than refugee coordination. The cluster system is older, has more agencies, more donor budget lines and more institutional inertia. Moving from parallel sector reports to an integrated basic-needs view is a political project, not a technical one.

The technical fix is what the rest of this piece is about. An integrated beneficiary registry changes the unit of analysis. The primary record becomes the household, not the cluster report. Cluster reporting still exists, but it becomes a derived view from the registry. The response can still report food, WASH, shelter and cash activity. It can also answer the more important question: what did this household actually receive?

This is the kind of data structure HOPE provides. The population-management layer, the linked assistance records and the household-level reporting are not bolt-ons. They are part of the architecture. An agency running cash and basic-needs programmes on HOPE has much of the data structure that an integrated beneficiary registry requires. The cluster-by-modality failure described above is the kind of problem a HOPE-style registry layer is well placed to address.

The structural fix and the technical fix are complements, not alternatives. A Basic Needs Working Group without a household-level data layer will still run into the same aggregation problem at scale. An integrated beneficiary registry without a coordination structure that integrates across modalities will produce technically excellent data into an organisational architecture that cannot act on it. The two need to move together.

It is worth being honest about why some refugee responses got closer to this first. Coordination at household level is easier when there is a mandated registration authority and a common case record. In many refugee responses, UNHCR, or a government system working with UNHCR, provides a more centralised population record than exists in most IDP responses. Partners coordinate around a population the system at least partly knows. The household-level visibility problem is largely solved upstream by the registration mandate, before any working group sits down. What looks like an integrated beneficiary registry in a refugee response is closer to a single-agency registry that other agencies coordinate against.

That is precisely the problem in IDP responses. No single agency owns the registration. Caseloads are built by each implementing partner against their own programmes. The cluster system aggregates the activity afterwards. Inter-agency household-level visibility has to be constructed deliberately because it does not arrive for free with the coordination architecture. This is exactly where a shared integrated beneficiary registry layer matters. It is the harder problem, and it is the one most IDP responses have not solved.

Some refugee responses noticed cross-modality coordination years ago and restructured. Most IDP responses have built neither the coordination structure nor the underlying data layer that would make such a structure operationally workable at scale.

That is the architectural failure the full paper is really about. HOPE is the case study, but the bigger argument is that cash has outgrown the reporting model it is being forced into, and the sector already knows what a better model looks like.

What this looks like in Khartoum

Take Sudan.

The 2024 Sudan Humanitarian Needs and Response Plan sought about $2.7 billion and was 70.6 percent funded through the plan by year-end. The 2025 plan was scaled to about $4.2 billion and sits, on current financial reporting, at around 40 percent funded. The 2026 plan has been prioritised down to about $2.9 billion in country, targeting 20.4 million people against 33.7 million people in need.

That is the real story. Need has risen. The response is being forced to narrow.

Inside that kind of funding environment, the Humanitarian Coordinator's problem is not theoretical. It is a cut problem. If there is not enough money, who stays in the caseload? Which households can be rotated out without doing the most harm? Which areas are receiving overlapping assistance? Which registered households have received cash but no WASH support? Which have received food repeatedly but no shelter support? Which households have not been reached since registration?

The current architecture can answer some of that at the aggregate level. It cannot answer it cleanly at household level.

With an IBR underneath the response, the view changes. A registered household in Khartoum North has one record. Food from Agency A, cash from Agency B and hygiene support from Agency C sit against that record. The cluster reports can still be produced, but the coordinator can now ask cross-modality questions.

How many registered households in this location received food and hygiene support this month? How many received cash but no in-kind support? How many households with a recorded vulnerability profile received nothing in the last payment cycle? How many were selected by two agencies for the same transfer objective?

Again, be honest about the limit. This only works for the registered caseload. A household the response has never registered will not appear in the registry. The denominator still has to come from needs analysis, displacement tracking, community reporting, IDP enumeration and assessment work. Those remain weak in many responses.

But even that bounded visibility is valuable. In a funding crisis, the most painful decisions are often about the known caseload. The question is not always "who exists?" Sometimes it is "of the people we already know about, who is receiving what, who is receiving nothing and where are we duplicating?"

That is answerable. Or it should be.

Somalia tells the same story in another setting. The 2025 Somalia plan was launched at $1.42 billion to assist 4.6 million people. By mid-year, it had been reprioritised down to $367 million and 1.3 million people. More than three million people were dropped from the original target. An IBR would not have produced the missing funding. It would have made the decision about the registered caseload more defensible.

Ukraine proves the defensive value

The defensive value of shared infrastructure is easier to price than the affirmative value.

Ukraine has the numbers.

The July 2025 Ukraine Cash Working Group data management assessment reports that by the end of 2024 deduplication systems had saved an estimated $207 million in duplication in Multi-Purpose Cash disbursements. Sectoral CVA savings using related platforms are publicly reported at about $23 million. Sixty-three partners are enrolled in MPC deduplication. Sixteen use the Rapid MPC deduplication function.

That is an estimated $230 million in duplication avoided across MPC and sectoral CVA combined.

The system that has to be named here is WFP's Building Blocks. Building Blocks has been central to Ukraine's deduplication success. WFP says the platform has helped avoid more than $270 million in unintended assistance in Ukraine since 2022, and CALP's Ukraine analysis describes the response as having advanced in deduplication through WFP's Building Blocks. The OCHA CWG figure and the WFP figure are not the same number because they cover different timeframes and scopes. The OCHA figure aggregates MPC deduplication savings reported by CWG partners through end-2024. The WFP figure is the platform's own cumulative total since 2022. Both can be accurate.

This matters because Ukraine does not prove the sector lacks deduplication infrastructure. It proves the opposite. When the sector builds shared infrastructure and agencies actually use it, the savings are enormous.

The argument for HOPE sits one layer wider. Building Blocks addresses the inter-agency overlap and assistance-coordination problem. HOPE addresses the agency cash operations layer: registration, population management, targeting, payment lists, financial service provider transmission, reconciliation, payment verification, grievances, feedback and reporting.

The point is not that HOPE replaces Building Blocks. The point is that Ukraine has already proved shared infrastructure pays for itself. The question is why the sector has not applied the same public-good logic to the broader cash management layer.

So why is nobody using it?

The answer is not, I think, that the code is bad. I have looked at it. The architecture is sensible. The documentation is better than many humanitarian systems. The licensing is clean.

The answer is what is missing around it.

When agencies need participant data infrastructure, they usually fall into three patterns.

The first is commercial SaaS, like ActivityInfo. ActivityInfo is good software. It is used across humanitarian and development contexts for data collection, reporting, monitoring, case management and coordination. Many agencies use it as a hosted subscription service, although self-managed options exist. It solves a real problem. It also leaves the agency dependent on a vendor's pricing, roadmap and support model.

The second is generic open-source CRM, like EspoCRM. The licence cost is low. The deployment cost is whatever it takes your team to configure, secure and maintain it. If you have the technical staff, it can work. If the one person who understands the deployment leaves, the system becomes a liability.

The third is enterprise CRM, usually a customised Salesforce instance. It works. It has mature workflow tools, role-based access control and integrations. It is also expensive, and recurring licensing costs become a strategic problem when funding collapses.

Three options. None of them are HOPE.

The reason is not that HOPE is unavailable. The source code is public. The reason is that HOPE is not yet available in the way a stressed country office needs a system to be available. It does not have a visible ecosystem of consultants, hosted-service providers, deployment playbooks, training packages, security review pathways and support partners who can make adoption feel safe.

That is what KoBoToolbox, ODK and RapidPro have. Their GitHub metrics are not the point. The ecosystem is the point. Small NGOs can use those tools because there are people around them who know how to deploy, adapt, host and support them.

HOPE does not yet have that ecosystem outside UNICEF-led implementations.

That is the gap.

The core should not be captured by the market

There is nothing wrong with paying firms to implement, host, secure or support humanitarian software. HOPE will probably need that ecosystem if it is ever going to travel beyond UNICEF.

But there is a line.

The core registry, data model, deduplication logic, payment-management workflow and governance templates should not be owned by a vendor whose commercial interest is to make the agency dependent on its platform. A market can support the public good. It should not own the spine.

The procurement reflex is still to buy the vendor. That reflex made sense for a long time. Vendors did not just sell code. They sold assurance. They sold hosting. They sold support. They sold someone to call when the system broke.

Open source often sold possibility without responsibility. That is why the vendor won.

The problem is that the conditions have changed. The sector is now in a funding crisis. Recurring licence costs matter more. Public-good infrastructure exists. And the cost of evaluating that infrastructure has fallen.

What changed

I want to be careful here because AI hype has done real damage to credibility in this sector.

I am not saying AI will solve this. I am not saying anyone with a laptop can deploy production cash infrastructure. I am not saying HOPE is suddenly easy.

The claim is narrower.

The cost of serious evaluation has fallen.

With agentic coding tools like Claude Code, OpenAI Codex, Cursor and others, a competent technical person can now understand a complex codebase much faster than before. They can map the architecture. They can trace workflows. They can identify integration points. They can draft deployment notes. They can stand up a sandbox. They can ask better questions before the agency commits to a vendor contract.

That is not production deployment. Production still needs senior review, security assurance, data protection, hosting decisions, backups, incident response, user support, release management and governance.

But it changes the procurement question.

A year ago, an agency could plausibly say the open-source comparator was too expensive even to evaluate. That argument is much weaker now. If you are about to sign a multi-year beneficiary management or cash platform contract, the cost of a serious HOPE feasibility assessment is small compared with the decision you are making.

The realisation has not landed

The thing I keep coming back to is that the sector has not had its moment of recognition yet.

The capability is there. The code is public. The platform is running. The lesson from Ukraine is clear. Shared infrastructure pays for itself. The procurement reflex has not updated.

Somewhere in your organisation right now, someone is putting together the budget for next year's beneficiary management platform. That budget probably assumes the rules of twelve months ago. Those rules have changed.

HOPE may not be the right answer for every agency. That is not the point. The point is that a production-grade, open-source humanitarian cash management platform exists, has run at scale, and is barely being evaluated by the organisations now signing expensive multi-year platform contracts.

In 2026, that is no longer defensible.

The answers are not all built. Governance remains hard. Protection risks are real. Implementation capacity is uneven. But enough is built to change the default question.

The default should no longer be: which vendor do we buy?

It should be: what public-good infrastructure already exists, what would it cost to adapt, and why are we signing a proprietary contract before answering that?

I am happy to spend an afternoon, in the next few weeks, walking through how I would approach a HOPE evaluation for a small INGO with one technical staff member and an agentic coding subscription. If that is useful to you, write to me. I will collect the questions and answer them in a follow-up piece.

For now, please share this with the cash programme manager in your organisation, the country director who has just signed off on the next platform contract, and the donor desk officer who is about to approve the next round of grants.

The realisation has not landed. The piece's job is to land it.

Tom Byrnes is CEO of MarketImpact Digital Solutions and writes Aid & Dev Dispatches. He served as Social Protection and Humanitarian Consultant for UNICEF on the Ukraine response in 2022, including work connected to inter-agency deduplication systems. The full working paper behind this piece includes the disclosure, limitations and references in full.

Sources

Anthropic (2026) Claude Code overview. Available at: https://code.claude.com/docs/en/overview (accessed 11 May 2026).

CALP Network (2024) Humanitarian Cash and Voucher Assistance in Ukraine: Recommendations for a Better Cash Response. Available at: https://www.calpnetwork.org/publication/humanitarian-cva-in-ukraine-recommendations-for-a-better-cash-response/ (accessed 11 May 2026).

Coppi, G. (2026) Reinventing Humanitarian Aid Procurement for the Age of AI. Access Now. Available at: https://www.accessnow.org/ai-infiltrating-humanitarian-aid/ (accessed 11 May 2026).

Cursor (2026) Cursor: the best way to code with AI. Available at: https://cursor.com/ (accessed 11 May 2026).

Digital Public Goods Alliance (2025) HOPE: Humanitarian cash Operations and Programme Ecosystem (DPG profile). Available at: https://www.digitalpublicgoods.net/r/hope-humanitarian-cash-operations-and-programme-ecosystem (accessed 11 May 2026).

OCHA (2026a) Sudan Humanitarian Needs and Response Plan 2026: Summary. Available at: https://www.unocha.org/publications/report/sudan/sudan-humanitarian-needs-and-response-plan-2026-summary (accessed 11 May 2026).

OCHA (2026b) Global Humanitarian Overview 2026: Sudan. Available at: https://humanitarianaction.info/plan/1514 (accessed 11 May 2026).

OCHA Financial Tracking Service (2024) Sudan Humanitarian Needs and Response Plan 2024 (Plan 1188). Available at: https://fts.unocha.org/plans/1188/summary (accessed 11 May 2026).

OCHA Financial Tracking Service (2025) Sudan Humanitarian Needs and Response Plan 2025 (Plan 1220). Available at: https://fts.unocha.org/plans/1220/summary (accessed 11 May 2026).

OCHA Somalia (2025) Somalia: The Cost of Inaction, July 2025. Available at: https://www.unocha.org/publications/report/somalia/somalia-cost-inaction-july-2025 (accessed 11 May 2026).

OCHA/Ukraine Cash Working Group (2025) Ukraine CWG Data Management, Systems and Governance Assessment Report, July 2025. Available at: https://www.unocha.org/publications/report/ukraine/ukraine-cwg-data-management-systems-and-governance-assessment-report-july-2025 (accessed 11 May 2026).

OpenAI (2025) Introducing Codex. Available at: https://openai.com/index/introducing-codex/ (accessed 11 May 2026).

UNHCR (2019) Basic Needs Working Group Terms of Reference. UNHCR Operational Data Portal. Available at: https://data.unhcr.org/en/documents/details/68073 (accessed 11 May 2026).

UNHCR Jordan (n.d.) Basic Needs Working Group: Jordan. UNHCR Operational Data Portal. Available at: https://data.unhcr.org/en/working-group/44 (accessed 11 May 2026).

UNHCR Türkiye (n.d.) Basic Needs Working Group: Türkiye. UNHCR Operational Data Portal. Available at: https://data.unhcr.org/en/working-group/74 (accessed 11 May 2026).

UNICEF (n.d.) UNICEF Humanitarian cash Operations and Programme Ecosystem (HOPE) repository. GitHub. Available at: https://github.com/unicef/hope (accessed 11 May 2026).

UNICEF (n.d.) HOPE: User Manual and Documentation. Available at: https://www.unicef.org/hope-hct/ (accessed 11 May 2026).

UNICEF Office of Innovation (2026) Advancing Sustainable Funding for UNICEF Digital Public Goods. Available at: https://www.unicef.org/hope-hct/stories/advancing-sustainable-funding-unicef-digital-public-goods (accessed 11 May 2026).

United Nations Somalia (2025) Humanitarian partners seek US$1.42 billion to assist 4.6 million people in Somalia in 2025. Available at: https://somalia.un.org/en/288199-humanitarian-partners-seek-us142-billion-assist-46-million-people-somalia-2025 (accessed 11 May 2026).

World Food Programme (2026) Building Blocks. WFP Innovation Accelerator. Available at: https://innovation.wfp.org/project/building-blocks (accessed 11 May 2026).

Byrnes, T. (2026) Hope, Hiding in Plain Sight: A Practitioner Perspective on UNICEF HOPE and Humanitarian Cash Management Infrastructure. ResearchGate working paper. DOI: 10.13140/RG.2.2.21550.06728. Available at: https://www.researchgate.net/publication/404720980_Hope_Hiding_in_Plain_Sight_A_Practitioner_Perspective_on_UNICEF_HOPE_and_Humanitarian_Cash_Management_Infrastructure (accessed 11 May 2026).