If you're a SaaS platform headquartered in California, or if you have California residents as users, you've probably already had a conversation about CCPA compliance. You updated your privacy policy, mapped your data flows, stood up a "Do Not Sell My Personal Information" link, and moved on.
Then you decided to add payments or lending. And now the data picture is materially different.
Financial data collected through payment processing and lending products sits in a different regulatory category than the operational data your SaaS was collecting before. CCPA as amended by CPRA introduces a "sensitive personal information" (SPI) category that didn't exist in the original 2018 statute — and financial account data fits squarely inside it. More importantly, adding a lending product may change your platform's status under federal law in ways that interact with your California obligations in non-obvious ways.
This article is not legal advice. It's a structured walkthrough of the specific CCPA/CPRA provisions that become relevant when a SaaS platform adds financial products, with practical steps for each. You should work through this with your privacy counsel before launching.
CCPA vs. CPRA: what actually changed for fintech use cases
CPRA, which amended CCPA and became fully operative on January 1, 2023, made several changes relevant to platforms handling financial data.
Sensitive personal information (SPI) as a new category: CPRA added a defined category of sensitive personal information, which includes financial account information — specifically, account numbers, debit or credit card numbers, and related access credentials. When your platform collects payment account numbers or processes loan-related financial data, that data is SPI under CPRA.
The SPI designation has two practical consequences: consumers have the right to limit the use of their SPI to purposes necessary to provide the service they requested, and you must disclose in your privacy policy that you collect SPI and for what purposes. If you're using financial data for purposes beyond the immediate service delivery (analytics, cross-product targeting, model training), that use requires either a purpose limitation disclosure or an opt-in, depending on the use.
Right to opt out of sharing (not just selling): CPRA added "sharing" — broadly, cross-context behavioral advertising — as a trigger for opt-out rights, alongside the original CCPA opt-out from "sale." For a SaaS platform adding financial products, this matters if you're sharing transaction data or financial behavioral signals with advertising partners or analytics vendors. It's easy to have this happen inadvertently through third-party pixels or analytics SDKs that touch pages where financial data is displayed.
Right to correct: CPRA added a right to correct inaccurate personal information (not just delete). For platforms handling financial records — loan terms, payment history, account balances — this creates a correction workflow obligation that didn't exist before 2023.
When your platform becomes a "financial institution" under GLBA
The Gramm-Leach-Bliley Act (GLBA) defines a "financial institution" broadly: any company significantly engaged in the business of providing financial products or services to consumers. If your SaaS platform is originating consumer loans, facilitating consumer payments, or brokering financial products, there's a reasonable argument that GLBA applies to your platform — not just to the bank partner behind your product.
Why does this matter for CCPA? Because GLBA has its own privacy and safeguards rules that exist separately from California state law. The GLBA Privacy Rule requires annual privacy notices to consumers and restricts sharing of nonpublic personal information (NPI) with nonaffiliated third parties. CCPA explicitly excludes from its scope "personal information that is collected, processed, sold, or disclosed pursuant to the federal Gramm-Leach-Bliley Act."
This carve-out sounds helpful, but it's narrower than it appears. The GLBA exclusion applies specifically to the financial data collected in the context of your financial services activity. Your platform likely collects other personal data — usage analytics, support interactions, operational data — that is not covered by the GLBA exclusion and remains subject to CCPA in full. Operating a GLBA-covered lending product doesn't make your entire data operation exempt from CCPA; it creates a segmented compliance picture where some data flows fall under GLBA and others under CCPA.
We're not saying GLBA coverage simplifies your obligations — it often adds them. We're saying that understanding which data flows are GLBA-governed vs. CCPA-governed requires an explicit mapping exercise before you launch financial products.
Practical checklist: what to update before launching
Privacy policy updates
Your existing SaaS privacy policy almost certainly needs to be revised when you add financial products. Minimum changes required under CPRA:
- Add a section disclosing that you collect sensitive personal information (financial account data) and specify the purposes for which it's used
- Add the right-to-limit-SPI-use disclosure and the mechanism for exercising it
- Update your data category disclosures to include financial transaction data, payment history, and loan-related information
- If you're subject to GLBA, add the required GLBA privacy notice (these can be combined into a single document with appropriate structuring)
Data mapping for financial data flows
Before you can update your privacy policy accurately, you need to know where financial data actually goes in your infrastructure. Common data flows that get missed:
- Does your data warehouse include financial transaction records? Who has access?
- Do third-party analytics or error monitoring tools (Mixpanel, Datadog, Sentry) potentially receive financial data through events or error payloads?
- Does your CRM receive customer financial status data (loan amounts, payment history)?
- What does your bank partner or BaaS provider do with the data they receive from your originations?
Consumer request handling
CPRA requires responding to consumer requests — access, deletion, correction, opt-out — within 45 days (with a single 45-day extension if notice is provided). For financial data, deletion requests create a tension with financial record retention requirements: federal and state regulations generally require retention of certain financial records for 5–7 years. You cannot simply delete loan origination records or payment history in response to a deletion request if that data falls under a financial record retention obligation.
Your consumer request handling workflow for financial-product data needs to document which records are exempt from deletion (and why), and communicate that to the consumer with a clear explanation. Saying "we cannot delete this record because it's required by applicable financial regulations" is compliant; silently not deleting it without disclosure is not.
Vendor DPA requirements
Every vendor that receives personal information from your platform — including financial data — needs a data processing agreement (DPA) that meets CPRA requirements. If your bank partner, lending infrastructure provider, or KYC vendor doesn't have a CPRA-compliant DPA, you're carrying privacy liability for their handling of data you sent them.
Review your DPAs with fintech infrastructure vendors specifically. Many standard vendor agreements were written before CPRA's SPI category existed and may not adequately address the obligations that category creates.
The intersection with state money transmission laws
CCPA/CPRA is not the only California-specific regulatory framework that becomes relevant when you add financial products. California's DFPI regulates money transmission, lending, and certain payment activities under the California Consumer Financial Protection Law (CCFPL). If your platform is acting as a money transmitter or a lender in California, DFPI registration or licensing requirements may apply independently of your CCPA obligations.
These aren't the same compliance workstream — CCPA is data privacy, DFPI licensing is financial services regulation — but they often get conflated or handled by the same counsel, and the overlap in timing means a platform launching financial features in California should address both in parallel.
The platforms that handle this transition cleanly tend to do two things: they treat the launch of financial products as a material change that triggers a full compliance review (not just an engineering sprint), and they involve privacy and regulatory counsel before the product launches rather than after the first consumer complaint arrives.