Integrating NIN and BVN Verification into Nigerian Software Products | Blog

# Integrating NIN and BVN Verification into Nigerian Software Products

TL;DR: If your product touches money, accounts, or regulated services in Nigeria, NIN and BVN verification isn't optional polish — it's a CBN-mandated onboarding gate, and getting the integration architecture wrong (wrong provider, wrong data-retention model, no fallback) is one of the most common reasons Nigerian fintech and marketplace launches stall in review or get flagged for compliance breaches.

Why NIN and BVN verification matters right now

Two identity numbers anchor almost every regulated digital transaction in Nigeria:

NIN (National Identification Number) — an 11-digit number issued by the National Identity Management Commission (NIMC) tied to a citizen's biometric and demographic record.
BVN (Bank Verification Number) — a 11-digit number issued through the banking system and centrally managed by the Nigeria Inter-Bank Settlement System (NIBSS), linking a customer's biometrics across every bank account they hold.

They aren't interchangeable, and 2026 has made that distinction sharper. The Central Bank of Nigeria's tiered KYC framework requires every Tier 1 account or wallet to be linked to a BVN or NIN, with a ₦30,000 cumulative balance ceiling; Tier 2 requires both BVN and NIN plus a verified address, unlocking a ₦500,000 limit; Tier 3 demands full verification with no limit. Self-declaration no longer satisfies any tier — real-time, automated lookups against NIBSS and NIMC are now the baseline expectation, not a nice-to-have.

On top of that, CBN Circular BSD/DIR/PUB/LAB/019/002 (issued 10 March 2026) sets Baseline Standards for Automated AML Solutions and requires banks, fintechs, and payment service providers to submit an automated AML implementation roadmap by 10 June 2026 — pushing identity verification further into "must be API-driven and real-time," not batch or manual.

For any founder or engineering team building a wallet, lending app, payments product, marketplace with escrow, HR/payroll tool, or insurance product for the Nigerian market, this means identity verification has to be designed as core infrastructure, not a bolted-on form field.

The two official routes: NIMC and NIBSS

NIMC Verification Service (NVS / NINAuth)

NIMC exposes a Verification Service API (NVS), historically a SOAP-based web service, that lets registered organizations query the National Identity Database. Access is tiered — NIMC operates multiple access levels, from Level 1 (minimal fields returned) up to Level 5 (full demographic data), and the service fee is negotiable based on which level your use case requires and the volume you expect. NIMC has also rolled out NINAuth, a newer authentication service aimed at more seamless, government-service-grade identity checks.

Getting direct NIMC access typically involves:

1. Formal registration as a Verification Service provider or licensee with NIMC.

2. Signing a data-sharing/access agreement that specifies which fields you're permitted to receive (a full demographic dump is rarely justified or granted for a simple KYC check).

3. Technical integration against NIMC's endpoints, with credentials scoped to your approved access level.

NIBSS BVN Validation Portal

BVN verification runs through NIBSS's centralized infrastructure. The NIBSS BVN Validation Portal is described by NIBSS itself as the official, centralized platform through which licensed banks, fintechs, and authorized partners verify BVNs in real time — but it's explicitly built for institutional access, not a self-serve public API. You need to be a licensed financial institution, a PSP, or work through an authorized aggregator/partner to get direct BVN validation access.

This institutional gatekeeping is exactly why most software teams — even well-funded ones — don't integrate directly against NIMC or NIBSS for a first build. It's slow, requires licensing relationships, and the raw access levels are calibrated for banks, not app developers shipping in a sprint.

The practical route: licensed identity API aggregators

In practice, most Nigerian and pan-African products integrate NIN/BVN verification through licensed third-party identity verification APIs that already hold the NIMC/NIBSS access agreements and re-expose the checks as clean REST APIs. Providers active in this space include Smile ID, Youverify, Dojah, VerifyMe, and Prembly — each offering NIN/BVN lookup alongside adjacent checks like liveness/selfie matching, document verification (driver's license, international passport, voter's card), watchlist/sanctions screening, and business verification (CAC).

These providers differ meaningfully in ways that affect architecture decisions:

Consideration	What to check
Match type	Number-only lookup vs. full biometric/selfie match against the NIN/BVN record
Data returned	Full demographic record vs. match/no-match boolean — request the minimum you need
Latency & SLA	Real-time sync response vs. async webhook-based results
Coverage	NIN, BVN, CAC, driver's license, voter's card, international passport — which combination you actually need
Pricing model	Per-lookup pricing, often with volume tiers; caching/re-verification policy matters here
Compliance posture	Whether the provider is itself licensed/registered and can be named in your own compliance documentation

A sensible integration pattern is to treat the aggregator as a pluggable adapter rather than a hard dependency: define an internal IdentityVerificationProvider interface (verify NIN, verify BVN, verify biometric match) and implement it against your chosen vendor's API. This keeps you able to switch providers, add a secondary provider for failover, or route different products to different providers by cost/coverage — without a rewrite. This is the same pattern we use whenever we build API integrations that sit between a client's product and a third-party data source: isolate the vendor contract behind a stable internal interface so vendor risk doesn't become product risk.

Architecture and compliance considerations

Design for verification failure, not just success. NIN/BVN mismatches happen constantly — name order differences, maiden vs. married names, transposed digits, expired enrollments. Build a manual-review fallback path (document upload + human review) rather than hard-blocking users on a single automated failure; this is standard practice among the KYC platforms themselves.

Minimize what you store. The Nigeria Data Protection Act (NDPA) 2023, together with the 2025 General Application and Implementation Directive (GAID) from the Nigeria Data Protection Commission (NDPC), requires Data Protection Impact Assessments for high-risk processing (identity verification qualifies), strict controls on cross-border data transfers, and breach notification within 72 hours. In practice: store the verification result (verified/not verified, timestamp, provider reference ID) rather than the raw demographic payload wherever your compliance obligations allow it, and encrypt at rest what you must retain.

Match your KYC tier to your actual risk. Don't default every user to Tier 3-level verification if your product only needs Tier 1. Over-collecting NIN/BVN/address/document data increases both your compliance surface and your NDPA exposure for no regulatory benefit.

Budget for per-lookup cost at scale. Unlike a typical SaaS API, identity verification is usually billed per call. A consumer app verifying hundreds of thousands of users needs caching (don't re-verify unchanged records), duplicate-detection before calling the API, and provider-tier pricing negotiated ahead of a marketing push — not discovered after invoices spike.

Treat DPCO engagement as part of the compliance checklist, not an afterthought — the NDP Act requires many data controllers/processors to work with a licensed Data Protection Compliance Organisation for audits, and an identity-heavy product is a natural candidate for that scrutiny.

FAQ

Do I need both NIN and BVN verification, or just one?

It depends on your product's CBN tier. Tier 1 wallets/accounts need BVN or NIN. Tier 2 and above need both, plus additional address/ID verification. Non-financial products (e.g., an HR platform doing employee identity checks) may only need NIN, since BVN is banking-specific.

Can I integrate directly with NIMC or NIBSS instead of a third-party API?

Technically yes, but both routes are institutional: NIMC requires formal registration and a negotiated access-level agreement, and the NIBSS BVN Validation Portal is built for licensed banks/fintechs/authorized partners, not general developer signup. Most product teams reach production faster through a licensed aggregator that already holds these agreements, then move to direct access later if volume justifies it.

How long does NIN/BVN integration typically take?

With a licensed aggregator API, a basic verification flow (number lookup + match) can be integrated in days. Adding biometric/selfie matching, manual-review fallback, webhook handling for async results, and compliance-grade audit logging is realistically a multi-week effort if done properly rather than bolted on.

What's the biggest mistake teams make with this integration?

Treating it as a single API call instead of a workflow. Real deployments need retry/fallback logic for mismatches, data-minimization decisions for storage, provider failover, and tier-appropriate verification depth — skipping any of these tends to surface later as either a compliance finding or a support-ticket flood from legitimate users failing automated checks.