Skip to main content
The LumiID Government ID Face Match API verifies a live selfie against the official biometric photo associated with a customer’s Nigerian NIN or BVN. Unlike a standard face match — where you must supply both images yourself — this API handles the reference image for you. Submit the selfie and the identity number, and LumiID automatically retrieves the trusted government-issued photo from NIMC or NIBSS, performs an AI-powered facial comparison, and returns a match result. This removes the need for you to store or manage sensitive government identity photos while providing stronger, authoritative identity assurance for KYC, AML, and fraud-prevention workflows.

Key capabilities


Endpoint

Headers

Request body

string
required
The type of government identity to look up. Supported values: nin, bvn.
string
required
The customer’s government-issued identity number corresponding to the selected id_type.
string
required
Base64-encoded selfie image captured live from your user.
float
Matching threshold between 0.0 and 1.0. Comparisons that score above this threshold are classified as a match. Defaults to 0.75. Use the default unless your risk model specifically requires a stricter value.

Supported identity sources


Integration flow

1

Capture a live selfie

Use a live camera feed in your application to capture a front-facing selfie from your user.
2

Collect the identity number

Ask the customer to provide their NIN or BVN. This is the identity number you will pass as id_number.
3

Send both values to the endpoint

POST the selfie, id_type, and id_number to /v1/face/id-match/. Include your optional threshold if your risk policy requires it.
4

LumiID runs the comparison

LumiID automatically retrieves the official government biometric photograph from NIMC or NIBSS, performs an AI-powered facial comparison, calculates a similarity confidence score, and returns the result.
5

Approve or escalate

Use the match_result and confidence.score in the response to approve the onboarding, request a new selfie, or trigger a manual review based on your internal business rules.

Code examples

Success response

Response fields

boolean
Indicates whether the request completed successfully.
string
Machine-readable response code.
string
Human-readable response message.
object
High-level verification summary.
object
Detailed face comparison result.
object
Request metadata.

Confidence score guide


Match results

CONFIRMED

The live selfie matches the official government biometric record. Proceed with onboarding.

MISMATCH

The faces belong to different individuals. Reject the verification or ask the user to submit a new selfie.

INCONCLUSIVE

The system could not confidently compare the faces. Common causes include a blurry selfie, multiple faces in the frame, poor lighting, or a partially obscured face. Request a new capture before making a decision.

Error codes


For the highest level of fraud protection, run these checks in sequence:
1

Passive Liveness Detection

Run the Liveness Detection API to confirm the selfie was captured from a real, live person — not a photo, replay, or deepfake.
2

Government Identity Verification

Validate the customer’s NIN or BVN against the official registry to confirm the identity number exists and belongs to a real person.
3

Government ID Face Match

Submit the verified selfie and identity number to this endpoint. LumiID compares the live selfie to the official government biometric photo.
4

Approve or Escalate

Use the match_result and confidence.score to complete onboarding or trigger a manual review. This layered approach protects against impersonation, synthetic identity fraud, and presentation attacks while providing a strong audit trail for KYC and AML compliance.

Best practices

  • Always run Passive Liveness Detection before this endpoint.
  • Capture selfies in good, even lighting without harsh shadows.
  • Ensure only one face appears in the selfie before submitting.
  • Avoid selfies where the user is wearing sunglasses, a mask, or heavy filters.
  • Use the default threshold of 0.75 unless your risk model requires stricter verification.
  • Store the returned request_id for every request — you will need it for audit trails and support queries.