General
What agentic payments change about stablecoin reconciliation
Give an agent a wallet, not the treasury. The controls it needs are the same ones finance teams already apply to human-initiated payments.

AI agents settled more than $73 million onchain across roughly 176 million transactions between May 2025 and April 2026, according to Keyrock's report with Coinbase, Tempo and Virtuals. About 98.6% settled in USDC.
That is tiny compared with stablecoin settlement overall. Adjusted stablecoin volume reached $8.8 trillion in the first half of 2026, including a record $1.79 trillion in June. A full year of agent settlement is roughly one twenty-five-thousandth of a single month of stablecoin settlement.
The comparison is imperfect because the reporting windows differ. It also uses adjusted stablecoin volume, the more conservative measure of overall activity. Even on that basis, agent payments remain negligible.
Recent activity has also slowed. The Keyrock reporting window ended in April 2026, and x402 daily settlement volume is down 93% year-to-date as of mid-August.
The infrastructure is outpacing the volume.
Cloudflare gave agents an identity layer and reserved wallet handles on August 4. Amazon added agent payments to Bedrock AgentCore via Coinbase and Stripe, which is generally available since August 18. Mastercard opened cards, accounts and stablecoins to agents in June with more than 30 launch partners.
The rails are still lightly used. Sampling Tempo's public RPC endpoint, we measured mainnet activity at 0.40 to 0.51 transactions per second on August 18 and 19, with four in five blocks empty. Tempo's nightly benchmark reports around 18,000 transactions per second, but its published benchmark runs use a local devnet chain ID rather than mainnet.
That gap matters. Controls defined now can be built into the payment flow. Controls defined after the volume arrives must be added to a live system.
What a finance team is actually being asked to control
Start with what an auditor expects from any outbound payment.
There should be an authorizing instruction, an identified counterparty, a business purpose and a record that survives review. Nothing in MiCA or the FATF Travel Rule changes because software initiated the payment instead of a person.
Agent payments therefore create the same basic control questions as human payments:
- How much can this account spend?
- Who can it pay?
- At what amount does a human need to approve?
- What checks run before the money moves?
Range orchestrates the risk and compliance providers a company already uses rather than replacing them. A company can bring its existing screening vendor key into Range, with those signals applied to the matched counterparty record instead of sitting in another console.
Agent payments do not need a separate compliance stack. They need the existing controls to operate at machine speed.
Monitoring, reconciliation and reporting can then run from the same record. Finance, compliance and risk teams have a single system for controls, transactions, ledger entries and audit trails.
Metering and settlement are two separate obligations
Bloomberg reported on August 16 that Stripe had signed an agreement to acquire OpenRouter for more than $7 billion.
OpenRouter currently operates on prepaid credits. Its documentation describes credits as deposits that customers use for LLM inference, with crypto top-ups priced below card. Its homepage reported 200 trillion tokens per month in August 2026.
That means the payment and the usage happen at different times.
A developer might deposit $2,000 once, then spend that balance across millions of inference calls. Finance sees one settlement event. OpenRouter meters usage separately, offchain, against the prepaid balance.
When that balance runs out, OpenRouter returns an HTTP 402 response, indicating your account has run out of credits.
x402 and the Machine Payments Protocol are designed to make that same response actionable by a machine. Instead of asking a human to top up a balance, the response can become a payment instruction that the agent settles onchain.
This distinction matters for reconciliation.
Stripe owns Bridge for stablecoin issuance and Privy for programmable wallets, incubated Tempo with Paradigm, co-authored the Machine Payments Protocol and sits at the Premier tier of the x402 Foundation. OpenRouter has not built those payment rails into its billing system.
Today, machine usage can generate millions of metered events while finance reconciles a much smaller number of deposits.
If settlement moves to the individual call, that changes.
A finance team then has two records to reconcile: the usage ledger, which shows what the agent consumed, and the settlement ledger, which shows what it paid.
Permission is the attack surface
A weak model with tightly constrained spend authority can cause less financial damage than a strong model with unrestricted access to funds.
Agent payments make permissions especially important for three reasons.
- The market never closes, so there is no overnight batch window where an incorrect payment waits for review.
- Stablecoin settlement is generally irreversible. There is no chargeback process comparable to cards.
- The destination may be a smart contract rather than an organization someone can call when something goes wrong.
We covered the screening side of this in an earlier post on what x402 means for real-time sanctions screening.
The control question here is broader: what limits bind the agent, what requires human approval and what record reaches reconciliation afterward?
The controls are already in the building
Circle, whose USDC settles almost all of current agent payment volume, describes its agent control model in familiar treasury terms: a single balance with human-set spend limits and controls, plus a resolvable counterparty identity and behavior history. It describes this as a vision rather than a product commitment.
Its legal disclaimer makes the control model explicit: agent transactions can execute under user-defined permissions without real-time human review.
When a human is not reviewing each payment, permissions become the controlling factor.
Most of those permissions already exist in payment policies written for people. Onchain execution adds two important controls with no direct card equivalent: simulate the contract call before signing and cap token approvals.
The harder problem is frequency.
A policy that sends every payment above a threshold to a named approver does not make sense when payments are worth fractions of a cent. Keyrock found that 76% of agent payments fall below the $0.30 fixed fee charged by card networks.
Per-transaction human approval does not scale to that environment. Aggregate controls do.
An agent can operate under a daily or monthly spending ceiling, a fixed set of approved counterparties, automated screening on every payment and attribution captured when the payment is created.
Human approval moves from the individual payment to the budget and its associated permissions.
The failure that shows up at month-end
The obvious risk is an agent draining a wallet.
The more likely operational failure is quieter: finance cannot explain what the agent spent.
The prepaid model currently solves much of that problem through aggregation. A balance topped up once a month can represent a million machine decisions as one accounting line with a date, amount and counterparty.
That is one reason agent spending has not yet created a major reconciliation problem. x402 and the Machine Payments Protocol can remove that aggregation.
If settlement moves from the deposit to the individual call, metering and payment become the same event. Instead of one monthly top-up, the ledger receives thousands of tiny transactions.
At that scale, each transaction is too small to review manually. If the system does not capture context at execution, those payments arrive without a business purpose, a counterparty mapping or a clear authorization instruction.
At month-end, the controller is left with stablecoin outflows that cannot easily be tied back to why the money was spent or who authorized it.
That is a controls problem.
In an audit, it appears as a gap in the transaction population. Fixing it means reconstructing a period that was never instrumented properly in the first place.
One ledger, one record, one approval surface
Range has not shipped an agent-specific product. It does not need one for this control model to apply.
The controls needed for agent-initiated payments already run on human-initiated payments, across $30B+ in onchain assets secured for customers and tens of billions in monthly payment volume screened.
- Unify's Treasury brings custodians, wallets and bank accounts into a single real-time view with configurable approvals, so limits can be applied to the account the agent draws from.
- Protect's Transaction Screening evaluates every transaction before money moves, blocking pre-execution onchain and alerting on fiat.
- Counterparty Management creates a matched entity record across rails, so an allowlist can refer to a counterparty rather than a wallet address.
- Counterparty Risk & Travel Rule continuously monitors exposure against that entity record. This becomes particularly important when software initiates a transfer under delegated authority. The company remains the originator and still needs the records required to satisfy its Travel Rule obligations.
- Threat and Fraud Prevention checks for exploits, scams and address-poisoning patterns before signing.
- Treasury and Portfolio Risk monitors asset, FX, custody, protocol and chain risk against more than 500 configurable rules.
- Transaction Reconciliation normalizes and categorizes flows across rails. Reporting and Intelligence can then feed classified transaction data into Xero, QuickBooks, NetSuite and SAP rather than passing an unexplained stablecoin outflow into the accounting system.
The Platform API is how the systems initiating the payment can read that ledger and those controls.
The approval experience also matters. A human should never be asked to approve a vague "system operation."
Before signing, the approver should see the recipient, asset, amount, network, gas cost and purpose in one place.
Before you grant an agent spend authority
Ten questions to answer in writing before giving an agent a funded credential:
- At the daily and monthly spending limit, does the payment block or only alert?
- Who approves a new counterparty the agent is allowed to pay?
- Above the approval threshold, is the signer a named person or a rota?
- On a screening hit, does the payment block or only log?
- Is the agent wallet segregated from operating funds, and what is the maximum loss if the credential is compromised?
- Are token approvals capped, and is every contract call simulated before signing?
- Can the approver see the recipient, amount, network and purpose without leaving the approval screen?
- Is the business purpose written when the payment is created or added manually afterwards?
- How does the usage ledger reconcile to the settlement ledger, and who owns the exceptions?
- Can someone revoke the credential in one action at any hour?
A company that can answer those questions has defined an agent payment control model.
A company that cannot has given software spending authority without defining how finance will control or reconcile it.
Range builds that record across stablecoins and fiat today for payments initiated by people. If agent-initiated payments are on your roadmap, define the limits before issuing the first funded credential, rather than after the first month-end close you cannot explain.
Get in touch, and we will walk through the control set against your payment rails.
Protect your time and money
Get your unified treasury dashboard in 30 minutes.


