A V-CIP session that is technically flawless but poorly documented is, from a regulatory standpoint, as good as one that never happened. The Reserve Bank of India's Master Direction on KYC (RBI/2021-22/35, dated May 10, 2021) devotes substantial attention to what happens after the video call ends -- how session data is stored, where it resides, who can access it, how long it must be retained, and how its integrity is guaranteed over time. These audit trail and data management requirements are not secondary to the technical requirements; they are co-equal. A V-CIP system that delivers perfect liveness detection but stores its records on servers outside India, or fails to maintain an alteration-proof activity log, is non-compliant. This article provides a thorough, provision-by-provision analysis of every data management requirement the RBI imposes on V-CIP operations, and how regulated entities can build storage architectures that satisfy them.
1. Data Localization: All V-CIP Data Must Stay in India
The RBI's data localization mandate for V-CIP is unambiguous:
"All the data pertaining to V-CIP shall be stored in systems located in India."
"All the data" is comprehensive. It encompasses video recordings, audio recordings, captured photographs, document images, OCR-extracted text, biometric templates (face embeddings, liveness scores), Aadhaar verification responses, PAN verification results, GPS coordinates, IP addresses, timestamps, consent records, agent decisions, activity logs, session metadata, and any derived analytics. Every byte of data generated during, or as a result of, a V-CIP session must reside on computing infrastructure physically located within the territory of India.
This requirement applies not just to primary storage but to all copies -- backups, disaster recovery replicas, analytics exports, and archival copies. If an institution uses a cloud provider, the cloud region must be in India (such as AWS Mumbai, Azure Central India, or GCP Mumbai). If the institution uses a hybrid architecture with edge nodes, CDN caching, or processing nodes, none of these can be located outside India for V-CIP data.
The data localization requirement also has implications for technology vendor selection. If a V-CIP vendor processes biometric data (face matching, liveness detection) through APIs hosted outside India -- even transiently -- this constitutes a violation. Institutions must verify that the entire data processing pipeline, including third-party API calls made by the V-CIP platform, operates within Indian jurisdiction.
This requirement aligns with the broader RBI circular on Storage of Payment System Data (RBI/2017-18/153), which mandated that all payment data be stored exclusively in India. The V-CIP data localization requirement extends this principle to customer identification data, reflecting the regulator's consistent position that sensitive financial and personal data must remain within the country's legal and regulatory jurisdiction.
2. Video Recording Storage: Safe, Stamped, and Searchable
The RBI prescribes specific requirements for how V-CIP video recordings must be stored:
"The video recording shall be stored safely with date-time stamp for historical search and retrieval."
This requirement has three distinct components, each with significant technical implications.
Safe storage: "Safely" means the recording must be protected against unauthorized access, modification, deletion, and corruption. This requires encryption at rest (AES-256 minimum), strict access control (role-based access with multi-factor authentication for retrieval), integrity verification (cryptographic checksums that detect any tampering), and redundancy (replication across at least two geographically separated data centers within India to protect against hardware failure, natural disasters, and site-level outages). The storage medium must be reliable for the entire retention period -- which, as discussed below, can extend to 8 years or more.
Date-time stamp: Every video recording must be tagged with the precise date and time of the V-CIP session. This timestamp must be derived from a reliable, centralized time source (NTP-synchronized) rather than the customer's device clock or the agent's workstation clock, both of which can be manipulated. The timestamp format must be unambiguous -- ISO 8601 with UTC offset is the industry standard. The date-time stamp must be embedded in both the recording metadata and the storage index, ensuring it cannot be separated from the recording itself.
Historical search and retrieval: The storage system must support efficient searching and retrieval of recordings based on various criteria: date range, customer identifier, session ID, agent ID, verification outcome, and potentially other metadata fields. This is not a trivial requirement at scale. An institution processing 10,000 V-CIP sessions per day will accumulate over 3.6 million recordings per year. The storage architecture must support fast indexed searches across this volume without requiring sequential scanning. This typically necessitates a dedicated video management system with a robust metadata database, rather than simply storing recordings in a flat file system.
3. Activity Log Preservation with Official Credentials
The RBI requires comprehensive logging of all V-CIP activities, with a specific requirement around official identity:
"Activity log along with the credentials of the official conducting the V-CIP shall be preserved."
The activity log must capture every significant event during the V-CIP session, from initiation to completion. This includes: session start time, customer connection event, consent capture event, document presentation events, Aadhaar/PAN verification request and response events, liveness detection execution and result, face-matching execution and result, photograph capture event, agent questions and customer responses (correlated with video timestamps), agent decision (approve/reject/escalate) with rationale, and session end time. Each event must be timestamped to the second.
The "credentials of the official" component means that the activity log must unambiguously identify the RE official who conducted the session. This requires more than a username -- it requires verifiable credentials such as an employee ID, the official's V-CIP authorization reference, their login session details, and ideally a digital signature or authentication token that ties each log entry to the specific individual. If an institution uses multiple agents or shifts, the log must clearly record handoff events if a session is transferred between officials.
The preservation requirement means these logs must be retained for the same duration as the video recordings and must be equally protected against tampering. Activity logs stored in mutable databases where administrators can insert, modify, or delete entries do not satisfy the preservation standard. Institutions should implement append-only log storage, cryptographic chaining (where each log entry's hash incorporates the previous entry's hash, creating a tamper-evident chain), or write-once-read-many (WORM) storage to ensure log integrity.
4. Alteration-Proof Consent Recording
As discussed in the context of infrastructure requirements, consent recording carries a specific integrity standard:
"Customer's consent shall be taken in an auditable and alteration-proof manner."
From a data management perspective, this means the consent record must be stored as an immutable artifact. The consent record should include: the exact text of the consent presented to the customer, the timestamp of consent capture, the method of consent (click, verbal, both), the session identifier linking the consent to the specific V-CIP session, and a cryptographic hash of the consent record computed at the time of creation.
For verbal consent captured during the video call, the consent moment must be identifiable within the video recording -- typically through a timestamp marker that allows an auditor to navigate directly to the point in the recording where consent was given. The video recording itself, being stored in an alteration-proof manner, serves as the primary evidence of verbal consent.
For digital consent (checkbox, button click, e-signature), the system must generate a consent receipt that is cryptographically signed and stored independently of the application database. This ensures that even if the application database is compromised, the consent record remains verifiable. Some institutions implement blockchain-anchored consent receipts, where the consent hash is written to a distributed ledger, providing third-party verifiable proof of consent existence and integrity.
5. Concurrent Audit Before Accounts Become Operational
One of the most distinctive requirements in the V-CIP circular is the concurrent audit mandate:
"Concurrent audit shall be carried out before accounts opened through V-CIP are made operational."
This is a critical control that distinguishes V-CIP from other digital onboarding methods. Even after a V-CIP session is completed and the agent has approved the verification, the account cannot be activated until a concurrent audit has reviewed the session. The concurrent auditor -- who must be independent of the V-CIP operations team -- reviews the video recording, the activity log, the document verification results, the liveness detection scores, the face-matching results, the consent record, and the agent's decision rationale to confirm that the session was conducted in compliance with all applicable standards.
From a data management perspective, this requirement means the V-CIP system must make all session data available to the concurrent auditor in a structured, reviewable format immediately after session completion. The system must support an audit workflow -- a queue of sessions pending audit, a review interface that surfaces all relevant data, and an audit decision mechanism (approve, reject, or flag for further review) that is itself logged and preserved.
The concurrent audit also creates a data integrity checkpoint. If any data artifact is missing, corrupted, or inconsistent at the audit stage, the account cannot be activated. This means the V-CIP system must ensure data completeness and integrity between session completion and audit review -- a window that is typically measured in hours but can extend to days depending on the institution's audit capacity. Storage systems must guarantee that no data is lost or altered during this interim period.
6. Aadhaar Number Redaction and Blackout
The V-CIP data management framework incorporates the Aadhaar redaction requirement mandated by the Aadhaar Act and reinforced by the KYC Master Direction. Regulated entities must ensure that the complete Aadhaar number is never stored in their systems:
"The Aadhaar number shall be redacted or blacked out through appropriate means to ensure that the complete Aadhaar number is not visible."
In the V-CIP context, Aadhaar redaction must be applied across multiple data types. In video recordings, if the customer displays their Aadhaar card during the session, the full number must be masked in the stored recording -- either through real-time video processing that blurs or obscures the number during recording, or through post-processing before the recording is finalized. In captured images, any photograph or screenshot of the Aadhaar card must have the first 8 digits masked, showing only the last 4. In database records, the full 12-digit Aadhaar number must not be stored; only a masked version (XXXX-XXXX-1234) or a reference token should be retained. In logs and metadata, any system log that might capture the Aadhaar number (API request logs, OCR output logs, verification response logs) must be sanitized.
The technical challenge of real-time Aadhaar redaction in video is non-trivial. It requires OCR-capable video processing that can detect Aadhaar numbers in the video frame and apply masking in real-time or near-real-time before the frame is written to the recording buffer. Alternatively, institutions can implement post-processing redaction where the raw recording is processed by an automated redaction pipeline before being committed to permanent storage. The raw, unredacted recording must never be persisted to permanent storage -- it should exist only in temporary, encrypted memory during the redaction process.
7. PAN Verification and Storage
The V-CIP circular requires PAN capture and database verification as part of the identification process:
"PAN shall be captured and verified with the database of the issuing authority during V-CIP."
Unlike Aadhaar, PAN does not carry the same redaction mandate, but it does carry data protection obligations. The PAN must be captured during the V-CIP session -- either through OCR from the physical PAN card displayed on camera, or through manual entry verified against the card. The captured PAN must be verified in real-time against the Income Tax Department's database (via NSDL/UTIITSL verification API) to confirm that the PAN exists, is active, and the name on the PAN matches the customer's declared name.
From a data management perspective, the PAN verification request, the verification response (match/mismatch, details returned), and the timestamp of verification must all be stored as part of the session record. The PAN itself, as a sensitive personal identifier, must be stored with appropriate encryption and access controls. Under the Digital Personal Data Protection Act (DPDPA), 2023, PAN qualifies as personal data, and its storage, processing, and sharing are subject to the purpose limitation, data minimization, and retention limitation principles of the Act.
8. Offline Aadhaar Freshness Validation
When V-CIP identification uses Offline Aadhaar (XML or QR code), the circular imposes a freshness constraint:
"The Aadhaar XML or QR code shall not be more than 3 days old at the time of V-CIP."
This requirement exists to prevent the use of stale Aadhaar data that may no longer reflect the customer's current demographic details or photograph. From a data management standpoint, the V-CIP system must extract the generation timestamp from the Aadhaar XML or QR code, compute the age of the document relative to the current session time, and reject any document older than 72 hours. This validation must be automated -- it cannot rely on the agent manually checking the document date.
The system must also verify the digital signature on the Aadhaar XML to confirm it was genuinely issued by UIDAI and has not been tampered with. The validation result -- including the document age, signature verification status, and extracted data -- must be stored as part of the session record. If a customer presents an Aadhaar XML older than 3 days, the system must reject it and prompt the customer to download a fresh copy from the UIDAI website, with the rejection and reason logged in the activity record.
9. Retention Periods and Lifecycle Management
While the V-CIP circular does not specify an explicit retention period within its own text, the retention requirements are derived from the broader KYC Master Direction and PMLA rules. Under the Prevention of Money Laundering (Maintenance of Records) Rules, 2005, KYC records must be maintained for a minimum of five years after the business relationship has ended or the account has been closed. The RBI has further recommended, through various circulars, that institutions retain KYC records for up to eight years.
For V-CIP data, this means video recordings, activity logs, consent records, document images, and verification results must be retained for a minimum of 5 years -- potentially 8 years -- after the customer relationship terminates. Given that some customer relationships span decades, the effective retention period for V-CIP session data can be 15-25 years or more from the date of the session.
This long retention period has significant implications for storage architecture. Video recordings consume substantial storage -- a single 5-minute V-CIP session at 720p produces approximately 50-100 MB of compressed video. An institution processing 5,000 sessions per day generates 250-500 GB of video data daily, accumulating to approximately 90-180 TB per year. Over a 10-year retention window, this translates to nearly 1-2 PB of video storage -- before accounting for backups and redundancy.
Institutions must implement tiered storage strategies: hot storage (fast SSD-based) for recently completed sessions under active audit, warm storage (HDD-based) for sessions within the past 1-2 years that may be needed for operational queries, and cold storage (object storage like S3 Glacier or tape-equivalent) for older sessions retained purely for regulatory compliance. All tiers must maintain encryption, integrity verification, and access controls. The transition between tiers must be automated and logged, and retrieval from cold storage must be achievable within regulatory-acceptable timeframes (typically 24-48 hours).
10. DPDPA Intersection: Privacy by Design in V-CIP Data Management
The Digital Personal Data Protection Act, 2023 (DPDPA) adds a new layer of obligations on top of the RBI's V-CIP data management requirements. V-CIP data is rich in personal data -- biometric data (face images, liveness scores), identity numbers (Aadhaar, PAN), addresses, photographs, voice recordings, and location data. Under the DPDPA, this data is subject to:
Purpose limitation: V-CIP data collected for customer identification may only be used for that purpose and closely related legitimate purposes (such as regulatory compliance and fraud prevention). Using V-CIP video recordings for marketing analytics, employee training (without anonymization), or any purpose beyond KYC compliance would violate the purpose limitation principle.
Data minimization: The institution should collect and retain only the data necessary for V-CIP compliance. While the RBI requires comprehensive recording and logging, the DPDPA requires that additional data beyond what is mandated should not be collected. Metadata fields that are not required for compliance or operational purposes should not be captured or stored.
Storage limitation: Once the retention period expires, V-CIP data must be securely deleted. The DPDPA requires that personal data not be retained beyond the period necessary for the purpose for which it was collected. Institutions must implement automated deletion workflows that identify sessions past their retention deadline and securely erase all associated data -- including backups and archived copies -- with deletion certification.
Data principal rights: Customers have the right to access their V-CIP data, request correction of inaccuracies, and request erasure (subject to regulatory retention requirements). The V-CIP data management system must support these rights -- providing mechanisms for data retrieval in response to customer requests, correction workflows for demographic data, and conditional erasure that respects the regulatory retention floor.
11. Storage Architecture Comparison: On-Premise vs. Cloud in India
Regulated entities face a fundamental architectural decision for V-CIP data storage: on-premise infrastructure, cloud infrastructure within India, or a hybrid approach. Each has distinct implications for compliance, cost, scalability, and operational complexity.
On-Premise Storage
On-premise storage provides maximum control over data sovereignty. The institution owns and operates the hardware, controls physical access, manages encryption keys internally, and has complete visibility into where data resides. This approach is favored by large banks and financial institutions with existing data center infrastructure, dedicated IT operations teams, and stringent internal policies around data control. However, on-premise storage carries significant capital expenditure (hardware procurement, data center space, power, cooling), operational overhead (hardware maintenance, capacity planning, disaster recovery), and scalability constraints (scaling requires hardware procurement cycles that can take weeks or months).
Cloud Storage in India
Cloud storage within Indian regions (AWS ap-south-1, Azure Central India, GCP asia-south1) satisfies the RBI's data localization requirement while offering elastic scalability, built-in redundancy, automated tiering, and pay-as-you-go economics. Cloud providers offer India-specific compliance certifications and data residency guarantees. For institutions without large data center operations, cloud storage can dramatically reduce the time-to-deploy and ongoing operational burden of V-CIP data management. However, cloud storage requires careful configuration -- default replication policies must be constrained to Indian regions, encryption must be customer-managed (not provider-managed) for maximum control, and access policies must prevent data from being copied or exported outside India.
Hybrid Approach
Many institutions adopt a hybrid model: hot storage on-premise (or in a dedicated cloud VPC) for active sessions and recent data, with cold archival storage in India-region cloud object storage for long-term retention. This balances the performance and control benefits of on-premise infrastructure with the cost efficiency and scalability of cloud storage for the bulk of archival data. The hybrid approach requires careful data lifecycle management to ensure seamless, encrypted, and logged transitions between storage tiers, but it often represents the most practical balance of compliance, cost, and operational feasibility.
How BASEKYC Handles Audit Trail and Data Management
BASEKYC's data management architecture was designed from inception around the specific requirements of the V-CIP circular and the broader Indian regulatory framework. Every design decision -- from database schema to storage tier selection to log architecture -- traces back to a specific regulatory provision.
Data localization: BASEKYC operates exclusively within Indian data center infrastructure. All processing -- video encoding, biometric analysis, OCR, verification API calls, and session management -- occurs on servers physically located in India. For cloud deployments, we enforce India-only region constraints at the infrastructure-as-code level, making it technically impossible for V-CIP data to be replicated outside the country. For on-premise deployments, the entire stack runs within the RE's own data center.
Video storage: BASEKYC's video management system stores every recording with AES-256 encryption at rest, NTP-synchronized timestamps embedded in both the recording metadata and the storage index, cryptographic integrity hashes (SHA-256) computed at recording completion, and a full-text searchable metadata index supporting queries by date range, customer ID, session ID, agent ID, verification outcome, and custom fields. Automated tiered storage transitions recordings from hot to warm to cold storage based on configurable age policies, with full encryption and integrity preservation maintained across all tiers.
Activity logs: BASEKYC implements cryptographically chained activity logs where each entry's hash incorporates the previous entry's hash. This creates a tamper-evident chain -- any insertion, modification, or deletion of a log entry breaks the hash chain and is immediately detectable. Agent credentials are captured through authenticated session tokens tied to the RE's identity management system, ensuring every log entry is attributable to a specific authorized official.
Consent management: Consent records are generated as cryptographically signed artifacts at the moment of capture, stored in an append-only consent registry independent of the main application database. Each consent record includes the full consent text, capture method, timestamp, session reference, and a verifiable digital signature. The consent registry supports independent audit verification without access to the main application systems.
Aadhaar redaction: BASEKYC implements automated Aadhaar redaction at two levels. During the live session, our OCR engine detects Aadhaar numbers in the video frame and applies real-time masking before the frame is written to the recording buffer. In document capture, the full Aadhaar number is masked to show only the last 4 digits before the image is committed to storage. At the database level, full Aadhaar numbers are never persisted -- only masked representations and UIDAI-issued reference tokens are stored.
Concurrent audit workflow: BASEKYC includes a built-in concurrent audit module. Completed V-CIP sessions are automatically queued for audit review, with all session artifacts -- video, logs, documents, verification results, consent records -- presented in a unified audit interface. The audit decision is logged with the auditor's credentials and rationale, and account activation is blocked until the audit is marked as complete. Institutions can configure audit rules, sampling rates (for high-volume operations), and escalation paths.
Retention and deletion: BASEKYC's data lifecycle engine enforces configurable retention policies. When a retention deadline is reached, the system automatically identifies all data associated with the session, verifies that no regulatory hold prevents deletion, executes cryptographic erasure (destroying the encryption keys that protect the data, rendering it permanently unreadable), and generates a deletion certificate with timestamp and scope. This process runs across all storage tiers -- hot, warm, and cold -- ensuring no orphaned data remains in any tier after the retention period expires.
Conclusion: Audit Trails Are the Foundation of V-CIP Trust
The V-CIP process derives its regulatory legitimacy from the quality and integrity of its audit trail. A video call without a searchable, tamper-proof recording is not a V-CIP session. A verification decision without a cryptographically preserved activity log is not an auditable decision. An Aadhaar verification stored without proper redaction is not a compliant record. The RBI's data management requirements under RBI/2021-22/35 exist precisely because the entire V-CIP framework depends on the ability to reconstruct, verify, and audit every session at any point in the future.
Institutions that invest in robust, purpose-built data management infrastructure for V-CIP -- rather than retrofitting existing general-purpose storage systems -- will find that compliance becomes a natural outcome of good architecture rather than a burden imposed on top of it. Data localization, tamper-proof logging, automated redaction, concurrent audit workflows, and lifecycle management are not features to be added later; they are foundational capabilities that must be present from the first session.
As video KYC volumes continue to grow across Indian financial services, the institutions that have built their V-CIP data management on solid regulatory foundations will scale confidently, while those that have cut corners will face escalating compliance risk with every additional session they process.