A video KYC compliance checklist turns the Reserve Bank of India's V-CIP (Video-based Customer Identification Process) minimum standards into items a team can build, test and prove to an auditor. For a commercial bank, those standards are paragraph 27 of the Commercial Banks KYC Directions, 2025 (RBI/DOR/2025-26/169); other regulated entities have the same rules under other paragraph numbers. The checklist below has 34 items in four phases: before go-live, before each session, during the session and after it.
Each item gives the RBI requirement and its paragraph, what to build, how to test it, the evidence to keep, and whether the item is RBI text or common practice. It is written for compliance, product and engineering teams at banks, NBFCs and other RBI-regulated entities, and for the fintechs that build V-CIP for them. A free copy of the same checklist is available as a CSV and a PDF, with no form to fill in.
How VideoSDK built this checklist: we read the V-CIP paragraphs of all ten KYC Directions, 2025 on rbi.org.in and compared them line by line. We read the Google India results for the checklist, geo-tagging and retention searches. We ran the two code samples in a test project, with @videosdk.live/react-sdk 1.2.0 for the call in headless Chrome and the live VideoSDK REST API for the checks. The build, test and evidence columns are our reading for engineering and audit teams, not legal advice. VideoSDK sells the video layer named in some rows; every other row works with any provider. If you find an error, tell us and we will correct the page.
Key takeaways
- V-CIP is optional ("may undertake V-CIP", para 26 for commercial banks), but an entity that offers it must meet every minimum standard in para 27 and offer V-CIP as the first option for remote onboarding (para 44(1)).
- Video KYC geo tagging means the recording itself carries the customer's live GPS coordinates and a date and time stamp (para 27(1)(iv)). Blocking IP addresses outside India is a separate rule (27(1)(iii)).
- There is no V-CIP-specific recording retention period. Para 27(3)(i) applies the record rules to V-CIP, and VideoSDK's reading is that the recording is an identification record, kept at least five years after the business relationship ends (para 50(2) for commercial banks). Rejected and dropped sessions have no RBI period, so your written policy decides.
- Several items on the ten third-party checklist pages we reviewed are not in the RBI text: an eight-year retention rule, a minimum bandwidth, "IP whitelisting", mandatory blinking, and concurrent audit of a sample of sessions.
Video KYC compliance checklist at a glance
The 34 items reduce to these controls, in the order a session runs. Paragraph numbers are from the Commercial Banks KYC Directions, 2025.
- Before go-live: technology in your own premises and network domain (27(1)(i)); no data left with the cloud or video provider (27(1)(i)); encryption from the customer's device to your hosting point (27(1)(ii)); block IP addresses outside India and spoofed IPs (27(1)(iii)); liveness and face match (27(1)(v)); VAPT and security audit by CERT-In empanelled auditors (27(1)(viii)).
- Before each session: consent recorded (27(1)(ii)); negative-list screening (27(2)(v)); one of four identity sources (27(2)(vi)); Aadhaar XML or QR not older than three working days (27(2)(viii)).
- During the session: a trained official admits and runs the call (27(2)(i)); audio and video recorded with live GPS and a time stamp (27(1)(iv), 27(2)(vi)); varied questions (27(2)(iii)); clear PAN image (27(2)(xi)); a fresh session after any call drop (27(2)(ii)).
- After the session: concurrent audit before the account works (27(2)(xv)); all data and recordings in India (27(3)(i)); activity log with the official's credentials (27(3)(ii)); records kept at least five years after the relationship ends (50(2)).
How to read this video KYC checklist
Every row in the tables below has four columns:
- Requirement (para): what the RBI text asks, in short form, with the paragraph of the Commercial Banks Directions. Quotes are exact; the rest is a close summary. The two rows that are not in the RBI text, P4 and L11, start with "Common practice": they help you meet a rule that is.
- What to build: the app or platform feature that meets the requirement. Where a VideoSDK feature fits, it is named, with its plan where the docs give one.
- How to test: a test you can run before go-live and repeat at each periodic review.
- Evidence to keep: what an internal or concurrent auditor is likely to ask for.
The build, test and evidence columns are VideoSDK's reading. Your compliance team and your CERT-In empanelled auditor decide what your evidence pack contains.
Which RBI paragraphs apply to your entity?
The V-CIP rules sit in each entity's own KYC Directions, 2025, all issued on 28 November 2025. The 2016 KYC Master Direction they replaced is repealed. Find your row, then read the checklist with your own paragraph numbers.
| Regulated entity | KYC Directions, 2025 | V-CIP uses | Minimum standards | Five-year record rule |
|---|---|---|---|---|
| Commercial banks | RBI/DOR/2025-26/169 | 26 | 27 | 50(2) |
| Small finance banks | RBI/DOR/2025-26/200 | 27 | 28 | 51(2) |
| Payments banks | RBI/DOR/2025-26/218 | 26 | 27 | 49(2) |
| Local area banks | RBI/DOR/2025-26/243 | 25 | 26 | 49(2) |
| Regional rural banks | RBI/DOR/2025-26/266 | 25 | 26 | 49(2) |
| Urban co-operative banks | RBI/DOR/2025-26/291 | 25 | 26 | 49(2) |
| Rural co-operative banks | RBI/DOR/2025-26/316 | 25 | 26 | 49(2) |
| All India financial institutions | RBI/DOR/2025-26/335 | 26 | 27 | 47(2) |
| NBFCs | RBI/DOR/2025-26/361 | 26 | 27 | 47(2) |
| Asset reconstruction companies | RBI/DOR/2025-26/377 | 25 | 26 | 45(2) |
Read the row for your own entity, because the shift is not the same everywhere. A small finance bank adds one to every V-CIP number (27(1)(iv) becomes 28(1)(iv)); local area banks, regional rural banks, co-operative banks and ARCs take one off; an NBFC keeps 26 and 27 but its record rule is 47(2), not 50(2).
Where the V-CIP text differs by entity type
VideoSDK compared the ten V-CIP texts line by line after replacing the entity name. Three differences change the checklist:
- Assisted V-CIP through Business Correspondents is only in the seven bank Directions. NBFC, AIFI and ARC teams can skip item G13, and their concurrent audit clause is numbered (xiv), not (xv).
- The cyber security framework named in the first infrastructure clause is the one "for banks" in all seven bank texts, and the one for NBFCs, AIFIs or ARCs in the other three. Map item G1 to your own framework.
- The NBFC text numbers its uses (1) to (4), because the proprietorship-firm proviso has its own number. Cite "26(3)" for converting Aadhaar OTP accounts if you are an NBFC.
Payment aggregators
Non-bank payment aggregators are not one of the ten entity types, but their rules point to the same text. The RBI's payment aggregator Master Direction (RBI/DPSS/2025-26/141) asks a PA to do customer due diligence of its merchants "in accordance with MD on KYC" (para 13(a)), and lets a non-bank PA use agents for "Assisted V-CIP" at the merchant's end (para 15(a)(ii)). Since the 28 November 2025 circular (RBI/2025-26/101), those references read as the Commercial Banks KYC Directions, 2025, and the assisted V-CIP reference as their paragraph 27. VideoSDK's reading: a PA can use the checklist with the commercial bank numbers, and item G13 applies to its agents. Para 27 is worded for banks, so confirm the scope with your counsel. The same circular also points prepaid payment instrument issuers to the Commercial Banks KYC Directions (para 6.1 of the PPI Master Direction); VideoSDK has not mapped PPI scope separately.
The rest of the differences are cross-references and spelling. For the full clause-by-clause explanation of each rule, see our guide to the RBI video KYC guidelines. NBFC teams can also read video KYC for NBFCs, and co-operative and small finance banks can read video KYC for co-operative and small finance banks.
Video KYC checklist: before go-live
The go-live items cover the infrastructure rules in para 27(1), plus the SOP and the Business Correspondent rule from 27(2). Run them once before roll-out and again at each periodic review, because 27(1)(viii) and (ix) ask for the security and functional tests to be "carried out periodically".
| Requirement (para) | What to build | How to test | Evidence to keep |
|---|---|---|---|
| G1. Technology housed in the bank's own premises; the V-CIP connection originates from its own secured network domain; outsourcing follows RBI rules (27(1)(i)) | Host the V-CIP application and the official's console inside your network domain; list every vendor component as an outsourced service | Trace a test session end to end; confirm the official's console cannot be reached from outside the bank network | Architecture diagram, outsourcing assessment |
| G2. With cloud deployment, data ownership rests with the bank, all data including the video moves to bank-owned or leased servers immediately after the session, and the provider retains no data (27(1)(i)) | Configure your own AWS S3, Azure Blob or GCP bucket as the recording storage (VideoSDK storage configuration); confirm in writing whether any copy of the media or call metadata remains with the provider, and delete what does (VideoSDK delete recording API) | After a test session, confirm the file is in your bucket, then list recordings through the provider API and check what remains | Storage configuration, deletion log, provider's data terms |
| G3. End-to-end encryption of data between the customer's device and the hosting point of the V-CIP application (27(1)(ii)) | Encrypt every hop from the customer's browser or app to your hosting point; media end-to-end encryption between participants blocks recording on VideoSDK, so agree the design with your security team | Security test of each network hop by your CERT-In empanelled auditor | Encryption design note, VAPT report |
| G4. Customer consent recorded in an auditable and alteration-proof manner (27(1)(ii)) | A consent screen before the join; store the consent text version, time and customer reference in an append-only log | Try to edit a stored consent record; the change must be refused or detected | Consent log, tamper test result |
| G5. The application is capable of preventing connections from IP addresses outside India or from spoofed IP addresses (27(1)(iii)) | IP geolocation before you issue the join token, plus VPN or proxy detection as your reading of "spoofed"; VideoSDK Geo IP Restriction with region INDIA (Enterprise in the docs, add-on on the pricing page) | Join from a non-India IP address: it must be refused before the call starts; repeat through a VPN or proxy if your policy blocks them | Configuration, test cases with results |
| G6. Recordings contain the customer's live GPS co-ordinates and a date and time stamp; live video quality allows identification beyond doubt (27(1)(iv)) | Capture device GPS during the call and show it in the recording (VideoSDK geo-tag recording template reads PubSub topic GEO_TAG); add the date and time in the template, which you host yourself | Play back a test recording and read the coordinates and time on screen; deny location permission and confirm the official cannot proceed | Sample recordings, denial test result |
| G7. Face liveness or spoof detection and face matching with a high degree of accuracy; gestures such as blinking are not mandatory; special needs are considered (27(1)(v)) | A liveness and face match component (VideoSDK Face Match and Face Spoof Detection APIs are Enterprise); a path for customers who cannot make a gesture | Run a spoof set (printed photo, screen replay, mask) and a no-gesture case | Vendor accuracy report, test results |
| G8. The bank may use appropriate AI technology to make the V-CIP stronger (optional) (27(1)(vi)) | If used, AI checks support the official (document reading, face match scores, fraud signals) and never decide alone | Confirm the official can see and override every AI result | Model documentation, override log |
| G9. Technology and workflows updated from detected, attempted and near-miss forgery cases; forged identity reported as a cyber event (27(1)(vii)) | A feedback loop from fraud cases into the app and SOP; a reporting step in the incident process | Tabletop drill with a forged-identity case | Incident register, change log |
| G10. Vulnerability assessment, penetration testing and security audit by CERT-In empanelled auditors before roll-out and periodically; critical gaps closed first (27(1)(viii)) | Book the empanelled auditor before the build freezes; track every finding to closure | Retest of every critical finding | Auditor reports, closure evidence |
| G11. Functional, performance and maintenance testing of the application and its APIs before live use, repeated periodically (27(1)(ix)) | Load test at expected peak sessions; failure tests for recording failure, network drop and token expiry | Test plan executed with results; critical gaps closed before roll-out | Load and failure test reports, gap closure log |
| G12. A clear workflow and SOP; V-CIP operated only by specially trained officials who can do the liveness check; liveness does not exclude persons with special needs (27(2)(i)) | Official's console that follows the SOP; role-based access for trained officials only | Log in with an untrained account: the console must refuse it | SOP, training records, access list |
| G13. Banks: assisted V-CIP through Business Correspondents at the customer end, with the BC's details kept (non-bank payment aggregators: through agents at the merchant end) (27(2)(xiv)) | A BC or agent field in the session record; support for a device held by the BC or agent at the customer side | Run an assisted test session and check the BC or agent details are stored | BC or agent details per session |
Items G3 and G2 need a design decision early. Item G3: the RBI asks for encryption "between customer device and the hosting point of the V-CIP application", and the hosting point also records the call. VideoSDK's end-to-end encryption guide says recording and transcription do not run while media end-to-end encryption is on, so agree the encryption design with your security team and auditor before you build. Item G2: VideoSDK's recording storage configuration lets you write recordings to your own AWS S3, Azure Blob or GCP bucket, and a delete recording API removes a file by ID. The docs do not say whether VideoSDK keeps a copy of a recording stored in your bucket, or what call metadata it keeps, so settle both in the contract. The docs we read also do not say where media is processed or recordings are composed, or describe running the media layer inside a bank's own network domain: for G1 and A2, get both answers from VideoSDK in writing. VideoSDK's recording encryption can also encrypt each file at rest with your RSA public key.
Video KYC checklist: before each session
The per-session items run before the customer reaches the official: screening, the identity source and the three-working-day limits in 27(2)(v) to (ix). Most of them can be automated, and a stale Aadhaar XML file fails 27(2)(viii) before the call starts.
| Requirement (para) | What to build | How to test | Evidence to keep |
|---|---|---|---|
| P1. The workflow factors in existing or new customer, earlier rejection and negative lists (27(2)(v)) | Screening step before the call is scheduled | Run a name from a test negative list: the case must be flagged | Screening results |
| P2. Identity information from one of: Aadhaar OTP e-KYC, offline Aadhaar verification, CKYCR records, or an equivalent e-document including DigiLocker (27(2)(vi)) | Record which source was used for each session | Check every test session record names one source | Identity source per session |
| P3. Aadhaar XML or Secure QR not older than three working days; the video step within three working days of obtaining the identification information (27(2)(viii), (ix)) | A date gate that counts working days before the call can start | Feed an XML file generated four working days earlier: the call must not start | Download and call timestamps |
| P4. Common practice: Pre-call device and network check so the call can meet the video quality rule | VideoSDK runPreCallTest() before the customer enters the waiting room | Run it on a throttled network and confirm the customer is told before the call | Pre-call results |
| P5. Customer consent taken for each session and recorded in an auditable and alteration-proof manner (P5 applies G4 to every session) (27(1)(ii)) | Consent screen shown and logged for every session before the join token is issued | Start a session without consent: the join must be blocked | Consent record per session |
Video KYC checklist: during the session
The V-CIP live-session controls are the items an auditor checks against the recording itself, so each needs a test that leaves evidence. They come from 27(2)(i) to (xiii) and the geo-tagging rule in 27(1)(iv). We did not run ask_join admission, onFailure close-room, captureImage() or runPreCallTest(); those rows follow VideoSDK's docs.
| Requirement (para) | What to build | How to test | Evidence to keep |
|---|---|---|---|
| L1. Only a trained official runs the session (27(2)(i)) | The customer waits until an official admits them (VideoSDK ask_join token and onEntryRequested) | Join as the customer with no official present: entry must stay pending | Activity log with join times |
| L2. Record audio and video and capture a photograph of the customer (27(2)(vi)) | Start the recording before the identity checks, with onFailure close-room; capture a still on the customer's device with captureImage(). VideoSDK's remote-capture flow holds the image in temporary file storage until the room ends, so send it from the customer's page to your server or settle the copy in the contract (G2) | Make recording fail in a test: the room must close; run the session audit and check it reports one recording | Recording, photo, audit output |
| L3. Disruption must not create multiple video files; a call drop or disconnection needs a fresh session (27(2)(ii)) | When the customer drops, end the room and create a new one for the retry; link both to the same application | Drop the customer's network mid-call; run the session audit and check no customer rejoined the same session | Session log, audit output |
| L4. Vary the sequence and type of questions to show the call is live, not pre-recorded (27(2)(iii)) | A question bank that shuffles order and type per session | Compare two test sessions: question order differs | Question bank, session notes |
| L5. Reject the account opening if there is prompting at the customer end (27(2)(iv)) | A reject action with a reason code on the official's console | Role-play a prompted customer and check the rejection is logged | Rejection log |
| L6. Redact or black out the Aadhaar number (27(2)(vii)) | Mask the number in captures and stored documents | Inspect stored test captures for an unmasked number | Masked samples |
| L7. Capture current address records if they differ from the OVD; confirm the economic and financial profile (27(2)(x)) | Address capture and profile questions in the official's script | Run a test case with a different current address | Session notes, address record |
| L8. Capture a clear image of the PAN card unless e-PAN is given; verify PAN with the issuing authority, including through DigiLocker (27(2)(xi)) | High-resolution capture from the customer's camera; PAN verification call | Hold up a blurred PAN: the official must ask again | PAN image, verification response |
| L9. A printed copy of an equivalent e-document, including e-PAN, is not valid (27(2)(xii)) | SOP step and a reject reason for printouts | Show a printed e-PAN in a test call: it must be rejected | SOP, rejection log |
| L10. The customer's photo in Aadhaar or OVD and PAN matches the customer, and the details match (27(2)(xiii)) | Face match between the live face and document photos, plus a details check | Run a mismatched photo case | Match results |
| L11. Common practice: GPS fix shown to the official before identity checks start, with its accuracy | Show the latest coordinates, accuracy and time on the official's console | Emulate a position and confirm the console shows it; deny permission and confirm the checks stay locked | Console screenshot, test result |
Video KYC checklist: after the session
The V-CIP post-session controls decide when the account can be used and how long the evidence is kept. They come from 27(2)(xv), 27(3) and the record rule.
| Requirement (para) | What to build | How to test | Evidence to keep |
|---|---|---|---|
| A1. Accounts opened through V-CIP become operational only after concurrent audit (27(2)(xv)) | Keep the account inactive until the concurrent auditor signs off | Try a transaction before sign-off: it must be blocked | Audit sign-off per account |
| A2. All data and recordings stored in systems located in India, safe and secure, with date and time stamps that allow easy search; record management rules apply (27(3)(i)) | India-region bucket you control; index recordings by date, time and application | Search for a test session by date and retrieve it; check the bucket region | Storage region settings, search test |
| A3. Activity log preserved with the credentials of the official who performed the V-CIP (27(3)(ii)) | Sessions API join and leave times stored with the official's employee ID from your system | Export the log for a test session and check the official's ID is present | Activity log export |
| A4. Identification records kept for at least five years after the business relationship ends (50(2)) | A retention date computed from the relationship end, not the session date | Close a test account and check the computed review date | Retention policy, retention job log |
| A5. Other statutes such as the IT Act apply (27(2)(xvi)) | Legal review of data protection and IT Act duties for recordings and logs | Not a technical test | Legal review note |
What does video KYC geo tagging require?
Video KYC geo tagging means the V-CIP recording itself carries the customer's live GPS coordinates and a date and time stamp; it is not an IP address check. The RBI text is one sentence: "The video recordings shall contain the live GPS co-ordinates (geo-tagging) of the customer undertaking the V-CIP and date and time stamp" (para 27(1)(iv) for commercial banks). Three things follow from the wording.
- The coordinates belong in the recording (VideoSDK's reading). A location stored in a separate database table does not show that the recording carries it. Burn the coordinates and the time into the video, or store them with the recording in a way the reviewer sees on playback.
- They must be live GPS (VideoSDK's reading). A location derived from the IP address, or typed by the customer, is not live GPS from the device. Ask for device location permission at the start of the call and keep updating it.
- Geo-tagging is not the India check. The rule that keeps foreign connections out is 27(1)(iii): the application must be "capable of preventing connection from IP addresses outside India or from spoofed IP addresses". The Directions do not use the words "physically present in India" that some pages attach to geo-tagging, and they do not ask for an IP whitelist.
| What to capture | Basis | How VideoSDK can carry it |
|---|---|---|
| Latitude and longitude from the device, during the call | RBI text, 27(1)(iv) | Customer page publishes them on the PubSub topic GEO_TAG, which the geo-tag recording template reads and shows in the recording |
| Date and time stamp in the recording | RBI text, 27(1)(iv) | Shown by your recording template; recordings also have a creation time in the fetch recordings API |
| GPS accuracy in metres and the time of the fix | Common practice | Send them in the same PubSub message and show them on the official's console |
| Refusal when location is denied | Common practice | Your app keeps the identity checks locked until a fix arrives |
| Connection from an IP address outside India, or a spoofed IP | RBI text, 27(1)(iii) | Geo IP Restriction with region INDIA (Enterprise in the docs, add-on on the pricing page) or your own IP check before you issue the join token |
| VPN or proxy detection | Common practice (VideoSDK's reading of "spoofed") | The Geo IP Restriction docs list VPN and proxy restriction as a use case; or your own detection |
To test it, emulate a position on the customer's device, run a session, and play back the file: the coordinates and time must be readable. Then deny location permission and confirm the official cannot start the checks. We did not run the geo-tag recording template, a billed recording, or a foreign-IP or VPN connection; those steps follow VideoSDK's docs. In our test run, with an emulated position in Mumbai, the official's console showed "Customer GPS: 19.076000, 72.877700 (within 20 m)" with the time it was received. The components we used, and the late-joiner issue we found, are in the code section of our RBI video KYC guidelines guide.
How long must video KYC recordings be kept?
The RBI sets no recording retention period specific to V-CIP; the general KYC record rule applies, and on VideoSDK's reading that means keeping a recording for at least five years after the business relationship ends. Para 27(3)(i) says "the extant instructions on record management, as stipulated in this direction, shall also apply to V-CIP", and the record rule for commercial banks, para 50, has two clocks:
- Identification records: kept "for at least five years after the business relationship has ended" (50(2)). The Explanation to para 50 says identification records include "updated records of the identification data, account files, business correspondence and results of any analysis undertaken". VideoSDK's reading is that a V-CIP recording is part of the identification record, so its clock starts when the relationship ends, not on the day of the call.
- Transaction records: kept "for at least five years from the date of transaction" (50(1)). This clock covers transactions, not the onboarding video.
The same two clocks sit in the law above the Directions. Section 12 of the Prevention of Money-laundering Act, 2002 keeps transaction records "for a period of five years from the date of transaction" (12(3)). It keeps identity records "for a period of five years after the business relationship between a client and the reporting entity has ended or the account has been closed, whichever is later" (12(4)). The Digital Personal Data Protection Act, 2023 adds the other edge: once its section 8(7) is in force, personal data must be erased when the purpose is served, "unless retention is necessary for compliance with any law for the time being in force". The DPDP Rules, 2025, published on 13 November 2025, start in stages, and most of their duties begin eighteen months after publication. VideoSDK's reading: keep each recording for as long as the KYC record rule needs it, then delete it on a schedule you can show.
For the build, that means:
- Store the relationship end date with every recording. A recording made today for an account that stays open for twenty years is kept for twenty-five years or more. On this reading, a retention job that deletes recordings five years after the call breaks the rule.
- Write a policy for rejected and dropped sessions. The Directions are silent on recordings of sessions that did not open an account. Decide the period, write it down and apply it the same way every time.
- Keep everything in India. All data and recordings of V-CIP must be stored "in a system / systems located in India" (27(3)(i)), searchable by date and time.
This small helper encodes the two cases. It is plain JavaScript, so it runs in any Node service that owns your retention job.
// retention.mjs: when may a V-CIP recording be reviewed for deletion?
// RBI sets no V-CIP-specific period. Identification records are kept for at
// least five years after the business relationship ends (para 50(2) for
// commercial banks; check the paragraph for your entity type). PMLA section
// 12(4) counts from the relationship end or the account closure, whichever
// is later, so pass both dates when you have them.
export function retentionFor({ outcome, relationshipEndedAt, accountClosedAt, policyDaysForRejected }) {
if (outcome === "account-opened") {
const ends = [relationshipEndedAt, accountClosedAt].filter(Boolean).map((d) => new Date(d));
if (ends.length === 0) {
return { basis: "KYC record rule", reviewAfter: null, note: "Relationship active: keep" };
}
const reviewAfter = new Date(Math.max(...ends));
reviewAfter.setUTCFullYear(reviewAfter.getUTCFullYear() + 5);
return {
basis: "KYC record rule",
reviewAfter: reviewAfter.toISOString(),
note: "At least five years after the later end date; legal holds extend this",
};
}
// Rejected or dropped sessions: no RBI period. Your board-approved policy
// decides, and the decision should be written down.
if (typeof policyDaysForRejected !== "number") {
throw new Error("Set a written retention policy for rejected and dropped sessions");
}
return { basis: "Internal policy", reviewAfterDays: policyDaysForRejected, note: "No RBI period" };
}
We ran it with Node's built-in test assertions: an open account returns no review date, an account closed on 31 March 2026 returns 31 March 2031, and a rejected session without a written policy throws an error instead of picking a period. The date adds calendar years; our first version added 365.25-day blocks and drifted by six hours, so test your own date code the same way.
Which checklist items are not in the RBI text?
Some items on the ten third-party checklist pages and in the AI answers we read for these searches are not in the 2025 Directions. VideoSDK checked each one against the Commercial Banks text.
| Claim (not in the RBI text) | What the Directions say |
|---|---|
| "Keep recordings for eight years" | No eight-year rule. Identification records: at least five years after the relationship ends (50(2)). |
| "Five years from the date of the session" | 50(2) counts identification records from the end of the relationship. That a V-CIP recording is an identification record is VideoSDK's reading of 27(3)(i) and the Explanation to para 50. |
| "A minimum bandwidth such as 500 kbps" | No figure. Video quality must allow identification "beyond doubt" (27(1)(iv)). |
| "IP whitelisting" | The rule is to prevent connections "from IP addresses outside India or from spoofed IP addresses" (27(1)(iii)). |
| "The customer must blink or smile" | Gestures are "not mandatory for liveness check" (Explanation to 27(1)(v)). |
| "Concurrent audit of a percentage of sessions" | Every V-CIP account becomes operational "only after subjecting them to concurrent audit" (27(2)(xv)). |
| "An August 2025 amendment made deepfake detection mandatory" | The 14 August 2025 amendment (RBI/2025-26/75, an amendment to the now repealed 2016 Master Direction) added that liveness "shall not result in exclusion of person with special needs"; the same sentence now sits in 27(2)(i). Spoof detection is in the minimum standards as 27(1)(v). |
| "AI can run the call alone" | Only "officials of the bank specially trained for this purpose" operate V-CIP (27(2)(i)); AI may support them (27(1)(vi)). |
| "Aadhaar XML must be less than three days old" | "Not older than three working days" from the date of the V-CIP (27(2)(viii)). Count working days, not calendar days. |
| "AES-256 encryption is mandatory" or "multi-factor login is mandatory" | No cipher or login method is named. The rule is end-to-end encryption "between customer device and the hosting point of the V-CIP application" (27(1)(ii)). |
| "Insurers must follow the RBI V-CIP rules" | The KYC Directions cover RBI-regulated entities. Insurers follow IRDAI's video-based identification rules; see our IRDAI VBIP guide. |
| "The session ends after 30 seconds of lost video" or "calls only in business hours" | No such figures. A pause that creates no second file may continue; a call drop needs a fresh session (27(2)(ii)). |
How to test your V-CIP flow before an audit
The "How to test" column turns into a test plan with three layers: manual role-play tests for the SOP items (prompting, printouts, varied questions), automated browser tests for the app items (GPS, admission, recording start), and a post-session audit that reads the platform's own records. The third layer can also run after every live session.
This server-side check reads VideoSDK's sessions API and fetch recordings API for one room and reports each rule it can evidence. officialIds are the participant IDs your app gave the officials when they joined (the participantId field in the meeting config).
// auditVcipSession.mjs (your server, Node 18+)
// Checks one V-CIP room after the call against the session rules a video
// platform can evidence. officialIds are the participantId values your app
// gave the bank officials when they joined.
const API = "https://api.videosdk.live/v2";
async function getJson(url, serverToken) {
const res = await fetch(url, { headers: { Authorization: serverToken } });
if (!res.ok) throw new Error(`${url} answered ${res.status}`);
return res.json();
}
export async function auditVcipSession({ roomId, officialIds, serverToken }) {
const room = encodeURIComponent(roomId);
const { data: sessions } = await getJson(`${API}/sessions/?roomId=${room}`, serverToken);
const { data: recordings } = await getJson(`${API}/recordings?roomId=${room}`, serverToken);
return sessions.map((session) => {
const people = session.participants;
const officials = people.filter((p) => officialIds.includes(p.participantId));
const customers = people.filter((p) => !officialIds.includes(p.participantId));
const files = recordings.filter((r) => r.sessionId === session.id);
const checks = [];
const check = (para, rule, pass, detail) => checks.push({ para, rule, pass, detail });
check("27(2)(i)", "A bank official took part in the session", officials.length > 0,
`${officials.length} official(s), ${customers.length} other participant(s)`);
// A customer who joined twice in one session rejoined after a drop:
// the Directions ask for a fresh session instead.
const rejoins = customers.filter((p) => p.timelog.length > 1);
check("27(2)(ii)", "No customer rejoined the same session", rejoins.length === 0,
rejoins.map((p) => `${p.name} joined ${p.timelog.length} times`).join("; ") || "none");
// One recording, and only one: 27(2)(vi) asks for a recording and
// 27(2)(ii) says a disruption must not create multiple video files.
check("27(2)(ii), (vi)", "Exactly one recording file", files.length === 1, `${files.length} file(s)`);
// geoLocation came back on each participant in our test run but is not in
// the API reference: confirm with VideoSDK before you rely on it. It is an
// after-the-fact check, not the block that 27(1)(iii) asks for.
const unknown = people.filter((p) => !p.geoLocation);
const abroad = people.filter((p) => p.geoLocation && p.geoLocation.country !== "India");
check("27(1)(iii)", "Every connection was located in India", unknown.length === 0 && abroad.length === 0,
abroad.map((p) => `${p.name}: ${p.geoLocation.country}`).join("; ") ||
(unknown.length ? `${unknown.length} without location` : "all India"));
return { sessionId: session.id, start: session.start, end: session.end, checks };
});
}
We ran it against two test rooms, each with an official and a customer joining from headless Chrome. In the first room the customer's page reloaded mid-call and joined the same room again, the way a phone does after a network drop.
- First room: "Test Customer joined 2 times" failed the fresh-session check, as intended. Your app should have ended that room and opened a new one.
- Second room, no reload: the fresh-session check passed.
- Both rooms failed "Exactly one recording file" with "0 file(s)", because we did not start a recording. We did not run the success path (one file) or produce a second file.
- The sessions API returned a
geoLocationobject (city, region, country) on each participant, which the reference does not list, so the India check in the sample is marked as one to confirm with VideoSDK. It cannot replace the block before the join.
Run the audit from the recording-stopped webhook and store its output with the session record, so it can serve as evidence for items L2, L3 and A3.
What is needed in video KYC on the customer's side?
The customer's side of the video KYC checklist is short. Show it in your app before the call:
- A phone or computer with a working camera and microphone, and location permission turned on for the call.
- The original PAN card (a printout of an e-PAN is not accepted), unless an e-PAN is shared digitally.
- Aadhaar details for OTP e-KYC or a recent offline Aadhaar XML or QR, or the KYC identifier for CKYCR, depending on the method the entity uses.
- A quiet, well-lit place with no one prompting the customer, because the official must reject the session if there is prompting.
- Answers ready for questions on current address, occupation and income.
Glossary
- V-CIP (Video-based Customer Identification Process) is the RBI's term for video KYC run live by a trained official of the regulated entity.
- Geo-tagging is attaching the customer's live GPS coordinates to the V-CIP recording, with a date and time stamp.
- Concurrent audit is the check of each V-CIP account that must happen before the account is made operational.
- CERT-In empanelled auditor is a security auditing organisation on the list of the Indian Computer Emergency Response Team, required for V-CIP security testing.
- Equivalent e-document is an electronic version of an identity document issued with a valid digital signature, including documents in DigiLocker.
- Business Correspondent (BC) is an agent a bank uses outside its branches; banks may use BCs for assisted V-CIP at the customer end.
- Activity log is the record of who did what in a V-CIP session, which must be kept with the official's credentials.
Frequently asked questions
What are the things required for video KYC?
For the regulated entity: a trained official, a recorded live video call with the customer's consent, live GPS and a time stamp in the recording, the ability to block IP addresses outside India, liveness and face match, a clear PAN image, and storage of all data in India. For the customer: a device with camera, microphone and location turned on, the PAN card and Aadhaar details.
What are the RBI guidelines for video KYC?
They are the V-CIP paragraphs of each entity's KYC Directions, 2025: paras 26 and 27 for commercial banks and NBFCs, and other numbers for other entities. They cover infrastructure, the call procedure and records. This page turns each clause into a checklist item; the entity table above gives your paragraph numbers.
What will be asked in video KYC?
The official confirms your identity details, asks you to show your PAN card, asks questions in a varied order to confirm the call is live, and confirms your current address and your occupation and income. Expect the official to capture your photo and to reject a printout of an e-document, including an e-PAN.
Is geo-tagging mandatory in video KYC?
Yes, for V-CIP under the RBI KYC Directions, 2025. The video recordings must contain the customer's live GPS coordinates and a date and time stamp (para 27(1)(iv) for commercial banks). Separately, the application must be able to block connections from IP addresses outside India or from spoofed IP addresses.
Does the RBI require IP whitelisting for video KYC?
No. The rule is that the V-CIP application "shall be capable of preventing connection from IP addresses outside India or from spoofed IP addresses" (para 27(1)(iii) for commercial banks). On VideoSDK's reading, that means an IP geolocation check and VPN or proxy detection before the customer joins, plus the live GPS geo-tag in the recording, which is a separate rule.
Does a dropped video KYC call need a new session?
Yes. Para 27(2)(ii) says that "in case of call drop / disconnection, fresh session shall be initiated". A short pause that does not create a second video file may continue in the same session. In practice, end the room when the customer drops, create a new one for the retry, and link both to the same application.
What is the retention period for KYC records after account closure?
At least five years after the business relationship ends or the account is closed. The RBI Directions say "at least five years after the business relationship has ended" (para 50(2) for commercial banks), and section 12(4) of the PMLA says five years after the relationship ended or the account was closed, "whichever is later". Transaction records run five years from each transaction.
Can a fintech or vendor keep copies of V-CIP recordings?
No, where the regulated entity uses a cloud or third-party setup. Para 27(1)(i) says data ownership rests with the entity, all data including the video moves to its own or leased servers immediately after the session, and the cloud or technology provider "shall retain no data".
Conclusion
Each item on a V-CIP compliance checklist needs evidence an auditor can check. Start from your entity's own Directions, build each item, run its test, and keep the output where your concurrent auditor and CERT-In empanelled auditor can find it. The three items most worth automating are the geo-tag in the recording, the fresh session after a call drop, and the retention date that runs from the end of the relationship.
Build your V-CIP flow on VideoSDK. Sign up for VideoSDK to get API keys and follow the video KYC guide. A new account comes with a $20 credit (pricing). Need Geo IP Restriction, Geo Fencing to India or the identity APIs? Talk to our team about Enterprise. If you are still choosing between building and buying, our build vs buy guide covers the trade-offs.