Before giving AI agents power, bankers should ask questions 

Visa, Mastercard and Ant International announced an initiative this month to develop common standards for identifying and verifying AI agents that make purchases on behalf of users. The collaboration brings a practical challenge for banks into focus: How much authority should an AI agent receive?

Processing Content

Banks face a corresponding set of decisions within their operations. An agent may be capable of reviewing a payment request, investigating an exception and initiating a transfer. Each carries different consequences and should require a different set of permissions. 

The distinction becomes clearer when banks examine workflows through three models of human-AI collaboration: AI-led, where AI performs a task within well-defined limits; AI + HI, in which artificial and human intelligence work together; and HI-led, in which people direct the work and exercise judgement with AI support. A single workflow can contain all three. The appropriate mode depends on the action being delegated and the bank's ability to manage its consequences. 

Three questions can help translate that approach into decisions about agent authority.

What should the agent be allowed to do?

A broad mandate such as "resolve payment exceptions" leaves too much unspecified. Resolution might involve retrieving a record, comparing an invoice with payment instructions, contacting a customer or changing a beneficiary. Banks should define permissions at the level of these actions, including the information an agent can access and changes it can make to the system.

Consider an illustrative payment workflow. An agent could gather supporting records and identify a mismatch within an AI-led process. A banker could review its explanation and determine the next step in an AI + HI process. A request to change beneficiary details could require a person to lead verification and approval, with AI assisting in assembling the evidence. The bank would assign these models according to its compliance process and the circumstances of the transaction. 

This requires business judgement before technical configuration. The bank needs to decide which exceptions fit established rules, which require interpretation and which actions create commitments to customers or other parties. Those decisions should determine the agent's access and execution limits. 

Can the bank catch and reverse a mistake?

How much judgement a task requires is one consideration. Another is whether the bank can detect an error early enough to contain it and reverse its consequences.

An incorrect internal summary may be corrected before anyone relies on it. The same error becomes more consequential if it changes payment instructions or feeds another automated process. Even a routine-looking task can warrant a closer look when mistakes remain hidden until after execution. Conversely, a narrowly defined action may be suitable for greater autonomy when its results are promptly checked and recovery is straightforward.

Banks should therefore examine the point at which an action becomes consequential. Can an incorrect payment be stopped before release? Would an erroneous record change be detected before other systems use it? Could the bank restore the previous state without affecting customers or downstream processes? Reversibility is an important factor to consider in delegating tasks to agents.

These questions connect governance with measurement. In addition to completion rates and processing time, a bank should track exceptions, time to detection, recovery effort and the consequences of errors. Average accuracy alone cannot establish an appropriate level of authority when a small number of failures could have disproportionate effects. Where detection is slow or recovery uncertain, the bank has a stronger reason to require approval before execution.

Who owns the outcome and can stop the agent?

Delegation also requires an organizational decision. A bank should identify a business owner accountable for the workflow if it is not already clear, establish when exceptions must be escalated and give designated staff the authority to suspend the agent. Those responsibilities need to be understood across the business and technology functions.

This is a practical application of the T-shaped teams approach: combining specialist depth with sufficient understanding across disciplines to deliver a working process. Business staff understand the customer and operational consequences. Technology staff understand the agent's access and system dependencies. Risk and compliance staff help define acceptable boundaries. Together, they should determine how intervention will work under production conditions.

A person assigned to review an agent needs the information, time and authority to act. If an agent processes exceptions faster than staff, the review queue itself becomes a constraint. Banks should test whether staff can reconstruct an action from its records, recognize an escalation trigger and stop further execution before the problem spreads.

Authority should expand as the team demonstrates that the workflow performs reliably and that exceptions can be contained. Changes to the agent, its data or its permissions should prompt a fresh assessment. For banks, the next step in human-AI collaboration is to make delegation explicit: which actions AI can take, under what conditions and with whose accountability.  


For reprint and licensing requests for this article, click here.
Artificial Intelligence Market Intelligence
MORE FROM AMERICAN BANKER
Load More