An agent that explains a payment exception is doing a very different job from one that can repair it. The second may be able to change a record or call a payment tool. If we assess only what that agent says, we miss the riskiest part: what it can do.
Our experience at Sibos 2026 in Miami highlighted the distinction between agents merely providing information and those capable of taking action. Interest in agents is growing across payments, trade, servicing, and other operational workflows. AI was featured in discussions about compliance, market infrastructure, and programmable money. The importance of security and auditability was clear.
Our report supports that institutions really want AI in production. However, not all banks are moving at the same pace, nor has every institution finished piloting agents. For a bank considering an agent in a financial workflow, a more useful question is: what evidence would justify giving it meaningful authority?
Payment workflows with authority make testing essential
Payment routing, repair, initiation, and orchestration were all discussed as possible use cases for agents. Each gives the agent a different level of authority. An agent that suggests a correction should not be tested like one that can submit a transaction.
Take a hypothetical payment-repair workflow. The agent can fix formatting and prepare a repair, but it cannot change the beneficiary or release the payment without separate approval.
A good test would push against those limits. For example, an exception message might try to turn a permitted repair into an unauthorized change. The agent should block the action or escalate it, leaving the payment untouched.
A reassuring chat reply isn't enough. We need to see the attempted action and what the connected service allowed. A rejected tool request is very different from an unauthorized change being accepted. The report should make that difference crystal clear.
Platform controls are only part of the test
One of our most useful observations was how banks are approaching AI security. Our report describes institutions turning to existing cloud, AI, and infrastructure providers for governance and security. This leaves a gap. Independent adversarial testing of agent workflows, what we call AI Agent Assurance, is an essential, complementary component to what these large providers already offer.
What matters most is how those safeguards work together in a real deployment. For the hypothetical repair agent, we would test the tools it can call, the records it can change, and the point where a person is expected to step in.
Before testing, the bank and its providers should agree on expected behavior, including where permitted corrections should go. Anything outside the agent's remit should fail or reach the right reviewer. The evidence should show both outcomes.
Mace Ai is structured to easily work alongside the institution and its providers to run those tests. Platform safeguards tell part of the story; evidence from the configured workflow tells the rest.
Human oversight should change the outcome
As discussed, we found a robust but practical appetite for AI adoption. Strong controls plus a human to provide judgment around consequential decisions remain important. Our recommendation is to turn that expectation into something a test can prove.
For the repair agent, human oversight should change what happens. Without the required approval, the restricted action should not occur. Once approval is given, it should cover only the action the reviewer approved.
We would test what happens when a message tells an agent that a payment is urgent or has already been approved. Does the workflow still verify the required approval before allowing the payment to proceed?
The evidence should also clearly state what the test can and cannot observe. A tool-call record may show that the agent requested an action. A record from the connected system may show that it accepted the request or that something changed. If downstream execution is not visible, the report should clearly say the outcome remains unverified.
Programmable money raises the stakes
Stablecoins, tokenized assets and programmable money were discussed alongside AI and automation. The conference program covered agentic payments, AI and ISO 20022, as well as a Temenos session on agentic commerce and programmable money.
The conversations did not establish how widely autonomous financial agents are operating across those systems. However, the potential opportunities explain why people increasingly discuss the topics together. The combination is especially relevant because these are high-consequence environments where action-level testing matters.
An agent's authority deserves as much scrutiny as the infrastructure it uses.
Four questions to ask before testing a payment agent
We use four questions to define the starting scope of an assessment.
- Authority: Which actions may the agent take and not take? Include actions it can attempt through otherwise permitted tools.
- Approval: Where is human approval enforced, and what evidence shows that a restricted action cannot occur without it?
- Adversarial behavior: Can an input or a sequence of interactions push the agent outside the agreed workflow? Record attempted violations separately from actions that succeed.
- Evidence: What can the assessment observe in the agent and its connected systems? Distinguish requests, accepted actions, and confirmed state changes, and identify anything the test cannot verify.
Together, these questions give the assessment a clear purpose. The institution can decide what evidence it needs before approving a particular level of authority, investigating a finding, or changing a control.
Fisher is Mace Ai's adversarial testing platform that helps determine a workflow's vulnerability. The goal is evidence about a specific agent under specific conditions, not a blanket claim that the agent is safe. The evidence gives decision-makers a firmer basis for deployment.