Skip to main content
Commerce Security Authority
Category: Fraud Detection Analytics

Address Verification Service

Also known as: AVS, Address Verification System
Simply put

Address Verification Service (AVS) is a fraud-prevention tool that checks whether the billing address a customer provides matches the address the card issuer has on file for that cardholder. It is intended to help businesses detect potentially unauthorized card transactions and may help reduce certain fraud and chargebacks. It is one signal among many and does not, on its own, confirm cardholder identity or eliminate fraud.

Formal definition

AVS is a service offered through major card processors and networks that compares numeric elements of the customer-supplied billing address (typically the street number and postal/ZIP code) against the address data held by the card issuer, returning a response code that indicates full match, partial match, or no match. It is commonly applied in card-not-present transactions as one input to a risk-scoring or fraud-detection process and can help limit fraud and chargebacks when used effectively. AVS validates address data correspondence only; it does not authenticate the payment card, verify sensitive authentication data such as CVV2/CVC2/CID, or provide the cryptographic assurance associated with EMV chip authentication or 3-D Secure. Match logic, supported elements, and coverage vary by network and region, and AVS is subject to both false positives (legitimate mismatches from address changes or formatting) and false negatives, so it should be treated as a supporting control rather than a definitive fraud gate.

Why it matters

AVS gives merchants a low-friction signal for evaluating card-not-present transactions, where the physical card and cardholder are not present and traditional in-person checks are unavailable. By comparing the billing address supplied at checkout against the address the issuer holds on file, AVS can help businesses detect potentially unauthorized transactions and, when used effectively, may help limit certain fraud and chargebacks. This makes it a common input to risk-scoring and fraud-detection processes for online and telephone orders.

Its value depends on how it is used. AVS validates only the correspondence of address data — typically the street number and postal/ZIP code — and returns a response code indicating a full match, partial match, or no match. It does not authenticate the card itself, does not verify sensitive authentication data such as CVV2/CVC2/CID, and does not provide the cryptographic assurance associated with EMV chip authentication or 3-D Secure. Treating an AVS match as proof of cardholder identity overstates what the control can do.

AVS is also subject to error in both directions. False positives can arise from legitimate address changes or formatting differences, potentially declining valid orders, while false negatives can let fraudulent transactions through. Match logic, supported address elements, and coverage vary by network and region. For these reasons AVS is best treated as one supporting signal among many rather than a definitive fraud gate.

Who it's relevant to

Merchants and e-commerce operators
Businesses accepting card-not-present payments use AVS as a low-friction signal to help detect potentially unauthorized transactions and may reduce certain fraud and chargebacks. They should account for false positives from address changes or formatting when setting decline thresholds, and avoid treating an AVS match as confirmation of cardholder identity.
Fraud analysts and risk teams
AVS response codes serve as one input to risk-scoring and fraud-detection processes. Analysts should weigh AVS alongside other signals, understanding that it validates only address data correspondence and is subject to both false positives and false negatives, with match logic that varies by network and region.
Payment processors and acquirers
Processors and networks offer AVS and define the match logic, supported address elements, and coverage that determine how response codes are generated. They mediate the comparison between merchant-supplied address data and issuer records, and variation across networks and regions affects the results merchants receive.
Chargeback and dispute teams
AVS results can factor into dispute and chargeback handling, since the service is intended to help limit fraud and chargebacks when used effectively. Teams should note that chargeback rules and liability are governed by card brand and network rules, which vary by region and change over time, and that AVS alone does not determine dispute outcomes.

Inside AVS

Numeric Address Match
AVS compares the numeric portions of the billing address supplied during a transaction, typically the street number and the postal or ZIP code, against the values on file with the card issuer.
AVS Response Code
The issuer returns a code indicating the degree of match, for example full match of address and ZIP, partial match of one element, no match, or a response indicating AVS is unavailable or unsupported for the card or region.
Card-Not-Present Context
AVS is primarily used in card-not-present environments such as e-commerce and mail or telephone order transactions, where the physical card and cardholder are not present to be inspected.
Complementary Data Element to CVV2/CID Checks
AVS is often used alongside verification of the card verification value (CAV2/CVC2/CVV2/CID). These are distinct checks: AVS addresses billing address consistency while the card verification value addresses possession of the physical card at order time. Note that the card verification value is sensitive authentication data and must not be stored after authorization.
Issuer and Network Dependency
AVS support, coverage, and response semantics depend on the card issuer, the card brand or network, and the region. Availability and interpretation vary, and international transactions frequently return unsupported or unavailable results.

Common questions

Answers to the questions practitioners most commonly ask about AVS.

Does AVS verify the entire billing address, including the street name?
No. AVS compares only the numeric portions of the billing address, typically the street number and the ZIP or postal code, against what the card issuer has on file. It does not validate the street name, city, or the full textual address. Because of this, two different addresses that share the same numbers can produce a matching result, so AVS should be understood as a partial check rather than a confirmation that the full address is correct.
Does a successful AVS match prevent card-not-present fraud?
No. AVS is intended to help reduce certain card-not-present fraud risk by adding an address data point, but it does not prevent fraud. It does not authenticate the cardholder, and a fraudster who possesses the legitimate billing address, for example through data compromise or account takeover, can still obtain a match. AVS should be treated as one signal among several in a broader fraud-detection and risk-scoring strategy, not as a standalone control.
How should AVS response codes be incorporated into an authorization decision?
AVS returns a response code indicating the degree of match, such as full match of street number and postal code, partial match of one element, no match, or that AVS data was unavailable or unsupported. Merchants typically map these codes to risk-handling rules, for example approving on a full match, routing partial or no-match results to manual review or additional verification, and accounting for unavailable responses that may occur with certain issuers or regions. The specific codes and their meanings should be confirmed against your processor and card brand documentation, as they can vary.
What are the trade-offs of declining transactions solely on an AVS mismatch?
Declining strictly on AVS mismatch increases the risk of false positives, meaning legitimate customers may be rejected because of typos, recently moved addresses, issuer data that is out of date, or formatting differences. Conversely, approving all mismatches raises exposure to fraud and potential chargebacks. Many teams use AVS as a weighted input into a risk score or a step-up verification flow rather than a hard decline rule, balancing fraud reduction against acceptance-rate and customer-experience impacts.
Does AVS work for international transactions?
AVS support varies by issuer, region, and card brand, and it is more consistently available in some markets than others. Cross-border transactions may return an unavailable or unsupported response even when the address is valid, simply because the issuer does not participate in AVS or handles address formats differently. Implementations should handle unavailable responses explicitly and confirm regional support with the processor rather than assuming uniform behavior.
How does AVS relate to PCI DSS scope and data handling?
AVS involves the billing address rather than the primary account number, and address data is not sensitive authentication data. However, AVS requests and responses are typically transmitted as part of the authorization flow, so the systems and channels handling that flow, including any transmission of cardholder data, remain subject to the applicable PCI DSS requirements for protecting and controlling that data. You should confirm current requirement details against the published standard, as numbering and wording differ between versions.

Common misconceptions

A successful AVS match confirms the transaction is legitimate and prevents fraud.
AVS only compares billing address data supplied against issuer records; it does not confirm cardholder identity or card possession. It may help reduce certain card-not-present fraud but produces both false positives, such as legitimate customers with mismatched or foreign addresses, and false negatives, such as fraudsters who possess the correct billing address. It should be treated as one signal among several, not a guarantee.
AVS is a PCI DSS requirement or a compliance control.
AVS is a card-brand and issuer-supported fraud-mitigation tool, not a control defined by PCI DSS. It does not by itself reduce PCI DSS scope. Merchants should confirm any compliance obligations against the current published standards rather than assuming AVS satisfies them.
AVS works consistently for all cards and all countries.
AVS coverage and response codes vary by issuer, card brand, and region, and support is frequently limited or unavailable for international transactions. Relying on AVS as a uniform global check can incorrectly decline valid orders or fail to evaluate ones where AVS data is not returned.

Best practices

Use AVS as one input within a layered fraud-screening strategy alongside other signals such as card verification value checks, device and behavioral data, and velocity rules, rather than as a sole decision point.
Define AVS response-code handling policies that distinguish full match, partial match, no match, and unavailable or unsupported responses, and tune thresholds to balance fraud reduction against false-positive declines of legitimate customers.
Account for regional and issuer variability by adjusting AVS logic for international transactions where AVS coverage is limited or responses are commonly unavailable, to avoid unnecessarily declining valid orders.
Do not store the card verification value used alongside AVS after authorization, since it is sensitive authentication data, and confirm that AVS handling does not create prohibited storage of such data.
Do not treat AVS as a substitute for stronger authentication controls such as 3-D Secure or as a PCI DSS control; evaluate it separately for its intended purpose and document its role in fraud operations.
Monitor AVS decision outcomes over time, reviewing decline rates and confirmed fraud against AVS results, and recalibrate rules as issuer behavior, card-brand rules, and fraud patterns change.