DigiLocker Evidence in Fintech KYC Workflows
Separate DigiLocker document evidence from a regulated KYC decision. Use an NBFC example to map signature checks, due diligence, and review responsibilities.
Treat a retrieved DigiLocker document as evidence for a defined onboarding step. The regulated entity owns the decision about how to identify the customer and complete due diligence.
For a specific example, the RBI KYC Directions for NBFCs define an equivalent e-document using a valid issuing authority signature. They also distinguish identification routes and describe additional steps for particular workflows. Confirm the applicable direction and entity policy for your case. RBI KYC Directions for NBFCs
Assign each decision an owner
| Step | Evidence or action | Responsible role |
|---|---|---|
| Application sign-in | Proof of account control | Application identity team |
| Document access | Approved source and user grant | Requester integration owner |
| Evidence validation | Checks required for the accepted document | Evidence reviewer |
| Customer due diligence | Applicable identification and review steps | Regulated entity |
| Onboarding decision | Approved policy applied to the case | Authorised decision owner |
Ask the regulated partner to specify required document types, checks, and exception handling. The application can then return a precise evidence status to the partner's decision workflow.
Trace an incomplete evidence case
In a synthetic case, a customer shares an issued document. The integration records source and download integrity as passed. Its independent issuer signature field remains unverified.
If the accepted route requires signature verification, keep that requirement open. Route the case to the approved verifier or alternate workflow. Make the missing check visible to the regulated entity.
A permission to retrieve the record governs that retrieval. Record the separate business policy and processing basis for any downstream use. Keep the decision tied to the policy version and the evidence used.
Design the handoff for review
- Identify the regulated entity and the applicable onboarding route.
- Record each evidence requirement for that route.
- Map every requirement to an implemented check or reviewer.
- Define the status for incomplete and conflicting evidence.
- Test one case that needs another verification step.
- Record who authorises the final decision.
Keep application audit data distinct from the document. Review what your partner must receive and retain before choosing fields or retention periods. For related registry terminology, see the CKYC implementation guide.
Review the technical boundary with NamoID
NamoID engineers can help map sign-in, account binding, and evidence handling to your partner's requirements. The controlled driving licence preview reports its issuer signature status as not_verified. Bring a synthetic evidence matrix and the checks your partner requires. Message the NamoID team in Slack