Category: AML and KYC

Identification and Verification

Also known as: ID&V, Identity Verification, IDV, Identity and Verification

Simply put

Identification and Verification (ID&V) is the process an organization uses to confirm that a person is genuinely who they claim to be, often by collecting and checking official documentation such as government-issued identification or other proof of identity. It is commonly applied when onboarding a new customer or opening an account, including in remote or digital channels. ID&V establishes identity at a point in time; it is distinct from ongoing authentication, which controls access on subsequent interactions.

Formal definition

ID&V is the process of confirming, at enrollment or onboarding, that an individual or entity corresponds to a claimed identity, typically by collecting and validating official documentation (for example government-issued identification or proof of identity) and, in remote contexts, by confirming that a digital user is the legitimate claimant. It is functionally separate from identity authentication (IDA): ID&V is focused on establishing and confirming identity, whereas authentication is focused on granting access on subsequent interactions. In payment and compliance contexts, ID&V supports customer onboarding and risk controls, and its rigor, evidence requirements, and acceptable methods depend on the applicable regulatory, program, or network rules governing a given use case rather than on the label alone. ID&V addresses identity assurance and should not be conflated with transaction-level controls such as EMV chip authentication, 3-D Secure, or multi-factor authentication, which mitigate different risks at different points in a transaction.

Why it matters

Identification and Verification (ID&V) establishes trust at the point where an organization first engages with a customer. If an identity is not confirmed correctly at onboarding, downstream controls inherit that weakness: an account opened under a false or stolen identity can become a vehicle for fraud, money laundering, or account takeover regardless of how strong later authentication controls are. Because ID&V confirms identity at a point in time rather than on every interaction, it is foundational to, but not a substitute for, ongoing authentication.

In payment and compliance contexts, ID&V is where the strength of an organization's fraud and risk posture is largely set. The rigor required, the evidence that is acceptable, and the methods that satisfy the process depend on the applicable regulatory, program, or network rules governing a given use case rather than on the label "ID&V" alone. This matters especially in remote and digital channels, where the organization cannot physically inspect a person or document and must instead confirm that a digital user is the legitimate claimant.

ID&V should not be treated as a control that eliminates fraud on its own. It is intended to reduce the risk of fictitious, stolen, or synthetic identities entering a system at onboarding, but it does not address transaction-level risks handled by controls such as EMV chip authentication, 3-D Secure, or multi-factor authentication. Its effectiveness also depends on the quality of the documentation and verification methods used, which carry their own trade-offs between friction and assurance.

Who it's relevant to

Merchant risk and onboarding teams

Teams responsible for opening customer accounts rely on ID&V to confirm that a new applicant is genuinely who they claim to be before granting access to products or services. Getting this right at onboarding helps reduce the risk of fictitious or stolen identities entering the system, though it does not replace ongoing monitoring or authentication.

Compliance officers

ID&V often supports customer onboarding obligations, where the required rigor and acceptable evidence depend on the applicable regulatory or program rules governing a given use case. Compliance teams should confirm requirements against the specific rules that apply to their jurisdiction and product rather than assuming a single universal standard.

Fraud analysts

For fraud teams, ID&V is a first line of defense against identities that are fabricated, stolen, or synthetic entering an account base. It is distinct from transaction-level and access controls, so analysts should treat it as one layer among several rather than a control that eliminates fraud on its own.

Identity and authentication engineers

Engineers building enrollment and access flows need to keep ID&V distinct from authentication (IDA). ID&V establishes identity at enrollment; authentication controls access on subsequent interactions. In remote channels, engineers must also address confirming that the digital user is the legitimate claimant, not only that the documentation appears valid.

Inside ID&V

Identity assertion collection

The gathering of the cardholder-supplied information and credentials that the process will evaluate, such as PAN, cardholder name, expiration date, billing details, or authentication factors presented during onboarding or a transaction. Collection methods and the sensitivity of the data collected determine applicable handling controls.

Verification against authoritative sources

The step in which collected data is checked against issuer records, network directories, or other trusted references to assess whether the presented identity or card is legitimate. Verification confirms correspondence between the asserted identity and a source of record; it is intended to reduce, not eliminate, the risk of impersonation.

Authentication factor evaluation

Assessment of factors used to establish that the party is who they claim to be. Distinct mechanisms address different points in a transaction, for example EMV chip authentication for card-present, 3-D Secure and strong customer authentication for card-not-present, and multi-factor authentication for account access. No single factor is sufficient on its own for all fraud scenarios.

Data classification within ID&V

Distinguishing cardholder data (such as PAN, cardholder name, expiration date, service code) from sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks). Sensitive authentication data must not be stored after authorization even when encrypted, while some cardholder data may be retained under defined controls.

Risk-based decisioning and step-up

The logic that weighs verification outcomes and contextual signals to accept, decline, or request additional verification (step-up). Detection thresholds involve trade-offs between false positives (legitimate customers challenged or declined) and false negatives (fraud allowed through).

Record keeping and auditability

Retention of evidence about what was collected, how it was verified, and the resulting decision, in a manner consistent with applicable data-handling controls. What may be retained depends on data classification and validated implementation rather than on the ID&V label alone.

Common questions

Answers to the questions practitioners most commonly ask about ID&V.

Is ID&V the same as authenticating a payment transaction?

No. ID&V refers to establishing and verifying the identity of a cardholder or user, typically at enrollment or provisioning time, for example when a card is added to a digital wallet or when a customer is onboarded. Transaction authentication, such as 3-D Secure challenges or EMV chip authentication, addresses whether a specific payment attempt is legitimate. The two occur at different points and address different risks, and performing ID&V does not by itself authenticate later transactions.

Does completing ID&V guarantee that fraud will not occur on the account?

No. ID&V is intended to help reduce the risk that an account, card, or credential is set up or accessed by someone other than the legitimate party, but it does not guarantee prevention of fraud. Fraud such as account takeover, first-party or friendly fraud, and synthetic identity fraud can still occur despite ID&V, and detection controls carry false-positive and false-negative trade-offs. ID&V is one layer among several, not a standalone safeguard.

What data elements are typically used to perform ID&V?

Implementations vary and may combine several factors, such as verification of contact details, one-time passcodes, knowledge-based checks, document verification, or issuer-side confirmation. Where card data is involved, it is important to distinguish cardholder data from sensitive authentication data: full track data, card verification values such as CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization even when encrypted. Any ID&V design should confirm which elements it handles and apply the corresponding controls.

How does the ID&V process affect PCI DSS scope?

If an ID&V process transmits, processes, or stores cardholder data, the systems involved fall within PCI DSS scope and must meet applicable requirements of the current published standard. Techniques such as tokenization, encryption, truncation, or masking may reduce or transform the data handled, but their effect on scope depends on how they are implemented and validated, not on the label alone. Confirm scope by mapping actual data flows rather than assuming a control removes systems from scope.

Where does ID&V fit relative to standards other than PCI DSS?

ID&V as a concept may intersect with several frameworks depending on context. For example, PIN-related handling is governed by PCI PIN, point-to-point encryption by PCI P2PE, and 3-D Secure environments by PCI 3DS, while PCI DSS governs the protection of account data more broadly. Identify which standard governs each control involved in your ID&V flow, and do not assume PCI DSS covers a requirement that belongs to a separate standard.

How should teams handle false positives and false negatives in ID&V checks?

Any ID&V verification carries trade-offs: stricter checks may reject legitimate users (false positives) while looser checks may admit bad actors (false negatives). Teams typically tune thresholds against their own risk appetite, monitor outcomes, and combine multiple signals rather than relying on a single check. Because liability and dispute rules are set by card brand and network rules that vary by region and change over time, confirm current applicable rules when designing enrollment and step-up flows.

Common misconceptions

ID&V verifies identity, so it prevents fraud.

ID&V is intended to reduce the risk of impersonation and unauthorized use, but it does not eliminate fraud. Different fraud types, such as card-not-present fraud, account takeover, first-party or friendly fraud, chargeback fraud, and synthetic identity fraud, can bypass or exploit weaknesses in a given ID&V process. Any control involves false-positive and false-negative trade-offs.

Because ID&V may involve encryption, sensitive authentication data can be stored as long as it is protected.

Sensitive authentication data, including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be stored after authorization even when encrypted. Only certain cardholder data may be retained under defined controls. Encrypting the data does not create an exception to the prohibition on storing sensitive authentication data.

Enabling one authentication mechanism, such as 3-D Secure, satisfies all ID&V and authentication needs.

EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in a transaction. No single mechanism covers every channel or fraud scenario, and any liability shift associated with a mechanism is governed by card brand and network rules that vary by region and change over time.

Best practices

Classify all data handled during ID&V, and confirm that sensitive authentication data is not retained after authorization, regardless of encryption, while limiting retained cardholder data to what is necessary under defined controls.

Select authentication mechanisms appropriate to the channel and point in the transaction, recognizing that EMV chip, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks and are not interchangeable.

Apply risk-based step-up verification and tune thresholds deliberately, monitoring the trade-off between false positives that friction legitimate customers and false negatives that let fraud through.

Verify collected identity and card data against authoritative sources where available, and treat verification as a control that reduces rather than eliminates impersonation risk.

Confirm applicable controls, requirement wording, and version-specific obligations against the current published standard rather than assuming fixed requirement numbers, and identify which standard governs each control.

Consult current card brand and network rules for the relevant region when relying on liability shift or chargeback outcomes tied to a given authentication mechanism, since these rules vary and change.