What Is Identity Verification?

Identity verification (IDV) is the process of confirming that a person is who they claim to be. It answers two questions:

• Does this identity document belong to a real person?
• Is the person presenting it the same person the document belongs to?

You encounter IDV as a customer whenever you open a bank account online, board a flight, or verify your age on a regulated platform. As a developer, you're responsible for building the integration that makes IDV happen.

Why Applications Need Identity Verification

Regulations in financial services, healthcare, and other industries require organizations to verify the identity of their customers before granting access to certain services. The two most common regulatory frameworks are:

• Know Your Customer (KYC): Requires financial institutions to verify customer identity before and during a business relationship. KYC primarily prevents fraud, money laundering, and terrorist financing. KYC is mandated by Anti-Money Laundering (AML) laws in most jurisdictions.
• Know Your Business (KYB): The KYC equivalent for business entities. Before onboarding a business customer, a regulated organization must verify that the business is real, legally registered, and not subject to sanctions. In many jurisdictions, you must also identify the individuals who ultimately own or control the business, known as Ultimate Beneficial Owners (UBOs).

Beyond regulatory compliance, you can use identity verification to:

• Reduce fraud
• Protect users from account takeover
• Build trust in their platforms

How Identity Verification Works

A typical IDV flow includes three components that work together:

• Document verification confirms that an identity document—such as a passport, driver's license, or national ID—is real. This involves checking the document structure, security features, and data fields against known templates for that document type. It also includes checks for document tampering and forgery. Incode supports verification of 4,600+ document types across more than 200 countries and territories, including NFC chip reading for ePassports.
• Biometric verification confirms that the person presenting the document is the same person pictured in it. The customer takes a selfie, and the platform compares it against the photo on the document using facial recognition. A liveness check—either passive or active—runs at the same time to confirm the selfie is from a live person and not a photograph, screen replay, or synthetic image. Incode's liveness detection is certified to ISO/IEC 30107-3 and ranked among top performers in NIST FRVT testing.
• Data verification (eKYC) optionally cross-references the identity data extracted from the document against authoritative external sources—government registries, credit bureaus, or watchlists—to further confirm that the identity exists and is in good standing. Incode connects to government sources in 8+ countries, including deep integrations with Mexican government registries (RENAPO, CURP, INE, SAT) not available through any other platform in this space.

What Can Go Wrong—and How Incode Detects It

Identity fraud takes several forms, and a production IDV system needs to address all of them, including:

• Document fraud: Using a forged, altered, or stolen document. Incode's document verification checks physical and digital security features, cross-references OCR-extracted data against document templates, and flags inconsistencies that indicate tampering.
• Presentation attacks: Holding up a photo, playing a video, or using a mask to defeat the selfie capture. Incode's passive and active liveness detection, including its Deepsight deepfake defense suite, detects physical attacks (printed photos and masks) and digital attacks (screen replay, injection attacks, and synthetic face generations) as distinct check categories.
• Identity spoofing: Using another real person's documents. The face match between the selfie and the document photo addresses this directly. For returning users, Incode's 1:N face authentication can identify a person against an entire enrolled database without requiring them to claim an identity first—a capability not offered by any other major IDV platform. This makes it particularly effective for detecting repeat fraud attempts under different identities.
• Synthetic identity fraud: Combining real and fabricated data to create a fictitious identity. eKYC database checks, combined with device signals and behavioral data captured during the session, help identify patterns that are inconsistent with a genuine user.

The Difference Between Verification, Authentication, and Authorization

These three terms are frequently used interchangeably, but they describe distinct steps in a security flow. Knowing the difference between them prevents integration designs that skip steps or assign responsibilities to the wrong layer. Here's what they mean:

• Verification happens once, or periodically when re-verification is required. It establishes who a user is and creates a durable record of that identity. A government ID is checked, a selfie is captured, and the two are matched. This is the foundation of any good onboarding flow.
• Authentication happens repeatedly after verification. It confirms that the person accessing your application right now is the same person who was previously verified. Face authentication using a selfie is a common post-verification authentication method. Incode supports both:
  • 1:1 authentication: The user claims an identity and the selfie is compared against that specific enrolled identity.
  • 1:N authentication: The selfie is compared against all enrolled identities to identify the person without a prior claim. Authentication is also an important part of onboarding flows.
• Authorization happens after authentication. It determines whether the verified, authenticated person has permission to perform a specific action or access a specific resource. Authorization is a decision your application makes based on the user's role, account status, jurisdiction, or other business rules. It is outside the scope of the IDV platform itself. Incode confirms who someone is; your application decides what they are allowed to do. Depending on why your application is using IDV, authorization may or may not be necessary.

Privacy and Data Handling

Identity verification involves collecting sensitive personal data, such as government ID images, selfie photographs, and biometric templates. Your integration is responsible for handling this data in compliance with applicable regulations, including GDPR in Europe and CCPA in California. Key design considerations include:

• Data minimization: Only collect what is required for your use case.
• Consent: Obtain explicit user consent before capturing biometric data. Incode's Workflow builder includes configurable consent modules for this purpose.
• Data residency: Incode supports U.S., EU, and regional deployment options to satisfy data localization requirements.
• Retention: Establish and enforce policies for how long verification data is stored.

Incode holds SOC 2 Type II certification and is GDPR and CCPA compliant. HIPAA compliance is also available for healthcare use cases.

What Incode Adds to the Picture

Most IDV platforms handle the core document-plus-selfie flow. Incode offers the expansion and configurability of what happens around that core:

• Modular Workflow builder: Configure the exact verification steps your use case requires, with conditional branching logic, without writing orchestration code.
• LATAM government depth: Direct integrations with government registries in Mexico, Brazil, Argentina, Colombia, Chile, Peru, and more; a coverage depth not available with any competitor.
• Flexible integration: Seven mobile SDK frameworks (iOS, Android, React Native, Flutter, Xamarin, Cordova, Ionic Capacitor), Web SDK, REST API, hosted no-code Flows, kiosk mode, and an end-to-end encrypted integration variant.
• Session completeness: A single onboarding session can combine document verification, biometric liveness, eKYC checks, business verification (eKYB), custom forms, consent capture, and a video conference review module if needed.
• Prizma design system: A documented, token-based UI customization system with light/dark mode support. It lets your integration look and feel native to your application, as opposed to a generic third-party widget.

Now that you understand what identity verification is and what Incode does, the next step is understanding the core concepts specific to building with the Incode platform.