AI Security in Financial Services: Navigating Compliance and Risk

A security researcher recently tested 24 AI banking chatbots and found that every single one was exploitable. Simple conversational techniques, not sophisticated zero-days, were enough to bypass guardrails across the board. The most damaging outputs looked harmless at first glance but disclosed exactly the kind of information that fraudsters look for.

Financial services is moving fast on AI. Banks are deploying customer-facing chatbots, automating compliance workflows, building AI-driven fraud detection, and integrating LLMs into advisory tools. IBM's 2025 Cost of a Data Breach Report puts the average cost of a data breach in financial services at $5.56 million, well above the cross-industry average of $4.44 million. But the security and compliance frameworks governing these deployments haven't kept pace. The result is a widening gap between what regulators expect and what most institutions have actually implemented.

This post breaks down the regulatory landscape, the specific risks LLMs introduce to financial services, and practical steps your team can take to close that gap.

The Regulatory Landscape in 2026

Financial services firms deploying AI face a layered and evolving set of regulatory obligations. Understanding who requires what is the first step toward building a defensible program.

U.S. Federal Regulators

SEC examination priorities for 2026 explicitly target AI governance. The SEC's Division of Examinations has flagged AI as a heightened compliance and investor protection risk. Examiners are now reviewing whether firms have implemented adequate policies to monitor and supervise their use of AI technologies, covering fraud prevention, back-office operations, AML, and trading functions. They're also checking whether representations about AI capabilities are accurate, a direct response to concerns about "AI-washing" in the industry.

FINRA's 2026 Regulatory Oversight Report includes a standalone section on generative AI that substantially expands on prior guidance. For the first time, FINRA explicitly discusses the risks of AI agents, not just chatbots, and articulates expectations for GenAI governance, testing, and monitoring.

The OCC and Federal Reserve continue to apply their existing model risk management framework (SR 11-7) to AI deployments. While SR 11-7 was written before the LLM era, the OCC has made clear that AI tools should be governed by the same risk-based principles that apply to any model used for business decisioning. That means validation, documentation, ongoing monitoring, and clear governance structures.

The challenge is that SR 11-7 was designed for static, deterministic models. LLMs are neither static nor deterministic. Most model risk management policies break down when applied to generative AI because the output space is essentially unbounded. Financial institutions need to adapt their MRM practices, not abandon them, to account for the probabilistic nature of LLM outputs.

EU AI Act

The EU AI Act has entered full force, with high-risk AI system requirements becoming applicable by August 2026. Several AI use cases common in financial services fall squarely into the high-risk category: credit scoring, fraud prevention systems, AML tools, and automated insurance pricing.

For these high-risk applications, the Act requires bias testing, comprehensive documentation, human oversight mechanisms, and conformity assessments. The European Banking Authority has confirmed that the AI Act is complementary to existing EU banking regulations, meaning institutions face dual compliance obligations.

Non-compliance penalties reach up to 7% of global annual turnover or 35 million euros, whichever is greater.

NIST AI Risk Management Framework

The NIST AI Risk Management Framework has rapidly evolved from voluntary guidance to a regulatory reference point. Multiple regulations now explicitly cite NIST AI RMF as a compliance benchmark, and institutions that cannot evidence NIST-aligned AI governance may struggle to defend themselves in enforcement actions or litigation. The Treasury Department's 2024 report on AI in financial services specifically recommends that financial institutions align their AI risk management practices with the NIST AI RMF.

NIST AI 600-1, the Generative AI Profile released in 2024, identifies 12 risks unique to or exacerbated by generative AI and provides over 200 suggested actions for risk management. Financial institutions deploying LLMs should treat this as a practical implementation guide, not optional reading.

LLM-Specific Risks in Financial Services

The financial sector faces all the standard LLM security risks (prompt injection, jailbreaking, hallucination) plus several industry-specific concerns that amplify the consequences.

Unauthorized Financial Advice

When a customer-facing chatbot generates investment recommendations, tax guidance, or insurance advice without proper disclaimers or licensing, the institution faces regulatory liability. This isn't hypothetical. LLMs are confident by default, and a model that was supposed to answer account balance questions can easily drift into providing financial guidance if its system prompt boundaries aren't enforced.

The SEC specifically examines whether "technology-driven recommendations align with regulatory expectations." If your AI assistant crosses the line from information to advice, you're in scope for regulatory action.

Data Leakage and PII Exposure

Financial institutions handle some of the most sensitive personal data that exists: account numbers, Social Security numbers, transaction histories, credit scores, income data. When this information enters an LLM's context window, whether through RAG retrieval, fine-tuning, or user input, it becomes a data leakage risk.

Research shows that 77% of enterprise employees who use AI have pasted company data into a chatbot query, and 22% of those instances included confidential personal or financial data. In a financial services context, that could mean customer account details, trading strategies, or compliance-sensitive information entering systems where it shouldn't be.

This is why major banks including JPMorgan and Goldman Sachs implemented restrictions on external AI tool usage after discovering employees had shared sensitive information with AI assistants.

Prompt Injection in Financial Workflows

Prompt injection attacks take on outsized consequences in financial services. The OWASP Top 10 for LLM Applications ranks prompt injection as the top risk (LLM01), and MITRE ATLAS documents real-world case studies of adversarial attacks against ML systems in production, including financial fraud detection models. Consider an AI-powered fraud detection system that processes incoming transactions. If an attacker can embed instructions in transaction metadata that manipulate the model's classification, they could potentially mark fraudulent transactions as legitimate.

Second-order prompt injection is particularly concerning for multi-agent financial workflows. Attackers have demonstrated techniques where a low-privilege agent is fed a malformed request that tricks it into asking a higher-privilege agent to perform an action on its behalf, bypassing normal access controls. In a financial context, that could mean unauthorized fund transfers, data exports, or compliance overrides.

Model Supply Chain Risk

The January 2026 DeepSeek security crisis, which revealed exposed databases and prompted government bans worldwide, highlighted a risk that financial services firms cannot ignore: the security posture of your AI supply chain. When you integrate third-party models, embeddings, or AI services, their vulnerabilities become your vulnerabilities.

For regulated financial institutions, this means conducting due diligence on AI vendors with the same rigor applied to any critical third-party service provider. The OCC's guidance on third-party risk management (OCC Bulletin 2023-17) applies directly to AI vendor relationships and requires banks to assess vendors' security practices, data handling, and incident response capabilities.

Building a Compliant AI Security Program

Meeting regulatory expectations while actually protecting your systems requires a structured approach. Here's a framework that maps security controls to regulatory requirements.

1. Establish AI Governance

Before deploying any LLM in a customer-facing or decision-influencing role, document your governance structure:

• Inventory all AI systems with their risk classification, data sources, and intended use. Both the EU AI Act and NIST AI RMF start here.
• Define ownership and accountability. Every AI system needs a business owner responsible for its behavior and a technical owner responsible for its security.
• Create an AI acceptable use policy covering which models are approved, what data can be processed, and what review is required before deployment. The SEC is explicitly looking for these policies during examinations.
• Establish a review board for new AI use cases. This doesn't need to be a formal committee. A lightweight review process with clear criteria is sufficient, and it satisfies the governance expectations from both U.S. regulators and the EU AI Act.

2. Implement Input and Output Security

Every LLM interaction in a financial services context should pass through security controls on both sides. This is the single most impactful technical control you can implement.

Input scanning catches prompt injection attempts, jailbreak attacks, and harmful content before they reach the model. Output scanning catches PII exposure, data leakage, unauthorized financial advice, and content policy violations before they reach the user.

import wardstone
 
def process_customer_query(text: str):
    # Scan input for attacks
    input_result = wardstone.guard(text)
    if input_result.flagged:
        log_security_event(text, input_result)
        return {"error": "Your request could not be processed."}
 
    response = llm.generate(text)
 
    # Scan output for data leakage and compliance issues
    output_result = wardstone.guard(response)
    if output_result.flagged:
        if "data_leakage" in output_result.categories:
            return redact_and_respond(response, output_result)
        return {"error": "Response could not be delivered."}
 
    return response

This dual-layer approach maps directly to multiple regulatory expectations: the OCC's requirement for model output validation, the EU AI Act's human oversight provisions, and the SEC's expectation that firms monitor their AI outputs for accuracy and compliance.

3. Enforce Data Boundaries

Financial data classification matters more with AI than with traditional software. Map your data classification tiers to your AI systems:

• Tier 1 (Public): Can be freely processed by any approved AI system.
• Tier 2 (Internal): Can be processed by approved, internally hosted AI systems with logging.
• Tier 3 (Confidential): Requires data minimization, redaction before processing, and audit trails.
• Tier 4 (Restricted, e.g., PII, account data): Must never enter an AI system without explicit controls, encryption, and compliance review.

For RAG systems connected to financial databases, enforce access controls at the retrieval layer. If a customer shouldn't see another customer's data through the UI, they shouldn't be able to access it through the AI assistant either.

4. Build Audit Trails

Regulators expect you to demonstrate what your AI systems did and why. Log every AI interaction with sufficient detail for after-the-fact review:

• The full input (with PII redacted in logs if necessary)
• The model used and its version
• Any retrieved context (for RAG systems)
• The full output
• Any security flags raised
• The action taken (served, blocked, redacted)
• Timestamps and user/session identifiers

import Wardstone from "wardstone";
 
const wardstone = new Wardstone();
 
async function auditedAICall(input: string, userId: string) {
  const startTime = Date.now();
  const inputCheck = await wardstone.guard(input);
 
  const auditRecord = {
    userId,
    input: redactForLogs(input),
    inputFlagged: inputCheck.flagged,
    timestamp: new Date().toISOString(),
    model: "gpt-4o",
    action: "pending",
  };
 
  if (inputCheck.flagged) {
    auditRecord.action = "blocked_input";
    await saveAuditLog(auditRecord);
    return { error: "Request blocked by security controls." };
  }
 
  const response = await llm.generate(input);
  const outputCheck = await wardstone.guard(response);
 
  auditRecord.action = outputCheck.flagged ? "blocked_output" : "served";
  auditRecord.outputFlagged = outputCheck.flagged;
  auditRecord.latencyMs = Date.now() - startTime;
 
  await saveAuditLog(auditRecord);
  return outputCheck.flagged ? sanitize(response) : response;
}

These logs serve double duty: they satisfy regulatory record-keeping requirements and they give your security team the data needed to investigate incidents and improve defenses over time.

5. Conduct Ongoing Testing

Static validation isn't enough for AI systems. The threat landscape evolves weekly, and models can behave differently under different conditions. Build continuous testing into your process:

• Monthly adversarial testing against your AI endpoints using known attack patterns. The Wardstone playground is a good starting point for understanding what attacks look like.
• Quarterly model validation reviews that align with your SR 11-7 obligations. Document model performance, any incidents, and changes to the threat environment.
• Annual comprehensive risk assessments covering your full AI inventory, required by both NIST AI RMF and the EU AI Act for high-risk systems.

Common Pitfalls in Financial AI Deployments

We've worked with fintech companies and financial institutions at various stages of AI adoption. These are the mistakes we see most often.

Treating AI like traditional software

AI systems don't fail the same way traditional software does. A bug in conventional code produces the same wrong output every time. An LLM can produce different problematic outputs on each interaction, making testing and validation fundamentally different. Your QA process needs to account for the probabilistic nature of AI responses.

Over-relying on prompt engineering for compliance

"The system prompt says not to give financial advice" is not a compliance control. Prompt-based restrictions are routinely bypassed by determined users, sometimes unintentionally. You need actual detection and filtering, the kind that catches policy violations in model outputs regardless of how they were triggered.

Ignoring the context window

Financial data that enters an LLM's context window can leak in unexpected ways. A customer support chatbot that retrieves account information to answer billing questions might inadvertently include that data in responses to subsequent users if context management isn't implemented correctly. Treat the context window as a security boundary.

Deploying without monitoring

Some institutions deploy AI features and consider the job done. Without active monitoring, you won't know when your AI starts behaving outside its intended boundaries until a customer, auditor, or regulator tells you. By then, the damage is done.

What Comes Next

The regulatory environment for AI in financial services will continue to tighten through 2026 and beyond. The SEC's examination priorities signal increasing scrutiny. The EU AI Act's high-risk provisions are taking effect. FINRA is paying attention to AI agents, not just chatbots. And model risk management frameworks are being actively updated to address generative AI.

The institutions that will navigate this well are the ones treating AI security and compliance as an integrated discipline, not separate workstreams. Security controls that map to regulatory requirements. Governance structures that serve both risk management and innovation. Testing programs that satisfy both your security team and your examiners.

Start by auditing your current AI deployments against the framework in this post. Identify the gaps between what you've implemented and what regulators expect. Then prioritize: input/output security and audit logging will close the biggest gaps fastest.

The tools and frameworks exist. The regulatory expectations are clear. The question is whether your institution will build these capabilities proactively or reactively, and the cost difference between the two approaches is significant.

Ready to assess your AI security posture? Try the Wardstone playground to see how your LLM inputs and outputs are evaluated, or explore our enterprise solutions for financial services deployments.