Skip to content

The Zev ecosystem at a glance

A high-level map of what each Zev product is, what role it plays in data terms (controller, processor, or both), and how the products communicate.

For DPO reading

This page is the orienting view — what exists, who does what. The how-data-actually-flows view lives in Cross-product data flows.

The Zev brand and every product below sit under ZevOP Technologies Limited — a Nigerian company. That's the data controller named on NDPA filings, DPAs with third-party processors, and the user-facing privacy notice. References to "Zev" elsewhere in this site mean the brand / product family; the legal-entity column on any compliance document is ZevOP Technologies Limited.

Products

The Zev ecosystem operates under ZevOP Technologies Limited (the data controller named on every NDPA filing). The products below are the publicly-accessible surfaces today:

Product Role What it does Data-controller role
ZevID Identity provider Centralised user accounts, authentication, MFA, cross-product permissions (ZPIP). Lives at accounts.zevop.com. Not a "product" in the consumer sense — it's the identity substrate every other product uses. Controller for identity + auth data
ZevPay Payments Personal accounts + business accounts, wallets, transfers, payment processing, KYC for financial regulation. Controller for financial data; processor for KYC data passed in by other Zev products
ZevCommerce Merchant platform Stores / catalogues / orders for merchants; integrates ZevPay for collections. Controller for merchant + order data
ZevCloud Developer cloud App / container / deployment hosting. Controller for project + deployment data
ZevWorkspace Org collaboration Org accounts, teams, document collaboration. Controller for org + document data

Additional oauth_clients rows exist in production for internal use, not-yet-launched products, and sandbox environments — these aren't end-user-accessible. The DPO can request the full list from the deployment owner when relevant to an audit.

Account-creation model. A user signing up at any one Zev product gets a ZevID account (centrally) plus an enrollment row for that specific product. ZevID accounts are NEVER auto-created at other products — each product's enrollment is consent-gated and only happens when the user visits that product and signs up via ZevID. A single ZevID may have zero, one, or several active product enrollments.

What ZevID centralises

By design, ZevID is the single sign-on + the single identity-data store:

  • Email, password, MFA factors, phone numbers — owned here, not duplicated.
  • KYC verification record (NIN/BVN/face-match outcome) — written by whichever product runs KYC (today: ZevPay), readable by others via ZPIP.
  • Cross-product enrollments and per-product tier metadata — synced from each product into ZevID via the enrollment-sync contract.
  • Cross-product permissions (which product can do what on behalf of a user) — granted via the ZPIP consent flow.

Other products hold only their domain-specific data (transactions for ZevPay, orders for ZevCommerce, deployments for ZevCloud, documents for ZevWorkspace). When they need user-identity data, they read it from ZevID rather than duplicating it.

Communication patterns

Cross-product communication happens through ZPIP — the Zev Product Integration Protocol. Two flavours:

  • Service-only — generic ecosystem utilities (e.g. ZevPay's bank-name lookup). No user in the loop. Documented in Cross-product / ZPIP.
  • Service + user (consent-gated) — a product acts on a user's behalf for a specific scope. Requires the user to grant explicit consent on accounts.zevop.com/zpip-consent. Documented in Cross-product / ZPIP.

The architectural decision underpinning this is recorded in zevid-backend/docs/decisions/0001-batched-zpip-consent.md (link to be updated once internal repo URL is finalised).

Data residency

All Zev product databases run in regions consistent with NDPA's cross-border-transfer expectations. Specifics per product live in each product's third-parties.md. Cross-border transfers (e.g. to Cloudflare / Sentry / observability vendors) are listed and accompanied by DPA documentation in each product's section.

What this site does NOT cover

  • Public marketing claims — those live at zevop.com.
  • Engineering architecture in depth — code-level architecture decisions live in each product's repo under docs/. This site captures the compliance-relevant layer.
  • Customer support runbooks — those live in our internal support tooling.
  • Vendor security questionnaires we send to suppliers — those live with the procurement team.

If a regulator or auditor asks something this site doesn't cover, the DPO routes to the appropriate internal team.