The Execution Gap: what it takes to settle an AI agent’s payment
Executive summary
AI agents have started paying for things in production. They complete card purchases, pay for API calls, data, and compute in stablecoins, and early pilots have them paying approved supplier invoices.
Take the simplest of these, an agent paying for an API call. An agent calls a paid API and gets back a request for payment. It signs a payment instruction and retries, and as far as the protocol is concerned, the payment is done.
But the provider still has to be paid. The agent’s stablecoins may sit on a different network than the provider accepts, the provider may want dollars in a bank account, and the agent may have exceeded the daily spending limit set by its company.
Payment protocols such as x402 and AP2 standardize how an agent signals that it wants to pay, proves it has authority, and completes a checkout. But they stop there by design. Settlement, meaning the actual movement of money, falls to whoever processes the payment.
Our new report, The Execution Gap, covers the work between a valid payment intent and final settlement.
Five questions every agent payment has to answer
A payment request can be valid at the protocol level and still not be ready to execute. The report sets out five questions that must be answered before execution:
- Identity and trust. Who is the agent, who deployed it, and is it acting for a verified person or business?
- Authorization and policy. Is the agent authorized to make this payment on behalf of its user or organization? Is the payment within the limits, vendors, and categories its organization set?
- Settlement routing. What asset is the payer using, what does the recipient need, and which path gets the value there: onchain, across chains, or out to a bank account or card?
- Compliance and controls. Which screening and monitoring obligations does this path trigger, and does anything about the transaction warrant review before funds move?
- Reconciliation. How is the outcome recorded, and how are onchain and bank-side records matched for reporting, audit, and disputes?
Why agents make each question harder
A human sees the price before approving a purchase. An agent often commits before the full details of the transaction are settled, from the price to the fees to who’s actually getting paid. Authorization therefore can’t be approval of a known transaction; it has to be a set of rules checked against the actual payment at the moment of settlement.
Agent payments also cross environments. A payment can start in a crypto-native context, get authorized in another system, and settle over a different chain or a bank rail. And at agent volumes, reviewing every transaction isn’t viable, so the work shifts to identifying the transactions that warrant extra controls.
What’s in the report
- Four transaction flows: pay-per-request API access, conversion across assets and rails, enterprise-controlled agent spend, and multi-step tasks that pay several services along the way.
- The current landscape: what today’s protocols and products cover, and where each one stops.
- A reference architecture for the layer that answers the five questions, from taking in a payment request through policy, routing, and the ledger.
What HIFI runs today
Part of this layer is already in production. HIFI moves value between stablecoins and dollars today:
- Virtual accounts turn USD deposits over Fedwire, ACH, or RTP into stablecoins.
- Orchestration addresses pay stablecoins out to a bank account automatically.
- Payouts go out over Fedwire, ACH, RTP, push to card, USD SWIFT, and local rails outside the US.
We’re building the rest: support for agent payment protocols, policy checks that run before settlement, and evaluation of agent identity and trust.
