What is AVS (Address Verification System)?
AVS is a card-not-present fraud control that simply asks the issuing bank: “Does the billing address
the buyer typed in match the one on file for this card?” The issuer replies with a short code—full match, ZIP-only
match, street-only match, no match, unavailable. Simple. Fast. Imperfect.
Where it shines: catching low-effort fraud and fat-fingered entries before authorization settles. A full match
boosts confidence; a mismatch in a risky context can justify declines, step-ups, or holds. AVS is cheap signal,
not gospel. Treat it that way.
Limits you must design around:
- Coverage: strongest in the U.S., Canada, U.K.; spotty elsewhere. Some issuers don’t support it; some
merchants never request it.
- Granularity: it validates numeric street and postal code—names and apartment numbers often get ignored,
so “partial matches” are common.
- Use cases: prepaid cards, corporate cards, and cross-border transactions may return “unavailable,” which
is not the same as “bad.”
- Shipping ≠ billing: perfect AVS doesn’t prove the parcel went to a safe place; it proves the cardholder’s
billing data aligned.
How to use it well: normalize addresses before sending (standardize abbreviations, strip punctuation), request
AVS on first use and high-risk events, and combine outcomes with other signals—CVV result, device and IP risk,
velocity, 3-DS frictionless/step-up, historical dispute rate by BIN or merchant category. Tighten controls when
AVS says “no match” and the rest of the story looks off; loosen when you have a full match plus clean context.
For physical goods, compare AVS to delivery patterns and return history. For digital, watch geovelocity and
instant consumption.
Remember, AVS checks a billing claim. KYC’s proof of residence is a different game entirely—see proof of address. For checkout-layer defenses and playbooks that pair AVS with layered controls, explore our payment fraud prevention guidance.
