Wednesday, October 14Global edition

Banks race to verify that AI agents had authority before payments go through

AI agents are beginning to initiate and route payments inside enterprise workflows, but a technically valid transaction can still lack proof that the agent was authorised to act. Banks, payment networks and compliance vendors are building verification layers to test authority, provenance and evidence before funds move.
Empty bank operations centre with payment-monitoring screens glowing in the darkIllustration image generated with AI
Generated by AI
Share

AI agents are starting to initiate, route and execute payment decisions inside enterprise workflows, forcing banks to address a control problem that traditional payment authentication does not resolve. A bank may be able to validate a payment channel, credential and network rail. It may still lack proof that the particular agent had permission from the enterprise to act when funds moved.

Financial institutions, payment networks and compliance vendors are converging on an independent verification layer between an agent and the systems of record that hold authoritative data. The model remains an analytical architectural concept rather than a formal regulatory category. Its purpose is to test a proposed action before it reaches the conventional application or authorised human that commits a change.

The distinction matters because a transaction can be technically valid while lacking evidence that an agent had enterprise approval to make it. Chief financial officers, auditors, regulators and boards will want to know who authorised the agent, the limits on that authority and the payment to which it applied.

A useful design uses two stages. The agent proposes an action and gathers evidence in support of it. A separate service then compares the proposal with policy and current authoritative data before a conventional application or authorised human completes the transaction. In higher-risk workflows, that verifier should preferably rely on deterministic rules or independently governed services. Asking a second language model to agree with the first provides a weaker form of control.

The first test is authority. A verification layer needs to establish the agent's identity and the identity of the person, process or customer for whom it is acting. A neutral authority registry could check the agent's mandate, limits, delegation chain, revocation status and audit evidence before money moves.

Permission may need to be tied to a particular task, account, transaction value, time window and purpose. An agent allowed to assemble an anti-money laundering, or AML, case should not automatically receive authority to close it. An agent permitted to draft a payment should not automatically be able to release funds.

Regulators in jurisdictions including member states of the Financial Action Task Force have begun indicating that the beneficial owner of an agent carries know-your-customer, or KYC, responsibility. That approach places responsibility with an identified human or entity and makes broad access to payment credentials harder to justify.

Provenance forms the second check. Institutions need to identify the facts an agent used and determine whether those facts came from approved sources. The third is internal consistency, which tests a proposal against the institution's deterministic constraints. These can include accounting identities, product rules, customer status, sanctions restrictions, credit limits, settlement cut-offs, transaction ceilings, required approvals and mandatory fields.

The fourth check is evidence. An institution needs to be able to reconstruct what the agent saw, the tools it called, its proposed action, the rules applied, the approvals received and the information ultimately written into the system of record. That record is central to audit and compliance when a payment decision is later challenged.

Existing compliance technology offers part of the required infrastructure. Several established payment-compliance platforms have application programming interface, or API, architectures that technical teams can call during an agent's transaction workflow. They typically perform sanctions screening, politically exposed person checks and basic AML pattern matching. Several AML vendors are also extending APIs for programmatic use, enabling agent-based systems to submit transaction metadata and receive risk scores.

Payment networks are pursuing related approaches. Mastercard's Agent Pay framework describes registered agents that use network tokens, allowing their activity to be governed and traced. Its Verifiable Intent initiative centres on authenticated user intent and explicit consent, with the aim of creating an auditable connection between an instruction and later action by an agent.

Institutions are weighing several implementation paths. They can develop governance middleware, use third-party APIs, build controls into banking-as-a-service infrastructure or explore blockchain-native systems. Smart contracts and blockchain platforms can encode spending limits and requirements for approval by multiple parties. The relative scalability and auditability of those approaches at enterprise scale remains unclear.

Other questions remain unresolved. There is no settled answer on whether a common standard for agent identity and authorisation will emerge, how liability will be assigned after an unauthorised payment, or how delegation and revocation should work when agents can sub-delegate authority. Deterministic verification also faces a test in unusual transactions that fall outside pre-defined policy. For now, the emerging model combines established payment-security measures, AI-driven fraud detection and governance designed specifically for agents, while keeping payment authority within defined limits.

Sources (4)

Topics

More from The Modern on this topic:

Julian HaleTech

Julian Hale covers corporate power and the people who wield it — boardrooms, deals, and the money moving behind the headlines. Meticulous, well-sourced, and hard to impress with a press release.

Comments (0)