Reference architecture · agent-backed card purchasing

Before the payment is authorised, prove the agent was authorised.

Independent reference architecture for an AI agent purchasing on behalf of a customer or business using a tokenised payment instrument. KYE Protocol™ provides the authority · state · decision · evidence layer around the agent action — complementary to payment rails and verifiable-intent layers, never a replacement.

Payment rails move money. Verifiable intent proves customer intent. KYE™ proves delegated authority.

Section 1 · public market context

Agentic commerce is moving from theory to live payment flows.

Public agentic-commerce announcements demonstrate that AI agents are entering real payment flows on infrastructure designed for trusted, scoped agent actions. Each item below quotes the issuing organisation’s own press release; we link the primary source so you can verify every claim:

  • Mastercard Agent Pay — announced 29 April 2025 as Mastercard’s “Agentic Payments Program”. Mastercard describes the program as “groundbreaking… integrates with agentic AI to revolutionize commerce” and introduces Mastercard Agentic Tokens built on existing tokenization that powers mobile contactless and Mastercard Payment Passkeys. Initial partners named in the press release: Microsoft, Stripe, Google, Ant International’s Antom, Braintree, IBM, OnePay. Mastercard press release →
  • Mastercard Verifiable Intent — co-developed with Google; Mastercard describes it as “a new open, standards-based trust layer for agentic commerce” that “links identity, intent, and action into a single, privacy-preserving record” using a Selective Disclosure privacy mechanism. Aligned with Google’s Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP); described as protocol-agnostic. Public industry support cited in the announcement: Adyen, Fiserv, Worldpay. The framework is open-sourced at verifiableintent.dev. Mastercard story →
  • Banco Santander × Mastercard live AI-agent payment — announced 2 March 2026. Santander and Mastercard describe the transaction as “Europe’s first live end-to-end payment executed by an AI agent” and “the first agentic payment carried out within a regulated banking framework”. The pilot uses Mastercard Agent Pay; integrates Microsoft Azure OpenAI Service and Microsoft Copilot Studio; ran through Santander’s live payments infrastructure. Both organisations explicitly note it is a pilot, not a commercial rollout. Mastercard press release → · Santander press release →
  • Visa Trusted Agent Protocol (TAP) — announced October 2025 by Visa with 10+ partners; Visa describes it as “a foundational framework for agentic commerce that enables secure communication between AI agents and merchants during every step of a transaction”. Built on the HTTP Message Signature standard; aligned with the Web Bot Auth proposal; co-developed with Cloudflare. Reference implementation open-source on GitHub. Visa investor announcement → · visa/trusted-agent-protocol →

These independent initiatives validate one shared thesis: if agents can buy on behalf of people or businesses, the ecosystem needs a standard way to prove delegated authority, scope, state, decisioning, and evidence — before the payment-network rules execute. KYE Protocol™ sits at exactly that layer; it composes with each of the initiatives above without claiming any of them as a partner or endorser. See the disclaimer in §8.

Section 2 · the unresolved authority question

Payment authorisation is one question. Authority is another.

Card-network authorisation already answers “is this card transaction financially authorised?”. Agentic commerce raises a separate, prior question that today’s issuer pipelines do not answer:

  • Which agent acted?
  • Who delegated authority to that agent?
  • What payment instrument (card / token / wallet) was used?
  • What merchant + MCC was allowed?
  • What amount limits applied?
  • Was approval required and on which channel?
  • What was the agent’s state at the time of action?
  • What signed evidence proves the decision?

A bank, issuer, merchant, network, auditor, court, or regulator who later wants to replay any one purchase needs all eight answers in a single replayable artefact. That is the gap KYE Protocol™ closes.

Section 3 · where KYE™ fits

Authority finality, before payment finality.

KYE Protocol™ does not process the card payment, issue the card, replace tokenisation, run fraud scoring, replace SCA, or replace issuer authorisation. It is the authority + state + decision + evidence layer around the agent action.

  Customer / Cardholder
        ↓ delegates limited authority
  AI Purchasing Agent
        ↓ uses
  Purchase Capability
        ↓ against
  Card Token + Merchant + Basket
        ↓ checked by
  KYE™ Authority Decision
        ↓ returns
  allow / deny / require_approval
        ↓ then
  Bank / Issuer / Card processor authorises payment
        ↓ and emits
  Decision Map™ + Evidence Pack
Section 4 · KYE™ object model

Every purchase resolves into eight objects.

  • Principal entity — cardholder or business (kye:human:bank-z.eu:psu:alice-meier / kye:business:bank-z.eu:corp:acme-treasury-gmbh).
  • Acting entity — AI purchasing agent (kye:agent:bank-z.eu:retail:shopping-bot).
  • Capability entity — card_purchase with sub-capabilities (purchase.search · purchase.compare · purchase.prepare · purchase.request_approval · purchase.execute · purchase.refund_request · purchase.dispute_prepare).
  • Resource entity — tokenised payment instrument (kye:credential:bank-z.eu:card-token:tok_abc123). Agent never holds the raw PAN.
  • Scope — amount cap, merchant allowlist, MCC allowlist + blocklist, jurisdiction, time window, approval threshold.
  • State — six dimensions: agent lifecycle, credential, authority, delegation, recovery, risk.
  • Decision — one of allow_with_constraints, require_approval, deny, with reason code.
  • Evidence — signed audit event, payload hash, receipt reference, Decision Map™, Evidence Pack.
Section 5 · runtime decision flow

Seven steps from purchase intent to signed proof.

Step-by-step text version
  1. 1. Agent prepares the purchase: merchant, basket, amount, currency, delivery address, payment instrument.
  2. 2. Agent submits a signed purchase request — POST /v1/runtime/authorize.
  3. 3. KYE™ resolves customer + agent + card token + capability + scope.
  4. 4. KYE™ evaluates state, delegation, authority, and policy.
  5. 5. KYE™ returns allow_with_constraints · require_approval · deny with reason (e.g. merchant_category_blocked, amount_above_agent_threshold).
  6. 6. Bank / payment stack continues with normal card-issuer authorisation.
  7. 7. KYE™ emits the audit event + Decision Map™ + Evidence Pack to the audit chain.
Section 6 · evidence pack

What ends up signed and replayable.

  • customer / principal reference
  • agent reference + agent state snapshot at time of purchase
  • delegation grant URN
  • payment capability URN
  • card-token reference (no raw PAN)
  • merchant metadata + MCC + jurisdiction
  • basket hash
  • amount + currency
  • policy decision + reason code
  • approval event (where applicable)
  • state snapshot (six dimensions) + risk state
  • payload hash + signature
  • audit-chain entry pointer
  • receipt reference (if execute completed)
  • full Decision Map™

The Evidence Pack lets the bank later prove either: “the agent was allowed to do this specific purchase at this specific time under this specific authority” — or, equally importantly, “the agent was not allowed; the transaction should have been blocked or escalated.”

Section 7 · why banks care

Eight teams that read this artefact.

  • Agent-purchase disputes — complainant says the agent overstepped. Pull the Evidence Pack; replay offline.
  • Chargebacks — merchant challenges a refund. The Decision Map™ shows why the purchase was authorised in the first place.
  • Fraud investigation — SIU walks the chain agent → agent state → delegation → principal in seconds.
  • Consumer protection — regulator audits the merchant-allowlist + amount-cap behaviour against the holder’s consent.
  • Merchant assurance — merchant proves the AI agent that hit their checkout was a real delegated agent of a real cardholder.
  • Issuer liability analysis — the bank distinguishes “agent acted within authority” vs “agent acted outside authority” in audit.
  • Operational resilience (DORA) — replayable evidence chain meets ICT-third-party-risk reporting.
  • Regulatory audit — PSD3 + EU AI Act + PCI DSS 4.0 obligations all draw from the same chain.
Honest non-goals

What KYE™ does not do.

  • KYE™ does not store raw card numbers (PANs).
  • KYE™ does not process the payment.
  • KYE™ is not the issuer processor, the wallet custodian, the SCA flow, or the fraud engine.
  • KYE™ does not replace card-network rules.
  • KYE™ does not replace customer consent UX.

KYE™ governs: agent authority · card-token authority · purchase capability · scope limits · state · decision · audit · evidence · revocation. That keeps the protocol correctly scoped.

Section 8 · disclaimer

Independent reference architecture, not endorsement.

Disclaimer. This page is an independent illustrative analysis of public agentic-commerce announcements, with every primary claim cited to its issuing organisation’s own press release in §1. KYE Protocol™ is not affiliated with, sponsored by, endorsed by, or approved by Mastercard, Visa, Banco Santander, Microsoft, Google, Stripe, Ant International / Antom, Braintree, IBM, OnePay, Adyen, Fiserv, Worldpay, Cloudflare, the FIDO Alliance, EMVCo, or any payment network, issuer, acquirer, merchant, processor, or standards body referenced on this page. Mastercard Agent Pay™, Mastercard Verifiable Intent™, Mastercard Agentic Tokens™, Visa Trusted Agent Protocol™, Google Agent Payments Protocol (AP2)™, Universal Commerce Protocol (UCP)™, Microsoft Azure OpenAI Service™, Microsoft Copilot Studio™, and all other third-party names and trademarks belong to their respective owners. The references on this page are public market context only — not a statement of partnership, integration, technical compatibility, or product approval. Readers should rely on the cited primary sources for canonical product behaviour. KYE Protocol™ is independently developed and published Apache 2.0.

Where to go next

Adjacent reading.

payments Open-banking flow → link On-Behalf-Of primitive lightbulb All financial-services use cases shield Threat model fact_check PSD3 / DORA / PCI DSS / EU AI Act forum Talk to us