KYC vendor security Nigeria: What we test in SmileID, Youverify, and Appruve integrations

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

The KYC architecture defines the onboarding security of any Nigerian fintech. SmileID, Youverify, Dojah, and IdentityPass provide robust verification engines. They handle liveness detection. They check the BVN database. They return a binary result. The problem lies entirely in how your backend consumes that result.

We find critical vulnerabilities in KYC integrations continuously. Developers trust the vendor implicitly. They fail to bind the verification result to the exact user session. They fail to validate webhook signatures. They allow attackers to reuse a single successful verification to open hundreds of fraudulent Tier 3 accounts. We attack the integration logic.

Map the decision before testing the vendor call

Write down each state from KYC start to account activation. Include the user ID, session ID, vendor job ID, verification purpose, result, account tier, and time limit. The backend must own every state change.

A vendor result answers one question about one verification job. The fintech still decides which account receives that result, whether the job can be reused, and which product action it unlocks. An API-first KYC architecture must rely on strict state machines. If a user tries to skip from state 1 directly to state 5, the API must reject the request.

We map the entire flow. We capture every API call during onboarding. We identify the exact endpoint that flips the database flag from "unverified" to "Tier 3 verified". We attack that specific endpoint from every possible angle.

1. KYC step bypass via direct account creation endpoint calls

Call the final account creation endpoint without completing KYC. Repeat with a pending, failed, expired, and cancelled job. Attackers automate this process using Python scripts to farm hundreds of accounts.

Pass: the server checks a completed job for the same user and onboarding attempt before creating or raising the account tier. The server does not trust the client application to enforce the workflow.

# Test: skip KYC, directly call account creation
curl -X POST https://api.fintech.ng/v1/accounts \
  -H "Authorization: Bearer session_token" \
  -H "Content-Type: application/json" \
  -d '{"phone": "08012345678", "pin": "1234"}'

# If this creates an account without a kyc_verified: true check: critical finding

Client-side routing restrictions are meaningless. We drop the mobile app entirely. We intercept the requests using Burp Suite. We call the protected endpoints directly. If the backend relies on the frontend to display the KYC screen before unlocking the account creation endpoint, the system is fundamentally broken.

2. KYC verification result replay across users

After a successful job, replay the job ID from another user, device, session, and product flow. Then submit it twice in parallel. Pass: the backend accepts the job once for its original user and purpose. Every mismatch or reuse fails without changing the account.

We execute token reuse attacks. We complete the SmileID or Youverify process legitimately once. We capture the successful `job_id` or `reference_id`. We spawn fifty parallel threads. We submit that same successful reference ID to fifty different user accounts simultaneously. If the database lacks a unique constraint or a consumed-flag check, fifty accounts instantly upgrade to Tier 3 using one person's face and BVN. We see this flaw constantly.

3. KYC response body tampering in transit

Send an unsigned callback, a callback with one changed byte, an old timestamp, and a valid callback twice. Follow the vendor’s current signature rules. Dojah, SmileID, and Appruve all mandate cryptographic signature verification on webhooks. Developers routinely ignore the documentation.

Pass: invalid callbacks fail before storage. A valid callback updates the matching job once.

We bypass verification by acting as the vendor. We set up an external server. We send a forged webhook payload to your callback URL. We claim the verification succeeded. We assert a 99% confidence score on the face match. If your server does not cryptographically verify the HMAC signature using the shared secret key, it processes the forged webhook. The attacker instantly controls a fully verified account. This is a critical failure of KYC architecture.

4. Liveness bypass testing for specific vendors

Use the vendor’s approved test process and safe test identities. Check photo replay, screen replay, recorded video, challenge order, retry limits, and device changes. Record the liveness mode, SDK version, test input, vendor result, and server decision. Do not test against production user data.

Liveness checks are a cat-and-mouse game. Attackers use deepfakes, printed masks, and virtual camera drivers. We test the integration settings. Did you configure the vendor SDK to enforce active liveness (smile, blink) or passive liveness? Are you accepting low confidence thresholds? We test boundary conditions to ensure your risk tolerance aligns with your implementation.

5. Unauthorized KYC lookup and PII exposure from verification responses

Use two test users to check job, result, image, and staff lookup endpoints. Change the job ID, user ID, and tenant ID. Mass data breaches occur when these endpoints lack authorization controls.

Pass: users see only their own required fields. Staff access needs a role, a purpose, and an audit log. A user should never be able to enumerate `job_id=1001`, `job_id=1002`, and pull the raw BVN data and face photos of other customers.

We hunt for Insecure Direct Object Reference (IDOR) vulnerabilities on the KYC result endpoints. We swap identifiers. We extract plaintext Personally Identifiable Information (PII). We verify that your data localization and encryption-at-rest policies cover the cached vendor responses in your database.

6. Race condition between KYC completion and account tier assignment

Send transactions while the KYC job is pending and while two callbacks arrive in parallel. We exploit the time gap between a webhook arriving and the database transaction committing.

Pass: only a stored successful result raises the tier. Pending and failed states keep the lower limit. We use specialized tooling to fire simultaneous requests, attempting to trigger a state where an account bypasses tier restrictions by exploiting database locks.

Evidence and pass rules

During an audit, we document every failure path meticulously. A robust KYC architecture must withstand direct, adversarial manipulation. We enforce these evidence rules:

• Account binding: Keep two test users and one completed job. Pass when the second user receives a 403 or 409 and no account state changes.
• Callback trust: Keep the unsigned, altered, expired, and valid callback responses. Pass when only the valid signed callback changes the job state.
• One-time use: Keep two parallel requests using one job ID. Pass when one succeeds and the other fails under an atomic database rule.
• PII access: Keep request pairs for two users. Pass when each user can read only their own redacted result.
• Activation: Keep the account row before and after each failed test. Pass when failed, pending, expired, and mismatched jobs never raise the account tier.

Related reading

Blog: KYC and BVN data security · BVN spoofing and liveness bypass · NIN verification API security

Services: Penetration testing · API security