Identity Verification Protocols Guide: Everything Enterprises NeedSlug: /identity-verification-protocols

In the InterPol global financial fraud threat assessment, global losses related to financial fraud have been estimated at USD 442 billion.  For compliance and risk teams in regulated industries, that figure raises one direct question. Are the identity verification protocols currently in place calibrated to match the threat, or are they a collection of methods with no clear mapping to risk?

This guide covers the three major protocol frameworks enterprises draw on, what each one requires, and how to build a risk-based approach that holds under regulatory scrutiny. If your team is working through NIST 800-63, FATF enhanced due diligence requirements, or an eIDAS 2.0 readiness timeline, this is the practical starting point.

What is an identity verification protocol?

An identity verification protocol is a defined ruleset specifying what evidence an organisation accepts, how it validates that evidence, and what assurance level the check must reach before a user can proceed. A verification method, such as a document scan or a biometric check, is one component of a broader protocol. A single enterprise typically runs multiple protocols in parallel, each calibrated to a different customer risk tier.

The three protocol frameworks enterprises rely on

Most regulated enterprises draw their requirements from three overlapping standards, specifically NIST 800-63, FATF’s risk-based customer due diligence tiers, and eIDAS 2.0. These frameworks address digital identity verification from different angles, but their requirements converge at higher assurance levels.

NIST 800-63 and identity assurance levels

NIST SP 800-63A defines three Identity Assurance Levels.

IAL1 permits remote, self-asserted identity with basic evidence validation and optional biometrics. IAL2 raises the standard. Evidence must be validated against an authoritative source, and the applicant must be bound to that evidence through biometric comparison or postal confirmation. IAL3 mandates physical presence, on-site attended proofing, and biometric sample collection by a trained proofing agent, reserved for the highest-assurance scenarios.

For financial services and fintech onboarding, IAL2 is the standard operational baseline. High-risk events such as account recovery, large-value transfers, or access to restricted assets typically call for IAL3-equivalent controls, even when local regulators do not use NIST terminology directly.

FATF risk-tiered verification requirements

The FATF Recommendations require a risk-based approach to customer due diligence. Standard CDD covers identity confirmation using reliable documents or data. Enhanced Due Diligence (EDD) applies when the customer or transaction presents elevated risk, including politically exposed persons, high-value cross-border payments, non-face-to-face onboarding in high-risk jurisdictions, and complex ownership structures.

EDD requirements go beyond confirming that someone is who they claim to be. The protocol must verify source of funds, beneficial ownership down to the UBO level, and political exposure, and it requires ongoing monitoring throughout the customer relationship. In the US, the FinCEN CDD Final Rule codifies these obligations, mandating identity verification of natural persons holding 25% or more ownership in any legal entity customer.

eIDAS 2.0 and the shift to digital identity credentials

European enterprises face a hard compliance deadline. By December 2027, businesses in banking, energy, health, education, and telecoms must accept EU Digital Identity Wallets when users present them, per eIDAS 2.0. All 27 member states are required to have wallets available to citizens by December 2026.

For identity verification teams, this creates an immediate protocol planning requirement. The EUDI Wallet qualifies as “SUPERIOR” evidence under NIST’s framework, meaning it is cryptographically verifiable, issuer-signed, and tamper-evident. Systems that accept it must interrogate digital security features directly, not simply compare a photographed document.

Enterprises currently running document-upload-only verification for European users face the greatest readiness gap. A workflow that handles passports and driving licences in 2026 will need to absorb wallet-based credential presentation by 2027. Those that have already deployed electronic identity verification through national database schemes, such as BankID, MitID, and Singpass, are better positioned to absorb this change without rebuilding from scratch.

How to build a risk-based identity verification protocol framework

A risk-based protocol framework assigns each customer segment to the right assurance tier before any verification runs. This differs from applying a single standard flow to every user.

Mapping customer risk to the right assurance level

The framework works with at least three customer risk tiers. Standard customers with low transaction volumes and no red flags can proceed through IAL1-equivalent verification with basic document validation. Elevated-risk customers, specifically those in restricted industries, transacting above defined thresholds, or originating from high-risk jurisdictions, need IAL2 controls, including cross-source attribute validation and biometric binding. High-risk customers, including PEPs and those with complex UBO structures, require full EDD-level protocol with documented evidence trails and ongoing transaction monitoring.

The FATF guidance on digital identity explicitly supports this tiered approach, confirming that a well-designed digital identity system can satisfy AML/CFT assurance requirements when the verification method maps correctly to the risk outcome.

Protocol customisation without a development team

A common concern when moving to a risk-tiered model is engineering cost. Three separate verification flows for three risk tiers historically meant three separate integrations. Modern no-code verification workflow tools let compliance teams configure protocol logic for each risk tier, covering document requirements, biometric thresholds, eID scheme acceptance, and step-up triggers, without changing the underlying API. Risk tier assignments update in real time as customer profiles change, so a standard customer who crosses a transaction threshold automatically triggers the elevated protocol.

What enterprises get wrong when selecting identity verification protocols

The most common mistake is treating “verification method” and “verification protocol” as the same thing. A biometric check is a method. The protocol defines when that check is required, what assurance standard it must meet, and what happens when verification fails.

A second frequent gap is treating the initial onboarding check as the complete protocol. FATF and FinCEN’s CDD rules both require ongoing monitoring after onboarding, not just a one-time identity confirmation. An enterprise with thorough entry controls but no post-onboarding review process has a structural gap in its protocol.

Enterprises entering the EU market also underestimate the eIDAS 2.0 readiness timeline. December 2027 is the compliance deadline, but wallet interoperability testing, technical integration, and staff training all need lead time. A review of how eIDAS 2.0 is reshaping identity verification for European financial institutions now avoids a compliance sprint under pressure later.

Protocol mismatches, and inconsistent application of identity verification protocols across customer risk tiers, are among the most direct routes to regulatory exposure for enterprises in financial services, fintech, and gaming. Shufti covers the full protocol spectrum, from IAL1-equivalent passive database checks and biometric verification to 30+ national eID schemes for eIDAS 2.0 compliance, all configurable by risk tier through a no-code interface. Request a demo to map your customer segments to the right verification protocol and see the full flow on your own use cases.

Frequently asked questions

What is an identity verification protocol?

A defined ruleset specifying what evidence an organisation accepts, how that evidence is validated, and what assurance level a check must reach before granting access. Most enterprises run multiple protocols simultaneously, each mapped to a different customer risk tier.

What is the NIST 800-63 standard for identity verification protocols?

NIST SP 800-63A defines three Identity Assurance Levels (IAL1, IAL2, IAL3) with progressively stricter evidence, validation, and verification requirements, from basic remote proofing at IAL1 to on-site attended proofing with biometric collection at IAL3.

What is the difference between IAL1, IAL2, and IAL3 identity verification?

IAL1 requires one piece of evidence with basic validation and no mandatory biometrics. IAL2 demands stronger evidence, cross-source validation, and applicant binding through biometrics or postal confirmation, and can be completed remotely. IAL3 requires physical presence and biometric sample collection by a trained agent.

What identity verification protocol is required for high-risk financial transactions?

FATF’s Enhanced Due Diligence requirements apply, covering source of funds verification, UBO confirmation, political exposure screening, and ongoing monitoring. In the US, the FinCEN CDD Final Rule mandates identity verification of any individual holding 25% or more ownership in a legal entity.

Can identity verification protocols be customized per customer risk level without coding?

Yes. No-code verification workflow platforms let compliance teams configure document requirements, biometric thresholds, eID acceptance rules, and step-up triggers for each risk tier, with real-time updates as customer risk profiles change.