Banks should stop treating liveness as a universal challenge-and-response step and instead align verification strength to applicant risk. Use low-friction capture where confidence is high, then escalate only when device, behavioural, or fraud signals justify it. That approach protects conversion without turning identity proofing into an obstacle course.
Why This Matters for Security Teams
For banks, liveness is not just a fraud-control problem. It is a conversion control, an accessibility issue, and a trust signal in one workflow. The mistake is to force every applicant through the same high-friction challenge, even when device integrity, behavioural patterns, and transaction context already support a lower-risk decision. That usually increases abandonment without materially improving assurance.
Current guidance suggests aligning identity proofing strength to risk, not to a fixed ceremony. That means banks should treat liveness as one input in a broader fraud decision, alongside device reputation, velocity, document quality, and step-up signals. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control discipline for doing this consistently, while NHI Management Group’s Ultimate Guide to NHIs shows why overlong, static credential assumptions fail when identities and access paths become operationally complex. In the market, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that rigid screening is not the same as resilient assurance.
In practice, many security teams encounter conversion loss only after onboarding drop-off has already been normalised as “expected friction,” rather than through intentional customer journey design.
How It Works in Practice
The practical model is adaptive liveness orchestration. Start with the lowest-friction verification path that still meets the bank’s risk appetite, then escalate only when signals justify added scrutiny. This is less about “weaker” controls and more about deciding when stronger control is actually necessary.
A workable sequence usually looks like this:
- Capture baseline signals early, including device integrity, session behaviour, IP or location anomalies, and document authenticity.
- Use passive or low-friction liveness when confidence is high, especially for low-risk accounts or returning applicants.
- Step up to active liveness, additional document checks, or manual review when signals indicate spoofing, synthetic identity risk, or mule-account patterns.
- Bind decisions to policy, not intuition, so the same case path is reproducible for audit and model governance.
- Continuously tune thresholds against false-accept and false-reject rates, with conversion metrics tracked alongside fraud losses.
This pattern aligns well with risk-based identity proofing concepts in the NIST SP 800-53 Rev 5 Security and Privacy Controls and with the broader risk and governance posture described in the Ultimate Guide to NHIs, especially where identities, access signals, and lifecycle events need consistent decisioning. For banking use cases, FATF Recommendations — AML and KYC Framework can also inform how much evidence is reasonable before account opening.
Operationally, the bank should treat failed or uncertain liveness as a branch in the workflow, not as an automatic denial. A retry, different capture mode, or a higher-assurance step-up may preserve legitimate conversion while still blocking fraudulent attempts. These controls tend to break down when risk scoring is disconnected from the onboarding channel, because call-center, mobile, and broker-assisted journeys generate different fraud patterns and failure rates.
Common Variations and Edge Cases
Tighter liveness controls often increase abandonment, so organisations have to balance fraud reduction against completion rate, accessibility, and support cost. There is no universal standard for this yet, and best practice is still evolving.
In branch-assisted onboarding, some banks can afford stronger checks because staff can recover failed sessions. In fully digital onboarding, however, a single failed liveness event may end the journey entirely. That makes threshold design and retry policy especially important. For higher-risk products, current guidance suggests accepting some friction to reduce impersonation and account mule risk; for lower-risk products, over-validating every applicant can create unnecessary drop-off.
Another edge case is when legitimate users struggle with camera quality, lighting, assistive technology, or time pressure. In those environments, passive signals and step-up paths are often better than forcing repeated challenge-response loops. Banks should also be careful not to let fraud models become proxy gates for demographics or device classes, since that creates compliance and fairness concerns. The question is not whether to use liveness, but when to use it and how to fail safely. NHI Management Group’s Ultimate Guide to NHIs reinforces the broader point: assurance that cannot adapt to context tends to break under real operational load.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Adaptive onboarding depends on identity assurance matched to risk and context. |
| NIST SP 800-63 | IAL2 | Bank onboarding maps directly to identity proofing assurance levels and evidence strength. |
| NIST AI RMF | Risk-based decisions need governance, measurability, and human oversight. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static identity checks fail when attackers reuse compromised credentials and sessions. |
| OWASP Agentic AI Top 10 | Context-aware authorization principles support runtime decisions over fixed rules. |
Use risk-based identity assurance so liveness steps scale with the applicant’s threat profile.
