How AI Changes the Risk Profile of Banks
Banking is unusually exposed to AI risk because it combines several conditions that rarely occur together elsewhere: very large volumes of sensitive personal and financial data, decisions that are themselves regulated (lending, trading, AML), tightly interconnected systems, heavy reliance on external infrastructure, direct financial consequences from errors, and operations that increasingly run in real time.
AI does not usually invent entirely new problems here — it amplifies problems banks already manage. A traditional data-access control gap becomes more serious when an AI assistant can retrieve, summarize and act on information pulled from multiple internal systems at once, rather than requiring a person to query each system individually. A traditional fraud problem becomes more scalable when synthetic identities, deepfake audio or automated account-opening scripts let one attacker attempt what used to take a team.
This amplification effect is also the reason regulators keep returning to the same theme: existing frameworks data protection law, operational resilience rules, consumer protection law mostly still apply — but the speed and scale at which AI operates test assumptions those frameworks were built around.
AI in Banking: Where Is It Being Used?
AI is now embedded across most major banking functions, and each use case carries its own risk profile rather than one generic "AI risk."
- Fraud detection — AI models flag anomalous transactions in real time. Risk: false positives disrupt customers, false negatives miss novel fraud patterns, and adversaries probe models to learn how to evade them.
- AML and financial crime monitoring — AI helps surface suspicious patterns across large transaction volumes. Risk: opaque scoring makes it harder to justify decisions to regulators and can miss criminal activity if training data is stale.
- Credit underwriting — AI assists or drives lending decisions. Risk: bias, poor explainability, and disparate impact on protected groups.
- Customer service — Generative AI powers chatbots and support tools. Risk: hallucinated or inaccurate information delivered directly to customers.
- Document processing — AI extracts and summarizes information from contracts, statements and filings. Risk: misclassification or leakage of sensitive document content.
- Compliance — AI supports monitoring and reporting obligations. Risk: over-reliance on AI outputs without adequate human review of regulatory judgment calls.
- Risk management — AI models support credit, market and operational risk assessment. Risk: model risk compounds if the risk function itself depends on unvalidated models.
- Trading and investment analysis — AI assists research, signal generation and execution support. Risk: correlated model behavior across firms can amplify market moves.
- Personalization — AI tailors products and offers. Risk: profiling based on sensitive inferred data raises privacy and fairness questions.
- Internal knowledge assistants — AI helps employees search and synthesize internal information. Risk: broad retrieval access can expose data beyond what a given employee should see.
- Cybersecurity — AI supports threat detection and response. Risk: the same capability that helps defenders is available to attackers, and often faster to deploy on the offensive side.
AI Cybersecurity Risks in Financial Services
This is where 2026 regulatory attention has concentrated most heavily, and for good reason. In its June 2026 risk assessment, the European Banking Authority said advances in frontier large language models had significantly increased cyber risk for European banks, describing AI as a potential "material risk amplifier" for the sector because highly capable models can help attackers identify and exploit software vulnerabilities. The EBA tied this to banks' growing dependence on complex technology stacks and third-party vendors, which act as additional channels for operational disruption.
That warning did not stay isolated. On 7 July 2026, the European Systemic Risk Board formally warned that frontier AI models are capable of discovering vulnerabilities, generating working exploits and autonomously executing full-scale cyberattacks at a speed, scale and accuracy that exceeds previous generations of AI — a shift it characterized as a source of systemic risk to the EU financial system. The ESRB had raised its assessment of this risk from "elevated" to "severe" between March and June 2026, and the EBA, EIOPA and ESMA jointly endorsed the warning at the end of July, calling for a consistent, risk-based supervisory approach to the ICT risks arising from frontier AI. Separately, the European Central Bank told the chief executives of Europe's significant banks in July 2026 that frontier models can now find and exploit software vulnerabilities faster than any human-paced response process, and set a 31 October 2026 deadline for those banks to explain how they intend to withstand AI-accelerated cyberattacks.
This is a defender's-side problem as much as an attacker's-side one. If attackers can use increasingly capable AI to compress reconnaissance, exploit development and attack execution into a much shorter window, financial institutions have to compress their own detection, patching and response timelines to match — without simply throwing more headcount at the problem, since the volume and speed of AI-assisted probing can outpace manual review.
Relevant risk vectors include AI-assisted phishing and social engineering that is more convincing and harder to spot; faster automated reconnaissance and vulnerability discovery; credential-stuffing and account-takeover attempts run at greater scale; prompt injection and other techniques aimed at manipulating an institution's own AI systems; and exposure introduced through insecure integrations or third-party AI infrastructure that sits outside the institution's direct control. Where institutions deploy agentic AI — systems that can take multi-step actions rather than just generate text — the same automation that increases efficiency also increases the blast radius of a compromised credential or a manipulated prompt.
On the U.S. side, the OCC's May 2026 Semiannual Risk Perspective made a similar point in supervisory language: AI is significantly transforming the cybersecurity threat landscape for banks, both by facilitating fraud directly and by lowering the barrier to entry for threat actors while increasing the speed, scale and sophistication of attacks against financial institutions.
None of this means every institution faces an imminent AI-driven breach. It means the threat model has shifted enough that supervisors on both sides of the Atlantic are treating AI-accelerated cyber risk as a distinct, board-level item rather than a subset of ordinary IT risk.
AI Data Privacy and Security Risks in Banking
Financial institutions handle an unusually wide range of sensitive data: customer PII, transaction and payment data, account information, proprietary trading data, M&A and deal information, internal risk data, employee records, authentication credentials, and confidential regulatory correspondence. Any of it can end up flowing through an AI system, often without anyone mapping the path explicitly.
A useful way to think about exposure is to trace the data flow itself: data source → AI application → retrieval or context assembly → model → output → logs → storage → downstream systems. Exposure risk can appear at almost any point in that chain — not just "the model."
Common risk points include sending more data to a model than the task actually requires; retention settings that keep prompts and outputs longer than necessary; logging that captures sensitive content by default; third-party processing that moves data outside the institution's direct control; cross-border processing that raises data-residency questions; access controls that are too broad for who can see prompts and outputs; output leakage, where a model surfaces information it should not have combined or disclosed; retrieval-augmented generation (RAG) systems exposing documents beyond a user's actual permissions; and, increasingly, employees using unsanctioned consumer AI tools with sensitive data because sanctioned tools feel slower or more restrictive.
It's worth being precise about what happens to data sent to an AI provider, because this is an area where blanket claims cause real confusion. It is not accurate to say that every query sent to a cloud AI provider automatically becomes part of that provider's future model weights — training-use practices vary considerably by provider, product tier, contractual terms and configuration. Enterprise agreements commonly include commitments around training-use exclusion, logging limits, data residency, tenant isolation and access controls that differ meaningfully from a consumer-facing free tier of the same underlying model. The practical implication for a financial institution is that these terms need to be verified and documented for each AI product in use, not assumed from general industry reputation.
A related area of confusion involves fine-tuning models on customer data and later deletion requests. Fine-tuning sensitive financial data into a model does raise a genuine architectural challenge — model weights don't have a simple "delete this record" mechanism the way a database row does — but that challenge is not automatically a data-protection law violation, and it does not make deletion universally impossible. It's a reason to think carefully, before sensitive data ever reaches training, about privacy by design, data minimization, purpose limitation, appropriate retention limits, controlled and documented training datasets, and traceability of what data went into which model version. Institutions that get this right typically avoid training on regulated personal data in identifiable form at all, using retrieval or other architectures instead.
AI Regulatory Risk: What Financial Institutions Need to Understand
AI regulatory risk in financial services is not really a single risk category — it's the risk that an institution's AI use triggers obligations under existing law and supervisory expectations that it hasn't mapped, documented or controlled for. That can touch privacy obligations, sector-specific financial regulation, model governance expectations, consumer protection and fair-lending rules, operational resilience requirements, cybersecurity obligations, third-party risk management duties, recordkeeping, explainability expectations, and general accountability and data-governance requirements.
A few instruments come up repeatedly in this conversation, and it matters that they don't all carry the same legal weight:
DORA (the EU's Digital Operational Resilience Act) applies to how EU financial entities manage ICT risk, including from third parties — it is binding regulation for in-scope entities, but it does not treat every AI system a bank uses as automatically in scope in the same way; applicability depends on how the AI system functions as an ICT service and what role it plays in the entity's operations. Regulators applying the recent frontier-AI cyber warnings have been explicit that this guidance doesn't create new law — the expectations are read into existing DORA and EU AI Act obligations, which are designed to be technology-neutral.
The EU AI Act creates risk-tiered obligations that depend on how a given AI system is classified and the role the institution plays in the AI value chain (provider, deployer, etc.) — it does not create one uniform compliance obligation that applies identically to every financial-services AI use case. A customer-facing credit-scoring system and an internal document-summarization tool are very unlikely to sit in the same risk tier.
GDPR, where applicable, governs the processing of personal data an AI system touches, and applies based on what data is processed and how — not based on the mere fact that AI is involved.
The NIST AI Risk Management Framework is a voluntary U.S. framework, not a law or a mandatory financial regulation. There is no certification and no enforcement mechanism — no regulator issues penalties for non-compliance. Published in January 2023 and extended by a Generative AI Profile in July 2024 covering risks such as confabulation, data privacy, information security and value-chain risk, it's widely used because it gives institutions a shared vocabulary and structure for AI governance — but citing it as if it were a compliance requirement misstates what it is.
Sector-specific financial regulation and supervisory expectations — issued by banking, securities and insurance regulators — often matter more in practice than any AI-specific instrument, because they were frequently written to be technology-neutral and already cover the underlying activity (lending, trading, outsourcing) regardless of whether AI is involved.
A May 2025 U.S. Government Accountability Office report on AI use and oversight in financial services found that federal financial regulators primarily oversee AI using existing laws, regulations, guidance and risk-based examinations, though some regulators have issued AI-specific guidance — for example on AI use in lending — or conducted AI-focused examinations. Regulators told GAO they continue to assess AI risks and may refine guidance or update regulations as vulnerabilities emerge. That's a useful summary of where things stand globally as well: mostly existing frameworks, applied with increasing specificity, rather than one comprehensive new AI law.
The practical takeaway: don't ask "does AI regulation apply to us?" Ask, for each AI use case, "which specific laws, regulations, supervisory expectations and voluntary frameworks apply to this system, given what it does, what data it touches, and what decisions it influences?"
Model Risk and AI Decision-Making
Model risk has always mattered in banking — credit models, market risk models and capital models have been subject to formal validation for years. Generative and machine-learning-based AI adds new failure modes to a category regulators already understand well: incorrect or unstable outputs, data drift as market or customer conditions change, poor or biased training data, hidden assumptions baked into model design, limited explainability, harder validation (especially for large language models), hallucination, use of a model outside the purpose it was validated for, and human overreliance on AI-generated outputs.
That last point deserves emphasis. Human oversight does not mean having a person click "approve" on an AI-generated recommendation without meaningfully engaging with it. Effective oversight means the human reviewer has the information, time, authority and incentive to actually catch and correct a wrong output — in credit decisions, fraud alerts, investment recommendations, risk scoring, or customer communications. A rubber-stamp approval step satisfies a governance checkbox without providing a real control.
Third-Party and AI Concentration Risk
This is one of the areas where the current article landscape underserves financial-services readers, and it deserves more depth than a generic vendor-risk paragraph.
Financial institutions increasingly depend on a relatively small set of external providers for cloud infrastructure, foundation models, data providers, AI platforms, cybersecurity tooling, model hosting, APIs and specialized AI services. The Financial Stability Board has identified third-party dependencies and service-provider concentration as one of the AI-related vulnerabilities with the potential to increase systemic risk, alongside market correlations, cyber risk, and model risk and governance gaps. The concern isn't that using vendors is inherently risky — it's that when many institutions rely on the same small set of providers, a failure, compromise or outage at one provider can produce correlated disruption across the sector rather than an isolated incident at a single firm.
A 2026 global survey by the Cambridge Centre for Alternative Finance found regulators notably more concerned than AI vendors about critical third-party risk — 43% of regulators flagged it as a top concern compared with 23% of vendors, which itself illustrates a structural problem: the parties best positioned to assess concentration risk across the system (supervisors) are not the parties making day-to-day vendor decisions (individual institutions).
Practical implications for an institution include understanding exactly which critical functions depend on a given AI or cloud provider, having a realistic exit or substitution plan rather than a theoretical one, and factoring AI-vendor concentration into existing third-party and operational-resilience risk assessments rather than treating "AI vendor risk" as a separate category that falls outside established third-party risk management.
AI Fraud, Deepfakes and Consumer Risk
Financial institutions need to think about AI risk from two directions at once: AI used by the institution, and AI used against it and its customers. These raise different questions and need different controls.
On the attacker side, generative AI has lowered the cost of producing convincing synthetic identities, deepfake voice and video used to impersonate customers or executives, automated and personalized scam messaging, fraudulent loan or account applications built on synthetic documentation, and social-engineering attempts tailored to a specific target using publicly available information. A deepfake voice used to authorize a wire transfer, or a synthetic identity built to pass automated identity-verification checks, are no longer edge-case scenarios — they're the kind of threat fraud teams are actively building detection capability against.
Conflating this with the institution's own AI use case is a common mistake. The controls that reduce risk in the institution's internal AI deployments (access control, logging, model validation) don't do much to stop an external attacker using AI to generate a synthetic loan application. Fraud and cybersecurity teams need to treat "AI as an attack tool" as its own line of defense, layered on top of AI governance for internal systems.
Systemic and Market Risks from AI in Finance
Beyond risk to any single institution, regulators are watching for risk to the financial system as a whole. The FSB's foundational work on this topic notes that AI may amplify certain financial-sector vulnerabilities — including third-party dependencies, market correlations, cyber risk and model risk — potentially increasing systemic risk, even though existing financial policy frameworks already address many of these vulnerabilities. In its June 2026 consultation on sound practices for AI adoption, the FSB again emphasized that rapid AI adoption may amplify or introduce risks that need to be identified and managed appropriately, and its Chair told G20 finance ministers in an August 2026 letter that the potential impact of frontier AI on cyber risk is the most immediate concern facing the financial system.
The systemic concern isn't that any one institution's AI system will fail. It's that if many institutions rely on similar models, similar data sources, or the same small set of infrastructure providers, their behavior in response to a shock can become correlated in ways that amplify rather than dampen market stress — a dynamic regulators sometimes describe using terms like herding or procyclicality. This is a monitored risk, not a predicted certainty: supervisors are building the tools to watch for it, not asserting that AI will definitely cause instability.
How Should Banks Assess AI Risk?
A practical starting point is to evaluate every AI use case — not the technology in the abstract — against a consistent set of dimensions:
- Data sensitivity — what data does the system touch?
- Decision impact — what does the output influence, and for whom?
- Autonomy — does a human review the output before action, or can the system act independently?
- External connectivity — does the system call out to third-party infrastructure?
- Regulatory exposure — which specific laws or supervisory expectations apply?
- Model dependency — how much does the outcome depend on model behavior versus other controls?
- Third-party dependency — how much of the system sits outside institutional control?
- Privilege and access level — what can the system see or do?
- Customer impact — does this touch customers directly?
- Failure and recovery characteristics — what happens if it fails, and how fast can it be recovered or bypassed?
- Monitoring capability — can behavior actually be observed in production?
- Auditability — can a decision be reconstructed and explained after the fact?
This produces a genuinely useful risk matrix rather than a single "AI risk" label. Low-risk internal summarization — say, an employee tool that summarizes publicly available research — looks very different from high-risk credit decisioning, which looks different again from a high-risk autonomous financial action, such as a system authorized to move funds or execute trades without a human in the loop. Each tier needs proportionate controls: the summarization tool needs basic access control and output review; credit decisioning needs formal model validation, fair-lending testing and explainability; autonomous financial action needs the strictest combination of authorization limits, monitoring and kill-switch capability.
Financial-Services AI Security Control Framework
A practical control stack for financial-services AI risk generally moves through: Discover → Classify → Assess → Minimize → Authorize → Protect → Monitor → Test → Respond → Review.
- Discover — build and maintain an AI inventory. Institutions cannot govern systems they don't know exist, and unsanctioned tool use is one of the most common gaps.
- Classify — tag each system by data sensitivity, decision impact and regulatory exposure using the assessment dimensions above.
- Assess — run a proportionate risk assessment before deployment, not after.
- Minimize — apply data minimization so sensitive fields don't reach a model unless the task genuinely requires them.
- Authorize — apply least-privilege identity and access controls to who and what can use the system.
- Protect — secure model configuration, vendor due diligence, and privacy controls appropriate to the data classification.
- Monitor — log usage, outputs and anomalies in a way that supports both security and model-performance monitoring.
- Test — red-team and adversarially test systems, particularly ones with customer-facing or financial-action capability.
- Respond — build AI-specific scenarios into incident response, since an AI failure or compromise often looks different from a traditional outage.
- Review — reassess models, vendors and permissions on a set cadence, not just at initial deployment.
Every stage ties back to a financial-services-specific risk rather than functioning as a generic IT checklist — the point of classifying an AI system, for example, is directly connected to whether it touches regulated data or a regulated decision.
What Should Financial Institutions Ask AI Vendors?
Vendor due diligence is where a lot of AI risk gets resolved or missed in practice. Useful questions for CIOs, CISOs, DPOs, risk leaders and procurement teams include:
- Is customer data used to train or fine-tune the provider's models, and can this be contractually excluded?
- How long is input data (prompts, documents, outputs) retained, and can retention be configured?
- Where is data processed and stored, and does that meet applicable data-residency requirements?
- Who — including which subcontractors — can access prompts and outputs?
- What logging occurs, and can the institution access those logs for its own monitoring?
- Can data be isolated by tenant, and how is that isolation technically enforced?
- How are sensitive fields (e.g., account numbers, PII) protected in transit, at rest and during processing?
- How are model changes or updates communicated, and can the institution test before a change goes live?
- What happens to the institution's operations if the provider suffers an outage?
- What security testing — penetration testing, red-teaming — has been performed, and can results be shared?
- How does the provider report and communicate security incidents, and on what timeline?
- What audit evidence (certifications, attestations, audit rights) is available?
- What controls exist for verified data deletion on request?
- How is AI output quality and drift monitored over time?
- What subcontractors or downstream model providers are involved in delivering the service?
Where Data Minimization Fits Into AI Security
A useful principle sits underneath most of the controls above: the safest sensitive data is often data that never reaches the downstream AI model in identifiable form in the first place. If a customer-service AI tool doesn't need a full account number to resolve a query, sending a masked or tokenized version reduces exposure regardless of what the model does with it afterward.
It's worth being precise about the techniques involved, because they solve different problems and aren't interchangeable. Redaction removes or blocks sensitive content outright, typically used when the information isn't needed downstream at all. Anonymization aims to strip data of identifying characteristics so it can no longer reasonably be linked back to an individual — a high bar that's harder to achieve than it sounds, especially with rich or combinable datasets. Pseudonymization replaces identifying values with a substitute, while keeping a way to re-link the data under controlled conditions — useful when downstream processes still need to reference the same customer consistently, but reduces exposure if the dataset is compromised. Tokenization substitutes sensitive values (like account or card numbers) with a non-sensitive token that can be mapped back only within a controlled, separate system, which is common in payments contexts specifically.
This is where Questa AI fits as one layer among several. Questa AI's role is to reduce the amount of sensitive information that reaches downstream AI processing in identifiable form — acting as a privacy-first layer that sits ahead of AI applications rather than replacing the broader controls a financial institution needs. It does not automatically confer regulatory compliance, does not guarantee GDPR compliance on its own, does not eliminate the possibility of data leakage entirely, does not provide complete data sovereignty by itself, and does not replace identity and access management or the broader AI governance, security and operational-resilience program a financial institution needs to run. It's a complement to those things — a way to reduce the sensitivity of what reaches an AI system in the first place, which lowers the stakes of everything downstream.
Sovereign, Private and Hybrid AI Architectures
A related question institutions face is where AI processing should actually happen. On-premises or fully local deployment is sometimes presented as the only defensible option for financial data, but that overstates the case. Data residency (where data is physically processed or stored), data sovereignty (which legal jurisdiction governs it), private AI (dedicated, non-shared infrastructure), on-premises deployment, controlled cloud deployment with strong contractual and technical guarantees, and hybrid architectures are all distinct options with different trade-offs in cost, scalability and control. Which one is appropriate depends on the risk profile of the specific use case — the sensitivity of the data, the applicable regulatory requirements, the realistic threat model, and operational needs like latency and scale — rather than a blanket rule that one architecture is always safest.
