How should financial services teams think about inclusion and identity proofing?

Inclusion Is a Proofing Design Choice, Not a Trade-off Between Rigour and Access

For financial services, identity proofing should be judged by whether it can establish enough confidence for the transaction while still working for real customers who do not fit a narrow legacy profile. The right question is not “how strict can we make it?” but “what evidence is sufficient, proportionate, and reachable for the people we need to serve?”

That matters because proofing often becomes exclusionary when it relies too heavily on a single document path, one device pattern, or an assumption that every applicant has the same history, address stability, or credit footprint. A better design uses multiple acceptable evidence paths, each mapped to the same assurance target.

One practical reference point is NIST SP 800-63 Digital Identity Guidelines, which frames assurance as a question of confidence level rather than a single verification method. The underlying lesson is that inclusion improves when teams separate the assurance goal from the specific evidence source.

Why Legacy Identity Assumptions Create Unnecessary Friction

Many onboarding and recovery flows still assume a stable paper trail, a long address history, or an existing relationship with another regulated provider. Those assumptions can fail legitimate users such as younger customers, recent migrants, people rebuilding after a name change, or customers with thin-file histories.

When proofing is too dependent on legacy history, the control shifts from “verify the person” to “verify the person the institution already expects to see.” That is a weak design pattern because it conflates familiarity with assurance. It can also push higher-risk customers into manual review queues, where delay becomes a form of operational exclusion.

For financial services teams, the inclusion test should be whether the proofing method recognises a broader set of acceptable signals without weakening the transaction standard. The strongest programmes treat flexibility as a controlled verification architecture, not as an exception process.

A useful policy and onboarding companion is FATF Recommendations - AML and KYC Framework, because customer due diligence has to support reliable onboarding without creating a one-path-only model for identity collection.

Building Verification Paths That Broaden Access Without Lowering Confidence

Inclusive proofing usually works best when teams combine multiple independent signals rather than overloading one signal with too much meaning. Document checks, device and liveness checks, knowledge or possession checks, trusted reference data, and guided remediation can each contribute to the overall decision when used carefully.

The important practitioner judgement is to define which combinations are acceptable for which risk tier. Low-friction methods may be fine for lower-risk actions, while higher-value transactions may need stronger evidence, step-up verification, or a different channel. That is how you broaden access while preserving confidence in the transaction.

For teams modernising their onboarding and verification stack, Identity Proofing and KYC Guide is a natural internal reference for assurance levels, document and liveness checks, and synthetic identity risk. The broader point is that inclusion improves when each method is evaluated for what it proves, not for how familiar it feels.

Risk and Threat Considerations

Proofing models that are designed to be inclusive can still fail if they accept weak evidence, over-trust one channel, or make manual exceptions too easy to game. The main threat is not inclusion itself, but the pressure to compensate for exclusionary design by lowering assurance in ways that increase account-opening fraud, synthetic identity abuse, or impersonation risk.

Failure mechanism: A narrow proofing model creates a large population of users who cannot clear the standard path, while an over-flexible model creates openings for fraudsters to exploit relaxed review, recycled documents, or manipulated verification signals. The problem gets worse when the institution cannot tell which fallback path was used and why it was accepted.

Impact: Legitimate customers are denied access or pushed into costly manual review, while attackers gain a route to open accounts or bypass controls under the cover of “accessibility.” Over time, the organisation inherits both higher fraud exposure and poorer customer experience.

Where this becomes especially important in financial services is at onboarding, account recovery, and exception handling. Those are the places where a proofing decision can quietly become a durable identity-risk decision.

Practitioner Guidance

What to prioritise: Define proofing outcomes by required assurance level, then allow more than one evidence path to satisfy that level. If a path only works for customers with a long legacy history, it is not inclusive enough for a modern customer base.

What to verify: Check that fallback flows preserve auditability. A reviewer should be able to see which evidence was used, why it was accepted, and whether the decision met the same risk threshold as the standard path.

Decision rule: If a verification method expands access but reduces traceability, treat it as a risk control problem, not just a UX improvement. If it expands access and preserves decision quality, it is a stronger candidate for production use.

Practitioner takeaway: The goal is not to make proofing easy for everyone, it is to make it reachable for more legitimate users without turning identity confidence into a guess.

Related resources from NHI Mgmt Group

• How should security teams think about the gap between authentication and identity proofing in SSO workflows?
• What do security teams get wrong about identity-led personalisation in financial services?
• How should organisations think about the relationship between identity protection and fraud prevention in healthcare and financial services?
• What do financial services teams get wrong about SHAP and LIME?