A selfie on its own does not prove there is a real person behind it. It only proves that an image was submitted. In many onboarding flows today, that distinction is still treated as enough.

Attackers take advantage of this gap. They do not need to break your system. They only need to pass through it using inputs that look valid at a glance. A printed photo, a replayed video, or a generated face can move through KYC if there is no mechanism to confirm presence.

This is where most fintech teams run into problems. Verification appears complete, but the identity behind it is not real. This article breaks down how fake selfies are used to bypass KYC, what liveness detection actually does, and how to implement it in a way that improves security without slowing down onboarding.

What Liveness Detection Actually Does

Liveness detection answers a simple question. Is there a real, present human behind the camera at the time of verification?

Instead of accepting a static image, liveness checks evaluate signals that indicate human presence. This includes facial movement, depth, light reflection, and how the face interacts with the camera during capture.

In practice, this changes how your system makes decisions. You are no longer asking, “Does this face match the ID?” You are also asking, “Was this face captured live right now?”

That second question is what stops most spoofing attempts early.

It is also important to place this correctly in your flow. Liveness does not replace identity verification. It strengthens it at the exact point where users prove they are physically present. Without it, your system assumes every image is real. With it, you begin to validate how that image is produced before accepting it.

Passive vs Active Liveness and the Impact on UX

Not all liveness checks work the same way. The approach you choose directly affects both fraud prevention and user experience.

1. Passive liveness

Passive liveness runs in the background during a normal selfie capture. The user does not need to follow instructions or perform actions. The system analyses signals like texture, depth, and natural movement without interrupting the flow.

This keeps onboarding fast and smooth. It works well in mobile-first environments where users expect quick verification. The limitation is that, on its own, it may not be strong enough against more advanced spoofing attempts.

2. Active liveness

Active liveness requires the user to do something specific. This could be turning their head, blinking, or following on-screen prompts. These actions confirm that the person is physically present and interacting in real time.

In practice, most fintech teams combine both approaches. Passive liveness handles the majority of users with no friction. Active liveness is triggered when risk increases.

This allows you to keep onboarding simple for legitimate users while still controlling for higher-risk scenarios. 

Why Selfies Alone Fail Against Modern Fraud

A standard selfie check assumes that what the camera sees is genuine. That assumption no longer holds.

Attackers now use tools that can generate or manipulate facial inputs in ways that look realistic enough to pass basic verification. In many onboarding systems, the only check is whether the face matches the ID. There is no validation of how that face is being presented.

In practice, this creates a gap:

• A fraudster can submit a printed image of a stolen identity and pass face match checks
• A recorded video of a real user can be replayed during onboarding
• AI-generated faces can be used to create entirely synthetic identities

As long as the visual match is close enough, the system accepts it.

This is why photos and videos alone are no longer reliable. The problem is not image quality. It is the lack of validation around whether the input is live or injected.

Common Spoofing Methods Fintechs Need to Account For

To implement liveness properly, you need to understand how attacks actually show up in your flow. Most spoofing methods follow a few consistent patterns.

1. Photo replay attacks

The attacker presents a printed or digital image of a real person to the camera. In weaker systems, this can pass as a valid selfie because there is no depth or presence check.

2. Video replay attacks

A recorded video of a real user is played during verification. Because there is movement, basic motion checks may still pass, making this harder to detect without stronger liveness signals.

3. Deepfake and synthetic faces

AI-generated faces or manipulated videos are used to create realistic but fake identities. These can mimic natural expressions and are becoming more accessible.

4. Emulator and injection attacks

Instead of using a camera, the attacker feeds pre-recorded or generated content directly into the verification flow. From your system’s perspective, it appears as if the input is coming from a real device.

All of these methods exploit the same weakness. They rely on systems that accept visual input without validating how that input was created.

This is why liveness detection needs to evaluate both the face and the capture environment, not just the image itself.

How to Implement Liveness Without Adding Friction

A common concern is that liveness detection will slow down onboarding or increase drop-offs. This usually happens when it is applied as a fixed step for every user.

A better approach is to apply liveness dynamically based on risk.

1. Start with passive liveness as the default

Let most users complete verification without interruptions. This keeps the flow fast and aligned with user expectations.

2. Introduce step-up checks when risk increases

Trigger active liveness when certain signals appear, such as:

• A new device with no history
• Unusual session patterns or repeated failed attempts
• Inconsistent location data

This ensures that additional friction is only applied when needed.

3. Optimise for mobile conditions

Most onboarding happens on mobile devices, often under varying network conditions. Liveness checks should be lightweight, fast, and able to handle different camera qualities.

4. Provide clear user feedback

If a check fails, the user should understand why and what to do next. Clear guidance reduces abandonment and helps legitimate users complete verification.

When implemented this way, liveness does not slow users down. It adds control exactly where it matters.

What to Look for in a Liveness Detection API

Choosing a liveness detection API should be based on how it performs in real-world conditions, not just technical specifications.

1. Real-time speed

Verification should happen instantly or within seconds. Delays increase drop-offs and affect onboarding completion.

2. Detection accuracy

The system should correctly identify spoofing attempts without blocking legitimate users. High false positives create friction and operational overhead.

3. Device and environment compatibility

Your users will be on different devices and in different network conditions. The API should perform consistently without requiring high-end hardware.

4. Coverage across attack types

It should detect photo replays, video replays, deepfakes, and injection attempts, not just basic spoofing.

5. Easy integration

The API should fit into your onboarding flow without requiring major infrastructure changes.

6. Actionable outputs

Beyond detection, the API should return signals you can act on. This allows you to approve, step up, or block sessions based on risk.

The goal is not just to detect fraud, but to make decisions quickly and confidently.

Where Liveness Fits in Your Onboarding Flow

Liveness detection works best when it is integrated into your identity verification flow, not added as a separate step.

A typical onboarding sequence looks like this:

1. Document capture
The user submits a valid ID.

2. Selfie capture with liveness checks
Liveness runs during capture to confirm the presence of a real person.

3. Face match
The captured face is matched against the ID.

This sequence ensures three things:

• The document is valid
• The face matches the document
• The person presenting that face is physically present

When combined, these checks close the gap that attackers rely on.

Liveness can also be applied beyond onboarding. It is useful during high-risk actions like password resets, device changes, or large transactions. This extends protection across the full user lifecycle.

How Dojah Helps Prevent Fake Selfies in KYC

Fake selfies are no longer a minor edge case. They are a direct entry point into your platform when liveness is missing.

If your onboarding flow accepts images without validating presence, it creates a gap that attackers can exploit using tools that are now widely available and easy to use. What looks like a completed verification can still result in a compromised account.

Liveness detection closes that gap by shifting verification from static inputs to real-time validation. It ensures that a real user is present at the point of verification and stops spoofing attempts before access is granted.

Dojah helps you implement this in a way that works in real onboarding environments.

With Dojah’s Liveness Check, you can:

• Detect spoofing attempts in real time during selfie capture
• Identify photo replays, video replays, and synthetic or AI-generated faces
• Run liveness checks seamlessly in mobile-first environments
• Maintain fast onboarding speeds without adding unnecessary friction

Dojah is built as an identity infrastructure for fintechs that need to verify users reliably at scale. It helps you move beyond basic selfie checks and introduce real-time controls that reduce fraud while keeping onboarding smooth.

If you are looking to strengthen your KYC flow, the next step is to see how this works in practice. 

See how Dojah’s liveness detection works and how it can help you prevent spoofing during onboarding.