Identity verification is the process of confirming that a person owns the identity evidence they present. NIST uses three identity-assurance levels, from little or no real-world identity linkage to in-person proofing.
You've probably met the vague version of this request already. A bank, software platform, event organizer, or private community asks you to “verify your identity,” then presents a document upload, a selfie prompt, or a few questions. You may wonder what the system checks, who sees your information, and whether a name or LinkedIn profile would have been enough.
I've reviewed hundreds of community applications, and I've learned that identity verification works best when everyone separates the checks. You need to know whether a person exists, whether their evidence is genuine, whether they own that evidence, and whether they fit the community or service. Those answers don't always come from the same tool.
The Check That Decides If You Get In
You apply to a bank, a platform, or a private group. The screen says, “Verify your identity.” You upload a document, take a photo, and wait. The process may take moments, yet the phrase hides several different decisions about you and your information.
Identity verification confirms that the person presenting identity evidence is the genuine owner of that evidence. It connects a real person, reliable evidence, and the account or membership that person wants to create.
That definition matters because checking a name doesn't prove much. A person can enter a real name, copy a profile photo, or share a convincing LinkedIn page while claiming someone else's identity. A document upload also doesn't settle the question by itself. The document may belong to someone else, or the file may have been altered.
What happens after you submit evidence
A verification process may check the document's format, security marks, issuing source, biographical details, device signals, or facial match. A higher-risk service may add liveness detection, chip reading, database checks, or human review. The organization should choose those checks based on what could go wrong if an impostor gets access.
A bank may need to establish who controls an account. A low-risk discussion group may only need confidence that each applicant is a real person. A founder community may also check whether the applicant has a genuine connection to a company or professional identity. Those are separate questions, and they shouldn't automatically require the same personal data.
Why the request feels unclear
Organizations often use “identity verification” as a catch-all phrase. They may mean identity proofing during signup, authentication during login, professional vetting, fraud screening, or a combination of these.
Before you submit anything, ask four plain questions:
- What are you checking? Ask whether the process checks a real person, a document, an account, a professional claim, or all of these.
- Why do you need it? The answer should connect to a specific risk, such as impersonation or unauthorized access.
- What will you retain? A verification result may meet the need without storing a full passport image.
- What happens if I fail? A fair process has a review route for mismatches and people who can't use the default method.
The rest of the process becomes easier to judge once you separate identity proofing from login security and treat privacy as part of the design.
What Identity Verification Really Means
Think of a locked door. A key proves that someone holds a key, but it doesn't prove that the building owner gave that key to the person standing outside. Identity verification asks for the second part. It checks whether the evidence belongs to the person presenting it.
Core definition: Identity verification confirms that the person presenting evidence is the individual to whom that evidence was issued.
A passport, driver's license, or digital identity assertion can describe a person. The system still needs to connect that description to the applicant. It may compare a face with a document photograph, ask the applicant to complete a liveness action, inspect a chip, or send the case to a trained reviewer.
Proofing and authentication answer different questions
NIST formalized identity proofing in its Digital Identity Guidelines, first published in 2017. The framework separates proofing from authentication and defines three identity-assurance levels that organizations can match to risk. NIST's Digital Identity Guidelines describe proofing as establishing who someone is during enrollment. Authentication happens later, when the system checks whether that person controls the approved authenticator.
Here's the practical difference:
- Identity proofing asks, “Who are you?” You present evidence, and the organization decides whether it can link you to a real-world identity.
- Authentication asks, “Can you access the approved account?” You enter a password, use a passkey, approve a login, or provide another authenticator.
- Federation asks, “Can another trusted system send an identity assertion?” One service may rely on an assertion from another service instead of repeating every check.
A thief with your password might pass authentication while failing identity proofing. A genuine applicant might pass proofing but lose access to an account after losing a device. Treating those events as the same problem creates bad recovery procedures.
Assurance is a dial, not a switch
NIST's assurance levels let an organization choose how much evidence it needs. A service with little harm attached to impersonation may use a lighter process. A service that manages money, sensitive records, or legal authority may ask for stronger evidence and closer human supervision.
The point isn't to collect everything available. The point is to gather enough trustworthy evidence for the risk you face. A private dinner group doesn't need to copy a bank's entire onboarding process because both groups use the phrase “verify your identity.”
The Three Checks Behind Every Verification
I use a three-piece puzzle to explain the process. The first piece identifies one person, the second checks the evidence, and the third connects the applicant to that evidence. Remove any piece and the picture becomes unreliable.
First, resolve the identity
Identity resolution asks whether the claimed identity matches one unique person in the relevant population. If an applicant supplies a common name and a location, the system needs enough information to distinguish that person from others with similar details.
Resolution doesn't prove that the applicant owns the identity. It only decides which real-world identity the evidence appears to describe.
Second, validate the evidence
Evidence validation asks whether the document or data remains genuine, accurate, and valid. The process may inspect document features, check information with the issuer, read a supported NFC or other chip, or compare details across reliable records.
A stolen passport could pass this stage because the passport itself is genuine. That result still doesn't tell you whether the applicant is the rightful passport holder.
Third, verify the applicant
Verification asks whether the person presenting the evidence is the person to whom it was issued. The system may compare the applicant with a document photograph, use liveness or presentation-attack detection, or send an unusual case to a human reviewer.
NIST's identity-proofing guidance defines resolution, evidence validation, and verification as separate checks. A document upload or LinkedIn profile alone can't answer all three questions.
A real person using a false document can fail validation. A real document held by the wrong person can pass validation while failing verification. A genuine person with inconsistent records may need a review instead of an automatic rejection.
If you're testing a service, ask which pieces it performs and which it leaves to another system. If you're designing a signup flow, write each decision down before choosing a vendor. People should know whether you're proving their identity, checking their professional context, or merely confirming that they control a phone or email account.
For account recovery or phone-based testing, teams may also need temporary access to a number without tying that number to a person's identity. A resource about rent phone numbers online can help explain that phone possession and identity ownership are different questions.
How KYC, Document Checks, and Biometrics Compare
People often use KYC, document verification, and biometrics as if they mean the same thing. They don't.
KYC, or know your customer, describes a wider process used by financial institutions. A bank checks more than a customer's name. It may need to identify the beneficial owner, meaning the natural person who ultimately owns or controls the customer or acts for someone else in a transaction.
The building analogy helps. A document check looks at the person standing at the front door. A beneficial-owner check asks who owns or controls the building.
FATF guidance for financial institutions says banks should use reliable, independently sourced documents, data, or information and take reasonable measures to verify beneficial owners. Accepted evidence can include an unexpired passport, national identity card, residence permit, or driver's license with a photograph.
| Method | What It Proves | Typical Evidence | Main Failure Mode |
|---|---|---|---|
| KYC | The customer and, where required, the person who owns or controls the customer | Identity documents, address records, ownership information, independently sourced data | Complex ownership or outdated records can hide the person who actually controls the account |
| Document check | The presented evidence has valid details and appears genuine | Passport, national identity card, residence permit, or driver's license | A stolen genuine document may pass the document check |
| Biometric comparison | The person presenting the evidence resembles the person shown in the evidence | Facial comparison, liveness signal, fingerprint, or another approved biometric method | Poor lighting, changed appearance, spoofing, bias, or inaccessible hardware can cause a wrong result |
Where each method fits
Document checks give you a durable source of identity attributes. Biometrics help connect the person in front of the camera or sensor to a document, but they don't automatically prove that the document contains accurate information.
A bank may combine all three methods because an account can carry financial and legal risk. A small membership group may need a document or equivalent real-person check, then a separate review of the applicant's professional claim. Calling both activities “KYC” can make a modest community process sound more invasive than it needs to be.
Privacy Trade-Offs You Should Think About
Verification creates a trade. Stronger evidence can reduce impersonation risk, yet every extra field, image, or biometric record creates more exposure for the applicant and the organization holding it.
Start with the harm you want to prevent. If a private dinner group wants to keep out fake profiles and aggressive sellers, it may need confidence that applicants are real people. It may not need passport numbers, full addresses, or a permanent copy of an identity document.
NIST's assurance ladder gives organizations a practical way to size the process. IAL1 doesn't require linkage to a specific real-life identity. IAL2 requires evidence of a real-world identity plus an association between that identity and the applicant. IAL3 requires in-person proofing with an authorized representative. NIST's current identity-proofing framework, published in August 2025, treats privacy, equity, usability, and recovery as core design concerns.
Collect only what the decision needs
Write the admission decision before you collect data. If the decision requires “this is a real person who claims to work at this company,” record that outcome and the limited attributes needed to support it. Don't let the process drift into a general-purpose dossier.
- Store outcomes where possible. Keep a status, review date, and minimum necessary attributes instead of retaining full document images indefinitely.
- Separate identity from context. A real-person check doesn't prove employment, company ownership, location, or expertise.
- Explain the process plainly. Applicants should know what you check, why you check it, who handles exceptions, and how long you keep the result.
- Build recovery before launch. People lose phones, change names, replace documents, and encounter record mismatches. A recovery path prevents repeated document submissions.
Communication matters too. If you're emailing a group about a sensitive process, learn the difference between choosing CC or BCC so you don't expose applicants' addresses to one another. Your broader confidentiality policy should also explain how private information moves inside the organization, as described in what confidentiality means and why it matters.
Privacy rule: Use the lowest assurance level that addresses the actual harm, then remove data that the decision doesn't need.
When Verification Fails or Gets Attacked
A verification flow can reduce some fraud while creating new targets. Attackers may manipulate documents, faces, accounts, support tickets, or recovery steps. A system that checks more signals still needs people to review how those signals can fail.
AuthenticID reported that its detected fake IDs and suspicious biometric transactions increased 42% year over year in 2024. Veriff reported that global fraud attempts rose 21% year over year in 2025, with deepfakes accounting for one in 20 identity-verification failures. These figures come from individual company reporting, so I wouldn't apply them to every provider or population, but they show why verification can't function as a one-time guarantee. The reported fraud findings also give attackers a reason to probe the process itself.
Genuine people can fail too
A legitimate applicant may have poor lighting, an old document photo, a changed appearance, an inaccessible camera, a missing document, or inconsistent records. The system may treat those conditions like fraud even when the person did nothing wrong.
More friction doesn't automatically produce more security. If the only fallback asks someone to submit the same sensitive documents again, the organization may increase privacy risk while giving the applicant no fair way to resolve the problem.
A fair process should include:
- Alternative proofing methods. Give people an option that doesn't rely on face recognition when the risk allows it.
- Manual escalation. Send unusual mismatches to a trained reviewer instead of rejecting every exception automatically.
- Limited appeals. Let applicants explain a mismatch without sharing their documents with a wider group.
- Clear recovery. Use more than one authenticator and provide a controlled route for account recovery.
The person who designs verification should test failure cases before launch. Ask what happens when a document is genuine but stolen, when a camera can't capture a face, when a professional profile is outdated, and when someone needs help from another device. Those answers tell you more about the quality of the process than a polished signup screen.
Why Vetted Communities Verify Members
A private community needs enough trust for members to discuss mistakes, money, hiring, suppliers, and personal pressure. Impersonators, self-promoters, and service-sellers can damage that setting quickly. The organizer doesn't need to know everything about an applicant. The organizer needs a defensible reason to believe that the person is real and belongs in the room.
I'd split the decision into two checks:
- Real-person identity: Does the applicant control the identity evidence they present?
- Professional context: Does the applicant have a credible connection to the founder, company, or work history they describe?
A LinkedIn review can help with the second question. It doesn't replace the first. A polished professional profile can support context, while a government ID or equivalent method can support a real-person identity. Each check carries different privacy costs, so I'd document them separately.
For a small founder group, I'd keep the record simple. Store that the identity check passed, note the minimum attributes needed for membership, and avoid retaining a full document unless a clear rule requires it. If an applicant's name or company details don't match, ask for clarification and route the case to a person.
A practical example looks like this: the group checks an applicant's identity, reviews the professional context, then admits the person to a private dinner and conversation space. The group doesn't need a bank-style ownership file for every member. It needs a repeatable decision and a way to protect confidential discussion.
You can compare this kind of Identity verification with other screening approaches used by volunteer and nonprofit organizations, then choose only the checks that fit your group's risk.
Small-group structure matters after admission. A format with private dinners, a focused group chat, and explicit confidentiality rules gives members a clear setting for honest discussion. The SoHo House application guide provides a useful comparison point for people evaluating selective communities, though each group should set its own standards.
Best Practices for Verifying People in Small Groups
You can design a proportionate process without building a bank. Start with the decision, then work backward to the evidence.
A practical checklist
Name the risk. Write down what you're trying to prevent. Impersonation, harassment, aggressive selling, unauthorized access, and false professional claims may need different responses.
Choose the assurance level. Use a lighter check when the harm from impersonation stays low. Choose stronger evidence when members access money, regulated services, sensitive records, or high-trust responsibilities.
List required attributes. Decide whether you need a real name, professional affiliation, location, age range, or another specific attribute. Don't collect a field because a vendor makes it available.
Separate the checks. Keep real-person identity, account control, and professional context as distinct decisions. A phone number proves access to a phone. It doesn't prove who owns the identity behind the account.
Tell applicants what happens. Explain the evidence you accept, the reason for the check, who can review it, the retention period, and the appeal route.
Store the result, not the whole file. Record the outcome and minimum necessary attributes. Limit access to the people who make membership decisions.
Review mismatches by hand. A wrong birth date, changed name, outdated profile, or poor image may need a conversation. Automatic rejection can remove good applicants and teach attackers how to probe your rules.
Test recovery. Decide how someone regains access after losing a device or changing personal details. Don't make people repeatedly upload sensitive documents without a reason.
A community also needs a format that supports trust after screening. Private dinners and small peer groups can create a better setting for candid conversations than open networking, provided the organizer explains the boundaries. The mastermind group format shows how a structured peer setting can keep participation focused.
Identity verification connects a real person to reliable evidence. Good design keeps that connection clear, uses only the strength of check the risk demands, and gives legitimate people a fair route through failure.
Chicago Brandstarters is a free, vetted community for Chicagoans and Midwesterners building brands from the idea stage toward seven figures, with identity and LinkedIn vetting, private 6–8 person dinners, and confidential founder conversations. Visit Chicago Brandstarters to learn how membership works and decide whether the community fits your next stage.
Leave a Reply