The Outlier Lab

Negative Lists and Deny Lists

Curated lists of identifiers tied to confirmed fraud. Used to block, review or score repeat actors, they work only with entry criteria, expiry, collision handling and an appeal path.

What it is

A negative list records identifiers the program has already tied to confirmed fraud, and it's the cheapest form of memory a fraud program has. It's usually the first control a team builds, and its cleanup often comes last. Most mature programs end up running several lists, each with a different job:

List typeActionExample entriesNotes
Hard denyBlock outrightPayout bank accounts confirmed as mule destinations; document numbers from confirmed synthetic identitiesKeep it small and high-precision. Every entry should carry evidence.
Review / watchRoute to review or step-upDevices linked to banned accounts; addresses tied to past claim abuseCarries most of the volume and tolerates moderate precision.
Score featureInput to a modelDistance to a listed entity, number of list hits, age of the hitLets weak list hits contribute without driving decisions.
Allow / trustedExempt from specific rulesVerified corporate payroll originators; long-tenured customers' bound devicesNeeds the same governance as deny lists. An allowlist is an attack surface.
Shared / consortiumAny of the aboveIndustry-reported mule accounts, scam payees, terminated merchantsQuality varies. Validate before you trust it. See Consortium and Data Sharing and External Intelligence Feeds.

What it stops (and what it doesn't)

Lists pay off most on identifiers that are expensive for the adversary to replace. That depends on the entity:

EntityReplacement cost to adversaryList value
Payout destination (bank account, card, wallet)High: each one needs an account at a regulated institution, often a muleHigh. Destinations are the bottleneck of cash-out. See Payee and Counterparty Risk.
Identity documents and SSNsHighHigh, but mind identity-theft victims whose real identifiers were misused
Physical addressMediumMedium. Apartment buildings, freight forwarders and shared housing cause collisions. See Address Risk Signals.
DeviceLow to mediumMedium. Decays quickly. See Device Fingerprinting and Device Reputation and Linkage.
PhoneLow to mediumMedium. Watch for recycled numbers. See Phone Risk Signals.
EmailLowLow as a block, useful as a feature. See Email Risk Signals.
IP addressVery lowLow. Carrier NAT, VPNs and mobile networks make IP blocks blunt. See IP Reputation and Proxy Detection.
Receipt or transaction fingerprintn/aHigh for duplicate detection in cashback. See Receipt and Purchase Verification.

Lists don't stop novel actors, and they're backward-looking by design. Adversaries respond predictably by rotating whatever is cheapest to rotate, which is acceptable, because a list's job is to make reuse expensive so that adversaries have to keep buying fresh identities and destinations. A list that isn't catching anything may be working, or it may have been routed around. Your measurement should tell the two apart.

Design considerations

Entry criteria. Write down what evidence puts an entity on each list: a confirmed fraud outcome, a chargeback reason, a closed investigation, a consortium report. "Analyst felt suspicious" belongs on a watch list with a short expiry, never on a hard deny. Tie each entry to a case ID in your Case Management Systems.

Entry metadata. Every entry needs a reason code, who added it, the source (internal case, consortium, partner), the date added, an expiry, and the linked case. Without these you can't audit, expire or defend an entry.

Expiry by entity type. Devices and IPs go stale in weeks to months. Bank accounts and documents last much longer. A list nobody expires grows until it's mostly noise, and its false positives pile up silently.

Normalization. Lists should match on canonical, resolved entities rather than raw strings. Do identifier normalization and entity resolution in your data layer (Fraud Data Architecture, Entity Link Analysis) so that trivially different representations of the same thing match. Details of normalization logic belong in members content.

Collisions. Shared and recycled identifiers produce false positives: family devices, campus Wi-Fi, carrier IP ranges, reassigned phone numbers, multi-unit addresses, a payment processor's pooled account numbers. Maintain a "known shared" exception set, and require multiple independent hits before a hard action.

Victim protection. When an ATO victim's real identifiers get listed because a fraudster used them, the victim gets locked out later. Distinguish actor-controlled identifiers (a mule's bank account) from victim-owned identifiers that were abused (the victim's own email). The latter should be watch-only, with a recovery path.

Hashing. Store sensitive identifiers (account numbers, document numbers) as keyed hashes, so list matching doesn't widen PII exposure. Use the same approach to share across business units or with partners.

Graph seeding. A listed entity is a seed for Graph Analytics. Every account within one or two hops of a listed payout destination deserves a look. See Playbook - Fraud Ring Investigation Members.

Edit rights. Adding and removing entries, especially on allowlists, changes outcomes. Changes should be logged, reviewed and restricted (Insider Access Controls, Rule Governance and Change Management).

Implementation path

StageWhat it looks likePrerequisites
CrawlOne table of blocked emails, devices and bank accounts checked at sign-up and payout; manual entry after confirmed casesCase outcomes recorded; a hook at sign-up and payout
WalkSeparate deny, watch and allow lists; reason codes, expiry and case links; normalized entities; list hits as rule inputs in the Rules Engine; collision exceptionsEntity resolution; rules engine; Case Management Systems
RunLists auto-populated from confirmed labels; graph expansion from listed seeds; consortium feeds with source-quality scoring; list hits as model features; precision tracked per list and per entity type; appeal and removal workflowGraph Analytics, Consortium and Data Sharing, Machine Learning Models

Customer friction and trade-offs

A hard deny adds no friction for everyone else and blocks the matched customer completely. The cost lands on false positives, who usually can't find out why they were blocked. Keep hard denies narrow. Route ambiguous hits to step-up or review rather than blocking. Give support a way to see that a list hit occurred, without the reason being disclosed to the customer, plus an escalation path for genuine customers to appeal.

Measuring effectiveness

  • Precision per list: share of list-hit decisions later confirmed as fraud. Sample hard-deny hits for QA review (Fraud QA Program).
  • Hit rate and trend per entity type: a sudden drop may mean adversaries rotated that identifier.
  • Incremental catch: fraud stopped only by the list, not by other rules or models.
  • Appeal overturn rate: how often listed entities are later cleared.
  • List age profile: share of entries past their intended expiry.
  • Time to list: from fraud confirmation to the list entry going live.

Common failure modes

  • Lists that only grow, with no expiry or owner.
  • Hard-blocking on cheap identifiers (IP, email), causing collateral damage with little deterrence.
  • Listing victims' identifiers after ATO.
  • No collision handling for shared infrastructure.
  • Allowlists that become permanent bypasses, especially "VIP" or "known good" lists nobody re-reviews.
  • Consortium data treated as ground truth without validating it.
  • Lists checked at sign-up but not at destination add or payout. Payout is where reuse matters most.

Regulatory and policy notes

  • Privacy. List data is personal data. Retention, purpose limitation and sharing need a legal basis. See Privacy and Data Use in Fraud Prevention.
  • Sanctions screening is a separate obligation. OFAC and similar screening isn't a fraud deny list and has its own requirements and governance.
  • Cross-institution sharing. BSA-covered financial institutions can share fraud indicators under the FinCEN 314(b) safe harbor. FinCEN's June 2026 fact sheet lists indicators such as multiple accounts sharing identifying information. Non-FIs need other legal bases. See Consortium and Data Sharing.
  • Account validation. Nacha's account validation resource center lists data-consortium services among the ways to validate first-use consumer accounts. These services are effectively shared positive and negative account-status lists. See Bank Account Ownership Verification.
  • FCRA when a third-party list drives a denial. Your own first-party list (built from your own transactions and experiences with the consumer) is excluded from the FCRA "consumer report" definition. A list assembled by a third party, or pooled across companies, and used to decide a consumer's eligibility can be a consumer report, making its supplier a consumer reporting agency. The CFPB treats checking-account screening companies this way: a bank that denies an account based on their report must send an adverse action notice naming the company and pointing to the consumer's right to a free copy and to dispute. Whether a specific vendor or consortium list crosses that line depends on how it's assembled and used, so get counsel's view per use case, and prefer routing third-party hits to review rather than automatic denial. The CFPB's 2024 proposal to extend FCRA to data brokers was withdrawn in May 2025, so the existing statutory line still governs.

Mechanisms addressed

Multi-Accounting · Account Farming and Resale · Money Mules · Payout Redirection · Fraud Rings and Collusion · Receipt Fraud (Cashback) · Sign-Up Bonus Abuse · Referral Abuse · Card Testing · Seller Non-Delivery and Fake Listings · Refund and Return Fraud · Authorized Push Payment (APP) Scams (scam payee lists)

Withdrawal and Payout Controls · Bank Account Ownership Verification · Rules Engine · Graph Analytics · Consortium and Data Sharing · Seller Onboarding and Reserves · KYC and Customer Identification Program (CIP) · Controls Index

Sources and further reading