NPPI stands for Nonpublic Personal Information. It is the personal financial data that the Gramm-Leach-Bliley Act (GLBA) requires financial institutions to protect: account numbers, balances, transaction history, loan and credit applications, and anything else a person hands over, or a company collects, in the course of providing a financial product or service.
If you searched for “NPPI” and just wanted the definition, that is it. The rest of this guide is the part that actually matters for engineers and compliance leads: what counts as NPPI, what is specifically excluded, how it differs from PII and PHI, and how to find and redact it in production systems.
The precise definition
GLBA defines NPPI in two layers, and the nuance is in the second one.
First, personally identifiable financial information (PIFI): any information a consumer provides to obtain a financial product or service, any information about a transaction between the consumer and the institution, and any information the institution otherwise obtains about the consumer in connection with providing that product or service.
Second, NPPI is PIFI plus any list, description, or grouping of consumers that is derived using PIFI and is not publicly available. So a spreadsheet of “customers who took out a mortgage in 2025” is NPPI even though “took out a mortgage” sounds like a category rather than a data point, because the list was derived from financial information.
Defined by: the Gramm-Leach-Bliley Act (15 USC 6801 to 6809), implemented through the GLBA Privacy Rule (16 CFR Part 313 and the CFPB’s Regulation P at 12 CFR Part 1016) and the Safeguards Rule (16 CFR Part 314, updated 2023).
What counts as NPPI
In practice, the entity types that show up in NPPI workloads are:
- Account numbers of every kind: checking, savings, brokerage, loan, and credit card (PANs).
- Routing and transit numbers, IBANs, and other payment identifiers.
- Balances, transaction history, and statements.
- Credit and loan data: applications, scores, decisions, and mortgage files.
- Tax records and income information collected to underwrite a product.
- The customer’s identity fields when collected in a financial context: name, address, SSN, date of birth, phone, and email tied to an account.
The last point is the one engineers miss. A name and a SSN are ordinary PII in the abstract. The moment they sit in a customer record at a bank or an insurer, they are NPPI, and the GLBA controls attach.
What is NOT NPPI: the publicly available exclusion
GLBA carves out publicly available information: data the institution reasonably believes is lawfully made available from federal, state, or local government records (property records, certain court filings), from widely distributed media, or from disclosures legally required to be made public.
The catch is that the exclusion applies to the information, not to the list. If you publish a list of your customers and the fact that they are your customers is not public, the list is still NPPI even if each name appears in a phone book somewhere. The derived-list rule overrides the surface-level public availability of the individual fields.
NPPI vs PII vs PHI
NPPI is one of two well-known financial-or-health subsets of the broad PII umbrella:
┌─────────────────────────────────────┐
│ PII │
│ (the broad umbrella; NIST, │
│ GDPR, state laws) │
│ │
│ ┌──────────────┐ ┌──────────┐ │
│ │ PHI │ │ NPPI │ │
│ │ (HIPAA) │ │ (GLBA, │ │
│ │ │ │ PCI) │ │
│ └──────────────┘ └──────────┘ │
│ │
└─────────────────────────────────────┘
- PII is any data that identifies a person. It is the default assumption for any pipeline.
- PHI is the health subset, governed by HIPAA.
- NPPI is the financial subset, governed by GLBA (and overlapping with PCI DSS for cardholder data).
The distinction is not academic: each regime brings a different set of identifiers, controls, breach-notification timelines, and audit deliverables. For the side-by-side breakdown of all three, read PII vs PHI vs NPPI: An Engineer’s Guide.
Why the term matters
GLBA’s definition of a financial institution is far broader than “bank.” It reaches insurers, lenders, mortgage brokers, tax preparers, debt collectors, financial advisors, check cashers, and a large share of fintech. If you offer a financial product or service to consumers, you handle NPPI, and two rules apply:
- The Privacy Rule governs how you share NPPI with third parties and what notices and opt-outs you owe consumers.
- The Safeguards Rule (updated in 2023) requires a written information security program with specific technical controls: access controls, encryption of NPPI in transit and at rest, and monitoring. Redacting NPPI before it propagates into logs, analytics stores, test environments, and LLM prompts is one of the most direct ways to shrink the surface that the Safeguards Rule applies to.
How to find and redact NPPI
The architectural pattern is the same one PHI workloads use: detect NPPI at the boundary and strip it before the data reaches any system that does not strictly need the raw values.
- Discover where it lives. Use Phinder to scan data stores and surface the account numbers, SSNs, and customer records hiding in places you did not expect (log files, support tickets, free-text notes).
- Redact at the boundary. Run text through Philter with a GLBA-tuned policy. The GLBA NPPI redaction policy is a ready-made starting point that covers customer identifiers, account and routing numbers, IBANs, credit cards, and loan data, with format-preserving options so a redacted account number still validates downstream.
- Measure it. Use Philter Scope to evaluate precision and recall on your own data, so you can show an examiner that the redaction actually catches what the policy claims.
The same engine that handles a HIPAA Safe Harbor workload handles a GLBA workload. The difference is the policy file and the audit story, not the deployment. The financial-services pipeline pattern walks through the whole thing, and the finance use case shows where it fits in a real institution.
If you are scoping an NPPI workload and want help building the policy or deciding which controls apply, get in touch. It is one of the most common questions our consulting engagements start with.