Video KYC API: Building an RBI-Compliant V-CIP Integration in India

A search for a video KYC API in India returns two kinds of vendor, and neither one answers the question an engineer is actually asking. The first group sells video infrastructure. Its feature matrix runs to thirty-odd items covering WebRTC, recording, agent queueing and screen share, while the compliance section names GDPR and HIPAA without reaching a single Indian requirement. The second group sells RBI compliance on a marketing page that documents no endpoints, no response schemas and no session model at all.

The distance between those two positions is where V-CIP builds go wrong. Under the Reserve Bank of India's rules, video-based customer identification is an evidence-producing workflow with a mandated origination point, a defined control set, a fixed artefact bundle and an audit gate that determines when the account becomes usable. Treating it as a video feature bolted onto an onboarding flow is the mistake those two vendor categories encourage between them.

Read as an integration specification, that control set divides cleanly. Some controls a vendor can carry in software. Others are written as obligations of the regulated entity's own infrastructure and its own trained staff, and no contract moves them. Where the line falls shapes the endpoints, the session state machine and the evidence model, and it fixes the point at which an account is released to operational.

What a video KYC API has to do, and why a video-calling API is not one

A video KYC API is a programmatic interface for initiating, supporting and evidencing a live audio-visual customer identification session that meets RBI's V-CIP requirements and is conducted by a trained official of the regulated entity. Its surface covers session creation and lifecycle; delivery of a secure link or an SDK token; integration with a permitted identity source; liveness and face-match results; capture of the customer's PAN image; a recording carrying live GPS co-ordinates and a date and time stamp; an activity log tied to the official who conducted the session; and status retrieval. Vendor documentation frequently labels the same surface a VKYC API.

A video-calling API exposes the media layer and stops there. Signalling, encryption in transit, recording, queueing and reconnection are genuinely hard problems, and the platforms built to solve them solve them well. Underneath a V-CIP process they remain transport, in the way an SMTP library is transport underneath a transaction alerting system. Controls, the evidence bundle and the audit gate all sit above that layer. A feature matrix listing thirty-six capabilities without naming one regulatory requirement is describing transport.

V-CIP is RBI's video-based route to customer identification, described in the Directions as an alternative method by which an authorised official conducts identification with facial recognition and customer due diligence through a "seamless, secure, live, informed-consent based audio-visual interaction." The definitional ground is covered in detail in our explainer on V-CIP; what follows treats it as a set of build constraints.

RBI's V-CIP control set, read as an integration specification

The controls below are stated as compliance obligations in our V-CIP compliance guide, and the corresponding obligations checklist for banks and NBFCs is here. Neither is repeated. Each control appears once below, followed by what it forces in the architecture.

For commercial banks the governing text is the Reserve Bank of India (Commercial Banks – Know Your Customer) Directions, 2025, reference RBI/DOR/2025-26/169, issued 28 November 2025 and updated as on 29 December 2025, at Chapter VI, paragraphs 26 and 27. That November 2025 consolidation replaced the single 2016 KYC Master Direction with a set of entity-specific directions, so an NBFC works from RBI/DOR/2025-26/361 and other regulated entities from the direction issued for their own category. Paragraph numbering is consistent across them, though the applicable text is worth confirming before it is relied on. V-CIP itself predates the consolidation. RBI introduced it through RBI/2019-20/138, "Amendment to Master Direction (MD) on KYC," dated 9 January 2020, which permitted V-CIP as a consent-based alternate method of establishing customer identity and inserted the definition into the Master Direction on KYC dated 25 February 2016.

Network and infrastructure: the constraint most integrations get wrong

Paragraph 27(1) requires the bank to house the technology infrastructure in its own premises and states that the V-CIP connection and interaction "shall necessarily originate from its own secured network domain." It requires end-to-end encryption of data between the customer device and the hosting point. The infrastructure or application must also be capable of preventing connection from IP addresses outside India or from spoofed IP addresses.

That single clause about origination reorders the whole evaluation. A hosted session that opens on a vendor's domain, or a redirect out of the bank's application into a vendor-branded URL, does not on its face satisfy an origination requirement written against the bank's own secured network domain. Deployment model therefore ranks ahead of feature list. Where is the application hosted, which domain terminates the session, who holds the media path, and does the vendor support deployment inside the bank's environment at all, or only as a multi-tenant service.

Geo-restriction is the second consequence. Blocking connections from IP addresses outside India, and from spoofed addresses, has to exist as an enforcement point in the stack, and a datasheet line is not one. The check runs before the participant joins the session, never as a flag written into the recording afterwards, and it has to be exercised in a test. A session attempted from a foreign egress address should fail closed and produce a logged, retrievable outcome.

Vulnerability assessment, penetration testing and security audit conducted by empanelled auditors of the Indian Computer Emergency Response Team (CERT-In) come from the same paragraph 27(1). For a delivery plan that is a release gate with external scheduling attached, and it applies to the deployed system, not to the vendor's product in the abstract. Booking it after the code freeze is how V-CIP launches slip a quarter.

Session controls: liveness, face match, randomisation and prompting

Paragraph 27(1) requires the application to have face liveness/spoof detection as well as face-matching technology with a high degree of accuracy. Under paragraph 27(2) the bank varies the sequence and/or type of questions to establish that the interaction is real-time and not pre-recorded, rejects the account opening process if any prompting is observed at the customer end, and ensures the liveness check does not result in the exclusion of persons with special needs.

Randomisation is a server-side concern. If the question set is generated on the client, or drawn from a fixed script the agent reads, nothing exists to evidence when an auditor asks how real-time interaction was established. The generator belongs behind the API, and the selection belongs in the activity log. Variance across sessions has to be something an auditor can query.

Prompting-rejection needs somewhere to live in the state model. An agent console needs to terminate the session with a distinct outcome mapped to rejection. That outcome then travels to the onboarding system as a terminal state, and everything downstream has to tell it apart from a technical failure or an abandonment. Systems that model the session as a binary pass or fail lose the distinction at the first integration boundary.

The accessibility requirement rules out a liveness design built solely on instructed gestures. A flow whose only liveness signal is "blink twice" excludes customers who cannot comply, and it carries no fallback path that preserves the control.

Terminology matters here more than it looks. RBI's text says "face liveness/spoof detection." It does not say "deepfake detection," and it does not mandate specific gestures such as blinking or smiling. Vendors who market deepfake detection as an RBI requirement are describing their own roadmap. Deepfake detection is a legitimate control to buy, and several platforms including KYC Hub offer it, but it sits above the regulatory floor and does not stand in for it. Note the scope boundary before writing presentation-attack resistance into a requirement: standard testing methodologies address attacks presented at the biometric capture device, and system-level vulnerability assessment sits outside that scope, so injected media entering through a virtual camera is a separate control question.

Identity sources and document capture

Paragraph 27(2) permits identity to be established through one of four routes: OTP-based Aadhaar e-KYC authentication, offline verification of Aadhaar, KYC records downloaded from the Central KYC Records Registry using the KYC identifier, or an equivalent e-document of an officially valid document, including documents issued through DigiLocker.

Four routes means four branches, each with its own response shape, failure modes and artefacts landing in the evidence bundle. An integration that models identity as one field, populated by whichever source happened to answer, produces an audit trail that cannot explain which route was taken.

Two rules in this paragraph are pre-flight validations, and reviewers see them far too late. Where offline Aadhaar verification is used, the XML file or the Aadhaar Secure QR code must not be older than three working days from the date of the V-CIP. That is a testable constraint with a working-day calendar behind it, including the question of what the system does when a session is scheduled on Friday and completed on Monday. The second rule is that a printed copy of an equivalent e-document, an e-PAN included, is not valid for V-CIP. So the document-capture path has to distinguish a displayed digital document from a printout, and it has to fail the session instead of recording the outcome as verified.

The direction also requires a clear image of the PAN card to be captured as displayed by the customer during the session, except where an e-PAN is provided. That means live capture inside the session, and an upload collected before or after it will not do. The image belongs to the session's artefact set. What prevents a legible-but-wrong document from reaching the review stage is field-level validation against the extracted OCR values at the point of capture.

Evidence: what every session has to leave behind

Under paragraph 27(1) the video recording must contain the live GPS co-ordinates, described in the direction as geo-tagging, of the customer undertaking the V-CIP, together with a date and time stamp. Paragraph 27(3) requires the bank to store the entire data and recordings of V-CIP in a system or systems located in India, and to preserve the activity log along with the credentials of the official who performed the V-CIP.

In practice that becomes a single retrievable bundle keyed to the session identifier: the recording with its embedded geo-tag and timestamp, the activity log carrying the official's credentials, the captured PAN or document images, the liveness and face-match outcomes with their scores, and the consent record. Screenshots taken at decision points belong in the same bundle, as do the IP address the session ran from and the identity of every officer who touched the case. The most reusable idea circulating in vendor documentation is a purpose-bound, geotagged, time-stamped consent artefact treated as a first-class object, and it is worth adopting deliberately. A consent record that exists only as a boolean on a session row is not evidence.

Two questions follow that most procurement processes never ask. Where does the recording physically sit? That answer lives at the storage layer, and a contract clause is not evidence of it. The second question is how the bundle comes out: in what format, through which endpoint, with what latency, and with what guarantee of chain of custody between the vendor's store and the bank's archive. An integration that can display a recording in a vendor console but cannot export the bundle has moved a compliance obligation into someone else's interface.

Retention is a separate statute and is frequently misattributed to the V-CIP paragraph. It comes from section 12 of the Prevention of Money-Laundering Act, 2002, under which a reporting entity maintains records of all transactions for five years from the date of the transaction between the client and the reporting entity, and maintains records of documents evidencing the identity of clients and beneficial owners, along with account files and business correspondence, for five years after the business relationship has ended or the account has been closed, whichever is later. V-CIP artefacts are identity evidence, so the second clock governs the recording, and it does not start at session close.

Concurrent audit: the gate that makes the account operational

Paragraph 27(2), at clause (xv), requires the bank to make all accounts opened through V-CIP operational only after subjecting them to concurrent audit.

That is a state machine, and no compliance footnote will implement it. Between "V-CIP session completed with a positive decision" and "account operational" there is a pending state, and something has to move the account out of it. So the integration needs an explicit account status that blocks transactions while the identification is complete, plus an interface through which the concurrent auditor reviews the session and its artefacts. Releasing the account is then its own event, whether a webhook, a queue message or an API call, and that release is written into the audit trail. Teams that discover this after the onboarding flow is built end up bolting a manual hold onto a system that was designed to activate on decision.

One correction is worth making explicitly, because several vendor pages state the opposite. The Directions require concurrent audit. They do not use the term "maker-checker." Maker-checker is a common way for banks to implement review workflows, and a configurable maker-checker workflow is a reasonable thing for a platform to offer, but presenting it as the regulator's mandate misstates the source and understates the obligation.

The session lifecycle: what the API surface actually looks like

Vendor documentation on this SERP names between four and ten endpoints and stops. What follows is the lifecycle a video KYC integration actually has to model, described generically so that it holds across providers.

Scheduling and the pre-session workflow

Most integration guides begin at session creation. A substantial part of the surface sits before it, and it carries regulatory constraints of its own.

The agent pool is not a roster of available staff. Only officials specially trained for V-CIP may conduct a session, so the pool a scheduler draws from is filtered by regulatory eligibility first, then by shift availability, then by jurisdiction or language where an institution operates across regions. Time slots offered to a customer derive from that filtered roster and the institution's operational hours. A scheduler that offers a slot without applying the eligibility filter produces a booking no qualified official can staff, and the failure surfaces at the worst moment, with the customer already waiting.

Allocation is a capacity problem, decided on availability at the chosen time, current agent workload, capacity thresholds and any service-level commitment attached to the segment. The allocation stays provisional until the session actually begins, so the slot has to be locked against double booking while staying releasable when the customer never arrives. Both sides of that behaviour belong in the integration contract, because an onboarding system that cannot see a provisional hold will cheerfully offer the same slot again. Confirmations to both parties, a reminder on the day and a readiness check immediately before the slot are what keep the no-show rate down.

Exception handling is where the audit trail either holds or breaks. When either party fails to appear, the event needs a timestamp and a reason code written to the log. A session that did not happen is a different regulatory fact from a session that was rejected, and an auditor reading a bare gap in the schedule cannot tell them apart. From there the system either reassigns from the eligible pool or offers the customer a new slot against the same availability matrix.

Rescheduling has one consequence that is easy to miss. Moving a session re-opens the three-working-day freshness rule on any offline Aadhaar payload captured for the original slot, so the pre-flight validation has to run again at the new time and cannot carry forward from the booking.

The happy path

Authenticate against the API, typically with a bearer token issued to the server and not to the client. Create or reference the customer record. Session creation returns a session identifier and either a secure link for delivery over SMS, email or a messaging channel, or a short-lived token for an embedded SDK. Pre-session checks then run: device and browser capability, network bandwidth, IP geo-restriction, and capture of informed consent as a stored artefact.

The customer enters the queue, and an official is assigned from the pool described above. The live session carries the substantive controls: document capture against whichever of the four identity routes applies, live PAN capture where an e-PAN has not been supplied, liveness and face match, and the randomised questions drawn server-side. The identity branch matters here, because the artefacts differ. An Aadhaar OTP e-KYC route produces a UIDAI response. An offline Aadhaar route produces an XML or QR payload with a generation date that has to be validated against the three-working-day rule. A CKYCR route produces a downloaded record.

The official records a decision. The session closes, the recording finalises with its geo-tag and timestamp, and the status becomes retrievable by polling or, preferably, by signed webhook. The artefact bundle is retrieved and archived. The account enters its pending state, the concurrent audit runs, and the release event makes the account operational.

SDK, hosted link, or API-only

The three integration shapes trade control against effort in ways that map directly onto the origination requirement.

A hosted link is the fastest to ship and gives away the most. The session opens wherever the vendor hosts it, so the domain question has to be answered explicitly through white-label domain mapping and never assumed. The customer-facing interface belongs to the vendor.

A video KYC SDK embedded in the bank's own web and mobile applications keeps the session inside the institution's application shell and its domain, at the cost of platform coverage work. Confirm platform support line by line and not by brand: web, Android and iOS at minimum, plus whichever cross-platform framework the mobile team actually uses. An SDK also puts version management on the roadmap, since a liveness model update usually arrives as a client release.

API-only integration, where the institution builds its own agent console and customer surface on top of session, media and verification endpoints, gives the most control over origination, interface and evidence handling. It also costs the most to build and to keep audited. It is the right choice when the deployment sits inside the bank's own environment and the agent workflow has to match existing branch tooling.

The failure paths nobody documents

Every ranking page documents the happy path. The failure paths are where integration time actually goes.

A customer drops mid-session on a mobile network. Does the session resume against the same identifier with the partial recording preserved, or does it start over and orphan the first recording, and if it orphans it, does that fragment still form part of the evidence set. Image quality fails on the document capture. Is there a re-capture prompt with a retry limit, and does exhausting the limit produce a distinct outcome from an agent rejection. Prompting is observed. The session terminates in mandatory rejection, and that state has to travel intact through every downstream system.

Agent-side failures deserve the same treatment. Queue overflow, agent unavailability outside working hours and group capacity limits all form part of the integration surface, and the better platforms expose them as queue-status, availability and agent-group endpoints. Teams that treat agent capacity as an operations concern arriving after go-live end up with customers queuing where the onboarding application cannot see them.

One design decision cuts across all of these. Polling-only status makes drop handling materially harder than signed webhooks with idempotent delivery and replay. If the only way to learn that a session ended is to ask every few seconds, the system cannot distinguish a slow session from a dead one without a timeout policy it has to invent.

What the API cannot do for you

Paragraph 27(2) requires that the V-CIP process be operated only by officials of the bank specially trained for that purpose. Where a bank takes the help of Business Correspondents to facilitate the process, assisted V-CIP is permitted only at the customer end, and the bank retains ultimate responsibility for customer due diligence. Paragraph 13 of the same Directions states that the bank shall not outsource the decision-making functions of determining compliance with KYC norms.

Those three provisions, read together, set the boundary. A vendor can supply the media transport, the liveness and face-match models, the agent console, the artefact store and the endpoints that tie them together. What stays with the regulated entity is the network domain the session originates from, the trained officials who conduct it, the decision on compliance and the liability for the customer relationship. No product transfers them. A banner claiming "100% RBI compliant" describes a marketing position, and the Directions confer no such status on any software.

The practical consequence for a build team is a change of question. "Is your platform RBI compliant?" has no useful answer, because compliance is a property of a regulated entity's process and not of a software product. "Which of these controls does your stack let us own, and which does it require us to hand over?" produces an answer that can be verified in a sandbox and written into a contract.

The same boundary appears elsewhere in the payments stack. The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025, reference RBI/DPSS/2025-26/141 dated 15 September 2025, permit a non-bank payment aggregator to use agents for assisted V-CIP during merchant onboarding, and adopt the V-CIP definition from the Master Direction on KYC without replacing it.

Evaluating a video KYC API in India: what to ask for

This is integration due diligence, and most of it gets answered in a sandbox. Trial access is usually free; production V-CIP is not, because the obligations under paragraph 27 attach to the regulated entity whatever the integration costs.

Start with sandbox access carrying test identities across all four identity routes, and with documented endpoints and response schemas in place of a feature list. Ask whether status arrives by signed webhook with idempotency keys and replay. The error taxonomy is worth requesting in full: the distinct codes for drop, quality failure, retry exhaustion, prompting rejection and agent-side termination. SDK platform coverage should be named platform by platform, alongside the minimum bandwidth at which the session degrades gracefully.

On the controls specifically: ask where question randomisation is generated and how variance is evidenced to an auditor; ask for presentation-attack testing evidence against a published methodology instead of a "deepfake detection" label; ask for confirmation of India storage at the infrastructure layer, naming the region and the service; ask whether the in-session checklist can vary by customer type, since an individual and a business, or a resident and a non-resident, rarely need the same document set or escalation path; ask to see the exportable audit bundle and its format; ask what interface the concurrent auditor uses and what event releases the account; and ask whether the deployed configuration has been through vulnerability assessment, penetration testing and security audit by CERT-In empanelled auditors, and when.

Scheduling is the part most evaluations skip entirely. Ask how the eligible agent pool is filtered, and whether V-CIP training status is a field the system enforces or a spreadsheet someone maintains. Slot locking should prevent double booking, and a vendor should be able to demonstrate it. When a customer or an official fails to appear, the log needs a reason code an auditor can filter on.

Then test the constraints that are easiest to miss: attempt a session from a foreign IP, submit an offline Aadhaar payload generated four working days earlier, present a printed e-PAN, and run a liveness check with a customer who cannot perform an instructed gesture. Each should fail in a defined, logged way.

Data portability and exit belong in the conversation before signing, because the evidence bundle has a retention clock measured in years and the vendor relationship may not.

Verification APIs are rarely consumed in isolation. They sit alongside document checks, database verification, screening and decisioning in the same onboarding flow, and every additional vendor portal adds its own authentication model, sandbox and audit export. A verification API portal that exposes the API catalogue, sandbox, OpenAPI specifications and audit trail behind one login compresses that work. KYC Hub reports go-live in roughly a day against a typical alternative of six weeks, and a catalogue built on 100+ native microservices means most of the surrounding checks become configuration instead of a second integration.

Where the V-CIP API sits in the onboarding stack

Upstream, the V-CIP session consumes identity from the same sources the rest of onboarding uses. The Central KYC Records Registry, defined in the Directions as the entity that receives, stores, safeguards and retrieves KYC records in digital form, is one of the four permitted identity routes, which means a customer with an existing KYC identifier may need no document capture at all. DigiLocker supplies equivalent e-documents of officially valid documents, and the direction names it explicitly among the accepted routes. The V-CIP flow inherits both integrations; it does not own them.

Downstream, the identified customer moves into sanctions, PEP and adverse-media screening, risk rating, and ongoing monitoring, and the KYC record is filed to CKYCR. This is where an integration scoped as video calling plus liveness starts to leak. Screening that runs as a disconnected offline step after the session has closed produces a decision the session cannot evidence, which is why the stronger designs run sanctions, PEP and watchlist checks in-line while the official is still on the call and the customer can still be questioned.

The wider problem is continuity of evidence. What later stages depend on is produced during the V-CIP session: the official's credentials, the identity route taken, the consent artefact, the geo-tagged recording. If that evidence terminates at the vendor boundary, the audit trail breaks at the seam between identification and everything that follows. A single regulator-ready audit trail across onboarding, screening and monitoring is the practical answer, and it is an architectural decision made at integration time. Nobody buys it later as a reporting feature.

The November 2025 consolidation moved V-CIP into an entity-specific direction for commercial banks without loosening a single control in it. The origination requirement and the concurrent-audit gate both survived the rewrite intact. For an integration already in production, the work that consolidation creates is largely citational: control descriptions, policy documents and audit templates that point at the 2016 Master Direction now have to point at the direction issued for that entity category, while the code behind the origination check and the release event stays where it is.

See this in a sandbox before you build against it. Book a walkthrough of KYC Hub's V-CIP sandbox — the identity routes, the evidence bundle and the concurrent-audit interface, live.