发卡行主导的智能体支付：Issuer-Sovereign Agentic Payments

持卡人不在场时，承担资金风险的发卡行如何在支付凭证生成前执行消费规则。

• 场景：作者称智能体正从给建议转向行动，付款是其中一种。行业方案一般有两种模式：用户在场并当场批准，或事先授权、支付时不在场。本文两种都适用，主例是第二种；作者称它更难保障，也是现有做法缺口最清楚之处。
• 现有做法：用户连接卡并授予范围，如消费上限、允许的商户类型和到期时间。卡以 token 表示，规则附在 token 或用户意图的签名记录上。支付时智能体持有引用；商户准备扣款时，系统回调 credential provider，用引用换取 cryptogram。
• 作者指出的后果：作者称 cryptogram 由网络的 token 服务生成，消费范围在网络层而非银行检查。于是支付依赖外部方在销售点被连通并响应；发卡行承担资金风险，却在授权当下缺少直接控制，并与第三方绑在一起。
• 作者的立场：作者称 Google AP2、Mastercard Agent Pay、Visa Intelligent Commerce 在各自设计内有效，但执行都离开发卡行，发卡行主要在凭证已于别处形成后做最终授权。即便提供方可由银行托管，执行仍围绕已经存在的凭证，而不是决定凭证是否形成。
• 本文提出：Issuer-Sovereign Agentic Payments。持卡人批准一次规则，银行自己的认证组件记录它；智能体向特定商户付款时，银行核对商户与规则，仅在允许时生成卡认证值。支付走原有卡通道并由发卡行校验，执行时不引入额外依赖。

论文没有单独的 Related Work。相关讨论在引言和第 2 节，并指向参考文献。

智能体支付产品

• 三种已公布方案：作者把 Google AP2、Mastercard Agent Pay、Visa Intelligent Commerce 列为让智能体凭事先授予的权限完成购买的例子，并称它们一般支持用户在场与事先授权两种模式。引用日期分别为 2025 年 9 月 16 日、4 月 29 日、4 月 30 日。
• 作者点名的共同点：作者称三者在各自设计内有效，但执行离开发卡行；发卡行主要在凭证于别处形成之后参与最终授权。即便这类提供方可由银行托管，执行仍围绕已存在的凭证，而不是决定凭证是否被创建。

token 化与支付时换取 cryptogram

• Mastercard tokenization：作者用它说明常见模型。给卡做 token 化会返回带唯一引用的 token；请求方稍后用该引用，在交易时请求 token 和新鲜 cryptogram。作者称 cryptogram 由网络 token 服务产生，消费范围在网络层检查，而不是在银行。
• 连接智能体时的 token：作者称任何智能体支付之前，用户首次把卡连到智能体时，经 Visa Token Service 或 Mastercard MDES，按商户或钱包的 card-on-file 路径 token 化，得到常称 DPAN 的网络 token，代替 PAN。作者称这一步是普通做法，不是本文提出的部分。依据为 EMV Payment Tokenisation 与 MDES 文档。

发卡行侧认证

• EMV 3-D Secure：作者称发卡行 Access Control Server 在认证时用发卡行密钥生成认证值，Visa 为 CAVV，Mastercard 为 AAV，通常覆盖一个特定商户。认证供应商运行该服务器时，也是代表银行并使用银行密钥。作者称发卡行因此是执行消费规则的自然位置，因为它已经拥有决定认证值是否存在的组件。

论文没有实验基线，也没有列出用于对比的基准或数据集。

作者把本文定位为相反立场：把执行移入发卡行自己的认证步骤，由银行决定支付凭证是否被创建。

Issuer-Sovereign Agentic Payments 在发卡行认证系统内增加约束组件。同意阶段只记录规则；执行阶段把商户核对与认证值生成做成同一步，通过后才有可支付凭证，再沿原有卡通道授权。Figure 1 展示同意与执行两阶段。

前提与新增组件

• 网络 token：智能体支付之前，卡经 Visa Token Service 或 Mastercard MDES token 化，得到代表 PAN 的 DPAN。智能体像 card-on-file 一方那样持有它。作者称这不是本文提出的步骤，只回答智能体如何一开始持有卡凭证。
• 认证值：3-D Secure 下，Access Control Server 位于发卡行域，用发卡行密钥生成 CAVV 或 AAV，向授权系统证明持卡人已认证，通常覆盖单一商户。
• 约束组件：放在发卡行认证系统、具体在 Access Control Server。作者称该服务器已认证、运行在发卡行密钥管理之下，也是持卡人认证发生之处，因此不新增信任边界或敏感密钥持有者。

同意阶段

• 用户在场，且不扣款。示例：法国持卡人 Lena 让旅行智能体在七天内预订至多 500 欧元的任意航空公司并批准。智能体向 Directory Server 发非支付认证请求，再路由到 Access Control Server。
• 持卡人挑战：服务器要求她确认自己是持卡人。她以指纹或其他合适方式批准。验证后，服务器请约束组件提交规则。
• 只记规则：组件记录消费上限、允许商户集合和时间窗，不生成认证值或支付凭证，只返回确认规则存在的引用。同意结束时，存在的是规则及其引用。
• 可选签名：需要时，组件可把规则提交为密码学签名对象，使上限、允许集合或时间窗的事后改动可被发现。作者称这保护规则的完整性与来源，并可在争议中证明已批准规则；它与是否生成认证值的检查分开。

执行阶段

• 用户缺席。购物智能体把 DPAN 和同意阶段的引用交给商户智能体。商户智能体发起适合持卡人不在场的认证请求，并引用该规则，使银行知道适用哪条规则。请求经 Directory Server 到 Access Control Server，再交给约束组件做校验并生成。
• 同一步核对与生成：组件确认商户在允许集合内、金额在上限内、请求在时间窗内。仅全部通过，才为该笔交易生成覆盖单一商户的 CAVV 或 AAV。商户在允许集合外时，不生成有效认证值。作者称系统内因此没有可用支付凭证，检查与生成之间也没有“凭证已存在、商户却从未获批”的窗口。
• 此后按普通已认证卡支付：认证值回到商户智能体。商户智能体向网络提交授权，携带网络 token 和认证值。网络把 DPAN 还原为 PAN，把 PAN 和认证值转给发卡行。发卡行用自己的密钥校验认证值并授权。作者称此阶段不再回调约束组件。批准再作为回执返回。

规则能表达什么，以及保证说到哪里

• 多笔与其他约束：一条同意不必只对应一笔购买。它可以允许上限和时间窗内的多笔支付，每笔对照规则的当前状态检查，使上限和时间窗覆盖同一次同意下的全部支付。作者称上限和时间窗只是两例；生成认证值时还可检查允许的商户或商户类别、单笔金额、支付次数、允许币种等。
• 两条密码学值：网络 token cryptogram 属于 token 化服务，在去 token 化时检查；CAVV 或 AAV 属于发卡行。作者称本方法只涉及后者。
• 作者写出的保证：消费规则在认证值生成的当下、在发卡行内执行。作者称保证是：对允许集合外的商户，发卡行组件不会创建有效认证值，系统内不会形成可支付凭证。
• 作者列出的线上性质：认证值放在标准认证字段，各方按普通已认证卡支付处理，处理流程无需改动。购物智能体与商户智能体不需要共享 credential provider，只传递 token 和引用。作者称交易与其他已认证卡支付无法区分，且不暴露智能体安排。

实验设置

• 被测模型：论文未运行或报告任何模型。
• 数据集或基准：论文未使用数据集、基准或评测环境。
• 基线：未设实验对照。引言和第 2 节讨论 AP2、Agent Pay、Intelligent Commerce 与 Mastercard token 化，但未报告作者自己运行这些系统。
• 指标与评审：未定义成功率等指标，未写评审模型、阈值、样本量或重复次数。
• 叙述例子：第 3 节用 Lena 说明流程。同意内容是七天内、至多 500 欧元的任意航空公司；符合规则的航空公司付款可完成，电子产品零售商等无关商户不会得到可用凭证。这是例子，不是测量。
• 图：Figure 1 的图注为端到端流程，含同意阶段与执行阶段。正文未给出图中的数值。

主结果

论文没有结果表，也没有可对应到表或图的测量数字，因此不列表。

• 作者称符合规则的航空公司付款会成功，允许集合外的商户不会产生可用凭证。论文未给出成功次数或失败次数。
• 作者称执行阶段不再回调约束组件，发卡行按普通已认证卡支付校验认证值。论文未报告延迟、依赖失败或授权结果。
• 第 4 节列出零集成处理、双方不共享凭证方、控制留在发卡行、在凭证生成点执行、线上与普通已认证卡支付无法区分。这些是设计主张，不是实验结果。

其他消融与分析

• 论文未报告消融、参数分析、重复实验或人工评估。
• 论文未报告负面结果或失败案例的测量。

作者指出的局限与后续方向

论文未专门讨论局限。第 5 节重述方法：持卡人批准一次规则，发卡行组件记录它，仅在后续支付符合规则时生成认证值，支付走标准卡通道并由发卡行按通常方式校验，执行时无额外依赖，生态其余部分不变。该节没有把某项写成不足或未来工作。全文也没有 Limitations、Discussion 或 Future Work。

实验覆盖范围

• 全文为方法说明（第 1–5 节与 Figure 1），未报告实验运行。
• 未报告被测模型、基准、指标、样本量或重复次数。
• 第 3 节的 Lena、500 欧元与七天窗口用于说明同意内容，不是评测样本。
• 引言与第 2 节讨论 Google AP2、Mastercard Agent Pay、Visa Intelligent Commerce 以及 Mastercard 在交易时用引用换取 cryptogram；作者未报告自己运行这些系统。
• 第 3 节把保证写成：允许集合外的商户不会被创建有效认证值，因而系统内不形成可支付凭证。论文未报告对该保证的测试。

Issuer-Sovereign Agentic Payments 把智能体消费限额留在发卡行认证步骤里，而不是在扣款时依赖银行外的 credential provider。

• 要管的缺口：用户可以事先授权、支付时不在场。作者称现有做法把范围检查放在网络或行外凭证方，cryptogram 也在那时生成。承担损失风险的发卡行要到最终授权才进来，而且面对的往往是已经形成的凭证。
• 做法：发卡行认证系统内的约束组件，在持卡人通过挑战后只记录上限、允许商户和时间窗，并返回引用。此时没有 CAVV、AAV，也没有可付款凭证。需要时规则可以是签名对象，用于发现事后改动，并在争议中证明已批准规则。
• 付款时：购物智能体交出的是事先 token 化得到的 DPAN 加上该引用。约束组件核对商户、金额和时间窗，通过才生成覆盖该商户的认证值。作者称检查与生成是同一步。之后网络把 DPAN 还原为 PAN，发卡行用自己的密钥校验认证值，不再回调约束组件。网络 token cryptogram 与认证值是两件不同的东西，本方法只涉及后者。
• 规则范围：一条同意可以覆盖多笔支付，每笔对照规则的当前状态。作者称同一检查点还可带上商户类别、单笔金额、支付次数或币种。作者称允许集合外的商户在系统内得不到可支付凭证；认证值走标准字段，处理方按普通已认证卡支付对待。
• 作者的结论：控制回到已经承担损失风险的一方，执行时没有额外依赖，其余生态保持不变。这些是方法主张。论文没有实验或数字结果。