屏幕抓取和基于应用程序编程接口 (API) 的访问都能帮助商家从客户的银行账户中获取所需的金融数据，但它们使用了根本不同的机制来实现这一点。屏幕抓取使用您的凭据登录您的银行账户，并从您自己能看到的相同页面上读取数据。API 访问通过您自己银行的登录路径路由您，然后签发一个限定范围、可撤销的令牌，而不会触碰您的密码。在某些情况下，基于 API 的连接已将成功率提高至高达 99.9%。除了可靠性之外，这种方法还拥有很高的安全性，可以改善客户体验，并有助于商家保持遵守法规。

下面，我们将探讨屏幕抓取和 API 访问是如何运作的，为什么凭据存储会产生与基于令牌的访问不同的风险概况，以及银行和监管机构如何加速向 API 的转变。

要点

• 传统的屏幕抓取需要存储客户的银行凭据，而 API 访问依赖于客户直接在其银行进行身份验证后签发的限定范围、可撤销的令牌。

• 当银行更改其网站时，屏幕抓取可能会损坏，而 API 通过一份契约返回结构化数据，该契约通常只有在银行故意更新时才会发生变化。

• 消费者金融保护局 (CFPB) 的第 1033 节规定以及英国和欧盟现有的开放式银行框架正在推动银行采用标准化访问（通常意味着 API），并逐渐远离基于凭据的抓取。

金融服务中的屏幕抓取是什么？

屏幕抓取意味着第三方服务使用您的用户名和密码登录您的银行账户，然后直接从您自己登录时银行显示的页面读取数据。没有专门的数据通道。该服务使用客户使用的相同会话，并直接从呈现的页面中提取账户余额、交易历史记录和账号。

金融数据 API 如何运作？

基于 API 的访问通过基于权限的移交取代了凭据共享，并通常在开放授权 (OAuth) 2.0（在线授权的事实标准）上运行。

该流程分为几个不同的步骤：

• 重定向和身份验证： 您会被直接转到您银行的登录页面，在其中输入只有您银行才能看到的凭据。

• 同意和范围： 您的银行要求您批准有限的权限，例如请求商家被允许查看的账户余额或交易历史记录，而不是赋予对您账户中所有内容的全面访问权限。

• 令牌签发： 一旦您批准，您的银行就会向请求的商家签发一个访问令牌。该令牌代表一项有限的、可撤销的授权。

• 结构化数据传送： 商家使用该令牌调用银行的 API，并收到清晰、结构化的数据作为返回，例如 JavaScript 对象简谱 (JSON)。

为什么与屏幕抓取相比，API 可以降低安全风险？

屏幕抓取和 API 访问最大的区别在于存储的内容以及谁控制访问权限。这种差异几乎决定了随之而来的所有安全后果，从入侵暴露到关闭受损连接的速度。

存储凭据与签发令牌

传统的屏幕抓取通常需要聚合器将其系统中的某个位置存储您的实际银行用户名和密码，通常在您继续使用该服务期间都会一直存储。如果该聚合器的数据库遭到入侵，每一个已存储的凭据集都是目标。

使用 API 时，在 OAuth 身份验证后传递给商家的访问令牌是一种限定范围、可撤销的凭据，通常会过期，并且仅授予您批准的访问权限，例如对交易历史记录的只读可见性。如果商家的系统遭到入侵，可以在银行层面关闭该令牌，而无需您这边重置密码。

完全访问权限与已定义访问权限

已存储的密码会赋予持有者与您自己登录时相同广泛的访问权限。令牌可以严格限制为一个功能，因此为贷款申请表确认您账户余额的商家不会带走他们根本不需要的五年交易历史记录。完全访问权限和已定义访问权限之间的差距是银行、监管机构和 API 提供商将凭据存储视为风险更高模型的原因之一。

屏幕抓取和 API 之间的可靠性和扩张性有何不同？

从设计上讲，屏幕抓取非常脆弱，因为它依赖于银行自身的网站。当银行更新其登录流程、重新设计其管理平台或添加新的身份验证步骤时，基于旧布局构建的抓取工具可能会停止工作，直到工程师手动重建它们。这种脆弱性加上它带来的规模问题，导致了几个明显的问题：

• 网站依赖性： 抓取工具依赖于银行的 HTML 保持不变，这意味着例行的重新设计可能会在没有任何警告聚合器的情况下悄悄断开连接。

• 手动维护： 损坏的抓取工具通常需要工程师为新布局重建它们——这项工作需要在数千家按各自发布计划运行的银行中重复进行。

• 更高的失败率： 基于抓取的连接失败率往往明显高于基于 API 的连接，尤其是在银行推送网站更新之后。

一般认为 API 更可靠，原因如下：

• 已定义的数据契约： 银行的 API 以固定结构返回账户数据，例如格式化为以分为单位的整数的余额字段，并且该结构通常不会改变，除非银行故意更新 API 并发出通知。

• 清晰的错误处理： 当出现故障时，API 会返回一个明确的错误代码，以便商家的系统知道重试或标记问题，而不是处理损坏或格式错误的数据。

• 线性规模与网络化规模： 开放式银行基础结构促进了与数千家银行和信用社的直接关系，这意味着商家只要集成一次就能覆盖整个网络。然而，基于抓取的方法需要为列表中的每家银行构建并维护一个自定义脚本。

屏幕抓取如何影响用户体验和客户信心？

将您的银行用户名和密码交给第三方应用需要一定程度的信任，而许多人并不愿意提供这种信任。许多银行自己的安全信息都会引导用户切勿在银行自身网站之外共享登录凭据，因此，如果某个基于抓取的应用要求用户在其自身界面中执行此操作，可能会引起用户的怀疑。这种不匹配可能会在账户关联时引起犹豫，从而阻碍用户完成关联流程，或者在他们感觉凭据请求不对劲时中途放弃。

基于 OAuth 的流程避开了这个问题，因为您只需在银行自己的登录页面中输入密码。这是已知域名上熟悉的界面，并且权限屏幕会明确告诉您同意共享的具体内容。这种明确性改变了同意的心理，因为您会收到一份具体的项目列表，例如账户余额和过去 90 天的交易历史记录，并被要求直接批准或拒绝。因此，基于直接银行身份验证构建的同意流程通常比基于凭据的聚合带来更高的完成率。

一旦由于糟糕的体验或有关基于抓取的聚合器遭到入侵的新闻头条而动摇了信心，就很难重新赢回信任。开发金融产品的商家越来越多地将身份验证方法本身视为可信度的指标，而不是简单的实施细节。

监管机构是如何推动从屏幕抓取向 API 的转变的？

CFPB 的第 1033 节规定目前在联邦法院发布初步禁令后暂停执行，该规定旨在实施多德-弗兰克法案中要求银行等数据提供商按照客户的指示向第三方提供客户金融数据的一部分。该规定的目的是赋予客户以可用、便携格式拥有其自身数据的法律权利。该规定明确支持标准化、安全的电子转移方法，在实践中，这通常意味着采用 API 而不是基于凭据的抓取。

许多大型金融机构已经花费数年时间构建了专门的 API 基础结构，部分原因是为了能够停止支持访问其面向客户的网站的抓取工具流量。这可能会对服务器容量造成压力，并导致安全审查复杂化。英国和欧盟的开放式银行框架为此转变开创了早期的先例。

由于许多规模较小的机构和信用社仍然缺乏大型银行已经建立的 API 基础结构，一些聚合器将抓取作为对于尚未提供 API 替代方案的账户的回退机制。然而，随着第 1033 节规定的实施不断推进，并且越来越多的银行拥有合规的 API 端点，开发金融产品的商家最应该及早采取行动，以免基于抓取的连接遭到淘汰。

Stripe Financial Connections 如何提供帮助

Stripe Financial Connections 是一组 API，允许您安全地关联到客户的银行账户并检索他们的金融数据，从而让您能够构建创新的金融产品和服务。

Financial Connections 可以帮助您：

• 简化入驻流程：提供无缝、即时的银行账户验证流程，无需人工核验身份与账户信息。

• 访问丰富的金融数据： 检索有关您客户的银行账户的全面信息，包括余额、交易和账户详情。

• 自动化经常性付款流程：支持客户安全绑定银行账户实现经常性付款，提升支付成功率。

• 加强风险管理：分析客户财务数据，为信贷、借贷及其他金融产品决策提供依据。

• 遵守法规：Financial Connections 可帮助您满足客户身份验证 (KYC) 和反洗钱 (AML) 要求。

• 安心创新：基于安全可靠的 Financial Connections 基础设施开发新型金融产品与服务。

进一步了解 Financial Connections，或立即开始使用。