You're a Fintech. You Probably Handle Financial Data. That Could Make You a Financial Institution.

There's a line I hear fairly often when I'm talking to founders and CTOs at fintech companies: "We don't actually handle the money, so the financial regulations don't really apply to us." And I get it, and I’ll even wrestle with the definition myself. If you're building the software layer that sits on top of a payment processor, or you're aggregating transaction data to surface insights, it feels like you're one step removed from the regulatory picture. But… you’re not.

The Gramm-Leach-Bliley Act, better known as GLBA, is a US federal law that most people associate with banks and credit unions. What catches a lot of technology companies off guard is how broadly the law defines a "financial institution." Under GLBA, the term applies to any company that is significantly engaged in financial activities, or whose services facilitate financial operations on behalf of entities that are financial institutions. That second part is the one that surprises people.

The FTC made this explicit in an enforcement action against a company called Dealerbuilt, a software provider that processed data for car dealerships. Dealerbuilt didn't lend money. It didn't take deposits. But because its software enabled dealers to extend credit to consumers, the FTC ruled that Dealerbuilt was itself a financial institution under GLBA. The company was on the hook for the law's privacy and security requirements as a result.

So if you're building payment infrastructure, facilitating lending decisions, aggregating consumer financial account data, or providing any kind of service that sits in the flow of financial activity, there's a reasonable chance GLBA applies to you. And that comes with real obligations: a written information security program, privacy notices to consumers, restrictions on how you share non-public personal information, and as of 2024, a breach notification requirement to the FTC within 30 days if 500 or more customers are affected.

Where State Laws Come Into It

Here's where things get genuinely complicated. Most US state privacy laws include some kind of carve-out for GLBA. The logic is that if you're already regulated by federal law, you shouldn't also have to comply with the state equivalent for the same data. But those carve-outs are not blanket exemptions, and they work differently from state to state.

California's CCPA, for example, does not offer a full entity-level exemption. It exempts specific data that is subject to GLBA, not the company as a whole. This means that if you're a fintech collecting data that falls outside GLBA's scope, such as information from website visitors who aren't customers, or your own employees, that data may still be subject to CCPA. The state law exemption only covers what GLBA already covers, and nothing more.

Other states like Virginia, Colorado, and Utah have taken a different approach, offering entity-level exemptions that apply to the whole institution rather than just specific data. If you're subject to GLBA in those states, you may be fully exempt from the state privacy law. But you can't assume that's universal, and as more states update their privacy laws, the landscape keeps shifting.

What this means in practice is that being subject to GLBA doesn't necessarily get you off the hook with state laws, and not being subject to GLBA doesn't mean you're free from them either. The two frameworks interact in ways that require you to understand both, not just one.

Why This Matters for Your Privacy Program

None of this is hypothetical. The FTC has shown it will go after non-bank companies that it considers financial institutions. The state attorneys general enforcing CCPA and similar laws are actively looking at the fintech space. And your enterprise clients, particularly if they're banks or financial institutions themselves, are increasingly asking pointed questions about your privacy and security posture in vendor assessments.

The starting point is a scoping exercise: does GLBA apply to you, and if so, in what scope? From there, you layer on the state privacy obligations that aren't displaced by GLBA, and you build a program that covers both. It's not the most elegant system, but it is the system that exists right now.

Legal counsel with financial services experience is genuinely useful here because the classification questions can be subtle. But the privacy engineering work that follows, actually building the data mapping, the security program, the consumer notice infrastructure, the incident response capability, is where I can help.

If you're building in the fintech space and you're not sure where your obligations sit, feel free to reach out at rossgsaunders.com. I'm also happy to come in and walk your team through this landscape directly, which tends to be a useful conversation for product, engineering, and legal to have together.