Identity Proofing and KYC Guide: Verifying People Before You Trust Them

Identity proofing decides whether an account ever belongs to a real, correctly identified person. Every later control assumes it went right. Authentication proves it is the same person who enrolled, access control decides what that person may do, and recovery restores access to them. If an impostor or a synthetic identity passed proofing, all of those controls faithfully protect the wrong person. Remote onboarding, generative AI and industrial-scale fraud have made this first step one of the most attacked points in identity. This guide explains what identity proofing is and how it differs from authentication and KYC. It covers assurance levels, how a modern proofing pipeline works, the threats it faces, how to tell when it is failing, and how to hand a proofed identity over safely to customer identity and access management.

Key takeaways

• Proofing, authentication and KYC are different things. Proofing establishes who someone is once. Authentication confirms it is the same person later. KYC is the regulatory obligation that often requires proofing but does not by itself make it secure.
• Choose an identity assurance level from the harm a wrong decision would cause, not from what the onboarding flow can tolerate.
• Remote proofing now has to defeat deepfake selfies, camera injection, forged documents and synthetic identities. Presentation attack detection alone is no longer enough.
• Measure proofing by what happens after account opening: early-life fraud, linked-attribute clusters and mule behaviour show failures that pass rates hide.
• Bind the proofed identity to phishing-resistant authenticators at enrolment, and re-proof rather than weaken checks at account recovery.

What identity proofing is, and what it is not

Identity proofing collects evidence about a claimed identity, checks that the evidence is genuine, and confirms that the person presenting it is the person it describes. It happens at enrolment and again when an organisation needs to re-establish trust, for example after a lost account. It is often confused with two neighbouring processes.

In the identity lifecycle, proofing comes first, enrolment binds the proofed identity to authenticators, and authentication and recovery follow. The Customer IAM (CIAM) Guide covers what happens after the account exists. This guide covers the step before it.

Identity assurance levels

Assurance levels express how confident a relying party can be that an applicant is who they claim to be. NIST SP 800-63A-4, the identity proofing volume of the revision 4 Digital Identity Guidelines published in 2025, defines three identity assurance levels (IALs):

• IAL1 establishes the real-world existence of the claimed identity and validates core attributes against authoritative sources. Remote or on-site proofing is allowed.
• IAL2 requires stronger evidence and more rigorous validation. It can still be done remotely or on-site without a proofing agent present.
• IAL3 requires an on-site attended session with a trained proofing agent and the collection of at least one biometric characteristic.

The same revision describes four proofing types: remote unattended (fully automated), remote attended (a secure video session with a proofing agent), on-site unattended (a controlled kiosk or workstation) and on-site attended (in the presence of an agent). Other frameworks express the same idea differently. The EU eIDAS framework uses levels of assurance (low, substantial and high), and UK guidance uses levels of confidence. Map between them deliberately rather than assuming equivalence.

Choose the level from the impact of getting it wrong: financial loss, access to other people's data, regulatory exposure and harm to the genuine person whose identity is misused. A current account, a payment wallet and an account that controls production systems deserve more assurance than a newsletter subscription. Many services proof at a moderate level at onboarding and step up to a higher level before higher-risk actions such as large payments or changes to payout details.

How the proofing pipeline works

Resolution

Resolution narrows a claimed identity down to one unique real person using a minimal set of attributes, such as name, date of birth and address. Weak resolution is where synthetic identities thrive: a combination of real and invented attributes that resolves to nobody in particular but passes every individual check.

Evidence collection and validation

• Documents: passports, national identity cards and driving licences are checked for security features, consistency and signs of tampering. Where a document has a chip, reading it and verifying its digital signature is far stronger than analysing an image of the page.
• Live capture: NIST SP 800-63A-4 requires live capture of documents during remote validation, with checks that the document is physically present, so that a manipulated digital copy cannot simply be uploaded.
• Digital evidence: digitally signed evidence, such as a mobile driving licence or a verifiable credential from a trusted issuer, can be validated cryptographically instead of visually.
• Authoritative sources: attributes are checked against issuing or credible sources. NIST SP 800-63A-4 also requires a death records check in every proofing process.

Verification

• Biometric comparison: a live facial image is compared with the document photo or the chip image.
• Presentation attack detection (PAD): checks that the biometric comes from a live person rather than a printed photo, a mask or a replayed screen. ISO/IEC 30107-3 defines how PAD is tested. NIST SP 800-63A-4 sets a maximum impostor attack presentation accept rate (IAPAR) of 0.07 for remote biometric collection.
• Injection attack detection: checks that the image or video came from a genuine camera, not from a virtual camera, emulator or tampered app. NIST SP 800-63A-4 requires controls against digital injection and forged media for all remote proofing. CEN/TS 18099 defines how injection attack detection is evaluated.
• Confirmation codes: a code sent to a validated address or phone number shows control of that channel. It supports verification but is weak on its own, because phone numbers can be hijacked through SIM swap.

Exceptions: trusted referees and applicant references

Some genuine people cannot complete standard proofing because they lack documents, have a thin credit history or have a disability that affects biometric capture. NIST SP 800-63A-4 describes trusted referees, trained agents of the service who make risk-based decisions in these cases, and applicant references, people who vouch for the applicant and must themselves be proofed to the same or a higher level. Exception routes are essential for inclusion, and attackers target them for exactly that reason. Give them their own controls, logging and review.

Threats to identity proofing

• Synthetic identities: identities built from a mix of real and invented attributes, often matured over months before being used for fraud. There may be no real victim to notice.
• Stolen identities: real people's data from breaches, used with forged or stolen documents to open accounts in their name.
• Forged and altered documents: physical fakes, edited images and increasingly AI-generated document images that defeat visual checks.
• Deepfake selfies and face swaps: generated or manipulated faces used to match a forged document. The Arup deepfake fraud showed that a convincing live video of a known person is no longer proof that the person is present.
• Camera and virtual camera injection: the attacker bypasses the camera and feeds pre-recorded or generated media straight into the capture flow, so presentation attack detection never sees a physical artefact.
• Money mules and account farming: genuine people recruited or paid to pass proofing and then hand over the account. The proofing is technically correct and the account is still fraudulent.
• Social engineering of exception routes: pressure on trusted referees, support staff and support chatbots to override checks. The Meta AI support chatbot account takeover showed how a support channel can become the weak point.
• Bot-driven registration: automated attempts at scale that probe which details pass, a problem the CIAM guide covers under fake account creation.

Signs your proofing is not working

Proofing failures rarely show at the point of decision, because a successful attack looks like a successful onboarding. Look downstream and across applications.

• Early-life fraud: fraud losses, charge-offs, chargebacks or account closures concentrated in the first weeks and months after opening.
• Linked-attribute clusters: the same device, phone number, address, IP range or document image appearing across applicants who claim to be different people.
• Suspicious pass-rate patterns: pass rates that jump in one channel, region or partner, or that stay perfectly stable while attacks elsewhere are rising.
• Probing: repeated attempts with small variations in name, date of birth or images. NIST SP 800-63A-4 requires services to stop unsuccessful applicants from inferring which submitted details were correct.
• Capture anomalies: emulators, virtual camera drivers, rooted devices or identical media across sessions.
• Exception creep: a rising share of approvals through manual review overrides or trusted-referee routes.
• Mule behaviour: accounts that sit dormant after opening and then move funds rapidly in and out.
• Genuine users failing: high abandonment or false rejection, especially where it falls unevenly on particular groups, pushes legitimate customers to weaker channels and is itself a risk.

Feed confirmed fraud back into proofing decisions. NIST SP 800-63A-4 requires identity services to run a fraud management programme and to tell relying parties about suspected and confirmed fraud. The loop matters as much as the checks.

KYC and AML obligations

This section is an orientation, not legal advice. Regulated firms should confirm their obligations with their compliance and legal teams.

• Customer due diligence (CDD): anti-money laundering (AML) rules generally require firms to identify and verify customers, identify beneficial owners of legal entities, understand the purpose of the relationship and monitor it on an ongoing basis. Higher-risk customers need enhanced due diligence.
• FATF: the Financial Action Task Force's Guidance on Digital Identity (March 2020) explains how digital identity systems can be used for CDD on a risk-based approach, using assurance levels to judge their reliability.
• European Union: the Anti-Money Laundering Regulation, Regulation (EU) 2024/1624, applies from 10 July 2027 and sets directly applicable CDD rules across member states.
• United Kingdom and United States: UK firms follow the Money Laundering Regulations 2017. US banks follow the Customer Identification Program rules under the Bank Secrecy Act.

Compliance sets a floor, not a ceiling. A process can satisfy KYC rules and still be defeated by injection attacks or mule recruitment, and fraud controls often need to go further than the regulation requires. The Identity Security Regulatory Map summarises related identity obligations.

Reusable and wallet-based identity

• EU Digital Identity Wallets: under Regulation (EU) 2024/1183, every member state must offer at least one European Digital Identity Wallet by 24 December 2026. Private relying parties that are required to use strong user authentication in sectors such as banking, financial services, telecommunications, transport, energy and health must accept the wallet within 36 months of the relevant implementing acts entering into force. Micro and small enterprises are excluded.
• United Kingdom: the UK digital identity and attributes trust framework 1.0 was published in June 2026 under the Data (Use and Access) Act 2025. It certifies digital verification services that relying parties can use instead of running their own document checks.
• Mobile driving licences and verifiable credentials let an issuer sign attributes that the relying party verifies cryptographically, with selective disclosure of only the attributes needed.

Reusable identity changes where proofing happens, not whether it matters. The relying party must still trust the issuer and the wallet, confirm that the person presenting the credential is its holder, and handle a lost or compromised wallet. Treat issuer trust lists, holder binding and revocation checks as part of your proofing design.

From proofed identity to secure account

• Bind at enrolment: register a phishing-resistant authenticator such as a passkey in the same session as proofing, so the proofed person and the account holder cannot be separated. See the Passwordless and Passkeys Guide.
• Record the assurance: store the assurance level, evidence types and proofing route with the account, so later decisions can check how the account was established.
• Re-proof for recovery: for high-value accounts, recovery should repeat identity verification rather than fall back to email, SMS or knowledge questions. The CIAM Guide covers recovery design, and the Identity Provider and SSO Security Guide covers help-desk verification for workforce accounts.
• Step up for risky changes: require fresh verification before changes to payout details, contact details or high-value transactions.
• Minimise and protect data: documents and biometric templates are high-value targets. Biometric data used to identify a person uniquely is special category data under the GDPR. Keep only what you need, for as long as you need it, and protect it accordingly.

Beyond individuals: businesses and AI agents

The same questions apply when the applicant is not a single person. Know your business (KYB) checks verify that a legal entity exists, who controls it and who its beneficial owners are, then proof the individuals acting for it.

AI agents acting for customers raise a different question. An agent cannot be proofed like a person. What matters is binding the agent to a proofed human or organisation, with delegated authority that is scoped, time-bound and revocable. The Agentic Commerce Identity Guide covers agents that buy on a customer's behalf, and the Agent Identity Standards Tracker follows the emerging standards. For the wider distinction between people and software identities, see Human vs Non-Human Identity.

Practitioner checklist

• Set the identity assurance level per product and action from the harm of a wrong decision, and document the mapping between frameworks.
• Read document chips or verify digitally signed evidence wherever possible, and require live document capture for images.
• Use presentation attack detection and injection attack detection, and ask vendors for independent test results against ISO/IEC 30107-3 and CEN/TS 18099.
• Check applicants against authoritative sources, including death records, and look for linked attributes across applications.
• Stop unsuccessful applicants from learning which details were correct, and rate-limit attempts.
• Give trusted-referee, manual review and support exception routes their own controls, logging and review.
• Track early-life fraud, linked-attribute clusters, exception rates and genuine-user abandonment as proofing metrics.
• Bind proofed identities to phishing-resistant authenticators at enrolment and re-proof for high-value recovery.
• Minimise retention of documents and biometric data, and protect what you keep.
• Plan for wallet-based and certified reusable identity where your sector and jurisdiction require or allow it.

Standards and references

• NIST SP 800-63A-4: Identity Proofing and Enrollment (2025)
• ISO/IEC 30107-3:2023 Biometric presentation attack detection: Testing and reporting (2023)
• CEN/TS 18099:2024 Biometric data injection attack detection (2024)
• FATF Guidance on Digital Identity (March 2020)
• Regulation (EU) 2024/1624: Anti-Money Laundering Regulation (2024)
• Regulation (EU) 2024/1183: European Digital Identity Framework (2024)
• UK digital identity and attributes trust framework 1.0 (June 2026)

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Passwordless and Passkeys Guide · Identity Provider and SSO Security Guide · Identity Security Regulatory Map