How Should Financial Institutions Control AI Agents That Can Move Money?

What Are AI Agent Banking Controls?

AI agent banking controls are the rules, permissions, monitoring, and human oversight used when software agents initiate, recommend, or execute banking activities. An ordinary chatbot answers questions, while an agent may retrieve account data, prepare a payment, select a vendor invoice, negotiate terms, or submit a transaction through an API. That difference changes the risk from incorrect information to potentially unauthorized financial action. Controls should therefore be built around the transaction, the agent’s identity, the data it can access, and the systems it can change. The central question is not whether the model is generally accurate; it is whether the institution can prove, for each decision, who authorized it, what information it used, what limits applied, and how the activity was detected and reviewed.

Also worth reading: How Do Financial Institutions Establish AI Audit Trail Compliance for 2027 Regulatory Standards? · How Can Financial Institutions Effectively Implement Algorithmic Bias Mitigation Strategies in 2026? · What are the specific SR 26-2 spreadsheet model inventory requirements for financial institutions?

A practical control model combines preventive, detective, and corrective safeguards. Preventive controls restrict an agent to approved accounts, transaction types, currencies, counterparties, and dollar limits. Detective controls record prompts, tool calls, retrieved documents, approvals, and transaction events in an immutable audit trail. Corrective controls include reversal, suspension, model quarantine, dispute handling, and escalation to a human investigator. The model should also be assessed for prompt injection, data leakage, poisoned documents, excessive permissions, tool confusion, and failure to follow business rules. The Monetary Authority of Singapore, EY, AWS, and the World Economic Forum have all emphasized that agentic banking requires stronger governance than conventional chatbot deployment because agents can affect operational outcomes directly.

Why Traditional Banking Controls Are Not Enough

Traditional banking controls were designed mainly around human users and deterministic applications. A dual-approval rule may work when two employees examine a wire, but it can fail if an agent creates the payment, changes the beneficiary, and automatically retries after an exception. Similarly, a system that limits a person to one million dollars per day does not automatically prevent an autonomous process from splitting transactions across many accounts or invoking a compromised tool repeatedly. The control must follow the effective authority of the agent, not merely the employee account that launched it.

The agent’s behavior can also change without a software release. A new tool, a revised invoice, a changed model, a web page containing hostile instructions, or a new prompt can alter what the system decides to do. A static rule such as “block transactions over $50,000” remains meaningful only if the bank also controls beneficiary changes, token creation, account access, and retry behavior. Institutions should treat the model, orchestration layer, data sources, identity provider, payment gateway, and exception workflow as one connected control surface.

There is no universal percentage that makes an agent safe. A 99% accuracy score is not equivalent to 99% control effectiveness, especially when the remaining one percent includes fraud, privilege escalation, or a high-value payment. Institutions should use risk-based thresholds, with stricter limits for new agents, unfamiliar counterparties, sensitive data, and irreversible actions. Pilot transactions should start at immaterial amounts, but pilot status should be supported by technical restrictions rather than by a hope that human operators will notice errors.

The Minimum Control Architecture

A bank should give every agent a distinct machine identity rather than allowing it to borrow a human’s credentials. That identity should be short-lived, scoped to a particular business purpose, and unable to perform unrelated actions. Permissions should be enforced server-side at the API and ledger layers, not only described in prompts or policy documents. The system should distinguish read access from write access, recommendation from execution, and low-risk activity from a payment that creates legal or financial exposure.

Every agent action should produce a trace that can be reconstructed later. The record should include the agent version, user or process that initiated the task, timestamp, input references, retrieved evidence, tool name, parameters, policy decisions, model output, human approval, transaction ID, and final outcome. Logs should be tamper-resistant and linked to the originating invoice, customer request, or accounting entry. Storing a generic chat transcript is insufficient because auditors need to know which document caused a decision and which rule permitted it.

Human approval should be meaningful rather than ceremonial. The approver should see a plain-language purpose, beneficiary, amount, currency, payment rail, supporting evidence, and any material deviation from normal behavior. Approval should expire quickly, apply to exact transaction parameters, and be invalidated if the agent changes the amount or destination afterward. For high-value or unusual payments, institutions should require two independent controls, such as a human approval plus a separate beneficiary verification through a trusted channel.

## Practical Implementation Steps for Banks

Banks should first inventory every agent use case and classify it by the action it can take. A reporting agent that summarizes general-ledger data presents a different exposure from an agent that issues payments or changes vendor master data. The inventory should record the model provider, orchestration framework, connected tools, data classifications, counterparties, transaction limits, expected frequency, and named business owner. Agents should not be placed into production merely because a vendor calls them autonomous or production-ready.

The next step is to build a test environment using synthetic or masked data and realistic failure cases. Testing should include incorrect invoices, duplicate payments, changed beneficiaries, stale prices, conflicting approvals, prompt injection in retrieved documents, malicious tool responses, and attempts to exceed limits. Institutions should test both the model and the surrounding infrastructure because a secure model can still be used through an unsafe API. A control pass rate below 100% should be expected in adversarial testing, with zero tolerance for unauthorized high-value execution.

After testing, the bank should launch through a staged rollout. A pilot might begin with 10 to 50 low-value transactions over a 30-day period, with a hard cap of $1,000 per transaction and $10,000 in aggregate, provided the institution’s risk assessment supports those numbers. The limits are examples, not regulatory safe harbors. During the pilot, finance operations, internal audit, cybersecurity, compliance, and the business owner should review exceptions daily. Expansion should depend on observed performance, not just elapsed time or a positive vendor demonstration.

Finally, the bank should define an operating owner and an independent assurance process. The business owner remains accountable for the financial process, while model risk, internal audit, or compliance independently tests the controls. A quarterly review may be appropriate for stable low-risk agents, but agents using changing data, new tools, or payment execution should be reviewed more frequently. Material model or workflow changes should trigger reassessment before deployment.

Alternatives and Comparison of Control Strategies

Institutions can choose between preventing agent actions, requiring human approval, or allowing autonomy inside strict limits. Complete human approval reduces the agent’s speed advantage but can create approval fatigue if reviewers do not understand the transaction. Fully autonomous execution can improve processing time, but it exposes the bank to losses that may be difficult to reverse after settlement. A hybrid model is usually more defensible for payment operations: autonomy can handle data gathering and preparation, while execution remains gated by policy and human or machine verification.

A further alternative is to restrict agents to recommendations rather than direct execution. The agent can identify a duplicate invoice or propose a payment, but the existing enterprise resource planning or treasury platform performs the actual posting. This “decision support” pattern can deliver much of the productivity benefit while preserving established segregation-of-duties controls. It does not eliminate risk, because a malicious or manipulated recommendation can still influence an employee, so evidence and review remain necessary.

Cost depends on the existing stack. A narrow API-based agent pilot may cost several thousand dollars in engineering, security testing, and monitoring, while an enterprise deployment with identity management, ledger integration, observability, red-team testing, audit tooling, and vendor support can run into six figures annually. Model usage fees may be modest compared with integration and assurance costs, especially for a large bank. The more expensive issue is usually not token consumption; it is rework, payment errors, compliance investigation, and the cost of proving control operation.

Common Mistakes and Warning Signs

One common mistake is treating a model’s general accuracy as authorization. Accuracy answers whether the model is often right, not whether it is allowed to initiate a $750,000 transfer. Another mistake is putting controls only in the user interface. If the agent can call the payment API directly, browser or prompt restrictions are bypassable. Controls must exist in backend services, IAM policies, ledger permissions, and payment gateways.

Another error is using an unbounded retry loop. A temporary network failure can cause an agent to submit the same payment repeatedly, and a response timeout can create uncertainty about whether the first payment settled. Idempotency keys, transaction status checks, duplicate detection, and a maximum retry count should be mandatory. Banks should also prevent an agent from creating its own beneficiary or changing payment instructions after approval.

Prompt injection is a different failure from a hallucination. A malicious document may tell the agent to ignore policy and send funds to an attacker, even if the model was never explicitly asked to do that. Retrieved documents should be treated as untrusted data, not as policy. The agent should be unable to interpret document text as authority to change its permissions or bypass controls. Security teams should monitor tool calls and compare instructions with approved business policy.

When Should a Financial Institution Act?

A bank should act before connecting an agent to live financial data, especially if the agent can write to a ledger, initiate payments, alter customer records, or approve transactions. The threshold is capability and consequence, not whether the agent has a friendly customer interface. A read-only agent that exposes sensitive customer information can still create privacy, confidentiality, and cyber risk. A writing agent that can act on a production account requires formal model-risk, vendor-risk, security, operational-resilience, and compliance review.

A practical trigger for escalation is any combination of new payment permissions, a new model version, a new external data source, or a change in transaction volume. If an agent’s monthly volume rises from 100 to 10,000 transactions, its risk profile has changed even if the code has not. Errors involving duplicate payments, unexplained beneficiary changes, unexplained data access, or approval bypass should cause immediate suspension while the event is investigated.

The bank should also distinguish between an agent that “can” act and one that actually has authority. Sandboxes, synthetic accounts, and read-only replicas are useful early controls. However, moving a system into production without testing its permission model, logging, recovery process, and independent monitoring is not a safe transition. Waiting for a regulator to define a specific rule is also not a substitute for control design; supervisors are increasingly focused on accountability, explainability, resilience, and third-party risk.

The Audit Perspective

Internal audit and financial-audit teams should test the control as an end-to-end financial process. They should trace a sample of agent-created transactions from the originating request through invoice evidence, model decision, tool invocation, approval, ledger posting, settlement, reconciliation, and final accounting classification. The sample should include successful payments, rejected payments, manually overridden payments, reversed payments, and transactions that were escalated.

Testing should answer whether the agent could have made the same decision with altered information, whether the reviewer could detect an error, and whether the bank can prevent a repeat event. Auditors should compare the agent’s stated purpose with actual activity, examine dormant permissions, and look for differences between production and test configurations. An apparently complete log is not useful if timestamps, approvals, or tool parameters can be edited without detection.

The strongest evidence is a reproducible chain linking data, decision, authority, and outcome. That chain helps a bank identify discrepancies, explain a customer dispute, determine whether a control failed, and quantify exposure. It also makes vendor replacement or model retirement less disruptive. In agentic banking, observability is not an optional feature; it is part of financial control.

Final Control Principles

AI agents should be permitted to perform financial work only when authority is explicit, narrow, temporary where appropriate, and enforced outside the model. The bank should use least privilege, server-side transaction limits, verified beneficiaries, idempotent processing, immutable logs, independent monitoring, and tested recovery procedures. Human approval should be reserved for decisions that require human judgment, but it should be informed, independent, and impossible to bypass through a changed parameter.

The most important control is continuous reconciliation between what the agent was asked to do, what it was allowed to do, and what it actually did. That comparison should occur before execution and after settlement. As of 26 September 2026, institutions should treat agentic banking as an operational-risk and financial-control problem, not as a chatbot feature. This approach allows banks to benefit from automation while preserving auditability, legal accountability, and the ability to find discrepancies before they become losses.