Why the integration layer is more dangerous than the vendor layer
SmileID has a mature liveness detection model. Youverify's document verification system processes millions of checks. These are funded, engineered products with dedicated security teams. The fintech's integration code, by contrast, was often written by one engineer over two weeks to hit a launch deadline. The vendor is not the weak link. The code that calls the vendor, processes the response, stores the result, and gates account creation on it — that is where we consistently find exploitable vulnerabilities.
The consequence of a KYC integration vulnerability is also compounding. A single exploitable path through the KYC flow does not just affect one fraudulent account — it creates a repeatable method that attackers can automate. If we find that a fintech's KYC bypass works, we can demonstrate it on any new account creation. A single vulnerability in the integration layer can enable synthetic identity fraud at scale across the entire platform.
1. KYC step bypass via direct account creation endpoint calls
The onboarding flow a user sees in the app goes through multiple screens: BVN entry, liveness check, document upload, KYC result, account creation. The backend, however, is a set of separate API endpoints. We test whether calling the final account creation endpoint directly — without first going through the KYC endpoints — produces a complete account. If the account creation endpoint does not validate the existence of a completed, successful KYC result for the current session, an attacker can skip the entire vendor flow.
# 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 finding2. KYC verification result replay across users
After a successful SmileID job completes, the vendor returns a job reference ID. The fintech's backend stores this ID alongside the user's session and uses it to confirm the KYC check was passed. We test whether submitting a known valid job reference ID in a different user's account creation request causes the backend to accept it as a fresh verification. If the backend does not validate that the job ID belongs to the current user's session — not just that the job was successful in general — any successful job ID can be reused to create an unlimited number of verified accounts.
3. KYC response body tampering in transit
If the fintech does not verify the signature on the KYC vendor's webhook or callback response, the response body is untrusted. We test whether the fintech validates the HMAC signature on SmileID callbacks, whether Youverify webhooks are rejected without a valid signature header, and whether the verification status field in the callback can be modified from "Failed" to "Passed" before it reaches the fintech's webhook handler. This requires a man-in-the-middle position or a MITM-capable proxy — we test from the client side first, then as a webhook forger if the callback endpoint is known.
4. Liveness bypass testing for specific vendors
We test the liveness detection of the integrated vendor using standardized bypass techniques. For SmileID and Youverify integrations we test: high-resolution photograph held in front of the camera on a secondary device, recorded video replay on a device (a known weak point for non-active challenge-response liveness), and 3D mask attacks where the print quality of an attacker's reference image is high enough to fool a depth-unaware liveness model. We document which bypass methods succeed and at what image resolution, giving the fintech actionable data on whether their chosen vendor's liveness tier is appropriate for their risk level.
5. Unauthorized KYC lookup and PII exposure from verification responses
KYC verification responses contain full biographic data: name, date of birth, photograph, BVN, address. This data is returned by the vendor and stored by the fintech. We test whether the stored verification data is accessible through the fintech's own API — specifically, whether one authenticated user can retrieve the KYC verification data of another user by enumerating the job ID or user ID, and whether administrative endpoints that query KYC records are restricted to authorized staff or are accessible to all authenticated users.
6. Race condition between KYC completion and account tier assignment
Some fintechs process KYC results asynchronously: the user completes the liveness check, the result comes back via webhook a few seconds later, and the account tier is upgraded when the webhook is processed. We test the window between KYC submission and account tier assignment. If a user can initiate transactions at a higher tier immediately after submitting KYC, before the webhook result is processed and the tier confirmed, they may be able to transact above their actual verified limit during this window.
SmileID job ID from a completed legitimate verification accepted for new account creation
During a penetration test of a Nigerian lending platform, we identified that the loan application endpoint accepted a smile_job_id parameter and used it to look up the verification result directly from the fintech's internal cache. The validation checked only that the job result was "Passed" — it did not check that the job belonged to the requesting user's session or phone number. We used a SmileID job ID from a previously completed test verification (obtained by monitoring the network traffic on our own test account) and submitted it in a new loan application for a different phone number. The application was approved and the loan disbursement initiated based on the successful KYC result of a completely different person. Fix priority: critical. Remediated by binding the job ID to the user's session at initiation time and rejecting any application where the job ID's registered phone number does not match the authenticated session's phone number.
Integrated SmileID, Youverify, or Appruve for KYC in your Nigerian fintech? Book a security audit of the full integration chain before a replay attack enables synthetic identity fraud at scale.
Book a KYC Integration Security AuditFrequently asked questions
If SmileID or Youverify are responsible for liveness detection, why does the fintech still need a security audit?
The KYC vendor is responsible for the accuracy of their liveness algorithm. The fintech is responsible for how it calls the vendor, how it stores the response, and how it binds the verification result to the account being created. Even when the vendor's liveness check works perfectly, vulnerabilities in the fintech's own integration can allow an attacker to replay a verification result from a legitimate user onto a fraudulent account, bypass the KYC step entirely by calling the account creation endpoint without going through the vendor flow, or access another user's verification data through a poorly authorized response storage API.
What is a KYC verification result replay attack?
After a user completes a successful KYC check with SmileID or Youverify, the vendor returns a verification job ID and a result payload indicating success. If the fintech stores this result and links it to the user's session, an attacker who obtains a valid job ID from a previous legitimate verification (through API enumeration or an insider) can submit that job ID in a new account creation request. The fintech queries the vendor with the existing job ID, receives a success result, and creates an account that was never actually verified by the new user.
Do KYC vendors like SmileID share liability for fraud losses from integration failures?
No. KYC vendor terms of service place the responsibility for correct integration on the fintech customer. The vendor provides a verified result. What the fintech does with that result, how it stores it, and how it binds it to the account creation flow are entirely the fintech's responsibility. Fraud losses from integration vulnerabilities are borne by the fintech, not the vendor.
Related reading
Blog: KYC and BVN data security · BVN spoofing and liveness bypass · NIN verification API security
Services: Penetration testing · API security