银行业不惜重金打造“数据最谨慎保管者”的形象，但现实往往背道而驰。针对欧美14家金融服务网站的审查显示，嵌入在开户、抵押贷款及贷款申请流程中的追踪与个性化脚本，正将用户的联系方式、金融意图和设备指纹发送给第三方。其中，9家网站在未获得有效同意的情况下进行了此类操作。
这些违规行为主要呈现三种模式，其法律界定各不相同。
首先，部分财富管理、投资银行和支付提供商的网站，在用户尚未对Cookie横幅做出回应前便触发标签。根据欧盟《电子隐私指令》，在任何数据存储或读取前必须获得同意，因此这种行为自始缺乏合法依据。
其次，即使用户主动拒绝Cookie，追踪仍未停止。在某网站上，Google Ads和DoubleClick仍在请求URL中接收用户的哈希电子邮件，并伴随“拒绝同意”信号发送。这意味着拒绝记录虽被生成，却随即被无视。
第三，无论同意状态如何，金融细节均遭泄露。在一例个人信用申请中，2500欧元的贷款金额、12个月期限及保险选择被发送至Google Analytics；而在一家葡萄牙银行，客户姓名、年龄和税号在开户期间以Base64编码形式，通过请求URL发送给Evergage。
此外，某荷兰银行网站的第一方脚本结合浏览器指纹识别与对本地端口（7070和5938，关联AnyDesk和TeamViewer）的图片请求，实质是在检测访客设备上是否运行远程访问软件。
责任归属
Meta和TikTok此前指出，网站运营商才是数据收集内容的控制方。Meta援引其隐私控制政策及不分享敏感数据的立场；TikTok则表示仅接收合作伙伴有意配置的事件和参数，由广告商决定发送内容。
这种说法将责任全推给网站运营商，但这仅在收集内容为运营商故意开启时才成立。事实往往并非如此。以Meta Pixel为例，其“自动高级匹配”功能默认开启，无需网站所有者额外配置，即可捕获并哈希处理联系表单数据。
银行工程师在添加标准追踪代码时，并非有意将抵押贷款申请人的哈希电子邮件和电话号码发送给Meta，但Pixel的默认设置导致了这一结果。平台禁止收集敏感数据的政策与其默认收集此类数据的功能之间存在明显矛盾。
这并不免除银行的责任。银行自主选择部署供应商、设置同意横幅并发布Cookie政策。双方均负有部分责任：平台提供最大化数据捕获的默认设置，而银行将这些默认设置部署于最敏感的流程中，却未验证其实际运行效果。
缩小差距
这不仅是道德问题，更是严峻的合规挑战。
在欧盟，面向客户流程中不受管理的第三方脚本违反GDPR和ePrivacy的同意要求；对于受监管金融机构，还触及DORA的第三方风险和运营弹性规则；PSD2也为支付流程增加了安全义务。在美国，机构需遵守《格雷姆-里奇-比利雷法案》保障规则，并日益受到加州消费者隐私法（CCPA/CPRA）等州法律的约束。撇开监管风险，这也是基本的运营规范要求。
修复这一问题始于验证运行时行为，而非假设其符合配置。这意味着需验证脚本在承载高价值数据的真实开户、抵押贷款、贷款和模拟页面上的实际行为，而非仅检查主页。同时，需警惕标签收集超出最初设定范围的数据，即所谓的“范围蔓延”。
可见性需转化为控制权。安全团队应能阻止第三方脚本读取敏感表单字段，并拦截未经授权的数据传输，包括研究中多次发现的将标识符和金融细节隐藏在请求URL而非请求体内的技术。
同意必须在实践中生效，而非仅停留在纸面。拒绝应真正阻止数据离开浏览器，而非仅仅记录为被拒绝信号却仍触发追踪调用。这种选择还需贯穿客户流程触及的任何iframe或子域名，而非在跨越边界时重置。
除非收集过程已记录、披露且合法，否则应关闭像“自动高级匹配”这样默认哈希并发送联系数据的功能。第一方代码应与第三方标签一样受到严格审查：用于欺诈预防的指纹识别和本地端口探测可能合法，但内部构建并不能免除披露和同意的需求。
这并不意味着银行必须放弃分析或个性化，而是要求将敏感页面上的脚本视为机构风险面的一部分，像对待其他供应商一样定期审查，而非一次配置后便置之不理。在受审的14个网站中，有9个通过自身同意横幅声称已关闭的渠道发送数据。
脚本被允许做的与其实际做的之间的差距，值得在监管机构或客户发现之前予以消除。