--- title: "KYE Protocol™ — Agent Purchasing | Reference architecture for agentic commerce" description: "Independent reference architecture for AI-agent purchasing on a tokenised card. KYE Protocol™ provides the authority + state + decision + evidence layer…" url: https://kyeprotocol.com/agent-purchasing/ lang: en source: "KYE Protocol" --- > Independent reference architecture for AI-agent purchasing on a tokenised card. KYE Protocol™ provides the authority + state + decision + evidence layer… Reference architecture # 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 →](https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html) - **Mastercard Verifiable Intent** — announced **5 March 2026**, **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](https://verifiableintent.dev/). [Mastercard story →](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html) - **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 →](https://www.mastercard.com/news/europe/en/newsroom/press-releases/en/2026/santander-and-mastercard-complete-europe-s-first-live-end-to-end-payment-executed-by-an-ai-agent/) · [Santander press release →](https://www.santander.com/en/press-room/press-releases/2026/03/santander-and-mastercard-complete-europes-first-live-end-to-end-payment-executed-by-an-ai-agent) - **Visa Trusted Agent Protocol (TAP)** — announced **14 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 →](https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx) · [visa/trusted-agent-protocol →](https://github.com/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. Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. - **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. Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. 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 5b · try it yourself ## Change the inputs. Watch KYE™ decide. Adjust the agent state, customer authority, merchant, basket amount, customer-set approval threshold, card / token state, or risk state. The runtime decision, the first signed webhook KYE™ would emit, and an evidence-pack preview update live. Decision logic is intentionally simplified for clarity — production runtime semantics live in the gateway, never on a marketing page. 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. Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. - **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. Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. **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. Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. [Open-banking flow →](https://kyeprotocol.com/open-banking/) [On-Behalf-Of primitive](https://kyeprotocol.com/concepts/#on-behalf-of) [All financial-services use cases](https://kyeprotocol.com/usecases/#financial) [Threat model](https://kyeprotocol.com/risk/) [PSD3 / DORA / PCI DSS / EU AI Act](https://kyeprotocol.com/frameworks/) Talk to us ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).