银行网站隐私合规调查：第三方脚本泄露敏感财务数据
尽管银行业投入巨资以树立其作为个人及财务数据谨慎保管者的形象，但一项针对欧洲和美国 14 个金融服务网站的检查显示，实际情况并不乐观。在开户、抵押贷款和贷款申请等关键流程中，嵌入的跟踪和个性化脚本向第三方发送了用户的联系方式、财务意图及设备指纹信息。
调查发现的数据泄露行为主要呈现三种模式，且每种模式在法律层面均存在显著差异：
- 缺乏合法依据：在财富管理、投资银行和支付提供商网站上，此类数据收集行为根据欧盟《电子隐私指令》从未具备合法基础。
- 忽视用户拒绝同意：部分网站在用户主动拒绝 Cookie 后仍继续追踪。例如，某网站上的 Google Ads 和 DoubleClick 仍在请求 URL 中接收用户的散列电子邮件地址以及“拒绝同意”的信号，这意味着用户的拒绝被记录后随即被无视。
- 无视同意状况泄露财务细节：无论用户是否给予同意，具体财务数据均被泄露。在一次个人信用申请中，一笔 2,500 欧元的贷款、12 个月的期限以及保险选择信息被发送至 Google Analytics。在葡萄牙一家银行的开户流程中，客户的姓名、年龄和税务号码以 Base64 编码文本形式通过请求 URL 发送给 Evergage。
此外，在一家荷兰银行的网站上，一段第一方脚本将浏览器指纹识别与向本地端口（7070 和 5938）发起图片请求相结合。这两个端口分别与远程访问软件 AnyDesk 和 TeamViewer 相关联，实质上是在探测访问者设备上是否运行着远程控制程序。
责任归属争议：平台默认设置与银行部署疏忽
关于数据收集的责任归属，Meta 和 TikTok 均指向网站运营商，认为控制被收集内容的是运营方。Meta 援引其隐私控制政策及反对分享敏感数据的规定；TikTok 则表示广告商决定发送哪些事件和参数，平台仅接收合作伙伴故意配置的内容。
然而，事实表明这种“故意配置”往往并不存在。Meta 的自动高级匹配功能在 Meta 像素上是默认开启的，无需网站所有者进行任何单独配置即可捕获并散列联系表格数据。这意味着，当银行工程师添加标准跟踪片段时，并未主动选择将抵押贷款申请人的哈希电子邮件和电话号码发送到 Meta，而是像素默认机制导致了这一结果。这与 Meta 声称的反对收集敏感数据的政策形成矛盾。
这并不能免除银行自身的责任。银行自主选择部署哪些供应商，在客户面前展示同意标语，并发布 Cookie 政策。双方均负有部分责任：平台提供最大限度捕获数据的默认设置，而银行将这些默认设置应用于最敏感的业务流程中。
合规风险与技术整改建议
这一问题不仅是道德层面的考量，更是严峻的合规挑战。在欧盟，未经管理的第三方脚本在面向客户的流程中超越了 GDPR 和 ePrivacy 的同意要求；对于受监管的金融实体，还需遵守 DORA 关于第三方风险和运营弹性的规则；支付流程则需满足 PSD2 的安全义务。在美国，机构需依据《格拉姆-利奇-布莱利法案》的保障规则承担责任，并日益受到 CCPA/CPRA 等州法律的约束。
除了监管压力，这也是基本的运营卫生问题。金融机构不应假设实际收集的数据与已配置的内容一致，而应验证脚本在实时开户、抵押贷款、贷款及模拟页面上的实际行为。同时，需警惕标签开始收集比最初设定更多数据的现象，即“范围爬行”。
视野需要转化为控制力。安全团队应具备阻止第三方脚本读取敏感表单字段的能力，并拦截未经授权的数据传输。同意机制必须在实践中产生意义，而非仅停留在纸面：拒绝选项应真正阻止数据离开浏览器，而不是仅仅记录一个被忽视的拒绝信号。此外，这种选择权需延伸至流动触及的任何 iframe 或子域，避免在跨越边界时重置。
除非收集行为经过记录、披露并确保合法，否则应关闭如自动高级匹配等默认散列和发送联系人数据的功能。第一方代码也应接受与第三方标签同等的审查：虽然为防止欺诈而建立的指纹识别和本地端口探测可能是合法的控制手段，但内部构建并不能消除对用户披露和获取同意的需求。
这些措施并不意味着银行必须放弃分析或个性化服务，而是要求将敏感页面上的脚本视为机构风险表面的一部分，纳入与其他供应商相同的定期审查周期，而非一次配置后便放任不管。调查显示，在被检查的 14 个网站中，有 9 个通过其自身同意标语所禁止的途径发送了数据。在监管机构或客户发现问题之前，缩小这一差距至关重要。
