They should treat behavioural analytics as a continuous risk input, not a standalone verdict. Identity verification establishes who the user is, while behaviour and device signals show whether the interaction fits expected patterns. The two together provide a stronger basis for intervention than either one alone.
Identity verification and behavioural analytics solve different parts of the trust problem
identity verification answers a point-in-time question, while behavioural analytics answers a continuous one. In financial services, that distinction matters because onboarding risk, session risk, and post-login abuse are not the same problem. A strong design uses identity proofing to establish an initial trust anchor, then keeps testing whether later actions still fit the same person, device, and context.
That is why the two signals should be combined rather than averaged into a single score. Identity evidence is strongest when the institution needs to decide whether to admit, step up, or reject the user. Behavioural evidence is strongest once the session is underway and patterns begin to drift. The control objective is not perfect certainty, but better decision quality at each stage of the interaction.
How the signals should work together in fraud and access decisions
Behavioural analytics should enrich identity verification, not replace it. If identity checks say the customer is plausibly genuine but the device, typing cadence, navigation path, or transaction pattern looks unusual, the institution should treat that as a reason to step up verification or constrain high-risk actions. If behaviour looks normal but identity evidence is weak, the organisation should not let a familiar session mask a poor proofing outcome.
In practice, this creates a layered control. Identity verification supports enrolment, recovery, account changes, and other high-impact moments. Behavioural analytics supports continuous assessment across logins, transfers, profile edits, and device changes. The most reliable decision is often the one that requires agreement between both channels before the bank allows sensitive activity to continue.
For financial institutions, this also helps reduce false confidence from any single signal. A verified identity does not guarantee legitimate intent, and normal-looking behaviour does not prove the user has rightful access. The combination is most useful when it informs a broader case management flow that can hold, challenge, or monitor rather than forcing an all-or-nothing approval.
Where financial institutions get value, and where they can overreach
The main value comes from using behavioural signals as context for risk-based intervention. That makes the control more adaptive: low-risk interactions can pass with minimal friction, while unusual patterns can trigger stronger checks before money moves or account attributes change. In a financial setting, that is especially important because fraud often begins with valid credentials and then moves into abnormal transaction behaviour.
The danger is overreliance on behavioural analytics as if it were proof of identity. Behavioural models are probabilistic, can drift over time, and can be influenced by device changes, accessibility needs, travel, shared devices, or automated customer behaviour. Institutions should expect the model to support judgment, not to act as the sole arbiter of legitimacy.
Risk and Threat Considerations
When behavioural analytics is used without strong identity verification, attackers can exploit a familiar session, stolen account, or device-trust assumption to move from login to monetisation. When identity verification is used alone, a one-time proofing event can be followed by account takeover, session hijacking, or mule activity that the original check never sees.
Failure mechanism: the institution treats a single proofing event or a single anomaly score as definitive, so it misses the gap between initial identity confidence and ongoing interaction risk.
Impact: that gap can enable fraud, unauthorised transfers, account manipulation, and delayed detection of compromised or coerced users.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Identity proofing and session trust depend on strong authentication assurance. |
| Recommendation — Use V6 to verify authentication strength before allowing sensitive financial actions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authenticated access decisions for users operating financial systems. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Relevant where customers or other external users are verified before access. | |
| IA-12 — Identity Proofing | Directly supports verifying who a customer is during onboarding or recovery. | |
| Recommendation — Apply IA-2 to require strong user authentication before access is granted. Apply IA-8 to authenticate external users before exposing sensitive functions. Apply IA-12 to strengthen identity proofing before account activation or recovery. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Combining identity proofing with ongoing behavioural checks is an access-control design choice. |
| A.8.24 — Use of cryptography | Protects authentication material and identity data used by verification workflows. | |
| Recommendation — Implement A.5.15 to ensure access decisions reflect both identity and current risk. Implement A.8.24 to protect identity evidence and authentication artefacts in transit and at rest. | ||
Practitioner Guidance
What to prioritise: use identity verification to set the entry threshold and behavioural analytics to govern what happens after entry. The control should be strongest at the moments that change funds, access, or account ownership, not just at login.
What to verify: confirm that step-up actions are tied to specific risk events, such as device change, high-value transfer, recovery request, or profile modification. If the response does not change when the signal changes, the integration is only informational.
Decision rule: if identity evidence is weak, do not let “normal” behaviour overrule it; if identity is strong but behaviour shifts sharply, constrain the session and require additional assurance before the action completes.
Practitioner takeaway: the best operating model is a layered one, where identity establishes trust and behaviour continuously tests it, with intervention driven by disagreement between the two.
Related resources from NHI Mgmt Group
- How should financial institutions combine identity verification and fraud controls across the customer lifecycle?
- How should financial institutions implement identity verification for regulated transactions?
- How should financial institutions use behavioural analytics to support CSCRF compliance?
- How should financial institutions evaluate identity verification controls for e-KYC onboarding in regulated markets?