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

Negative List

Also known as: Blocklist, Deny List
Simply put

In payments and fraud prevention, a negative list is a record of users, devices, IP addresses, or payment methods that have previously been linked to fraud, chargebacks, or other abuse. When a new transaction matches an entry on the list, it can be flagged, declined, or sent for additional review. The term is also used in unrelated contexts, such as trade and foreign investment policy, where it means something different.

Formal definition

In a fraud-prevention context, a negative list is a maintained set of identifiers—such as user accounts, device fingerprints, IP addresses, email addresses, or payment instruments—previously associated with fraud, chargebacks, or other disallowed activity, against which incoming transactions or authentication attempts are matched to block or escalate them. It is a rules-based screening control and should be distinguished from broader risk-scoring or behavioral analytics. As a detection mechanism it is subject to false-positive and false-negative trade-offs: stale or overly broad entries can block legitimate customers, while fraudsters who rotate identifiers (new cards, devices, or IPs) can evade static matching, so a negative list is intended to help reduce repeat abuse rather than eliminate fraud on its own. Note that identifiers used for matching may include or derive from cardholder data or personal data, so their storage and handling may fall within PCI DSS or applicable privacy scope depending on implementation; validate against the current published standard. The term 'negative list' is also used, unrelated to payments, in trade and foreign-investment policy (for example China's foreign-investment negative list) to enumerate prohibited or restricted sectors—these usages should not be conflated.

Why it matters

Repeat abuse is a persistent challenge in fraud prevention: a fraudster or abusive customer who succeeds once often returns using the same account, device, email address, or payment instrument. A negative list gives fraud teams a direct, rules-based way to remember prior bad actors and act on that memory, so that an identifier previously linked to fraud, chargebacks, or other abuse can be flagged, declined, or routed for additional review the next time it appears. This makes it a practical first line of defense against known repeat offenders and a way to reduce the operational burden of re-investigating identities that have already been judged harmful.

The control has important limitations that shape how it should be relied upon. As a static, match-based mechanism it is subject to false-positive and false-negative trade-offs. Stale or overly broad entries can block legitimate customers—for example, when an IP address or device is shared across many users, or when an entry is never reviewed and removed—while fraudsters who rotate identifiers by acquiring new cards, devices, or IP addresses can evade matching entirely. For this reason a negative list is intended to help reduce repeat abuse rather than to eliminate fraud on its own, and it is typically layered with broader risk-scoring and behavioral analytics rather than used in isolation.

Because the identifiers used for matching may include or derive from cardholder data or other personal data, the storage and handling of a negative list can fall within PCI DSS or applicable privacy scope depending on how it is implemented; teams should validate their handling against the current published standard. It is also worth noting that the phrase 'negative list' appears in an unrelated policy context—trade and foreign-investment regulation, such as China's foreign-investment negative list of prohibited or restricted sectors—which should not be conflated with the fraud-prevention usage described here.

Who it's relevant to

Fraud analysts and merchant risk teams
These teams build and maintain negative lists as part of their day-to-day screening rules, deciding which identifiers to add, how matches are actioned, and when entries should be reviewed or removed. They must balance blocking known repeat abusers against the risk of false positives that decline legitimate customers, and they typically pair the list with risk-scoring and behavioral analytics rather than relying on it alone.
Payment processors and acquirers
Processors and acquirers may operate or offer negative-list screening as part of transaction risk controls, matching incoming transactions against identifiers linked to prior fraud or chargebacks. They have an interest in the accuracy and freshness of these lists because overly broad entries can harm legitimate transaction flow while gaps allow repeat abuse to recur.
Compliance officers and security engineers
Because the identifiers stored on a negative list may include or derive from cardholder data or other personal data, those responsible for compliance and data handling need to assess whether the list's storage and processing falls within PCI DSS or applicable privacy scope. They should validate the implementation against the current published standard rather than assuming a fixed treatment.

Inside Negative List

Blocked card or account identifiers
Entries commonly include PANs, tokens, or card fingerprints previously associated with fraud, chargebacks, or policy violations. Where PANs are stored to support matching, they are cardholder data and must be protected under applicable controls; storing a hash or truncated value rather than the full PAN can reduce exposure depending on implementation and validation.
Blocked identity and contact attributes
Elements such as email addresses, billing or shipping addresses, phone numbers, and device or IP identifiers that have been linked to prior fraud, account takeover, or abuse and are used to decline or flag matching transactions.
Match and decline logic
The rules that determine how an incoming transaction is compared against listed values and what action results, such as automatic decline, hold for review, or added scrutiny. Matching sensitivity affects the balance between false positives and false negatives.
Provenance and expiry metadata
Contextual data for each entry, such as the reason it was added, the source, the date added, and any review or expiration schedule, supporting auditability and periodic cleanup of stale entries.

Common questions

Answers to the questions practitioners most commonly ask about Negative List.

Is a negative list the same thing as a blocklist for stolen cards?
Not exactly. A negative list is a broader concept: it is any list of identifiers that a merchant, processor, or fraud system uses to decline or flag transactions. Stolen or reported card numbers may populate one, but a negative list can also contain email addresses, device fingerprints, IP addresses, shipping addresses, or customer accounts previously associated with fraud or chargebacks. Treating it as only a stolen-card list understates its scope and the range of identifiers it may hold.
Does adding an identifier to a negative list guarantee that fraud from that source is stopped?
No. A negative list is intended to help reduce repeat fraud from previously observed bad identifiers, but it does not guarantee prevention. Fraudsters can rotate card numbers, emails, devices, and addresses, so a negative list is inherently backward-looking and may miss new identifiers. It also carries false-positive risk, since legitimate customers can be blocked if an identifier is shared, reassigned, or added in error. It is one input among several detection controls, not a standalone solution.
What kinds of identifiers should a negative list contain, and how do PAN entries interact with PCI DSS scope?
Common entries include card identifiers, email addresses, phone numbers, device fingerprints, IP addresses, shipping and billing addresses, and internal customer or account IDs. If a negative list stores primary account numbers, those PAN entries are cardholder data and bring the storage into PCI DSS scope, subject to the applicable protection requirements. Many implementations store a transformed value such as a hash or truncated form for matching rather than the full PAN; whether that reduces scope depends on the specific implementation and validation, not on the label alone. Confirm the applicable requirements against the current published standard.
How do you keep a negative list from generating excessive false positives?
False positives arise when shared or reassigned identifiers, such as recycled email addresses, dynamic IP addresses, or common shipping locations, are treated as inherently bad. Mitigations include preferring more specific identifiers over broad ones, combining a negative-list match with other risk signals rather than declining on a single match, and setting expiry or review dates so entries do not persist indefinitely. Monitoring the decline and false-positive rates attributable to the list helps tune it. Any trade-off between catching more fraud and blocking more legitimate customers depends on your data, thresholds, and review process.
How should entries be added to and removed from a negative list?
Establish documented criteria for what qualifies an identifier for addition, such as a confirmed fraud case or chargeback, and record the source and reason for each entry. Provide a removal or expiry process so entries do not remain permanently without justification, and a dispute or review path for legitimate customers who may have been added in error. Governance over who can add and remove entries, and logging of those changes, supports accountability and helps limit both stale entries and improper blocking.
How does a negative list fit alongside other fraud detection controls?
A negative list is typically one signal within a layered approach that may also include velocity checks, device intelligence, behavioral analytics, and authentication controls. Because it is backward-looking, it complements forward-looking controls that assess new or unseen activity. Using it as a contributing factor in a broader risk decision, rather than as an automatic decline on its own, generally balances its benefit against its false-positive risk. It does not address transaction-level authentication concerns, which are handled by separate controls.

Common misconceptions

A negative list prevents fraud on its own.
A negative list is a reactive control that may help reduce repeat abuse from previously seen identifiers, but it does not detect new or previously unseen fraud. It is one layer among others such as behavioral analytics, 3-D Secure, and manual review, and it carries both false-positive and false-negative trade-offs.
Storing full PANs on a negative list is outside PCI DSS scope because the purpose is fraud prevention.
PAN is cardholder data regardless of why it is stored. Systems that store, process, or transmit PANs are in scope for PCI DSS, and the applicable data-protection controls apply. Note that sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PIN blocks must not be retained after authorization even if encrypted, so such elements should not appear on a negative list. Confirm current requirement wording against the published PCI DSS standard.
Hashing or truncating list entries removes all compliance obligations.
Hashing, truncation, and masking transform data differently and their effect on scope depends on implementation and validation, not on the label. A weak or reversible transformation, or storing both a hash and other recoverable elements, may leave data in scope. Assess each approach against the applicable standard rather than assuming exclusion.

Best practices

Never place sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs or PIN blocks) on a negative list, since it must not be retained after authorization even when encrypted.
Where card identifiers must be matched, prefer storing a one-way hash or truncated value over the full PAN, and validate the approach against the applicable PCI DSS controls rather than assuming it removes scope.
Record provenance for every entry (reason, source, date added) and enforce a periodic review and expiration process to remove stale or unjustified entries that drive false positives.
Tune match sensitivity deliberately and monitor false-positive and false-negative rates, recognizing that overly aggressive matching can decline legitimate customers while loose matching misses repeat abuse.
Treat the negative list as one layer within a broader fraud program alongside controls such as behavioral analytics, device intelligence, 3-D Secure, and manual review, rather than as a standalone defense.
Restrict and log access to the negative list, especially where it contains cardholder data or personal contact attributes, and align retention and handling with applicable data-protection and PCI DSS requirements confirmed against the current published standard.