Ghana SIM Registration: Biometric Liveness Verification Requirements

A subscriber can present a genuine Ghana Card and still be the wrong person holding it. A selfie can match the card portrait and come from a replayed video. Even a successful biometric response is weak evidence if the operator cannot show which source, threshold and rule led to activation. Ghana's new SIM-registration model closes these gaps only if identity, presentation and decision controls stay separate and traceable.

The National Communications Authority's 2026 FAQ states that subscriber biometrics are validated in real time against the National Identification Authority database and that a SIM is activated only after successful biometric verification. That is a requirement on the regulatory process. Face comparison, presentation-attack detection, device integrity and exception handling can still return different answers, and your design has to handle each one.

In brief

• Ghana's current process requires real-time biometric verification against the authoritative identity source before activation.

• Identity-source verification, face matching and liveness answer different questions and should produce separate results.

• A liveness pass tells you about the capture event. It does not show that the identity data are correct.

• The activation record should preserve source, session, result and decision data without retaining more biometrics than the applicable rules and purpose allow.

What changed in Ghana's SIM-registration control

The NCA describes a central registration platform with real-time biometric verification against the NIA database, support for physical SIM and eSIM self-registration, validation of corporate registration data and device checks through the Central Equipment Identity Register. In operational terms, a number should stay inactive if all a person has done is type in plausible Ghana Card details.

So the control chain goes well past an image upload:

subscriber and registration context
→ eligible identity credential
→ authoritative data validation
→ live biometric capture
→ biometric comparison
→ operator policy and exception handling
→ activation decision and audit record

The NCA source sets the real-time biometric requirement and the activation condition. How capture integrity, retry rules and manual review work in practice is left to engineering and risk teams, unless a binding instrument spells it out.

Verification is not one indivisible check

Keeping these results apart stops a common implementation error, where one model score becomes the final KYC verdict. A similarity score does not give the probability that two images show the same person; it is an algorithm-specific measure compared with a threshold. A liveness result is likewise limited to the attack types, devices and conditions its mechanism was tested on.

Where liveness belongs in the flow

Liveness should guard the live-capture step before anyone trusts the face image for comparison. Passive liveness cuts friction because the subscriber does not have to turn their head or speak on cue. You still have to protect the camera path. If a virtual camera or injected stream has replaced the capture, a system analysing a genuine-looking frame may be checking the wrong thing.

Treat these as three separate attack surfaces:

• Presentation attacks: a printed photo, screen replay or mask is shown to the camera.

• Injection attacks: a previously captured or generated stream is inserted after the camera.

• Account and process abuse: a genuine person is manipulated, an agent overrides a result, or the same identity is used outside policy.

ISO/IEC 30107-3 provides a framework for testing presentation-attack detection. Read any certification or test result together with the attack species and conditions it evaluated. It gives no general guarantee against injection, social engineering or operator abuse.

Design the activation rule before integrating the models

Define a decision table first. A generic verified=true response is too thin to run activation on.

These routes come from our editorial risk model; the NCA does not prescribe them. They keep fraud, customer error and infrastructure failure from ending up under the same rejection code.

The evidence trail must reproduce the decision

An audit-ready record should explain what happened, and the operator should not need to keep every raw image forever to get there. When designing the system, consider linking at least:

• registration and subscriber identifiers;

• the identity credential type and authoritative source used;

• timestamps and a unique verification session;

• separate liveness, face-match and source-validation outcomes;

• model, threshold and decision-policy versions;

• retry, manual-review and override events;

• the final activation decision and responsible system or role;

• retention and deletion status for raw images and derived templates.

The NIA's Identity Verification Services page shows that institutions cannot look records up freely. Onboarding requires business and regulatory documents, a stated operational use case, the datasets requested, technical setup and a contract. Record in the audit trail that each request went through an authorised integration. A copied card is not the same as a verified NIA response, and the record should never suggest otherwise.

Five tests before production

• Source test: Can the team distinguish an NIA-confirmed record from user-entered or OCR-extracted data?

• Capture test: Can the mobile flow detect or constrain replay and injected-stream paths relevant to its threat model?

• Threshold test: Were false-match and false-non-match rates measured on representative devices and users?

• Exception test: Do outages, borderline scores and accessibility cases have safe routes that do not become bypasses?

• Reproduction test: Can an investigator reconstruct why a SIM was activated using immutable versions and timestamps?

Biometric.Vision Liveness can provide a presentation check, and Face Match compares the captured face with a reference image. Each module covers one technical step. The operator still needs authorised access to the identity source, an activation policy, device and channel controls, exception handling and a retention schedule.

Asking whether the flow “has biometrics” gets you nowhere. Check that each biometric result has a defined source, threat, threshold and consequence, and that someone can explain the final activation after the session has ended.