V-CIP and RBI's video-KYC rules: what the liveness engine actually has to do

This is an engineering note, not compliance advice. The authoritative text is the RBI’s Master Direction on KYC and its amendments; your compliance team owns the interpretation for your institution. What this post does is translate the shape of those rules into the properties a liveness engine has to hold — because that translation is where most video-KYC implementations quietly go wrong.

V-CIP — the Video-based Customer Identification Process — is the RBI’s framework, introduced into the Master Direction on KYC in January 2020, that lets a regulated entity complete customer identification over a live video interaction instead of face-to-face. In broad strokes, the process is expected to be live and real-time, conducted by a trained official of the regulated entity, to confirm that the customer is a genuinely present live person, to capture a clear image of them, to verify identity documents, and to leave an auditable, retained record of the interaction. The exact obligations — geotagging, concurrent audit, document specifics, retention — live in the Master Direction itself and have been amended over time, which is precisely why you should read it rather than a vendor’s summary. Including ours.

The common implementation shortcut is to treat V-CIP liveness as a photo problem: grab a frame every few seconds, run a single-frame passive liveness check on it, average the scores, done. It demos well. It is also a different — and much weaker — security claim than the one the process is making.

A per-frame check answers “does this frame look like a live face?” A video session needs to answer “was a single, live, present human on this call for its entire duration?” Those differ in exactly the places attackers operate. A frame-sampling pipeline cannot see that the face was swapped between samples, that the “camera” is a virtual device replaying a recording, or that thirty seconds of perfectly live-looking frames contain no actual human motion at all.

From building our streaming engine (continuous liveness, shipped as /v1/stream), we ended up with four properties that a V-CIP liveness engine has to hold simultaneously — drop any one and there is a known attack that walks through the gap.

Liveness must be a property of the stream, not of sampled frames. Our engine ingests frames continuously over a WebSocket and maintains a temporal model across them: passive anti-spoof per frame, plus temporal signals — is there real, physically plausible head motion? Does the signal evolve the way a live face in front of a real camera evolves? A looped three-second clip that scores “live” on every individual frame fails the temporal model, because its motion statistics are wrong.

The person who passes the liveness check must be the person who finishes the call. The engine embeds faces throughout the session and verifies that they remain the same identity — the same 512-d face, within threshold, from first frame to last. Without this, the oldest trick in remote KYC works fine: the genuine customer starts the call, and the person the account is really for takes over after the liveness gate. Identity continuity turns “someone was live” into “this person was live throughout.”

Presentation attacks arrive through the camera; injection attacks arrive instead of the camera — virtual camera devices feeding a pre-recorded or deepfaked stream. A per-frame classifier is mostly blind to a good injection, because the injected frames genuinely are frames of a live person; they’re just not this moment’s frames. The engine therefore watches the stream itself: replayed content, frame-timing and content signatures inconsistent with live capture, and screen-recapture forensics — with the signals exposed in the response rather than swallowed into a bare verdict.

Randomized challenges — turn left, blink now — exist for one reason: a pre-recorded video cannot respond to instructions it has never seen. In a continuous session the engine issues the challenge script and verifies the response inside the same identity-continuous, temporally-scored stream. That last clause matters: a challenge check bolted onto a frame-sampling pipeline can be spliced; one embedded in the stream model cannot be answered by cutting between recordings without breaking properties 1 through 3.

Wired together, a session looks like this:

POST /v1/stream/start        # open a session, get challenge script
GET  /v1/stream/{id}         # WebSocket: stream frames in

# per-frame, in-stream:
#   passive anti-spoof        (is this frame live?)
#   temporal model            (is the motion real and sustained?)
#   identity continuity       (same 512-d face throughout?)
#   replay/injection signals  (is this capture, or a recording?)
#   challenge verification    (did they blink when asked?)

# end of session -> one signed verdict + full audit trail

Frame transport today is WebSocket ingest; a WebRTC media bridge is the remaining transport adapter on our roadmap — stated here because pretending otherwise is exactly the vendor behaviour we complain about.

If you are buying rather than building, five questions separate continuous liveness from frame sampling with better marketing. Is liveness scored over the whole stream or on sampled frames? Is identity continuity enforced frame-to-frame, and with what face-match threshold? What specifically detects an injected virtual-camera feed? Are challenges randomized per session and single-use? And can you get the per-session evidence — signals, scores, audit trail — or just a pass/fail? We keep a longer version of this list, with our own answers linked, on the vendor checklist page.