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

版本： 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 金融生态互联的三类叠加实践 #

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”也不等于“开放真实金融业务”。本报告分别评价。

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

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

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

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

3.1 七类互联形态 #

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

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

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

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

国内实践： 中国银联 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。

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

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

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

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

设计启示：强制安全控制，不强制唯一部署形态。 底层 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 中经官方页面核对的“已核”条目；“已核（转载）”“待核”及状态中注明待核的部分不计；官方未说明环境的样本不计入“生产或受限开放”。评级反映当前公开案例对方向的支持度，不是预测置信度。

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

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 监管与治理坐标 #

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 合规与标准依赖提示 #

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

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

7.1 总体思路与逻辑架构 #

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

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 分阶段实施路径 #

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

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，待复核”“已核（范围待核）”“条文待核”“媒体，待核”），所注明的待核部分一律按待核处理。

附录 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 按需加载的任务技能包。