The tool call that hits a wall
An AI agent today can read a contract, extract payment terms, match them against inventory, negotiate with a supplier, and issue a purchase order. The entire workflow runs autonomously in seconds.
Then it reaches the payment step. And stops.
Not because the agent lacks capability. Because the banking API it needs to call was designed for a human sitting at a desk with a browser. The agent cannot authenticate without a session. It cannot settle without manual approval. It cannot get structured compliance evidence back from the API. It cannot route across rails.
The bottleneck in agent-operated commerce is not the agent. It is the banking layer the agent has to talk to.
Five things wrong with the current banking API
Session-based authentication
Traditional banking APIs assume a human operator with a browser session. Agent runtimes operate across thousands of concurrent requests with no session concept. OAuth refresh loops become the bottleneck, not the computation.
Human-in-the-loop by default
Most payment APIs require explicit human confirmation for every material transaction. An agent that can negotiate, procure, and route at machine speed still has to wait for a human to open a laptop and click approve.
No structured compliance evidence
Existing APIs return a transaction ID and a status code. They do not return a structured compliance record that an agent can reason about, store, or present to an auditor. The evidence is somewhere in the bank's back office, not in the API response.
Single-rail only
Fiat APIs handle fiat. Stablecoin APIs handle stablecoins. No production banking API lets an agent say 'send $50,000 to this counterparty on whichever rail is faster and cheaper' and get a governed response.
No mandate model
There is no standard way to register an agent's operating boundaries — maximum transaction size, permitted counterparty types, escalation thresholds — and have the banking layer enforce them structurally. Limits are applied at the account level, not the operator level.
Why wrapping the old API does not work
The instinct is to build a middleware layer: take the existing banking API, add an agent-friendly wrapper, handle the authentication dance, queue the approvals, and return a cleaner response.
This works for demos. It does not work for production. The wrapper inherits every limitation of the underlying API. The session model still breaks under concurrent load. The compliance evidence still lives in the bank's back office, not in the API response. The human approval step is still there — the wrapper just hides it behind a polling loop.
And critically, the wrapper cannot add dual-rail routing. If the underlying bank only handles fiat, wrapping it does not give you stablecoin settlement. You need an operating layer that was designed for both rails from the start.
What the Agent Banking Interface is designed for
Key-based authentication
API keys with scoped permissions, not session cookies. The agent authenticates once and operates within its mandate until the mandate expires or is revoked.
Structured mandates
A registered contract that says: this agent can settle up to $500K per transaction, $5M per day, on fiat and stablecoin rails, with auto-escalation above $250K. The banking layer enforces it. The agent does not need to self-police.
Compliance as a return value
Every settlement response includes a structured compliance record — screening results, mandate references, policy decisions, ledger hashes. The agent can store this, reason about it, and present it when asked.
Dual-rail routing
One instruction, two possible settlement paths. The agent specifies the intent. The banking layer routes based on policy, speed, cost, and availability. The agent gets back which rail was used and why.
Multi-Agent Consensus
No single agent executes alone. Independent compliance, treasury, and policy layers must agree before settlement proceeds. This is not a limitation. It is the governance model that makes autonomous execution safe enough for regulated finance.
What a real integration looks like
An agent integrated with the ABI does not need to understand banking. It needs to understand one tool call. The ABI exposes a structured tool that fits into LangChain, OpenAI function calling, Anthropic tool use, CrewAI, AutoGen, or direct REST.
# The agent's entire banking integration
result = settle.run({
"amount": 50000,
"currency": "USD",
"beneficiary": "acct_supplier_id",
"rail": "auto",
"memo": "Invoice INV-2026-0441"
})
# The response includes everything the agent needs
# settlement_id, rail_used, compliance_tag, ledger_hash,
# mandate_reference, screening_result, next_stateThe agent does not manage sessions. It does not poll for approval. It does not reconstruct compliance records. The operating layer does all of that. The agent gets a structured response it can reason about, store, and act on.
The governance question
The natural objection is: should AI agents be executing financial transactions autonomously? The answer is that they already are, just badly. Agents are already making procurement decisions, treasury recommendations, and payment instructions. The human approval step is increasingly a rubber stamp on a decision the agent already made.
The question is not whether agents will execute. It is whether the banking layer they execute through has the governance model to make it safe. That means structured mandates, multi-agent consensus, compliance validation before execution, and human escalation at configurable thresholds.
An agent with no banking API takes no financial action. An agent with a legacy banking API takes poorly governed action. An agent with a purpose-built banking interface takes governed, compliant, auditable action.
Who this is for
If you are building agent-operated workflows that touch money — procurement, treasury management, payroll automation, supply chain finance, marketplace settlement — the ABI is the interface designed for your use case.
Early-access developers can request sandbox credentials and documentation today. The sandbox enforces the same mandate model, compliance flows, and dual-rail routing as the production environment. Integration starts with one tool call.
Yves R. Burri is Co-Founder and CEO of Vayan. Company formation and licensing preparation are underway. Vayan is not yet authorised or regulated by the FCA or OCC, and nothing in this article constitutes financial or legal advice.