Automated KYC can take the mechanical, repeatable part of identity verification — document capture and quality checks, face match, liveness, field matching against the ID — and turn a multi-minute manual onboarding into a fast, logged flow, while a share of cases still routes to human review. What it cannot do is decide, on its own, that your onboarding is compliant. Whether a KYC flow satisfies the RBI's KYC directions and DPDP's data-handling requirements is a question for your compliance and legal team, not a setting a vendor certifies. Orkivanta has built verification rails inside a regulated lending environment, not a packaged KYC product. Here is what automates, what stays human, and the questions to keep open.
What automates cleanly
The rule-bound steps are where automation is strong. Document verification checks that an ID is genuine, readable, and not tampered with. Face match compares a selfie to the document. Liveness confirms a real person rather than a photo. Field extraction and matching line up name and date of birth against the document and your records. And underneath all of it, a complete audit log records every check and its result — the part that makes the rest defensible in a regulated setting.
That is the mechanical work that repeats identically across thousands of applicants, which is exactly where an agent is consistent, tireless, and logged. It is not the same as the flow deciding it is compliant.
The 70/30 reality
HyperVerge publicly reports that for ZestMoney, an Indian BNPL lender, automated C-KYC took onboarding from around 10 minutes to under 10 seconds, with roughly 70% automated and about 30% going to manual review, alongside a large rise in transactions. Those are HyperVerge's reported figures for its client — third-party public evidence, not an Orkivanta result.
The honest thing that 70/30 split tells you is this: the credible way to talk about KYC automation is not '100% automated.' A residual share always needs a human, and a vendor claiming full automation is describing a demo, not a regulated flow. Plan for the manual-review queue as part of the design, not as a gap to close to zero.
Where Orkivanta actually sits
We do not sell a packaged KYC product. What we have run is a bespoke build in a lending environment — document verification, e-signature, credit-bureau integration, co-borrower flows, and full audit logging — described anonymized at /case-studies/regulated-verification-rails, with the productised agents at /products. The transferable discipline is auditability: in a setting where a wrong answer is a legal event, the log that lets you reconstruct any decision is the point of the build, not overhead. That case study claims no certification and no compliance badge, and neither should any vendor.
The compliance questions to keep open
These are decisions for your compliance and legal function, framed as questions rather than answers a blog can give. Does your flow meet the RBI's KYC directions for your product and customer type? What consent does DPDP require for the identity data you collect, and how long may you keep it? Who reviews the roughly 30% that do not auto-clear, and against what criteria? What must the audit log capture to answer a regulator later?
The system's job is to enforce whatever your counsel decides and to log it completely. It is not to author the policy or to vouch that your use of it is lawful. Keep those questions open and human-owned; that is the posture a regulated build requires.
When automated KYC is wrong for you
When you are pre-product-market-fit with a handful of onboardings a day — manual review is cheaper than a build, and you have bigger problems than verification throughput.
When you are looking for a vendor to own compliance accountability. No automation and no vendor can take that off your institution; the accountability stays with you.
And when you expect fully automated KYC. The residual human-review share is not a defect to engineer away — it is part of a defensible regulated flow. If that share is unacceptable to your model, the problem is the expectation, not the tool.