# 国内外银行及金融机构智能生态互联实践研究报告

> **版本：** v1.9  
> **更新日期：** 2026 年 10 月 29 日  
> **研究基准日：** 2026 年 10 月 27 日（关键事实复核截至 2026 年 10 月 29 日）  
> **研究范围：** 中国及海外商业银行、卡组织、支付网络、互联网金融公司、金融科技与金融基础设施平台  
> **核心主题：** 开放银行、API/SDK/H5、BaaS、金融数据互联、MCP/A2A、智能体支付、可信交易与跨机构协作

## 一、执行摘要

本报告调研开放银行 API、嵌入式金融、金融数据互联、面向智能体（Agent）的工具开放、智能体支付与跨机构协作，归纳共性实践范式与趋势，并提出商业银行内外互联智能生态的规划建设建议。案例细节与信源统一列入附录 A。

**核心结论：公开案例显示，部分领先金融机构与支付网络正在把“开放金融 API”拓展为“开放可供 AI Agent 调用的金融能力”，并探索“具备独立身份、委托授权、交易意图和责任规则的可信智能体协作与交易网络”。** 三者是叠加关系而非替代关系，也不代表所有机构按同一顺序演进。能力发现、业务数据读取与资金执行正在分层开放；存量金融 API 与确定性业务系统仍是执行底座。

### 1.1 金融生态互联的三类叠加实践

```mermaid
flowchart BT
    A["基础层：API 化开放银行<br/>API / SDK / H5 / 嵌入式金融 / 数据共享<br/>成熟生产底座"]
    B["面向智能体的金融能力<br/>MCP / Skills / 工具目录 / 协议网关<br/>2025—2026 年快速发展，以文档、查询和受控写操作为主"]
    C["智能体协作与交易网络<br/>Agent 身份 / 委托授权 / 交易意图 / 责任规则<br/>交易侧：试点与部分生产；协作侧：早期探索"]
    A -->|"叠加，不替代"| B
    B -->|"叠加，不替代"| C
```

### 1.2 六项主要发现

1. **对外开放 MCP 的金融机构已有官方可核实案例，银行侧以准入制、查询为主。** 银行类有 HSBC（企业客户查询类工具）、Danske Bank（目录发现加本地代理，生产环境只允许 GET）和 Fifth Third Newline（以 MCP 与 Skills 支持 API 接入）；金融科技类有 Mercury、Qonto 等，它们开放了受控写操作。
2. **“智能体协议入口 → 既有金融 API”是最清晰的技术范式。** 机构新增的是适配与治理职责，无需把核心业务系统改写为 MCP Server。
3. **接入形态多样，安全控制是强制项，部署形态不是。** 远程 OAuth 直连、本地安全代理、安全 SDK 与托管聚合平台并存。
4. **开放能力不等于开放权限，发起金融动作不等于拥有最终执行权。** Mercury 的付款须在原平台审批，Qonto 的审批和强客户认证回到原渠道，Blend 对锁价、征信查询等动作另设门控；国内交通银行“银企付”同样以付款方在企业网银确认订单作为对公付款授权。另据媒体报道†，美国多家银行正在发现或限制凭客户凭据或模拟界面接入的未授权 Agent。Wells Fargo 新版在线访问协议（2026-11-24 生效）只说明客户对其授权的 AI Agent 的交易负责，不能证明银行实施了限制。两类动向的共性是授权与责任边界更趋明确，而不是“一律禁止”或“MCP 是唯一合法方式”。
5. **卡组织、支付网络和国内支付机构正在构建可信智能体交易基础设施。** 中国银联 APOP、Google AP2（已宣布捐赠 FIDO 联盟）、Mastercard Agent Pay、American Express、蚂蚁国际、支付宝等分别探索 Agent 身份、交易意图与支付授权。
6. **国内商业银行的开放均可见 API、部分同时提供 SDK 或 H5，智能体入口尚未见于银行官方材料。** 本轮核实了工、农、中、交、招、民生、浦发七家银行的官方材料（建行官方页面未能打开，标“待核”）。七家的材料均可见 API 开放，其中工、农、中三行明示同时提供 SDK 与 H5（材料未说明三者主次），其余各行的接入形态与开放能力以 3.4.1 表所示为准；官方材料可见的控制方式包括应用方准入、客户逐项授权、证书与签名，各行实现不一。截至 2026-10-29，本报告在上述银行官网、已能加载的开放平台页面及公开网络中未检索到其对外开放金融业务 MCP 服务的官方材料，这一结论不等于“国内银行没有 MCP”。国内已核的 MCP 开放样本来自卡组织：中国银联 2025 年 7 月上线 MCP 集市。银联与 15 家银行推出的 AI 智能体银行卡属于产品与权益层面的合作。跨银行 Agent-to-Agent（A2A）自主协作在国内外都缺乏充分的公开生产证据。

> **关键界定：** “外部 Agent 可以调用银行工具”不等于“银行内部自主 Agent 已通过 A2A 对外开放”；“开发文档 MCP”也不等于“开放真实金融业务”。本报告分别评价。

## 二、研究范围与评价方法

| 维度 | 覆盖对象 | 研究重点 |
|---|---|---|
| 国内商业银行 | 国有大行（工、农、中、建、交）与股份制银行（招商、民生、浦发） | 开放平台、准入与安全方式、场景生态、智能体入口 |
| 海外商业银行 | 美欧、英国、新加坡及亚洲银行 | MCP 服务、API 产品化、企业司库连接 |
| 卡组织与支付网络 | 中国银联、Visa、Mastercard、American Express | 可信 Agent、交易授权、跨平台互操作 |
| 互联网金融与支付 | 支付宝、蚂蚁国际、PayPal、Stripe、Adyen | Agent Commerce、支付工具、生态平台 |
| 金融科技基础设施 | Mercury、Qonto、Plaid、Wise、Blend、Coinbase、Circle | 金融数据共享、BaaS、MCP、机器支付 |

**成熟度口径：** 生产/正式服务（官方明确提供真实业务服务）；受限开放/Beta（限客户、功能或环境）；试点/验证（白名单、沙箱或受控验证）；框架/发布（公开协议或方案，不代表已投产）；内部实践（不等同于对外开放）。成熟度按**具体能力 × 授权边界 × 实际环境**判定，不对整家机构或整类形态统一定级。准入受限与生产或沙箱环境是两个维度：官方未说明环境的，环境一项按“未说明”处理。

**证据口径：** 优先依据机构官网、官方开发者文档、发布公告与监管原文；媒体报道单独标示。附录 A 逐项记录来源与核验状态，未能取得一手材料的标“待核”。**待核条目只作方向示例，正文中以 † 标注，不单独支撑结论；支持度评级只计已核条目。** 媒体报道按待核处理，正文写作“据……报道†”。动态开发文档只证明核验当日的状态；上线公告只证明发布时点的情况。主体区分**银行**、**卡组织与支付网络**与**非银金融科技**：后两者的实践可作参照，不能直接外推为银行的已有做法。未在公开材料中看到某项控制，不推断机构内部没有该控制；国外案例也不能作为国内金融标准的替代性合规证明。

## 三、互联形态与代表实践

### 3.1 七类互联形态

七类形态是可组合的观察维度，不是同一尺度上的成熟度阶梯：P1—P3 按开放对象划分，P4—P7 按接入与协作方式划分，同一案例可归入多类（如 Blend 以 MCP 工具开放承载信贷业务能力）。“所属层”一列对应 1.1 的三类叠加实践。

| 形态 | 划分维度 | 所属层 | 开放对象 | 典型技术 | 代表案例（主体） | 公开实践状态 |
|---|---|---|---|---|---|---|
| **P1 API 能力开放** | 开放对象 | 基础层 | 账户、支付、融资等业务接口 | REST、H2H、SWIFT | 工行开放平台、交行开放银行（银行）；DBS RAPID（银行） | 成熟生产 |
| **P2 嵌入式金融** | 开放对象 | 基础层 | 完整金融产品与流程 | BaaS API、SDK、H5 | Wise Platform（非银）；交行Ⅱ、Ⅲ类账户 API、民生场景金融（银行） | 生产服务 |
| **P3 金融数据互联** | 开放对象 | 基础层 | 用户授权数据、验证结果 | OAuth、Open Banking API、FDX | Plaid†、Tink†、香港 IADS† | 方向示例；按市场与机制差异较大 |
| **P4 Agent 工具开放** | 接入方式 | 智能体能力层 | 开发文档、API 目录、受控业务工具 | MCP、Skills、工具目录 | J.P. Morgan（文档）、Danske、HSBC（银行）；Mercury、Qonto（非银）；银联 MCP 集市（卡组织） | 快速发展；按开放层次分级 |
| **P5 智能业务能力开放** | 接入方式 | 智能体能力层 | 信贷、分析、流程服务 | MCP、领域智能体 | Blend Autopilot MCP（非银） | 发展中 |
| **P6 智能体协作网络** | 协作方式 | 协作与交易层 | 跨主体身份、任务、委托 | Agent-to-Agent、KYA | 暂无充分公开的跨银行生产案例 | 早期探索 |
| **P7 智能体交易网络** | 协作方式 | 协作与交易层 | 可信购买、支付授权与结算 | AP2、APOP、AMP、Agent Pay、x402 | 银联、Mastercard（卡组织）；蚂蚁国际（非银）；Visa† | 框架发布、试点与部分生产并存 |

### 3.2 Agent 能力开放的分层样本

| 开放层次 | 代表样本（已核，括号内为主体） | 共性 |
|---|---|---|
| 文档与服务发现 | J.P. Morgan Payments 开发者 MCP（银行）、Mastercard Agent Toolkit（卡组织）、Danske 托管 MCP（银行） | 只检索文档、目录与接入指南，不执行业务 API |
| 运维与开发辅助 | Plaid Dashboard MCP（生产诊断与用量）、Plaid 本地开发 MCP（沙箱）（非银） | 运维与开发能力先 Agent 化，不等于开放用户账户数据 |
| 生态工具市场 | 银联 MCP 集市（卡组织；汇聚银联、腾讯、百度等的金融领域 MCP 服务，示例为商户入网、营销信息获取） | 面向金融机构与服务商的工具开放，不涉及商业银行账户或支付执行 |
| 受限业务查询 | HSBC MCP（余额、交易、汇率、付款状态；环境未说明）、Danske 本地 Proxy（生产仅 GET）（银行） | 沿用原 API 准入、证书与 OAuth；不提供发起付款的工具 |
| 受控写操作 | Mercury（付款与转账申请须在 Mercury 审批）、Qonto（不提供 SEPA 对外转账，审批与强认证回到原渠道）（非银） | 工具集刻意窄于完整 API，低风险写操作与资金执行分开授权 |
| 业务流程能力 | Blend Autopilot MCP（锁价、征信查询、披露交付等动作在机构启用前保持门控）（非银） | 高风险动作单独准入 |

内部平台不可冒充对外案例。PayPal 披露的内部 MCP Hub 按权限和任务语义动态发现工具，对银行工具治理有参考价值，但它是内部实践。

### 3.3 智能体支付与可信交易

| 机制类别 | 代表实践 | 状态要点 |
|---|---|---|
| 交易意图与授权证据 | Google AP2 v0.2（Checkout Mandate、Payment Mandate；含用户在场与不在场模式）；中国银联 APOP（身份、意图、过程信任）；American Express Intent Intelligence | AP2 2026-04-28 宣布捐赠 FIDO 联盟；APOP 2026-04-02 发布；Amex 框架 2026-10-13 发布，经 ACE 开发者工具包提供（经转载核对） |
| Agent 身份与凭据 | Mastercard Agent Pay（Agentic Tokens，Agent 须注册验证）；蚂蚁国际 KYA；Visa Intelligent Commerce / Trusted Agent Protocol† | KYA 与 Visa、Mastercard 的互操作合作处于启动阶段 |
| 商户与钱包连接 | Adyen Agentic（美国企业商户限量开放）；蚂蚁国际 AMP（首期 10 家钱包、7 家收单机构）；PayPal Agent Ready†、Stripe† | 指向减少商户、钱包与 Agent 之间的点对点集成（本报告判断，见 4.6） |
| AI 服务计费与机器支付 | 支付宝 AI 付（Agent Pay、Vibe Pay、Skill Pay、Machine Pay、Token Pay）；Coinbase x402；Circle Agent Stack† | API、Skill 与模型资源成为可计费的数字产品；链上支付仅作海外范式观察 |
| 事后保障 | 蚂蚁国际 AgentSafePay（企业承诺的资金保障，条款与理赔条件未公开） | 企业产品承诺，不是监管兜底，也不能替代事前、事中控制 |

**国内实践：** 中国银联 2026 年 7 月公告与 15 家商业银行合作推出 AI 智能体银行卡，平安、浦发、交通等已发卡，其余陆续推出；同时与银行和商户推进“一键智能支付”试点。这说明国内银行已经参与智能体交易生态。公告内容属于产品与权益合作，本报告不据此推断这些银行已对外开放统一的 MCP 或支付接口。

**术语区分：** 支付语境中的 A2A 常指账户对账户（Account-to-Account），不同于 Agent-to-Agent；MCP 解决 Agent 对工具与资源的发现和调用；AP2、APOP、AMP、Agent Pay、x402 等协议与网络机制分别处理交易意图、授权、凭据和结算。它们可在同一业务链路中协同，不能互相替代。缩写全称见附录 B。

### 3.4 国内开放银行与双向互联

#### 3.4.1 八家银行样本

下表只写官方材料所示内容；页面未展示的写“未展示”，不推断为“没有”。核验日期均为 2026-10-29。

| 银行 | 官方材料所示的开放形态与能力 | 准入、授权与安全方式（材料所示） | 证据性质 |
|---|---|---|---|
| 工商银行 | “互联网金融开放平台”提供账户管理、资金结算、员工薪资、商户收单、投资理财、网络融资、跨境财资等 API 服务，支持 API 对接或 H5、SDK 嵌入，并提供 API 文档、SDK 与开发指南 | 平台提供在线身份认证服务，满足合作方对客户进行身份核实和数字签名的需要；接口级签名细节未展示 | 现行平台首页 |
| 农业银行 | 开放银行平台全面对外服务，综合运用 API、SDK、H5，开放用户认证、账户服务、支付结算、信用卡、财富与融资、信息服务六类产品 | 合作方系统统一接入，配套业务管理体系、开放接口规范与安全风控措施；具体机制未展示 | 2020 年 1 月官网公告（2019 年 8 月起非公开试点），当前服务清单未核 |
| 中国银行 | 开放银行以 API、SDK、H5 与应用方合作，对公客户可经应用方一站式办理金融服务 | 企业客户在企业网银中选定授权的应用方、账户、权限范围与到期日，并以数字安全证书确认；银行处理应用方交易指令前须确认其在授权范围内 | 现行客户授权协议（2023-08-02 生效） |
| 建设银行 | 检索摘要显示“开放银行管理平台”以标准 SDK、API 发布账户开立、结算、投资理财等服务 | 未能核实 | **待核**：官方页面本次无法打开，不计入研判 |
| 交通银行 | 交银金融网“开放银行”栏目列出Ⅱ、Ⅲ类账户 API 全流程服务、资金存管、收单支付、银企付、信用付（H5）、快易付、进口信用证、跨境电商、银证转账等产品 | “银企付”以“订单通知 API + 企业网银付款”方式运作，付款方在企业网银确认订单即构成对公付款授权 | 现行官网栏目 |
| 招商银行 | 掌上生活开放平台为合作方提供文档、SDK 与在线测试，以 API 和客户端协议两种方式提供服务；另设招商银行 Open API 平台 | 合作方提交申请，取得合作方编号（mid）与应用号（aid），并与平台交换 SM2 公钥；平台按 mid、aid 开通接口权限；每次请求带时间戳、随机串与签名 | 现行接入指南；Open API 平台内容需脚本加载，未核 |
| 民生银行 | 官网将开放银行概括为三种模式：以 API、H5 把金融产品嵌入行业场景（“走出去”），引入出行、导航、财税等非金融服务（“引进来”），与合作方共建行业云 | 企业标准 Q/CMBC 003—2022 规定：接口接入层先完成认证鉴权、加密解密、授权校验、越权检查等安全管控，再转发集成层；接口分 A1、A2、A3 三级；签名验签与报文加解密使用国家密码管理部门认可的国产密码算法 | 现行官网说明与公开企业标准 |
| 浦发银行 | 2018 年 7 月发布“API Bank 无界开放银行”，以 API 把金融服务嵌入合作方平台，自述发布时已与 46 家企业合作；API 开放平台门户现行 | 门户内容需脚本加载，未核 | 官网发布稿（历史时点）；门户内容未核 |

#### 3.4.2 研判

1. **均可见 API 开放，其余形态与能力因行而异。** 七家已核银行的材料均可见 API 开放；农、中两行把 API、SDK、H5 并列，招行以 API 和客户端协议两种方式提供服务，材料未说明主次。工、农、中三行明示同时提供 SDK 与 H5；交行、民生的材料可见 H5；招行掌上生活可见 SDK 与客户端协议；浦发的发布稿只涉及 API。开放能力方面，工、农两行的材料明示账户、支付结算与融资类能力；交行列有Ⅱ、Ⅲ类账户、收单支付，以及信用付、进口信用证等融资相关产品；其余各行以 3.4.1 表所示为准。P1、P2 两类形态在国内已有多家银行的官方证据。样本按管理员指定的范围选取，不是随机抽样，不能据此推出全行业覆盖率或成熟度排名；农行、浦发的证据为发布时点材料，只证明当时的情况。
2. **准入与“执行权回到原渠道”已有国内做法。** 中行要求企业在网银中逐项选定授权范围与到期日并用证书确认，交行“银企付”把付款授权留在企业网银，招行掌上生活以 SM2 公钥交换和逐次签名控制接入，民生企标把安全检查放在转发集成层之前。这些做法与 JR/T 0185—2020 的分级与认证要求一致（见 6.3），说明“开放能力不等于开放权限”在国内传统开放银行中已有实践基础。各行实现并不统一，不能认定七家采用同一种方式。
3. **双向互联在国内也有依据，但范围有限。** 民生银行明确区分金融服务输出与外部非金融服务引入。这只能证明银行渠道在消费外部非金融服务，不能证明银行已消费外部金融数据，更不能证明存在跨银行 Agent 协作。
4. **智能体入口仍在银行开放平台之外。** 截至 2026-10-29，本报告在七家已核银行的官网、已能加载的开放平台页面及公开网络中，以“MCP”“智能体”“开放平台”等中文关键词检索，未发现其对外开放金融业务 MCP 服务的官方材料。招行 Open API 平台与浦发 API 开放平台门户的内容需脚本加载、未能读取，不在检索覆盖范围内。国内已核的 MCP 开放样本是银联 MCP 集市（卡组织），银行侧参与智能体生态的已核形式是智能体银行卡等产品合作。
5. **对国内路径的推论（本报告判断）。** JR/T 0185—2020 要求账户与资金类接口的应用方以证书或公私钥对双向认证并签名，而通用的 OAuth 直连 MCP 客户端一般不具备这一能力。国内银行引入智能体入口时，较可能的路径是在存量开放平台的边界与签名体系之后增加协议适配，或由客户侧安全 SDK、本地代理承载签名能力，而不是另建一个绕开存量边界的直连入口（见 4.5、7.1）。

据此，传统开放银行样本增加了 P1、P2、T2 的国内旁证，但不计入面向智能体能力的趋势样本，T1 的银行主体评级不因此上调。

#### 3.4.3 海外双向互联

海外实践同样表明生态互联是**双向的**：银行既通过 DBS RAPID（信息、交易与流程三类 API）、CitiConnect API（2021 年新闻稿所述的余额、付款状态、汇率查询与付款发起）等输出能力，也通过 Wise Platform 等外部网络消费跨境支付服务（Wise 列出的合作方含渣打、Morgan Stanley 等，可经 Swift 报文或 API 接入）；Plaid†、Tink†、香港 IADS† 等数据共享机制通常以用户或企业授权为前提。金融 Agent 未来可能更多消费经授权、最小化或可验证处理的结果，而非全部原始数据。

## 四、行业共性范式

### 4.1 范式一：能力发现、业务读取、交易执行分层，而非重建核心系统

Danske、Mercury、Qonto 与 HSBC 的公开边界表明，开放程度可依次从**文档与服务发现 → 受限数据查询 → 授权业务动作 → 独立资金执行**分层推进。本报告据此推断，较稳妥的演进链路是：金融业务能力 → 标准化 API → 安全治理 → 面向 Agent 的协议适配。MCP Server、A2A Agent 或传统 API 网关提供不同入口，账户、支付、清算与风控的确定性执行仍由银行业务系统承担。

### 4.2 范式二：从 API 数量转向能力产品化和目录治理

Agent 关注的是“能完成什么任务、按什么顺序调用、有什么权限和副作用、失败后如何恢复”。因此，工具目录应升级为**业务能力目录**，登记风险分类、授权主体、工具 Schema、副作用、幂等语义、审批要求、版本与审计策略。规模扩大后，应以“先按权限筛选、再按任务语义发现”的方式控制暴露给模型的工具范围，不把全部 API Schema 注入上下文。PayPal 内部 MCP Hub 是这一做法的公开样本（内部实践）：先按权限过滤、再按语义检索，执行时重新校验策略，并为每次操作留存审计事件。由 OpenAPI 文档自动生成 MCP 工具可以减少封装工作量，但无法自动生成委托、审批、幂等与恢复语义，生成结果仍须逐项评审后才能上架。

### 4.3 范式三：主体、权限与交易意图三重信任

| 信任维度 | 需证明的问题 | 代表实践 |
|---|---|---|
| 主体可信 | 机构、用户、Agent 分别是谁 | Mastercard Agent Pay、蚂蚁国际 KYA、Visa Trusted Agent Protocol† |
| 权限可信 | Agent 是否能执行指定动作 | Mercury OAuth Scope、Danske API 准入、中行客户授权协议 |
| 意图可信 | 本次交易是否在授权边界内 | AP2 Mandate、银联 APOP、Amex Intent Intelligence |

Agent 身份不替代企业或自然人身份，而是额外的委托与执行主体，须有可审计的授权链。签名和凭证能证明数据与授权链可验证，但不能证明模型正确理解了用户需求，因此仍需事中规则校验与高风险确认。

### 4.4 范式四：业务发起权与最终执行权分离，形成事前—事中—事后闭环

付款申请仍受审批约束，卡组织引入受限凭据与授权条件，信贷类高风险动作单独门控。这不等于行业普遍禁止 Agent 自动付款；更准确的共性是：**资金执行权限来源于可验证的授权、明确的范围、确定性风险规则及审计证据**。事前核实身份、委托、金额与意图；事中以业务规则、限额、风控和高风险审批防止提示词注入或意图偏差；事后保留交易与审批证据，按适用规则处理争议与赔付。“承诺赔付”不能替代事前、事中控制。

### 4.5 范式五：直连、SDK 与本地代理长期共存

| 形态 | 代表案例 | 适用优势 |
|---|---|---|
| 远程直连 MCP | HSBC、Mercury、Qonto | 简化标准客户端接入 |
| 本地安全代理 | Danske | 在客户侧持有证书与密钥，沿用原 API 准入 |
| 传统 API + 安全 SDK | 招行掌上生活（合作方与平台交换 SM2 公钥、逐次签名；材料未说明接口的安全等级）；工行（提供 SDK，并提供满足数字签名需要的在线身份认证服务，接口级签名细节未展示，仅作旁证） | 沿用存量准入与签名体系；A2 接口的认证与签名要求见 6.3 |
| 跨网络交易接入 | Mastercard Agent Pay、蚂蚁国际 AMP、Visa† | 跨生态支付与身份互操作 |

**设计启示：强制安全控制，不强制唯一部署形态。** 底层 API 要求客户端证书、持钥签名时，外部 AI 客户端须经安全 SDK、可扩展 HTTP 传输、企业本地代理或受控运行环境等某种受控实现具备该能力，但不必然要求单独部署一台适配器（Adapter）。

### 4.6 范式六：平台竞争走向跨生态互操作

Adyen Agentic 提供面向 Agent 的模块化 API，蚂蚁国际 AMP 首期连接 10 家钱包与 7 家收单机构，Mastercard Agent Pay 要求 Agent 注册验证并使用 Agentic Tokens 代用户支付（PayPal Agent Ready† 方向相同）。本报告据此判断，这些机制的共同指向是减少商户、Agent、钱包和收单机构之间的点对点集成；长期竞争力不仅取决于单个 Agent 的能力，也取决于金融工具能否被不同 Agent **安全发现、授权和组合使用**。

## 五、两至三年趋势研判

**评级口径：** “较强”指已有 3 家以上持牌或大型机构的官方生产或受限开放证据；“中”指至少 2 家官方发布，但以框架、Beta 或试点为主；“弱”指仅有少量试点、倡议或媒体报道，或没有已核样本。评级按全部主体计算，银行主体单独注明。“大型机构”未设量化判准，本报告把已对外提供生产或受限服务的 Mercury、Qonto、Blend 等金融科技公司计入；T1、T2 的“较强”以此为前提（见第九章第 4 条）。只计附录 A 中经官方页面核对的“已核”条目；“已核（转载）”“待核”及状态中注明待核的部分不计；官方未说明环境的样本不计入“生产或受限开放”。评级反映当前公开案例对方向的支持度，不是预测置信度。

| 趋势 | 已观察实践 | 研判 | 支持度（计入样本） |
|---|---|---|---|
| T1 开放 API 向面向智能体演进 | 银行与金融科技已开放 MCP、Skills 与工具目录 | 开放平台增加智能体入口 | 较强（Danske、Mercury、Qonto、Blend）；银行主体：中（Danske、Newline）；国内银行暂无已核样本 |
| T2 能力发现与交易执行分层 | Danske、Mercury、Qonto；国内中行、交行、招行的传统 API 准入作旁证 | 发现易开放，敏感 API 保留强准入 | 较强（Danske、Mercury、Qonto；HSBC 环境未说明，不计入） |
| T3 Agent 身份与委托凭证 | KYA、Mastercard Agent Pay（Visa TAP†） | 多方探索，跨网络互认与法律效力待验证 | 中（蚂蚁国际、Mastercard） |
| T4 交易意图与责任规则 | AP2、APOP（Amex 经转载核对，不计入） | 可验证意图与争议证据受重视，统一标准尚未形成 | 中（Google、银联） |
| T5 可组合智能业务能力 | Blend、Mercury 付款申请 | 向分析、对账、业务准备与受控制单扩展，授信决策权不随之下放 | 中（Blend、Mercury） |
| T6 跨机构 Agent-to-Agent 协作 | 试点与倡议为主 | 将出现更多试点，尚非成熟生产范式 | 弱（无已核样本） |
| T7 工具治理平台工程化 | PayPal 内部 Hub | 准入、目录、权限、评测、可观测统一建设 | 弱（已核官方样本仅一家，且为内部实践） |
| T8 机器微支付 | x402、支付宝 Machine Pay（Circle†） | 按次或按量计费的服务收费模式扩展 | 中（Coinbase、支付宝，均为发布或按条件开通） |

## 六、新动向与监管、标准提示

### 6.1 授权式服务开放与未授权 Agent 接入并行分化

据 Axios 2026 年 10 月 22 日报道†（单一原始信源，多家媒体转述），JPMorgan、Bank of America、Morgan Stanley、Wells Fargo、Citi 等美国金融机构正在发现或限制未经授权、使用客户凭据或模拟界面接入的第三方 AI Agent；各机构的具体政策以其官方表态为准。Wells Fargo 新版在线访问协议标注于 **2026 年 11 月 24 日**生效，其中写明客户对授权代表及其 AI Agent 的交易负责、允许 AI Agent 访问可能影响安全程序的风险由客户承担；截至基准日尚未生效，法律效果须结合适用法律判断，且该协议只说明责任划分。

**归纳（本报告判断）：** 市场不是在“开放”与“封禁”之间二选一，而是在区分有明确身份和权限的受控互联，与凭用户密码或屏幕模拟的不可控接入。

### 6.2 监管与治理坐标

| 地区及资料 | 性质 | 对生态互联的提示 |
|---|---|---|
| **中国：《关于银行业保险业人工智能安全开发应用的指导意见》（金发〔2026〕8号，2026-06-18，国家金融监督管理总局）** | 监管指导意见 | 本报告只核对了标题、文号与日期，条文未核；正文不据此推导具体义务，各行须以正式条文为准评估智能体外部接入的治理要求 |
| **新加坡：MAS《Safeguards for Agentic Finance at Runtime》（2026-07-03）** | 行业在 MAS BuildFin.ai 倡议下共同形成的信息文件，提出治理框架 | 强化运行时身份与委托、动作检查与审计；不是强制技术法规 |
| **美国：SR 26-2（2026-04-17）** | 美联储、OCC、FDIC 修订的模型风险管理指导，替代 SR 11-7 与 SR 21-8 | 正文明确生成式 AI 与智能体 AI 模型不在本指导范围内；不能写成 Agentic AI 专项监管规则 |
| **KYA 等行业倡议** | 行业实践 | 不应把行业倡议视为具有法定强制力的统一标准 |

### 6.3 国内接口安全标准

JR/T 0185—2020《商业银行应用程序接口安全管理规范》（中国人民银行 2020 年发布，金融行业标准）第 6.2 条将接口分为两级：**A2 为资金交易与账户信息查询类**，A1 为与用户个体无直接关联的金融产品和服务信息只读查询类。对 A2 接口，应用方身份认证须使用数字证书或公私钥对进行双向认证（7.2.1、9.2.1），数据交互须使用数字签名保证完整性与不可抵赖性（7.2.2、9.2.2），资金交易类用户认证至少使用双因子（7.2.1）；A1 采用 MAC 校验等手段保证完整性，必要时使用数字签名（9.2.2）。因此，账户余额等只读查询同样属于 A2，不能以“只读”或“由 AI 调用”为由降低控制等级，国外 OAuth 直连 MCP 案例也不能作为国内 A2 接口免签名的依据。

该标准第 8 章给出的部署结构，与本报告 7.1 的分层直接相关：银行应在互联网边界部署防火墙、入侵检测与防护、DDoS 防护等措施；应用程序接口服务层部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务（认证鉴权等也可部署在银行业务层）；服务层与银行业务层之间还应部署防火墙等访问控制措施。也就是说，外部调用统一经互联网边界防护进入接口服务层，再经访问控制进入业务层，任何新协议入口都应纳入这一结构，而不是绕开它。

本报告沿用行业标准的 A1、A2 两级口径。部分银行的内部规范更细，如民生银行企业标准把账户信息查询列为 A2，把资金交易与服务签约单列为 A3，并对 A3 增加经本行渠道的二次认证。实施时应映射到本行更严格的分级，不能以“行业标准只分两级”为由降低本行控制。标准的适用方式还须结合监管要求与本行制度确定。

### 6.4 合规与标准依赖提示

下表只列名称和关注点，不展开条文；适用性须由各行逐项评估。

| 类别 | 依据（名称·年份） | 关注点 |
|---|---|---|
| 个人信息与数据出境 | 《个人信息保护法》（2021）；JR/T 0171—2020《个人金融信息保护技术规范》；《促进和规范数据跨境流动规定》（2024） | 同意与委托处理边界；区分银行授权查询与向模型服务商提供数据；使用境外模型或平台时的出境评估 |
| 网络与数据安全 | 《网络安全法》（2016）；《数据安全法》（2021）；《银行保险机构数据安全管理办法》（2024）；《中国人民银行业务领域数据安全管理办法》（中国人民银行令〔2025〕第 3 号，2025-06-30 施行）；JR/T 0197—2020《金融数据安全 数据安全分级指南》 | 数据分类分级、最小必要、日志与推理结果留存；人民银行办法按其第二条界定的业务领域数据评估适用范围 |
| 第三方与外包 | 《银行保险机构信息科技外包风险监管办法》（2021） | 第三方 Agent、模型与平台服务商的准入、监督与退出 |
| 生成式 AI | 《生成式人工智能服务管理暂行办法》（2023） | 按是否向境内公众提供服务判断适用范围 |
| 密码应用 | 《密码法》（2019 年通过、2020 年施行）；GB/T 39786—2021《信息系统密码应用基本要求》 | 国密算法、签名与密钥管理，密码应用安全性评估 |
| 海外参照 | 欧盟 DORA（2025-01-17 起适用）、欧盟《人工智能法》、美国 CFPB 1033 规则（现状待核） | 第三方 ICT 风险、高风险 AI 义务与数据共享权利，仅作境外业务参照 |

## 七、商业银行智能生态规划建设建议

### 7.1 总体思路与逻辑架构

1. **存量开放平台与 API 网关是唯一的对外网络边界。** MCP、A2A 等新协议服务部署在该边界之后：外部调用先按接口安全等级完成机构与应用准入（A2 调用须完成证书双向认证、验签与防重放），再进入协议处理。银行不在边界之外另建对外入口，也不在 MCP/A2A 侧另建一套准入、证书与密码体系；协议服务仍须按配套约束校验令牌受众与会话归属。这一安排与 JR/T 0185—2020 第 8 章的部署结构一致（见 6.3）。
2. **在边界之内增加智能体治理职责。** 治理职责包括工具与 Agent 注册、能力目录、评测、委托与持续授权、长任务状态和调用链审计。注册、上架、评测与策略管理属于行内控制面，不接受外部管理调用；外部调用方只能看到经授权的目录视图。治理职责与存量 API 安全控制是逻辑分层，可在现有平台上合建，也可分建，不要求采购两套网关。这是本报告的设计建议，未见银行公开披露同类分层实践。
3. **共享能力元数据，分别发布授权视图。** 行内与外部 Agent 使用同一套业务能力元数据，但按调用方类型、机构与授权范围分别发布可见工具，并分区授权与审计。
4. **按用例风险开放。** 开放范围由接口安全等级、数据敏感度、资金影响和决策影响共同决定。

```mermaid
flowchart TB
    X["外部调用方：企业系统 / SaaS / AI Agent 平台 / 合作金融机构"]
    Y["行内员工与行内智能体"]
    subgraph L1["① 统一对外边界：存量开放平台与 API 网关（唯一互联网入口）"]
        E1["网络防护 / 机构与应用准入 / 证书双向认证（A2） / 令牌校验"]
        E2["验签 / 防重放 / 限流 / 按协议方法与工具名访问控制"]
    end
    subgraph L2["② 协议服务区（位于边界之后，不单独对外）"]
        A["API / SDK / H5 路由"]
        B["MCP 服务"]
        C["A2A 等协作协议服务"]
    end
    subgraph L3["③ 业务授权与风控（存量金融 API 安全控制）"]
        F["按主体、资源、动作、委托与交易参数逐次授权 / 风控 / 审计"]
    end
    subgraph L4["④ 确定性业务底座"]
        I["账户 / 支付 / 融资 / 数据服务"]
        K["交易审批 / 核心执行"]
    end
    subgraph GOV["智能体治理控制面（行内，不接受外部管理调用）"]
        G1["能力目录 / 工具与 Agent 注册 / 评测 / 策略"]
        G2["委托与授权状态 / 长任务状态 / 调用链审计"]
    end
    X --> E1
    E1 --> E2
    E2 --> A
    E2 --> B
    E2 --> C
    Y -->|"行内身份认证"| B
    Y --> C
    A --> F
    B --> F
    C --> F
    F --> I
    F -->|"独立授权与确定性校验"| K
    G1 -.->|"发布经审批的目录视图与策略"| E2
    G1 -.-> B
    G2 -.->|"委托有效性"| F
    B -.->|"审计与任务状态"| G2
```

**图的读法：** 实线是业务调用流向，虚线是治理控制面向运行时组件发布策略或接收审计。各组件可以合建或分建，不要求物理上串行，但不得出现绕过①的对外入口，也不得出现绕过③的执行路径。行内调用方不经过互联网边界，但同样须经③授权与风控。

**配套约束：**

- **新增协议处理仍会增加攻击面。** 复用同一边界可以避免旁路入口，但 MCP、A2A 的协议解析、会话与长连接仍是新的处理逻辑。网关应能识别 MCP 的具体方法和工具调用，仅放行某个路径不足以完成工具级授权。会话与长任务的恢复须绑定发起时已认证的调用主体，不得跨主体复用。MCP 官方安全指南还要求 MCP 服务只接受明确签发给自身的令牌（禁止令牌透传），不以会话标识代替身份认证，并对服务端发起的外部请求做出站限制以防服务端请求伪造。
- **签名链不能断。** A2 请求的应用方签名在①验签。协议服务把原始主体、委托证据和参数摘要随请求传递到③，并保留可复验的原始签名报文及其与转换后工具调用、业务参数的对应记录，不得用银行密钥或高权限服务账号代替调用方重新签名，否则会丧失应用方签名提供的不可抵赖性。
- **“应用方”须明确。** 持有证书并与银行签署接入协议的主体（企业客户自建系统或 Agent 平台）是 JR/T 0185 意义上的应用方，承担应用方义务；Agent 作为其下的执行实体另行登记，不改变应用方的责任。
- **客户侧部署是 A2 场景的首选落地方式。** 采用 4.5 所述的客户侧本地代理或安全 SDK 时，MCP 适配运行在客户侧，持钥签名也在客户侧完成，银行侧只暴露存量 API 边界，不新增任何协议入口。
- **合建与分建的取舍。** 在现有网关上增强协议能力，组件少、边界单一，但网关须理解 MCP 方法与会话语义，升级节奏受制于网关平台；独立部署协议服务便于跟进协议演进，但会增加可用性保障和责任交接成本。两种方式都须满足上述约束，由各行按现有平台能力选择。

### 7.2 前置条件与组织治理

**前置条件：**

- **API 资产盘点与安全分级。** 开放前，业务负责人应逐项登记拟向智能体开放的接口，写明对应的数据、调用主体、资金影响和决策影响，并按 JR/T 0185—2020 第 6.2 条及本行更细的分级确定控制等级（见 6.3）。安全部门据此确定各阶段可以开放的上限，不得仅凭 HTTP 方法或“只读”标签判定为低风险。
- **数据分类分级。** 拟由智能体读取的数据应先完成分类分级，并确定哪些数据可以返回原文、哪些只能返回脱敏或汇总结果、哪些不得进入模型上下文。可参照 JR/T 0197—2020、《银行保险机构数据安全管理办法》与《中国人民银行业务领域数据安全管理办法》，适用范围由各行评估。
- **客户与企业授权、委托机制。** 银行应能记录“谁在何时、以何种范围、在多长期限内授权哪个应用方和哪个 Agent”，并为客户提供随时撤销的渠道。撤销应覆盖新调用、排队中的任务和仍可阻止的执行动作。JR/T 0185—2020 第 9.3.2 条已要求按应用方、应用、接口、用户等维度最小授权，取得包含授权有效期的明示同意，并提供关闭服务的渠道；中行客户授权协议在企业网银中逐项选定应用方、账户、权限范围与到期日的做法可作参照。
- **国密与签名能力。** A2 接口的应用方须以数字证书或公私钥对完成双向认证，并对交互数据签名（JR/T 0185—2020 第 7.2、9.2 条）；该标准第 7.1 条还要求所用密码算法、技术及产品符合国家密码管理部门及行业主管部门的要求，第 7.3.4 条要求加密与签名密钥分离、私钥不得写入代码或本地配置文件，并按接口等级设置密钥有效期、定期更新。部分银行的内部规范更明确，例如民生银行企业标准要求证书签名验签和报文加解密使用国家密码管理部门认可的国产密码算法，招行掌上生活开放平台要求合作方与平台交换 SM2 公钥。因此，“具备国密与签名能力”的含义是：银行内部负责密码管理的部门明确各跳通信与业务签名的责任主体，规定密钥生成、托管、轮换、吊销与异常处置的方式，并确保协议适配不会使证书或私钥进入模型上下文或普通日志。密码应用安全性评估等要求按《密码法》与 GB/T 39786—2021 由各行评估适用范围。
- **统一身份体系。** 身份体系应区分机构、应用方、企业经办人、自然人客户与 Agent 五类主体，并记录它们之间的委托关系、资源范围、有效期与撤销方式，使 Agent 的每次调用都能追溯到委托它的企业或自然人。注册 Agent 本身不产生任何业务权限。

**组织治理：** 每个场景应由业务部门指定场景负责人，并由科技、风险、合规、法务与数据部门共同确认开放范围。工具上架、版本变更与退役应经评审；工具描述、参数、权限或副作用发生变化时须重新评审。第三方 Agent 与平台的接入应参照 JR/T 0185—2020 第 9.1 条对应用方的准入审核与身份核验，在合作协议中约定接口范围、信息安全与交易安全责任，并按第 9.4 条在退出时作废其证书与密钥。红队评测与事件响应应明确执行人与复核人，事件处置纳入既有的生产事件流程。

**客户协议：** 客户协议应写明第三方 Agent 接入的授权范围、撤销方式与损失责任划分，并向客户提示资金类交易经第三方发起的风险。中行客户授权协议约定，应用方在授权范围内的操作视为客户本人行为，并提示客户在授权前核实资金类交易；Wells Fargo 新版在线访问协议约定客户对其授权的 AI Agent 的交易负责。两者可作为责任划分条款的参照，具体条款须经法务评估。

### 7.3 分阶段实施路径

| 阶段 | 优先开放能力 | 建议入口 | 准入条件 | 进入下一阶段的门槛 |
|---|---|---|---|---|
| **零：内部先行** | 行内能力目录、知识与开发辅助 | 内部 MCP、工具目录 | 内部权限分区与审计 | 目录治理与评测机制稳定运行，工具上架与退役评审已执行 |
| **一：公开信息与开发者服务** | 产品、利率、网点、开发文档 | 经统一边界的 API、MCP | A1 完整性控制 | 调用与安全事件可监测，工具级访问控制经测试有效 |
| **二：授权数据查询** | 对公余额、交易流水、现金流分析 | 经统一边界的 MCP + 存量 A2 接口，或客户侧 SDK、本地代理 | A2 双向认证与数字签名、企业授权、数据最小化 | 越权、提示词注入、参数篡改、跨主体会话复用与撤权测试通过，撤权在约定时限内生效 |
| **三：智能业务服务与受控写操作** | 单证审核、风险分析、制单与付款申请 | MCP；低权限 A2A 试点 | 沿用阶段二控制（付款申请属资金交易类 A2，用户认证至少双因子）；委托、产物验证、申请幂等、审批不下放、审计恢复 | 结果不明、重复提交与人工接管演练通过；人工复核比例结合风险解释，不以降低比例为单独目标 |
| **四（远期）：跨主体金融协作** | 智能司库、跨机构单证、受限交易 | A2A + 确定性业务 API + 交易信任机制 | 交易意图证据、幂等、对账；取得监管部门对跨机构委托与责任划分的明确意见 | 条件成熟再启动 |

每个用例须单独评估数据、决策与资金影响；前一阶段通过不构成后一阶段的授权，未达门槛时停止扩大范围。单证审核、风险分析与交易建议可能影响重大决策，或涉及投资建议与适当性监管，不能只按“查询—智能服务—协作”的顺序判定风险。

### 7.4 异常处置与安全底线

- **发现不等于授权。** 能力发现不授予执行权限。每次实际调用都应复核主体、资源、委托有效性及交易参数；审批后参数发生变更的，须重新确认。
- **控制链失效时拒绝执行。** 授权、风控或审计任一环节不可用时，敏感操作一律拒绝执行（失败即关闭）。银行应能撤销授权、停用指定 Agent，并由人工接管未完成的任务。
- **结果不明时先查后补。** 核心系统超时后，任务进入“结果待确认”状态，使用原业务流水号查询和对账。只有确认未受理且满足幂等条件时才能重试；无法确认的交由人工处置。已结算的交易按适用的退款、冲正或争议流程处理。
- **回退到确定性渠道。** Agent 链路失效或意图不明确时，回退到网银或 App 中的确定性确认流程。回退时应先查询并接管原业务记录，避免客户重复制单。

### 7.5 度量

度量不只看工具数量。下列指标的口径、阈值和升级责任人应在上线前由场景负责人确定，并与 7.3 的阶段门槛对应。

| 类别 | 指标 | 用途 |
|---|---|---|
| 业务价值 | 机构接入数、有效调用量、交易成功率、单笔成本与业务收益 | 判断开放是否产生实际价值 |
| 安全 | 越权与安全事件数、拒绝或升级人工的比例、安全测试结果 | 判断控制是否有效，作为阶段一、二的门槛依据 |
| 韧性 | 撤权生效时间、恢复时长、重复执行数、未决交易数量与账龄 | 判断异常处置是否可靠，作为阶段二、三的门槛依据 |

## 八、研究结论

**第一，智能生态互联没有取代开放银行和金融 API。** MCP、A2A 新增了工具发现、任务协同和语义交互入口；金融 API、统一身份授权、安全网关、支付与账务核心及审计仍是生产底座。国内七家已核银行的开放实践均可见 API，部分同时提供 SDK 或 H5。

**第二，主要变化是调用主体与协作方式。** 代表个人、企业或机构行动的 Agent 会动态发现并组合业务能力，需要额外治理 Agent 身份、委托范围、交易意图、任务生命周期与责任边界。

**第三，开放能力不等于开放权限。** 目录与文档可以广泛开放，敏感数据受限开放，写操作单独授权，资金执行须有独立的信任证据（见 1.2 第 4 条与 4.4）。

**第四，对商业银行的建议：** 以存量开放平台与 API 网关作为唯一对外边界，在其后增加协议适配与智能体治理职责，不新增绕过边界的入口；内部先行、先读后写、按用例风险分阶段开放；把个人信息、数据安全、第三方合作、生成式 AI 与密码应用合规作为开放前提；跨机构 A2A 协作按远期、低权限试点推进。后续研究重点为 Agent 身份与委托、业务能力目录、交易意图验证与跨机构可信协作。

## 九、少数意见

以下为有依据、经再讨论仍未被本版采纳的不同意见，保留备查。已在本版正文中闭环的意见，处理情况见“更新历史”。

1. **七类形态的表达方式**（核验席、主主持，第 1—3 轮；第二主持，再审第 1 轮）：主张改为“开放对象 × 接入层次”二维表或合并为四类。本版在 3.1 表中增列“划分维度”与“所属层”两列并声明七类可组合、不是成熟度阶梯，未改为二维表或合并。
2. **趋势评级**（第二主持，第 1—3 轮）：主张删除支持度列，只区分“已观察实践”与“研判”。本版保留评级，补充计入样本以便复核，并写明评级是证据支持度而非预测概率。
3. **小样本评级与证据时点**（核验席、主主持，第 3 轮；质疑席，再审第 1 轮）：T3、T4、T5、T8 各只有两家计入样本，处于“中”级下限，两家门槛本身是人为设定的；CitiConnect 的依据为 2021 年新闻稿，只能证明历史实践。本版逐项列出计入样本，P1 已改以工行、交行等现行官方页面为主要依据，但未调整评级门槛。
4. **“大型机构”的判准**（再审第 2 轮，主持综合整理；再审第 3 轮，核验席、质疑席）：评级口径写“持牌或大型机构”，但“大型”没有量化判准。T1 计入的 Blend、Mercury、Qonto 与 T2 计入的 Mercury、Qonto 都是金融科技公司，若只计持牌银行，两项都达不到三家，v1.7 以“不计 Blend 仍有三家”为由维持评级的论证不成立。本版在评级口径中写明金融科技公司按“大型机构”计入、T1 与 T2 的“较强”以此为前提，T1 另列银行主体评级为“中”；未采纳的是为“大型”设定量化门槛，因为现有公开材料不足以统一衡量各主体规模。

## 附录 A 案例证据与信源

核验状态：“已核”指主持人于 2026-10-28 或 2026-10-29 打开官方页面核对了本报告所用的表述；“已核（转载）”指官方页面未能加载、经发布稿转载核对，可在正文作事实引用，但不计入支持度评级；“待核”指未能取得一手材料，只作方向示例（正文标 †），不单独支撑结论，也不计入支持度评级。状态中含“待核”或“待复核”字样的（如“沿用 v1.1，待复核”“已核（范围待核）”“条文待核”“媒体，待核”），所注明的待核部分一律按待核处理。

| # | 机构/资料 | 本报告所用要点 | 状态 | 来源 |
|---|---|---|---|---|
| 1 | HSBC MCP | 5 个工具：余额、交易、汇率、付款状态查询与连通检查；准入制、OAuth；未筛选的交易查询须带 `confirmed: true` 再次调用（调用确认参数，非用户授权）；无付款发起工具；页面未说明生产/沙箱（环境一项不计入评级） | 已核 | <https://interact.hsbc.com/developer/mcp/> |
| 2 | Danske Bank MCP | 托管服务只读、只做目录发现；本地 Proxy 的 `call_endpoint` 调用 mock/sandbox/live，生产仅 GET，需客户证书与 OAuth | 已核 | <https://developers.danskebank.com/premium-apis/mcp-service> |
| 3 | Mercury MCP | 付款与转账申请须在 Mercury 审批；分类与备注修改即时生效；OAuth 动态注册与 PKCE（S256） | 已核 | <https://docs.mercury.com/docs/connecting-mercury-mcp> |
| 4 | Qonto MCP | 不提供 SEPA 对外转账与国际汇款；多笔转账申请由审批人用 SCA 在原渠道签署 | 已核 | <https://docs.qonto.com/mcp/capabilities> |
| 5 | Fifth Third Newline | 2025 年 12 月引入 MCP，2026-04-13 推出 Skills；用于简化 API 集成与开发；具体业务工具与生产权限未见公开 | 已核（范围待核） | <https://ir.53.com/news/news-details/2026/Fifth-Thirds-Newline-Extends-MCP-Server-Capabilities-with-Skills/default.aspx> |
| 6 | Blend Autopilot MCP | 2026-05-04 发布；锁价、征信查询、披露交付等动作在机构启用前保持门控 | 已核 | <https://blend.com/company/newsroom/blend-launches-autopilot-mcp-server-opening-lending-platform-fi-built-ai-agents/> |
| 7 | Plaid MCP | Dashboard MCP 仅用于生产诊断与分析；本地工具包用于沙箱与文档 | 已核 | <https://plaid.com/docs/resources/mcp/> |
| 8 | Mastercard Agent Toolkit | 服务发现、文档与接入指南，未见执行交易的工具 | 已核 | <https://github.com/Mastercard/developers-agent-toolkit> |
| 9 | J.P. Morgan Payments 开发者 MCP | 三个工具：读取、搜索开发者文档与查找相关页面；未见执行支付 API | 已核（2026-10-29，原链接已失效，改用现行页面） | <https://developer.payments.jpmorgan.com/resources/ai-solutions/capabilities/mcp/overview> |
| 10 | Griffin MCP | 本地 MCP Server，限沙箱 | 沿用 v1.1，待复核 | <https://github.com/griffinbank/griffin-mcp-server> |
| 11 | Ramp MCP | 业务 MCP 与开发者文档 MCP 分立 | 待核（页面未能读取） | <https://docs.ramp.com/developer-api/v1/guides/ramp-mcp-remote> |
| 12 | PayPal 内部 MCP Hub | 2026-10-08 技术博客：面向员工的内部 Hub；认证后上架、先按权限过滤再语义发现、执行时重新校验、逐操作审计 | 已核（2026-10-29） | <https://developer.paypal.com/community/blog/One_connection_2000_tools/> |
| 13 | Visa Intelligent Commerce / MCP | Agent 支付生态与开发者 MCP | 沿用 v1.1，待复核 | <https://developer.visa.com/mcp-docs> |
| 14 | 中国银联 智能体银行卡、APOP/AVOP | 2026-07-20 公告：与 15 家银行推出 AI 智能体银行卡，平安、浦发、交通等已发卡；APOP 于 2026-04-02 发布；“一键智能支付”试点 | 已核 | <https://www.unionpay.com/upowhtml/cn/templates/newInfo-nosub/7885004da382485e8bde5a0ba000fdd3/20260720094703.html> |
| 15 | 中国银联 MCP 集市 | 2025-07-28 公告：正式上线银联 MCP 集市，汇聚银联、腾讯、百度等多方金融领域 MCP 服务，支持金融机构、支付服务商、科技企业选用；示例为对话中快速商户入网、营销信息获取；首批服务已开放对接 | 已核（2026-10-29） | <https://cn.unionpay.com/upowhtml/cn/templates/newInfo-nosub/7885004da382485e8bde5a0ba000fdd3/20250728101955.html> |
| 16 | Google AP2 | v0.2 定义 Checkout Mandate 与 Payment Mandate，含用户在场与不在场模式；2026-04-28 宣布捐赠 FIDO 联盟 | 已核 | <https://ap2-protocol.org/ap2/specification/>；<https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/> |
| 17 | American Express Intent Intelligence | 2026-10-13 发布的框架，经 ACE 开发者工具包提供，用于在 Agent 购买前获取并验证授权意图 | 已核（转载；不计入评级） | <https://www.americanexpress.com/en-us/newsroom/articles/innovation/intent-intelligence-framework-agentic-commerce.html> |
| 18 | 蚂蚁国际 AFA/KYA/AgentSafePay/AMP | 2026-09-18 公告；产品于 2026 年秋冬陆续推出；AgentSafePay 称“100% 资金保障”，未公开条款；AMP 首期 10 家钱包、7 家收单机构；KYA 与 Visa、Mastercard 合作已启动 | 已核 | <https://www.ant-intl.com/en/news/detail/ant-international-launches-full-stack-ai-native-solutions-for-payment-account-fx-treasury-and-growth-operations-for-global-businesses/> |
| 19 | 支付宝 AI 付 | Agent Pay、Vibe Pay、Skill Pay、Machine Pay、Token Pay 五类产品，按接入条件开通 | 已核 | <https://aipay.alipay.com/> |
| 20 | Adyen Agent Marketplace | 2026-10-22 开源的 AI 编码工具配置共享命令行工具，不是 Adyen 产品或商户交易市场；本报告未将其作为交易案例 | 已核 | <https://www.adyen.com/knowledge-hub/agent-marketplace> |
| 20a | Adyen Agentic | 2026-06-16 发布的模块化 API（Agentic Feed、Cart、Payments），面向美国企业商户限量开放 | 已核（2026-10-29） | <https://www.adyen.com/press-and-media/adyen-agentic> |
| 20b | Mastercard Agent Pay | 2025-04-29 发布；引入 Agentic Tokens，Agent 须注册并验证后方可代用户支付 | 已核（2026-10-29） | <https://newsroom.mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai> |
| 21 | 工行开放平台 | “互联网金融开放平台”：API 服务含账户管理、资金结算、员工薪资、商户收单、投资理财、网络融资、跨境财资等；API 对接或 H5、SDK 嵌入；在线身份认证服务满足合作方身份核实和数字签名需要；接口级签名细节未展示，不引用接口数量 | 已核（2026-10-29，仅限页面所示范围） | <https://open.icbc.com.cn/icbc/apip/index.html>；<https://open.icbc.com.cn/icbc/apip/service_detail.html?service_id=00481> |
| 21a | 农业银行开放银行平台 | 官网公告：开放银行平台全面启动对外服务，应用 API、SDK、H5，开放用户认证、账户服务、支付结算、信用卡、财富与融资、信息服务六类产品；2019 年 8 月起非公开试点；合作方统一接入 | 已核（2026-10-29；上线时点证据，当前服务清单未核） | <https://www.abchina.com/cn/aboutabc/nonghzx/newscenter/202001/t20200120_1868965.htm> |
| 21b | 中国银行开放银行客户授权协议（对公） | 2023-08-02 生效；以 API、SDK、H5 与应用方合作；客户在企业网银选定授权的应用方、账户、权限范围与到期日并以数字安全证书确认；银行处理交易指令前确认在授权范围内；应用方在授权范围内的操作视为客户行为 | 已核（2026-10-29） | <https://www.boc.cn/ebanking/service/cs1/202207/t20220711_21411224.html> |
| 21c | 建设银行开放银行管理平台 | 检索摘要：以标准 SDK、API 发布账户开立、结算、投资理财等服务；官方页面域名本次无法解析，2025 年度报告中未检到开放银行表述 | 待核 | <https://yun.ccb.com/industryPlatform/detail/openbank.html>（未能打开） |
| 21d | 交通银行开放银行 | 交银金融网“开放银行”栏目：Ⅱ、Ⅲ类账户 API、资金存管、收单支付、银企付（订单通知 API + 企业网银付款，以付款方确认订单作为对公付款授权）、信用付（H5）、快易付、进口信用证、跨境电商、银证转账 | 已核（2026-10-29） | <https://www.bankcomm.com/BankCommSite/shtml/jyjr/cn/2602759/2602766/2602768/list.shtml?channelId=2602759> |
| 21e | 招商银行掌上生活开放平台 | 接入指南：合作方申请 mid、aid，与平台交换 SM2 公钥，平台按 mid、aid 开通接口权限；API 与客户端协议两种方式；请求含时间戳、随机串与签名；另有招商银行 Open API 平台（页面需脚本加载，内容未核） | 已核（2026-10-29；Open API 平台内容未核） | <https://open.cmbchina.com/Platform/src/documents/overview/guide.html>；<https://openapi.cmbchina.com/> |
| 21f | 民生银行开放银行 | 官网综合服务方案：“走出去”以 API、H5 输出金融服务，“引进来”引入出行、导航、财税等非金融服务，联合打造行业云 | 已核（2026-10-29） | <https://www.cmbc.com.cn/gskh/jrstq/gjjrstq/zhfwfa/index.htm> |
| 21g | 民生银行企业标准 Q/CMBC 003—2022 | 《中国民生银行应用程序接口安全管理规范》：接入层负责认证鉴权等安全管控后转发集成层（5、8 章）；A1、A2、A3 三级（6.2），A2 为账户信息查询类，A3 为资金交易与服务签约类；A3 经本行渠道二次认证（7.2.1）；签名验签与报文加解密使用国家密码管理部门认可的国产密码算法（7.3.4） | 已核（2026-10-29，官网公开 PDF） | <https://www.cmbc.com.cn/cmbc/attachDir/2024/06/2024062610533551506.pdf> |
| 21h | 浦发银行 API Bank 无界开放银行 | 官网发布稿：7 月 12 日推出业内首个 API Bank 无界开放银行，以 API 嵌入合作方平台，已与 46 家企业合作（自述；官网同题报道归档于 2018 年 7 月）；API 开放平台门户现行，内容需脚本加载未核 | 已核（2026-10-29；历史时点证据） | <https://news.spdb.com.cn/about_spd/xwdt_1632/202503/t20250329_1108468.shtml>；<https://open.spdb.com.cn/> |
| 22 | DBS RAPID | 信息类（余额、对账单、交易状态等）、交易类（汇款、实时支付与收款、换汇）与流程类 API | 已核（2026-10-29） | <https://www.dbs.bank.in/in/corporate/solutions/cash-management/rapid> |
| 22a | CitiConnect API | 2021-04-12 新闻稿：企业客户经财资系统或 ERP 查询余额、付款状态、汇率，并发起付款 | 已核（2026-10-29；2021 年历史证据，不证明当前状态） | <https://www.citigroup.com/global/news/press-release/2021/citi-s-digital-channels-process-one-billion-api-calls-from-corporate-clients> |
| 22b | Wise Platform | 面向银行与金融机构的跨境支付代理行服务，可经 Swift 报文或 API 接入；列出的合作方含渣打、Morgan Stanley | 已核（2026-10-29） | <https://wise.com/platform/> |
| 22c | 渣打开放银行平台、BBVA、Tink、香港 IADS、Plaid 数据共享 | 开放银行与授权数据共享 | 待核 | — |
| 23 | Coinbase x402 | 官方文档：把 API 或数字服务变为付费资源，示例含 Agent 在任务中购买工具调用；CDP Facilitator 负责验证与结算 | 已核（2026-10-29） | <https://docs.cdp.coinbase.com/x402> |
| 23a | Stripe、PayPal Agent Ready、Circle Agent Stack | 商户支付工具、Agent Commerce 与机器支付；Circle 仅检索到媒体报道 | 待核 | — |
| 24 | 金发〔2026〕8号 | 国家金融监督管理总局《关于银行业保险业人工智能安全开发应用的指导意见》，2026-06-18 发布 | 已核标题、文号与日期（官网页面未渲染，经检索核对），条文待核 | <https://www.nfra.gov.cn/cn/view/pages/governmentDetail.html?docId=1261784&generaltype=1&itemId=861> |
| 25 | MAS SAFR | 2026-07-03 发布，列于专著/信息文件栏目，业界在 BuildFin.ai 倡议下共同形成 | 已核 | <https://www.mas.gov.sg/publications/monographs-or-information-paper/2026/safeguards-for-agentic-finance-at-runtime> |
| 26 | SR 26-2 | 2026-04-17；美联储、OCC、FDIC；替代 SR 11-7 与 SR 21-8；生成式与智能体 AI 模型不在本指导范围内 | 已核 | <https://www.federalreserve.gov/supervisionreg/srletters/SR2602.pdf> |
| 27 | JR/T 0185—2020 | 6.2 两级分类；7.1 密码算法合规；7.2.1、7.2.2、9.2.1、9.2.2 的认证与签名要求；7.3.4 密钥管理；第 8 章部署结构；9.1 应用方准入与身份核验；9.3.2 权限控制；9.4 应用方退出 | 已核（银行公开承载的标准文本） | <https://www.aibank.com/upload/attachs/2022/12/14-商业银行应用程序接口安全管理规范.pdf> |
| 28 | Wells Fargo 在线访问协议 | 2026-11-24 生效；第 2(b)、2(d)、8(b) 节涉及 AI Agent | 已核 | <https://www.wellsfargo.com/online-banking/online-access-agreement/upcoming/> |
| 29 | Axios 报道（媒体） | 2026-10-22，美国银行发现并限制未授权 AI Agent；原文未能直接访问，经多家转述核对 | 媒体，待核 | <https://www.axios.com/2026/10/22/ai-agents-banks-unauthorized-accounts-access> |
| 30 | 中国人民银行业务领域数据安全管理办法 | 中国人民银行令〔2025〕第 3 号，2025-05-01 公布，2025-06-30 施行；第二条界定适用范围 | 已核（2026-10-29，正式文本） | <https://www.pbc.gov.cn/zhengwugongkai/attachDir/2025/11/2025111915275027791.pdf> |
| 31 | MCP 安全最佳实践 | 混淆代理、令牌透传（MCP 服务不得接受非签发给自身的令牌）、服务端请求伪造、会话劫持（不得以会话认证）与最小权限范围 | 已核（2026-10-29） | <https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices> |

## 附录 B 缩写

MCP：Model Context Protocol（模型上下文协议）；A2A：Agent-to-Agent（智能体间协作），支付语境中也指 Account-to-Account；AP2：Agent Payments Protocol；APOP：银联智能体支付开放协议框架；AVOP：银联智能体增值服务协议；AMP：蚂蚁国际 Agentic Mobile Protocol；KYA：Know Your Agent；BaaS：银行即服务；SCA：强客户认证；FDX：Financial Data Exchange；SM2：国家密码管理部门发布的椭圆曲线公钥密码算法，常用于签名与密钥交换；Skills：可被 Agent 按需加载的任务技能包。

## 更新历史

| 版本 | 日期 | 说明 |
|---|---|---|
| v1.0 | 2026-10-27 | 原报告 |
| v1.1 | 2026-10-27 | 根据第三方复核意见，对事实边界与 2026 年重点案例作受控增补 |
| v1.2 | 2026-10-28 | 经五席审议第 1 轮修订，见下文 |
| v1.3 | 2026-10-29 | 经五席审议第 2 轮复审修订，见下文 |
| v1.4 | 2026-10-29 | 第 3 轮复审通过后，按少数意见作标注与口径修订，见下文 |
| v1.5 | 2026-10-29 | 定稿，见下文 |
| v1.6 | 2026-10-29 | 按管理员再审议要求，经再审第 1 轮意见收集修订，见下文 |
| v1.7 | 2026-10-29 | 经再审第 2 轮复审修订，见下文 |
| v1.8 | 2026-10-29 | 再审第 3 轮复审通过后，按强席位少数意见作措辞收窄与口径说明，见下文 |
| v1.9 | 2026-10-29 | 再审议定稿，见下文 |

**v1.2 修订要点：**

- 结构：案例细节压缩为分层样本表，移入附录 A；删去原第十章标杆清单和重复的架构图；第七章更名为“互联形态”，与第四章“共性范式”区分；Adyen 归类、Plaid 定位等勘误直接写为终态结论。
- 事实：“六项发现”实列七条的矛盾已修正；核心结论由“全球金融业”收窄为“部分领先金融机构与支付网络”；三层图改为叠加关系。Mastercard 收窄为服务发现与接入指南，Newline 收窄为“支持 API 接入与开发、具体业务工具待核”，HSBC 注明 `confirmed` 为调用确认参数。删除无法核实的招商银行“逾 2,000 个企业 API”与兴业银行“大量 API”；删除未具名的“跨境数据验证平台”；银联 15 家银行改按公告写明已发卡与陆续推出的情况；P3 不再整体标“成熟”；Griffin 移出 MCP 发现与本地安全代理样本。
- 监管与标准：补充金发〔2026〕8号的标题与日期，并区分原文与本报告解读；SR 26-2 补充联合发布机构与被替代文件；JR/T 0185—2020 补充条款号，明确账户信息查询属 A2；Axios 标为单一原始信源的媒体报道；新增合规与标准依赖提示表。
- 建议：双层网关改为逻辑职责分层；新增前置条件与组织治理、阶段零与进入门槛、异常处置与安全底线、安全度量；第四阶段标为远期。
- 趋势：补充评级口径，下调 T1（银行主体）、T3、T4、T5、T6、T7。
- 来源：参考资料去重（原 1/16、2/15、3/17、6/18 重复），按“机构—要点—状态—来源”逐项记录核验状态，媒体单列。

**第 1 轮审议记录（2026-10-28）：** 五席均有效作答，表决均为 REVISE；投票席位无 APPROVE，未进入互评，按意见收集采纳。各席认可“存量金融 API 承载执行、智能体协议新增发现与协作入口”和“开放能力不等于开放权限”的主线。

**强席位阻塞项闭环：**

| 提出席位 | 阻塞项 | 处理 |
|---|---|---|
| 质疑席 | Mastercard、Newline 业务调用能力超出证据 | 已修复：按官方页面收窄（3.2、附录 A 第 5、8 项） |
| 质疑席 | 国内案例缺来源，招行数字无法核实 | 已修复：删除无源数字，国内表压缩为概述并标待核（3.4、附录 A 第 21 项） |
| 质疑席 | 敏感数据开放的合规前提不完整 | 已修复：新增 6.4 合规与标准依赖提示 |
| 质疑席 | 缺授权撤销、参数篡改、结果不明、控制面不可用的处置 | 已修复：新增 7.4 |
| 质疑席 | 核心能力、状态与日期缺逐项可追溯依据 | v1.2 建立附录 A 逐项记录；第 2 轮复审指出口径与正文矛盾，v1.3 已修复，见下文第 2 轮闭环表 |
| 核验席 | JR/T 0185 A1/A2 分级无条款依据 | 已修复：核对标准文本，补充 6.2 等条款号，A2 含账户信息查询，阶段二准入相应调整 |
| 核验席 | 国内案例无来源、招行数字无法核实 | 已修复，同上 |
| 核验席 | 缺个人信息、数据安全、外包、生成式 AI、密码等合规提示 | 已修复：6.4 |
| 核验席 | 实施路径缺前置条件、组织治理与阶段门槛 | 已修复：7.2、7.3 |

**v1.3 修订要点（第 2 轮复审）：**

- 证据口径：改为“待核条目只作方向示例（正文标 †），不单独支撑结论；支持度评级只计已核条目”，第二章与附录 A 同步。
- 补核：主持人于 2026-10-29 核对 J.P. Morgan（更换失效链接）、PayPal 内部 Hub、工行开放平台、DBS RAPID、CitiConnect API、Wise Platform、Coinbase x402、Mastercard Agent Pay、Adyen Agentic 的官方页面，附录 A 改为已核并新增 20a、20b、22a、22b、23；Circle 仅有媒体报道，Stripe、PayPal Agent Ready、Visa、Tink、香港 IADS、渣打、BBVA 仍待核，正文降为 † 示例。
- 正文：国内开放银行由总体归纳收窄为工行样本；海外双向互联改用已核的 DBS、Citi、Wise；执行摘要第 4 条注明“据媒体报道”，并把 Wells Fargo 协议改写为责任划分；AP2 统一为“宣布捐赠”FIDO 联盟；范式六改用 Adyen Agentic、蚂蚁国际 AMP、Mastercard Agent Pay。
- 趋势：T7 由“中”降为“弱”；T8 保留“中”并注明已核两家，Circle 不计入；T2 注明 HSBC 按受限开放计。
- 其他：合规提示补《网络安全法》与《促进和规范数据跨境流动规定》；阶段三准入写明沿用阶段二控制与付款申请幂等；Amex 状态改为“已核（转载）”；删除正文未使用的 ACP、UCP 缩写。

**第 2 轮复审记录（2026-10-29）：** 五席均有效作答，主主持、顾问席 APPROVE，质疑席、核验席、第二主持 REVISE；投票席位不足两家 APPROVE，未进入互评，按意见收集采纳。各席确认第 1 轮阻塞项中除“逐项可追溯依据”外均已闭环。

**第 2 轮强席位阻塞项闭环：**

| 提出席位 | 阻塞项 | 处理 |
|---|---|---|
| 质疑席 | 证据口径“待核不参与推断”与正文矛盾：J.P. Morgan、PayPal、国内概述、x402/Circle 支撑结论但附录待核 | 已修复：J.P. Morgan、PayPal、工行、x402 补核为已核；国内概述收窄为工行样本；Circle 降为 † 示例且不计入 T8；口径改为“待核只作方向示例” |
| 核验席 | 同一矛盾；另指 T7、T8 评级不足，Adyen Agentic 与 Mastercard Agent Pay 无附录条目，执行摘要把媒体报道写成事实 | 已修复：T7 降为“弱”，T8 只计已核两家；附录新增 20a、20b 并核为已核；执行摘要第 4 条加“据媒体报道”，Wells Fargo 改写为责任划分 |

第二主持（不计票）同时指出的 DBS、Citi、Wise 归纳对应待核问题，已按其候选链接方向自行核对官方页面后改写；渣打不再作为输出案例。

**未纳入本版的候选：** 席位按记忆提出的支付宝 2025 年支付 MCP Server、银联与中国数联的数据交易支付预研、欧盟 PSD3/FiDA 与 MAS AI 风险管理指引等，本轮未取得一手材料，未写入正文，待后续核实后增补。

**第 3 轮复审记录（2026-10-29）：** 研讨完整完成（独立意见、互评与综合齐全），五席在独立意见与互评两个阶段均投 APPROVE，法定人数满足，无强席位阻塞项。质疑席、核验席确认第 2 轮阻塞项已闭环，本轮修订未引入新问题。顾问席引用的行号超出送审稿全文，所述内容在送审稿中检索不到，其意见未作为依据。

**v1.4 修订要点（第 3 轮少数意见）：** 本轮无阻塞项，以下均为编辑性收窄，不改变结论与评级。

- 媒体标注：证据口径写明媒体报道按待核处理并标 †；执行摘要第 4 条与 6.1 的 Axios 报道补 †；结论第三条注明“限制”一侧只有媒体报道；6.1 归纳注明为本报告判断。
- 状态词：附录 A 说明写明“已核（转载）”按已核计，含“待核/待复核”字样的状态中所注明的部分按待核处理。
- 评级口径：“中”写明至少 2 家；T3、T5 注明已核两家；T6 注明无已核样本。
- 推论标注：范式六先列三项已核事实，再标明“减少点对点集成”为本报告判断；4.5 工行“沿用存量安全网关”标为推论。
- 执行摘要第 4 条补 Wells Fargo 协议 2026-11-24 生效。
- P2：Newline 只有 MCP 与 Skills 已核，状态改为“生产服务（以 Wise Platform 为已核样本）”。
- 少数意见专节补第 3 轮的第 7—9 条。

**v1.5 定稿说明：** 以 v1.4 为基础定稿，结论、评级与来源不变；3.3 表“商户与钱包连接”一行的状态要点与 4.6 一致，标明“减少点对点集成”为本报告判断。


**v1.6 修订要点（再审议第 1 轮）：** 管理员在 v1.5 定稿后提出四项再审议要求：补充国内国有大行与股份制银行样本并重新研判；调整 7.1 架构图中智能体治理职责与存量 API 安全边界的先后关系，并以完整句子展开 7.2 等小节；对少数意见再讨论；正文控制在约 12000 字。本版据此修订。

- 国内样本（3.4）：新增 3.4.1 八家银行样本表与 3.4.2 研判。主持人于 2026-10-29 打开官方页面核对了工行平台首页、农行 2020 年上线公告、中行对公客户授权协议、交行交银金融网开放银行栏目、招行掌上生活接入指南、民生官网综合服务方案与企业标准 Q/CMBC 003—2022、浦发 API Bank 发布稿；建行官方页面无法打开，标“待核”且不计入研判。招行、浦发的开放平台门户需脚本加载，只核对到平台存在，内容未核。各席按记忆提出的平台别名、上线年份与接口数量，凡未在官方页面核到的均未写入。
- 联动修改：执行摘要第 6 条改为多银行样本，并写明“未检索到”的日期、范围与关键词；第 4 条补交行“银企付”作国内参照，并把 Wells Fargo 协议与媒体报道拆开表述；P1、P2 补国内代表，P2 移除证据不对应的 Newline；P4 与 3.2 补银联 MCP 集市（已核，卡组织）；4.3 权限可信补中行授权协议；4.5“传统 API + 安全 SDK”改以招行、中行已核做法为依据，删除原“推论”标注；T1 注明国内银行暂无已核样本；T2 补国内旁证且不计数。
- 架构（7.1）：采纳管理员意见。存量开放平台与 API 网关改为唯一对外边界，MCP、A2A 协议服务置于边界之后，智能体治理改为行内控制面，不接受外部管理调用；“内外同目录”改为“共享能力元数据，分别发布授权视图”；删除“基于 Danske 等案例的推论”（Danske 本地代理部署在客户侧，不能推出银行侧治理层），改标为本报告设计建议；补充签名链、应用方认定、客户侧部署、MCP 特有风险及合建与分建的比较。6.3 补 JR/T 0185—2020 第 8 章部署结构作为分层依据。
- 展开（7.2—7.5）：7.2 五项前置条件、组织治理与客户协议改为完整句子，并标注 JR/T 0185—2020 第 7.1、7.2、7.3.4、9.1、9.2、9.3.2、9.4 条，民生企标第 7.3.4 条，中行授权协议与人民银行数据安全办法等依据；7.3 门槛补验收条件，写明“前阶段通过不构成后阶段授权”，“监管认可”改为可检验条件；7.4 改为带小标题的完整句子；7.5 改为分类指标表。
- 口径：“已核（转载）”可作事实引用但不计入评级，T4 改按 AP2、APOP 两家计；官方未说明环境的样本不计入“生产或受限开放”，T2 不再计入 HSBC，评级不变；评级按全部主体计并单列银行主体，表中逐项列出计入样本。6.2 金发〔2026〕8号删去实质性解读，只保留已核的标题、文号与日期。6.3 补行业 A1/A2 与银行内部 A3 分级的映射说明。6.4 补《中国人民银行业务领域数据安全管理办法》。
- 第九章：导语改为“有依据、经再讨论仍未采纳”；九条少数意见逐条再讨论后保留三条，其余处理见下表。
- 篇幅：精简执行摘要与第八章的重复表述，正文（一至九章，不含图示代码）约 1.14 万汉字，v1.5 约 0.72 万汉字；增量主要用于 3.4 与第七章。

**第九章少数意见再讨论结果：**

| 原条目 | 再讨论意见 | 处理 |
|---|---|---|
| 1 七类形态的划分维度 | 核验席、主主持、质疑席、第二主持均认为可在 3.1 表增列维度说明；第二主持认为二维表或合并四类仍可作为编辑选择保留 | 增列“划分维度”“所属层”两列，声明七类不是成熟度阶梯；二维表与合并主张保留为少数意见第 1 条 |
| 2 双层网关的定位 | 各席意见均认为 7.1 改为“单一对外边界 + 边界之后的治理职责”即回答了该问题；质疑席要求比较部署方式 | 已闭环：7.1 重写并补合建与分建比较 |
| 3 趋势评级 | 核验席、主主持、质疑席、第二主持均主张保留评级；质疑席要求评级可重算 | 保留评级并逐项列出计入样本；删列主张保留为少数意见第 2 条 |
| 4 顾问席的架构补充 | 质疑席、核验席指出 OpenAPI 自动转译不能生成委托、审批、幂等与恢复语义，且全量转译与 4.2 “不注入全部 Schema”冲突 | 已闭环：4.2 补一句说明自动转译的边界；其余为实现选项，不展开 |
| 5 银行与非银的外推 | 各席意见均主张在表格中标注主体 | 已闭环：3.1、3.2 表逐项标注银行、卡组织或非银主体，第二章证据口径同步 |
| 6 人民银行数据安全要求 | 质疑席给出正式文本；主持人核对原文 | 已闭环：6.4 补人民银行令〔2025〕第 3 号，附录 A 第 30 项 |
| 7 Wells Fargo 协议的证明范围 | 各席意见均认为 v1.5 已采纳质疑席读法，不再属于少数意见 | 已闭环：执行摘要第 4 条将协议与媒体报道分开表述 |
| 8 证据时点与样本量 | 质疑席、第二主持部分采纳：Citi 只证明历史实践，两家门槛属人为设定 | P1 改以工行、交行现行页面为主要依据，附录 A 第 22a 项注明历史证据；评级门槛不变，保留为少数意见第 3 条 |
| 9 顾问席第 3 轮的补充方案 | 核验席、主主持指出其与专节导语“有依据”矛盾 | 已移出少数意见，记录留在本节第 3 轮复审记录中 |

**再审议第 1 轮记录（2026-10-29）：** 以 `--goal review` 审议 v1.5，按意见收集采纳。五席均提交了意见，表决均为 REVISE；投票席位无 APPROVE，未进入互评。主主持（不计票）被插件判为盲席，其原文仍作参考。各席认可“存量金融 API 承载执行、智能体协议新增发现与协作入口”和“开放能力不等于开放权限”的主线，一致认为管理员关于 3.4 样本不足和 7.1 暴露面的意见成立。顾问席引用的原报告行号（如 320—375、710—755、960—1065 行）超出原报告全文 402 行，所述“上下文沙箱”“熔断降级”等短语与“私有化模型”“生成式 UI”等争议在原报告中不存在；其中提出的语义防火墙、自主度分级与限额自主扣划、分布式事务补偿、本地化匿名脱敏网关等方案，以及引用的《商业银行互联网贷款管理暂行办法》第二十五条、银监发〔2011〕104号等依据，均未经核实，未予采纳。其列出的部分平台网址与官方材料所示不一致（如农行官方公告所列为 openbank.abchina.com）。

**再审议第 1 轮强席位阻塞项闭环：**

| 提出席位 | 阻塞项 | 处理 |
|---|---|---|
| 核验席 | 7.1 图中外部流量先经智能体治理、后经机构准入，与 6.3 的 A2 双向认证与签名要求及 7.3 阶段二相互矛盾，影响落地 | 已修复：7.1 重写为唯一对外边界在前，协议服务与治理职责在后，补签名链与应用方认定 |
| 核验席 | 3.4 只有工行样本，执行摘要第 6 条的否定性陈述缺检索范围 | 已修复：3.4.1 补七家已核银行，执行摘要第 6 条写明检索日期、范围与关键词 |
| 核验席 | P2 代表案例 Newline 的证据只覆盖 MCP 与 Skills，不支撑嵌入式金融 | 已修复：P2 移除 Newline，改用 Wise Platform 与交行、民生 |
| 核验席 | 金发〔2026〕8号条文待核却给出解读 | 已修复：6.2 删去实质性解读 |
| 核验席 | 7.1 用 Danske（客户侧代理）推论银行侧治理层；第九章导语与第 9 条矛盾 | 已修复：改标为本报告设计建议；第 9 条移出少数意见 |
| 质疑席 | 国内样本应补齐并区分“官网介绍”与“接口、权限、安全实现已核” | 已修复：3.4.1 按“材料所示”写明证据性质，未核部分逐项注明 |
| 质疑席 | 7.1 治理与协议处理位于认证之前；须补内部控制面、令牌受众、会话绑定、签名前置验证，且不能承诺零新增暴露面 | 已修复：7.1 配套约束写入，附录 A 第 31 项；会话绑定 v1.6 未明确写入，v1.7 补入（见下文） |
| 质疑席 | 7.2、7.4、7.5 须写清责任、动作与验收结果 | 已修复：7.2 至 7.5 重写 |
| 质疑席 | “已核（转载）”不应计入一手证据门槛；HSBC 环境未知不能按受限开放计 | 已修复：评级口径与 T2、T4 调整，评级结果不变 |
| 质疑席 | 银联 MCP 集市公告可读，应提升证据状态并限定范围 | 已修复：附录 A 第 15 项改为已核，正文限定为卡组织的工具开放 |
| 质疑席 | 行业 A1/A2 与银行内部 A3 分级需映射 | 已修复：6.3 补映射说明 |
| 质疑席 | 阶段门槛只衡量监测能力与人工成本，不足以证明可扩大权限 | 已修复：7.3 门槛补验收条件与停止扩围规则 |

**再审议第 2 轮记录（2026-10-29）：** 以 v1.6 为送审稿，研讨完整完成（独立意见、互评与综合齐全），法定人数满足。独立意见阶段核验席、质疑席、顾问席均投 APPROVE；互评阶段核验席、质疑席改投 REVISE，顾问席维持 APPROVE，两席指向同一阻塞项。各席确认管理员四项再审议要求已落实，再审第 1 轮强席位阻塞项基本闭环。顾问席所引行号（如 190—255、355—438 行）与送审稿内容不符，所述建行“开放银行 3.0”等内容在送审稿中不存在，其意见未作为依据。

**再审议第 2 轮强席位阻塞项闭环：**

| 提出席位 | 阻塞项 | 处理 |
|---|---|---|
| 质疑席、核验席 | 执行摘要第 6 条（含标题）、3.4.2 研判第 1 条与第八章第一条把“以 API 为主、辅以 SDK 和 H5，开放账户、支付结算、融资能力”写成七家共有，超出 3.4.1 表所示证据，与表格自相矛盾 | 已修复：三处按表收窄为“均以 API 开放为主”，研判第 1 条逐行列出各行可见的形态与能力（工、农、中明示 SDK 与 H5，交行、民生可见 H5，招行可见 SDK 与客户端协议，浦发只涉及 API；工、农、交明示三类能力），结论改为“部分辅以 SDK、H5”；待提出席位定向复核 |

**v1.7 修订要点（再审第 2 轮少数意见，均为编辑性收窄，不改变结论与评级）：**

- 检索范围：执行摘要第 6 条与 3.4.2 第 4 条改为“已能加载的开放平台页面”，写明招行 Open API 平台与浦发门户内容未能读取、不在检索覆盖范围内（核验席、质疑席、第二主持）。
- 7.1：第 1 条改为按接口安全等级准入，双向认证、验签与防重放限定为 A2 调用，图中 E1 同步标注；“不重建鉴权体系”改为“不另建准入、证书与密码体系”，并写明协议服务仍须校验令牌受众与会话归属，消除与配套约束的措辞张力（核验席、主主持）。配套约束补“会话与长任务的恢复须绑定已认证的调用主体”，阶段二门槛补跨主体会话复用测试，再审第 1 轮闭环表相应改注（质疑席、核验席、第二主持）。签名链补“保留可复验的原始签名报文及其与转换后工具调用、业务参数的对应记录”（质疑席）。
- 4.5：“传统 API + 安全 SDK”一行只以招行为直接依据并注明其接口安全等级未说明，工行降为旁证，中行（客户证书确认授权）移出该行，仍保留在 4.3“权限可信”（核验席、质疑席、主主持）。
- 民生分级：主持人于 2026-10-29 重新打开民生企业标准原文，核对第 6.2 条 A2 为账户信息查询类、A3 为资金交易与服务签约类，附录 A 第 21g 项补记，6.3 正文不变（核验席）。
- 措辞：3.4.2 第 2 条“八家”改为“七家”；7.2 “密码管理部门”改为“银行内部负责密码管理的部门”，避免与国家密码管理部门混淆；T1 计入样本删去“等”；再审第 1 轮讨论表中“各席一致认为/主张”改为“各席意见均认为/主张”，因为该轮没有互评（核验席、主主持）。
- 第九章：新增第 4 条少数意见（T1 计入 Blend 与评级口径的张力），说明不采纳的理由。
- 未采纳：顾问席提出的 NEF/CAPIF、BCBS 与 DORA 等背景没有出处，且 DORA 为欧盟法规而非巴塞尔委员会文件，未写入；主主持提出的阶段三“低权限 A2A 试点”范围问题，现有表中已限定“低权限”并沿用阶段二控制，本版不改。

**再审议第 3 轮记录（2026-10-29）：** 以 v1.7 为送审稿，研讨完整完成（独立意见、互评与综合齐全），法定人数满足。核验席、质疑席、顾问席在独立意见与互评阶段均投 APPROVE，两个主持席同样 APPROVE，强席位无阻塞项。核验席、质疑席定向复核确认：再审第 2 轮唯一阻塞项（七家共有 SDK、H5 与三类能力）已闭环，v1.7 采纳的少数意见没有引入新的事实错误或矛盾。顾问席所引第 33、113、323 行原文与送审稿不符，其意见未作为依据。各席本轮均未联网复核外部原文，外部事实以附录 A 的主持人复核记录为据。

**v1.8 修订要点（再审第 3 轮少数意见，不改变结论与评级）：**

- “以 API 为主”改为“均可见 API”：执行摘要第 6 条（含标题）、3.4.2 研判第 1 条与第八章第一条。农、中两行把 API、SDK、H5 并列，招行以 API 和客户端协议两种方式服务，材料都没有说明主次（核验席、质疑席、第二主持）。
- 交行开放能力：3.4.2 研判第 1 条不再称交行“明示融资类能力”，改为列有Ⅱ、Ⅲ类账户、收单支付，以及信用付、进口信用证等融资相关产品，与 3.4.1 表一致（核验席、质疑席）。
- 4.5 工行旁证：“在线数字签名服务”改为“满足数字签名需要的在线身份认证服务”，与 3.4.1 表和附录 A 原文一致（核验席、质疑席、主主持）。
- 评级口径与第九章第 4 条：Mercury、Qonto 同为金融科技公司，v1.7“不计 Blend 仍有三家”的理由不成立。评级口径补写金融科技公司按“大型机构”计入、T1 与 T2 的“较强”以此为前提；第九章第 4 条改写为保留“大型”缺少量化判准的意见（核验席、质疑席）。
- 未采纳：主主持关于 v1.6 修订要点残留的意见已在互评中撤回；顾问席补充的 MCP 网关、小程序沙箱等方案没有出处，未写入。

**v1.9 定稿说明：** 以 v1.8 为基础定稿，正文、结论、评级与附录 A 来源均不变，仅更新版本号与本更新历史。再审议共三轮：第 1 轮意见收集，第 2 轮研讨完整但有一项强席位阻塞项（v1.7 已修复），第 3 轮研讨完整、五席均投 APPROVE 且强席位阻塞项全部闭环。v1.8 的措辞收窄发生在第 3 轮通过之后，与本版一并提交终审复核。第九章保留四条少数意见。