Both. Liveness sits at the point where identity proofing meets fraud resistance, because it decides whether the system is interacting with a real human or an artefact. In practice, that means identity and fraud teams should jointly define assurance thresholds, escalation paths, and controls for remote transactions.
How liveness fits between identity proofing and fraud prevention
Liveness is a control decision about whether the person in front of the camera, device, or session is a real, present human and not a replay, mask, injection, deepfake, or other artefact. That makes it relevant to both identity proofing, which asks “who is this?”, and fraud prevention, which asks “is this interaction trustworthy enough to proceed?”
In a financial flow, the same liveness signal can support account opening, step-up verification, recovery, payment approval, or suspicious-session review. The key point is that liveness does not belong cleanly to one team, because its value depends on whether the business is using it to raise assurance, block abuse, or both.
What changes when liveness is treated as shared control
When teams treat liveness as a shared control, they avoid the common failure mode of one group setting the biometric bar while another group assumes the fraud stack will absorb every exception. A good design makes the assurance threshold explicit, then defines what happens when liveness is weak, ambiguous, or bypassed by fallback paths.
That shared view also clarifies ownership. Identity teams usually own the proofing standard, the acceptable evidence, and the enrollment journey, while fraud teams own behavioural signals, anomaly scoring, device context, and post-event investigation. Identity proofing and KYC guidance is useful here because it frames liveness as part of assurance, not as a standalone biometric feature.
For financial firms, the most important practical question is not whether liveness exists, but whether the control is calibrated to the transaction class. A low-value login may tolerate a different threshold than high-risk onboarding, beneficiary change, or instant payment authorisation. The same control can be appropriate in both domains, but the decision rule should change with risk.
How to calibrate liveness for real-world financial abuse
Liveness works best when it is paired with a broader fraud model rather than treated as a yes or no gate. Presentation attacks, virtual cameras, injected video, synthetic faces, and replayed selfies are not the only concern; organised fraud often combines weak liveness with device abuse, account takeover, mule behaviour, or social engineering.
That is why financial teams should treat failed or borderline liveness as an input to escalation, not always as a hard block. In some cases the right response is step-up verification, in others manual review, and in others outright decline. Identity fraud prevention guidance helps connect liveness outcomes to downstream fraud signals instead of isolating them as a biometric-only problem.
Liveness also interacts with operational thresholds. If the threshold is too strict, legitimate users will fail and the business will push them into fallback channels that are often weaker. If it is too loose, the control becomes a theatre layer that admits synthetic or replayed identities. The right answer is usually a risk-based tiering model, not a single universal setting.
Risk and Threat Considerations
Liveness controls are attractive to attackers because they sit close to trust decisions and can be attacked with increasingly realistic artefacts, including deepfakes, injected streams, and stolen enrolment data. The risk is not only false acceptance, but also silent degradation, where a control appears to work while fraud adapts around it.
Failure mechanism: Weak liveness can let synthetic or replayed interactions pass proofing, while overly rigid liveness can create user drop-off and push customers into weaker recovery paths that fraudsters exploit.
Impact: The organisation can suffer account opening fraud, account takeover, payment abuse, higher manual review costs, and inconsistent assurance across channels or customer segments. In financial workflows, that can translate directly into losses and control exceptions that are hard to explain after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Covers customer-facing identity proofing and verification for external users. |
| IA-12 — Identity Proofing | Directly addresses remote identity proofing assurance, including biometric evidence. | |
| Recommendation — Apply IA-8 to require stronger proofing and liveness checks for non-organizational users. Use IA-12 to set assurance thresholds and evidence requirements for proofing journeys. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance levels and identity proofing practices that frame liveness decisions. |
| Recommendation — Map liveness thresholds to the required identity assurance level for each transaction. | ||
| OWASP ASVS | V6 — Authentication | Liveness affects how authentication flows resist impersonation and replay in applications. |
| V16 — Security Logging and Error Handling | Failed or borderline liveness events should be logged and reviewable for fraud analysis. | |
| Recommendation — Include liveness outcomes in authentication risk decisions and step-up logic. Log liveness failures and exception paths so fraud teams can investigate patterns. | ||
Practitioner Guidance
What to prioritise: Define which journeys require proofing-grade liveness and which require fraud-screening-grade liveness. Those are related but not identical controls, and the business should not assume one threshold fits onboarding, recovery, and transaction approval.
What to verify: Make sure fallback paths are at least as well governed as the main liveness path. A strong biometric front end is undermined if a failed check can be bypassed through weak help desk recovery, loose exception handling, or undocumented manual override.
Decision rule: If liveness is being used to approve a high-impact financial action, require a documented escalation path that combines biometric outcome, transaction risk, and fraud context before approval. If the control only informs triage, keep the decision reversible and measurable.
Practitioner takeaway: Treat liveness as a shared assurance signal with different operating thresholds, not as an ownership dispute between teams. The control is most effective when identity and fraud functions agree on what a failure means, who reviews it, and when the business should stop the transaction.
Related resources from NHI Mgmt Group
- Should identity teams treat proofing as part of access governance?
- How should revenue and identity teams improve forecasting accuracy when fraud prevention is part of the sales motion?
- How should identity teams balance fraud prevention with digital inclusion when biometrics are part of the onboarding flow?
- How do IAM and fraud teams work better together on identity proofing?