The two things AI security means in digital banking
The first job is the one banks have been doing for years. Machine learning has sat inside transaction monitoring, card fraud scoring and identity verification for long enough that it has an owner, a validation cycle and a line in the audit plan. When a vendor sells AI security solutions in digital banking in this sense, they are selling detection, and the institution already knows how to buy and supervise it.
The second job is newer and structurally different. Generative and agentic systems are now embedded in the core, the origination platform, the servicing system, the contact centre and the productivity suite. They read customer documents, retrieve internal records, draft decisions and, increasingly, take actions in other systems. Securing them is not a detection problem. It is an architecture and permissions problem, and it usually lands on a team that inherited the system rather than chose it.
The distinction matters commercially, because the two categories fail differently. A weak fraud model produces false negatives you can measure. A weakly scoped AI agent produces a confident, well-formatted, wrong output that flows into a downstream system before anyone reads it. The rest of this piece is about the second category, because that is where the questions are currently unanswered.
If the governance side of that is what you are working through, the companion piece on AI agents in financial services and how to govern them covers the accountability structure. This one covers the security controls.
The security concerns that actually show up in banking AI systems
The useful thing about 2026 is that the threat categories are no longer speculative. Two community standards now name them, and both were built from real incidents rather than from thought experiments.
OWASP published the Top 10 for LLM Applications 2026 on 4 August 2026, an update built on research drawn from thousands of real-world AI security incidents and mapped to NIST, MITRE ATLAS and CWE. Its companion, the Top 10 for Agentic Applications 2026, was published on 9 December 2025 and covers what happens when the model stops producing text and starts taking actions: ten categories numbered ASI01 to ASI10, running from agent goal hijack through tool misuse, memory poisoning and rogue agents.
Two shifts in the 2026 LLM ranking are worth a banking reader's attention. Excessive agency climbed, which is the direct consequence of models being handed tools and write access. And misinformation and unbounded consumption, which sat at the bottom of the 2025 list, moved up to sixth and seventh: a confidently wrong answer now feeds straight into a downstream tool rather than sitting in a chat window where a human would catch it.
The five that matter most in a lending or servicing workflow
Prompt injection through customer documents
A bank's AI reads content the bank did not write: uploaded statements, borrower emails, third-party reports. Instructions embedded in that content can be treated as instructions. The flaw is architectural, not a bug to patch, so the control is to treat every model output as untrusted input to whatever comes next.
Excessive agency
The gap between what an agent needs to do the job and what its credentials actually permit. Most deployments over-grant on day one because scoping is slower than shipping. The test is simple: list every system the agent can write to, then remove the ones the workflow does not require.
Retrieval scope and cross-tenant disclosure
Retrieval-augmented systems are only as safe as the entitlements they inherit. If the retrieval layer runs with service-account access rather than the requesting user's permissions, a relationship manager can be shown a file they were never entitled to see, and nothing in the output will indicate that.
Memory and context poisoning
Agents that carry state between runs create a persistence surface. Anything written into that store by an earlier compromised run shapes later decisions. Memory needs the same write controls and retention rules as any other system of record.
The model and tool supply chain
A model reached through a vendor API is a third-party relationship, not a black box the bank can disclaim. Version changes, tool connectors and agent frameworks all sit inside the supply chain your third-party risk programme is expected to govern.
None of these are exotic. They are the standard consequences of putting a probabilistic component inside a workflow that was designed around deterministic ones.
What changed in the rules in 2026
Three developments in 2026 changed the compliance backdrop for this, and they point in different directions.
The US model risk framework stepped back. On 17 April 2026 the Federal Reserve, the OCC and the FDIC issued revised interagency guidance on model risk management, published as SR 26-2 and OCC Bulletin 2026-13, superseding the SR 11-7 framework that had governed model risk practice since 2011 along with the 2021 BSA/AML model risk statement. The revised guidance is principles-based and risk-tiered, scaling to an institution's size and complexity. It also explicitly excludes generative and agentic AI models from its scope, on the basis that they are novel and rapidly evolving. The traditional models are covered. The systems generating the most new security surface are not.
Treasury filled part of the gap voluntarily. On 19 February 2026 the US Department of the Treasury announced the Financial Services AI Risk Management Framework, developed by the Cyber Risk Institute with the Financial Services Sector Coordinating Council and more than 100 financial institutions, alongside an AI Lexicon for the sector. The FS AI RMF is structurally aligned to the NIST AI RMF and expands it into 230 control objectives spanning governance, data, model development, validation, monitoring, third-party risk and consumer protection. It is non-binding. It is also the closest thing the sector has to an examination-shaped control taxonomy for AI, and voluntary frameworks in this sector have a history of becoming examination scaffolding.
The EU moved its hardest deadline, but not all of them. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It defers the high-risk obligations for standalone Annex III systems, a list that includes creditworthiness assessment, from 2 August 2026 to 2 December 2027, and Annex I product-embedded systems to 2 August 2028. What did not move: the Article 50 transparency and AI-content-labelling duties took effect as scheduled on 2 August 2026, the general-purpose AI provider obligations have applied since August 2025, and the Article 5 prohibited practices have been in force since February 2025.
| What | Status as of September 2026 | What it means for an AI deployment |
|---|---|---|
| SR 26-2 / OCC 2026-13 | In effect since April 2026; supersedes SR 11-7 | Covers traditional models. Generative and agentic AI are out of scope, so the control framework for those is the institution's own. |
| FS AI RMF | Released February 2026; voluntary | 230 control objectives aligned to NIST AI RMF. The most practical starting inventory for an AI control programme. |
| EU AI Act, Annex III high-risk | Deferred to 2 December 2027 | Credit scoring obligations are delayed, not withdrawn. The requirements themselves are unchanged. |
| EU AI Act, Article 50 transparency | Applied from 2 August 2026 | Disclosure duties for chatbots and synthetic content are live now, including for customer-facing banking assistants in scope. |
The practical reading for a bank or a credit union: there is no external checklist that will tell you your generative AI deployment is adequately secured. There is a voluntary control taxonomy, a set of deferred obligations, and an expectation that you can explain your own reasoning.
What a secure AI architecture for banks and fintechs looks like
Secure AI architectures for banks and fintechs tend to converge on the same seven controls, because they are the ones that survive an examiner asking how you know.
1. Scope the agent to one workflow, not one function
Permissions granted for a broad mandate are impossible to justify later. An agent that spreads financials should not hold credentials to change a loan status. Narrow scope is the single control that limits blast radius most reliably.
2. Run retrieval on the requester's entitlements
Not on a service account. If the system cannot enforce the same access rules a person would face, it will eventually surface something it should not, and you will find out from a customer rather than from a log.
3. Treat model output as untrusted input
Validate and constrain anything that flows from a model into another system. This is the only durable answer to prompt injection, because the injection itself cannot be filtered away reliably.
4. Gate consequential writes behind a person
Reversibility is the useful test. Extraction, classification and drafting can run ahead of a human. Approving, declining, disbursing or changing a customer record should not. This is also what makes the audit story defensible.
5. Cite every figure back to its source
An output a reviewer cannot trace is an output a reviewer has to redo. For document-driven work, field-level citation back to the page and line is the difference between a checkable system and a plausible one.
6. Log the version that ran
Which model, which prompt, which tool version, which document, and what a human changed afterwards. If that record is not retrievable months later, you cannot reconstruct a decision during an examination or a dispute.
7. Monitor for drift and for silent vendor change
Model behaviour changes when the vendor updates it. Without a scheduled evaluation against a fixed test set, the first signal of a regression is an operational error, not a metric.
How to evaluate AI vendors on security and compliance
Most institutions will meet AI security through procurement rather than through a build. These are the questions that separate a vendor with a security architecture from a vendor with a security page, and they are worth asking before the pilot rather than after it.
- Data handling. Are our documents or customer data used to train anyone's models, by default and under the contract? Where is data processed and stored, and is tenancy shared or isolated?
- Permissions. Which systems can the product read from, and which can it write to? Can those be restricted per workflow, and who approves a change to that scope?
- Identity. Does retrieval run under the end user's entitlements or a service account? How are agent credentials issued, rotated and revoked?
- Traceability. Can you retrieve, twelve months from now, which model and prompt version processed a specific item, what it produced, and what a person changed?
- Human control. Which actions are gated behind a human by default, and can we tighten that ourselves without a change request?
- Change management. How are model updates governed, announced and testable before they reach our production environment?
- Evidence. What will we receive for our model risk function and for an examination: the SOC 2 Type II report and its scope, penetration test summaries, an FS AI RMF or NIST AI RMF control mapping, and documentation of red-teaming against the OWASP categories.
- Incidents. What triggers a notification to us, on what timeline, and what are our audit rights?
A vendor that answers the traceability and permissions questions concretely is usually a vendor that built for regulated deployment. A vendor that answers with a certification logo has told you about their office security, not their product. Our companion piece on SOC 2 Type II and the questions to ask a commercial lending AI vendor goes deeper on the evidence side.
Where Uptiq fits
Uptiq builds domain-trained AI agents for commercial lending workflows: document intake and extraction, financial spreading, credit memo drafting, covenant monitoring. Those are document-heavy, evidence-producing and reviewable, which is deliberate. They are the category of work where an agent can carry the volume and a human still owns the decision.
The security-relevant design choices follow from that. Extraction runs at 95%+ accuracy with every figure cited back to the source document, so a reviewer can check rather than re-key. Agents are scoped to a single workflow rather than a function, which keeps permissions defensible. Deployment starts with one agent in about five business days rather than a platform migration, which means the governance question is answered for one narrow use case before it is answered for twenty. More than 150 financial institutions run on the platform, and it connects through 100+ integrations rather than replacing a core or an origination system.
None of that removes the institution's own work. The seven controls above still belong to you. What a vendor can do is make them possible to evidence.
Frequently asked questions
What are AI security solutions in digital banking?
The term covers two distinct categories. The first is AI used to defend the bank: fraud scoring, anomaly detection, behavioural authentication and alert triage, a mature category with established controls. The second is the set of controls needed to secure the generative and agentic AI a bank already runs inside its core, origination, servicing and contact centre systems. That second category covers prompt injection defence, permission scoping, retrieval entitlements, memory integrity, human gating of consequential actions, version logging and model supply chain governance. Most institutions have a mature programme for the first and an assumption for the second.
What are the biggest AI security risks for banks in 2026?
Prompt injection through content the bank did not write, such as uploaded customer documents and borrower emails; excessive agency, where an agent holds broader system permissions than its workflow requires; retrieval running on a service account rather than the requesting user's entitlements, which can surface records to someone not entitled to see them; memory and context poisoning in agents that carry state between runs; and the model and tool supply chain, since a model reached through a vendor API is a third-party relationship the institution is expected to govern. The OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026 are the two standard taxonomies for naming and tracking these.
Does the revised US model risk guidance cover generative AI?
No. The revised interagency guidance issued by the Federal Reserve, the OCC and the FDIC on 17 April 2026, published as SR 26-2 and OCC Bulletin 2026-13, supersedes SR 11-7 and takes a principles-based, risk-tiered approach, but it explicitly excludes generative and agentic AI models from its scope on the basis that they are novel and rapidly evolving. Traditional models remain covered. For generative and agentic systems, the institution's own risk management and governance practices determine the appropriate controls. Treasury's voluntary Financial Services AI Risk Management Framework, released in February 2026 with 230 control objectives aligned to the NIST AI RMF, is the closest available substitute for a sector control taxonomy.
What should a bank ask an AI vendor about security and compliance?
Whether your data or customer documents train anyone's models, by default and by contract. Which systems the product can read from and write to, and whether that can be scoped per workflow. Whether retrieval runs on the end user's entitlements or a service account. Whether you can retrieve, a year later, which model and prompt version processed a given item and what a person changed. Which actions are gated behind a human by default. How model updates are governed and testable before reaching production. And what evidence you will receive for your model risk function: the SOC 2 Type II report and its scope, penetration test summaries, and a control mapping to the FS AI RMF or NIST AI RMF.
Did the EU AI Act deadline for credit scoring move?
Yes, but only the date. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred the high-risk obligations for standalone Annex III systems, which include creditworthiness assessment, from 2 August 2026 to 2 December 2027. Annex I product-embedded systems moved to 2 August 2028. The requirements themselves are unchanged; the deferral was driven by harmonised standards not being ready. Article 50 transparency and AI-content-labelling duties still took effect on 2 August 2026, the general-purpose AI provider obligations have applied since August 2025, and the Article 5 prohibited practices since February 2025.
Regulatory descriptions reflect publicly available sources as of September 2026, including the revised interagency model risk management guidance issued in April 2026, the Financial Services AI Risk Management Framework published in February 2026, Regulation (EU) 2026/1744, and the OWASP GenAI Security Project's 2026 Top 10 lists. Guidance, timelines and supervisory expectations change, and how any of it applies to a given institution depends on its charter, regulator and activities. Nothing here is legal, compliance or supervisory advice; confirm with your own legal, compliance and model risk functions.
Start with one workflow, on your own documents
Tell us which stage is consuming your team's week and we will run it on the files you actually receive, with every figure cited back to the page it came from.
