Data processed and stored inside Zimbabwe

Sovereign identity verification, built in.

KYC, liveness and biometrics for regulated businesses. One API for face match, documents and AML screening, with a capture flow you own, not a redirect to a foreign vendor.

Capture: Hosted; No foreign redirect
Liveness: Passive + active; PAD + challenge
Data: In-country; Zimbabwe

verify/session/live

capturing

Turn your head slowly to the right

2 / 3

Scroll

Passive livenessActive liveness challengeFace match 1:1Document + MRZAML / PEP screeningNational-ID validationVerification sessionsSigned webhooksPassive livenessActive liveness challengeFace match 1:1Document + MRZAML / PEP screeningNational-ID validationVerification sessionsSigned webhooks

The design principle

Your citizens’ biometric data is processed and stored inside Zimbabwe.

Most verification stacks send a face and an ID document across a border to be checked. That is the moment the hard questions start: whose law applies, who can be compelled to hand the data over, and whether the transfer was ever lawful.

Sovera removes that moment entirely. Keeping the regulated data in-country is not a feature bolted on later. It is the reason the product is shaped the way it is.

No cross-border transfer to answer for

Because capture, inference and storage happen in-country, there is no export of biometric data to a foreign processor, and so no adequacy or transfer question to resolve first.

The capture flow is yours

Subjects are verified inside a flow you control, not redirected to a third-party vendor in another jurisdiction. Fewer drop-offs, and the trust stays with your brand.

Designed for the local framework

Built with Zimbabwe's data-protection framework in mind, including the Cyber and Data Protection Act and SI 155 of 2024. Alignment by design, not a badge.

Sovera is not certified or endorsed by any regulator or lab. We describe alignment with the local framework as a design goal, not as accreditation. No ISO, no iBeta, no partnership is implied.

Capabilities

Everything a regulated onboarding needs, in one place.

Compose the checks you need. Each one is a call; together they make a verification session.

The differentiator

Active liveness

The oval, plus a turn-left / turn-right challenge that proves a live person is present in real time. This is the flow that replaces a redirect to a foreign vendor with capture you host yourself.

challenge · nod · turn · blink

Passive liveness

Presentation-attack detection from a single frame. Catches printouts, screens and masks without asking the subject to do anything.

PAD

Face match

One-to-one comparison of a captured selfie against a reference portrait, returning a similarity decision.

1:1

Document and MRZ

Read an identity document, extract the machine-readable zone and validate its structure and check digits.

OCR / MRZ

AML and PEP screening

Screen a subject against sanctions, watchlists and politically-exposed-person data as part of onboarding.

Sanctions

National-ID validation

Check an identity number against the relevant authoritative source to confirm it is real and well-formed.

eGov

Verification sessions

A hosted capture flow that stitches the checks together, from first frame to a single decision you can act on.

Hosted flow

How it works

Three calls from cold start to a decision.

Create a session

Call the API to open a verification session and choose the checks it should run. You get back a session id and a link to the hosted capture flow.

POST /v1/sessions
Authorization: Bearer svk_live_…
{ "checks": ["active_liveness",
             "face_match",
             "document"] }

Capture, in-country

The subject completes the hosted flow: the liveness oval, the turn challenge, a document scan. Everything is captured, run and stored inside Zimbabwe.

→ oval framing
→ turn-right challenge  ✓
→ document + MRZ  ✓
→ template encrypted

Get a decision

Read the session result, or receive a signed webhook the moment it resolves. One decision, with the underlying check outcomes attached.

event: session.completed
{ "decision": "approved",
  "checks": { "liveness": "pass",
              "face_match": "pass" } }

For developers

An API that behaves the way you expect.

No surprises in auth, errors or retries. The primitives are the boring, dependable ones you already reach for.

Read the docs API reference

POST /v1/verify/liveness

# request
curl -X POST https://verify.lioncapventures.com/v1/verify/liveness
  -H "Authorization: Bearer svk_live_…"
  -H "Idempotency-Key: a1f9…"

# 200 OK
{
  "decision": "pass",
  "score": 0.987,
  "request_id": "req_2Zk…"
}

Bearer keys, scoped: svk_live_ and svk_test_ keys with deny-by-default scopes, so a key can do exactly what you granted it and nothing more.
RFC 9457 errors: Every failure is a problem+json document with a type, a title and a request id. Predictable to parse, easy to log.
Idempotency built in: Send an Idempotency-Key and a retried request replays the original result inside the replay window instead of double-charging work.
Signed webhooks: Sessions resolve to HMAC-signed webhooks with a timestamp and signature, so you can trust the payload before you act on it.
SDKsRoadmap: Client libraries are on the roadmap. Until then the API is plain HTTP and JSON, so any stack can call it today.

Compliance posture

Built to be defensible, not just to pass a demo.

Data sovereignty is the theme, and these are the controls that make it real: consent first, minimal retention, encryption, and a clean path to erasure.

Written to be aware of POTRAZ, the Data Protection Authority under the Cyber and Data Protection Act. Aware is the operative word. Sovera is not endorsed, licensed or certified by POTRAZ or any other body.

Consent-gated by design

No biometric template is created without a live consent record tied to it. Consent is the spine the rest of the data hangs from.

PII tokenized

Personal data is routed through a vault and referenced by token, so raw identifiers are not scattered across the system.

Templates encrypted

Biometric templates are encrypted at rest. They are derived data, held only as long as the purpose that justified them.

Erasure on request

A data-subject can be erased through the API, removing their records and templates to satisfy a deletion request.

Integrations and partners

Get started

Bring sovereign verification to your onboarding.

Create an account, generate test keys and make your first verification call in minutes. No sales call to start, no foreign redirect in your flow.

Test keys in minutes
Signed webhooks
Data stays in Zimbabwe