Institutional Crypto: How AI‑Driven Payments Will Work

By: Dean Hanson

& An institutional introduction to AI‑driven payments

In this recent blog, I highlighted how agentic wallets are really about control: who can move value, under what conditions, and how you contain the blast radius when software goes wrong. This follow‑up looks at how that same control question plays out in institutional crypto when AI‑driven payments start to become real.

Two emerging approaches are worth the attention of banks and fintechs: x402 (backed by Coinbase and others) and Stripe’s Machine Payments Protocol (MPP). Both are designed for a world where software agents initiate payments. They just embed control in different places.

AI Can Now Make Payments

Most existing payment flows assume a human is somewhere in the loop.

A person types in card details. A trader clicks submit. An ops analyst approves a wire. Even with automation around the edges, there is usually a clear point at which a human is at the wheel.

AI‑driven workflows challenge that assumption, with software agents now able to:

• Decide to call a service or API.
• Compare options and prices.
• Initiate the payment.
• Consume the result.
• Do this continuously, at any time of day.

That creates a different risk profile. You are no longer worried about one large fat‑finger event. You are worried about thousands of small, autonomous decisions adding up before anyone notices.

So the questions for traditional finance become:

• How do we set spending limits for software, not just for people?
• How do we log intent and context, so an auditor can understand what happened?
• How do we stop an agent quickly, and what happens to in‑flight payments when we do?

x402 and MPP are early, concrete attempts to answer those questions in the payment layer.

x402: A Vending Machine for Software

x402 is a way for software to pay for online resources on a per‑request basis, using digital dollars, with no stored cards, no login, and no invoice.

The basic flow is simple:

1. An AI agent requests a paid resource (for example, access to an API, a dataset, or a scraping run).
2. The provider replies with “payment required” plus the amount and where to send it.
3. The agent sends a small payment in a digital token designed to track a regular currency like the US dollar.
4. Once payment is confirmed, the provider returns the resource.

The easiest analogy is a vending machine:

• Each time you want something, you put in the money.
• If the payment is valid, you get the product.
• There is no ongoing balance, no tab, no account relationship inside the vending machine itself.

That is by design. x402 deliberately keeps the payment model minimal: one payment, one response. It does not try to handle:

• Credit limits.
• Ongoing subscriptions.
• Negotiated discounts.
• Long‑running spending sessions.

For banks and fintechs, that has clear implications:

• The power of x402 is that it is simple, fast, and machine‑friendly.
• The responsibility for control lives mostly outside the protocol:
  • Your “agentic wallet” (or equivalent account infrastructure) decides which agents can pay, where, and how much.
  • Your policy engine enforces per‑request and per‑day limits.
  • Your risk systems determine what counts as suspicious behaviour.

In other words, x402 gives you a clean “coin slot” for software. But it is up to you to decide which coins are allowed, who can insert them, and how often.

For firms that already hold digital assets directly and are comfortable managing keys, this minimalism is attractive. For more traditional institutions, it can feel like a very powerful primitive that absolutely has to be wrapped in strong internal controls before being exposed to AI agents.

MPP: A Corporate Card for Agents

Stripe’s Machine Payments Protocol (MPP) starts from a different place: existing payment rails, card programmes, and compliance processes.

Where x402 is about per‑request digital cash, MPP is about giving software a tightly controlled way to use familiar instruments: cards, bank payments, digital wallets, and, over time, other rails like real‑time payments.

The key idea in MPP is the session.

A session is a temporary spending window with a defined purpose and limit. For example:

• “This agent can spend up to £500 with this data provider over the next 24 hours.”
• “This agent can make up to 1,000 small payments of a few pence each to this API this week.”

Within that session:

• The agent can initiate individual charges as it consumes services.
• The system can aggregate those charges for settlement to keep things efficient.
• If anything looks wrong, the session can be paused or revoked.

The natural analogy here is a corporate card:

• You set a limit, a merchant category, and sometimes a time window.
• An employee can spend within those parameters without asking for permission each time.
• You see all transactions in the same dashboards and reports as usual.

MPP extends that pattern to software agents:

• Sessions encode limits and constraints directly into the payment flow.
• Transactions run over rails the institution already understands.
• Existing fraud, dispute, and reporting tools can be reused.

For traditional finance, the comfort factor is obvious:

• You do not have to hold or manage new types of asset if you do not want to.
• You can map agent‑initiated activity into the same reconciliation and reporting processes you already use.
• You can explain the controls to regulators using familiar language: limits, merchant scopes, logs, and revocation.

The trade‑off is that you are accepting a more opinionated, centralised view of the world. Control is partly in your hands (defining sessions and policies), and partly in the processor’s risk models and infrastructure.

Two Approaches to Institutional Control

It is tempting to frame x402 and MPP as competing visions. It is more useful, especially for banks and fintechs, to see them as two different ways of placing guardrails around AI‑driven payments.

A simple way to think about them:

• x402 puts almost all the sophistication in your own environment.
  • The payment primitive is basic but powerful.
  • Control lives in your wallet infrastructure, policy engine, and monitoring.
  • You get maximum flexibility, but also maximum responsibility.
• MPP bakes more structure into the rail itself.
  • Sessions, limits, and scopes are first‑class concepts.
  • Control is shared between your systems and the processor’s platform.
  • You trade some flexibility for easier integration with existing processes.

Both approaches assume agents will sometimes misbehave, act on bad inputs, or be manipulated. Both are trying to make it easier to constrain the consequences.

The real decision for a traditional institution is less about “crypto vs cards” and more about three design choices:

1. Where do we want authority to sit? In our own risk and policy engines, or in third‑party infrastructure?
2. How do we want to see and explain AI‑driven payments? As movements of digital tokens on a shared ledger, or as enriched entries in our existing settlement and reporting systems?
3. How do we want to stop things? Do we prefer fine‑grained internal kill‑switches at the wallet and agent level, or simpler “pause this session / shut off this rail” controls exposed by a processor?

The Key Takeaway for Institutions

AI‑driven payments are not about trusting software agents. They are about deciding where to place the guardrails.

In 2024, that conversation was mostly about wallet technology, key management, and approval workflows. In 2026, it is expanding to include payment standards like x402 and MPP.

For banks and fintechs, the practical work over the next few years will be in designing architectures where:

• Accounts and wallets are clearly owned and supervised.
• Policy engines for humans and AI agents are consistent.
• Payment rails, whether x402‑style coin slots or MPP‑style corporate cards for software, are chosen because they match a specific risk appetite and regulatory perimeter.

The software is going to start spending anyway. The institutions that stay in control will be the ones that decide, early, exactly how.