Join our Newsletter — 33% off our NHI Course

Fullz

Fullz is criminal slang for a complete set of personally identifiable information used to commit identity theft or payment fraud. It commonly includes names, addresses, card numbers, security codes, and expiration dates. Because it packages enough data to impersonate a victim, it lowers the effort required for fraud.

What Fullz Means in Criminal Markets

In fraud ecosystems, fullz refers to a packaged identity record sold or traded because it is immediately usable for account takeover, payment fraud, or synthetic identity abuse. The value is in completeness: the more fields included, the easier it becomes to impersonate a victim or pass weak verification checks.

That completeness also makes fullz more than a loose collection of stolen data. It is a fraud-enablement artifact, typically assembled from breaches, phishing, malware, card skimming, data broker leakage, and other sources that can be combined into a single operational bundle.

What Information Fullz Commonly Contains

A fullz package usually includes core identity details such as a name, address, date of birth, and government identifiers, plus payment data like card numbers, expiration dates, and security codes when the use case is card fraud. Some sets also add email addresses, phone numbers, account credentials, and answers to knowledge-based questions.

The exact contents vary by criminal need and by what the seller was able to collect. A partial record may still be valuable, but a more complete record increases the chance that downstream fraud will work with less friction.

The term is not a formal legal or technical category. It is criminal slang, so usage can vary across forums and marketplaces, but the security meaning is stable: a usable identity bundle built for abuse.

Why Fullz Matter to Fraud and Security Teams

Fullz matter because they compress multiple attack prerequisites into one purchaseable package. Instead of collecting each data element separately, an attacker can move faster from data theft to impersonation, which raises the likelihood of successful fraud and reduces the defender’s response window.

This is why fullz are often associated with identity theft, card-not-present fraud, account opening abuse, and account recovery abuse. The presence of a fullz record usually indicates that sensitive personal data has already been exposed and can now be operationalised by another party.

For defenders, the term is useful because it points to a class of abuse, not just isolated stolen records. It suggests that controls must address data collection, credential abuse, fraud detection, and verification weakness together rather than as separate problems.

How Fullz Are Used in Fraud Workflows

In practice, fullz support several steps in a fraud workflow. A buyer may use the data to answer verification prompts, open new accounts, reset existing accounts, or authorise purchases that appear consistent with the victim’s profile. In some cases, the package is paired with stolen credentials or one-time access paths to create a more convincing impersonation attempt.

The underlying security issue is not only theft of data, but reuse of data across systems that treat personal information as a proof signal. Where verification relies on static or widely exposed fields, a fullz package can defeat the process even without direct access to the original victim’s mailbox or device.

That is why fullz are tied to fraud economics. They reduce manual effort for the attacker and can be traded repeatedly until the compromised details stop working or the victim’s accounts are locked down.

Risk and Threat Considerations

Fullz create a direct identity theft and fraud risk because they give attackers enough structured information to impersonate a real person at scale. The same package can be reused across multiple services, so one disclosure can produce many downstream abuse attempts.

Failure mechanism: Static personal data, weak verification logic, and data aggregation allow stolen identity attributes to be replayed as proof of legitimacy, especially where organisations rely on knowledge-based checks or low-friction account recovery.

Impact: Victims can face account takeover, unauthorised purchases, new-account fraud, tax or benefits abuse, and longer recovery times, while organisations absorb chargebacks, manual review costs, and trust erosion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AA-05 — Identity Management, Authentication, and Access Control Fullz abuse exploits weak identity proofing and access checks.
Recommendation — Strengthen identity verification and access controls to reduce fraud enabled by stolen identity bundles.
NIST SP 800-53 Rev 5 IA-8 — Identification and Authentication (Non-Organizational Users) Fullz are used to impersonate external users and bypass account controls.
IA-12 — Identity Proofing Fullz often defeat weak proofing by supplying enough personal data for false enrollment.
Recommendation — Use stronger external-user authentication and proofing to resist impersonation with stolen identity data. Harden identity proofing so personal data alone cannot establish a trusted account.
OWASP API Security Top 10 API2 — Broken Authentication Fraud using fullz often succeeds when authentication relies on exposed or replayable data.
API6 — Unrestricted Access to Sensitive Business Flows Account opening and recovery flows are common abuse targets for fullz-driven fraud.
Recommendation — Require stronger authentication paths that cannot be satisfied by stolen identity attributes. Protect high-value account flows with step-up checks and tighter abuse detection.
CIS Controls v8 CIS-6 — Access Control Management Fullz abuse is enabled when access decisions rely on weak identity evidence.
Recommendation — Tighten access-control decisions for account creation, recovery, and sensitive transactions.