Minnesota's MCDPA Has Been Enforcing Since January — Your GLBA Exemption Doesn't Cover What You Think It Does

TL;DR

• Minnesota’s MCDPA uses a data-level GLBA exemption — non-bank fintechs are covered for all personal data outside GLBA’s financial data scope, even if their core business is a financial product
• The cure period ended January 30, 2026; the Minnesota AG has been enforcing without notice-to-cure since January 31
• Mortgage companies, payment apps, BNPL providers, and PFM platforms are among the most exposed non-bank financial entities
• Data protection assessments, DSAR infrastructure, and opt-in consent for sensitive data are the highest-priority compliance gaps

The Minnesota Consumer Data Privacy Act went into effect for large processors on July 31, 2025. Since January 31, 2026, it’s been fully enforcing against everyone in scope — with no notice-to-cure and a $7,500-per-violation ceiling that doesn’t scale down for smaller companies.

If you’re a non-bank fintech serving Minnesota consumers, the GLBA exemption is real. It just doesn’t cover what most compliance teams assume it covers.

The MCDPA GLBA Exemption — What “Data-Level” Actually Means

Every comprehensive state privacy law has some version of a GLBA carve-out. The critical variable is what form that exemption takes.

Entity-level exemption: If your company is a GLBA-covered financial institution, the entire state privacy law doesn’t apply to you. Virginia’s CDPA and most early state privacy laws used this approach — GLBA-covered entity, out of scope entirely.

Data-level exemption: Personal data that is regulated under GLBA is exempt. Everything else you collect is subject to the state law. This is what Minnesota’s MCDPA (Minnesota Statutes Chapter 325O) uses — and it’s what Texas’s TDPSA and several newer state laws have adopted.

The MCDPA expressly exempts:

Personal data that is subject to and collected, processed, sold, or disclosed pursuant to the Gramm-Leach-Bliley Act and implementing regulations.

Read that carefully: personal data subject to and collected pursuant to GLBA. Not “personal data collected by a GLBA-covered entity.”

That single word choice — “data” not “entity” — is what catches non-bank fintechs. You can be unambiguously GLBA-covered for your core financial product and still have the vast majority of your personal data collection sitting outside the GLBA exemption.

What Falls Inside (and Outside) the GLBA Perimeter

GLBA’s “nonpublic personal information” definition covers financial information obtained in the context of providing a financial product or service: loan applications, account information, transaction histories, payment data directly tied to financial products. That’s the core of what GLBA covers.

What isn’t GLBA-covered NPI:

• App usage data, session logs, click-stream behavior
• Device identifiers and advertising IDs (IDFA, GAID)
• Location data not directly tied to a specific financial transaction
• Inferred financial attributes, spending category classifications, and financial health scores
• Marketing preferences and engagement history
• Purchase pattern analysis derived from aggregated transaction data
• Employee data (if you’re processing HR data for employees who happen to be in Minnesota)

For a traditional bank, the gap between entity-level and data-level exemptions is often small in practice — most of what they collect is GLBA-covered financial data. For a non-bank fintech, the gap can be enormous.

The Fintechs Most Exposed

Mortgage companies and non-depository lenders. Your loan origination data is GLBA-covered. Your app analytics, behavioral data, marketing attribution, and browsing data from users who visited but didn’t apply — all MCDPA. The origination funnel data above the loan application sits outside the GLBA perimeter.

Payment and wallet apps. Transaction records may be GLBA-covered. Click-stream behavior, merchant category enrichment, purchase pattern inferences, device identifiers, and loyalty or rewards data almost certainly aren’t. If you’re building a behavioral profile from payment activity to drive marketing or product recommendations, that profile lives outside GLBA.

Personal financial management platforms. You aggregate GLBA-covered account data via data aggregation. The analytics layer — spending category assignments, savings recommendations, financial health scores, budget forecasts — lives outside GLBA’s scope and squarely inside MCDPA’s.

BNPL providers. The CFPB’s 2024 interpretive rule brought BNPL under Reg Z, expanding GLBA coverage for the credit transaction itself. But behavioral data collected for underwriting, marketing, and user experience — particularly data collected before or between transactions — isn’t covered.

Earned wage access providers. Wage advance data may or may not be GLBA-covered depending on product characterization. Either way, app engagement data, usage patterns, marketing analytics, and employer data sit outside the GLBA perimeter.

The pattern: non-bank fintechs have large swaths of personal data collected from Minnesota consumers — behavioral, marketing, device, location — that fall completely outside the GLBA perimeter. That data is subject to MCDPA.

What MCDPA Compliance Requires for Non-GLBA Data

For personal data that doesn’t qualify for the GLBA exemption, the MCDPA imposes the full consumer rights and controller obligation framework.

Consumer Rights You Must Honor

Minnesota consumers have the right to:

• Access: Request a copy of personal data you hold. You have 45 days to respond, extendable to 90 days with written notice of the reason.
• Correction: Request correction of inaccurate personal data. You must take action and inform the consumer of the outcome.
• Deletion: Request deletion of their personal data. You must delete or de-identify and notify downstream processors.
• Portability: Receive their personal data in a portable, readily usable format.
• Opt-out: Opt out of targeted advertising, sale of personal data, and profiling used for consequential decisions.

Your DSAR response process needs to handle all five for data that falls outside the GLBA exemption. If your existing DSAR infrastructure was built for CCPA, the workflows differ — timelines, definitions of “personal data,” and deletion scope all need a Minnesota-specific layer. For a detailed look at building state-law DSAR workflows, see DSAR Response Workflow for CCPA, GDPR, and State Privacy Laws.

Controller Obligations

Data minimization. You may only collect personal data that is adequate, relevant, and reasonably necessary for the disclosed purpose. If your analytics stack is collecting data that your team would struggle to justify as “necessary” for any disclosed use, that’s your first gap.

Purpose limitation. Processing personal data for purposes incompatible with what you disclosed when collecting it is a violation — regardless of whether the new purpose would otherwise be permissible.

Sensitive data consent. Biometric identifiers, precise geolocation data, and certain health information are “sensitive data” under MCDPA and require opt-in consent rather than just an opt-out mechanism. Fintechs using biometric authentication (Face ID, fingerprint for app login), collecting precise location for fraud detection, or handling health-related financial products need an opt-in consent flow for these data categories for Minnesota consumers.

Privacy notice requirements. Your privacy policy must include specific disclosures required by MCDPA. Most CCPA-tuned privacy notices have material gaps relative to MCDPA’s required content — particularly around sensitive data, data protection assessments, and the Minnesota-specific consumer rights framework.

Data protection assessments. For processing activities presenting heightened risk — targeted advertising, sale of personal data, profiling for consequential decisions, sensitive data processing — MCDPA requires a documented data protection assessment. This is a documented risk evaluation that must exist before the processing activity starts, not something assembled in response to an enforcement inquiry.

Enforcement Without a Cure Period

The MCDPA’s notice-to-cure period — a 30-day window in which companies could fix alleged violations before the AG filed an enforcement action — expired January 30, 2026.

Since January 31, the Minnesota Attorney General can file an enforcement action immediately upon finding a violation. No 30-day letter. No opportunity to remediate before the action drops.

Civil penalties: up to $7,500 per violation. In state privacy enforcement, “per violation” has typically been interpreted as per affected consumer per violation type — which makes the exposure scale quickly when a misconfigured marketing data flow affects thousands of Minnesota consumers over months.

Minnesota also isn’t doing this alone. The multi-state AG enforcement consortium that launched in early 2026 has enabled coordinated enforcement across state AGs, particularly targeting companies operating across multiple state jurisdictions. A company out of compliance with MCDPA may have simultaneous exposure in Texas, Virginia, and other states. See State Privacy Law Enforcement in 2026: Texas, California, and the AG Consortium for how coordinated enforcement is developing.

How MCDPA Compares to Texas TDPSA for Fintechs

Minnesota and Texas both adopted data-level GLBA exemptions — a different approach than Virginia (entity-level), which means both are particularly significant for non-bank fintechs. Here’s how they compare on dimensions that matter most:

Texas still has a cure period. Minnesota doesn’t. For Texas-specific GLBA exemption analysis, see Texas TDPSA and the GLBA Exemption: What Financial Services Companies Got Wrong.

The broader pattern of data-level GLBA exemptions eroding the entity-level protection that financial services companies have historically relied on is examined in GLBA Safe Harbor and State Privacy Laws: What Financial Institutions Need to Know in 2026.

Five Steps to Assess Your MCDPA Exposure

If your team hasn’t done a formal MCDPA gap assessment, here’s how to prioritize the work:

1. Map your data inventory against the GLBA perimeter. This is a categorization exercise: go through your data inventory for Minnesota resident data and identify which personal data categories fall outside GLBA’s NPI scope. That’s your MCDPA exposure universe. The output is a list of data categories and their regulatory status — GLBA-exempt or MCDPA-covered.

2. Check your privacy notice for MCDPA-required disclosures. The Minnesota AG has indicated that privacy notice adequacy is an enforcement focus. If your notice was written for CCPA, it likely has material gaps relative to MCDPA’s required content.

3. Evaluate your DSAR infrastructure for MCDPA scope and timelines. Can your system respond to Minnesota-specific access, correction, deletion, and portability requests within 45 days? The clock started July 31, 2025. If requests have come in and you don’t have a documented response process, that’s accrued exposure.

4. Identify sensitive data processing. Are you collecting biometric identifiers, precise geolocation, or health information from Minnesota consumers? If yes, do you have opt-in consent mechanisms in place? Processing any of these without opt-in consent is a direct MCDPA violation — this is your highest-priority gap if it exists.

5. Build your data protection assessments. Targeted advertising, data sales, profiling for consequential decisions — each requires a documented DPA for activities involving Minnesota consumers. If you’re doing any of these without a completed assessment, you’re currently out of compliance.

The Practical Reality

The GLBA exemption in the MCDPA is real and meaningful for financial data — loan applications, account information, transaction histories. For your marketing data, behavioral analytics, device identifiers, and app usage data, it doesn’t apply.

The Minnesota AG isn’t sending warning letters. Since January 31, the process starts with the enforcement action.

The gap assessment isn’t complicated. The data protection assessment isn’t complicated. What makes this hard is that compliance teams assumed the GLBA exemption covered more than it does, and didn’t prioritize the non-GLBA data inventory.

Do the categorization exercise. Find your MCDPA exposure universe. Prioritize sensitive data consent and data protection assessments for high-risk processing. Your privacy notice and DSAR infrastructure are the next two gaps to close.

Key Sources

• Minnesota Consumer Data Privacy Act — Minn. Stat. Chapter 325O (revisor.mn.gov)
• Minnesota Attorney General — Data Privacy (ag.state.mn.us)
• FTC — Gramm-Leach-Bliley Act (ftc.gov)
• CFPB — GLBA Regulation P Compliance Resources (consumerfinance.gov)