Deepfakes in KYC: Detecting Face Spoofing and Protecting Video Verification

Deepfake Attack Scenarios Against KYC Video Verification

Attackers adapt deepfake tools to specific points in the KYC process: the video selfie, direct camera capture, the operator call, passive liveness detection. Each scenario exploits its own vulnerability and requires separate countermeasures.

Face Spoofing in a Video Selfie Before Submission

The scenario with the lowest barrier to entry: the attacker prepares a video clip in advance and feeds it into the KYC stream instead of a live recording. Preparation takes from a few minutes to half an hour:

1. The source face image is taken from open sources — social networks, leaked databases, darknet marketplaces where photographs and short videos of real people are sold. An alternative is generating a fully synthetic face through StyleGAN-class models; the cost on commercial services is $5–15 per «identity».
2. Using face-swap tools (open-source or commercial), a video is created: the «victim’s» face or a synthetic face is overlaid onto a recording of a real person performing the required actions — head turns, blinking, a smile.
3. The finished video is uploaded into the KYC provider’s application directly through the file-upload interface or by spoofing the camera at the software level.

The scenario targets systems that accept uploaded files without controlling the capture source. If the KYC platform does not verify that the video was recorded by the device’s camera in real time rather than played back from a file, the attack succeeds with high probability. According to Trend Micro, industrial eKYC providers with such an architecture are vulnerable to face-swap attacks carried out with standard, publicly available tools.

Real-Time Face Spoofing by Substituting the Camera Source

A more technically mature vector is video stream injection (an injection attack). The attacker does not show a face to the camera but substitutes the video signal source itself at the software or hardware level. The system «sees» a stream that looks like a capture from a real camera but is actually broadcast from a computer.

A typical attack chain:

— A real-time deepfake generation application (DeepFaceLive-class) is launched on a desktop. The operator sits in front of the PC camera, and the algorithm replaces their face with the target one — matching the photograph in the document.

— The generated stream is routed through a software virtual camera (OBS Virtual Camera and similar) or specialized utilities (Volcam, Swapcam) sold on the darknet and in Telegram channels for prices ranging from $490 to $10,000. These tools embed into mobile devices connected to a PC and substitute the phone’s standard camera input.

— The KYC service’s application is opened on a mobile device or an Android emulator. Instead of the real sensor, it receives the stream from a virtual driver. The attacker follows the instructions of the liveness detection system — turns, blinking, a smile — and the deepfake model transmits these actions with the substituted face.

In December 2025, MITRE ATLAS added this exact scenario to its knowledge base on threats to AI systems. A case study prepared by iProov confirmed it: the combination of open-source face swap → OBS → a virtual camera on Android made it possible to pass a liveness check in a test environment and complete identification under someone else’s name. All the tools used were publicly available and free.

Face Spoofing on a Video Call with an Operator

Video KYC with a live operator is often perceived as a more reliable format: the employee can ask arbitrary questions, change the verification scenario, pay attention to details. New-generation deepfake technologies work here too.

Real-time tools (DeepFaceLive, Magicam, Amigo AI, and others) allow an attacker to change their face, voice, gender, and even race right during a video call. The operator sees on the screen a person who visually matches the photograph in the document, responds to questions, and moves naturally. The deepfake generator processes the fraudster-operator’s facial expressions and transmits them through the video-conferencing platform or client application.

The scale of the threat is illustrated by an early-2024 incident involving the company Arup: a finance employee transferred $25 million after a video call in which all the participants — the «CFO» and «colleagues» — turned out to be deepfakes. This is not a KYC scenario in the pure sense, but it demonstrates the level of realism achievable in a targeted attack on a video call.

In KYC, the situation is aggravated by the fact that the video verification operator works with a stream of unfamiliar faces and has no personal acquaintance with the client. A study by Korshunov and Marcel (2020) showed that people correctly recognize high-quality deepfake videos in only 24.5% of cases. Visual control by an operator is unreliable as a standalone barrier — it must be supplemented by instrumental checks on the platform’s side.

Combining a Deepfake with a Bypass of Passive Liveness Detection

Passive liveness detection analyzes a single frame or a short fragment without active user participation: it assesses skin texture, depth distribution, micro-movements, and the optical properties of the surface. The method is convenient — it requires no gestures or turns. But it is precisely this autonomy that creates a vulnerability: the attacker does not need to respond to the system’s requests in real time; it is enough to prepare a static or weakly dynamic deepfake that will pass frame-by-frame analysis.

The combined attack is built in two steps:

— A high-quality face swap or a fully synthetic face is prepared, optimized to bypass visual metrics: the texture is close to real skin, the lighting corresponds to typical selfie conditions, and artifacts at the boundaries of the face are minimized.

— The video or image is injected into the stream through a virtual camera, driver substitution, or interception of the API call between the application and the server (man-in-the-middle). Passive detection receives input data visually indistinguishable from a real capture and returns a positive decision.

The European technical specification CEN/TS 18099, adopted to complement ISO 30107-3, separately identifies the class of injection-attack detection (IAD) — precisely because a standard PAD check, including a passive one, is not designed for data injection bypassing the physical camera sensor. The forthcoming ISO 25456 standard formalizes procedures for testing resilience to injection attacks at the international level.

The situation is complicated by the speed at which generative models evolve. Deepfake detectors trained on previous-generation artifacts (GAN noise, characteristic distortions around the eyes and teeth, unstable ear geometry) lose accuracy when confronted with deepfakes based on diffusion models — these form the image by a different mathematical path and leave a different «signature».

According to 2024 research, detection models can lose up to 50% of their accuracy when encountering previously unknown generators. Protection built exclusively on passive analysis of a single frame, without controlling the capture source, verifying session integrity, and behavioral signals, creates a false sense of security while the real vulnerability to a targeted attack remains.

Detecting Face Spoofing by Video Content

Any method of face spoofing — face swap via an autoencoder, GAN generation, a diffusion model — leaves traces in the video itself. These traces fall into three groups: spatial artifacts in an individual frame, anomalies in the temporal sequence of frames, and signs of synthesis or re-encoding of the video stream. Combined analysis of all three groups allows a detector to work more reliably than when relying on a single type of signal: a spatial artifact may be masked by high-quality generation but will surface in the temporal or frequency layer — and vice versa.

Signs of Face Spoofing in a Single Frame

In a face swap, the synthesized face is overlaid onto the source frame through a blending operation, and it is precisely the boundary of the merge that gives the first and most robust class of artifacts.

The blending boundary. The generator creates the face separately, then fits it into the original background. At the junction of the two areas — the synthesized and the real one — a blending boundary appears: a difference in texture, sharpness, or color tone that is absent in genuine video. The Face X-ray method (Li et al., CVPR 2020) demonstrated that a forgery can be detected by checking whether the image decomposes into two overlaid sources. The approach generalizes to previously unseen generation techniques, since the blending step is common to most face-swap pipelines.

Mismatch of textures and resolutions. The resolution of the generated face and the resolution of the background rarely match pixel for pixel. The facial area may turn out to be slightly more blurred or, conversely, excessively «clean» — with characteristic oversmoothing of the skin, in which the natural microtexture of pores and fine wrinkles is suppressed. Detectors based on Local Binary Patterns (LBP) and Sobel/Canny filters catch this difference in local texture and contour characteristics between the facial area and the surrounding context.

Geometric and lighting anomalies. The position of the eyes, nose, and mouth after the swap may not agree with the geometry of the skull and the camera angle, especially at extreme head-turn angles. Shadows and highlights on the substituted face are formed by the lighting conditions from the generator’s training set rather than the video-call scene — a mismatched lighting gradient becomes a distinguishing feature. Small high-frequency elements — teeth, the iris, the hairline — pose a separate problem for generators: they often show color outliers, blurry boundaries between teeth, or a «floating» iris.

Color channels. In a natural image, the correlation between the RGB channels obeys the physics of lighting and the properties of the camera. Generative models violate this correlation: spectral analysis of the color differences between channels reveals anomalies hidden from the human eye but accessible to a CNN classifier.

The listed features work more effectively in combination. Modern detectors are built as multi-scale architectures: one branch analyzes the face as a whole (global view), a second focuses on the area around the facial landmarks (local view), and a third accounts for head pose. This reduces dependence on a single type of artifact and increases resilience to unfamiliar generation methods.

Signs of Face Spoofing in Motion

Deepfake generators process video frame by frame: each frame passes through the neural network independently, after which the results are stitched back into the video sequence. Because of this, temporal anomalies appear between adjacent frames that do not occur in genuine recordings.

Facial Feature Drift. The coordinates of the eyes, the tip of the nose, and the corners of the mouth «jump» slightly from frame to frame even with a motionless head — a consequence of the generator’s frame-by-frame independence, which does not guarantee spatial consistency between frames. The effect is especially noticeable in slow-motion playback and is reliably recognized by recurrent networks (GRU, LSTM) that model the sequence of landmarks over time.

Flickering and «pulsation» of texture. Skin texture, the sharpness of the eyebrows, and the shape of shadows on the generated face may vary from frame to frame — temporal flickering. The human eye perceives it as an unnatural «twitching» of the face, while a neural-network detector records it through anomalies in the optical flow and the inter-frame spread of pixel values in the facial area.

Desynchronization of facial expressions and speech. In reenactment attacks, where one person’s facial expressions are transferred onto another’s face, lip articulation may not match the phonemes of speech. Lip-sync detectors analyze the correlation between lip movements and the audio track; a discrepancy above a threshold is a strong indicator of spoofing. In a KYC video call this is critical: the operator asks the person to say a random phrase, and the desynchronization between speech and lip movement becomes a visible signal.

Absence of a physiological pulse (rPPG analysis). Blood flow causes micro-changes in skin color synchronized with the heartbeat. The method of remote photoplethysmography (rPPG) extracts this signal from video by analyzing sub-pixel fluctuations in the brightness of the facial skin. A real face contains a periodic pulse signal with a frequency of 50–90 beats per minute; a deepfake, as a rule, contains no such signal, since generators do not model physiology. Studies (DeepFakesON-Phys, Hernandez-Ortega et al., 2020; FakeCatcher, Ciftci et al., 2020) showed an AUC above 98% when classifying real and fake videos based on rPPG maps. Limitation: high compression and low fps degrade the quality of the rPPG signal, and the newest generators are already experimenting with injecting artificial pulsation — which is why rPPG works more reliably as one of the layers of multimodal analysis rather than as the sole criterion.

Blinking anomalies. Early face-swap models generated faces with unnaturally infrequent or absent blinking. Modern generators reproduce blinking, but its frequency and dynamics may still differ from the norm — especially with low-quality training data on the attacker’s side. Detectors based on the Eye Aspect Ratio (EAR) track the blinking pattern as an additional feature.

Signs of Generation and Re-Encoding of the Video Stream

The third layer of detection goes beyond the content of the frame and facial expressions, analyzing the properties of the video file itself — the frequency spectrum, encoding traces, and metadata.

Category	Description
The generator’s frequency fingerprints	Any neural-network generation passes through upsampling operations (increasing resolution) that leave a characteristic trace in the frequency spectrum. Work by Frank et al. (2020) and Durall et al. (2020) demonstrated that GAN-generated images have specific anomalies in the high-frequency components that are absent in real photographs. The discrete cosine transform (DCT) and the fast Fourier transform (FFT) isolate these patterns and make it possible to build a classifier on them. Each generator architecture — StyleGAN, DeepFaceLab, various diffusion models — leaves its own frequency «fingerprint» (GAN Specific Frequency), which makes it possible not only to detect the forgery but also to attribute it to a specific type of generator.
Double-compression artifacts	The substituted video passes through the chain «decode the source → render the deepfake → re-encode». Each cycle of H.264/H.265 compression introduces its own set of quantization artifacts. Double compression creates a characteristic interference of quantization grids, detectable by analyzing DCT coefficients: the distribution of AC coefficients in doubly compressed video differs statistically from singly compressed video. The feature is robust because the attacker cannot avoid re-encoding — they are forced to reassemble the video stream after embedding the synthesized face.
Inconsistency of stream parameters	A video stream that has passed through a virtual camera or a software render often differs from a «live» capture in a set of parameters: codec profile and level, group-of-pictures (GOP) structure, and chroma subsampling format. If the KYC system records the reference stream parameters for a specific device and compares them against the actual ones, a mismatch indicates injection or software processing. The absence or substitution of EXIF metadata is an additional, though easily forged, indicator.
Spectral roll-off	Real photographs and video frames obey the power-law spectral roll-off: the amplitude of the frequency components decreases with increasing frequency along a predictable curve. GAN-generated images violate this regularity — the high-frequency region turns out to be either impoverished (oversmoothing) or contains periodic peaks (checkerboard artifacts from upsampling layers). Analyzing the shape of the spectral roll-off is a fast and computationally cheap pre-filter that makes it possible to weed out obvious fakes before running heavy models.

Frequency and codec features complement spatial and temporal analysis: they retain their informativeness even after the visual artifacts have become almost indistinguishable to CNNs operating in RGB space. In industrial detection systems, all three layers — frame-by-frame, temporal, and frequency-codec — are combined into a single multi-stream pipeline with score aggregation and a decision made on the basis of the aggregate assessment.

Protecting Video Verification Against Face Spoofing

Detecting a deepfake in a frame is a necessary but insufficient task. An attacker can bypass content detection if they control the delivery channel: substituting the camera, intercepting the video stream, or injecting a synthetic signal before the analysis module. Resilient protection of video verification is built not on a single line but on a chain of controls, each of which works at its own level: capture, transport, analysis, and continuous session validation.

The logic is the same as in information security in general: no single control provides guarantees, but the aggregate of layers makes the cost of a successful attack unacceptably high.

On-Device Capture Control and Protection Against Virtual Cameras

The first and often underestimated line of defense is the guarantee that the video stream originates from the physical camera of a real device rather than from a software emulator or a virtual camera. Injection — substituting the data stream while bypassing the sensor — has become one of the fastest-growing vectors: according to industry reports for 2024–2025, the number of attempts grew dozens of times over compared with 2022–2023, and the availability of the corresponding software sharply lowered the barrier to entry.

For the substitution, attackers use virtual cameras (OBS Virtual Camera and similar), mobile emulators with video-input substitution, interception of the browser API through JavaScript extensions, and hardware capture devices that inject an external video signal in place of the built-in camera.

Countermeasures work at several levels:

On the SDK side. A mobile or web SDK embedded in the customer’s application checks the environment directly on the device. For mobile platforms, this includes OS integrity control (detecting jailbreak/root), verifying that the application is running on a physical device rather than in an emulator, and validating the camera source — the SDK tracks that the video input comes from the hardware sensor rather than from a software proxy. In the web environment, obfuscation of the client code and verification of the video stream’s metadata through WebRTC make substitution harder, although the browser context is objectively harder to control than a native application.

At the level of the cryptographic chain. Modern mobile OSes (iOS and Android) provide cryptographic attestations certifying the authenticity of the device, the integrity of the OS, and the fact that a specific application was launched. The mechanisms rely on hardware security modules (Secure Enclave, TEE) and are practically impervious to software forgery. If the SDK uses attestation, the server side can be sure: the video stream originates from a genuine device with an unmodified OS.

At the level of stream metadata. Server-side analysis of the technical characteristics of the incoming video — resolution, frame rate, color space, EXIF, and codec — makes it possible to identify discrepancies. The declared device model implies a camera with a specific sensor and resolution; if the stream parameters do not match the profile, the system records an anomaly.

None of these controls is absolute on its own. Virtual cameras are improving, emulators are learning to disguise themselves, and in the web environment the attacker controls more variables. Capture control is the first layer that lowers the probability of a successful injection, not the only barrier. Its task is to cut off mass and low-skill attacks, leaving advanced attempts to the next lines.

From a standards standpoint, the European technical specification CEN/TS 18099:2025 was the first to describe a unified methodology for evaluating protection against biometric data injection. At the international level, the ISO/IEC 25456 standard is being prepared on its basis. The presence of an independent evaluation against these specifications is an objective criterion when choosing a vendor, allowing solutions to be compared by a single methodology rather than by marketing claims.

Binding Video to the KYC Session and Verifying Stream Integrity

A session challenge. The server generates a unique, unpredictable request for each session: a sequence of actions (turn the head left, then right, smile), a unique visual marker on the device screen (a changing background color, a dynamic code), or a random set of characters to be pronounced. The video is valid only if the response matches the request of that specific session. A replay attack fails because the previously recorded video contains the response to a different challenge.

Cryptographic session binding. Each fragment of the video stream is signed or bound to the session identifier, a timestamp, and a one-time token (nonce). The server side verifies that the received data corresponds to an open session and was not resubmitted. If the timestamps do not fall within the allowable window (usually a few seconds), the session is rejected.

Transport integrity control. TLS encryption between the client and the server is a basic requirement, but it alone is not enough. Additional measures: signing frames on the SDK side before transmission over the network (end-to-end integrity) and monitoring the continuity of the stream — sharp changes in the frame rate, latency spikes, or gaps between segments may indicate tampering.

Reuse detection. The system maintains a registry of hashes of previously received biometric samples. If a newly received video matches or substantially overlaps with an already registered one, this is a signal of a replay attack. The check is especially important for scenarios where an attacker tries to pass verification multiple times with the same material under different identities.

When properly implemented, session binding renders a pre-prepared video useless: each session requires a unique response in real time, and the cryptographic wrapping rules out data substitution during transmission.

Anti-Spoofing Resilient to Real-Time Deepfakes

Classic anti-spoofing (Presentation Attack Detection, PAD) was originally designed to protect against physical artifacts: printed photographs, screens playing back video, silicone masks. Real-time deepfakes create a fundamentally different challenge — synthetic video is generated instantly, driven by the operator’s facial expressions, and looks like a live person in front of the camera. This requires anti-spoofing capable of working with digital synthetic signals as well.

Pixel-level frame-by-frame analysis. Neural-network models trained on a large volume of real and synthetic data analyze skin texture, microrelief, reflections in the iris, the boundaries of the face, and transition zones (the hairline, the oval of the face, the ears). Deepfakes — even high-quality ones — leave artifacts: texture inhomogeneities at the substitution boundaries, incorrect reflections, the absence of fine details (pores, hairs, shadows from eyelashes). The higher the resolution of the input stream and the more the training set includes current generation techniques, the more reliable the detection.

Analysis of dynamic features. A real human face has characteristic dynamics: micro-movements, natural desynchronization of the blinking of the left and right eyes, physiologically conditioned delays between a command and a movement (between speech and lip articulation). Generative models reproduce these patterns with deviations that a human will not notice but that a specialized neural network will detect through the time series of facial landmarks.

Multimodal signals. Adding information beyond RGB video complicates the task for the attacker. Infrared sensors, 3D cameras (structured light, ToF), and analysis of the audio track (verifying lip synchronization with the voice, spectral analysis of speech) substantially narrow the space for attack. A deepfake convincingly imitates an RGB image, but simultaneously forging RGB, the IR channel, and 3D geometry is an order of magnitude more difficult.

Continuous model updates. Generation technologies develop quickly: new architectures appear (diffusion models, face reenactment via neural radiance fields), and the quality of face swap improves. An anti-spoofing model trained six months ago may fail to recognize an attack using the newest technique. Regular retraining on fresh data, including samples obtained by a «red team» and from real incidents, is a mandatory condition of operation.

Continuous Identity Verification Throughout the Video Session

A typical vulnerability of video verification is the one-time check: the system confirms the identity at the start of the session and then relies on the same person remaining in front of the camera. This is exploited in participant-substitution attacks (session handoff): a real person passes the check, after which someone else takes their place or a deepfake is switched on.

Continuous verification eliminates this gap:

Periodic biometric matching. Throughout the video session, the system extracts a biometric face template at set intervals and matches it against the template obtained during the initial verification. A sharp change in the biometric vector (exceeding the threshold of allowable variability caused by a head turn, a change in lighting, or facial expressions) signals a possible substitution.

Monitoring the continuity of presence. The system tracks that the face is present in the frame without significant interruptions. A prolonged absence of the face, camera obstruction, or the sudden disappearance and appearance of a different face are triggers for an automatic request for re-verification or suspension of the session.

Consistency control of parameters. Throughout the session, the stability of the image parameters is analyzed: lighting, background, camera characteristics. A sharp change in background or lighting while the declared device remains unchanged may indicate a switch of the video source.

Spontaneous repeat challenges. At critical moments of the session (before confirming a transaction, when conditions change), the server may initiate an additional request — a repeat liveness check, a random action, or the pronunciation of a one-time phrase. This prevents the attacker from preparing video material in advance for the entire duration of the session.

For a video call with an operator, continuous verification has an additional dimension. The operator acts as another layer of control: they can ask non-standard questions, request that the document be shown at a different angle, and pay attention to details the automation did not check. Given that a human operator is susceptible to social engineering and fatigue, their decisions are reinforced by continuous automatic monitoring rather than replacing it.

The aggregate of the described layers — capture control, session binding, multimodal anti-spoofing, and continuous validation — forms a system in which each level compensates for the potential gaps of another. It is precisely the defence-in-depth principle that makes it possible to maintain verification resilience as deepfake techniques grow more sophisticated.

Actions When Signs of a Deepfake Are Detected in KYC

Detecting a deepfake is not the end of the process but the start of a managed incident. The difference between a reliable and a vulnerable system is determined not only by the quality of detection but by what happens in the following seconds and minutes: how the system escalates the suspicion, who makes the final decision and by what criteria, and what data is preserved for the investigation.

The response to a suspicion should neither block legitimate users without explanation nor allow the attacker to repeat the attempt until they find a workaround.

Raising the Verification Level and Safe Retries

When automatic detection records signs of face spoofing or video stream injection, a hard rejection without the possibility of a retake creates two problems: a legitimate user caught by a false positive leaves for another service, while a fraudster receives a binary «failed» signal and adjusts the attack.

A more effective approach is graduated escalation (step-up verification): when the suspicion threshold is exceeded, the system automatically raises the requirements for the next attempt rather than simply repeating the same scenario.

If the initial video-selfie check recorded anomalous artifacts, the second attempt may include an active challenge: a randomly generated sequence of actions — turning the head in a specified direction, pronouncing a one-time phrase, interacting with a physical object. Such tasks are hard to reproduce with a pre-recorded deepfake or a low-latency real-time face swap. On a repeat trigger, the system switches the user to a video call with an operator or requests an alternative verification channel.

It is critically important to limit the number of repeat attempts within a single session and tie them to unique identifiers: device fingerprint, IP, document identifier. Without this limit, an attacker can iteratively tune the generation parameters until one of the variants passes the threshold. A typical limit is two or three attempts per session with an increasing cooldown interval.

Another condition — during step-up, the specific reason for the escalation should not be disclosed to the user. The wording «face spoofing detected» tells the attacker which control was triggered. A neutral message («an additional step is required to complete verification») preserves unpredictability for the fraudster and does not alarm the legitimate client.

Routing to Manual Verification and Requirements for the Operator

Not every suspicious case can be resolved automatically. When the session’s score falls into the zone of uncertainty — between a confident «clean» and a confident «fraud» — the optimal route leads to a live operator. The task of manual verification is to make a decision where the algorithm cannot give an unambiguous answer, without increasing the number of false rejections in the process.

Routing must be adaptive. The specific rules depend on the operation’s risk profile: opening an account with a high limit, changing the linked device, an operation in a higher-risk jurisdiction — all of these lower the escalation threshold. For mass low-risk scenarios, the threshold can be higher so as not to overload the manual queue.

A specialist working with a suspected deepfake must possess practical skills in recognizing visual anomalies: unnatural transitions at the boundary of the face and background, desynchronization of lip movement and speech, anomalies in eye glare, static facial expressions when the pose changes. These signs are not always obvious without training — the quality of modern generation tools is high enough to deceive an unprepared observer.

During a video call, the operator applies interactive checks that are hard to imitate with synthetic video: asking the person to bring the document up to their face and smoothly rotate it, to show a side profile, to bring a hand up to their face (generating correct occlusion remains a weak spot for real-time deepfakes). The operator’s interface simultaneously displays the readings of the automatic detectors — the liveness score, the results of the video stream integrity check, the device metadata. The decision is made taking into account the totality of the signals.

Organizationally, the process of manual verification of suspicious sessions is formalized in an internal regulation that fixes the list of mandatory verification actions, the criteria for the final decision (approve / reject / escalate), the maximum time for reviewing a case, and the procedure in the event of technical connection failures. Records of the operator’s decisions, with justification, are preserved for audit and for training the detection models.

Preserving Evidence and Incident Analytics

Every video verification session in which the deepfake-suspicion trigger fired generates data valuable in three contexts at once: compliance reporting, internal investigation, and improvement of the detection models. None of these contexts works with a fragmentary or lost dataset.

The minimum composition of the evidence base: the source video stream (or fragments with sufficient resolution and frame rate), session metadata (device fingerprint, IP address, user-agent, geolocation, event timings), the results of each stage of the automatic check with numerical scores and thresholds, the operator’s decision and justification (if the session was escalated), and the identifier of the presented document.

Retention requirements depend on the jurisdiction and the type of organization. In the Russian context, Federal Law No. 115-FZ requires that information necessary to identify the client be retained for no less than five years from the moment the relationship ends. The FATF Recommendations set a similar benchmark — five to seven years. Under the GDPR, the retention period for biometric data must be justified by the purpose of processing and fixed in the retention policy. Specific requirements should be checked against the current regulations and the regulator’s guidance in the applicable jurisdiction.

The technical integrity of the evidence base is ensured by immutable (append-only) logs with cryptographic hashes or digital signatures. This guarantees that the records were not modified after being recorded — a critically important property when handing over materials to law-enforcement agencies or during a regulatory audit. Systems that support the C2PA standard (Coalition for Content Provenance and Authenticity) additionally record the provenance of the media data, although at present this standard is not a mandatory requirement in any jurisdiction.

The accumulated incident data forms an analytical base for improving protection. Aggregated analysis reveals patterns: which types of deepfakes are used more often, in which time windows attacks concentrate, which devices and sources recur. On the basis of these data, the automatic detection thresholds are calibrated, the step-up verification scenarios are updated, and the instructions for operators are adjusted.

How to Confirm the Effectiveness of Protection in a Pilot and in Production

Any anti-deepfake solution looks reliable in marketing materials. Real protection is confirmed only by a measurable result — on controlled attacks and under real traffic conditions. Without formalized testing, it is impossible to understand which types of spoofing the system rejects and which it lets through, what percentage of false rejections legitimate users will receive, and how quickly the protection becomes obsolete as new generative tools appear.

Verification proceeds in two stages. The first is the pilot: the system is subjected to a set of reproducible attacks in a controlled environment, and the results are recorded using standardized metrics. The second is production monitoring: real bypass attempts, model quality drift, and the emergence of previously unknown spoofing techniques are tracked.

The Set of Test Attacks and Reproduction Conditions

For a pilot to yield meaningful results, a structured set of attacks is needed that covers the main threat vectors.

Presentation attacks — when a forged image is presented to the camera physically: playing back recorded video from a smartphone or monitor screen, showing a printed photo, silicone and latex masks of varying detail, deepfake video played back in front of the camera. The evaluation methodology is described in the ISO/IEC 30107 series of standards: part 1 defines the terminology and taxonomy, part 3 sets the requirements for testing and reporting. For each attack type, the standard introduces the concept of a PAI Species — a class of attack instrument whose results are measured separately.

Injection attacks — when a synthetic video stream is fed in while bypassing the camera: through a virtual camera, an emulator, interception at the driver level, or data substitution in the transmission channel. This vector is the most dangerous for real-time deepfakes, since it makes it possible to bypass the optical signs that classic liveness checks rely on. To evaluate resilience to injection attacks, the European technical specification CEN/TS 18099 was published in 2024, and at the ISO level the ISO/IEC 25456 standard is under development.

Combined scenarios — a combination of a deepfake with additional bypass techniques: substituting the background environment, imitating micro-movements on the operator’s command, using several generative models in a single session. Such attacks model the behavior of a prepared adversary and test the resilience of the entire verification chain.

Reproduction conditions are critically important for the correct interpretation of the results. Each test must record: the software version and threshold configuration, the capture device (model, OS, SDK version), the characteristics of the attacking instrument (source screen resolution, generative-network model, rendering parameters), lighting, and distance. The ISO/IEC 30107-3 standard requires multiple presentations of each PAI instance to reduce the influence of random factors. The same principle applies to injection attacks: reproduction must be repeatable, and the log of each attempt must be available for subsequent audit.

A separate point is the diversity of the subjects’ biometric characteristics. The attacking materials must be created on the basis of faces that differ in gender, age, and phenotype. Without this, the test results may conceal demographic biases: the system passes the check on one set of faces but lets attacks through on another.

Detection Quality Metrics and Target Thresholds

Standardized metrics make it possible to compare solutions against one another and track the dynamics of quality. In the context of anti-deepfake protection for KYC, two basic metrics from ISO/IEC 30107-3 are used:

APCER (Attack Presentation Classification Error Rate) — the share of attacks erroneously accepted as legitimate. It is calculated separately for each PAI Species, which makes it possible to see which attacks the system is most vulnerable to. A low APCER means high security.

BPCER (Bona Fide Presentation Classification Error Rate) — the share of legitimate users erroneously rejected. A high BPCER means that the protection «overplays it» and blocks real people, lowering conversion and creating load on manual verification.

The two metrics are inversely related: tightening the threshold lowers APCER but raises BPCER. To assess overall quality, the DET curve (Detection Error Tradeoff) is used, displaying the full spectrum of trade-offs between security and convenience at different thresholds. An additional metric — ACER (Average Classification Error Rate), the arithmetic mean of APCER and BPCER — is convenient for an initial comparison but does not replace analysis of the full curve.

When evaluating the full system (rather than a standalone PAD module), the standard provides for the metric IAPMR (Impostor Attack Presentation Match Rate) — the share of attacks that not only passed detection but were also matched to the target identity. This metric is closer to the real damage, since it accounts for both lines: liveness and face matching.

Target thresholds depend on the threat model and the business context. For high-risk financial services, the benchmark is an APCER below 1% with a BPCER of no more than 5–10%. In certification testing against ISO/IEC 30107-3 (in accredited laboratories), the BPCER thresholds are set at no higher than 10–15% to pass the test; at the same time, the system must demonstrate a zero or near-zero APCER for the declared attack categories. Pilot thresholds are an internal benchmark rather than a guaranteed indicator for production: the real distribution of attacks, devices, and lighting conditions is broader than in the laboratory.

In the pilot, it is recommended to fix the thresholds in the form of an SLA with the vendor: the allowable APCER for each type of attack from the test set, the allowable BPCER on a sample of legitimate users, and the system’s latency. If the solution does not meet the target thresholds for one or more attack types, this is a point for joint refinement: revising thresholds, adding additional modules, or changing the verification scenario.

Monitoring New Deepfake Techniques and Updating Models

Production monitoring is built on several signals. The first is tracking the distribution of detection scores: if the median or variance of scores on live sessions shifts without visible cause, this may indicate the emergence of a new type of attack or degradation of the model. The second is correlation with the results of manual review: cases sent to an operator and confirmed as fraud but not caught by the automation form a dataset for retraining. The third is external threat monitoring: tracking publications of new generative tools, open repositories for face swapping, and changes in the available frameworks (new modes, faster inference, a lower barrier to entry).

Updating models in a production environment requires an established process rather than one-off patches. An effective practice is a CI/CD pipeline for detection models: new attack samples enter the training set, the model is retrained (fine-tuning or continual learning), passes regression testing on a reference set, and only after confirmation that the old attack types are still detected is it deployed to production. Continuous learning methods (experience replay, knowledge distillation) make it possible to adapt the detector to new techniques without catastrophic forgetting of previously learned patterns.

The frequency of updates depends on the dynamics of the threats. The minimum benchmark is a quarterly revision of the test attack set and validation of the current model on fresh samples. When a new vector capable of bypassing the protection is discovered, the update cycle must be unscheduled — with a clear SLA between the customer and the vendor: within what period the new attack type is added to the set, within what period an updated model is released, and how a rollback is performed in the event of a regression.

When choosing a solution for KYC, it is worth clarifying: whether the vendor provides reports on model updates, which datasets are used for retraining, whether the solution undergoes independent testing (certification in accredited laboratories against ISO/IEC 30107-3 and CEN/TS 18099), and whether there is a documented process for responding to new attack types. A solution without a transparent update history and without external validation creates a hidden risk: the protection may degrade unnoticed, and the fact of a bypass will become obvious only through its consequences — financial losses or incidents with the regulator.