KYC in Nigeria Is Not a Compliance Problem, It’s a Product Problem
--
Oftentimes, we see KYC as a compliance ‘thingy’. Something you integrate, tick and move on from. But after working on Fintech products. I now understand better.
KYC in Nigeria is more than just a compliance requirement; it’s a core product challenge. Most systems don’t fail because the technology is broken. They fail because they are not designed for the Nigerian environment.
Here are a few patterns I’ve consistently encountered:
1. User behaviour is different from system assumptions
Most KYC flows assume ideal conditions:
- That users have physical documents on hand
- Users are comfortable scanning instead of uploading
- Users can easily perform liveness checks in any environment
In reality:
- Documents are already stored digitally on users’ phones
- Liveness checks can feel awkward, especially in public
- Repeated failures create frustration and drop-offs
This creates a gap between how systems expect users to behave and how users actually behave.
2. Address verification is sometimes over-optimised for
Map-based address selection and live location capture work well in structured regions. But in Nigeria, many valid addresses:
- Don’t exist on mapping platforms
- Are inconsistently labeled
- Rely on landmarks and informal descriptions
When systems enforce strict geolocation validation, they unintentionally exclude legitimate users.
There’s also the assumption that users are always physically present at their residential address during verification.
In reality, that’s rarely the case. People are mobile:
- At work
- In transit
- Visiting family
- Operating between multiple locations
Requiring a live location as a proxy for proof of residence makes the verification false
3. Proof-of-address assumptions don’t reflect reality
A common requirement is that a user’s name must appear on a utility bill or similar document.
In practice:
- Many people live in rented apartments
- Utility bills are often in the landlord’s name
- Bank statements become the only widely usable option
This isn’t an edge case; it’s a common living arrangement.
4. Verification flows are not product-ready
Many providers offer pre-built flows or “customizable” options. But in reality, these flows are rigid and difficult to align with real onboarding journeys.
Instead of embedding verification seamlessly, the result is an experience that feels different
5. Pricing doesn’t scale with product reality
On paper, KYC pricing is simple: pay per verification.
In practice:
- Failed attempts still cost money
- Retries multiply quickly
- Multiple providers increase spend
- Drop-offs mean you pay for users who never convert
And beyond usage-based pricing, there’s another layer:
Some providers require high fixed monthly commitments, sometimes running into five figures.
For early-stage products, this creates a real constraint:
- You’re paying upfront before achieving meaningful volume
- You’re locked into costs before validating your onboarding funnel
This isn’t just a pricing issue; it’s a misalignment between how providers price and how startups scale.
At that point, KYC becomes more than compliance; It becomes a unit economics and growth constraint.
The shift in thinking
As long as teams rely entirely on provider-defined flows, they inherit assumptions that don’t match their users and UX decisions that are not in their control
What has worked better is shifting from integration to ownership:
- Orchestrate, don’t outsource
Break verification into components and design your own flow. See providers as building blocks, not end-to-end solutions.
2. Design for real user behaviour
- Allow document uploads, not just scanning
- Make liveness checks easier and not awkward
- Support manual address entry alongside map-based options
3. Build fallback paths, not single flows
If one method fails, users should have alternative ways to proceed.
4. Apply risk-based verification
Not every user needs the same level of friction. Adjust verification intensity based on risk signals instead of enforcing a uniform flow.
In conclusion
The next evolution of identity verification won’t come from better APIs/SDKs alone.
It will come from systems designed around:
- real user behaviour
- local infrastructure realities
- and flexible, product-led implementation
