Source-linked AI summary
Issuer-Sovereign Agentic Payments
Dishant Sharma, Rajneesh Kaushal, Ashu Kanaujia
TL;DR
When users are absent, today's agentic payment approaches typically put spending-rule enforcement outside the issuer, even though the issuer carries the financial risk. The paper records the user's rule inside issuer authentication and generates an authentication value only for a permitted merchant. The payment then uses normal card rails and issuer validation, without an extra execution-time dependency.
Problem
When users are absent, current approaches typically place spending-rule enforcement outside the bank, while the issuer carries the financial risk and has little direct control at authorization.
Source: §2 · pp. 1–2Method
The issuer records a cardholder-approved rule and later checks the specific merchant against it, generating an authentication value only when the rule allows the payment.
Source: §3 · pp. 2–4Results
Takeaways & Limitations
The method places the decision to create a payment credential with the issuer that carries the risk, while leaving card processing unchanged.
Source: §4 · p. 5
Abstract
from arXiv · showhide
AI agents are beginning to make real payments. Current approaches let an agent pay by relying on a credential provider that, in the approaches deployed today, typically sits outside the cardholder's bank. The spending rules are then enforced by the card network or that provider, and not by the bank itself. This leaves the issuing bank, which carries the financial risk, with little direct control at the moment a payment happens. This paper describes Issuer-Sovereign Agentic Payments, a method that keeps that control with the issuer. The cardholder approves a spending rule once, and the bank's own authentication component records it. Later, when the agent pays a specific merchant, the bank checks the merchant against the approved rule and generates the card authentication value only if the merchant is allowed. The payment then travels the normal card rails and is validated by the issuer, with no extra dependency introduced at execution.
1. Introduction
AI agents are beginning to make payments using authority granted by users in advance. This method applies to both user-present and user-absent payments, focusing on the harder absent-user case by enforcing spending limits inside the issuer's authentication step.
1. Introduction
- Agentic payment protocols let agents purchase using authority users granted in advance.Examples include Google's AP2, Mastercard's Agent Pay, and Visa's Intelligent Commerce.Source: §1 · p. 1
- These approaches support payments approved in real time by a present user or authorized ahead of time for when the user is absent.The paper uses the absent-user mode as its main example because it is harder to secure and makes the gap in current approaches clearest.Source: §1 · p. 1
- The method enforces user spending limits inside the issuing bank's authentication step rather than relying on an outside party at payment time.Source: §1 · p. 1
2. Problem Statement
When users are absent, payments lack an in-the-moment approval check, while current approaches typically place spending-rule enforcement outside the issuing bank. The paper proposes moving enforcement into the issuer's authentication step, where the bank decides whether a payment credential is created.
2. Problem Statement
- Without the user present, another mechanism must ensure a payment stays within the user's authorized limits.Source: §2 · p. 1
- Today's approaches typically attach spending rules to a token or signed intent managed by a credential provider outside the cardholder's bank.Scopes can include a spending cap, allowed merchant types, and an expiry.Source: §2 · p. 1
- In the common model, the agent holds a reference that triggers an external provider to return a fresh cryptogram when the merchant is ready to charge.The network token service produces that cryptogram, and spending scope is checked at the network layer rather than by the bank.Source: §2 · pp. 1–2
- This creates a point-of-sale dependency on the external provider while leaving the issuer, which bears financial risk, with little direct control over spending-rule enforcement.Source: §2 · p. 2
- The proposed alternative moves enforcement into issuer authentication, so the bank decides whether a payment credential is formed at all.Existing approaches may enforce around a credential that already exists, even when a provider is hosted by the bank.Source: §2 · p. 2
3. Proposed Solution
The method records an approved spending rule at the issuer without creating a payment credential, then checks each later merchant and generates an authentication value only when the rule permits it. That value proceeds through ordinary card processing, with the issuer validating it as usual.
3. Proposed Solution
- The network token is an ordinary tokenized stand-in for the PAN, while the CAVV or AAV is the issuer-generated authentication value that this method governs.The network token cryptogram and issuer authentication value are distinct; the former belongs to tokenization and is checked during de-tokenization.Source: §3 · pp. 2, 4
- The issuer's constraint component records the approved rule at consent and later checks the merchant and generates an authentication value together, only when the rule permits it.The component is inside the issuer's authentication system; no payment credential is created at consent.Source: §3 · pp. 2–4
- At consent, the authenticated cardholder's rule is recorded and a reference is returned, but no authentication value or payment credential is created.The recorded rule includes a spending cap, allowed merchants, and a time window.Source: §3 · p. 3
- The recorded rule can be signed so later changes to its cap, allowed set, or time window are detectable and its approval can be proven in a dispute.This protects rule integrity and origin, separately from the check governing authentication-value generation.Source: §3 · p. 3
- At execution, the merchant's agent presents the network token and consent reference, and the issuer checks merchant eligibility, amount, and time window before generating a merchant-specific CAVV or AAV.If the merchant is outside the approved set, no valid authentication value is generated; checking and generation are a single step.Source: §3 · pp. 3–4
- After generation, the authentication value follows ordinary card authorization rails and the issuer validates it with its own key, without another call to the constraint component.Source: §3 · p. 4
- A rule can govern multiple payments, with each checked against its current state so the cap and time window apply across payments under one consent.Rules may also express allowed merchants or categories, per-payment amounts, payment counts, and currency.Source: §3 · p. 4
- Locating the component at the issuer's Access Control Server reuses a certified environment under issuer key management, without adding a trust boundary or sensitive-key holder.Source: §3 · p. 4
4. Advantages
The method keeps spending control with the issuer while preserving ordinary card processing: issuer checks precede credential generation, and the resulting payment uses existing rails.
4. Advantages
- The checked authentication value uses the standard field and existing rails, so parties process the payment as a normal authenticated card transaction.No processing changes are required.Source: §4 · p. 5
- The shopping agent and merchant's agent need no shared credential provider because the bank enforces spending limits directly.They interact only to pass the token and reference.Source: §4 · p. 5
- The issuer that carries financial risk decides whether a payment credential is created, aligning control with responsibility.Source: §4 · p. 5
- The issuer checks the rule before a credential exists and generates the value only when the rule is satisfied.For a merchant outside the approved set, no usable credential is produced.Source: §4 · p. 5
- The authentication value rides the normal field, making the transaction indistinguishable from other authenticated card payments on the network.The wire does not expose the agent arrangement.Source: §4 · p. 5
5. Conclusion
For agent payments made without the user present, the issuer records the user's approved rule and generates an authentication value only when a later payment fits it. The payment then follows standard card rails and is validated by the issuer without an extra execution-time dependency.
5. Conclusion
- Today's approaches place spending credentials and enforcement outside the bank, leaving the bank dependent on another party while it carries the risk of loss.Source: §5 · p. 5
- The issuer's own component records a rule approved once by the cardholder and generates the authentication value only when a later payment fits that rule.Source: §5 · p. 5
- The payment travels standard card rails and is validated by the issuer in the usual way, with no extra dependency at execution.Source: §5 · p. 5