Ghana Card Verification: KYC Workflow for Businesses

A sharp photograph of a Ghana Card can capture the wrong evidence in perfect focus. The card may be real and stolen, the image may be altered, the data may be out of date, or someone else may be holding the credential. A better copy fixes none of this. The business needs an authoritative answer about the identity, tied to the person in front of it and to the purpose, plus enough evidence to explain the decision later.

In 2026 the rules caught up with this. The National Identification Authority says L.I. 2523 came into force on 9 June 2026: visual inspection is no longer sufficient, real-time biometric verification must be performed against the NIA database, and organisations must not request, photocopy, scan or retain Ghana Card copies for identity verification except where law permits. Where biometric verification is available, the physical card need not be presented.

In brief

• Treat IVSP verification as an authoritative-source event; a card-image check is something else.

• Request only the NIA fields required for the declared KYC purpose.

• Keep source verification, holder binding, AML risk and the final onboarding decision as separate results.

• Design failure, mismatch and accessibility routes before launch. An IVSP outage says nothing about fraud.

The Ghana Card is a reference, not the whole KYC decision

The Ghana Card supplies an identity anchor. IVSP can confirm data against the National Identity Register. Neither tells you the purpose and expected nature of a financial relationship, who owns a company, whether there is sanctions exposure or whether the residual risk is acceptable.

For a natural-person onboarding flow, use four evidence layers:

Fold these into a single “KYC passed” field and the reviewer loses what they need. A source mismatch, a presentation attack and a sanctions candidate each go to a different owner and call for a different action.

Access to IVSP is an institutional control

The NIA's verification-services page describes an onboarding process. An institution submits business registration and licensing evidence where applicable, the law permitting its collection of personal data, a valid data-protection certificate, its intended operational use and requested datasets. Access follows document review, technical setup and a contract.

In practice, that means two things.

First, when a vendor says it can “check Ghana Cards”, ask which authorised party accesses IVSP and under what contract. Document OCR and card-authenticity analysis are useful. The official response is still required.

Second, choosing fields is a compliance decision. The NIA request form lists many possible datasets, and you should request only the ones you need. Map each requested field to a specific KYC purpose, consumer disclosure, downstream user and retention rule.

A defensible business workflow

define product and legal purpose
→ collect minimum customer claim and consent/notice evidence
→ request approved IVSP verification and required fields
→ bind the response to the current person
→ resolve mismatches and technical outcomes
→ perform risk-based CDD and screening
→ record the decision, policy version and retention event

1. Define the transaction before requesting data

A bank account, an insurance policy and a low-risk non-financial service may each need different evidence. Document the purpose, controller/processor roles, legal basis, minimum dataset and downstream recipients before configuring IVSP fields.

2. Keep submitted and returned data separate

Do not overwrite the applicant's spelling or date with the NIA response. Preserve both values, the comparison outcome and the resolution. If someone later corrects the record or investigates fraud, they can see exactly what happened.

3. Bind the authoritative record to the presenter

Real-time biometric verification is the rule described by the NIA for the new regime. In system design, retain separate evidence for the authoritative record, biometric comparison and capture integrity. Calibrate the match threshold for the use case. The displayed score is a similarity measure, and reading it as a probability of identity is a mistake.

4. Apply customer-risk controls

Identity confirmation feeds CDD; it does not finish it. The organisation may still need to establish purpose, beneficial ownership, PEP or sanctions exposure, source of funds and expected activity under the rules applicable to its sector.

5. Explain the final decision

The record should link the IVSP transaction reference, approved dataset, customer session, biometric outcomes, policy version, exceptions and final decision. Keep raw biometric data out of the default audit log. Identifiers, signed responses and derived results usually meet the evidence purpose with far less exposure.

Failure handling is part of verification

Questions for an IVSP integration review

• Who is contractually authorised to send the NIA request?

• Which exact fields are requested, and why is each necessary?

• Is the returned photograph or biometric reference used only inside the approved purpose?

• How are consent, notice and data-subject requests linked to the verification event?

• Can operations distinguish mismatch, attack, user error and NIA outage?

• Which data are retained by the business, processor and verification provider?

• Can a reviewer reproduce the final decision without keeping an unnecessary card copy?

Biometric.Vision Document Verification can extract and inspect document data, while face comparison and liveness can help bind a trusted portrait to a live session. These are technical modules and do not give direct NIA access. The organisation has to establish, separately, its IVSP authorisation, lawful data use, KYC policy and final risk decision.

A good Ghana Card workflow keeps fewer card images and more decision provenance: what was asked, which official source answered, how the presenter was bound to the response and why the business accepted the customer.