Financial Services and the Agent Internet

Published September 13, 2026, by Frans

The most powerful capability a provider can offer an agent is the ability to move money.

Every agent workflow that produces real-world value eventually hits the same wall: payment. An agent can research flights, compare prices, select the optimal itinerary, navigate the checkout flow, fill in passenger details — and then stop. It cannot pay. It must hand control back to the human, who opens a wallet, types a card number, confirms a charge, and waits for a receipt. The most sophisticated autonomous system on earth is reduced to a notification: "Ready for you to complete checkout."

This is the bottleneck. Not compute, not reasoning, not capability discovery — payment. And the providers who solve it will occupy the most structurally powerful position in the agent economy.

This paper is a playbook for financial services providers who want to understand that position and claim it.

The Wallet Gap

What Agents Have Today

Agent runtimes manage user credentials, navigate web interfaces, and execute multi-step workflows across dozens of services. They maintain session state, handle authentication, coordinate concurrent tasks, and produce auditable logs of every action taken.

What they lack is a native financial identity.

When a human uses the internet, their financial identity is distributed across bank accounts, credit cards, PayPal, Venmo, Apple Pay, and crypto wallets. Each one is a separate relationship, separately authenticated, separately funded. The human juggles them manually — picking which card to use at which service, managing balances across accounts, tracking subscriptions across providers.

An agent operating on behalf of that human has no unified way to access any of these. It can navigate to a checkout page and fill in a saved card number, but this is the financial equivalent of screen-scraping — fragile, site-specific, and dependent on the human having pre-configured payment on every service the agent might visit.

What Agents Need

An agent needs a programmable financial identity — a single interface through which it can:

1. Hold a balance on behalf of its user
2. Authorize payments within user-defined constraints
3. Receive funds (refunds, rebates, payouts)
4. Report transactions in real-time to the user and the runtime's audit system
5. Enforce limits that the user sets and the agent cannot override

This is not a credit card. It's not a bank account in the traditional sense. It's a financial capability layer — an abstraction that sits between the agent and the financial system, providing programmatic access to money movement within boundaries the human defines.

The agent.json Opportunity

The agent internet's capability discovery mechanism is the agent.json manifest — a machine-readable declaration of what a service offers to agents. Today, most agent.json manifests declare informational or transactional capabilities: search, lookup, purchase, booking.

A financial services provider publishing an agent.json creates something qualitatively different. It doesn't just offer a service the agent can use — it gives the agent the ability to use every other service. A payment capability is a meta-capability: it unlocks the entire transactional surface of the internet for autonomous completion.

Consider the difference:

The financial capability is multiplicative. Every other provider's capability becomes fully autonomous once the agent can pay.

What Financial Services Providers Can Offer

Tier 1: Agent Wallets

The foundational capability: a wallet that an agent can programmatically fund, draw from, and report on.

Mechanics:

• The human user links or provisions a wallet through their agent runtime's settings
• The wallet holds a balance denominated in a settlement currency (fiat, stablecoin, or both)
• The agent can request payments against that balance, subject to user-defined limits
• Every transaction is logged and reported to the runtime's audit system in real time

agent.json declaration:

\{
  "capabilities": \{
    "wallet.balance": \{
      "description": "Check the current balance of the user's agent wallet",
      "auth": "oauth2",
      "returns": \{ "balance": "number", "currency": "string" \}
    \},
    "wallet.authorize": \{
      "description": "Authorize a payment from the agent wallet",
      "auth": "oauth2",
      "params": \{
        "amount": "number",
        "currency": "string",
        "recipient": "string",
        "memo": "string"
      \},
      "constraints": \{
        "requires_user_approval_above": "configurable",
        "daily_limit": "configurable",
        "per_transaction_limit": "configurable"
      \}
    \}
  \}
\}

This is the entry point. A financial provider that offers just this — a programmable balance with programmatic authorization — immediately becomes one of the most valuable integrations in any agent runtime's ecosystem.

Who can build this today: Neobanks (Mercury, Wise, Revolut), crypto platforms with wallet infrastructure (Coinbase, Circle), payment platforms (Stripe via Issuing, PayPal), and fintechs built on Banking-as-a-Service rails.

Tier 2: Virtual Card Issuance

A more powerful capability: the provider issues ephemeral virtual cards on demand, allowing the agent to pay at any service that accepts card payments — without the service needing its own agent.json.

Mechanics:

• Agent requests a virtual card for a specific transaction
• Provider issues a single-use or merchant-locked card with the exact transaction amount
• Agent uses the card number in a standard checkout flow
• Card expires immediately after use or after a configurable window
• Provider reports the charge back to the runtime's audit system

Why this matters: Virtual card issuance solves the bootstrap problem. In the early agent internet, most services won't have an agent.json. The agent still needs to pay them. A virtual card lets the agent transact with any merchant on earth that accepts cards, using the existing payment infrastructure, without requiring the merchant to know or care that an agent is the customer.

This is the bridge capability — it makes the entire existing commerce infrastructure agent-accessible without requiring every merchant to integrate.

Who can build this today: Stripe Issuing, Marqeta, Lithic, Privacy.com, any provider with access to card network issuance.

Tier 3: Agent-to-Agent Settlement

The most advanced capability: enabling agents to transact with each other, settling obligations between runtimes or between an agent and a provider without going through the card networks.

Mechanics:

• Provider operates a settlement network (likely on-chain, using stablecoins on a low-fee L2)
• Agent runtimes connect to the settlement network via the provider's agent.json
• When an agent completes a task that generates a provider payout, the settlement happens programmatically: runtime wallet → provider wallet
• Near-zero transaction fees (L2 execution costs fractions of a cent)
• Settlement is final and auditable on-chain

Why this matters: Card networks charge 2-3% per transaction. For high-frequency, low-value agent transactions (a weather lookup costs $0.003, a search result costs $0.01), card network fees would exceed the transaction value. Agent commerce needs a settlement layer with fees proportional to the values being transferred.

On-chain settlement on L2 networks (Base, Arbitrum, Optimism) achieves this: transaction fees are sub-cent, settlement is final in seconds, and the audit trail is publicly verifiable. Stablecoins (USDC, USDT) provide the price stability that neither Bitcoin nor ETH offer for commercial settlement.

Who can build this today: Coinbase (Base L2 + USDC), Circle (USDC issuer + Payments API), any provider with L2 smart contract capabilities.

The Competitive Landscape

Why This Won't Be a Monopoly

Financial services for agents will not — and should not — consolidate into a single provider. Three structural forces prevent it:

1. Jurisdictional fragmentation. Financial regulation is national. A provider licensed to hold funds and issue cards in the US cannot automatically do so in the EU, Japan, or Brazil. Agent runtimes need financial providers in every jurisdiction where their users live. This creates natural geographic segmentation.

2. Payment method diversity. Different users prefer different payment methods. Some want to fund their agent wallet with a credit card. Some want to use a bank transfer. Some want to use stablecoins directly. Some want to use Apple Pay. The provider that supports the broadest set of funding methods captures the broadest user base — but no single provider supports all methods in all jurisdictions.

3. Trust and counterparty risk. Users are choosing who holds their money. This is an inherently trust-sensitive decision. Some users will prefer a traditional bank. Some will prefer a crypto-native platform. Some will prefer a regulated fintech. Diversity of providers reduces systemic counterparty risk — if one provider fails, the ecosystem continues.

The agent.json Standard as Competitive Infrastructure

The critical insight: the agent.json standard doesn't pick a winner — it creates a competitive marketplace for financial capabilities.

When an agent runtime routes a payment, it evaluates available financial providers the same way it evaluates any capability provider: by reliability, cost, speed, and user preference. A financial provider that offers faster settlement, lower fees, broader acceptance, and better uptime wins more routing.

This is fundamentally different from the current financial system, where payment method selection is static — you pick a card when you sign up for a service, and that's what gets charged. In the agent internet, the runtime can dynamically select the optimal payment provider for each transaction based on real-time conditions:

• Domestic purchase? Route through the provider with the lowest card processing fee.
• International transfer? Route through the provider with the best FX rate.
• Micro-transaction (<$0.10)? Route through the L2 settlement provider to avoid card minimums.
• High-value purchase? Route through the provider with the strongest buyer protection.

This creates genuine price competition at the transaction level — something the current payment industry lacks because switching costs are high and selection is infrequent.

Security Model

The Problem Space

Giving an agent the ability to spend money introduces risks that don't exist in read-only agent workflows:

1. Unauthorized spending. An agent that misinterprets a user's intent and authorizes a payment the user didn't want.
2. Exploitation. A malicious service that tricks an agent into overpaying or paying for something it didn't receive.
3. Credential theft. An attacker who compromises the agent-to-wallet authentication channel and drains the balance.
4. Collusion. A provider and an agent developer colluding to route payments through a specific provider for kickbacks.

The Framework

Financial capabilities require the most stringent security tier in the agent permission model. The following constraints should be enforced at the protocol level — not left to individual implementations:

1. Budget envelopes. Every agent session operates within a budget envelope set by the user. The envelope defines: maximum per-transaction amount, maximum daily spend, and approved merchant categories. The financial provider enforces these constraints server-side — the agent cannot modify them.

User sets: $50/day, max $20/transaction, categories: [travel, food, retail]
Agent requests: $25 payment to airline → APPROVED (within envelope)
Agent requests: $75 payment to airline → DENIED (exceeds per-transaction limit)
Agent requests: $25 payment to gambling site → DENIED (category not approved)

2. Transaction signing. Every payment authorization must be cryptographically signed by the agent runtime (not the agent itself). The financial provider verifies the signature before executing. This prevents rogue agents from initiating payments outside the runtime's supervision framework.

3. Real-time notification. Every transaction triggers an immediate notification to the user through an independent channel (push notification, SMS, email). The user can freeze the wallet instantly. This is the equivalent of card transaction alerts, adapted for agent workflows.

4. Reversibility windows. For transactions above a configurable threshold, the financial provider enforces a hold period during which the user can cancel. The agent is informed that the payment is "pending confirmation" and must wait before treating it as settled.

5. Provider reputation integration. The agent runtime's domain reputation system feeds into payment authorization decisions. If a merchant's domain has low trust scores, the financial provider can require additional user confirmation or reduce the per-transaction limit for that merchant automatically.

6. Audit trail requirements. Every transaction must include: the user's original intent (natural language), the agent's interpretation, the proposed action, the user's approval (or auto-approval criteria met), the financial provider's authorization, and the final settlement status. This complete chain enables dispute resolution and forensic analysis.

The Economics

Revenue Model for Financial Providers

Financial services for agents create three revenue streams:

1. Transaction fees. The traditional model: a percentage or flat fee on each payment. In the agent internet, transaction volumes will be dramatically higher (agents transact more frequently than humans) but individual transaction values will be lower (many agent transactions are micro-payments for capability access). Providers need pricing models that work for $0.01 transactions (e.g., batching) as well as $500 transactions.

The competitive pressure from L2 settlement (where fees are sub-cent) may push card-network-based providers toward subscription or tiered pricing models rather than per-transaction percentages.

2. Float revenue. Users pre-fund their agent wallets with a balance. The provider earns yield on those balances — the same model that makes interchange-based banking profitable. As agent wallet balances grow (users keep a float so their agents can transact autonomously), this becomes a significant revenue source.

3. Data and intelligence. With user consent, aggregated transaction data from agent activity provides insights that don't exist elsewhere: which services agents use most, which capabilities command the highest prices, where completion rates drop (indicating friction in the provider's integration). This intelligence is valuable to providers optimizing their agent.json capabilities, and financial providers are uniquely positioned to sell it.

Cost Structure

The primary costs for a financial provider serving agents are:

• Compliance and licensing: KYC/AML on user accounts, money transmission licenses, payment card industry compliance. These are fixed costs that scale with jurisdictions served.
• Fraud prevention: Agent-specific fraud patterns require new detection models. Traditional fraud systems look for unusual human behavior; agent behavior is inherently different.
• Infrastructure: Low-latency payment processing, real-time balance updates, webhook delivery for audit trail integration. Agent transactions are bursty and latency-sensitive.
• Integration: Maintaining the agent.json interface, supporting multiple agent runtimes, keeping up with protocol evolution.

Market Sizing

The addressable market is the total transaction volume that moves from human-initiated to agent-initiated. Every utilitarian transaction — bill payment, subscription management, purchasing, booking, account transfers — is a candidate for agent delegation.

The financial provider doesn't need to capture a large percentage per transaction. They need to capture a small percentage of a very large volume. At scale, agent-initiated transactions could represent a significant share of consumer internet commerce — and the financial provider that handles the payment layer touches all of it.

Integration Roadmap for Financial Providers

Phase 1: Publish an agent.json (Week 1)

The lowest-effort, highest-signal action a financial provider can take is to publish an agent.json that declares their existing capabilities in machine-readable format. Even before building agent-specific features, this makes existing APIs discoverable by agent runtimes.

For a bank or fintech that already has an API:

\{
  "agent": \{
    "name": "ExampleBank Agent Services",
    "version": "1.0",
    "payout_address": "0x...",
    "settlement_network": "base"
  \},
  "capabilities": \{
    "balance.check": \{
      "endpoint": "/api/v1/accounts/balance",
      "auth": "oauth2",
      "description": "Returns account balance",
      "cost_per_call": 0
    \},
    "transfer.initiate": \{
      "endpoint": "/api/v1/transfers",
      "auth": "oauth2",
      "description": "Initiates a transfer to a recipient",
      "cost_per_call": 0,
      "requires_user_confirmation": true
    \}
  \}
\}

This costs nothing beyond deploying a static JSON file. But it puts the provider on the map for every agent runtime that crawls for financial capabilities.

Phase 2: Agent-Specific Wallet Product (Month 1-3)

Build a wallet product designed for agent use:

• API-first funding (ACH, wire, card, stablecoin deposit)
• Programmatic authorization endpoint with budget envelope enforcement
• Real-time transaction webhooks compatible with agent runtime audit systems
• Virtual card issuance for legacy merchant compatibility
• Dashboard for users to manage their agent's spending limits

This is the product that makes the provider indispensable. Users will choose their agent's financial provider the way they choose a bank — and switching costs are real once the wallet is funded and limits are configured.

Phase 3: Settlement Network Participation (Month 3-6)

Join or deploy on an L2 settlement network:

• Accept and disburse stablecoins (USDC on Base is the current default, but the standard should be network-agnostic)
• Offer instant settlement between agent wallets on the same network
• Bridge to card networks for off-network transactions
• Participate in the provider payout system — handle settlement from agent runtimes to capability providers

This positions the provider as infrastructure, not just a product. They become part of the settlement backbone of the agent internet.

Phase 4: Multi-Runtime Compatibility (Month 6+)

As multiple agent runtimes emerge (not just one), the financial provider that supports all of them captures the largest user base:

• Support the agent.json standard as it evolves
• Integrate with multiple runtime audit trail formats
• Offer a universal agent wallet that works across runtimes
• Provide analytics across runtime providers (with user consent)

The providers that achieve multi-runtime compatibility becomes the financial backbone of the agent internet — a network that works everywhere, regardless of which runtime the agent is using.

What This Means for the Ecosystem

For Agent Runtimes

Agent runtimes should not try to be banks. Building financial infrastructure requires licenses, compliance frameworks, fraud systems, and regulatory relationships that are outside the core competency of agent software. The correct architecture is:

• Runtime manages: intent interpretation, capability routing, supervision, audit trails
• Financial provider manages: balance custody, payment authorization, settlement, compliance

The interface between them is the agent.json standard. The runtime discovers financial providers the same way it discovers any capability provider — through the manifest. This clean separation means runtimes can support multiple financial providers, and users can choose based on their preferences.

For Regulators

The agent internet doesn't create new financial instruments or new forms of money. It creates a new interface to existing financial systems. Agent wallets are accounts. Agent payments are transfers. Virtual cards are cards. The regulatory frameworks that exist for each of these apply directly.

What regulators should focus on:

• Agent authorization standards. How does a financial provider verify that an agent is authorized by its user? The runtime's cryptographic attestation model provides this, but regulators should codify minimum requirements.
• Liability allocation. When an agent makes an unauthorized payment, is the user, the runtime, or the financial provider liable? Clear rules reduce friction and encourage adoption.
• Consumer protection. Budget envelopes, reversibility windows, and real-time notifications should be mandatory, not optional. These are the consumer protection equivalents of Regulation E for agent-initiated transactions.

For the Industry

The provider who moves first has a structural advantage. Agent wallet integrations are sticky — once a user funds a wallet, configures limits, and starts using it across agent workflows, switching to a different provider means reconfiguring everything. Early movers capture users during the period when agent commerce is novel and users are choosing their first financial provider for this new context.

But moving first means building for a standard that's still evolving. The providers who succeed will be those who participate in the standard's development — contributing to the agent.json specification, working with runtime developers on integration patterns, and sharing learnings about agent-specific fraud patterns.

The agent internet will be the largest new source of payment volume since mobile commerce. The financial providers who recognize this early — and build for it — will define the infrastructure layer that everything else runs on.

Conclusion

The completion economy needs a financial layer. Agents that can reason, plan, and execute but cannot pay are fundamentally limited — they can advise but not act. The financial services provider that closes this loop doesn't just add a feature to the agent internet. They remove its single largest constraint.

The playbook is clear: publish an agent.json, build an agent wallet product, join the settlement network, and scale across runtimes. The technology exists today. The regulatory frameworks apply. The market is forming now.

The question isn't whether financial services will integrate with the agent internet. It's who will get there first — and whether the result is an open, competitive marketplace where agents can choose the best financial provider for each transaction, or a walled garden where a single provider controls the payment layer.

The agent.json standard ensures the former. Every financial provider that publishes a capability manifest is a competitive option. Every agent runtime that supports multiple financial providers preserves user choice. The architecture is designed for competition, not consolidation.

The most valuable capability on the agent internet is the ability to move money. It's waiting to be claimed.