This note covers Issuer-Sovereign Agentic Payments: A method for enforcing agent spending limits inside the issuer's authentication step, by Rajneesh Kaushal, Dishant Sharma, and Ashu Kanaujia (arXiv:2609.27452, posted 23 September 2026, https://arxiv.org/abs/2609.27452). It is a preprint and it is not peer reviewed.

What the paper says

All three authors list Thales email addresses, and the paper has no conflict statement. The authors say that, in the approaches deployed today, the credential provider typically sits outside the bank of the cardholder. The authors say the card network or the provider then enforces the rule, not the bank. The authors say the issuer carries the risk but has little direct control at payment time.

The paper names AP2, Agent Pay, and Intelligent Commerce. The authors call each one effective in its own design. They say the three share one trait: enforcement sits away from the issuer.

The paper separates two modes: user present and user absent. It uses the absent case as the main example. The method adds a constraint component inside the authentication system of the issuer, at the Access Control Server of 3-D Secure.

At consent, the cardholder approves a rule once. The component records the rule and creates no payment credential. At payment, the component checks the merchant, the amount, and the time against the recorded rule. It generates the authentication value only if the checks pass.

The authentication value is the CAVV on Visa and the AAV on Mastercard. The authors say the check and the generation form one step, so no credential exists for a merchant outside the approved set. After that, the payment travels the normal card rails, and the issuer validates the value with its own key.

The authors limit the guarantee to this: the component will not create a valid value for a merchant outside the approved set. The authors argue for five advantages. They list no integration work for other parties, a decoupled ecosystem, issuer control, enforcement at credential generation, and a standard form on the wire.

What it does not show

The paper has five sections and no experiment, no prototype, no implementation, and no measured result. It reports no figure for latency, cost, or failure rate. It does not test the method against AP2, Agent Pay, or Intelligent Commerce, and compares them by description only. It does not say how an issuer will adopt the method.

Descriptions of other protocols come from the authors, not from tests. The Lena travel example is an illustration, not evidence.

Why it matters in payments

The paper puts the rule inside the issuer authentication step. My case studies cover the payout step and the checks around it.

In my disbursement scaling case study, a payout bank account must match the registered business bank account. That policy exists to prevent misdirected payouts, and it reduces the surface area for fraud and operational error.

My PJP readiness work lists fraud rules with different triggers: VEL_SPIKE and ODD_HOURS in real time, DORMANT in a daily batch, and HIGH_VALUE_DISB 30 minutes before closing.

Where a rule sits decides what it can stop. That is the part of this paper I take with me.