How should security teams handle identity verification across both traditional finance and Web3 environments?

Why This Matters for Security Teams

identity verification in finance is no longer limited to a single perimeter, a single account type, or a single trust model. Traditional banking workflows still depend on KYC, KYB, sanctions screening, and fraud checks, while Web3 systems add wallet-based access, on-chain activity, and pseudonymous counterparties. Security teams that treat these as separate problems create gaps when users move between fiat rails, custodial platforms, and blockchain-native services. Current guidance suggests the identity layer must support both regulatory assurance and transaction-level risk decisions.

This is where identity governance and NHI discipline overlap. Verification is only durable if it can be re-evaluated as context changes, not just accepted once at onboarding. That means mapping identity evidence to policy decisions, preserving traceability, and controlling the credentials and APIs that move verification data between systems. The Ultimate Guide to NHIs shows how weak visibility and over-privilege make this harder in practice, while FATF Recommendations remain the baseline for AML and customer due diligence expectations.

In practice, many security teams discover the identity gap only after fraud, account takeover, or a compliance review has already exposed inconsistent verification paths.

How It Works in Practice

The strongest pattern is a unified identity orchestration layer that ingests evidence from both finance and Web3 sources, then applies consistent policy to each transaction or account event. That layer should not assume one authoritative identifier. Instead, it should correlate legal identity, business identity, device and session signals, wallet ownership proofs, and behavioural risk indicators into a single decision record.

For traditional finance, this usually means KYC and KYB checks, sanctions and watchlist screening, and ongoing monitoring aligned to eIDAS 2.0 and local regulatory obligations. For Web3, teams often add wallet linking, proof-of-control challenges, transaction graph analysis, and risk scoring on counterparties. The point is not to replace identity proof with wallet ownership. It is to bind them together so that a verified user, a verified business, and a verified wallet remain linked under policy.

Operationally, this works best when verification services are treated as sensitive workloads with tightly controlled NHIs. Secrets, API keys, and service accounts that pull screening data or push status updates should be rotated, monitored, and scoped narrowly, because compromised integration accounts can undermine both compliance and fraud controls. NIST control families around identification, authentication, and audit logging are helpful here, especially NIST SP 800-53 Rev 5 Security and Privacy Controls. NHIMG research also notes that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which is a direct warning for identity pipelines that rely on machine-to-machine trust.

• Use one verification policy engine for both custodial and blockchain-facing workflows.
• Re-check identity risk at onboarding, login, withdrawal, contract interaction, and recovery events.
• Keep evidence, decisions, and exceptions auditable across legal, compliance, and security teams.
• Limit the blast radius of screening APIs, wallet linking services, and case-management automations.

These controls tend to break down when identity evidence is siloed by jurisdiction or when wallet activity is ingested without a stable link to the verified legal entity.

Common Variations and Edge Cases

Tighter identity controls often increase friction, requiring organisations to balance fraud prevention and regulatory assurance against user experience and conversion loss. That tradeoff is especially visible in Web3, where excessive gating can break legitimate participation, but weak verification can expose exchanges, custodians, and DeFi front ends to sanctions, scams, and laundering risk.

Best practice is evolving for wallet-native identity claims. There is no universal standard for this yet, so some environments use reusable attestations, while others rely on session-based proofs or risk-based step-up checks. Security teams should be cautious about assuming that a wallet address alone is a durable identity. In many cases, it is only one signal among many, and it can change hands or be bridged through services that obscure provenance. That is why NHIMG’s broader NHI guidance on visibility and lifecycle control remains relevant, including the Top 10 NHI Issues and the 52 NHI Breaches Analysis.

Edge cases also appear in cross-border operations, delegated custody, and account recovery. Joint ventures may need KYB on the business plus KYC on controlling persons, while custodians may need to preserve user control without losing AML visibility. Security teams should document where verification is authoritative, where it is advisory, and where human review is mandatory. In high-risk flows, the safest approach is continuous verification with short-lived trust, not a one-time identity check.

Related resources from NHI Mgmt Group

• How should security teams handle identity verification on shared devices in frontline environments?
• How should security teams unify identity across cloud and data center environments?
• How should security teams handle identity risk across AWS and Azure?
• How should security teams govern workload identity across mixed cloud environments?