UNICEF AidLink: How Blockchain Transforms Humanitarian Cash Transfers

The Problem That Refuses to Go Away

In 2023, the global humanitarian system distributed $55.2 billion in aid. By the most generous estimates, between 15 and 30 cents of every dollar were consumed by intermediary costs -- banking fees, currency conversion, compliance overhead, reconciliation processes, and the logistical friction of moving money across borders and into regions with limited financial infrastructure. The math is straightforward and disturbing: somewhere between $8 billion and $16 billion in humanitarian funding never reached the people it was intended for. Not because of corruption, although that exists, but because the plumbing is inefficient.

Cash and voucher assistance (CVA) has grown to represent over 20% of all humanitarian aid globally, according to the Cash Learning Partnership's 2024 State of the World's Cash report. The shift toward direct cash transfers reflects a growing consensus among aid organizations that recipients are better positioned than distant program designers to determine what they need most. But the infrastructure supporting these transfers was built for a different era. Wire transfers through correspondent banking networks take days, cost percentage-point fees, and provide limited visibility into when funds actually arrive. Mobile money networks have improved last-mile delivery in parts of Africa and Asia but remain fragmented across providers and geographies.

This is the context in which UNICEF's Innovation Fund made a bet. Not on blockchain as an abstract technological advancement, but on blockchain as the missing infrastructure layer that could make humanitarian cash transfers transparent, traceable, programmable, and dramatically cheaper. That bet produced AidLink.

What AidLink Actually Is

AidLink is not a single application. It is a modular pipeline composed of three distinct components, each built by a different organization, each recognized as a Digital Public Good, and each designed to be independently useful while becoming more powerful in combination.

The first component is Rumsan, built by the Rumsan team in Nepal. Rumsan handles beneficiary registration and management -- the process of identifying who should receive aid, verifying their eligibility, and creating the digital identities that enable them to receive funds. This sounds simple until you consider that many humanitarian beneficiaries lack government-issued identification, live in areas without internet connectivity, and may be displaced or mobile. Rumsan addresses these constraints with offline-capable registration, biometric alternatives to document-based ID, and a flexible data model that accommodates the messy realities of humanitarian field operations.

The second component is Shelter, built by Xcapit. Shelter is the disbursement engine -- the system that takes a donor's funds, converts them into blockchain-based stablecoins, and distributes them to verified beneficiary wallets according to programmatic rules. I will go into much more detail on Shelter below, because it represents a significant strategic investment for Xcapit and embodies lessons from five years of building blockchain infrastructure for social impact.

The third component is Kotani Pay, built by the Kotani Pay team in Kenya. Kotani Pay handles last-mile conversion -- the process of turning blockchain-based assets into local currency that beneficiaries can actually spend. In many target regions, that means conversion to mobile money (M-Pesa, Airtel Money) or cash through agent networks. Kotani Pay integrates with mobile money providers across multiple African markets and is expanding into Latin America, creating a bridge between the on-chain world and the local economies where beneficiaries live.

The Architecture of Trust

What makes AidLink architecturally significant is not any individual component but the way they compose. Traditional humanitarian cash transfer systems are monolithic -- a single organization or platform handles everything from beneficiary registration to disbursement to reconciliation. This creates vendor lock-in, single points of failure, and opacity. When something goes wrong, it is difficult to determine where in the pipeline the failure occurred.

AidLink's modular design means that each component operates independently and communicates through well-defined interfaces. Rumsan produces verified beneficiary lists. Shelter consumes those lists and executes disbursements on-chain. Kotani Pay monitors on-chain disbursements and triggers last-mile conversion. At every step, the blockchain provides an immutable record of what happened, when it happened, and to whom. This is not theoretical transparency -- it is practical auditability that allows donors, implementing organizations, and oversight bodies to verify the flow of funds in near-real-time.

The stablecoin layer is worth emphasizing. AidLink uses USDC and USDT on low-cost blockchain networks (Polygon, Celo, and Stellar depending on the deployment context) to denominate transfers in stable value. This eliminates the exchange rate risk that plagues traditional cross-border transfers and allows beneficiaries to receive funds denominated in a value they can understand and plan around, regardless of local currency volatility. For populations in countries experiencing high inflation -- Argentina, Venezuela, Lebanon, parts of sub-Saharan Africa -- this is not a convenience feature. It is a fundamental improvement in the quality of the aid received.

The Cusco Pilot: 270 Beneficiaries, Zero Intermediary Banks

In late 2024, we ran the AidLink pilot in Cusco, Peru with 270 beneficiaries. The choice of Cusco was deliberate -- it represented the intersection of several constraints that any global humanitarian system must handle. Limited banking infrastructure in surrounding rural communities. Inconsistent internet connectivity. A population that includes indigenous Quechua speakers with varying levels of digital literacy. If the system worked in Cusco, it could work in most deployment contexts worldwide.

The pilot ran for three months. Beneficiaries were registered through Rumsan's field-based process, which used community health workers already embedded in the target population as registration agents. Each beneficiary received a blockchain wallet through Shelter -- some accessed via smartphone app, others via our SMS-based wallet for feature phone users. Disbursements were triggered by the implementing organization through Shelter's dashboard, with funds arriving in beneficiary wallets within seconds of the transaction being confirmed on-chain.

The results were concrete. Average transaction cost was $0.27, compared to $3 to $12 for traditional wire transfer channels to the same region. Settlement time was under 30 seconds, compared to 3 to 5 business days for correspondent banking transfers. One hundred percent of disbursed funds reached beneficiary wallets -- there was no leakage, no unexplained deductions, no reconciliation gaps. Every transaction was verifiable on-chain by any party with the transaction hash.

• 270 beneficiaries registered and onboarded across urban Cusco and surrounding rural communities
• Average disbursement cost of $0.27 per transaction versus $3-$12 through traditional banking channels
• Sub-30-second settlement time from disbursement trigger to funds in beneficiary wallet
• 100% of disbursed funds reached beneficiary wallets with full on-chain traceability
• SMS-based wallet access enabled participation by beneficiaries without smartphones or internet
• Native Quechua language support in wallet interactions, reducing barriers for indigenous beneficiaries
• Three-month pilot duration with recurring disbursements, testing the system across multiple distribution cycles

But the numbers, while important, do not capture what I found most significant about the Cusco pilot. What mattered was the operational simplicity. The implementing organization -- a local NGO with no prior blockchain experience -- was able to manage the entire disbursement cycle through Shelter's dashboard without requiring technical support after an initial two-hour training session. The beneficiaries did not need to understand blockchain, stablecoins, or wallets. They received an SMS, they went to a participating merchant, they bought what they needed. The technology was invisible to the people it served, which is exactly how infrastructure should work.

Shelter: From Project Component to SaaS Infrastructure

Shelter began as Xcapit's contribution to AidLink, but it has evolved into something broader. At its core, Shelter is SaaS infrastructure for impact asset distribution -- a platform that enables any organization to programmatically distribute digital assets to large populations with full traceability, compliance controls, and reporting.

The technical architecture reflects five years of lessons from building blockchain systems for social impact. Shelter uses smart contract-based escrow to hold funds until disbursement conditions are met -- conditions that can be as simple as a date trigger or as complex as multi-party approval workflows. The smart contracts are deployed on EVM-compatible chains, giving organizations flexibility to choose the network that best fits their cost, speed, and regulatory requirements. A chain-agnostic abstraction layer means that the organization using Shelter does not need to understand or choose a blockchain -- they interact with a dashboard and API while Shelter handles the on-chain complexity.

What differentiates Shelter from a generic payment rail is the compliance and reporting layer. Humanitarian disbursements have specific requirements that commercial payment systems do not address: beneficiary privacy protections (many aid recipients are in vulnerable situations where financial visibility could endanger them), donor reporting standards (major donors require specific data formats and audit evidence), and programmatic conditions (funds may be restricted to specific use categories, geographies, or time periods). Shelter encodes these requirements as programmable rules within the smart contract layer, making compliance automatic rather than manual.

We are positioning Shelter not just as a humanitarian tool but as general-purpose infrastructure for any context where verifiable, programmable asset distribution matters. Government social transfer programs -- conditional cash transfers, pension disbursements, emergency relief payments -- face many of the same challenges as humanitarian aid: reaching underserved populations, ensuring funds are not diverted, providing transparent audit trails, and operating at scale with minimal per-transaction cost. Climate finance disbursement -- distributing carbon credit proceeds to communities implementing conservation projects -- requires similar capabilities. Shelter's architecture was designed to serve all of these use cases with minimal customization.

Digital Public Good Recognition: What It Means and Why It Matters

All three components of AidLink -- Rumsan, Shelter, and Kotani Pay -- are recognized as Digital Public Goods by the Digital Public Goods Alliance. This recognition is not honorary. It requires satisfying nine substantive criteria: relevance to the Sustainable Development Goals, use of an approved open license, clear ownership, platform independence, comprehensive documentation, non-extractive data practices, privacy and security safeguards, adherence to applicable standards, and evidence of doing no harm.

The DPG designation matters for several practical reasons. First, it provides a signal of credibility to institutional adopters. When a government ministry or UN agency evaluates technology for humanitarian deployment, DPG recognition indicates that the technology has been independently assessed for openness, safety, and alignment with global development goals. Second, it ensures interoperability and prevents lock-in. Because DPGs must use open licenses and maintain platform independence, organizations adopting AidLink are not dependent on any single vendor. If Xcapit disappeared tomorrow, the Shelter codebase would remain available for any organization to maintain and develop. Third, DPG recognition connects products to a growing ecosystem of institutional support, including funding, implementation partnerships, and policy advocacy.

I want to be direct about what DPG recognition required from us. Making Shelter a Digital Public Good meant open-sourcing code that represents significant proprietary investment. It meant documenting not just the technical implementation but the governance model, the data handling practices, and the potential risks of misuse. It meant submitting to an external review process with no guaranteed outcome. We did this because we believe that humanitarian infrastructure should not be proprietary -- the populations it serves are too important and too vulnerable for vendor lock-in to be acceptable. But I would be dishonest if I did not acknowledge the tension between open-source requirements and commercial sustainability. We resolved that tension by building Shelter as open-source infrastructure with commercial SaaS offerings -- managed hosting, dedicated support, custom integrations -- layered on top. The infrastructure is free. The operational expertise is the product.

Why Blockchain, Specifically

There is a reasonable question that skeptics of blockchain in humanitarian aid ask: why not just use conventional payment rails? Mobile money exists. Bank transfers exist. Prepaid cards exist. What does blockchain add that justifies the complexity?

The answer is four-fold, and each element addresses a specific failure mode of existing humanitarian payment infrastructure.

• Transparency and auditability: On a public blockchain, every transaction is independently verifiable by any party with access to the network. Donors can verify that funds reached intended recipients without relying on the implementing organization's self-reported data. This addresses the trust deficit that has eroded public confidence in humanitarian aid effectiveness.
• Programmability: Smart contracts enable conditional disbursement -- funds that release only when specific conditions are verified, restrictions on use categories, time-locked distributions, and multi-signature approvals. Traditional payment systems require manual enforcement of these conditions, which is expensive and unreliable at scale.
• Speed and cost: Blockchain transfers settle in seconds at costs measured in cents. Cross-border humanitarian transfers through correspondent banking take days and cost percentage-point fees. For emergency response, where timing directly impacts lives, the difference between seconds and days is not an optimization -- it is a fundamental capability shift.
• Interoperability without intermediaries: AidLink connects three independent systems -- Rumsan, Shelter, Kotani Pay -- without requiring a central intermediary to reconcile between them. The blockchain itself serves as the shared ledger. This eliminates the need for bilateral integration between every pair of systems and reduces the number of entities that must be trusted.

None of these advantages require beneficiaries to understand or interact with blockchain directly. This is a critical design principle: the blockchain is infrastructure, not interface. Beneficiaries interact with SMS messages, mobile money accounts, and merchant point-of-sale systems. The blockchain operates underneath, providing the properties that make the system trustworthy without imposing the complexity that would make it unusable.

Scaling from Pilot to Global Infrastructure

The Cusco pilot proved that AidLink works. The next challenge -- and it is a substantially harder one -- is scaling from 270 beneficiaries to hundreds of thousands, across multiple countries, organizations, and regulatory environments.

We are approaching this scaling challenge along three dimensions. The first is geographic expansion. Kotani Pay's mobile money integrations already cover Kenya, Ghana, Nigeria, Uganda, and Tanzania, with expansion into additional African markets and Latin American corridors underway. The second is organizational adoption. We are working with multiple humanitarian organizations to integrate Shelter into their existing disbursement workflows, not as a replacement for their entire technology stack but as a disbursement layer that connects to their existing beneficiary management and reporting systems. The third is regulatory navigation. Every jurisdiction where AidLink operates has different rules for digital assets, cross-border transfers, and data privacy. We are building a compliance framework that is flexible enough to accommodate jurisdictional variation while maintaining a consistent operational model.

The vision is ambitious but grounded in practical architecture: a global humanitarian payment infrastructure where any organization can register beneficiaries, disburse funds on-chain, and enable last-mile conversion -- all with full transparency, at minimal cost, and without requiring any single entity to be trusted with the entire flow. The technology exists. The pilot has proven the model. What remains is the operational work of building partnerships, navigating regulations, and earning the trust of institutions that have been understandably cautious about new technology.

What This Means for Xcapit

I want to close with a reflection on what AidLink and Shelter mean for Xcapit as a company, because the strategic significance extends beyond a single project.

When we started Xcapit, our thesis was that AI, blockchain, and cybersecurity would converge into a unified enterprise technology stack. AidLink validates a specific dimension of that thesis: blockchain as verifiable, programmable infrastructure for high-stakes asset distribution. The same capabilities that make Shelter effective for humanitarian cash transfers -- traceability, programmable compliance, multi-party auditability -- are directly applicable to enterprise use cases in financial services, supply chain, and government operations.

Shelter is also an example of what we believe the best technology companies do: build products that create genuine value for the most challenging users first, then apply those capabilities to broader markets. The constraints of humanitarian deployment -- low connectivity, low digital literacy, high regulatory complexity, zero tolerance for fund leakage -- forced us to build infrastructure that is more robust, more accessible, and more auditable than what we would have built for a comfortable enterprise client. Those properties make Shelter better for every use case, not just humanitarian ones.

We are proud to be part of AidLink and proud to have Shelter recognized as a Digital Public Good. But pride does not scale. Execution does. The work ahead is to take what the Cusco pilot proved and build it into infrastructure that humanitarian organizations worldwide can rely on -- not as an experiment but as a standard operating capability. That is the commitment we are making.

If your organization is involved in humanitarian operations, government social programs, or any context requiring transparent, traceable asset distribution at scale, we would welcome the opportunity to discuss how Shelter and the AidLink pipeline can integrate with your existing workflows. Visit our case studies at xcapit.com/case-studies to see how blockchain infrastructure translates across different deployment contexts, or reach out directly through our contact page.