Fraud models are built on signals. The more signals you have, the better your decisions, at least in theory. In practice, what matters is understanding what each signal actually tells you, when it's authoritative, and when it's noise.

Most fraud signals fall into one of two categories.

1. Passive and behavioral signals: Device fingerprints, IP reputation, velocity checks, transaction history. These tell you something about the transaction or the account.
   They answer the question: does this look like a legitimate user?

2. Cardholder verification signals: Address, CVV, and name. These tell you something different. They go directly to the issuing bank and ask: are these card details correct?

That's a categorically different question. Not a better one in every scenario, but a more authoritative one in specific situations.

This article covers what each cardholder verification signal actually tells you, where each one is strong, where each one is weak, and how to use them together in a fraud model that gets real value from issuer verification.

What cardholder verification signals are

Quick summary: A $0 authorization sent to the issuer, checking submitted details against their records and returning match, partial match, or no match. Three signals, AVS, CVV, and name, are widely available. Two newer ones, phone and email, are useful but have limited issuer support.

Cardholder verification works by performing a non-financial check, typically a $0 authorization, through the card networks. The issuing bank validates the supplied cardholder data against its records and returns verification signals. These get normalized into consistent result types: match, partial match, or no match, depending on the signal.

Three signals, AVS, CVV, and name validation, are long-established and available across most or all networks. Two more, phone and email, are newer additions to the network verification services (currently offered by Visa) and worth understanding, even though coverage is more limited.

Address Verification (AVS)

AVS compares the billing address and postal code provided by a user with the address on file with the issuing bank. The issuer returns a response code representing different combinations of address and postal code matching, typically normalized into match, partial match, or no match.

AVS is the oldest and most widely deployed verification signal. It's available through most PSPs as part of standard payment processing and works most reliably in the United States, the United Kingdom, and Canada. Outside those markets, reliability varies significantly. Inconsistent address formatting, incomplete issuer records, and different address structures in markets like Spain, Latin America, and parts of Asia mean partial matches are common even for entirely legitimate cardholders.

CVV Verification

CVV verification checks whether the three or four digit security code provided by a user matches the code held by the issuer. Unlike AVS, CVV is a binary check with no partial match. If the CVV does not match, the issuer typically declines the request and other verification checks may not proceed.

Name Validation (ANI / NVS)

Name validation compares the cardholder name provided against the name held by the issuing bank. It's available on Visa, where it's called Account Name Inquiry, and on Mastercard, where it's called Name Validation Service. Visa validates first name and surname separately and returns a result for each. Mastercard returns a single full-name result. Both use string-distance algorithms to assess similarity, so small differences between the submitted name and the issuer record, a nickname, a missing middle name, or a slight spelling variation typically return a partial match rather than a hard failure.

Phone and email verification

Phone and email verification work the same way as the other three signals mechanically: the submitted value is checked against the issuer's record and returned as a match, partial match, or no match. What makes them worth calling out separately is the theory behind why they're strong, and the practical reality of why they're not always usable.

The theory: a fraudster may have the name and the billing address. What they're far less likely to have is the cardholder's actual phone number or email address on file with the issuing bank, since neither is printed on the card or reliably present in most breach dumps. In principle, that makes a phone or email match a strong, hard-to-forge signal.

The reality: This is a newer capability, currently offered by Visa, and issuer support is inconsistent. You'll see this signal returned as unavailable far more often than you'll see AVS or CVV returned as unavailable. Evervault supports both where the issuer does, and a match is worth weighting accordingly when you get one, but plan your fraud model around AVS, CVV, and name as the reliable core, with phone and email as a valuable bonus signal rather than something to depend on.

How verification signals differ from passive and behavioral signals

Quick summary: Passive signals detect anomalies by comparing against a baseline. Verification signals ask the issuer a direct question with no baseline involved. That's why a full data breach defeats verification but gets caught by passive signals, and why the reverse is true in other scenarios.

To use verification signals well, it helps to be precise about what makes them different from the passive and behavioral signals that make up most of a typical fraud model.

Passive signals detect anomalies. A device fingerprint that's never been seen before on a particular account is anomalous. An IP address associated with a high-risk geography is anomalous. A sudden spike in transaction velocity is anomalous. These signals work by comparing what you're seeing now against a baseline of prior behavior, prior sessions, and prior transactions. When something deviates from that baseline, the risk score rises.

Verification signals don't work that way. They don't compare the current session against anything. They go to the issuer and ask a direct question about the details presented. The answer is independent of the transaction, the device, the IP address, and the account history.

This means the two types of signals answer fundamentally different questions, and they're strong and weak in different scenarios as a result.

The scenario where passive signals clearly win is a full card data breach, where an attacker has obtained complete card records, PAN, expiry, name, billing address, and CVV, from a compromised source. In that scenario, the fraudster passes every verification check because the details are genuinely correct. The anomaly isn't in the card details. It's in the session: a new device, an unusual geography, a behavioral pattern that doesn't match the legitimate cardholder. Passive signals catch that. Verification signals don't, because verification only ever checks whether the submitted details match the issuer's record, nothing about who's submitting them or from where.

That boundary matters enough that it's worth returning to later in this piece, since it's easy to misapply verification to a problem it structurally can't solve.

CVV: the strongest verification signal, and why

Of the five cardholder verification signals, CVV is typically the most powerful for the moment of a transaction. The reason is rooted in a data security regulation most fraud teams know but don't always connect to signal weighting.

PCI DSS, the payment card industry's data security standard, explicitly prohibits merchants from storing CVV data after a transaction is authorized. This is a hard rule, not a guideline. The practical consequence: when a merchant database is breached, attackers typically obtain the PAN, expiry date, cardholder name, and billing address. They don't obtain the CVV, because compliant merchants don't store it. CVV is available only to the issuing bank and on the physical card itself.

This creates a meaningful asymmetry. A fraudster who buys card data from a breach dump or a dark web marketplace typically has a complete set of card details, excluding the CVV. They have everything needed to attempt a transaction except the one piece of data that proves physical possession of the card.

A CVV mismatch is therefore a high-confidence fraud signal in most scenarios. It strongly suggests the user doesn't have the physical card, and that the card details came from a source that couldn't include CVV. A CVV match doesn't guarantee legitimacy; CVV data can still be obtained through phishing, skimming, or social engineering, but, when combined with other signals, a match meaningfully increases confidence.

The practical implication: if you're weighting one verification check most heavily, CVV is the right starting point for card-not-present transactions. It's the detail most likely to be absent from stolen card data and the hardest to fake without physical access to the card or a direct social engineering attack on the cardholder.

Address verification: useful signal, important caveats

AVS is widely available, well understood, and genuinely useful. But it needs to be applied carefully, because its reliability varies in ways that aren't always well accounted for in fraud models.

The fundamental limitation is geographic. AVS was developed primarily for the US market and works most reliably where address data is structured consistently, and issuers maintain accurate billing records. In the US, UK, and Canada, it's a reasonable signal. Outside those markets, it becomes progressively less reliable.

Spain is a useful example. Spanish addresses often include multiple components: street name, building number, floor, and door number, that issuers may not store in full. A user submitting a complete address may get a mismatch against an issuer record that only stores the street name and number. Spanish postcode areas are also relatively large, so a user who's moved within the same postcode area will have a different street address but an identical postcode, producing a partial match that's entirely legitimate. Similar issues arise across much of Southern Europe, Latin America, and parts of Asia.

The second limitation: billing address data is more widely available in breach dumps than CVV. An attacker with a complete stolen card record typically has the cardholder's billing address, which makes AVS a weaker signal than CVV against sophisticated fraud involving comprehensive card data.

How to use AVS well: treat it as a risk input that adjusts your confidence level, not a gate that triggers hard decisions on its own. A complete mismatch on both street and postcode in a market where AVS is reliable, combined with other risk signals, is meaningful. A partial match in isolation, particularly outside the US, UK, and Canada, should raise a risk score rather than trigger a decline. When combined with a CVV mismatch, a full AVS mismatch becomes a strong signal worth acting on.

One practical note: using an address standardization tool before submitting AVS checks reduces false partial matches caused by formatting differences rather than genuine mismatches. Google Address Validation is a commonly used option.

Name validation: the most powerful signal in the right context

Name validation is less commonly available than AVS and CVV. Most PSPs don't expose it. In the wrong context, it adds limited value. But in specific scenarios it's the most powerful of the five signals, because it answers a question the others can't.

AVS confirms a billing address is correct. CVV confirms a user has the physical card. Name validation, in the right context, can confirm a card belongs to the person presenting it. That's an ownership question, not just a validity question, and it's categorically more powerful for certain fraud problems.

The honest caveat first: cardholder name data is frequently included in breach dumps, unlike CVV. An attacker with a complete stolen card record will typically have the cardholder's name and can pass a name validation check. In that scenario, name validation adds little on its own.

But consider what changes when name validation is combined with a KYC process. A fraudster with Jane Smith's full card data, PAN, expiry, CVV, billing address, and name will pass every verification check. They can't, however, pass a KYC process that requires Jane Smith to present a government-issued ID and a matching selfie. The combination creates an ownership confirmation that neither signal alone provides. The issuer confirms the name matches its records. KYC confirms the name matches a verified identity document. Together, they establish that the card belongs to this specific verified person, a question no other fraud signal answers as directly.

This makes name validation most powerful in two contexts. First, payout flows where a platform already performs KYC, since confirming the payout card name matches the verified account holder is a strong ownership signal before funds are sent. Second, any scenario where the core question isn't whether this session looks suspicious, but whether this card belongs to this person, a different and often more important question in high-value or high-risk environments.

Name validation also produces partial matches more frequently than AVS or CVV, and those need careful interpretation. Common scenarios that produce legitimate partial matches include nicknames versus legal names (Mike versus Michael), multiple surnames in Spanish and Latin American naming conventions, patronymic naming in Russia and Iceland, family-name-first formats in China, Korea, and Japan, and married-name changes. Treat a partial match in any of these scenarios as a contextual signal, not a failure, and weight it based on what else you know about the user.

The scenarios where verification signals are most valuable

Quick summary: Verification earns its keep most clearly in five moments: guest checkout, card onboarding for payments, card onboarding for payouts, pre-authorization step-up, and 3DS exemption decisions. Each has a different reason why verification helps, and a different limitation when it's only available as part of your PSP.

Understanding what each signal tells you is useful. Understanding when to use them is what makes the difference in practice.

Guest checkout and first-time card use

This is the scenario where passive and behavioral signals are at their weakest. There's no prior transaction history to compare against, no stored device profile, no behavioral baseline. A fraudster using a stolen card for a one-off guest checkout looks identical to a legitimate first-time customer from a session perspective.

Cardholder verification fills exactly this gap. CVV is the most valuable signal here, providing a direct issuer-side check on whether the user has the physical card, independent of anything the session tells you. AVS adds a secondary signal. Name validation is less powerful without a KYC anchor but still useful as a consistency check. Phone and email, where the issuer supports them, add a further hard-to-forge check at no extra cost of friction, since the customer is entering these details anyway on most checkout forms.

This is one of the scenarios where PSP-bundled verification works reasonably well, since a payment is being processed and verification fires naturally as part of the authorization. The structural limitations of PSP verification are less acute here than in the onboarding and payout scenarios below.

Card onboarding for payments

When a card is saved to an account, on an e-commerce platform, subscription service, travel site, or marketplace, that's one of the highest-value intervention points in the payment lifecycle. Catch a fraudulent card at onboarding, and it never reaches checkout, never generates a chargeback, and never needs to be checked again.

CVV is the most important signal at onboarding, for the same reason it matters at guest checkout: breach dumps frequently exclude it.

This is where the structural limitation of PSP-bundled verification first becomes significant. PSP verification is tied to authorization and fires when a payment is processed. Verifying a card at onboarding would require triggering a payment, which isn't appropriate when the goal is just to validate a card before storing it. Companies relying solely on their PSP for verification have no mechanism to run these checks at onboarding, which puts one of the most cost-effective fraud prevention interventions in the payment lifecycle out of reach.

Standalone cardholder verification, decoupled from the payment flow, makes onboarding verification practical. The check runs independently, no payment is triggered, and the result is available before any decision is made about storing the card.

Card onboarding for payouts, with KYC

This is the strongest use case for the full combination of verification signals, and the one where getting it wrong is most costly. Unlike payments, where chargebacks provide a recovery mechanism, card payouts have no equivalent. Once funds are sent to the wrong card and settled, recovery is rarely possible. The loss falls directly on the platform.

Verifying a payout card at onboarding, before funds are ever sent, is the most important intervention point. Name validation combined with KYC identity documents is the most powerful ownership signal available: the issuer confirms the name matches its records, KYC confirms the name matches a verified identity, and together they establish card ownership in a way no other combination of signals replicates. CVV at onboarding adds an additional layer, confirming physical card possession before any payout is processed. AVS is a secondary signal, and phone or email, where available, adds further corroboration against the account holder's other known contact details.

The same logic applies any time a new payout card enters the picture, not just at initial onboarding. If an account adds a second card, or changes its payout destination, that new card should go through the same check before it's used, for the same reason: it's new information the issuer hasn't confirmed yet. What doesn't warrant a re-check is the original, unchanged payout card being used again, however much time has passed or however large the withdrawal, since nothing about the card itself is different from the last time it was verified.

PSP verification can't support this scenario for two reasons. First, verification is tied to authorization and can't run before a payout without triggering a payment event. Second, most PSPs don't expose name validation, and effectively none expose phone or email verification, which removes the ownership signals that matter most for payout confirmation. A company using only PSP verification for payout card onboarding is operating without its most important tools.

Pre-authorization step-up

A common and effective pattern:

Run lightweight fraud checks first, looking at things like BIN data, IP, device, and velocity to generate a risk score. From there, use cardholder verification as a conditional step-up for medium-risk transactions before deciding whether to approve, escalate to 3DS, or decline.

This adds an authoritative issuer signal at the moment of decision without adding friction to low-risk transactions. It's particularly useful where passive signals are generating uncertainty rather than a clear signal: high-risk geographies, unfamiliar devices, medium-confidence fraud scores, or guest checkout with no account history.

PSP verification can support this pattern during a transaction, since a payment is being processed, though most PSPs won't expose name, phone, or email validation as part of it. The limitation shows up in multi-PSP environments, where a failed transaction is retried through a different processor. Each processor runs verification as part of its own authorization, so the same card gets re-verified on every retry rather than carrying a result forward. In a flow where the speed of the fraud decision matters, that added latency on every retry is a real cost.

3DS exemption evidence

Where 3DS is in use, cardholder verification signals can inform how it's applied. A strong match, particularly on CVV and name, gives you the confidence to approve a transaction without authentication where that's possible.

Where 3DS is mandatory, a verification match is concrete issuer evidence that the cardholder details are legitimate, exactly the kind of supporting signal that strengthens a Transaction Risk Analysis exemption request. A mismatch tells you clearly when a challenge is warranted, and when not to seek an exemption.

What verification signals can't tell you

It's worth stating the boundary explicitly, because it's easy to reach for verification in a scenario it isn't built for.

Verification only ever checks whether the details submitted right now match the issuer's record. It has no visibility into device, IP address, location, or account history, and no memory of anything beyond the current check. That means a card that verified cleanly once will verify exactly the same way every time after, as long as the submitted details themselves haven't changed, regardless of what's happened to the account in between.

This matters because account takeover is a common and real fraud pattern, but it isn't one verification can catch. If an attacker takes over an account and simply uses the card, phone number, and email already saved there, nothing about those details has changed. Re-running verification returns the same match it always returned, because the check has nothing new to evaluate. The compromise is in the session: a new device, a new login pattern, a password reset, not in the details on file, and verification doesn't look at any of that.

The trigger worth watching for isn't a change in context. It's a change in the details themselves: a card reissue, an updated expiry, a new phone number or email added to the account, or a new card being used for the first time. Any of those genuinely present new information for verification to check. A takeover using unchanged, previously verified details doesn't, no matter how suspicious the account otherwise looks, and closing that gap needs a device, location, or login-based signal instead.

How to weight verification signals in your fraud model

Quick summary: CVV: highest weight, hard signal. Address: medium weight, context-dependent, never a standalone gate. Name: highest weight with KYC, moderate without. Phone and email: high weight when returned, but a missing result means nothing, not that something's wrong.

Bringing the signal-specific analysis together into a practical framework:

CVV carries the highest weight as a hard signal. A mismatch is a high-confidence fraud indicator in most scenarios, most likely explained by the user not having the physical card. A match raises confidence meaningfully, particularly where the fraud pattern involves breach dump data that typically excludes CVV. Use a CVV mismatch as a hard block in most scenarios, and treat a match as a strong positive signal that raises overall confidence.

Address is a medium-weight, context-dependent signal. A full mismatch on both street and postcode in a strong AVS market, combined with other risk signals, is worth acting on. A partial match in isolation, or any result from outside the US, UK, and Canada, should adjust a risk score rather than trigger a hard decision. Never use AVS as a standalone gate.

Name validation carries the highest weight when anchored to KYC and lower weight without it. Without a verified identity source, name validation confirms cardholder details are internally consistent, useful but not ownership-confirming. With KYC, it becomes one of the strongest signals available. Weight it high in KYC-anchored payout flows, moderate as a consistency check in payment flows without identity verification.

Phone and email are high-weight when returned, but treat their absence as neutral, not suspicious. Because a fraudster is unlikely to have the cardholder's real phone number or email on file with the issuer, a match is a strong positive signal, closer to CVV than to AVS in reliability. But given how often the issuer simply doesn't support the check yet, a missing result tells you nothing about risk. Don't penalize a transaction for a signal your issuer never had the ability to return.

Reading your verification results

Why PSP-bundled verification limits the value of these signals, and what you get with standalone solutions

Most companies access cardholder verification through their payment processor. PSPs expose AVS and CVV as part of standard payment processing, and for basic checkout validation in simple payment flows, that's often sufficient. But the way PSP verification is architected creates a fundamental constraint: it's only available during an authorization.

Verification fires when a payment is processed through the processor handling that specific payment. It can't be triggered independently. It can't run at card onboarding without simulating a payment. It can't run before a payout, where there's no authorization event. It can't carry results across processors in a multi-PSP environment. And most PSPs don't expose name validation at all, and essentially none expose phone or email verification, removing the strongest ownership signals from the picture entirely.

Standalone verification decouples the check from the payment entirely, making the signal available whenever it's needed: at onboarding, before a payout, at transaction time, consistently across every processor. CVV becomes usable the moment a card is first stored, before it ever reaches a transaction. Name, phone, and email validation become accessible, which is what makes the ownership confirmation question answerable in payout flows. And verification results are no longer tied to a single processor or a single point in time.

That's the difference between using cardholder verification as a byproduct of payment processing, and using it as a deliberate tool in a fraud model that applies each signal at the moment it's actually valuable.

Evervault Cardholder Verification provides standalone access to address, CVV, name, phone, and email verification signals, independent of your payment processor and usable at any point in the card lifecycle. Learn more or talk to our team.