---
title: "KYE Protocol™ — Open banking | Delegated payment-initiation authority for AI agents (PSD3 · DORA · EU AI Act)"
description: "KYE Protocol™ for open banking and delegated payment initiation: account holder → TPP → AI finance agent → ASPSP, every link signed, every scope…"
url: https://kyeprotocol.com/open-banking/
lang: en
source: "KYE Protocol"
---

> KYE Protocol™ for open banking and delegated payment initiation: account holder → TPP → AI finance agent → ASPSP, every link signed, every scope…

Open banking

# Before the bank authorises the payment, KYE™ authorises the agent.

KYE Protocol™ sits over open-banking rails as the authority & evidence layer. The bank authorises the card; KYE™ proves the AI agent was allowed to request the purchase on the customer’s behalf.

See the flow ↓ Card-issuing agent [On-Behalf-Of primitive](https://kyeprotocol.com/concepts/#on-behalf-of)

Where KYE™ sits

## 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.

PISP / TPP flow

## Account holder → TPP → AI agent → ASPSP. Six steps, end-to-end signed.

Step-by-step text version

1. 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. 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. 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. 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. 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. 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.

Card-issuing · agent purchasing on a tokenised card

## 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.prepare`
- `purchase.request_approval` (push to bank-app) · `purchase.execute`
- `purchase.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.

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.

Framework bindings

## 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 `tombstoned` state.
- **NIS2** — for the financial-services essential-entity classification.

[Per-framework reference →](https://kyeprotocol.com/frameworks/) [See all 4 financial-services use cases](https://kyeprotocol.com/usecases/#financial) [OSCAL exporter](https://kyeprotocol.com/oscal/)

Where to go next

## Adjacent reading.

[On-Behalf-Of primitive →](https://kyeprotocol.com/concepts/#on-behalf-of) [All 9 use cases](https://kyeprotocol.com/usecases/) [Threat model](https://kyeprotocol.com/risk/) [Readiness self-test](https://kyeprotocol.com/readiness/) [Scope a pilot](https://kyeprotocol.com/engage/#enterprises)

## 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/).