How we handle personal information.
ReliefPay operates on the principle that data about people in crisis can harm people in crisis. This policy reflects that. It is written to be read, not filed.
The short version.
If you only read one section, read this one.
- We collect the minimum necessary to run the service. If we do not need it, we do not ask for it.
- Personal data about recipients of humanitarian assistance is held by the implementing organisation, not by ReliefPay. We do not maintain a global database of recipients.
- No personally identifying information is written to the public blockchain. Case identifiers on-chain are cryptographic hashes, not readable data.
- We do not sell personal data. We do not share it with advertisers. We do not use it for marketing beyond replying to enquiries you send us.
- You may request access, correction, or deletion of your personal data at any time by writing to hello@reliefpay.org.
Who we are.
ReliefPay is a humanitarian payments infrastructure project, currently operated as a sole-trader venture pending incorporation as a legal entity in Sweden or South Africa.
The data controller for the purposes of the UK GDPR, EU GDPR, South African POPIA, and equivalent legislation is Nicolas Nel, contactable at hello@reliefpay.org.
Once ReliefPay is formally incorporated, this document will be updated to reflect the operating entity and its registered office. The change will be version-logged at the end of this page.
Where ReliefPay is deployed under an agreement with a humanitarian organisation, that organisation is the data controller for recipient personal data. ReliefPay acts only as a data processor under the implementing organisation’s instructions.
The data we hold.
Organised by role, because different people using the site generate different data.
- IP address, browser type, and operating system (standard server logs, retained 30 days).
- Pages visited and referrer (if any), for basic diagnostics.
- No analytics cookies. No advertising pixels. No cross-site trackers.
- Email address, name, and the contents of your message, when you write to hello@reliefpay.org.
- Retained for up to three years for legitimate business correspondence, then deleted unless an ongoing relationship exists.
- A smart-account wallet address, derived from the Google login used via thirdweb's in-app wallet service. This address is pseudonymous; it is not linked to your real name by ReliefPay.
- Session state (connection status, active role) stored in your browser for the duration of the visit.
- Any demo data you generate (example allocations, redemptions, QR signatures) recorded in our Supabase database and on the public test registry.
- Important: the prototype is for evaluation. Do not use real personal information. Demo data is not treated as sensitive.
- ReliefPay does not hold personal data about recipients of humanitarian assistance on our infrastructure.
- Name, case reference, household composition, eligibility status and similar are held by the implementing humanitarian organisation in their own systems.
- What ReliefPay processes on their behalf is limited to: a pseudonymous wallet address, a cryptographic hash of the case reference, allocation and redemption amounts, and timestamps.
- Under this arrangement the implementing organisation is the data controller. ReliefPay acts only as a processor under instructions.
- Shop name, contact phone, approved programme, terminal access status, and settlement history.
- Bank name, bank routing code, account holder name, and account number when a vendor chooses to save payout details.
- The browser sees a masked account number after save. The raw account number is used server-side only for settlement processing and support.
- Vendor payout details are used only to pay approved vendor claims, verify settlement readiness, prevent fraud, and keep the audit record.
Data on the blockchain.
Public blockchains have privacy properties that differ from conventional databases. We take them seriously.
ReliefPay uses a public blockchain (currently the Public test network, mainnet equivalents in production) to record allocations, redemptions, and the contracts that govern them. Data on a public blockchain is world-readable, permanent, and cannot be edited or deleted.
Because of this, we write to the chain only what is strictly necessary and only in privacy-preserving form:
- Wallet addresses. Pseudonymous 42-character hex strings. Not linked to real names on the chain itself.
- Case identifiers. A cryptographic (keccak256) hash of the case reference used in the implementing organisation’s database. The hash cannot be reversed to recover the original reference.
- Amounts and timestamps. Numeric values, publicly visible.
- Never written to the chain: names, identity documents, contact details, household composition, demographic categories, geolocation beyond broad programme region, or any information that would directly identify an individual.
A motivated analyst combining on-chain data with external sources could, in theory, link a wallet to a real person. This is a known risk of any public blockchain. We mitigate it by rotating wallet addresses where operationally possible, keeping personal mappings off-chain, and advising implementing organisations on deanonymisation risk in their specific contexts.
Why we process data.
Under GDPR Article 6 and POPIA Section 11:
- Contact correspondence: legitimate interest in responding to people who write to us, and, for partnership discussions, steps taken at your request before entering a contract.
- Prototype usage: legitimate interest in operating a demonstration system, and, for the wallet session, performance of a service you have actively initiated.
- Server logs and security: legitimate interest in securing the service against abuse.
- Production deployments: processed under instructions from the implementing organisation, whose lawful basis is typically its own public interest or vital interests of the recipients (GDPR Article 6(1)(d) or (e)).
- Vendor payout details: performance of the vendor settlement service requested by the approved vendor and implementing organisation, plus legitimate interest in fraud prevention, auditability, and support. Vendors confirm the payout notice before saving or replacing bank details.
Who sees what.
Under no circumstances does personal data collected by ReliefPay get sold, rented, or shared with third parties for their own marketing purposes. Not now, not under acquisition, not if we are offered money for it. This is not a promise we ever intend to modify.
We rely on the following infrastructure providers, each of whom processes data strictly under our instructions:
- Vercel (USA, Frankfurt): hosts the web application. Sees server logs.
- Supabase (USA, EU): the database behind the prototype. Holds demo seed data and contact-form records.
- thirdweb (USA): wallet authentication and blockchain RPC. Handles Google login and smart-account derivation.
- Google (USA): Google Fonts (served by Next.js) and, for anyone signing into the prototype with a Google account, the authentication process itself.
- Flutterwave: payout rail for approved vendor settlements when an implementing organisation enables it. Only the fields required to route or reconcile a payout are shared, such as bank code, account number, account holder, amount, currency, reference, and settlement status.
- Public blockchain infrastructure: Public test network validators, and, in production, Ethereum mainnet or Polygon validators. These are decentralised and do not act under our instructions; what is written to the chain is described in section 03.
We will comply with lawful requests from competent authorities (court orders, subpoenas, or equivalent). We will resist bulk data requests, will not volunteer data beyond what is specifically compelled, and will inform affected individuals unless legally prohibited. We commit to publishing a transparency report describing requests received.
Where your data goes.
ReliefPay is currently operated from Sweden and South Africa. Our infrastructure providers are primarily US-based, with EU data-residency options we use where available.
Transfers of personal data out of the UK, EEA, or South Africa occur under the following safeguards, depending on provider and jurisdiction:
- EU-US and UK-US Data Privacy Framework adequacy decisions, where the provider is certified (currently Vercel, Supabase via Amazon Web Services, and Google).
- Standard Contractual Clauses (EU Commission 2021) for providers not covered by DPF.
- For transfers involving South African data: POPIA Section 72 requirements including equivalent protection assessments.
A transfer impact assessment is available on request to implementing partners who require it for their own compliance.
How long we keep things.
- Server logs: 30 days.
- Contact-form records: up to 3 years, then deleted unless an ongoing relationship exists.
- Prototype demo data: retained for the lifetime of the prototype; routinely reset during development. Not treated as sensitive.
- On-chain records: immutable and permanent. Cannot be deleted. This is an inherent property of public blockchains and a reason we minimise what is written there in the first place.
- Production deployment data: retention is set by the implementing organisation under their contractual agreement with ReliefPay.
What you can ask us to do.
Under GDPR, UK GDPR, POPIA, and equivalent laws you have rights in relation to personal data we hold about you. They include:
Data about children.
The public website and prototype at reliefpay.org are not directed at children and we do not knowingly collect personal data from anyone under 18 via the site.
In production humanitarian deployments, recipients are typically adults who may be parents or guardians of children in their household. Information about those children (ages, household size, needs) is held by the implementing humanitarian organisation, not by ReliefPay. Where we process anything that relates indirectly to a minor in a recipient household, we do so only under the instructions and lawful basis of the implementing organisation, which carries the safeguarding responsibility. See our Safeguarding statement for more.
How we protect data.
We take reasonable technical and organisational measures to protect data against loss, misuse, and unauthorised access, including encryption in transit, limited access controls on the database, and separation of production and demo environments.
No system is immune to breach. If we discover one affecting personal data, we will notify the relevant supervisory authority within 72 hours and inform affected individuals where legally required.
Security researchers are welcome to report vulnerabilities in good faith through our Responsible Disclosure policy.
When this changes.
This is v0.2. Material changes will bump the version number and be explained in a short note at the top of this page. Minor editorial changes will be logged silently.
This policy will be reviewed by external counsel specialising in data protection and humanitarian operations before we take on our first paying production deployment. The resulting v1.0 may differ in structure and language but cannot, per our public commitments, weaken the protections set out here.
About your data.
Privacy questions go to hello@reliefpay.org. We respond within 72 hours.
General questions go to hello@reliefpay.org.
ReliefPay (operating as a sole-trader venture pending incorporation)
Nicolas Nel
Stockholm, Sweden
A postal address will be added here once the operating entity is formally registered. In the meantime, all correspondence is handled by email.