Conductance: Private-Sector Agentic Stacks Shipping Faster Than CBDCs

The Sovereign Layer

Programmable CBDC Architecture and Agentic Settlements

Capture the FlagAxel Quack

Part 1: programmable sovereign tokens, UTXO objects, oracles, and agentic settlement in ECB/BIS pilots. This is the private-sector sequel — the rails that already clear.

The Dissolution of Identity: Virtual Characters, AI Agents, and the Sovereign Self

Identity is dissolving into masks, keys, and proofs: AI VTubers top Twitch, agents get on-chain names and wallets, and proof-of-personhood turns scarce. Time to plant identity as a flag.

Capture the FlagAxel Quack

Agents acquired names and reputations. Here they acquire spend authority — and liability chains.

In Part 1 I argued that Europe is building money that reasons: CBDC tokens as policy-carrying objects that agents can consume under DORA-grade rails and AI Act constraints. The closing promise was explicit — examine how private-sector agentic commerce stacks already ship similar primitives at global scale, often with lower latency and broader merchant acceptance than today’s sovereign pilots.

This is that essay. It is longer on purpose. The gap between a press release and a production payment path is where architecture, liability, and regulation actually live.

Conductance vs viscosity (the frame)

I use two physics metaphors deliberately:

Part 1 was viscosity with an agentic coating. Part 2 is conductance with an identity problem: how do you let a non-human initiate a card (or stablecoin) payment without handing it a primary account number and a blank cheque?

In 2025–2026, conductance won the stopwatch. An April 2025 double launch — Mastercard Agent Pay (29 Apr) and Visa’s agentic commerce push (30 Apr), later crystallised as Trusted Agent Protocol / Intelligent Commerce — and Stripe’s Agentic Commerce Protocol (ACP) with OpenAI (Instant Checkout era, open spec on agenticcommerce.dev) turned “AI can shop” from demo into integration work. Google’s Agent Payments Protocol (AP2) pulled both networks into a multi-party orchestration story by September 2025. Parallel to all of that, x402 (Linux Foundation) revived HTTP 402 Payment Required for machine-native API micropayments.

None of this waits for a retail digital euro mandate. It sits on fifty years of dispute law, scheme rules, and acquirer plumbing — the boring infrastructure CBDCs still have to reinvent or interoperate with.

The problem statement experts actually solve

A production agentic payment is not “the LLM clicked Buy.” It is a closed chain of answers to six questions:

1. Who is the principal? (cardholder, corporate treasury, regulated entity)
2. Who is the agent? (model runtime, vendor, version, key material)
3. What mandate binds them? (MCC allowlist, amount caps, TTL, geography, merchant whitelist)
4. What credential moves? (network token / agentic token / shared payment token — never a raw PAN in the agent context if you are sane)
5. Who is liable on chargeback / fraud / AI Act high-risk decisioning?
6. What is the audit artifact? (JWT, signed intent, explanation log, webhook trail)

Get any of these wrong and you do not have innovation — you have an uninsured confused deputy with a credit line.

Protocol map (2025–2026)

Think in layers the way you think in networking: MCP is not Visa; ACP is not a CBDC; x402 is not a supermarket POS. Confusion of layers is how strategy decks die.

Stripe ACP — open commerce grammar for agents

What shipped

Stripe positions the Agentic Commerce Protocol as an open standard (co-created with OpenAI; Meta also in the creator set per Stripe docs) defining how AI agents complete purchases on behalf of buyers. Spec and schemas live at agenticcommerce.dev with versioned OpenAPI/JSON Schema (e.g. 2026-04-17 tree in the public repo). The consumer-visible wedge was Instant Checkout in ChatGPT: stay in the conversation, complete a real purchase, merchant still on Stripe rails.

ACP’s building blocks (Stripe’s own decomposition):

• Agentic checkout — create/update/complete sessions; cart; fulfilment options; payment processing
• Cart and feed — catalogue browse before checkout
• Delegate payment — pass payment tokens among buyer, agent, and business via payment handlers
• Delegate authentication — OAuth 2.0 so agents act for a buyer at a business
• Orders and webhooks — lifecycle: confirm, ship, deliver, refund

This is not “Stripe invented cards.” It is Stripe inventing the session and delegation grammar so ChatGPT-class surfaces and merchant backends share a language.

Shared Payment Tokens (SPTs)

The security heart is the Shared Payment Token concept (Stripe agentic commerce docs): a credential the agent can present without holding a primary account number. Design goals that matter in regulated EMEA:

• AES-GCM-class encryption of sensitive material at rest/in transit between parties that need it
• Risk signals without PAN — dispute likelihood, card-testing heuristics, velocity flags as first-class telemetry for Radar-class engines
• Conditional economics — promo windows, cart thresholds, MCC gates can vest in the instrument, so the model is not re-negotiating policy in natural language every turn
• Merchant-of-record / Connect patterns — enterprise control planes for who is seller of record when the “UI” is an agent

Fraud scoring narratives put graph anomaly checks on SPT telemetry in the sub-100 ms band. Treat vendor latency as a design target, not your SLA until you measure it on your traffic mix.

Why ACP “won mindshare” among builders

Three non-technical reasons:

1. Apache-2.0 / open-spec posture — agents and merchants can implement against a public contract, not only a private API.
2. OpenAI distribution — Instant Checkout made the protocol legible to product managers overnight.
3. Composability with existing Stripe surface — Radar, Issuing, Treasury, Connect: the agent path reuses the same economic atoms (including, in advanced designs, metering model cost in the same unit as goods).

If you are building an agent storefront in 2026, ACP is often the default north star grammar even when settlement still lands on Visa/Mastercard tokens underneath.

Mastercard Agent Pay — the network as delegated token runtime

Architecture: agent as delegated tokenholder

Mastercard’s April 2025 launch treats the agent less like a browser and more like a new credential class on MDES (Mastercard Digital Enablement Service). Agentic Tokens extend network tokenisation: provisioned under cardholder mandates, revocable, attribute-rich.

What “attribute-rich” means in practice (research + programme narratives):

• JSON policy vectors bound at provisioning or update: spend caps, approved MCCs, TTL (time-synced expiry), geography, tool contracts
• Machine-readable tool surfaces — OpenAPI 3.1 / MCP-shaped endpoints so LangGraph/Agentforce-class orchestrators generate tool schemas without a human hand-writing every method
• Insight Tokens — privacy-preserving behavioural vectors (homomorphic / encrypted-feature narratives) for RAG-style fraud and spend prediction without dumping raw PII into the model context
• Know Your Agent (KYA) — registration of the agent identity; PS256-signed JWTs with rotating key IDs; revocation via compact structures (bloom-filter-class blacklists in design notes)

The philosophical claim: identity, policy, and payment share one token lifecycle. That is the correct unit of design. Separating “the LLM” from “the card” without a binding mandate is how you recreate password-sharing with extra steps.

Consent model

Agent Pay’s consent story is mandate-at-provisioning: the cardholder (or corporate admin) defines what the token may do before the agent runs hot. That maps cleanly to corporate T&E agents and household “buy milk under €40” bots. It maps less cleanly to open-ended shopping agents that discover merchants mid-dialogue — those need dynamic mandate updates or you will over-provision.

Merchant integration

Because acceptance is the existing Mastercard network, merchants often see an agent flag in the auth message rather than a brand-new rail. That is the unfair advantage CBDCs envy: two billion-plus credentials already work at the till.

Pilot-era partner names in public comparison write-ups included Microsoft, IBM, Braintree, Checkout.com — the point is not the logo list, it is the acquirer and cloud path into production.

Latency bands (pilot / production narratives)

EMEA clients I hear in expert-network settings demand similar orders of magnitude: <100 ms for fraud decisioning in the hot path, <800 ms for multi-rail reconciliation loops. Your p99 on SEPA + scheme + core banking will differ; design with budgets, not vibes.

Visa TAP / Intelligent Commerce — signed intent and external memory

Timeline nuance

Visa announced agentic commerce capabilities 30 April 2025 (a day after Agent Pay). The specific Trusted Agent Protocol lineage and the broader Visa Intelligent Commerce programme evolved through 2025 (TAP materials often dated mid/late 2025 in secondary sources). For architecture, use the stable split:

• Tokenisation via Visa Token Service (VTS) agent credentials
• Per-transaction signed intent — agent acts inside an authorized scope; intent is a first-class signed object
• Agent-as-MoR / constrained intermediary patterns for some merchant flows (agent closer to merchant-of-record than pure delegated cardholder token)
• Acceptance Cloud + SDKs for integration
• Signals APIs for post-transaction feedback (dispute prediction, continuous risk training)

Five-API mental model (Intelligent Tokens suite)

A useful expert decomposition that matches how FS architects brief the stack:

Personalisation vectors landing in vector DBs (Pinecone/Weaviate-class) for multi-hop reason-then-pay is the pattern: the network becomes external memory with legal gravity, not just a pipe.

Consent model vs Mastercard

Where Agent Pay emphasises mandates bound to tokens at provisioning, Visa’s TAP lineage emphasises per-transaction signed intent inside a scope. In practice serious programmes need both: standing authorities and fresh intent for higher-risk actions. The network you pick first often reflects whether your UX is “always-on procurement bot” or “confirm this cart in chat.”

3-D Secure and step-up

Adaptive 3DS-flex remains the adult in the room. Silent auth when risk is low; challenge when the graph gets nervous. Conditional auth narratives often cite <200 ms when no challenge fires — challenges destroy agent UX, so the real product work is mandate design that keeps risk scores boring.

Stablecoins on the side

Both networks moved into tokenised deposit / stablecoin settlement narratives (Mastercard Multi-Token Network framing; Visa stablecoin settlement paths via major L1s). For EMEA banks this is a treasury and MiCA conversation layered on top of agent credentials — not a replacement for scheme rules on day one.

Side-by-side: Agent Pay vs TAP (expert cut)

You will run both if you are a European bank with dual issuing and dual acceptance. Single-network purity is a startup luxury.

Google AP2 — orchestration above the schemes

Agent Payments Protocol (AP2) is best understood as an orchestration and interoperability bet: multiple agents, wallets, and networks need a shared choreography so the industry does not fragment into four mutually deaf “agent checkouts.” Visa and Mastercard joining AP2 as launch partners (September 2025) is the signal: schemes will compete on tokens and risk, and still cooperate on how agents speak payment.

For architects: put AP2 (or equivalent multi-party contracts) in the supervisor plane; keep scheme tokens in the credential plane; keep MCP tools in the action plane. Collapse the planes and you cannot reason about liability.

Production multi-agent pattern (FS / insurance)

What actually ships in regulated EMEA multi-agent systems — hierarchical, not free-for-all swarms:

This mirrors Part 1’s CBDC “Liquidity Manager / Compliance Node” story — except the policy carrier today is usually a network token + JWT, not a central-bank UTXO opcode.

Failure modes experts watch

• Mandate over-broad → agent becomes a shared corporate card with a chat UI
• Model drift → same mandate, new tool-calling behaviour after a silent host update
• Dual writes — agent thinks payment succeeded; webhook never arrived; recon agent must be source of truth
• Explainability theatre — SHAP dump nobody can operate in a complaint file
• Cross-border data — personalisation vectors leaving the EU without a transfer story

x402 — the open-web twin (not a POS replacement)

x402 (Coinbase origin → Linux Foundation x402 Foundation, Apache-2.0) makes HTTP 402 Payment Required real:

1. Client GETs a resource.
2. Server returns 402 with machine-readable PAYMENT-REQUIRED (schemes, amount, network, payTo).
3. Client signs PAYMENT-SIGNATURE (often USDC on Base/Solana/etc.).
4. Server verifies/settles (often via a facilitator), returns 200 + PAYMENT-RESPONSE.

Schemes include exact, upto (usage ceiling — natural for LLM tokens), and batch-settlement for high-frequency micropayments. Facilitators are typically non-custodial executors of signed authorisations.

Where x402 fits the conductance map:

x402 is the missing payment layer for M2M composition. It is not how you buy groceries in Düsseldorf in 2026. Conflating the two is how crypto-native decks lose bank audiences — and how bank decks miss the API economy.

MCP guides for x402 matter: the same agent that calls tools/call can pay for the tool. That closes a loop Part 1 only sketched on sovereign rails.

A2A — when the counterparty is another agent

Agent2Agent (A2A) (Google → Linux Foundation) standardises opaque agent-to-agent collaboration: Agent Cards, tasks, artifacts. It is not a payment protocol. The correct stack slogan:

Build agents in any framework → tools via MCP → collaborate via A2A → pay via ACP/scheme tokens/x402 → settle sovereignly when viscosity is mandatory.

Payment without A2A is a single-agent checkout. A2A without payment is a committee that cannot tip the waiter.

EU regulatory envelope (the part that kills demos)

EU AI Act

Automated creditworthiness and certain fraud decisioning can sit in high-risk categories. Production programmes claim readiness via:

• Per-decision explanation artifacts (SHAP-compatible or equivalent operator-readable)
• Cryptographically attested agent identities (JWT/KYA)
• Human-in-the-loop thresholds with logged overrides
• Dataset and drift governance for the models inside risk agents

If your “agent pays” path includes a model that approves credit or blocks a customer, you are not in a chatbot sandbox. You are in Annex-risk territory. Budget compliance engineering like you budget auth latency.

PSD2 → PSD3 / PSR trajectory

Delegated payments need strong customer authentication stories that still allow automation: delegated OAuth, step-up on anomaly, clear payer consent receipts. Agent mandates must be explainable to a customer who never typed a CVV into the chat.

GDPR

Insight tokens and personalisation vectors are still personal data pipelines. Data minimisation vs model quality is the permanent tension; “homomorphic” marketing does not remove DPIA work.

DORA

If the agent path is in scope for an financial entity’s ICT, the PSP, cloud host, and model provider become third-party concentration topics. Conductance that depends on one US network + one US model host is a single story for the register of information.

MiCA (when stablecoins enter)

x402 and network stablecoin settlement drag crypto-asset regimes into the same programme. Separate the agent credential design from the settlement asset design or your legal memo becomes a novella.

Conductance vs viscosity — extended

The rational endgame is hybrid:

• Conductance for conversational commerce, API micropayments, day-to-day agent spend under tight mandates.
• Viscosity for holding limits, welfare constraints, wholesale atomic settlement, moments that must not depend on a single network’s outage or policy change.

Part 3 of this series — when written — is the fusion architecture: when does the supervisor agent mint or pull a CBDC UTXO versus presenting an Agentic Token? The honest 2026 answer is: almost always the token first, CBDC when the corridor and the statute exist.

Architecture blueprint (what I would put on a whiteboard)

A production path is a pipeline of roles, not a single chat session. In order:

1. User / corporate policy admin sets mandates, spend caps, MCC allowlists, and TTLs.
2. Supervisor agent reads those policies, calls MCP tools, and talks to merchant ACP / catalog surfaces.
3. Checkout yields a credential, never a raw PAN: Shared Payment Token, Agentic Token, or VTS agent credential.
4. Risk agent consumes Insight/SPT (and related) signals before anything clears.
5. Auth hits scheme rails (Mastercard/Visa), an x402 facilitator, and/or SEPA as the corridor demands.
6. Recon agent is source of truth via ISO 20022 mappings, webhooks, and ledger state — not the model’s last message.
7. Audit store keeps AI Act logs, consent receipts, and the JWT/intent trail.

Non-negotiables

1. No raw PAN in model context or long-term agent memory.
2. Separate identities for research agents vs spend agents.
3. Webhook/recon as source of truth, not the LLM’s last message.
4. Kill switch: revoke token + disable MCP payment server in one runbook.
5. Dual-network issuing if you cannot tolerate a single scheme outage for critical flows.

Flag theory for agent wallets

Classic flag theory diversifies jurisdictions. Agentic conductance needs the same instinct:

• Do not let one cloud agent host hold every mandate.
• Do not let one scheme token be the only spend path for critical ops.
• Do keep a human-gated break-glass path.
• Do treat payment MCP servers like HSMs: change control, pinned versions, least privilege.
• Do assume the model host will change behaviour; bind power in credentials, not in prompt text.

Final thoughts

Part 1’s sovereign layer is the long game: money as a democratic policy object. Part 2’s conductance is the short game: agents already spend, on rails that already clear, under legal wrappers that already know how to charge back a bad transaction.

If you only read ECB PDFs, you will miss that the agentic economy is being standardised in OpenAPI files, network tokens, signed intents, and HTTP 402 headers — not only in unified ledgers. If you only read Stripe blog posts, you will miss that liability, AI Act high-risk classification, and dual-scheme reality decide whether your demo survives a bank’s architecture board.

Private stacks ship. Sovereign stacks deliberate. The supervisor agent in production will call whichever tool returns 200.

Your job — as builder, risk officer, or citizen planting flags — is to make sure that 200 was authorized, attributable, and reversible on purpose.

The website and the information contained therein are not intended to be a source of advice or credit analysis with respect to the material presented, and the information and/or documents contained on this website do not constitute investment advice.

Addendum: Programme names, partner lists, and latency bands reflect 2025–2026 public docs, vendor narratives, and research notes (including expert-network preparation materials). Schemes and open specs evolve quickly — re-verify against Mastercard Developers, Visa Acceptance/Intelligent Commerce docs, docs.stripe.com/agentic-commerce, agenticcommerce.dev, x402.org, and your counsel before any build or investment decision. Yes, I use AI tooling to compile long research from a Markdown vault; the arguments and structure are editorial.