Meet us at Money20/20 USA
Las Vegas | 18 - 21 October 2026

What Is Agentic Commerce? A Complete Guide for Financial Institutions and Payment Providers

What Is Agentic Commerce?

Table of contents

What Is Agentic Commerce?

Agentic commerce is a model of digital trade in which AI agents discover products or services, make bounded decisions, and initiate or complete transactions on behalf of people or organizations under explicit rules, permissions, and controls.

Within the broader field of AI commerce, it is the point at which software moves from recommendation to authorized execution. A conventional assistant may compare flights or draft a shopping list; an agentic system can select an option, create a cart, request approval when required, choose an authorized payment method, complete the purchase, and record the outcome.

The practical distinction is authority. In this context, autonomous commerce operates within defined permissions and spending controls. The agent needs reliable commercial data, a verifiable identity, a mandate that defines what it may do, and payment infrastructure that can enforce those conditions. The user may approve every transaction, set a recurring budget, restrict spending to named merchants, or permit purchases below a defined threshold.

During the Payments Leaders’ Summit in London, Pavel Kashuba illustrated this shift with a household example: a consumer asks a voice assistant to organize a party for 40 guests, and the assistant uses the known guest list to decide what to buy, place the orders, and pay from an approved account. The example raises an infrastructure question. When one AI agent transacts with another, identity, delegated authority, payment routing, and settlement must be machine-readable. Kashuba frames the central question for financial institutions:

Which rails can support those requirements when software becomes the transaction initiator?

A business example follows the same logic. A procurement agent monitors warehouse stock, requests quotations from approved suppliers, checks delivery times, applies purchasing policy, and places an order when inventory falls below a threshold. The payment may use a commercial card, an instant bank transfer, a tokenized deposit, or a stablecoin. The important feature is the control structure around the transaction.

Why Is Agentic Commerce Emerging Now?

Agentic commerce became practical because several technologies matured at the same time. Kashuba describes the market as approaching a tipping point: adoption is still gradual, but once the threshold is crossed, change can accelerate quickly. Coinspaid’s own demand history illustrates the pattern: requests expanded from Bitcoin to Ethereum and stablecoins, followed by physical point-of-sale payments from crypto wallets.

1. Generative AI can interpret commercial intent

Generative AI made natural-language instructions usable as software inputs. A request such as “rebook my trip if the new itinerary costs less than €300 more and gets me home before 18:00” contains a goal, constraints, and a decision rule. Modern models can convert that instruction into a sequence of searches, comparisons, and actions.

Language understanding alone doesn’t provide safe execution. The link between AI agents and payments is the authority layer: the model can propose an action, but reliable data, authenticated tools, deterministic controls, and an authorized payment method must govern execution. Safe AI payments therefore require payment infrastructure that banks, EMIs, fintech companies, merchant acquirers, and payment providers can govern and audit.

2. AI agents can plan and act across systems

An AI agent combines a model with tools, memory, and workflow logic. It can call an API, read a product catalog, compare offers, contact another agent, or update an enterprise system. Emerging protocols standardize these interactions. Google’s current stack includes Model Context Protocol for tools and data, Agent2Agent for communication, Universal Commerce Protocol for commerce, and Agent Payments Protocol for signed payment mandates. These standards remain early, but they separate commerce, identity, authority, and payment into distinct layers.

3. APIs made financial services addressable by software

Open Banking, Embedded Finance, and modern payment APIs already let software retrieve account data, initiate payments, tokenize credentials, and reconcile transactions. Agentic commerce uses the same foundation with a new initiator.

Traditional e-commerce assumed a human would move between pages and submit forms. An AI agent expects structured product data, stable APIs, clear error messages, idempotent payment requests, and event-driven status updates. Institutions with fragmented interfaces may support human customers while remaining difficult for agents to use safely.

4. Digital identity and tokenization can carry authority

A payment instruction needs an accountable principal. The system must know who owns the funds, which agent acts for that person or company, what the agent may purchase, how long the permission lasts, and which conditions trigger human approval.

Tokenization helps separate authority from raw credentials. Mastercard introduced agentic tokens that build on existing network tokenization, while Stripe uses shared payment tokens that can be scoped to a transaction and limited in time. Visa’s Trusted Agent Protocol focuses on helping merchants distinguish approved purchasing agents from malicious bots. These approaches differ in implementation, but each treats the agent as a visible, governed participant in the payment flow.

5. Real-time payments reduced the gap between decision and settlement

Agents can operate continuously, so batch-based settlement and limited operating hours create friction. Real-time payment systems improve the fit between automated decisions and money movement. In the euro area, payment service providers must support instant euro transfers, and the rules include payee verification to reduce mistakes and scams.

Real-time settlement also changes treasury operations. A company can release funds closer to purchase and update liquidity positions sooner. Reliable reconciliation, sanctions controls, fraud monitoring, and operational resilience remain necessary.

6. Agent-to-agent payments strengthen the case for blockchain infrastructure and stablecoins

Blockchain networks give software a shared transaction environment with programmable rules and 24/7 availability. Kashuba sees this as a strong fit for agent-to-agent transactions because the infrastructure can support fast settlement, digital assets, and direct system-to-system integration. In his view, multinational companies may increasingly use stablecoin networks such as USDC for treasury transfers that currently use traditional cross-border infrastructure such as SWIFT.

That is a forward-looking position rather than a universal outcome. Stablecoins may reduce friction in some cross-border payments, but their value depends on regulation, reserve quality, redemption, liquidity, network costs, banking access, and the availability of instant bank rails. Agentic commerce can use blockchain infrastructure without requiring every transaction to settle on-chain.

Regulation has moved closer to operational reality. MiCA became fully applicable in the EU in December 2024, while the U.S. GENIUS Act established a federal framework for payment stablecoins in July 2025. These regimes differ, but both make regulated digital-asset infrastructure easier for financial institutions to evaluate.

7. Tokenized assets widen the opportunity beyond payments

Kashuba extends the argument beyond money movement. He uses tokenized cocoa futures as a simple example of assets that could move across blockchain infrastructure and create new transaction flows for financial institutions.

Evolution of Commerce chart

How Agentic Commerce Differs from Traditional E-Commerce

Agentic commerce changes the initiator, interface, decision process, and control model. The merchant still needs pricing, inventory, fulfillment, customer service, and payment acceptance. The surrounding transaction becomes more machine-readable and policy-driven.

Human Commerce vs Agentic Commerce

Dimension Traditional e-commerce Agentic commerce
Initiator A person visits a site or app A person or company delegates a task to an AI agent
Interface Web pages, forms, and mobile screens Natural language, APIs, and agent-to-agent messages
Product discovery The user searches and compares The agent searches, filters, and ranks within stated constraints
Decision process The user evaluates each option The agent applies preferences, budgets, and policy rules
Checkout The user enters or confirms payment details The agent submits a tokenized or otherwise authorized payment instruction
Identity Login, device, cardholder, or account holder Principal identity plus agent identity and delegated authority
Authorization Consent at checkout A mandate may cover 1 transaction, a category, a limit, or a time period
Timing Human-paced and session-based Continuous, event-driven, and potentially high-frequency
Risk controls Fraud scoring around a human checkout Agent verification, mandate validation, fraud scoring, and behavioral controls
Settlement Cards, bank transfers, wallets, or other rails The same rails plus programmable bank money, tokenized deposits, or stablecoins
Audit trail Order and payment records Intent, agent action, approval, payment, settlement, and exception records
Merchant relationship Direct interaction through the merchant channel Interaction may occur through an external agent while the merchant retains fulfillment and service responsibilities

The comparison also explains why agentic commerce doesn’t require one universal payment rail. Kashuba expects stronger technologies eventually to replace weaker ones, but in the near term cards, Open Banking payments, account-to-account transfers, digital wallets, tokenized deposits, and stablecoins are likely to coexist. The route will depend on geography, transaction value, consumer protection, merchant acceptance, liquidity, and regulation.

The deeper change concerns transaction density. Agents may split a process into several purchases, renew services automatically, buy data or compute on demand, and transact at machine speed. Payment systems designed for occasional human checkout may face new requirements for throughput, low-value transactions, real-time risk decisions, and automated reconciliation.

The Technologies Behind Agentic Commerce

5-I Agentic Transaction Control Model

Financial institutions can assess readiness through five control layers: Intent, Identity, Instruction, Instrument, and Infrastructure. Together, they connect the commercial request to the authority, payment method, and operating systems required to execute it.

1. Intent: what outcome did the principal request?

Intent begins with the user’s or company’s objective. It may include a product specification, budget, time limit, merchant list, delivery condition, refund requirement, or sustainability rule. The agent converts this instruction into a plan.

Financial institutions should preserve the original intent in a structured record. A natural-language prompt alone may be ambiguous. A production system needs normalized fields that compliance, risk, and dispute teams can inspect later.

2. Identity: who is acting, and for whom?

The identity layer links the principal, the agent, the merchant, and the payment account. It may use digital identity credentials, passkeys, device binding, certificates, wallet signatures, or enterprise identity and access management.

The merchant also needs to identify legitimate commercial agents. Conventional bot controls often block automated traffic because automation historically signaled scraping or fraud. Trusted-agent frameworks aim to let approved agents present verifiable credentials while merchants keep defenses against malicious automation.

3. Instruction: what exactly is the agent allowed to do?

The instruction layer turns intent into enforceable authority. It defines spending limits, approved merchants, payment methods, currencies, timing, approval thresholds, and revocation rules.

Google’s AP2 model uses an intent mandate, a payment mandate tied to a specific purchase, and a receipt that closes the audit trail. This structure addresses a central question in autonomous transactions: whether a payment matched the authority granted before execution.

Banks can implement similar logic without adopting a specific protocol. The essential capability is a policy engine that evaluates every request against current permissions and routes exceptions to a human or another control function.

4. Instrument: which form of money or credential will pay?

The instrument may be a tokenized card credential, an instant bank payment, a wallet balance, a stablecoin, a tokenized deposit, or another digital asset. Wallet infrastructure determines how credentials or assets are held, signed, transferred, and recovered. Each instrument brings different rules for settlement finality, refunds, disputes, FX, liquidity, and consumer protection.

Programmable payments don’t require all business logic to sit inside the money itself. Policy may be enforced by the agent, the payment orchestrator, the bank, smart contracts, or several layers working together. Separating those responsibilities makes controls easier to test, audit, and change.

5. Infrastructure: how is the transaction processed, monitored, and reconciled?

Infrastructure includes payment APIs, merchant acquiring, payment orchestration, custody, blockchain connectivity, FX, liquidity, compliance, fraud controls, real-time settlement, treasury, reporting, and incident management. This layer determines whether an agentic prototype can operate at enterprise scale.

Pavel Kashuba identifies transaction volume as the clearest enterprise test because it demonstrates resilience, scalability, and the ability to grow without losing performance. A controlled demonstration may still fail under sustained traffic, chain congestion, market volatility, provider outages, or a surge in compliance alerts. Enterprise buyers should evaluate throughput, latency, recovery procedures, reconciliation accuracy, and change management alongside feature coverage.

The Agentic commerce stack

Challenges of Agentic Commerce

Trust and agent legitimacy

Merchants need confidence that an agent represents a real customer or authorized business. They also need protection from scraping, account takeover, synthetic identities, and automated fraud. Agent credentials, cryptographic signatures, network tokens, and merchant-side verification can reduce this risk, but adoption will depend on interoperability.

Liability and disputes

A failed purchase can involve the principal, agent provider, bank, merchant, payment service provider, model provider, and data source. The agent may misunderstand a request, use stale data, exceed a limit, or select an unsuitable item. Institutions need explicit rules for authorization evidence, cancellation, refunds, chargebacks, and complaints. The audit trail should show the original intent, policy version, agent decision, approval, payment instruction, and outcome.

Fraud and manipulation

Agents can be targeted through prompt injection, malicious product content, compromised tools, false merchant identities, and manipulated pricing. Fraud models will need signals such as mandate validity, tool provenance, agent identity, and unusual delegation patterns. Transaction approval should rely on structured checks outside the model, with step-up authentication or human approval for high-risk actions.

Identity, privacy, and data minimization

An agent may process preferences, purchase history, location, balances, company policy, and identity credentials. Institutions should limit disclosure through tokenization, purpose limitation, and short-lived credentials. Personalization may guide a recommendation, but payment authorization should follow explicit permissions.

Compliance and regulatory classification

Agentic commerce crosses existing regulatory areas, including payments, AML, sanctions, consumer protection, data protection, outsourcing, operational resilience, and AI governance. The applicable rules depend on the use case and jurisdiction.

Financial institutions should map the legal role of each participant before launch. Questions include who initiates the payment, who authenticates the customer, who performs KYC or KYB, who monitors transactions, who holds funds, and who provides the customer-facing explanation. In the EU, DORA already requires in-scope financial entities to manage ICT risk and third-party dependencies within a harmonized operational-resilience framework.

Interoperability and fragmentation

The market includes several commerce, agent, identity, and payment protocols. This creates integration costs and inconsistent trust signals. Payment orchestration can support multiple agent frameworks and settlement rails without repeated changes to core systems.

Liquidity, settlement, and reversibility

Fast settlement transfers value quickly, which can reduce the window for correcting mistakes. Stablecoin and digital-asset flows add wallet, network, liquidity, and conversion risks. Institutions need pre-funded balances or reliable liquidity access, transaction limits, chain monitoring, and clear refund procedures.

Tokenized settlement also requires legal certainty. BIS Project Agorá showed how tokenized commercial bank deposits and central bank reserves could support atomic, multi-currency wholesale settlement, conditional payments, and embedded compliance logic. The project remained an exploratory platform, yet it demonstrated that programmability can apply to regulated bank money as well as public blockchain assets.

How Financial Institutions Can Prepare

Institutions can begin with a modular implementation. Kashuba recommends starting with custody, exchange, payments, or operational applications, then expanding after testing the relevant controls and operating model.

Define authority before selecting technology

Choose a narrow task, such as subscription management, travel booking, supplier replenishment, contractor payouts, or treasury transfers. Document which decisions the agent may make, which data it may access, the maximum transaction value, approved counterparties, and the conditions for human approval.

This exercise produces the mandate model. It also exposes whether the institution has reliable identity, payment, compliance, and reconciliation capabilities.

Build an API-first, event-driven architecture

Agents need structured access to products, balances, payment status, FX quotes, limits, and compliance outcomes. APIs should use consistent schemas, authentication, idempotency, versioning, and machine-readable errors. Event streams should report authorization, settlement, rejection, reversal, and refund status.

Legacy systems can remain in place if a modular layer exposes their capabilities safely. This matches the expected transition period: established rails continue to serve existing journeys while newer infrastructure supports automated ones.

Separate model output from payment authority

The AI model may propose an action, but a deterministic policy service should authorize it. The policy service checks identity, mandate, amount, merchant, currency, risk score, sanctions results, available balance, and approval requirements.

This separation makes controls testable and auditable. It also lets the institution change models without redesigning payment governance.

Add payment orchestration

Payment orchestration selects a route based on geography, cost, acceptance, speed, risk, and settlement needs. It can support cards, Open Banking, instant account-to-account payments, wallets, stablecoins, and digital assets through a common control layer. It should manage retries, fallback routes, duplicate prevention, FX, and status normalization.

Develop blockchain connectivity with clear business criteria

Blockchain infrastructure is useful when it improves a defined flow, such as 24/7 cross-border settlement, digital-asset custody, tokenized assets, or stablecoin treasury operations. Institutions should compare it with instant bank rails and card networks on cost, liquidity, legal finality, refunds, and customer protection. A modular design avoids dependence on a single form of money.

Automate compliance and preserve audit evidence

Compliance automation should screen customers, merchants, wallets, and transactions at the relevant stages. Rules may cover KYC, KYB, sanctions, AML, KYT, Travel Rule requirements, velocity, geography, and transaction purpose.

Every automated decision needs evidence, including inputs, rule results, model version where relevant, approvals, and timestamps. Compliance teams need tools to review, override, and explain outcomes.

Test operational readiness at enterprise volume

Pilot success should be measured against production conditions. Test peak volume, latency, failover, duplicate events, provider outages, chain congestion, liquidity stress, and manual intervention. Monitor authorization rates, false declines, settlement time, reconciliation breaks, review rates, refunds, and complaints.

Production readiness also depends on operational experience. In the interview, Kashuba highlights security experience gained from real attacks and regulatory experience accumulated since 2019. Enterprise buyers should assess both alongside performance and product coverage.

How Coinspaid Enterprise supports the transition

Coinspaid Enterprise provides modular infrastructure across several layers of the 5-I model. Core Processing and API integrations support payments, payouts, invoicing, webhooks, and settlement management. Crypto Gate & Custody supports wallet operations, key management, transaction management, asset flows, and cold-wallet processes. Exchange Aggregator connects multiple liquidity venues and supports smart order routing, spread management, and order-book aggregation. Compliance Guard adds KYT and AML monitoring, risk scoring, approval workflows, audit trails, and transaction controls. Merchant Portal supports financial operations, reporting, and reconciliation.

These components cover execution, custody, liquidity, compliance, and back-office operations. The financial institution defines the agent experience, delegation policy, mandate model, customer authorization, and risk policy.

Agentic transaction flow chart

Conclusion

Financial institutions remain central to agentic commerce as transaction initiation, authorization, settlement, and monitoring become more automated. They continue to provide regulated money, identity, risk controls, liquidity, and customer protection. AI agents become a new transaction participant, while financial institutions continue to provide regulated money, identity, risk controls, liquidity, and customer protection.

Legacy and newer rails will coexist during the transition, with adoption rates varying across instant bank payments, tokenized credentials, stablecoins, tokenized deposits, and other programmable settlement methods. A durable architecture supports several routes through a common policy and orchestration layer.

Financial institutions can prepare now by defining bounded use cases, modernizing APIs, separating AI decisions from payment authority, automating compliance, adding modular blockchain connectivity where it solves a defined problem, and testing infrastructure at production volume. Every autonomous transaction should have a clear principal, a verifiable agent, an enforceable mandate, an appropriate payment instrument, and a complete operational record.

FAQ

A user or company gives an AI agent a goal, constraints, and payment authority. The agent collects information, compares options, selects an action, and sends a payment request. Identity, policy, fraud, compliance, and payment systems verify the request before execution. The agent then receives status data and reports the result.

Traditional e-commerce relies on a person to search, compare, and complete checkout. Agentic commerce delegates some or all of those tasks to software. This requires machine-readable product data, agent identity, explicit mandates, programmable controls, and stronger audit records.

AI agents convert intent into actions. They can discover products, negotiate or compare terms, manage carts, initiate payments, monitor delivery, and handle routine follow-up. Their authority should remain limited by policy, identity, budgets, and approval rules.

Blockchain can provide 24/7 settlement, programmable transactions, digital-asset custody, and a shared record for transfers between systems. It may be useful for cross-border payments, stablecoins, tokenized assets, and machine-to-machine transactions. Agentic commerce can also run on cards and bank-payment rails.

No. An agent may use tokenized card credentials, bank-payment permissions, or another controlled payment method. Digital wallets become relevant when the agent holds or transfers digital assets, uses stablecoins, or interacts with on-chain applications.

Suitable infrastructure includes payment APIs, tokenization, payment orchestration, real-time payments, merchant acquiring, identity services, policy engines, fraud controls, compliance automation, treasury tools, custody, blockchain connectivity, liquidity, and reconciliation.

No. Stablecoins are one possible settlement instrument. They may suit 24/7 cross-border flows, digital services, and on-chain transactions. Cards, instant bank transfers, tokenized deposits, and other payment methods may be preferable in different markets or use cases.

Key risks include unclear authority, agent impersonation, prompt injection, fraud, privacy breaches, unsuitable purchases, compliance failures, duplicate transactions, liquidity problems, and disputes over liability. Structured mandates, short-lived credentials, deterministic policy checks, transaction limits, step-up approval, and complete audit trails reduce these risks.

Yes. Banks already provide identity, accounts, payment instruments, compliance, fraud controls, and settlement. They need to expose those capabilities through secure APIs, add delegated-authority controls, recognize agent-initiated transactions, and support real-time status and audit data.