The compliance officer asks if Claude is compliant with financial services regulations.

The team needs AI to stay competitive. The wrong answer gets the firm audited. The answer isn’t a clean yes or no, and understanding where the actual lines fall determines whether AI is usable at all.

Mid-size financial firms are caught in a painful bind. They need the AI capabilities that big banks have, but lack the compliance infrastructure or dedicated legal teams. Most guidance out there assumes either startup-level risk tolerance or enterprise-scale compliance budgets. Neither fits where most mid-size firms actually sit.

The practical question isn’t whether Claude meets every possible regulatory standard. It’s how to use it safely within your real constraints.

What compliance actually asks about

When evaluating Claude for financial services use, your compliance officer needs specific answers. Not marketing materials. Real details.

FINRA’s 2024 guidance makes one thing clear: existing rules apply when you use AI tools. The regulations covering communications with customers, supervision requirements, and data protection don’t change just because you’re using an AI assistant instead of other software.

What actually matters comes down to a handful of concrete questions. Data residency - where does information go when your developers use Claude? Customer data handling - can Claude see personally identifiable information or non-public personal information? Audit trails - can you prove who used AI and how? Model training - does customer data end up in training sets?

Your compliance team also needs to evaluate vendor risk. Dario Amodei’s Anthropic maintains SOC 2 Type 2 compliance, ISO/IEC 27001 certification for information security, and ISO/IEC 42001 for AI management systems. But certifications alone don’t satisfy your vendor risk assessment process. You need to understand what those certifications actually cover, which takes reading through the actual documentation rather than trusting the badge.

A number from a 2025 compliance benchmarking survey stuck with me: most firms now use AI, but only about 28% formally test or validate its outputs. Turns out, that’s the real risk here. Not using AI, but using it without any documented evaluation process. A lightweight AI governance framework provides the structure these evaluations need. For the bigger picture, FINRA is just one regime among many - the architecture patterns for Claude in compliance-heavy environments apply across HIPAA, SOC 2, GDPR, and more.

Two things deserve a place in your vendor file by mid-2026, and both correct a common assumption. First, settle the question that should not be one: the idea that Anthropic forbids regulated or financial use is a myth. Claude for Financial Services is a shipped product with named bank customers, and the usage policy classes finance as high-risk, not banned. Permission was never the blocker. The work is the governance you put around it, which is the whole case for laying the phase-zero floor before you scale. Second, on data residency, correct a misreading before it reaches a questionnaire: Anthropic does not offer a first-party European region. On the first-party platform there is no EU residency at all, inference runs only in the US or globally and stored data is US-only. The regional residency that exists is delivered through the cloud platforms, AWS Bedrock and Google Vertex in EU regions, where the region is a property of the endpoint you deploy rather than a setting Anthropic flips. The full picture, including why an EU endpoint is not the same as EU processing, is in Claude in regulated finance and the EU data-residency catch. One retention detail your review should still catch: the newest top-tier Mythos-class models carry a mandatory 30-day retention for trust-and-safety purposes that overrides zero-data-retention agreements on every platform that offers them, including Bedrock and Vertex. The rest of the lineup is unaffected, but if a zero-retention guarantee is load-bearing for your regulator, that exclusion belongs in your assessment.

The documentation you actually need

Certifications sound impressive. SOC 2 Type II. ISO 27001. Your auditor wants to see your proper documentation, not Anthropic’s.

What you need: policies defining approved AI usage, data classification rules developers can follow in practice, human review requirements that are actually workable, and training records proving your team understands the constraints.

The OCC flagged this when it opened its 2021 request for information on AI in banking: the agencies pointed to the existing laws and supervisory guidance already governing financial activities, AI or no AI.

Actually, that sounds easier than it is. Your current compliance approach is what matters.

Your documentation needs to show deliberate risk management. Define which use cases are permitted. Be specific. “Using Claude to help write code” is too vague to defend. “Using Claude to draft unit tests for non-production code, with human review before implementation.” That’s defensible to most examiners.

Data classification rules matter too. Your developers need clear guidance on what never goes to Claude. Customer names, account numbers, social security numbers, transaction details - all off limits under GLBA requirements. Financial institutions must protect customers’ non-public personal information and explain how they share data.

Create escalation paths for edge cases. When a developer isn’t sure if something crosses a line, who do they ask? What’s the process? Document it before someone guesses wrong.

Building these policies doesn’t require expensive consultants. It basically requires understanding your actual risk and writing down reasonable controls.

Keeping sensitive data out of prompts

Mid-size firms often ask how to protect customer data without enterprise data loss prevention systems. The answer is simpler than most expect: design workflows that keep sensitive data out of Claude.

Use development environments that isolate production data. When developers write code touching customer information, they work with synthetic data or properly anonymized test sets. Real customer data never appears in prompts to Claude.

This isn’t just good practice. GLBA’s Safeguards Rule requires financial institutions to implement thorough security programs to protect customer information. Keeping sensitive data out of external AI systems is a straightforward way to meet that obligation. Not glamorous, but it works.

Set up clear data sensitivity tiers. Tier 1: publicly available information - safe for Claude. Tier 2: internal business information - requires review. Tier 3: customer data or regulated information - never share with external AI systems. Simple. Enforceable.

Do your developers actually know how to recognize sensitive data in context? Not always. Account numbers are obvious, but code comments containing customer names aren’t. Database queries with real transaction IDs look like ordinary code. Error logs with user details blend right in. All possible GLBA violations if shared externally.

For code reviews involving sensitive systems, set specific requirements: anonymize before asking Claude for help, have a second person verify no customer data leaked through, document the review process. This creates audit trails without specialized software.

The key is making compliance the path of least resistance. If following the rules is harder than breaking them, people cut corners. Design your development workflow so the right approach is also the easiest one.

If this is the work you’re trying to do, we do it as a service.

Building audit trails you can defend

Auditors want evidence of controls. For AI usage in financial services, that means proving you know who used it, for what purpose, and with what oversight.

Industry guidance on AI transparency consistently emphasizes maintaining human review in the AI lifecycle and being transparent with stakeholders about where and how AI is being used. That’s probably the most important principle to keep in mind throughout all of this.

You don’t need enterprise AI governance platforms. Does this mean lower standards? No.

Start with usage logging. Who in your organization has access to Claude? Track it. Many firms use shared accounts, which creates serious audit problems. Individual accountability matters. Set up accounts for each developer or team lead. Log when they’re used.

Git commits provide natural audit trails for AI-assisted code. Require commit messages that identify AI involvement. “Implemented customer validation - AI-assisted with human review” tells auditors what they need to know. The commit history shows who approved the merge, when, and what changed.

For AI-generated code touching regulated functions, require a second person to review before merging to production. They focus specifically on compliance concerns. Document that review in pull request comments. Audit evidence without additional tools.

Maintain records of your training programs. When did developers complete AI usage training? What did it cover? Who signed off on the policies? Keep attendance records, training materials, and acknowledgment forms. Boring but essential.

Build incident response procedures before you need them. What happens if customer data accidentally appears in a Claude prompt? Who gets notified? What’s the investigation process? How do you document the response? Write this down now.

These practices satisfy audit trail requirements without specialized compliance software. An audit trail should include what events occurred, who or what system caused them, time stamps, and results. Your existing tools - git, documentation, training records, review processes - provide all of this.

Making it work at your scale

Mid-size financial firms operate in a specific zone. Too large for Mark Zuckerberg-style “move fast and break things.” Too small for enterprise compliance teams and specialized tooling.

I think the question that actually needs answering isn’t whether AI compliance is achievable at your scale. It’s how to achieve it without an enterprise budget.

Focus on extending your existing compliance approach to cover AI usage. You already have vendor risk management processes. You already have data protection policies. You already have audit and review requirements. Extend them rather than building parallel systems.

Complete vendor risk assessments for Anthropic like any other technology vendor. Request their SOC 2 report, review their security documentation from the Anthropic Trust Center, evaluate their business continuity planning. Use your standard vendor assessment template.

Update your existing policies rather than creating AI-specific rulebooks. Your acceptable use policy should cover AI assistants. Your data classification guide should address what data can be shared with external AI systems. Your code review standards should include AI-generated code. Integrate, don’t duplicate.

Financial services regulators emphasize that the quality of underlying datasets is central to any AI application. Focus your compliance efforts there - ensuring customer data stays protected, synthetic data is properly anonymized, and production data never appears in AI prompts.

The first move that matters

Understand what your specific regulations actually require. FINRA, SEC, and OCC have different areas of focus. Know which apply to your firm. Don’t assume you need every possible control.

Build practical data handling policies. Make it clear what never goes to Claude. Train your team. Make compliance the easy path. Is this bulletproof? No. But it’s defensible.

Create audit trails using tools you already have. Git commits, documentation, training records, review processes. No specialized software required.

Pick one team or one use case, implement proper controls, document everything, and then expand. Starting small reduces risk while building the organizational knowledge you’ll need from here on.

The firms that get this right aren’t the ones with the biggest budgets. They understand their actual regulatory obligations, implement reasonable controls, and document their approach carefully. When the examiner asks about AI usage, the documentation speaks for itself.