§ Our commitments · v0.1

The principles this product is built to serve.

ReliefPay operates inside a sector that already has a well-developed ethical framework. We don’t invent principles; we commit to the ones the humanitarian community has agreed on, and translate them into product decisions.

Framework 01

The four humanitarian principles.

Established by UN General Assembly Resolution 46/182 (1991) and refined by Resolution 58/114 (2004), the four principles form the foundation of principled humanitarian action. Every major humanitarian organisation—ICRC, UNHCR, WFP, OCHA, IFRC, and the Sphere network—operates under them.

Humanity

Human suffering must be addressed wherever it is found, with particular attention to the most vulnerable.

Binding on ReliefPay

ReliefPay is designed so that recipients are treated as rights-holders, not suspects. Identity checks happen at case registration, not at the till. The system does not deny a purchase because of a pattern flag or a risk score. Dignity is the default.

Neutrality

Humanitarian actors must not take sides in hostilities or engage in controversies of a political, racial, religious, or ideological nature.

Binding on ReliefPay

Vendor approval on ReliefPay is based on licensing, regulatory compliance, and programme fit—never political affiliation. We do not support configurations that restrict assistance by political identity, faith, or ethnicity.

Impartiality

Assistance must be provided on the basis of need alone, giving priority to the most urgent cases of distress, without discrimination.

Binding on ReliefPay

Eligibility for assistance on ReliefPay is set by the implementing organisation’s verified case files. The platform itself does not apply demographic filters. Allocation policies set by partners are auditable on the ledger, so discrimination becomes visible, not invisible.

Independence

Humanitarian action must be autonomous from political, economic, military, or other objectives that any actor may hold regarding areas where humanitarian action is implemented.

Binding on ReliefPay

Recipient data is held by the implementing organisation, not by ReliefPay. We will not provide individual recipient records to governments, donors, or third parties outside lawful process. We publish transparency reports for any such requests, consistent with the Signal Code for humanitarian data.

Framework 02

The Core Humanitarian Standard.

The CHS, revised in 2024, is the sector’s agreed quality and accountability framework. It sets out nine commitments to the people and communities affected by crisis.

ReliefPay, as infrastructure, supports three of those commitments directly:

CHS 4Communities and people affected by crisis know their rights, have access to information, and participate in decisions that affect them. The recipient view shows available assistance, history, and eligible vendors in the recipient's own language.
CHS 5Communities and people have access to safe and responsive mechanisms to handle complaints. We will build in-product reporting for issues with vendors, allocations, or the platform itself.
CHS 9Resources are managed and used responsibly for their intended purpose, minimising waste. Every allocation and payment leaves an on-chain receipt tagged to the originating case.

Framework 03

Do No Harm.

Do No Harm, developed by Mary Anderson and the Local Capacities for Peace project, asks a simple question of any humanitarian action: could this make things worse?

For a digital payments platform operating in crisis contexts, specific risks include:

Data exposureNo personal identifiers are written to the public ledger. Recipient records stay with the implementing organisation. Case identifiers on-chain are cryptographic hashes of case references, not readable information.
Digital dividePrinted QR codes and card-based fallbacks are an explicit roadmap item for recipients without smartphone access or in low-connectivity environments.
Vendor captureProgramme operators choose vendors; we do not bias vendor recommendations. Vendors may be delisted at any time by implementing partners through on-chain registry updates.
Dependency on platform continuityThe underlying recipient device uses standard smart-account infrastructure. Recovery procedures must be tested and documented before field use, while on-chain allocation and redemption records remain auditable if ReliefPay is unavailable.

Framework 04

Data & dignity.

The Signal Code (Harvard Humanitarian Initiative) sets out five human-rights obligations for humanitarian data. We adopt them as product requirements.

01
Right to information
Recipients see their own available assistance, history, and eligible vendors inside the recipient view. Nothing is hidden from the person the data is about.
02
Right to protection
No personally identifying information is written to the public ledger. Recipient records are held by the implementing organisation and accessible only to their authorised personnel.
03
Right to privacy, security, and ownership
Recipients control the private keys to their wallets. ReliefPay cannot withdraw, transfer, or freeze recipient funds except through the signed authorisation mechanism set by the implementing organisation's policy.
04
Right to data agency
Recipients may request deletion of their case record. The public ledger cannot be rewritten, but personally identifying mappings can be removed from the implementing organisation's database, leaving only an unresolvable hash on-chain.
05
Right to rectification and redress
Errors in allocation or payment are correctable by the implementing organisation through the admin interface, with the correction itself recorded on the ledger.

§ The spine

Configurations we will not build.

A commitment that never says no isn’t a commitment. We will decline to build, and will remove if asked, features that:

Deny assistance based on political affiliation, faith, ethnicity, gender, or sexual orientation.
Share individual recipient purchase history with donors, governments, or third parties outside lawful process.
Impose per-transaction fees extracted from the recipient’s available assistance.
Monetise recipient data, in aggregate or otherwise.
Serve advertising inside the recipient view.
Restrict recipient access to the available assistance already allocated to them, except under the signed conditionality policy set at allocation time.

These constraints are binding on the product regardless of whether we are asked politely, whether it would be commercially advantageous, or whether it would be operationally convenient. Read as a single sentence: we build for recipients first.

§ A living document

This page will change.

We are early. Commitments sharpen as we deploy. When we change this document we will version it and explain what changed, on this page. Version history will be maintained publicly so no commitment can be quietly removed.

If you work in the humanitarian sector and believe a commitment here is incomplete or wrong, please write to us at hello@reliefpay.org. We take sector correction seriously.

Document · Commitments v0.1

Last revised · 21 April 2026

Next review · 21 July 2026

Related · Safeguarding · Security · Pilot partners

← Return to reliefpay.org