Banks already use AI for fraud detection, risk scoring and customer service. The next problem is materially different: agents that can call tools, alter records, initiate transactions and chain decisions together faster than people can intervene. Regulators increasingly want proof that permission, accountability and stopping mechanisms survive the automation.
The shift from prediction to delegated action
A credit model that predicts a probability of default is not the same system as an autonomous agent that reads a customer’s file, chooses a decision, sends a legally consequential message, updates the account and instructs a payment service. The former produces an output that another process may interpret. The latter can execute a sequence whose individual steps may each appear legitimate while the final result exceeds the customer’s or institution’s authority. That is the operational distinction making regulators more concerned about agentic AI than ordinary automation.
On October 15, 2026, the Financial Stability Board finalized 12 sound practices for responsible AI adoption by financial institutions, addressing board responsibility, documented use cases, human oversight, ICT and third-party risk, explainability and lifecycle controls [1]. These are international sound practices, not a new enforceable statute. The FSB’s final publication makes the timing important: a June consultation has now become a finalized supervisory reference point, even while each jurisdiction retains its own legal regime.
The Bank of England’s July 2026 Financial Stability Report said agentic systems can complete multi-step tasks at machine speed and highlighted the possibility of correlated behavior, shared-supplier disruption and AI-enabled cyber risk [2]. The concern is not that every bank already has fully autonomous investment agents. The Bank explicitly described current financial-market uses as more common in research, coding assistance and surveillance than direct autonomous trading. The concern is that growing capability can change what banks are able to deploy before conventional governance adapts.
This is connected to behavioral biometrics for detecting financial fraud: authentication and anomaly detection can help prove a session behaves unusually, but they do not by themselves establish that an AI agent was allowed to initiate a transfer, edit a credit decision or override controls.
A surprising US regulatory gap: existing model guidance is not the agent rulebook
US banking authorities updated model-risk guidance in April 2026. The OCC explicitly stated that generative AI and agentic AI models are outside the scope of that updated guidance, reflecting their novel and evolving characteristics [3]. The OCC, Federal Reserve and FDIC also indicated they intended further information-gathering about AI risk. That should not be misread as permission for banks to deploy autonomous agents without safety obligations. Cybersecurity, privacy, consumer protection, safety-and-soundness, operational resilience and third-party oversight remain relevant depending on the bank and activity.
The distinction matters to board members. A traditional validation programme can test statistical performance, bias and parameter drift. But an agent with dynamically selected external tools introduces questions that conventional model validation alone cannot answer: which software tools were available, what authenticated principal initiated a call, what information entered its context, which rules were binding, what action was submitted, and who could stop it before funds moved. An agent can use a well-performing underlying model and still fail because an API credential grants excessive authority.
The FSB’s finalized practices are cross-cutting rather than a one-model checklist. They emphasize materiality assessment, data governance, human oversight, cyber controls, external dependencies and ongoing performance testing [1]. A useful audit therefore evaluates not only the model but also the entire action chain.
Five ways a bank agent can fail while behaving ‘intelligently’
| Failure | What goes wrong | Preventive control |
| Authority | Agent spends without consent | Scoped mandate, hard limits |
| Context | Invoice injects new payee | Untrusted-data isolation |
| Compound error | Erroneous chained API calls | Multi-step transaction validation |
| Common mode | Same provider breaks many banks | Concentration/exit testing |
| Recourse | No explanation or remedy | Replayable evidence, appeals |
Table 1. Risk taxonomy for autonomously executed financial workflows.
First, an authority failure occurs when an authenticated agent performs an action it was never delegated. For example, a customer tells an assistant to ‘prepare the transfer’ and it submits the payment without approval. Identity is necessary, but not sufficient: a recognized actor may still exceed its mandate.
Second, a context failure happens when source text from a document, website or message is treated as an instruction. A malicious invoice note could say to change the beneficiary account. The agent might parse it as an operational command if trusted instructions and untrusted data are mixed. This is the prompt-injection problem translated into a bank’s money-moving environment.
Third, a compound-error failure emerges when small mistakes reinforce one another. A model classifies an exception incorrectly, then edits the customer file and clears a warning before initiating a downstream transfer. Each API log might record a normal call, but the sequence is economically harmful.
Fourth, a common-mode failure comes from many firms deploying similar models, data sources and vendor tools. If the same news signal drives numerous AI trading services to de-risk simultaneously, market liquidity could deteriorate. If a shared supplier suffers a cyber problem, many banks could fail in parallel. The Bank of England’s financial-stability analysis specifically singles out interdependencies at common providers as a transmission route [2].
Fifth, a recourse failure arises after a wrong decision. A customer whose legitimate payment was blocked needs a traceable reason, prompt review and a responsible institution—not a message saying ‘the algorithm did it.’ The bank cannot outsource accountability to a vendor’s chatbot.
Figure 1. Original process architecture for a bank agent: each layer requires evidence and independent authorization.
What the adoption data actually tells us
The Bank of England and FCA’s 2024 survey found 75% of responding financial firms already used AI, a further 10% planned use within three years, and around one-third of AI use cases relied on third-party implementations. It reported concentration among the top three providers of approximately 73% for cloud, 44% for models and 33% for data, measured within their respective provider categories [4]. These are survey measures from 2024, not a current 2026 agentic deployment rate, and the provider percentages have different denominators.
The figures matter because banks can buy faster innovation while accumulating correlated technology dependency. A vendor’s model may satisfy a firm’s accuracy threshold but depend on one cloud account, one vector-search service, shared authentication, one orchestration framework and one payments tool. A single control-plane error can therefore disable several independently branded applications. Governance should map those dependencies at the workflow level rather than treat every vendor invoice as an isolated supplier.
Figure 2. 2024 BoE/FCA survey: top three suppliers within cloud, model and data categories; categories have separate denominators.
Adoption is not evidence that every application acts independently. The useful measure of autonomy is what an agent can actually read, decide and write, and whether a human can reverse or prevent the effect. This suggests an authorization ladder: read-only retrieval; drafting without execution; recommending decisions; executing bounded reversible actions; and independently initiating high-value irreversible actions. The same underlying model can occupy any of these levels depending on tool access.
An expected-loss model for controlling autonomy
Figure 3. Derived scenarios: 100,000 actions × assumed error rate × $1,000 severity; 90% mitigation represents an assumed control effect.
Consider a hypothetical transaction agent handling 100,000 requests each month. Suppose 0.3% of instructions would result in an erroneous transaction absent additional checks—300 events. If the average consequential loss per event is $1,000, gross expected loss is $300,000 before controls. A bank introduces hard transaction caps, beneficiary allowlists, structured instruction verification and dual approval for anomalous transactions that together block 90% of loss-bearing errors. Residual expected loss falls to $30,000 under this toy model.
If those controls cost $80,000 monthly in infrastructure and human review, the net modeled benefit is $190,000, ignoring avoided remediation and reputational harm. But the result changes with transaction volume, error probability, average severity, effectiveness and false-positive cost. If only 0.03% of requests are loss-bearing errors, baseline modeled loss drops to $30,000; an $80,000 review programme would need other benefits to justify its cost. These are invented sensitivity parameters, not observed bank loss rates.
The crucial insight is that permission boundaries can reduce the severity of an error even when model accuracy does not improve. For example, a hard rule that a bot cannot send more than $500 without fresh customer confirmation limits one class of exposure. It does not protect against many repeated $499 transfers unless aggregate and velocity limits also exist. Effective limits must bind across time, beneficiaries and identities—not only individual clicks.
Model risk cannot be monitored with accuracy metrics alone. A bank should track erroneous actions per 10,000 tool calls; value of actions requiring human override; false-positive review burden; time from alert to suspension; irreversible-value at risk before detection; and exceptions involving untrusted external instructions. These metrics tie model behavior to financial harm.
Why human oversight sometimes fails at machine speed
‘Human in the loop’ can be an empty phrase if a reviewer has two seconds to inspect a hundred queued payments or if the proposed rationale is generated by the same agent that initiated the action. Human oversight needs a meaningful decision window, the original source data, an understandable comparison to the authorization mandate and a genuinely independent ability to reject. Otherwise the human serves as a decorative signature.
A more precise design lets low-risk, reversible actions proceed automatically under tight constraints, while escalating high-value transfers, new beneficiaries, credit-denial decisions or broad account restrictions for independent review. A system should not be able to modify its own approval threshold, hide audit events, grant itself new credentials or approve its own exceptions. Administrators should be able to revoke tool credentials and halt a running workflow even if the language model continues generating text.
The Bank of England, FCA and UK Treasury’s May 2026 statement urged firms to strengthen protective, detection, containment and incident-response capacity against faster frontier AI cyber threats [5]. It was a supervisory warning about resilient security, not a claim that frontier models could already compromise every well-defended bank. The July report similarly discusses both expanding capabilities and real-world limitations [2]. An article that treats worst-case capability tests as confirmed mass attacks would exaggerate the evidence.
Third parties, cross-border rules and the accountability chain
A bank may contract with a model provider, a cloud host, an identity vendor, a payments processor and several data services. Yet customers usually have a direct relationship with the bank, not every subcontractor. Regulators need a named accountable function, meaningful audit rights, exit planning, reliable incident notification and access to evidence when an agent causes harm. A contract promising 99.9% uptime does not prove suitability for credit or payments decisions.
US agencies published proposed revised third-party risk-management guidance in September 2026 [6]. It should be described as a proposal, not binding new rules. In the EU, the AI Act operates alongside financial-sector requirements; applicability depends on the activity, system classification, deployment role and the act’s phased implementation [7]. DORA’s operational resilience and ICT supplier oversight may also matter for covered financial firms. There is no single globally uniform ‘agentic banking licence.’
The Financial Stability Board’s 12 practices provide a useful common language, but the enforcement perimeter comes from local banking, privacy, payments and consumer rules. Audit findings must therefore specify jurisdiction, legal entity, process, role and system boundary. A global bank cannot assume that a third-party AI tool cleared by one market is approved for all financial decisions everywhere.
digital-bank fees, features and deposit protections illustrates the same legal lesson in another context: an elegant app may make unlike legal products appear uniform. With agentic AI, the analogous mistake is to treat every automated action as if it carried the same permission, consumer recourse and auditability.
A practical control architecture regulators can inspect
| Control | Independent test |
| Permission | Try an out-of-scope transaction |
| Value and velocity | Attempt many small repeated transfers |
| Third-party input | Inject new payee into invoice text |
| Human approval | Validate review evidence and time |
| Containment | Revoke credentials during active workflow |
Table 2. Suggested adversarial audit tests, not a universal statutory checklist.
A robust workflow separates at least six components. Identity establishes whether the customer or employee is genuine. Intent capture records the requested outcome, amount, payee, time limit and exceptions. Mandate enforcement converts that intent into machine-verifiable constraints and denies actions outside scope. Tool isolation gives each function the least permission necessary. Transaction authorization verifies the final action using trusted systems rather than untrusted model prose. Evidence and recovery preserve immutable or tamper-evident logs and an operational escalation path.
Take a simple bill payment. The user may instruct an assistant to pay a $120 electricity bill. An agent can find the correct invoice, but it should not silently accept an account number from a random email, add a new beneficiary and send $1,200 because the email said the old bill had penalties. Hard upper bounds, payee confirmation and separate bank-side validation prevent the model’s mistaken interpretation from becoming irreversible authority.
The same architecture applies to customer-service agents that waive fees or change account details. A fee waiver is lower stakes than a six-figure transfer, but repeated unauthorized waivers can create losses and discrimination across customers. Policy evaluation must be explicit, not inferred from a successful natural-language exchange.
A useful bank audit tests the negative case: can the agent be induced to spend more than the ceiling, reroute payments, approve blocked jurisdictions, alter its own system prompt or conceal what it did? Testing only normal prompts measures usability, not boundary integrity. Simulated adversarial instructions and end-to-end rollback exercises are necessary for any system entrusted with financial authority.
Why fraud detection and autonomous execution are different problems
AI used to flag suspicious activity can make large volumes of decisions, but it usually recommends a review outcome. Autonomous AI that executes payments changes the principal risk from decision quality to the combination of decision quality and enforceable authority. Even very accurate models can be unsafe if given unrestricted payment credentials.
The user-side version of this principle appears in what crypto-wallet scam permissions reveal about delegated authority: recognizing a legitimate application is not identical to consenting to an unlimited token allowance. In banking, authenticating a valid AI agent is similarly not equivalent to authorizing each transaction it proposes. The critical trust boundary lies between the recommendation and the executable instruction.
What would show that regulators’ fears are overstated?
Evidence would include robust, independent measurements showing that agents execute only within explicit mandates; failure rates remain low under adversarial conditions; high-value mistakes are intercepted before settlement; human appeals succeed quickly; and independent vendors do not create common-mode disruption. Wide deployment of read-only or draft-only agents with tightly separated execution channels would also reduce the most serious concerns.
Conversely, repeated unauthorized transfers, weak audit logs, inadequate override capacity, serious vendor concentration incidents, or credit decisions made without usable explanations would support closer supervision. The debate is not whether AI is inherently unsuitable for banks. It is whether banks can demonstrate risk boundaries that are stronger than the agent’s ability to improvise.
Bottom line
Regulators are worried because autonomous systems can move from suggesting a decision to exercising financial authority. The latest primary evidence includes the FSB’s final 12 sound practices on October 15, the Bank of England’s systemic-risk work, and the OCC’s recognition that its revised conventional model guidance does not directly cover novel agentic models. A bank that governs only model accuracy may miss the loss channel. What matters is permission design, reliable evidence, incident containment, third-party dependency management and meaningful customer recourse. For customers, the practical test is simple: can a software agent act without specific permission, and if it acts wrongly, who can stop it and make the customer whole?
Methodology and limitations
Research cut-off October 18, 2026. Institutional guidance is distinguished from binding law and proposals. The 2024 BoE/FCA survey is not presented as a 2026 adoption census; cloud, model and data concentration measures have different denominators. Expected-loss calculation equals actions × error probability × average financial loss, with an assumed control effectiveness applied to the result; it does not estimate industry loss rates. Control costs and transaction examples are hypothetical. Citations prioritize central banks and banking supervisors; legal outcomes and customer recourse vary across jurisdictions. This analysis does not assume current AI systems can routinely conduct undetected attacks on defended banks.
Sources
[1] Financial Stability Board, October 15, 2026 — final 12 AI sound practices — Open source
[2] Bank of England, July 2026 — Financial Stability Report, frontier AI chapter — Open source
[3] OCC, April 17, 2026 — revised model-risk guidance and agentic-AI exclusion — Open source
[4] Bank of England/FCA, November 2024 — survey of AI adoption and concentration — Open source
[5] Bank of England/FCA/HMT, May 15, 2026 — cyber-resilience joint statement — Open source
[6] OCC, September 11, 2026 — proposed third-party guidance — Open source
[7] European Commission — EU AI Act regulatory framework — Open source
[8] FSB, June 10, 2026 — original consultation on AI sound practices — Open source
[9] FSB, October 15, 2026 — consultation-response analysis — Open source
[10] Federal Reserve — updated supervisory guidance on model risk — Open source
[11] OCC, April 2026 — bulletin summarizing model risk — Open source
[12] Reuters/FT, October 18, 2026 — central-bank AI agent accountability concern — Open source
[13] Bank of England, May 2026 — prudential regulatory digest — Open source
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574