Before the bank authorises the payment, KYE™ authorises the agent.
KYE Protocol™ is the authority & evidence layer that sits over open-banking rails — not a replacement for them. The bank still answers “is this card transaction financially authorised?”. KYE™ answers the prior question every regulator, court, and chargeback panel actually wants: “was this AI agent allowed to request this purchase, on this customer’s behalf, under this delegation, in this state?”.
In the bank / agent / card stack.
KYE Protocol™ does not replace the bank, card network, wallet, processor, fraud engine, SCA flow, or issuer authorisation system. It sits as the authority and evidence layer around the agent’s purchasing action.
Customer / Cardholder
↓ delegates authority
AI Purchasing Agent
↓ requests purchase
KYE™ Authority Decision
↓ allow / deny / require_approval
Bank / Issuer / Card processor
↓ authorises payment
Merchant
↓ fulfils purchase
KYE™ Audit + Evidence Pack
Clean positioning: KYE™ provides Authority Finality™ before payment finality. The bank still decides whether the card transaction is financially authorised. KYE™ proves whether the agent had the authority to request it.
Account holder → TPP → AI agent → ASPSP. Six steps, end-to-end signed.
Step-by-step text version
- 1. Account holder grants the TPP a delegation: “initiate payments on my behalf, ≤ €1,000 single, ≤ €10,000 monthly, EUR + SEPA only.” Signed by the holder; SCA satisfied at the human edge once.
- 2. TPP sub-delegates an attenuated scope to its AI finance agent: “EUR only, EU corridors, prepare-and-stage; final submit requires human approval > €500.” Child scope MUST be a subset of the holder’s grant — protocol invariant.
- 3. AI agent prepares a €420 payment. The KYE™ ePDP walks: agent → TPP → account holder. Every link is signed; every scope attenuates. The bank receives a payment intent with the full chain attached.
- 4. ASPSP verifies the chain offline using public keys; returns
allow_with_constraints. Constraint: emit an SCA proof artefact + an audit-chain entry. Then the bank’s normal issuer authorisation pipeline runs. - 5. Holder revokes consent at T+30 days. Cascade kills every authority + every downstream agent grant in < 1s. Stale-consent transactions become impossible — the next agent call gets
deny: authority_revoked. - 6. 60 days later, a complainant disputes the €420 payment. The bank pulls the Evidence Pack; the regulator verifies the full chain offline using the public keys it already holds for each party. No interview transcripts, no spreadsheets.
Bank-backed AI shopping agent on a virtual card token.
A retail bank ships an AI purchasing agent to its customers. The customer delegates limited buying authority — capped amount, allowed merchant categories, jurisdiction, time window, approval threshold — bound to a virtual card token (never the raw PAN). On every purchase intent, KYE™ answers was the agent allowed to use this card, on this customer’s behalf, for this merchant, this amount, this category, in this state? before the bank’s issuer authorisation pipeline runs.
Authority grant — example
{
"grant_id": "kye:authority:grant:agent_purchase_001",
"principal_entity_id": "kye:human:bank-z.eu:psu:alice-meier",
"actor_entity_id": "kye:agent:bank-z.eu:retail:shopping-bot",
"capability_id": "kye:capability:payment_action:card_purchase",
"resource_id": "kye:credential:card-token:tok_abc123",
"scope": {
"max_amount_per_purchase": { "amount": 100, "currency": "GBP" },
"max_daily_amount": { "amount": 300, "currency": "GBP" },
"allowed_merchant_categories": ["groceries","travel","office_supplies"],
"blocked_merchant_categories": ["gambling","crypto","adult","weapons"],
"requires_approval_above": { "amount": 50, "currency": "GBP" },
"allowed_jurisdictions": ["GB"],
"valid_until": "2026-06-30T23:59:59Z"
},
"state": "active"
}Sub-capabilities — an agent may prepare without being allowed to execute
purchase.search·purchase.compare·purchase.preparepurchase.request_approval(push to bank-app) ·purchase.executepurchase.refund_request·purchase.dispute_prepare
Decision shape
Per purchase, the agent calls POST /v1/runtime/authorize. KYE™ checks: customer + agent + card token active · delegation valid · merchant allowed · amount within scope · approval threshold · risk state · payload signed and fresh. Returns allow_with_constraints · require_approval · deny with reason (e.g. merchant_category_blocked, amount_above_agent_threshold).
KYE™ Authority Finality™ + bank issuer authorisation = agent-backed card purchase with replayable proof a regulator, court, or chargeback panel can verify offline.
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.
Which obligations the chain evidences.
- PSD3 — SCA at the human edge once, attenuated through the chain; payment-initiation authority audit-trail; consent-revocation cascade.
- DORA — signed audit chain for ICT-third-party-risk; replayable evidence for incident response.
- EU AI Act — Title III high-risk (autonomous payment systems) technical-documentation pack: capability registry, decision logs, human-oversight gates, post-market monitoring.
- PCI DSS 4.0 — tokenised card binding (no raw PAN held by the agent); per-purchase Decision Map™.
- GDPR — minimum-necessary principle on payload metadata; right-to-erasure via lifecycle
tombstonedstate. - NIS2 — for the financial-services essential-entity classification.