AI Security for Fintech: Compliance, Model Risk, and LLM Deployment Controls

Financial services regulators have been signaling their AI expectations clearly and with increasing specificity. The OCC, Federal Reserve, and FDIC issued joint guidance on model risk management that predates the LLM era but applies directly to AI systems used in credit decisions, fraud scoring, and customer interactions. SR 11-7, the longstanding model risk management guidance, requires validation, documentation, and ongoing performance monitoring for any model used in a consequential decision — and regulators have made clear that LLMs used in financial workflows fall within scope.

The SEC has issued guidance on AI use in investment advice contexts, focusing on conflicts of interest, suitability, and disclosure obligations. State-level regulators are increasingly active on AI fairness and bias in credit and insurance decisions. For fintech companies that operate across multiple states or that maintain bank partnerships, the aggregate compliance surface is significant — and the documentation requirements are specific. Examiners do not want to hear that you have an AI policy. They want to see model inventories, validation records, access controls, and evidence that someone is accountable for each deployment.

SOC 2 engagements are increasingly surfacing AI-specific questions. Auditors are asking about data inputs to AI systems and whether those inputs include customer PII, about access controls governing who can modify model configurations or system prompts, about change management processes for AI systems, and about monitoring and alerting for anomalous AI behavior. Fintech companies that have deployed AI rapidly without building the underlying documentation infrastructure are discovering during SOC 2 prep that they have significant gaps — gaps that take longer to close than a standard control deficiency because they require both technical implementation and process documentation.

Traditional model risk management, as defined in SR 11-7, focuses on quantitative models: credit scoring algorithms, fraud detection classifiers, valuations models. These are deterministic systems with defined inputs, documented assumptions, and measurable outputs. Validation involves back-testing, sensitivity analysis, and benchmark comparison. The risk is that the model produces incorrect outputs due to flawed assumptions, data quality issues, or deployment in contexts outside its validation boundary.

LLM deployments introduce model risk of a different character. The outputs are natural language, not numeric scores, and they are non-deterministic — the same input can produce meaningfully different outputs across runs. The "assumptions" embedded in the model are the result of training on a dataset that cannot be fully audited. The boundary conditions — the inputs under which the model's outputs should not be trusted — are poorly defined and can only be discovered through adversarial testing. Traditional validation methodology does not map cleanly onto these characteristics.

What does map is the underlying governance principle: any system that produces outputs used in consequential financial decisions requires documented validation, defined performance standards, ongoing monitoring, and a process for identifying and responding to performance degradation. For an LLM used to draft customer communications, validation means testing for accuracy, tone, regulatory compliance of the output language, and resistance to adversarial input. For an LLM used to assist with underwriting document review, validation means testing for consistency, coverage of material information, and the conditions under which the model's outputs should require human review before acting on. The specific methodology differs from traditional model validation, but the governance requirement — document it, test it, monitor it, own it — does not.

Data segregation is the most critical technical control for fintech AI deployments and the one most frequently misconfigured. LLM applications built on RAG architectures retrieve documents from a knowledge base at query time. If that knowledge base contains customer financial data, transaction records, or any regulated information, the retrieval layer must enforce authorization controls that prevent any user from accessing data belonging to another customer. This is not a new requirement — it is basic data isolation — but the RAG architecture pattern makes it easy to implement incorrectly. A retrieval system that selects documents based on semantic similarity without checking the requesting user's authorization will surface documents that user has no right to see.

For fintech companies operating under PCI DSS, the question of where cardholder data flows in relation to AI systems requires explicit scoping. If a customer service AI can retrieve transaction history that includes card numbers or CVVs, that system is in scope for PCI DSS. If the AI is used in a payment processing workflow, the entire pipeline — system prompt, retrieval context, model inference, output handling — requires assessment against PCI DSS controls. Many fintech companies that deploy AI rapidly without a formal PCI scoping exercise are inadvertently expanding their cardholder data environment.

Audit logging for AI systems in financial contexts must be treated with the same rigor as audit logging for any other system that touches regulated data. Every interaction — the input, the retrieved context, the model output, any tool calls made — should be logged with sufficient detail to reconstruct the session for regulatory review or incident investigation. Log retention should align with your regulatory obligations, which in financial services frequently means seven years. This requirement eliminates cloud AI providers whose logging capabilities are limited or whose data retention policies conflict with your obligations.

Access control over AI system configuration is a control gap that surfaces frequently in fintech environments. System prompts define the AI system's behavior, data access scope, and operational boundaries. In many deployments, system prompt modification is not subject to the same change management controls as application code changes — developers can modify the prompt directly without a formal approval workflow, audit trail, or rollback capability. For a fintech company, an unauthorized or unreviewed system prompt change is a configuration change to a system that may be making consequential outputs. It belongs in your change management process.

A defensible AI security posture is one that you can document, explain, and defend to a regulator, auditor, or incident investigator. It does not require perfection — it requires evidence of a systematic approach. The components are: a complete AI asset inventory with risk classifications, documented governance and approval processes for new deployments, technical controls appropriate to each deployment's risk tier, validation records for models used in consequential decisions, ongoing monitoring with defined escalation criteria, and incident response procedures specific to AI failures.

For fintech companies earlier in their AI governance journey, the sequence matters. Start with inventory — you cannot document what you do not know exists. Move to risk classification — not all your AI deployments carry the same regulatory and security risk, and your documentation effort should be proportionate. Then address the highest-risk deployments first: anything that touches regulated data, anything used in a consequential decision, anything customer-facing with brand or legal exposure. Build the governance documentation and technical controls for those deployments, then extend the framework to lower-risk systems.

The fintech companies that are best positioned for both regulatory examination and continued AI adoption are the ones that treat AI security governance as infrastructure, not overhead. The documentation you build to satisfy a SOC 2 auditor is the same documentation your security team needs to respond to an incident. The access controls you implement to comply with PCI DSS are the same controls that prevent customer data exfiltration through an adversarial AI interaction. Security and compliance, properly implemented, are not competing priorities — they are the same work, done once, applied consistently.