Digital customer onboarding was supposed to be the part of financial services that got easier as technology matured. In many respects it has:- the branch visit that is no longer mandatory, identity documents that can be verified remotely, and a customer who can be onboarded in minutes under the right conditions. Yet for every institution that has digitised its onboarding process, the friction hasn’t disappeared. It has migrated. It now sits in different places, shows up in different ways, and is often harder to diagnose precisely because it doesn’t look like the old friction anymore.
The customers who drop off mid-onboarding, the files that sit incomplete for days, the compliance reviews that stall at the same point every time – these are not random failures. They tend to cluster around identifiable pressure points that most institutions encounter in some form, regardless of how sophisticated their technology stack is. Understanding where onboarding breaks down is the first step toward building a process that doesn’t.
1. Identity Documents That Don’t Cooperate
The starting point of almost every digital onboarding journey is document capture and it is where a significant share of drop-offs occur before the customer has even been assessed for risk.
Uploaded images are blurry, cropped, or backlit. OCR engines misread names because of fonts on older documents. The name on the Aadhaar doesn’t match the name on the PAN because one was registered with an initial and the other wasn’t. The document is genuine, the customer is legitimate, and the process still fails not because of fraud, but because the interface between physical identity documents and digital verification systems is more fragile than it appears.
Where it gets harder: India’s identity document ecosystem is not uniform. Older Aadhaar cards carry different formatting from recently issued ones. PAN cards issued over different periods carry variations in font, field placement and lamination quality that OCR engines trained on cleaner document sets struggle to handle reliably. Add to this the prevalence of documents that have been physically handled, folded, or photographed under poor lighting conditions, and the failure rate climbs well before any question of fraud arises.
The newer frontier: Institutions are now grappling with AI-generated or digitally manipulated documents that pass a visual check but carry subtle inconsistencies in metadata, font kerning or security feature placement. The document verification problem has therefore split into two distinct challenges — operational quality failures for genuine customers, and increasingly sophisticated forgery detection for bad actors and the same system must handle both without creating so much friction that legitimate customers abandon the process.
The institutions that have reduced this friction invest in guided capture interfaces with real-time feedback, extraction logic built for Indian document variability, and a separate forensic layer that runs quietly in the background rather than interrupting the customer experience for every routine upload.
2. The Video KYC Bottleneck
Video KYC (V-CIP) as the RBI frames it; resolved one major friction point by eliminating the branch visit. It introduced a different one in its place.
Scheduling and conducting a live video session requires both the customer and a trained official to be available at the same time, in conditions that meet technical requirements — adequate lighting, stable connectivity, a compatible device. In practice, connectivity drops mid-session, customers call in from environments that don’t meet liveness detection thresholds, and the rescheduling loop that follows is where engagement erodes.
The staffing constraint nobody talks about: For institutions running high onboarding volumes, the staffing model for V-CIP creates a throughput ceiling that isn’t visible until it is already causing delays. Peak onboarding hours typically midmorning and early evening create queuing pressure that well-designed digital journeys simply weren’t built to absorb. Customers who have completed every prior step and are waiting for a video slot experience a jarring shift from the autonomy of self-service to the dependency of appointment-based verification.
The deepfake dimension: As AI-generated facial imagery becomes more accessible, liveness detection has moved from a technical nicety to a frontline fraud control. Passive liveness checks which detect spoofing from a static image or a replayed video are no longer sufficient on their own against adversaries using real-time face-swap technology. Institutions must now run active liveness challenges alongside passive detection, without making the process so burdensome that genuine customers find it intrusive or confusing.
The compliance requirement remains clear trained officials, real-time verification, documented consent. The operational design that makes this scalable without compromising the control is the part most institutions are still actively working through.
3. CKYC Fetch, Upload and the Data Mismatch Problem
The Central KYC Registry was designed to reduce the duplication of KYC effort across institutions and where it works cleanly, it does exactly that. Where it creates friction is in the gap between what the registry holds and what the customer presents at the point of onboarding.
A customer whose CKYC record was created years ago under a slightly different name format, or whose address has changed since the record was last updated, creates a mismatch that the onboarding system flags and the compliance team must resolve manually. The OTP-based consent process for downloading records introduces its own dependency: the mobile number registered with CKYCRR must be active and accessible at the moment of onboarding, which is not always the case for customers who have changed numbers since their last KYC was done.
The data quality layer underneath: Poor upload quality at the time of original CKYC creation compounds the problem. Records with incomplete fields, incorrect date formats, or demographic information entered inconsistently across documents create a fragile foundation that every subsequent interaction with the registry has to work around. When an institution attempts to fetch a record and the match is partial rather than clean, the automated process stops and a human has to intervene which is precisely the outcome the CKYC architecture was meant to reduce.
The newer pressure point: As CKYCRR guidelines have evolved introducing OTP-based consent for downloads, tightening requirements around deceased customer flagging, and mandating deactivation of duplicate records in institutions whose internal processes were built around an earlier version of the registry workflow are finding that their onboarding automation breaks at the points where regulatory requirements have moved on. Keeping the integration current is a continuous operational obligation, not a one-time implementation task.
These are not edge cases. They are routine occurrences in any institution onboarding at scale, and the time spent resolving them manually is one of the less-discussed costs of the current state of CKYC data quality.
4. Risk Classification That Has to Happen Before You Know the Customer
Customer risk classification — the decision about whether a new customer warrants standard due diligence, enhanced due diligence, or something in between is required at onboarding. The difficulty is that it must be made on the basis of limited information, at the precise moment when the institution knows least about the person it is assessing.
The triggers for enhanced due diligence are clear enough in principle: high-risk jurisdictions, PEP status, certain business types, transaction profiles that don’t match declared purpose. In practice, the information available at onboarding to make these assessments is often incomplete.
The disclosure problem: Customers don’t always disclose PEP relationships proactively. Source of funds declarations are accepted at face value because there is no reliable mechanism at onboarding to verify them in real time. Beneficial ownership for accounts held by companies or trusts depends on the accuracy of what is declared, and the declared structure may bear only a partial relationship to the actual one.
The AI-assisted frontier: Some institutions are beginning to layer behavioural signals and device intelligence into the onboarding risk assessment examining not just what the customer declares but how they interact with the onboarding interface, what device they are using, where they are located, and whether any of these signals are inconsistent with the profile being presented. This approach is promising but introduces its own governance challenges: how are these signals weighted, how are they documented, and how does the institution demonstrate to a regulator that a risk decision made on the basis of device behaviour was both reasonable and defensible?
The risk classification that results from current onboarding processes is sometimes less a genuine assessment and more a structured guess – one that the institution revisits only when transaction behaviour eventually tells a different story.
5. The Regulatory Layering Problem
India’s financial sector is regulated by multiple authorities — RBI, SEBI, IRDAI, PFRDA and others each with its own KYC framework, its own definition of what constitutes acceptable identity verification, and its own view of what the onboarding record must contain.
An institution that operates across more than one regulatory perimeter – a bank that also distributes insurance, or an NBFC that also offers investment products must maintain onboarding processes that satisfy each regulator’s requirements simultaneously. The friction this creates is most visible in the customer experience: the same customer, onboarded for one product, is asked to go through elements of the process again for a second product because the regulatory standard for the second product requires something the first didn’t capture.
The account aggregator wrinkle: The emergence of the account aggregator framework has added a new dimension to this problem. Customers who consent to share financial data across institutions expect that KYC information flows with it or at least reduces the repetition. In practice, the regulatory boundaries between what can be shared, in what form, and with what fresh consent, mean that institutions cannot yet fully leverage the aggregator framework to eliminate re-verification across products and customers who expected seamless cross-product onboarding encounter a more fragmented reality.
From the customer’s perspective, repeated onboarding looks like institutional disorganisation. From the compliance team’s perspective, it is a genuine regulatory constraint with no clean workaround yet.
6. The Re-KYC Burden That Onboarding Created
Every customer onboarded today becomes a re-KYC obligation in the future. Periodic KYC updation requirements under RBI’s KYC Master Direction triggered by risk category, customer type and the passage of time mean that the onboarding process doesn’t end with account opening. It creates a future compliance liability that many institutions have not built adequate operational capacity to manage at scale.
The backlog that accumulates silently: Institutions that onboarded aggressively during periods of rapid digital growth now face Re-KYC cycles for large customer cohorts simultaneously. The operational model built for initial onboarding which typically involves a motivated customer initiating the process works very differently from re-KYC, which requires the institution to reach out, get a response, and complete verification within a regulatory timeframe for customers who may have low engagement or changed contact details since their original onboarding.
The expectation mismatch: Customers who were onboarded digitally and expect a digital re-KYC experience encounter institutions that are still managing periodic updates through branch visits or physical document submission. The expectation gap between how the relationship started and how it is maintained is a source of both customer dissatisfaction and growing compliance backlog and as the RBI’s enforcement posture on KYC currency has sharpened, this backlog is increasingly a supervisory risk, not just an operational inconvenience.
7. Integration Gaps Between the Onboarding System and Everything Else
The final friction point is one that customers rarely see but compliance and operations teams live with daily. Digital onboarding platforms don’t always integrate cleanly with the core banking system, the CKYC registry, the sanctions screening engine, the risk classification module and the document management system.
Data entered at onboarding has to be re-entered, manually reconciled or reformatted before it is usable downstream. The onboarding record that makes it into the core system may not be identical to the one created during the verification process, and the difference between the two is where audit findings originate.
The API reliability problem: Real time onboarding depends on a chain of API connections to UIDAI for Aadhaar verification, to say NSDL or UTITSL for PAN validation, to CKYCRR for record fetch, to the sanctions screening engine for name matching. Each link in this chain introduces a dependency. When one API is slow, returning errors, or undergoing maintenance, the onboarding flow either stalls or falls back to a manual workaround. Institutions that have not designed for API failure with graceful fallbacks, retry logic and clear escalation paths find that their digital onboarding process is only as reliable as its least stable external dependency.
The audit trail gap: Regulators expect that every decision made during onboarding — every document checked, every risk flag reviewed, every manual override exercised — is captured in a retrievable, tamper-evident audit trail. In systems where onboarding spans multiple platforms and some steps happen outside the core workflow, assembling a complete audit trail after the fact becomes a forensic exercise rather than a routine retrieval. That gap between what was done and what can be demonstrated is increasingly where supervisory scrutiny lands.
What the Friction Is Really Telling Us
Taken together, these seven points share a common thread: they are not primarily technology failures. They are design failures: places where the process was built for the institution’s internal logic rather than for the reality of the customer and the regulatory environment it sits within.
The newer frontiers — deepfake detection in video KYC, AI-assisted risk signals at onboarding, account aggregator integration, API chain resilience are adding complexity faster than most onboarding architectures were designed to absorb. The institutions making genuine progress are not those chasing the newest capability. They are the ones that have mapped honestly where their process breaks down, accepted that digital onboarding is a continuously governed operation rather than a solved implementation, and built their compliance design around the specific points of failure that keep reasserting themselves.
That kind of institutional honesty is harder than deploying a new platform. It is also considerably more durable.