Pixel mosaic in Nzinga colours, one bright cell at its core
Trust Centre
/
Compliance

Compliance

How Nzinga meets one strict standard wherever members live, and which parts are in place or still planned.

In place
Planned, and said so
01

One standard, local modules

Nzinga is jurisdiction-neutral by design: one strict common standard everywhere. Requirements that differ by country are handled by modules, each reviewed by local counsel before launch there.

Note

Nothing on this page is legal advice or a legal conclusion. It says what is in place and what is planned.

03

An audit log of access

Every access to recordings and consent records is to be logged, append-only, so auditors can see who looked and why.

audit
planned
Consent and ledger history, append-only
in place
Access log for recordings
planned
Read-only access for auditors
planned
Audit right in every licence
planned
Source: POC plan, sections 6 and 9
04

Impact assessment before launch

A data protection impact assessment and a record of processing are completed before any external member records.

05

Breach notice within 72 hours

If a breach puts members at risk, we tell the people affected and the relevant authority within 72 hours of finding it: what happened, and what to do.

Status

Planned. A written breach response plan and a named data protection contact come before external members join.

06

Export and deletion requests

Requests are answered within a published time. Today, export is a button in the app, and a deletion request is completed within 30 days.

member requests
app demo
Download my data, in the app
in place
Deletion request, 30 days
in place
Published response times
planned
Self-serve deletion through the API
planned
Source: apps/mobile; POC plan, section 6
07

Independent security review

An independent security review and penetration test happen before any public launch. Until then, the app runs as a demo and an internal pilot.

08

Identity verification

We verify only as much as each action needs, rely on partners who already verify people, and never store ID documents.

level 0 · join
built in part
Phone number confirmed by one-time code
built
Invite from a member who vouches
built
Self-declared adult
planned
Genuine-device check
planned
Source: apps/api, packages/core/src/invites.ts
level 1 · contribute
planned
Short random phrase read aloud, a live person
planned
Duplicate and synthetic-audio checks
planned
Before recordings are accepted
level 2 · get paid
planned
Mobile-money provider's own identity check
planned
Name on the wallet matches the profile
planned
Above set limits: a licensed verification partner
planned
Nzinga keeps the result, never ID images
rule
Before any payout
level 3 · roles with more access
planned
Reviewers pass a language test
planned
Teams admins sign in through their organisation's login
planned
Reviewers and Teams admins
organisations
planned
Business verification
planned
Sanctions screening
planned
Review of intended use: no voice cloning, no surveillance
planned
Licensing partners
Biometrics

We do not store voiceprints. Any speaker-consistency check runs on the phone where possible and keeps only a match result. Voice is never used to identify people, and nothing biometric is ever sold.

Age. Adults only. Planned: declared at sign-up and confirmed by the payout check. Recordings with children’s voices are excluded.

Calls. Not built yet. When they are, everyone recorded is a signed-in member who agreed for that call. Non-members are never recorded.

Later. Privacy-preserving credentials, so a member can share “over 18” or “identity checked”, never the document.

09

Status at a glance

compliance
in place / planned
Consent recorded per item, with text and app version
in place
Audit log of access
planned
Impact assessment before launch
planned
Breach notice within 72 hours
planned
Export and deletion within a published time
in part
Independent security review before public launch
planned
Country modules reviewed by local counsel
planned
Identity checks, levels 0 to 3
in part
Sources: SPEC.md; POC plan, section 14; apps/api; apps/mobile

To report a concern, open an issue on GitHub or contact the team.