When the Reserve Bank of India introduced the Video-based Customer Identification Process (V-CIP) framework, it did not simply permit banks and NBFCs to conduct KYC over video calls. It prescribed a detailed, non-negotiable set of infrastructure and technical requirements that every regulated entity must satisfy before conducting a single V-CIP session. These requirements -- codified in the RBI Master Direction on KYC (RBI/2021-22/35, dated May 10, 2021) -- cover everything from where the technology must be physically hosted to how face-matching algorithms must perform under adversarial conditions. This article is a comprehensive, provision-by-provision examination of every infrastructure and technical standard the RBI mandates for V-CIP systems, and what it takes to build or procure a platform that meets them.
The Regulatory Foundation: RBI/2021-22/35
The V-CIP infrastructure requirements are not advisory. They carry the full force of regulatory direction under the Prevention of Money Laundering Act (PMLA) and the Reserve Bank of India Act. Non-compliance does not merely expose institutions to operational risk -- it exposes them to regulatory action, monetary penalties, and potential loss of license. The Master Direction on Know Your Customer (KYC) Direction, 2016, as updated by RBI/2021-22/35, lays out the V-CIP technology framework in granular detail.
The circular addresses V-CIP infrastructure across several interconnected dimensions: physical hosting and network architecture, encryption and data integrity, biometric verification technology, security testing and audit, and application lifecycle management. Each dimension carries specific mandates that a regulated entity must demonstrate compliance with -- not just at the time of initial deployment, but on an ongoing basis.
What follows is a systematic analysis of each requirement, drawn directly from the provisions of the circular, with practical guidance on how to implement them.
1. Technology Housing: Own Premises, Secured Network Domain
The RBI's very first infrastructure requirement addresses where V-CIP technology must physically reside. The circular is explicit:
"The technology should be housed in the RE's own premises and operated from a secured network domain of the RE."
This requirement has significant architectural implications. The V-CIP application -- including the video conferencing engine, document verification modules, biometric processing components, and session management systems -- must run on infrastructure controlled by the regulated entity (RE). This does not necessarily mean the RE must own bare-metal servers in a private data center, but it does mean the infrastructure must be within the RE's operational control and secured network perimeter.
In practical terms, this means the V-CIP platform cannot be a pure SaaS application hosted entirely on a third-party vendor's shared infrastructure, accessed over the public internet. The RE must maintain control over the network domain -- the DNS resolution, the firewall policies, the access control lists, and the TLS termination points. Cloud deployments are permissible, but only when the RE controls the virtual private cloud (VPC), the network security groups, and the access policies. The technology vendor may provide the software, but the RE must own the deployment.
For institutions evaluating V-CIP vendors, this means asking a critical question: does the vendor support deployment within our controlled infrastructure? A vendor that only offers a multi-tenant SaaS model with no option for dedicated or on-premise deployment may not satisfy this requirement.
2. End-to-End Encryption Standards
The circular mandates a specific encryption posture for all V-CIP communications:
"The process shall be end-to-end encrypted."
End-to-end encryption (E2EE) in the V-CIP context means that the video stream, audio stream, document images, biometric data, and all signaling information exchanged between the customer's device and the RE's V-CIP platform must be encrypted such that no intermediate party -- including network providers, CDN operators, or even the technology vendor -- can access the plaintext content.
This is a higher standard than transport-layer encryption (TLS/SSL), which only protects data in transit between two endpoints but allows the server to access plaintext. True E2EE requires that encryption keys are negotiated directly between the customer's device and the RE's V-CIP application, with no key escrow at intermediate hops. In practice, this means implementing protocols like SRTP (Secure Real-time Transport Protocol) with DTLS (Datagram Transport Layer Security) for media streams, and TLS 1.3 for signaling channels.
The encryption requirement also extends to data at rest. Video recordings, captured documents, biometric templates, and session metadata stored after the V-CIP session must be encrypted using AES-256 or equivalent encryption standards. Key management must follow industry best practices -- ideally using Hardware Security Modules (HSMs) for key storage and rotation.
When evaluating V-CIP platforms, institutions should demand architectural documentation showing exactly how E2EE is implemented across the entire data flow -- from customer device to agent interface, from session recording to archival storage. Any gap in the encryption chain represents both a compliance failure and a security vulnerability.
3. Customer Consent: Auditable and Alteration-Proof
Consent is not just a UX checkbox in V-CIP. The RBI mandates that consent must be captured in a manner that is both auditable and tamper-proof:
"Customer's consent shall be taken in an auditable and alteration-proof manner."
The "auditable" component means that every consent action -- when it was given, what it covered, and by whom -- must be logged with sufficient metadata to reconstruct the consent event at any future point. This includes timestamps, session identifiers, the consent text presented to the customer, and the customer's affirmative action (click, verbal acknowledgment, or both).
The "alteration-proof" component is more technically demanding. It means the consent record, once created, must be immutable -- it cannot be modified, deleted, or backdated without detection. Implementation approaches include cryptographic hashing (where each consent record's hash is stored independently), append-only databases, blockchain-anchored audit logs, or write-once storage systems. The key test is whether a regulator or auditor can independently verify that the consent record has not been tampered with since its creation. Institutions that rely on simple database entries for consent recording -- entries that an administrator could theoretically modify -- may not meet this standard.
4. IP Geolocation and Connection Origin Controls
The RBI imposes specific controls on where V-CIP connections can originate from:
"Necessary measures should be taken to prevent connections from outside India, or from spoofed IP addresses."
This requirement has two distinct components. First, the V-CIP platform must implement IP geolocation filtering to block connections originating from outside India. This means integrating with commercial IP geolocation databases (such as MaxMind GeoIP2 or IP2Location) and enforcing country-level blocking at the application or network layer. The system must resolve the customer's IP address to a geographic location and reject connections that resolve to non-Indian jurisdictions.
Second, the platform must detect and block spoofed IP addresses. IP spoofing -- where a customer or attacker masks their real IP address to appear as though they are connecting from within India -- is a known attack vector. Mitigation approaches include TCP handshake validation (spoofed IPs typically cannot complete a full TCP three-way handshake), VPN and proxy detection (using databases that track known VPN exit nodes, Tor relay IPs, and public proxy servers), and behavioral analysis (flagging connections with anomalous routing characteristics).
Beyond IP-based controls, the circular also mandates GPS-based location capture. The platform must collect the customer's device GPS coordinates during the session and store them with a date-time stamp. This provides a secondary, independent verification of the customer's physical location. Combined with IP geolocation, this creates a dual-layered location verification system that is significantly harder to circumvent than either method alone.
5. GPS Geo-Tagging and Time-Stamping
Closely related to the IP geolocation requirement, the RBI mandates that every V-CIP session must capture precise location and temporal data:
"GPS coordinates and date-time stamp shall be captured during the V-CIP session."
GPS coordinates must be captured from the customer's device using the device's location services API. The V-CIP application must request and obtain location permissions before the session begins, and the coordinates must be captured at session initiation -- not retroactively. The captured coordinates must have sufficient precision to identify the customer's city-level location (typically 4-5 decimal places of latitude and longitude).
The date-time stamp must use a reliable, centralized time source -- ideally NTP-synchronized server time rather than the customer's device clock, which can be manually adjusted. The timestamp must capture both the session start and end times, and must be stored in a standardized format (ISO 8601 with timezone offset) to ensure unambiguous interpretation during audits. These geo-tags and timestamps become part of the permanent session record and are critical for audit trail integrity, dispute resolution, and fraud investigation.
6. Video Quality Standards
The RBI does not prescribe a specific video resolution or codec, but it sets a functional standard that is equally demanding:
"Video quality must be such that it allows identification of the customer beyond doubt."
"Beyond doubt" is a high bar. This means the video must be of sufficient resolution, frame rate, lighting, and clarity that a trained official can positively identify the customer's facial features, read document text held up to the camera, and detect any signs of document tampering or impersonation. In practical terms, this typically requires a minimum of 720p video resolution at 25-30 frames per second, with adaptive bitrate encoding that degrades gracefully under poor network conditions rather than dropping below a usable quality threshold.
The platform must implement quality monitoring during the session. If video quality degrades below the identification threshold -- due to network congestion, poor lighting, or device limitations -- the system must alert the agent and, if quality cannot be restored, the session must be aborted. Completing a V-CIP session with substandard video quality is a compliance violation, as it undermines the entire purpose of visual identification. The recorded video must also maintain this quality standard in storage, meaning compression algorithms must not reduce the recording below the identification threshold.
7. Face Liveness Detection and Spoof Prevention
The biometric verification requirements in the V-CIP circular are among its most technically rigorous provisions:
"The V-CIP application shall have face liveness/spoof detection features and face matching to ensure that the process is not carried out using a photograph, pre-recorded video or any other spoofing artefact."
This provision mandates two distinct technical capabilities. First, face liveness detection -- the ability to determine that the person appearing on camera is a live, physically present human being, not a static photograph, a video replay, a 3D mask, a deepfake video, or any other spoofing artefact. Liveness detection typically employs a combination of active challenges (asking the user to blink, turn their head, or perform a specific gesture) and passive analysis (detecting micro-movements, skin texture, reflection patterns, and moire patterns that distinguish a real face from a reproduced one).
Second, face matching -- the ability to compare the live face captured during the V-CIP session with the photograph on the customer's identity document (Aadhaar, PAN, passport, etc.) and confirm that they are the same person. The circular further specifies the accuracy standard:
"Face matching shall be carried out with high accuracy."
While the RBI does not specify a numerical threshold for "high accuracy," industry practice and regulatory expectation converge on a false acceptance rate (FAR) below 0.01% and a false rejection rate (FRR) below 1%. The face-matching algorithm must perform reliably across diverse skin tones, lighting conditions, aging differences between document photos and live appearance, and partial occlusions (such as spectacles). Institutions should demand ISO 30107-3 certification for liveness detection components and NIST FRVT benchmarks for face-matching algorithms when evaluating V-CIP technology partners.
8. AI Technology in V-CIP: Permitted but Governed
The RBI explicitly permits the use of artificial intelligence in V-CIP processes:
"AI technology may be used for carrying out the V-CIP process."
This permission is significant because it legitimizes the use of machine learning models for document classification, OCR-based data extraction, automated quality assessment, anomaly detection, and decision support during the V-CIP session. AI can assist the authorized official by pre-screening documents, flagging potential inconsistencies, scoring liveness confidence, and automating data entry -- all in real-time during the video call.
However, the permission to use AI does not absolve the RE of human oversight. The V-CIP circular requires that sessions be conducted by "trained officials" who make the final verification decision. AI serves as an augmentation tool, not a replacement for human judgment. Institutions implementing AI in their V-CIP workflow must maintain clear boundaries between automated assistance and human decision-making, ensure AI model decisions are explainable and auditable, and establish governance frameworks for model training, validation, bias testing, and ongoing monitoring. The use of AI also triggers additional requirements around model security -- adversarial robustness, data poisoning prevention, and model integrity verification.
9. Regular Upgrades Based on Forgery Attempts
The RBI recognizes that V-CIP security is not a one-time implementation but an ongoing arms race against evolving fraud techniques:
"The V-CIP application shall be regularly upgraded based on the detected attempts of forgery."
This is not a vague recommendation -- it is a mandatory requirement for continuous improvement. Every detected fraud attempt, every new spoofing technique, and every emerging deepfake methodology must feed back into the system's defenses. Institutions must maintain a structured process for collecting and analyzing fraud intelligence, updating liveness detection models, enhancing face-matching algorithms, and patching application vulnerabilities.
In practice, this requires a dedicated security response capability -- either in-house or through the technology partner -- that monitors the threat landscape, processes incident reports from V-CIP agents, conducts post-mortem analysis of detected and near-miss fraud attempts, and deploys countermeasures within defined SLA timelines. Institutions should establish a quarterly (at minimum) upgrade cycle for their V-CIP fraud detection components, with emergency patching capability for critical vulnerabilities. Audit evidence of these upgrades -- version histories, change logs, fraud analysis reports -- must be maintained for regulatory review.
10. VA/PT and Security Audit by RBI-Accredited Agencies
The RBI does not trust self-certification for V-CIP security. The circular requires independent, external validation:
"Vulnerability Assessment / Penetration Testing (VA/PT) and Security Audit of the V-CIP application shall be carried out by agencies accredited by the RBI."
This requirement has several important dimensions. First, the VA/PT must be conducted by agencies specifically accredited by the RBI for this purpose -- not any third-party security firm. The RBI maintains a list of empaneled IS auditors and CERT-In accredited agencies that are qualified to conduct these assessments. Using a non-accredited agency, regardless of its technical reputation, does not satisfy the regulatory requirement.
Second, the scope of the VA/PT must cover the entire V-CIP application stack: the customer-facing mobile and web applications, the agent dashboard, the video conferencing engine, the biometric processing modules, the API layer, the database tier, the network infrastructure, and all integration points with external systems (UIDAI, NSDL, DigiLocker). A narrowly scoped assessment that covers only the web frontend would not satisfy the requirement.
Third, the security audit must be conducted both before initial deployment and on a periodic basis (typically annually, or after significant application changes). The audit report, including identified vulnerabilities, risk ratings, and remediation status, must be maintained as part of the institution's compliance documentation and made available to RBI inspectors upon request. All critical and high-severity vulnerabilities identified in the audit must be remediated before the V-CIP application goes live -- or returns to live operation after an upgrade.
11. Functional, Performance, and Maintenance Testing
Beyond security testing, the RBI mandates comprehensive application testing before any V-CIP system is deployed in production:
"The application software for V-CIP shall be tested for functional, performance, and maintenance aspects before live rollout."
Functional testing must verify that every feature of the V-CIP application works as specified: video call initiation and termination, document capture and OCR, Aadhaar and PAN verification, liveness detection, face matching, consent recording, geo-tagging, session recording, agent workflow, approval/rejection/escalation paths, and audit trail generation. Edge cases must be covered -- session interruption handling, network failover, concurrent session limits, and error recovery scenarios.
Performance testing must validate that the application can handle the expected session volume with acceptable latency, video quality, and processing throughput. Load testing should simulate peak session volumes, stress testing should identify breaking points, and endurance testing should verify stability under sustained load over extended periods. Key metrics include session setup time, video latency, face-matching processing time, API response times, and concurrent session capacity.
Maintenance testing covers the application's supportability -- the ability to diagnose issues, apply patches, perform upgrades, and roll back changes without disrupting live operations. This includes testing backup and recovery procedures, database migration paths, configuration management, and monitoring/alerting systems. The test results, test cases, and defect resolution records must be documented and retained for regulatory review.
12. Identification via Approved Methods
The V-CIP platform must support the specific identification methods prescribed by the circular. Customer identity during V-CIP can be established through:
OTP-based Aadhaar e-KYC: Real-time Aadhaar authentication via UIDAI's e-KYC service, where the customer receives an OTP on their Aadhaar-linked mobile number. The platform must integrate with UIDAI's API infrastructure and handle the complete authentication flow within the video session.
Offline Aadhaar Verification: Using Aadhaar XML or QR code downloaded by the customer from the UIDAI website. The circular imposes a freshness requirement -- the XML or QR code must not be more than 3 days old at the time of use. The platform must validate the XML digital signature, extract demographic and photograph data, and verify the document's age against the generation timestamp.
CKYCR Records: Verification against the Central KYC Records Registry maintained by CERSAI. The platform must integrate with the CKYCR API to search for and retrieve existing KYC records using the customer's KYC identifier.
OVDs via DigiLocker: Officially Valid Documents accessed through the DigiLocker platform, which provides digitally signed copies of government-issued documents. The platform must integrate with the DigiLocker API to pull and verify documents with the customer's consent.
Additionally, the circular requires PAN capture and verification against the Income Tax database during the V-CIP session. The platform must capture the PAN number (either from the physical card shown on camera via OCR or from electronic verification) and validate it in real-time.
A critical compliance requirement is Aadhaar number redaction. The V-CIP platform must ensure that the full Aadhaar number is masked or redacted in all stored records, displaying only the last four digits. This applies to video recordings, captured document images, database entries, and any logs that may contain the Aadhaar number. Failure to redact Aadhaar numbers is a violation of both the RBI KYC direction and the Aadhaar Act.
How to Choose a V-CIP Technology Partner
Given the breadth and depth of these requirements, selecting a V-CIP technology partner is one of the most consequential decisions a regulated entity will make in its digital KYC journey. Here is a framework for evaluation, derived directly from the regulatory requirements:
Deployment flexibility: Can the vendor deploy within your controlled infrastructure (on-premise, private cloud, or dedicated VPC)? Multi-tenant SaaS-only vendors may not satisfy the "own premises, secured network domain" requirement.
Encryption architecture: Does the platform implement true end-to-end encryption for video, audio, and data channels? Request architectural documentation and independent validation.
Biometric capabilities: What liveness detection methodology is used (active, passive, or hybrid)? What are the FAR/FRR benchmarks for face matching? Does the vendor hold ISO 30107-3 certification or NIST FRVT benchmarks?
Security audit readiness: Has the platform undergone VA/PT by an RBI-accredited agency? Can the vendor share audit reports and remediation evidence?
Fraud intelligence: Does the vendor have a process for continuous upgrades based on detected forgery attempts? What is the historical frequency of security updates?
Integration completeness: Does the platform natively support all RBI-prescribed identification methods -- Aadhaar e-KYC, Offline Aadhaar, CKYCR, DigiLocker, and PAN verification? Partial integrations create compliance gaps and operational friction.
How BASEKYC's Infrastructure Meets Every RBI Requirement
BASEKYC was engineered from the ground up to satisfy every infrastructure requirement in the V-CIP circular -- not as an afterthought or through retrofit, but as foundational design principles.
Deployment within RE's controlled infrastructure: BASEKYC supports on-premise deployment, dedicated private cloud deployment, and VPC-based deployment within the RE's cloud account. The entire application stack -- video engine, biometric modules, document processing, session management, and storage -- runs within the RE's network domain. No session data ever traverses third-party infrastructure.
End-to-end encryption: All video and audio streams use SRTP with DTLS key exchange. All signaling uses TLS 1.3. All data at rest is encrypted with AES-256, with keys managed through HSM-backed key management services. The encryption chain is continuous from customer device to archival storage, with no plaintext exposure at any intermediate point.
Liveness and face matching: BASEKYC employs a hybrid liveness detection system combining active challenges with passive AI-based continuous analysis. Our face-matching engine achieves FAR below 0.001% and FRR below 0.5% across diverse demographics, validated through independent third-party benchmarking. The system is regularly updated with adversarial training data to counter emerging deepfake and spoofing techniques.
IP geolocation and GPS: BASEKYC implements dual-layer location verification with IP geolocation filtering (blocking non-Indian IPs, VPN exit nodes, and known proxy servers) and GPS coordinate capture with NTP-synchronized timestamps. All location data is stored as part of the immutable session record.
Security audit posture: BASEKYC undergoes annual VA/PT and security audits by CERT-In empaneled and RBI-accredited agencies. Audit reports, remediation evidence, and continuous monitoring dashboards are available to RE compliance teams. Our security update cadence exceeds the quarterly minimum, with emergency patching capability for zero-day vulnerabilities.
Complete identification integration: BASEKYC natively integrates with UIDAI (OTP e-KYC and Offline Aadhaar), CERSAI (CKYCR), DigiLocker, and NSDL (PAN verification). Aadhaar redaction is automatic and enforced at the platform level -- the full Aadhaar number is never stored in any database, log, or recording. Offline Aadhaar XML/QR freshness is validated against the 3-day maximum age requirement before acceptance.
Conclusion: Infrastructure Is Not Optional
The RBI's V-CIP infrastructure requirements under RBI/2021-22/35 are not a checklist to be minimally satisfied. They represent a comprehensive security and operational framework designed to ensure that video-based customer identification is at least as secure and reliable as in-person verification -- and in many respects, more so. Every requirement -- from technology housing in the RE's own premises to regular upgrades based on forgery detection -- exists because the regulator has identified a specific risk that must be mitigated.
Institutions that treat these requirements as mere compliance boxes to check will find themselves perpetually reacting to audit findings and regulatory observations. Those that internalize the requirements as design principles -- building or selecting V-CIP infrastructure that embodies the spirit, not just the letter, of the circular -- will build systems that are not only compliant but genuinely secure, scalable, and resilient.
The investment in compliant infrastructure pays for itself many times over: in avoided regulatory penalties, in customer trust, in operational efficiency, and in the ability to scale V-CIP operations confidently as video KYC becomes the dominant onboarding channel across Indian financial services.