Introduction: The RBI KYC / V-CIP Technology Audit
Video-based Customer Identification Process (V-CIP) has transformed customer onboarding across India's regulated financial ecosystem. What was once a paper-heavy, in-person exercise governed by the Prevention of Money Laundering Act (PMLA) and the Reserve Bank of India (RBI) Master Direction on Know Your Customer (KYC) is now a fully digital, real-time, audio-visual interaction. That convenience carries a corresponding regulatory burden: the RBI expects every Regulated Entity (RE) that adopts V-CIP to demonstrate, through independent technology audit, that its onboarding stack cannot be spoofed, replayed, coached, or fraudulently manipulated.
The RBI KYC / V-CIP Technology Audit is the structured, evidence-driven examination of an RE's digital onboarding platform against the RBI Master Direction on KYC (RBI/DBR/2015-16/18, Master Direction DBR.AML.BC.No.81/14.01.001/2015-16, as amended), the January 2020 and subsequent amendments that introduced and refined V-CIP, and allied UIDAI, NPCI, CERT-In, and MeitY requirements. This guide is written for two audiences simultaneously: the auditor who must design the assessment, gather evidence, and opine on control adequacy; and the implementer (product, engineering, compliance, and operations) who must build, harden, and remediate the platform so it passes.
CyberSigma conducts these audits as a CERT-In empanelled security auditing organisation, combining application security testing, cryptographic review, artificial-intelligence/liveness assessment, and PMLA control mapping. This deep-dive sets out the full methodology, the master control checklist, evidence expectations, scoring model, and remediation approach so that banks, NBFCs, payment aggregators, and fintechs can achieve and sustain V-CIP compliance.
Regulatory-source note
This guide is original CyberSigma work product. It paraphrases and interprets publicly issued RBI Master Directions, amendments, and allied UIDAI/NPCI/CERT-In circulars. It does not reproduce copyrighted or proprietary text from the Reserve Bank of India or any other issuer. Regulated entities must always refer to the current, authoritative circulars on the RBI, UIDAI, NPCI, and CERT-In websites, as directions are amended frequently. Requirement identifiers cited (for example paragraph and clause numbers) reflect the Master Direction structure at the time of writing and should be reconfirmed against the live consolidated version.
What is RBI KYC / V-CIP
V-CIP is an alternate method of establishing a customer's identity, defined by the RBI as a consent-based, live, audio-visual interaction between an authorised official of the Regulated Entity and the customer, undertaken to obtain identification information (including any documents required for Customer Due Diligence) and to establish that the customer is genuinely present, alive, and in real time. It is treated as a face-to-face CIP, and the RE bears full responsibility for its integrity.
The RBI KYC / V-CIP Technology Audit is not a generic penetration test. It is a targeted assurance engagement covering the specific controls the RBI mandates for V-CIP: geotagging, liveness detection, randomised sequencing to defeat pre-recording, secure and encrypted storage, network-quality safeguards, official-side workflow controls, Aadhaar/OVD verification, and the audit trail. It also assesses the surrounding CDD lifecycle: risk categorisation, name-screening against sanctions and PEP lists, ongoing due diligence, and periodic updation.
The audit produces an independent opinion on whether the platform, its processes, and its supporting IT general controls meet the regulatory standard, together with a prioritised remediation roadmap. For many REs this audit is a licensing or supervisory prerequisite: RBI inspections routinely ask for the most recent V-CIP technology audit report.
Why V-CIP is audited separately from general IT audit
- Fraud surface is unique: deepfakes, injection attacks on the camera pipeline, presentation attacks (photo/video/mask spoofing), and coaching of applicants are threats specific to remote identity proofing.
- Regulatory specificity: the RBI prescribes concrete technical behaviours (random action liveness, geotagging within India, real-time face match with Aadhaar photo) that must be individually verified.
- Data-protection sensitivity: V-CIP handles Aadhaar numbers, biometrics-adjacent facial data, and OVDs, invoking the Aadhaar Act, UIDAI regulations, and the Digital Personal Data Protection (DPDP) Act, 2023.
- Concurrent audit expectation: the RBI expects V-CIP to be subject to concurrent/periodic audit given its high-risk, high-volume nature.
Who must comply
Any entity classified as a Regulated Entity under the RBI KYC Master Direction that chooses to onboard customers or undertake CDD through video-based identification must implement V-CIP controls and subject them to technology audit. The obligation extends across the banking and payments value chain.
| Entity category | Applicability of V-CIP audit | Primary regulator/reference |
|---|---|---|
| Scheduled commercial banks, small finance banks, payments banks | Mandatory where V-CIP onboarding is offered; concurrent audit expected | RBI KYC Master Direction |
| Regional Rural Banks and Cooperative Banks | Applicable where digital onboarding is adopted | RBI / NABARD |
| Non-Banking Financial Companies (NBFCs), including NBFC-MFIs | Applicable; widely used for digital lending onboarding | RBI KYC MD + Digital Lending Guidelines |
| Payment Aggregators and Payment Gateways (PA/PG) | Applicable to merchant/customer onboarding KYC | RBI PA/PG Guidelines + KYC MD |
| Prepaid Payment Instrument (PPI) issuers / wallets | Applicable for full-KYC PPI onboarding | RBI Master Direction on PPIs + KYC MD |
| Housing Finance Companies (HFCs) | Applicable; regulated by RBI post-2019 transfer from NHB | RBI KYC MD |
| Fintechs / LSPs onboarding on behalf of an RE | RE remains accountable; outsourced V-CIP must be audited | RBI outsourcing + Digital Lending norms |
| Asset Reconstruction Companies, factors, other REs | Applicable where video onboarding is used | RBI KYC MD |
Accountability cannot be outsourced
Where V-CIP is performed by a Lending Service Provider, KYC service provider, or third-party technology vendor, the Regulated Entity remains fully responsible for compliance, data protection, and audit. The RE must ensure vendor platforms are covered by its own V-CIP technology audit scope and that contracts embed audit rights.
Structure of RBI KYC / V-CIP
The audit universe can be decomposed into control domains that together assure the integrity of remote identity proofing and the surrounding CDD lifecycle. The following structure is CyberSigma's assessment taxonomy, aligned to the Master Direction clauses that govern V-CIP and CDD.
| Domain ID | Control domain | Scope summary | Primary regulatory anchor |
|---|---|---|---|
| D1 | Consent and customer authorisation | Explicit informed consent capture, disclosures, and record | KYC MD V-CIP clause; DPDP Act |
| D2 | Liveness and anti-spoofing | Random-action liveness, presentation-attack detection, deepfake defence | V-CIP integrity requirements |
| D3 | Geotagging and location integrity | Capture of customer geo-coordinates; India-territory verification | V-CIP geotagging requirement |
| D4 | Identity verification and face match | Aadhaar/OVD data, live face match with reference photo, OTP/e-KYC | KYC MD CDD + Aadhaar Act |
| D5 | Official-side workflow and competence | Trained authorised official, real-time interaction, question workflow | V-CIP official responsibilities |
| D6 | Recording, storage and retention | Encrypted, tamper-evident storage; retention periods; data residency | KYC MD record management; DPDP |
| D7 | Network, session and quality controls | Bandwidth checks, session integrity, TLS, injection resistance | V-CIP technical robustness |
| D8 | Screening and risk categorisation | Sanctions/PEP/adverse-media screening; risk rating; STR triggers | PMLA + KYC MD risk-based approach |
| D9 | Audit trail and tamper evidence | Immutable logs, timestamps, sequence proof, non-repudiation | KYC MD audit + IT controls |
| D10 | IT general controls and security | Access control, change management, secrets, secure SDLC | CERT-In / RBI IT framework |
| D11 | Data protection and privacy | Aadhaar masking, data minimisation, DPDP obligations, breach handling | Aadhaar Act, UIDAI regs, DPDP Act |
| D12 | Governance, outsourcing and audit | Board oversight, vendor governance, periodic/concurrent audit | RBI outsourcing + governance norms |
Master assessment checklist
This is the core of the engagement. Each domain below is enumerated with the specific control expectations, what the auditor must verify, and the typical evidence that satisfies the test. No control area is omitted. Where a clause identifier is commonly referenced, it is noted; auditors must reconfirm against the live consolidated Master Direction.
D1 — Consent and customer authorisation
| What to verify | Typical evidence |
|---|---|
| Explicit, informed, consent is captured before the V-CIP session begins and is recorded within the audio-visual stream | Consent screen wireframes, session recordings showing verbal/on-screen consent, consent timestamps in logs |
| Consent covers processing of personal data, Aadhaar (if used), facial image, geolocation and recording | Consent text, DPDP notice, privacy policy version control |
| Customer can decline and an alternate KYC route is offered | Process flow, drop-off handling documentation |
| Consent artefacts are linked immutably to the customer record and session ID | Data model, database records, log correlation |
| Withdrawal-of-consent and grievance mechanism exists and is functional | Grievance policy, DPDP consent-manager readiness, test tickets |
D2 — Liveness and anti-spoofing
| What to verify | Typical evidence |
|---|---|
| Random-action or randomly generated instructions are issued during the session to prevent use of pre-recorded video | Randomisation logic code/design, session recordings showing varied prompts, entropy analysis |
| Passive and/or active liveness detection is implemented with a documented false-accept/false-reject rate | Liveness engine specs, vendor model documentation, test results, ISO/IEC 30107 PAD test reports where available |
| Presentation-attack detection defeats printed photo, screen replay, video and mask attacks | Red-team/spoof test results, PAD test evidence |
| Deepfake and camera-injection resistance is assessed (virtual-camera detection, device integrity) | Injection-attack test report, device attestation controls, virtual-camera detection logic |
| The official confirms the customer is live and present in real time, not a recording | SOP, recordings, official checklist within workflow |
| Liveness pass/fail decisions and scores are logged and auditable | Liveness decision logs, thresholds configuration |
D3 — Geotagging and location integrity
| What to verify | Typical evidence |
|---|---|
| Customer geo-coordinates (latitude/longitude) are captured during the session | Session metadata, database geotag fields, screenshots |
| System verifies the customer is physically located within India | Geo-fence rule, rejection logs for out-of-India attempts, test cases |
| GPS/location spoofing is detected or mitigated (IP-geo cross-check, mock-location detection) | Anti-spoof geolocation controls, mobile SDK settings, test evidence |
| Geotag is bound to the specific session and stored tamper-evidently | Log correlation, hash/immutability evidence |
| Location capture failure handling prevents onboarding without valid geotag | Business rules, negative test cases |
D4 — Identity verification and face match
| What to verify | Typical evidence |
|---|---|
| Identity is established via Aadhaar OTP e-KYC, offline Aadhaar XML/QR, DigiLocker, or permitted OVD as per CDD rules | Integration architecture, UIDAI AUA/KUA agreements, DigiLocker integration, OVD capture flow |
| Live face is matched against the photograph from Aadhaar e-KYC or the OVD, with a documented match threshold | Face-match engine config, match scores in logs, threshold policy |
| Aadhaar number is masked/redacted in storage and display per UIDAI requirements | Masking implementation, sample stored records, UI screenshots |
| PAN verification and cross-validation of extracted data (OCR) against captured data is performed | OCR results, PAN verification API logs, data-match rules |
| Original OVD is verified for genuineness (tamper, template, security features where applicable) | Document-verification engine output, forgery detection results |
| Where XML/offline Aadhaar is used, share-code/QR authenticity and freshness are validated | Validation logic, timestamp checks, test evidence |
| Identity data is captured from the customer during the session and matched, not merely re-keyed by the official | Workflow design, session recordings, extraction logs |
D5 — Official-side workflow and competence
| What to verify | Typical evidence |
|---|---|
| V-CIP is conducted by a trained, authorised official of the RE, not an outsourced agent acting unsupervised | Authorisation matrix, official roster, training records, RBAC config |
| Officials receive documented training on impersonation, coaching, and fraud red-flags | Training curriculum, attendance, assessment scores, refresher schedule |
| The workflow enforces a live, unscripted question sequence and prevents the official from bypassing steps | Workflow engine rules, mandatory-step configuration, bypass test cases |
| Concurrent audit / quality-check sampling of sessions by an independent reviewer is performed | QC sampling policy, review reports, exception logs |
| The official records observations (behaviour, coaching signs) and can reject the session | SOP, rejection reason codes, sample rejected sessions |
| Segregation of duties between onboarding official and approver/reviewer | RBAC roles, maker-checker evidence |
D6 — Recording, storage and retention
| What to verify | Typical evidence |
|---|---|
| Full audio-visual recording of each session is captured and stored | Recording pipeline design, sample recordings, storage inventory |
| Recordings and KYC artefacts are encrypted at rest (strong algorithm, managed keys) and in transit | Encryption config, KMS/HSM evidence, TLS scan results |
| Storage is tamper-evident (hashing, WORM, or equivalent integrity control) | Integrity mechanism design, hash registers, tamper test |
| Retention meets the KYC MD requirement (records retained for the mandated period, typically five years post relationship/transaction) | Retention policy, data-lifecycle config, deletion logs |
| Data residency: KYC/payment data stored within India as per RBI localisation norms | Cloud region config, data-flow diagram, hosting attestations |
| Access to recordings is restricted, logged, and reviewed | Access logs, privileged-access review, DLP controls |
D7 — Network, session and quality controls
| What to verify | Typical evidence |
|---|---|
| Session bandwidth/quality is checked pre-session to ensure a clear, uninterrupted interaction | Pre-check logic, quality thresholds, abort-on-poor-quality test |
| Video/audio quality is sufficient to reliably identify the customer and read documents | QA sampling, resolution/frame-rate config |
| Sessions run over authenticated, encrypted channels resistant to man-in-the-middle | TLS config, certificate pinning (mobile), pentest results |
| The pipeline resists frame/video injection, replay, and API tampering | Injection test report, API security tests, signature/nonce controls |
| Session state integrity prevents mid-session substitution of participant or feed | Session-binding controls, continuity checks, test cases |
| Rate limiting, bot and automation defences protect the onboarding APIs | WAF/rate-limit config, bot-defence evidence |
D8 — Screening and risk categorisation
| What to verify | Typical evidence |
|---|---|
| Customer name is screened against UN/domestic sanctions lists and PEP databases at onboarding | Screening tool config, list sources and update frequency, match logs |
| Adverse-media / negative-news screening is performed for higher-risk customers | Screening reports, escalation workflow |
| Risk categorisation (low/medium/high) is assigned per the risk-based approach and drives EDD | Risk-scoring model, category assignment records, EDD triggers |
| Suspicious activity and STR/CTR triggers are wired to the AML monitoring system | Alert rules, STR case samples, FIU-IND reporting linkage |
| Beneficial ownership is identified for non-individual customers where applicable | BO capture flow, ownership records |
| Screening false-positive handling and disposition are documented and audited | Disposition SOP, reviewer logs |
D9 — Audit trail and tamper evidence
| What to verify | Typical evidence |
|---|---|
| Every session generates an immutable, timestamped audit trail of all steps, decisions and actors | Log schema, sample end-to-end trail, immutability control |
| Randomisation, liveness, geotag and face-match events are individually logged with results | Event logs, decision records |
| Timestamps are synchronised to a reliable NTP source and cannot be back-dated | NTP config, time-integrity control |
| Logs are protected against modification and deletion, and centrally aggregated (SIEM) | SIEM integration, log-integrity/WORM evidence, access controls |
| Non-repudiation: actions are attributable to authenticated identities | IAM logs, session-actor binding |
| Audit trail supports reconstruction of any onboarding for supervisory review | Reconstruction test, sample regulator-ready pack |
D10 — IT general controls and security
| What to verify | Typical evidence |
|---|---|
| Role-based access control with least privilege across the V-CIP platform | IAM/RBAC matrix, access-review records |
| Multi-factor authentication for officials and administrators | MFA config, enrolment evidence |
| Secure SDLC: code review, SAST/DAST, dependency scanning for the onboarding app | Pipeline config, scan reports, remediation tracker |
| Change and release management with approvals and rollback | Change tickets, CAB records |
| Secrets, API keys and cryptographic keys are managed in a vault/HSM | Secrets-management evidence, key-rotation policy |
| Vulnerability management and periodic VAPT of the V-CIP stack | VAPT reports, patch SLAs, closure evidence |
| Business continuity and DR for the onboarding platform | BCP/DR plan, RTO/RPO, test results |
D11 — Data protection and privacy
| What to verify | Typical evidence |
|---|---|
| Aadhaar handling complies with the Aadhaar Act and UIDAI regulations (masking, no storage of full number where prohibited, virtual ID support) | Aadhaar data-handling policy, masking evidence, UIDAI compliance attestation |
| Data minimisation: only data necessary for CDD is captured and retained | Data inventory, field-level justification |
| DPDP Act obligations: notice, consent, purpose limitation, data-principal rights | DPDP readiness assessment, consent artefacts, rights-fulfilment process |
| Facial images and biometrics-adjacent data are protected as sensitive personal data | Encryption, access control, classification policy |
| Personal data breach detection, response and notification process exists | Incident-response plan, breach-notification workflow (CERT-In 6-hour reporting), drill records |
| Cross-border transfer controls and localisation compliance | Data-flow map, transfer assessment |
D12 — Governance, outsourcing and audit
| What to verify | Typical evidence |
|---|---|
| Board/senior-management approved KYC and V-CIP policy exists and is reviewed periodically | Approved policy, board minutes, review dates |
| Outsourced V-CIP/technology vendors are governed by contracts with audit rights, SLAs and data-protection clauses | Vendor contracts, due-diligence records, audit-right clauses |
| Vendor platforms are within the RE's audit scope and independently assessed | Vendor audit reports, right-to-audit evidence |
| Periodic and concurrent audit of V-CIP is performed and reported to management | Audit calendar, prior audit reports, action-tracker |
| Compliance function monitors regulatory changes and updates controls | Regulatory-change log, control-update evidence |
| Grievance redressal and customer complaint handling for onboarding failures | Grievance policy, complaint MIS |
Scoping
Correct scoping determines audit rigour and cost. The scope must encompass every component, actor, and data flow that touches the V-CIP process, whether operated in-house or by a vendor.
In scope
- The customer-facing web/mobile V-CIP application and its SDKs.
- The official-side agent console and workflow engine.
- Liveness, face-match, OCR, document-verification, and geotagging engines (in-house or vendor).
- Aadhaar/e-KYC, DigiLocker, PAN, and OVD integrations.
- Recording, storage, encryption, key management, and retention infrastructure.
- Audit logging, SIEM, and monitoring pipeline.
- Sanctions/PEP/adverse-media screening and risk-scoring systems feeding onboarding.
- IT general controls (IAM, change, secrets, VAPT, BCP/DR) supporting the above.
- Third-party/LSP platforms performing V-CIP on the RE's behalf.
Out of scope (typically)
- Downstream core banking / loan management systems beyond the onboarding hand-off point (assessed separately).
- General corporate IT unrelated to onboarding, unless it shares infrastructure with V-CIP.
- Product credit-decisioning logic (covered under lending audits), except where it consumes KYC risk data.
Scope Aadhaar carefully
If Aadhaar authentication is used, the AUA/KUA licensing, UIDAI compliance, and Aadhaar Data Vault requirements must be explicitly in scope. Understating Aadhaar scope is a frequent cause of audit findings and regulatory observations.
Implementation approach
CyberSigma delivers V-CIP readiness and remediation through a phased engagement. Implementers can use these phases as a build/harden roadmap; auditors can use them to check maturity of the client's programme.
Phase 1 — Discovery and gap assessment
- Activities: architecture walkthrough, data-flow mapping, control inventory, regulatory-clause mapping, vendor identification, threat modelling of the onboarding pipeline.
- Deliverables: scoped control matrix (D1-D12), data-flow diagram, preliminary gap register, threat model.
Phase 2 — Control design and hardening
- Activities: design/uplift liveness randomisation, PAD and injection defences, geotag verification, masking and encryption, audit-trail immutability, screening integration.
- Deliverables: control design documents, updated SOPs and policies, secure-configuration baselines, remediation backlog with owners.
Phase 3 — Technical testing
- Activities: spoof/PAD red-teaming, deepfake and camera-injection testing, replay and geo-spoof tests, VAPT of the app/APIs, cryptographic and TLS review, log-integrity testing.
- Deliverables: technical test report with severity-rated findings, proof-of-concept evidence, retest results.
Phase 4 — Process and governance validation
- Activities: review official training, concurrent-audit sampling, outsourcing governance, retention and DPDP/Aadhaar compliance, incident-response drills.
- Deliverables: process-control assessment, governance findings, evidence pack.
Phase 5 — Reporting, remediation and attestation
- Activities: consolidate findings, risk-rate, agree remediation plan, retest closed items, produce the RBI-ready V-CIP technology audit report.
- Deliverables: final audit report with executive summary, control-by-control opinion, remediation tracker, and management attestation.
Maturity and capability model
CyberSigma scores each control domain on a five-level capability scale. This gives management a defensible view of programme maturity and a target state for the next audit cycle.
| Level | Maturity | Description | Illustrative characteristic |
|---|---|---|---|
| L1 | Initial | Controls ad hoc or absent; heavy reliance on manual official judgement | No documented liveness thresholds; logs not immutable |
| L2 | Developing | Basic controls exist but are inconsistently applied or undocumented | Liveness present but no PAD testing; geotag captured but not verified |
| L3 | Defined | Controls documented, standardised, and mapped to RBI clauses | Randomisation, masking, encryption, audit trail all operational and documented |
| L4 | Managed | Controls measured, tested, and monitored with KPIs and concurrent audit | PAD/injection testing periodic; QC sampling and metrics reviewed |
| L5 | Optimised | Continuous improvement, threat-intel driven, automated assurance | Deepfake detection tuned on emerging attacks; automated log-integrity and anomaly detection |
An RE should target at least Level 3 (Defined) across all domains to pass a V-CIP technology audit, with Level 4 expected for high-volume onboarding given the concurrent-audit expectation.
Assessment and audit approach
- Initiation and scoping: confirm entities, platforms, vendors, and data flows; agree the control matrix and evidence plan.
- Documentation review: examine KYC/V-CIP policy, SOPs, architecture, prior audits, and vendor contracts against the Master Direction.
- Control walkthroughs: interview onboarding, engineering, compliance, and vendor teams; observe live/sandbox V-CIP sessions.
- Technical testing: perform spoof/PAD, deepfake, injection, replay, geo-spoof, VAPT, cryptographic, and log-integrity tests.
- Sampling: select onboarding sessions across risk categories and outcomes; reconstruct the full audit trail for each.
- Design and operating-effectiveness evaluation: assess whether controls are both designed adequately and operating consistently.
- Gap analysis and risk rating: rate each finding by likelihood and impact; map to the affected RBI clause and domain.
- Reporting: issue draft findings, obtain management responses, and finalise the control-by-control opinion.
- Remediation and retest: verify closure of high and critical findings; update the residual-risk position.
- Attestation: deliver the RBI-ready V-CIP technology audit report and maturity scorecard for supervisory submission.
Evidence request list
The following categorised evidence set should be assembled before fieldwork to accelerate the audit.
- Governance: board-approved KYC/V-CIP policy, organisation chart, roles and authorisation matrix, prior audit reports and action trackers.
- Architecture: system and data-flow diagrams, component inventory, vendor list, integration specifications (Aadhaar/e-KYC, DigiLocker, PAN, OVD).
- Consent and privacy: consent screens and text, DPDP/privacy notice, Aadhaar handling policy, data-retention and deletion policy.
- Liveness and anti-spoofing: liveness/PAD engine documentation, randomisation logic, threshold configuration, prior spoof/deepfake test results.
- Geotagging: geo-capture and geo-fence configuration, out-of-India rejection logs, anti-spoof controls.
- Identity verification: face-match and OCR configuration, Aadhaar masking implementation, sample (redacted) onboarding records.
- Recording and storage: encryption and key-management configuration, storage/residency attestations, retention schedules, access logs.
- Screening: sanctions/PEP/adverse-media tool configuration, list-update evidence, sample match dispositions, risk-scoring model.
- Audit trail and monitoring: log schema, sample end-to-end audit trails, SIEM integration, NTP/time-integrity configuration.
- IT general controls: IAM/RBAC matrix, MFA evidence, change records, secrets-management and VAPT reports, BCP/DR test results.
- Training and process: official training curriculum and records, concurrent-audit/QC sampling reports, grievance MIS.
- Vendor governance: contracts with audit-right and data-protection clauses, vendor due-diligence and vendor audit reports.
Roles and responsibilities
| Role | Responsibility in V-CIP compliance |
|---|---|
| Board / Senior Management | Approve KYC/V-CIP policy, ensure resourcing, oversee audit outcomes and residual risk |
| Principal Officer / MLRO | Own PMLA compliance, screening, STR/CTR reporting, risk-based approach |
| Chief Compliance Officer | Maintain regulatory mapping, track amendments, oversee control adequacy |
| Head of Onboarding / Operations | Own official training, workflow, concurrent-audit sampling, quality |
| CISO / IT Security | Own encryption, IAM, VAPT, log integrity, incident response, secure SDLC |
| Data Protection Officer | Own DPDP/Aadhaar compliance, consent, data-principal rights, breach notification |
| Product / Engineering | Build and harden liveness, geotag, face-match, audit-trail and API controls |
| Vendor / LSP | Deliver compliant platform under contract; provide audit access and evidence |
| Internal Audit | Perform periodic/concurrent audit; validate remediation |
| External Auditor (CyberSigma) | Independent technology audit, testing, opinion, and RBI-ready report |
KPIs to track
- Liveness/PAD false-accept and false-reject rates, trended over time.
- Percentage of sessions with complete, verified geotag within India.
- Face-match pass rate and average match score against threshold.
- Percentage of onboarding sessions with a complete, immutable audit trail on reconstruction.
- Spoof/deepfake red-team detection rate (attacks blocked vs attempted).
- Concurrent-audit / QC sampling coverage and exception rate.
- Screening hit rate and average disposition turnaround time.
- Percentage of high/critical VAPT findings closed within SLA.
- Aadhaar-masking and encryption coverage across stored records (target 100%).
- Data-retention compliance and timely deletion beyond retention period.
- Mean time to detect and report a personal-data breach (against CERT-In 6-hour rule).
- Official training completion and refresher currency rate.
Readiness checklist
- Board-approved KYC and V-CIP policy is in place and current.
- Explicit customer consent is captured within the recorded session.
- Random-action liveness prevents use of pre-recorded video.
- Presentation-attack, deepfake, and camera-injection defences are implemented and tested.
- Geotag is captured and verified to be within India, with spoof detection.
- Live face is matched to Aadhaar/OVD photo above a documented threshold.
- Aadhaar numbers are masked and data is encrypted at rest and in transit.
- Full audio-visual recordings are stored tamper-evidently within India.
- Retention meets the mandated five-year (or applicable) period.
- Immutable, time-synchronised audit trails cover every session step.
- Officials are authorised, trained, and subject to concurrent-audit sampling.
- Sanctions/PEP/adverse-media screening and risk categorisation are operational.
- IAM, MFA, VAPT, secrets management, and BCP/DR are in place.
- DPDP and Aadhaar Act obligations, including breach notification, are met.
- Vendor/LSP platforms are contractually governed and within audit scope.
- A current V-CIP technology audit report is available for supervisory review.
Common gaps
- Liveness present but no independent PAD/spoof testing, so real false-accept rates are unknown.
- Randomisation is predictable or reused, allowing pre-recorded video to pass.
- No camera-injection or virtual-camera detection, leaving the pipeline open to deepfake feeds.
- Geotag captured but never verified against India territory, or trivially spoofable.
- Aadhaar numbers stored unmasked or outside an Aadhaar Data Vault.
- Recordings stored without encryption, tamper-evidence, or within retention/residency requirements.
- Audit trails that are mutable, incomplete, or not time-synchronised, undermining reconstruction.
- Officials effectively outsourced and unsupervised, with weak training and no QC sampling.
- Screening lists updated infrequently or missing PEP/adverse-media coverage.
- Vendor platform performing V-CIP with no right-to-audit clause and no independent assessment.
- No DPDP-aligned consent management or breach-notification process meeting the CERT-In timeline.
- No concurrent or periodic V-CIP audit, so gaps persist undetected between inspections.
RBI KYC / V-CIP mapped to other frameworks
V-CIP controls overlap substantially with broader security and privacy frameworks. Mapping helps REs reuse evidence and avoid duplicate effort.
| V-CIP domain | ISO/IEC 27001:2022 | NIST CSF 2.0 | PCI DSS v4.0 | DPDP Act 2023 |
|---|---|---|---|---|
| Consent (D1) | A.5.34 privacy & PII | GV/ID (Govern, Identify) | N/A directly | Notice & consent obligations |
| Liveness/anti-spoof (D2) | A.8.26 app security requirements | PR.PS / DE (Protect, Detect) | Req 6 secure development | Reasonable security safeguards |
| Geotag (D3) | A.8.16 monitoring | DE.CM continuous monitoring | Req 10 logging | Purpose limitation |
| Identity/face match (D4) | A.5.16 identity management | PR.AA authentication | Req 8 identify & authenticate | Accuracy of personal data |
| Recording/storage (D5-D6) | A.8.24 cryptography; A.8.10 deletion | PR.DS data security | Req 3 protect stored data | Storage limitation & security |
| Session/network (D7) | A.8.20-8.21 network security | PR.PS platform security | Req 4 encrypt transmission | Security safeguards |
| Screening/risk (D8) | A.5.7 threat intelligence | ID.RA risk assessment | N/A | Lawful processing |
| Audit trail (D9) | A.8.15 logging | DE.CM / RS (Respond) | Req 10 logging & monitoring | Accountability |
| IT general controls (D10) | A.8 technological controls | PR / GV | Req 6, 7, 11 | Reasonable safeguards |
| Privacy (D11) | A.5.34; ISO 27701 | GV.SC / PR | Req 3, 9 | Core DPDP obligations |
| Governance/audit (D12) | Clause 9 performance evaluation | GV.OV oversight | Req 12 policies | Data-fiduciary duties |
How CyberSigma helps
CyberSigma is a CERT-In empanelled security auditing organisation with PCI QSA and deep RBI-regulatory expertise. We run end-to-end RBI KYC / V-CIP Technology Audits: liveness and deepfake red-teaming, camera-injection and geo-spoof testing, cryptographic and audit-trail review, Aadhaar and DPDP compliance validation, and vendor/LSP governance assessment. You receive an RBI-ready audit report with a control-by-control opinion, a maturity scorecard, and a prioritised remediation roadmap owned to closure, so your onboarding platform stands up to both fraudsters and supervisors. Talk to CyberSigma to scope your V-CIP audit and achieve sustainable compliance.
Frequently asked questions
What makes V-CIP secure?
Robust liveness detection and anti-spoofing, randomised prompts, geo-tagging, session integrity, strong encryption and complete audit trails — all validated in the technology audit.
Official documents
CyberSigma resources
Need help with RBI KYC / V-CIP?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.