Target picture: Scoped Mandate on ARF, PaSO and SPAA¶

Public version, status 23 October 2026 (design revision v3, live since 22 October 2026: the mandate is a credential issued by the bank; categories as Google Product Taxonomy IDs since 23 October 2026). Describes where the proof of concept leads: an agent purchase that rests entirely on the European trust framework. What already runs today is listed at the end.

The idea in one paragraph¶

A customer grants their bank one limited mandate: this much per purchase, this much in total, for this long, at these merchants, for these product categories. The approval is a strong customer authentication in the EUDI wallet. Afterwards an AI agent shops on the customer's behalf. At every purchase two parties check independently: the merchant checks the goods, the bank checks the money. Neither the wallet nor the agent decides about payments. Every rejection names the party and the reason; revocation takes effect immediately.

Roles according to the Architecture Reference Framework (ARF)¶

Two things are deliberate: the bank is both issuer of the SCA credential and verifier of the mandate approval, because it holds the mandate — and, since v3, it is also the issuer of the mandate itself. And the agent is not a separate wallet but a second holder key in the same wallet unit, with two credentials bound to that key: its identity from the operator, its mandate from the bank. Nothing in the chain is self-attested.

Protocols and formats¶

Every credential field by field: Credentials.

The flow in the target picture¶

Sequence of the mandate approval (bank as PaSO verifier, the only approval path):

A · Obtain credentials (once). The customer fetches the Konto Karte from their bank via OpenID4VCI after logging in to online banking (authorization code, PAR, PKCE). The agent generates its key pair in the Secure Enclave. The customer identifies to the operator with the Konto Karte (OpenID4VP); only then does the operator issue the agent's credential via OpenID4VCI with a pre-authorized code: agent id, operator with register number, role, validity, key as proof of possession. In the target picture the credential is sealed from the operator's EBW.

B · Grant the mandate (one SCA). The mandate lives at the bank and has two parts. The payment part is in the clear: limits, validity, permitted merchants. The checkout part — product categories (Google Product Taxonomy IDs) and age rule — stays with wallet and agent; the bank only ever sees its hash. The agent sends the request and identifies with its credential (key binding over a bank nonce). The bank issues an OpenID4VP request in the PaSO profile with the payment part as transaction_data, which carries the hash of the checkout part, not its content. The wallet shows both parts, the customer confirms with Face ID, the wallet presents the Konto Karte, the bank verifies, creates the mandate and issues it as a credential: an SD-JWT VC bound to the agent's key with the payment part in the clear, the checkout hash, how the approval was made, and a status-list entry for revocation. The agent fetches it via OpenID4VCI with a pre-authorized code from the approval session. There is no other approval path.

C · Purchase (no further prompt). The agent presents its agent credential and the bank-issued mandate credential to the merchant via OpenID4VP, with the basket hash as transaction_data, and hands over the checkout part in the clear. The merchant verifies both credentials against the roots of operator and bank, checks the status list, recomputes the checkout hash and compares it with the bank-signed claim, checks the basket against the categories and confirms with a signed attestation bound to hash C and the basket. No call to the bank. The agent submits a payment order to the bank referencing mandate and attestation. The bank verifies merchant, limits, validity and merchant signature, then settles via SCT Inst.

D · Say no and revoke. If the goods do not fit, the merchant rejects. If the money does not fit, the bank rejects. Every rejection names party and reason; nothing is paid. The customer revokes at one place, at the bank in the app or the bank's own app: the bank flips the status bit of the mandate credential and rejects every further payment; agent and merchant see the status without asking. An agent the customer cannot stop does not belong with consumers.

Evidence after the fact. A dispute never needs the customer's phone: the merchant keeps the presented credentials and the checkout part, the bank keeps the SCA session with the customer's key-bound signature over the hash. Anyone with the bank's root can recompute that the categories matched what the customer approved. The item-to-category mapping follows a shared scheme, the Google Product Taxonomy: the merchant logs taxonomy ID and path per line, so a third party can follow the decision.

Where SPAA sits¶

SPAA is not a service anyone calls but the European Payments Council's rulebook for account access beyond the PSD2 obligations. It defines the Dynamic Recurring Payment: a mandate under which many payments of variable amount run within fixed limits, set up with a strong customer authentication with dynamic linking and executed without further SCA. That mandate is the payment part of Scoped Mandate.

SPAA governs the traffic between the third party (asset broker) and the account-servicing bank (asset holder). Here the third party is the agent's operator: the agent speaks SPAA to the bank. Three things are outside SPAA and unchanged in the target picture: the customer's approval (OpenID4VP in the PaSO profile between wallet and bank), the merchant with checkout part and attestation (an addition above SPAA, carried as a reference in the payment order), and settlement (SCT Inst). Since 19 October 2026 the bank's mandate service also offers the same mandate in SPAA form as a façade following the Berlin Group openFinance structure under /spaa/v1 (Interface Specification §1.17).

What the separation of powers guarantees¶

The bank never sees the basket or the categories, the AI never sees the account. The merchant sees the payment part of the mandate — limits, validity, permitted merchants — because it is in the clear in the bank's credential; it does not see the account, the customer's name or the remaining budget. The intelligence is replaceable; the security lies in the mandate and in the checks of bank and merchant.

What runs today, what is target picture¶

Bank, merchant and operator are mocks with stable, documented interfaces. The path from today to the target picture replaces the mocks and transport protocols, not the interface contracts and not the distribution of roles.