We build Video Customer Identification Process flows to the Reserve Bank of India's prescribed requirements — agent-conducted live sessions, the capture and geotagging the process specifies, recording retention, and the concurrent audit path. The engineering effort sits mostly around the session: queueing, network resilience, drop-off recovery and rescheduling.
V-CIP is a specified process, not a feature
The most expensive misunderstanding on this subject is treating V-CIP as a video call added to an onboarding screen. It is not a UI pattern. It is a process the regulator has defined, and the definition constrains who conducts it, what must happen during it, what must be recorded, and what happens to that recording afterwards.
That distinction changes what the build actually is. If it were a video call, the work would be picking a video SDK and embedding it. Because it is a specified process, the work is establishing that each prescribed element is satisfied and evidenced, and building the operational machinery that lets a live human conduct sessions at your volume without the queue collapsing.
Teams discover this in a predictable order. The video call works in the first demo. Then someone asks how the official is authenticated and trained. Then someone asks what happens when the customer's connection drops halfway through. Then someone asks where the recordings are stored, for how long, and who can retrieve one when it is asked for. Each of those is a larger piece of work than the call.
What the build includes
- Session orchestration — the queue between a customer requesting verification and an official becoming available, including realistic wait communication and a rescheduling path that does not lose the application.
- The prescribed capture set, built into the session flow rather than left to the official to remember: the live interaction, the location capture the process specifies, and the artefacts the session is required to produce.
- Network resilience. Customers join from mobile connections that vary enormously. The flow needs to handle degradation and mid-session disconnection by resuming or cleanly rescheduling, not by discarding a half-complete session.
- Recording storage and retention on infrastructure you control, with retrieval by customer identifier, retention rules applied deliberately, and access restricted and logged — these recordings are among the most sensitive records your organisation will hold.
- The concurrent audit path, so that reviewing sessions is a designed workflow with sampling and outcomes recorded, rather than an afterthought someone builds under audit pressure.
- Official-side tooling — the console the trained official actually works in, which determines how long each session takes and therefore what your capacity costs. This is routinely the least designed and most impactful surface in the whole system.
Where the engineering effort actually goes
If you plotted effort across this build, the live video portion would be a small slice. The rest divides roughly into three areas.
The first is capacity and queueing. V-CIP requires a human, so throughput is bounded by staffed hours in a way no API-based check is. That makes queue design a product decision as much as an engineering one: whether sessions are scheduled or on-demand, what the customer sees while waiting, what happens outside staffed hours, and how the system behaves when demand spikes past capacity. Getting this wrong does not produce an error message; it produces abandonment that looks like disinterest.
The second is the unhappy path. Live sessions fail in ways API calls do not — the customer's connection drops, the lighting makes capture impossible, the official has to terminate the session, the customer joins on a device that cannot do what the process requires. Each of these needs a defined outcome that preserves the application and tells the customer what happens next. A flow that returns them to the start after a failed session will lose most of them.
The third is retention and retrieval. You are now storing video recordings of identifiable individuals presenting identity documents, and you are obliged to keep them. Storage cost, access control, retrieval latency when a specific session is requested, and deletion at the end of the retention period all have to be designed rather than inherited from whatever the video vendor does by default.
Drop-off, and what actually moves it
When we are asked to improve completion on an existing V-CIP flow, the fixes that work are rarely inside the session.
The wait is usually the largest single factor. A customer routed into a queue with no indication of duration will abandon at a rate that no improvement to the call itself will offset. Communicating a realistic wait, and offering a scheduled slot as an alternative to waiting, changes the number more than anything else available.
The second factor is the moment. Live verification demands the customer's full attention and a decent connection simultaneously. Requesting it at a point in the journey the customer did not choose guarantees a share of failures that have nothing to do with willingness. A flow that lets the customer pick a time, and that reminds them, converts better than one that insists on now.
The third is the recovery path. Sessions will fail. What determines the eventual completion rate is whether a failed session is a dead end or a reschedule with context preserved.
Regulatory context
The Video-based Customer Identification Process is defined within the Reserve Bank of India's Master Direction on Know Your Customer, available in full at rbi.org.in. We link it rather than reproducing it, and we would encourage your compliance team to work from the current text of the Direction directly.
The reason is specific to this subject. V-CIP requirements are prescriptive and have been amended since introduction. Secondary summaries — including vendor-published ones — go stale in ways that are not obvious from reading them, and a flow built to a superseded description of the process looks compliant right up to the point where it is examined.
Where we fit
We build the V-CIP process; we are not the platform it runs on. Where you have selected a platform, we build the process around it correctly and tell you honestly where its defaults do not meet what the Direction requires. Where you have not, we help you select on the criteria that matter operationally rather than on the demo.
Where V-CIP is one channel within a larger onboarding flow, the surrounding checks are KYC API integration work. Where it is being used as a channel to clear an overdue book, see Re-KYC remediation.